Badlock vulnerability disclosed | Hacker News Reader

Badlock vulnerability disclosed

badlock.org

34 pointsrunesoerensen49 comments

Just for those of you who don't keep abreast of vulnerability research: the overwhelming hot-take response to Badlock is that this is a candidate for the most over-hyped vulnerability of the year, and that the underlying issue (that SMB was pervasively vulnerable to MITM) is well-known already..

It's not SMB. It's nothing to do with SMB. Please read the vulnerability disclosures.

so if I'm reading it correctly it's a downgrade attack where the attacker can MitM a connection?

If so, I'm struggling to not agree that this has been overhyped a lot.

I'm ambivalent towards the hype.

The web site is nothing to do with the Samba Team. Having said that, this is an important enough bug that lots of vendors need to patch immediately, and the website really helped let them know that they needed to address this as soon as possible.

Could it have been handled better ? Maybe, but you get back to me after you've coordinated security disclosure for 15+ major product vendors and give me some tips :-).

Sorry I must have missed the bit where I impuned the rollout of the issue, or suggested I could have done it better?

My comment related to the hype surrounding this bug, which I see (from an infosec point) as a bad thing.

From https://www.samba.org/samba/history/security.html it looks like there were 8 CVEs for bugs in samba this month and 14 in Microsoft's monthly patch bulletin (https://technet.microsoft.com/library/security/ms16-apr)

Should all of those have logos and websites...? Do the other issues in these releases not need to be fixed...?

So why is it a bad thing? Well to me it contributes to "vulnerability fatigue". the more issues that get hyped up and then don't turn out to be objectively more serious than many other issues that are getting release, the more people will dismiss efforts to draw attention to issues that come up.

This is the first DCE RPC protocol level vulnerability I'm aware of. DCE RPC isn't the web, but millions of businesses depend on it (mostly unknowingly) to do admin on their local networks every day.

Not trying to mitigate someone else's hype, but from the Samba point of view this is one of the most serious bugs we've ever had to fix I think. We've had worse bugs that only affected Samba (root-level compromises, shudder), but the effect of this one is the most widespread.

I'm not writing this to be argumentative, but to get a better idea of what you mean by "protocol level vulnerability". Do you mean, "vulnerability intrinsic in the DCE RPC protocol, and not in the application layer functionality on top of it"?

Because, didn't the Welchia worm target DCE RPC?

I mean intrinsic to the "bind" authentication part of the DCE RPC protocol. Because the connection level part of that isn't integrity protected then any mitm can downgrade it.

this is an important enough bug that lots of vendors need to patch immediately,

I'm curious who those vendors are that have trivially MitM'able networks.

It's not the vendors, it's their customers :-).

Sorry. You're right, of course.

I only skimmed the CVEs, and from painful memories of having to implement all that shit for scanner products, that whole bundle of protocols is just "SMB" in my head --- in particular, DCERPC to me is "stuff you do over a named pipe".

Because jra_samba doesn't want to elaborate: https://technet.microsoft.com/library/security/MS16-047

  Update FAQs
  
  My application or product uses the SMB protocol, does this issue affect me?
    - No. Only applications and products that use the SAM or LSAD remote protocols
      are affected by this issue. The SMB protocol is not vulnerable.

"An elevation of privilege vulnerability exists in the Security Account Manager (SAM) and Local Security Authority (Domain Policy) (LSAD) remote protocols when they accept authentication levels that do not protect them adequately. The vulnerability is caused by the way the SAM and LSAD remote protocols establish the Remote Procedure Call (RPC) channel. An attacker who successfully exploited this vulnerability could gain access to the SAM database.

To exploit the vulnerability, an attacker could launch a man-in-the-middle (MiTM) attack, force a downgrade of the authentication level of the SAM and LSAD channels, and then impersonate an authenticated user. The security update addresses the vulnerability by modifying how the SAM and LSAD remote protocols handle authentication levels."

Sorry, wasn't deliberately not elaborating. I hadn't read the Microsoft announcement yet, I've been too busy working on our side of things. Thanks for the link.

Is it just me or is this really not all that exciting? Some NTLM MITM and downgrade stuff mostly, hasn't that family of protocols always had those issues? From all the pre-announcement hype I'd expected at least something on the level of unauthenticated remote root over UDP :P

Also this web site seems to be overloaded, and there's not even any links to the relevant MS16-0xx patches. Not so impressive :(

> Is it just me or is this really not all that exciting?

Hmm, let's recap:

