Image via CrunchBase

On 12th July 2012, more than 400,000 emails and passwords for Yahoo! Voices were stolen via an SQL injection and published online. The passwords were reportedly stored in plaintext, making this security breach even more serious. If you are a member of Yahoo! Voices, change your password immediately, and if you use the same password on other sites, make sure to change them as well.

I performed the following password analysis with the help of pipal, a very popular and powerful password analyzing tool. The full pipal report is located here, with a longer report (showing the top 100 of each category) here.

10 Most Popular Passwords

123456 = 1667 (0.38%)
password = 780 (0.18%)
welcome = 437 (0.1%)
ninja = 333 (0.08%)
abc123 = 250 (0.06%)
123456789 = 222 (0.05%)
12345678 = 208 (0.05%)
sunshine = 205 (0.05%)
princess = 202 (0.05%)
qwerty = 172 (0.04%)

Despite numerous warnings by security professionals, the most popular password is still “123456″, followed by “password” in second place. These are highly insecure passwords, not just because of their length or complexity (which is very low), but because they are at the top of most password lists that attackers use to try to compromise an account. Remember, brute-forcing a password is always a last-ditch attempt at gaining access to an account; a clever attacker will always try common passwords first, and if your password appears in a password list online, you should never use it!

The fact that these passwords were even allowed reveals substandard practices in Yahoo’s password policy. To boost security, a user should be required to have a password that contains both upper and lowercase letters, as well as numbers and symbols. For additional security, the chosen password should be rejected if it matches one found in common password lists.

Password Length

8 = 119214 (26.92%)
6 = 79650 (17.99%)
9 = 66058 (14.92%)
7 = 65654 (14.83%)
10 = 54815 (12.38%)
12 = 21785 (4.92%)
11 = 21261 (4.8%)
5 = 5325 (1.2%)
4 = 2748 (0.62%)
13 = 2585 (0.58%)
14 = 1433 (0.32%)
15 = 773 (0.17%)
16 = 442 (0.1%)
3 = 303 (0.07%)
17 = 252 (0.06%)
20 = 169 (0.04%)
18 = 116 (0.03%)
1 = 116 (0.03%)
19 = 78 (0.02%)
2 = 67 (0.02%)
21 = 6 (0.0%)
22 = 4 (0.0%)
29 = 3 (0.0%)
30 = 2 (0.0%)
24 = 2 (0.0%)
28 = 2 (0.0%)

As you can see, most people are still using short passwords. Indeed, a whopping 61.66% of people are using a password that is 8 characters or shorter. If you include passwords with a length of 9 or 10, then the number jumps to 88.96%. When a dictionary attack fails, the main thing stopping a brute-force from succeeding in a specific amount of time is the length of the password. For each additional character a password has, the amount of time needed to brute-force it increases by a factor of 95 (assuming the brute-force is trying all types of character). Even if the password only contains lowercase letters, an additional letter will increase the time required by a factor of 26.

8 characters and longer is usually cited as the recommendation for password length, but with cracking speeds up due to improvements in processing power, that number should probably be closer to 12, if not more. Remember, a long complex password need not be hard to remember.

Complexity

Only lowercase alpha = 146512 (33.09%)

This small statistic shows a staggering lack of password complexity. Almost a third of passwords only contained lowercase letters, making the task of brute-forcing them much easier.

loweralphanum: 224085 (50.6%)
loweralpha: 146512 (33.09%)
numeric: 26080 (5.89%)
mixedalphanum: 23233 (5.25%)
loweralphaspecialnum: 6053 (1.37%)
mixedalpha: 5122 (1.16%)
upperalphanum: 3416 (0.77%)
mixedalphaspecialnum: 3327 (0.75%)
loweralphaspecial: 2103 (0.47%)
upperalpha: 1776 (0.4%)
mixedalphaspecial: 489 (0.11%)
upperalphaspecialnum: 233 (0.05%)
specialnum: 189 (0.04%)
upperalphaspecial: 51 (0.01%)
special: 20 (0.0%)

As these additional statistics show, more than half the passwords only contained lowercase letters and numbers (the numbers only increase the brute-forcing attack by a factor of 10). Barely one percent of the passwords could be considered “complex”, containing upper and lowercase letters, numbers, and symbols.

Conclusions

Yahoo! is of course to blame for the passwords being accessible to hackers, as well as storing them in such an insecure way. Their password policy which apparently lets users choose single characters for a password is absurd, and a full investigation should be carried out to find out how on earth the users were left this vulnerable. There were some decent passwords in the list, and those were made completely useless through Yahoo’s ineptitude.

