Key Points
Automated scanning is an essential part of any cybersecurity program, but some vulnerabilities are simply too layered, obscured, or intricate for scanning tools alone to detect. That’s where Intruder’s Private Bug Bounty service makes the difference. Our expert penetration testers continuously monitor your changing attack surface to find critical vulnerabilities that scanners might miss – but determined threat actors won’t.
To explain the types of complex, layered weaknesses we’re talking about, we're sharing some examples of significant issues recently discovered by our security team – vulnerabilities that required human expertise to detect and have since been resolved, helping our customers stay one step ahead.
Getting a shell with a hidden weakness
Vulnerability scanners excel at picking up known vulnerabilities, either by executing checks which safely and actively exploit a vulnerability, or by detecting software versions and cross-referencing these with vendor advisories. However, version numbers aren't always disclosed by the product, and many products are patchworks of other software and frameworks put together. So, more finesse is sometimes required to figure out exactly what is running under the hood of a web application.
While hunting for bugs in an app that allows users to digitally sign documents, we noticed that after signing a PDF, its metadata listed "Exiftools" as the document creator. Recalling some powerful exploits in Exiftool from recent years, we had good reason to dig further to see if a vulnerable version was in use. Though the application didn’t reveal which version was running, the tester’s instinct led us to run through all the recent known vulnerabilities in Exiftool, and sure enough, after creating and uploading a malicious PDF containing a payload that exploits CVE-2021-22204, we got a shell:
This was a good find for the client: even advanced vulnerability scanners lack the contextual awareness to compare PDF uploads before and after processing, notice Exiftool is in use, and build specific exploits to target the weakness. Without a Private Bug Bounty service, this vulnerability could have been found by a determined attacker, and a shell as www-data is an excellent initial foothold.
Using SSRF to steal AWS secrets
If a web application takes a URL as a parameter from the user and fetches the resource, care should be taken to ensure an attacker can't trick the app into fetching something unintended. Known as Server-Side Request Forgery (SSRF), this is a common vulnerability in modern applications that can have a significant impact, particularly against applications deployed in the cloud.
An example of an application falling victim to SSRF when not properly secured was discovered when investigating an app used for moving homes. This application allowed users to send a test webhook to a user-controlled destination - the response was logged and could be viewed within the application.
This particular application was running in AWS, and could be tricked into fetching data from the cloud metadata service IMDS. Direct access to the metadata service IP (169.254.169.254) was blocked by the application’s validation, and attempts to use a domain name resolving service as a workaround also failed. We attempted a few more bypasses for common security controls, and one landed – the attack chain went as follows:
- Application sends a webhook request to the attacker's web server
- The attacker's server responds with a 302 redirect to
http://169.254.169.254/latest/meta-data/... - Application sends a request to
http://169.254.169.254/latest/meta-data/...and the response from that request is logged and shown to the user
Once again, this is an attack chain that would not get detected by purely automated tooling, due to the multi-step workflow and use of an attack server supplying a redirect. Even the most advanced automated tools can miss this type of involved attack chain, so a human eye is often required. Again, this exploit provides an attacker with an excellent initial foothold into the cloud environment – by enumerating the permissions of the exposed IAM credentials, they would next seek to pivot into the cloud environment.
An interesting point to note about this vulnerability is that it relied upon the metadata service not being hardened with best practices for AWS by enforcing use of IMDSv2. This highlights an example of how automated tools, despite being less advanced, can still often save the day. While automated tools would have been unlikely to find the end-to-end vulnerability, a good cloud security scanner would have highlighted the lack of best practices here, and breaking that part of the chain would have prevented the vulnerability being exploited.
Upgrading self-XSS to hijack accounts
Cross-Site Scripting (XSS) vulnerabilities are a good vehicle for carrying out session hijacking attacks against site users, particularly when they don’t require any interaction such as the user clicking on a link. A "Self-XSS" weakness is one that is usually only exploitable in the attacker’s own browser, presenting very little risk, unless it can be combined with another vulnerability. The following example shows how we upgraded an innocuous Self-XSS into a persistent exploit that could be weaponized to mass-exploit all application users and take over their sessions.
While hunting on an auction application, self-XSS was discovered: a user-supplied HTTP request header was reflected in the application's response:
An attacker typically has no way to make a victim's web browser send a malicious HTTP header with the request, even using a malicious link. This makes this XSS vector quite harmless on its own. However, when combined with a cache poisoning vulnerability, it is possible to trick the app into caching a response containing the payload, and serve it up to all site visitors.
We then hunted for a cache poisoning weakness on the same application, and found it was vulnerable! This allowed us to combine the two weaknesses and make site-wide persistent XSS possible. The combination of these weaknesses could be abused to take over the user account of any site visitor, including administrators.
The reason this works is because the part of the request used to elicit the malicious payload was “unkeyed” by the cache, meaning the cache ignores it in its uniqueness constraints. The detail is a little complex, but for those interested, there’s an excellent explanation of how this all works here.
A vulnerability scanner alone is likely to find the self-XSS and rate it as Low impact, and some scanners may also be able to detect cache poisoning. But only an astute human tester can combine these weaknesses to report this exploit chain which has High-to-Critical impact.
Simple API weaknesses with impactful results
API weaknesses are still way more common than most would believe, incredibly easy to exploit, and often seriously impactful.
In a wide range of APIs of all kinds, including 'hidden’ APIs which take enumeration effort to discover, we’ve found innumerable IDOR weaknesses. These are so easy to exploit that there’s not much of an attack chain to explain here, and really the challenge is to first find the endpoint and then, crucially, realize that it exposes sensitive information.
We’ve listed a few HTTP requests and paths below that we have found lately, each of which exposed high-severity sensitive data belonging to other application users or administrators:
GET /organisations/edit_user?user_id=1234
GET /prod-applicantresumes/1234.pdf
GET /transcription/1234/transcript
POST /Order/Download, OrderNo=1234
Exploiting an IDOR weakness is as simple as changing the identifier to a resource that the user does not own.
Although these weaknesses are typically as simple to exploit as changing a number, they are often difficult for scanners to find, because they lack the context of “what is sensitive?” in a response, and the ability to understand which data should be exposed to which type of user. All automated scans happen within a context, e.g. from the perspective of a ‘Customer’ type user belonging to the ‘MyCorp’ organization. When a scanner uses lists of payloads and identifiers to make requests, it lacks the context to know that when it requests data for CustomerID=1001, that data actually belongs to users from ‘OtherCorp’, and the application should be responding with an authorization error.
Reviewing exposed code to break into an application
Raw vulnerability scan results can be reviewed to pick out findings that require more investigation and could be escalated into something with a higher impact. In this last example, we investigated an unintentionally exposed .git repository, which the scanner picked up.
Some basic hunting revealed that the repo was for a web application – one that was exposed publicly. Further review of the application’s code led us to discover an auth bypass vulnerability: the app’s login page could be circumvented entirely by supplying a hidden parameter to the login request. This parameter wouldn’t have been easily guessable to an attacker without the source code.
Once we’d logged in, the application gave access to a management tool, which didn’t have any particularly sensitive functionality that might be useful for an attacker. However, after some testing, we then discovered a blind SQL injection vulnerability present in an application page past the login:
/[…]status.php?search=abc'%20and%20(select+*+from+(select(sleep(20)))a)--%20
Using the injection vulnerability, it was possible to access a rich database of students’ and staff’s personal information for a university.
Find the issues that scanners can’t
Intruder’s Private Bug Bounty service is available as a bolt on for Intruder’s Premium plan customers. And it's a breeze to get started: just tell us how many days of testing you'd like (spread out over a contract year) and we’ll take care of the rest.
Why it works for you:
- Year-round continuous testing: Protect your digital estate year-round with continuous coverage that a point-in-time pentest simply can’t provide. Threat actors don’t wait - so why wait for your next annual pentest when you could be vulnerable now?
- No noise, just high-impact vulnerabilities: We only report validated, high-impact vulnerabilities, sending them directly to your user portal. That means no distractions from low-impact issues that don’t require action.
- Fast, proactive, and reactive ethical hacking: When new vulnerabilities emerge, our team checks your estate for exposure - without you having to do anything. And as your attack surface evolves, we proactively hunt for newly introduced vulnerabilities, keeping you one step ahead.
If you want more information about Private Bug Bounty or the other features available with our Premium plan, check out our pricing page or book some time to chat with us.
Dan heads up the Security team at Intruder. His background is in .NET software engineering, consulting, and penetration testing.
