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. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped
firefoxsacija.bash
Description: Binary data
-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
