This is entertaining.  The gist:

[Anonymous'] disguise is earning big bucks for a major media conglomerate. Warner Brothers, the Time Warner subsidiary who produced the movie, owns the rights to the Guy Fawkes mask – and they earn royalties on every sale. (Obligatory disclaimer: Time Warner is also TIME’s parent company, so in an extremely roundabout way, we’re also profiting from this.) While Time Warner hasn’t released any data related to their earnings from the masks, it’s safe to say that the hundreds of thousands of Guy Fawkes masks sold each year helps to bring sure profit to the company.

Today we published our second Web Application Attack Report (WAAR).  The full version is available here (no reg required).

Last report we described the most common attacks against applications which included SQL injection, Local File Inclusion, Cross Site Scripting and Directory Traversal.  This time we added Business Logic Attacks.  Here's an excerpt from our WAAR detailing the nature of attack.

Business Logic Attacks
A Business Logic Attack (BLA) is an attack which targets the logic of a business application. “traditional”, technical, application attacks contain malformed requests. On the other hand, business logic attacks include legitimate input values. This lack of unusual content attributes makes a business logic attack difficult to detect. BLAs abuse the functionality of the application, attacking the business directly. A BLA is further enhanced when combined with automation, where botnets are used to challenge the business application.

BLAs follow a legitimate flow of interaction of a user with the application. This interaction is guided by an understanding of how specific sequences of operations affect the application’s functionality. Therefore, the abuser can lead the application to reveal private information for harvesting, allocate her a disproportionate amount of shared resources, skew information shared with other users, etc. The motivation for BLAs is that the attacker can convert these effects to monetary gains.  We followed two types of BLAs:  email extraction and comment spamming.

Email Extraction
Email extraction (also called email scraping) is the practice of scanning web applications and extracting the Email addresses and other personal contact information that appear in it. These emails are then used for promotional campaigns and similar marketing purposes. Email extraction is one of several activities that harvest data from web applications against the intent of the data owners and the applications’ administrators.

On average there were 20000 such attacks each month, but clearly there was a peak of activity during September-October and much lower activity during other months:

Email extraction is a “grey area” practice: attackers earn easy money by selling information extracted illegitimately from web applications. The attack does not exploit vulnerabilities in the application. Rather, the data is extracted by automatically scanning the targeted application, while imitating a user’s browsing activity. To speed up the attack and avoid black listing, several scans are run concurrently using web proxies.

Email extraction is offered on the web both as an online service (i.e., “pay on delivery”) and as software tool for download. The notorious “Beijing Express Email Address Extractor”, a software tool freely available on the web, was responsible for over 95% of the Email Extraction activity we identified. Usage of the commercial software Advance Email Extractor was also seen in the traffic.  This is the Beijing Express Email Address Extractor:

Hosts that sent Email extraction traffic to the observed application had very unusual geographic locations: Of the 9826 hosts, 3299 (34%) were from Senegal and 2382 (24%) were from Ivory Coast. Other unusual countries (Thailand, Malaysia, Ghana and Nigeria) were also prominent in the list of attacks’ geographic sources. Obviously, attackers are hiding their tracks by employing remote and perhaps less monitored hosts for this attack type.

The EU has come out with a data protection proposal.

First, the good stuff:

• The new EU privacy law takes a good step forward for privacy.  The ability to control and even delete individual data profiles is a needed move. 
• Unifying laws across the member EU states makes sense.

However, the proposal doesn’t do enough to protect data.  Since it mainly proposes fines, it will not help keep EU citizen data safe from hackers or insiders.  Such approaches have not met with success in the past.  Why?  Fines enable companies to game the system. They can risk a breach without having put in place the basic elements of cyber defense. 

Rather, the EU should put in place fines coupled with a more prescriptive approach, working with industries to identify specific actions firms should take to protect data.  The payment card industry, PCI, adopted this approach through self regulation and has managed to lock down data better than any regulation in existence today.  This prescriptive method makes gaming the system much tougher.  More importantly, by involving the industries and not just spanking them, private enterprise has real skin in the game.

Yesterday we mentioned that the Polish government experienced numerous DDoS attacks.  Today, it is Brazil's turn.

This pastebin site shows that several Brazilian government sites were brought down:  

http://pastebin.com/sSi54WFf 

Here's an image of a downed Brazilian government site:

http://img855.imageshack.us/img855/5739/brasiloff.png

All in all, many websites were taken down. The fact that most of them are up again indicates that this was not the most sophisticated attack. However, the speed and power of the DDoS attacks is something to worry about.  

Looking at the LOIC downloads in Brazil, they were high but not compared to the US, Poland or France. It seems these attacks were propogated mostly through websites which enabled DDoS attacks.

Bradley Manning is on trial.  For some reason, we didn't find this Wired article linking Manning's document download spree with SharePoint until now.  Here are the key passages:

Special agent David Shaver, who works for the Army’s Computer Crime Investigative Unit, said that on one of two laptops that Manning used he found a folder called “blue,” in which he found a zip file containing 10,000 diplomatic cables in HTML format, and an Excel spreadsheet with three tabs.

Shaver discovered Wget scripts on Manning’s computer that pointed to a Microsoft SharePoint server holding the Gitmo documents. He ran the scripts to download the documents, then downloaded the ones that WikiLeaks had published and found they were the same, Shaver testified.

Our blog last week caught an early snapshot of LOIC downloads being used to DDoS various websites.

Today, the download picture has changed.  Year to date, there were 90,000+ downloads with a peak of 33,007 on the 20th of January.  Today, downloads are trending back to pre-campaign levels (click to BIGGIFY):

And downloads by country hasn't changed in any dramatic fashion.  The US is still the lead nation, followed by France and Brazil.  The only big change is that Poland moved up quite a bit:

The increase in Polish downloads is likely due to an attack on Polish government websites which has been reported in Polish and German press.

Once again, Anonymous is using the low orbit ion canon (LOIC) to DDoS websites.  This tool was developed by white hat hackers stress test websites.  

Not surprisingly, the tool they are using is exactly the same one used for Operation Payback which took place about a year ago.

Looking at the LOIC downloads so far this year, its clear there has been a sudden, sharp increase in the past few days which coincides with the latest Anonymous campaign (click image to BIGGIFY):

And the top country downloading the attack tool?  The US though not with a huge lead.  France and Brazil are not far behind.  Click image to BIGGIFY:

(NOTE:  These above numbers are current as of 8:30ish AM PST.  The stats will change.)

In addition to the version of LOIC that is downloaded and used locally, several websites have been developed that automatically DDoS simply by loading them.  Here is one example:

Typically, these sites use a JavaScript to iterate attacks.

PC World covered Tal Be'ery's discovery of an IE flaw.  Interestingly, the article features an argument that the issue isn't a bug after all.  Tal's response:

Apps should definitely not trust client’s input and sending it back unsanitized in the response is a security vulnerability. The relevant real world question is whether or not this vulnerability is exploitable.

In the case of the reflected XSS, the attacker cannot control the encoding of the URL. Therefore, for the example specified in the blog entry, had IE implemented the URL encoding according to the RFC (as Chrome and FireFox do) the vulnerability would not be exploitable.

Even if XSS is caused by poorly written apps, the browser made it their business to protect against it. In fact, Microsoft takes pride in their XSS filter. Implementing a fancy filter on one hand, and then helping XSS attackers by being noncompliant with proper security standards on the other, is like having a fancy shield and then shooting yourself in the foot.

Imperva CTO Amichai Shulman on Oracle's latest critical patch update (CPU).

This is a standard patch.  However, quite a large volume of patches are dedicated to the MySQL database which is a new introduction into Oracle's CPU process.  Overall, there are 78 vulnerabilities which is consistent with previous releases.  However, considering Oracle added MySQL to the patching process, this number seems low.

Key observations:

• There is a bottleneck in the Oracle patching process.  If you were to introduce a new product, there should be more vulnerabilities overall in the CPU--but this didn’t happen.  Could there be obstacles in the security and testing process?  While introducing MySQL into the patch process is a good thing, it emphasizes again scalability problems. With the introduction of a new product, especially when it shows 27 fixes in this CPU, you'd expect the number of overall patches in the CPU to increase. This has not happened. For example, the Oracle DB server product only shows two fixes. 
• There are only two vulnerabilities in the database product.  Why? Either the database server has reached an amazing maturity in terms of security or Oracle did not have enough resources to include more fixes into the process.  This may be a consequence of adding the new MySQL product in the patching process.  However, another factor may be that these fixes are much more critical and complex than their CVSS score suggests.
• Oracle continues to undervalue the severity of their reported vulnerabilities.  For example, the vulnerability described in InfoWorld is CVE-2012-0082 only gets a 5.5 on the severity scale.  As another proof point, one Solaris vulnerability (CVE-2012-0094), scores a 7.8 but is very similar to issues Oracle database server and MySQL products that scored just a 5.5. 
• Other stuff:  Other than that there are many fixes in HTTP based components of the Oracle product line.

What does this release tell us to expect from Oracle security in 2012?

• Severity scores will continue to be misleading.  Oracle should rethink their "Partial+" ranking which artificially plays down the severity.
• Vulnerability bottleneck.  They should fix this bottleneck, especially as they introduce new products and acquisitions continue.  We assume the bottleneck exists due to the relative low num of vulnerabilities while the patch increases in terms of products covered. As in many organizations, it’s safe to assume that Oracle has a security team separate from the engineering team that deals with the vulnerabilities and so the bottleneck most likely resides there and should be removed.

A bug in IE allows hackers to conduct XSS attacks.  The flaw in IE gets a little techie but it is essentially this: the way double quotes are encoded by IE isn't properly done.  This oversight has a significant downstream effect for websites supporting IE (and there's a lot).  Since website developers assume requests from IE are properly done, hackers can sneak XSS attacks into websites.

