Hell Pizza Hell: database security was lacking?

Comment by astroboy, on 26-Jul-2010 05:57

" it's a known fact that many Internet users simply reuse the same password in different sites. This can potentially lead to identity theft. This is serious business"

Does this mean that Hell didn't encrypt user passwords?

Comment by Kyanar, on 26-Jul-2010 09:38

Based on the comments from Hell, I'd say they were not in fact hashing passwords (regardless, they probably used MD5 even if they did, and as such most passwords can relatively easily be cracked anyway).

Spikefin Interactive was responsible for that atrocity. 

Comment by BlueToothKiwi, on 26-Jul-2010 10:37

You said, "How long since Hell Pizza had knowledge of this security breach?...  If they did have knowledge, why wasn't it disclosed before?"

I got notified last week with an email (with an option to unsubscribe - which I promptly did). The point about the password is a valid one - I have a habit of not using same password in multiple web sites - though as I get older I find it harder and harder to remember 33 or so passwords in my head!!"

Anyway here is the email I got - which I think goes someway towards taking ownership - but prevention in the first place would have been better:

"Dear Valued Hell Customer,

We have been approached by a party claiming to be in possession of customer details from the previous Hell website which is no longer in operation.  The samples that we received included details of four customers from 2006, including phone numbers and email addresses and order information. We can confirm that credit card data was not at risk as this is held independently on a secure banking website.

Whilst we are still investigating the matter, we can confirm that the information was obtained without our knowledge and we have approached the New Zealand Police with a view to lodging a formal complaint.  Hell recognises the importance of protecting customer information and additional security measures were implemented earlier this year when our new website was rolled out (again, we reiterate that this is not an issue affecting the new website). As a further security measure your may wish to consider changing your passwords on other sites if they were the same as the old Hell Pizza website.

We apologise for the incident and any inconvenience that this may have caused.

Sincerely,

Stu McMullin – Director Hell Pizza

We acknowledge that some of you have asked to be removed from the database and we have only included you for the purposes of this notification. "

Comment by richms, on 26-Jul-2010 13:12

Businesses cant really remove people from their database as so many privacy nuts request, as the database is the businesses records.

Also they are allowed to contact people that have opted out of emails for things like this so I am puzzled why they even put that link into the email

Comment by Sycophant, on 26-Jul-2010 21:19

"as I get older I find it harder and harder to remember 33 or so passwords in my head!!"

Consider creating unique passwords for each site based on a common primary password, so for maybe your base password is "t15sta7" then add two or three characters on based on the site it's for - so maybe "gz" for GeekZone - although that's a little obvious to a human, so perhaps make it a practice to pick the 1st and 4th characters for example, and insert into positions 2 and 6 in your passowrd, so it's now tg15szta7

Something like that anyway, so it's a simple base you can remember and a predictable (to you) pattern of customisation for each site.

You could still maintain completely unique passwords for very important sites (banking etc).

Comment by Janice Taylor-Gaines, on 27-Jul-2010 02:40

This is a GREAT article, despite the dismay of breaches and data insecurities, in that it keeps one of my pet concerns front and center: Security. In David Scott's words, everyone needs to be a mini-Security Officer today. I think Mr. Scott, the author, is right: Most individuals and organizations enjoy Security largely as a matter of luck. For some free insight (and free is good!), check out his blog, "The Business-Technology Weave" – you can Google to it. Anyone else here reading I.T. WARS? It reflects much of what is said here. I had to read parts of this book as part of my employee orientation at a new job. The book talks about a whole new culture as being necessary – an eCulture – for a true understanding of security, being that most identity/data breaches are due to simple human errors. It has great chapters on security, as well as risk, content management, project management, acceptable use, various plans and policies, and so on. Just Google IT WARS – check out a couple links down and read the interview with the author David Scott at Boston's Business Forum. (Full title is I.T. WARS: Managing the Business-Technology Weave in the New Millennium). "In the realm of risk, unmanaged possibilities become probabilities." Keep "security" front and center! Great stuff.

Comment by dman, on 28-Jul-2010 00:16

I'm disappointed Spikefin has won awards:
http://www.ictcapital.com/news/news-list/silverstripe/?page=creative-hq-

Comment by Private, on 7-Dec-2011 18:32

I know I'm a bit late on this post, but I can remember back when that first website was launched, having a poke around and being shocked with the sql_engine.jsp, which then moved to sql_engine2.jsp.

After a few years the website was replaced (by spikefin) with a shiny new one (seemingly free of SQL injection attacks), but for some reason the old one returned yet again with sql_engine2_secure.jsp. It entertained me that anyone could ever think that prepending 'SELECT ' to the start of the query would make it more secure, especially because the server would parse and execute nested and multi queries.

The interesting thing about the whole story is that nobody seemed to pick up on was the way the 'static' content of the site was loaded from an xml file, and after adding a couple of ../'s to the start of the URI, you were able to browse the contents of almost the entire server. From this I concluded two things;
1. Apache was running as root
2. Whoever coded the site had even less idea of data sanitisation than I initially thought.

Having read access to the server wasn't really enough to do any damage, but it was plenty to read the dsn, which was present in multiple files. (not so) Coincidentally, the database connection was also being established as root.

What I tried next shocked me, not only because ssh was open on port 22 of the production server with no apparent IP restrictions, but root login was enabled and the password was the same as that of the database server.

Now, I could have done some damage, but I'm a nice person so all I really did was look at some logs. Interestingly, there was actually some fairly good logging practise for such a vulnerable system. They were using an external syslog server for most things, but all the apache logs were on that machine. This was almost pure gold - about 99% of the time, the flash application was POSTing to sql_engine, while illegitimate queries were coming in on the query string, complete with IP addresses and payload sizes.

It's funny that the first thing most people (at least 50) tried was SELECT * FROM customer WHERE name = [their_name]

That's got to be almost as stupid as the people who made the site to begin with?