Webcams used to attack Reddit and Twitter recalled
bbc.com
bbc.com
Because the DDOS's costs are borne externally to the consumer, consumers can't really be counted on to mandate security fixes. On the other hand, establishing liability for a company adding to a preexisting botnet through security faults seems tenuous.
One solution seems to be regulation (self or third-party), and it's exciting to see a manufacturer take this issue seriously and start us down the path of self-policing.
[edit: for clarity]
I imagine there were a lot of angry calls from Washington and Beijing over this. I don't think companies are magnanimous like this without external pressure.
>but I think we should also applaud efforts of those who are taking the expensive steps of fixing the problem with no direct incentive to do so.
Applaud what exactly? That all these companies ship devices that happily take IP addresses and go on the public internet or punch through firewalls with upnp and do not force a first-time password change and do not have an auto-updater installed? Even the cheapest Netgear comes with a sticker on the side for a semi-random password instead of shipping everything with 'admin/password.' Or using antiquated and non-encrypted transports like telnet. These 1990's habits need to die and it won't happen because of corporate good graces, because those haven't worked historically. If it happens, it'll happen via external pressure via governments and lawsuits. Market forces are rarely a fix all here.
No one in Washington or Beijing with diplomatic credentials and contact with the other side even knows what DNS is or that there was an attack on Friday.
A lot of Chinese companies are both privately owned and awash in money, and that gives them the latitude to behave in ways that aren't strictly about achieving maximum Pareto efficiency.
These guys are doing the right thing. Please don't try to minimize that.
They have advisors that sure as hell know exactly what is going on here. This is a very naive view of how government works. Diplomates don't need to know what code is to make policy. Chinese bureaucrats certainly know that pissing off their biggest trade and manufacturing partner isn't good for their economy.
This was a very high-profile attack. Pretty much every intelligence agency in the world has notified their higher-ups on what likely happened and the hammer most definitely fell on this company. Chinese businesses aren't exactly known for their good corporate personas and generosity. See baby and dog poisonings and desperate reactions by the government like executing executives. On top of the everyday IP infringements and other cavalier attitudes towards international business norms.
Are you speculating? Do you work in the diplomatic corps? I get the opposite impression given what I've read in wikileaks releases.
This was a very high-profile attack. Pretty much every intelligence agency in the world has notified their higher-ups on what likely happened and the hammer most definitely fell on this company.
Assuming for the moment that there is any communication made at all regarding this incident, do you really think the Chinese government is going to pressure some small Chinese business to lose a whole bunch of money unnecessarily because an American anarchist group attacked some American websites with said Chinese company's webcams?
Nobody cares.
Chinese businesses aren't exactly known for their good corporate personas and generosity.
What an awful generalization.
http://www.nzherald.co.nz/business/news/article.cfm?c_id=3&o...
Or this http://www.foodandwaterwatch.org/news/potentially-unsafe-foo...
Well, try this if you are still not convinced http://lmgtfy.com/?q=china+us+food
What about naked self-interest? Those webcams are vulnerable and can be used to attack any infrastructure, including China's own.
Carrot: labeling/rating system ("our IoT device is A+ security rated, best in class!")
Stick: Devices found part of a botnet and/or DDoS attack are taken offline permanently until cleaned, and/or recall mandated by the governments.
That ought to be enough to improve IoT devices security by about two orders of magnitude from what it is now.
The nice thing about such regulations is that now manufacturers don't have to race to the bottom on costs by not increasing their devices' security and updating them. Because they could win more sales through good rating systems or they could lose much more money through recalls, being shut off from the Internet, and therefore potentially losing customers permanently, and so on.
I'm a believer in "free markets with good baseline standards" for competition, fairness, consumer protection, etc.
I'm not entirely sure how support for updates should be handled, but I think it should be mandated that until at least 80% of your customers stopped using your product, then you are still liable for updating all of them.
So, for instance, if 30% of your customers still use your "smart fridge" 10 years later, then you should still send security updates to it (within 3 months of bug discovery). If after 12 years, only 19% of your customers still use it, then you can stop updating it.
Even then, I worry that 20% of IoT devices could mean potentially billions of devices 15 years from now. And they could still be used by botnets. But hopefully by then the Internet would also be a lot more resilient to DDoS attacks (perhaps by decentralizing it more) and a couple billion IoT devices embedded everywhere into our cities won't represent that much potential DDoS firepower.
EDIT: Whatever made you think this was "voluntary" of Hangzhou Xiongmai? The FBI and likely the DHS and the NSA were investigating this issue. They probably at the very least felt some pressure from them to do this recall. After all, the U.S. government has often been quite decisive on banning Chinese companies from selling in the U.S. because of "national security reasons", so it doesn't seem unlikely that this company feared the same could happen now, too. From that perspective a recall seems cheap.
All hardware should follow basic security principles, it shouldn't be something you can grade on. If there's been an issue then the company should be rightly called out, which seems to have happened in this case.
This isn't perfect (especially if the signature mechanism itself can be exploited; hello attacker-patchable devices) but it's a start.
This is a very thorny problem.
Due to externalized costs that impact more or less the entire population, this is now a political issue. It's exactly as thorny as environmental regulation, or public safety regulation. Should users truly own their cars and have the ability to disable safety features? I think so, but it shouldn't just be a button on the dash. Should they be able to disable emissions features?
I'm not trying to oversimplify here, but I also don't think we should allow the perfect to be the enemy of the good. If there were real incentives to produce secure products, we could expect to see much more investment in secure software, perhaps even verifiable formal methods, and hopefully more industry collaboration/standardization around open source platforms to mitigate risk. It's a tradeoff, but I so often see front-line engineers faced with situations where acting responsibly/ethically with respect to security puts them at odds with management, and that's a clear sign that we're not getting the balance right.
The vast majority of people don't change configuration or even have any idea configuration exists. Taking devices with sophisticated configuration and dumping all responsibility off onto end users simply cannot be the way forward for smart devices. Or we'll live in a world where some 12 year old with internet access can download a script that turns your refrigerator off ruining food; turns your kettle/oven/coffeemaker/toaster oven on burning your house down; and makes you an internet porn star by turning cameras on in your home and streaming the video to who-knows-where.
If everyone is allowed to point the finger at everyone else, nothing will get fixed.
This organization profited from the sale of opaque, unserviceable devices with known flaws. Anyone with a basic understanding of the internet knows a default password is an accident waiting to happen. When will we consider this an unacceptable product defect and mandate that manufacturers be responsible for implementing fixes?
That's the only way we'll see sustained investment in open, vetted architectures and push back against security corner cutting for business reasons.
You might be like, "Well hobbies have to install those images on their hardware." Well what if those projects sold hardware on the side to raise funds? Or a 3rd party sold hardware+software bundles? Who in the chain is liable?
Usually not the case for OSS projects.
Still, I think liability (for either users or manufacurers) is the right answer. If your device is participating in a DDOS, then it is a bad actor and you should pay for that.
As for regulation, I am in favor of the right regulations (which I suspect will be rules about liability). The danger is that we end up with rules forcing particular engineering methods and security certifications.
That will benefit the incumbent companies who already used the official methods, without necessarily improving the software. In fact it would create "standing targets" that will benefit attackers.
After-the-fact liability can't stop a million small users from buying off-brand merchandise and can't stop off-brand merchandise makers from functioning - especially if quality manufacturers add a premium for the liability they face.
It is the responsibility of the IETF and the infrastructure manufacturers.
There is absolutely no way to control the actions of individual devices, nor should there be.
The liability lies with the network itself. Period.
I wonder how that would play into the debate on gun manufacturers being responsible for people shot and car manufacturers for people run over.
It's hard to find a good way to do make a law about this, that doesn't end up taking ownership away from the owners.
In the case of IoT security, it's probably more realistic that we see manufacturers held liable. But in my book owner liability would be fine exactly because it keeps ownership with the owner.
If some DDOS victim can show your camera was pinging them, then he can sue you for 1 cent per ping or something. It's only $200 in total, no big deal. But it will make you ask for more security on your next IoT purchase.
IMO a better metaphor would be to car manufacturers being held responsible for undue environmental degradation, something that does happen to a degree already. (Hello Volkswagen!) The manufacturer should be held responsible for damages to common infrastructure or resources caused by design flaws or deliberately negligent design.
But to use an Internet of Shit device safely, well, I could do it, but I'd have to uncrate a firewall, freshen its software and get it to play nicely with my AT&T U-verse modem/firewall, freshen my knowledge of packet filtering, and then....
This is not my forte, and obviously impossible for the vast majority of people. Instead, to borrow a phrase from RMS/FSF, these defective by design devices need policing, perhaps at a pretty severe level (e.g. requiring stable responsible entities, which could be 3rd parties (should be, actually, since hardware companies are particularly notorious for bad software and security practices), requiring updating capabilities, ISP policing (https://news.ycombinator.com/item?id=12772979), etc.), we need to generally improve the state of the art, etc. etc. etc.
To bring it back to the gun analogy, some basic human factors allowing the rigorous application of 4 rules (https://en.wikipedia.org/wiki/Jeff_Cooper#Firearms_safety) are all that's needed to keep them from causing unintentional harm (and teaching these isn't hard), just sitting in my holster this morning when I went shopping, mine wasn't going to do anything bad as long as I retained it from a bad actor trying to snatch it (and first he'd have to realize I was carrying it).
Whereas all it takes is plugging in an IoS device into the net, following the instructions provided for the consumer, for bad actors to compromise them and cause increasing chaos.
We're in for some interesting times; this furthers my determination to make sure I can be productive with my computer(s) without the net being available, and my recent and very much related to all this decision to not go "paperless" with all my utility etc. accounts.
Best practice is to require your customer to set an initial password before they can even use the device. But to make something labial for missing a potential attack vector seems counterproductive.
The current problems are not that different from computer viruses a decade ago. The problem was only fixed after some major incidents (not that computers are virus free now, but you can install windows and connect it to the internet without having a virus on your device within 5 minutes).
The state of the industry also changes so fast, it's hard to see how regulation could even be relevant.
As for liability, I don't know about fairness, but I think that the isp is really the only entity prepared to deal with this sort of thing on a timely basis. All service providers know the"fix your shit out we un plug you " drill. It flows in both directions, too. Generally speaking, the more you pay, the more warnings and hand holding you get. But the point is that the isp is the first responder here; nobody else is in a position to stop an attack in progress.
Of course, if you make the isp legally liable, fairness aside, internet access will cost rather more.
[0] http://www.costco.com/Samsung-SmartCam-HD-Plus-1080p-Wi-Fi-I...
The lower tech approach means you can park a van in my driveway and probably pick up the signal but that's a lot harder (and more obvious) than scanning an IP range from anywhere in world and finding vulnerable devices.
[1] https://www.amazon.com/Foscam-FBM3501-Wireless-Digital-Monit...
Still pretty weird seeing the constant log entries trying to reach a couple servers - I've been doing traffic capture since I'd like to see what it's trying to do. One is obviously the plug-n-play stuff, but it's crazy that those packets apparently get broadcast outside the network (? - I haven't really looked into how that PnP IP/port is handled but it's getting caught at my firewall).
With Nest, you have to use their "cloud" for it to be fully functional, which to me makes it a no-go for anybody like you who is actually concerned with his/her security/privacy.
The most popular IP camera on Amazon is a Chinese camera gets your Wifi password through their app via the "cloud". Fuck that.
And? What does it matter that someone has a password that's only good for about 100 metres around your house?
Of all the passwords I have, my wifi password is the one I care least about.
I'd be more worried about what the app itself is doing on my phone - I caught one attempting to update outside of the Play Store. No thanks.
If it is Chinese-made, that might just be because the Play Store is blocked by the Great Firewall. Apps in China need to use some other way to update.
Admittedly, it's a far cry from an Off-the-Shelf solution though.
"Security issues are a problem facing all mankind," it said. "Since industry giants have experienced them, Xiongmai is not afraid to experience them once, too."
The fact that they aren't scared of having brain-dead security failures in their products is, to put it lightly, telling.
EVERY device on the Internet is vulnerable, and it makes no difference to Dyn DNS where it was manufactured or how long it had been running without an update.
Zero Day Exploits are real!
Wake up!
Shall I give you a couple of hundred comments for ammunition.
On the other hand, if you disagree with my perspective, man up and present an alternate perspective.
How is that?
The thing is, I'm seriously concerned about the rhetoric on this thread. There seems to be a general bias toward legislative action and I know it isn't going to go well if that's the way things turn.
My reaction against down votes is pure frustration though. Down votes are a dead end.
I think I'll go back to my happy place...
curl ... | sh
I doubt there's much overlap between the two groups of people.
I'm afraid that you would find the number of people who failed to consider blackbox internet appliances as attack vectors to be disappointingly large.
Luckily, I already had a paranoid router setup, so I think I'm probably okay.
That said, I wouldn't be terribly surprised to see a fair bit of overlap.
Linux does essentially the same thing with GPG signatures instead.
That isn't to say that it isn't the product of a targeted trojan signed with a stolen GPG key.
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
Almost no one actually audits the source they download before they run it, whether it be a package installer, a configure/make/make-install tarball, or a curl|sh.
If you know enough to audit a shellscript, you can easily decompose the command-line to download, audit, and run the local copy.
For the vast majority that chooses to simply trust the author, there is no additional security issue with curl|sh compared to other non-signed distribution methods provided the script is wrapped in a function call or otherwise resistant to errors that might happen if a partial download is executed.
Should we do better than curl|sh? Yes. But it's no worse than downloading some random tarball or even cloning some random git repository, as long as it's served over HTTPS.
Thats not the security issue here, its effectively running build-time logic during install-time, on every bodies machine at every install, instead of at package maintainers secure build system, once, and having the installation basically be an unpack instruction.
Another negative point of curl | bash, is you assume your users are idiots who do not know their OS package manager well enough to run apt-get install shitpackage pacman -S shitpackage or apk add shitpackage.
Absolutely, but packaging for all major distributions can be a larger headache than writing the project in the first place. For a lot of small projects, this isn't justifiable.
Edit: I cooked up an example actually. Here is a small Go program that will panic after 1 nanosecond: https://gist.github.com/kyleterry/dc304503dfca2d149b189694d1...
This will sometimes return partial responses.
Run this in a bash `while true` loop and curl localhost:8080 a few times. You will mostly see empty and full responses because my example isn't perfect, but occasionally you will only get part of the script dumped to the screen and that's the problem with curl|bash.
function f {
echo "hello world"
}
fIve yet to see a "curl https://thisshit.net/trust/us/really/we/have/https | bash" script which didnt fail for whatever dumb reason, such as only working on specific variants of Ubuntu, with specific packages installed in specific version, and/or RedHat.
Usually these shit scripts fail when trying them out, for curiosity, in ArchLinux, Gentoo or Alpine Linux.
Sandstorm.io looking at you.
If you are already going to invest in making "an install script" with defined/researched which packages/versions with which your software needs, for various platforms - submit this data to that platform as an debian/{control,etc} to make a .deb or specfile for .rpm or PKGBUILD or whatever, and use the platforms _build tools_ to generate a platform specific package - be a package mantainer if you have to.
Another side effect of telling your users to curl | bash, is I wont ever use your software. You didnt make the effort to do the right thing with packaging, why would you have done any better for whatever it is youre trying to do with your shit software? (sandstorm again).
When I have to install packages from source, I have a more secure/locked down linux container, with seccomp applied, dropped capabilities etc, then if I intend to use the the software over longer time, and expect updates, I skim the source and build-system quality, quickly write a PKGBUILD or APKBUILD, build it, install it into its own new container - with iptables filtering outgoing connections, and thats it, sometimes submit the APKBUILD to alpine testing or aur.
And all this is easier than curl | bash oh watch it fail for dumb reason in the install script - and I did try that, the time spent troubleshooting the install script is longer than time to sandbox the whole thing as described above.
So, if I can do it, why cant the project? Why spend their efforts on writing an install script instead of package-build instructions to various distributions?
(I am a Sandstorm fan, but I don't have it installed because it wants me to flip some sysctl about user namespaces or something, and I don't currently have a separate machine to do that on)
FWIW, this is no longer needed! Sandstorm has been updated to work without user namespaces and this installer script change will remove the check from the installer (will probably ship this week):
https://github.com/sandstorm-io/sandstorm/pull/2656
(You will need to let Sandstorm start as root if you don't want to flip the sysctl, though.)
Joke of today, thanks for the laugh.
If it's a single-user machine, any process running at any privilege level can trivially get root by editing ~/.bashrc and aliasing the sudo command.
I dont even have sudo, let alone if I had it, I wouldnt use its dumb caching of credentials/session or "ask no password" "feature".
Just because my system is single-user doesnt mean I run every process with that one user, in fact I run firefox as its own user, chrome has its own, mpd as its own user, nginx is its own user and so on. This is basic security practice.
If you seriously think that it is so easy to get root just because you can run a process as a normal user - "by aliasing sudo command", then by all means run everything as root, whats the harm or big deal, right? Why do you even have a user which is non-root?
Why cant sandstorm run like lighttpd or nginx - as their own user, requiring no capabilites, in fact even syscalls can be revoked from them with seccomp and they will still work fine. All they need is socket api, file system api ( open close create), and some others, no they dont need to load kernel modules, ptrace or open_file_handle_at and so on.
Sandstorm works exactly the same way.
nginx can run as completely non-root, if you are OK with high-numbered ports.
Sandstorm can too, if you are OK with high-numbered ports and if unprivileged user namespaces are enabled.
(It sounds like you actually use UID separation for security on a desktop. That's cool, although keep in mind that if everything is talking to the same X server, then UID separation probably doesn't help much. If you're serious about this approach you should probably be using QubesOS.)
Projects that recommend piping curl to bash are trying to dumb down the process, and they have a tendency to make too many assumptions about the system it'll be running on.
such as only working on specific variants of Ubuntu,
with specific packages installed in specific version,
and/or RedHat
submit this data to that platform as an
debian/{control,etc} to make a .deb or specfile for
.rpm or PKGBUILD or whatever, and use the platforms
_build tools_ to generate a platform specific package
- be a package mantainer if you have to
Another side effect of telling your users to curl | bash,
is I wont ever use your software. You didnt make the
effort to do the right thing with packaging, why would
you have done any better for whatever it is youre trying
to do with your shit software?
[1] https://developers.google.com/speed/pagespeed/module/build_n...
So you dirty the system where its supposed to be installed, a server, with gcc, make and friends?
> . If you're running something else it prints out "This doesn't appea
State so on your documentation/page before telling the user curl | bash, as I wrote in another post here, that is nice.
Your script does not support transactionional installations, as it is it can break at any point in the script and leave the target system broken/dirty. With a simple PKGBUILD youd also have solved the "binary ABI" part. If it really is tedious to coordinate with several distros, you can take a shortcut and dont deliver a "pkgspeed-for_nginx_module-1.2.3@v1.2" package but instead a "pkgspeed-1.2.3" which conflicts with the normal nginx package and thats it.
So you dirty the system where its supposed to be
installed, a server, with gcc, make and friends?
State so on your documentation/page before telling the
user curl | bash
Your script does not support transactional
installations, as it is it can break at any point
in the script leave the target system broken/dirty
No. That is not how nginx is traditionally installed.
You misunderstand basic Linux package management and build systems, which is why you end up in this mess. But thats okay, world is keepin on spinnin. To each their own.
> Sandstorm.io looking at you.
That's hardly fair, since the reason the Sandstorm installer fails on Arch is because it explicitly checks for the presence of a required kernel feature, and Arch explicitly doesn't have that feature. The installer script fails intentionally because of the missing feature, not because it is badly written. Shipping an Arch package wouldn't have magically made Sandstorm be able to work without the required kernel features. OTOH, if you build a custom kernel that has the necessary features, the Sandstorm installer will run just fine on Arch.
(Coincidentally, we plan to lift this restriction this week, as we recently implemented an alternate sandbox design which doesn't require this feature.)
In any case, I doubt your sandbox today would work in my sandbox.
That is kind of the point, why cant you ship an application which runs as a normal user only, why do you require root for everything and assume your sandstorm will be the machine-manager? Last time I tried, you actually recommended curl shit | sudo bash. sudo! Nevermind I hate sudo and dont have it.
If you need sudo, take it/ask for it, specifically for that 1 operation, not for whole install script. Maybe thats how its done today?
No it wasn't. The install script ran a little program that actually attempted to invoke the system call to see if it failed:
https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150...
We have never relied on /etc/lsb-release nor /proc/config.
> why cant you ship an application which runs as a normal user only
First, we're not shipping an application, we're shipping an application platform which includes a container engine.
On systems that have unprivileged user namespaces available, you actually can install and run Sandstorm as a regular user -- no root privileges at all.
Unfortunately, Arch explicitly turns off user namespaces in their kernel build.
Without user namespaces, we have no choice but to require root privileges, because the Linux system calls for setting up containers require either root or user namespaces. (Note that Sandstorm is careful with its root privs -- most of the system runs as a regular user, calling out to a separate daemon for the specific operations that need root.)
If you don't want to give Sandstorm root -- which is perfectly understandable -- and you don't want to enable the kernel features that allow it to be non-root, then you'll need to run it in a dedicated VM.
> Last time I tried, you actually recommended curl shit | sudo bash.
We have never recommended that.
If your GPG signature is in your keychain, it's safer anyway.
HTTPS by itself does not protect against malicious content or malicious actors (DigiNotar, TurkTrust, GCHQ, ...)
That you may unwittingly opening up your machine to vulnerabilities.
Most sophisticated people won't execute remote scripts from untrusted sources, but as more people switch to unix-like operating systems, they may have as much scrutiny.
A designer on my team was given a mac, and if a script failed to run locally, he would immediately re-run the script using `sudo.` I can't imagine he was the only person to use this solution.
Sometimes IT department just google random instructions from the interweb. Some of them include really outdated security practice
THE MOST POPULAR CURL DOWNLOAD – BY A MALWAREIt's almost poetic that the IoT devices in question are remote-controllable webcams, since constant surveillance is the other symbol of a dystopian Big Brother society.
Because remote management, and the default state is to have everything opened up to facilitate pain-free setup and config.
Not that this in any way absolves the OEM for the utter idiocy of including the telnet port in their forwards at all and the absolute negligence of having it active by default and 'secured' by a single or small combination of well known auth tuples.
But yeah, that's really what they did. Here's the section of Mirai's scanner.c that sets up the destination port. [1]
// Set up TCP header
tcph->dest = htons(23);
tcph->source = source_port;
tcph->doff = 5;
tcph->window = rand_next() & 0xffff;
tcph->syn = TRUE;
[0] https://www.us-cert.gov/ncas/alerts/TA16-288A
[1] https://github.com/jgamblin/Mirai-Source-Code/blob/master/mi...
(Matthew is an absolute expert at breaking into cheap IoT devices)
I like the idea of UL testing for at least basic security vulnerabilities.
Vulnerabilities are often trivial in hindsight and lost in a massive forest up until the moment they are serendipitously discovered.
I'm not saying a proper audit shouldn't have found this and flagged it. But yes, agree strongly, vulnerabilities can be surprisingly hard to find.
I see it as analogous to FCC certification of RF related equipment.
This does a few things.
1. Secures endpoints down 2. Chains users to company 3. Makes cloners hard to copy product, given server based logic
Hell, Google and Microsoft can't even bother to keep up products or their DRM up for any length of time. But again, users are willing to rent chained devices like the Nest.
Instead, how about ISP supplied modems/routers have sensible defaults(and have the admin password reset)?
Much more cost effective.
Thee is no way these horses can be put back into the barn, there are too many of them. As long as consumers make their decision based on price there is every incentive for the manufacturers to continue cutting corners - the ones that put extra work into security will be at disadvantage compared to those playing fast and lose.
Can we talk about BGP flowspec instead? Filtering offensive traffic early and often can end DDoS once and for all.
What about spoofing? Until broadband providers get serious about BCP 38, this is just cat and mouse.
https://www.amazon.com/Surveillance-Infrared-Recording-Wirel...
If you sort by the seller there you can see they make dashcams and webcams.
First of all, IoT devices really need to be connected on isolated vlans with very strictly controlled WAN capabilities. Obviously this already exists, but not in the fashion a layman, who wants to put their fridge on the wifi will understand. The average home routers need cleaner interfaces and clearer abstractions rather than the cruft that exists now.
Does your fridge really need to access the internet, and if it does, perhaps you could setup your router to only allow access at certain times, to a single host and with circuit breaker protections in case traffic has a signature that matches that of a DDoS attack. This circuit breaker pattern could be extended to all traffic running through the router, and provide the user with reports of potential infected devices and traffic hungry users.
There is absolutely no way that we can protect all devices on the internet from being bots, etc. Just as it is almost pointless blaming hackers when in most cases the hacks were because breeches from failure to update software, to put in proper security software, and to hire top level consultants to implement secure systems.
Put another way, we can't possibly jail everyone who would want to steal money. That is why we use safes.
Poetic justice.
Maybe I'm too cynical, but from what I know about the NSA and other three letter US Government agencies, I beg to differ.
Additionally, good luck finding any type of electronic device that is entirely made in the USA. I honestly can't think of anything with a printed circuit board that is assembled in the USA from 100% American-made parts.
Then of course there's always the whole engineers taking shortcuts to meet unrealistic deadlines thing. Somehow network security tends to be very low on the list of priorities when you have to make a profit.
Now, if you can show me that the same manufacturers make cameras for China's internal use that are fully secured, that would make me change my mind. But based on the occasional "trips to Chinese tech bazaar" reports we see here sometimes, I'd be surprised.
(On a similar note, in my political blog reading I saw a lot of paranoia that the DDoSes last week were somehow motivated by name-your-choice of political actor. However, per what we are discussing right now, we don't need to hypothesize that. It is completely plausible that criminals have come into possession of that much power. The trendlines have been clear for a while; we've been getting DDoSes ~25% larger than the largest one ever recorded about every ~three months for a long time now, and most of them do not seem to be state actors. Just because they're out to get you doesn't mean that it may not be paranoia, to invert a famous quote.)
Why isn't there a uber secure OS written in a high level language that would prevent easy privilege escalations, vulnerabilities caused by buffer overruns etc?
It would be nice to have a standard security approving body (like FCC) that gives out graded standards.
It is like every generation forgets the mistakes of the past and repeats them. When $5 Raspberry Pi is powerful enough to run desktop OS, I see no reason to not adopt a high-level language that prevents basic security violations at the roots.
The UCC provides an implied warranty for suitability for intended purpose. The FTC defines unfair and deceptive business practices to require a baseline level of security commensurate with the sensitivity of the data that could be exposed or the potential damages that can be inflicted. As in most cases, new laws tend to make things worse, we just need to do better with the old laws.
It's not that it's illegal to sell someone a Io(S)T device that can be owned for running a DDoS, but I am willing to bet it is illegal or at least creates significant liability for the manufacturer to sell such a device that also has no way to be fixed after that flaw is discovered.
What would be nice is a simple industry standard labeling that indicates a device has auto-update functionality, along with a large numeral indicating the number of years from date of purchase that updates will be provided. The same decal could be used on computers, phones, routers, and IoT.
Just like we trained consumers to look for the WiFi Alliance logo to know the router or card they are buying will "just work" I think we are missing a label which would drive consumer confidence and encourage good behavior by the manufacturers.
Probably an industry consortium already exists for something like this, but I just haven't heard of it... Because there's no such thing as a new idea, right?
Who could you hold responsible? The user for not setting a password or the manufacturer for accidentally creating a backdoor? Neither is really reasonable nor feasible. Filtering the attack is also extremely hard due to the scale of distribution.
Will this lead to a more locked down internet?
One would hope best practices don't have to be turned into laws (because they quickly become outdated and are easily miss-applied), but there is going to be a push to do that.
That's obvious - nobody wants to be blamed for its own ignorance and then if at the same time you can make money on it, the law is just a matter of time, especially in the left wing climate supporting bureaucracy and over regulation and eventually making people more ignorant and irresponsible. Vicious circle.
The proposal I like best is that the industry should get out in front of this, and build a self-regulator organization now which issues recommendations and certifications of Internet-connected products. Then governments could simply require compliance with the industry norms, established and vetted by the industry, and we can keep political institutions out of micromanaging the electronics industry.
The model to follow here is Underwriters Laboratory, which sets standards and grants certifications for electrical and industrial supplies and equipment. Then, for example, city governments can just specify that everyone installing, say, outdoor lighting at their home must purchase lights and outlets rated for wet outdoor usage by the UL.
What's all this crap about simple fun web cameras as "Bad Actors"... In fact the use of the term "Actor" as applied to a pretty dumb piece of electronics is pretty creepy in itself. What are we trying to do here?
The term "State Actor" is fairly new in terms of popular usage. Thanks to CNN and media, we are being trained to know this word in a particular context.
Now, we are being trained to place dumb pieces of electronics in the same bucket as Russia and China. LOL
I'm sure there wasn't a meeting where the camera manufacturer execs set around a table and said let's make these things blow up the world.
And you know, even if there was, the shame lies on the fact that we don't have better edge level security that can detect and shut down abnormal traffic patterns close to source.
There is some fairly low hanging fruit here. Routers and gateways with pretty damn simple algorithms could detect and prevent these types of attacks if they were available.
The network should protect itself against "Bad Actors", because... trillions of devices are a coming, and we can't expect them all to be certified to protect the network. The concept itself is completely absurd.
Fat better to improve the infrastructure than to impose per device level policies. It's the IETF that needs to step up. Not the guys in a garage who couldn't code.
Sure maybe they could have done a better job, but from the level of programming we are currently at it is an absolute certainty that this will happen again whether we like it or not.
Everyone who's been affected by the DDOS. Manufacturers are responsible for the security of their devices. If you ship something that's vulnerable, it's you to fix it. If there are damages, those come out of your pocket.
> It's the IETF that needs to step up. Not the guys in a garage who couldn't code.
No. If you're a guy in a garage who can't code, you shouldn't be writing code, let alone shipping devices.
Are you for real, or some kind of astroturf account?
I am not sure it's that simple really. the whole point of ddos is that it's distributed so that each node doesn't need to do a whole lot of traffic(and filtering out the traffic at the other side is really hard because of the distributed nature of it).
the main reason this stuff happens is that security is not a feature that most people care about and won't pay for it because they are ignorant of how the system works. The managers decide not to make security a priority.
I can't understand why people are calling for regulations on IoT devices. Instead, how about ISP supplied modems/routers have sensible defaults(and have the admin password reset).
Much more cost effective.
Regulating IoT is going to be impossible when tiny little devices can be shipped undeclared. Even if it could be policed effectively it would destroy the economics of some of these cheaper devices.
However, these being used for a DDoS attack puts a spotlight on the issue. While I don't know the solution, I feel it will become harder for manufacturers to shrug this off.
I could do with some for a farm project at the moment, but as far as I can tell, they're uniformly awful. Are there any that are reflashable with something more respectable, even?
Ideally what I want is a video stream over TCP with power-over-ethernet support - and no other services.
https://www.shodan.io/search?query=rompager http://www.pcworld.com/article/2861232/vulnerability-in-embe...
http://www.forbes.com/sites/aarontilley/2015/07/21/whats-the...
What's wrong with this approach? Imagine the PR disaster if this DDoS attack was caused by HomeKit devices.
As a potential future user of HomeKit it's reassuring to know security is a real concern here. I'm glad I won't have to probe the device to check it isn't running a telnet server with no root password, for example.
When we're talking about an internet-connected camera or a front door lock, yeah I'm going to want high standards for security. If that slows down HK adoption so be it. If I wanted a convenient-but-insecure lock compatible with my existing devices today I'd just leave my door unlocked.
"You must just apply and meet certain standards" - your factory also needs to apply and meet standards, not just you. we work with a fantastic factory that builds high quality products (numerous baby and toy products) and is large (>45K employees). they aren't mfi certification (its not just meeting standards, its an application process that costs time and money).
The benefit is you have access to a huge market (iOS users). - we already have access to this market. The main thing is slapping a little homekit badge on the packaging and slightly tigher integration with siri.
agreed with you that nobody wants to be at fault for taking down the internet due to bad security on their devices, but its a bit misleading to suggest that apple's approach is a good way to do it.
whats fundamentally wrong with it is the cost it imposes onto companies making something compatible with their ecosystem. I don't want to add a few dollars to my BOM so that I can further help their ecosystem. I also don't like the closedness but I understand that is apple's general approach. I want to have open APIs and cloud integrations. Radio/hardware level integrations are fine but given the giant mess that is IoT radio standards, I would rather just integrate via https.
For perspective on how this makes it down market:
Lets say I want to make a Thread compatible device and a homekit compatible device. I have now likely added 4-8USD to my BOM. Typical multipliers from BOM to retail are 3-5X or more so we could have just added 32 usd to our price. Or we could have just done a cloud integration and used the wifi or bluetooth chipset we were going to use anyways...
>The main thing is slapping a little homekit badge on the packaging and slightly tigher integration with siri.
It's integration into the entire HomeKit platform including the new Home app across multiple devices.
Thanks for the in depth numbers. Personally I'd pay an extra $20 for something HomeKit compatible, especially if I'm paying $150+ anyway. I've been looking at some devices lately and haven't even considered anything which doesn't integrate with HomeKit.
You can't un-ring this bell, and it might actually be harmful to try. A free and open Internet is more important than DDoS attacks.
A hardware recall seems silly when it's clearly a software issue. Unless they didn't include any firmware updating system... which is likely the elephant in the room not being addressed with most insecure IoT devices. Android faced this problem as well and has recently made progress addressing it. Although a lot of phone companies get in the way and manufacturers have very short support lifespans.
Edit: Better? "Webcams used to attack a DNS provider recalled."
If I setup a raspberry pi with camera and there are exploitable bugs in the software is the creator of the software liable? Does every piece of software open source and closed source need to be approved by a regulation body before your allowed to run it? Distribute it? Put it on GitHub?
There's nothing unique about IoT devices. They're just computers. If you regulate one you arguably have to regulate the other
Yes, digital/software is inherently less tangible and trickier to regulate than a physical product sold at smaller volumes, but we need to start somewhere. Poorly made digital+connected products distributed in large volumes can have tremendous impact to the world population.
We've no idea if there are others out there who attack these devices and subvert the firmware too.
I think it's kind of troubling that "the vast variety of information services that comprise the internet" apparently means "Reddit, Twitter, and Facebook" to laymen now.
The courage to try something new. Oh wait it isn't new, this is being a copycat.
Except it's not. They can't touch me, hurt me physically, take things away. All they can do is see me.
So what they see some guy in front of a computer. I'm more worried about the hacks that can take over my keyboard, and can access financial data. But even then it's the banks problem and insurance that will take care of it.
1. Any device with internet access must be able to automatically update all its software.
2. Because a manufacturer can either go out of business (some devices are used for >10 years) or not care about its users, all its software must be open source. A code, which needs to be secret, can be stored on a hardware level.
3. But if a software is open source, it doesn't mean there would be people who'll fix the bugs, therefore there should be the list of OSes approved (by a regulator and EFF?) to be used on IoT-devices. The development of these OSes should be public (on GitHub, etc.). By having ~10 different OSes instead of a million, solving bugs would be possible and much easier.
4. By having such list of approved OSes, we also solve the problem of having a vulnerabilities in the updating process, e.g. missing signatures, using RSA-1024 or even RSA-512 for signatures.
5. By having such list of approved OSes, it'll be easy to maintain the live kernel patching service (in the future it'll be hard to imagine an OS without it).
6. By having such list of approved OSes, community would quickly fix the problem of using default passwords.
Without such law, expect 10 Tbit/s attacks in a year, and >500 Tbit/s attack in 2022 (if popularity of IoT would increase as fast as mobile phones did).