Tagged as: Blackhat

I've discovered a sort of "remote code execution" vulnerability that affects all Linux desktops, particularly Fedora and Ubuntu but most likely all desktop Linux distributions could be affected, except for maybe Arch or Gentoo with extremely customized installations.

First and foremost: this requires the victim to click not one, but two random links sent to them over Pidgin (or any other program that does URL auto-linking the way Pidgin does). So it's not exactly the most severe vulnerability, but I found it interesting nonetheless.

Read more...

Tonight, my great aunt Connie needed some help with her computer. Normally, I don't do tech support for Windows users, but it was kinda too late to object to it because my grandma told her I'd be able to help her before even asking me. So I figured I'd just give it a look, tell her to what extent her computer is messed up, and tell her what she should do about it, and not break a sweat doing anything to actually help.

Luckily, this wasn't one of those typical, "I've installed eleven different PC cleaning programs and they all installed all kinds of malware and my computer takes two hours to boot and etc etc".

Instead, her only real concern was that when she logs on to the desktop, she gets this window popping up telling her the computer is infected with X amount of viruses, then it will pretend to scan your computer, and finally tell you to buy the full version to take care of the infections.

Yeah, one of those viruses.

I noticed that the desktop was solid black except for the task bar, and no icons were on the desktop. All that was visible on-screen was this one window. And, this window refused to close: it simply ignored the X button being clicked. I right-clicked on the task bar and noticed that "Task Manager" was greyed out.

Great, it's one of those viruses that disables Task Manager. Starting taskmgr from the Run dialog confirmed:

Task Manager has been disabled by your administrator.

I've seen the likes of these before. Usually, if a virus does this (and a lot of viruses do), they'll also disable your Registry Editor, so that you can't just go in and re-enable the Task Manager. I was expecting I'd need to write a program to fix the registry for me because Regedit would be disabled, and if so, this is where I would've called it a day.

Fortunately, the virus didn't stop me from getting into the Registry Editor. So, I went in and re-enabled Task Manager. I just had to make sure I deleted the following key from both HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE (in this case, only the LOCAL_USER was affected by this and all the other registry changes).

\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableTaskMgr (1)

In Task Manager, I first killed off that GUI, and a couple other suspicious looking names.

Back in the Registry, I went to the Run and RunOnce keys in both places to find the name of the virus (viruses always place their keys in these places in the registry). It turns out this virus's main EXE file was under C:\Documents and Settings\All Users. So, I went there in Windows Explorer.

This folder was completely empty. OK, the files were all hidden, so I went into the Folder Options to enable the "Show hidden files/folders" option. There they are! I saw the hidden EXE's that this virus was running off of. After a few seconds, all the icons disappeared again. Clever virus! It changed my "Show hidden files/folders" option back off again.

I turned it back on, and deleted these files. Then, I rebooted the computer (since I removed all the startup keys--and made sure I looked in the "Startup" folder of the start menu)--the viruses weren't likely to start back up after a reboot. I was right. Virus has been neutered. Now I had to clean up the damage.

First, I had to fix the desktop. The virus had disabled right-clicking on the desktop, disabled desktop icons, and disabled the ability to set the desktop wallpaper. I had to fix this by deleting these keys from the registry (again, only under CURRENT_USER, but check for LOCAL_MACHINE too if this ever happens to you):

\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoViewContextMenu (1)
\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDesktop (1)
\Software\Microsoft\Windows\CurrentVersion\Policies\ActiveDesktop\NoChangingWallpaper (1)

This let me restore the desktop to its original glory. Then, I noticed the Start Menu was just absolutely empty. There were no "recently used" apps in the menu, and when I moused over the "All Programs" link, I just got a small pop-up menu that said "(empty)"

So I right-clicked the Start button to "Explore", and noticed that all the start menu folders were marked as hidden. This was done in the local user account and the "All Users" folder. So, I un-hid all these folders to bring back the start menu items. But, this virus did something even more evil than that: it deleted every shortcut file from the Start Menu.

