Open Redirect vulnerability allows attacker of an web application to redirect users to any external sites. Here, there is no validation of the passed input by attacker. This is basically used in phishing attacks.
OR
Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.
The vulnerability was a sneaky one, instead of writing a long article I decided to record it.
PS: Enjoy the song :)
Recently while participating into AT&T Bug bounty program i have submitted bunch of bugs. Yes bunch of bugs. Well as i have already blog posted many bugs like XSS, CSRF etc. So rather then blog posting those bug i will be describing one interesting bug which is Host header injection.
Introduction:-
What is Host Header Injection ?
As the name suggest host header injection is attack in which an attacker can manipulate the Host header and cause the application to behave in unexpected ways. Header simply specifies which web site should process the HTTP request. The web server uses the value of this header to dispatch the request to the specified website. In short if any malicious user is able to handle this header to their desired domain and if server is not validating it then it leads to host header injection
Why this happens ?
HTTP header injection occurs when Hypertext Transfer Protocol (HTTP) headers are dynamically generated based on user input.
OR
ANY site that does not validate HTTP Host: headers.
How to find this bug ?
Verify the header of the request. Inject other domain in the header field and check the response.
What is impact of this bug ?
An attacker can simply send the wrong host in the requests and poison the cache of proxies/web server. It has nothing to do with the browser's cache.
Next time, a legitimate user tries to access the correct host but since the cache of the web server is poisoned with the attacker's domain, the legitimate user will be redirected to the attacker's domain.
How to mitigate this bug ?
Do NOT use the value of the Host header for anything.
Proof Of Concept:-
So basically I was able to control the host header of AT&T. Below is the POC Request and Response. POC Request-
GET /shopping-cart HTTP/1.1
Host: telephones.att.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
As I mentioned earlier I have reported bunch of bugs and Host header injection is one of them so after fixing my all submitted bugs, they selected me for quarterly Top 10 Reporter Award :)
So wish me Luck :)
Video POC:-
Below is the video POC demonstration of this attack
Time-Line:
Vulnerability timeline:
July 04, 2015 at 11:25 AM : Reported to AT&T Team
July 20, 2015 at 10:15 PM : Received initial reply from AT&T Team
Aug 06, 2015 at 11:19 PM : AT&T Team released a quick fix for the vulnerability
Oct 25, 2015 at 09:30 PM : Public responsible disclosure
In this blog I will be discussing about xss in authentication. I prefer writing less about xss in the blog post but the xss which I found in 123contactform was from no where. So this forced me to write this blog post.
About 123Contact Form:-
123ContactForm is an online web form and survey builder. It helps designers create powerful web-based forms and surveys without any technical knowledge.
123ContactForm has become a worldwide top class online form and survey builder.
Well This all their site says under About Section
Introduction:-
Everyone knows about XSS, If not then you can refer from here.
Usually we find XSS either in url or in search parameter and so on...but what about authentication pages ?
If we talk about authentication page OR login page, we generally test for SQLi, Authentication bypass or Broken authentication related bugs and etc.
Well Do we think about XSS ???
Proof Of Concept:-
The story starts when I was on Login Page of 123Contact Form this time I was not thinking about SQLi , not authentication bypass and not about session related bugs but what I was thinking is XSS.
So rather than writing my username and password, I simply injected xss script as a payload in username field. I know this might me funny try from my end. After injecting the script I fired up burp suite to see the request-response in order to check where my payload is landing and whether they have any server side validation check or not.
I was so shocked to see the response :D
Below is the screenshot of the response:-
My input reflects in response as it is :D Well this is what an Xsser wants.
Moral Of the Story:
- Try thinking out of the box
- Always try new things and push yourself
- Easy findings always around you, but you just have to act smart to find that.
Time-Line:
Vulnerability timeline:
Aug 7, 2015 at 1:59 PM: Reported to 123Contact Form Team
Aug 11, 2015 at 3:17 AM: Received initial reply from 123Contact Form Team
Aug 12, 2015 at 4:26 PM: 123Contact Form Team released a quick fix for the vulnerability
Aug 12, 2015 at 4:42 PM: Again Reported Another XSS
Sep 10, 2015 at 1:32 PM : 123Contact Form Team released a quick fix for the vulnerability
Oct 14, 2015 at 4:47 PM : Full disclosure
