Thoughts about Information Security.
The Metasploit CTF this year was supposed to be easier, and I guess in some ways, it was. But it was entirely too easy to overthink some of the challenges. While I personally didn’t solve all of the challenges, I did manage a few. It was a lot of teamwork to get all of them solved. We didn’t make it to the top 5 this year, but it was a fun experience all the same.
With that all said, here’s the challenge writeups for the ones I did.
Continue readingYou’re assessing a website. You get an HTTP response that looks like this:
HTTP/2.0 200 OK
content-type: text/html; charset=utf-8
expires: Sat, 01 Jan 2000 00:00:00 GMT
x-frame-options: DENY
x-powered-by: PHP/5.1.5
pragma: no-cache
strict-transport-security: max-age=15552000; preload
cache-control: private, no-cache, no-store, must-revalidate
date: Tue, 18 Jun 2019 04:28:37 GMT
X-Firefox-Spdy: h2
What do you report? If you’ve spent any time in Information Security, you’re probably eyeing that X-Powered-By header. You’d probably report that, right? But why? Why would you report it? Because of its presence in the response?
There’s a mixed bag here. I used to be one of those people that would say “oh no, hide the version number!” But what does that solve?
Put another way, you’d probably take that version number and look up known exploits for it, right? So why hide it? It doesn’t fix the problem. It just hides the problem, obscures it. The mantra “security by obscurity” still holds here. By recommending that people hide the version number, we are encouraging security by obscurity while still beating the drum that it doesn’t work for everything else. So where did this come from?
I remember years ago PHP Group released a guide for hiding the version number, and even at one point openly stated that it was useless. This guide was released some 17 years ago. This was the earliest that I remember seeing something written about hiding and the value of hiding it. I do remember hearing the advice passed around (or rather seeing) on bulletin boards and probably even some books I had read. But nobody was talking about the value.
Let’s talk value.
| Benefits | Drawbacks |
| Reveals less about the environment, slowing down attackers | Attackers are still going to keep probing and looking |
| Harder for IT/security/SEs to identify out-of-date software through scanning, such as Qualys, Nessus, and other tools in their environment | |
| Doesn’t actually fix what is being reported – out of date software |
To me, this is a clear win. Yes, I’m a little biased, having spent some time now in the enterprise and seeing things differently. However, the main reason why I used, and many others, would recommend hiding the version number of ASP.NET, PHP, and others, is to reveal less about the environment and slow down attackers. There aren’t many other benefits that I can see, even if I try to sit here and think about them.
I think we all would rather people patch and keep updated on the stack they are using rather than hide the fact that they don’t have good patch maintenance.
What’s the version number actually telling you? “Hey, I’m here!” or “Hey, I’m here and I need patches.” We can exploit lack of patches. Simply being there not so much. If we can exploit lack of patches, we can patch it.
| git log --format=oneline | cut -d " " -f 1 > log.txt; for rev in $(cat log.txt); do mkdir $rev && git --work-tree=./$rev/ checkout $rev -- .;done; |
Why? This will get you the ability to look through git history in a set of folders. This is especially useful when you need to find credentials that were removed from the current revision, but not changed. *cough*
Let’s break it down:
git log --format=oneline | cut -d " " -f 1 > log.txt
I’m asking for the commit log in a oneline format, piping to cut and asking for the first field.
for rev in $(cat log.txt)
Each revision is stored in log.txt for reference. We use this to loop through so that we can pass it to git.
do mkdir $rev && git --work-tree=./$rev/ checkout $rev -- .
For each revision in git, we are creating a directory with the name of the revision and then setting the work tree to that revision so that we can check it out.
Though it can stand to be improved, I did it this way for a couple of reasons:
Now that we have the full checkout for each revision, we can start grepping for what we want. Usually this is credentials, but really anything we want.
As nice and fast as this is, we are missing a few things:
I’ve come to really, really, really like Trufflehog. It too has its downsides I’ve discovered. Namely, it produces a human-readable format, but friendly for the terminal (color codes and all) or it produces a machine-readable format in the form of a JSON file. You’ll then need to write code to parse it. But Trufflehog is in Python (yay!) and extensible. This takes the hard work out of ensuring you manage searching across everything.
But there’s plenty of juicy things to be had, stored in version control.
h4ckNinja's Blog 