0. Samba has, for years, been a pure clusterfuck to compile and build yourself, attempts at getting community help from the mailing list are always deflected with "don't do that, use SerNet's binaries". Distribution packages as well are not supported by the Samba community, it's SerNet or GTFO.

1. SerNet stops distributing precompiled Samba binaries for free. Thus, users are forced to either buy absurdly expensive "samba+" licenses (250€/server/year!) or to stick to distribution packages, which are still at 4.1.

2. Samba, led by SerNet, stops supporting 4.1.

3. Samba announces "Badlock" _several weeks_ in advance and helpfully points out that, since 4.1 reached EOL a week earlier, users will have to upgrade to versions that are only available from source or as paid SerNet binaries.

I'm sure there's absolutely no malicious intent behind this whole ridiculous charade.

This is the first time I recall hearing about SerNet. What is this, some kind of sell-out or hostile takeover? I always thought samba was created by "that rsync guy" and a team of nice open source maintainers. I had no idea.

It seems that SerNet provides a huge chunk (the majority?) of the manpower behind Samba, and has thus considerable influence in organizing the project.

Unofficial back-ports are being attached to the bug report all the way back to 3.0.x. Red Hat, SuSE and others have donated engineering time and resources to review and create these back ports. All vendors will be preparing patches for all supported versions. Microsoft is also patching the same vulnerability.

This is a large coordinated effort. Expect patches from other non-Samba using vendors shortly.

Which is, of course, the exact opposite of what the Samba project communicated: https://lists.samba.org/archive/samba/2016-March/198526.html

Coincidentally, Samba 4.4.0 was released on the same day: https://lists.samba.org/archive/samba/2016-March/198501.html

No, it's nothing to do with NTLM.

There are some additional NTLM m-i-t-m bugs being fixed in Samba at the same time, but the main bug is authentication independent.

Note that there are still several high impact vulnerabilities released today:

Hyper-v guest escape[0]

Local privilege escalations[1][2]

DOS for IIS/http.sys[3]

Also, there is a different MitM that allows dumping the SAM database[4]

[0] - https://technet.microsoft.com/library/security/MS16-045

[1] - https://technet.microsoft.com/library/security/MS16-046

[2] - https://technet.microsoft.com/library/security/MS16-048

[3] - https://technet.microsoft.com/library/security/MS16-049

[4] - https://technet.microsoft.com/library/security/MS16-047

VM Guest escape sounds a lot more critical and exciting than this badlock bug. Whoa!

[4] is the Microsoft version of the same protocol bug (aka. "badlock" - don't blame us for the name...).

So yeah, it's high impact.

Ugh. Never have I gone so fast from "this is a great idea!" to "this is a fucking terrible idea" as I have with named/marketed vulnerabilities. Heartbleed was a perfect usage because it really was ultra-critical: the patch needed to be applied ASAP and people really did need to STOP signing into servers until it was fixed, and then generate new keys afterward. But now it has become cheap marketing for infosec hucksters trying to get attention for their crappy firm, and used on bugs that are really no big deal. Stop, stop, for the love of god please stop. You're making things worse.

I understand what you want to say, but you have to see this in the context of crypto lockers. I think it's a very realistic scenario that an attacker hacks into a router and then uses this position to encrypt the SAMBA Server in a MITM attack.

Having access to the internal network is a "game over" scenario for 95% of real-world networks. I'm not sure if anyone would even attempt to use something as elaborate as MitM in a crypto locker, when they could most likely just throw a random exploit kit at the network and be done with it in the majority of cases. Not to say people shouldn't fix this, but this was extremely overhyped.

I dunno, but things seem to be getting worse. I remember when it used to be "Have physical access to the local machine, then it's game over". After a while it became "Have remote shell access to the machine, then it's game over".

Have we really come to the point where it's now "Having access to the internal network is a 'game over' scenario for 95% of real-world networks" ?

WTF is happening to our security ?

Yes. Yes, we really have. Yes. On a network large enough to have an important AD DC, internal network access is always game-over.

Some of our largest and savviest clients would pay us to do "internal network penetration tests". Despite these clients having huge security teams and despite internal network security being so important to them that they'd actually spend consultant dollars to test it, those projects were invariably a bonanza for the testers.

I think this explains some of the reaction on Twitter from software security people: if you've done consulting work, you already assumed these networks were totally insecure.

Remember, many branch offices have read-only DC's on them, which makes them vulnerable to this bug. It doesn't have to be "important" DC's. Anything with a password database will do.

I must confess, on my own internal networks I've moved to trying to avoid any unencrypted traffic on the network. SMB3 helps a lot with this (finally Windows clients will do SMB-level encryption to servers).

If you're interested in what pentesters (and presumably their bad guy equivalents) are doing these days on internal pen tests where they start from Local LAN access it's a good idea to look at tools like responder(https://github.com/SpiderLabs/Responder), which spoof responses to various queries and can then be used to grab hashes to either to Pass-the-hash attacks or get passed to password cracking tools for recovery of passwords.

There's also tools like bettercap (https://www.bettercap.org/docs/) which can already use various tricks to grab creds once a MiTM is sorted..

Interesting toolset. Only NTLMv1/v2 mitm attacks possible against a Windows/Samba server though. And the latest patchset should make those impossible if the server were properly configured (i.e. all machines joined to AD, using krb5 auth and SMB3 encrypted file traffic).

Of course, I bet few networks are actually set up this way. But correctly configured Windows/Samba networks should be safe from this.

It rather involved being on the other side of this airtight hatchway... https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...

If the attacker has can MITM you and encrypt your traffic then you are probably screwed already.

1) "Heartbleed" was a great name, while by their own admission, "badlock" doesn’t mean anything in particular.

2) The Heartbleed page explained the bug; the Badlock page doesn’t seem to do so!

