Category: NewsSupport Desk Attacked, Passwords Compromised

Share this post...Tweet about this on TwitterShare on Google+0Share on Facebook0

It has come to our attention that between Feb. 28 and Mar. 5, 2011, our support desk, located
at, and indirectly, via, was
compromised by an attack.

Thursday, March 10, 2011

Interworx Support Desk Database Compromised
It has come to our attention that between Feb. 28 and Mar. 5, 2011, our support desk, located at, and indirectly, via, was compromised by an attack. The investigation is still ongoing – however, at this point, we have to assume that full access to our support desk database was achieved. It is critically important that ANY login/password data that has been provided to interworx via the support desk, and has not since been changed, be changed immediately. This includes root passwords, Nodeworx/Siteworx passwords, email account passwords, your help desk password, and any other password data shared via the support desk. We strongly encourage you to do a full audit of all passwords and change them immediately to prevent unauthorized access to your system or other services which may use the same passwords. Although the support desk was previously accessible via the billing portal, the billing portal itself is segregated and on a different server, and thus was not compromised. However, we will no longer allow direct access to the support desk via the billing portal as a precaution going forward.

To make a bad situation worse, the support desk software version we use was storing e-mail and password data in plain text. Anyone using the same password elsewhere should change it immediately. We have modified the support desk software to cease all storing of plain text passwords, and we have reset ALL support desk users’ passwords to random values. In order to login to the support desk at, all existing users must use the “lost password” functionality to have a new password e-mailed to them, or register a new support desk account.

We are aware of a few clients that have had their servers modified to distribute malware javascript, as a direct result of this attack. In each case, a malicious apache module was installed in /usr/lib/httpd/modules or /usr/lib64/httpd/modules, with file name or The module was loaded via the main httpd.conf file. Initial analysis implies that the attacker logs in via SSH, compiles and installs the malicious module, “cleans up” most evidence of their actions, and logs out. As with any root exploit, there is always a concern of a root kit or other back door being left behind – tools like rkhunter ( and chkrootkit ( can help detect areas of concern.

Internal Changes
We are in the process of fully reviewing our security and sensitive-data-storage procedures, and making a number of changes to help prevent this kind of attack from succeeding in the future. We are already working hard to ensure that this doesn’t happen again and that the information your share with us via the support system is protected. Please do not hesitate to contact us if you have any questions.

Paul Oehler
CTO InterWorx LLC

Mar 11, 2011, 10:39 amBy: InterWorx (0) Comments

Leave a Reply
Surround code blocks with <pre>code</pre>

Your email address will not be published.