6 ms·

Part 1 says that they use SSL-stripping attacks to replace cryptocurrency addresses with their own address, allowing them to capture e.g. transfers to a crypto

Part 1 says that they use SSL-stripping attacks to replace cryptocurrency addresses with their own address, allowing them to capture e.g. transfers to a crypto mixer. https://nusenu.medium.com/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac https://nusenu.medium.com/how-malicious-tor-relays-are-explo...

jandrese 5y ago
The thing that confuses me about that is if you have not installed the malicious MITM's root cert in your browser isn't that going to fail? Or are these MITM's somehow signing stuff with well known root certs? That seems like it would be a much bigger story. Or are TOR users really accepting self-signed certs when passing around their bitcoin addresses? Maybe there are bitcoin clients that don't validate the chain when doing TLS? Given the sorry security posture of so many exchanges this is somewhat more plausible.
- bawolff 5y ago
  Ssl stripping usually means replacing https links with http (when on http) and blocking TLS so users retry with http. Moral of the story, if you a are a site operator use HSTS. And if you're on tor, you should maybe consider configuring things so you only use tls.
  - deleted 5y ago
    [deleted]
- jandrese 5y ago
  That makes sense. I know the MITMproxy they mentioned re-signs the traffic, but it will not work unless you install its self-generated cert so I thought it was weird that the malicious exit nodes were using it. Also, if someone is running a bitcoin exchange that has port 80 open for anything more than a redirect I would not do business with them.
  - swiley 5y ago
    You can just tell people to install the cert. Verizon puts an MITM proxy from Mcaffe on people's routers (with their consent) that does this.
    - hmaxwell 5y ago
      Why would installing a ssl cert inside a router change anything? The only way is if you could install the cert inside the OS or the browser...
      - swiley 5y ago
        They put software on the router that terminates people's SSL connections and tells them to install a cert on their computer.
