I completely understand how IoT devices were used in the massive DDoS attacks because they are easily manipulated due to lack of firewalls, default passwords, etc.
What I don't understand is although easily hacked, most IoT devices are connected to secured private wifi networks.
Here's the question: So is it assumed that these thousands of IoT devices' networks were hacked first, then the device itself was hacked?
The devices are designed to be accessible from outside the home. To offer this service to their owners, they make themselves accessible through the homeowner's router/firewall. The way they do this is by sending a UPnP packet to the owner's router that tells the router to open a port that connects back to them. They then listen for connections that arrive directly from the internet.
In other words, the devices first hacked their owner's routers by design, which exposed their own vulnerabilities. (This has nothing to do with secured, private, or open WiFi, other than many IoT devices connect via WiFi; UPnP exposes the exact same vulnerabilities on wired devices connected by Ethernet cables, too.)
To protect yourself, disable UPnP on your router.
Your understanding of the attack is not as clear as you think. In this article, Krebs mentioned that the attackers didn't really have to hack the devices. The vulnerability was well known, they just had to scan the internet for those devices.
Sure, if SSH/Telnet to the devices was disabled, the problem would have been solved easily. To make the matter worse, the hard coded credentials present in the hardware were not even visible to the web interface for the administrator.
Yes, it is absolutely imperative to know what are the devices present in your network and what are the services that you do/do not need.
EDIT : After @tlng05 's clarification about the question.
As already mentioned in other answers, you should disable UPnP on your router to absolutely make sure that your device is not straight forward configurable from the outside world.
Your misconception is here:
secured private wifi networks
Whilst many home WiFi networks are secured against unauthorised wireless devices connecting directly, many are wide open to access from the wider Internet. It's this access (that's demanded by the IoT devices to perform their legitimate functions) that can be abused (and on a much bigger scale than physically visiting many WiFi networks).
The attack surface of a router is on both all networks!
What I don't understand is although easily hacked, most IoT devices are connected to secured private wifi networks.
Yes they are connected to your private wifi networks, But are they secured? Well not so much as pointed by you these device are unprotected by firewalls, IPSs unlike the enterprise networks. Some of them have ancient firmwares, which haven't been updated since ages. And yes some have default passwords still working, So that anyone can easily take access and exploit them for attacks.
So is it assumed that these thousands of IoT devices' networks were hacked first, then the device itself was hacked?
Well not necessarily, Although it may be possible in some cases. But mostly these devices are intentionally left exposed to the internet because they are needed to be accessed from anywhere around the world.
As pointed out by many examples above, If you want the CCTV footage of your house mostly you would want it live streamed on your handheld device and that is why they are needed to be accessible over internet. They are N number of other examples.
Conclusion: To use IoT devices to attack, one doesn't need access to your network. These devices can be directly accessed from internet. What we need to do is protect these devices from such un-authorized accesses and keep our devices safe without having to use expensive devices like firewalls and IPSs.
UPnP can be an issue, but everybody seems to be missing the point that many of these devices make persistent standard outgoing NAT connections to the vendors' servers. All the attacker has to do is hack into the vendor's site to gain control of all of the attached IoT devices, and from there, since they are now inside home networks, to attack other computers inside the network or launch DDoS attacks. Direct HTTP, SSH or other UPnP-enabled access through your router isn't necessarily a requirement.
While IoT devices are indeed within secure networks, they are largely made such that they are accessible from the internet. For example, the temperature setting of your home is accessible from your phone app when you're at work. This is enabled by a connection being opened up to the internet. This answers why they're able to access the outside world.
Now, most IoT devices, or botnets, are not well patched and use loose security configurations. Parts 1 and 2 of the article found here explain this in detail, but to summarize, these devices are infected with malware. They are able to send outgoing messages to the internet (the outside world). And thus, they end up sending the "DoS" message to the target.
Most IoT devices are on networks that are connected to the Internet by conventional SoHo NAT routers that typically have very limited firewall capabilities or where the firewalls are not enabled or maintained. There is a common myth that NAT is a security layer, it is not.
"NAT and firewalling are completely orthogonal concepts that have nothing to do with each other. Because some NAT implementations accidentally provide some firewalling, there is a persistent myth that NAT provides security. It provides no security whatsoever. None. Zero." -- How Important is NAT as a security layer?
It may be worthwhile thinking about terminology and what is meant when people say that IoT things have been 'hacked'. In many cases, the devices have not been hacked at all - they are performing as designed.
Broadly speaking, there are two types of network connections. The first type is a fully connected type connection where both parties need to be fully connected. Similar to a phone call, you need to have someone on both ends. With this type of connection, the initiating system makes an initial connection to the destination system and the destination system connects back to the initiating system. This type of connection is what normally occurs when it is important to be able to coordinate communications, track data packet order and request re-sending of any lost data.
The other type of connection is more like a messaging connection (think of SMS or some other messaging In this type of connection, you don't have a bi-directional connection. The originating system sends a message to the destination system and, depending on the message, the receiving system may send back a response to the sender address in the initial message. This type of communication is good when order of data, loss of some data etc is not critical.
The thing is, while fully connected connections are great for things like data integrity and because of the bi-directional nature, are difficult to spoof, they are more expensive in terms of resources and overhead. The second type of connection has less integrity and is easier to spoof because there is no bi-directional connection, but they are cheap - require less resources and have lower system overheads to process.
Many IoT systems are small, lightweight and need to be efficient. They typically have less memory and less powerful processes and therefore tend to favour designs which use connecitonless protocols rather than more expensive connected protocols. However, this also means that it is easier for rogue systems to 'lie' and do things like spoof IP addresses. This is like me sending you a message, where the return address is false. When you reply to the message your reply will go to the address in the message, but that is not the real originating address.
In effect, what is happening is that the IoT devices are being folled into sending data/responses to an innocent bystander who has not requested anything. The system has not been 'hacked', only fooled.
Often, the situation can be made worse by using amplification techniques. There are some connectionless type services out there which, when asked a vary simple/short question, will respond with a vary long answer i.e. answers with lots of data. This can make it vary easy to create a situation where suddenly, a victim site (such as a DNS) suddently starts receiving large amounts of data it was not expecting or did not ask for.
to do this, all you need to do is identify devices on the internet which support a connectionless protocol, send these devices a message which requests something which is likely to involve a large data response and spoof the IP address of the targeted victim.
to make it worse, the targeted system doesn't even need to know or understand the data being sent to it. The idea is to just send so much data that the system becomes overwhelmed - that could happen when the system is forced to look at large amounts of incoming data simply to make a decision to discard it and take no further action. With enough data, even that process of working out you need to just ignore it can be enough to prevent the system from being able to process legitimate connections. The fact that this data is comming from multiple different source systems i.e. all the IoT deices means you cannot just block an IP address because there are simply too many.
So, while it is vary true there are far too many IoT devices which ahve been poorly designed and lack sufficient security controls, a part of the problem is the conflicting requirements to implement a light-weight resource efficient solution on one hand, but somehow deal with a world with too many malicious agents who want to exploit your good intentions. There is certainly a lot IoT vendors could do to improve the situation, but for most of them, this would just increase production costs and the reality is, most consumers are not aware of the issues, so failing to invest in the better solution doesn't affect market share and therefore doesn't result in sufficient financial benefit.
XM actually disabled telnet/ssh on many of their IoT devices (they supply many for new DvRs, webcams, etc.) more than a year ago. So anyone who had actually updated the firmware (who knows) or had bought a more recent model of (IoT device whatever) since then likely would have been immune from that sort of attack.
My understanding is the Mirai (not sure about the other popular one Bashlight) connected to most IoT devices through GRE - an IP point-to-point virtual tunnel. GRE is kind of like a VPN of packet delivery - it can pass data through public network privately - without the actual data/headers being identifiable and with almost no protocol overhead. So once you have a master list of exploitable cams, home sec, connected whatever devices and the models, you can scan the whole internet and tunnel IPs accessible through open ports, run against passwords, etc etc. Hard for people to see it coming because GRE looks like regular IP transmission between devices calling home or streaming home video to app, etc. This is just my take...
New in this forum I thought I'd chime in from a hobby IoT device maker's perspective. I may very well be off topic, not least since I am not entirely sure what you guys even consider to BE an IoT device, but for what it's worth:
The "IoT devices" I create, which do useless things such as report whether or not someone has moved within a certain area in a certain time, could easily be "hacked" without accessing my WiFi. You could probably just put up a receiver of the right sort (we could be talking 433MHz) and eavesdrop all day. Then you could craft your own messages and send them to my stupid device and/or the server that collects that information, and have me running home in panic since my not-so-smart-home system says it's 200 degrees Centrigrade in my fridge and five thousand people have passed into my garage but noone came out.
Basically what I'm saying is that whatever flaws the IoT devices hardware exposes directly, and it's software doesn't guard against, could be an entry port for a hacker. Heck, based on where the device is placed you could even attach your own hardware to it and start making trouble. "Here's my WiFi enabled ESP8266, go ahead and upload your own software to it via USB." But I guess that's really out of scope.
