Computer Security Articles

Dutch GPS and navigation software giant, Tom Tom, recently took what I consider to be a small privacy step for the company, but a giant privacy step for mankind.

Faced with evidence that the Dutch police have been using anonymised trip data from Tom Tom users to assist in enforcing speeding laws, Tom Tom CEO Harold Goddijn last week published an official comment on YouTube.

In the video, Goddijn said:

We learned today…that the police in the Netherlands are using [our] information to identify road stretches where people in general, and on average, are driving too fast. They use [our data] to put up speed cameras and speed traps. And we don’t like that, because our customers don’t like it. We will prevent that type of usage of our data in the future.

Tom Tom seems to be recognising some potential privacy-eroding issues which other companies don’t or haven’t concerned themselves with in the past. (Not all viewers of the YouTube video agree with me – there are currently 34 dislikes but only 26 likes.)

Even so-called anonymous data, collected in good faith, may end up being anything but.

Possibly the most infamous, and outrageous, anonymity gaffe in recent history was perpetrated by AOL nearly five years ago. The company published some 20 million search terms – supposedly for web research purposes – with usernames replaced with arbitrary numbers.

The problem was that each username was replaced with the same number every time it appeared. The result ought to have been foreseen.

As you accumulate more and more search terms tied to specific individuals, you can make ever-more accurate deductions about their identities from the search terms alone.

After all, over months of searching, you probably give away multiple hints about your identity. You might narrow down where you live by repeatedly searching for businesses in your neighbourhood. You might search for cohorts from your school or college. You might check garbage collection dates in your street. You might even do a vanity search for your own name or property, which, in the AOL data, would have been the privacy-erosion equivalent of “Bingo!”

Indeed, the New York Times famously traced Thelma Arnold, and her dog Dudley, right to her home in Georgia by reversing the AOL search data to remove her anonymity altogether.

Google, too, is no stranger to controversy over its definition of anonymise. Google is proud of the fact that it “anonymises” IP addresses in its search logs after nine months, even though this involves simply blanking out the bottom eight bits of your IP address.

This just about sneaks into the definition of anonymise given in my New Oxford American Dictionary, namely: to “remove identifying particulars from test results for statistical or other purposes”. But it might not meet your definition. You probably assume that an anonymised log entry can’t be connected with you at all.

Keeping the actual details of every search term – even ones which actually include your name, or your address, or some sort of personally identifiable information – isn’t really anonymous. Tying these searches together with an IP identifier which narrows you down to 1 in 256 people (at the very best – many /24 networks are only sparsely populated, after all), and which probably identifies your ISP, your suburb and your phone exchange, is even worse.

So, be careful out there. Anonymised data may not be as anonymous as you thought. And anonymised data which you share with a vendor – such as your average speed across the Sydney Harbour Bridge, where you’re supposed to keep below 70km/hr – might end up getting used for purposes you wouldn’t consider “anonymous”.

Unless you are absolutely certain what will be shared, and how, and for what purpose, I recommend that you turn such sharing features off. And if a product or service requires data sharing to work at all, don’t buy into it in the first place.

At the very least, before enabling any “share data with vendor” option, ask yourself, and the vendor, what’s in it for you – in other words, work out the best result you can ever expect from the sharing. Contrast that value with what’s in it for the vendor, or for the intelligence services and law enforcement authorities in that vendor’s jurisdiction.

Make sure there is an obvious positive balance in your favour.

If there isn’t, then the vendor simply isn’t paying you enough for your data. It really is a commercial transaction!

This message may repeat. This message may repeat. For those of us old enough to have fond memories of the phonograph, the phrase “broken record” may come to mind.

Yes, more user information has been leaked and in a totally preventable fashion. A season ticket sales representative for the New York Yankees accidentally emailed a spreadsheet to “several hundred” affiliates with the personal details of over 21,000 Yankees ticket holders.

