5 ms·

Wow. Just wow. These BGP vulnerabilities are ridculous. Imagine, someone taking over DNS for even a small subset of people and being able to basically just rewr

Wow. Just wow. These BGP vulnerabilities are ridculous. Imagine, someone taking over DNS for even a small subset of people and being able to basically just rewrite the internet as they see fit, completely taking control of anything. Even without being able to get a valid SSL certificate you could do a lot of damage. For example, let's say I rewrote requests for SomeNationalBank.com to my proxy server. I make a request to the real SomeNationalBank.com with the weakest set of ciphers allowed, and then pass those bytes along to the client. Then I can try and decrypt it and log into your bank account as soon as I do. OR better yet I wait for you to log into an unsecured site like neopets.com or something and then pair that unencrypted password wait the fact that I saw you request the domain for a certain bank and if your password is the same (which it is for most people) then that can also get me in. We need a new more secure system to replace DNS.

pdimitar 8y ago
Check out IPFS' DNS alternative -- IPNS. No blockchain needed, it's pretty solid.
- d4l3k 8y ago
  The issue with IPNS is it's based off of public private key crypto which means the "domain" is a hash and has no name recognition. While still useful, it's not going to make its way into the mainstream anytime soon. For instance, I host my personal site on both IPFS and normal web traffic. https://fn.lc/ipns/Qmea45XwFtdwaCGAPLRMxFmoUP5YLnknc2WGCGQ3HnDP6f/ https://fn.lc/ipns/Qmea45XwFtdwaCGAPLRMxFmoUP5YLnknc2WGCGQ3H... https://gateway.ipfs.io/ipns/Qmea45XwFtdwaCGAPLRMxFmoUP5YLnknc2WGCGQ3HnDP6f/ https://gateway.ipfs.io/ipns/Qmea45XwFtdwaCGAPLRMxFmoUP5YLnk...
  - alexdumitru 8y ago
    The first one took 61 seconds to load, while the second one took 121 seconds. It doesn't seem very practical.
- KirinDave 8y ago
  I did. It's not very useful or performant, unfortunately.
cowkingdeluxe 8y ago
How similar was this to the BGP attack by Russia in late 2017? https://arstechnica.com/information-technology/2017/12/suspicious-event-routes-traffic-for-big-name-sites-through-russia/ https://arstechnica.com/information-technology/2017/12/suspi...
- omarforgotpwd 8y ago
  Ostensibly they were the exact same thing?
- ryanlol 8y ago
  >by Russia Sounds like xenophobic bullshit.
  - balls187 8y ago
    More correct to say "Russian Government"
    - ryanlol 8y ago
      The correct thing to say is “ISP in Russia”, could be Norwegian hackers using their routers for all you know.
knome 8y ago
DNSSEC adoption would prevent a hijacker from manipulating responses.
- autocracy 8y ago
  Buuuuut.... not if you hijack the destination route. It helps if the DNS servers are hijacked, but if you also snag the destination route's IP then you can still get the certificate and serve traffic. Sneaky sneaky.
- tptacek 8y ago
  No, it wouldn't. It comically wouldn't: in a BGP hijacking attack, the attackers control IP. It doesn't matter what your signed DNS record points to; attackers will just make that address theirs.
  - AndyMcConachie 8y ago
    I think in this instance DNSSEC would have prevented the entire attack. If I understand the sequence of events correctly, the route hijack was done to the auth DNS servers hosting myetherwallet.com. Then these rogue DNS servers redirected users to a fake myetherwallet.com. If myetherwallet.com had been DNSSEC signed then users who validated the signature chain would have not been redirected to the fake site. But it's not DNSSEC signed.
    - tptacek 8y ago
      In a BGP hijacking attack against a DNSSEC-signed zone, the attacker just looks at which IP address is in the signed A record, and then injects that prefix. Note that "the auth servers hosting myetherwallet.com" aren't some random IP addresses in Tallinn, Estonia. It's Route53! I get what you're saying with your counterfactual, that DNSSEC "breaks the exploit", requiring the attackers to use a slightly different exploit. But who cares? The slightly different exploit has the same predicates. That's what's so funny about the narrative that DNSSEC has some role to play in today's attack. It would almost make sense if the narrative was "we could use DANE to get rid of all CAs and then it wouldn't matter if you could trick a DV validator". But, no, people are talking about how DNSSEC would help LetsEncrypt, in the event of a global BGP hijacking. Admit it! That's funny.
viraptor 8y ago
SomeNationalBank.com in my experience uses 1 or 2 ciphers which are not the most modern, but are secure enough. For a few reasons there are almost no banks which would allow you to drop lower than aes-128-cbc.
- omarforgotpwd 8y ago
  Certain configurations of aes-128-cbc using certain software stacks have been found to have vulnerabilities. But if you really couldn't decrypt it, you could at least save anything you think might have the password in it, and then wait until you can decrypt it at some point in the future.
tialaramex 8y ago
>For example, let's say I rewrote requests for SomeNationalBank.com to my proxy server. I make a request to the real SomeNationalBank.com with the weakest set of ciphers allowed, and then pass those bytes along to the client. Then I can try and decrypt it and log into your bank account as soon as I do. What you're describing is called a Downgrade attack, and it can be detected. The newer the software at both ends, the better (more capable) the detection. In TLS 1.3 both sides need to have experienced exactly the same conversation right up until the encryption switches on, or else encryption fails and they abort. If you sneak in say a message saying "No, do crappy old crypto" to the client that was never actually sent by the server, the two conversations won't match and the connect fails. If you snuck in a message to the server saying "I can only do crappy old crypto" that was never really sent by the client, again, no match, no connection. In earlier versions of TLS, you can't fake the version number or tweak the ciphersuites or again the encryption fails and no connection is made. Only downgrading to SSL 3.0 or lower gets you somewhere, and no modern client software will allow such a downgrade.

