Say Cheese: a snapshot of the massive DDoS attacks coming from IoT cameras
blog.cloudflare.com
blog.cloudflare.com
IoT is a security disaster
I hate to suggest things like this but we may need legal remedies to solve the problem before it becomes an Internet Zombie Armageddon (IZA). It's that bad.
There's going to be tens of billions of IoT devices installed at businesses and homes in just a few short years. If they're not receiving regular, timely security updates the Internet as we know it may just plain collapse from the sheer weight of all the zombies.
I propose a mandatory "nutrition label" of sorts for IoT device packaging. Something like this:
* Updates itself regularly
* Conforms to NIST security standards
* Public penetration test results: https://ptr.iot.nist.gov/A2L7P9D23345
* Shares data with 3rd party: No
* Administration by vendor: No
* Requires Internet connection to administer: No
* Requires 3rd party service to function: No
* Notifies of intrusion: Yes
* Logs all access: Yes
* Encrypts all network traffic: Yes
As a bit of an analogy, while I may enjoy poring over computer system security details, I'm pretty novice at a lot of more real-world things. Yesterday I was buying a new dryer exhaust hose. I read some reviews online, and looked at boxes in the store. I managed to learn enough to realize I wanted an all-metal construction so it wouldn't catch on fire. But I really wanted some big shiny signal to let me know "HEY YES IF YOU HAVE NO IDEA WHAT YOU'RE DOING, BUY THIS ONE!"...
The only answer is to fix the Internet to make DDOS harder and less effective. Implementing standards to block IP spoofing is a start since it would make source quench actually work.
Another not mutually exclusive answer is decentralization. DDOS works because you can use it to take down all but the largest central servers or those that don't buy protection. But if apps are decentralized, an attacker can only play whack a mole with individual endpoints to far less effect. If decentralized protocols do mobility well victims could just switch connections or their ISPs could react by rotating IPs.
Food labeling requirements haven't lead to monopoly control over food. Why would IoT labeling be different?
Don't get me wrong, I'm cynical too! The lobbyists that control our legislators with purse strings will most certainly do everything in their power to ensure any such labeling only makes things better for their corporate overlords! I just think, "what's good for corporate overlords" is actually good for everyone in this case.
I would expect VC-funded businesses to reject any such, "Requires 3rd party service to function" label since they're all about locking customers in with "network effects". I would also expect established, old-school businesses like Microsoft to reject any label that would identify a product as "open source".
...but what corporate overlord is going to object to labeling like, "Regularly updates itself"? That's something that's cheap for them to do but can be expensive for upstart competitors.
There's much to be gained and almost nothing to be lost with labeling IoT devices.
You don't need to know what they all mean, you only need to know what the ones you care about mean.
If I put my consumer/layperson hat on for a moment...Even if there is no government mandate to add this type of "label" to these IoT products, if I see 2 comparable products side-by-side on a shelf (or ecommerce website), but one has this "label/label info", and one lacks it, I would definitely purchase the one which HAS the label.
SECURITY INFO
<QR Code Here>
https://some.thirdparty.org/info/ABC123456789
I've also been warning governments about how bad things are and how bad things are going to be. I can see some movement, but it is too slow. We need more mandatory, automated penetration testing of all corporations by regulation. We also need cyber army reserves to help bring some of the knowledge that we have in the private sector to our governments without having to work in a shitty beige office downtown Ottawa.
A bunch of Teslas hacked at the same time is a weapon of mass destruction. We need to recognize that we have weapons of mass destruction online and take countermeasures now so we don't wake up one day to the news that 20 million cars accelerated to 200km/h and crashed into gas plants and government buildings all around the country. We need to regulate industry so the "move fast and break things" doesn't actually move fast and break things.
Daemon[1] was a fun read, but I have no desire to see it become reality.
No thank you, there be dragons there. Before you know it that regulation leaks to all software development that includes calls to connect() or bind().
But an Underwriters Laboratory for pen testing? Yes, please. (Or even UL themselves!) I saw an article on HN within the last 12-18 months about a similar concept/security auditing.
For example: You can't sell phones that explode. You can sell phones that are cheaper than the competition.
Likewise the FCC is very particular about radio emissions and will outright reject your product if it's too noisy.
We absolutely need something that can handle obvious problems like this, plus a way of coordinating with the vendors of these products should a vulnerability emerge that requires a patch or a recall.
That's only really recently true--just ask a ham radio guy about the noise floor if you want an earful. The FCC was pretty lax about this until this year when they finally quit accepting cross-certification from emissions labs from countries like China.
So, don't worry about it.
The post above was publicly broadcast in hopes that the person who makes the decision reads HN, not because it is expected that the common everyday Joe reader will do something about it.
Creating embedded systems that won't be updated and live indefinitely is knowingly creating a hazard and nuisance to society.
This seems like it would give free range to sell shitty devices that are obsolete the moment they come out of packaging - or worse, that brick themselves on a timer for supposed security purposes (think HP ink cartridges.)
The solution for most devices is to simply keep them off the internet. Being a host on the internet requires some level of care and maintenance so you don't become a hazard to others. I doubt most light-bulbs or thermostats are worth the ongoing expenses of maintaining security updates into the indefinite future. In theory, traditional goods that last more than a few years should be more successful on the market than self-destructing devices with dubious internet features.
Now perhaps some good recycling laws would combat abuses of such an effect.
[0] And a pretty strong argument against "forever" IoT devices.
That is, if router manufacturers could also keep their crap safe...
If you don't trust an off the shelf router for this, you could also use a computer setup as a router with such relaying software. It would be as simple as running a dhcp server or something.
Routers could also default to denying any authentication from WAN, with the user changing this policy on a per device basis or just allow eveything.
So when do you want me to turn off your colored LED light bulbs you bought? Yeah, thought so.
I assure you I have not (and never will) purchase any "internet enabled" (or "smart") device. Most devices worked just fine without a network interface.
To turn off my (standard) LED light bulbs, use the switch on the wall.
so your first point, automatically updates, implies your fifth point, administered by vendor, should be "yes". (Not "no", as you've put it.)
Further, I would like you to think more broadly about infrastructure. I think every person's home should have a local network called "shitty backdoored and malicious IoT crap". The question is how to administer that network, what its topology should be, how these devices should be able to receive information from the Internet, and in general what their capabilities should be and the way in which they should be firewalled off.
Having these devices on users' home wifi via their home router (the status quo) is obviously wrong and insufficient. I'm afraid your checklist is also, therefore, wrong and insufficient.
so, think harder at the architectural level, please. the existence of IoT stuff is obviously good. (as in, obviously there can be a benefit to devices being able to be connected - in the abstract, not based on today's very flawed infrastructural and architectural choices) the infrastructure we have for it today is obviously insufficient. I don't have a comprehensive solution in mind or anything but it is worth giving serious attention to by people who have spent years on the subject.
today, they are failing. It's not that people are ignoring their advice: they just don't have any. They've thrown up their hands and given lists like yours, which are not a comprehensive solution and are not even internally consistent. They need to think outside the box and propose completely new infrastructure.
there needs to be different infrastructure in place, not an SOP for the current infrastructure. we need better security baked into the topology and architecture of how the devices are connected.
Then why are you putting it on the internet?!
Either you create devices that are secure - which may include things that neither the manufacturer or the user want to do - or you shouldn't be putting it on the internet.
> I think every person's home should have a local network called "shitty backdoored and malicious IoT crap".
Relying on border security is a terrible idea. A firewall is not an excuse to ignore host security.
pretty sure we can at least agree that all IoT choices available to users and manufacturers today are hugely problematic for one or both of these parties.
No, I don't expect anyone to be asked to update. I expect it to work just like Chromecast devices do: It updates in the background while in operation and applies that update at the next reboot. If idle for long enough it'll reboot itself (usually in the middle of the night when no one is expected to use it).
Self-update mechanisms aren't rocket science. In fact, there's so many FREE options to choose from at this point you can just take your pick. Don't need to code anything on your own!
By neglecting to update devices you increase risk by ensuring vulnerabilities won't get fixed. You also might not get notified in the event of product recalls (if you never registered your purchase).
I understand your argument though: By solving one security issue we're creating another: Trusting the vendor. To that I have this to say...
If you don't trust the vendor why did you buy their product in the first place!?
- http://www.theverge.com/2016/4/4/11362928/google-nest-revolv-shutdown-smart-home-products
- https://nest.com/support/article/Nest-Protect-SafetyI doubt we can solve this problem legal way because all economic forces are against us.
Making a product secure costs many times more than making a product itself. "Regular security updates" is a nightmare to vendors. Nobody actually does it, especially on consumer market. Vendors react to massively exploited vulnerabilities at best. Any long-term maintenance, including security, simply don't fit into current business models.
And people want cheap products, they don't want secure products. Government contractors want super cheap products (with support but this doesn't change much). And education/propaganda won't change that until some big disaster happen.
SSL Labs' HTTPS ratings work because the developer of the test is also constantly tweaking and optimizing for current "best practices", and the ratings are not too far off from what the sites should be rated at in terms of HTTPS security.
http://www.euractiv.com/section/innovation-industry/news/com...
Do not plug your "things" on the Internet unless there's a serious gain from it!
This solves most of the problem. The rest will only get solved by free software, and if the government should mandate anything, it is that the software can be managed by the user, not a laundry list of warnings that will mean nothing in practice.
(By the way, that "conforms to NIST security standards" is intended as a "yes" mean "bad" kind of warning, right?)
Why not? It's kind of a tragedy-of-the-commons situation.
I gain a fancy lightbulb that can change colors when I play with my phone. Do I, personally, really care if that lightbulb is part of a botnet that's beating someone's website into submission? Statistically, it's unlikely to affect me, so it's all gain for no cost beyond paying for the bulb.
Do you care about thieves checking your lights from anywhere on the city? And what about your lights launching attacks against your other computers?
Well, this article (and discussion) is mostly about these devices being sources of DDOS attacks.
> And what about your lights launching attacks against your other computers?
I thought my comment was pretty explicitly clear that most people would not care at all, even if they knew.
That said, them being connected to the internet isn't an issue itself. Make all your IoT devices connect through one central gateway (in your house) that controls all of them and suddenly instead of 20 devices broadcasting on the internet you have a single entry point. Obviously this entry point would be the target of many, many attacks, but securing this one gateway (that would be easier to update than your lightbulb.) is much less of a complicated task than securing all twenty.
That current abilities to do so, in the U.S. are arbitrated by the Library of Congress, seems entirely insufficient. Except that it perhaps gained us some temporary rights to do so that corporate lobbyists via Congress would otherwise already have taken away.
This tech has become essential to society. Intellectual property "rights" need to find their limits at a point before they put this essential function at risk. If the original manufacturers can't get this right, and where the underlying chipset technologies are from what strikes me as an oligopoly -- regardless of the number of brands and models they get stuffed into -- then the public should have every right to research, verify, and fix the products, themselves.
Ultimately and hopefully, this also works, financially. If you can't make it work properly, you lose control of your revenue stream, rather than using a government-granted monopoly (IP) and your income on lawyers and lobbyists to coerce people to suffer with your failure.
And when you would flip that switch, anyway? Wouldn't it make more sense to control this from your router? Something like changing the wifi password or network name would work even better (assuming you control the router.)
Maybe someone should start enforcing mandatory VPNs for households? I.e. I get you want to control your LED bulbs from your phone, but that doesn't imply they should be accessible from public Internet.
Also I wonder if the whole thing isn't just a symptom of a problem that we can no longer expand connected technologies while expecting zero knowledge from end users. Maybe it's about time to require some minimum amount of computer knowledge from citizens of a technological civilization?
You don't even need a VPN, just have the device only accept connections from local IPs (and use TCP to avoid spoofed IPs).
You need strong authentication and secure (proven input recognizer[1]) code in anything that connects to any network, even a guaranteed LAN. Border security is only one layer of protection, and LANs are rarely an isolated network.
[1] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
If Internet connections worked like radio broadcasts (one-way) then we'd be fine but they are inherently two-way connections. That means that for every outbound request a hole is opened up for return traffic. Even if you think, "that doesn't count" one must still account for the fact that PCs get compromised via side channels all the time and are subsequently used as pivot points for further attacks on any attached networks.
We need to stop treating intranets like they're somehow "safe" or special places apart from the Internet. They're not.
Always treat every device on any network as if it is being placed directly on the Internet because most of the time it really is. NATs and proxies aren't security tools even if they pretend to be.
That doesn't mean that you shouldn't be able to control it all from your router too. But if your home router gets hacked, or there's a devastating crypto vulnerability, or you suspect your teakettle is ratting you out to the NSA, you should still be able to boil water with it.
Finally, a mandatory physical switch would remind people (and inform them) of just how much stuff they use is now net-connected.
I don't see any way around implementing them as bog standard "RFKill" switches. A software switch is basically the only way to go because the WiFi chips are controlled in software.
The nub of the idea is a legal requirement for a physical switch that will in all cases immediately disconnect the device from the network.
The difference is that now more of our daily lives depend on the internet being reliable, and, that some IoT device's failure mode might involve a cost in human lives. But the fact that the incidents are going to be worse will also probably put more pressure on companies to fix their security. Regrettably, I don't think this will actually happen until some startup's fancy new IoT gadget gets hacked in a way that causes it to kill a few hundred people and the resulting lawsuits end the company.
That would shift incentives back to the owners to some extent, since they're basically acceptable targets as long as their devices are insecure.
Also I imagine many botnet owners secure the devices they take over so that others can't steal them for their own botnet.
Whenever Apple or Samsung release an update for their smartphones, I have a to help family members click through dialogs to install them. How are they supposed to assess and implement security for an IP camera they bought at a department store?
How would they do it anyway? Is the expectation that they fire up Wireshark, identify traffic flows to and from their device, then configure the firewall on their consumer-grade router to limit this traffic?
[0] previously read just '... disconnect between this forum ...'
But should we really worry about that scenario? If you have internet-exploitable and already-exploited devices in the ER room, haven't the horses left the barn already?
I'd be much more worried about identity theft & credit card theft with IoT devices than physical theft.
I've been in the professional IT game for 15 years. The "please run this macro in word to view content" issue still exists today and is one of the main vectors in ransomware. Heck, the "click this to view my photos" 'sexy-pics.exe' problem has not been solved in Windows either. End users don't care about UAC pop-ups, they click through them. See the recent literature on "Security Fatigue."
I think you have way too much faith in the industry to fix its own problems. Its clear that there are many classes of security problems that remain unfixed for decades. We're just seeing the newest version of the very same problems we've failed to address in the past.
I have no idea what the solution here is, but I imagine some level of certification is needed. Perhaps as simple as validating that you're forced to change the default password/keys and auto-update for security updates is on by default with some level of commitment to perform security updates for x amount of years after purchase. Toss in mandatory fail2ban-like functionality and you've patched the most common exploit use cases. I imagine that's a fairly hands-off approach here that won't interrupt business and will cost very little to implement.
On the end-user side of things, having a router that can detect when you're part of a botnet/DDOS and stop traffic would be valuable. Why aren't these $200+ Netgears and Linksys's running any sort of IPS? No IPS in this day and age is pretty crazy. An implementation of snort or similar wouldn't eat too much CPU and would only raise the cost marginally.
Its still very much the wild west out there from a security perspective.
In my opinion, the end-user is not the one causing the problem. The manufacturer is causing the problem and -- just like we do things at $work -- he who causes the problems (should be the one who) suffers by being the one to also fix it.
For example, imagine if home PCs and even laptops, had a special (macro) SD card like slot. This is the slot that the user put in their ownership card to get it to turn on at all, to log in to their OS account.
The computer would REFUSE to continue to operate with this card present. It would then enter 'normal mode'.
In normal mode no OS updates would process, no programs could be installed, no new scripts / downloads could be run. Trying to run a new thing would bring up the Authentication Required screen. They would need to insert the ownership card again. They would then need to expressly authorize what the new program could do.
That's the experience that end users for an appliance might desire; at least once they got used to it. I also strongly require that the end user is also the //owner// of the hardware. Not whoever made the OS/etc. All of the above controls would be in software, which could be replaced if they decided.
Firewalls were designed to keep bad traffic from entering LANs. For the IoT era, perhaps what we need are firewalls that keep bad traffic from exiting LANs.
Sigh. Firewalls worked great for Yahoo, Sony, and LinkedIn, right?
Firewalls are just a layer. They don't even do that much!
Not only that but the average consumer knows nothing of firewalls. Do we expect Joe Average to be able to login to his router and configure a firewall to allow his refrigerator access to its security update server? Or maybe we should expect Jane Average to configure her Firewall to perform MitM attacks on SSL so traffic going to/from her IoT coffee maker can be inspected?
They are not perfect (nothing is), but a Internet without firewalls would be apocalyptically worse.
No, NAT is most decidedly not a firewall.
You mean like just about every firewall in existence today?
How surprised would we be to hear governments uniting in response to an IZA that the answer is a new, centrally controlled and managed "internet" - because terrorists, the economy, and think of the children?
To me, we should have IoT devices on a different protocol not everything http(s). Nothing gets out unless you got an IoT passthrough router.
An IoT hub that shows me what devices, connections, and manages what can connect to where and when. QoS and other neat features if needed.
It'll never happen now of course, but would sure beat the current fustercluck.
Thus, there's no way for an attacker to get access to services on them on a large scale basis (well, without hacking the cloud service, but hopefully someone can actively maintain that).
The cameras are only an issue because many people exposed them directly to the internet so they could access them remotely.
You will not see many people expose speakers, lightbulbs, blind controllers, thermostats, fridges, TVs, etc to the internet, so it's not exactly a major threat for most devices.
Not for now at least. If IPv6 becomes wide spread available to consumers, we're in for a whole new wave of attacks on these types of devices unless home routers are configured to block incoming traffic by default to devices behind them.
If an attacker compromises any device on your network you think they'll stop there? Hell no. They're going to pivot and compromise every other vulnerable device on the network and we're already seeing "crime kits" (aka customizable malware) with built-in exploits for things like networked printers and cameras. It won't be long before they have built-in exploits for light bulbs, refrigerators, and more.
Also, what about IPv6? To date, consumer routers that support IPv6 are configured by default to hand out global IPv6 addresses (as they should!) to connected devices via DHCPv6. What this means is that your IoT light bulb is going to get a globally-accessible IPv6 address.
You can setup the firewall to block inbound connections to your light bulbs, toasters, microwave, refrigerator, etc but who is actually going to do that? Firewalls are a huge pain in the ass to configure for zillions of little devices like that and in order for them to work properly you'll need to ensure that each device gets a reasonably static IPv6 address which means going deep into the configuration of your router.
Also consider that even if you have near perfect security for your LAN we're all constantly moving in and out of our homes with connected devices that could be compromised elsewhere. Laptops, phones, tablets, etc leave our homes, connect to who-knows-what free WiFi network and then return; possibly in a compromised state.
Never assume that because something is on a LAN it is "protected" by the mere fact that it doesn't have a direct connection to the Internet! If something else on that LAN has a connection to the Internet you must treat it as if it were exposed to the Internet because it is.
Yes, while it would certainly work on a targeted basis, it's impossible on a massive scale basis. You can't just go hack all smart lightbulbs because you can't just go hack all home networks. There's no large-scale threat here if a vulnerable lightbulb is behind a NAT, where it cannot be directly attacked. It might be a point where an attacker who broke in already could lurk, but it's not a new and trivial point of intrusion.
> Also, what about IPv6? To date, consumer routers that support IPv6 are configured by default to hand out global IPv6 addresses (as they should!) to connected devices via DHCPv6. What this means is that your IoT light bulb is going to get a globally-accessible IPv6 address.
I commented on this already: By _default_ routers need to be firewalling off incoming connections completely via v6 too, as they effectively do with v4, NAT is probably the only reason we're not still in the worm era. This is incredibly trivial for manufacturers to do, and I'm hoping the majority will do it. Seriously, it's like one iptables rule that needs to be in their config.
NAT _is_ a security tool, like it or not, if you're preventing your most vulnerable devices from being directly attacked, that's a damn good security tool. Not a perfect one by any means, but a very important one for the non-expert majority of home network operators.
edit: The most democratic and open platform in the world was made by developers from all across the world vs US made operating systems like Windows and Apple which were basically trojan horses. We need an equivalent for security protocols, and protocols in general.
We can't let US stazi entrenched Silicon Valley and their faux "Startup Scene" destroy the internet as rapidly as they are today.
http://www.nytimes.com/2016/06/08/technology/the-webs-creato...
Semi-related aside: Microsoft Active Directory violates the NIST's new password hashing guidelines because it doesn't use a random salt when storing password hashes.
By platform do you mean the Internet? The Internet was initiated by the U.S. Defense Advanced Research Projects Agency.
Also, "logs all connections" is tricky. Why should my fridge need a hard drive? How much space must be available, and how far back should it store logs?
It's not contradictory with, "Updates itself regularly".
You've got me thinking about this though... If I were selling an IoT device today I would likely just outsource the majority of the self-update problem by using an open source Linux distribution as the basis of my product and merely configure it to perform automatic updates.
The product's software could be updated via a separate software repository (e.g. like a PPA). That way it would get automatically updated at a regular interval along with the OS (assuming I put out regular updates).
This would actually be an ideal setup for consumers too because if I went out of business or my software stopped getting updates the consumer could just replace the software performing the IoT functions or merely remove it and at least be left with a functional embedded computer to hack around with.
Obviously most consumers wouldn't do that but it'd be nice to give them that option.
Who said anything about logs necessitating the need for permanent storage? My router doesn't have a permanent log... It just keeps a buffer of the last N log entries in memory (e.g. `logread`).
Alternatively, I can (and have) configured it to forward its logs to a central server on my home network. Syslog forwarding and collection has been around for a really long time. It may be tricky to meet the "encrypts all network traffic" certification and syslog forwarding at the same time though since encrypted syslog normally involves a PKI.
The whole Certificate Authority concept doesn't play really well with IoT, actually.
And why would a device need full Internet access? Shouldn't it be only accessible in home network with maybe some (user selected) servers from Internet it is allowed to connect to?
We could use some sort of VPN (from device to other owner's devices) so that even if it is connected to Internet directly it doesn't accept any packets coming not from its owner. VPN also provides encryption while allowing user to examine traffic in clear text.
I think we need some type of easyly deployed, ubiquitous, simple, snandartised VPN type protocol so that the users can build protected networks over public insecure infrastructure.
Today if you connect your device to Internet you connect it directly to NSA and chinese hackers.
And if your device is disconnected from public network hackers cannot break into it even if they have exploits.
Attacks from real IP addresses are potentially blockable upstream. That's only a temporary fix. The device, if behind a NAT, can request a new IP address and evade the block. It may do so periodically, just to confuse the issue. At least you can block a hostile IP at a firewall, so it can't use server resources. That's what Cloudflare is doing.
On the legal front, it's worth suing makers of vulnerable devices for negligence. Their EULA will not protect them, because the victim isn't their customer and isn't a party to the EULA. A few court orders to recall a product might get the attention of the IoT industry.
[1] https://www.damballa.com/downloads/r_pubs/WP_Botnet_Communic...
Where does one sue the no-name Chinese manufacturers of these devices? I have a feeling a lawsuit won't get very far in Shenzhen Municipal Court. There's absolutely no consequences to them building these devices and you cannot expect a solution from them.
Cloudflare can start by suing a retailer. That's likely to result in the retailer pulling all merchandise from the offending vendor, even before the lawsuit gets very far. (Otherwise, they move to a higher tier of negligence and damages for knowingly allowing the problem to persist.) That will start to get the attention of manufacturers.
See this article.[1]
[1] http://www.techrepublic.com/article/lock-it-down-ddos-attack...
For now there is little evidence that says the bots are behind NAT's. I'm pretty sure this will come though. In the blog post I stated that there is indication that port 23/telnet is or was in past open.
Blacklisting IP addresses is indeed effective for L7 attacks. It's harder for L3 when the source IP's could be spoofed.
[0] https://medium.com/@cjbarker/mirai-ddos-source-code-review-5...
Sue the people who own and use the devices.
The first few times will be ugly and unfortunate, but if it becomes clear that buying a vulnerable device and installing it in your home is a potentially life-ruining liability, people will quickly stop buying and using the devices. And without a market for insecure IoT gadgets, well, one way or another we won't have insecure IoT gadgets.
Once a few Americans have been hit with ruinous lawsuits, the market for insecure devices will collapse, worldwide, overnight.
I don't even know what to say. Aside that you're clearly not targeting the right thing.
And, you have to admit, it'd be effective: the market would instantly collapse if device owners could be held liable for damage caused by their devices.
Why? When attacks like this are first detected, they can be shut down at the source. Known bad devices can be preemptively locked down behind a firewall. Traffic to specific IP addresses, or packets which spoof headers to cause amplification attacks could all be detected and dropped before they even reach the ISP.
Yes, there will be problems and bad diagnoses, no, I don't want one of these managing my home network; but it would be perfect for my mother, for my non-technical friends, and for the average Joe with a subverted IP camera.
In another comment[0] I described how I keep my cameras away from the internet. Someone like Google could easily build something into their routers and firewall them off as they're added to the network. The firewall could allow them to talk to the appropriate cloud service, and nothing else, in order to better secure them without the user even knowing it's happening.
This doesn't solve all of the IoT problems, but it does help some for the one described in the article.
We could bootstrap this idea by having the router fingerprint IoT devices and apply matching firewall policies from a database. If only we could install "apps" on routers, like we do on Android and iOS devices, someone could get started with this idea right now.
I realize how close to Vista's UAC this is getting.
Until Google decides that your Android traffic get priority over iOS traffic.
Which is a more likely problem--a big company trying to control my stuff (see the Phillips LED Light kerfuffle) or my device participating in a botnet?
I can mitigate the botnet by turning my device off. Giving a company control of my devices isn't so easily mitigated.
CloudFlare is seeing close to 50k. And that's the attackers just using a small portion of their real power for http floods.
Our report from a few months ago breaking down the types of cameras and networking doing the attack - very similar to what CloudFlare saw:
https://blog.sucuri.net/2016/06/large-cctv-botnet-leveraged-...
*I work at Sucuri.
All of the cameras live on a separate Wifi network that is unable to connect to the internet. I use Zoneminder to handle all of the recording, motion detection, etc. For remote access, I've got a VPN server running. Fortunately, the cameras I use are perfectly happy to work without being able to talk to the manufacturer's servers (though they do try!).
In a nutshell, I get almost all of the "benefits" of the cloud service (the only missing thing is off-site storage, but a fix for that is in the works) with almost none of the drawbacks.
Of course, this is NOT easy for the average consumer to set up. They expect to be able to plug the camera in and have things Just Work, which is why we've got cameras that can open ports on routers/firewalls, register themselves with cloud services, etc, with minimal effort.
As for IoT in general, my future plans are to use this separate WiFi network for all IoT-like devices that don't really need to connect to the internet. The Philips Hue is a good example - it has a bunch of cloud-enabled functionality, but I don't actually need any of it.
When I started with the cameras I was just using the motion detection and email features that were built into the firmware. I never bothered setting up the cloud stuff because I didn't need it. Slowly I transitioned to having the cameras dump images onto a local NAS via FTP. Eventually I started using the cameras for more than watching the cats, so I needed something with better motion detection and recording capabilities. I started with 'motion', then used a fork of 'motion' that seemed to work better, then finally ended up with ZoneMinder.
On the VPN side, I decided many years ago that I wanted remote access to my "stuff" - file shares, etc. This started out with the PPTP VPN built into my router, which is terrible but sort of worked. The next step was writing a script that would run SSH and set up a couple dozen tunnels, which is differently terrible but sort of worked. Eventually I got tired of maintaining that and ended up with an IPSec VPN using racoon -- split DNS and split tunneling are truly amazing.
The extra Wifi network actually started as a misguided attempt to prevent other stuff (Netflix, mainly) from interfering with the cameras. I figured that putting them on a separate Wifi network would isolate them and give them dedicated bandwidth. My first attempt involved using a Raspberry Pi as an AP. It worked, but not very well at all. The second attempt used the Virtual AP functionality on my router -- it wasn't until I set this up that I understood that Virtual APs don't quite work this way. Around this time I started to see articles about cloud-enabled cameras doing bad things and decided that this setup was worth keeping.
The camera and VPN stuff both went on over the last 5-10 years or so, with the Wifi changes being something I did within the last year.
You're right that there was a lot of effort, but as you can see it wasn't really driven by privacy/security until the end. Most of these things were driven by trying to find better ways to scratch various itches.
The next planned change is to re-address my network so that it doesn't use the 192.168.1.0/24 range that every consumer router seems to use by default. This way I will be able to use VPN when I'm visiting friends without having to tether to my cell phone. Like everything else, it's just scratching an itch.
But they don't announce themselves to the WAN and despite the fact that I may be naive, I don't think there is any reason I would be an attractive enough target for someone to try to gain roundabout access via a PC or phone on the WAN-enabled network.
Same thing with the Hues. No "cloud" stuff enabled and still work fine in the house where I need them to work.
I guess I like the idea of network-accessible devices (at least ones that make sense to control or access via the network) but there isn't much that I want accessing the WAN compared to the items that have the ability baked in.
I've annoyed several friends by pleading with them not to buy those "just connect to your wifi and view on our iPhone app!" cameras because I've seen how easy it is to find and exploit these via Shodan and friends. Most people don't ever even open the web interface to set up a password since it clearly shows up on the phone app and "it's just so easy!"
Yes, I restrict the cameras from talking to each other too. There's no need for one camera to talk to another in my setup.
That approach seems like the only logical conclusion for the device owners. I hope this is how the field will eventually evolve.
While its against the commercial interests of "Internet data" companies (who might subsidize devices), in the long term regular consumer appliance manufacturers will implement it if theres enough market pull for it.
* Any device can send arbitrary data to somewhere on the internet
* Internally, any devices can send arbitrary data to any other device
-----------------------
Another less-critical but important usability limitation is the short sighted nature of how device logic + APIs will evolve long-term for Device-to-Device communication.
Device-to-Device implies the application protocols are running on the devices themselves, which can't be bugfixed or upgraded by the user and in the majority of cases will likely never be updated by the manufacturer after release.
In [2] they give examples of devices like fridges and thermostats talking to each other. There's 3 long-term ways I see of handling device-to-device application APIs:
* Option 1: Raw device-to-device (Short term): How the hell will those APIs be agreed upon and evolve across multiple years and device products? Bluetooth now barely handles relatively simple interop use cases (files, contacts, audio...). Will Thermostat X support Fridge Protocol 8? How will the user handle more advanced use cases?
* Option 2: Vendor managed (Currently the most likely): The devices will talk to the vendor servers which will talk to other vendor servers which will talk to your other devices. Terrible for the user for so many reasons but great for the vendor: its the simplest to implement, keeps protocols secret and locks user into giving that specific vendor endpoint all that juicy data.
* Option 3: User managed (IMHO Preferable): Computer drivers are a much better model for this. Drivers sit over devices to transform the weird device API (fixed target) into a consistent interop API (community driven moving target) that does what people want. This still supports device-to-device: device A -> API call on gateway driver A -> gw driver interop API -> API call gateway driver B -> device B. This is what Option 2 (vendor managed) will actually have to do under the hood anyway. This could be implemented in a simple way e.g. with per-device(type) containers exposing a TCP/UDP port to the device.
I predict Option 3 to become mainstream when the year of the Linux desktop lands :D
-----------------
[1] https://www.threadgroup.org/portals/0/documents/resources/Th...
[2] https://www.infoq.com/articles/thread-protocol-for-home-auto...
(Thread is a poorly chosen name for a new computer protocol:P)
However this and other IoT devices got me thinking that maybe it's time to start an underground device hacking organization solely committed to not only rooting and reverse engineering these devices but also releasing new firmware for all of them with open source internals. I'm sure this would have to be "underground" due to all the legal restrictions around the embedded device drivers.
Who wants to do this? I wouldn't know where to start besides a .onion site...
I had the same idea, except in my version automated scan finds exploitable IOT devices and updates them with new firmware straight from /dev/null. Problem SOLVED.
The manufacturers would probably be upset they don't get my data to analyze anymore.
> These two services, like most booters, are hidden behind CloudFlare, a content distribution service that lets sites obscure their true Internet address. In case anyone cares, Lizardstresser’s real Internet address currently is 217.71.50.57, at a hosting facility in Bosnia.
https://krebsonsecurity.com/2014/12/lizard-kids-a-long-trail...
Either way, Cloudflare appears to both help booters and then also sells services to protect you from booters.
I usually agree that spending 1h on a talk may be much. But I found this one to be really good. Matthew is both entertaining, and revealing some things that weren't public before.
I'd say the 1h is worth it.
I'd say "Cloudflare recommends Cloudflare" is pretty uninformative while a TL;DR isn't.
Examples are given how Amazon removed Wikileaks from their servers without court order, how another CDN removed content because they had other clients that didn't like that content etc.
I cannot judge how honest it all is, but I'm impressed and do believe their intent. One of the scary things is what happens if Google, Microsoft or Amazon decides to buy them. Or some shady Russian or Chinese investor...
Definitely has nothing to do with the fact that a healthy market for booters is the best salesman they could ask for.
Cloudflare thinks that everyone should be immune to DDoS, both good people and bad people. I agree with that sentiment.
They're not helping the booters do booting activities.
well if they would have keep-alive it would be probably even more disastrous. especially if the botnet would have some intelligence that it would try to detect the keep alive timeout and send requests exactly in this time frame.
--
also a lot of these devices are probably built with linux. and here is something that is probably bad with linux, the lifespan of most linux iot devices are probably outspanning the official lifecycle of any distribution/kernel. this may lead to problems that the vendor will just abadonned it or doesn't care anymore, if he even provided a way to upgrade. on windows this is probably as bad as well since most vendors will probably not pay additional fee's after the next windows iot gets out of live.
it's probably time to abadon most os's for these devices and create a new open source project for these kind of devices, hardended from scratch. this would at least help with the unmaintained part of the os parts, which would make the situation at least 1% better. well it won't fix the laziness of certain vendors.. but it would be a beginning.
Their plans to upgrade the Ddos mitigation sound very interesting, will be interesting to see how long it takes until they need the 5Tbps:
>will be replaced by a new technology developed in-house and based on FGPA (programmable integrated circuits) and codes that have been in development for the past 18 months. This will allow us to offer up a VAC capable of withstanding DDoS attacks with peaks up to 5 Tbps without slowing down our network.
[0] https://www.ovh.com/us/news/articles/a2367.the-ddos-that-did...
- Is turned on by default (bad)
- Is turned on without enabling even the slightest of security by the end user (stupid but still bad)
- If a or b aren't true, it has some sort of exploit that the company will never fix (if they are still in business)
The "rest" of IoT in many cases doesn't have this problem at this scale. You're either talking about proximal networks with no outside internet (z-wave, 15.4, etc) or something with secure communication with the home service (PKI for example).
I'm more and more frustrated with IoT fearmongering, if you want to talk about CCTV fearmongering? OK. But these aren't Nest cams, or Arlo cams. They're off the shelf DVR CCTV systems.
But putting the burden on all devices that connect to the network is idealistic. Sure it may work for the 99 billion devices, but what about the 1 billion devices that may not be properly secured. This wack a mole strategy rarely works.
There must be a way for edge nodes to quickly detect a ddos and shut it down.
We should be extremely wary security hysteria often used by people with agendas to gain control and lock things down. Only 'approved' devices can connect to the network or everyone on the internet must surrender their passport to the nearest authority and be surveiled 24/7 to prempt and prevent criminal operations.
I doubt you'd notice a difference on the device unless you were doing something network/CPU intensive on it, even then, it'd just seem slow.
Similar attacks probably work against other CGI parsing things that don't expect to have hundreds of thousands of qps each with long querystrings.
Let's make a protocol that allows a server to specify to its upstream ISP to cut off all traffic from a particular IP address. The ISP can either soak up the traffic, or go further up to its own upstream ISP and relay the request, and so on until the source of the attack is reached. Now it's between an IoT device owner and his residential ISP, it's up to them to sort it out.
To motivate all ISPs to play along let's make a law for each ISP to be financially responsible for failure to honor such requests, enough for a victim to pay for defense plus some %% in penalties.
Sort of an automated "Ceases and Desist" letter, and a failure to abide is an automatic tort.
Hm?
The problem is what to do once abusive IPs are identified. Right now you will pay for all the bandwidth used.
They should probably invest that in doing some research and patching .
Which doesn't matter anyway because the traffic is still going through the edge networks (the ISP and a little bit upstream from there), so is still bandwidth impacting at some point.
We really need a way of getting the ISPs to talk to the providers upstream, and a way of notifying back that a particular host is causing problems. Unfortunately ISPs don't want to do this because unhappy customers = revenue. Also I don't want my traffic analysed on the way through, so there's a freedom issue on this too.
So it's not an easy problem to solve, but the ISPs could do it. But they won't.
On the flip side dealing with this sort of stuff is why i'd like to work for Cloudflare, Google, Facebook or others. It's fascinating how technical solutions can be bypassed by customer or provider inertia.
Some links:
- https://krebsonsecurity.com/2016/10/who-makes-the-iot-things...
- http://blog.malwaremustdie.org/
- https://www.akamai.com/us/en/our-thinking/information-securi...
I salute their help and everything, but it's always important to keep in mind that helpful companies are just an acquisition away from antagonizing us.