Inventory? What a pain in the assets!

In a recent bug bounty I was getting bored hammering on the main site of the client so I decided to re-read the rules of engagement.  It contained all the standard stuff, then something caught my eye.  This bounty excluded specific pages of the site (one was a payment processor and the other was a message board).  This particular bounty allowed for discovery of *.domain.com outside of the exclusions noted above.

Unfortunately due to disclosure terms and timelines this post is NOT a story about what I happened to discover.  This is a post about the importance of inventory management.

Vulnerability management has lots of tooling available.  So much tooling, in fact, that determining which tool to use is often a challenge in and of itself.  The reality, however,  is that once you select a tool and get it configured that is no longer the hardest part of the job.  The issue then becomes two-fold.

First you need to make sure that you are scanning everything in your environment.  Sounds easy right?  Just pop the IP space in your scanner and let it rip.  Sure, this will get you started with your local footprint but it also brings me to the second point which I’ll get to in a second.  Anything that is hosted in the cloud, anything that is hosted by another supplier, even any web redirect to another partner using your URL namespace all present a potential attack surface.  This is why a CMDB (or an asset database if your not all into the ITIL) really is important to vulnerability management.  You have to know what is supposed to be there in order for you to identify what doesn’t belong.

This brings be to that second point I promised earlier.  CONTACTS!  Even if you know all the stuff that is supposed to be out there, you still need to know who to talk to to get things fixed.  This ranges from PBXs in the telcom closet all the way to the edge of the public facing web site.  You need to know who to talk to when all of your nifty tools actually find a problem.

It turns out that someone standing a system up “under their desk” and forgetting about it is one of the key pivot points for a modern attacker.  This also happens in the cloud so don’t think you’re safe there.  Someone testing out that new, awesome, vulnerability riddled,  beta42.example.com service and forgetting to shut it down before they went home for the weekend.

Well, that brings me to the end of this ramble.  Remember to keep track of your stuff and who it belongs to.  That makes the business of vulnerability management substantially easier.  Oh, and as for the bug bounty…I’ll bet if you were paying attention through this whole article you probably pieced together…the rest of the story.

As always….feedback is welcome in the comments.  You can follow me on Twitter @JaredGroves

Happy hunting!

 

Beware the False Negative -SSLv2 Detection Issues

In vulnerability management there are few things worse than the false negative.  Analysts happily going about their day, thinking things are fine while skr1pt kiddies are doing somersaults  through old vulnerabilities.  In my case we were looking for systems that still supported SSLv2.

I was most recently caught by the false negative situation when asked to do a verification of some settings changes aimed at tightening up the crypto on some of our web servers.  It being a busy day I turned to the trusty nmap scanning tool to perform the verification that SSLv2 was, in fact, disabled on these web servers.

nmap --script ssl-enum-ciphers -p 443 [hostname]

nmap -sV -sC -p 443 [hostname]

I look through the results of both checks, no sslv2.  No complaints, no problem, right?  WRONG!

More secure is always better, right?  Well, not if you are responsible for vulnerability management.  In this case the default crypto libraries on Windows no longer support SSLv2 and therefore don’t detect it as an available option when offered by the server.  This results in certain tools returning the dreaded false negative.

Knowing there’s a problem is a big step towards the solution.  There are still specialized tools available that use various methods to detect supported ciphers and protocols that can help.

If you have a web facing system and want to do a quick check there is always Qualys SSL Labs.  I’d recommend selecting the ‘do not show the results on the boards’ tick box, at least time you run your site.

My favorite offline tool for this task is testssl.sh.  Unfortunately it is only Linux or Cygwin so you are out of luck native on Windows.  I haven’t tested this on the new bash shell for Windows.  Anyone tried it?  Send feedback with your results.

If you are testing from a Windows box ssl scan is always an option.

Hope this helps. Happy hunting!

You can find my post on securing TLS on your system here:  HTTPS check. Secure? Maybe.

Have feedback?  Feel free to leave it in the comments or find me on Twitter @JaredGroves