[aklug] Re: getting ready for Badlock?

Update: general announcement is coming out 17:00 hours UTC - so 8am Alaska.

http://badlock.org/

This coincides with the usual timing of Patch Tuesday, apparently.

Royce

On Mon, Apr 11, 2016 at 11:32 AM, Royce Williams <royce@tycho.org> wrote:

> Badlock is landing tomorrow. From a survey of Alaskan IP space, I can
> confirm that there's a non-trivial amount of SMB facing the public
> Internet. If you have not already scanned your own IP space, now's a good
> time to do so.
>
> My scan is still running, but a summary of the results so far can be found
> here (access limited to Alaskan IP space). These are Alaskan IPs that are
> publicly responding to SMB queries.
>
> http://www.techsolvency.com/scans/smb/smb-os-discovery.txt
>
>
> You should also definitely be blocking any outbound SMB at your border.
> This blog post has a good way to check from a Linux machine:
>
> http://malwarejake.blogspot.com/2016/04/getting-ready-for-badlock.html?m=1
>
> Quoting:
>
> $ nc smbcheck.rsec.us 139
> $ nc smbcheck.rsec.us 445
>
> If you get no output, you're good to go. If you see what I have displayed
> below, you've got problems:
>
> jake$ nc smbcheck.rsec.us 139
> DANGER! Your network allows TCP port 139 outbound. You should block this!
>
> jake$ nc smbcheck.rsec.us 445
> DANGER! Your network allows TCP port 445 outbound. You should block this!
>
> [end quote]
>
>
> This thing may be wormable -- either directly, or with multiple hops (get
> any user to click on something, or hijack an ad network to get in, then
> exploit Badlock). So you may want to think hard about things like being
> ready for quarantine, emergency patching, restoring from 100% airgapped
> backups. Disconnecting a few machines to pre-quarantine them as "known
> good" might not be a bad idea. Experimenting with what you can do with SMB
> completely turned off may also be in order.
>
> This nmap scan may also be helpful. Use latest nmap (7.12) to get the
> latest SMB detection that they added expressly for Badlock.
>
> sudo nmap -T5 -p139,445 -PE -PS139,445 -PA139,445 -PU139,445 -PP --script=
> smb-os-discovery -iL cidr.list -oA smb-os-discovery
>
>
> Royce
>
>
> On Sat, Mar 26, 2016 at 10:44 PM, Royce Williams <royce@tycho.org> wrote:
> >
> > On Fri, Mar 25, 2016 at 2:13 PM, Royce Williams <royce@tycho.org> wrote:
> >>
> >> What are folks doing to get ready for Badlock?
> >>
> >> http://badlock.org/
> >>
> >> Since no details have been released, my inclination is to start
> recommending that folks do a full inventory of all internal SMB-speaking
> systems (Windows and otherwise), including base OS version, SMB/Samba
> versions enabled, vendor, etc. ... and scan the environment with either
> whatever vuln scanning suite you have, or at least some of the *smb* Nmap
> NSE scripts. Disabling as much backward compatibility as you can get away
> with is probably a good idea anyway, and doing so in advance is probably a
> good idea, since we have more that 2 weeks' warning.
> >>
> >> From:
> >>
> https://blogs.technet.microsoft.com/josebda/2012/06/06/windows-server-2012-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-or-smb-3-0-are-you-using-on-your-file-server/
> >>
> >> CIFS – The ancient version of SMB that was part of Microsoft Windows NT
> 4.0 in 1996. SMB1 supersedes this version.
> >> SMB 1.0 (or SMB1) – The version used in Windows 2000, Windows XP,
> Windows Server 2003 and Windows Server 2003 R2
> >> SMB 2.0 (or SMB2) – The version used in Windows Vista (SP1 or later)
> and Windows Server 2008
> >> SMB 2.1 (or SMB2.1) – The version used in Windows 7 and Windows Server
> 2008 R2
> >> SMB 3.0 (or SMB3) – The version used in Windows 8 and Windows Server
> 2012
> >>
> >>
> >> ISPs that aren't already blocking inbound SMB probably should be. If
> they're not, may want to consider blocking it on the client side.
> >
> >
> > To clarify, I intended for this to mean the customer demarc endpoint,
> downstream from the ISP that is not blocking SMB.
> >
> >>
> >> The speculation is that it might be wormable, but Microsoft has been
> mum on the issue so far.
> >>
> >> And regardless, probably a good idea to reserve a change window for
> April 12th. The inventory of all SMB-speaking devices will help gauge
> worst-case scope. I know that "we don't know what it is yet, but here's the
> list of boxes that may be in scope" is better to have in hand in advance,
> rather than scrambling to track down all of the infected boxes after a worm
> hits. YRMV (Your Risk May Vary), of course. ;)
> >
> >
> > Two updates:
> >
> > 1. A now-deleted tweet from a member of the discovery team says
> "#badlock means admin accounts for everyone on the same LAN":
> >
> >
> http://www.csoonline.com/article/3047221/techology-business/company-behind-the-badlock-disclosure-says-pre-patch-hype-is-good-for-business.html#tk.twt_cso
> >
> >
> > 2. Info on newer SMB versions that I neglected to include.
> >
> > First, newer MS links about SMB info for Windows 8.1 / Windows Server
> 2012 R2 (thanks, Mack!):
> >
> >
> https://blogs.technet.microsoft.com/josebda/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-are-you-using/
> >
> > SMB 3.02 (or SMB3) – The version used in Windows 8.1 and Windows Server
> 2012 R2
> >
> > ... and per
> https://blogs.technet.microsoft.com/josebda/2015/05/05/whats-new-in-smb-3-1-1-in-the-windows-server-2016-technical-preview-2/
> >
> > SMB 3.1.1 - Windows 10 / Windows Server 2016
> >
> > And per Wikipedia: [SMB 3.1.1] supports AES-128-GCM encryption in
> addition to AES-128-CCM encryption added in SMB3, and implements
> pre-authentication integrity check using SHA-512 hash. SMB 3.1.1 also makes
> secure negotiation mandatory when connecting to clients using SMB 2.x and
> higher.
> >
> > Royce
> >
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Apr 11 10:53:17 2016