Here are the technical details.  Internet Explorer (IE) doesn't encode double quote characters (") in the query part of the uniform resource identifier (URI). This behavior, besides being non standard (as stated by RFC and implemented by other browsers including Chrome or Firefox) may expose IE users to reflected XSS attacks.  How? Websites may assume that the URI in the request is properly encoded by the browser and embed it "as is" in the HTML response. Since double quotes are not properly encoded by IE it may break the websites HTML structure and allow an attacker to smuggle an XSS attack against the IE user.

According to RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt) which defines the URI syntax, the proper syntax of the query part of the URI is as follows:

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

   query         = *( pchar / "/" / "?" )

   pct-encoded   = "%" HEXDIG HEXDIG

   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

   reserved      = gen-delims / sub-delims

   gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"

   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"

                 / "*" / "+" / "," / ";" / "="

It's easy to verify that double quote should be "pct-encoded" and therefore represented as %22.

Furthermore, IE behavior is inconsistent across the different parts of the URL - double quote gets encoded on the "path" part of the URI but not on the "query" part.

For example, typing the following URI in IE's address bar– 'http://example.com/Sea"rch.asp?q"="b"' over the wire it will be 'GET /Sea%22rch.asp?q"="b" '

See the following wireshark screenshot (click to BIGGIFY): 

