backtop


Print 20 comment(s) - last by W00dmann.. on Aug 29 at 3:48 PM


Uh oh, Nokia has been hacked...
The extent of the damage appears limited

Nokia Oyj. (HEL:NOK1V), currently in the midst of trying to push out Windows Phone 7 product, suffered an embarrassment when its developers website, developers.nokia.com, lost customers' personal information.

The extent of the damage appears limited, according to Nokia.  For most customers, only their email address was lost (so watch out for phishing
!).  For an estimated 7 percent of customers "either birth dates, homepage URL or usernames for AIM, ICQ, MSN, Skype or Yahoo" were also lost. More sensitive information, however, like passwords and usernames, was not in the affected database and remains safe.

Nokia writes:

You may have seen reports or received an email from us regarding a recent security breach on this developer.nokia.com/community discussion forum.

During our ongoing investigation of the incident we have discovered that a database table containing developer forum members' email addresses has been accessed, by exploiting a vulnerability in the bulletin board software that allowed an SQL Injection attack. Initially we believed that only a small number of these forum member records had been accessed, but further investigation has identified that the number is significantly larger.

The database table records includes members’ email addresses and, for fewer than 7% who chose to include them in their public profile, either birth dates, homepage URL or usernames for AIM, ICQ, MSN, Skype or Yahoo. However, they do not contain sensitive information such as passwords or credit card details and so we do not believe the security of forum members’ accounts is at risk. Other Nokia accounts are not affected.

We are not aware of any misuse of the accessed data, but we are communicating with affected forum members, though we believe the only potential impact to them may be unsolicited email. Nokia apologizes for this incident.

Though the initial vulnerability was addressed immediately, we have now taken the developer community website offline as a precautionary measure, while we conduct further investigations and security assessments. We hope to get the site back online as soon as possible and will post developments here in the meantime.

If you have any questions on this, please contact Nokia.developer-discussions-support@nokia.com.

The Nokia Developer website team.

Nokia is hardly the first major online entity to be hacked by SQL injection, and is unlikely to be the last.  SQL injection (affectionately nicknamed a "Little Bobby Tables" attack by web-comicXKCD), relies on sending malformed queries to a publicly available SQL database hence "injecting" unauthorized commands.  To succeed the attacker must gain physical access to the database (the ability to query it) and the database engine must lack more advanced code to handle malformed queries.  

SQL injection attacks are very preventable -- either by denying public access and/or by properly coding your database.  However, recent years have seen countless SQL injection attacks.  In 2009 Kapersky and the Australian federal police were both hacked via SQL injection.  In 2010The Pirate Bay was hacked via SQL injection.  This year hackers employed the method to penetrate several databases [1][2][3] of Japanese electronics giant Sony Corp. (TYO:6758
).

Thus far Anonymous and other familiar "hacktivists" have not claimed responsibility for the attack.  It is unknown why the hacker(s) responsible targeted the Finnish phone maker.



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

Injection without commitment?
By EricMartello on 8/29/2011 9:00:14 AM , Rating: 3
SQL tables are dirty little sluts who love being injected. When is the corporate world going to wake up to this fact?




RE: Injection without commitment?
By Ristogod on 8/29/2011 9:09:14 AM , Rating: 2
It's so easy stupid to prevent them too. It's hard to believe there are still entities out there without the intestinal fortitude to proactively spend the effort in safe-guarding themselves.


RE: Injection without commitment?
By Flunk on 8/29/2011 10:17:35 AM , Rating: 2
It's all about cost vs just leaving it alone. Many software companies never do any security testing at all.


RE: Injection without commitment?
By drycrust3 on 8/29/2011 1:39:24 PM , Rating: 2
quote:
It's all about cost vs just leaving it alone.

Well, the cost is that Nokia not only have to pay to fix it, but that they look even more stupid now than they did before.
Of course, one approach is that they just shut that site down as it was a developer site, and since Nokia seems to have gone out of development for the foreseeable future, then that is probably the cheapest option. They only need developers if Microsoft don't cough up with the promised OS in 2013 (or was that 2020?). By then they will be 4 years, millions of Christmas presents, several patent squabbles, half a dozen Android versions, and a whole raft of hardware improvements behind their competitors; as well as being a brand name synonymous with the being "just a phone".
The fact that this might actually get a mention on the minutes for the board of directors isn't important, what is important is whether they accept more excuses from their impartial Microsoft shareholding expert as to why it is good for Nokia to be getting further and further behind in a changing technology market. I don't understand how their shareholders are even happy with not having several decent android smartphones and at least one tablet in the stores in time for Christmas.
If I was a shareholder then the hacking of that site would just about be the last straw.


