HEIST Vulnerability – Overview and BIG-IP Mitigation
An interesting topic was talked about in the recent Black Hat conference. It is a new attack called HEIST (HTTP Encrypted Information can be Stolen through TCP-windows) which demonstrates how to extract sensitive data from any authenticated cross-origin website. What makes this attack unique is the ability to execute without any sort of traffic eavesdropping or man-in-the-middle scenarios. The attack happens in the browser, upon visiting an attacker-controlled website. Basics of a HEIST The HEIST attack, as described by Leuven University researchers Mathy Vanhoef and Tom Van Goethem, makes use of a new browser feature called Service Workers and specifically a new interface called Fetch API. The Fetch API, much like XMLHttpRequest (XHR), allows for arbitrary requests to be sent from the browser. These requests may also include sensitive authorization information such as session cookies. It is obviously not so trivial to read the responses from requests sent by Fetch API or XHR, due to the Same-origin Policy (SOP) enforced by the browser. However, it may be possible to use side channel attacks to infer information about the size of the response and in certain circumstances even extract personal data. No Empty Promises The attack uses the Fetch API and its performance measuring tool. Shortly after an arbitrary request is sent using Fetch API, the browser creates a Promise object in the DOM. This object is created once the browser starts receiving data from the server. A “responseEnd” attribute is added to the object once the browser fully receives the entire data. The “patent” of the attack is knowing whether the response consisted of either one TCP packet, or more. That is by measuring the time between the Promise object creation and “responseEnd”. This allows the attacker to detect an approximate size of any page, as it appears to the victim. For pages that reflect user-input data, the attacker may detect the exact size of the response. Can I (Ab)Use? Service Workers are supported in the following browsers: This table shows that a rather large majority of browsers in the market today already support Service Workers. The trend is expected to grow as Service Workers are useful with creating dynamic and responsive web applications. Source: http://caniuse.com/#feat=serviceworkers Call the Police! In this section we’ll go over possible mitigations, including solutions available for BIG-IP users. Disable third-party cookies The researchers list disabling third-party cookies as the only real mitigation for this attack. By disabling this functionality, the browser won’t send authorization information in Fetch API and XHR requests made to cross-origin domains. Pros: Completely disables the attack. Cons: The setting happens in the browser. Web servers cannot enforce this setting upon users. Also, it is unclear what functionality may be hampered by disabling third-party cookies. Applying data in varying lengths to responses The researchers also list this action as a possible mitigation. The idea is to add data at random lengths to every response. This will considerably affect the attacker’s ability to understand what is the actual response length. The original attack requires up to 14 requests in order to detect the exact response length. By adding random data in different possible lengths, the attacker may have to work much harder and be more aggressive towards the web server. The following is an iRule that adds this functionality to BIG-IP virtual servers: when HTTP_RESPONSE { set sRandomString {} set iLength [expr {int(rand() * 1000 + 1)}] for {set i 0} {$i < $iLength} {incr i} { set iRandomNum [expr {int(rand() * 62)}] if {$iRandomNum < 10} { incr iRandomNum 48 } elseif {$iRandomNum < 36} { incr iRandomNum 55 } else { incr iRandomNum 61 } append sRandomString [format %c $iRandomNum] } HTTP::header insert X-HEIST $sRandomString log local0. "Added random header X-HEIST: $sRandomString" } This iRule will add a random string as a response header called “X-HEIST”. The string length ranges between 1 and 1000 chars. Pros: Adds significant complexity to the attack, possibly until the point that it is no longer feasible. Cons: Doesn’t completely shut down the vulnerability. In some cases, where the exact response length isn’t interesting to the attacker – this approach alone may be less effective. Block unknown origins Fetch API and XHR requests often add a request header that describes from which domain the request originated. For example, an XHR request in a script that runs on “http://attacker.com” will add the following request header: Origin: attacker.com The Origin header is not meant to be used as an access list for security needs. However, it is generally good practice to only allow known domains to be able to send Fetch API or XHR requests. This configuration is available in BIG-IP ASM (version 11.5.0 and up), under Security >> Application Security : URLs : Allowed URLs : Allowed HTTP URLs >> Allowed HTTP URL Properties: Pros: A request with an unknown Origin will be blocked by ASM, disallowing the browser from performing this attack. Cons: It may be challenging for website admins to create an allowlist of accepted domains. For public APIs it is often desired to allow all origins. In addition, there are some cases where the Origin header isn’t added to the request. Web Scraping protection Enabling Web Scraping protection in ASM may prevent this attack. Web Scraping protection is configurable under Security >> Application Security : Anomaly Detection : Web Scraping. Combining this protection with the iRule mentioned above creates adequate mitigation for this attack. By adding length randomization, the amount of requests the attacker must send is significantly increased. This will trigger Web Scraping detection in ASM once it is enabled. Furthermore, during the attack period the browser will fail answering the JavaScript challenges sent by ASM and therefore not receive the desired result from the server. Conclusion The HEIST attack is a unique and original form of attack. It uses legitimate functionality like cross-origin requests, and is based on known variables such as TCP slow start algorithm defaults. The attack uses side channel to retrieve data from cross-origin sources, despite the SOP protection found in browsers. As the researchers claim, the only real effective mitigation to this attack is disabling third-party cookies in the browser. However, using ASM and iRules we’ve shown that it’s possible to effectively mitigate this 0-day vulnerability using the tools and protections already found in BIG-IP.
Is it possible to query ad Server to check for user presence?
The way I see how it suppose to be working Logon Page - AD Query to check for user presence - if user present try to authenticate. If the user is not present append domain name and use AD Server with cross domain support I couldn't find any session variable that let me do this One possible solution is to to use AD Query with "expr { [mcget {session.ad.last.queryresult}] == 1 }" if it fails - send over to AD server with cross domain support. I don't think that from design standpoint is the best solution because what if the user typed in wrong password? Any help is appriciated