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@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-massi...
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=0b28b39f25c748b69369c18f72e937950826f189...
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.... - 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=996167e00f2aef787c432ca4ce4613edf39c5f83...
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@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).