CVD, EU-DSGVO and revDSG - A personal responsible disclosure experience of a data breach in the Swiss cyber landscape in 2022/23
Introduction
In late November 2022, a few days after ETH Alumni launched their new feature “Who is who” which allows them to look up and connect to other members, I came across a severe access control vulnerability. Without any authorization over the internet, it allowed extracting at least 35418 member profiles, including full name, postal address, nationality, title, graduation field, study start year, gender, profile picture and hashed passwords.
First, this article aims to provide insight into the landscape of coordinated vulnerability disclosure in Switzerland based on a real case, building a foundation to actively encourage others to report similar incidents to make the web a (slightly) better and more secure place.
Second, a personal interpretation of the Datenschutz-Grundverordnung from the European Union (EU- DSGVO respectively GDPR), together with a comparison to the Swiss counterpart, the Revised Swiss Data Protection act (revDSG), reveals several differences in the prevention, case handling and thus, the overall protection of user data.
Third, as the story unfolds, it showcases that following best practices, seriously applying the laws, and investing resources can drastically reduce attack vectors. Providing another example of the importance of cyber security and compliance with the DSGVO respectively revDSG.
Disclaimer
My primary expertise is technical. The interpretation of the EU-DSGVO and revDSG reflects my understanding of the law.
Quick Summary [for ETH Alumni Members]
This passage is for ETH Alumni members that aren’t here for technicalities but rather interested in the incident and the recommended mitigation steps. All the others may skip this paragraph.
With the launch of the “Who is who” feature on the ETH MyAlumni platform [4], a severe access control vulnerability (besides several other existing vulnerabilities) has been introduced. This provided unrestricted access without any authentication and was accessible via the internet.
While the user data and postal address leak might lead to unwanted advertisement, impersonation attempts or even online data sales, password hashes of weak user passwords can be cracked within minutes. These cracked passwords are then often used for password spraying attacks against a variety of popular online services. The re-use of such passwords can then lead to the compromise of other unrelated online accounts. ETH Alumni and the service provider don’t know for sure if and how much data had been extracted before the service was taken offline.
Important: I strongly recommend that everybody changes their password immediately. Furthermore, should you have re-used the same password somewhere else, please change it for all affected accounts. Kindly inform other users and advise them to do likewise.
The Story
The Discovery
A question I have heard numerous times is where to start looking for security issues. Many stories directly jump into the findings or issues presented by the vulnerability. While sophisticated automated tools, self-coded scripts and programs are out there scanning general or specific targets, I neither have the time nor personal interest in this activity.
The discovery was more of an accident combined with higher awareness of cyber security thanks to my background in computer science. Before I elaborate further, we have to go a step back and look at a property of the language of the internet, the Hypertext Transfer Protocol (HTTP).
HTTP is a stateless protocol, which means that web servers do not store any information about previous requests (sessions). How can the webserver know what to return, for example, when you are logged in? In that case, small pieces of text called web cookies have been introduced, which a web server can send to the requestee upon successful login. This can then be stored locally and appended to the subsequent web request to authenticate this request to the web server. The cookie authenticating the login is typically called a session authentication cookie and eventually expires within minutes or days, depending on the application.
After I checked out ETH Alumni’s new “Who is who” feature with great interest late at night, I went to bed with the open browser tabs. The next morning, while the web browser automatically refreshed the pages, in one browser tab, I had been logged out of the MyAlumni platform (the session cookie expired). Still, in another tab, the open query response reloaded just fine. The second access did not need a valid authentication cookie to succeed.
With this discovery, my curiosity was awoken, and I took a closer look, leading to this vulnerability report. While I found several additional threats and possible privacy issues, this article only focuses on the most severe of the disclosed vulnerabilities.
Interested readers can refer to the full, but redacted CVD report for a complete picture and to get an idea of how such a vulnerability report can look.
The Vulnerability
What makes this vulnerability severe is two-fold. First, while the search query seems to only return the profile picture and some basic information, in the background, a lot of personal data is fetched from the service but simply not displayed in the frontend. However, this information can be easily extracted even without additional tools. Secondly, the service that processes the search queries is not authenticated and can be accessed from the internet.
This combination allows even people with minimal knowledge to execute arbitrary search queries from everywhere, and thus extraction of at least 35418 member profiles. The video below demonstrates a simple Linux command that can be used to query the data, building the base for a more sophisticated data scraping tooling that can extract the entire dataset.
Opt-in vs Opt-out
As part of the advertisement campaign, users were encouraged to adjust their privacy settings on the platform in an opt-out scheme. By default, all members are visible in the service, and active action is required to disable visibility.
While opt-in and opt-out are valid approaches under the revDSG (Swiss law), the GDPR would not permit the opt-out scheme. This incident is an excellent example of why the GDPR takes this approach, as with the opt-in system, most likely only people actively enabling the visibility in their profile would have been affected by the data breach instead of almost all (except those that opted out).
No matter what visibility choice (except the complete enable/disable) has been selected, all data was loaded in the background and only filtered on the client side (web browser), thus effectively ignoring the user’s privacy choice.
The Reporting
The reporting process was mostly swift and smooth, which is why this section is kept to a minimum. It is limited to an event timeline and some additional explanations only.
I decided to send the initial report to the ETH Alumni head office (Geschäftsstelle) as the primary recipient, as well as the technical contact (ETH Informatikdienste) and their privacy contact (ETH Rechtsdienst). All further correspondence has been with the head office. Furthermore, the vulnerability has been reported to the NCSC via their web form [5].
Unfortunately, and almost ironically, submitting the form to the NCSC failed due to their firewall blocking the submission and thus, leading to a de-facto inability to report vulnerabilities. To be fair, the NCSC replied within the next 24 hours, offering an alternative submission option via encrypted email, and resolved the whole issue within another 24 hours, which shows their engagement.
An important note to people that want to submit vulnerabilities, is the range of competence of NCSC in these cases. Web application vulnerabilities are generally out of their scope, except if the organisation responsible for the application is not cooperating or responding to the CVD. In such cases, they would try to arbitrate between the parties involved. If you find a security flaw in a software application, they can be more actively involved by assigning a common vulnerability and exposure identification number (CVE) and helping with the publication.
Note that there is neither a requirement for official reporting nor a party that will check or ensure that the affected organisation has taken measures to prevent future data breaches. This is a major drawback compared to the GDPR with such requirements.
The Reporting
- 16.11.2022: [me] Initial discovery
- 20.11.2022: [me] Writeup and responsible vulnerability disclosure to ETH Alumni and ETH Informatikdienste, (start of 45 days non-disclosure period)
- 20.11.2022: [me] Informing the National Cyber Security Centre (NCSC) that their vulnerability submission form does not work
- 21.11.2022: [NCSC] Confirming the issue, providing email address for alternative, encrypted submission
- 21.11.2022: [ETH Alumni] Email confirmation from the executive board, informing that the service has been disabled (not the case at this point), including further steps
- 22.11.2022: [general] “Whoiswho” service disabled
- 22.11.2022: [NCSC] Form submission problem resolved
- 23.11.2022: [me] Confirming that “Whoiswho” is offline, re-iterating that the “photo_user” service is still publicly accessible
- 23.11.2022: [NCSC] Reply and findings/inputs from their side (completed)
- 01.12.2022: [ETH Alumni] Confirming the closure of the “photo_user” service, engaging an external Cyber Security firm, reporting to the Eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragter (EDÖB)
- 08.12.2022: [general] ETH Alumni newsletter (no disclosure to the members, nor password reset)
- 16.01.2023: [me] Asking for an update on ETH Alumni member briefing and password reset
- 20.01.2023: [general] ETH Alumni newsletter (no disclosure to the members, nor password reset)
- 20.01.2023: [ETH Alumni] Commit to a password reset within the next three weeks
- 10.02.2023: Article publication
- 12.02.2023: Several affiliate organisations (VESUV, IAETH, ..) immediately informed their members and asked them to reset the password (Thanks @Philipp, @Melanie for your comment)
- 14.02.2023: [ETH Alumni] Email to all ETH Alumni members informing about the vulnerability, with a recommendation to manually reset the password (an automatic password reset should eventually follow)
The Aftermath
For now, the “Who is who” feature and other reported bugs seem to either be mitigated or disabled. Therefore, they should not pose any additional risks for now, which is good. However, even though a professional cyber security firm has been consulted, users have not been informed, nor has their password been reset (the reset should happen within the next three weeks, according to the head office). While Swiss law is again more relaxed in the obligation of user notification, under the EU-DSGVO, data breaches with personal information and hashed password leaks are considered to be a substantial risk to the users. Thus, a notification of the person and the authority would be required [6].
I will update this paragraph should any important updates occur.
Conclusion- A Trilogy
The good
Being a fresh ETH Zurich Computer Science alumnus interested in cyber security, I have seen major transformations and improvements in the institutional handling of cyber and privacy incidents from talks, lectures, and personal discussions. This transformation can be seen in practice while interacting with the state bodies, where time and resources are invested in resolving these issues. This is a particularly important and a good sign towards a cyber-aware and cyber-resilient future.
The head office of ETH Alumni has been very responsive and forward coming in terms of handling this case, including progress updates, which shows seriousness and appreciation about the reported incident. This can be a totally different experience, for example, handling the “CDU Connect” vulnerability [2], ending up in a criminal complaint. I hope that other companies take this as a good example.
As many organisations and companies not only operate in Switzerland but also in the neighbouring countries of the European Union, the more user data protective and stricter DSGVO applies to them, including reporting such incidents.
The bad
Neither ETH nor ETH Alumni is enrolled or has its own bug bounty program [1]. Thus, from a financial perspective, extracting a whopping 35418 member profile dataset, including addresses, degrees, and password hashes, would be much more lucrative to sell in the darknet or elsewhere, rather than reporting it with zero financial compensation for the hours of painstaking disassembly and reporting.
The ugly
Since a part of this incident has already been reported two years ago, it suggests structural problems in data management. Questions on why this happened or how to prevent such incidents in the future have not been answered to the previous informants. This heavily reduces trust in ETH Alumni’s data processing capabilities and showcases that enforcement of compliance is required, and respectively, that reputation risks are not strong enough to ensure compliance.
A stricter data protection regulation, including mandatory reporting and a process to ensure compliance, would significantly increase data protection and resiliency against the ever-increasing threat vector on the internet and thus should be of public interest. Most of these demands are met by the GDPR, but for Switzerland, there is neither a requirement for official reporting nor a party that will check or ensure that the affected organization has taken measures to prevent future data breaches (i.e. prosecuted ex officio).
After all, no matter what minimal requirements the law sets, after the discovery, it feels like my duty to keep my own data, but also those of others, safe.
Attribution
I am grateful for all the comments, opinions and discussions with cyber experts and colleagues that heavily contributed to shaping this article.
Personal note
Your feedback is important to me. Please reach out via email if you have any questions, critique, concerns, or valuable input.
References
[1] https://en.wikipedia.org/wiki/Bug_bounty_program
[3] https://de.wikipedia.org/wiki/Responsible_Disclosure_(IT-Sicherheit)