Posted: Mon Jun 08, 2009 7:31 pm Post subject: SQL injection attack
This morning, California time, the Trinity forum website was subject to a SQL injection attack.
What happened
From spending all day in our website's and database's log files, the attack - which came from IP address 74.208.16.168 (infong662.lxa.perfora.net) - appears to have occurred as follows:
1. The attack found a hole in the phpNuke 8.1 software that we use for this site and was able to pass SQL statements in one of Trinity's form input pages
2. The SQL changed the name, user ID, e-mail, and the encrypted password of Ed's account (Ed's is the account with the lowest user ID number) in an attempt to gain Ed's moderator privileges.
3. Successive SQL attacks attempted to collect the user names and the encrypted passwords of the separate administrative users that that we use to administer this site (in phpNuke, there is a separate user table for admins).
4. The attacking software appears to have attempted to log into this site's administrator pages with the administrative users names and encrypted passwords.
Damage caused
After thoroughly comparing all of the data in Trinity's database after the attack against a database backup from before the attack - we backup the database every 12 hours - the only data that the attacker changed was Ed's account. Furthermore, by changing Ed's account data, they accidentally disabled his account so they could not login using Ed's account. Specifically, the attacker disabled his account by changing Ed's user ID. This stripped Ed's account of his moderator privileges and disconnected him from all of this posts so if the attacker succeeded in logging into Ed's account, there was no way to delete or modify Ed's or anyone else's posts
While the attacker was able to collect the encrypted passwords for Ed and our administrator users, the attacker was also unable to login as any other user or as an administrator I modified the phpNuke code several months ago to not use phpNuke's MD5 hashing encryption algorithm that suffers from this security vulnerability and, instead, use a much more secure algorithm that uses a salt value combined with MD5 hashing multiple times.
This makes the encrypted password extremely difficult to unencrypt. In fact, they are so hard to unencrypt that we never try. Instead, the Trinity software checks your password by encrypting it and seeing if the encrypted values match.
After I verified that only Ed's account data was corrupted, I deleted his account and recreated it using our database backups.
Has any of my data been compromised?
From our database logs, it appears that the attacker only updated Ed's account and queried the administrator's table. In other words, it appears that they queried usernames and encrypted passwords for only Ed, Fran, and I. Since the passwords are strongly encrypted and it is highly impractical to unencrypt them, the loss of the encrypted passwords does not provider the attacker with any useful data. So, while it does not hurt to change your password, it is not absolutely required.
How do we protect against another attack
Recently, security researchers (also known as "white hat" hackers) have reported this security hole latest versions of phpNuke. Since there is a good chance that the attacker exploited that security hole to embed SQL queries in the pages that they accessed, today I implemented my own fix for this security hole in the Trinity software.
Nevertheless, all websites with user accounts are constantly subject to attack attempts so we will continue to be very vigilant about preparing for and reacting to any new attacks that may occur in the future.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon Jun 08, 2009 8:30 pm Post subject:
Thanks Patrick et. al. for noticing this and tracing down the issue. For those who may remember, historically phpNuke has had quite a number of SQL injection holes in it due to poor error checking of parameters in HTTP POST requests, URL parameters, and the like. We used to have these issues a while back, but this probably is the first in a year or so. Patrick and I have spent time in the past auditing certain areas and fixing the holes, but it is always going to be an ongoing process.
Also, so everyone is aware, we store minimal information about our users, only an e-mail name and that very encrypted password. We leave processing of any sensitive data for donations up to PayPal as they spend a lot more on security and have the option of the PayPal Security Key for very security conscious users. Our computers actually see nothing from PayPal except an e-mail address...our own servers never process people's actual data, or even their real names beyond an e-mail address
We're very conscious to not store information about our users except the minimal needed to keep login accounts to allow people who want to remain relatively anonymous to do so. Problems on the trinity server do not affect anyone's information beyond trinity logins. They do not otherwise affect NeoOffice, its source code, or the integrity of downloads (all of which are in separately secured systems).
I want to thank Samwise for reporting this problem to us so quickly this morning. Samwise spend several hours with us trying to figure out what had actually happened.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