According to the Yankees, the spreadsheet contained customers’ names, addresses, phone numbers, fax numbers, e-mail addresses and other information like their seat numbers and which ticket packages they purchased.

Implementing data loss prevention (DLP) for sensitive customer data is easy to do. There are at least three ways this could have been prevented…

1. Encrypt the spreadsheet to prevent accidental disclosure
2. Implement endpoint DLP software to watch for the transfer of sensitive data to instant message, email and other communication tools
3. Scan outgoing email messages for personally identifiable information to prevent accidental disclosure.

Later this afternoon DSLReports.com disclosed that they had been the victims of a SQL injection attack that succeeded in stealing usernames and passwords. Justin, the owner of DSLReports, wrote in a forum message that a “sql injection attack by a botnet on wednesday afternoon obtained a large number of email / password pairs.”

Strangely, Justin stated that he had notified account holders who either created their accounts in the last 12 months, or had logged in over the last 12 months. This seems like a terrible practice. Many users have had accounts for more than 10 years and may not even remember having created one.

To not notify everyone who may have been affected seems to be a lapse in judgement, but it gets worse. All of the passwords in DSLReports’ database were in clear text. No hashing, no salting, totally unencrypted.

Once again we find that if we re-use passwords for seemingly unimportant websites, we may be putting our reputations at risk. You can count on the attackers trying to use these email addresses and passwords on as many popular sites as possible.

They may only use them to spread forum spam, but do you really want your name/profile/identity associated with this kind of activity?

Creative Commons image of New York Yankees helmet courtesy of Mr. T in DC’s Flickr photostream.

In the absence of a genuine ticket to the real event, Facebook users are encouraging each other to reveal their Royal Wedding Guest name.

Here’s a typical message that is currently being spread by well-meaning users across the social network:

In honor of the big wedding on Friday, use your royal wedding guest name. Start with either Lord or Lady. Your first name is one of your grandparents’ names. Your surname is the name of your first pet, double-barreled with the name of the street you grew up on. Let’s do this! Post yours here. Then cut and paste it into your status.

Regally yours,
Lady Edith Spanky-Rushmoor

Do you see the problem?

By playing the game, you might be unwittingly making life easier for identity thieves and hackers.

Look at it this way. Think of all the websites which ask you to give it a “secret question” which can confirm your identity in the event of you forgetting your password.

If you tell everyone your Royal Wedding Guest name then you are giving away information which might help someone break into, say, your email account.

So, here’s my advice.

Firstly, don’t post this kind of personal information onto the internet – the few seconds worth of amusement you may get by telling people your Royal Wedding Guest name are not worth the potential pain of having your identity stolen.

Secondly, when websites ask you for a “secret answer” to reset your password… lie. You don’t need to tell the truth when you’re asked by a website what your mother’s maiden name was, or the name of your favourite TV show. So, say something random but memorable that no-one is likely to guess like “Xena Warrior Princess” or “Artichoke Sandwich”.

If you use Facebook and want to learn more about threats, you should join the Sophos Facebook page where we have a thriving community of over 70,000 people.

Of course, if you do happen to be one particular couple getting married tomorrow, you’re not going to have any chance keeping your grandparents’ names secret..

Hat-tip: Thanks to Naked Security reader Paul who brought this particular issue to our attention.

Two weeks ago, the Federal Bureau of Investigation (FBI) obtained a court order in Connecticut, USA. This court order allowed the FBI to undertake an anti-cybercrime operation of a sort which had never been authorised before in America.

Not only did the cops seize various US-based Command and Control (C&C) servers belonging the Coreflood botnet, but they also redirected all traffic intended for those servers to a surrogate server under their own control.

When infected PCs connected to the surrogate, the cops instructed the bot process to terminate, providing that the PC appeared to be in the US, and thus under their jurisdiction.

What made this court order a first in the US is that it gave law enforcement permission to interfere directly with computers belonging to users who weren’t being investigated, or charged with any crime.

