Friday, April 20, 2012

From LOW to PWNED [1] Exposed Services and Admin Interfaces


Several (tm) months back I did my talk on "From LOW to PWNED" at hashdays and BSides Atlanta.

The slides were published here and the video from hashdays is here, no video for BSides ATL.

I consistently violate presentation zen and I try to make my slides usable after the talk but I decided to do a few blog posts covering the topics I put in the talk anyway.

Post [1] Exposed Services and Admin Interfaces

Exposed Services:

An example of exposed services and making sure you check for default and common passwords. so first example is a VNC server with  no password. This gives us a HIGH severity finding

 The following is a VNC server with a password of "password"

see the problem? Same thing goes for SSH, Telnet, FTP, etc.  Don't forget about databases as well, MS SQL, MySQL, Oracle, Postgres listening out to the Internet at large.



Admin Interfaces:

Admin interfaces can be gold. the problem is 1) you have to find them on the random ass port they are running on and 2) you have to get eyes on them. this can be a hassle/problem/hard to do.

So to bring the "low" to it.  some random HTTP server gets you this in Nessus

Now, to be fair this could be totally accurate, but the point is you need to look at what is being served on this HTTP server, could be something could be nothing, no way to know unless you look.  Finding useful HTTP pages on all the random ports can be challenging.

Here is a possible methodology for doing it:


  1. Nmap your range
  2. Import your nmap results into metasploit
  3. Use the db_ searches to pull out a list of hosts & ports
  4. With the magic of scripting languages make that list into an html page(s)
  5. Use linky to open all those links
Kinda goes like this:

after you have imported your nmap results, uses the services option.

If its populated you'll get a list or results like the below

Output that stuff to a CSV

msf > services -o /tmp/demo.csv

Take that CSV and run some ruby on it


The above code will output an html file that you can open with linky
linky will open each link in a new tab allowing you a way to get eyes on each of those random HTTP(S) services.

You can now start intelligently trying default passwords or viewing exposed content.

Thoughts?

-CG

at

3 comments:

  1. Daniel MillerApril 20, 2012 at 8:30 AM

    Neato. Quite a bit of that could be automated with Nmap NSE scripts, also. Grab page titles with http-title. Classify admin interfaces, backends, etc. with http-favicon and http-enum. Brute-force basic auth with http-brute and form-based auth with http-form-brute (not as reliable). Fingerprint and try default credentials for various devices with http-default-accounts.

    ReplyDelete
  2. pipefishApril 20, 2012 at 9:14 AM

    This is good stuff! It drives home the point that even with the prevalence of automated scanners and automated pen testing tools companies need to have diligent IT security pros on the payroll. Those pros on the payroll would also benefit from having some experience in the "offensive side" of security (read: pen test, not dirty jokes), to add the hacker perspective to reviewing findings.

    ReplyDelete
  3. jcranApril 20, 2012 at 11:49 PM

    nice post. please continue this.

    Good info gathering and interactive testing tools paired with good data analysis and drill-down (and the ability to run further, related tests) is where i see testers having the best quick wins.

    One thing many scanners / tools could do is be more explicit about exactly what and how they're testing - and allow the tester to drill into that.

    I like to screenshot large sets of http servers and do a quick visual analysis to get a sense of areas to focus. Quickly lets me eliminate dupes and vhosts that don't matter. Definitely don't see scanners doing this sort of thing in the near term.

    Another thought, the limitations of scanners and tools based on the language / platform that they run on can totally prevent the visibility of exploitable bugs.

    Often the tools cannot speak enough of a protocol to properly implement a check or exploit in a non-standard language. Not to mention that they're limted by the perspective they have to the network (remote vs mitm), and whether they're designed to test w/o much interactivity (scanners) vs be used as a reversing tool (proxies, etc)

    so yeah, network testers aren't going away any time soon :)

    ReplyDelete