Reading the Docs for literal leads.
Good evening everyone. It’s been a long yet productive day and I’m doing my darndest to get this post out before we hit the brick wall of Monday. I’ll go over this post as needed to clean up links and formatting later on. First up, our update for the month.
This month has been exploratory once again. I challenged myself to utilize visual studio code, finding the ins and outs of Node, React, Next, Docker, Eslint and Graphql. I got a docker image for a default site up and going, learned the ins and outs of git and Github’s version control, and found a great way to fork and pull packages kicking and screaming through Eslint for vulnerabilities.
Another thing that happened was learning from a misstep or two. I had hoped to build a webpage as part of a self hosted hackathon! It turns out, maybe I’m not as up to snuff on my React objects as I’d like to be. I was quite hung up with assigning properties. I eventually got the hang of it, but a bit too late for my plans for now. I’ll be back, React! Oh and integration testing an API which I was trying to hook into a Graphql markup file didn’t do well on a local machine. Will need to proxy it to my web domain after it’s ready though, it should be worthwhile.
The trouble with working around infosec, sysadmin and developer tool stacks, is that you have a wide, not necessarily deep, range of knowledge. In each of these areas too, different practices carry different jargon. In Sysadmin, this is being keen on your vertical’s documentation, in development this is known as ‘full stack’, and in infosec this is having a wide range of reconnaissance techniques.
I got my first taste of a good DevOps workflow and it’s been a long time coming. Still, DevSecOps isn’t traditionally meant to be handled by a single person and it shouldn’t. Collaboration, SME’s and job rotations is incredibly important in any IT oriented business. However, I’ve seen it’s not impossible if your curiosity for new software is a grand super buffet in size.
On today’s menu is Github, namely the secrets one might be able to find on Github, even if they’re not deemed as security secrets. This is another key piece of the pentester’s toolkit.
Let’s start by looking at what secrets would be the most horrendous thing to put out there: Secret API Keys.
The above reading covers Github’s tools for finding secret keys. It’s only for keys, not URL’s or subdomains that should remain hidden. Developers are also given the power to turn off the “nag alarm”.
Keys don’t belong on Github, they should be controlled. Specially when it comes to API’s. Your endpoints should have data encrypted, not obfuscated, at all 3 stages of its lifecycle. Developers love their tools, we’re now at the point that these programs are, very controversially writing themselves. Well I might mention Github copilot has this type of implied secret disclosure from the software it’s built to less than gracefully borrow. I want to shout out the fantastic writeup from 0xbadidea on Github. She gives a great hacker mindset into developer practices of copilot which is similar to this blog’s tone.
Is Github’s key detection tool effective? I would say yes, and it’s customizable just like any good developer tool.
So now we have no keys, but maybe we need to share information about how our product works. What is the answer to provide documentation through something bigger than a readme but smaller than a wiki? Allow me to introduce you to Readthedocs. This product was made by three dedicated developers and puts documentation at the forefront. Anyone can make them, only the writers can edit them.
So what’s in these docs? Information, please! Subdomain endpoints, API fuzzing, default credentials and… wait WHAT?! Oh well, at least google isn’t indexing these right? … right?
[this is where a meme would go]
Oh boy. Well as we established, this isn’t technically a leak of keys, but is pretty juicy and another foothold to possibly leverage. If your client uses software which ends up in your net, then it’s more than likely worth checking. For the bug bounty hunters out there, that tip’s for you. This is how I found one of my first bugs back in November.
So an attack that utilizes this tool might be a googledork which looks like this: Look up a document, find a plugin, it’s for a popular “dashboard of dashboards” tool. Look up examples of URL formats. Look for an API endpoint, look for the presence of the plugin API. Now this is hard to pull off, but read the docs is a good tool for a red team toolbelt.
Well most developers would do this right? Turns out maybe not, this is another hotbed topic butting heads for devs and security folks. Gosh, everyone sit down and have a crumpet, smile, life is short. Github’s web crawlers are very touchy, and you need permission for your project to crawl it. Google however, everybody is crawling all the time!
The answer, and the moral of today’s story is, Read the docs! There’s an ignore function right there for you. https://docs.readthedocs.io/en/stable/config-file/v2.html#search-ignore
Setting up config files is as important as setting up ignore files. Here’s each of the ignore techniques I’ve encountered which are needed to keep your non-key secrets safe.
Gitignore, keeps files from being uploaded to Github. Basically keeping version control in place.
Yarn/tailwind: File this one under “a product for a solution”. Security experts like to make fun of this fact, but for developers new tools are always exciting and useful. The prospect is that if it’s good, it can replace the old way. Progress, right? Well Yarn has a great security centric design, and tailwind is more of a curious case, wrapping CSS and HTML into the same page structure. I’d argue this is 1 point for yarn, 0 for npm and maybe a point deduction for tailwind. Either way, it will likely keep getting used until proven otherwise.
For docker, you have your docker yaml and yml files, this tells docker each package required to make a constructed container from other containers. The basic dockerfile is going to have the way it’s made, similar to ye-old linux makefiles (and uses syntax like you’re using a makefile if you want it running the best for the hardware.) Docker also has dockerignore and yaml ignore, so use those effectively.
By not indexing sensitive pages, we keep it out of the search engine as best as they can make them. This would keep bots from skimming for domains that are private elsewhere.
That’s all for now. We’re back into web projects for the Wordfest conference in a week’s time, then it’s onto the monolith that is Azure. Until next time. Stay safe!
