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 126.96.36.199 (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.
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.
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 APIs:
CGMainDisplayID, 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 and I’ve already talked about this in another post (in italian, though). 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 calls XQueryExtension(), 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.
On OS X, it steals the system information from the following unexported system variables:
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.
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?