VICTOR LASZLO: If we stop fighing our enemies, the world will die.
RICK BLAINE: Well, what of it? It will be out of its misery.
-- From the movie "Casablanca" (1942)
Sorry, but some days I just can't help thinking to myself "Oh well,
as much fun as it has been, this whole lab experiment called The
Internet was never really going last or stand the test of time anyway."
The problem isn't the technology. It's the politics. It's fragility
by design.
Oh! And by the way, one news source that I was just reading a few minutes
ago stated that all of the carnage at Dyn today was caused by something
on the order of just 1/10th of the known CCTV bots out there.
And I'm thinking, like, "Gee! I guess that we ought to count ourselves
as lucky that whoever was running this thing, for whatever reason, just
didn't much feel like firing up the whole entire bloody thing today.
Otherwise, you know, we might have REALLY had a problem."
Regards,
rfg
P.S. To all of you Ayn Rand devotees out there who still vociferously
argue that it's nobody else's business how you monitor or police your
"private" networks, and who still refuse to take even minimalist steps
(like BCP 38), congratulations. Via your inaction and self-centered
intransigence you have today moved us all one step closer to the day
when the relevant decisions will be taken out of your hands. You are
succeding brilliantly at creating the exact thing that you most abhor,
i.e. government control.
Clemenceau said that war is too important to be left to the generals.
Well, guess what? The Internet is too important to be left to the
[[fill in the blank]]. It has already begun...
What does BCP38 have to do with this? All that does is block one specific type of attack (and cause a lot of collateral damage). The IoT devices do not need to spoof addresses - they can just generate attack traffic directly. This is even better, because you can't cut those eyeball addresses off - those are the same addresses your target audience is using. If you cut off the eyeball networks there's not much point to running an internet business website anymore.
nothing technical, as these iot attacks are not spoofed.
think of it as a religion.
I'm going to save this e-mail forever!
no extra charge
we deploy it more than most. we talk about it less than most. and
every time something untoward happens on the internet, we do not tell
everyone that they should deploy bcp38, iltering, origin validation,
dnssec, ipv6, ...
Block one type of attack enough times and you've accomplished something. Because script kiddies are taking advantage of published exploits doesn't mean we stop setting passwords on things. You have to protect from them all.
No, no collateral damage. We discussed this a couple weeks ago and there was no credible evidence of collateral damage.
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).
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:
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:
* 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 :
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:
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.
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.
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.
If there is enough concentration of common flows from a certain set of IPs, it's quite possible to detect the scanning activity using sampled flow data if one were collecting such data. I say sampled as 1-for-1 flow data collection is not common.
You would not see packet content just using flow data.
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).
The Internet *is* already broken.
After the attack on Krebs, the terabit+ attack on OVH, and the
events of Friday, if there are still some people who fail to grasp
this fundamental point, then it can only be because some folks
have become really adept at living in denial.
