Thread

I am running EE 1.6.3. on a public-facing website.  We have a paid EE license, which I can provide the key if needed.

Recently, I noticed a bunch of users in my “members” table that should not be there. One was even a superadmin.  I have not configured the site to allow for users to self-register, and even more disturbing one of these rogue members was listed as a SuperAdmin.

I am not the only superadmin on the site, but these were pretty clearly spam accounts (with names like Free Tax Advice and similar). 

When looking in the CP logs, none of those rogue users showed up as having been created (so I assume they weren’t created via the CP UI), where accounts that I created do show up in the log.  They also don’t show up as ever having logged in, though if they don’t show up as created either, I should probably assuem that the CP log is not infallible.

I deleted the rogue accoutns, and they have not come back in the 24 hrs since.  I was not able to discern any malicious activity on the site, but I don’t know enough about digital forensics to be sure I didn’t miss something. 

I’m extremely concerned that this site is now vulnerable, esp. since I didn’t see anything in the change logs of the later versions of EE after mine to indicate that a SQL inject bug of this magnitude has been found and squashed.

Almost all web hosting services permit access directly to the MySQL database, usually via phpMyAdmin. 
If your MySQL username and password are easy to guess, and ditto the URL for phpMyAdmin web access,
then someone can hack in using a brute force (e.g. dictionary-driven) MySQL username / password guessing attack. 
Try using more complex username and password with upper and lower case, numeric characters and maybe symbols.
The hacker may well have added advertising spam and pingbacks that make it look as if your site is originating the spam.

Thanks for the advice, but the username and password to the db & phpmyadmin are already good on teh complexity scale.  Longer than 8, using upper and lower, numbers and symbols, and are not real words in any language. 

It seems unlikely, based on that, that that’s how it happened, but if you have suggestions on how to determine what the vector of the attack was, I can try and run it down.

If you’re sure it’s SQL injection then are you using custom-made forms (that store data in the database and)
that have not been hack-proofed against SQL injection (by stripping out special characters entered into the forms)?
There are useful articles on the web like this on security.
Another possibility: if your site is in a “site.com” folder on the web server, check the permissions on that folder. 
It should not be world writeable, or other server users may put rogue files there.
Did you check file dates to try to spot rogue files?

Thank your for reporting this, pavenc. This is on a shared host, I presume? If so, a successful directory traversal attack would reveal your MySQL password in config.php. Only your host would be able to confirm this, though.

That said, it is urgently recommended that you upgrade. 1.6.3 is almost 2 years old by now.

Agreed- first thing to do is get on the latest version.  If you have backups of the database from before purging those members?  It would be handy if I could take a look at a few of the records from the exp_members table.  In addition- see if there is a matching member id for the spam users in exp_member_data.  Let me know if that’s possible.

Also- any custom code on the site?  Custom forms, third party modules/plugins?

ETA- and you definitely have in ‘Members- Membership Prefs’ “Allow New Member Registrations?” set to ‘no’?

wow, ok.  I am certain that was set to ‘no’, but it’s now set ‘yes’, and I can’t change it.  I change it to ‘no’ and get an error that the ‘httpdocs/images/avatars/uploads/’ is not writeable, and that I should change the perms to 777.  That seems like a very weird error to me, so was hoping to verify that that’s normal behavior before executing. 

I will upgrade the site.  We do have a number of third party modules, but none that are in-house created.  Modules we’ve added:

Akismet
Blacklist/Whitelist
Comment
Email
Emoticon
Fresh Variables
Photo Gallery
Mailing List
Member
Query
Referrer
Search
Statistics
Trackback
Weblog

Thanks for the help.

Incidentally I notice that the Membership Preferences page does not tell you how to turn off Profile Triggering and
Public Member List default (I recall that older versions of EE had public member list turned on by default). 
Maybe this default is not changed if older versions are upgraded?
If any of the Admins. used the same User Name and Alias, and a “log on form” was visible or easy to find,
then a hacker would only have to look at the user names and brute-force guess the password to log in as Admin.
Maybe this potential security hazard and privacy issues could be better documented. See also here.
Maybe “Allow New Member Registrations” could be reworded less ambiguously as something like
“Allow Prospective/New Members to Register Themselves”. It might be useful if control panel settings—
especially important settings—had links to online or local help docs. (long term project).

@pavenc,

I change it to ‘no’ and get an error that the ‘httpdocs/images/avatars/uploads/’ is not writeable, and that I should change the perms to 777.  That seems like a very weird error to me, so was hoping to verify that that’s normal behavior before executing.

This is normal if you missed setting those permissions during your original install. See Set File Permissions here to make sure you have others set correctly.

@KeithW,

(I recall that older versions of EE had public member list turned on by default)

This is done on a member group basis under Member Account Privileges

CP Home ›  Admin ›  Members and Groups ›  Member Groups ›  Edit Member Group ›  Members

EE Docs : Member Groups - Create/Edit

If any of the Admins. used the same User Name and Alias, and a “log on form” was visible or easy to find,
then a hacker would only have to look at the user names and brute-force guess the password to log in as Admin.

Under Using Banning you can restrict usernames and screenames

CP Home ›  Admin ›  Members and Groups ›  User Banning