Raccoon is the next flashy security flaw with a name, cute logo, and a website (and a PDF). Raccoon is a flaw in TLS version prior to 1.3, and seems to be a clever bit of work, albeit one with limited real-world application. The central problem is that these older versions of TLS, when using Diffie Hellman (DH), drop leading all-zero bytes in the resulting pre-master key. As that key is part of the input for calculating the master session key, a shortened pre-master key results in a slightly faster calculation of the master key. If an attacker can make fine-grained timing measurements, he can determine when the pre-master key is trimmed.

Let’s review Diffie Hellman, briefly. The client and server agree on two numeric values, a base g and modulus p, and each party generates a secret key, a and b. Each party calculates a public key by raising the shared base to their own private key, mod the shared modulus: A = g^a mod p. These public keys are exchanged, and each party raises the received key to their own secret key: A^b. Exponents have a non-obvious quirk, the power rule. A value raised to a power raised to a power is the same as the value raised to the power of the exponents multiplied together. g^a^b is equal to g^(a*b). By going through this mathematical dance, the server and client have arrived at a shared value that only they know, while preserving the secrecy of their private keys.

On to the attack, which is only exploitable when the server is reusing its DH key for multiple connections. The attack is to capture the target client’s public DH key, which is sent in the clear as part of the TLS handshake. The attacker now initiates a new TLS handshake, but chooses a special value for its own public key: The target’s public key, raised to a random-but-known exponent. Note that this means the attacker can’t actually calculate the new shared key, but can learn something about it. Through carefully measuring the server’s response time, it can be determined if this new DH shared key has a leading zero byte. This isn’t terribly useful on its own, but there is a mathematical trick that changes the game, the Hidden Number Problem.

The Hidden Number Problem (HNP) is an approach to breaking public key cryptography like DH. The math involved is above my pay grade, but we’ll try to get an overview, at least. In the DH exchange, the modulo operator is used to keep the magnitude of the numbers manageable. There is a side effect — the normally one-dimensional number line can be thought of as a two-dimensional number grid. There are some clever algorithms that work on a 2D lattice that don’t work on the normal number line. The result is that when you have enough clues about the hidden number you’re looking for, it can become much easier to find that number.

One of the unexpected conclusions of HNP is that not all bits are equally important. Knowing the most significant bits (MSBs) are much more useful when trying to solve HNP. To put it another way, it’s more useful to know that a number is between one thousand and five thousand, than to know that it is even. The fact that the information leakage reveals the most significant byte means that it’s much more useful than just shortening the key size by eight bits.

After discovering multiple cases where the new key starts with a zero byte, an HNP solution is feasible, and the victim’s session key can be calculated. With that key, the entire session can be decrypted.

Raccoon isn’t too hard to mitigate. On the server-side, simply don’t reuse DH keys. This is considered best practice anyway, and most distros and devices ship in this configuration by default. On the client side, dropping support for Diffie Hellman key exchange in the TLS handshake also mitigates the issue. All the major web browsers have already retired these older modes, but there will inevitably be support in libraries and applications for years to come. The timing side-channel that makes this all possible requires very tight measurement tolerances, so it will likely be difficult to actually use Raccoon in the real world.

There are cases where Raccoon is much easier to pull off. Certain configurations of F5 BIG-IP devices have a particular bug that makes detection of the zero byte much easier. The report indicates that there are other implementation with similar flaws, likely in the process of being reported and fixed.

TLS Finished

Next is yet another TLS attack, but this one is entirely a vulnerability in the wolfSSL client. The report describes the problem as the TLS 1.3 state machine not being strictly enforced. Put simpler, wolfSSL accepts a “finished” message while still in the process of validating the certificate. An attacker can successfully man-in-the-middle a TLS connection. Version 4.5.0 has been released, addressing the bug.

h2c Request Smuggling

Many web services use an architecture where an Nginx instance works as a reverse proxy and load balance. Nginx often does the TLS termination, as well as providing security and user authentication. In this arrangement, end users aren’t intended to directly connect to the back-end servers. A method to bypass that separation often brings about unexpected security problems. [Jake Miller] over at Bishop Fox Labs did some interesting work on using HTTP/2 over cleartext (h2c) as a new way to accomplish HTTP request smuggling. We’ve talked a bit about HTTP request smuggling in the past.

The trick here is that it’s possible to request a connection upgrade from HTTP/1.1 directly to an h2c connection. This is usually done using TLS-ALPN, a TLS extension specifically designed for managing allowed protocols. The HTTP/2 specification doesn’t allow the upgrade request to be sent in a regular TLS connection, but it seems that some front-ends incorrectly allow the request to be forwarded to the back-end. If the protected HTTP server allows the connection upgrade, the front-end will dutifully treat the connection as an unmanaged tunnel, bypassing any protections built into the front-end service.

SSH Honeypot

How many login attempts does an open SSH service attract in three months? Thanks to [David Tomaschik], we can safely say it’s over nine (hundred) thousand! The analysis of the login attempts proves interesting, with a litany of default and often used username/password combinations represented. One password in particular caught my attention, J5cmmu=Kyf0-br8CsW. This doesn’t seem to show up anywhere other than the list of commonly guessed passwords. I immediately wondered if it was an injection attack that worked on some obscure system. [David] asks for information on this password guess, if anybody knows where it’s from, and I’ll echo that curiosity.

Security Through Obscurity

Finally for this week, an essay by [Utku Sen] caught my attention on the virtues of security through obscurity. It’s a good opportunity to talk about this controversial topic, but if you have time, go read the essay first. His point is essentially that obscurity is a useful component of a defense in depth strategy. So long as one is careful about it, this isn’t a terrible idea, with some caveats.

On some level, nearly all security is through obscurity. Your password is secure because it’s obscure enough to not be on a list of common passwords. Your 4096 bit key is obscure enough that it won’t be guessed before the heat death of the universe. Beyond that, things like moving your SSH port is useful to cut down log noise. Disabling root SSH logins forces an attacker to guess the account name as well as the password, essentially adding key length.

But really, neither of those scenarios are what we’re talking about when we talk negatively about security through obscurity. The phrase usually refers to vulnerable software, or really bad policy, that we don’t think will ever get attacked because it won’t get noticed, like running a super old version of WordPress on the company website, and not worrying about it, because hardly anybody visits it. A particularly troubling example is the tendency of certain companies to write really sloppy and insecure code, and trusting that because the source is closed, the flaws will never be found.

What we really need is to think about what threats we are protecting against. Avoiding SSH log spam is a bit different from protecting against a determined attacker. Moving your SSH port is helpful in the first case, but not at all in the second. In the end, I agree with [Utku]’s conclusion. Obscurity isn’t a security solution, but sometimes it can be useful. Also, since he mentioned port knocking, I have to plug Fwknop. It’s the idea of port knocking, but with real crypto, not just obscurity.