16 03 DROWN (TLS, SSL 2, and EXPORT GRADE

ciphers)

Decrypting RSA with Obsolete and Weakened eNcryption

DROWN depends on a cryptographic backdoor known as EXPORT_GRADE, baked into
US products by law until the end of the twentieth century.
In 2015, TLS/SSL vulnerabilities callen FREAK and LOGJAM showed that it was possible
to trick servers that still supported EXPORT_GRADE to fall back to these backdoor ciphers, and thus
made it possible, albeit unlikely, that crooks could break into supposedly-secure TLS sessions.
DROWN does something similar, giving attackers a tiny but fighting chance of cracking individual TLS
connections.
As the DROWN paper points out, the general form of this attack requires roughly 40,000 probe
connections and 250 cryptographic computations, and would cost about $440 in cloud computing
charges. For each investment of that amount of time and money, you get a 1-in-900 chance of
decrypting a single TLS connection.
Were not going to try to explain DROWN here, because the paper consists of 22 dense and technical
pages, but, very briefly put, the attack works against servers that support TLS, and SSL 2, and
EXPORT_GRADE ciphers.
SSL 2 is a legacy predecessor to TLS: you shouldnt use it or even support it any more because it is known
to be insecure.
Indeed, the internet standards document RFC 6176, published five years ago, requires that TLS clients
and servers never negotiate the use of SSL version 2.0.
Nevertheless, if you can find a server that does accept both TLS and SSL 2, and also supports
EXPORT_GRADE ciphers, you may very occasionally be able to eavesdrop on an encrypted session.
You can sniff data from an existing TLS connection, and then use it in a sequence of SSL 2 connections to
the same server in the hope of figuring out the decryption key needed to eavesdrop on the original TLS
connection.
Note that decrypting one TLS session at a time is all you can do with this attack. Unlike Heartbleed,
you cant use DROWN to retrieve secret data from the server itself, such as other peoples data, or the
servers private key.

15 04 HTTP .sys

(MS15-034)

1. This isnt an IIS bug, so it doesnt apply only to IIS servers.

As far as we can see, the bug affects pretty much any Windows software that uses Microsofts HTTP
stack to respond to HTTP requests, whether that software runs on desktops, laptops or servers.
All sorts of software could fall into that category: custom company messaging systems; data loggers;
configuration agents; peer-to peer-tools; heck, even an existing malware infection!
2. The bug allows remote code execution.
3. The bug can be triggered with an innocent-looking HTTP request from outside your network.
That means that the bug could, in theory, be turned into a true network worm like the Morris Internet
Worm or SQL Slammer. Those worms spread without having to wait for users to do anything such as
clicking a web link or opening an attachment.
4. The bug is in a kernel component, and a successful exploit gives the attacker SYSTEM privileges.
5. Even Server Core is affected.
6. Proof of Concept (PoC) exploit code can already be found on the internet.
The proof of concept weve seen doesnt actively attempt to exploit the bug and do anything
deliberately malicious. But reports say that a probe by the PoC does actually trigger a buffer overflow,
which could be distracting and time-consuming when you review your logs. You can expect a sea of
probes over the next few days, as inquisitive researchers find the PoC and set it loose to see what
happens

15 05 LOGJAM

(TLS MITM downgrade attack EXPORT GRADE Diffie-Hellman cipher)

The attackers essentially act as a MITM encryption strength shifter between
client and server.
Due to a weakness in the TLS protocol itself, the LOGJAM crew
1. intercepted a client request for a Diffie-Hellman-Merkle cipher,
2. passed the request on to the server as a downgraded EXPORT-quality 512-bit
cipher request,
3. forged the reply to the client so it didnt notice the deception.

They can simulate the server cryptographically because they know how to crack the discrete LOG
problem for 512-bit primes using a pre-calculated dataset and a Number Field Sieve technique,
whereupon they JAM the forged results into their own replies.
Because the connection between the MiTM and the server is only export-grade, the attackers can
extract the session keys agreed during the TLS setup, and therefore read and modify the rest of the
sessions traffic.

15 03 FREAK

(TLS MITM downgrade attack EXPORT GRADE RSA cipher)

The bug is known to exist in OpenSSLs TLS implementation (before version 1.0.1k),
in Apples SecureTransport, and in the Schannel TLS library that is part of Microsoft
Windows.

A TLS session using export grade RSA encryption (512-bit RSA keys) can be sniffed,
saved, and then fairly easily cracked later on. Today, we are talking about two
weeks of cracking on a decent $2000 laptop, or 12 hours and $100 using Amazons cloud.
Additionally, many servers use the same hardware-RSA key over and over again. In theory, this is not a
bad thing, because RSA keys arent supposed to be crackable, so you can save processing power by not
creating a new key every time.
But in the context of FREAK, it may mean that, after cracking a servers export grade key, you can use
the result to decrypt other sessions, using the same key, without paying another $100 (and without
waiting another 12 hours).
Cracking an RSA key is done by a technique known as factoring the modulus, something that is
supposed to be computationally unfeasbile, except in the case of export grade keys.
Loosely speaking, that means you decompose the key into its public part (which is supposed to be
public) and its private part (which you are never, ever supposed to get your hands on).
With the private key, you can now sign traffic from your own imposter website as though it came from a
trusted third party.

