New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manipulation of Host Header lead to Account Takeover Vulnerability #748
Comments
|
Hi @mmetince |
|
That's impressive ! Thanks for taking a very quick action. Are you guys going to request a CVE ? |
|
I fixed it on VestaCP in more simpler way - serghey-rodin/vesta@c3c4de4 |
|
@mmetince Would be the first time ever we would request a cve, just a lack of knowledge here so it isnt planed :). @dpeca This was also our first idea, but limit it to hostname will prevent logins from ip address or possible subdomains using mod_rewrite/proxy to the backend. |
|
Gotcha ! @ScIT-Raphael A'right mate, I will go ahead and request one for you. It usually takes 1-2 days to get one. I'll let your know when I heart from MITRE team. |
|
@mmetince you can also send to dev@vestacp.com if it's related to VestaCP too. |
|
@mmetince Awesome, thank you verry much for your help! If you would find anything else or would like to stay in contact with the whole team (we would love to <3) write me a mail to info@hestiacp.com. |
|
Ofcourse ! I was particularly interested in finding a 0day on Vesta because of an, hmm, let say assignment :). If I find an anything else in the future, I will definitely send it via e-mail. Also, may I suggest you guys to use Security feature of GitHub so that all can have this conversation privately next time ? Cheers, |
|
@mmetince Sure, I'll forward this to @kristankenney, ha can setup the Security feature within a few clicks. |
|
Assigned CVE number ise CVE-2020-10966 @dpeca @ScIT-Raphael |
|
Awesome, thanks @mmetince! We just have released the security hotfix under version 1.1.1, so I going to close this issue now. Again thank you for pointing us on it, do not hesitate do contact us again, if you would find everything else! |
Tbh, vulnerability is pretty simple. On line 33. $_SERVER['HTTP_HOST’] value is directly used without any validation and then on line 34. E-mail send to the targeted account’s email address.
hestiacp/web/reset/index.php
Line 33 in 5ffb7ac
Content of the password reset e-mail is generated by using following string definition.
So that means, $_SERVER['HTTP_HOST’]value is used for URL generation in e-mail template and we can fully control it.
We can spoof $_SERVER['HTTP_HOST’]value during HTTP request to the password reset endpoint.
Actual Host header value İS NOT hacker.com but the URL will be hacker.com in the password reset e-mail. As you can following screenshot, even though the Vesta is being installed on 192.168.74.163 on port 8060, URL placed in the e-mail for account recovery is HACKER.com now. So if the admin user click on that link in the e-mail, HACKER.COM will steal the code value which is enough for resetting password of the admin user.
PS: I should mention that in the real-life use-case you can very similar domain name instead of hacker.com :) Since the e-mail is being sanded from Vesta server, it’s not a kind of phishing attack.
Suggested Fix
According to technical details of the installation, Vesta installs it’s own Apache, Nginx and bunch of services. That means %90 of the real-life deployment is standalone server. By saying that I mean, there is no different service in front of the Vesta where might be validation on Host field of request header.
This vulnerability could have been mitigated by doing Nginx configuration, which is being used as reverse-proxy in the product, or even can be Apache without touching PHP side. But default Vesta configuration gives your chance to work with Host field.
Side Note
I've found & successfully tested that vulnerability during analysis of Vesta ! I haven't tested it against HestiaCp but I strongly believe it's also works too.
The text was updated successfully, but these errors were encountered: