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.

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.

Instructions

This is a cross between a scavenger hunt and a CTF event. Each USB key will contain a puzzle which has to be solved, giving the location of the next USB key. These puzzles aren’t security specific, so anyone technically minded should be able to take part. If you’d like to participate, come along to the Portcullis Village and we’ll point you towards the first location.

Please note: These USB keys are not guaranteed to be safe! The team before you may have left all sorts of nasties on there. Please use sensible precautions, as you would when plugging any unknown device into your computer.

Rules

• Please don’t remove the USB keys from their locations, or move them from where you found them. This will ruin the fun for others!
• Once you find a USB key, copy the contents off before you start working on the challenge.
• Please don’t alter the contents of the USB keys.
• Have Fun!

Problems?

If you have any issues, think something is wrong, or just need some help, please come and find us at the village!

The post EMF Camp 2014 USB scavenger hunt appeared first on Portcullis Labs.

BSides London is an annual community-driven security conference which, this year, will be taking place at the Kensington and Chelsea Town Hall in London.

Graham’s talk coincides with the disclosure of a set of vulnerabilities in the administration features of the Citrix NetScaler appliance, which will be discussed in the talk.

Graham has provided the following abstract for his talk:

“Breaking binary protocols and bad crypto”

This talk is a running account of a few weeks spent attacking and reverse-engineering a widely deployed network device. Graham went from having little knowledge of the system, to producing some powerful and interesting exploits. The focus of this talk is more towards how the issues were found, rather than the issues themselves. To that end, a generic set of hints and tips will be proposed for analysing and attacking binary protocols, including a method for classifying and identifying unknown cryptography used on data.

While Tim will be presenting “Mobile application testing considerations” and has provided the following abstract for his workshop:

“Mobile Application testing considerations”

This workshop represents a quick dive into the world of mobile application testing, focusing on Android but with consideration for Windows Mobile, BB10 and iOS. It will be based on Portcullis’ mobile application testing methodology although it will cover much of the equivalent OWASP methodology of which I am a contributor. It will cover testing from a network perspective as well as how you assess the attack surface an application presents locally.

The post Portcullis security consultants to present at BSides London appeared first on Portcullis Labs.

I spoke at Securi-Tay last year (video), before I joined Portcullis, on the security threats posed by common office and datacenter devices such as photocopiers, printers, and UPSs. This year I decided to tackle a much more foreboding and monolithic topic: cryptography. I feel that one of the major obstacles to learning about cryptography is the stigma around it – it is often seen as obscenely complex, studied only by mathematicians with foot-long beards and a slew of three-letter acronyms trailing their surnames, detailing their accomplishments. Another obstacle is the lack of reputable, high quality, entry-level education in the subject outside of university courses and paid workshops. This aspect has improved somewhat, especially with the introduction of free online courses like Stanford’s, but free materials are certainly nowhere near the breadth and ubiquity we come to expect in other areas of security education. As such, I felt that I should do my part in rectifying this.

My talk, entitled “Breaking crypto without breaking your brain”, aimed to give people a basic understanding of the common types of cryptography that I see in practical use as part of my day job, without needing an advanced degree in mathematics. In contrast to many introductions to the topic, I skipped the classic ciphers such as the Caesar cipher, simple alphabetic transposition and substitution ciphers, and other algorithms of that ilk, as I rarely find knowledge of them useful in the context of real security assessments. Instead, I focused upon one-time pads, modern stream and block ciphers, padding, block cipher modes, and demonstrated how seemingly strong encryption can often be broken trivially.

The talk was recorded and should be available on YouTube within the next few weeks, via the AbertayHackers YouTube account. In the meantime, you can download the slides and both demo applications:

• Slides - Breaking crypto without breaking your brain
• Demo 1 - OTP key re-use
• Demo 2 - ECB block-cipher mode weakness

Aside from my own, there were a number of very good quality talks from both industry professionals and students. I thought it would be nice to write a short description of each that I saw, with some take-away points for each talk.

Olly Whitehouse – “Real world threat modelling”

This talk covered a range of topics around the concept of assessing a black-box appliance, with a view to building a threat model. Olly proposed that by building a threat model, pentesters can obtain greater coverage of targets during tests, primarily by answering simple questions that help us understand the system. He highlighted the need to understand underlying technologies, especially the operating system, in order to minimise the risk of missing key issues. Finally, he went on to discuss ways of building threat models, visualising them, and utilising feedback from security tests to improve upon existing models.

Three take-away points:

• Go for the simplest attacks to reach your goal – elabourate and sexy tricks aren’t important
• Threat modelling can help both pentesters and the organisations that hire them
• Threat model discussions with security engineers, developers, and other technical staff can lead to real improvements in security posture

Panagiotis Gkatziroulis – “Physical attacks: Walking past the egg shell perimeter”

This talk gave a broad overview of the technological, structural, procedural, and human challenges that are involved in physical security. First, a range of security measures were discussed that fall into the building design and security technology category, including entry choke points, placement of receptionists and guards, use of CCTV cameras and electronic doors, as well as the training of the personnel involved. Panagiotis noted that reception staff are often not trained to act as security guards, despite the fact that fooling them may get you the “keys to the kingdom”. He went on to discuss four avenues of exploitation when dealing with human opponents: misrepresentation, obligation, authority, and emergency. Five key reasons why humans fail to act were proposed: a sense of obligation to business goals (not wanting to hinder productivity), employees feeling that they aren’t targets, anxiety of punishment if they mistakenly report something, a lack of confidence in challenging people, and a belief that security is someone else’s problem.