- Lammy 5y ago
  > you have not installed the malicious MITM's root cert in your browser PROTIP: Your browser already comes with all the malicious root certs a Five-Eyes-aligned attacker would ever need. The Tor Browser uses Mozilla's Root Store if you want to go see what's in it. To pick a random example look at VeriSign's root, the company that runs dot-com and dot-net, and manages dot-gov. Do you think they might be Best Fwends with the DoD/NSA/etc? https://www.ntia.doc.gov/page/verisign-cooperative-agreement https://www.ntia.doc.gov/page/verisign-cooperative-agreement I also think it's a pretty safe bet that many many other roots are compromised many times over even if nobody ever willingly cooperated with anything.
  - vorpalhex 5y ago
    The NSA is probably not stealing your bitcoin.
  - fpgaminer 5y ago
    The concern here isn't state actors; just lowly exit node operators looking to skeeze a buck. Check the other comments for how it's actually done. More importantly, I think your fear about state actors abusing trusted root certificates is unfounded. As soon as a malicious cert is found, the issuing root cert will be nuked from orbit by all the major browser vendors. It's not a viable option for state actors, especially when they have much better options (like the NSA tapping Google's internal networks, for example).
  - vbezhenar 5y ago
    There's certificate transparency, it's required for all certificates, so if any root will issue fake certificate, you can catch and report it. So I'm not sure if that's a pretty safe bet.
    - tialaramex 5y ago
      Logging (for Certificate Transparency) isn't a policy requirement. In fact last time I looked, there are (special purpose, typically in industrial settings so their clients aren't web browsers) Intermediates under some roots that just aren't outfitted to be capable of logging at all. Their existence is not a policy violation. Clients (most particularly, popular browsers such as Chrome) can and do require SCTs (effectively proof the certificate was logged) to accept a certificate, but that just means if you issue a certificate under a trusted root without logging it, it just won't work in such browsers until somebody logs it. You can even do this intentionally, if you're Google for example you get yourself (unlogged) certificates for shiny-new-product.google.example and shiny-new-product.example on Monday, and you don't need to worry that some eagle-eyed journalist spots that in the logs before your official product launch on Thursday evening, live in front of millions of people. You can log the certificate yourself minutes before launch, then attach the SCTs and it'll work. [Google even got this wrong once, mistakenly using a certificate they didn't have enough SCTs for due to a bug. Chrome rejected these certificates and so, for a brief period until they fixed the problem, Google's own sites didn't work in Chrome] Now, that last part is technically not trivial to do correctly (chances are your existing web dev tooling can't do SCT stapling, or at least you'd need to go read a bunch of instructions that you aren't going to bother with) and so when you get a Let's Encrypt cert, or you buy something cheap from a reseller, it is already logged for you, the SCTs are baked inside the certificate you get -- but that's just because there isn't a big market for unlogged certificates, not because such certificates can't or mustn't exist.
- michaelmcmillan 5y ago
  Most sites redirect all http traffic to https to make sure the traffic is encrypted. Here's an example with HN (notice the protocol in the req/res): $ curl -v http://news.ycombinator.com [...] < HTTP/1.1 301 Moved Permanently < Location: https://news.ycombinator.com/ However, the first request is over http, before it gets redirected and encrypted. This is where the malicious relay node would intercept and change the response.
  - tialaramex 5y ago
    This is actually what's going on. It's what HSTS and HSTS preloading protects you against, it's why Chrome is moving to just assuming HTTPS when you type domain names without specifying, and it's why Firefox now has "HTTPS only mode" where it goes further and just rewrites all HTTP as HTTPS (even in random links you follow) and gives you an interstitial caution page to decide if you really want to try HTTP when HTTPS fails. People have all these fancy high-tech Hollywood-style theories about how they imagine things being attacked, but the reality is almost always far more boring.
    - deleted 5y ago
      [deleted]
    - meowface 5y ago
      Yeah. And for anyone unaware, this technique, SSL stripping, was made well-known (and perhaps pioneered?) by Moxie Marlinspike of Signal with his tool sslstrip back in 2011: https://github.com/moxie0/sslstrip https://github.com/moxie0/sslstrip. I believe that's what he was most famous for before Signal. It's unfortunate that this very simple attack remains extremely successful even a decade later. I'm surprised Tor Browser didn't enforce HTTPS Everywhere for all domains by default years ago. HTTPS Everywhere was released in 2010, before sslstrip, even. HSTS and HSTS preloading helps, but individual site owners still have to explicitly submit their site to be added to the preload list.
      - mercora 5y ago
        > and perhaps pioneered? i highly doubt that. in fact i knew about ssl striping before i knew moxie or even sslstrip and this attack was probably already well known when someone came up with a seperate url scheme for https...
- michaelt 5y ago
  They MITM connections that aren't encrypted and prevent them from becoming so. Many bitcoin mixers are not HSTS preloaded. And to avoid creating a trail, TOR Browser doesn't save frequently visited sites, history for autocomplete, cached redirects, or cached HSTS headers between sessions. And as Tor users prize secrecy, many don't bookmark their bitcoin mixer. Instead they key in the address manually - and sometimes they're used to doing without the https://www https://www. prefix. And by convention, browsers use http when you do that. The exit node then removes the http-to-https redirect, and presents the bitcoin mixer over http, with the bitcoin addresses replaced. The result looks like this: https://imgur.com/otaBerJ https://imgur.com/otaBerJ No MITM of encrypted connections needed. It's almost impossible for the Tor project to detect this, as the attackers only target a small whitelist of sites - so the Tor project can only detect attackers by guessing the sites on the attack whitelist.
  - colejohnson66 5y ago
    I’d say the first step could be switching http-https around. Attempt to connect to https and fallback to http if the user agrees to being less secure.
    - jhugo 5y ago
      HSTS is this, but without the fallback.
makomk 5y ago
Hopefully the Tor operators have improved their process for handling this since a few years ago when the e-mail address for contacting them about malicious exit nodes went to someone whose email provider bounced any emails containing the names of some of the main targets for these attacks and who didn't seem to be able to understand the attack once you did somehow get through to them...

jandrese 5y ago

The thing that confuses me about that is if you have not installed the malicious MITM's root cert in your browser isn't that going to fail? Or are these MITM's somehow signing stuff with well known root certs? That seems like it would be a much bigger story. Or are TOR users really accepting self-signed certs when passing around their bitcoin addresses? Maybe there are bitcoin clients that don't validate the chain when doing TLS? Given the sorry security posture of so many exchanges this is somewhat more plausible.

bawolff 5y ago
Ssl stripping usually means replacing https links with http (when on http) and blocking TLS so users retry with http. Moral of the story, if you a are a site operator use HSTS. And if you're on tor, you should maybe consider configuring things so you only use tls.
- deleted 5y ago
  [deleted]
jandrese 5y ago
That makes sense. I know the MITMproxy they mentioned re-signs the traffic, but it will not work unless you install its self-generated cert so I thought it was weird that the malicious exit nodes were using it. Also, if someone is running a bitcoin exchange that has port 80 open for anything more than a redirect I would not do business with them.
- swiley 5y ago
  You can just tell people to install the cert. Verizon puts an MITM proxy from Mcaffe on people's routers (with their consent) that does this.
  - hmaxwell 5y ago
    Why would installing a ssl cert inside a router change anything? The only way is if you could install the cert inside the OS or the browser...
    - swiley 5y ago
      They put software on the router that terminates people's SSL connections and tells them to install a cert on their computer.
Lammy 5y ago
> you have not installed the malicious MITM's root cert in your browser PROTIP: Your browser already comes with all the malicious root certs a Five-Eyes-aligned attacker would ever need. The Tor Browser uses Mozilla's Root Store if you want to go see what's in it. To pick a random example look at VeriSign's root, the company that runs dot-com and dot-net, and manages dot-gov. Do you think they might be Best Fwends with the DoD/NSA/etc? https://www.ntia.doc.gov/page/verisign-cooperative-agreement https://www.ntia.doc.gov/page/verisign-cooperative-agreement I also think it's a pretty safe bet that many many other roots are compromised many times over even if nobody ever willingly cooperated with anything.
- vorpalhex 5y ago
  The NSA is probably not stealing your bitcoin.
- fpgaminer 5y ago
  The concern here isn't state actors; just lowly exit node operators looking to skeeze a buck. Check the other comments for how it's actually done. More importantly, I think your fear about state actors abusing trusted root certificates is unfounded. As soon as a malicious cert is found, the issuing root cert will be nuked from orbit by all the major browser vendors. It's not a viable option for state actors, especially when they have much better options (like the NSA tapping Google's internal networks, for example).
