Contact us
Request demo →
Contact us
German website
search
close

This is what happened with the vulnerabilities found at Hâck The Hague

by Cybersprint Blog 26 May 2021

At every edition of Hâck The Hague it’s exciting to see what vulnerabilities the participating hackers will discover. The systems of the municipality of The Hague itself and those of its suppliers are being scrutinized. At least as interesting though is what happens with all these findings. In the end, that is what the hacking event is all about: making the digital environment of the Municipality of The Hague safer!

Within two to three weeks after the event, about half of the reported hacks is solved. The other half takes more time to resolve, because it involves more complex systems that are only updated once or twice a year for example. Or it’s about systems that are also being used by other municipalities which means that extensive (and lengthy!) consultations are needed to resolve the issues found.

On this page we give you more insight in what happened with vulnerabilities found and how they have been solved over time.

  1. Embedded login details for API
  2. Clickjacking
  3. Request sniffing
  4. Outdated software/libraries (ex. jQuery)  
  5. Login details of a development environment on Github
  6. Attack on Wi-Fi infrastructure →
  7. An extraordinary vulnerability: security leaves keys →

Want to know more about Hâck The Hague? Visit the website for more information & registration!



 

Embedded login details for API

A mobile app of one of the participating suppliers contained an embedded account that gave access to sensitive technical information and metadata of print jobs on a specific part of the print system via the API. The system was used by mobile employees to send print jobs via a mobile app or email to the printers. The ethical hacker probably used an overview of new vulnerabilities (for example the Full Disclosure list) and open source intelligence (OSINT) to find the names of websites of the municipality.

Approach

A couple of days before the hacking event and independent of Hâck The Hague, a security researcher published a responsible disclosure about the product concerned that was used by the municipality. In this document, username and password of the embedded API account were also included. During the event, the ethical hacker probably gathered the names of the municipal websites looking for product names for which recent vulnerabilities were reported and could use the information from the responsible disclosure for that purpose.

How was the vulnerability submitted

The ethical hacker wrote a fairly short report. The impact of the vulnerability was well described and substantiated with an example of the data. Unfortunately details of the way in which the attack was executed were not submitted, but the article on the Full Disclosure mailing list with the full description was quickly found. That kind of detail though - explain how an attack has been set up - is highly appreciated. As there are many ways of executing an attack, it’s extremely relevant for us to find out in what way a particularly attack has been carried out.

Impact assessment

This vulnerability got high priority because the meta data of the print job could also contain sensitive information. Directly after this hack was being reported it was obvious that there would be no quick-fix, so we decided to close public access to this system while waiting for a patch from the supplier.

Solution

The security researcher who initially wrote the responsible disclosure of this particular vulnerability, did so after various attempts to no avail to bring this to the attention of the supplier. During Hâck The Hague, representatives of the IBD (supports municipalities with information security and privacy) were also present and we informed them about the vulnerability found. What followed was intensive contact with the municipality and the Dutch branch of the supplier which eventually resulted in a patch for the API concerned, delivered within a less than a week. Moreover, the app was removed from the Apple and Google app stores. Fortunately the deactivation of the app was not an issue for the municipality as we had other ways in which we could use the product.

Although all credits for finding this particular vulnerability goes to the security researcher who initially reported it, we like to think that the fact that one of the participants of Hâck The Hague found it as well and we were able to share it with the right people who happened to be at the event, contributed to the fact that we were able to quickly resolve this issue.


 

Clickjacking

A more challenging vulnerability as far as finding a structural solution is concerned, is clickjacking. This vulnerability allows to load a website by means of an iframe. This may lead to an attacker misleading a user of this website to execute specific actions without being aware of this.

Approach

The ethical hacker used the Iframe option in the html file with the vulnerable website as source.

How was the vulnerability submitted

The report we received contained a good description of the vulnerability. The hacker clearly identified all steps taken and even proposed a possible solution.

Impact assessment

This vulnerability got a lower priority, even though it was found and reported on various websites.

Solution

Some vulnerabilities found can be solved within a week, however, there are those that take much longer than that. What makes this vulnerability extra challenging to solve, is that a structural solution depends on action being taken by various suppliers. They just need to change a header (X-Frame-Options: deny), which in itself is easy enough, but often just isn’t implemented.


Request sniffing

Request sniffing enables attackers to obtain sensitive data by intercepting POST requests.

Approach

Request sniffing during Hâck The Hague was possible because the debug mode was activated in the production environment.
How was the vulnerability submitted
The ethical hacker shared the exploit script together with a clear description of all steps taken.

