Web Security and

Man In The Middle Attack

Dec 10, 2018

Dr. Ram P Rustagi rprustagi@ksit.edu.in rprustagi@gmail.com

Overview• Security in Web • Security by HTTPS • MITM • Dealing with MITM • Experimentation

!2

Resources• https://www.computer.org/cms/Computer.org/

computing-edge/ce-oct17-final.pdf • IEEE Computing Edge: CyberSecurity

• Phishing: Safe banking tips from ICICI Bank • https://www.icicibank.com/online-safe-banking/

phishing.page • Experiential learning of networking technologies ▪ http://rprustagi.com/ELNT/Experiential-Learning.html

!3

Overview• Security in Web • Security by HTTPS • MITM • Dealing with MITM • Experimentation

!4

Security in the Web• At start of internet (TCP/IP)

❖ All protocols are in clear text ❖ Interent was inherently secure. ❖ Initially confined to academics

❖ Security came with commercialization ❖ Phishing

!5

Phishing Email

!6

Internet Security - Quotes• Vinton G Cerf

❖ “We didn’t focus on how you could wreck this system intentionally, You could argue with hindsight that we should have, but getting this thing to work at all was non-trivial.”

❖ Janet Abbate, author of “Inventing the Internet” ❖ “People don’t break into banks because they’re not

secure. They break into banks because that’s where the money is.”

❖ “They thought they were building a classroom, and it turned into a bank.”

!8

Internet Security - Quotes• Crocker on early DARPA design stage

❖ “Back in those days, the NSA still had the ability to visit a professor and say, ❖ ‘Do not publish that paper on cryptography’”

❖ Nuemann, CS Prof, RISKS Digest 1985 ❖ “The fundamental problem is that security is always

difficult, and people always say, ❖ ‘Oh, we can tackle it later,’ or, ‘We can add it on

later.’ But you can’t add it on later, ❖ “You can’t add security to something that wasn’t

designed to be secure.”

!9

Overview• Security in Web • Security by HTTPS • MITM • Dealing with MITM • Experimentation

!10

exam.msrit.edu (Chrome Browser)

!11

exam.msrit.edu (Firefox Browser)

!12

exam.msrit.edu (Firefox Browser)

!13

HTTPS Authentication• Server provides website certificate, having

– Website name e.g. mywww.com– Certificate validity period (typically 1 year)– Public key of certificate issuing authority

• Authentication mechanisms– Browser checks for all 3 pieces of information– Any violatation flags a warning

• User has to click-thru to proceed• Examples:

– https://172.217.166.100 #google – https://mygoogle.com #google IP in /etc/hosts – https://mywww.com #self signed certificate

!14

SSL Certificates

• Certificate types– DV (Domain Validation) - the basic type

• Webserver authentication and encryption only– OV (Organization Validation) certificate

• Verifies the actual business that is requesting• Organization name is listed in the certificate

– Extended Validation (EV)• Provides a green address bar in the browser• Requires stronger authentication process to confirm

the identity of business

!15

Mixed Content Webpage

!16

Secure, No Mixed Content

Potentially Unsecure, Passive Content is not blocked

Potentially Unsecure, Active Content is not blocked

Insecure Password Field in Form

• Quite often, web developers use form tag – <input type=“password” …> in the form.

• When this form is accessed with HTTP, it becomes in secure access.

• Browsers are by default configured to throw a warning when password field is submitted on HTTP.

!17

Example Resources

• Create your own content or download from following URLs https://rprustagi.com/workshops/web/pure.html https://rprustagi.com/workshops/web/mixed.html https://rprustagi.com/workshops/web/mixed-active.html https://rprustagi.com/js/mywww.js

!18

Secure Web• The default protocol: HTTPS • Can HTTPS be broken?

❖ A browser today 650+ certificate authorities ❖ https://www.eff.org/files/colour_map_of_cas.pdf ❖ Attacker needs just one of these which is

breakable ❖ Compromise a router near victim

❖ Redirect DNS responses/emails ❖ Compromise a DNS server

❖ Comparatively easy job ❖ Govermental intervention

❖ CA is forced to crate a malicious certificate

!19

Secure HTTP (HTTPS)• A user authenticates a website, which involves

❖ Website name i.e. FQDN ❖ Validity period ❖ Certificate issuing authority.

❖ Violation of above ❖ Any browser warns user before proceeding ❖ Example: Access google with https using IP address

!20

Secure HTTP Analogy

!21Can the screws be opened from other side

Secure HTTP Analogy

!22Locksmith can easily open the door

HTTPS Deployment Challenges• Any network that requires authentication

❖ The network site hijacks the URL ❖ e.g. public hotspots, colleges

❖ Redirects to authentication URL ❖ On successful authentication, user is permitted access ❖ This setup does not work with HTTPS

❖ On hijack of HTTPS traffic, ❖ Browser will show warning

❖ Try accessing a msrit.edu using HTTPS ❖ You are likely to see a warning web page.

!23

Overview• Security in Web • Security by HTTPS • MITM • Dealing with MITM • Experimentation

!24

What is MITM Attack• An attack where the attacker secretly captures

• Possibly alters the communication between two parties

• While parties believe that they are directly communicating with each other

!25

Typical E-commerce Traffic w/o MITM

!26

• Typical Usage: User enters ecomm.site • Gets the web page displayed • Proceeds with transaction

User-A

User-X ecommsite.com

User-A

User-X

AP/Router

ecomm.site

User-A1. http://ecomm.site

2. 302 Redirect to https://ecomm.site

3. New request to https://ecomm.site

4. Setup of HTTPS Session

5. Secure Data Exchange

4. Setup of HTTPS Session

1.

2.3..

4, & 5.

ecomm.site

Typical E-commerce Traffic w/ Attacker

