[Update: Some of these examples were mitigated in Chrome 38 and 39]
After seeing in the previous post how Data-URIs can be used as a mechanism to easily carry malicious code, I’ll elaborate more about the issues it presents.
Some of it merely exists from the way Data-URIs are designed and implemented, and some of it might be considered as security bugs in the browsers.
Using Data-URI to manipulate the address bar
The simplest thing an attacker can do is to add spaces after the “data:” in the URI and by that it can make it look like it some kind of a Chrome internal page.
It will also change the link status in the bottom of the browser. The link will show “data:” hiding all the base64 code that is there. It’s a way to manipulate the status bar without the need of JavaScript. Hence the link will be manipulated even in an environment that doesn’t allow JavaScript.
Combine that attack with the previous example of the phishing SVG and you can get catastrophic results. Lots of users might believe this is an internal Chrome page.
While in the above example the user will see only “data:..” in the address bar. If he’ll feel uncomfortable the user can still examine the address bar and might find the hidden base64 code.
The next example will show how to prevent the user from examining the address bar at all, and it’ll always show “data:” The 3 dots indicating there might be more to it – will be removed as well.
By making the original content larger than ~28KB the address-bar will always show “data:” and only data.
Live example of only data in the address-bar (Open in Chrome)
While Chrome is the most vulnerable to the Space attack, other browsers will fall for it too.
FireFox trim the spaces when you click on the link, but an attacker will still be able to manipulate the status-bar (at the bottom of the browser). As we’ll see in the next vector.
*Safari *doesn’t trim the spaces but instead convert it to %20 or any other Unicode escaped representation of a space. It’ll work with any combination of unicode spaces.
*Mobile Chrome for iOS. * It was a bit surprising to see that the Chrome version for iOS will fall for the “Over 28KB base64” attack.
It interesting to see that even Chrome for iOS which is very different environment, share the shell code with all of the other Chrome browsers.
*
Tricking the user to download malicious content using the DATA URI*
We already seen how one can abuse the browser’s address-bar and the status-bar by simply adding spaces after the “data:” in the link.
But what if we add any other character, other than space. In that case, the users will be prompted to download a file (by default the user won’t be prompted and the file will just download)
How convenient for an evil one. Combining that with the previous stuff…
The user will see data:http://google.com/graphics/doodle.svg in the status-bar, clicking the link will automatically download the attacker’s malicious SVG file that is hiding in the base64 code inside the link.
Click to download doodle.svg (not really a doodle)
As noted before, FireFox trim the spaces after the “data:”, but one can use %20 instead. Also, FireFox does a good job and put an ellipsis in the middle of the link in the status-bar. So the user will see the suspicious gibberish base64 at the end, But that can easily overcome with simply adding spaces at the end of the link as well.
Click to download doodle.svg (FireFox version)
The interesting thing is that this kind of attack doesn’t limit us to SVG, any kind of file can be downloaded this way, any kind of binary file as well.
How about an EXE (that EXE does nothing but to echo some text to the terminal)
(Will add it latter)
Remember COM executables? Only few bytes, 32bit windows will still run it, still many of these are out there.
ZIP is a great bad vector IMHO
ZIP with badies inside (not real badies just text files)
While on windows an attacker will also need to trick the user to change the extension of the file or to make him “Open With…” the file with a certain app. On the MAC these extension doesn’t matter much.
The file will be opened or executed according to its real type.
The new Mac OSes have this great feature called Gatekeeper that makes running applications way more secure in general.
The default settings is “from app-store AND identified developers”. How difficult is it for a motivated attacker to become an “Identified Developer”?
If the user have disabled Gatekeeper the app will just run when clicked.
It will probably work on old macs, but anyway I think that the most dangerous attack will be using just a zip file with all kind of badies inside.
The user flow might be:
- Click on a link -> File is immediately downloaded (there is no wait as the file is already embedded no the page)
- Click on the downloaded file -> file is automatically extracted (if the zip is small enough the user won’t notice much going on as the extraction will be fast)
- Malicious apps will be spread all over the user’s Downloads folder.
- “Hopefully” one day the user will notice these apps and its inviting names and will run one of these – thinking he downloaded it himself.
These are most of the browsers I’ve tested on, other browser may behave differently, generally it works the same on ubuntu as well.
IE (Internet Explorer) – does not suffer form most Data-URIs flaws, it does it by not supporting most of its features. I don’t think that getting away with it by not supporting it is generally a good thing.
*Final notes about these vectors: *(repeating some from the previous post)
- Remember that no JavaScript is needed for any of this, all that is needed is a link. It’ll work just the same with JavaScript disabled.
- No server is involved either.
- All an attacker need is a bunch of strings and the user’s browser will do all the rest.
- AV won’t scan these links.
- Not easily blockable – no domain to block.
- More easily shared and distributed.
- The attack is also cached in the browser history and doesn’t need Internet connection to be present at the moment of the attack.
- Will propagate across devices. For example, if you’re signed-in into Chrome the attack will propagate to all of your devices. (You’ll still have to run it on each device though, just type data in the address bar).
Can be easily embedded in the naively looking *.URL file. Who doesn’t click on these? It always felt safe.
— Reported the bug to Google.