Better link: http://badlock.org (https version doesn't seem to work)

Let this be the death knell of the "named vulnerability" sensation. Please.

The naming / marketing of the vulns helps get the word out about the vulnerability. However, it's definitely something that should be reserved for those vulns that affect a larger number of systems severely.

Not really anymore: http://techcrunch.com/2016/04/11/hyping-vulnerabilities-is-n...

I think the value of the name is in making it easy to talk about that particular type of vulnerability as an atomic concept, just like naming everywhere else in computers. I'm not sure there needs to be a bright line on impact for that--if it's impactful enough to talk about, giving it a name makes sense.

The hype comes from people not understanding the impact, pure and simple, and overinflating it as it gets passed around. The name just makes it easier to pass around in the process.

A good solution would attack the understanding of impact part of it--maybe a severity rating system like we have for tornados, earthquakes, or other catastrophic disasters?--not so much the naming. Making it easy to talk about is great, as long as we make it easy to talk about accurately.

While that can be true, greedy idiots are going to use the hype machine to increase their revenue.

I have a vuln I was considering naming, but after BadLock I'm strongly reconsidering it.

Well then some good has come of it :-).

Over-hyped. Nobody in their right mind would expose a SMB share to the public net which mitigates the exploits a bit, and for #1 SMB servers have a long history with MITM issues.

Yes they are bad and people should patch, but did it really need such a build up, and how did the build up help?

Read the disclosures. It's not SMB. It's nothing to do with SMB. It's your AD-DC that is at risk here.

It's not SMB, but it's all DCE RPC, right?

Yes that's correct. But DCE RPC is used for control of all AD-DC instances. That's why it's rated important.

I have, and I didn't say it had anything to do with it. The point is it's hardly a heartbleed or even a shellshock.

Having samba accessible from the public internet is a issue in itself, regardless of this exploit. The MITM is dangerous I guess, but it's a MITM. It's bad, but not super-hypetrain mega-branding bad. It's not colleagues talking about it at lunch bad. Plus all the shady stuff other people have commented on here.

Edit: having re-read the release ok, yeah, it's pretty bad. I still think you overdid it on the release though.

I can't disagree. But I (and the Samba Team) didn't create the website or do the hype.

Unfortunately, there are a lot of people not "in their right mind" that work in I.T.

About 18 months ago, I was asked to look into an issue one of our customers was experiencing (we're primarily an ISP but we also provide some managed services to our customers as well). They had several Windows (2003 and 2008) servers sitting on the public Internet, with public IP addresses, not behind a firewall.

Among several other "WTFs?", their primary domain controller was being used 24/7 in DoS (amplification) attacks by way of the DNS service. Of course, every other port that Windows exposes by default was open and accessible to the world on this machine (and several others).

Don't underestimate the clusterfucks that can happen when so-and-so's nephew who is "good with computers" is allowed to run things.

Here's the Google cache version:

http://webcache.googleusercontent.com/search?q=cache:ZKTmHGz...

I didn't read closely but it seems to be mostly MITM

so some sort of pass the hash all over again?

Reply on news.ycombinator.com