Victims receive a malicious an email from one of their contacts; the message pretends to carry a PDF document that can be previewed directly from Gmail. When the victim clicks on the “attachment” image included in the body of the email, he is redirected to a fake Gmail page. Giving a close look at the URI associated with the image in the email message we can notice that at first glance it could appear as legitimate and linked to the official Google domain. The URI to which the images of attachments point is crafted to appear legitimate: “data:text/html,https://accounts/google.com,” It is interesting to note that the web browser does not display any certificate warning, but a deep inspection of the URI associated with the image reveals that the legitimate part of the URI is followed by a sequence of white spaces that prevents the victims from seeing suspicious strings at the end of the address. This string is an obfuscated script that opens a Gmail phishing page in a new tab. A technical description of the Chrome/Gmail attack has been published on Github.
Figure 1 – Image of attachment included in the phishing messages
Figure 2 – Analysis of the URI associated with the image “You click on the image, expecting Gmail to give you a preview of the attachment. Instead, a new tab opens up, and you are prompted by Gmail to sign in again. You glance at the location bar, and you see accounts.google.com in there. It looks like this….” states a blog post published by WordFence. “Once you complete sign-in, your account has been compromised.” This technique is not new; several victims already reported similar attacks on July 2014. One of the main characteristics of the recent string of Gmail phishing attacks is that cyber criminals immediately accessed the compromised accounts and used them to send out phishing emails to all the victim’s contacts. At the time I was writing there aren’t further information about the attacks, it is not clear if attackers have found a way to automate the process to access the victim’s account once he has provided its Gmail login credentials via the phishing page. As usual, let me suggest enabling the Two-Factor Authentication (2FA) on Gmail to avoid being victims of this phishing scheme. In this way, even if the attacker has your credentials, he also needs the verification code to access the account. However, hackers can obtain this code if he uses a Gmail phishing page that also requests the verification code and uses it immediately after the victim provides it. “2FA would make it harder to exploit, but phishing attacks are getting fancier. They capture the 2FA code you enter and immediately start a session elsewhere with your password and 2FA. Hardware 2FA, a security key, (such as a Yubikey) is the only likely way to prevent phishing (excluding targets of state actors)” wrote a user in a discussion on Hacker News. Another important suggestion for users to avoid such phishing attacks is to inspect the address bar every time they sign into any web service. It is necessary to verify the protocol and the hostname. Be sure that there is nothing before the hostname ‘accounts.google.com’ other than ‘https://’ and verify the presence of the lock symbol. You should also take special note of the green color and lock symbol that appears on the left. If you cannot verify the protocol and verify the hostname, do not attempt to sign in. Google has been aware of this new phishing tactic since at least March 2016. For this reason, the Chrome security team suggested introducing a “Not Secure” tag in the address bar for data: blob: and other URLs that may be exploited by phishers in hacking campaigns. I include the response provided by Google to a customer asking for more information: “The address bar remains one of the few trusted UI components of the browsers and is the only one that can be relied upon as to what origin are the users currently visiting. If the users pay no attention to the address bar, phishing and spoofing attack are – obviously – trivial. Unfortunately, that’s how the web works, and any fix that would to try to e.g. detect phishing pages based on their look would be easily bypassable in hundreds of ways. The data: URL part here is not that important as you could have a phishing on any http[s] page just as well.” In September 2016, experts at the phishing observatory D3Lab monitored a new phishing attack against the users of a small Italian bank, the Banca Popolare di Spoleto.
Figure 3 – Phishing attack against an Italian Bank Attackers leveraged base64 encoding to obfuscate the website used for the phishing attack. Victims receive an email that includes a short link that points to a PHP page hosted on a compromised website. The page is used to redirect the users to a local page that is created by the browser decoding the base64 code in the URI.
Figure 4 – Phishing attacks against an Italian bank. The phishing attack is similar to the one observed in the last campaign against Google users. Also, in this case, hackers used a specially crafted URI that includes a portion of a legitimate URL of the bank https://ihb2.cedaci.it/… and the encoded phishing page. It is not the first time that Google users are targeted with this technique, in 2014 phishing attack based on data URI (uniform resource identifier) targeted the accounts of the tech giant. Below an example of the phishing messages sent to the victims:
Figure 5. Gmail phishing attack 2014
The attack leveraged on the URI scheme based on the ‘data:’ ta. This technique has been known since 2007 and was detailed in a paper titled “Phishing by data URI” published by the student Henning Klevjer in 2012.
The paper describes how attackers can use data URI in a phishing attack, the content of the phishing page is encoded in Base64. Experts also dubbed the technique a page-less Phishing attack that doesn’t need to host the phishing content on a server.
Klevjer demonstrated how to compose a phishing page of 24,682 characters using 26-character link by using a URL shortening service.
The result was a Wikipedia login page, the URI format he adopted was:
data:[
