Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Networking

The Internet of Compromised Things 62

An anonymous reader writes: Jeff Atwood has a post about a security threat that's becoming more prevalent every day: spreading malware through a compromised router. "Router malware is the ultimate man-in-the-middle attack. For all meaningful traffic sent through a compromised router that isn't HTTPS encrypted, it is 100% game over." He links to a thorough technical analysis of how even HTTPS encrypted traffic can be subverted. Atwood provides a list of suggestions for keeping your router safe that probably won't be any surprise to people reading this site, and he further recommends only browsing on an unknown router if encryption is available. What I'm curious about are the long-term implications — is there a way forward to re-establish trust in our router infrastructure? What can the open source community do to speed this along?
This discussion has been archived. No new comments can be posted.

The Internet of Compromised Things

Comments Filter:
  • if you want to trust a router, you better be sure there is a vested interest in it being secure. new consumer grade routers come out as often as car models and the firmware is common crap that has half-assed security in the name of features.

    i wouldn't trust a router without it being open source and open hardware down to the ICs. so... is anyone making a RISC V based router?

    • by Anonymous Coward

      Well, there's this [bananapi.com], but it's probably not open enough for you, and almost certainly tries to do too much at once, but it's a nice OpenWRT [openwrt.org] platform.

  • by Anonymous Coward on Sunday August 09, 2015 @04:54AM (#50278779)

    The people who designed the internet had the right idea: Dumb network, intelligent edge. Perimeter security and trusted networks are dead ends. Communication is from endpoint to endpoint. The network shouldn't even matter. You might be running IP over avian carriers if that's what you need to do to get a connection. But if you need to trust the network between the endpoints, you're doing it wrong. Even if you could trust your own router, do you trust the ten or more routers behind it? Ubiquitous encryption and authentication with IPSec is possible with DNSSEC supplying the keys.

    • by Anonymous Coward on Sunday August 09, 2015 @05:46AM (#50278849)

      I think you still have to trust some aspects of the network. Sure, DNSSEC can provide some protection, but what if your ISP's DNS server is compromised to provide bad information? I suppose you could verify it against other servers. Can you trust that the routers your packets pass through are properly routing your traffic to the IP you want it to reach? If done right, compromising these things could be almost invisible to a lot of users. I think you have to trust certain aspects of the network, though you should use encryption to protect against MITM attacks. I think you can avoid many types of exploits, but you have to trust something in order for the internet to function. The idea of using HTTPS is a step in the right direction, except that CAs can't be trusted and the biggest one has a horrible record of security. Add to it that most users are ignorant of HTTPS and many applications don't reveal the protocol to the user and you have a problem. Can you trust that mobile apps and a lot of other software that doesn't explicitly reveal its protocols to the user makes use of encryption? Sure, you could sniff the packets, but who does that? I just don't think you can entirely remove trust from the equation, though we can do a lot better than we do now.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        what if your ISP's DNS server is compromised to provide bad information?

        That's why you need to use DNSSEC, and by use I mean verify that you got authentic data, which DNSSEC lets you do.

    • by TWX ( 665546 )

      The people who designed the internet had the right idea: Dumb network, intelligent edge.

      No they didn't. There was no default encryption. There was no built-in means to confirm that one was speaking to the host one thought one was speaking to. There was no method in the protocols to detect MIM attacks. Basic protocols require one to be honest about one's identity (like SMTP) and have only relatively recent bandaid attempts to mitigate the disaster that is their implementation. The original Internet was all telnet and UUCP and FTP and SMTP and POP3 and password flying in plain-text all over

  • by Rosco P. Coltrane ( 209368 ) on Sunday August 09, 2015 @04:56AM (#50278793)

    Nevermind your own dinky router: any traffic you send on the internet is exploited by greedy "big data" companies and rogue 1984-style government agency. And encryption doesn't stop them from watching what you do...

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      This is unfortunately the ugly reality: the internet as we knew it is dead. What many dreamed would be an empowering tool for the masses became the ultimate instrument of power and control for the Ruling Elite. We can't even leave it because all services are being brought online and online only. We have been enslaved and there's nothing we can do. In the end, I almost think the Ruling Elite deserves its great victory: they have been most astute and far-seeing in their acting. It's the culmination of a 20-ye

      • by rmdingler ( 1955220 ) on Sunday August 09, 2015 @07:28AM (#50278993) Journal

        This is unfortunately the ugly reality: the internet as we knew it is dead. What many dreamed would be an empowering tool for the masses became the ultimate instrument of power and control for the Ruling Elite.

        To be fair, it's actually a little bit of both.

        Having access to all the compiled knowledge of mankind is empowering for any and every person with internet access, as is being essentially free to contact nearly every other Worldly citizen via the web. The ability to monitor an individual's access to that information is maddeningly power grubbing for the government's surveillance state.

        Being realistic, if it was not advantageous to the ruling elite, would they let us keep it?

      • by tlhIngan ( 30335 )

        What many dreamed would be an empowering tool for the masses became the ultimate instrument of power and control for the Ruling Elite.

        In what way has it ever been about empowering the masses?

        Remember, freedom of the press belongs to those who own the presses. LIkewise, freedom on the internet belongs to those who own the internet - in this case, corporations who sponsor the backbones and who connect our homes with it.

        Always been the case. As long as someone big and power owns a part of it, they control it.

    • No, but it can make watching you sufficiently expensive and impractical as to render it impossible on a non-targetted basis.

      SSL interception is possible, but if any ISP or intelligence service does it on a large scale it will inevitably be noticed.

    • by mcrbids ( 148650 )

      I wish this weren't modded up. Really, I do.

      "any traffic" implies "all traffic" and it's simply wrong that "big data" is somehow exploiting, for example, the OpenVPN traffic between my laptop and my home mini server, nor are they making use of anything going on over SSH.

      And encryption doesn't stop them from watching what you do...

      And this is just silly. Of course it does! It is *not* a perfect tool, but it is a damned good one, the engineers did their job. As with any defensive/offensive technique, there are ways to mitigate it, and there are ways to bolster against

  • by Cigaes ( 714444 ) on Sunday August 09, 2015 @05:54AM (#50278859) Homepage
    The first thing I notice about that article is that it help spreading the misconception that HTTP is the only use of Internet and HTTPS the only encryption scheme. I must say, I feel much safer knowing my SSH sessions are not HTTPS-encrypted, because the certification mechanism is completely broken.
    • by msobkow ( 48369 )

      TLS is no more broken than SSL, and can be used by HTTPS sessions. If anything, SSL is the older and less reliable protocol, and that is what SSH is built over. So is sftp.

      Regardless of whether you are using TLS or SSL, you are relying on the same public key infrastructure system to identify hosts. So I don't know where you get the idea that SSH is "more secure."

      • by Anonymous Coward

        SSH does not use SSL and also has no CA (this is what parent talked about).

        • by msobkow ( 48369 )

          With no CA, how can you claim that it's "more secure"? You have no way of knowing the certificate was actually issued for the server you connect to if that's the case!

          Here I'd always thought people were just using self-signed certs, but if there is no CA, it's not even that secure.

      • by Cigaes ( 714444 )
        TLS is the name for later evolutions of the SSL protocol, but as someone else already noted, I was talking about SSH, not SSL.
    • The first thing I notice about that article is that it help spreading the misconception that HTTP is the only use of Internet and HTTPS the only encryption scheme. I must say, I feel much safer knowing my SSH sessions are not HTTPS-encrypted, because the certification mechanism is completely broken.

      The HTTPS certification infrastructure has problems, but to say that SSH is better because it doesn't have one at all is rather bizarre. If you'd like exactly the same sort of security from HTTPS that you get from SSH you can verify HTTPS certificate IDs manually, and you can install a browser extension that warns you when they change.

      • by Cigaes ( 714444 )

        Sorry, but it does not work. People who manage SSH servers know what a private key is, they treat it as a precious file and keep it when, for example, restoring from a hardware failure. Only when the key is compromised do they change it. If they are really serious about it will even distribute the fingerprint along with other necessary information when opening new accounts. You can verify it carefully, and then it is once and for all in the known_hosts file.

        People who manage HTTPS sites, on the other hand,

        • So, essentially, your argument is that the SSH method does not scale. I agree.
          • by Cigaes ( 714444 )

            Absolutely not. My argument is that the TLS authentication architecture is broken beyond repair.

            The SSH authentication system does not scale, but it is sound, and it could be made to scale without changing the base principle. The TLS authentication can not be repaired without changing it from the core.

            • Absolutely not. My argument is that the TLS authentication architecture is broken beyond repair.

              The SSH authentication system does not scale, but it is sound, and it could be made to scale without changing the base principle. The TLS authentication can not be repaired without changing it from the core.

              There is no SSH authentication "system". It's purely manual. How could it scale for use by billions of people who know nothing about security and are more than happy to click "OK" just to get that annoying dialog out of the way? Particularly without forcing far-reaching changes in the rest of the web infrastructure.

              Also, I disagree that TLS' authentication architecture is broken beyond repair, for two reasons. First, in actual practice for the vast majority of uses, it's not broken at all. Given the scope

              • by Cigaes ( 714444 )
                Once again, I did not propose to replace the broken CA system by anything resembling .ssh/known_hosts, that makes more than half your long messages irrelevant.
                • You didn't propose anything at all. You just complained about TLS and said SSH is great, not even substantiating either of those.

                  The reason for my lengthy posts is to engage in a technical conversation, but you seem incapable of doing anything but whining. If you'd like to actually respond to my points, perhaps propose how an SSH-style scalable system would work, or explain why you think the proposed fixes for the CA system (including the others I didn't mention... surely you're well aware of them), I'll

    • I'm seeing a few misconceptions in what you've said here as well as in your subsequent posts in these threads, so I hope you'll pardon the upcoming car analogies in response to this sentence:

      I feel much safer knowing my SSH sessions are not HTTPS-encrypted, because the certification mechanism is completely broken.

      To me, that reads like:

      I feel safer knowing my Newegg packages are not Amazon-shipped, because the gasoline industry is completely broken.

      To break that down a bit...
      1) HTTPS is not an "encryption scheme" any more than Amazon is a courier service. Suggesting you can "HTTPS-encrypt" something makes about as much sense as saying that you can "Amazon-ship" a random package. Which is to say, just as Amazon relies on FedEx, UPS, and other

  • by Anonymous Coward

    The FCC has an open rulemaking proceeding that would expand these requirements beyond the 5 GHz U-NII devices covered by the OET document to all Part 15 devices. See paragraphs 45 and 46 on page 18 of the Notice of Proposed Rulemaking (FCC 15-92):

    We propose to modify the SDR-related requirements in Part 2 of our rules
    based in part on the current Commission practices regarding software
    configuration control. To minimize the potential for unauthorized

    • by KGIII ( 973947 )

      We should fill that public comments section up with traditional Slashdot posts. These should even include GNAA, Goatse, and many others calling them 'fags' or whatnot. It would be priceless.

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Working...