Windows security hole – the “Orpheus’ Lyre” attack explained

Every few months, a new vulnerability comes along that gets more publicity than most.

Sometimes that’s because it’s very serious and thus creates widespread concern anyway, and sometimes that’s because it’s what we call a BWAIN – a Bug With An Impressive Name that attracts attention, often with a dedicated website and logo to go along with the catchy title. (Remember Heartbleed?)

And sometimes, to be fair, it’s a bit of both.

The latest BWAIN is an authentication bug with the very fancy name of Orpheus’ Lyre, although we’ll avoid that pesky dangling apostrophe by referring to it as OL from now on.

Amusingly, OL not only has its own website and logo, but even its own theme tune that rather annoyingly autoplays when you visit the OL website. (The theme tune is somewhat worryingly – or perhaps cynically – called Crocodile Tears.)

OL is a security hole in a venerable network authentication system called Kerberos, probably best known because it is widely used by Windows for logon and access control.

Kerberos explained

Loosely speaking, Kerberos is what’s known as a ticket-based authentication system.

If client X wants to access server Y, for example, it doesn’t negotiate directly with server Y, but first contacts the Kerberos server and requests an “access ticket”, thus allowing the authentication process to be centralised and carefully managed.

With Kerberos, you don’t need to have tens or hundreds of servers each storing, managing and validating lists of passwords – a task that is surprisingly easy to do badly, and that can quickly lead to inconsistencies, misconfigurations and security holes.

The Kerberos concept is much like the way train tickets work: the platform barriers that open to let you get on your train don’t need to be able to accept payments, issue tickets, give change, or help you select from the options available for your chosen journey; instead, they just need to know how to validate the ticket you already bought at a ticket machine or the ticket office.

Kerberos tickets use strong cryptography so that they can’t be hacked or modified after they’ve been issued, at least in theory.

If attackers could undetectably modify some of the data fields in a security ticket, they might be able to extend the time that the ticket remained valid, pretend to be a different user, switch the ticket to be valid on a different sever, or trick a client to trust an imposter server in place of a real one.

Repeated data in Kerberos

Unfortunately – perhaps because its design dates back to the 1980s, before cybercrime became the problem it is today – Kerberos doesn’t encrypt everything that it stores in the access tickets it generates.

Some of the data fields in a Kerberos ticket appear twice – once in plaintext form, and again in encrypted form.

Strictly speaking, data redundacy of this sort is neither necessary nor desirable, but it does serve a vaguely useful purpose – in the same way that train tickets (in the UK, at any rate) usually have your destination and travel date printed smudgily if unreliably on the front, so you can quickly and informally tell two tickets apart, but also have a unique identification number encoded on them that can be used to validate the ticket rigorously if needed.

You can see where this is going.

The researchers who found the OL vulnerability realised, in more than one widely-used implementation of Kerberos, that the programmers had been inconsistent.

There was a place where the software incorrectly relied on the hackable, unencrypted server name in the access ticket, instead of looking at the tamper-protected encrypted version.

That’s a bit like an inspector on a train from central London asking to see your ticket, where the destination EALING BROADWAY is clearly shown, but nevertheless taking your word for it when you insist that the ticket is, in fact, valid all the way to EDINBURGH. (Edinburgh is up in Scotland, a destination more than 50 times further away than Ealing and perhaps 15 times more expensive to reach.)

According to the researchers who found the OL hole, this bug means that an attacker on your network could modify an official Kerberos reply in order to lure an unpatched client computer to an imposter server.

To continue our train analogy, crooks could undetectably adjust Kerberos tickets to persuade client computers to travel trustingly all the way to EDINBURGH instead of getting off at EALING BROADWAY as originally intended.

Fixing the bug

Here’s how a popular open source Kerberos implementation called Heimdal ungrammatically describes the surprisingly simple patch:

In _krb5_extract_ticket() the KDC-REP service name must be obtained from encrypted version stored in enc_part instead of the unencrypted version stored in ticket. Use of the unencrypted version provides an opportunity for successful server impersonation and other attacks.

Without the technical jargon, this means: when you extract information from replies sent out by the Kerberos authentication server, only ever use tamper-protected data fields. Ignore any unencrypted Kerberos data – it can be modified undetectably, so you can’t trust it.

What to do?

The Windows implementation of Kerberos used to be vulnerable, but was fixed in Microsoft’s July 2017 security update under the designation CVE-2017-8495, so make sure you’ve installed the latest Windows patches.

Numerous open source implementations, such as those in various Linux distributions, in the Samba networking software, and in FreeBSD, have been patched, so apply updates to affected open source Kerberos components as soon as you can.

As the discoverers of OL have noted, this bug can’t be exploited by a client against an unpatched server – instead, the risk is that an unpatched client could be led astray by an imposter server.

In other words, it’s not enough just to patch your servers and leave all your other computers to their own devices.

By the way, if you are planning to encrypt something, try encrypting everything instead – that way, you won’t have to worry that there was something you didn’t encrypt, and you won’t accidentally end up in the same position as if you hadn’t encrypted anything.

If Kerberos had only ever stored the server name once, in encrypted form, the error that led to this vulnerability would have been impossible to make.