No matter what people think about it, the increasing exposure of Linux and OS X to malicious code is strictly related to the worldwide exposure of those operating systems on desktops and laptops. In the last couple of years, more and more home users decided to switch to Linux (e.g. Ubuntu Linux, just to name one of the best known Linux distributions) or OS X. Most of these users, when questioned about why they switched from Windows to another operating system, usually answer by blaming Windows’ critical exposure to malware.

However, this increasing trend has been followed by many virus writers as well, who started writing malicious code able to target these alternative operating systems. This shouldn’t be a surprise though, as it’s the expected response of cybercrime: the more users there are using Linux and OS X, the more virus writers are interested in infecting them as well.

This is the main reason why the security industry in the last year saw a rising trend of malware attacks involving OSX. Apple also chose to include a basic malware scanner in their operating system, turned on by default and regularly updated by Apple through the system update mechanism. To be fair, we are not yet seeing the same complexity level already reached by Windows-based malware – which clearly is a good thing. On the other hand it means that malware writers have plenty of room to improve their malware capabilities on such operating systems. Things are actually quickly changing, as trojan Wirenet may show us.

First isolated by Russian security company Dr.Web, Wirenet is a trojan with backdoor features able to hit Linux and Mac users in a way that looks way similar to what trojans are currently doing on Windows. Wirenet is among the first cross-platform password stealing trojans, able to steal sensitive data from Linux and Mac environments as well as from Windows and Solaris.

How the infection reaches the operating system is still unknown, though it’s easy to assume that social engineering and unpatched flaws in Java and/or Flash plugins could have played a key role in its spreading.

When executed, the infection runs as a standard executable (ELF on Linux and Solaris, Mach-O on OSX, PE on Windows) located in the current user session. It’s easy to spot the infection (if you know what to look for) though. It’s behavior allows the infection to get access to all the user’s sensitive data it wants. Don’t forget that even ZeuS and SpyEye infections on Windows-based environments are pure user-mode infections, though they have been able to steal a critical amount of sensitive data worldwide and they are still among the most common banking infections.

The architecture of the infection is similar to most trojans on Windows: the trojan’s configuration is embedded inside its body and it’s RC4 encrypted, so that the average user can’t read any plain text data from the file. The configuration contains, among all the settings, the address to the command and control (C&C) server, where the trojan uploads all the stolen data from the infected PC. The connection to the server is AES encrypted, though the password for the encryption can be easily recovered from the local configuration data, after it has been decrypted. The current C&C server address is 212.7.208.65 (remote port 4141) and the AES password used is “sm0k4s523syst3m523” (without quotes), though this can easily change as we’ve found earlier samples of this infection using the remote address “xyl2k.no-ip.biz” and AES password “Password” (without quotes). Before stealing data, the trojan sends an authentication packet to the C&C server which contains the string: “RGI28DQ30QB8Q1F7”. It creates a mutex to make sure that just one instance of the trojan is running: on Linux the mutex is named vJEewiWD, on OSX it’s named lbOOjfsO.

Wirenet searching for sqlite database

The Linux (and Solaris) variants of Wirenet look for user profiles created by Google Chrome, Mozilla Firefox, Mozilla Thunderbird, Mozilla SeaMonkey, Opera, Pidgin and, if any of them is found, it tries to steal them and the passwords stored in them.

With Mozilla products, it decrypts the passwords stored in the encrypted signons.sqlite database by “exploiting” the same routine used by Mozilla to decrypt them (PK11_GetInternalKeySlot, PK11_Authenticate, NSSBase64_DecodeBuffer, PK11SDR_Decrypt). When looking for Opera’s wand.dat, it extracts the whole file and uploads it to its command and control server. With Google Chrome (and Chromium), it locates the Login Data folder (.config/google-chrome/Default/Login Data, .config/chromium/Default/Login Data) and decrypts the SQlLite database. When looking for Pidgin, it steals whole .purple/accounts.xml configuration file.

On OS X, on the other hand, the trojan looks for just Mozilla and Opera products, and if they are found, Wirenet uses the same techniques to steal the passwords saved in their password managers. On Windows, like on Linux, it targets Chrome, Chromium, Mozilla products, Opera, Pidgin, Internet Explorer and Microsoft Live accounts.

