MitM attacks on HTTPS sessions Much of this material can also be - - PowerPoint PPT Presentation

mitm attacks on https sessions
SMART_READER_LITE
LIVE PREVIEW

MitM attacks on HTTPS sessions Much of this material can also be - - PowerPoint PPT Presentation

Software and Web Security 2 MitM attacks on HTTPS sessions Much of this material can also be seen in DEFCON 2009 presentation by Moxie Marlinspike; see URL on course page sws2 1 MitM (Man-in-the-Middle) attacks MitM attack: attacker


slide-1
SLIDE 1

Software and Web Security 2

MitM attacks on HTTPS sessions

Much of this material can also be seen in DEFCON 2009 presentation by Moxie Marlinspike; see URL on course page

sws2 1

slide-2
SLIDE 2

MitM (Man-in-the-Middle) attacks

  • MitM attack: attacker gets between the browser and the web server,

eg by – setting up a wifi access point – luring victim to his website and passing on traffic to another site

  • HTTPS (ie HTTP over TLS/SSL) should protect against this...
  • There are different ways in which this can go wrong

– on the protocol/network level – security flaws in the browser or at the Certificate Authority (CA),

  • in the software or the human/organisation
  • One particular attack is SSL stripping, invented by Moxie

Marlinspike, and implemented in sslstrip tool

sws2 2

slide-3
SLIDE 3

(Aside: name confusion on SSL vs TLS)

  • Is it SSL, TLS, SSL/TLS, or TLS/SSL?
  • SSL (Secure Socket Layer) developed at Netscape.

Version 1.0 never released. Version 2.0 had several security flaws

  • SSL 3.0 renamed to TLS, of which versions 1.0, 1.1, and 1.2 exist

sws2 3

slide-4
SLIDE 4

Reminder: weaknesses/attacks on HTTPS already discussed in week 3

  • Implementation flaws in various TLS implementations

– such as HeartBleed, iOS goto bug, or FREAK

  • Software failing to do the right certificate checks
  • Certificate Authorities being hacked
  • Software in webbrower displaying URLs incorrectly

– eg http://paypal.com%01%00@mafia.com

  • Human user of the web browser not checking things correctly

– but punycode representation of URLs is a countermeasure against user being confusing by strange character sets

sws2 4

slide-5
SLIDE 5

SSL stripping

sws2 5

slide-6
SLIDE 6

Two variants of SSL stripping

sws2 6

bank.com HTTPS HTTPS bank.com HTTP HTTPS

slide-7
SLIDE 7

SSL stripping (1)

sws2 7

bank.com HTTP HTTPS

slide-8
SLIDE 8

SSL stripping (1) HTTP + HTTPS

The idea: the attacker forces the browser to fall back to an HTTP session, and hope the user won’t notice the missing s

When can the attacker do this? If the user a) types in rabobank.nl, without https in front of it b) begins a HTTPS session by clicking on a link in a webpage that was retrieved with HTTP

sws2 8

bank.com HTTP HTTPS

slide-9
SLIDE 9

MitM attack on start of HTTPS session (b)

user MitM website some HTTP request

sws2 9

change HTTPS links to HTTP links user clicks a replaced link change HTTP request back to HTTPS request change HTTPS links to HTTP links very careful user will notice missing s in browser toolbar server thinks there is nothing wrong!

slide-10
SLIDE 10

MitM attack on starting of HTTPS session (a)

user MitM website

sws2 10

change HTTP request back to HTTPS request careful user would notice missing s in browser toolbar user types in rabobank.nl request for http://rabobank.nl redirect (302) to https://rabobank.nl redirect (302) to http://rabobank.nl change HTTPS to HTTP change HTTPS links to HTTP links brower follows redirect https://rabobank.nl server thinks there is nothing wrong!

slide-11
SLIDE 11

SSL stripping (1)

  • The MitM attacker

