While on a test recently, I noted that several hosts had TCP port 3389 (RDP) open. I had a little extra time to play with and after reading Robin Wood’s @diginija recent blog post Show RDP login page. Great I thought, time to put this to practice! Maybe I could snag some low hanging fruit such as what @diginija got a glimpse of i.e. logged in user accounts/usernames. Now the difference in my scenario was I was using a Linux host for testing and @digininja used a Windows host, this meant I’d be using either ‘rdesktop’ or ‘Remmina/FreeRDP’ instead of the native windows application. So a few questions arose from this, “Would I be able to replicate what @diginija achieved?” and “would there be any issues in trying to achieve the same objective, though using a different host??” Only one way to find out!
First though, here’s a short round up/background info on both the RDP protocol and NLA service.
RDP
The Remote Desktop protocol, or RDP as its commonly known, is a proprietary service developed by Microsoft which provides a user with a graphical user interface (GUI) while connecting to another computer over a network connection. This requires a user to employ RDP client software, while the remote host must have an RDP server enabled. Put quite simply, the RDP services allows a user to initiate a remote session on the standard TCP port 3389 should a remote host have the service enabled (a switched on sys/network admin may change the standard port to hide of obfuscate the service from users in attempt to hide the service).
More in-depth info on the service and its history can be found here via these external links:
NLA
Network Level Authentication, or NLA as its commonly known, is a service/technology that is used in conjunction with Remote Desktop services and was rolled out with version 6.0 of RDP with initial support in MS Windows Vista. When RDP connections are made where NLA is not enabled or supported the attacker will automatically be connected to the remote host should the RDP server be enabled. When NLA is enabled with RDP, prior to establishing a RDP session a user will be prompted to enter valid network connection/login credentials, which will be authenticated prior to any RDP graphical session being established. Simply put, if the user trying to connect doesn’t valid login creds, then even though the RDP service is running, no RDP session will be created. This has the added advantage of preventing an unintended attacker from enumerating low hanging fruit such as user names, Domain names and potentially logged in users.
More in-depth info on the Service and its history can be found here via these external links:
Ok, so now we have a nice overview/understanding of RDP and NLA it’s time to get to work on the issues at hand - How to detect NLA and what if its enabled?
The network enumeration I had carried out on the standard ports and services highlighted that the RDP service was running on several hosts. This is always a personal favourite of mine to see if I can leverage this service for some ‘low hanging fruit’ or better still exploit a weak or misconfigured service. As I had a bit more time on this occassion, I decided to explore a different avenue and set about testing out a PoC I read about over on digi.ninja. Though I was going to attempt to do a PoC using a linux host/tools.
Using everyones favourite port scanning/enumertaion tool, NMAP, my scans against the target hosts identified that TCP port 3389 (standard RDP port) was open (see below):
---[SNIP-Nmap-Scan]---
3389/tcp open ssl/ms-wbt-server? syn-ack ttl 121
| ssl-cert: Subject: commonName=****-****-****.****.net
| Not valid before: 2016-09-22T09:47:25
|_Not valid after: 2017-03-24T09:47:25
|_ssl-date: 2016-12-05T11:42:47+00:00; 0s from scanner time.
Using the Nmap NSE script ‘nmap -p 3389 –script rdp-enum-encryption’ I was able to confirm some further info (see below):
---[SNIP-Nmap-RDP-NSE-Script]---
Nmap scan report for ****-****-****.****.net (10.xx.xx.xx)
Host is up (0.0013s latency).
PORT STATE SERVICE
3389/tcp open ms-wbt-server
| rdp-enum-encryption:
| Security layer
|_ CredSSP: SUCCESS
Nmap scan report for ****-****-****.****.net (10.xx.xx.xx)
Host is up (0.0014s latency).
PORT STATE SERVICE
3389/tcp open ms-wbt-server
| rdp-enum-encryption:
| Security layer
|_ CredSSP: SUCCESS
NB: as seen above no encryption ciphers were displayed and CredSSP has been noted aswell. The NSE script output normally returns the following:
---[SNIP-from-NSE-file-showing-example-output]
-- nmap -p 3389 --script rdp-enum-encryption <ip>
--
-- @output
-- PORT STATE SERVICE
-- 3389/tcp open ms-wbt-server
-- | rdp-enum-encryption:
-- | Security layer
-- | CredSSP: SUCCESS
-- | Native RDP: SUCCESS
-- | SSL: SUCCESS
-- | RDP Encryption level: High
-- | 128-bit RC4: SUCCESS
-- |_ FIPS 140-1: SUCCESS
--
This may indicate that we have encountered out first hurdle to overcome in achieving our goal of replicating @digininja’s work while using a linux client!?
Ok, time to attempt an RDP connection to see what we can view:
---[SNIP]---
# rdesktop 10.xx.xx.xx
Autoselected keyboard map en-gb
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Failed to connect, CredSSP required by server.
Ok, so that attempt failed as CREDSSP is required by the target server. From carrying out some research into this, it seems rdesktop does support CREDSSP + kerberos which is a subset of NLA support. If NLA is enabled on the server, the client must provide a valid Kerberos ticket to initiate the connection, if you don’t have one, rdesktop will fail with the following error:
CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Failed to connect, CredSSP required by server.
For continuity, I next tried the linux tool Remmina (a linux equivalent of of the windows RDP tool) with a view to following the steps outlined in digininja’s blog, through setting up and then tweaking the Remmina config to suit or circumstances.
Taking a shot in the dark and not being able to find any reference to amending the config file of a Remmina connection, I took a stab in the dark and entered the same string in to the Remmina config file that digininja used in the windows config change:
enablecredsspsupport:i:0
Now I’m almost 100% certain that this isn’t the correct format for the Remmina configs but again, I couldn’t find any other info to guide me on this!! If anyone knows the correct string/format to enter into a Remmina config file drop me a mail via the blog.
As I suspected, the connection didn’t work via this particular method! Its looking more and more likely that NLA is enabled on the target hosts. I tried one last thing and replicated exactly what digininja did and set up a connection using a windows host, altered the config and then initiated the RDP session …. as you’ve all probably guessed by now, the connection failed! Any further attempts at this stage of the engagement against the RDP service/server would prove useless!
Whilst my attempts in proving a PoC using a linux host/tools in this instance was unsuccessful it was good to have time to go over some basics in identifying services and validating additional services in play which prevent an unintentional user from doing things and making connections to services they shouldn’t be!!
In summary, my target hosts did employ NLA, as each time I attempted to initiate any type of remote connection protocol/service I would receive the following pop-up:
This, combined with the other information and output we have recovered, all point to the fact that NLA is in use on this occassion and will stop any type of connection and enumeration of the service without valid user credentials. This ultimately places another security barrier which has to be overcome in the way of any would be snooper!
Should you ever come across a host with RDP server enabled and TCP port 3389 open, don’t pay it lip service and assume it will be locked down! Always investigate and attempt a connection, you don’t need to go to the extent that I have, but by checking it out, you never know how lucky you may get! If the host isn’t employing NLA you may well be able to enumerate information which could prove useful in gaining a foothold on a network at a later stage!
I’d like to say thanks to a few folks who gave me some nudging long the way to write this up tamonten, digininja & zyx2k. All very knowledgable peers and someday I might get to their levels!
Thanks for reading!
