The post Playback: A TLS 1.3 story appeared first on Portcullis Labs.
]]>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:
The post Playback: A TLS 1.3 story appeared first on Portcullis Labs.
]]>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:
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:
The post Playback: A TLS 1.3 story appeared first on Portcullis Labs.
]]>The post SSL/TLS Hipsterism 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:
The post SSL/TLS Hipsterism appeared first on Portcullis Labs.
]]>The post Downgrading RDP connections and how to avoid it 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.
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:
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.
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.
Note that the warning message about not being able to authenticate the server tallies with the MiTM attack described above.
Unless you’ve configured your host to trust the SSL certificate of the RDP server, you’ll see a certificate warning like this one:
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.
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:
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:
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:
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.
Configuring the Terminal Server to use SSL for it security layer instead of “Negotiate” prevents such a downgrade attack.
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.
]]>The post Locating SAT based C&Cs appeared first on Portcullis Labs.
]]>Satellite DVB-S/2 connections are, sometimes, unencrypted so with cheap hardware and some free software the downlink can be sniffed. By using the satellite as the downlink of an Internet connection, an attacker can use another connection which let to spoof IP address as a uplink and then have a hijacked IP from the satellite provider to use as a normal one and almost completely anonymous.
One good thing about this technique is to have an anonymous broadband connection directly to the attackers base/home/server/laptop without proxies/bouncers – if you have ever used TOR, you’ll probably realise know how useful these characteristics can be.
In summary, the attackers were using satellite link to anonymise their activities and prevent them being tracked. In this blog post I’ll show some ideas to track malicious agents trying to hide behind satellite links.
What to do when these connections are being used for “bad things”? I have also tried to research about different ways to locate these rogue connections. Here are a few ideas on how to solve this challenge:
If an attacker is using a connection vulnerable to sniffing and “Man-In-The-Middle” attacks, the communication stay vulnerable, so we can attack these:
Hijack communications with the systems the attacker is connecting with.
If the attacker navigate through HTTP, in some circumstances we can inject HTML or JavaScript code to get information of the target system.
Sometimes we can inject fake executable, ActiveX or Applets and try to cheat the attacker.
If the attacker system is configured as I proposed in my talk, that system can be reached with an satellite IP address, we can try to attack it.
Definitely these attacks can provide us information about the attacker but, most probably, not an address or a name.
Let’s redraw again the network diagram:
Here I draw R1 and R2, which are the routers of the ISP the attacker is using as the uplink channel of the hijacked satellite-based connection.
It’s not possible to get an IP address of the attacker because it is configured with the hijacked IP address, but, is it possible to get the IP address of R1 or R2? Getting that information can be really useful in the hunting of an attacker, remember that the target must use a local internet connection as uplink.
How can we get router IP addresses?
We can wait till the attacker do a traceroute, that can be a lot of time. We can´t control the TTL of an IP packet leaving the target host so let´s think in other way.
Another option is to ping the target and activate the record route option on IP, you can do that using hping:
# hping3 -1 IPsat -G
The record route option provides a means to record the route of an Internet packet. When an Internet module routes a packet it checks to see if the record route option is present. If it is, it inserts its own Internet address as known in the environment into which this packet is being forwarded into the recorded route.
We have it? No, this option must be activated in all routing devices, from you to the target and back, and usually this option is disabled – in a lot of years doing pentesting, I have only seen it work in a small fraction of cases.
Another option I found with possibilities is to create IP traffic rejected by the uplink ISP routers (R1 or R2), and sniff the ICMP Destination Unreachable packets to get the IP of R1 or R2.
For example, pinging the satellite IP of the target from an internal address, the remote system will respond to the private IP echo with a ICMP echo response. If the traffic to that internal subnet is rejected by the uplink ISP routers, and usually it is, the routers will send an ICMP error to the satellite IP from the router own IP, so we can sniff that ICMP packet and get the IP address:
# hping3 -1 IPsat -a 10.30.16.41
Some problems we find to use this technique:
What private IP addresses are rejected? We have to send several packets to the IP of the target, 69781, one packet per private C range or 17891228 which is the number of all private IP addressed.
What if the private IP addressed are filtered and not rejected? Bad luck.
The target host filter packets which come from private IP addresses via satellite interface? Bad luck.
What if the target host have filtered the ICMP ping? Please…
The idea of the target sending traffic to internal IP addresses can be exploited from several angles, for example, injecting malicious JavaScript on the targets browsers if he use it. Imagination! Imagination! Imagination!
So, if the attacker who is hijacking the satellite Internet connection is clever enough, this kind of connections are still anonymous. But, as I thought some attacks to break the anonymity, sure you people can follow this way.
The post Locating SAT based C&Cs appeared first on Portcullis Labs.
]]>The post SSL “Man-In-The-Middle” attacks on RDP appeared first on Portcullis Labs.
]]>Before we start, let’s first clarify which of the various RDP connection types this post is about. There are 3 types of connection:
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):
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.
If users are used to dismissing a warnings like this one each time they connect, then this post is relevant to them:
At a high level, the attack will proceed in a similar way to any SSL MiTM attack:
The only complication to this attack is that our tool has to talk the RDP protocol briefly before creating the required SSL connections.
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):
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.
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 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.
Simultaneously, our tool also sends and SSL Client Hello to the RDP server and creates a second SSL connection.
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>
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.
]]>