So, we got all the folders back in the Start Menu, but every folder was empty. Like, "Start->All Programs->AOL Instant Messenger->(empty)".

This virus really went to great lengths to make my great aunt's life more difficult. I neutered it and undid most of the damage, but there's no automatic way to restore the Start Menu shortcuts. Plus, I noticed that many of the programs mentioned in the Start Menu aren't even installed anymore at all. Maybe the virus actually deleted as many programs from the computer as it could? The only programs in "C:\Program Files" were core built-in programs that come with Windows (speaking of which, every folder in C:\Program Files was marked Hidden as well!)

If this was my computer, I'd reinstall the OS. But it's not, and I'm not getting paid for any further tech support, but figuring out what extent this virus messed up the system was fun enough in itself.

As some of you may or may not have known, in the past I wrote a keylogger in Perl for Linux systems. The purpose was to see what my significant other was doing to my computer while I was away from it, and certainly not to log passwords and things that malicious people use keyloggers for. I posted the source code to it here with the express disclaimer that it should be used only for educational purposes. ;)

Well, that keylogger had its problems. Although it had a couple of pros in there too compared to my new keylogger. The problem it had was that it required you to have root privileges on the Linux system you run it on, because it needed to read from /dev/input/* devices directly, which only the root user has permission to do. It also needed you to figure out which device node to read from ahead of time. And finally, it didn't work on some types of keyboards (I only tested it with a USB keyboard but I've heard reports from others that it just doesn't work for them).

The only pro it had was that it would log keys at the hardware level, including on text mode terminals.

Enter the New Keylogger

After reading this blog post about GUI isolation in *nix, I found out the trick to reading keys in the X Window System without root privileges. So, I wrote a new keylogger to take advantage of this new information I learned.

And so, the new keylogger does not require root privileges! The new keylogger relies on the X Window System, though, but this is the de facto windowing system on just about every Linux/Unix system out there today. This also means it will only log keys entered into graphical applications (for desktop *nix users though, this would log keys for just about everybody) so users in a text-mode terminal won't be logged.

One issue I ran into though is that the xinput test command seems to expect you to have a terminal (or TTY), i.e. that you run the command from a graphical terminal. So trying to read the output of this command in Perl caused some weird buffering issue, where the command wouldn't give any output until about 100 characters were typed. So, the script requires the IO::Pty::Easy module which creates a virtual TTY so that xinput believes you're running it from a real shell.

The new keylogger's source code can be found here. Have fun! :)

More Ideas

They say that the Qubes system isn't vulnerable to this. In Qubes you basically set up different "security zones" for your various apps, to prevent the apps from messing with each other. On the back end it seems that it just uses multiple X servers to partition off the various zones. I have an idea how my keylogger could defeat even this...

When run from a graphical terminal, the $DISPLAY environment variable is already set to your current X display, e.g. ":0.0". But when launched from a non-graphical environment, the script would need to set the value of $DISPLAY itself, in order for xinput to know which X server to connect to.

Well, maybe if the keylogger changes up the value of $DISPLAY to log from different X servers it may be able to cross the partitions set up by Qubes. I'll have to investigate this further. (6)

Over a period of time I've put together two Perl scripts to help monitor a Linux desktop system.

Why? To see if anybody else uses my computer when I'm not there, and to see what they were doing with it.

screenspy - Linux desktop monitoring daemon

This is the visual desktop monitoring script. It takes quite a lot of screenshots during periods when the desktop is currently being used.

Basically, you run this script as root, and it monitors your major hardware input devices for any activity. By default it watches /dev/console (which, on Fedora systems, seems to output data whenever there's keyboard activity), and /dev/input/mice (which is a common node for the collective input of any and all mice attached to a computer).

When it sees any activity at all on either of these devices (it doesn't care what the devices are doing, it just cares that they're active), it begins taking screenshots. If you use the keyboard or mouse for a little bit, and then stop for 2 seconds, it takes a screenshot. If you use the keyboard or mouse constantly and don't stop, it will take a screenshot every 5 seconds.

So it essentially creates a visual log of everything you were doing on the computer; every time you type, stop typing, type like crazy, move the mouse, stop moving the mouse... anything that happens, a screenshot is taken.

It uses scrot to take the screenshot, since this is the lightest-weight screen capturing program I could find. Using ImageMagick's import command is slow, and makes the computer beep, and GNOME's screensaver application can't run without showing a GUI window.

You can check it out here. You'll be required to edit the script in the "configuration" section though, at least to change the directory where it saves the screenshots to.

Since the script runs as root, the images it creates are naturally owned by root as well, and can't be deleted by the nonprivileged user, even if the user does manage to find the screenshots. Better yet, you can have the screenshots saved under root's home directory, keeping them completely out-of-sight for the user. And, to kill the script, you have to be root since it will be a root-owned process. +1 if your unauthorized users don't know your root password!

keylog - A Simple Keylogger

This is just a simple keylogger that reads from one of the input event devices, like /dev/input/event0. You run it as root again, and it saves keystrokes to a file under /tmp.

Actually, it doesn't store all keystrokes; instead, it stores what the user "intended" to type. That is, if a user begins typing a sentence and makes a typo and hits backspace a few times and then continues typing, what gets logged is what they actually ended up typing... you don't see their typo; when they hit backspace, the log buffer also deleted the last character it logged, before saving it to disk.

It separates what they type based on certain "divider characters," which includes Tab, Return and Enter. So as they fill out a web form, the script would log one line of text for each field they filled out as they tab through the form. Also, if they delay their typing for a few seconds it will dump the current buffer to the log file as well, so if they're a particularly slow typer, one "sentence" may span multiple lines in the log file.

I can't recommend using this keylogger for malicious purposes, it's just being uploaded for educational purposes only and should only be used as a personal desktop monitoring solution, if it should be used at all.

Source code: keylog.

It's generally true that Linux and other unix-like operating systems don't have the problem of viruses and malware like Windows does. Linux and Mac users don't need virus scanners except in odd cases when they act as file servers where Windows clients are likely to receive files from them (a Linux mail server can easily store and transmit e-mail attachments containing viruses, in which case it'd want a virus scanner, only to look out for the Windows users it comes in contact with).

Unix-like systems do have small amounts of malware out there, but they're more commonly called "rootkits" and they tend to take the form of backdoors and trojans left behind after a hacker has already taken control of your system remotely. Thus they affect server systems more than client workstations. For instance if a server allows root login over SSH, and the root password is weak, a hacker could get into the server and once there installs some rootkits to guarantee further access in the future, even if the sysadmin changes the root password.

For desktop users, the following are commonly cited as to why we're generally safe from viruses:

1) Unix requires executable file permissions before files can be executed.

A Windows user reading their e-mail can easily click an attachment and run it immediately. All that Windows needs for a file to be executable is that it has a ".exe", ".scr", ".bat", or a small handful of other file extensions. With Unix, the file would need to be manually given permission to execute.

So for a user to get a virus via e-mail, they'd need to save the attachment to disk, then open its properties and change its permissions to be executable, and then double-click the file to run it (or, if they like the terminal, they'd need to cd to where they saved it, chmod it, and then execute it).

All of this eliminates the issue of accidentally executing e-mail attachments. If a user has to go through this much hassle to run a virus, they're more likely to think about it for a second and wonder how good of an idea it is.

2) Unix generally doesn't give users administrative rights.

With Windows operating systems (particularly Windows XP and older versions), all users of the PC have administrative rights. It means that, if you were so inclined, you could go to the system folders and start deleting stuff, and find your PC might not boot again after that.

Unix-like systems (including Mac) don't do this, and the user that you log on as for your day-to-day use doesn't have permission to do very much. You can download and modify things in your home directory and that's just about it. So, any programs you run are also stuck with these limited privileges. If you download an email attachment, give it executable permissions, and execute it, it's not gonna be allowed to do very much that you yourself aren't allowed.

Can it potentially get your saved passwords out of Firefox? Yes. So I wouldn't recommend trying to run things that are likely to be malicious. But can it affect your system as a whole? Can it get into other users' accounts and get their passwords? Can it infect your boot sector? No, no, no. They need root (administrative) privileges to do any such thing. If a normal user does run a malicious program, it's their own problem. Not like on Windows where it becomes everybody's problem because the system itself has become infected.

3) To do anything administrative, you need to have a password.

Usually you'll need to know the root user's password, as it's the only user with full rights to make system changes. Windows Vista prompts you for permission to do anything, but it doesn't ask for a password, and the prompt it gives you can be automatically accepted by a running program that can simulate mouse clicks on your behalf. So Vista's security model is hardly better than XP's.

On Linux systems the user passwords are typically kept in the file /etc/shadow, and are encrypted using a one-way hashing algorithm. If a hacker has a hashed password, it makes it easier for them to crack it, because it takes out the element of having to go through another system to do so (for instance, brute force login attempts can be handled by the server locking out the account after enough failed attempts). If the hacker has the hash, they can do their own cracking "offline" and only bug the server again once they know the password for sure.

But /etc/shadow is owned and read-only for the root user. So, the regular limited user account that's executing a malicious program doesn't have permission to even read this file, so the program can't even get the hashed passwords out of it.

So to do anything administrative, a password is needed (either the user's password or, more commonly, the root password), and the malicious program couldn't possibly know what those passwords are, and if it were to try guessing, any decently configured system would start to get suspicious of it.

Thus it's highly difficult for a user-executed program to gain root privileges. Sometimes they're able to do it, but they usually need to think way outside the box and exploit security holes in running services to do so. But it's a major hamper in their ability to do any harm.

How Linux viruses could work:

A computer is only as secure as the user who runs it.

I'm first going to talk about package management systems in Linux. Most mainstream distributions (Fedora, Ubuntu, Mandriva, etc.) have package management systems that control installed software. The distribution's vendor maintains a default repository of available software. The majority of software a user would ever want is usually available in these repositories, from Firefox to OpenOffice all the way to development libraries like GTK+ and GStreamer.

This eliminates the user's need to surf the web and bounce from site to site downloading installers for everything. Most things are available in the software repository, and better yet, they're all cryptographically signed by the vendor, so you can be reasonably sure you're installing trusted, safe software.

But, not all Linux software is available in the repositories. For instance, Sun's VirtualBox. To get VirtualBox you go to its website and download an RPM or Debian package file and install it. To install it, you enter a password (yours, or root's). Then, at least on Redhat-based systems, RPM will complain that the package has not been cryptographically signed using a trusted key, and asks for a second password to be entered to verify that you seriously want to install this.

And this is the point I'm getting at: most Linux software that isn't directly located in one of your trusted software repositories, frankly, can't be trusted. Recent Redhat-based systems give you a second prompt if you attempt to install untrusted software.

So how can Linux viruses be downloaded? If the end user is apathetic and just types in their passwords whenever asked. They could download a package from some random website that appears legit, give their root password to install it, and at that point the package installer has administrative privileges to install that package however it wants.

The package could, for instance, install a binary somewhere, owned as root, and with permissions set in a way that, when executed, it runs with root privileges automatically, regardless of what user executed the binary. And in this way, if it were a virus, it would already have root access to the system, and could do whatever it wanted.

A malicious hacker could take an RPM package such as VirtualBox, replace the main binary with a "wrapper" program (which could launch a second "virus" program and then launch the legitimate VirtualBox binary), repackage it as a new RPM, and post it on a website promoting VirtualBox, saying the download is provided as a convenience to its users so that they don't need to go and download VirtualBox themselves. And since such a wrapper program would launch the legitimate VirtualBox app, most of its users would never know anything was amiss.

So long story short, computers are only as secure as their users are.

P.S. this could also happen to Mac OS X, but it requires less explanation; Mac doesn't have a central software repository full of cryptographically signed packages; they buy or download software the same as Windows users. But they still need a password for installation, so everything after that point still applies. Mac is still a Unix-like operating system.