Death of the Internet, Film at 11

Sun Oct 23 14:22:20 UTC 2016

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 thing 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 la spam blockers. Providers then could either blackhole (at the source) or filter those addresses.

 -mel 

> On Oct 23, 2016, at 5:20 AM, clinton mielke <clinton.mielke at gmail.com> wrote:
> 
> 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 would
> love feedback.
> 
> The source code of Mirai is here, and Ive had some fun taking it apart over
> the last week:
> https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet-outage/
> 
> Notable findings:
> 
> * 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, but
> I suppose one of the devices its targeting uses that port.
> 
> * The malware disables any services running on ports 22, 23, and 80,
> primarily to prevent other infection opportunities. This surprises me, for
> 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. See
> line 88:
> https://github.com/jgamblin/Mirai-Source-Code/blob/master/mirai/bot/killer.c
> 
> * The malware uses a large set of signatures to kill other bots running in
> 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 the
> library of signatures here :
> https://github.com/jgamblin/Mirai-Source-Code/blob/master/mirai/bot/table.c
> 
> Digging around, I found that several samples of Mirai related malware have
> been uploaded and processed by the Indian honeynet's Linux sandbox. Heres a
> sample:
> https://detux.org/report.php?sha256=0b28b39f25c748b69369c18f72e937950826f189cd43227431384d34a0dce6fa
> 
> 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.
> 
> 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/scanner.c
> - Googling around, you can find the make and model number that each of
> those user/password combinations are associated with. Brian compiled a list
> actually:
> https://krebsonsecurity.com/wp-content/uploads/2016/10/IoTbadpass-Sheet1.csv
> 
> 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 with
> the IPs of all of their victims.
> 
> Aside from the active scanning population, finding dormant hosts might only
> 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=996167e00f2aef787c432ca4ce4613edf39c5f83363b269137aff3a3e75af5a9
> 
> 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 attack.
> Ultimately if you know the C&C being used, you can much more easily find
> the bots.
> 
> Im going to pull apart the server code next. About time I learn GO...
> 
> 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.
> 
>> On Sun, Oct 23, 2016 at 3:16 AM, Florian Weimer <fw at deneb.enyo.de> wrote:
>> 
>> * Randy Bush:
>> 
>>>> What does BCP38 have to do with this?
>>> 
>>> nothing technical, as these iot attacks are not spoofed.
>> 
>> How do you know?  Has anyone disclosed specifics?
>> 
>> 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 “do something,
>> now!” messages at least some pointer to technical details of what was
>> going on.
>> 
>> 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).
>> 