How I Found Multiple Vulnerabilities on Dutch Government

As a newcomer to the field of bug hunting, I have always been drawn to targets with expansive scopes. The Dutch government’s VDP caught my attention through discussions with my colleagues. With over 1900 scopes listed and a cool t shirt as a reward, it presented the ideal opportunity for someone with my interests.

After many failure and invalid reports for a month, I almost gave up on Dutch. After some extensive research, I decided to change my methodology. I need to do something that other researcher haven’t done before. I started looking deeper and it worked.

I never imagined I would find such a simple yet crucial bug like this. The Apache Server Status for that domain was visible. I don’t think I can show the actual page for server status but it looks something like this:

I could see all the request coming to the server.

It got fixed after two week and I got my first swag, Cool T-shirt from Dutch.

There was login page on the target. I noticed something different on that page. There was a hidden input div in which the URL was reflecting. So, I tried escaping characters from that div and it worked. But I could not close the div with “>” due to WAF. I tried many bypasses including HTML encoding, URL encoding, double encoding, special characters and so on. Nothing worked so I must execute the XSS within the input tag.

I looked for payload on portswigger: https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

I found this payload:

<input type=”hidden” accesskey=”X” onclick=”alert(1)”> (Press ALT+SHIFT+X on Windows) (CTRL+ALT+X on OS X)

This payload only works on Firefox. When the accesskey “X” is pressed it executes the XSS.

Payload: ;default’%20accesskey%3d’X’%20onclick%3d’alert(document.domain)

And voilà. I reported it and it was fixed after a month. I got my 2nd swag.

After many failures and XSS on static sites, I gathered sites which contains login pages. I tried SQLi payloads, Blind XSS on every form I see.

Tip: Unhide hidden form fields in burpsuite settings.

Always check hidden fields

After an extensive month-long testing period on the Dutch, I successfully identified a critical vulnerability: an OR boolean-based blind SQL injection (SQLi). This significant discovery was located within a hidden field of the registration form, specifically affecting the ‘channel_id’ parameter. The form was submitted on TRUE and was giving error on FALSE.

So, I tried sqlmap and for some reason I wasn’t able to dump anything. Maybe the WAF was blocking my request. Since this time based payload worked “if(now()=sysdate(),sleep(10),0) — “, I decided to create a script to dump database.(Playing CTFs paid off I guess) I put delay so that the WAF doesn’t block me and after some time I got few table names content from “information_schema”

I used this payload in the script:

if((select%20SUBSTRING(table_name%2c$number%2c1)%20from%20information_schema.tables%20where%20table_schema%3ddatabase()%20limit%200%2c1)%3d’$alphabet’%2csleep(10)%2cnull)

which proved that it was vulnerable to SQL Injection. So I reported it.

And after 2 days it got triaged.

And after two weeks It was fixed and I got my final T-shirt.

In cybersecurity, it’s all about sticking to your goals and how much you really want to achieve them. My experience finding weaknesses in the Dutch government’s systems shows that if you keep at it and really want to find something, you will. If I had just given a quick look and moved on, I would have missed these hidden issues. It’s a reminder that hard work and a strong desire can lead to important discoveries that make a difference.