!28

• Typical Usage: User enters ecomm.site • Attacker hijacks the session • Gets the web page displayed with subtle changes • User does not notice it, provide credentials, and

• proceeds with transaction • Attacker steals the credentials

ecomm.site

ARP Spoofing• Objective: When A & C communicate, B can snoop • Use ARP Spoofing to fool A & C go via B • Attacker machine

• Become a router to forward traffic • Run tcpdump to capture traffic

• Why ARP Spoofing works?

!29

172.25.4.x 172.25.4.y 172.25.4.z

A CB

LAN

MITM Attack• Convert B into a router • sudo sysctl -w net.ipv4.ip_forward=1

• Insstall ARP Sniffer on B • sudo apt install dsniff

• Issue ARP Spoof command on B for A & C • arpspoof -i <i/f> -t <Address of A> -r

<Address of C> • Run wireshark on B for IP address of A & C

• capture filter: host <A> or host <C> • Let A & C chat • Run tcpdump on B (between A and C)

!30

User-A

User-X

AP/Router

ecomm.site

User-A 1. http://ecomm.site

3. 302 Redirect to https://ecomm.site

4. New request to https://ecomm.site

5. Setup of HTTPS Session

6b Secure Data Exchange with eavesdropping

1.

2.3.

6a

ecomm.site

4.

56b

User-X (MITM Attacker)

2. http://ecomm.site

6a. HTTP Response & Data Exchange

Traffic Flow with MITM Attacker• Step 0: Attacker sets up the hostile environment

• Using ARP Spoofing, and • Open src package dsniff • Makes silent ARP changes in victim m/c • Makes silent ARP changes in local router • All traffic between user and router goes via

attacker • Using SSLStrip

• Open src package sslstrip • Converts HTTPS urls to HTTP and vice versa

!32

Traffic Flow with MITM Attacker• Step 1: User types ecomm.site in browser • Step 2: HTTP packets instead of going to local router, are

delivered to attacker’s system. • Pkt still has Src IP of victim, and dst IP of ecomm.site

• Step 3: Attacker forwards the request via local router to ecomm.site (becomes initiator)

• Step 4: ecomm.site server sends redirect to using https • Step 5: local router sends HTTP Response (IP packet) to

attacker instead of victim • Pkt has Src IP of ecomm.site, and dest IP of victim

• Step 6: Attacker initiates HTTPS request to ecomm.site • Step 7: ecomm.site responds with web page

!33

Traffic Flow with MITM Attacker• Step 8: Attacker manipulates web page

• Replaces all references to HTTPS with HTTP • SSLStrip does it automatically

• Step 9: Victim sees the same look and feel as before. • Does not notice that it is not HTTPS

• Step 10: Victim enters credentials and sends • Step 11: The HTTP packet with credentials is delivered

to attacker • Attacker records the information (e.g.tcpdump) • Forwards the response on HTTPS to ecomm.site

• Summary: ecomm.site believes everything is HTTPS which is true. Victim is unaware of credentials stealth.

!34

Why MITM Works?• User does not enter HTTPS with URL. It just types

ecomm.site • A typical user is not aware that any credential

information should be entered • Only if there is Green lock symbol before URL

• User has no knowledge of how L3 and L2 of networking works. • Has no means of verifying that data is not going to

local router but to an attacker. • Any IT dept (of organization) is typically short-staff and

believes that no attacks happening internally.

!35

Web Scenarios for MITM• Plaintext HTTP mechanism

• Simple ARPSpoofing is good enough • HTTPS access with HTTP redirection from HTTP

• SSLStrip is helpful for attacker • Using HSTS

• First time usage is hackable.

!36

Overview• Security in Web • Security by HTTPS • MITM • Dealing with MITM • Experimentation

!37

Avoiding MITM Attacks?• Sol 1: Educate the user

• User must enter HTTPS before the URL • Practically not possible to educate billion users

• Sol 2: Enforce the browser vendors to intiate all traffic with HTTPS • Proxies won’t work • URL hijack for auth won’t work • Note: Chrome marks site is not secure

• Sol 3: Empowering IT • IT dept runs MITM tools, • Detects any MITM activities • Challenges: Typical IT is not capable

!38

Avoiding MITM Attacks?• Sol 4: A responsible website responds only to HTTPS

• Does not respond to HTTP • Challenge: User stills enters HTTP

• It will lose business when user does not see response

• Entity does not want to lose business. • Sol 5: Make ARP entries static in router and victim m/c

• Challenge: Practically impossible • User needs to understand how ARP works.

!39

Avoiding MITM Attacks?• Sol 6: Use HTTP Strict Transport Security (HSTS)

• HSTS: https://tools.ietf.org/html/rfc6797 • A mechanism incorporated by the web server • Instructs browser to always initiate requests with

HTTPS • Even if user enters http://<website>

• Ensures that once a browser receives HSTS header • Strict-Transport-Security: max-age=31536000; includeSubDomains

• Browser initiates HTTPS always

!40

Inadequacies of HSTS Mechanism• When user visits website first time, and website

responds with HSTS header • The MITM attacker can still manipulate the response

and remove HSTS header. • User is subject to attack on first time access.

!41

HTTP Headers for Secure Web• HSTS: HTTP Strict Transport Security • Avoiding XSS

• use Secure; HttpOnly in Set-Cookie • X-XSS-Protection: 1

• Avoid guessing by a browser • X-Content-Type: nosniff • Uses content only when Content-Type is

provided • Use Content-Security-Policy

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

!42

Summary• Web is inherently insecure • Take precaution

• Avoid Man In the Browser attack • Use HTTPS by default

• Experimental learning • Do not try MITM in the lab without authorization. • Consequences can be fatal.

!43

Thank You

!44