Exploiting Google's Parameter 'q' to show Visitors/Bots with Fake Keywords and Google's Open-Redirect Issue

As mentioned earlier in one of my thread (http://hackforums.net/showthread.php?tid=5044562) I reported a bug in the param 'q' which can be used to generate visitors/bots with fake keywords, that not even Analytics can detect. Since there's no actual fix to the bug according to Google, I had to post a thread. I wrote them everything they needed to know about the bug, solution to fix it and the reproduction steps, including a proof-of-concept video.

Reproduction steps:

1. Suppose I want to send traffic to my client. Let's say his website is onlinecarsblog . com or whatever. Of course he wants targeted traffic, and what's more convincing than traffic coming straight from Google with the keyword "Buy Cars, etc."? Well, here's the trick.

2. This is the URL; www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CBoQFjAAahUKEwjVr6fbvfTIAhUJmJQKHYYeAqA&url=https%3A%2F%2Fwww.facebook.com%2F&usg=AFQjCNGug_CqO9cxLI8dHdn-CceO8_ie5w (I'm using Facebook link's as an example.)

3. The "q=" query determines the keyword that Analytics or any other traffic stats' website will show. So if you change it to "something", traffic will be shown to be coming from Google with the keyword "something".

4. "usg" is a unique id for each URL. facebook . com will have "usg=AFQjCNGug_CqO9cxLI8dHdn-CceO8_ie5w" and facebook.com/anything will have a different unique usg. So don't mess with it unless you know what you're doing.

Attack scenario:

An attacker can use this to manipulate stats in Analytics.

Proof of Concept:

In my video I have demonstrated how this can be used to manipulate Analytics to show visitors/bots with fake keyword.

Google's Response:

When I first reported this to Google these were the responds to my emails.

Open-redirect issue -

I had also found another param bug which could lead to open-redirect issue once the user logs in. An attacker/hacker could use it to redirect the victim to it's phishing page, or inject an exploit hosted on it's server. Not only the same URL had open-redirect issue but it would try to POST another param with some data that one could log, but it was useless according to GOOGLE. As of now I choose not to discuss it much. Once it get's fixed, I'll update the post with information on how I managed to do it. Google respond:

When I described it as an open-redirect issue, and use it to describe a phishing scenario, this is what they responded with:

Read More

Using Chrome's Extension to Inject Code

If you were wondering if Chrome's extensions we safe to install then this video will demonstrate how one can use Chrome's extension to hijack sessions or steal cookies from a victim. 

Session hijacking

In computer science, session hijacking, sometimes also known as cookie hijacking is the exploitation of a valid computer session—sometimes also called a session key—to gain unauthorized access to information or services in a computer system. In particular, it is used to refer to the theft of a magic cookie used to authenticate a user to a remote server. It has particular relevance to web developers, as the HTTP cookies used to maintain a session on many web sites can be easily stolen by an attacker using an intermediary computer or with access to the saved cookies on the victim's computer.

Prevention

Methods to prevent session hijacking include:

• Encryption of the data traffic passed between the parties by using SSL/TLS; in particular the session key (though ideally all traffic for the entire session). This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack. In response, scientists from the Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by correlating the application session with the SSL/TLS credentials.
• Use of a long random number or string as the session key. This reduces the risk that an attacker could simply guess a valid session key through trial and error or brute force attacks.
• Regenerating the session id after a successful login. This prevents session fixation because the attacker does not know the session id of the user after s/he has logged in.
• Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.
• Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, two legitimate, closely timed requests from the same client can lead to a token check error on the server).
• Users may also wish to log out of websites whenever they are finished using them. However this will not protect against attacks such as Firesheep.

Read More