That said, it should be noted that regardless of Yahoo’s ineffective defences and security policies, a great deal of these user chosen passwords were highly insecure. It is up to the user to choose a decent password, rather than relying on a system which you should not really trust (as users, we do not know what security weaknesses a system has, or how it stores important data). It is best, therefore, to create a unique complex password (or passphrase) for each account you have online, and to use a good password manager to help you keep track of them.

Various organisations have revealed the existence of yet another piece of malware used for targeted attacks against a country’s infrastructure. Flame (also known as Flamer and sKyWIper), was discovered jointly by Kaspersky Lab, Iran’s MAHER Center, and CrySyS Lab of the Budapest University of Technology and Economics.

The most visible difference between Flame and earlier pieces of targeted malware like Stuxnet and Duqu is the size, expanding to 20 megabytes when fully installed (Stuxnet was only half a megabyte). CrySyS Lab, which discovered Duqu in 2011, have described Flame as “arguably… the most complex malware ever found.”

More information on Flame can be found below:

Identification of a New Targeted Cyber-Attack - Iran National CERT (MAHER)

The Flame: Questions and Answers – Kaspersky Lab

sKyWIper: A complex malware for targeted attacks [PDF] – CrySyS Lab

Meet ‘Flame’, The Massive Spy Malware Infiltrating Iranian Computers – Threat Level (Wired)

Flame malware – more details of targeted cyber attack in Middle East – Naked Security (Sophos)

Flame: Massive cyber-attack discovered, researchers say – BBC News

This hasn’t been a good week for Google Wallet, the mobile app that stores your credit cards so you can easily make payments with your phone. Yesterday, zvelo engineer Joshua Rubin revealed that the 4-digit PIN used to authenticate users of the app is stored as a SHA256 hash on the device, and this hash is easily obtained if the device is rooted. The problem here isn’t that SHA256 is insecure (on the contrary, it is a highly recommended hashing algorithm), but rather that there are only 10,000 possible values that the PIN could be (0000 to 9999 inclusive). This means that a brute-force attack is easily executed by simply SHA256 hashing each possible PIN and checking the resultant hash with the one stored on the device.

The following video shows the attack in action. The team who found the vulnerability simply created a separate app that reads the stored hash value and brute-forces it. It only takes the app a few seconds to crack the hash.

If you thought that was a bad design decision by Google, you haven’t seen anything yet. As it turns out, there is no need to root the device or crack the hash, as all an attacker needs to do is ask the phone to reset the Google Wallet application data. This wipes the PIN from storage, but not any card details, so when the Google Wallet app is next opened it asks you for a new PIN and lets you use the stored card details immediately:

Any online poll that doesn’t require some form of registration is going to run into big problems when trying to limit users to one vote each. The standard procedure of many online polls is to assume that each IP address constitutes one person, and thus the poll is limited to one vote per IP address. Whilst this assumption is of course flawed in both aspects (one IP address can be assigned to multiple people, and one person may have access to multiple IP addresses), it is a good one to have when trying to limit the amount of “voter fraud” in anonymous online polls. However, relying on this assumption alone as a preventative measure is not even close to good enough.

Other methods for limiting people to one vote each usually rely on the ignorance of most internet users in terms of how browsers work. For instance, a relatively common method I have seen is to set a cookie when the user votes, and then to check the status of that cookie whenever they make a subsequent vote. If the cookie is set, the vote is disallowed (though this action may not be communicated back to the user), and if the cookie is empty or non-existent, the vote goes into the system. Since cookies are stored on the user’s computer and not the poll server, they can be easily (in most cases) deleted by the user in question. In fact, many browsers have methods built-in to them to deny cookies from certain websites¹, and some have extensions that can easily be used to perform repetitive votes in an online poll.²

If preventing as many instances of voter fraud as possible is your aim, then using methods that depend on client-side procedures is a big mistake. Limiting the poll to one vote per IP address is the best way to go if you don’t want to code a registration system, but the additional security measures should not be overlooked.

About.com is a large information & advice sourcing site owned by The New York Times Company.³

About.com’s content is provided by a large group of writers, who each write for a specific topic, ranging from African History to Yoga. According to Alexa⁴, About.com is ranked as the 64th most visited website on the internet, so you would expect their design team would know a few things about how the internet works. Sadly, when it comes to anonymous online polls, this is not the case.

Every year, About.com run a “Readers’ Choice Awards” competition, where their readers vote in various polls for each topic. The medium for most polls used appears to be a custom-made form, the processing of which is done on an About.com server. The poll I chose to do my analysis on was the “Best Web Design Overall” poll at the About.com Web Design / HTML topic. I thought it a good poll to choose given that at the time it had received relatively few actual votes, and the topic ties in nicely with the security of online polls.

Using Paros (a nifty proxy tool that allows you to view raw HTTP requests / responses), I captured the exact requests sent to the About.com server that were responsible for making a vote (my vote went to the site in last place, which at that point had only 3 votes).

