[192241] in North American Network Operators' Group
Re: Death of the Internet, Film at 11
daemon@ATHENA.MIT.EDU (Mel Beckman)
Sun Oct 23 10:22:29 2016
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: clinton mielke <clinton.mielke@gmail.com>
Date: Sun, 23 Oct 2016 14:22:20 +0000
In-Reply-To: <CANq0y_3ijoGwwmw66s7Pg8_+-cBkzVBBEcypfJ3qhUtsjiXeew@mail.gmail.com>
Cc: Florian Weimer <fw@deneb.enyo.de>, "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Clinton,
This is excellent information. While it's not possible to see passwords in =
netflows (only headers are included, not packet contents), it's a sure thin=
g that attacked victims could extract a list of infected machines from the =
IP address scan and then run verification scans against just those devices.=
Any confirmed infected devices could then be published on a blacklist, a l=
a spam blockers. Providers then could either blackhole (at the source) or f=
ilter those addresses.
-mel=20
> On Oct 23, 2016, at 5:20 AM, clinton mielke <clinton.mielke@gmail.com> wr=
ote:
>=20
> A number of people are asking for advice on how to detect this bug. Here
> are some thoughts. Im a mathematician, and not a network operator, so wou=
ld
> love feedback.
>=20
> The source code of Mirai is here, and Ive had some fun taking it apart ov=
er
> the last week:
> https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-ma=
ssive-internet-outage/
>=20
> Notable findings:
>=20
> * Primary infection vector is via telnet scanning. Port 23 is literally
> hardcoded in. 10% of the time, it scans for port 2323. Found that odd, bu=
t
> I suppose one of the devices its targeting uses that port.
>=20
> * The malware disables any services running on ports 22, 23, and 80,
> primarily to prevent other infection opportunities. This surprises me, fo=
r
> I figured that killing port 80 might attract attention from the device
> owner, but evidently the risk of reinfection is too high to not do it. Se=
e
> line 88:
> https://github.com/jgamblin/Mirai-Source-Code/blob/master/mirai/bot/kille=
r.c
>=20
> * The malware uses a large set of signatures to kill other bots running i=
n
> memory, like QBot. I find this interesting. A script kiddie wont, but a
> more sophisticated adversary could add Mirai itself to this list of
> signatures to out compete the released variant of the code. You can see t=
he
> library of signatures here :
> https://github.com/jgamblin/Mirai-Source-Code/blob/master/mirai/bot/table=
.c
>=20
> Digging around, I found that several samples of Mirai related malware hav=
e
> been uploaded and processed by the Indian honeynet's Linux sandbox. Heres=
a
> sample:
> https://detux.org/report.php?sha256=3D0b28b39f25c748b69369c18f72e93795082=
6f189cd43227431384d34a0dce6fa
>=20
> From the host connectivity log, you can see all of the port 23 scanning
> activity. The scanning is completely random, and not sequential, hopping
> all over the place. From a detection standpoint, that is where I would
> start, but this assumes that the hosts on your network are actively
> scanning and not lying dormant.
>=20
> This file, starting on line 124, has all of the hard-coded passwords that
> the malware uses to login to telnet sessions:
> https://github.com/jgamblin/Mirai-Source-Code/blob/master/mirai/bot/scann=
er.c
> - Googling around, you can find the make and model number that each of
> those user/password combinations are associated with. Brian compiled a li=
st
> actually:
> https://krebsonsecurity.com/wp-content/uploads/2016/10/IoTbadpass-Sheet1.=
csv
>=20
> My question for you guys, since Im a theoretician and not a seasoned
> operator: how feasible or legal is it to find telnet scanning activity or
> any of these passwords in high-bandwidth netflows? If its feasible, then
> this at least gets you the active scanning population of hosts, along wit=
h
> the IPs of all of their victims.
>=20
> Aside from the active scanning population, finding dormant hosts might on=
ly
> be feasible if we know the list of C&Cs used, which can very widely. For
> Mirai in particular, the actual bot itself is delivered via tftp or wget
> from another dropper host. Take a look at this other sample for this kind
> of behavior. It connects to a webserver in the netherlands and pulls down
> the payload binary:
> https://detux.org/report.php?sha256=3D996167e00f2aef787c432ca4ce4613edf39=
c5f83363b269137aff3a3e75af5a9
>=20
> I think its unlikely that skilled users of this malware would keep using
> the default 'mirai.arm7' payload, but evidently some are in the wild!
> Finding these http drops might help you find recent successful infections=
.
> More importantly however, the payload delivered itself will have
> information about the C&C, which if we as a community gather and analyze,
> we can find more easily the total set of dormant devices waiting to attac=
k.
> Ultimately if you know the C&C being used, you can much more easily find
> the bots.
>=20
> Im going to pull apart the server code next. About time I learn GO...
>=20
> Lastly, studying this malware long enough, some techniques jump to mind
> which could hypothetically infect and patch a large number of vulnerable
> hosts. Im sure someone brave enough might do this. Totally worked out for
> Robert Morris.
>=20
>> On Sun, Oct 23, 2016 at 3:16 AM, Florian Weimer <fw@deneb.enyo.de> wrote=
:
>>=20
>> * Randy Bush:
>>=20
>>>> What does BCP38 have to do with this?
>>>=20
>>> nothing technical, as these iot attacks are not spoofed.
>>=20
>> How do you know? Has anyone disclosed specifics?
>>=20
>> I can understand that keeping details under wraps is sometimes
>> required for operational security, but if the attacks are clearly
>> succeeding, I would have expected those who posted =93do something,
>> now!=94 messages at least some pointer to technical details of what was
>> going on.
>>=20
>> Not that the underlying threat will go away until we find a way to
>> clean up almost all of the compromised devices (and without breaking
>> the Internet along the way, forever).
>>=20
