TLS 1.3 is the new secure communication protocol that should be already with us. One of its new features is 0-RTT (Zero Round Trip Time Resumption) that could potentially allow replay attacks. This is a known issue acknowledged by the TLS 1.3 specification, as the protocol does not provide replay protections for 0-RTT data, but proposed countermeasures that would need to be implemented on other layers, not at the protocol level. Therefore, the applications deployed with TLS 1.3 support could end up exposed to replay attacks depending on the implementation of those protections.

This talk will describe the technical details regarding the TLS 1.3 0-RTT feature and its associated risks. It will include Proof of Concepts (PoC) showing real-world replay attacks against TLS 1.3 libraries and browsers. Finally, potential solutions or mitigation controls would be discussed that will help to prevent those attacks when deploying software using a library with TLS 1.3 support.

Tools referenced in this talk include:

• TLS Playback

us-18-GarciaAlguacil_MurilloMoya-Playback_A_TLS_1.3_Story__v6.pdf
August 13, 2018

2.6 MiB
MD5 hash: c56f49adfbda571c9c32f5860d6f9319
Details

Date:

August 13, 2018

The post Playback: A TLS 1.3 story appeared first on Portcullis Labs.

TLS was born as a substitute of the ancient Secure Sockets Layer (SSL) protocol, which was showing its age and being susceptible to multiple attacks. The first version of TLS, 1.0, was created in 1999 and it was based on SSLv3. Since then TLS 1.1 (2006) and TLS 1.2 (2008) were created to improve previous versions of the protocol, solving some of the security weaknesses that security researchers discovered in the last two decades.

TLS 1.3 is the new protocol version. It is not officially released yet, but it is in the final stage, just waiting for the final approval. In any case, some important vendors and open source projects are currently supporting it. The TLS 1.3 Working Group released multiple iterations (drafts) that refined and improved the protocol in the last four years. One of the outcomes of that hard work is that TLS 1.3 has been simplified compared to previous versions of the protocol and it is not vulnerable to previous known attacks that were affecting previous versions. For example, in TLS 1.2 the number of ciphers supported was high, maybe there were too many, and the Working Group has decided to limit this new version to support only five ciphers. Another example is that with TLS 1.3, forward secrecy is not optional, so, in the case that an attacker manages to steal the private keys of one server, he will not be able to decrypt previous communications as he would not be able to obtain the session keys used to encrypt previous messages.

TLS 1.3 has also introduced a new feature to improve the performance for new connections. The name of this feature is 0-RTT (Zero Round Trip Time Resumption) and it allows to have a fast session resumption that can push data to the server without needing to wait for a server confirmation. This is possible as 0-RTT reuses cryptographic information obtained in the first connection to the server. The following diagram shows how TLS 1.3 0-RTT resumption works:

0RTT handshake state diagram

This is an interesting functionality from the point of view of the performance, but it has some known security implications.

Cisco security consultants Alfonso Garcia Alguacil and Alejo Murillo Moya will deliver a presentation about some of the known security implications of using 0-RTT and will show Proof of Concepts (PoCs) of some attacks in real world environments. The intent is to raise awareness across the security community about that new feature. The presentation is named “Playback: A TLS 1.3 story” and it will be presented at Black Hat USA 18 and DEF CON 26. Attendees will learn about TLS 1.3 0-RTT, see some examples about how an attacker could take advantage of that new feature and finally get an understanding of the security implications of enabling the featu

You can find the slides and tool from this presentation here:

• Playback: A TLS 1.3 story

The post Playback: A TLS 1.3 story appeared first on Portcullis Labs.

A lot of fantastic work has gone into the discovery, analysis, and (on occasion) marketing of SSL/TLS vulnerabilities. Some, such as BEAST and LUCKY13, are issues in the protocol itself. Other bugs, however, affect individual implementations of this complicated and nuanced protocol. This talk will discuss an approach for identifying security bugs in SSL/TLS server implementations, outside the mainstream well-publicised issues that we all know so well.

Tools referenced in this talk include:

• sslxray

STHST.pptx
November 16, 2017

1.0 MiB
MD5 hash: 503a77150111d59a0352c27a62195c4c
Details

Date:

November 16, 2017

The post SSL/TLS Hipsterism appeared first on Portcullis Labs.

During the 90s very strict export regulations regarding cryptography were present in the United States of America. Due to this issue, some SSL implementations have deliberately weakened ciphers which would comply with the American export laws. All these ciphers are tagged as EXPORT ciphers or export-grade cryptography, which nowadays is considered obsolete. Solutions exist at the moment to provide higher confidentiality and integrity levels for messages, and these export regulations are no longer present.

