June | 2012 | ZionOps

Archive for June, 2012

An Update on LinkedIn Member Passwords Compromised

The following update has been posted on the LinkedIn blog:

We want to provide you with an update on this morning’s reports of stolen passwords. We can confirm that some of the passwords that were compromised correspond to LinkedIn accounts. We are continuing to investigate this situation and here is what we are pursuing as far as next steps for the compromised accounts:

Members that have accounts associated with the compromised passwords will notice that their LinkedIn account password is no longer valid.
These members will also receive an email from LinkedIn with instructions on how to reset their passwords. There will not be any links in this email. Once you follow this step and request password assistance, then you will receive an email from LinkedIn with a password reset link.
These affected members will receive a second email from our Customer Support team providing a bit more context on this situation and why they are being asked to change their passwords.

It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases.

We sincerely apologize for the inconvenience this has caused our members. We take the security of our members very seriously. If you haven’t read it already it is worth checking out my earlier blog post today about updating your password and other account security best practices.

2012: 06/07
CATEGORY: Internet Privacy
Leave a comment

you-r!-k@n reboots the middle-east cyberwar?

This was posted yesterday on hackmageddon.com:

After several months of silence, a new resounding dump in Middle East.

I have just received an email message from you-r!-k@n, one of the early pro-Israeli contenders of the Middle East Cyber War, advising me of a new huge dump against an Iranian Server (irimo.ir, Iranian Meteorological Organization), which is currently unavailable. He claims to have acquired administrator privileges for the domain (1500 computers and server, 400 users), and has posted some screenshot as evidence, and the list of 400 Active Directory Users.

Of course I have decided not to publish the list except a small sample (which appears to come from a Windows 2000 Server), but cannot help but notice that, after a couple of months of silence, this is the first new event that closely resembles the resounding dumps which characterized the very first stage of the Middle East Cyber War.

Will this be an isolated episode or a brand new precursor of a new wave of attacks in the Middle East?

Update: Irimo.ir is currently unavailable, however, I was given a screenshot of the site before it was taken down. Looking at the messages left on the devastated site (which announced the erase of the Active Directory), it is interesting to notice that the reference to the Nuclerar as to reaffirm that the standoff between Israel and Iran about the Nuclear Strategy of Tehran, is influencing also the Cyber Space.

2012: 06/07
CATEGORY: #ZionOps
Leave a comment

Linkedin Massive Data Breach – 6.5M accounts leaked

Though “unsalted hash” sounds more like a menu item for the sodium-conscious, it’s actually a reason to change your LinkedIn password.

Linkedin may help around five or six people a year get a new job, but mostly it’s a breeding ground for slimy recruiters and pointless networking groups. Well now it’s become even more irritating as an estimated 6.5 million of our passwords have been leaked online, according to The Independent.

The news comes in the wake of security concerns surrounding LinkedIn’s mobile application calendar feature. A report began circulating in which LinkedIn was violating its own user privacy policy by sending detailed calendar entries to its servers. The company said on Wednesday that it was in the process of updating the app, after researchers noticed a flaw in the way the app shared potentially sensitive “meeting notes” data.

Reports are suggesting that a Russian hacker published a list of the passwords online and LinkedIn_logo is reportedly “crowd-sourcing help in breaking the encryption.” Linkedin has responded to the allegations with a number of tweets stating that the breach hasn’t been confirmed, but the team’s looking into the problems right away.

There is a possibility that this could be a hoax, but several people have said on Twitter that they found their real LinkedIn passwords as hashes on the list. Many of the hashes include “linkedin,” which seems to add credence to the claims.

Graham Cluley, a consultant with U.K. web security company Sophos, said in a blog post that investigations by Sophos researchers have confirmed that the file does contain, in part, LinkedIn passwords. It’s worth noting that the passwords are stored as unsalted SHA-1 hashes. SHA-1 is a secure algorithm, but is not foolproof. LinkedIn could have made the passwords more secure by ‘salting’ the hashes, which involves merging the hashed password with another combination and then hashing for a second time. Even so, unless your password is a dictionary word, or very simple, it will take some time to crack.

According to ZDNet, Finnish security firm CERT-FI is warning that the hackers may have access to user email addresses, too, “though they appear encrypted and unreadable.”

Robert Graham has posted a web form that converts your password to an SHA-1 password for lookup and provides a link to the file of LinkedIn passwords that were dumped on the Internet so you can download and see if yours is in there.

I’ve also written a Python script that does the same, but you need the password file to be in the same folder. You can get it from here.

If you haven’t already, you should change your LinkedIn password and email login, certainly before you use this tool.

RT @_logik I don’t think I’ll change my LinkedIn password.If somebody’s hacked into it, please work on my resume. I’m too lazy to update it.

— lavanya (@lavsmohan) June 6, 2012

There are a few lessons from this:

Never ask users to have their email ID as a user ID. This would lead to a user email getting known and the user becoming a victim of spam later on.
A single password for multiple sites and and email ID as the User ID is a disaster for those who have the same password everywhere.
Do not put up too much personal information on social networking sites. The problem here is, taking social network sites too seriously could lead to issues in case of hacks like these.

And it is true…. only the paranoid survive.

2012: 06/06
CATEGORY: Internet Privacy
Leave a comment

Facebook replaces Chrome with Opera

Last week, Google Chrome users were shocked to find that Facebook appears to have dropped support for their browser, recommending Opera instead as one of the three supported web browsers, fueling further speculation of a takeover by Facebook of the popular web browser. It appears Facebook has since regretted this premature update, as their support page once again shows all four major browsers (IE, Safari, Firefox and Chrome).

*Update: As of yesterday, Facebook has been loading excruciatingly slow on Chrome, leading some to believe that Facebook may be deliberately throttling browsing speed for Chrome.

The Browser War

It is a known fact that historically, Google and Facebook have always been at each other’s throats, although the truth is, the hatred seems to be more on Facebook’s part, as Google never seemed to feel too threatened by the new kid on the block. Remember the whole "Facebook can import Google contacts", but not the reverse saga? The only exception might be Chrome’s direct integration with Google services, rather than Facebook, but in my opinion, that sort of favoritism is expected.

And here’s something interesting to close off on:

It appears that many large companies are sabotaging Opera’s user experience by blocking or serving Opera broken or outdated code. You can see for yourself by spoofing the user agent header. Compare the code that you receive from Google’s servers. If the user agent contains Opera, there are large parts of code missing or are outdated. You can clearly see that by doing server-side browser sniffing, Google is serving different content for Opera than for the other major browsers.

I can’t say for the many browsers out there, but this happens a lot to Opera. For example, big companies like Amazon and Microsoft also do the same thing and serve Opera different code. Amazon serves Opera missing code that prevents many of the Amazon features like Amazon Cloud, Amazon TV, appstore, etc., from working. The workaround for server-side browser sniffing is to spoof as a different browser so that servers can’t detect Opera from the user agent header. Sadly, spoofing as Firefox is what Opera had to do to bypass Amazon’s server-side browser sniffing.

Historically, Microsoft’s MSN.com sent Opera broken CSS / webpages. You can look at Opera’s response by searching for "opera bork bork bork".

P.S. Here’s my two cents on the browser war: I hate that Chrome “pretends” to be responsive when one of its pages are stuck. Many features on some of my favorite sites don’t work with Chrome, forcing me to switch to Firefox to regain that functionality. However, I’m sticking with Chrome because it performs great overall, and besides, I love Google. Point made.