Discovering vulnerable hosts through SHODAN's API

So one of the many ways of discovering and enumerating hosts on the Internet is through the well-known SHODAN search engine. Shodan's differential is that it lets you search through some service banners for specific keywords. One can add granularity to searches through various filters, allowing you to specify countries, cities, hostname, subnet, operating system, ports, etc.

Some of this search filters haven't become public so you'll need an API key to use such features which is given to you after payment. In fact, there's a nice anniversary promotion right now for $19. A full account will give full access to the API including SSL search filters (cipher type, key length, CA, ...), searching metasploit modules, exploit-db, exporting results and some more stuff.

Whatever the reason is you have to search for vulnerable hosts in the Internet, this is the appropiate kind of service for you. I've written a python script to implement Shodan's API. This allows fetching results from command line, which will always be handy for great a great deal of data (please yourself with: http://blog.commandlinekungfu.com/). If it's worth it, there's a copy of it at:

https://github.com/salcho/shodan_code

You'll need the python shodan library which can be installed through easy_install, you'll also need to paste your API key in the SHODAN_KEY variable.

Of course Shodan is widely used to find default admin passwords on network devices, applications and services in many devices like IP cameras, routers, smartphones, tables and whatnot. Similarly, many vulnerabilities can be fingerprinted through this kind of search. Just like the metasploit guys say: Good exploits never die. And one of such exploits is the Glassfish authentication bypass through Verb Tampering vulnerability.

Found in 2011 by Core Security, many many hosts are still vulnerable today. One can find such hosts by using the shodan_code script, for example narrowing the search to specific countries or cities:

Output is written as JSON objects to a log file which can then be parsed in a variety of ways, say: command-line, scripting, sqlite, etc etc etc. I'm currently using some awk, sort, uniq combinations but a parser script should arrive soon enough. Objects logged include hostnames, raw banners, IP adresses, ports, geolocation, OS, ISP, registered organization, among others.

Once parsed that info, point missiles:

And that's it... Just another day at the office.

Trojanizing Windows servers/workstations with metasploit's enable_support_account

Have you ever lost access to some admin, developer or user's server/workstation because your credentials stop being valid in the worst moment? Effective persistence on exploited machines has long become a major concern, especially in restricted environments where you can't actually add users to privileged groups, upload and execute tools, dump hashes and/or passwords, access network shares, etc.

Pentesting is coming to a paradigm shift as to what targets and data are most valuable/critical to clients. It's not like getting domain admin stopped being important, is just that it will be so depending on the business perspective of it. Such philosophy has been stated with far more arguments and details in conferences and websites in the recent years as in dark0perator's Tactical Post Exploitation, which I'd recommend you to look at if you haven't already.

Given that train of thought a technique for easily setting alternative access to a compromised machine without using other tools besides the ones provided for the OS would come to be handy. As far as I know this particular (simple) technique hasn't been widely documented but it has proven great effectiveness in a number of pentests.

The objective is to use only OS resources (actually built-in accounts and the registry) in order to guarantee additional access to critical targets in some network. Microsoft introduced many changes since Windows XP, some of which are the addition of built-in accounts like HelpAssistant, KRBTGT and support_388945a0. Each of these accounts has been designed for a specific purpose (say, service accounts) usually related to remote support and assistance which is why network administrators and users usually don't pay much attention to them. Default settings for such accounts include being disabled and having limited privileges.

As such, built-in accounts usually go unnoticed and so they are an interesting feature to play with if one's task is to maintain access. Of course these facts aren't to robust as they rely way too much on network environment and administrators skills, but real-world scenarios haven't often shown these to be an issue. Just by monitoring the registry we were able to spot the exact locations where settings are applied when a local user is modified with net.exe, lusrmgr.msc and so on.

Unlike domain controller's Windows servers and workstations will keep user data in very specific locations at the registry. The keys involved for these operations (changing passwords, enable/disable, etc.) are mostly in the HKLM\SAM\SAM\Domains\Account\Users key which requires SYSTEM access for write AND read access.

As it can be seen in the image, the Names sub-key holds all user account names. Each of these account names will map to exactly one User's sub-key according to a user's RID, which is specified in hex format in the Names sub-keys void values. Once a user account is mapped to it's corresponding Users sub-key you'll find the F and V REG_BINARY values with some nice data.

Some important data is located at offsets 30h and 38h which correspond to the user's RID and a enabled/disabled flag. Built-in accounts have well-known RIDs (see: http://technet.microsoft.com/en-us/library/cc779144%28WS.10%29.aspx) like the old good 500 for Administrator.

So, what if someone was to change some of these values? Well, it happens to be that when you overwrite some user's unique RID to the one of another user (i.e. RID 500) Windows will become confused as to which user that is, and since all important OS processes read these values to do their stuff, our beloved user will share a lot of settings and info with the user who actually holds the original RID.

As an example we'll swap the support_388945a0's RID for that of the administrator, enable it and set a password through registry as well as command line. We can then login as the support account to see what happens:

As weird as it seems, once the support account is logged in it'll share the administrator's desktop, files and even shell privileges. Moreover, every operation done with this user will be seen as if it was made by the administrator in the event log. This behavior brings some advantages with it:

• The user will be able (in many cases, depending on configuration) to log in remotely using Terminal Services, every operation will be logged as if it came from the admin account
• You won't be viable to delete the support account, as you'd be deleting the administrator's account to the eyes of the OS xD
• Even if it's true that quite every modification to the administrator or support account will affect both of them, some VERY important stuff won't, for example: their respective password. Such thing enables you to have access to the administrator stuff but using your own password!

Not being enough with that, whenever an administrator (or any other user, for that purpose) checks which users are part of the administrators group (by running 'net localgroup' or alike) they won't see the support account listed. That information will only be shown to the support user itself.

The limitations of this technique include what built-in accounts are actually in each OS versions (some built-in accounts will actually be used in the presence of Remote Assistance sessions, for example) and the fact that the target account actually appears as enabled with password set for those who look in detail.

I wrote a metasploit post module for automating this called enable_support_account under post/windows/manage. It will actually overwrite the support_388945a0's RID for the one belonging to the administrator, enable the account and assign a password of your choice. The module has been tested and verified in WinXP and Windows server 2003 by now but it won't take much to extend it for use with other built-in accounts present in other OS versions, stay tuned. Even though, the module has the ability to change any user's RID to one you specify as there's a lot of stuff you can use with this Windows feature.

The module's quite easy to use (as always in msf), here's a screenshot:

It's available now in the latest msf version. Just run msfupdate and that's that. Many thanks to claxus for ideas and thoughts. All feedback, opinions, suggestions, thoughts are welcome at salchoman[at]gmail.com. Hope you enjoy! :]