Two attacks on SSL export ciphers will be discussed: Logjam and FREAK.

Logjam Attack

What is it?

The Logjam attack exploits the acceptance on both clients and servers of export-grade ciphers using Diffie-Hellman as their key exchange protocol.

To exploit this vulnerability, the attacker performs a downgrade attack on the victim, forcing them to use a weak key exchange protocol. A man-in-the-middle can force TLS clients to use export strength DH with any server that allows DHE_EXPORT ciphers. Then, by computing the discrete log using techniques such as precomputation attacks against known primes, the attacker can learn the session key and arbitrarily read or modify the contents of the data transmitted between both parties.

What does it expose?

The successful exploitation of Logjam would allow an attacker to completely compromise the confidentiality and integrity of any TLS session on a client or server which accepts export-grade Diffie-Hellman key exchange.

It should be noted that, although it is expected to take a week or so to precompute logs for each prime, Diffie-Hellman implementations on different TLS clients and servers often use the same small set of primes, so only a few primes need to be precomputed against in order to enable the decryption of a significant portion of global TLS traffic.

FREAK Attack

What is it?

The FREAK attack exploits the presence of export-grade cryptography with RSA key exchange. As with the Logjam attack, the target connection is deliberately weakened by forcing the use of an export-grade key exchange.

To exploit this vulnerability, an attacker downgrades a regular RSA key exchange to one that uses export-grade ephemeral RSA keys, relying on a bug in several TLS client implementations. The attacker then factors the ephemeral key to hijack future connections that use the same key. At the time the vulnerability was first published, it cost around $100 (USD) to factor the weak RSA key in 8 hours on a cluster of systems running GPUs. Once the RSA key has been factored, an attacker would be able to decrypt the RSA-protected key-exchange, recover the symmetric encryption key and decrypt all SSL traffic captured.

What does it expose?

The successful exploitation of FREAK would allow an attacker to completely compromise the confidentiality and integrity of any TLS session between a client or server which accepts export-grade RSA as key exchange protocol.

Who/What is affected?

Any service which runs over TLS and accepts EXPORT_DH or EXPORT_RSA ciphers is vulnerable to these attacks. Although these attacks target specifically these export ciphers, all export ciphers are considered to be obsolete and hence should be disabled. An example of common services which could be affected by this attack are the following:

• HTTPS
• SSH
• SMTP

What should we do?

Both attacks exploit the possibility of downgrading a connection initialization to use a legacy key exchange protocol. In order to defend against the Logjam and FREAK attacks, Portcullis recommends to have an up-to-date client and to disable all export-grade ciphers on both clients and servers. In addition to this, it is recommended to transition towards Elliptic Curve Diffie-Hellman as key exchange protocol.

Our SSL Good Practice Guide has been recommending that old protocols and ciphers be disabled for some time now, which prevents this attack. You can use the SSL cipher suite enum tool to test your configuration.

The post SSL and Export Ciphers: Logjam and FREAK appeared first on Portcullis Labs.

The summary is, essentially, that SSLv3 uses a MAC-then-encrypt construction, which doesn’t authenticate the padding as it is applied on the plaintext message before padding or encryption are applied. This gives rise to a padding oracle bug, which is how BEAST worked too.

Block ciphers require plain-texts to be of a length divisible into fixed-size blocks, e.g. 128 bits in the case of AES. As normal messages don’t adhere to this (i.e. can be arbitrary in size) we use padding to ensure that the message is expanded to fit that requirement. Padding usually adds a minimum of 1 byte, and a maximum of one entire block. Its value is usually tied to the length of the padding, for example in PKCS#7 padding we would add 01 01 for two bytes, 02 02 02 for 3 bytes, 03 03 03 03 for 4 bytes, etc. However, instead of checking that all the bytes match, the SSLv3 specification states that only the last byte is to be validated. In some cases, in fact, client libraries mistakenly set the first padding bytes improperly – Oracle’s implementation has, in the past, used zeroes for all bytes but the last.

Another requirement that block ciphers don’t provide on their own is securely encrypting more than a single block with the same key. This is important, because simply transforming each block independently with a cipher (this is known as Electronic Codebook, or ECB mode) results in equal blocks encrypting to equal cipher-texts, which is bad news because this leaks information! Instead, we use different constructions to ensure safety when encrypting multiple blocks – Cipher Block Chaining (CBC) is a very common one.

