We've both found the issue and the extent and nature of the leak.
The attackers used an SQL injection attack against a specific portion of our forum software (we have notified the creators of this code both so they can fix and we can find out exactly what plugin/modification contributed the bad code) - and through that attack gained access to a subset of our mailing list table and a subset of the forum members table. The mailing list table was a compilation of Kickstarter backers and direct customers who signed up for our quarterly email list and was incomplete at the time (we've yet to send any emails to our lists). The two tables consisted of about 3,200 records. Of those 3,200 less than 300 appear to have been compromised - likely far less than that, as the attackers seem to have been frustrated by our additional security (namely our use of fail2ban and tools working with it) to detect and block repeated access to the same resources and quit their attack about 5 minutes after starting having only access 300 or less records and copied an unknown portion of that.
Due to the nature of this attack we have a clear log of all tables that were accessed - while we can only estimate the number of records accessed - we can clearly see that only the forum members table and the mailing list table was accessed. The mailing list table contained only email addresses with no other identifying information (this was by design). The forum members table contained one way encrypted passwords as well, but no attempt was made to access them. No passwords (which are all stored as one way hashes to begin with). names, addresses, or any other info was compromised. We do not ever store payment info on our servers, so that could not have been compromised either.
We have taken additional steps to detect this type of attack - and we have at this point disabled or evaluated all plugins or 3rd party code that could be susceptible to this type of attack (and rechecked all of our custom code). We do evaluate code for these vulnerabilities before installing as well, and of course our custom code is written to prevent this type of attack. Obviously this particular piece of code was not evaluated thoroughly and that is something we regret deeply - we will redouble our efforts to fully evaluate third party code and reduce the usage of complex third party code within our site. When practical we always prefer to write simple, standards compliant, secure code rather than use complex third party code.
We are thankful that the security measures we had employed, as well as the segmentation and protection of personal data did work to reduce the size and severity of this breach - but greatly regret that any breach occurred and give our full commitment to ensuring it does not happen again.
We welcome any comments, suggestions, or venting of frustration! We share in the frustration, even after an entire career in web development, SPAM sometimes beats even our careful security measures.
We hope that by being transparent and upfront about this issue and our solutions everyone will continue to visit and use this site.
Again, our sincerest apologies for this issue.