Indeed, the team behind the original FREAK research claim to have done just that to create a fake nsa
dot gov.

OpenSSL updated its code in January, so versions from 1.0.1k onwards dont have this bug. Microsoft
has published a list of workarounds that turn off export grade TLS encryption on Windows, which
prevents FREAK attacks from working.

15 01 GHOST (glibc / gethostbyname())

The spooky name comes from the system functions where the vulnerable code was
found. gethostbyname() and gethostbyname2() perform a host lookup from the
DNS retrieving the IP address fo r a given url.
Problem: gethostbyname() and gethostbyname2() check if the parameter passed
to them is an IP address already, avoiding the need to look up a host IP.
is 15 characters, so gethostbyname() and gethostbyname2() have a 16 byte buffer
allocated in memory. HOWEVER, if theyre resented with a string > 16 bytes it causes a buffer overflow.
gethostbyname() crashes and might present (with a lot of trial and error) a condition enabling remote
code execution.
255.255.255.255

See more at: Critical glibc Vulnerability Puts All Linux Machines at Risk https://wp.me/p3AjUX-ufb

Remote code execution is possible, but not straightforward. It needs to bypass the security mitigations
present on the system, such as ASLR.
See more at: Critical glibc Vulnerability Puts All Linux Machines at Risk https://wp.me/p3AjUX-ufb
It actually exists only in some versions of a software module called glibc, short for GNU C library;
its not used by default on Windows, OS X, iOS or Android. The issue affects all versions of glibc since
2.9
The bad news is that many, if not most, computers running Linux do use glibc, and may be at risk.
If you have any Linux-based systems, including home firewalls and routers:

Check with your vendor, or the maker of your distribution, to see if you need a patch.
If you do, make plans to apply the patch as soon as you can.

Oh, and if you are a programmer, you shouldnt really be using the gethostbyname functions anyway.
They were superseded many years ago by the much more flexible and useful function getaddrinfo(),
which you should use instead.

14 11 Kerberos 0-day (MS14-068)

The MS14-068 bug is in the Kerberos Key Distribution Center (KDC). Kerberos tickets
are a bit like hotel room keys that are encoded at the front desk after a security
check, and then handed over to give you access, for a limited period, to specific parts
of the building.
The MS14-068 bug is an EoP: it pretty much lets anyone who can logon to your
domain at all, even as the most junior sort of user, to turn themselves into a domain administrator, the
most powerful force in a Windows network.
Thats like a guest with an access card for an overnight stay in Room 1337 being able to transform his
card into an access-all-areas-at-all-times skeleton key.
Worse still, MS14-068 is not a privately disclosed hole. That means the Bad Guys got there first.
Microsoft has issued patches for all Windows flavours, including desktop versions that arent directly at
risk because they arent Active Directory domain controllers and dont have the offending Kerberos
services running.

14 11 Winshock a 19-year-old vulnerability (CVE-2014-6332

with a CVSS score of 9.3)

The bug can be used by an attacker for drive-by attacks to reliably run code
remotely and take over the users machine even sidestepping the Enhanced
Protected Mode (EPM) sandbox in IE 11 as well as the highly regarded Enhanced
Mitigation Experience Toolkit (EMET) anti-exploitation tool .
At this time, there is no evidence that the bug has been exploited in the wild.
This is perhaps in part due to the difficulty of exploiting CVE-2014-6332. Fixed array element sizes, few
opportunities for attackers to place arbitrary data where VBScript arrays were stored on the browser
heap, and the enforcement of variant type compatibility all have complicated attackers attempts up
until recently.
However, Freeman and his IBM X-Force Research team created a PoC and published detailed
information describing possible exploit steps for the vulnerability using VBscript.
MS November 2014 Patch Tuesday included remediation for this vulnerability.

14 10 POODLE

(MITM downgrade attack to SSL3.0 protocol)

Summary: Padding Oracle On Downgraded Legacy Encryption

POODLE attack can allow a crook who is eavesdropping on your network to read even
your HTTPS-encrypted traffic.
By modifying traffic as it passes through a rogue access point, you can interfere with the way HTTPS
connections are established.
That means you may be able to trick both ends of the connection typically a browser and a server
into downgrading their security, falling back to using an old and less secure HTTPS version known as SSL
3.0.
If you can do that, you may then be able to extract confidential data, thanks to a bug known as CVE2014-3566 (exploiting crypto flaws in SSL3.0 CBC)
WHAT TO DO?
The problem is SSL 3.0 and its unauthenticated, unverifiable padding process. SSL 3.0 is an old version
of the secure socket layer protocol: about as old as XP, in fact.
It was long ago superseded by safer alternatives such as TLS 1.0, TLS 1.1 and TLS 1.2.
So consider turning it off altogether.
You can tell your browser not to support SSL 3.0 connections, so that no rogue cybercrook in a coffee
shop can downgrade your HTTPS sessions to his own advantage.

