Wirenet, the first (?) real malware for Linux.
akuktin at gmail.com
Sat Dec 29 13:50:09 PST 2012
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
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
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
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.
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 383 bytes
Desc: not available
More information about the lfs-security