12

I need help understanding the dynamics of an sslstrip attack. I'm using it to test the security of a site that I own. I can successfully sniff the victim (in this case, myself) credentials over the internet but when the same attack happens against Gmail or MSN traffic I get no stuff back. It is completely static in that case. I'm using a go-daddy certificate to secure my ssl exchange.

Does it mean their ssl is secure and mine is not? Like the rogue ssl cert generated by sslstrip is caught and blocked by their ssl cert security and mine is configured in a insecure mode? Do devices like KEMP load balancer do anything to prevent such attacks?

What do I need to do to prevent my site from such attacks? Thanks.

curiousguy
  • 5,038
  • 3
  • 25
  • 27
Saladin
  • 1,547
  • 3
  • 14
  • 23

2 Answers2

9

IIRC, SSLStrip does not do a traditional SSL-MITM attack. What it does is watch HTTP traffic, look for links and redirects to HTTPS traffic, and rewrite those links/redirects to HTTP. A quick look at their website confirms this.

So, you must have some non-ssl page which links/redirects to an ssl page. SSLStrip sees that and changes the link/redirect to a non-secured link/redirect. For example, you might have index.php linking to https://domain.com/login.php. SSLstrip changes it to http://domain.com/login.php. You could verify this by typing into your browser https://domain.com/login.php and see if SSLStrip still sees the username and password (or when you click on the login link, see if it has http or https in the url bar in the browser).

You thwart this attack by

  1. Make your site only SSL.
  2. For whatever webserver you use (Apache, IIS, etc), there should be a way to force certain directories to only be accessable over SSL connections. Make all authenticated content SSL-only. A simple google search should reveal how to do this for a given piece of server software.
mikeazo
  • 2,827
  • 13
  • 29
  • 4
    Suggestion 2. problematic, since the attacker can use https to access the server, but still present it as http to the user. – CodesInChaos Jan 25 '12 at 15:01
  • @CodeInChaos, agreed, but the attack you are talking about is completely different from what SSLStrip does, and the question is about thwarting SSLStrip. – mikeazo Jan 25 '12 at 17:17
  • @mikeazo but sslstrip could easily be modified to use the HTTPS page – curiousguy Jun 26 '12 at 04:44
  • I'm conscious my comment comes 9 years after this answer, but the first link is broken. – jub0bs Mar 01 '21 at 11:30
2

IIRC you should get a warning when going over HTTPS that the certificate has a mismatch, unless you have the real certificate.

SSLstrip rewrotes HTTPS to clear HTTP apparently.

Also why would SSL strip use a "rogue" public key ? It uses the public key of the website.

There is a way to secure yourself, but your browser needs to support it. (read down)

The reason why it doesn't work is because you are probably doing it with Chrome or Firefox or any other major browser. They use HTTP Strict Transport Security.

It has two properties :

  1. Automatically turn any insecure links to the website into secure links. (For instance, http://example.com/some/page/ will be modified to https://example.com/some/page/ before accessing the server.)
  2. If the security of the connection cannot be ensured (e.g. the server's TLS certificate is self-signed), show an error message and do not allow the user to access the site.
Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
  • Thanks for your help. I made an error in the public key comment you are right since the attacker posses itself as rogue CA and generates a public key on its behalf so anything encrypted using 'his' public key would automatically gets decrypted on his end in the man in middle attack. – Saladin Jan 25 '12 at 05:19
  • But this doesn't answer my question i want to know why the same attack doesn't work in gmail or yahoo scenario? Why they are protected and not me. – Saladin Jan 25 '12 at 05:20
  • updated my answer – Lucas Kauffman Jan 25 '12 at 06:44
  • 2
    SSLStrip doesn't do an SSL MitM attack. It does a MitM attack on normal HTTP connections and watches for links/redirects to HTTPS pages and rewrites them as HTTP links/redirects. – mikeazo Jan 25 '12 at 12:34
  • I launched the attack using same browser my choice remained the same it was just google guys were smart enough to detect the mismatch certificate and mine did not. I can see there is clear difference in fingerprint of the cert the one i had originally from gmail and the one that was sent over using the redirect through attacker system bearing a different md5 and sha1 fingerprint. It was of this reason i think i got the following error msg from gooogle guys Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate.. – Saladin Jan 25 '12 at 17:09
  • I know that the two hashes must match in order to have positive verification of the certification. Is it because since the victim now tries to encrypts data using a changed / altered public key (sent via attacker) the sever now when attempts to compute the same hash on its end see a different number and throws an alert? or pop-msg... – Saladin Jan 25 '12 at 17:10
  • 2
    @user970533, SSLStrip does not do anything with certificates AFAIK. – mikeazo Jan 25 '12 at 17:19
  • @mikeazo yeah you are right it does not i have checked the entire source code but it does make the victim receives a second copy of the public key from the targeted website. – Saladin Jan 25 '12 at 17:38
  • in short this is what em trying to say hash(server_skey(a))!=hash(different_publickey(a)) – Saladin Jan 25 '12 at 17:40
  • When i launch this sslstrip based attack and im using XMLHTTPRequest over SSL and pull the cert out of that connection (using javscript command firefox addon). In case of hijacked session it fires the security state flags as "insecure". This happens in case of gmail. I run the script before and after attack the only thing that changes is the fingerprint section which seems quiet obvious now. I believe trust is based on first come basis (the first timestamp and everything) if there is a change the hash changes. – Saladin Jan 25 '12 at 17:49
  • @user970533 "_the attacker posses itself as rogue CA_" which attacker? which rogue CA? – curiousguy Jun 26 '12 at 04:47
  • @Lucas Kauffman just to update i didn't change any browser for the attack. Both attacks was done from the same browser which is firefox. – Saladin Sep 07 '12 at 17:59
  • @curiousguy from rogue i mean tampered attack machine is one where sslstrip is active. If the public cert is same as website why does java script command behavior say its insecure. It says insecure because on the server end ; either the hash doesn't match when the data is decrypted or some other integrity parameters that has been changed on transit. All asymmetric encryption provides some kind of non-repudiation i'm sure this behavior is violation of some sort security property. – Saladin Sep 07 '12 at 18:03