7 ms·

You posted the link like this: "...I wanted to see how easy it was to fail in practice so I built a simple app: notecrypt.appspot.com" If you copy and paste t

by moxie 13y ago

You posted the link like this: "...I wanted to see how easy it was to fail in practice so I built a simple app: notecrypt.appspot.com" If you copy and paste that into your browser, your browser will make an HTTP request. Your webapp will send back a 302 redirect with an HTTPS link, but if I'm an attacker running sslstrip (http://www.thoughtcrime.org/software/sslstrip http://www.thoughtcrime.org/software/sslstrip), that won't work. What's more, you don't set HSTS headers: $ curl -i https://notecrypt.appspot.com/ https://notecrypt.appspot.com/ HTTP/1.1 200 OK ETag: "ibqapA" Date: Wed, 29 May 2013 18:59:37 GMT Expires: Wed, 29 May 2013 19:09:37 GMT Cache-Control: public, max-age=600 Content-Type: text/html Server: Google Frontend Transfer-Encoding: chunked ...so anyone that types "notecrypt.appspot.com" into their browser in the future will continually expose themselves to the same vulnerability. At that point I can just modify the JS that gets transmitted back to the browser such that it doesn't actually do any encryption. As always webapp-based JS cryptography is reducible to the strength of SSL. If I can break SSL, I can break your JS crypto, so there's really no point in doing the JS-based crypto. How do I collect the $1000?

deleted 13y ago
[deleted]
absherwin 13y ago
The instructions are in a note. If I understand your attack, you'd need to set up a clone website that resends the password in the clear, have a malicious network redirect me to it and get me to enter my password. I'm happy to enable to you to demonstrate that it works. The hardest part is presenting a valid SSL certificate. As I warned in the initial post, "I won't promise to log in if you can't provide a valid SSL certificate." Email me and we can arrange the details.
- michael_h 13y ago
  Didn't Iran get a valid SSL certificate for *.google.com a while ago? Edit: Found an article, by cperciva no less: http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-wrong-SSL-certificate.html http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-w...
  - marshray 13y ago
    Among others. They were using them to conduct targeted and dragnet man-in-the-middle attacks in the country for weeks or months before any users spoke up and browsers were patched.
    - dylz 13y ago
      If Chrome was involved, it aggressively refuses to use anything but the whitelisted fingerprints and will notify Google if MITM is detected for any high profile hosts.
- moxie 13y ago
  No need to setup a clone website or to obtain a valid SSL certificate. If I'm in a position to observe a notecrypt users's communication (the reason encryption is necessary), I can just run sslstrip (no SSL certificate required). It will transparently intercept all of the notecrypt users's plaintext communication to notecrypt without generating any browser warnings. At that point I also have the opportunity to modify any of the plaintext traffic as it passes by. The user will be communicating with your actual website (no need to setup a clone), but I can just modify the JS as it is transmitted to the user so that it doesn't actually encrypt anything. This attack just requires running a single command, no complex setup required. You might want to read more about sslstrip to understand how this works.
  - rarrrrrr 13y ago
    FWIW, my reading of the OP is that it's stipulated that the user will check for the presence of a valid SSL session (i.e. with in browser visual indicators) before login. BTW, have been following your work on TACK with great interest.
    - j0ev 13y ago
      That's a bad assumption. I could feasibly purchase the appsp0t.com domain, grab an ssl cert for nodecrypt.appsp0t.com, hop onto the LAN and run sslstrip, redirect the user to https://nodecrypt.appsp0t.com https://nodecrypt.appsp0t.com and wall-a, green address bar with a close looking address. That would probably fool me. The "green" indicator is nice but definitely should not be relied upon to protect the user. note: i used appsp0t as an example, no idea if its really available to be bought. Edit: it's not letting me reply to the below comment (probably because this is a new account), but afair most browsers have fixed the IDN problem by checking for "suspicious" characters (characters that look similar to roman glyphs) and forcing the URL to be rendered in the full punycode URL.
      - ryalfalpha 13y ago
        I think it's also worth pointing out in Moxie's sslstrip talk he does go into detail on using IDN http://en.wikipedia.org/wiki/Internationalized_domain_name http://en.wikipedia.org/wiki/Internationalized_domain_name to spoof something similar (for non-english TLDs). Not sure how valid that still is (as the talk is a couple of years old? I only watched it today), but it has to be assumed that a portion of users are going to fall for even a badly mimicked url. Gotta say the IDN stuff is impressive in how generalised it could be. Terrifying. I'm convinced he's owed the $1,000.