On all the operating systems the trojan can receive commands from the C&C server, which could be either upload data, download and execute other malicious code, steal system information, kill processes, hide windows, change window titles, enumerate all windows on the desktop (CGSGetOnScreenWindowList on OSX, XQueryTree on Linux, EnumWindows on Windows) and much more.

Wirenet taking screenshots on OS X

On both operating systems, Wirenet can take screenshots of the desktop and upload them to the C&C server. On Linux, it exploits the X11 APIs XGetGeometry, XGetImage andSaveXImageToBitmap. On OSX, the trojan exploits the Quartz Display Services APIsCGMainDisplayID, CGDisplayCreateImage, CGImageDestinationCreateWithData,CGImageDestinationAddImage, CGImageDestinationFinalize. Wirenet contains a routine able to convert BMP images to JPEG format.

To improve the stealing routine, Wirenet includes a keylogger feature on its Linux (and Solaris) and Windows versions. This isn’t really a surprise as keylogger proof of concepts on Linux are widely available online. Point here is that a keylogger can run on Linux in the same easy way as it’s run on Windows, even without root privileges. The same applies to Windows, where a simple keylogger can be written by using just a single API and it could easily intercept everything even without administrator privileges – this was the situation in Windows XP, before Windows Vista and Windows 7 where Microsoft introduced UAC, MIC and UIPI technologies, which allow the operating system to better isolate processes from each other even if they are sharing the same user session.

On Linux, Wirenet opens a handle to the Display by calling XOpenDisplay(), and callsXQueryExtension(), looking for the XInputExtension extension. It then enumerates all the devices by calling XListInputDevices(), looking for the device named “AT” or “System keyboard“. When found, it opens a handle to that device by invoking XOpenDevice() and selects the keyboard events it wants to log by calling XSelectExtensionEvent(). In the end, in a infinite loop, it logs all the keyboard events with the XNextEvent() API. Few easy steps and the keylogger is working perfectly, able to steal passwords written on a bank’s login webpage or anything else. On its Windows release, the keylogger routine exploits the RegisterRawInputDevices()/GetRawInputData() APIs – I won’t spend too much time on this as it’s a very basic keylogging routine, already widely known.

Keylogging on Linux

On OS X, it steals the system information from the following unexported system variables:_kCFSystemVersionBuildVersionKey, _kCFSystemVersionProductNameKey,_kCFSystemVersionProductVersionKey

The path where the trojan installs itself on Linux is: %home%/WIFIADAPT, while on OSX is%home%/WIFIADAPT.app

Finally, on all operating systems it is able to bind a shell to allow remote access (the backdoor feature) and it’s able to simulate keyboard and mouse activity from remote (keystrokes and mouse movements). On Linux and Windows it acts as a SOCKS4/5 proxy server as well.

Shell binding

As you may spot from the analysis of this trojan, the similarities between a classic Windows trojan and Wirenet are quickly increasing. The idea is that Wirenet looks like a real attempt to port Windows infections to Linux and OS X. In some ways it reminds me of the first password stealing trojans on Windows NT, when it was enough for Windows-based malware to implement a classic keylogger using GetAsyncKeyState() to steals keystrokes, far before they started using hook-based techniques.

It was a long time ago on Windows. Perhaps it is the beginning of a new era on Linux and Mac?

By Ian Moyse

Moore’s Law back in 1965 predicted silicon power would double every two years. But what its creator, Gordon E. Moore, couldn’t have predicted was the dramatic economies of scale the cloud would eventually bring to all of our lives. For one, it’s helped lead to a drop in price for essentials like computing power and storage by making them more accessible. But also, it’s enabled conveniences no one ever would have imagined four or so decades ago.

Today we’re able to use a mobile device with massive power and local storage to locate and download from virtually anywhere in the world an application for as little as 59 pence. Think for example of Shazam, which identifies songs you can’t quite discern after it listens for just a few seconds. Leveraging its cloud database, Shazam also lets you buy and download the song via your smartphone. All of this – the convenience, the low cost, the power on the local device – is driven by the cloud.

