In Forbes, an article recently appeared, Anonymous is winning its war on Internet infrastructure. By contrast, our report on Anonymous put forward something a little more hopeful, highlighting a breach attempt that wasn’t successful using a web application firewall.

Down below in this blog you’ll find a partial list of Anonymous victims--some successful, some not.  It’s a long list. How many of these organizations have anti-virus, IPS and so-called Next Generations Firewalls (NGFW)?   Why are the attacks successful when these technologies claim to prevent them?  It is probably a safe bet to assume that many of the companies listed below had IPS, NGFW and anti-virus.  So why did these defenses fail?

First, anti-virus is completely useless.  As mentioned in our report, Anonymous mimics for-profit methods of hacking.  But there are some key exceptions, notably there was no reliance on malware as well as no phishing or spear phishing.  This means anti-virus is totally irrelevant.

Second, what about IPS and NGFW vendors who claim to protect applications?  Fundamentally, network-based technologies can’t be effective when it comes to protecting an application.  Don’t confuse “application aware” with actual application protection.  Application aware simply means "I know we are using Application X."  But it knows nothing about how the application works to put in place effective defense.  Here’s one (important) illustration:  how do you protect web applications that contain thousands of URLs each with dozens or hundreds of input parameters?  IPS may require an equal number of mitigation rules or policies when integrating with scanners, making their management very cumbersome if not impossible. Web applications firewalls (like ours) offer a simpler built-in protection of the entire application through the combined use of positive and negative security models. Through learning of application usage, WAFs know what characters are allowed and supported in every parameter and URL across the application. The impact:  A very high number of false negatives. 

Recently, some IPS/NGFW vendors claim that by integrating with vulnerability scanners (like Nikto), you’re left sitting pretty.  Not so.  Why?  By integrating the two technologies has several issues:

• You only protect vulnerabilities you know about which leaves out anything the scanner did not know about.
• You are not aware of attacks accumulating in parts of the application that were not found to be vulnerable.
• You are not protected against attacks published after the scan.
• You are not protecting resources introduced (or changed) after the scan.

Once again, you’re left holding a big basket of false negatives.

Partial List of Anonymous Targets

Amazon

AU Department of Communications

AU House of Parliament

Austria Federal Chancellor

Austria Ministry of Economy

Austria Ministry of Internal Affairs

Austria Ministry of Justice

Banco de Brazil

Bay Area Rapid Transit

BMI

Caixa

Catholic Diocese of Orlando

Church of Scientology

CIA

Citibank

Egyptian Government

Egyptian National Democratic Party

FBI

Fine Gael

French Presidential Site

Greek Department of Justice

HADOPI

HBGary Federal

Irish Department of Finance

Irish Department of Justice

Itau

Malaysian Government

Mastercard

Mexican Chamber of Deputies

Mexican Interior Ministry

Mexican Senate

MPAA

Muslim Brotherhood

New Zealand Parliament

Office of the AU Prime Minister

Orlando Chamber of Commerce

PayPal

Polish Government

Polish Internal Security Agency

Polish Ministry of Culture

Polish Ministry of Foreign Affairs

Polish Police

Polish President

Polish Prime Minister

RIAA

Rotary Club or Orlando

Slovenia NLB

SOHH

Sony

Spanish Police

Swiss bank PostFinance

Syrian Central Bank

Syrian Defense Ministry

Syrian Ministry of Presidential Affairs

Tunisia Government

UMG

US Copyright Office

US Department of Justice

US Senate

Various Pornography sites

Visa

Warner Brothers

Zimbabwe Government

Below you'll find a graphical summary describing the attack sequence used by Anonymous in the attack we recorded.  

The view the full report, please click on this link to download the PDF (no registration required).

Click image below to BIGGIFY:


Paul Cezanne:  Still Life with Skull (Nature morte au crane)

You have seen our report featured in the New York Times article which details the people, process and technology used in a failed Anonymous attack.  This is the first time we’re aware of someone chronicling, from cradle to grave, a full Anonymous attack.  The report can be downloaded here (registration not required).

This is a fairly technical overview of an attack.  In this case, the Anonymous approach is to steal data first and, if that fails, bring down a target website with a great flood of traffic.  We detail the tools—such as Acunetix, Nikto and Havij—that were used by fairly savvy hackers. 

We also detail the attack sequence which is summarized in the graphic below which we posted here.

Anonymous hacking operation fell into three distinctive phases:

1. Recruiting and communications phase (Day 1-18)—In this phase, Anonymous leverages social media to recruit members and promotes messages and campaigns.  In particular, they use Twitter, Facebook, and YouTube to suggest and justify an attack.  If a sufficient number of volunteers are persuaded to participate, the skilled hackers begin initial reconnaissance.
2. Reconnaissance and application attack phase (Day 19-22)—During this phase, the skilled hackers carefully hide their true identity and place of operation.  They probe applications in an effort to identify weaknesses that could lead to a data breach.
3. DDoS phase (Day 24-25)—If data breach attempts fail, the skilled hackers elicit help from the laypeople.  At this point, a large volume of individuals download attack software such as was done in Operation Payback or go to custom-built websites that perform DDoS attacks.

Disclaimer:  We are not certified sociologists, historians or psychologists.  For an interesting history and sociological analysis of Anonymous, read Gabriella Coleman’s essay here.

Forbes reports that YouPorn's was breached.  In all, 6,433 credentials (comprised of an email and password) were breached and posted online.  No word on the motivation behind the breach.

However, there are some possibilities:

• Free stuff?  They wanted access to free "content."  Reasonable possibility.
• Altruism?  On Valentine's Day, a hacker announced he had breached a porn site.  "The hacker said he was motivated by the desire to highlight a security vulnerability on the adult site, rather then anything overtly political. He did, however, claim allegiance to hacktivist collective Anonymous in an email exchange with AP."  Not likely.
• Mob war?  Could it be that there was a war of porn platforms or the closure of some sites? Probably the least likely and we have no evidence, but such theories are fun to think about.

On a different note, eyeballing the 6,433 credentials, its interesting to see that many users had to good sense to use emails that didn't give or indicate their actual names.  Certainly some did and are probably being ridiculed by co-workers as you read this.  Porn surfers, it seems, may be fairly sophisticated when it comes to protecting their identities.

A federal court reversed a conviction against a Goldman-Sachs developer who allegedly stole source code.

However, the court is not saying why. The reversal was without explanation; it said an opinion would follow “in due course.”  It looks like this is a case which was a precedence for the digital espionage law, demonstrating that the law itself requires updating:

A crucial issue in the appeal — and a main focus of Thursday’s oral argument — was whether Mr. Aleynikov’s actions constituted a crime under the statutory language of the Economic Espionage Act. The debate centered on whether Goldman’s high frequency trading system was a “product produced for interstate commerce” within the meaning of the law.

This reversal really shows how costly the insider threat is for businesses. Not only did Goldman lose proprietary code, but is now losing the case.  In addition to the fact that they can’t they be compensated for the code loss, Goldman now has deal with heavy legal expenses.

Apparently, legislators in DC are considering tax breaks for bolstering cyber security.

Does this make sense?  Probably not.

In the physical world, tax incentives help businesses compensate for investment deficiencies.  For example, a business may hire extra employees in response to a tax break.  The result, hopefully, is a decline in unemployment.  Theoretically, business lowers its costs, government reaps higher revenue from lower unemployment and society doesn’t need to deal with the social strain posed by people not having jobs.

The issue with cyber security tax breaks is this:  if enterprises make the wrong investments and a breach occurs, business, government and society all fail to benefit.  Today, businesses spend billions of cyber security and breaches continue to occur daily.  Companies already spend a lot on security—but are they spending on the right things?  With a tax break, the only differences is that tax payers will indirectly foot the bill.

How could a tax break could make sense?  If legislators mirrored a prescriptive approach, such as what PCI pushes, then we could expect to see cyber security spending go in the right direction and witness a drop in breaches.

A hacker has posted all the web vulnerabilities they could find on the UN website.  All the details are on pastebin (complete with f-bombs):  http://pastebin.com/ZB4eLVeS.  This episode is another reminder that web security is essential:

"It's web security 101," Aaron Titus, Chief Privacy Officer for Identity Finder says. "This breach seems to be a very simple attack. If this breach was real, they could have prevented this very easily and should have prevented it."

Though we have no evidence, its a safe bet that the UN had IPS, network firewalls and possibly so-called "next gen" firewalls which are virtually useless.  Its amazing that so many security professionals still can't distinguish between application layer vulnerabilities and perimeter protections.

Note that the hacker used Blind SQL injections, something we detailed on February 2nd.