RE: Injection without commitment?
By Mitch101 on 8/29/2011 10:31:06 AM , Rating: 2
As a developer there is a lot of misinformation and lack of education on securing data as I say its one line of code to input the data 14 lines of code to validate it and cleanse it even then Im still learning to make it better.

Every training course teaches you how to input data but nowhere is training on how to cleanse and secure data.

Early in development you will find single quote and double quotes are your first enemy the training class didn't teach you. All training classes Ive seen show you the most basic of login and password creation its up to you to learn to encrypt the password then you learn to salt the information. I cant tell you how many people think PHP magic quotes is for preventing sql injection and its being retired.

I tend to buy and download other peoples code to see what they do but ultimately I find their code ignores a lot of potential security issues right back to step on single quotes. Id love to have a course from security experts on how they sanitize and secure data I think it would be a huge seller.


RE: Injection without commitment?
By Etsp on 8/29/2011 11:06:30 AM , Rating: 2
You're going to have to be more specific when providing advice.
quote:
Early in development you will find single quote and double quotes are your first enemy the training class didn't teach you.
Are you referring to PHP? Yes, how single-quotes and double-quotes are handled is a subtlety that most newbies wouldn't immediately understand. However, what does that have to do with SQL injection? Any security conscious design will rarely build queries as strings with "escaped" user input. They would use parametrized queries. The only exception to this being that the database platform does not support parametrized queries.

The string storing the SQL query to be used would contain placeholders instead of user input, and the function to execute the query would take an array parameter of user-input values. This places burden of sanitizing the user-input on the developers of the database drivers, rather than on the individual application developers.


RE: Injection without commitment?
By lightfoot on 8/29/2011 11:57:21 AM , Rating: 2
quote:
This places burden of sanitizing the user-input on the developers of the database drivers, rather than on the individual application developers

Epic fail.

Input should ALWAYS be validated by the individual application. Assuming that someone else is doing it for you is how you get into these situations.

Always validate your input.


RE: Injection without commitment?
By inf-rno on 8/29/2011 12:49:37 PM , Rating: 2
EPIC FAIL by both you noobs.

Parametric queries do not escape user input. It byte streams the input directly to the server. So if you input ')"-- then that's literally what will be inserted to the table. No escaping. Half baked knowledge is bliss.. until you get injected.

You should Input validate if you want proper data in the database and not garbage like ')"--.


RE: Injection without commitment?
By Mitch101 on 8/29/2011 1:19:19 PM , Rating: 2
I was thinking single quote semicolon personally and possibly prefixing with a escape slash if necessary but that proves more than one methodology can be applied to get the job done.

This thread is starting to prove my point on security. Im sure in 20 minutes we would get another developer calling all the previous ones newbs again.

None of us can cover all the levels/possibilities necessary in a brief post I think were all generalizing to keep it under a book and its why SQL injection is so popular its obvious a lack of education exists even then there will be mistakes that happen to err is human.

Im begging for a group of experts to come together and develop some training on this and then it needs to be scrutinized again and again. Im mainly PHP but the same exists in ASP as well.


RE: Injection without commitment?
By inf-rno on 8/29/2011 1:46:34 PM , Rating: 2
Seems like you didn't understand... Your point of how you cannot cover all possibilities while 'escaping' is the reason why Parametrization is the only solution.

BECAUSE you do not escape input. You stream each character literally into the fields.


RE: Injection without commitment?
By Mitch101 on 8/29/2011 2:04:29 PM , Rating: 2
Your right where would you recommend I can learn more or where did you learn?


RE: Injection without commitment?
By Etsp on 8/29/2011 3:34:58 PM , Rating: 2
I was referring to security. How exactly is having the character string ')"-- in a database column a security risk? Unless you're using dynamic SQL somewhere else that pulls from that field. Which is another poor security practice.


RE: Injection without commitment?
By lightfoot on 8/29/2011 12:10:26 PM , Rating: 2
The problem with input validation is that it needs to be done differently for each type of input.

Phone numbers, names, social security numbers, passwords, dates, addresses, etc all have different formats and different allowable lengths and characters. Each would need its own validation algorithm.

The key is to figure out which characters to allow, not which ones to disallow.

Also, keep in mind that the input must be validated on the server side - any client side validation can be bypassed.


RE: Injection without commitment?
By Mitch101 on 8/29/2011 12:38:08 PM , Rating: 2
quote:
The key is to figure out which characters to allow, not which ones to disallow.
Very well said something that is not taught in any class I have seen so far.
quote:
Also, keep in mind that the input must be validated on the server side - any client side validation can be bypassed.
Always ugg the number of people Ive seen who only validate through script on the client side amazes me.

The programming field is severely missing a class that is well now you know how to program. Now lets teach you data validation and security techniques for programmers. I would sign up in an instant there is always something more to learn and make it mandatory they pass an exam. Then you would need updates to the course on the latest techniques being used.


