Stories
Slash Boxes
Comments

SoylentNews is people

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

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

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: -1, Troll) by Anonymous Coward on Friday October 14 2016, @06:55AM

    by Anonymous Coward on Friday October 14 2016, @06:55AM (#414182)

    Nope. SSH was always smoke and mirrors. Encryption isn't worth shit when SSH is full of fucking bugs. Might as well be using Telnet. But but but everybody uses SSH because everybody uses SSH because everybody uses SSH. What a bunch of clowns.

    Starting Score:    0  points
    Moderation   -1  
       Troll=2, Underrated=1, Disagree=1, Total=4
    Extra 'Troll' Modifier   0  

    Total Score:   -1  
  • (Score: 2) by Unixnut on Friday October 14 2016, @08:08AM

    by Unixnut (5779) on Friday October 14 2016, @08:08AM (#414196)

    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

      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.

      • (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.
    • (Score: 3, Interesting) by bob_super on Friday October 14 2016, @06:50PM

      by bob_super (1357) on Friday October 14 2016, @06:50PM (#414404)

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

  • (Score: 2) by LoRdTAW on Friday October 14 2016, @04:55PM

    by LoRdTAW (3755) on Friday October 14 2016, @04:55PM (#414361) Journal
    • (Score: 3, Informative) by stormwyrm on Monday October 17 2016, @12:39AM

      by stormwyrm (717) on Monday October 17 2016, @12:39AM (#415029) Journal
      Rob Pike, while right behind Ken Thompson and Dennis Ritchie in the Unix pantheon, hasn't really made a name for himself in the realm of cryptography and security. There is a reason why cryptographic protocols like SSH are designed to support a plethora of authentication and encryption methods: there is a small but distinct possibility that mathematical or technological advancements will render any of them insecure. The same reason applies to why there is no one guaranteed protocol for authentication and encryption that one can always use as a fallback. If we had such a thing, what would we choose? The posts were written in 2001, so would you have as fallback RSA and Blowfish or 3DES maybe? (there was no official AES yet back then) What if someday a smart mathematician publishes a proof that it is possible to factor numbers in polynomial time, or that the RSA problem is not really equivalent to factoring and there is a short-cut, or if engineering advances lead to practical quantum computers? RSA is then completely broken, but since support for it is guaranteed by the notional protocol, everyone using the notional SSH is an instant MITM target, with no way to remove or disable the algorithm that makes it possible. Version downgrade attacks have long been a staple of the security penetrator's toolkit. People complain about how complicated SSH and SSL/TLS are but don't realise that no complexity is added to these protocols by their designers without a strong security rationale. As I have mentioned in another post, many people underestimate how difficult it is to design a secure cryptographic protocol. The designers of the CIPE, VTUN, and TINC VPN systems designed simple protocols in reaction to what they perceived as the baroque complexity of SSH/SSL/TLS, and as a result designed protocols that were so simple that they were easily breakable.
      --
      Numquam ponenda est pluralitas sine necessitate.