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.
https://www.virustotal.com/file/1c4ba1bf8003b9d66b4423e0503bf5489cd4de13b1a3038499d039baa553cd0e/analysis/
http://blog.webroot.com/2012/09/14/wirenet-the-password-stealing-trojan-lands-on-linux-and-os-x/
http://news.techworld.com/security/3378804/linux-users-targeted-by-password-stealing-wirenet-trojan/
http://news.drweb.com/show/?i=2679&lng=en
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.
http://www.h-online.com/security/news/item/Hackers-turn-remote-maintenance-tool-into-trojan-1697425.html
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
trojan.
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.
groupadd firefox
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:
ListenAddress 127.0.0.1
AllowUsers firefox
Match User firefox
X11Forwarding yes
AllowTcpForwarding no
Set up copy/paste:
$ cat get-clipboard
#!/bin/sh
screen=$1
xsel --display $screen -p -o | xsel -p -i
$ cat set-clipboard
#!/bin/sh
screen=$1
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@localhost twm -display :1
ssh -Xf firefox@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.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