Three take-away points:

• Physical security is meaningless if humans can be subverted into giving you access
• Often a lack of proactive security – changes are reactive, after the damage is done
• Once you get a pass from reception, you win. These people should be trained in security procedures

Oren Benshabat – “DNS distress”

Oren’s talk focused on the problems of DNS cache poisoning and DNS amplification attacks from the ground up, explaining the subject in detail. He began with cache poisoning – an attack that tricks a system into accepting a spoofed DNS response. He described bailiwick checking, a series of checks designed to enforce correct responses, and how this process can be subverted by flooding the target with reply packets containing different query IDs until one is accepted. He went on to cover Dan Kaminsky’s BIND attack, which spoofs an entire domain rather than just one hostname, by spoofing the nameserver of a domain to point at an authoritative DNS server under the attacker’s control. He proposed several fixes, including BIND patches, randomised source ports, DNSSEC, and pinning of nameserver IP addresses. He went on to discuss DNS amplification DoS attacks, which involve tricking open DNS servers into sending large reply packets to a target system. A range of DNS features that increase response packet size were discussed, including EDNS0, DNSSEC, as well as proprietary and custom DNS extensions. Finally, countermeasures such as IP source validation (mainly at the ISP level) and restriction of open recursion were suggested, with the caveat that there is no bullet-proof solution against DNS amplification attacks at the current time.

Three take-away points:

• There are multiple ways in which DNS can be abused, even when properly configured
• Some DNS security features (e.g. DNSSEC) help to fix one problem but also contribute to other problems
• There is no current practical solution to DNS amplification attacks

Dom Cashley – “Security in SCADA”

SCADA is a topic that I am personally interested in, but have very little knowledge of. As such, I was very happy to see someone approaching the subject at an entry level. Dom started the talk by explaining the traditional SCADA network design, including Human-Machine Interface, Master Terminal Unit, and Remote Terminal Unit devices, and how they are usually deployed in production facilities. Whilst the original design was focused on an air-gapped network, Dom noted that many modern SCADA devices are in fact no longer air-gapped, and are commonly available from the internet for remote access purposes. He went on to explain how off-the-shelf hardware was often used to network these devices and link them to IP networks, making an attacker’s job easier. Additional security issues were also noted, such as a lack of security training for engineers that are deploying equipment, general purpose computing platforms being used in field devices (including BYOD-style policies), and “SCADA in the cloud” management systems. Dom noted several problems with patching and updates, including long-standing hardware life spans, a reluctance to take down critical devices for patching, and use of old insecure protocols. A demo was also shown, using a special demo board and an exploit that causes the MTU to alter pump motor parameters without alerting the HMI user.

Three take-away points:

• SCADA is usually controlled by software on regular PCs, often running Windows
• Patching bugs is paradoxically problematic due to the critical nature of systems
• Systems are often not air-gapped and regularly appear on the internet, and may be found on SHODAN

Paco Hope & Ritesh Sinha – “The Colour of your box: The art and science of security testing”

Along with Paco, Ritesh, and the usual exuberance we’ve come to expect, the stage was occupied with two rollercoasters built from k’nex, wrapped almost entirely in large cardboard boxes, exposing only the starting and finishing sections of track. These contraptions formed a metaphor for the core concept of their talk: black-box vs. white-box testing. A toy car was placed into each, which could be heard traversing the track, but the car did not appear at the other side. Two teams were invited from the audience to diagnose the fault, each given access to one rollercoaster each. This was described as the black-box test, where only inputs and outputs could be seen, functionality could be deduced, and some vision of the internal technologies was available. Each team reported that the system utilised k’nex, was meant to take a car in one side and send it through to the other, but did not work.

The teams were then allowed to open flaps on the sides of the boxes to see inside, and propose one single fix that would solve the problem – essentially a white-box test. The “one issue” restriction was designed to emulate a true penetration test, where the customer receives a report and cannot be guaranteed to fix anything but the highlighted issues. Paco noted that reports needed to be clear, concise, and free of unnecessary technical jargon, stating that far too many reports end up reading somewhere along the lines of “bla bla bla owned you bla bla bla root shell bla bla bla Cross-site Scripting bla bla bla disaster!”. Now that the Teams had access to the internals, both began identifying potential problems with the design, and tried to come to a conclusion on what should be fixed. After some pointers from the presenters, the solution was eventually found: a piece was blocking the passage of the car and needed to be moved.

The conclusion given was that both black-box and white-box approaches are necessary, as they both promote different types of thinking and analysis. Black-box tests tend to focus on the external attack surface that most attackers would see, whereas white-box tests tend to focus more on implementation details that may lead to potential issues. By combining the two methods, the presenters propose that a strong coverage of the target can be obtained.

Three take-away points:

• Black-box makes you focus on external attack surface, white-box makes you focus on implementation details
• Reports need to be clear, concise, and explain the full spectrum of problems in order to facilitate improvements
• Combining both types of testing helps increase coverage during assessments

The conclusion of Paco and Ritesh’s talk marked the end of the conference day, after which we all congregated in the student union bar for after-party drinks. I’d like to issue personal thanks to all involved with organising and running the conference, including all the speakers and sponsors.

As I noted above, all talks were recorded and should hopefully be available on YouTube within the next few weeks.

The post Securi-Tay 3 wrap-up appeared first on Portcullis Labs.