pdimitar 8y ago

Check out IPFS' DNS alternative -- IPNS. No blockchain needed, it's pretty solid.

d4l3k 8y ago
The issue with IPNS is it's based off of public private key crypto which means the "domain" is a hash and has no name recognition. While still useful, it's not going to make its way into the mainstream anytime soon. For instance, I host my personal site on both IPFS and normal web traffic. https://fn.lc/ipns/Qmea45XwFtdwaCGAPLRMxFmoUP5YLnknc2WGCGQ3HnDP6f/ https://fn.lc/ipns/Qmea45XwFtdwaCGAPLRMxFmoUP5YLnknc2WGCGQ3H... https://gateway.ipfs.io/ipns/Qmea45XwFtdwaCGAPLRMxFmoUP5YLnknc2WGCGQ3HnDP6f/ https://gateway.ipfs.io/ipns/Qmea45XwFtdwaCGAPLRMxFmoUP5YLnk...
- alexdumitru 8y ago
  The first one took 61 seconds to load, while the second one took 121 seconds. It doesn't seem very practical.
KirinDave 8y ago
I did. It's not very useful or performant, unfortunately.

cowkingdeluxe 8y ago

How similar was this to the BGP attack by Russia in late 2017? https://arstechnica.com/information-technology/2017/12/suspicious-event-routes-traffic-for-big-name-sites-through-russia/ https://arstechnica.com/information-technology/2017/12/suspi...

omarforgotpwd 8y ago
Ostensibly they were the exact same thing?
ryanlol 8y ago
>by Russia Sounds like xenophobic bullshit.
- balls187 8y ago
  More correct to say "Russian Government"
  - ryanlol 8y ago
    The correct thing to say is “ISP in Russia”, could be Norwegian hackers using their routers for all you know.

knome 8y ago

DNSSEC adoption would prevent a hijacker from manipulating responses.

autocracy 8y ago
Buuuuut.... not if you hijack the destination route. It helps if the DNS servers are hijacked, but if you also snag the destination route's IP then you can still get the certificate and serve traffic. Sneaky sneaky.
tptacek 8y ago
No, it wouldn't. It comically wouldn't: in a BGP hijacking attack, the attackers control IP. It doesn't matter what your signed DNS record points to; attackers will just make that address theirs.
- AndyMcConachie 8y ago
  I think in this instance DNSSEC would have prevented the entire attack. If I understand the sequence of events correctly, the route hijack was done to the auth DNS servers hosting myetherwallet.com. Then these rogue DNS servers redirected users to a fake myetherwallet.com. If myetherwallet.com had been DNSSEC signed then users who validated the signature chain would have not been redirected to the fake site. But it's not DNSSEC signed.
  - tptacek 8y ago
    In a BGP hijacking attack against a DNSSEC-signed zone, the attacker just looks at which IP address is in the signed A record, and then injects that prefix. Note that "the auth servers hosting myetherwallet.com" aren't some random IP addresses in Tallinn, Estonia. It's Route53! I get what you're saying with your counterfactual, that DNSSEC "breaks the exploit", requiring the attackers to use a slightly different exploit. But who cares? The slightly different exploit has the same predicates. That's what's so funny about the narrative that DNSSEC has some role to play in today's attack. It would almost make sense if the narrative was "we could use DANE to get rid of all CAs and then it wouldn't matter if you could trick a DV validator". But, no, people are talking about how DNSSEC would help LetsEncrypt, in the event of a global BGP hijacking. Admit it! That's funny.

viraptor 8y ago

SomeNationalBank.com in my experience uses 1 or 2 ciphers which are not the most modern, but are secure enough. For a few reasons there are almost no banks which would allow you to drop lower than aes-128-cbc.

omarforgotpwd 8y ago
Certain configurations of aes-128-cbc using certain software stacks have been found to have vulnerabilities. But if you really couldn't decrypt it, you could at least save anything you think might have the password in it, and then wait until you can decrypt it at some point in the future.

tialaramex 8y ago

>For example, let's say I rewrote requests for SomeNationalBank.com to my proxy server. I make a request to the real SomeNationalBank.com with the weakest set of ciphers allowed, and then pass those bytes along to the client. Then I can try and decrypt it and log into your bank account as soon as I do. What you're describing is called a Downgrade attack, and it can be detected. The newer the software at both ends, the better (more capable) the detection. In TLS 1.3 both sides need to have experienced exactly the same conversation right up until the encryption switches on, or else encryption fails and they abort. If you sneak in say a message saying "No, do crappy old crypto" to the client that was never actually sent by the server, the two conversations won't match and the connect fails. If you snuck in a message to the server saying "I can only do crappy old crypto" that was never really sent by the client, again, no match, no connection. In earlier versions of TLS, you can't fake the version number or tweak the ciphersuites or again the encryption fails and no connection is made. Only downgrading to SSL 3.0 or lower gets you somewhere, and no modern client software will allow such a downgrade.