The Mystery of Duqu: Part Six (The Command and Control servers)

Posted on by

The Mystery of Duqu: Part Six (The Command and Control servers) – Securelist.

For our particular server, several spikes immediately raise suspicions: 15 February and 19 July, when new versions of OpenSSH were installed; 20 October, when the server cleanup took place. Additionally, we found spikes on 10 February and 3 April, when certain events took place. We were able to identify “dovecot” crashes on these dates, although we can’t be sure they were caused by the attackers (“dovecot” remote exploit?) or simply instabilities.

Of course, for server ‘A’, three big questions remain:

  • How did the attackers get access to this computer in the first place?
  • What exactly was its purpose and how was it (ab-)used?
  • Why did the attackers replace the stock OpenSSH 4.3 with version 5.8?

Interesting read. Apparently there might have been a zero day exploit in openssh.

From: http://en.wikipedia.org/wiki/Duqu

Duqu is a computer worm discovered on 1 September 2011, thought to be related to the Stuxnet worm. The Laboratory of Cryptography and System Security (CrySyS)[1] of the Budapest University of Technology and Economics in Hungary, which discovered the threat, analyzed the malware and wrote a 60-page report[2], naming the threat Duqu.[3] Duqu got its name from the prefix “~DQ” it gives to the names of files it creates.

Here‘s an interesting comment on slashdot.

The only things you should need open to the internet are SSH (“the attackers may have used a zero-day in OpenSSH 4.3 to compromise the C&C servers initially”) and/or IPSec/L2TP. Anything else should redirect to a DMZ that does NOT route to the same subnet as SSH/IPSec/L2TP. The DMZ should not have port access to the regular network (everything should be pushed). The firewall should be set to not allow active connections out from the DMZ to anywhere, and any activity should not just be logged, but flagged and sent to the administrator. All devices in the DMZ should log to a remote (to them) syslog that is polled from outside the DMZ.

There… that’s the ideal world. In reality, this doesn’t account for people who don’t have that much hardware/expertise with VMs, for people who don’t keep up with their patches, for those who want to do an end-run around this policy to set up torrents, etc. directly from their working computer, etc.

It also doesn’t help that most gateway routers these days have some full-fledged OS inside and as a result often have exploits that can be leveraged directly against them due to inappropriate default configurations.