In a recently discovered (but yet to be fully publicized) attack, security researcher James Kettle has apparently succeeded in cache poisoning, the hacking and weaponizing of the web caches of several major websites and online platforms.
The victims include online stores, a software product, a video game, a popular cloud platform provider, a hosting platform provider, an investment company’s investor information, and a US government agency. And the attack differs from previous methods of exploiting web caches, in that Kettle’s research succeeds in priming them so that malicious content is directly delivered to website visitors or users of a platform.
But what are web caches? And how have hackers been exploiting, and now ultimately weaponizing them as tools against unwary internet users? We’ll begin by examining that first question.
What Are Web Caches?
A web cache is a storage space or repository which sits between one or more web servers (also known as origin servers) and a client (web browser, mobile app, etc.), or many clients. Its job is waiting for network requests to come in, and saving copies of the responses. These might take the form of web pages (HTML documents), images, or other types of files, and are collectively known as representations.
If another request is made for the same web address or URL, the web cache can use the response that it stored before, rather than relaying back a fresh request to the origin server. So, web caches sit as a sort of buffer in front of websites, serving up stored content from a location closer to the user, rather than all of the delivery coming remotely from the live website.
Relevant information about each website in the cache is stored in a table called a DNS Lookup table, and a simple algorithm works behind the scenes to decide which web pages to cache, and which to ignore.
Web caches are employed to reduce latency – the time lag between a client making a request for a file or resource, and it actually arriving. Caches speed up the delivery process, and make the web seem more responsive. They also help reduce network traffic, since less bandwidth is used to access and deliver locally stored copies of pages and files.
Types of Web Cache
You’ll probably be familiar with browser caches, from the set-up of internet access software on your desktop computer, laptop, or mobile device. These set up a portion of your device storage for holding representations (web pages you’ve previously visited, graphics downloaded, etc.) to help speed up your online experience.
Proxy web caches or proxies serve hundreds or thousands of users at a time, and are often deployed by large corporations and Internet Service Providers (ISPs). Request handling by proxy caches may be configured manually in your browser’s proxy setting, or via interception proxies set up by the underlying network.
Gateway web caches (also known as surrogate caches, or reverse proxy caches) are typically used by website owners or managers, to make their sites more reliable and scalable. They’re also used by content delivery networks (CDNs) such as Akamai or Speedera to distribute gateway caches across the internet, and to sell caching functionality to commercial subscribers.
Web Cache Poisoning Attacks
The Domain Name System or DNS is responsible for resolving the text-based web addresses or URLs that you type into your apps and browser windows into their numeric equivalents which point to specific web servers.
Like so many other resources on the internet, DNS resolvers make use of web caches to speed up and streamline their operations. If a hacker succeeds in introducing corrupt or misleading domain name system data into a DNS resolver’s cache, they may be able to dictate where the Domain Name System directs requests. This can allow them to redirect data traffic to their own systems, or to steal information directly.
Hackers typically use this method to divert traffic from legitimate web servers to their own malicious ones, where unsuspecting users can be re-routed to booby-trapped websites and served with malware. The technique (which has been around for a while) is known as DNS spoofing or DNS cache poisoning – and it’s a form of attack that’s fundamental to the weaponizing of web caches in general.
Web Cache Poisoning – Weaponizing With Metasploit In 2008
A DNS cache poisoning vulnerability outlined by security researcher Dan Kaminsky at the Black Hat conference briefings of August 2008 brought to light one of the earliest major instances of how weaponizing web caches could become a practical reality.
Before 1997, hackers using cache poisoning could target an organization’s network by asking its DNS server to resolve the IP address of a site over which the attacker had control. In response to this flaw, security professionals took steps to force DNS servers to only receive answers for resolution requests that were “in-bailiwick” – that is, the DNS servers could now only respond with records containing the domain name of the origin of the request.
So if an attacker sent a request from their system at www.hacker.com, only records ending in “hacker.com” could be returned, effectively exposing the hacker’s origin.
In order to target legitimate sites, this meant that hackers would somehow have to send a spoofed response to each request that seemed to originate from the targeted organization’s own DNS server. For every request, each DNS server has a 16-bit transaction ID (TXID) which an attacker has only a 1 in 65,536 chance of guessing correctly, in the time before the real DNS server responds.
Kaminsky discovered an exploit that makes it possible to start thousands of such races to resolve mostly bogus records. This greatly increases the attacker’s chances of hitting on a legitimate TXID in sufficient time to substitute their own data stream as a bogus request.
Once the news became public, hackers were quick to jump on the bandwagon. There are currently modules included within the Metasploit framework which allow this vulnerability to be easily exploited. Using them in conjunction with other tools, hackers can target corporate networks, and exploit insecure updates in consumer-level applications like Java, QuickTime, Notepad++, and Winamp.
Web Cache Deception Attacks In 2017
In 2017, Israeli security researcher Omer Gil discovered a technique known as the web cache deception attack, which takes advantage of the way that servers create cached pages. It was used to target several household names online, including the eCommerce and online payments platform PayPal.
Hackers can exploit this flaw by accessing links that point to non-existent resources. For example, a request for https://www.paypal.com/myaccount/home/hacker.css would cause a cache to be created for https://www.paypal.com/myaccount/home/ – and the cached page might include an email address, account balance, the last four digits of a user’s credit card number, and other useful information.
Gil discovered that over 40 different file types can be used in this ploy, including popular formats like DOC, JPEG, and AVI. Invoking any of them triggers the creation of a cache page, even if the request points to a bogus link. And these cached pages may linger up to five hours – more than enough time for a hacker to completely take over a user’s account.
Web Cache Poisoning – Weaponizing The Web Caches In 2018
Recent investigations by security researcher James Kettle have revealed a flaw in the way that caching and websites operate – one that’s independent of any particular technology or type of cache.
By exploiting security weaknesses in the design of the underlying website infrastructure, Kettle was able to take control of the web caches of several major sites and online platforms, in addition to exposing a serious gap in the infrastructure of Mozilla’s Firefox browser which enabled him to briefly gain control of “tens of millions of browsers,” as Kettle puts it.
Though Kettle is keeping coy about the details of his exploit until he has a chance to reveal it formally at August’s Black Hat USA conference, the researcher claims to be able to get web caches to misbehave without directly targeting them. Using a specialized web cache poisoning technique, Kettle has apparently succeeded in weaponizing a range of web caches so that:
“The website then replies with something potentially dangerous … and the cache takes that, so then anyone who visits after that gets hit by the exploit.”
Getting web caches to deliver exploits to website visitors is the distinguishing factor between Kettle’s new technique and other cache poisoning strategies. Using such a method, hackers could potentially inject malware that steals passwords or credit / debit card information from a website, when consumers visit. Altering website content and appearance or redirecting site visitors to URLs controlled by the attacker are other options.
As for the Firefox vulnerability, Kettle used his web cache poisoning technique against the infrastructure responsible for identifying and sending application and plug-in updates, as well as the URLs of dangerous websites to block. Kettle claims that:
“I found by accident … that I was able to use cache poisoning to effectively input [some limited commands to Firefox browser users worldwide]… If you opened Firefox, I got control of it.”
If true, attackers could easily exploit this weakness to force Firefox users to install certain extensions (e.g., vulnerable ones, or specially created ones with malware). The technique could also be used to assemble a worldwide botnet of Firefox browsers, for huge Distributed Denial of Service (DDoS) attacks.
Should We Be Worried?
Mozilla fixed the flaw in their infrastructure within 24 hours of Kettle’s reporting it to them, in an update to the Firefox software of January 25th. The company has declined to comment on Kettle’s research.
With regard to other forms of web cache poisoning and exposed vulnerabilities to web caches, ISPs and many corporate networks have responded by reconfiguring their caching mechanisms and strengthening the security of their web servers, to compensate.
We’ll have to wait until Black Hat USA in August for more details on the Kettle research, and any subsequent recommendations on protecting users and networks from the weaponizing of web caches.
Share this Post