- vbezhenar 5y ago
  There's certificate transparency, it's required for all certificates, so if any root will issue fake certificate, you can catch and report it. So I'm not sure if that's a pretty safe bet.
  - tialaramex 5y ago
    Logging (for Certificate Transparency) isn't a policy requirement. In fact last time I looked, there are (special purpose, typically in industrial settings so their clients aren't web browsers) Intermediates under some roots that just aren't outfitted to be capable of logging at all. Their existence is not a policy violation. Clients (most particularly, popular browsers such as Chrome) can and do require SCTs (effectively proof the certificate was logged) to accept a certificate, but that just means if you issue a certificate under a trusted root without logging it, it just won't work in such browsers until somebody logs it. You can even do this intentionally, if you're Google for example you get yourself (unlogged) certificates for shiny-new-product.google.example and shiny-new-product.example on Monday, and you don't need to worry that some eagle-eyed journalist spots that in the logs before your official product launch on Thursday evening, live in front of millions of people. You can log the certificate yourself minutes before launch, then attach the SCTs and it'll work. [Google even got this wrong once, mistakenly using a certificate they didn't have enough SCTs for due to a bug. Chrome rejected these certificates and so, for a brief period until they fixed the problem, Google's own sites didn't work in Chrome] Now, that last part is technically not trivial to do correctly (chances are your existing web dev tooling can't do SCT stapling, or at least you'd need to go read a bunch of instructions that you aren't going to bother with) and so when you get a Let's Encrypt cert, or you buy something cheap from a reseller, it is already logged for you, the SCTs are baked inside the certificate you get -- but that's just because there isn't a big market for unlogged certificates, not because such certificates can't or mustn't exist.
michaelmcmillan 5y ago
Most sites redirect all http traffic to https to make sure the traffic is encrypted. Here's an example with HN (notice the protocol in the req/res): $ curl -v http://news.ycombinator.com [...] < HTTP/1.1 301 Moved Permanently < Location: https://news.ycombinator.com/ However, the first request is over http, before it gets redirected and encrypted. This is where the malicious relay node would intercept and change the response.
- tialaramex 5y ago
  This is actually what's going on. It's what HSTS and HSTS preloading protects you against, it's why Chrome is moving to just assuming HTTPS when you type domain names without specifying, and it's why Firefox now has "HTTPS only mode" where it goes further and just rewrites all HTTP as HTTPS (even in random links you follow) and gives you an interstitial caution page to decide if you really want to try HTTP when HTTPS fails. People have all these fancy high-tech Hollywood-style theories about how they imagine things being attacked, but the reality is almost always far more boring.
  - deleted 5y ago
    [deleted]
  - meowface 5y ago
    Yeah. And for anyone unaware, this technique, SSL stripping, was made well-known (and perhaps pioneered?) by Moxie Marlinspike of Signal with his tool sslstrip back in 2011: https://github.com/moxie0/sslstrip https://github.com/moxie0/sslstrip. I believe that's what he was most famous for before Signal. It's unfortunate that this very simple attack remains extremely successful even a decade later. I'm surprised Tor Browser didn't enforce HTTPS Everywhere for all domains by default years ago. HTTPS Everywhere was released in 2010, before sslstrip, even. HSTS and HSTS preloading helps, but individual site owners still have to explicitly submit their site to be added to the preload list.
    - mercora 5y ago
      > and perhaps pioneered? i highly doubt that. in fact i knew about ssl striping before i knew moxie or even sslstrip and this attack was probably already well known when someone came up with a seperate url scheme for https...
michaelt 5y ago
They MITM connections that aren't encrypted and prevent them from becoming so. Many bitcoin mixers are not HSTS preloaded. And to avoid creating a trail, TOR Browser doesn't save frequently visited sites, history for autocomplete, cached redirects, or cached HSTS headers between sessions. And as Tor users prize secrecy, many don't bookmark their bitcoin mixer. Instead they key in the address manually - and sometimes they're used to doing without the https://www https://www. prefix. And by convention, browsers use http when you do that. The exit node then removes the http-to-https redirect, and presents the bitcoin mixer over http, with the bitcoin addresses replaced. The result looks like this: https://imgur.com/otaBerJ https://imgur.com/otaBerJ No MITM of encrypted connections needed. It's almost impossible for the Tor project to detect this, as the attackers only target a small whitelist of sites - so the Tor project can only detect attackers by guessing the sites on the attack whitelist.
- colejohnson66 5y ago
  I’d say the first step could be switching http-https around. Attempt to connect to https and fallback to http if the user agrees to being less secure.
  - jhugo 5y ago
    HSTS is this, but without the fallback.

makomk 5y ago

Hopefully the Tor operators have improved their process for handling this since a few years ago when the e-mail address for contacting them about malicious exit nodes went to someone whose email provider bounced any emails containing the names of some of the main targets for these attacks and who didn't seem to be able to understand the attack once you did somehow get through to them...