Backdooring MP3 Files

Recently I published information on how specially crafted HTML (remote and local), Flash and QuickTime (.mov) files can be used by malicious users to target and exploit internal and external networks. Than my friend and college David K released his findings on backdooring PDF documents via builtin Adobe Reader JavaScript features. Also, JavaScript malware via Google AJAX Search API seams to be possible and could affect many popular web software products. As Billy Hoffman said XSS is the new hotness!
. I cannot agree more on that.
MP3 files can be backdoored with malicious content too.
Over the past few days I have been exploring different features of Apple’s QuickTime player - key software component of iTunes and standard part of many home and business workstations. A lot of research was conducted and some problems, which IMHO are quite serious, were found. Please take this post as a security notice.
QuickTime is quite versatile and flexible media platform which has a lot of functionalities. I quite like it I must say. I even use iTunes on daily basis. Unfortunately because of its flexibility QuickTime seams to allow execution of malicious content in a form of JavaScript from media files such as mp3, mp4, m4a and everything else that is supported.
The problems is caused by a quite useful feature called QuickTime Media Link (.qtl). The whole point of these QuickTime Media Link files is to provide means of playing media files in a more accessible way. In this respect the developer can create a .qtl file which hold information about the media content that needs to be played plus recommended dimensions, accessibility features, control features etc.
QuickTime Media Link files are written in XML and end typically end with .qtl. A .qtl file in its very basic form looks like the following:
<?xml version="1.0">
<?quicktime type="application/x-quicktime-media-link"?>
<embed src="Sample.mov" autoplay="true"/>
The most important element in this XML is called “embed”. This element describes the content that needs to be played. There are quite few attributes that can be assigned to the “embed” element like “src” and “autoplay” but they are not as interesting as “qtnext”. The “qtnext” attribute specifies what needs to be played next. Because “qtnext” expects a URL as an input, .qtl files are capable of opening HTML pages, local files, FTP sites and JavaScript code in the current browser. As such, “qtnext” allows successful backdooring with malicious JavaScript logic any .qtl file. Here it is an example:
<?xml version="1.0">
<?quicktime type="application/x-quicktime-media-link"?>
<embed src="presentation.mov" autoplay="true" qtnext="javascript:alert('backdoored')"/>
Upon execution the media link presented above will display a harmless message to the user. Bear in mind that a lot more dangerous things can be done. For more information about the impact of such an attack check the AttackAPI - a toolkit designed to test browser related issues.
To sum up, .qtl files can contain malicious JavaScript code that can takeover some important network device when executed for example. That’s not the end of the story though. Because of its flexibility QuickTime doesn’t mind if Media Link (.qtl) files end with .mp3, .mp4, .m4a or even .mov. For example the following XML can be saved as .mp3 and once opened in QuickTime a harmless message will be prompted to the user:
<?xml version="1.0">
<?quicktime type="application/x-quicktime-media-link"?>
<embed src="http://example.com/path/to/real/song.mp3" autoplay="true" qtnext="javascript:alert('hello from backdoor')"/>
This is a quite big problem especially in default configurations of iTunes. The iTunes installation wizard installs the QuickTime player and QuickTime browser plugins and associates various media files with its components. If you open and mp3 file from the desktop it will be played in iTunes player by default, however if you open it from some website it will be played in the QuickTime player browser plugin. In this respect, users who are previewing mp3 and other media files from the Internet are vulnerable.
For the sole purpose of demonstrating how this vulnerability works I composed a quite simple and harmless proof of concept. There are two links to mp3 files at the bottom of this page. Two of these files are backdoored. One of them is a tune I composed many years ago.
- backdoored.mp3 - executes emediately
- jamesbond-overdrive-backdoored.mp3 - executes in the end
- jamesbond-overdrive.mp3 - real tune
I mentioned earlier that .qtl files can end with .mov, .avi or even .asf extension. This means that users can be fooled into executing malicious JavaScript content not only through mp3.
There is one more thing that is quite important to poin in this article. JavaScript opened from QuickTime is executed in the browser local context. This attack is also know as Cross-context scripting. In Firefox the context is “about:blank”. I am not quite familiar with about:blank but my understandings are that everything from about:* can request special privileges that will be granted without worning the user. If this the case malicious JavaScript will not only be able to read the local file system but also to alter it. This feature might be used to spread worms that go far beyond the normal Cross-site Scripting ones.
Proof of concept for this issue can be found at the following URL.
trackbacks
- shiftzwei » Blog Archive » Apples Quicktime Browser Plugin führt JavaScript aus
- Depressive Developer » F?hr! Mich! Aus!
- Da PingMachine.org Website » Archive du blog » Une backdoor dans un MP3
- Omar Khan’z » Backdooring MP3 Files
- Dinis Cruz Blog » Blog Archive » Firefox Dump
- GNUCITIZEN » Backdooring Images
- Planeta cPanel » Top 10 Web Hacks of 2006
- Top Web Hacks of 2006 » Hack Report
- GNUCITIZEN » DANGER, DANGER, DANGER
- 0DAY: QuickTime pwns Firefox | GNUCITIZEN
- Severe QuickTime vulnerability in Firefox disclosed : Mozilla Links
- Ryan Naraine’s Zero Day mobile edition
- IT Security mobile edition
- Info World » Blog Archive » After attacks, Apple fixes QuickTime bug


