[카테고리:] Data

Cryptology is everywhere these days. Most users make good use of it even if they do not know they are using cryptographic primitives from day to day. This two-part article series looks at how cryptography is a double-edged sword: it is used to make us safer, but it is also being used for malicious purposes within sophisticated viruses.

Part one introduces the concepts behind cryptovirology and offers examples of malicious potential with the SuckIt rookit and a possible SSH worm. It then introduces armored viruses that use shape shifting (polymorphism and metamorphism) to avoid detection.

Part two will look at some of the latest virus attempts to be stealthy and avoid detection and analysis. A continued discussion of armored viruses that use polymorphism and metamorphism 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 cryptography with a closed protocol that can be manipulated by an attacker.

Introduction to cryptology and virology

Cryptology is a domain split in two parts:

• Cryptography is dedicated to the design of algorithms ensuring confidentiality, authentication, integrity and so on. It is usually based on some kind of secret, often referred to as a key and/or specific mathematical functions (such as one-way mathematical functions).
• Cryptanalysis is the attempt to design algorithms to bypass confidentiality, authentication, integrity, and so on. It is usually based on complex mathematical theories, but certain tricks can also be used to achieve the same goals (known as operational cryptanalysis).

Due to the above split of cryptology, cryptography is regarded as a defensive science, whereas cryptanalysis is regarded as an offensive one. However, when one writes or speaks about “crypto,” our minds usually focus on it for defense.

Conversely, when we talk about virology, we immediately think about malicious attacks. Nevertheless, virology is also split into two sub-disciplines, one being offensive but the other one being defensive:

• A virus is a self-replicating program that spreads by inserting (possibly modified) copies of itself into other executable code or documents. This is regarded as offensive because of the malicious payload normally embedded in the virus, and because of the use of anti-anti-virus techniques (techniques that avoid anti-virus).
• An anti-virus is a program that attempts to identify, thwart and eliminate computer viruses and other malicious software. It is mainly built upon pattern matching (signatures) and upon identifying suspicious behaviors (heuristics).

Cryptography is used by anti-virus vendors to ensure (as much as possible) the confidentiality of the signature database, or for automatic updates to their software. But it is also used by the virus writer, for instance, to ensure the confidentiality of the virus’ payload or to avoid the detection and analysis of the malicious code (through code replacement, like polymorphism and metamorphism, which are known as armored virus techniques).

Cryptovirology

Writing a virus is just like writing any other piece of software, unfortunately. The designer tries to put some cleverness in the application to improve its function (or stealth), its robustness, its replication strategies, or even its payload. However, when an anti-virus analyst gets ahold of such a piece of code, he learns how it works, what it does, and so on. In the end, both the writer and the analyst share the same view of the virus, in what amounts to a Turing machine (we have a state-transition table and a starting state).

As is very clearly exposed in Malicious Cryptography [ref 1], the idea behind cryptovirology is to break this symmetric view of a virus. After one has done some crytpo and math in his life, when he thinks of symmetric, he also thinks asymmetric. Thus, the first definition of a cryptovirus is: a virus embedding and using a public-key.

A basic model seen today

This basic model can be seen according to intended targets:

• The virus writer creates an RSA key:
  • the public key appears in the body of the virus.
  • The private key is kept by the author.
• The virus spreads and the payload uses the public key. For example, it ciphers the data (hard drives, files, e-mail, whatever) of the targets with the public key.
• The virus writer requires a ransom before sending the private key.

There are a number of recently examples of this approach, such as GpCode and Krotten. Fortunately, this protocol has some weaknesses. First, there is the aspect of anonymity: how does the virus writer get the money without being caught? There is always a human being trying to collect the money. Then there is also a problem of reusability: what if a single victim publishes the private key? One approach virus writers could have may have the victim just send his encrypted data to the writer, who then sends it back deciphered, but this would mean the attackers have the data in clear text… and the target may not allow that to happen, preferring losing his data.

A hybrid cryptovirus model

Next, a hybrid model was proposed that uses both asymmetric and symmetric cryptography:

• The virus writer creates an RSA key:
  • The public key appears in the body of the virus.
  • The private key is kept by the author.
• The virus spreads:
  • The payload creates a secret key.
  • The secret key is used to cipher data on the disk.
  • The secret key is ciphered with the public key.
• The writer asks for a ransom before deciphering the secret key.

Target harvesting, delaying analysis, and stealth

As one would notice from reading Malicious Cryptography [ref 1], the usual question for an author of a cryptovirus is: how can I use a given crypto technology in virology? We will try here to reverse or extend that state of mind with two more pointed questions that the cryptovirus writer considers:

• How can we improve a given tactical factor with cryptology?
• How can we maliciously use cryptology?

In order to combat this emerging threat, we must first understand the approaches used. We will focus on three important properties a malicious author uses. The first one is target harvesting, which is the mechanism used to discover valid targets to infect and control the spreading of the virus. The second goal of a cryptovirus author is to delay the analysis, that is, finding ways to delay or even prevent the understanding one can get on the malicious code. And the last important property is stealth, as not being detected is a good way not to be caught.

A matter of precision

As previously stated, crypto is everywhere. For instance, on networks some layer 2 protocols are based on crypto (WEP, WPA/TKIP, and others), as are some upper layer protocols (IPSec, SSH, SSL, Kerberos, PGP, and so on). It is therefore used for many purposes, from authentication (with passwords using pre-shared keys, key exchange, tokens) to ciphering (with AES, DES, 3DES, IDEA, RC4, and many other mysterious acronyms).