The motivation for this novelty was that the Coreflood bot family is notorious for exfiltrating data from infected PCs. As the FBI’s Temporary Restraining Order puts it, Coreflood sets out:

to commit wire fraud and bank fraud in violation of Title 18, United States Code, Sections 1343 and 1344, and to engage in unauthorised interception of electronic communications in violation of Title 18, United States Code, Section 2511.

But the Electronic Frontier Foundation (EFF), a worldwide privacy advocacy group, expressed concerns about this sort of legally-endorsed interference. In particular, the EFF pointed out that there is something unappealing about sending commands of any sort to unknown malicious code on someone else’s computer without their explicit permission.

This may sound like a petty objection – and perhaps, in the real world, it is – but unless you know exactly which variant of the bot is on each PC, there is always a potential risk with trying to use a bot against itself. What if the crooks have deliberately rewired the “stop” command to carry out a “format hard drive” operation instead?

Nevertheless, the FBI went ahead, and the exercise seems to have been a success. So much so, in fact, that the cops went back to court over the weekend to ask for the two-week court order to be extended for a further month.

The new court application shows that the original two-week intervention had a measurable effect, documenting graphically the decrease in US-based PCs which tried to connect to the FBI’s surrogate C&C server:

The cops also compared the relative drop in Coreflood activity in the US and overseas. Sending “stop” commands to the infected PCs was noticeably more effective that simply cutting those PCs off from the C&C servers:

The big difference in the new court application is that the FBI is now asking to be allowed to uninstall Coreflood from infected PCs, not just to stop the bot process temporarily.

The FBI says it will only attempt this sort of automatic remote disinfection on “infected computers of identifiable victims who have provided written consent to do so.” This should keep the EFF happy, but it won’t be half as effective as blindly going ahead with automatic disinfection, without waiting for an exchange of written agreements.

Of course, even court-sanctioned auto-cleanup wouldn’t solve the real problem. Hundreds of thousands of users in the US (and many more than that overseas) have allowed themselves to get and to remain infected by malware which is comparatively easy to detect, remove and prevent.

As the FBI’s court application wryly notes in conclusion:

While the use of an “uninstall” command to remove Coreflood cannot be considered a replacement for the use of properly configured and updated anti-virus software, removing Coreflood from infected computers will at least serve to eliminate a known threat to that victim’s privacy and financial security.

These infected PCs actually pose a known threat not only to the victims, but also to the internet as a whole, and they advertise their infection by openly calling home to the C&C servers.

So, perhaps the FBI should have applied for permission to go at the problem in a much more gung-ho fashion, without the written permission clause?

What you you think?

I have been skimming the glut of news stories covering the PlayStation hack following Sony’s statement yesterday.

The issues that keeps coming back to me are these:

1. Sony, like any company who keeps customer account details, is responsible for keeping this sensitive data safe.

So the question is, How could these details, potentially including credit card details, of a whopping 70 million users not be encrypted? It baffles the mind.

Perhaps the data was indeed encrypted, but if it was, how come Sony haven’t stated this?

Let’s say I accidentally leave my front door ajar, leave the house for a few days, and return to find that I was robbed. People will say I am a bit of an dodo brain, but I will still get sympathy from friends and family and we will all blame the thief.

But, if I convince all my friends and family to trust me with their prized possessions, pile their valuables on my coffee table, and then leave the front door open, I doubt they will be very supportive when I meekly approach them saying, “whoopsie – someone took em. These things happen, right?”

So it is no wonder that so many people are annoyed. They have a right to be.

2. What the F*** happened at PSN?

Having read Sony’s statement, they thank their “valued” customers for patience/goodwill/understanding (annoying in itself since I doubt many feel patient, generous or understanding). They also tell you to be wary of scams, which is all well and good.

But they don’t tell us what happened.