In CBC, we take each previous cipher-text block and xor it with the current plaintext block before encryption. So for block 4, you take the encrypted block 3, xor it with the block 4 plaintext, then encrypt that value. The first block (block 0) has no previous cipher-text block, so we use an Initialisation Vector (IV). The IV is important, because it allows us to securely send the same full messages with the same key without their entire resulting cipher-texts being equal, as long as we don’t ever re-use an IV with the same key. Anyway, that detail isn’t important for this bug.

To decrypt a CBC message, we decrypt a block, then xor the output with the previous block’s cipher-text, i.e:

M_n = D_k(C_n) ⊕ C_n-1, where M is the message, D_k is a block decryption with a key k, C is the ciphertext, and ⊕ denotes an xor.

It turns out that this construction is malleable, meaning that an attacker can modify the cipher-text in a way that causes meaningful things to happen to the plaintext when it gets decrypted. This has been known about for a long time, and underpins many modern SSL/TLS bugs, as well as bugs in other crypto-systems.

Essentially, if you modify a block by xor’ing it with some value, the next block’s plaintext gets xor’ed with that value at the cost of the tweaked block being completely garbled. So if we want to attack block 4, we’d xor C₃ with a value t, so that the decryption becomes:

D_k(C₄) ⊕ (C₃ ⊕ t) = M₄ ⊕ t

This is really useful if you know any of the values of M₄, because you can use xor to arbitrarily alter any value you know. This has a side-effect, though. Because C₃ is now C₃ ⊕ t, when decrypting C₃ it gets utterly garbled, destroying it entirely. This is fine in some cases, for example if your target application doesn’t check block authenticity and doesn’t read (or doesn’t care about) the data in the garbled block. Another trick in this avenue is to change the IV instead, so that:

M₀ = D_k(C₀) ⊕ IV

becomes

D_k(C₀) ⊕ (IV ⊕ t) = M₀ ⊕ t

This doesn’t have the block-garbling side effect, but you can only do it on the first block. This is particularly useful in systems where cipher-text blocks are authenticated but the IV isn’t.

Anyway, you’re probably wondering what this has to do with POODLE. Remember all that padding stuff? Turns out that you can use that to work out the values of cookies.

An attacker gets the victim to visit a page controlled by them. That page includes JavaScript that repeatedly requests a target site for which we want to steal cookies from. The request body will look something like this:

POST /url\r\nCookie: name=value\r\n ... \r\n\r\nbody

Which after padding and MAC looks like this:

POST /url\r\nCookie: name=value\r\n ... \r\n\r\nbody{20-byte MAC}{pad}

The attacker controls the URL and the request body. This allows them to force the cookie into a particular position in the request. Specifically, the attacker sends requests with different length URLs and body data until the observed encrypted message grows by one block, with an earlier block having its last byte as one unknown byte of cookie. This sounds hard, but it’s as simple as knowing that the Cookie header is in a certain position and tweaking the URL to block-align it, then sending a maximum of 16 requests with incrementing POST body sizes until the output grows by one block.

The attacker knows that the final byte in the padding block will have a decimal value of 15 (i.e. 0x0F) because of the known padding size. He can then utilise the CBC malleability issue discussed above to replace the padding block with the target block (containing 1 byte of cookie at the end). Most of the time this will be rejected as invalid padding, but 1 in 256 times (on average) this will be accepted because the decrypted last byte will happen to be 15. This probability is due to the different key / IV used each time, so the cipher-text will be different (randomly) each time, so when the last block is decrypted it xors with the previous cipher-text block and has a chance of randomly producing 15 as the last byte.

That’s a bit of a challenge to follow, so let’s look at it specifically in terms of the decryption:

Mn = D_k(C_n) ⊕ C_n-1

where C_n, the final block, containing padding, is replaced with C_i:

M_n = D_k(C_i) ⊕ C_n-1

Because C_i wasn’t intended to be xor’ed with C_n-1 the output is garbage. However, because C_n-1 is random, in roughly 1/256 cases the last byte of output will be 15, leading the padding to be falsely accepted as valid. When this occurs, the attacker can deduce that:

D_k(C_i)[15] ⊕ C_n-1[15] = 15

Which, by doing a bit of bitwise algebra, gets us some plaintext:

M_i[15] = 15 ⊕ C_n-1[15] ⊕ C_i-1[15]

The above arises because C_i was xor’ed with C_i-1 when the CBC encryption occurred.

