Skip to content

September 1, 2011 Compromised, OpenSSH Source Not Backdoored, the primary site for the Linux kernel source, was compromised sometime in August. It is believed that the attackers gained access using compromised user credentials, and then escalated their privileges to root. Early pieces of information implied that some OpenSSH source code was stored on the compromised server(s), apparently this may not be the case. So far the investigation has found that several modifications were made to the compiled OpenSSH client and server binaries running on the system to log user activity. The full extent of the changes is not yet known, and nobody has yet come forward to claim this hack.

If you’ve installed or updated your kernel or OpenSSH recently, you may want to reinstall from a known good version, although it is not yet known if any kernel sources were modified. Although in this case OpenSSH wasn’t compromised, admins can consider running some form of Single Packet Authorization, such as fwknop, as an additional layer of protection for your SSH server against these kinds of issues (backdoors) and other potential future 0days.

Hopefully more info will come to light as the investigation progresses. Hit the jump for more details.

What happened?

  • Intruders gained root access on the server Hera. We believe they may have gained this access via a compromised user credential; how they managed to exploit that to root access is currently unknown and is being investigated.
  • Files belonging to ssh (openssh, openssh-server and openssh-clients) were modified and running live.
  • A trojan startup file was added to the system start up scripts
  • User interactions were logged, as well as some exploit code. We have retained this for now.
  • Trojan initially discovered due to the Xnest /dev/mem error message w/o Xnest installed; have been seen on other systems. It is unclear if systems that exhibit this message are susceptible, compromised or not. If developers see this, and you don’t have Xnest installed, please investigate.
  • It *appears* that 3.1-rc2 might have blocked the exploit injector, we don’t know if this is intentional or a side affect of another bugfix or change.

What Has Been Done so far:

  • We have currently taken boxes off line to do a backup and are in the process of doing complete reinstalls.
  • We have notified authorities in the United States and in Europe to assist with the investigation
  • We will be doing a full reinstall on all boxes on
  • We are in the process of doing an analysis on the code within git, and the tarballs to confirm that nothing has been modified

Follow on for more info.

Share your thoughts, post a comment.


Note: HTML is allowed. Your email address will never be published.

Subscribe to comments