The Cloud has not only driven down costs, but it’s helped increased our satisfaction with – and expectations of – our Internet experience. It’s enabled mobility and delivered immense computing power to anyone, anywhere at any time. The cloud has also driven the success of many vendors and will continue to do so as developers deliver applications that are faster to market and reach a wider commercial audience at a lower cost of delivery.

 We should expect to see more changes in the size and delivery methods of the technologies we use –where very small files, programs or devices connect to the cloud where all of the benefits are stored. Such client/cloud configurations are a boon for consumerisation as our appetites for an always-connected, “iWant” lifestyle increase.

In 10 years on iPhone 14 and iPad 11, will we see applications that are free and pay 1p per use perhaps? Or will we see others employing new models that yet again change the way we digest and pay for computing power and information?

More changes to the Cloud economics that we won’t see coming are inevitable. Perhaps an update to Moore’s Law will be formed to hypothesize that the number of applications running the in the cloud will double every two years; based on today’s adoption and consumption rates, however, we’re more likely to see this being every two months.

By Marco Giuliani

In the past few weeks a Chinese security company called Qihoo 360 blogged about a new BIOS rootkit hitting Chinese computers. This turned to be a very interesting discovery as it appears to be the first real malware targeting system BIOS since a well-known proof of concept called IceLord in 2007. The malware is called Mebromi and contains a bit of everything: a BIOS rootkit specifically targeting Award BIOS, a MBR rootkit, a kernel mode rootkit, a PE file infector and a Trojan downloader. At this time, Mebromi is not designed to infect 64-bit operating system and it is not able to infect the system if run with limited privileges.

The infection starts with a small encrypted dropper that contains five crypted resource files: hook.rom, flash.dll, cbrom.exe, my.sys, bios.sys. The goal of these files will be presented later in this analysis.

The infection is clearly focused on Chinese users, because the dropper is carefully checking if the system it’s going to infect is protected by Chinese security software Rising Antivirus and Jiangmin KV Antivirus. To gain access to the BIOS, the infection first needs to get loaded in kernel mode so that it can handle with physical memory instead of virtual memory.

Many of you may recall the old CIH/Chernobyl infection, the infamous virus discovered in 1998 that was able to flash the motherboard BIOS, erasing it. Even CIH needed to gain kernel mode access to reach the BIOS, though at the time the virus was exploiting a privilege escalation bug in Windows 9x operating system which allowed it to overwrite the Interrupt Descriptor Table with its own payload from user mode, then triggering the overwritten interrupt handler and its malicious code is executed in kernel mode. Mebromi does not use such kind of privilege escalation trick anymore, it just needs to load its own kernel mode driver which will handle the BIOS infection. To do so, it uses two methods: it could either extract and load the flash.dll library which will load the bios.sys driver, or it stops the beep.sys service key, overwriting the beep.sys driver with its own bios.sys code, restart the service key and restore the original beep.sys code.

The bios.sys driver is the code which handle the BIOS infection. To read the BIOS code, it needs to map the physical memory located at physical memory address 0xF0000, this is where the BIOS ROM usually resides. Once read, the driver verifies if the BIOS ROM is Award BIOS, by checking the presence of the string: $@AWDFLA. If found, the driver tries to locate the SMI port that will be used by the rootkit to flash the BIOS ROM.

If the BIOS ROM matches the string, the rootkit saves a copy of the BIOS to the file C:\bios.bin and pass the next step to the user mode component of the infection. The dropper extracts two files: cbrom.exe and hook.rom. Cbrom.exe is a legitimate tool developed by Phoenix Technologies, used to modify the Award/Phoenix BIOS ROM binaries. Hook.rom is the rootkit ISA BIOS ROM that is added to the BIOS binary, containing the rootkit infection. The dropper executes cbrom.exe with the /isa switch parameter, passing the hook.rom file. Before actually injecting the malicious ISA ROM, the dropper checks the BIOS ROM code looking for the “hook rom” string, used as a marker of the infection. If found, it means that the BIOS is already infected and it doesn’t need to be infected again.

After that the bios.bin file has been modified, the bios.sys driver send to the BIOS SMI port the command 0×29, used to erase the BIOS flash, and then the command 0x2F used to write the new BIOS ROM code to the BIOS ROM.