GET http://webdesign.about.com/gi/pages/poll.htm?linkback=http%3A%2F%2Fwebdesign.about.com%2Fb%2F2011%2F02%2F11%2Fvote-for-the-about-com-readers-choice-awards.htm&poll_id=6765141284&poll=4 HTTP/1.1
Host: webdesign.about.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://webdesign.about.com/b/2011/02/11/vote-for-the-about-com-readers-choice-awards.htm
Cookie: TMog=B2FKLs2J20kA0972; zFD=B2IPB2F20B20R20B00R02; gs=webdesign; jsc=13; Mint=B2IMZK0U20SA18BF; zBT=0; pc=30; zRf=-2; zFS=B2IB0B20B10B00B01
 
GET http://guidepolls.about.com/webdesign/6765141284/results.js?linkback=http%3A%2F%2Fwebdesign.about.com%2Fb%2F2011%2F02%2F11%2Fvote-for-the-about-com-readers-choice-awards.htm&poll_id=6765141284&poll=4 HTTP/1.1
Host: guidepolls.about.com
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://webdesign.about.com/gi/pages/poll.htm?linkback=http%3A%2F%2Fwebdesign.about.com%2Fb%2F2011%2F02%2F11%2Fvote-for-the-about-com-readers-choice-awards.htm&poll_id=6765141284&poll=4
Cookie: TMog=B2FKLs2J20kA0972; zFD=B2IPB2F20B20R20B00R02; gs=webdesign; jsc=13; Mint=B2IMZK0U20SA18BF; zBT=0; pc=30; zRf=-2

For security reasons I have removed the User Agent information from the two HTTP requests above.

What is very interesting is that my vote was sent (in the first request) using a GET method rather than a POST method that is usually associated with forms. The resulting HTTP response including a call to a JavaScript file (second request), and it was this second request that seemed to do the actual vote. One thing I did notice is that the poll did not rely on Cookies, but instead seemed to record my IP address with my vote, and disallowed any subsequent votes from my connection. However, this limit of one vote per IP address was the only “security” feature in place on the poll.

Knowing that the poll used a GET request, and that I could not simply manipulate the poll by sending multiple requests from the same IP address, I set up a fake HTML image tag in the footer of a website I run. The URL of the image would be the voting URL for my chosen poll option (i.e. the one in the second request above), and I added some custom CSS to the image that would hide it from view, so that no browser would show a missing image icon and draw attention to the code. The resultant code looked like this:

This type of exploit is known as a Cross-Site Request Forgery (CSRF/XSRF), and once embedded within the website footer, it was only a matter of time before site visitors would load the page and get their browser to (unknowingly) send a vote to the About.com server. The vote would be from their IP address, and would go completely unnoticed to most web users. Sure enough, after a few minutes, the poll results had gone from this:

Before

to this:

After

With the exploit working, and the site “Fido” in the lead, I removed the malicious code from my site. I refrained from posting this blog post until the official About.com voting period was over, and the results were announced (in the end, Google won).

What should be taken away from this? Well, don’t use GET requests to add votes to polls; POST requests are trickier to force upon users, and usually either involve them clicking submit on a form, or having some JavaScript doing the action in the background. Another thing this should alert web designers to is the importance of another level of security on top of their polls. It is great if you can code a poll that works, but it is even better to code a poll that works securely, especially if there are people out there who want to manipulate your votes for reasons other than trying to demonstrate possible exploits (like myself). In my opinion, I believe that a simple CAPTCHA verification (such as the popular reCAPTCHA) should solve most problems with online polls such as this. Yes, they can get annoying, but at the end of the day, they only take up a few extra seconds of your users’ time, and they are very difficult (though not impossible) to bypass.

Karsten Nohl and Sylvain Munaut from Security Research Labs have cracked GSM, enabling them to eavesdrop on any call made by a target device. The pair demonstrated their research at the Chaos Computer Club Congress (CCC), and have released a rough guide to the attack on their website.

What appears to be unique to this type of attack on GSM is that an attacker can specify an actual target device to eavesdrop on. Using a set of cheap Motorola phones with open-source firmware, the researchers were able to see all data being broadcast by the GSM base station. Once a target device is located, the relevant data can be unencrypted by finding the GSM encryption key using a set of rainbow tables. The set of tables used by the researchers was generated over a two month period in a previous research project, and is 2TB in size. An attacker only needs two encrypted known plaintext messages to have a 90% chance of finding the secret key.

In Nohl’s own words, “Now there’s a path from your telephone number to me finding you and listening to your calls, the whole way.”

Let’s just hope the GSM Association (GSMA) take on board the research, and pay special attention to the relative easiness and low cost of actually executing the attack. According to the BBC News write-up, the association have yet to comment on the attack.