New backdoor worm found attacking websites running Apache Tomcat

Diagram showing how Tomdep receives commands and spreads to new machines.

Researchers have identified new self-replicating malware that infects computers running the Apache Tomcat Web server with a backdoor that can be used to attack other machines.

Java.Tomdep, as the backdoor worm has been dubbed, is Java Servlet-based code that gives Apache Tomcat platforms malicious capabilities. It causes infected machines to maintain Internet relay chat (IRC) communications with attacker servers located in Taiwan and Luxembourg. The control servers send commands and receive progress reports to and from the infected machines. Affected platforms include Linux, Mac OS X, Solaris, and most supported versions of Windows. Researchers haven't said precisely how the malware takes initial hold of servers, but there's no evidence yet it exploits any vulnerability in Tomcat or any other software running on infected servers.

In a blog post published Wednesday, Takashi Katsuki, a researcher at security firm Symantec, said Java.Tomdep appears to be designed to harness the huge amounts of bandwidth and computing power available to Web servers for use in denial-of-service attacks against other machines. Unlike Darkleech and other malware targeting Web servers, there's no indication that it's used to attack end users visiting websites. Katsuki explained:

Read 3 remaining paragraphs | Comments


All Your Tomcat Are Belong to Bad Guys?

Symantec has discovered a new back door worm-type threat which targets servers running Apache Tomcat. This threat is a little different from the ones we usually encounter every day.

Back door type Trojan horses and worms let attackers execute various commands on compromised computers and essentially enable the attacker to control a computer remotely. This means that important information can be stolen from the user and their computer could be used to attack other victims.

You may think that this type of attack only targets personal computers, such as desktops and laptops, but unfortunately that isn’t true. Servers can also be attacked. They are quite valuable targets, since they are usually high-performance computers and run 24x7. We often see back door type Trojans that are written in PHP, such as PHP.Backdoor.Trojan. This time around though, Symantec has found a back door worm that acts as a Java Servlet. We have named it Java.Tomdep.

Tomdep 1.png

Figure 1. How Java.Tomdep spreads

The Java Servlet is executed on Apache Tomcat, but it does not create a Web page and instead behaves as an IRC bot. It connects to an IRC server and performs commands sent from the attacker. End users who visit Web pages from the compromised Tomcat server are not affected by this threat. Aside from standard commands such as download, upload, creating new process, SOCKS proxy, UDP flooding, and updating itself; compromised computers can also scan for other Tomcat servers and send the malware to them. It is thus possible that DDoS attacks from the compromised servers are the attacker’s purpose.

When it finds another Tomcat server, it first attempts to log in with the following pairs of weak usernames and passwords:

Tomdep 2 edit.png

Figure 2. Usernames and passwords used in attempts to log in by Java.Tomdep

Then it deploys itself to the found Tomcat server:

Tomdep 3 edit.png

Figure 3. Java.Tomdep deploys to the found Tomcat server

We know that the attacker’s command and control (C&C) servers are located in Taiwan and Luxembourg. We have infection reports from customers in a limited number of countries.

Tomdep 4 edit.png

Figure 4. Infection report locations

As far as we know, not many computers have fallen victim to this threat yet. However, in some cases, server computers don’t have antivirus products installed on them in the same way that personal computers would. Hopefully this isn’t a reason for the low rate of detection.

In order to avoid this threat, ensure that your server and AV products are fully patched and updated. We recommend that you use strong passwords and do not open the management port to public access.

Symantec products detect this threat as Java.Tomdep and Java.Tomdep!gen1.

Repeated attacks hijack huge chunks of Internet traffic, researchers warn

Huge chunks of Internet traffic belonging to financial institutions, government agencies, and network service providers have repeatedly been diverted to distant locations under unexplained circumstances that are stoking suspicions the traffic may be surreptitiously monitored or modified before being passed along to its final destination.

Researchers from network intelligence firm Renesys made that sobering assessment in a blog post published Tuesday. Since February, they have observed 38 distinct events in which large blocks of traffic have been improperly redirected to routers at Belarusian or Icelandic service providers. The hacks, which exploit implicit trust placed in the border gateway protocol used to exchange data between large service providers, affected "major financial institutions, governments, and network service providers" in the US, South Korea, Germany, the Czech Republic, Lithuania, Libya, and Iran.

The ease of altering or deleting authorized BGP routes, or of creating new ones, has long been considered a potential Achilles Heel for the Internet. Indeed, in 2008, YouTube became unreachable for virtually all Internet users after a Pakistani ISP altered a route in a ham-fisted attempt to block the service in just that country. Later that year, researchers at the Defcon hacker conference showed how BGP routes could be manipulated to redirect huge swaths of Internet traffic. By diverting it to unauthorized routers under control of hackers, they were then free to monitor or tamper with any data that was unencrypted before sending it to its intended recipient with little sign of what had just taken place.

Read 11 remaining paragraphs | Comments


Cupid Media Hack Exposes 42 Million Passwords In Plain Text

42 Million Passwords – now that’s a big number, and the worst part – they aren’t even hashed. Nope, not at all – not even badly. Apparently the intrusion took place earlier this year, in January 2013 – but there was no public announcement. The data was found on the same server where the hacked [...] The post...

Read the full post at