Pretty-Bad-Proxy An Overlooked Adversary in Browsers HTTPS Deployments

Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments Shuo Chen†, Ziqing Mao† ‡, Yi-Min Wang†, Ming Zhang† †Microsoft Research ‡Purdue May 20 th, 2009 IEEE Symposium on Security and Privacy, May 2009 University

HTTPS and Its Adversary Assumption HTTPS: end-to-end secure protocol for web traffic. Adversary assumption: MITM (man-in-the-middle). HTTPS server proxy browser Internet SSL tunnel Are today’s browser implementations consistent with this assumption? IEEE Symposium on Security and Privacy, May 2009 2

Our research Key finding A class of browser vulnerabilities (demo) proxy can defeat end-to-end security promised by HTTPS Vulnerabilities exist in all major browsers Industry outreach Technical work finished in summer 2007 Paper withheld until this conference Worked with all vendors to address the issues IEEE Symposium on Security and Privacy, May 2009 3

The Pretty-Bad-Proxy (PBP) adversary Browser PBP HTTPS server Rendering modules HTTP/HTTPS Unencrypted TCP/IP SSL tunnel, encrypted IEEE Symposium on Security and Privacy, May 2009 4

Attacks in this talk Key issue: browsers load unencrypted content from proxy in the HTTPS context of the victim server Attack 1: Proxy’s error response Attack 2: Proxy’s redirection Attack 3: HTTP-intended pages that are HTTPS loadable Attack 4: Visual context (GUI behavior, no script) IEEE Symposium on Security and Privacy, May 2009 5

Attack 1: error response Proxy’s error page: e. g. , 502 -server-not-found, other 4 xx/5 xx response; Script in error page runs in https: //bank. com. browser PBP Bank server https: //bank. com 502: Server not found https: //bank. comsrc= <iframe “https: //bank. com”> IEEE Symposium on Security and Privacy, May 2009 6

Attack 2: redirection (3 xx) bank. com server browser PBP https: //bank. com https: //js. bank. com https: / /evil. co m HTTP 302: redirection to https: //evil. com <script src=“https: //js. bank. com/foo. js”> evil. com server Script will run in the context of https: //bank. com IEEE Symposium on Security and Privacy, May 2009 7

Attack 3: HTTP-Intended-But-HTTPS-Loadable Pages (HPIHSL pages) Many websites provide both HTTP and HTTPS services What’s wrong with HPIHSL pages? sensitive HPIHSL Sensitive pages, e. g. checkout HTTPS only Non-sensitive pages, e. g. , merchandise Intended for HTTP access However, non-sensitive pages are often accessible through HTTPS as well!. Non-sensitive They often import scripts through HTTP The scripts will run in the HTTPS context. HTTP scripts IEEE Symposium on Security and Privacy, May 2009 8

Attack 3 continued Browsers warn about HTTP resource in HTTPS contexts, don’t they? The detection logic is only to determine the address bar’s appearance Address bar only concerns top level page, so … IEEE Symposium on Security and Privacy, May 2009 9

Bypassing the detection logic (attack 3 cont. ) Using an HTTPS iframe in an HTTP top level page. Top level: HTTP http: //res Hidden iframe: ources. jcpenny HTTPS for an. com/fo o. js HPIHSL page Attack scr ipt to ru n in the IEEE Symposium on Security and Privacy, May 2009 HTTPS context 10

How pervasive? (attack 3 cont. ) Very easy to find HPIHSL pages that import scripts The paper shows 12 websites having this problem. These HTTPS domains are not trustworthy. They cover a wide range Online shopping sites Banks, credit card companies Open source projects management site Top computer science departments Even the home domain of a leading certificate authority IEEE Symposium on Security and Privacy, May 2009 11

Attack 4: Visual context In attack 1, script in proxy’s error page runs in the HTTPS context. (all browsers) This attack No script, only static HTML Due to GUI behavior IE, Opera and Chrome display a certificate on the GUI as long as it is in the certificate cache. IEEE Symposium on Security and Privacy, May 2009 12

Attack 4 continued Schedule a one-second timer for refreshing the page. a respons e page e h from t g et a. jp G the phishing page (5 xx) <head> <meta HTTP-EQUIV=“Refresh” CONTENT=“ 1; URL=https: //www. paypal. com”> </head> r serve real Before the timer is expired, cache a Pay. Pal certificate <img src=“https: //www. paypal. com/a. jpg” style=“display: none”> A perfect GUI spoofing attack Fresh browser, single tab, address bar input IEEE Symposium on Security and Privacy, May 2009 13

Feasibility of Exploitations IEEE Symposium on Security and Privacy, May 2009 14

Threat level 1: when the proxy is malicious Proxies are used in many environments Corporate and university networks Hospitals, hotels Third-party free proxies Due to PBP issues, security of HTTPS communication depends on proxy’s integrity Is proxy infected by viruses, hijacked by attackers or configured by malicious insiders? IEEE Symposium on Security and Privacy, May 2009 15

Threat level 2: even without a compromised proxy All these attacks work as long as (1) Attacker can sniff your machine at the link layer For HTTPS, you need to assume this. (2) The browser has its proxy capability ON WPAD: Web Proxy Auto Discovery PAC script: Proxy Auto Config script Manual configuration IEEE Symposium on Security and Privacy, May 2009 16

Attack tests Our test bed Proxy required for web traffic to the Internet WPAD (default), PAC-script-config or manual-config Tested on Ethernet Tested on open wireless network GET /wpad. dat return good. Proxy_cfg return PBP_cfg attacker IEEE Symposium on Security and Privacy, May 2009 17

Vulnerability status (more recent than the camera-ready version) IE 8 (since Firefox beta 2) 3. 0. 10 Fixed Error-response issue Redirection issue N/A HPIHSL issue fix suggested Fix proposed for next version Cachedcertificate Fixed issue Future PBP issues Fixed N/A Safari 3. 2. 2 (or Opera since Chrome before) Dec. 2007 1. 0. 154. 53 Fixed Fixed N/A Acknowledged N/A Fixed Besides point fixes, how can we systematically prevent (or find) these bugs? IEEE Symposium on Security and Privacy, May 2009 18

Mitigations by securing the network Not a fundamental “solution” HTTPS security should not depend on the network. However, it is worthwhile to have mitigations Some issues not patched New issues found in the future Mitigations Wireless router: use WPA (Wi. Fi Protected Access) Corporate network: deploy IPSec on many types of servers Not only web servers, but DNS, DHCP, PAC servers Travelling employees: secure-VPN to your corporate networks IEEE Symposium on Security and Privacy, May 2009 19

Conclusions and Future Work The PBP adversary Targeting the rendering modules Encrypted/unencrypted contents confused Rendering modules HTTP/HTTPS Developers of rendering modules need to deal with MITM TCP/IP HTTPS layer not masking MITM for rendering modules. Beyond HTTPS Other end-to-end protocols: Kerberos, IPSec, etc E. g. , HTTP over IPSec, using Kerberos authentication What do you want to achieve if a proxy is in between? IEEE Symposium on Security and Privacy, May 2009 20

Potential misinterpretations HTTPS is flawed. We argue that many proxies are not secure enough to tunnel HTTPS. We advocate link layer security. In addition to browser issues, we also show issues in WPAD, etc. IEEE Symposium on Security and Privacy, May 2009 21

Advertising http: //research. microsoft. com/en-us/projects/occur/ A free web service for timestamping research ideas Why: some research contributions cannot be published immediately, e. g. , due to responsible disclosure policy. What: OCCUR gives your idea a timestamp from Veri. Sign Details: search for “Microsoft OCCUR” or ask me offline IEEE Symposium on Security and Privacy, May 2009 22