What an awesome format is SVG, so powerful and so well supported by browsers. And yet it is barely being used, it’s not getting the love it deserves. Well, browsers love SVG, perhaps too much…
SVG files are like little bundles of joy. Encapsulating graphics, animations and logic. One can write a full app or game all encapsulate in one SVG file. That SVG file can be compressed into a binary file with the extension of SVGZ and browsers will still accept it.
Its way less powerful than Flash but the concept is similar – vector graphics and logic in one binary file. And like Flash SWF files – these files tend to get viral and to be re-distributed. And by that I mean, once you release your attack in the wild it can get hosted from many other servers. A good example would be, tiger.svg.
Remember the lovely Flash dog? It can work just the same and even worse.
SVG also run from local files. By default, on Windows, SVG files are opened in IE, which will run the script with local privileges when it’s double clicked.
Anyhow, SVGs have some flaws built in into them; many are known some are new. I will argue that even without the new flaws an SVG file is somewhat dangerous by-design. I wanted to see how easy it would be to abuse SVG for phishing. I picked an easy target – Chrome’s “Sign In” page. It was pretty easy to create an almost fully functional version of the Chrome Sign In page.
Check it out only 5kb of SVG “Image”
Compressed as an SVGZ, only 2kb (Chrome will run it just fine)
Note: Google already changed the appearance of this page, but it almost identical to the previous version.
This page is generally here (google already changed the way it looks)
Letting SVG files execute JavaScript is actually the root of the problem. I’m not sure it serves any real purpose in today’s web.
A simple attack might goes like this:
- The attacker will send the victim an email with a malicious SVG file “Checkout this cool image / animation”.
- The victim will downloads the SVG and click / double click on it.
- SVG is opened in the browser.
- Attack taking place.
The JavaScript that will run will have local privileges and can easily attack the user (limited to the browser sandbox of course). It can for example – execute multiple cross-domain CSRF attacks (cookies are sent normally with every requests) and/or load multiple other attack vectors. Can be abused for spam, and that is not even illegal as long as long as the attacker doesn’t do anything too malicious.
You may be thinking “so what?!” you can script the user from an html page just as well.
There are few differences, as most users will look at SVG file as just another image.
- When you double click on an image to view it can’t execute anything –SVG can.
- SVG files get redistributed – there are numerous clip art sites that will host the evil SVG for the attacker.
- The malicious code embedded in SVG files will sustain after editing the file in graphic editors like Adobe Illustrator and Inkscape.
I would say that the main problem here is not what SVG files are capable of doing, and it’s more about the way they can get malicious code slip through the user’s normal defenses.
Wait there is more…
*
Even more fun with SVG and HTML5 Data-URI*
Another great feature of HTML5 is Data-URI. Now, SVG is working great with Data-URI. Malicious SVG works amazingly great with data-URIs.
SVG encoded, as Base64 will run directly from a link.
Some might call this a feature but it can be exploited for phishing attacks.
POC of an SVG phishing attack embeded in an HTML5 Data-URI
Some of the attacker benefits are:
- This is just a link, no need to host anything.
- 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.
Everything said here is valid to all Data-URIs supported formats; notable is also text/html:
Here is an example
Actually Data-URIs have their own set of problems, which are not necessarily related to SVG. It works perfectly with SVG but the issues are more general. I’ll elaborate more in another post.
More about the demo (Chrome Sign In)
I don’t want give too many ideas for the bad guys, but the possibilities here are endless, I can already think of far more nasty vectors than this demo.
This specific demo has an image of the Google logo. I managed to create the Google logo as an SVG in about 7kb, but the Google logo in the demo is anyhow small and not too noticeable, it felt like a waste of KBs.
I found that the font used be Google for their logo is catull, which is an old style serif typeface, and is similar to … you guessed it… Georgia, that was good enough. Georgia is preinstalled on all OSs.
I know that might look horrible to fonts and esthetics lovers, but the average victim will easily fall for it.
One of the most important features of this attack is the SVG text-input. The user will need to enter his credentials somewhere.
Text-inputs are not natively available in SVG, though there were some attempts to create them.
I didn’t create fully functional text-inputs, didn’t think it’s appropriate for me to do it at this point – for various reasons. For one, I didn’t want to make it too easy to replicate this attack in the real. I’m sure that nearly perfect SVG text-inputs can relatively easily be created – one just need enough motivation.
What about mobile?
Smartphones are just fine with SVG, more on that later as well.
Some tip to keep you safe
- Be alert when clicking on links that direct to SVG files or Data-URIs.
- Don’t double-click on SVG files to preview it in your browser.
- Don’t preview unknown or unchecked SVG files in your browser.
- Don’t export SVG from Adobe Illustrator and Inkscape without knowing where it came from and making sure it has no malicious script.