– strips S from HTTPS in links in traffic from server to user – puts this S back in traffic from the user to the server

  • The result
  • The attacker can now intercept a username and password that the

user sends (typically in a POST request)

  • After intercepting this information, the attacker could stop the MitM

attack, so that a secure tunnel between user & server is established – and the user can then no longer see anything wrong!

sws2 11

bank.com HTTP HTTPS

slide-12
SLIDE 12

Some problems & fixes

  • Secure cookies won’t be sent by the client’s browser over HTTP

Solution: remove the secure bit from Set Cookie instructions when forwarding traffic from the server to user

Similarly, the attacker can

  • strip content encodings (eg gzip) to simplify having to parse these
  • strip if-modified headers to prevent the web browser from reusing

cached pages

sws2 12

slide-13
SLIDE 13

Spotting this attack?

A careful user can spot this attack

  • the URL misses the s in https
  • the little lock is missing in the browser corner

Funny improvement: the attacker can add as flavicon

sws2 13

slide-14
SLIDE 14

Improvement: adding flavicon

user MitM website

... ... ... ...

sws2 14

replace HTTPS links with HTTP links and add flavicon

slide-15
SLIDE 15

The original secure site

sws2 15

slide-16
SLIDE 16

SSL stripped version

sws2 16

slide-17
SLIDE 17

The original secure site

sws2 17

slide-18
SLIDE 18

The SSL stripped version

sws2 18

slide-19
SLIDE 19

sws2 19

This window will pass username/password by https, but attacker can strip this, and reestablish the TLS session directly afterwards. Can the user still spot this?

slide-20
SLIDE 20

Moral

Moral of the last examples:

  • Never use https for a frame inside a http page
  • Never issues https requests from an http page

sws2 20

slide-21
SLIDE 21

This still happens...

sws2 21

slide-22
SLIDE 22

(old) news

  • http://kassa.vara.nl/tv/afspeelpagina/fragment/schokkend-nieuws-gevaarlijk-lek-in-

internetbankieren-ontdekt/speel/1/

  • http://webwereld.nl/beveiliging/82658-geld-stelen-via-hotspots-kon-door-lek-in-

internetbankieren

sws2 22

slide-23
SLIDE 23

SSL stripping (improved)

Can we improve things? Ideally we want to get so the user cannot notice he is not having a TLS session? For this, we have to to trick the browser into setting up a TLS tunnel to the attacker, believing it to be bank.com

sws2 23

bank.com HTTPS HTTPS

slide-24
SLIDE 24

SSL stripping (2): HTTPS+HTTPS

Different ways for attacker to set up TLS tunnel to himself from victim 1. Use a self-signed certificate for bank.com

– but warnings will scare most users away 

2. Attacker can buy domain name that looks like bank.com with international characters

– browser using puny-code may reveal this to user 

3. Attacker can redirect to mafia.com, for which he has a certificate a) and hope the user does not notice the mafia.com in address bar b) better, use characters that look like / and ? to make URL that looks like the bank’s, eg https://bank.com/Somelongname?.mafia.com

  • browser that highlights domain part of URL may warn user 

sws2 24

slide-25
SLIDE 25

SSL stripping (2): HTTPS+HTTPS

Different ways for attacker to set up TLS tunnel to himself from victim 4.

  • lder TLS implementations in browsers had a bug that allowed

attackers to create certificate for any site by extending the certificate chain, – incorrectly but without the browser noticing

sws2 25

slide-26
SLIDE 26

Certificates are chained

sws2 26

CA Certificate Intermediate Certificate Web site Certificate used to sign used to sign For example, a certificate for DigiNotar, or VeriSign For example, a certificate for science.ru.nl

slide-27
SLIDE 27

Certificates are chained

sws2 27

CA Certificate Intermediate Certificate Web site Certificate used to sign used to sign aka root certificate aka leaf certificate

slide-28
SLIDE 28

How would you implement checking these chains?

