Wormhole attacks Solaris station

Looking at the title of this article, you might be forgiven for thinking that you were about to read the script of an episode of Star Trek. Well, maybe next time – for now it is just the story of the Wanuk/Froot worm, or what is more widely known as the Solaris Telnet worm.

The number of threats designed to work on Solaris is quite small, and these consist mostly of tools used to perform DoS attacks, although we can also add to that a fine share of UNIX-compatible threats. Writing a worm for a more common platform like Windows does not seem as ‘exotic’ as writing one for Solaris, and this was probably one of the reasons for this unnecessary creation. Of course, other reasons include the fact that the vulnerability is trivial to exploit and it was disclosed before a patch was available.

If there were a Hollywood equivalent for the virus-writing industry, that is where this virus would have been produced – it has all the hallmarks of a ‘wanna-be’. In the movie industry the following can be seen as a recipe for success: take an interesting book (it’s easier than spending time and effort creating a new story), make a small change to the meaning that the author of the book wanted to express, add some shiny visual effects and voilà – a blockbuster!

Now, for the virus-writing equivalent: substitute a vulnerability advisory/disclosure for the interesting book, change its original meaning (instead of aiming to improve the security of the affected product, the vulnerability is exploited) and then add the final touch – an extravagant payload. This seems to be the norm for worms that use exploits to spread. Furthermore, worm writers are usually lazy enough to wait for a working proof-of-concept (PoC) exploit that achieves remote code execution after the vulnerability is disclosed. It’s very hard (if not impossible) to find a worm that exploits a previously unknown vulnerability. In fact, recently we have seen only a small number of targeted attacks with true zero-day exploits and those used backdoors or trojans rather than worms. In Wanuk’s case, the fact that the Telnet vulnerability was so trivial to exploit spared the author some time because there was no need to wait for a further PoC.

You can find a fully detailed explanation of the vulnerability in the published advisories [1]. It is a design vulnerability that has existed for a long time, but which became very dangerous when a new command line switch (-f) was made available to the login utility to allow ‘pre-authenticated’ users to log in without being prompted for a password. The Telnet daemon takes whatever string was sent as the user name and passes it to the login. This way, passing ‘-f[username]’ will cause the login to consider ‘username’ as authenticated.

The first thing the threat does when executed is to re-spawn itself like a daemon (new session, all standard input/output redirected to /dev/null, signals hooked for a graceful silent exit). If the time is between 1:00 AM and 5:59 AM on the 13th of the month, there is a one in three chance that the payload will run. It waits for noon to broadcast to all users logged onto the server (by using the wall utility) either some ASCII art text or, ironically, the patch for the vulnerability that it exploits (in diff format). It also has a message, for the faint-hearted users, that displays a fake output of the command to erase the whole file system:

# rm -rf /* &
23858
# rm: Unable to remove directory /dev/fd: Device busy
rm: Unable to remove directory /dev: File exists
rm: Unable to remove directory /devices: Device busy
rm: Unable to remove directory /etc: File exists
rm: Unable to remove directory /home: Device busy
rm: Unable to remove directory /lib: File exists
rm: Unable to remove directory /net: Device busy
rm: Unable to remove directory /opt: Device busy
rm: Unable to remove directory /proc: Device busy
rm: Unable to remove directory /system: File exists
rm: Unable to remove directory /tmp: Device busy
rm: Unable to remove directory /usr/openwin: Device busy
rm: Unable to remove directory /usr: File exists

Among the art messages we find:

In two other messages, the author diverts his ASCII drawing talents against Theo deRaadt (founder of OpenBSD) and Gadi Evron, not forgetting to feed us a fake confession, in which he claims to be Sun developer Casper Dik [2]:

Hi, I’m Casper, I am a bored Sun developer and I wrote this piece of code.

The two out of three times that the threat does not run the payload between the hours of 1:00 AM and 5:59 AM on the 13th of the month, it instead gathers some statistics with IP address ranges that are used for the non-local networks configured on the server and also any IP addresses that are accessed. These statistics are generated by parsing the output of two commands:

First, the worm creates a thread to deal with the information that it gathered from the statistics above. For each range of IP addresses, it chooses a random address in the range and tries to attack it. It then increments the IP until it reaches the end of that range. In parallel, the worm creates 66 threads to generate random IP addresses (using a predefined list for the most significant byte in the IP address to increase the accuracy), and then it attempts to attack them.

The attack consists of an attempt to connect on TCP port 23 (the standard port for the Telnet service), where it passes the user name -fadm. Upon successful connection, the worm checks that the computer it has connected to is Intel or SPARC and that the operating system is Solaris 10 (SunOS 5.10 or 5.11).

Next, it creates the directory /var/adm/sa/.adm where it transfers in uuencoded form the two worm bodies (one for Intel, one for SPARC), saving them as .i86pc and .sun4. The worm then overwrites /var/adm/.profile with a short shell script to be executed on login.

To complete the installation of the worm on the compromised computer, it attempts to copy the worm file to the computer architecture as a name selected randomly from the following list:

This copy, which will look like a legitimate process at first glance, is then added as a cron job to be executed every day at 1:10 AM. To speed up the spreading process it also executes the newly created copy.

The same attack as described above is performed again in order to open a small back door that just provides a shell to the attacker on TCP port 32982. For this attack, the worm uses the user name lp for the Telnet connection. The directory for installing this threat is /var/spool/lp/admins/.lp and the file names are .lp-door.i86pc and .lp-door.sun4. Again, it will install a cron job for the corresponding backdoor copy which can be named any of the following:

Unlike most malware writers, the author of this worm paid a lot of attention to detail with his creation, and included error checks at each step. Even I/O operations on files and sockets are wrapped in nice routines that use timeouts to avoid having the worm hanging on a faulty connection. You rarely see this kind of dedication from virus writers – they are not renowned for writing good quality code. This tends to support the idea that the author of Wanuk may be a professional developer, probably with too much time on his hands.

However, in spite of all the precautions taken by the author, at least one bug slipped through. The bug is in the routine that launches 66 threads for generating random IP addresses to attack and one thread to attack the nearby networks. Before launching the threads, the virus allocates an array of 67 integers to store the thread IDs, but when it creates the thread for attacking nearby networks it attempts to use index 67 for storing the thread ID, instead of 66 (random IP attack threads use indexes 0 to 65).

One more interesting feature is that the author included code to have the worm run in test mode, which was probably used during development. If there is an environment variable named M, the worm will use that variable’s value as the IP address to attack instead of generating random IP addresses to attack. Also, when running in test mode the payload is disabled (I guess the author got sick of all that ASCII art after a while).

Even though we did not see a significant epidemic as a result of this worm (after all, how many people still use Telnet?), this threat showed once again that an increasing number of different platforms are being targeted by malware writers.

Another trend highlighted by this worm is the improved adaptability of malware to multiple architectures (which can easily be achieved for Wanuk, just by recompiling the worm and backdoor source code).