[aklug] Re: [NUGA] Re: getting ready for Badlock?

From: Royce Williams <royce@tycho.org>
Date: Mon Apr 11 2016 - 15:39:58 AKDT

When the scan is finished I'll be able to provide a bit more info.

In the meantime, here are the top-talker domains. Note that this is driven
by PTR records, which can be stale. Note also that there are plenty of IPs
that either have no PTR, or have a generic one, so just because your domain
name doesn't appear here, don't assume that you're not exposed.

I haven't definitively verified this, but I'm guessing that ACS is probably
blocking 139 and/or 445 by default at the customer edge, and GCI probably
isn't.

888:gci.net
21:acsalaska.net
20:kpunet.net
20:kgbsd.org
6:arctic.net
4:acetekk.com
3:rogershsa.com
2:ctcak.net
2:arcus.org
2:firstcitylibraries.org
2:cvinternet.net
1:ak.us
1:wwcpa.com
1:serrc.org
1:galenanet.com
1:eatribes.net
1:caa-ak.org
1:investfairbanks.com
1:frozenreality.com
1:megawattelectric.com
1:psd-k12.org
1:north-slope.org
1:alaska.net
1:muni.org
1:tekmate.net
1:nana.com
1:alaskadesign.com

Royce

On Mon, Apr 11, 2016 at 1:35 PM, Damien Hull <dhull@section9.us> wrote:

> Royce,
>
> Nice! It would be interesting to see what kind of devices these are.
> Devices like network printers could have file sharing turned on by default.
>
> On Mon, Apr 11, 2016 at 12:35 PM, Royce Williams <royce@tycho.org> wrote:
>
>> 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 13:58:08 2016

This archive was generated by hypermail 2.1.8 : Mon Apr 11 2016 - 13:58:08 AKDT