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.
I agree. The manufacturer has not only released a device that is defective for its user, but has actually been weaponized against innocent 3rd parties. That goes beyond the normal problems of providing a product to buyers. When manufacturers can actually degrade the quality of the shared space, that's where we go beyond the normal consumer-protection rules and have special regulations like the FCC in the USA or the CRTC in Canada.
While right now the stuff you provide is basically Caveat Emptor, I could see these security problems eventually being taken more seriously by regulators than simple liability.
In that case, who's responsible for keeping the anti-malware software up to date... and paying for it?
Or maybe that's going too far and the first step is to just have them encourage / force more secure passwords.
(Assuming this is correct [1]):
> Mirai functions by infecting IoT devices by trying to brute force their passwords. The tactic it uses to brute force passwords is entering commonly used and default passwords.
The major difference between physical products, and network products, is that the damage caused by most physical products is limited to their immediate vicinity. Network products have no such limits. IOT devices in Calcutta can harm networks in the U.S. That isn't true of a bad lawn-mower or blender. The network operators and ISPs need to step in and do better policing of their networks. This of course, raises other issues but blaming device manufacturers, even if it really is their fault, just wont work.
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.
Didn't we try this same argument already with gun manufacturers? How well did that work?
The problem with holding manufacturers responsible for releasing a potentially dangerous product is that the manufacturers view compliance with regulation as an obstacle to maximizing profits, and seek to avoid it. Manufacturing is also centralized and they organize and lobby politicians to influence regulation.
Consumers are distributed and disorganized, and I predict that blame for not securing your IOT device(s) will stay with consumers for the foreseeable future.
I agree some standardized testing would be a good idea though.
people should start thinking about consumer protection for internet services and internet connected devices. Minimum security standards for products brought to market should be just one aspect of this.
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.
As I understand it, this will do nothing, in these cases, because the traffic is perfectly valid. At least in the case of the "Krebs On Security" blog, the attack was "just" a massive amount of perfectly valid http/https requests. I don't see how the ISP would be able to filter that out.
Before filtering is implemented, it makes sense for ISPs to warn their customers that their hardware was involved in a ddos attack. Analyzing historical data is typically much easier than real-time.
You mean "egress", and that's only helpful in cases where the source is in fact spoofed. With a large and widely distributed number of small devices, there isn't much of a need.
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.
These problems need to be fixed soon or government regulation will come. I think the government would be reluctant to regulate unless it seems like an emergency. If larger attacks happen then the public will call for regulation and politicians will fall over each other to do it. There will be intended and unintended consequences.
He best way to prevent regulation is to eliminate the perceived need. If another attack hits, especially larger and more costly the one last week, people will start getting outraged. Those businesses who lost money might even start lobbying.
I'm not hopeful at this point as I don't even get the feeling that most people have taken the time to understand what happened last week. I see almost mantras people repeat out there outlining mitigation that, white important generally, would not have helped mirigste the attack last Frieay. The solutions offered frequently involve big lag times even if somehow set into motion immediately.
It may be necessary to make some hard trade offs to show some real progress. When people don't freely make hard choices, the government will step in. That would be a preventable tragedy. I don't have much hope at this point.
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.
The EU version of that WiFi regulation also has a clause that while the default firmware for the router can't be allowed to be used for such purposes, users should always be able to install their own firmware.
Which, of course, will result in a worse security posture. Interesting technical ideas can be found in the actual research being done on embedded device security out there. This comes to mind, for example: https://lwn.net/Articles/568943/
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?
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.
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.
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.
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?
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 ?
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.
Sadly the present state of software engineering is mostly incapable of archieving what your reasonable expectation is. Malware can exploit bugs in the devices to get arbitrary code execution (=run any code the attacker wants).
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.
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.
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?
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.
Just do a quick shodan search for port 23, there are millions of devices directly attached to the web.
Some are intentional, but my guess is the most are just badly configured by people not caring for security. Add all the cheap vendors for IoT devices and "I need to be able to check my lights at home while on the road" and you get an amazingly huge attack surface
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.
[+] [-] pmontra|9 years ago|reply
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.
[+] [-] Pxtl|9 years ago|reply
While right now the stuff you provide is basically Caveat Emptor, I could see these security problems eventually being taken more seriously by regulators than simple liability.
[+] [-] tedmiston|9 years ago|reply
Or maybe that's going too far and the first step is to just have them encourage / force more secure passwords.
(Assuming this is correct [1]):
> Mirai functions by infecting IoT devices by trying to brute force their passwords. The tactic it uses to brute force passwords is entering commonly used and default passwords.
[1]: https://en.wikipedia.org/wiki/Mirai_(malware)
[+] [-] speedplane|9 years ago|reply
[+] [-] ComodoHacker|9 years ago|reply
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
[+] [-] tombrossman|9 years ago|reply
The problem with holding manufacturers responsible for releasing a potentially dangerous product is that the manufacturers view compliance with regulation as an obstacle to maximizing profits, and seek to avoid it. Manufacturing is also centralized and they organize and lobby politicians to influence regulation.
Consumers are distributed and disorganized, and I predict that blame for not securing your IOT device(s) will stay with consumers for the foreseeable future.
I agree some standardized testing would be a good idea though.
[+] [-] jvermillard|9 years ago|reply
[+] [-] whatupmiked|9 years ago|reply
[+] [-] Animats|9 years ago|reply
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|9 years ago|reply
https://www.sans.org/reading-room/whitepapers/firewalls/egre...
[+] [-] mrweasel|9 years ago|reply
[+] [-] cft|9 years ago|reply
[+] [-] blackguardx|9 years ago|reply
[+] [-] dgemm|9 years ago|reply
[+] [-] zorked|9 years ago|reply
[+] [-] marmot777|9 years ago|reply
He best way to prevent regulation is to eliminate the perceived need. If another attack hits, especially larger and more costly the one last week, people will start getting outraged. Those businesses who lost money might even start lobbying.
I'm not hopeful at this point as I don't even get the feeling that most people have taken the time to understand what happened last week. I see almost mantras people repeat out there outlining mitigation that, white important generally, would not have helped mirigste the attack last Frieay. The solutions offered frequently involve big lag times even if somehow set into motion immediately.
It may be necessary to make some hard trade offs to show some real progress. When people don't freely make hard choices, the government will step in. That would be a preventable tragedy. I don't have much hope at this point.
[+] [-] idlewords|9 years ago|reply
[+] [-] kuschku|9 years ago|reply
The EU version of that WiFi regulation also has a clause that while the default firmware for the router can't be allowed to be used for such purposes, users should always be able to install their own firmware.
Government regulation can be done effectively.
[+] [-] drvdevd|9 years ago|reply
[+] [-] nodesocket|9 years ago|reply
[+] [-] dmourati|9 years ago|reply
http://hosted.ap.org/dynamic/stories/D/DISRUPTIVE_CYBERATTAC...
[+] [-] dax1928|9 years ago|reply
[+] [-] astrodust|9 years ago|reply
[+] [-] mastazi|9 years ago|reply
[+] [-] archimedespi|9 years ago|reply
[+] [-] jagermo|9 years ago|reply
[+] [-] qb45|9 years ago|reply
[+] [-] Bedon292|9 years ago|reply
[+] [-] xorcist|9 years ago|reply
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|9 years ago|reply
Is this some "look what could happen" scenario or is someone using it to show off the skills of his other botnet?
[+] [-] agnivade|9 years ago|reply
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|9 years ago|reply
[0] https://github.com/0x27/linux.mirai/blob/6d5a3e2760852444de9...
[+] [-] fulafel|9 years ago|reply
[+] [-] braindead_in|9 years ago|reply
[+] [-] viraptor|9 years ago|reply
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|9 years ago|reply
It seems like somehow we
[+] [-] djkrul|9 years ago|reply
[+] [-] jagermo|9 years ago|reply
Some are intentional, but my guess is the most are just badly configured by people not caring for security. Add all the cheap vendors for IoT devices and "I need to be able to check my lights at home while on the road" and you get an amazingly huge attack surface
[+] [-] sigmar|9 years ago|reply
[+] [-] lsh123|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] speedplane|9 years ago|reply