I really REALLY want Sony to stand up and explain how the company screwed up, how the bad guys got into their system, why the data wasn’t properly stored: a clear and concise explanation and, where appropriate, a straight-up apology for their oversights/misplaced bets/mistakes/etc

(Shall we place a bet on whether an APT was responsible? – sorry, couldn’t help it…)

It won’t get your data back, but at least we’ll all have some idea of how this happened. And it might do wonders to repair the trust issues it is bound to face with its stakeholders. More importantly, it will help other companies learn from Sony’s mistakes.

True, it can take some time to sort through all the bits and bobs before you provide a detailed explanation. But Sony set a rather slooooooow pace by waiting a week between its first announcement and yesterday’s statement.

So what can you do?

Read advice on your next steps, including changing your passwords and credit cards, from fellow Naked Security writer Graham Cluley.

Affected users have also been invited to get in touch directly with Sony if you have any questions.

Why not ask for a public explanation and apology? Feel free to share the response with Naked Security.

Some time ago, a security researcher, Alex Levinson, found out the iPhone was keeping a SQLite database of the iPhone’s location (wifi-based location, cell-based or GPS) and a few other information.

The file, located in /private/var/root/Library/Caches/locationd/consolidated.db, is easily accessible on jailbroken phones (ssh or any file transfer tool) and readable by any SQLite3 tool.

This issue has recently re-surfaced as two researchers, Pete Warden and Alasdair Allan, wrote a MacOS tool to generate maps from the locations recorded in that database, and are presented this at Where 2.0 in San Francisco today.

If you don’t have a Mac, then there is an online tool here (in French) or you can use Firefox4 SQLiteManager plugin + Google Fusion to do the trick (which actually the solution I used for the maps below).

I would also encourage you read Mikko Hypponen’s post. It offers an interesting explanation as to why Apple designed such a database. In short, Hypponen’s idea is that it reduces the costs of renting an external location database.

The few things I would like to add to the story are:

• the consolidated.db is a ‘standard’ SQLite3 database, so you can query it like any SQLite database, there is no need for sophisticated tools (but they are cool). Data is directly usable:

  sqlite> .dump CellLocation
  PRAGMA foreign_keys=OFF;
  BEGIN TRANSACTION;
  CREATE TABLE CellLocation (MCC INTEGER, MNC INTEGER,
  LAC INTEGER, CI INTEGER, Timestamp FLOAT,
  Latitude FLOAT, Longitude FLOAT, HorizontalAccuracy FLOAT,
  Altitude FLOAT, VerticalAccuracy FLOAT, Speed FLOAT, Course FLOAT,
  Confidence INTEGER, PRIMARY KEY (MCC, MNC, LAC, CI));
  INSERT INTO "CellLocation" VALUES(208,10,49802,21036492,314034125.866114,
  43.60604608,7.06016272,1211.0,0.0,-1.0,-1.0,-1.0,70);
  ...

• The WifiLocation table tries to make up your location based on the wifi access points your iPhone sees, and for which Apple knows the location. If your iPhone sees a wifi access point known to be located by the Eiffel Tower, well, you probably are located close to the Eiffel Tower. This is done without using GPS.
• The CellLocation table does basically the same, but based on the GSM access points your phone sees.

  Now, in my case, I noticed neither table mentioned I had gone to Poland with the iPhone. Why ? Well, obviously, when you restore an old image of your phone, you overwrite the database By the way, the iPhone also made a poor estimation of my altitude and thinks I work at seal level (which is not the case).

• Comparing the cell location with the wifi location (see maps below) may release interesting information. First of all, it shows that Apple does successfully associate our workplace wifi with its physical location (I believe the several locations in Sophia Antipolis – where we are located – are just various approximations). It also shows that our lab iPhone (well, the backup I restored) only accessed wifi from our office , that we did a trip to Toulon, but that we did not use wifi there.
  

  CellLocation

  WifiLocation