As we had predicted ("Trend #9:  SSL Gets Hit in the Crossfire) SSL infrastructure is drawing a lot of attention this year.

Google researcher Adam Langley says that Google is planning on disabling online revocation checks, or Certificate Revocation Lists (CRL), in a future version of Chrome.

What's a CRL?

When a browser connects to an HTTPS site it receives signed certificates which allow it to verify that it's really connecting to the domain that it should be connecting to. In those certificates are pointers to services, run by the Certificate Authorities (CAs) that issued the certificate, which allow the browser to get up-to-date information. All the major desktop browsers will contact those services to inquire whether the certificate has been revoked. There are two protocols/formats involved: OCSP and CRL.

So why Google plans on disabling it?  Is it a good idea?

There are valid causes where CRL can't be reached.  When this happens, and the CRL cannot be fetched, the browser disregards that failure (known as a "soft fail"). This bypass makes CRL protection irrelevant when they are very much needed:  Man-In-the-Middle (MITM) SSL attacks.  How?  Malicious browser manipulation can also block the CRL query – making this mechanism ineffective.  Adam called it "soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it." Since CRL has also some performance and privacy issues, Google decided to disable it and introduce a proprietary solution – pushing revocation lists as a software update. They call Certificate Authorities to publish their "more important revocations" in a crawlable way, so it can be fetched by GoogleBot and pushed to Chrome users later on.

But there are drawbacks to Google's approach.  Specifically, their argument ignores other scenarios where the attacker cannot block the user's CRL query, making CRL an effective solution.  Their suggested replacement has its own drawbacks including:

• Its proprietary:
  • Not following the standards is usually a bad security practice (see "IE Bug Exposes Users to XSS Attacks " http://blog.imperva.com/2012/01/ie-bug-exposes-its-users-to-xss-attacks-.html)
  • A lot depends depends on CA's adoption rates.
• Not online – the list has to be fetched and pushed to the customer as opposed to CRL/OCSP online check.
• Not scalable – the client will now have to remember every revoked certificate of every CA – therefore Google already suggesting that only "more important revocations" will be published.
• Not necessarily solves the MITM situation – as MITM attacker can block these updates too (although it would be harder).

Microsoft researcher Eric Lawrence (Web Browser Legend) posted the following response titled  "Beware Silly Similes" on his blog:

In our headline-driven culture, where subtlety and nuance don't draw the clicks that a quick witticism can bring, a great simile will spread across the web like pollen on a spring morning.

Of course, the downside is that, like JPEGs, the compression is lossy. Important information can be obliterated in the conversion process. Technical experts might observe the loss, but an everyday consumer may not detect the difference. In some cases, that’s fine, but in others it really isn’t.

The problem with the simile in that recent blog post is that the information loss is unnecessarily high. The topic is complex, but that doesn't mean we can't use a simile—we just need to think a little harder.

Two more accurate similes immediately leap to mind. We could describe the security feature as

"Like a bicycle helmet that won’t prevent drowning if your boat sinks."

Or we could say it’s

"Like a flak jacket that can’t protect the lungs from chemical weapons."

Both of these are accurate statements that more closely reflect reality.

This is an interesting piece. The SC DMV is suffering from constant attacks--90 attacks since the beginning of the year.

The DMV contacted the FBI, since most of the hackers are attacking from foreign countries. The FBI's local cyber-security squad is assisting the DMV to make sure everything possible is being done to protect the DMV database, which contains not only drivers' names and addresses but also Social Security numbers and copies of birth certificates.

Why is this happening?  Possibilities include:

1. Foreign government gathering citizen information.  Though possible, it doesn't seem as likely.
2. It's not necessarily a foreign government, but a foreign entity gathering data.  Why?  The data could be useful for different purposes, such as for spear-phishing and impersonation. This type of information could be helpful for commercial hackers.
3. Data brokers may be stealing this information and simply selling it to whoever may be interested.

State governments sit on good quality data and probably haven't invested a lot in data security.  This makes them an attractive target.

As attacks on customers expand beyond banking and popular retail applications, organizations cannot sit on the sidelines and expect the average consumer to avoid infection and mitigate attacks on their own.

Fraud is a key--and evolving--challenge facing security teams today. In order to thwart the impact of client-side attacks, such as man-in-the-browser, businesses must take charge of securing the interaction with their clients.

This webinar will:

• Highlight tactics organizations can deploy to dramatically reduce incidents of fraud.
• Provide a high-level, technical overview of client-side attacks and demonstrate how man-in-the-browser attacks operate.
• Reveal two techniques that can be used by a Web application to detect infected clients.
• Discuss practical aspects of implementing these two methods and how to use the output of the detection process in the application.