The C_n-1 and C_i-1 values are known to the attacker, so they just decrypted a single byte of the message, without knowing the key!

The attack requirements are:

• Attacker can get the client to send HTTPS requests (easy via JS)
• Attacker is in a position to modify client traffic (“Man-In-The-Middle”)
• Connection uses a block cipher suite from SSLv3

Now that last one is interesting. SSLv3 is still very widely supported by servers, but TLS is usually there too and clients should prefer it. However, due to all sorts of issues with client/server compatibility, it turns out that if a connection fails to properly negotiate TLS then in many clients it’ll downgrade to SSLv3. All an attacker needs to do, is sit in the middle and interfere with the handshake such that the client assumes there’s an incompatibility and renegotiates down to SSLv3.

There are two fixes. The first is to just turn off SSLv3, or at least disable CBC cipher suites in SSLv3 (but that leads to other problems so isn’t recommended). There is also a client-side fix for the downgrade, which is to enable the TLS_FALLBACK_SCSV flag in the client hello – this is recommended within the original Google article. However, organisations should not rely upon all clients having this patch, or that some clients will not downgrade to SSLv3 for other reasons.

Our SSL Good Practice Guide has been recommending that SSLv3 be disabled for some time now, which prevents this attack. We’ve also updated the SSL cipher suite enum tool to include a check for POODLE, so you can test your configuration.

The post POODLE: Padding Oracle On Downgraded Legacy Encryption appeared first on Portcullis Labs.

In case you’ve been out of the loop, here’s a brief summary of the vulnerability:

What is it?

Heartbleed (AKA CVE-2014-0160) is an implementation flaw in TLS heartbeats for OpenSSL versions 1.0.1 through to 1.0.1f. It exposes an unpredictably addressed 64KB chunk of server process memory for each malformed heartbeat received. By performing multiple heartbeats, you can recover almost all of the server process’ memory. Basically, the heartbeat acts as an echo request, with the payload size and payload contents determined by the requester. Typically these are filled with a few bytes of data. However by putting in a payload of say, 1KB with a payload size of up to 64KB, the server will return 63KB of its own memory due to a lack of bounds checking.

What does it expose?

Heartbleed can expose anything stored in the server process’ memory, which may contain but is not limited to:

• Session tokens
• Form submissions
• Email addresses
• Usernames
• Passwords
• Private keys

Once the server’s private key is exposed, then all future traffic encrypted by this key can be intercepted and manipulated by anyone holding the key.

Who/What is affected?

Any application using OpenSSL/libssl version 1.0.1 through to version 1.0.1.f. This means both server and client are susceptible to this attack. The scope of this extends beyond just HTTPS- any service using TLS can be affected. This bug has existed in OpenSSL’s code for two years, and at this time there is evidence to suggest that this weakness has been exploited as far back as November 2013.

What should we do?

The remediation for this vulnerability is fairly straightforward, as shown below:

• Update OpenSSL to version 1.0.1g, or recompile with

  -DOPENSSL_NO_HEARTBEATS

• Revoke the certificates for any services which have ever been vulnerable. This is important, otherwise the potentially compromised certificates and keys will continue to work
• Get new certificates

If you have reason to suspect that your service may have been attacked then it would be prudent to suggest that all users change their passwords, as they may have been compromised.

The post Heartbleed appeared first on Portcullis Labs.

It also offers advice on how to protect and correctly configure, with the goal of helping ensure that SSL services have a minimised attack surface.

SSLGPG-1.4.pdf
September 23, 2015
Version: 1.4

578.6 KiB
MD5 hash: f1d0976053e839a85dd19259ba26b0c0
Details

Date:

September 23, 2015

SSLGPG-1.2.pdf
April 10, 2014
Version: 1.2

584.5 KiB
MD5 hash: 1c660fa51cb46805ee76a515aa330005
Details

Date:

April 10, 2014

SSLGPG-1.1.pdf
April 1, 2014
Version: 1.1

578.0 KiB
MD5 hash: 47029e16f8d2ccf5f041d368722c40b7
Details

Date:

April 1, 2014

SSLGPG.pdf
September 20, 2013

576.1 KiB
MD5 hash: eb0599b73eb8f3ef5110d30e14acb32e
Details

Date:

September 20, 2013

The post SSL Good Practice Guide appeared first on Portcullis Labs.

The Team will continue to update the guide going forwards, and will highlight major changes on the blog. Whilst you’re checking out our updated recommendations, why not take a few extra minutes and look at our SSL Certificate Good Practise Guide?

The post New SSL recommendations 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.