
Mirai Botnet Linked to Dyn DNS DDoS Attacks - ashitlerferad
https://www.flashpoint-intel.com/mirai-botnet-linked-dyn-dns-ddos-attacks/
======
pmontra
The manufacturers of devices should be held responsible for the security of
the devices they sell. This is not different from what they are required to do
for the electrical and physical parts of the devices. Pass some standard tests
that would prevent at least the most obvious vulnerabilities, default
passwords and other bad practices. Run metaexploit against it, etc.

This would raise the attention to secure software development also in other
areas of the IT business. Sure, it costs more upfront but we gain as we suffer
less from this kind of attacks.

~~~
ComodoHacker
Easier to say then do. Information security _is different_ from electrical and
material safety and the key difference is pace of technical progress. The
latter areas are relatively developed and stable, significant progress occurs
in decades. While infosec landscape can drastically change in years and even
months, within life-span of devices. To give you some perspective, toxicity of
asbestos was discovered half a century after beginning of its widespread use
[1]. And it took another half to fully realize the danger and stop using it.

When designing a new device, you can't mitigate a threat that you can't
imagine. And you don't have enough time and budget (time-to-market is the key)
to mitigate all known threats.

I'm not advocating status quo, which is dire. But there is no easy solution in
sight.

1\.
[https://en.wikipedia.org/wiki/Asbestos#Discovery_of_toxicity](https://en.wikipedia.org/wiki/Asbestos#Discovery_of_toxicity)

~~~
malka
There is. Stop making useless networked devices. You dont have time and budget
to mitigate threats. Then dont release.

~~~
ComodoHacker
If they were useless no one would buy them. They are indeed useful. The
problem is they also can be harmful, but not to their users.

The situation can be remotely compared to RF interference. If you use RF
spectrum irresponsibly, you harm your neighbors, police, military and other
parties, so everyone understands some regulation is needed. RF spectrum
regulation is in everyone's interests.

If you use insecure IoT devices, they are exploited to harm some abstract
people on the other side of the globe, who cares about them? If more people
realize their devices can be used to shut down their Twitter and Instagram,
maybe something will change. But I personally doubt that.

------
Animats
It looks like it's going to be necessary to get serious about ingress
filtering. See RFC 2827, which laid out the basics. Fortunately, there aren't
that many ISPs left. If Comcast, AT&T, and Verizon got serious about ingress
filtering, it would cut way down on the number of devices that could get
through with a random IP source address. The ISPs are in a good position to
tell their customers to unplug whatever is causing the trouble. (Assuming it's
not the ISP's own router, which they should be able to fix remotely.)

At the big-pipe level, there should be sampling. 1 in 10000 packets has been
suggested, which will reveal any massive attack without hurting privacy much.
If a big pipe has an excessive fraction of attack packets, that indicates the
sending end isn't doing proper ingress filtering. That's a matter to be dealt
with between network operators, possibly with involvement from CERT and
Homeland Security if necessary.

This problem is solveable, but it's going to take some ass-kicking. There are
now enough big companies annoyed about this for that to happen.

~~~
dmourati
I think you mean egress filtering.

[https://www.sans.org/reading-
room/whitepapers/firewalls/egre...](https://www.sans.org/reading-
room/whitepapers/firewalls/egress-filtering-faq-1059)

~~~
jlgaddis
From the ISP perspective, it is ingress filtering -- he's saying they should
be filtering their customer's traffic as it _enters_ their network, such as
leaving customer's cable modem and entering the CMTS.

~~~
dmourati
Ya, had to put on my ISP hat to see that.

------
zorked
Calling for government regulation of devices is all fun and games until the
government comes along and mandates closed source, irreplaceable firmware like
the FCC did with Wifi access points.

~~~
idlewords
Good regulation isn't impossible. For example, mandating a unique admin
password for each IoT device would go a long way to helping prevent this kind
of fiasco.

~~~
marmot777
How would a unique admin password help in cases where there's a backdoor
accessed via an open port? A lot of the devices used last Friday had port 23
open. The password used in the backdoor was compeletely separate from the
device admin password.

Your advice is good but it wouldn't have helped last Friday.

------
nodesocket
I really hope that dyn releases some graphs of queries per second for a few
day range so we can see how large this DDoS attack really was.

~~~
dmourati
I read 1.2 Tbps:

[http://hosted.ap.org/dynamic/stories/D/DISRUPTIVE_CYBERATTAC...](http://hosted.ap.org/dynamic/stories/D/DISRUPTIVE_CYBERATTACK?SITE=AP&SECTION=HOME&TEMPLATE=DEFAULT&CTIME=2016-10-21-17-26-28)

~~~
tedmiston
For reference, the earlier Krebs attack is quoted on Wikipedia as being 620
Gbps [1]. I'm not sure it's really comparing apples to apples though with this
being at DNS level. ~2x the traffic sure, but at a layer with a lot more
impact on everyone, so the outcome is much more than ~2x worse.

[1]:
[https://en.wikipedia.org/wiki/Mirai_(malware)](https://en.wikipedia.org/wiki/Mirai_\(malware\))

------
dax1928
Is there a way to determine electricity used during all of this? Certainly
each IoT device has low bandwidth and load draw, but each of their service
requests is honored the same as any normal human request. A small signal from
a device prompts more electricity in potentially multiple servers upstream
until the host can satisfy the request. So are there potentially thousands of
kWh being wasted even with mitigation? Or can requests from certain IP's be
denied and thus electricity saved?

~~~
astrodust
I don't think electricity here is the problem. In fact, measuring the impact
is probably pointless, a lot of servers are always-on regardless of traffic.

~~~
speedplane
Yes, but of course the lost productivity of the eastern continental U.S. for
just a few minutes likely dwarfs the wasted electricity by many orders of
magnitude.

~~~
dax1928
Sure, the current draw per byte of information exchanged is negligible. But
I'm curious as to how these millions of cheap, low-power IoT devices can
essentially act as transistors in the sense that their requests can prompt
more relatively higher current draw elsewhere. Once again, this draw is likely
miniscule.

In theory, if every internet connected device in the world could be a part of
Mirai, not only would we not be able to use the internet, but wouldn't the
majority of datacenters be running at full capacity?

------
mastazi
Is there any established way to test my router/IOT device for Mirai
vulnerability?

~~~
archimedespi
Check and see if the Mirai code has default credentials for it, and if so, try
logging in with them.

~~~
bsamuels
try logging in from the WAN, not the LAN. Mirai has no method of attacking lan
interfaces unless a upnp rule was already set up

------
Bedon292
Is there a page somewhere that maps the passwords to corresponding devices?
Essentially a list of what devices are affected by this botnet? I don't think
anything I own is affected, and I monitor my network pretty closely, but would
like to double check. And make sure not to buy any of them either.

~~~
creeble
Your post is late, but I would like to +10 it.

AFAICT, Mirai gains access ONLY through telnet on port 23. I see no one
mentioning that anywhere here. If you do not have a device with something
answering on port23, then you cannot be p0wned by Mirai.

Can anyone verify that statement as correct or incorrect?

~~~
marmot777
I just came into this thread yesterday and today and mentioned it but I get
the feeling this thread but maybe it's too late for discussing as this
thread's been around for like 5 days. I'd like to discuss it more, maybe start
another threwd but it might be futile to try to talk about this topic more.
It's a bummer there's not more passion for this.

------
xorcist
It's easy to call for companies to be held responsible for botnets etc. but
it's important to be much more specific than that.

Google has an absolutely _massive_ bot network in all Android devices running
Play Services, which basically keeps an open root shell to the mothership at
all times. However that is used mostly for good, by keeping devices updated
and removing malware remotely. An responsibility model would entail
insurances, and that could easily change the situation for the worse.

But it's also important the realize the inherent risk in this. Has anyone
tried to quantify it?

Then there has to be a line drawn somewhere. Holding the keys to Window Update
means a potential botnet. Maybe even being a Debian Developer. That probably
shouldn't carry the same responsibilities.

------
jagermo
I wonder what the goal of these guys is. Several high profile attacks with
little impact, source code and attack vectors leaked, users and vendors
scrambling to set up defenses.

Is this some "look what could happen" scenario or is someone using it to show
off the skills of his other botnet?

~~~
viraptor
Another speculation is that these were very specific attacks. Are there any
online monitoring / logging / audit services that stopped being reported to? I
know that at least the SPF checks failed for emails. Some other infrastructure
could fail too.

------
agnivade
Can someone ELI5 how does malware infect IOT devices ?

The firmware which is there can only be upgraded from the OEM sites right ? So
unless there is a way to affect the firmware from outside, how will a malware
affect it ?

And what can I do to secure an IOT device if I have one ?

~~~
desdiv
The malware hardcodes 62 common username:password pairs like root:12345 [0]
and apparently there are millions of IOT devices out there where these trivial
passwords will get you root.

[0]
[https://github.com/0x27/linux.mirai/blob/6d5a3e2760852444de9...](https://github.com/0x27/linux.mirai/blob/6d5a3e2760852444de9d39b082b06cb7176cd2c1/mirai/bot/scanner.c#L138)

~~~
Pxtl
I think he's asking more about how the attackers get past the simple NAT. I
mean, unless you deliberately expose the device as a webserver to the public
internet, a device should be by-default hidden theoretically unless it goes
_looking_ for trouble online. Of course, considering the quality of most
routers, it's not like the NAT itself is terribly safe.

~~~
jagermo
They don't need to. Millions of devices have their telnet port open to the
Internet (just check Shodan), after infecting those, Mirai has a beach head to
scan and attack the rest of the network.

~~~
marmot777
This is what so few people seem to talk about. Why? I'm baffled.

------
braindead_in
How difficult would it be to write a anti-mirai virus which disables the
remote access on these IoT devices? Or at least warns the user in some way
that this device is being used for DDoS.

~~~
viraptor
Relatively trivial. Mirai didn't prevent future access as far as I know. But
it would be illegal as well.

Warning the users would be much simpler. The hosts used to report infections
are known. Destination port for the infection is known and normally not
exposed.

I think that at this point ISPs should do the same thing with incoming port 23
as they did with outgoing 25. Disable by default, allow people to enable if
they want to.

------
kureikain
I don't understand how they can scan IoT devices if IoT devices are behinds a
router which is usually our home network setup. So we will expose a public IP,
and NAT is usually not enabling by default anyway so how the heck they can
telnet/connect to the IoT devices to brute force password?

It seems like somehow we

~~~
djkrul
UPnP is enabled on lots of routers by default and enables devices and services
behind NAT to forward traffic for specific ports to their internal IP address
to allow direct connections from the internet.

~~~
kureikain
I see. I just check mine and luckily DD-WRT disabled it by default.

------
sigmar
Has anyone seen any estimates of how much economic productivity was lost from
today's DDoS?

~~~
lsh123
Or gained :)

~~~
33degrees
github being down was a big pain for me today, and I'm surely not the only
one...

~~~
tehlike
why? were you trying to fork new repos or just your usual commit/push flow?

~~~
eropple
Downvoting this post is kinda shitty, because it's just obliquely pointing out
something that nearly every developer should already know--that having a
single point of failure for your builds and your tests (the only reason Github
being down should impact you) is a bad, bad idea. Your code should be building
and deploying from git remotes _you_ control, if you want to be using push-as-
build CD. If you have dependencies, bring them in-house on your own
Artifactory, gem server, npm mirror, whatever. Controlling the entirety of
your deployment stack is not just a good idea, it's a _requirement_ for safe
and sane operations.

~~~
otterley
Are you aware of some well-built systems for enabling that? What you're
describing, while simple in concept, is not so simple to set up. There's
tooling to be written and authentication to synchronize.

~~~
eropple
I...just do it? I don't find it to be complex at all. Use one or another
method of user authentication for SSH (I use SSSD, but no solution can be
really universally recommended), launch gitolite (a six line Chef recipe), do
the same for Boxcutter or whatever you need.

I tend to think that the problem isn't complexity, the problem is the current
developer culture being so predicated on _it 's easy, you don't have to
understand things_ that having to understand things borders on anathema. Yes,
doing this does require understanding how your tools work, but that doesn't
make it complex. And you should know anyway.

Or pay me. My rates are reasonable. =)

~~~
otterley
I've been doing this for 20 years now, and little has changed. It's not that
developers don't think they have to understand things; it's that their
incentives are to understand things that are relevant to the problem domains
of the products they are working on. Reliable and efficient deployment
strategies are not usually in their problem domains.

~~~
eropple
They may not have been in their problem domains twenty years ago (though they
were for me from the start, albeit merely fourteen or so years ago =). I think
that the future is obvious and that the expansion of the "stack" to the
underlying runtime infrastructure is a foregone conclusion; this is ignored at
a developer's own peril.

(As it happens, I was a developer first--but I was managing my own
infrastructure, too, and so from a very early age I had to be _damned_
comfortable with doing that. Now the industry is pivoting there as "devops"
becomes more and more of a thing.)

------
speedplane
To get around the DNS attacks, one of the cloud providers I use posted their
IP address to Twitter. Of course, when Twitter is down too, it doesn't help
much.