comments
Hmm doesn’t seem to do anything on my Mac …
Once again very good and intresting research.
So basicly anything played in quicktime can be backdored?
So basicly this is a quicktime problem. I am not an iTunes user but if you say that quicktime gets installed with it and used has default for several media files then it gets a bit scary :S
I personly only use quicktime(not actual quicktime but the alternative codecs) when i can’t use anything else, but i believe most persons would use quicktime to play everything if its the default player.
PS: I just tryed the files number 1 and 2 and they won’t open (say the files are corrupt) in winamp nor media player classic nor foobar2000, so i guess backdoring a mp3 file makes it only open in quicktime.
keep posting mate
Allan, I don’t know about MACs. However I am almost sure that it must work. Maybe I should get a MAC from somewhere and start playing with it.
nrg, yes it affects QuickTime and everything else that is based on it. As long as your applications can read QuickTime Media Links and support the “qtnext” attribute of the “embed” element they are vulnerable.
QuickTime is associated with .mov files mainly and several other formats. However if you have iTunes installed any .mp3 link will open the QuickTime browser plugin. I have a default installation of iTunes.
pdp,
This doesn’t seem to affect v6.5 default install. This is odd as I can see support for qtnext back in version 5. However, it does affect the latest version when I tested it.
Hi,
I tested the first two .mp3 on my Mac (Mac OS X 10.3.9 with Safari 1.3.2 and Quicktime Player 7.1.3)
Result:
In Safari: Both demos are working, an alertbox opens
In Quicktime Player: Opens and “plays” the files, but nothing else happens
In iTunes 7.0: Doesn’t open the files
Regards
Carsten
about:blank is as unprivileged as you can get in Firefox. Some about: pages are privileged (about:config, for example) and there were previous security vulnerabilities where researchers were able to leverage a “same-origin violation” flaw into code execution by injecting script into an about:config window or frame.
But about:blank is a different kettle of fish.
Hi Daniel,
I was experimenting with about:blank and yes you are right, it is unprivileged. However, it seams that it could be possible to access other about: resources.
I copied the code below to a text file, saved it and named it a .mp3 and it didn’t give me a prompt.
the first example backdoored mp3 didn’t work for me, but the second one (which printed at the end) did.
this issue is also present in Windows Media Player Clasic with QuickTime Alternative. I wasn’t able to execute it from the browser but there was no problem when files were opened from the desktop.
Some more data: I gave the links a click using Firefox 1.5 - the backdoors did nothing, the genuine tune played. I use the NoScript extension, so I tried disabling that - same result.
usefull cuzz it happened 2 me every tim i just explore a file with mp3 in it the explorer closes and starts again and when i scanned my comp i found the amount pf viruses = 2 the amount of songs (mp3 files) but i really cant fix it can u help me ????
nice!!!!!!!!!!
Doesn’t works on Mac OS X with the latest Quicktime updates.
Might be a Windows Quicktime only problem then.
Nice work ! But Kaspersky AV blocks these backdoored mp3 files.
I get a broken file, when using IE6 and QT 6.0.
Hi, thanks. but my Kaspersky AV blocks this files :(