Using Nmap to extract Windows host and domain information via RDP

I’ve recently spent some time in various code bases working on Windows RDP related discovery. This post is going to talk about using a new Nmap script, rdp-ntlm-info.nse, against RDP services to discover the target’s hostname, domain name, DNS name, and version.

3389/tcp open     ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info: 
|   Target_Name: W2016
|   NetBIOS_Domain_Name: W2016
|   NetBIOS_Computer_Name: W16GA-SRV01
|   DNS_Domain_Name: W2016.lab
|   DNS_Computer_Name: W16GA-SRV01.W2016.lab
|   DNS_Tree_Name: W2016.lab
|   Product_Version: 10.0.14393
|_  System_Time: 2019-06-13T10:38:35+00:00

This post was updated 2019.06.14 to reflect that the script had been committed to the official repo, update the usage instructions to reflect this, and include the NSEDoc link for the script.

This post was updated 2019.06.18 to indicate that users of 7.70 need updated nselib/datetime.lua as well.

Searching LDAP using Nmap’s ldap-search.nse script

Nmap has an NSE script, ldap-search.nse, that enables performing queries against LDAP ( Lightweight Directory Access Protocol) services. The goal of this post is to provide an introduction to using the script as well as a couple of practical examples.

Bypassing Active Directory restrictions against creating users over insecure LDAP connections

In 2011 I spent a little time working on improvements [1] in Nmap’s LDAP code. At some point during the work I stumbled across a way to work around Active Directory’s requirement for a secure connection when creating users via LDAP. This may be useful when abusing testing an Active Directory environment where your only access is over LDAP without TLS support. I’d meant to write this up at the time but didn’t. I recently had to recreate the process so I thought I’d create a blog post as a form of documentation.

Hardening Microsoft Remote Desktop Services (RDS)

As systems administrators we are often tasked with implementing countermeasures to mitigate risks that we can’t completely address. The intent of this post is to cover methods of reducing the risk presented by having Remote Desktop Services (formerly Terminal Services) available on the network.

The risks that I will cover are:

• Man in the Middle attacks
• Sniffing / Traffic capture
• Brute Force Attacks
• Information Disclosure

This post was updated 2019.05.28 to fix broken links, add commentary for Windows 2016 and Windows 2019, and add instructions for enabling CredSSP for WinXP as a client since the Microsoft link is dead.

Challenges for 2015

I think that for the rest of this year and early next year we are going to see quite a few challenges that will cause shifts in our platforms and user computing base.  Some of these, such as the end of support for Windows XP and Server 2003, we have seen coming for quite a while and knew we had a deadline.  Others were more  along the lines of ‘yeah, thats bad and we will fix it some day’.  Over the last two years these slow burning ‘some day’ issues have been fully ignited due to the Snowden releases and several SSL/TLS vulnerabilities turning the theoretical risk into practical and operational problems.

I don’t plan on going into too much detail here but what I want to do is to provide a list of  some challenges that I think many of us will be facing over the next 12 months or so.

Challenges for 2015: End of support for Windows XP

If you provide support for an organization or an external customer user base then you are likely still having to support machines running Windows XP. Microsoft mainstream support for Windows XP ended on April 14, 2009 and extended support ended on April 8, 2014 [1].  This presented an immediate impact in that you could no longer contact Microsoft for support, paid or otherwise. The long term impacts will compound over time as security and operational needs require that we implement technologies that Windows XP does not support.

Unfortunately, so long as the OS is still working today it can be difficult to convince management and customers to upgrade.  The intent of this post is to help make a business case for upgrading to a newer operating system by highlighting some of the challenges that XP users and those that support them will experience in 2015 and early 2016.

Cisco UCSM Information Disclosure / Privilege Elevation

When I find or read about software vulnerabilities I often chalk the root cause of the flaw up to human error or ignorance.  Occasionally I see something that makes me scratch my head and really wish I knew what stream of logic and events caused something to occur.  The topic of this post is one of those.

The TLDR version of the story can be found on the Full Disclosure list.

Using Nmap to find x509 (SSL/TLS) certificates that have SHA-1 and MD5 based signatures

 

 

 

