Don’t trust Google Links
Phishing campaigns are lucrative and probably will continue to be so for a while longer: they are cheap to launch and it only takes a few recipients that click on your malicious link to be successful. But awareness about the dangers of clicking on links is slowly rising. So if you’re a bad guy, how would you keep convincing people to click on the link to your malicious website once pretty much everyone has learned to be distrustful?
I played this mind-game with myself and came to the conclusion that you would need to find a way to use a trusted domain as a sort of redirect-proxy. Victims will check the domain: consider it safe, click, and then be redirected to the malicious website. So it seems there would be two issues to tackle:
- Find a well-known website that everyone trusts which has an open redirect functionality that can be abused.
- Obfuscate our domain to further prevent detection.
Google
The website actually came to mind quickly: Google!
Whenever you perform a search with Google and then click on a link, you’re actually first going to another Google-page before being redirected. This is how Google tracks clicks.
So I inspected the url and found it’s using a lot of parameters. That is good news (from an attacker-point-of-view), because in practice only few are relevant and such long urls will only help in our victims not noticing what’s going on.
Analyses
I then looked up our company in the search results to see how it was constructed:
Stripping this down to the bare essentials, I found that these urls need to contain at least the following:
- The base url: https://www.google.nl/url (but .nl can be any other Google toplevel domain)
- The parameters:
sa: this apparently always has the value turl: this is the (urlencoded) url of where you need to be redirected tousg: some kind of hash that seems to be different for every url
So the previous url would also work if we wrote it like this:
You can click this url and it will redirect you to the Bitnesswise homepage.
Playing around with this I noticed that modifying the url parameter without changing the usg parameter results in a warning from Google that you’re about to be redirected. In the following example I have replaced the value of the url parameter to create a redirect to www.privacy-wise.com
If you click it, you will notice that Google will give the warning I mentioned.
That is bad news from an attacker point of view. It seems Google has realized how dangerous this redirect could be without it and tries to prevent this by checking a hash only they can generate.
Not wanting to give up so easily (bad guys won’t either) I wondered if I could somehow make Google generate the hash for me. And the answer to that is actually simple: just let Google index the page.
Proof of Concept
While some phishers often use compromised websites, others are fond of using a free online service to host their malicious content. For obvious reasons I choose the later for this POC and signed up for a free webcindario hosting account where I created a page that I could use for any of my supposedly dark purposes. Once the page was created I submitted the url to Google and it was indexed moments later.
Now that the page was indexed and I had the hash (for the usg parameter) in my possession, there was one more issue to tackle: obfuscating the domain.
As you can see in the urls above: www.bitnesswise.com and www.privacy-wise.com are still clearly visible in the url for those who go beyond just checking the domain name. This gives away there might be content from another website involved. Hiding this last bit of information is easy though since all characters in query parameters can be written in their hexadecimal equivalent. For www.bitnesswise.com that would be : %77%77%77%2e%62%69%74%6e%65%73%73%77%69%73%65%2e%63%6f%6d, which would give the following url:
Now, the only human readable part is the Google domain, which is exactly what we want. And best of all, this doesn’t seem to affect the hash! If you click on the link above, it will still bring you to the Bitnesswise homepage, without a redirect notice.
So with the hash and the obfuscated url I can present the following link:
Do you dare to click it?
I hope you’re at least hesitant about clicking this link and I also hope you will have the same hesitation next time someone sends you a Google url!
Update 2018-11-23
Currently there are some browsers which will url-decode the url when displaying it in the status-bar (that part in the bottom-left of your browser where you can see where the link is pointing to). Google Chrome will decode the domain while leaving other parts as is and Firefox seems to decode the whole url. IE Edge still shows the url completely obfuscated (no url-decoding). This was different at the time of writing this post when all the browsers I checked showed it in the statusbar as it is displayed in the text of this post.
While this will give away the domain for some of you – thereby diminishing the effect somewhat – the POC is just as relevant:
- emails are opened in email clients and so far I haven’t found one that displays the decoded url
- emails are not the only source for phishing-links. Another popular technique is to hack accounts from services like Skype and send links to the contacts that are stored online
- the name of the malicious url could be further obfuscated by ‘hiding’ it at the end of the url. This could be accomplished by inserting a dummy parameter with a long value before it. As an example: https://www.google.nl/url?dummy=7shw9gKvkzABP5kpPFoE5Sd6BITeegApBpt7hzwaUvoePun8IYJs4GznqjAl5MuxWN1v0RLCWEpbzKinvsMBtUFwfx2XcJ9OoRDIruc4TMgttf2xEGRYcDjXkq0xARYIsdfFGb2BFyDmxZkQ6vdMo0IuqkqV3xXtHaMTCUoAS57xfzI0bQ2y4UQVfAHdn7YijyzYI9wtCYOHuPjOsTLK73EsYqW2n6ewLjnLsoPQ2SjXFrlejk7YtOkEqMhOchonx&q=%68%74%74%70%3a%2f%2f%65%76%69%6c%2d%68%61%63%6b%65%72%2e%77%65%62%63%69%6e%64%61%72%69%6f%2e%63%6f%6d%2f%6d%61%6c%69%63%69%6f%75%73%2d%6c%69%6e%6b%2e%70%68%70&ust=1548403315547000&usg=AFQjCNG_Ok-esnzrna37Hl6nwRC93i_XnA
- A lot of people will not look beyond the domain anyway and immediately trust the link once they see it points to a google domain (unless they read this post, of course ;-))
Update 2019-01-10
My old free account (to host the POC) expired and due to a bug in their system I could not revive it. I had to sign up for a new account which meant I also had to generate a new hash for the usg parameter. The old ‘Submit URL’ that Google used to have, doesn’t exist anymore though – at least, I couldn’t find it. It seems you now have to create a Search Console account, proof ownership and then submit it. Although it’s still doable, it has become much more cumbersome. On top of that, when I finally managed to have it indexed, instead of listing it with a usg parameter in the search results (the reason I was doing this), it made use of a very elaborate POST request to go from the listed search result to the actual page. This could be good news, because it could be an indication Google is trying to address the issue. But because my old urls with usg parameter also still worked I wondered how I could still make Google generate it for me – since there is obviously still support for it. Then I remembered how Gmail also uses a redirect when you click on the link in an email and wondered if maybe it used the same technique – and it does! So in the end this actually helped find an even easier way to generate a usg value : simply send an email to a Gmail account. Instead of hours (or even a few days) I now had a valid usg-value in less than a minute.
I have updated the post with the new link, which now also has new required parameters:
q: this replaces the oldurlparameterust: this is another required parameter that can be copied from the Gmail-generated link. Although it looks like a unix-timestamp (in microseconds), altering the value will result in the redirect notice, so it seems that it really needs to be generated by Google as well.