Eg in a web-browser or TLS/SSL library 1. Check that the leaf node as the name of the site you are connecting to 2. Check that the leaf node hasn’t expired 3. Check the signature 4. If the signing certificate is in the list of root CAs, then stop. 5. Otherwise, go up the chain, and start again with 2 CA = Certificate Authority

sws2 28

slide-29
SLIDE 29

Oops...

sws2 29

CA Certificate Intermediate Certificate Web site Certificate used to sign used to sign For example, a certificate for DigiNotar, or VeriSign For example, a certificate for science.ru.nl Certificate for paypal.com used to sign

slide-30
SLIDE 30

sws2 30

  • ie. this certificate is not

meant to be used to check other certificates

slide-31
SLIDE 31

Problems checking certificate chains (historic)

Two problems with certificate chains 1. Some CAs did not set CA=FALSE in Basic Constraints 2. Some browsers did not not check it, and allowed leaf certificates to be used to sign other certificates Such bugs should now all be gone... But: history repeats itself...

sws2 31

slide-32
SLIDE 32

Countermeasures to SSL stripping

  • HSTS (HTTP Strict Transport Security)

Server declares “I only talk HTTPS”

HTTP(S) Response Header: Strict-Transport-Security: max-age=15768000; includeSubDomain

  • This would stop the browser from ever issuing an HTTP request to

that domain.

  • use HTTPS Everywhere browser plugin
  • Giving that CAs may not be trustworthy anyway, Chrome will now check for

suspicious certificates issued for google.com

sws2 32

slide-33
SLIDE 33

Just when you think it’s all over…

Newer attacks on software handling X509 certificates: When talking to a CA to request certificates, an attacker may try

  • including a null character in the Common Name for which he request

a certificate, eg. paypal.com[null]mafia.com

– Different libraries interpret this differently! Which does the CA use and which does the browser use?

  • create confusing certificates with multiple Common Names, eg.

paypal.com,mafia.com

– Internet Explorer will respect all names in the list, Firefox will only respect the last one, and how has the CA interpreted this?

  • a SQL injection attack in the Certificate Signing Request to the CA

sws2 33

slide-34
SLIDE 34

Other attacks on sessions (out of scope for this course)

  • Cryptographic attacks on TLS

– Inherent cryptographic weakness in TLS/SSL is that encryption and MAC-ing are done the wrong way around

  • you should first encrypt, and then MAC

– Some cryptographic primitives used may be weak

  • eg using MD5 as hash function in certificates
  • attacks on DNS

– eg DNS cache poisoning – will be discussed in the Networking Security course next semester

sws2 34

slide-35
SLIDE 35

Advanced cookie stealing: without breaking HTTPS tunnel

Even without breaking the HTTPS tunnel, an attacker may be able to steal cookies namely if bank.com fails to set the secure flag for its cookie. (Recall: the secure flag means the cookie is only sent over HTTPS)

sws2 35

bank.com HTTPS

slide-36
SLIDE 36

Alternative MitM attack: stealing HTTPS cookies

Attack steps 1. user logs on to HTTPS://bank.com 2. server sets session ID for bank.com in cookie – which is encrypted in HTTPS-traffic 3. user ask for an unencrypted HTTP request (eg for http://nu.nl) 4. MitM attacker replies with a redirect to http://bank.com 5. Browser follows redirect and sends the bank’s cookie over HTTP 6. Bingo! Attacker has the cookie

sws2 36

bank.com HTTPS HTTP

slide-37
SLIDE 37

Still, using TLS is a hurdle to an attacker

sws2 37

slide-38
SLIDE 38

To watch

  • For another explanation of SSL stripping, see the video of Moxie

Marlinspike’s presentation at DEFCON This also presents – an improvement, where session cookies that already exists when the MitM attack starts are invalidated to force users to re- enter username & password – experimental results of running SSL-stripping at a Tor exit node

sws2 38