Aug. 6, 2015, 10:52 a.m. by mati

We discovered that was compromised via a security issue in Jappix since February 17th. As a consequence, the server and all its services (this homepage and are unavailable until Saturday. This article provides full disclosure on what (we know) happened and what you should do.

What should you do?

If you registered on/after February 17th or changed your password since then, we advise you to change your password. The compromised server did not host any account data (e.g. your password, roster, ...), however passwords were relayed via the server if you registered an account or changed your password (which ran on the same host). We did not find any evidence that the attackers were able to access this data, but as a precaution we still think it's best if you change your password.

What exactly happened?

Note: This obviously is a bit technical. If you are not interested in the technical details of the hack, you can obviously omit reading this section ;-). The server in question is our "auxiliary HTTP host", hosting most websites related to This means, and The server did not host this website itself or our APT repositories. The webchat hosted at used Jappix. The file server/file-share.php is essentially an anonymous file upload script. Since $users (see line 39) was completely unverified, the attacker could upload paths outside the intended upload root, allowing file uploads to any location the web server has write-access to. The attacker was able to override the intended filename, most likely (but we're not yet 100% sure) via some control characters in the HTTP POST request. In combination, this allowed the attacker to upload a PHP script simply executing any passed HTTP POST variable. The script normally would never have been executed, but since the attacker also uploaded a .htaccess file, the attacker effectively gained shell-access (with web server privileges) to the server. The script was uploaded on February 17th, but we have found no evidence the attacker was ever able to or even intended to gain root access. But of course, all traces may have long been erased, there is no way to be really sure.

What data could have been accessed?

If the attacker did not gain root access (as everything indicates so far), no relevant data could have been accessed (aside from the very few shared images via the webchat itself). Both this homepage and ran as separate processes with a different system-user with their entire source-code only readable to that user. This homepage obviously had some privileged access to the Jabber server itself (e.g. setting passwords of users, checking if a given password was correct), but access required authentication that was not readable with web server privileges. If the attacker did in fact gain root access, it might have been used to access ejabberds XMLRPC interface (ejabberd runs on a separate server), adding the ability to arbitrarily register accounts, change passwords, check given passwords, delete an account or get a full list of accounts. The XMLRPC interface did not allow retrieving any account information like the roster or offline messages, so even root access could not have revealed that information. Log files from ejabberd do not indicate any malicious use, so if the attacker ever had this ability, it was not used excessively. The account page also stored the email addresses for users, if the attacker did gain root privileges, they might have been accessed as well. If we ever receive reports that indicate they indeed have been read, we will make a separate posting on this website.