The POODLE has friends

In October last year, researchers from Google published details about an attack on SSL v3, called POODLE. This attack worked by modifying the padding bytes of the encrypted SSL records that are used to make the records into even multiples of 8 or 16 byte blocks of data, as used by 3DES and AES encryption in the “CBC” mode, checking how the server responded, and used this to deduce the plain text of the transmitted data, one byte at a time, with just a few tries.

TLS Record format for CBC block encrypted records looks like this:

header | payload | MAC | padding | padding length

As SSL v3 never specified the format of the padding, SSL v3 implementations cannot be patched to fix the problem. For this reason SSL v3 support has been dropping ever since (it was 98.9% one year ago, it is now 52%), and it is now essentially disabled in clients, although there are still a lot of servers still supporting it, along with TLS 1.0 and newer versions of TLS. Recently the IETF also deprecated SSLv3 with RFC 7568, as it had become too insecure.

Later, the same problem was discovered to affect some (SSL successor) TLS server implementations, and since TLS does specify the padding format, fixing the problem was easy. Shortly afterwards patches for this POODLE variant started to be deployed.

Are there more problems?

After the original news about POODLE appeared, I started wondering about another check that all SSL/TLS implementations must perform: the TLS Record’s Message Authentication Code (MAC in the above figure). The MAC is a cryptographic “checksum” of the transmitted record’s data (payload), combined with the key the client and server agreed on, a combination that binds the checksum to the negotiated key, and protects the checksum from various methods of predicting it, protecting the integrity of the transmitted data.

I wondered: Do all server implementations perform that check?

If a server does not check this field, then it has ignored one of the primary goals of TLS: ensuring the integrity of the data communicated over the channel. At the very least, data can be modified in transit, possibly corrupting databases, and as a friend pointed out, if the attacker can obtain a copy of the corrupted data (e.g. from a web page displaying the data), the data can be used to compromise the encryption keys.

I added a check for this issue in the TLS Prober, a tool I am using to scan SSL/TLS servers for support of, and compliance with the SSL/TLS specifications, which didn’t find any. It was not until I had completed a rewrite of the Prober engine several months later that I discovered that the test had never worked. Ooops!

The updated test found 269 servers (out of 530000 tested servers) that did not perform the check.

The low number of affected servers could be an indication that the problem isn’t a major issue anymore, and is disappearing, or that is an artifact of my sample being biased towards the Alexa top million sites and several common server names, so that I was just catching the outer fringe of a larger problem.

After some investigation of identified sites with the issue (which I decided to call MACE, for “MAC Error”), I found that the majority (~90%) seemed to be Cisco SSL VPN servers, and contacted Cisco’s security team about it. They confirmed that the servers appeared to be Cisco ASA firewall appliances, but they also reported not being able to reproduce the problem in their lab.

The conclusion was that we needed more information about the identified servers. That would prove to be a serious hurdle to cross. I had already been contacting one Cisco-using site for further details, as well as a number of other sites from my list of servers in order to identify other vendors. With a single exception, none of the contacted sites provided any information. The exception, which identified a different vendor, F5, who had already fixed the problem when they fixed the TLS POODLE problem in December.

To some extent, this reluctance can be understandable, particularly to an external researcher, but even when I suggested that they establish the initial contact with the vendor, and provide the necessary information directly, nobody took me up on it. In most cases I did not even get an email answer.

Eventually, Cisco’s security team went through my list of servers, identified 15 customers based on those server names, and asked the sales contacts for those customers to establish contact and ask for information. They got exactly one (1!) answer.

But that single answer did break the case wide open, identifying the non-default configuration setting that was used by the affected servers (which also helped explain the low number of affected servers found by my scan). This allowed Cisco’s security team to reproduce the issue and discover that it was caused by a problem in the firmware of a third-party component, made by Cavium, and that this affected several other customers of theirs. Cavium started contacting those customers, providing updated firmware for the component, and is disclosing the issue today..

Cisco have documented this vulnerability in Cisco bug ID CSCuu52976 (registered customers only) and has been assigned CVE ID CVE-2015-4558.

Even more problems

After I had confirmed a problem in the MAC check, I started wondering about another, similar check, this time in the TLS Handshake Finished Message. This message is usually the first encrypted message in a TLS connection (recent updates have added some special messages that are sent before the Finished message, e.g. as part of SPDY), and is used to confirm that the client and server calculated the encryption keys correctly and that none of the handshake messages were tampered with while negotiating the connection.

A successful attack on this record could allow an attacker to partially or completely take over the connection, and could allow anything from disabling of security features to establishing his own encryption keys and removing security completely from the connection.

