We are saddened to announce that on the 24th of January 2013 between 04:02 and 04:56 GMT, that the main PublicWhip site was exploited. We became aware of this around 07:30 GMT on the 25th.
Impact to you
Anybody that has signed up to the PublicWhip website (forum or membership) will have had their plain text email address exposed, their PublicWhip username and an md5 hash of their PublicWhip password exposed. Whilst the passwords were “hashed”, they were not salted (due to interaction with other code) and hence should be declared as “in the wild”.
You are advised to change any passwords which are the same as the PublicWhip one.
You will no longer be able to log in to PublicWhip as the accounts have been wiped from the server.
No financial information was exposed.
We are sorry for this inconvenience and any problems caused.
This exploit took advantage of an SQL hole in the code (basically, the inherited PublicWhip code did not properly “escape” data sent from the user: we’ve now been through and changed the vast majority of these to “PHP PDO parametrised queries” – we’re still trying to catch any remaining queries). This allowed the third party access to the MySQL database.
Impact to PublicWhip
What we’ve done:
- We’ve amended quite a lot of the core code of PublicWhip to prevent this from happening in the future and have setup a number of alerts to try and catch code that we’ve missed.
- We’re going to be checking for the next two weeks or so to ensure we’ve caught all changes before making the new codebase available
- Disabled the “account section” of the site as there are a number of exploitable holes that we have not currently fixed
- Changed all the passwords stored on the live database to a random 32 character string
- Changed all the email addresses stored on the live database to a random 32 character string
- Changed all the user names stored on the live database to a random 32 character string
What we are going to do:
- Over the course of the next few days, we will be emailing all 79,810 email addresses held on the PublicWhip database with details of blog post and asking them to review their passwords
- Report this loss of data to the Information Commissioner’s office (it is unclear whether we need to do this, but we’re going to be doing it anyway)
Q. How quickly did you find out about this?
A. We found out about it at around 7.30am Friday via a comment on this blog (about a web page which had been live for less than 2 hours).
Q. Have you wiped all the user data?
A. We know which divisions have been edited etc by which user id, but the live site does not have a list of usernames, email addresses or passwords that those user ids relate to. We have got off-line backups (held in an encrypted partition on our office NAS which cannot be accessed via the internet) which holds these relations: however, we have not yet decided whether just to let those backups expire.
Q. How old was the code affected?
A. The code that was exploited was nearly 10 years old and was written before PHP had various security measures (such as DBI, PDO) in-built.
Q. Does this affect any other sites hosted or maintained by Bairwell?
A. No. The PublicWhip site has always been kept separate from the rest of the Bairwell hosted sites due to a combination of resources needed and suspected security holes.
Q. Were you are of the potential of this security breach before hand?
A. No. We were aware of some basic HTML injection holes (which may or may not still exist) which just meant carefully crafted links would display set text to the user – but these did not impact the actual data storage system and did not pose a security risk. We did not know that the SQL injection issue was possible.
Q. What will you be doing in the future?
A. Once we’ve raised some more money to support development of PublicWhip v2 (please feel free to donate), we will rebuild the whole site from scratch using best practices and higher security (such as using bCrypt based password hashing). We are, actually, of a mind to not have any “on-site” login facilities at all, but allow logins managed by third parties (Facebook, Google, OpenId etc).
If you’ve got any questions about this, please do not hesitate to contact us: