Video Screencast Help
Security Response

Exploiting Jnanabot for Fun and Profit

Created: 17 Jan 2011 14:45:08 GMT • Updated: 23 Jan 2014 18:23:16 GMT • Translations available: 日本語
Harshit Nayyar's picture
0 0 Votes
Login to vote

Lest we forget, malware is a software application, albeit a malicious one. And, like any other software application, it can have vulnerabilities that can be exploited.

Our analysis of Trojan.Jnanabot has revealed several serious vulnerabilities. One of the more interesting features of Jnanabot is its custom peer-to-peer (P2P) networking protocol. In other words, its bots are designed to be a part of a P2P network and use a custom-designed protocol for communicating with each other. This ensures that there is no single point of failure and that it is harder to trace the source of the infection and to take the botnet down. While the protocol was designed to provide some degree of robustness to the botnet, it has some flaws that allow anyone (provided they have the right know-how) to exploit them for fun and/or profit. At the very least, these flaws can be used to collect information about the infected hosts. At worst, they can be leveraged to create a fully functional parallel botnet or effect the complete takeover of the existing one.

In this blog I will document these flaws and illustrate how they can be exploited. Taking a page from the black hat handbook, we know that a successful exploit involves the following steps:

1.    Identifying a target
2.    Information gathering
3.    Exploiting a vulnerability in a network service running on the target
4.    Launching further attacks

Our research has shown that Jnanabot protocol vulnerabilities make the above steps trivial.

Identifying a target

The port for Jnanabot P2P communication is determined from the IP address of the peer, using a hashing algorithm. This means that given an IP address, it is possible to determine the port on which the Jnanabot P2P service might be running—if the host is in fact infected. Moreover, if a badly formatted P2P message is sent to an infected host, Jnanabot responds with an error message. Hence, given a range of IP addresses, it is possible to scan and identify infected hosts in that range.

Information gathering

The Jnanabot P2P protocol has an information-disclosure vulnerability that can be exploited to determine the current version of the bot and the operating system of the infected host on which it is running. In fact, the bot provides access to any file to which the currently logged-in user has access. It is easy to determine the current operating system and its version from artifacts of the file system. For example, the following chart shows Jnanabot’s OS distribution, mapped in the early part of December 2010:

In addition, on Windows hosts the malware installs a keylogger that records keystrokes in a plaintext flat file on the system before uploading the file to a remote FTP server. These files are accessible via the P2P service and can reveal private and confidential details such as usernames and passwords to a remote unauthenticated attacker.

Exploiting a vulnerability

The Jnanabot P2P protocol has a vulnerability that allows the user to upload any file to any location of the host’s file system. This can be easily exploited to run a simple backdoor on the infected host. For example, a file created in the startup directory in Windows will run every time Windows restarts. An attacker may also install a rootkit to cover his or her tracks and/or hide the backdoor.

Launching further attacks

Each Jnanabot agent maintains a list of peers. The P2P protocol provides a way of updating this list and also obtaining this list from a host. In addition, this list is present in encrypted form in the root directory where Jnanabot is installed. Hence, if even a single peer in a network is known, its peer list can be used to identify further targets whose peer lists can in turn be used; in this way, a large list of exploitable hosts can be obtained. A single peer can be used as a springboard to dive ever deeper into the Jnanabot network. Note that each list can have a maximum of 100 peers—making it highly probable that at least some of those peers will be accessible and available for exploitation.

Conclusion

It is not possible to determine if the existence of these vulnerabilities is known to Jnanabot’s creator(s), who either have a callous disregard for them or are simply unaware. We also do not know if there are others in the black hat community who know of these issues and are exploiting them. In any case, a host infected with Jnanabot has its doors wide open with a big “Welcome” sign inviting further exploitation. As such, the presence of Jnanabot on a host poses a threat much more grave than previously thought. Put that together with the fact that Jnanabot can infect multiple platforms, and we have a recipe for disaster.

Note that Jnanabot is written in a secure language, using advanced cryptographic techniques with strong algorithms. Yet, it allows for a complete compromise of the host on which it runs. This goes to show that depending solely upon secure platforms cannot ensure application security. Logic bugs are platform independent and can affect any application, including malware. It also demonstrates how a single malware infection can open the door to further infections and compromise the overall security of systems and networks.