Re: Wirenet, the first (?) real malware for Linux.

This is a multi-part message in MIME format.
--===============1432114505==
Content-Type: multipart/alternative;
	boundary="------------050405060308050809000906"

This is a multi-part message in MIME format.
--------------050405060308050809000906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.


--------------050405060308050809000906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 12/29/12 13:50, Aleksandar Kuktin
      wrote:<br>
    </div>
    <blockquote cite="mid:20121229225009.7c163133@tekarot" type="cite">
      <pre wrap="">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 class="moz-txt-link-freetext" href="https://www.virustotal.com/file/1c4ba1bf8003b9d66b4423e0503bf5489cd4de13b1a3038499d039baa553cd0e/analysis/">https://www.virustotal.com/file/1c4ba1bf8003b9d66b4423e0503bf5489cd4de13b1a3038499d039baa553cd0e/analysis/</a>

<a class="moz-txt-link-freetext" href="http://blog.webroot.com/2012/09/14/wirenet-the-password-stealing-trojan-lands-on-linux-and-os-x/">http://blog.webroot.com/2012/09/14/wirenet-the-password-stealing-trojan-lands-on-linux-and-os-x/</a>
<a class="moz-txt-link-freetext" href="http://news.techworld.com/security/3378804/linux-users-targeted-by-password-stealing-wirenet-trojan/">http://news.techworld.com/security/3378804/linux-users-targeted-by-password-stealing-wirenet-trojan/</a>
<a class="moz-txt-link-freetext" href="http://news.drweb.com/show/?i=2679&amp;lng=en">http://news.drweb.com/show/?i=2679&amp;lng=en</a>

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.

<a class="moz-txt-link-freetext" href="http://www.h-online.com/security/news/item/Hackers-turn-remote-maintenance-tool-into-trojan-1697425.html">http://www.h-online.com/security/news/item/Hackers-turn-remote-maintenance-tool-into-trojan-1697425.html</a>

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.

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    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.<br>
    <br>
    groupadd firefox<br>
    useradd -m -d /home/firefox -s /bin/sh firefox<br>
    install -d -o firefox -g firefox -m770 /home/firefox/Downloads<br>
    usermod -G firefox &lt;myuser&gt;<br>
    ln -s /home/firefox/Downloads /home/&lt;myuser&gt;/Downloads<br>
    <br>
    Add this to /etc/ssh/sshd_config:<br>
    ListenAddress 127.0.0.1<br>
    AllowUsers firefox<br>
    Match User firefox<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; X11Forwarding yes<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AllowTcpForwarding no<br>
    <br>
    Set up copy/paste:<br>
    <br>
    $ cat get-clipboard<br>
    #!/bin/sh<br>
    <br>
    screen=$1<br>
    xsel --display $screen -p -o | xsel -p -i<br>
    <br>
    $ cat set-clipboard<br>
    #!/bin/sh<br>
    <br>
    screen=$1<br>
    xsel -p -o | xsel --display $screen -p -i<br>
    <br>
    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'.<br>
    <br>
    You will probably need to adjust this Xephyr screen size.<br>
    Xephyr -screen 1358x720 :1<br>
    ssh -Xf firefox@localhost twm -display :1<br>
    ssh -Xf firefox@localhost firefox -no-remote --display :1<br>
    <br>
    Add 'firefox --display=:1' to ~/bin/firefox-nested and make
    'firefox-nested' your default browser.<br>
    <br>
    Todo: Add buttons to TWM for get-clipboard and set-clipboard.<br>
    <br>
    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.<br>
    <br>
  </body>
</html>

--------------050405060308050809000906--

--===============1432114505==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

--===============1432114505==--