RE: Injection without commitment?
By drycrust3 on 8/29/2011 2:01:45 PM , Rating: 2
quote:
Every training course teaches you how to input data but nowhere is training on how to cleanse and secure data.

And do you ask the teacher how? Sure, I can understand not knowing to ask on the first course, but after lots of them?


RE: Injection without commitment?
By Mitch101 on 8/29/2011 2:19:48 PM , Rating: 2
Online training/CBT. I wish I could but there are a lot of self proclaimed experts who believe they are secure but probably have never dealt with anything beyond a botnet.

I think the best people are the one willing to admit they are always looking at the logs and seeing what is being tried and analyzing the methods used against their code to where they have it down to a method. Its how I determine if I have a possible flaw and Ive come up with some creative methods to prevent some of the attacks Ive seen. But I don't dare believe it cant be done because that's how you fail.

I believe there are many people who would enjoy sitting down with the people from Facebook, Microsoft, Google and finding out how they survive and even what they discover when someone succeeds.


Confusing
By BugblatterIII on 8/29/2011 12:39:38 PM , Rating: 3
quote:
To succeed the attacker must gain physical access to the database (the ability to query it) and the database engine must lack more advanced code to handle malformed queries.


Bit woolly there. It's generally done through a website, almost all of which need access to their database, be it direct or indirect.

If a developer queries the database in an insecure way that's when they're vulnerable to SQL injection.

Say for example the developer builds his query string like so:

string sql = "Select * from Customers where Name = '" + txtCustomerName.Text + "'";

Someone could type something like 'GO *Do bad things* GO' in that txtCustomerName textbox and the stuff between the 'GO' commands would get executed, with the same permission level as the website has.

Even worse is if the developer displays the results of the query blindly; very easy way to extract pretty much any data you like that way.

Using .Net the best way to avoid the vulnerability is firstly to not give the websites any table-level permissions at all (only allow it to execute the specific Stored Procedures it needs) and secondly ensure that you only ever use parameterised queries, i.e. never build up a SQL string and execute it. Ideally this would be enforced by having a Data Access Layer that only allows the execution of Stored Procedures and also only allows parameterised calls.

If you do that then you're protected; ADO.NET automatically protects against SQL injection for parameterised queries.

Of course there are dozens of other ways in, but they mostly require a little more skill and are generally less intensely embarrassing to be compromised by.

The more developers that know how to protect against these things the better. If someone has more information than I've given here I'll be interested to increase my knowledge.




RE: Confusing
By W00dmann on 8/29/2011 3:48:52 PM , Rating: 2
Thanks for this post BugblatterIII; as someone who is not in any way a software developer, it helped me better understand the underlying issue.

PS. - if you are Bugblatter the 3rd, is this to say your father's first name was also Bugblatter, in addition to your grandfather?


I got their email
By ertomas on 8/29/2011 9:11:11 AM , Rating: 2
Saying that my email address was among the retrieved info...

I had no sensitive info on their site I think so I'll have to rely on my spam filter!




Hmm.
By NellyFromMA on 8/29/2011 10:51:46 AM , Rating: 2
I think for the most part, this happens because corporations don't want to invest in legact updates to software which has probably seen a lot of bolt-on / iteration-based 'revisions' over the last 5 - 10 years or so.
The knowledge of the 'average' PC user as well as the multitude of users in general in addition to the lower-age entry level at which people start becoming interested and perhaps savvy with technology has pros and cons.
Leaders / management at corporations probably hadn't been presented compelling enough arguements about fixing these 'it still works' technologies because

A) In a 'I didn't do it' corporate world, no one wants to be held accountable, so the developers probably aren't interested in highlighting security flaws of sensitive data to those who aren't privvy to the issue

and

B) If the developer was sensible and thought of this, it may be an exceptionally difficult conversation conveying ROI, or really, loss minimization in this situation, to your boss or manager, especially when you start talking about company reputation and how something you worked on may have put it at risk.

Sensible and/or knowledgable management, if you are lucky enough to have that directly over you, is key in those situations.

It's easy for people here to comment about how this is 'another example of lazy devs' but honestly, 5 years ago, SQL Injection wasn't even terminalogy you could easily explain to anyone outside of the development world without getting into an entire dissertation and immediately lose who you're speaking to in technical jargon.

In a way, you can thank these companies for highlighting these issues at their expense (as well as the end-users unfortunately) so now, SQL Injection is a little more known as a term in itself.

So, thanks lulz and the like? Idk about all that crap, but I guess every cloud has some sort of silver-lining. And yes, I know no one is being blamed / taking credit for this attack. I just mean in general.




"Well, there may be a reason why they call them 'Mac' trucks! Windows machines will not be trucks." -- Microsoft CEO Steve Ballmer














botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki