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 self-deprecatingly – 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, or switch the ticket to be valid on a different sever – one they might not normally be allowed to access.
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.
There’s an acceptable reason for this redundancy: if the encryption is there not for secrecy but to prevent unauthorised modification and to preserve integrity, repeated data can be convenient.
Again, the concept is similar to the way that train tickets (in the UK, at any rate) usually have your destination and travel date printed smudgily on the front, for a fast and informal check, but also have a unique ticket number that can be used to validate the purchase more 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 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 printed, 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.)
In other words, you could tweak the server name in an existing Kerberos ticket, and the server that verified the ticket wouldn’t spot the treachery.
Fixing the bug
Here’s how a popular open source Kerberos implementation called Heimdal somewhat 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 file server software, and in FreeBSD, have been patched, so apply updates to affected open source Kerberos components as soon as you can.
It’s 2017, not 1987, so 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.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/EsZc2onkXbc/
Black Hat USA returns to the fabulous Mandalay Bay in Las Vegas, Nevada, July 22-27, 2017. Click for information on the