Understanding the danger of Web Cache

Since my last writing for a layman understanding on wireless security (thanks to Andrew Leniart's prompting and guidance),  it got me thinking there is also other similar security weakness and of a certain level of technicality that can be made easier to appreciate. Hence, here I am to attempt the next writing on another topic of this nature.

Recently, I chanced upon this release on web cache poisoning and in the same genre, another past advisory on web cache deception.  Both can be quite technical in nature, but worthy to know and if time allows, catch a whole read through, especially if you are running web services. One common trait you can find in web cache is that the use of proxy servers is a norm to deliver faster services, but there are hidden dangers and weakness to be aware of, so take care. 

Let get started! 

Basic understanding - So what is web cache?

Temporary store for web content such as HTML pages and images that can be served to the user so that it can save a trip to the server. It has a faster user surfing experience since the same content is requested and cheaper since it saves repeated trips to the web server.

1)    A user using the browser (client) surf the web page and passes through a proxy. Since it is the first trip, the request is passed on

2)  The web server responds and the proxy takes this chance to cache the content (document) and it also creates a KEY for future retrieval 

2a)  The Cache key is typically needed as it serves as a reference to a look-up table so that each cached content is tagged to the KEY

3)  When the user makes the second request to the same content, the proxy will check the KEY (made up of the same URL etc). 

4)  The Proxy responds on behalf of web server since the KEY is found and serves back the cached content.

See the diagram below:

It is just that simple. The KEY typically in its simplest form will reference the URL of the request (forward path) and the latter is normally termed as "keyed" for the cache. Another additional field depends on the provider of the proxy and the image shares one scheme from Akamai.  

This is not without Tradeoffs...

The cache scheme has its own weakness. Imagine if the cached content contains malicious code that redirects the victim to other compromised website to carry out further exploitation and get the visited machine infected.

Let's run through two recent findings. 

Attack 1 - Web Cache Poisoning 

The objective of poisoning is to send back a harmful response that gets saved in the cache and served to many more users. To carry out a successful attack requires:

• Find the vulnerable code, fill the HTTP header field with legitimate headers which leads the cache server to flush legitimate content.
  
  
• Send a specially crafted request that will be stored (or injected) as the latest in the cache.
  
  
• Send another request to confirm previously injected content is the response (using another machine).

What so different in this latest attack?

The attack poisons caches using unkeyed inputs like HTTP headers. The weakness is that cache KEY typically does not use the query field (yellow) and header field (bold white). Hence, injecting exploit codes through the headers may be possible by: 

1. Send request to the homepage (Red Hat) - it actually passed through a Proxy (Akamai content delivery network)

2. Web server's application generates a response (e.g. Open Graph URL inside a meta tag) - get cached.  Note reuse of header values.

3. Send request and this time, manipulate to inject "malicious code" (Cross-site script) in the header 

4. Web application similarly response like (2) and it also replace the previous cache content - "code" available for new client 

So any user fetching the homepage URL (without the malicious header) directly in a browser on a different machine will likely get the poisoned cache as long as it has not being purged or replaced. 

Attack 2 - Web Cache Deception

The objective of the deception is to expose victim sensitive data, and in the worst case scenario, allow attackers to take control over the account. In this case, it targets the default cache scheme which caches statics, public files: style sheets (CSS), scripts (js), text files (txt), images (png, bmp, gifs), etc. These files usually contain no sensitive information since it is published to the Internet (knowingly). This is also best practices for most web cache configurations. 

What so different from the previous attack?

The attack forces the default caching on sensitive content using a "non-existent" document. The weakness is the web application cache files by their extensions, even if the document requested does not exist (yellow) disregarding any caching header. 

1. Send request of a non-existence file (logo.png) such as appending any filename with a static cache-able extension

2. Typically due to the default cache scheme of static content, the proxy will cache the available document (page.html) instead 

3. Send another similar request as (1) on the non-existent file

4. Proxy response as the cached file is found and sent back to the client 

So far, it seems alright for such a minor mistake since the harmless page is served. But what the attacker will do is lure a logged-on user to access similarly using the same request and cause the page – containing the user's personal content – to be cached. This becomes publicly-accessible now! If the attacker can retrieve from the response session identifier, security answers or login tokens due to user login sessions, it's going to get worse for the victim.

What can be done to mitigate?

Here are some recommendations that need some rethinking to secure your web services:

1. Disable caching ( "Cache-Control: no-cache" ) but it impacts the user experience. Strike a balance.

2. Restrict caching to a whitelist of static documents and files with known extension. Define custom cache keys (rather than default URLs)

3. Configure the cache mechanism to adhere HTTP caching headers. Use Vary header to include "un-keyed" inputs.

4. Make sure any sensitive data is properly encrypted because it is stored on the local system.

5. Use the private or incognito browsing version where web pages are not cached.

6. Secure coding in an application to ensure the web attack (top 10 in OWASP) attempts are rejected. 

7. Explore the cache component if it can be configured to cache files by their content type (further than just default extension).

8. Handle exceptions well. Request for non-existent files to return a 404 or 302 response (proxy can make the wrong decision).

9. Keep the content framework in the application patch to the latest working security patches (1st attack - Drupal, Symfony & Zend)

10. In any case, always conduct regular security testing like penetration testing (not just using a tool) by professionals to surface the flaws early for remediation and mitigation in place. 

Share your practice 

There are no silver bullets and in this arms race against evolving threat (like DNS cache attack), one thing to keep us safer is the basic security hygiene regime that we must not neglect and treat lightly - every layer of defense matters and needs to be secure!