Pinned Tweet
A Bug Hunter's Guide To CWE-200
Hello everyone, hope you'll are doing absolutely good, welcome to my full course on CWE-200 ( i know it's not a course, but i believe it's more than a course ); this will
contain my thought process and all i know about information disclosure; throughout this course, i'll be using "info leaks" instead of "information disclosure"; let's get started with what info leak A.K.A CWE-200 is, basically, an an info leak happens when an application reveals information to someone who is not supposed to see it or someone who is not authorised to access that data ( that's the basic way i can put it to help you understand ); in a simple funny way, an "info leak is when an application talks too much".
Let's talk about "info leak" and just "information", not all information is a leak; when you've an information, ask "would this information help you ( the attacker ), understand, target, or abuse the system ?", if the answer is yes, then it's a leak ( YAHHHHHH !!! );
Example :
- "the site uses HTTPS" ( not a leak ), Why ? This is public knowledge and doesn't help an attacker.
- "the endpoint redirects to localhost:5000/api/user/contact" ( leak ), Why ? Reveals internal infrastructure and routing.
So, info leak is any unintended exposure of sensitive system information that helps an attacker...
Why info leaks are everywhere ? they are not rare vulns, let's talk about what actually counts as info leaks
i'll start with, "not everything you see is a vulnerability and not every piece of information is a leak".
Take note, "Information is only a leak if it helps an attacker understand, target, or abuse the system".
If it doesn't help an attacker, it's just information... when you come across an information, here are few
questions you need to ask "is this sensitive ?", "is it supposed to be private ?", "am i allowed to access it ?",
"as an attacker, what can i do with it ?", "would I want this hidden if I owned the app ?". if you can answer
these questions, report it.
Clear Examples ( Not an Info Leak )
- Website title
- Company name
- Public documentation
- Public API fields explicitly documented
- Generic error messages "Something went wrong"
These provide no attacker advantage.
We will discuss about IMPACT as we move on, for now we just have to understand what an info leak is and
how it looks like.
Info leaks are often the first step in all, they're rarely the final exploit, basically, attacker collect leaks before exploiting.
Before we dive into where to look for info leaks, we must destroy the biggest misconception that gets info leak reports rejected.
"it's not exploitable" is a biggest lie about info leaks ( i.e company says "This issue is not exploitable" )
And in many cases, that statement is technically true, and completely irrelevant.. info leak sometimes, doesn't create immediate exploitation, sometimes it does... it's something they need to understand...
Where to look for info leaks ? basically everywhere but here's how i think of it, the golden rule is to do what the application doesn't expect... If you remember one rule while hunting for info leaks, remember this
"Do things the application doesn’t allow, and watch it talk.", This is what helped me find countless info leaks.
Example :
- visiting /api/admin/user, return my user information, but adding "*" like this /api/admin/user/*
returns all user's PII, the application wasn't expecting the asterick ( * ).
- visiting /home, returns "200 OK" with the necessary information, but adding a forward slash ( / ) after
/home i.e /home/, redirects to http://localhost:6500/api/v2/home/contacts. the application wasn't expecting the ( / ).
Now, let's talk about severity, impact and escalation...
Info leaks can be labeled low, medium, high or critical, it'll depends on how sensitive the information is; the more sensitive the information, and the more it enables further attacks, the higher the severity.
low severity info leaks can be "internal file path/port/IP leak", medium severity can be "user PII leak i.e contact details that's not meant to be public", high severity can be "internal API key that could lead to access to restricted resource", while critical severity can be "Credentials or tokens", "Database connection strings"... take note "Info leaks are rated by sensitivity and attacker value, not by how flashy they look."
I reported a vuln that discloses internal hostname and port number along-side an endpoint, the program requested for more information regarding the impact, and i responded saying "am unable to prove impact due to i can't connect to the service i.e localhost:6500"
this response got my report accepted; the bounty was actually $$$... i wasn't expecting it.
Most companies wants you to do actual exploitation with that leak, i reported an info leak that discloses internal database table name, and the company close it as informative saying that i should prove exploitability; for me, this is wrong; because, database table name, by default, is private, but i got access to it...
I know that if i report same issue to another company, it will get accepted, so i'll likely say, it does depends on the company; some understand the risk, others need convincing.
This guide might not help you to fully understand CWE-200, but i believe it'll make things easier for you... don't forget to go through writeups/disclosed reports on CWE-200 ( info leaks )... i wish you goodluck.
Lastly, learn google dorking, it can help you find info leaks ( 100% )
( medium.com/@4osp3l/the-art-o… )
This is not a vulnerability in Microsoft Azure Application Gateway itself, but rather a misconfiguration in how the WAF is configured for the underlying web application.
Okay i noticed something; as long as the query contains the string ".js", the bypass succeeds; so ext like .jsp,.jsanything bypasses the Page. I will share more information on why this is possible and what layer causes that to happen; i am still studying the case.
Okay, the last time I used @BugBunny_ai, i wasn’t that impressed with it. But this time, i got access to it again, and man, it’s doing a really great job.
I’ve got a couple of valid vulnerabilities pending, with one already triaged. I’ll definitely share more updates.
Have you all seen the movie “London has fallen”; it’s a pretty interesting show… the attack was unexpected… but it looks like we got a new show “PHP has fallen” and this one is about to get interesting.
