The administration of Baden near Vienna actually only wanted to solve a small problem: only locals should visit the recycling yard, operated by the city’s building yard, and they should only die a maximum of 52 times a year. Instead of having your ID shown to you on site with every visit and keeping a tally on paper or in Excel, the city opted for a digital solution with a snappy name: the BadenCard.

At the end of 2020, the administration then considered a further development: In future, the card should cost 15 euros when it is issued and 10 euros per year thereafter. However, because the owner’s data was not recorded in the first version, the city asked all those willing to dispose of it to go to the citizens’ office in person to issue a new card. The prospect of standing in line every year and taking numbers in the town hall does not suit everyone in Baden, and the local politicians from the liberal party NEOS took the opportunity to loudly demand the possibility of online renewal and, on the occasion, a digital strategy for Baden. An online extension is not only a good idea for the future during the lockdown.

At the beginning of 2022, the city proudly agreed: “The municipality of Baden has created an online solution that allows both the extension itself and the payment to be made conveniently at home.” The payment worked, as you are used to from many web shops, by direct transfer or credit card, and the services of the Austrian payment service provider Hobex were integrated.

curious looks

One of our Austrian readers also took a curious look at the new offer. The link to the portal that the city had included on its website was suspicious at first glance. It ended with the path cgi-bin/web_if/web_if.cgi – unusual for a portal that one would have guessed at an easy-to-remember address like card.baden.at. If you omitted this path specification, a CGI test page said on the server. Not exactly what you would expect from a finished and productively used application. Since an application that behaves so suspiciously in the background is often worth a closer look, our reader takes a closer look around the server and examines common paths that have been responsible for data leaks elsewhere.

All gates open

At the beginning of March 2022, an email with a note landed in our investigative mailbox (can be reached via heise.de/investigativ). The attentive reader had discovered that the web server on the path /data was garrulous: the so-called directory listing, which almost all web servers have built in, was activated. If it is switched on, the server generates an overview page with all the files and folders in it for each folder that does not contain an index website, which you can easily download with a click. This is intended more for the development phase, this page has no place in finished applications.

We look at the URL and were able to get an idea of ​​the extent of the problem. There was no password protection, all folders with all data could be viewed directly. In addition to files with cryptic names, the file meldeamt.dbf (last changed on March 8, 2022, the day we accessed it) immediately caught the eye, which was 8.4 MB in size. dbf files belong to the antiquated database system dBASE II, which was introduced in the 1980s. The fastest way to open the dbf files, each of which contains a database table, is to use the Calc spreadsheet from the LibreOffice program family.

What we had feared based on the file name was revealed to us: surname, first name, address, gender, date of birth and information on whether it is a primary or secondary residence on 33,483 lines. According to this database table, 28,400 people have their primary residence in Baden – slightly more than the 26,037 that the city itself states on its homepage under “Baden in figures”. One can also assume that we had found the city’s complete registration database.

The cards.dbf table extends even more data fields. It apparently contains the data records of the 14,420 BadenCards issued. In addition to the postal address, which was entered in all data sets and was probably taken from the registration database, some users also stored an e-mail address and a telephone number. In addition, the table information on the plastic card such as the ID of the built-in RFID chip and the validity of the BadenCard.

As if that wasn’t enough personal data, the server still had a lot of text files with the character string “Hobex” and JSON objects on offer. These are apparently the transaction logs that the payment service provider Hobex generates when a citizen has paid their 10 euros for the next 365 days of disposal pleasure. The data is transmitted, among other things, name and billing address as well as the IP address. After all, when paying by credit card, you only see the last four digits of the credit card number – but with instant transfer, you see the full IBAN.

With these findings, we ended the search and informed the data protection officer of the city administration on March 8th with a reference to Responsible Disclosure. We pledged not to report on the case while the problem persists. The leak was temporarily sealed the next morning. The web server responded with “403 Forbidden”, but only the directory listing was switched off for the time being. A little later, the entire server was no longer accessible and the city’s homepage said: “The online extension of the Baden Card is temporarily not possible due to maintenance work!”

In our e-mail we had asked for answers to questions about the problem within 14 days – the authority let this deadline pass without any reaction and we didn’t get an answer to our request either. The Austrian data protection authority was more willing to provide information. She confirmed that she was informed on March 11 under Article 33 of the GDPR and that the procedure is still ongoing. When asked what the consequences of the serious negligence would have for the city administration, the spokesman replied: “An imposition of administrative penalties on authorities is excluded in Austria by § 30 paragraph 5 DSG.”

hands off

From a technical point of view, there are hardly any new lessons from the case, especially the old insight: There is actually no good reason for directory listing on web servers; This overview page makes it extremely easy to find useful data in directories. But turning off the directory entry is not enough: Databases and other sensitive content such as logs do not belong in a directory that IS delivered by a web server via HTTP. And if there really is a good reason for this, only behind a secure authentication – but there are almost always better alternatives such as retrieving sensitive data via SSH.

The basic architecture of the BadenCard platform was also problematic. Their server stores more data than is absolutely necessary for the task. Anyone who is commissioned to design an application should think carefully and calmly about whether there is a way to get by without a constantly updated copy of the entire population register. The demand for data economy is not an unworldly idea from data protection legislators, but reduces the damage in the event of a leak like this one. If, for example, the birth data is only to be used, as in this case, so that Baden Card holders can register with their card number and date of birth, the birth data can also be treated like a password and saved as a hash.

Monitoring tools, which usually call up a URL on a regular basis and trigger alarms if a page cannot be reached – for example if the server is down – can provide rudimentary protection against comparable data leaks. We recently presented such a tool with the open source software Uptime Kuma. Such applications can often also be operated in an inverse mode: it then sends an alarm by e-mail or messenger if a page that is not intended for the public is widely expected to be online. Configuration errors do not go undetected for long if all paths worth protecting are dutifully included in the monitoring.

However, such technical helpers can only support and do not replace the critical view of admin colleagues or external penetration testers. This view is sharpened if you, as an admin or developer, put yourself in the role of potential data thieves and try out common attacks with a test environment, for example.

(Jam)