Duqu Command & Control Servers included Hacked Linux Systems

Some very interesting information was released yesterday in a follow up Duqu analysis report by Kapersky Labs. Highlights from the article include:

  • The Duqu C&C servers operated as early as November 2009.
  • Many different servers were hacked all around the world, in Vietnam, India, Germany, Singapore, Switzerland, the UK, the Netherlands, Belgium, South Korea to name but a few locations. Most of the hacked machines were running CentOS Linux. Both 32-bit and 64-bit machines were hacked.
  • The servers appear to have been hacked by bruteforcing the root password. (We do not believe in the OpenSSH 4.3 0-day theory – that would be too scary!)
  • The attackers have a burning desire to update OpenSSH 4.3 to version 5 as soon as they get control of a hacked server.
  • A global cleanup operation took place on 20 October 2011. The attackers wiped every single server which was used even in the distant past, e.g. 2009. Unfortunately, the most interesting server, the C&C proxy in India, was cleaned only hours before the hosting company agreed to make an image. If the image had been made earlier, it’s possible that now we’d know a lot more about the inner workings of the network.
  • The “real” Duqu mothership C&C server remains a mystery just like the attackers’ identities.

Wait just a minute, “Most of the hacked machines were running CentOS Linux“. Linux gets hacked? For those of you who think that Linux is invulnerable, this may be an eye opener.

What is interesting though is how did they do it? This leads to more questions. A recovered sshd log from a server in Germany caught what might be evidence of a brute force password attack:

But what is odd too is that as soon as they logged in, one of the first things done was to update OpenSSH (used for remote access) from 4.3 to 5, as this snip from a recovered Bash shell history shows :

This has led to quite a debate, some saying that the hackers got in using an OpenSSH Zero Day exploit, while others claiming that they just needed the updated features of 5 to make command and control more uniform across the board.

Also interesting is to see how many times help files and manuals are referenced in the above capture. Why would the all powerful Stuxnet attackers who breached Iran’s secure nuclear facilities and have created several 0-day attacks need to reference help files so frequently?

The simple solution is that they probably were not as familiar with this distribution of Linux. Most likely they were more familiar with Red Hat Linux Enterprise Linux which CentOS is based on.

Be it brute force password hacking or another Stuxnet 0-Day, Duqu shows that Linux is vulnerable to hackers too. And with it’s growing install base, supplanting Windows desktops in many facilities, expect it to become even more of a target.

8 thoughts on “Duqu Command & Control Servers included Hacked Linux Systems”

  1. LOL — It doesn’t surprise me they referenced the man pages several times. Easy attack vector are often over-looked. Heck I’m a total Linux sec nerd and I find myself referencing man pages all the time.

    The part that DOES concern me though is even after years and years of servers getting owned due to the fact that weak SSH credentials are used (phalanx anyone?), still nothing has changed. There is a lot of that going around lately, most of the “big” attacks you hear about aren’t utilizing 0 day, most of the time it’s glaringly obvious vulnerabilities that the average sysadmin overlooks.

    Security is and always will be in the little things :-/

    1. LOL, yeah, too bad that the shell history doesn’t show the time lapse in between commands too. If it were me, it would show like 5-10 minutes in between each command as I looked it up in Google… 🙂

      Right on, the Bible verse, “Strain at a gnat, but swallow a camel” comes to mind. I have seen a company do everything right security-wise, but then over-ride the Domain password policy in Windows so they could keep on using the same simple 7-8 character admin password that they have used for the last 20 years… Crazy! 🙂

  2. Very interesting. As all security people now, no computer attached to the internet is safe in reality. If a skilled attacker really wants to get in, they will find a way. The thing i find really interesting is the attacker referencing the man pages. If I were going to pull off a hack like this, I would have done my research a bit before. Also, notice the man sshd_config command comes AFTER the attacker edits the file. What’s up with that? I would be interested in seeing the changes made to the config file for sshd to see what was changed.

    1. Yeah I was surprised too. But apparently it is more common than not. Check out Dangertux’s post. He did pen testing for a living in a major US city and he laughed at me when I mentioned it. 🙂

      Reminds me of the time when a security guru was asked by a client what he could do to make a particular computer completely safe on the internet. The security guy bends over and cuts the network cord and says, “There, that should do it!”

      What was amazing about stuxnet was that it leaped the gap from internet attached machines to secure non-internet PCL control systems via sneaker net. So in theory even non-internet connected machines could be susceptible.

      Thanks for the feedback Richard, I appreciate it and it is good hearing from you!


  3. The man page referencing could also be indicative of either a formal or informal organizational structure.

    The coders and sec experts that engineered the trojan could be running the show, and the actual handling of the servers, post infection, could be by underlings.

    That would fit both a loose-knit network of attackers where the leaders hide behind an army of less-capable, but ideology-driven wannabes.

    It would also fit the “U.S. or Israeli government” theories, as you’d have a formal organization launching the attack, with expensive assets involved in the engineering and initial deployment, but entry-level analysts handling the day-to-day.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.