|
Hey, it's EdOverflow!
What springs to mind when you hear the term "wordlist"? Think about it for a second.
Did you think of those stock wordlists that come with your favourite directory brute-forcing tool? What about SecLists? Not to downplay the fantastic contributions these projects have made, but this newsletter aims to encourage to try something new — dynamic and heavily-curated wordlists.
What I mean by "dynamic and heavily-curated wordlists" are wordlists that you created manually or using information from the target. A couple of months ago, I did a little demonstration to a handful of bug bounty hunters where I blindly picked a target and then worked my way to find a bug without doing anything but using dynamically-generated wordlists. The trick here was to use the information I had gathered from the target to determine what type of technology they were using and what naming conventions the developers used. In doing so, I was able to access high-privilege endpoints that had been left open by accident. First, I started by doing a general breadth-first search and very basic reconnaissance that most of us are familiar with. However, instead of jumping right at anything that stood out, I focused more on understanding how the target was built. This meant if I discovered an endpoint reflecting specific keywords or hinting towards a particular technology, I would keep a note of that. Then once I had all the information I needed, I started digging deeper into the technologies themselves by looking up relevant documentation and code.
For a more concrete scenario, let's take a recent bug bounty target I looked at. The target returned a blank index page, directory bruteforcing with very basic wordlists did not reveal much, and passive sources did not uncover much either. However, the subdomain was titled "wiki". This gave me the impression we might be looking at a self-hosted wiki instance. What technologies might a company use to run a wiki page? Well, I knew about WikiMedia which happens to be open-source (https://github.com/wikimedia/mediawiki), so I cloned the code repository and generated a new wordlist with all the paths from the repository.
git clone https://github.com/wikimedia/mediawiki.git
cd mediawiki/
ls -d -1 "./"**/* | sed '^\./' > mediawiki-wordlist
After running this newly-generated wordlist, it suddenly became apparent that I was looking at a semi-installed and misconfigured MediaWiki instance. What was once a blank index page staring at me, was now an old PHP application with lots of attack surface.
In addition to creating wordlists from code repositories as described above, I would suggest adding the following Bash function to your .bashrc file, which allows you to run add "path" whenever you want to submit a new entry into your wordlist. Read a neat blog post about a vulnerability on a specified endpoint? Add it to your wordlist if you think you might stumble across that endpoint.
add() {
if ! grep "$1" ~/wordlist > /dev/null; then
echo "$1" >> ~/wordlist;
else
echo "$1 already exists."
fi
}
To wrap things up, you cannot write a piece on "wordlists" without referencing the amazing work Shubham Shah and his colleagues have done. If you can haven't already, please take a moment to watch "Catch Me If You Can" that was presented at 44CON last year.
Now go find some bugs!
P.S.: One small unethical bug bounty tip that you should never attempt to do. Definitely, don't ever sign up for a web application security scanning service and generate wordlists from your logs while it scans your website. ;)
|