Impact assessment

This vulnerability got a high priority because sensitive data like login details were being leaked.

Solution

This vulnerability was being resolved almost on the spot after it being submitted by contacting the supplier.

 


Outdated software/libraries (ex. jQuery)

An example of this type of vulnerability that was discovered during HT, was an outdated JQuery library on one of the websites of the municipality. More specifically it was about version 1.12.4 that has more known vulnerabilities.

Approach

The hacker used no specific tools to discover this vulnerability. The information could be found in the source code of the website.

How was the vulnerability submitted

The report on this vulnerability was short and clear, with a reference to sources that contained more information on the possibilities of abuse.

Impact assessment

This vulnerability got a low priority because it did not concern specific abuse of the vulnerability. This depends on specific functions in the outdated software library and how these are being used in the webapp.

Solution

Solving this vulnerability is a challenge because updating a particular software library can have broader consequences for the application through dependencies of other components and software libraries. In this specific instance, the supplier indicated that the vulnerable functions of the software library were not being used. That was the reason why it wasn’t considered to be relevant. Furthermore, they said that an upgrade of the outdated software library was planned on the entire platform - reasons why it took some time before this vulnerability was being solved.

 


 

Login details of a development environment on Github

In a publicly accessible part of Github a piece of code of one of our developers was found which contained a username and a password of an API.

Approach

Github offers an API to search and there are tools to specifically trace this type of things (like Github-Dorks). It happens regularly that login details, private keys and other sensitive data can be found in Github repositories that can be viewed by anyone. Ethical hackers often find interesting things in these kind of places.

How was the vulnerability submitted

The report contained a short but clear description of the vulnerability. Like the exact location of the file concerned, the login details that were visible and the IP-address of the server in question. Based on this information it was immediately clear what the issue was, what system it was about, that it concerned a development environment and that the password was indeed correct.

Impact assessment

Although internal development environments are not accessible from the public internet, this vulnerability got a high priority. Login details should not be known, not even when it concerns an internal development environment.

Solution

The Github repository concerned was closed to the public immediately after the vulnerability was submitted and the developer cleaned the files with login details. Subsequently a check was being done to see if there was any other sensitive information available elsewhere. Obviously, the password of the system was also changed right away.


 

Attack on Wi-Fi infrastructure

Actually out of the scope of Hâck The Hague, but a very challenging problem: an ethical hacker reported a successful attack on clients using Wi-Fi by using software that pretends to be a Wi-Fi access point of the municipality (a so-called ‘evil twin’). By doing so, he captured password hashes amongst other things.

How was the vulnerability submitted

The report of this ethical hacker contained a clear description of the method and software used for the attack and provided an example of data captured and ideas on how to use this information for the next attack.

Impact assessment

This vulnerability got a ‘informational’ priority. Evil twin attacks are a renowned risk for which there is no solution yet, other than making sure all communication is send over encrypted connections only. What makes solving this issue extra challenging is that even WPA3 contains vulnerabilities.

Solution

As yet, there is no way to determine with certainty the authenticity of access points. For truly sensitive data, VPNs are being used


 

An extraordinary vulnerability: security leaves keys

During Hâck The Hague, one of the vulnerabilities that was being reported was that one of the security guards had left his keys for the taking in a public area. A vulnerability that can happen any time and any place, but one that is difficult to solve in a more structural way due to human behavior.

 

Hâck The Hague 2021 in the media

An awesome event like Hâck The Hague is bound to grab attention in the media. How many municipalities and organisations voluntarily allow their systems to be hacked? Not that many, and definitely not by 200 hackers at the same time! From interviews with hackers, to articles about the competition. We have summarised the most remarkable coverage for you in this blog post. 

read more

Hâck The Hague 2021 Press Release

The Hague, 27 September 2021 – Today the digital infrastructure of the municipality of The Hague was scrutinised by 206 ethical national and international hackers. Among the 125 reported vulnerabilities were; unsafe access to accounts, outdated software, the ability to inject malicious code into a website and an account that could be taken over completely.

read more

Hâck The Hague programme: sneak preview

We have planned an exciting programme for Hâck The Hague that will air on 27 September. Expect fun podcasts and videos about cybersecurity in all shapes and sizes. We tested citizens of The Hague on their knowledge of cybersecurity and held exclusive interviews with both professional and student hackers. What will they share? Here's a sneak peak. 

read more

Do you have a question?

Our experts have the answers

Contact us