Wirenet, the first (?) real malware for Linux.
robert at linuxfromscratch.org
Tue Jan 1 10:11:13 PST 2013
On 12/29/12 13:50, Aleksandar Kuktin wrote:
> Note that this mail is cross-posted to lfs-support, blfs-support and
> lfs-security, with a "Reply-To" set to lfs-security.
> This is also the first mail on the lfs-security list in at least three
> years. Yaay!
> Anyway, the news is from august/september of 2012, so it's a little
> stale. However, the search function over on LWN returns NULL when asked
> for "wirenet". OTOH, Forbes and The Register both wrote a small article
> each on the subject. A bunch of other sites copy-pasted the content
> from each other. H-Online also wrote a /very/ interesting article on
> the subject, discussed below.
> I have discovered this only today, and purely by accident. And then I
> thought it would be prudent to warn the LFS community about it.
> A Russian security firm called Dr. Web has discovered (made public ?)
> what they call a trojan capable of infecting Windows, MacOS X and Linux.
> Unlike the event about a year ago when a Java worm accidentally
> infected the Java plugins of browsers running on Linux, this is the
> real deal. ELF executable, X system API calls, Linux syscalls.
> According to Techworld, Dr. Web received the sample from Virustotal. I
> have not found any infomation regarding "the dropper" (a different
> malicious program which installs this malware on the computer), or any
> information regarding the specifics of Wirenet's point and method of
> entry. There is also no word on the method Wirenet uses to survive the
> shutdown-bootup barier.
> The post on Webroot goes to great lengths to explain (some) details of
> Wirenet's operation. Wirenet goes after the password caches of Firefox,
> SeaMonkey, Chrome/Chromium, Opera, Pidgin and Thunderbird. No word on
> whether it also targets keyrings of various PGP implementations (which
> is THE treasure stash, IMO). Wirenet is also capable of taking
> screenshots, keylogging (both of these via Xlib), remote code execution
> and possibly other things.
> H-Online has a very interesting take on the subject matter. They
> basically assert that the program was written by World Wide Labs under
> the name NetWire as a legit (ha-ha) remote administration/remote
> monitoring tool, but that it got coopted to operate as a malicious
> In light of that, and taking into account the current lack of a clear
> infection/boot-cycle-survival mechanism, it is entirely possible that
> Wirenet is a tempest in a teapot, malware without the dropper, a
> horsecart without horses (I'll stop now). IOW, I am not sure if it
> "exists" and does damage in the wild or not.
> The really interesting thing here, and the thing that really got me
> thinking, is the fact that Wirenet neither uses nor needs to use root
> to do it's thing. It exist entirely in nonpriviled userspace.
> Which makes its mitigation hard(er then neccessary).
> Speaking of mitigation, the Internets main advice seems to be "Linux is
> invulnerable to malware and you should stop worring about this, period,
> new paragraf, lalalala." Needless to say, this sort of attitude can only
> get one killed and/or robbed. In the interest of mutual safety, I will
> now describe my method of using browsers, together with modifications
> that should make one almost completely safe from this and other similar
> things (ha-ha).
> Starting with the premise that the browser has a code execution
> vulnerability, which holds true for them all on at least some days
> (WebKit, you eternal beta, I am looking at you), you can expect the
> browser to drop and start Wirenet. This is my premise. I start with
> "a day will dawn when my browser will betray me". If this happens,
> Wirenet will rob my (nonexistant - I don't store my passwords with the
> browser) password caches blind, possibly connect to the X server and do
> all sorts of bad things through it.
> However, for years I have not trusted my browsers and I have run them
> as separate users, sandboxed. My browser doesn't even connect to the
> net. It is firewalled and connects to a locally running HTTP proxy
> (polipo) and then the proxy connects to the net. Until today, the script
> which started the browser would have left the .Xauthority file in the
> browsers home directory, but in the light of Wirenet, that may be a bit
> too risky. So now it removes .Xauthority 1 second after forking the
> browser. I have attached the script starting Firefox for reference.
> So, I think that that is probabbly the only surefire way of protecting
> oneself: run the browser as a separate, sandboxed user and make sure it
> is only exposed to the X cookie for as little as it needs. Assuming
> your X server is not promiscous (I have found that running Xorg 1.11 or
> 1.9 or some such as non-root makes the server promiscous), this should
> be more-or-less good enough.
I have been running Firefox in a nested X server, and as its own user,
for a while. It works well. The purpose of this is to not allow Firefox
to have permission on :0 to listen to all display, keyboard, and mouse
events, nor have permission to read my home directory. It could also be
in a chroot, but I didn't see much benefit in that.
useradd -m -d /home/firefox -s /bin/sh firefox
install -d -o firefox -g firefox -m770 /home/firefox/Downloads
usermod -G firefox <myuser>
ln -s /home/firefox/Downloads /home/<myuser>/Downloads
Add this to /etc/ssh/sshd_config:
Match User firefox
Set up copy/paste:
$ cat get-clipboard
xsel --display $screen -p -o | xsel -p -i
$ cat set-clipboard
xsel -p -o | xsel --display $screen -p -i
When you are outside of Firefox and you want to paste in, run
'set-clipboard :1'. When you copy from Firefox and want to paste out,
run 'get-clipboard :1'.
You will probably need to adjust this Xephyr screen size.
Xephyr -screen 1358x720 :1
ssh -Xf firefox at localhost twm -display :1
ssh -Xf firefox at localhost firefox -no-remote --display :1
Add 'firefox --display=:1' to ~/bin/firefox-nested and make
'firefox-nested' your default browser.
Todo: Add buttons to TWM for get-clipboard and set-clipboard.
The final touch is to only allow the firefox user to use a local proxy,
and only allow that proxy to communicate out, with iptables. The same
setup can be done with email and irc clients, giving them the least
privileges needed for them to work.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lfs-security