Two possibly mitigating factors are involved: first, the information is encrypted, and as such always have a MAC ensuring the integrity of the message, and also the parties each send the other a Finished message, the second verifying the integrity of the first to the original sender. This means that the attacker will have to be able to bypass the MAC check (as described above, some servers don’t check it), and somehow keep the client in the dark, which might be possible during TLS Session Resume (reusing negotiated encryption parameters) when the server sends the first message, and the client sends the second.

Strictly speaking, it seems rather unlikely that a useful exploit for this can be developed, at least without some other problem being used in combination with the Finished issue. However, difficult does not mean impossible, and what attacks like BEAST, CRIME and POODLE should teach us is that if there is a chink in the armor, the only thing needed to turn that weakness into an attack is a new method that can be used as a fulcrum to tear it open.

The new TLS Prober test for this case turned up just 8 (eight) affected servers, and they were all also affected by MACE, which could mean that an attack is easier to develop. While I was able to tentatively identify and inform one vendor among these 8 servers, Fortinet, and none of the queried sites ever provided information that could identify the other involved vendors.

After some developments regarding variants of the POODLE issue, I started wondering if my assumption that servers would check all bytes of the MAC and Finished message, or none, was correct, and added tests checking modifications of the middle and last bytes of these fields, as well.

The results were surprising.

The updated MACE test turned up another 77 servers that checked the first byte of the MAC, but not at least one of the others I added tests for. The only tentatively identified vendor in this new group was Fortinet, which I had previously tentatively identified as having the MACE+Finished issue. Fortinet investigated and have confirmed that older unmaintained FortiOS 4.2 firmware installations were affected by MACE, but the newer FortiOS 4.3.13, 5.0 and 5.2 versions are not affected. Fortinet have posted an advisory about this.

The updated Finished test, on the other hand, turned up over 6000 new servers affected by the Finished issue. Fortunately, this time I did not need to query sites to discover which vendor was involved. In addition to a number of servers identifying the product in their HTTP Server header, I have known for several years that one of the sites found by my scan was using F5 BigIP servers. F5 quickly confirmed my discovery, and started working on a fix, which they plan to include in a future version.  This issue have been assigned CVE-2015-5517, and F5 have posted information at SOL16970.

As mentioned above, I think exploiting the Finished issue is going to be extremely difficult, and the F5 issue would actually be even more difficult to exploit, since the F5 servers actually checked at least the first and last bytes of the Finished message, but not the middle one, increasing the difficulty by at least a factor 65000. In addition, my test sent a correct MAC, which an attacker would have problems doing (short of other isues), and none of the affected servers accepted corrupted MACs.

In addition to the F5 problem, another test turned up a different kind of problem. The extra test checked if the received Finished message from the server was correctly calculated, using the received Finished as part of the calculated value, in which case a correctly implemented client would be able to detect the tampering with the Finished message (during full handshake, but not session resume).

This test of the returned Finished message turned up more than 200 servers that did not return the expected Finished message. It is possible that these servers returned a Finished message based on the calculated Finished message that they expected to receive (but did not check properly).

A look at some of these servers indicated that most of them, if not all, were Juniper SSL VPN sites, or as the product is now known, Pulse Secure SSL VPN. When informed, Pulse Secure quickly confirmed the issue and started working on workarounds and patches.

This variant have been assigned CVE-2015-5369, and Pulse Secure have posted information about a workaround <http://kb.juniper.net/TSB16756>

I never tried to develop actual attacks on these problem, since these two fields are fundamental security carriers in the protocol, an actual attack should not be needed. In the case of BEAST, CRIME, and POODLE it was necessary to demonstrate that there was an exploitable issue, since the fundamental problems where known, but not believed exploitable. It is conceivable that an attack using the same attack methods as these can be developed for Mace, as well as others that are more specifically exploiting the MAC problem itself.

At present, 0.076% of the servers I’ve tested are vulnerable to the MACE issue, and attacks to modify content transmitted to these servers are likely to succeed.

Regarding the Finished issue, 1.15% of the servers does not check the entire Finished message against the expected message. At present, due to mitigating factors, I do not think it is possible to exploit this issue in an attack, absent other serious issues in TLS that can be combined creating a practical attack.

It should be noted that it is unlikely that all affected vendors have been notified about these problems. I regret that, but given the lack of reliable vendor information in HTTP headers and the non-cooperativeness of the web site owners, it was not possible to contact many vendors.

While I will send links to this article to the affected sites that I originally contacted, I do not have the resources to contact all the affected sites.

Therefore, I recommend that vendors should not rely on customers informing them about the issue, they should independently check their code’s implementation of these operations, and in particular should ensure that they cannot be disabled by configuration settings.