And you can tell your servers not to offer or to accept SSL 3.0 connections, so that you can never be
tricked into accepting a malicious sequence of POODLE downgrade requests.
only about 1 in 1000 users make SSL 3.0 connections at all.
Those 1 in 1000 users have much bigger problems than POODLE: most of them are using SSL 3.0 because
theyre still running IE 6 on Windows XP.
And thats a story for another day

14 04 HEARTBLEED

(OpenSSL buffer overflow)

The bug only exists in the OpenSSL 1.0.1 source code (from version 1.0.1 to 1.0.1f
inclusive), because the faulty code relates to a fairly new feature known as the TLS
Heartbeat Extension.
The heartbeat extension was first documented in RFC 6520 in February 2012.
TLS heartbeats are used as keep alive packets so that the ends of an encrypted connection can agree
to keep the session open even when they dont have any official data to exchange.
Because the heartbeats consist of a reply and a matching response, they allow either end to confirm not
only that the session is open, but also that end-to-end connectivity is working properly.

https://xkcd.com/1354/

13 08 BREACH attack (Oracle attack against HTTP)

Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext
Loosely speaking, the web server takes the body of an HTTP reply and squashes it
with an algorithm known as deflate, the same compression that is used in PKZIP and
gzip.
On arrival, your browser inflates it and processes it from there as if the HTTP session
had been uncompressed all along.
Even when a compressed HTTP response is wrapped in TLS encryption to produce a secure HTTPS
connection, the actual length of the encrypted data stream (more precisely, the length of the
compressed data inside the encrypted stream) can be determined.
And by trying lots of different inputs, each slightly different from the last, and seeing how well or badly
they compress, you may be able to guess some of whats inside, even though you cant decrypt any of
the messages.
Clearly, to use an imaginary attack in real life, the following are required:

The HTTP pages must include both the PII that I want to guess and some chosen plaintext that I can
control.
The server must be requested, and configured, to serve the pages with compression turned on.
I need to persuade you, while you are logged in, to visit a page containing my malicious do-lots-ofsearches JavaScript.
I have to know what sort of PII I am looking for in order to structure my searches correctly.
I have to be able to sniff your traffic in sufficient detail to recover the length of each HTTP reply.

So, if you run a web server and you turn off compression for any pages that inlcude PII, you neutralise
this attack.
On the other side of the equation, you may be able to force your browser not to invite the use of HTTP
compression in the first place, thus neutralising the attack.

13 02 Lucky Thirteen HTTPS attack

The name comes from the fact that encrypted TLS packets have thirteen header
bytes that are consumed in one of the cryptographic calculations on which TLS relies.
The MITM attack relies on shortening or altering a packet and timing how long the
TLS server takes to reply with its error message when it realises the packet is invalid.
By systematically trying all possible two-byte tweaks (216, or 65536 of them), and assuming perfect
timing measurement, they could guarantee to extract two of the encrypted bytes.

Once those first two bytes are cracked, a further 14 bytes can be cracked, one byte at a time, by trying
all 256 possible tweaks of each byte, for a total tweak cost of 216 + 1428.
And thats the Lucky Thirteen attack.
Its not a terribly practical attack, not least because perfect timing measurements are impossible:

Each tweak attempt causes a TLS session to terminate, which may be both noticeable and timeconsuming.
Each tweaked session needs to have the same plaintext at the same packet location for the
tweaking to be done exhaustively.
The authors needed 27 repetitions of an exhaustive set of 216 tweaks (thats eight million dud
TLS sessions!) to produce enough statistically-significant timing data for a reliable result.

Oh, and that was under ideal network circumstances, with the TLS client, server and MiTM computer on
the same dedicated LAN.
Nevertheless, its an important result because, as mentioned above, it punctures some of the
cryptographic sanctity that TLS is supposed to provide.
Solutions and mitigations, which designers of future protocols might bear in mind, include:

Design and write your code so it isnt measurably quicker or slower when errors occur, even if
this means performing redundant computations.
Use a stream cipher, not a block cipher, to avoid the need for plaintext padding.
Checksum the data after encryption, rather than encrypting the checksum. This ensures that the
quantity of data to be checksummed does not depend on the plaintext.
Use an authenticated encryption algorithm, like AES-GCM, that combines checksumming and
ciphering.

Interestingly, the last-listed mitigation above (use authenticated encryption) is already supported in TLS
version 1.2, which came out in 2008.

11 09 BEAST attack

(Browser Exploit Against SSL/TLS 1.0)

In order to mount this attack, an adversary would need to be watching your internet
connection (MITM), and be able to force you to start your next TLS record with a
given string of his choice, and be able to guess something sensitive that you said
earlier, and guess which part of your TLS stream might have corresponded to it.
..and know the the ciphertext of the last block of the last message which is then
going to be used as the IV for the next message (SSL all versions and TLS1.0 only; TLS1.1 & 1.2 are not
vulnerable to this as IV ranomization is implemented).