When automating wayback machine and ffuf is not the answer, or manual analysis ftw

# Summary
The article emphasizes the importance of manual analysis over automated tools like Wayback Machine and ffuf when investigating web endpoints for security vulnerabilities.

# Abstract
The Wayback Machine serves as a valuable tool for initial reconnaissance to uncover obscure paths and endpoints that are unique to a company's naming conventions, which may not be present in public wordlists. While automated tools like ffuf can quickly analyze a large number of endpoints, they may not always identify endpoints that are still useful but return non-200 OK status codes. The author illustrates an instance where they encountered a list of endpoints that suggested potential IDOR (Insecure Direct Object Reference) vulnerabilities. Despite using ffuf to identify valid endpoints, a manual inspection was necessary to discover additional security issues related to parameters, such as XSS, SSRF, SQLi, and RCE, by examining the similarities and differences in endpoints with and without required parameters like api tokens. The article highlights two types of 'broken' links: those with invalid API keys that can lead to the discovery of additional API endpoints, and those requiring additional paths or parameters for a valid request. The author concludes by stressing the risks of solely relying on automated verification of endpoints and advocates for the value of manual analysis in certain scenarios.

# Opinions

- Automated tools like ffuf can miss important details when analyzing a large list of endpoints, especially when parameters and tokens are involved.
- Manual analysis is crucial for identifying endpoints that are not immediately flagged as valid by automated tools, and can reveal security vulnerabilities that require a deeper understanding of the context.
- The presence or absence of certain parameters, like API tokens, can significantly change the response of an endpoint, which automated tools may not always interpret correctly.
- The article suggests that security researchers and penetration testers should not rely exclusively on automation for reconnaissance and should invest time in manual analysis to uncover more nuanced security issues.
- There is an inherent risk in assuming that endpoints found in the Wayback Machine are either valid or invalid without proper manual verification, as the status codes alone may not tell the whole story.

Wayback machine is an awesome resource for a quick recon. It helps in finding sometimes obscure paths and endpoints specific to that company’s way of naming things, the words and paths that aren’t in any public wordlists. And a quick way to analyze those endpoints when there are too many for a manual approach is to use ffuf or equivalent. But, what if some of those endpoints that aren’t 200 OK according to ffuf are in fact still useful?

The broken puzzle There are endpoints that end up in wayback machine which don’t make any sense, usually because they seem to belong in js files or html source code (ie. html.onmouseover, innerHTML.onfocus, etc.) and are never, or rarely a part of a proper link (unless if it’s xss payload). And those are pretty useless. But then there are the “broken” ones, the ones that make sense, which, if you’re looking to leave it all to automation may mean you’ll miss some cool stuff.

Putting the pieces together On one occasion I found myself with a sizable list of seemingly interesting endpoints. It had tokens and the naming of those endpoints suggested a very interesting IDOR. I used ffuf to quickly verify what was worth looking at, and ffuf did found some valid endpoints. Still, being that the list was huge, and it had parameters, I figured, let’s see if I can get something more when attacking the parameters, like xss/ssrf/sqli/rce. Looking at the list, I noticed that there were similarities within endpoints, as in, some were lacking the token param compared to their pair that actually had it. And then some endpoints implied connection to the overall api, but were giving 403 because, as it turned out, they needed the token param.

Here is an example of two types of 302 redirects depending on the token’s presence:

I had to blackout bunch of stuff, but next screenshot will make this one make more sense

Note the Location header and pretty big Set-Cookie value

And here is an example of an endpoint that didn’t have api token, and then how it responded with a valid api token that was found in wayback machine:

As you can see there’s only one param and response is 400 Bad Request

And here you can see an additional param apiToken, and the response is 200 OK

The two types of broken links Now, I pretty much see that there are two types of broken links: 1 — some of the api keys not working for one endpoint, but the other endpoint that has valid api key means that we just got ourselves an additional api endpoint. 2 — some of the endpoints require additional either paths or params or both. It doesn’t have to be a special key, it can just be something that’s essential for the Request to be valid and to give a valid Response, otherwise, it will give 404 or 400, or even 301/302/500, depending on the configuration.

Yet another lesson/reminder of risk when it comes to relying on automating verification of even something as simple as wayback machine’s archived endpoints. In other words — manual analysis rules, sometimes. :)