If a website embeds the request's URI directly into the source of the page, assuming that it was properly encoded by the browser, it would break the HTML.

Consider the following scenario:

A web designer wants to dynamically embed the URL as a parameter in request for an image. The following JSP code implements just that:

out.println(" <Img src=\"http://www.example.com/pic.asp?ref=" + request.getRequestURL() + "?" + request.getQueryString() +"\">");

Now the hacker can create a reflected XSS attack by convincing the victim to follow the following link:

hxxp://vulnerablesite.com/vulnerablepage.jsp?"onmouseover=alert(1)//

On IE the victim gets the following HTML

<Img src="http://www.example.com/pic.asp?ref=hxxp://vulnerablesite.com/vulnerablepage.jsp?"onmouseover=alert(1)//">

And the event handler is now running a javascript on the victims browser.

When the same URI is accessed with a different browser (Chrome), the request is properly encoded and the script is not smuggled into the request.

<Img src="http://www.example.com/pic.asp?ref=http://10.1.1.190/decodeTest/showquery2.jsp?%22onmouseover=alert(1)//">

We have seen such vulnerable applications over the internet – so the threat is very actual and not theoretical.

We have contacted Microsoft and got the following response:

Thank you for writing to us.  The behavior you are describing is something that we are aware of and are evaluating for changes in future versions of IE, however it's not something that we consider to be a security vulnerability that will be addressed in a security update.

We beg to differ.  In fact, on XSSed.com (a site for public disclosure of XSS vulnerabilities), the vulnerability’s presence is beginning to be felt.  We have seen reported sites that are exposed to XSS attacks on IE users only, due to its encoding bug.