230 likes | 727 Views
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.
E N D
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
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?
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
The Pretty-Bad-Proxy (PBP) adversary Browser PBP HTTPS server Rendering modules HTTP/HTTPS HTTP/HTTPS Unencrypted TCP/IP TCP/IP SSL tunnel, encrypted
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)
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
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
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
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 …
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
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
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.
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)
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?
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
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
Vulnerability status (more recent than the camera-ready version) Besides point fixes, how can we systematically prevent (or find) these bugs? Future PBP issues
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
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?
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.
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/