A couple of months ago there was quite a bit of press about Google and Mozilla becoming more aggressive about how they handle x509 (SSL/TLS) certificates that have SHA-1 based signatures. The background for this is linked in the references section at the end of this post. In short, the SHA-1 cryptographic hash algorithm is considered too weak to be safely used as part of the public web PKI.

The impact for site operators and network security teams is that over the next two years browser users will begin to see warnings that indicate that a site is secure but with errors when it uses a SHA-1 certificate that expires after January 1, 2016.  Sites will be flagged as insecure if the SHA-1 certificate expires after January 1, 2017. This is something that requires action now as certificates are generally bought or generated with at least a one year life but in many cases organizations are using 2, 3, or 5 year certificates.

Support for session and job ID ranges in Metasploit console

When I am working on Metasploit related projects I often end up with a ton of shells during testing.  Some of these and some just need to be killed off.  To help with this at the end of October I submitted a pull request [1] to the Metasploit GitHub repo that added the ability to kill multiple sessions at a time in one command.  The basic syntax looks like this:

sessions -k  

sessions -k 1,3,5-8

Geolocating Internet connected HP printers

I’ve started this blog to help me focus my thoughts and finish projects by way of introducing public scrutiny and some self imposed deadlines.  To kick things off I am posting the results of some playing around that I did this weekend with an information disclosure issue in wireless HP printers.  To be clear, I am not presenting this as a security issue of significance, but instead just a bit of mental exercise and skill refresh.

A couple of weeks ago while reworking my home lab I had to reconfigure my HP Officejet printer.  In the process, I inadvertently printed out a network configuration page.  When I went to get it off the printer I found that the last page contained a list of wireless networks in the area, including the BSSID, channel, and signal strength values.  This caught my interest as couple of years ago I was inspired by Samy Kamkar’s ‘How I Met Your Girlfriend’  talk at DefCon 18 and I wrote some scripts and a private Metasploit module that would take this same information and query the Google and Skyhook Wireless databases for the physical location of an endpoint. This weekend I decided I would look at the web interface of the printer and see if I could extract the wireless network information from it.  What I found was that while the information wasn’t obviously displayed to the end user, the printer did send quite a bit of configuration data to the user’s browser in the form of XML files.  About 30 minutes later I was able to use the information in one of the XML files to build a URL that provided the desired information – ‘/IoMgmt/Adapters/Wifi0/WifiNetworks’ .

With this information in hand, I have written a python script that will query a target printer,  gather the wireless network list if it exists, query the Google Geolocation database, and display the findings and a Google maps link.  The python script, ‘hp.geolocate.py‘, can be found on Github (another new thing for me) at https://github.com/TomSellers/Python.Misc/

Here is an example of the output:

In order to use the script you will need to sign up for a free API key from Google.  The process takes about 10 minutes and allows 100 lookups per 24 hours.  After the key is acquired, it must be added to the script on line 14 in the variable ‘googleAPIKey’.

The script works on HP Deskjet, Officejet [Pro|Premium], and Photosmart printers.  Success depends upon the target device being accessible over IP and wireless enabled.  There appears to be no shortage of these.  They can be found by searching Shodan for ‘ASIC id’.  

In order to provide any value against a preselected target organization, an attacker would have to find a device in his target’s IP range.  The device could then be leveraged to determine what wireless and IP networks it was connected to without this script, but the script would provide additional information about the physical location and other wireless networks in range.  This additional information may assist with preparations for later on-site efforts.

The printer’s web interface and XML files expose various other information but nothing that would surprise anyone in InfoSec.   In addition to printer specs and details you can gather intel on the remote IP networks, fax numbers, etc. On a positive note, none of the XML or HTML documents that I was able to find contained passwords or wireless keys.  Typical best practices of not attaching the devices to the Internet (!), configuring HTTPS, and implementing admin passwords will prevent most of the potential risk.

– Tom

Reference:

1. Script download:   https://github.com/TomSellers/Python.Misc/blob/master/hp.geolocate.py

2.  Google Geolocate API:     https://developers.google.com/maps/documentation/business/geolocation/