- ctz 13y ago
  You won't need any SSL. A user's typical first interaction with notecrypt will be through http://notecrypt.appspot.com http://notecrypt.appspot.com (which just needs to evil reverse proxy to the actual site or an emulation, while backdooring the javascript to send the password somewhere). The client never sees any SSL.
- wglb 13y ago
  I suggest that you concede. It is easy enough for you to demonstrate it to yourself with the components that he describes.
lawnchair_larry 13y ago
SSL vs JS crypto is kind of missing the point. There are use cases that SSL does not address. This contest is obviously silly, and I'm not defending the app, but I take issue with the "break SSL = break JS crypto" argument. sslstrip, while a legitimate issue, is closer to phishing than an attack on JS crypto. It's based on tricking the user, not breaking the protocol. I'm not trying to downplay it but I don't think it's fair to equate that with an attack on JS crypto. In an audit, I would point out the things you mention. Consider: 1. The user knows how to look at their address bar and verify that they're on HTTPS. 2. The server gets raided or changes ownership, and the new "owners" are untrusted. Now the inevitable counter argument is, "if you don't trust the server, how do you trust the JS that they are sending you?" My retort would be: 1. Such attacks wouldn't be retroactive. Data is only compromised from the point that you execute the modified JS forward. If it gets owned or raided, and you don't log in, you're still safe. If you trust just SSL, you don't gain this advantage. 2. There can be varying degrees of trust. I can trust that the site operators won't actively attack me, but not trust that the data is unreadable by anyone. Your webhost could expose your data either out of malice or carelessness. It's a significant escalation for your webhost to hijack your site and start changing the code in it. I'm not trying to suggest that JS crypto is safe or that this is a solved problem, but SSL does not provide any solution at all here. JS crypto provides a poor solution, but a much better one than only SSL (though of course it must also be used with SSL). Mega is an example of where JS crypto might have some value. For users to be charged, Mega has to not only get raided, but the feds have to keep it running long enough so users can be attacked with the malicious JS, after which their files can be decrypted. That is far better protection than the first iteration, where a raid meant they already have everything they need to charge everyone, and they just have to start digging offline.
- marshray 13y ago
  > I can trust that the site operators won't actively attack me, but not trust that the data is unreadable by anyone. Who would it be readable to if not the site operators? > Mega is an example of where JS crypto might have some value. So it might be useful to someone, somewhere as a legal subterfuge. > For users to be charged, Mega has to not only get raided, but the feds have to keep it running long enough so users can be attacked with the malicious JS Good to know that it's secure in the absence of an attacker.
tptacek 13y ago
Here it is worth pointing out that despite losing his "contest", badly, Adam Sherwin decided not to pay Moxie Marlinspike.
- euroclydon 13y ago
  It seems like there are two strains of thought in this little drama: 1) This is just stupid because JS Encryption is only as strong as the weakest link in the whole website (SSL, Third-Party Scripts, etc.) 2) Actually completing the challenge, which I assume means hijacking Adam's session and retrieving and decrypting the reward instruction note. It's okay for people to focus on point one, I suppose, because otherwise innocent people may get hurt if developers actually come away with the conclusions that JS Encryption is safe. As for point two, I think it's okay to provide an intellectual proof of success in lieu of actually doing it, but what does that mean? Doesn't it hinge, in Moxie's case, on the condition Adam states, If you want to try injecting code, I'm happy to use a network you control if we can arrange the logistics though I won't promise to log in if you can't provide a valid SSL certificate :)? Moxie would have to MITM notecrypt.appspot.com which I assume is allowed because of, I'm happy to use a network you control. However, what about the further condition, though I won't promise to log in if you can't provide a valid SSL certificate? This is unclear to me. A valid certificate to what? notecrypt.appspot.com? Moxie's tool is called sslstrip, not sslreplace, so I don't think it can provide a valid SSL Cert, in which case he would not succeed. Perhaps he would strip the SSL from the JS file only, but that might yield a mixed content warning. What am I missing?
  - danielweber 13y ago
    +1. If he's paying $1000 so he can personally witness how something like this works, rather than reading about it, it's a fine learning experience. I'll totally back away if he tries to make this into a product.
    - tptacek 13y ago
      He's not paying. He contacted Moxie Marlinspike privately, and then Moxie posted on Twitter saying he wasn't paying. So he's not only wrong, but also a weasel. A WEASEL. I said it!

by moxie 13y ago

deleted 13y ago

[deleted]

absherwin 13y ago

The instructions are in a note. If I understand your attack, you'd need to set up a clone website that resends the password in the clear, have a malicious network redirect me to it and get me to enter my password. I'm happy to enable to you to demonstrate that it works. The hardest part is presenting a valid SSL certificate. As I warned in the initial post, "I won't promise to log in if you can't provide a valid SSL certificate." Email me and we can arrange the details.

michael_h 13y ago
Didn't Iran get a valid SSL certificate for *.google.com a while ago? Edit: Found an article, by cperciva no less: http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-wrong-SSL-certificate.html http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-w...
- marshray 13y ago
  Among others. They were using them to conduct targeted and dragnet man-in-the-middle attacks in the country for weeks or months before any users spoke up and browsers were patched.
  - dylz 13y ago
    If Chrome was involved, it aggressively refuses to use anything but the whitelisted fingerprints and will notify Google if MITM is detected for any high profile hosts.
moxie 13y ago
No need to setup a clone website or to obtain a valid SSL certificate. If I'm in a position to observe a notecrypt users's communication (the reason encryption is necessary), I can just run sslstrip (no SSL certificate required). It will transparently intercept all of the notecrypt users's plaintext communication to notecrypt without generating any browser warnings. At that point I also have the opportunity to modify any of the plaintext traffic as it passes by. The user will be communicating with your actual website (no need to setup a clone), but I can just modify the JS as it is transmitted to the user so that it doesn't actually encrypt anything. This attack just requires running a single command, no complex setup required. You might want to read more about sslstrip to understand how this works.
- rarrrrrr 13y ago
  FWIW, my reading of the OP is that it's stipulated that the user will check for the presence of a valid SSL session (i.e. with in browser visual indicators) before login. BTW, have been following your work on TACK with great interest.
  - j0ev 13y ago
    That's a bad assumption. I could feasibly purchase the appsp0t.com domain, grab an ssl cert for nodecrypt.appsp0t.com, hop onto the LAN and run sslstrip, redirect the user to https://nodecrypt.appsp0t.com https://nodecrypt.appsp0t.com and wall-a, green address bar with a close looking address. That would probably fool me. The "green" indicator is nice but definitely should not be relied upon to protect the user. note: i used appsp0t as an example, no idea if its really available to be bought. Edit: it's not letting me reply to the below comment (probably because this is a new account), but afair most browsers have fixed the IDN problem by checking for "suspicious" characters (characters that look similar to roman glyphs) and forcing the URL to be rendered in the full punycode URL.
    - ryalfalpha 13y ago
      I think it's also worth pointing out in Moxie's sslstrip talk he does go into detail on using IDN http://en.wikipedia.org/wiki/Internationalized_domain_name http://en.wikipedia.org/wiki/Internationalized_domain_name to spoof something similar (for non-english TLDs). Not sure how valid that still is (as the talk is a couple of years old? I only watched it today), but it has to be assumed that a portion of users are going to fall for even a badly mimicked url. Gotta say the IDN stuff is impressive in how generalised it could be. Terrifying. I'm convinced he's owed the $1,000.
ctz 13y ago
You won't need any SSL. A user's typical first interaction with notecrypt will be through http://notecrypt.appspot.com http://notecrypt.appspot.com (which just needs to evil reverse proxy to the actual site or an emulation, while backdooring the javascript to send the password somewhere). The client never sees any SSL.
wglb 13y ago
I suggest that you concede. It is easy enough for you to demonstrate it to yourself with the components that he describes.

lawnchair_larry 13y ago

SSL vs JS crypto is kind of missing the point. There are use cases that SSL does not address. This contest is obviously silly, and I'm not defending the app, but I take issue with the "break SSL = break JS crypto" argument. sslstrip, while a legitimate issue, is closer to phishing than an attack on JS crypto. It's based on tricking the user, not breaking the protocol. I'm not trying to downplay it but I don't think it's fair to equate that with an attack on JS crypto. In an audit, I would point out the things you mention. Consider: 1. The user knows how to look at their address bar and verify that they're on HTTPS. 2. The server gets raided or changes ownership, and the new "owners" are untrusted. Now the inevitable counter argument is, "if you don't trust the server, how do you trust the JS that they are sending you?" My retort would be: 1. Such attacks wouldn't be retroactive. Data is only compromised from the point that you execute the modified JS forward. If it gets owned or raided, and you don't log in, you're still safe. If you trust just SSL, you don't gain this advantage. 2. There can be varying degrees of trust. I can trust that the site operators won't actively attack me, but not trust that the data is unreadable by anyone. Your webhost could expose your data either out of malice or carelessness. It's a significant escalation for your webhost to hijack your site and start changing the code in it. I'm not trying to suggest that JS crypto is safe or that this is a solved problem, but SSL does not provide any solution at all here. JS crypto provides a poor solution, but a much better one than only SSL (though of course it must also be used with SSL). Mega is an example of where JS crypto might have some value. For users to be charged, Mega has to not only get raided, but the feds have to keep it running long enough so users can be attacked with the malicious JS, after which their files can be decrypted. That is far better protection than the first iteration, where a raid meant they already have everything they need to charge everyone, and they just have to start digging offline.

marshray 13y ago
> I can trust that the site operators won't actively attack me, but not trust that the data is unreadable by anyone. Who would it be readable to if not the site operators? > Mega is an example of where JS crypto might have some value. So it might be useful to someone, somewhere as a legal subterfuge. > For users to be charged, Mega has to not only get raided, but the feds have to keep it running long enough so users can be attacked with the malicious JS Good to know that it's secure in the absence of an attacker.

tptacek 13y ago

Here it is worth pointing out that despite losing his "contest", badly, Adam Sherwin decided not to pay Moxie Marlinspike.

euroclydon 13y ago
It seems like there are two strains of thought in this little drama: 1) This is just stupid because JS Encryption is only as strong as the weakest link in the whole website (SSL, Third-Party Scripts, etc.) 2) Actually completing the challenge, which I assume means hijacking Adam's session and retrieving and decrypting the reward instruction note. It's okay for people to focus on point one, I suppose, because otherwise innocent people may get hurt if developers actually come away with the conclusions that JS Encryption is safe. As for point two, I think it's okay to provide an intellectual proof of success in lieu of actually doing it, but what does that mean? Doesn't it hinge, in Moxie's case, on the condition Adam states, If you want to try injecting code, I'm happy to use a network you control if we can arrange the logistics though I won't promise to log in if you can't provide a valid SSL certificate :)? Moxie would have to MITM notecrypt.appspot.com which I assume is allowed because of, I'm happy to use a network you control. However, what about the further condition, though I won't promise to log in if you can't provide a valid SSL certificate? This is unclear to me. A valid certificate to what? notecrypt.appspot.com? Moxie's tool is called sslstrip, not sslreplace, so I don't think it can provide a valid SSL Cert, in which case he would not succeed. Perhaps he would strip the SSL from the JS file only, but that might yield a mixed content warning. What am I missing?
- danielweber 13y ago
  +1. If he's paying $1000 so he can personally witness how something like this works, rather than reading about it, it's a fine learning experience. I'll totally back away if he tries to make this into a product.
  - tptacek 13y ago
    He's not paying. He contacted Moxie Marlinspike privately, and then Moxie posted on Twitter saying he wasn't paying. So he's not only wrong, but also a weasel. A WEASEL. I said it!