However, independently from the kind of crypto which is used, one can be sure that when crypto is used at one end of a communication channel, it is also used at the other end. Moreover, there is often either a (weak?) password or a trust relationship between these entities. And remember that cryptographic protocols are usually complex, and require many conditions which are not often checked in their actual implementation. So let us exploit all these “features” in our look at cryptovirology, to get inside the mind of those with malicious intent.

In this part of the article, we will see how cryptovirus writers try to use crypto to find targets with a good accuracy, using a much better than the approach some older worms have done in the past (such as when they generated a random 32 bit number as an IP).

A brief recall of SuckIt

The SuckIt rootkit will not be deeply detailed here as it has already been covered in a previous article. [ref 2] So, let us just focus on the cryptographic part of this rootkit. Whatever the version used, its authentication is inherently flawed. Hence, when one finds a SuckIt binary, it can be used to enter the network of SuckIT-infected hosts owned by the attacker and understand what the attacker is doing.

The above is possible because SuckIt authentication is based on the comparison of two hashes. We do not need to retrieve a pre-image for the hash – having the hash is enough. So we just need to slightly change the client so that it sends the hash directly to the server, without asking us anything: replay of this is possible as much as we want.

The problem is then to find where to replay. The first place to look at is where the intruder comes in from. It is usually a compromised host, on which he may have installed and used a client with the same password. Attackers are human beings and like all users, they can not remember too many complex passwords. Hence, the host of the attacker is often the same password used on a SuckIt network. The second interesting place to find the intruder is with a capture performed by the SuckIt rootkit itself. A file .sniffer is hidden in the secret lair of the rootkit. And if the intruder used a SuckIt client on the compromised host, it also contains the traffic to other targets… and the hash, of course.

Design principles behind an SSH worm

SSH is now a well know protocol, based on many cryptographic protocols, and it’s used by many (if not all) system administrators on the Internet. It is designed to allow one to log into a remote machine and execute commands on it securely. Many authentication schemes are available to the clients: password, challenge/response, kerberos, public cryptography, and the list goes on. The server is identified by an asymmetric key. SSH also offers many more cool features: TCP proxy, secure ftp, forwarding agents, and so on.

Let us imagine what an attacker might use to create an SSH worm based on all these features. Of course, just as every worm does, this one could use an exploit targeting an SSH server. However, while this is the most obvious way to intrude into a remote SSH server, it is not the only one. Therefore if the worm could use such an exploit, fine, but it is not a necessity.

Let us suppose patient 0 is a compromised host with many users, and our worm has the highest privileges on this host, that is, it can change its identity to impersonate every local user if needed. As a side note, such a worm could also carry local exploits to gain similar privileges on freshly compromised hosts, and improve its spreading ability. However, for our example we will try to restrict the spreading mainly to SSH features and human weaknesses.

The first question we need to answer, when an attacker tries to design such a worm, how will it propagate on an SSH network from a single host? The answer contains two parts: first, we need to find interesting targets, and second, we need to find a way to enter into these targets as an attacker would.

In fact, a SSH network can be seen visually within a graph based on asymmetric cryptography and implicit trust relationships. Nodes are the SSH hosts. Outgoing edges reveal a remote SSH server where a user is or has connected, so it therefore indicates a target for our worm. Incoming edges show the place where a user is connected from, on the current SSH server. This may be a target, but the worm can not be sure a SSH server is running. So in this case, an exploit against a SSH client would be very useful to the attacker.

The excellent OpenSSH implementation provides all sorts of good information to discover remote servers (the outgoing edges). Remember, in this example we have the privileges of any local user, so for one of them, we could for instance:

• Look at the user’s known hosts. All hosts reached by a user have their public key saved under ~/.ssh/known_hosts. However, to preserve this information leakage, the latest version of OpenSSH uses a hash of the IP/name instead of a clear-text format.
• Dig into the configuration file ~/.ssh/config (if it exists) for the Host and go into the ControlPath directory.
• Look at current and future network connections.
• Explore the history: grep ssh ~/.bash_history

Now, let’s search for incoming the edges as defined above. We can first have a look in the file containing the keys authorized by the user, found in ~/.ssh/authorized keys. Network connections are also a useful place to look. With root privileges, one can also sniff the network and look at log files for incoming connexions.

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/configHost   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 ~/.bashrcalias    ssh='strace   -o   /tmp/sshpwd-`date    '+%d%h%m%s'`.log   -eread,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)  =9read(5, "b", 1)  =1read(5, "e", 1)  =1read(5, "e", 1) =1read(5, "r", 1)  =1read(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 ssh2Feb 9 23:25:17 localhost sshd[14238]: Failed password for invalid user admin from 80.95.161.86 port 58806 ssh2Feb 9 23:25:23 localhost sshd[14313]: Failed password for invalid user guest from 80.95.161.86 port 59243 ssh2Feb 9 23:25:26 localhost sshd[14351]: Failed password for invalid user webmaster from 80.95.161.86 port 59445 ssh2Feb 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. 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 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.

SecurityFocus Disclaimer

The nature of cryptography has become one where it can be used for malicious purposes just as it is used to make systems and networks more secure. SecurityFocus, and its parent company Symantec, do not necessarily endorse the approaches discussed in this article. The editorial team abides by the ethical mantra of Do No Evil, and we believe that cryptographic approaches must be discussed from all angles if they are to truly keep us safe.

http://www.securityfocus.com/infocus/1865