Millions of IoT devices have already been compromised and abused for distributed denial-of-service (DDoS) attacks and millions more are affected by critical vulnerabilities that make them an easy target for malicious actors.
While in many cases attackers hack IoT devices and leverage them to conduct attacks directly, researchers at Akamai have come across a different type of mass attack in which the compromised systems are used as proxies that route malicious traffic.
These attacks, dubbed by Akamai SSHowDowN Proxy attacks, have abused vulnerable CCTV, NVR, DVR, networking, storage and satellite antenna equipment to conduct HTTP-based credential stuffing campaigns. The breached devices are also used as an entry point to the internal networks that house them.
Read more at SecurityWeek.com
(Score: 2) by Unixnut on Friday October 14 2016, @08:08AM
Oh please, so just because some software with an encrypted channel has bugs, we should default to just blasting everything over plaintext using Telnet?
If there is something better out there, then sure, we can consider moving across. However not going to regress backwards because the current encrypted system is not secure enough. Better try to improve what we have.
(Score: 0) by Anonymous Coward on Friday October 14 2016, @09:19AM
"I ain't switchin' ov'r to nuttin' 'til ev'body else be switchin' ov'r!"
Gawhd daym, you're a stodgy crowd follower.
Here's a novel idea: stop packing iThingies full of bug-ridden crapware, and use simpler methods of remote access control instead, so they don't need patching all the damn time.
Here's just one possible example: Port Knocking.
(Score: 5, Informative) by stormwyrm on Friday October 14 2016, @10:42AM
Yeah, a fat lotta good port knocking is going to do for you when your attacker is able to MITM your connection to your remote host since you're not bothering to do proper encryption with your actual connection. Good security is hard, but the fact that we sometimes make mistakes while trying to do it shouldn't mean that we should just give up on the process altogether. You underestimate how hard it is to design a secure remote access protocol. In the late 1990s/early 2000s, as a reaction to the seeming complexity of the established IPsec/SSH/SSL/TLS protocols and the constant patching these complex protocols seemed to require, some developers on Linux tried to build VPN protocols on their own, only to find that they were all embarrassingly insecure [auckland.ac.nz] when they were examined, just as Microsoft's PPTP VPN was shown to be. Good security is hard:
This is why OpenVPN is the UDP-based VPN of choice these days, and all of the other programs mentioned have largely fallen into disuse. OpenVPN uses the TLS protocol to do what it does, and while it has had successful attacks on it they have been mostly implementation bugs like Heartbleed rather than deficiencies in the protocol design itself. The only major exceptions to this are the FREAK and Logjam attacks which exploit deliberate weaknesses incorporated into the protocol at the insistence of the US government during the height of Crypto War I.
Numquam ponenda est pluralitas sine necessitate.
(Score: 3, Interesting) by bob_super on Friday October 14 2016, @06:50PM
> we should default to just blasting everything over plaintext using Telnet
In some cases, it could be beneficial. If people were aware that they are having an insecure (i.e. recorded) communication, they would be more careful about its contents.
Then they'd switch to state-of-the-art "secure" protocols for really important things.
Right now, we have too many people trusting inadequate security and not questioning its actual performance. "It's encrypted" or "I've got to enter twelve passwords, so it's safe, even if I make them all the same" are the kind of reasoning which sure help me keep a low profile when unpleasant people come for easy pickings.