|
|
Log in / Subscribe / Register

The "Badlock" vulnerability

The details for the "Badlock" vulnerability in the SMB DCE-RPC protocol have finally been disclosed, along with the obligatory logo and domain name; there is no word on the availability of hats and T-shirts yet. It is a man-in-the-middle attack that can allow an attacker to access files in an SMB share, or gain access to Active Directory administrative tools, with the permissions of the intercepted user. "Please update your systems. We are pretty sure that there will be exploits soon. Engineers at Microsoft and the Samba Team worked together during the past months to get this problem fixed."

to post comments

The "Badlock" vulnerability

Posted Apr 12, 2016 19:24 UTC (Tue) by jra (subscriber, #55261) [Link] (5 responses)

It's not SMB shares (actually nothing to do with SMB), it's a DCE RPC protocol-level vulnerability. This is particularly bad for AD-DC implementations. Please patch asap.

Thanks !

The "Badlock" vulnerability

Posted Apr 12, 2016 21:15 UTC (Tue) by pboddie (guest, #50784) [Link] (4 responses)

Given the heritage of DCE/RPC, is this something that has been lurking for decades - like some other bug I seem to remember, maybe in X11 or one of the related technologies, that everybody was surprised about because "surely someone would have noticed by now" - or is it a result of more recent development?

The "Badlock" vulnerability

Posted Apr 12, 2016 21:20 UTC (Tue) by fratti (subscriber, #105722) [Link]

Perhaps the X11 bug you remember was CVE-2013-6462, which could be used to trigger a stack overflow with maliciously crafted BDF font files, and had existed for 23 years.

The "Badlock" vulnerability

Posted Apr 12, 2016 21:27 UTC (Tue) by jra (subscriber, #55261) [Link] (2 responses)

Yes, this has been in DCE RPC from the start. Metze was the first person to notice (whilst working with me on a fix for a Samba-specific DCE implementation bug we already had, which Codenomicon found). Amazing work by Metze. All I did was say "hey, wonder if Microsoft is vulnerable to <the other Samba specific bug we found> ?" as it was in a fiddly area of the protocol, and he did the rest :-).

The "Badlock" vulnerability

Posted Apr 12, 2016 22:29 UTC (Tue) by pboddie (guest, #50784) [Link] (1 responses)

Do you think it is likely that Microsoft products other than Active Directory are vulnerable given the DCE/RPC nature of this? I can think of quite a bit of infrastructure that would be affected, if so. (Not that I use or support such products, but the complacency on show might be toned down if people found that they were affected, even if it's merely stuff their employer makes them use.)

The "Badlock" vulnerability

Posted Apr 12, 2016 23:53 UTC (Tue) by jra (subscriber, #55261) [Link]

Microsoft have known about this since June, so I'd assume they've done the analysis required to protect their products. All server endpoints contactable via DCE RPC should at the very least refuse non-signed connections though.

The "Badlock" vulnerability

Posted Apr 12, 2016 19:30 UTC (Tue) by Otus (subscriber, #67685) [Link] (2 responses)

Did the long wait at least mean distro packages were ready to download as soon as this went live?

The "Badlock" vulnerability

Posted Apr 12, 2016 19:40 UTC (Tue) by asn (subscriber, #62311) [Link]

Yes, Red Hat release the minute Samba released tarballs. See https://access.redhat.com/articles/2243351 for RHEL. Fedora packages are in testing waiting for feedback from users. I would expect they will be in stable later today.

The "Badlock" vulnerability

Posted Apr 13, 2016 1:10 UTC (Wed) by pabs (subscriber, #43278) [Link]

Debian is looking for testers for their update:

https://lists.debian.org/debian-security/2016/04/msg00040...

The "Badlock" vulnerability

Posted Apr 12, 2016 20:52 UTC (Tue) by fratti (subscriber, #105722) [Link] (17 responses)

Public Service Announcement related to this vulnerability: Please be aware that yawning is contagious. Try not to yawn in presence of co-workers or your family.

The "Badlock" vulnerability

Posted Apr 12, 2016 21:00 UTC (Tue) by jra (subscriber, #55261) [Link] (16 responses)

I take it you don't administer AD servers then. Probably not many subscribers to lwn do. But for people who do, a notice to patch this is important.

The "Badlock" vulnerability

Posted Apr 12, 2016 21:16 UTC (Tue) by fratti (subscriber, #105722) [Link] (15 responses)

You're right, I don't administrate AD servers. The closest thing I have that's vulnerable would be my Synology DiskStation, which is only accessible in LAN, and I only use over SMB rarely.

In contrast to Heartbleed, which left millions of systems open for exploitation worldwide, this is only affects a small group of sysadmins who would most likely just be happy with the Red Hat notice, or whatever Microsoft publishes.

I think the hype built up by not disclosing the vulnerability for a long time, and the whole branding and website is entirely redundant. It's a lot less scary and a lot less prone to exploitation than many of the vulnerabilities covered by LWN every week.

Here's some examples from just the past few weeks:

  • flashplugin security patch with no less than 24 CVE-IDs, fixing among other things arbitrary code execution
  • mercurial security patch which fixed arbitrary code execution on "hg clone"
  • openjdk sandbox escape
  • pcre arbitrary code execution

Now obviously these don't target the same kinds of computers, and doesn't necessarily leave as many people vulnerable, but they usually have a more straightforward way to be exploited than a MITM-attack on a service that is usually behind firewalls.

The "Badlock" vulnerability

Posted Apr 12, 2016 21:23 UTC (Tue) by jra (subscriber, #55261) [Link] (14 responses)

Once again - it's *not* SMB (how many more times do I have to say this :-).

The reason this is serious, and why the Samba Team have been working on this with Microsoft since it was discovered last June, is that it leaves AD-DC's vulnerable to complete compromise.

These are not large numbers of machines, but they happen to often contain the passwords for everything you might care about on a network. And they're used by *every single* business (AD is *popular* :-).

Didn't name the bug. Didn't create the website. But I have to say I'm conflicted about all the hype. The people affected by this (AD-DC admins) really should patch this very soon.

The "Badlock" vulnerability

Posted Apr 12, 2016 21:34 UTC (Tue) by fratti (subscriber, #105722) [Link] (7 responses)

I didn't say it was in SMB, I said the only thing I use that comes close to what would constitute a vulnerable setup is when I access my NAS over SMB.

I agree that it's important to patch systems for vulnerabilities, but I don't think the marketing was necessary. People unaware of security will get it through automatic updates, people aware of security will stay up-to-date with security advisories, so the delay and additional marketing don't really do any good I think. The kind of scenario where this would be exploited (i.e., by somebody behind the firewall) is not just reliant on exploit code you whip up real quick within 24 hours after the patch was published, but also on somehow infiltrating the network through different means.

The "Badlock" vulnerability

Posted Apr 12, 2016 21:45 UTC (Tue) by jra (subscriber, #55261) [Link] (2 responses)

You have no idea how quickly metze was able to create an exploit :-). Then again, it *was* metze doing it :-).

Badlock - it was Metze's fault after all :-)

Posted Apr 14, 2016 14:00 UTC (Thu) by pr1268 (guest, #24648) [Link] (1 responses)

So, considering the concern you raised in your comment on March 24, does this mean we can blame Stefan Metzmacher for all this? (But in a nice way, of course!)

I, for one, admire how Metze's discussion on the Badlock page mentions why the "branding" of this security vulnerability (and others, for that matter) is so important. Good work, ladies and gentlemen.

Badlock - it was Metze's fault after all :-)

Posted Apr 14, 2016 15:51 UTC (Thu) by jra (subscriber, #55261) [Link]

I don't think Metze can be blamed (or take credit) in any way for that website. It was created by his employer, but that's as far as his involvement goes I believe :-). The credit (or blame) for badlock.org rests entirely with SerNet.

The "Badlock" vulnerability

Posted Apr 12, 2016 22:59 UTC (Tue) by rahvin (guest, #16953) [Link]

A bug as severe enough that total remote compromise of a system that probably holds all the other authentication tokens for your entire network is, IMO, a very valid bug to publicize across the entire internet so no one misses it through negligence.

Though not as wide ranging as heartbleed this sounds like one hell of a bug. Though you might not be affected by it I can guarantee business you work with are. At the very least if you start seeing wide ranging abuse of authority tokens around business you work with you'll have an idea of the cause.

The "Badlock" vulnerability

Posted Apr 13, 2016 8:18 UTC (Wed) by ab (subscriber, #788) [Link] (2 responses)

Given that the original bug was triggered by a fuzzer generating a single packet causing crash in samba, you don't really need to spend a lot of time to get close to reproducer. The issue has very real danger even if you are not realizing it.

The "Badlock" vulnerability

Posted Apr 13, 2016 20:39 UTC (Wed) by jra (subscriber, #55261) [Link] (1 responses)

Well I have to be clear here ab. The original single packet crash lead to you and I looking at the Samba DCE RPC code, which found CVE-level vulnerabilities, but they weren't the protocol level bug that got named by SerNet. The came when I asked metze to see if Windows was vulnerable to any of the implementation problems in the Samba code and whilst checking he suddenly had an epiphany :-). Metze found (and deserves sole credit for) finding the protocol issue all on his own :-).

The "Badlock" vulnerability

Posted Apr 14, 2016 5:41 UTC (Thu) by ab (subscriber, #788) [Link]

Oh, yes, totally. The word 'original' in my response was to indicate where this all started at all.

The "Badlock" vulnerability

Posted Apr 12, 2016 21:47 UTC (Tue) by raven667 (subscriber, #5198) [Link] (5 responses)

> AD-DC's vulnerable to complete compromise

If I understand correctly though it only leaves ADs vulnerable to MITM attacks by someone already on the network who can intercept and modify traffic in between an Administrator and the auth server, which represents its own serious problem, this doesn't give you privileges beyond what the account details you've intercepted has, right? That would make it a no-op if you break into an AD auth'd device, as you could already install a keylogger or access the AD data under the authority of any user on the device.

This is clearly a serious problem, but not in the "SSH worm" level of criticality.

The "Badlock" vulnerability

Posted Apr 12, 2016 23:44 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (2 responses)

"someone already on the network who can intercept and modify traffic in between an Administrator and the auth server"

For most "Enterprise" systems that's going to mean anybody with a smart outfit and a calm yet authoritative voice. It is _very_ hard to get a business to take security seriously enough to stop that being a problem.

The "Badlock" vulnerability

Posted Apr 14, 2016 7:54 UTC (Thu) by NAR (subscriber, #1313) [Link] (1 responses)

How does an outfit and a voice help with a turnstile that requires a keycard to turn?

The "Badlock" vulnerability

Posted Apr 14, 2016 18:46 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Turnstiles are not magic. I live in a city with a popular football (soccer) team and so large perhaps slightly drunken groups of fans are often to be found in the city's railway stations. If I sit and watch for a few minutes as they arrive, I will invariably see, first, a group approaches the person on duty at the stations gate line, they provide a distraction, perhaps they demand kisses, or want the employee to wear a silly hat or advise them on how to reach a distant place. While they do this, two people enter the turnstile with one ticket, the barrier opens, both push through at once, an attentive employee would see this clearly illegitimate behaviour and have the opportunity to demand to see both tickets, but the employee is distracted. A fan travels for free. Physical access control always has a human element, and humans are fallible.

Actually the turnstile is generally a bad sign. That means so many people are passing through that you're not even trying to identify them any more and instead rely on the physical token, usually from HID corporation.

One of the annoying things about me as an employee (or indeed customer) is that I insist on trying things the corporation claims to do but actually just wrote down in a security policy manual and forgot about. As I've written before, I'm the person who phones a sysadmin to ask if the encryption keys are supposed to have changed rather than just clicking past the warnings. So whereas a lot of people have a superficial idea that their workplaces are "secure" I end up actually knowing the (usually dismal) truth about places I work or routinely visit.

I have worked in one (1) place where the turnstiles worked and the policy was enforced. Everybody there disliked it, but at some point something bad enough had happened that managers actually cared. I have had to get a senior manager to come vouch for my manager to get them into the building, which is a good sign. Of course that place also had a strict no cameras rule, but if you care about security you may have seen hidden camera footage from inside it, taken by a reporter who'd been hired for an entry-level job and thus had a legitimate access card. That footage cost them a not inconsiderable amount of money. So, they were sincerely trying but it's hard to call it an unqualified success.

I have worked in at least six other offices or buildings which had turnstiles but either tailgating was widespread or security staff routinely waved people through without properly checking their ID. So those turnstiles were theatre only. I have no doubt whatsoever that I could visit those places today and plug something into a Cat5 network port without being arrested and probably without even being asked any awkward questions despite not having any valid ID.

However I have worked at two very small offices where everybody knew every other employee by name and face, where to get into the building required that somebody get up, come open the front door and let you in. _That_ is a scenario in which it's hard to exploit something like Badlock. A grey hat physical penetration guy once told me that a good sign for an actual secure environment is that the people working there have to do their own cleaning - if they don't it means a contract cleaner (laughably "vetted" by someone whose goal is to pay as little as possible and avoid annoying the client) has physical access out of hours. Being small though, none of those places used Active Directory and so they weren't vulnerable to anything like Badlock.

The "Badlock" vulnerability

Posted Apr 14, 2016 5:34 UTC (Thu) by asn (subscriber, #62311) [Link] (1 responses)

"[...] this doesn't give you privileges beyond what the account details you've intercepted has, right?"

You recognize that we are talking about an AD-DC? Normally it contains credentials for everything you might care about in your business ...

The "Badlock" vulnerability

Posted Apr 14, 2016 16:50 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I realize that one of the endpoints is the AD-DC, but is your ability to intercept or read credentials constrained by which individual credentials you can scrape via MITM? So if you scrape a regular user cred, you can only see the data in the directory tree that that user had access to, so scraping an admin level cred has a lot of value, as is scraping a machine principle account cred. The vuln doesn't give you access to the directory directly, it allows you to scrape sensitive creds via MITM that you could use to connect to the directory and further scrape or modify data, right? Or am I totally misunderstanding how this works?

The "Badlock" vulnerability

Posted Apr 13, 2016 3:06 UTC (Wed) by HybridAU (guest, #85157) [Link] (17 responses)

I'm with the people saying this is way over hyped. Microsoft has their own rating system for vulnerabilities. That goes Critical > Important > Moderate > Low and this month they released 6 critical patches and 7 Important patches. The "Badlock" patch rated as Important, it didn't warrant an out of cycle patch, it didn't event warrant a "Critical" rating, just Important.

I'm not saying that this couldn't be a serious issue in the right situation but it's not worth a logo an a website.

Also I've noticed badlock.org is only available over http, no TLS, so if I had man-in-the-middle I could potentially inject an exploit one of the several critical vulnerabilities patched in Internet Explorer or Microsoft Edge today and get straight up remote code execution.

The "Badlock" vulnerability

Posted Apr 13, 2016 4:17 UTC (Wed) by jra (subscriber, #55261) [Link] (12 responses)

Yeah well the website wasn't created by the Samba project, so we can't take any blame for that :-).

The "Badlock" vulnerability

Posted Apr 13, 2016 12:01 UTC (Wed) by richmoore (guest, #53133) [Link] (10 responses)

It would have been nice if 3 weeks ago the Samba project had said no need to panic rather than just let the highly misleading site remain as the only source of information. It's hype like this that gives security a bad name.

The "Badlock" vulnerability

Posted Apr 13, 2016 17:00 UTC (Wed) by jra (subscriber, #55261) [Link] (9 responses)

Well it's hard to judge. From the Samba project point of view this *was* a panic situation. You can use this flaw to extract the entire password database from a Windows AD-DC. Individual Samba bugs (remote root access) can be worse, but this affects Microsoft installations too (and god knows what other products they have out there that use DCE RPC).

So whilst I wasn't happy with the website or name (which I didn't understand at all :-), I wasn't unhappy with the fact that the publicity will cause many more people to patch. And believe me anyone using AD *needs* to patch.

The "Badlock" vulnerability

Posted Apr 14, 2016 0:53 UTC (Thu) by FrankL (guest, #108226) [Link] (8 responses)

I'd be nice if Samba took security seriously.

For starters, they could allow disabling of NTLM / RC4 authentication.

Microsoft does this through 'protected user' security groups and various group policies.
Samba has been offering... nothing. Which basically means you need to run Samba with the horrid NTLM/RC4 stuff enabled and no means to disable it (at least, last time I tried to find out how to do this).

The "Badlock" vulnerability

Posted Apr 14, 2016 5:27 UTC (Thu) by asn (subscriber, #62311) [Link] (7 responses)

Samba offers an option to disable NTLMv1 auth. See the manpage for smb.conf:

ntlm auth (G)

This parameter determines whether or not smbd(8) will attempt to authenticate users using the NTLM encrypted password response. If disabled, either the lanman password hash or an NTLMv2 response will need to be sent by the client.

The default is 'on' but will be changed to 'off' soon.

The "Badlock" vulnerability

Posted Apr 14, 2016 15:15 UTC (Thu) by FrankL (guest, #108226) [Link] (6 responses)

I'm talking about NTLM in its entirety, and RC4_HMAC_NT encryption type in Kerberos.

They're horrid in terms of security, and cannot be disabled in Samba. MS allows disabling them both AD DC server and client-side.

The "Badlock" vulnerability

Posted Apr 14, 2016 15:48 UTC (Thu) by jra (subscriber, #55261) [Link] (5 responses)

Good point. I'll look into what we can do to allow users to disable this. Don't suppose you'd like to log a bug on this at bugzilla.samba.org ? That would help me remember (I'm out next week giving at talk at Vault).

The "Badlock" vulnerability

Posted Apr 15, 2016 3:36 UTC (Fri) by flussence (guest, #85566) [Link] (4 responses)

This sort of response is pleasantly surprising to see. I've been conditioned to expect developers for big projects to double down on stubbornness when someone tells them they're doing it wrong...

The "Badlock" vulnerability

Posted Apr 15, 2016 4:12 UTC (Fri) by ab (subscriber, #788) [Link] (2 responses)

If you want your condition to be true, I can tell you that with MIT Kerberos integration we are getting close to get rid of RC4. FreeIPA which uses a bit of a Frankenstein setup with Samba 3 PDC and external MIT KDC, already allows to run cross-forest trust to AD without RC4 keys. We keep them enabled right now due to the fact that there are still plenty of Windows 2003 Server deployments at big companies but plan to first make it switched off and moved to an option and eventually disable completely.

MIT Kerberos support for Samba AD DC build is coming along too. We are at about 50 patches on top of the current git master for Samba. Heimdal-enabled Samba AD DC has been relying on RC4 keys for long time, in fact, it is the only type it could use over cross-forest trust right now as its logic in generating a salt for principals was severely limited to the point that none of AES-based keys were possible. This is cross-realm trust situation, for in-domain use it was somewhat mitigated already.

So yes, Samba developers know they had it wrong but at the same time we know and do things to improve this situation. :)

The "Badlock" vulnerability

Posted Apr 15, 2016 17:33 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

Take care: this sounds like it might rely on an AD-DC or at least Kerberos, which sounds like it might break the 'simple sharing' server role = standalone use case. (Sure, this isn't an important use case for corporate deployments, but it's damn useful for home deployments, where Kerberos let alone an AD-DC is insane overkill even for geeks like me. I mean, I used Kerberos on my home net for a while, but took it out again because ticket expiry was impairing robustness, it had an endless stream of security holes so it was impairing security, and to add insult to injury it was defending against a lot of attacks that, while real, mostly meant that someone had physically broken into my house, in which case I'd have bigger things to worry about... AD-DC has many of the same reasons for non-deployment on small, highly controlled sites.)

The "Badlock" vulnerability

Posted Apr 16, 2016 4:51 UTC (Sat) by ab (subscriber, #788) [Link]

Samba still maintains number of roles, including very simple ones. Unfortunately, NTLM ones are becoming less and less secure for use and defaults reflect that. You may want to switch them off but that would be your own choice. As always, of course.

The "Badlock" vulnerability

Posted Apr 15, 2016 16:12 UTC (Fri) by jra (subscriber, #55261) [Link]

Nah, this is Samba. We're always doing it wrong for somebody :-).

The "Badlock" vulnerability

Posted Apr 14, 2016 0:48 UTC (Thu) by HybridAU (guest, #85157) [Link]

jar, after rereading my post I feel like I've been a bit too harsh. My grumpiness was about the general trend of bugs with logos and websites and not meant to be an attack on you. I think you understood that :-) but I just to make it clear.

I also want to say thank you for finding an fixing this bug, for that we are all better off. Often creating security fixes is a thankless job and I think you (and people who fix and maintain code in general) deserve more a lot more recognition... So thanks.

The "Badlock" vulnerability

Posted Apr 13, 2016 8:33 UTC (Wed) by ab (subscriber, #788) [Link] (3 responses)

Shooting the messenger is not a right approach. Yes, we all don't like a hype and the website created by SerNet, but it would be better to acknowledge a problem rather than pushing it under the 'hype' category as many in InfoSec industry seem to enjoy doing.

Microsoft chose to rate as they wanted. They claim it only applies to SAMR and LSA while it actually a DCE RPC level issue. What about Exchange? Last time I saw, Exchange clients were running without sign/seal enabled. They also chose not to patch Windows 2003 Server which they know is used by many of their customers despite being out of official support. They know this problem exists and can be exploited in these enterprises but chose to ignore it.

Another facet of the issue is that an unpatched Samba-a-domain-member in AD can be used to stage a successful attack on AD DCs. One could potentially use Samba's remote code execution flaw (part of CVE-2015-5370) to break into winbindd without authentication and thus own secure channel towards AD DCs. Chances are slim but are not deniable.

The "Badlock" vulnerability

Posted Apr 13, 2016 14:51 UTC (Wed) by cwillu (guest, #67268) [Link] (2 responses)

Shooting the messenger seems to be _exactly_ the right approach, when the messenger goes above and beyond what the message warrants.

We're not shooting him because of the content, but the delivery.

The "Badlock" vulnerability

Posted Apr 13, 2016 16:58 UTC (Wed) by ab (subscriber, #788) [Link] (1 responses)

Overall reaction is exactly by throwing content out and concentrating on the messenger. To give you a level of incredible misunderstanding what the content is, here is a quote from 'threatpost.com', a site that is associated with Kaspersky Lab:

"As it turns out, Badlock was hardly the remote code execution monster many anticipated. Instead, it’s a man-in-the-middle and denial-of-service bug, allowing an attacker to elevate privileges or crash a Windows machine running Samba services."

The end of the second sentence is all you need to know about infosec news reporting.

The "Badlock" vulnerability

Posted Apr 13, 2016 18:22 UTC (Wed) by jra (subscriber, #55261) [Link]

Sorry Alexander but I've started pointing people at this comment, as it's the *best* summary of the sorry state of Infosec 'journalism' I've ever seen :-) :-).

The "Badlock" vulnerability

Posted Apr 13, 2016 8:25 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

The badlock site doesn't have any details. So the "finally been disclosed" link doesn't go anywhere with any actual disclosure of what the bug is about. Is there a link to some actual information on the bug (and if so, could the story be updated with it)?

The "Badlock" vulnerability

Posted Apr 13, 2016 8:36 UTC (Wed) by ab (subscriber, #788) [Link] (1 responses)

May be your browser caches it a bit to aggressive? badlock.org has references to all detailed CVE descriptions on samba.org.

The "Badlock" vulnerability

Posted Apr 13, 2016 8:58 UTC (Wed) by paulj (subscriber, #341) [Link]

Seems like. Thanks! Still not that much in the way of detail on the protocol vulnerability though.

The "Badlock" vulnerability

Posted Apr 13, 2016 10:36 UTC (Wed) by gowen (guest, #23914) [Link] (1 responses)

If it wasn't for Badlock, I wouldn't have no lock at all...

The "Badlock" vulnerability

Posted Apr 13, 2016 17:04 UTC (Wed) by clugstj (subscriber, #4020) [Link]

Gloom, despair, and agony on me.

The "Badlock" vulnerability

Posted Apr 17, 2016 2:41 UTC (Sun) by jra (subscriber, #55261) [Link]

Alexander Bokovoy wrote a really great write up on how this bug was discovered and fixed:

http://rhelblog.redhat.com/2016/04/15/how-badlock-was-dis...


Copyright © 2016, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds