My experience of Hacking The Dutch Government

Phenomenal
4 min readFeb 1, 2022

Hi Everyone! ,

Hope you’re doing well, today I am sharing my first write-up about my best finding.
It’s an SSRF — Server Side Request Forgery vulnerability that I discovered in Dutch Government Bug Bounty Program.

At first, I was so confused because there are more than 1000 domains within the scope. But later I decided to take a domain randomly from the list and started hunting on it.
Firstly I just reported some No Rate Limit & HTML Injection but no luck they all closed as N/A.
I decided to contact people who got that dutch swag and what type of vulnerability they reported and also collected writeups of the dutch government programs written by other bug bounty hunters.

After reading the write-up of Remonsec. I also started learning about Recon and followed his suggested recon posts.

The vulnerability

So again I randomly took a domain from the list started subdomain enumeration but that domain has only 1 subdomain which is like the main domain only. I focused more on the main domain and gathered some parameters using different tools and one of the parameters looks very suspicious it was like:

https://example.nl/imageproxy/220,fit/https://abc.redacted.nl/images/0737.jpg

Here the image proxy functionality was showing images of another domain
I tried to visit that particular domain but got forbidden. Then I put www.evil.com instead of https://abc.redacted.nl and successfully redirected to evil.com but open-redirect vulnerability has not much severe impact.

Now I used burp collaborator client and inserted collaborator URL instead of www.evil.com and got the HTTP hit on my collaborator, so here SSRF vulnerability was confirmed
Now instead of collaborator URL, I used localhost http://127.0.0.1 and I got the response.

Welcome to nginx!

I decided to do fuzzing for internal portscanning, using ffuf I got different ports that contain some data, and port 3030 was showing high data size, upon visiting that I got the response.
https://example.nl/imageproxy/220,fit/http://127.0.0.1:3030/

Further visiting more endpoints on that webpage and other ports gives me more sensitive data like password hashes, cluster name and ID, and many more.

This increases the impact of the vulnerability but I want to make sure that this time my report does not get rejected so I decided to look for more.

Whenever we get SSRF we also look for AWS Metadata so this time I use magic IP 169.254.169.254 which is used to retrieve aws metadata.

https://www.example.nl/imageproxy/220,fit/http://169.254.169.254/ and got the response

I google about this and came to know that metadata service supports two sets of APIs: an OpenStack metadata API and an EC2-compatible API. Both APIs are versioned by date. For more details visit:
https://docs.openstack.org/nova/rocky/user/metadata-service.html

To fetch more data I used:
https://www.example.nl/imageproxy/220,fit/http://169.254.169.254/2009-04-04/meta-data/ here I got more sensitive data like vendor data, instance id, public keys, and many more.

Conclusion

Now I was pretty sure that this will be accepted and after a few days I received the mail

Now I am waiting to receive my favorite swag.

TIP

I was hunting on this program for 4 To 5 months and as I mentioned, I got many duplicates and N/A’s, but I never lose hope and whenever someone gets that swag from the community I reach out to them and ask them all the details about the vulnerability they reported. If I ever feel like I am losing my motivation to hunt on this program I watch zseano videos.

Feel free to provide any feedback!!

Sanyam Chawla

--

--