SoylentNews

Attackers Use Decade-Old SSH Flaw to Target IoT Devices

posted by martyb on Friday October 14 2016, @06:22AM   
from the fast-forwarding? dept.

ticho writes:

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

---

Original Submission

• Re:Remember when Secure Shell was Secure? Re:Remember when Secure Shell was Secure? (Score: 0) by Anonymous Coward on Friday October 14 2016, @09:19AM

  by Anonymous Coward on Friday October 14 2016, @09:19AM (#414207)

  "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.

  Parent

• Re:Remember when Secure Shell was Secure? (Score: 5, Informative) by stormwyrm on Friday October 14 2016, @10:42AM

  by stormwyrm (717) on Friday October 14 2016, @10:42AM (#414219) Journal

  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:

  For all of these VPN apps, the authors state that they were motivated to create them as a reaction to the perceived complexity of protocols like SSL, SSH, and IPsec. The means of reducing the complexity was to strip out all those nasty security features that made the protocols complex (and secure). Now if you're Bruce Schneier or Niels Ferguson, you're allowed to reinvent SSL ("Practical Cryptography", John Wiley & Sons, 2003). Unfortunately the people who created these programs are no Bruce or Niels. The results are predictable.

  Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment. Replacing the SSL/SSH data channel is marginally justifiable, although usually just running SSL/SSH over UDP would be sufficient. Replacing the SSL/SSH control channel is never justifiable - even the WAP guys, with strong non-SSL/SSH requirements, simply adapted SSL rather than trying to invent their own protocol.

  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.

  Parent