• On a security point of view, it should be noted [thanks Guillaume for raising the point] that consolidated.db’s integrity is not guaranteed at all. It is easy to modify it to say I was in Greenland last month. Or I could hack into someone’s else iPhone and alter it so as to show that this person was on a crime scene when the crime happened. Thus, this should be handled carefully by forensics experts.
• The ‘untrackerd‘ application cleans the database regularly.
• Finally, you might have noted the iPhone stores the MCC (Mobile Country Code) and MNC (Mobile Network Code) of the SIM. It is interesting to note it did notice I sometimes use a fake SIM (208/30). This is when I use a local OpenBTS replication jail I will talk about at VB 2011 – patience In that case, it is unable to locate my position as it is not aware of this fake operator (as it is only valid within the walls of our lab)

  INSERT INTO "CellLocation" VALUES(208,30,1000,10,314034365.532726,
  0.0,0.0,-1.0,0.0,-1.0,-1.0,-1.0,0);

It has been observed that more and more children are using social networking websites. Kids even fake their age to join Facebook. Facebook is for high school and college students. Facebook is intended solely for users who are thirteen (13) years of age or older and the age limit is there for the purpose. Any registration by children under 13 is unlicensed and in violation of the terms of use.

Under age kids who join Facebook are not aware or old enough to understand the dangers involved when on Facebook. I have seen these kids engage themselves in online chat with people they neither know. These kids connect as well as send invites to connect with them to people whom they are not familiar with.

Our observation also reveals that most of the children using Facebook don’t use privacy settings. This makes them more vulnerable to stalkers and cyber bullying on the social networking sites. Most of the children do not configure their Facebook account properly and publicly display their profile including address and phone numbers. Facebook for kids is kind of whole new world but at the same time there are predators who are actively searching for next victim. I here by advise all the parents to take out some time and make sure your child’s Facebook account has right privacy settings and restrictions in place. One can follow below basic guidelines to start with:

- First of all do not allow kids under 13 to join Facebook at all. Try to explain and educate the kid that it is not safe for him/her to be on Facebook before age and he/she can do it when they are of appropriate age and you will be the one who will help in opening the account. Parents can be right judge to determine when they feel their children are mature and responsible enough to join social networking sites like Facebook.

- If your child is above 13 years of age and has opened Facebook account the first thing you should do is make sure he/she configures the right privacy settings. Configure the privacy settings of the child’s Facebook account to be accessible only to friends and not with everybody. Its important to understand the privacy settings provided by Facebook and teach your kids how to control their privacy.

- Connect yourself (and other seniors from family members) to kids account as a friend. So that you will keep on receiving all the posts that the child is putting to all his friends. In this way you will be aware of what’s going on the child’s Facebook account and can guide your child if he/she is posting messages/photos they should not be posting. Inappropriate pictures, messages can result in damage to a child’s reputation. It is good to teach your kids to think before they post. It is important for kids to understand that anything they create or post can be copied, altered and sent around.

- Restrict your child’s online time as many kids spend hours and hours on Facebook without them knowing how much time they have been online. Its good to restrict it before they become addicted to it.

- Teach your kid a very simple rule and if followed can avoid most of the problems on Facebook. If your kid wouldn’t want someone saying it to them, they should not say (post) it to anyone else. Also implies like if your kid would not say it to someone in person, they should not post it.

- Teach your kids to say no to strange request of becoming a friend on Facebook. As once you accept stranger among your friends any posts or communication you do on Facebook with your fiends is also going to be seen by the stranger.

- If your kid decides to meet a online friend whom he has not seen before, let them know that you too are interested to meet the friend and it is better and safe to see the online friend when you are there.

Try to make use of technology by installing and configuring parental control features that will help your child to visit only kids safe websites and also to restrict their time on the internet. Quick Heal Internet Security 2011 and Quick Heal Total Security 2011 has very good parental control features. For more information please visit http://www.quickheal.com/qh-total-security.asp