The BIOS is now infected, and the dropper goes to its next step: infecting the Master Boot Record. The infection is 14 sectors long and the original MBR is stored to the sector 7. To avoid potential startup issues, the infected MBR stores a copy of the original MBR’s partition table. Finally the dropper extracts the my.sys driver on the root of the C: drive. My.sys is a kernel mode rootkit that hijacks disk.sys’s IRP major functions, by redirecting the IRP_MJ_READ/WRITE and IRP_MJ_DEVICE_CONTROL native functions. It is used to hide the infection on the disk. Even if the BIOS infection doesn’t succeed, the rootkit does infect the MBR.

At the next system startup, after the BIOS POST phase, the malicious code injected inside it prepares the full MBR infection (all the first 14 sectors are stored inside the malicious BIOS rom, 7168 bytes in total) and checks the MBR code of the hard drive looking if the infection is already present. To do it, the BIOS malicious code checks for the presence of the string “int1” at the offset 0×92. If the string is not found, the BIOS malicious rom will overwrite all the first 14 sectors of the hard drive, thus restoring the MBR infection.

The system startup procedure continues and the control now passes to the malicious master boot record. Here the malicious payload analyzes the original MBR partition table and looks for the active partition, checking if it’s using a NTFS or FAT32 file system. The malicious MBR code contains indeed NTFS/FAT32 parser routines, used to get inside the file system to look for winlogon.exe or wininit.exe file. When found, the malicious code contains a file infection payload, able to inject malicious code inside the specified file and hijack the entry point of it. Before infecting the file, the MBR malicious code checks if it is already infected, by looking for the string “cnns” at the offset 0×50 from the beginning of the PE file. This is the infection marker. If the string is not found, the infection stores a crypted payload – about 600 bytes of code – inside winlogon.exe or wininit.exe and hijacks the PE entry point to the beginning of it, saving the original entry point at the offset 0×60.

The job of the MBR infection ends here, waiting for the Windows startup which will load the  patched executable. When loaded, the payload self-decrypt its malicious code and loads in memory the my.sys driver. Then it tries to download an additional infection from the (now unavailable) URL address: http://dh.3515.info:806/test/91/calc%5Bremoved%5D.

The concept behind Mebromi is not new. In fact we must recall the IceLord BIOS rootkit published in 2007, a public proof of concept able to target Award BIOS rom, using an approach very similar to the Mebromi one – or should we say that Mebromi is more than just inspired by the IceLord rootkit?

Storing the malicious code inside the BIOS ROM could actually become more than just a problem for security software, giving the fact that even if an antivirus detect and clean the MBR infection, it will be restored at the next system startup when the malicious BIOS payload would overwrite the MBR code again. Developing an antivirus utility able to clean the BIOS code is a challenge, because it needs to be totally error-proof, to avoid rendering the system unbootable at all. The job of handling with such specific system codes should be left to the developers of the specific motherboard model, who release BIOS updates along with specific tool to update the BIOS code.

On the other hand, although this kind of infection is potentially one of the most persistent infections known out there in the wild, it will hardly become a major threat because of the level of complexity needed to achieve the goal. While a kernel mode infection or a MBR infection could still work in a generic way among all the PC out there – and they still have a huge available free space to play with, a BIOS-based rootkit needs to be fully compatible with all major BIOS rom out there, it should be able to infect all the different releases of Award, Phoenix, AMI BIOS’s out there; a level of complexity that is simply unasked for writing a good persistent infection (e.g. TDL rootkit, various Rustock releases, ZeroAccess rootkit among all). In fact, why is Mebromi only targetting Award BIOS rom? Perhaps because there was already a known proof of concept that is 5 years old targeting Award BIOS ROM available online.

Are BIOS rootkits a real threat? Yes, we can consider Mebromi the first real BIOS rootkit incident discovered in the wild – let’s consider IceLord BIOS rootkit more a proof of concept. Should we be concerned about BIOS rootkits? Well, while we try to discover whether our PC is infected by an unknown and super-stealth BIOS rootkit, let’s try and look if there is a more “humble” kernel mode rootkit which is already infecting our PC, allowing a remote attacker to silently own our system.