Who ever said “work smarter, not harder” obviously had a Shodan account.  This is a little story of how I managed to run a relatively simple audit against the company I work for in under 15 minutes.  Again, if you haven’t read my blog post on the basics of Shodan, I would highly recommend giving it a quick skim through.  For privacy/security/whatever purposes, you’ll understand if I don’t use my actual company.  Instead, I’ll use a completely random, unbiased source organization… hmm I don’t know… how about Donald Trump?

So, what are we looking for here? We’re just going to check some basic security configurations across what could be thousands of domains all within a few minutes:

• SSL/TLS
  • Weak SSL/TLS Protocols
  • Weak SSL/TLS Encryption Ciphers
• Basic Security Headers
  • X-XSS-Protection
  • X-Frame-Options
  • X-Content-Type-Options
  • Content-Security-Policy
• Web Server Information Disclosure
  • Any related exploits

Let’s set a baseline for ourselves.  We’re just going to do a quick search of org:”Trump” to see what we’re working with.

Not bad.  A small group of 34 results, 15 of which are web servers, across two different organizations.  Now that we know what we’re working with, let’s get started.  I’ll start with the SSL/TLS issues.  Shodan actually allows you to search for domains based on certain SSL/TLS attributes such as the version, cipher, chain count, etc.  A full list of search options are shown below:

First, we’ll check for the SSL/TLS versions.  The current PCI-DSS standards state that only TLS 1.1 and TLS 1.2 are accept protocols.  So, we’ll do a quick search for anything using SSLv2, SSLv3, and TLS 1.0 using the command org:”Trump” ssl.version:”sslv2,sslv3,tls1″.

Now we’ve got 5 web servers running weak SSL/TLS protocols.  Now let’s check for some weak ciphers.  As we know, DES ciphers are pretty broken, so let’s check to see if any domains are using those with the search org:”Trump” ssl.cipher.name:des.

Oop, well there’s one.  That should probably be fixed.

If we want, we can also create a fancy report to properly present our results.  Shodan can do this very easily.  Just perform your search then select the “Create Report” button near the top of the screen.

After a couple minutes, you’ll have a nice report that outlines the details of your search with graphs and charts to show all the data in a very presentable way.  Here’s an example:

You can dive even further into the possible SSL/TLS issues, depending on what you or the company you work for is interested in auditing.

Auditing response headers is relatively easy as well.  I’ll use the X-Frame-Options header as an example.  We’ll use the search org:”Trump” -“X-Frame-Options” port:”80,443,8080,8443,9443″ to see which domains do not have the X-Frame -Options header in the server response.  This search can be repeated for each header you’d like to check for.  I’ve also specifically list the ports I’d like to check so that we can filter out any non-HTTP related results.

Oh good, so  15 domains do not have the X-Frame-Options header enabled.  Better get on that (it should be set to DENY or SAMEORIGIN fyi).  I’ll do another search for you guys as well, checking for the X-XSS-Protection header using org:”Trump” -“X-XSS-Protection” port:”80,443,8080,8443,9443″.

Even better, 17 domains without the X-XSS-Protection header set (should be set to 1, just in case some one was interested).

Now that we’ve check for the necessary security headers, let’s check for some headers that leak web server information.  A super common one is the “Server” header.  Let’s see which domains will tell us what is running on their web servers using the search org:”Trump” “server” port:”80,443,8080,8443,9443″.

So 12 domains have the “Server” header in the response headers.  What about another common one, the “X-Powered-By” header?

And there’s another 3 domains.  Now we had some information on the server versions, we could actually take this information and use Shodan Exploits to identify possible CVEs related to them.  I see a Microsoft IIS 7.0 server, so lets check that out using the exploit search description:”iis 7.0″.

Looks like 3 related vulnerabilities, but of course, these could be patched.

There are a few things to remember if you’re going to rely on Shodan as an auditing tool:

• Shodan will not audit any internal applications, only externally facing ones.
• Anything hosted in the cloud (such as AWS) will have an organization related to Amazon.
• Searches will usually give better results if they’re broken into individual searches (for example, rather than searching for SSLv3 and TLS1.0 at the same time, do them individually).

Thanks for reading! I hope you enjoyed and I’ll see you all next time.