
Badlock vulnerability disclosed - runesoerensen
https://badlock.org?new=1
======
tptacek
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..

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

~~~
peterwwillis
Because jra_samba doesn't want to elaborate:
[https://technet.microsoft.com/library/security/MS16-047](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."_

~~~
jra_samba
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.

------
0x0
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 :(

~~~
creshal
> 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.

~~~
jra_samba
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.

~~~
creshal
Which is, of course, the exact opposite of what the Samba project
communicated:
[https://lists.samba.org/archive/samba/2016-March/198526.html](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](https://lists.samba.org/archive/samba/2016-March/198501.html)

------
dsp1234
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](https://technet.microsoft.com/library/security/MS16-045)

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

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

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

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

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

------
Analemma_
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.

~~~
rmetzler
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.

~~~
pfg
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.

~~~
jra_samba
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 ?

~~~
tptacek
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.

~~~
jra_samba
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).

~~~
raesene9
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](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/](https://www.bettercap.org/docs/)) which can
already use various tricks to grab creds once a MiTM is sorted..

~~~
jra_samba
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.

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

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

~~~
michaelbuckbee
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.

~~~
CiPHPerCoder
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.

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

------
orf
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?

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

~~~
orf
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.

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

------
nix0n
Here's the Google cache version:

[http://webcache.googleusercontent.com/search?q=cache:ZKTmHGz...](http://webcache.googleusercontent.com/search?q=cache:ZKTmHGzZ48gJ:badlock.org/)

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

------
cmdrfred
so some sort of pass the hash all over again?

