{"id":1162,"date":"2009-03-13T14:20:43","date_gmt":"2009-03-13T22:20:43","guid":{"rendered":"http:\/\/cubist.cs.washington.edu\/Security\/?p=1162"},"modified":"2009-03-13T14:23:07","modified_gmt":"2009-03-13T22:23:07","slug":"1162","status":"publish","type":"post","link":"https:\/\/secblog.cs.washington.edu\/Security\/2009\/03\/13\/1162\/","title":{"rendered":"Current Event: Telegraph website hacked"},"content":{"rendered":"

The Telegraph<\/a>, a famous daily newspaper in the UK, was hacked into <\/a>by a Romanian hacking group last week. The group exposed a weakness in the way the website queried its database for property searches and was able to obtain around 700,000 subscriber email addresses and passwords in plaintext via a SQL injection attack. The Telegraph took down the site and is in the process of rewriting the code to fix the problem, and is telling subscribers to change their passwords for that site and other sites.<\/p>\n

It is unknown exactly what exact SQL injection string was used to gain access to the database of user emails and passwords, but SQL injection attacks are not terribly difficult attacks to defend against. Considering the email addresses and passwords were stored in plaintext, and considering the wide range of methods to protect code from SQL injection, it is likely this attack was only possible because the coders of the website were careless and did not think much about security risks when designing the website.
\n
\nThere are several obvious things the programmers could have done to protect themselves from this attack. For one, it is clear that they did not properly validate user input. It\u2019s not clear exactly how vulnerable the search was \u2013 whether the input was completely raw or if it just didn\u2019t catch all possible illegal characters \u2013 but certainly they should have had extra precautions to sanitize the input strings. They could have also changed the permissions of the database such that users have the least privileges possible. It is unlikely that a user searching a database of properties needs access to the table with passwords and email addresses. Finally, they could have stored encrypted passwords and email addresses. Encryption doesn\u2019t solve all problems, but it is good practice anyway and is part of the system\u2019s defense-in-depth.<\/p>\n

This event brings to light several interesting issues. For one, the group who found the bug is a \u201cself-confessed ethical hacker group\u201d called Hackersblog<\/a>. When they found the bug, they reported it on their blog instead of privately disclosing it to The Telegraph. This is because they feel that everyone (clients included) has the right to know about security vulnerabilities. It does bring up ethical issues, however \u2013 no work of code is be perfect, so it\u2019s highly likely that there are going to be security holes somewhere. Does Hackersblog have the right to reveal this information to the public? And is it even a good idea to have a group of \u201cethical\u201d hackers? (About<\/a> the group and statement on philosophy<\/a>)<\/p>\n

It is also important to realize how dangerous a leak like this is. Even though getting access to the emails and passwords for newspaper subscriptions does not seem like a very important issue, one must keep in mind that most users have the same password for everything. The article cites that 61% of people use the same password for a variety of websites, so a password leak anywhere can lead to disastrous problems.<\/p>\n

Obviously The Telegraph should fix these bugs, but it should also think about how to incorporate more secure practices into all parts of their system. Had they been designing their system with a security mindset all along, it is unlikely such an attack would be possible.<\/p>\n","protected":false},"excerpt":{"rendered":"

The Telegraph, a famous daily newspaper in the UK, was hacked into by a Romanian hacking group last week. The group exposed a weakness in the way the website queried its database for property searches and was able to obtain … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":94,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,7,9],"tags":[],"class_list":["post-1162","post","type-post","status-publish","format-standard","hentry","category-current-events","category-ethics","category-privacy"],"_links":{"self":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/1162","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/users\/94"}],"replies":[{"embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/comments?post=1162"}],"version-history":[{"count":6,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/1162\/revisions"}],"predecessor-version":[{"id":1168,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/1162\/revisions\/1168"}],"wp:attachment":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/media?parent=1162"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/categories?post=1162"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/tags?post=1162"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}