1 / 22

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 University May 20 th , 2009. HTTPS and Its Adversary Assumption.

benjamin
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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?

  3. 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

  4. The Pretty-Bad-Proxy (PBP) adversary Browser PBP HTTPS server Rendering modules HTTP/HTTPS HTTP/HTTPS Unencrypted TCP/IP TCP/IP SSL tunnel, encrypted

  5. 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)

  6. Attack 1: error response • Proxy’s error page: e.g., 502-server-not-found, other 4xx/5xx response; • Script in error page runs in https://bank.com. Bank server browser PBP <iframe src= “https://bank.com”> https://bank.com 502:Server not found https://bank.com

  7. Attack 2: redirection (3xx) <script src=“https://js. bank.com/foo.js”> bank.com server browser PBP https://bank.com https://js.bank.com evil.com server https://evil.com HTTP 302: redirection to https://evil.com Script will run in the context of https://bank.com

  8. Attack 3: HTTP-Intended-But-HTTPS-Loadable Pages (HPIHSL pages) • Many websites provide both HTTP and HTTPS services • 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!. • What’s wrong with HPIHSL pages? • They often import scripts through HTTP • The scripts will run in the HTTPS context. sensitive Non-sensitive HPIHSL HTTP scripts

  9. 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 …

  10. Bypassing the detection logic (attack 3 cont.) • Using an HTTPS iframe in an HTTP top level page. Top level: HTTP Attack script to run in the HTTPS context Hidden iframe: HTTPS for an HPIHSL page http://resources.jcpenny.com/foo.js

  11. 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

  12. 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.

  13. Attack 4 continued • A perfect GUI spoofing attack • Fresh browser, single tab, address bar input Schedule a one-second timer for refreshing the page. <head> <meta HTTP-EQUIV=“Refresh” CONTENT=“1; URL=https://www.paypal.com”> </head> Before the timer is expired, cache a PayPal certificate <img src=“https://www.paypal.com/a.jpg” style=“display:none”> a response page Get a.jpg from the real server the phishing page (5xx)

  14. Feasibility of Exploitations

  15. 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?

  16. 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

  17. 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 GET /wpad.dat return goodProxy_cfg return PBP_cfg attacker

  18. Vulnerability status (more recent than the camera-ready version) Besides point fixes, how can we systematically prevent (or find) these bugs? Future PBP issues

  19. 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 (WiFi 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

  20. Rendering modules Conclusions and Future Work HTTP/HTTPS • The PBP adversary • Targeting the rendering modules • Encrypted/unencrypted contents confused TCP/IP • Developers of rendering modules need to deal with MITM • 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?

  21. 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.

  22. Advertising OCCUR: Open Chronologist for Currently Undisclosed Research • 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 VeriSign • Details: search for “Microsoft OCCUR” or ask me offline http://research.microsoft.com/en-us/projects/occur/

More Related