[HackerNotes Ep. 67] VDPs & Accidental Program VS Hacker Debate Part 2

The guys deep-dive on the topic of Vulnerability Disclosure Programs (VDPs) and whether they are beneficial or not. We also touch on the topic of leaderboard accuracy, and some methods of bypassing endpoints which have been restricted by WAFs or reverse proxies.

Hacker TLDR;

  • Bug Bounty VDPs: Nagli’s tweet gained a tonne of traction around the current ecosystem with bug bounties and VDPs. The full link is here, but in case you missed it, a short summary:

    • Worsening experience for Bug Bounty Hunters and Paid Bug Bounty Programs

      • Significant Triage Burn-Out

      • Absurd triage times

      • non-existing communications on submissions

      • Mediations are completely dead

    • "Free Labor" / "Can only find bugs on VDPs"

    • Leaderboards are not trust-worthy

    • Samescope VDPs and bug bounty programs where they pay for one but not the other

  • Bypassing Walled-off Endpoints: Walling off an endpoint with a WAF or some form of reverse proxy is quite a common control to prevent access to a specific endpoint. Fortunately, there can be a few instances where we can bypass them:

Bug Bounty VDPs

In case you missed it, Nagli presented a very compelling argument on the current state of VDPs and what they’re doing to the bug bounty community, full tweet here https://twitter.com/galnagli/status/1780174392003031515:

A quick TL;DR of the thread:

  • Worsening experience for Bug Bounty Hunters and Paid Bug Bounty Programs

    • Significant Triage Burn-Out

    • Absurd triage times

    • non-existing communications on submissions

    • Mediations are completely dead

  • "Free Labor" / "Can only find bugs on VDPs"

  • Leaderboards are not trust-worthy

  • Samescope VDPs and bug bounty programs where they pay for one but not the other

Some pretty valid points here, in my opinion. You can’t argue with them, but equally, VDPs do still have their place in some situations.

One of the big gripes in the community is with some of the larger companies - Ford and Redbull for example. Despite having a substantial market cap, up to the tune of $44bn, researchers aren’t rewarded for their findings.

To add to this, it also has a knock-on effect on the platform (to add to Naglis's points above) and there isn’t much incentive for researchers to actually report anything aside from farming points on the platform, which brings me to my next point.

Now, when you have people hunting exclusively on VDPs and still getting points for it, it can massively skew leaderboards on the platform. On some platforms such as HackerOne, there is no differentiation between VDP & bounty points which can lead to some pretty deceptive leaderboard stats.

This is a problem because VDPs naturally have a lot fewer eyes on them as there isn’t anywhere near as much of an incentive (aka no $) which means it's easier to find bugs. If you hit a target with a good bounty table, it’s probably going to be much harder to find similar bugs.

Despite this, there is a case for VDPs not being all that bad. If you take a smaller org which does take their security seriously, but budgets are stretched for security already (usually the case for smaller organisations), VDPs can provide a good middle ground of ‘Hey we don’t have a financial incentive for you but thanks for the research’ AND being able to report things to the org.

One platform which took the reigns on this problem was BugCrowd. For BugCrowd, there’s a clear separation between VDP and bounty targets and points which seems to be working.

One of the HackerOne cofounders, Michiel Prins, also seems to be hinting at some upcoming changes to HackerOne https://twitter.com/michielprins/status/1780761283077521566:

Perhaps VDPs could have their own leaderboard and could be limited to company statistics such as total revenue, non-profit, or if the organisation is a charity?

Bypassing Walled-off Endpoints

A common control to prevent chaos from breaking loose when a new 0 day has dropped is to wall off endpoints. This can either be done on a WAF or reverse proxy and essentially puts a stop to all traffic hitting a certain endpoint, take /admin/login as an example.

Now although this might seem like a solid solution on the surface, if you dig a bit deeper, this control can sometimes be bypassed on targets.

Some really cool research highlighting this was covered in PortSwigger's Top 10 Web hacking techniques, titled ‘Exploiting HTTP Parser Inconsistencies’ - Full URL here: https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies

I covered this previously, but in case you missed it, here is a summary:

The research focuses on parser discrepancies between Nginx and different backend technologies. Different backend languages treat characters differently than Nginx, resulting in inconsistencies when interpreting a given path.

When ACLs and controls are usually applied per endpoint, this makes for some pretty interesting impact scenarios when you have the webserver and the backend parsing a route differently from each other.

Nginx supports the capabilities to rewrite, block or trigger rules based on strings or regex based on input from the HTTP pathname. This is done by specifying location rules which look like the below:

`location = /admin { deny all; }

location = /admin/ { deny all; }`

Nginx performs normalization on paths before checking them - so transforming and standardizing URLs to a consistent format by performing things like decoding and so on.

Equally, each backend does the same. Each language has its own spin on how the trim or strip function is implemented, essentially meaning each language has differences in which input it removes from paths passed to these functions.

Two examples of this are given in the research:

Now the research highlights some nice examples of how this might look when it comes to impact. Using the same block rules specified above, the below HTTP request would be permitted by Nginx as it’s not recognized as /admin, get passed to the Nodejs backend which trims the character passing it to the associated /admin route:

It is worth adding that some backends parse the path piece differently, allowing you to start the path with an @ character, ; and so on depending on the flavour. You can even put full HTTP URLs here too depending on the implementation for compatibility between HTTP versions and proxy configurations.

Tools and Wordlists

Equally, there are a few tools such as 403Bypasser which do this in a more automated fashion. It focuses on some URL tampering techniques alongside a range of headers which can be used to trick these gateway devices which implement rules.

Some other tools which do similar:

HackTricks has additional information on the tools and bypasses here: https://book.hacktricks.xyz/network-services-pentesting/pentesting-web/403-and-401-bypasses

JHaddix also added a new addition to SecLists lately with a whole bunch of URL manipulation methods which can be equally as effective: https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/403/403.md

Some more exotic means of bypassing these sorts of defences are also possible - one cool use of HTTP Request Smuggling I saw was a writeup from a researcher on Tesla, essentially using request smuggling as a means of bypassing a protected endpoint. Check it out here: https://bugcrowd.com/disclosures/5e1f7404-5421-4f3d-916a-443446afbb52/authentication-bypass-through-http-request-smuggling-on-https-apm-ap-tesla-services

Till next time. Happy hacking!