Hacking the Dutch government

A few months ago I found out that the dutch government is hosting a bug-bounty program that covers a lot of assets from their infrastructures.

The program scope available at https://www.communicatierijk.nl/vakkennis/r/rijkswebsites/verplichte-richtlijnen/websiteregister-rijksoverheid appears to be really wide, with more than 1000 targets, that allowed to find some interesting application by running some basic passive subdomain enumeration checks.

Once obtained a list of in-scope subdomains, i started performing some basic HTTP services enumeration, to gather information such as the response headers and the technology stack in use.

A key aspect when testing for vulnerabilities in large organizations or applications is to search for differences in the way the technologies stacks are implemented. For example, if a company mostly uses Apache web servers, but has one server running a different technology like IIS, it could be a sign of potential vulnerabilities. This is because the different technology might have unique configurations, settings, and security protocols that could create new attack vectors.

Finding the Bug

After the enumeration stage, i started focusing on a domain that had several targets running Apache but one running IIS, which was a book library platform related to the dutch police academy.

After quickly digging in through the JavaScript files, I found an interesting endpoint, which was carrying a URL as a parameter value. This functionality exposed the application to a Server-Side request forgery vulnerability, that allowed the exploitation of 3 attack vectors.

Server-Side Request forgery

Server-side Request Forgery (SSRF) is a security vulnerability that allows an attacker to manipulate a server into making unintended requests, usually to internal resources that are not intended to be accessible from the outside. In some cases the attacker can see the response from these requests, revealing sensitive information such as internal network configurations, sensitive private services and other confidential data.

To verify the issue it was possible to receive an HTTP callback to a publicly accessible host (burp collaborator)

Request received on burp suite collaborator

As mentioned earlier, this could have been exploited via 3 different attack vectors.

1. Reflected Cross-Site scripting

As the external resource provided is directly embedded into the page, it was possible to exploit a reflected cross-site scripting vulnerability by hosting an html document with javascript code in it.

When the same resource is loaded by a browser, the payload is executed.

2. Internal assets disclosure

Internal networks could have been reached, causing the potential disclosure of reserved assets and / or internal services. This scenario is really common for this class of vulnerability.

3. Gopher protocol support

The target was running PHP, and a phpinfo file disclosure showed the
php_curl configuration used by the vulnerable component:

supporting the gopher protocol allows attackers to send arbitrary request body data to targets, being able to interact with services such as mysql, ldap, redis or any other using an unencrypted protocol for its communications. I actually made a pwnx lab that covers a gopher abuse scenario.