According to this, Chinese equipment makers have built backdoors into their hardware (which may be the root of Mr. Panetta's remarks).

First, a little perspective:  Most intelligent networking equipment, manufactured by almost any vendor anywhere in the past 20 years have been shown to contain some kind of a backdoor.  Master passwords for routers and secret technician codes for mobile phones or set top boxes have been published over the year (not to mention those secret key combination in Microsoft products that invoke flight simulator games).  This development begs two questions:

What percentage of infrastructure, civilian as well as military, is vulnerable to APT (enemy) shutdown?
The answer really depends on which country, what infrastructure and who is the enemy. In general large modern economies with decentralized infrastructure are less vulnerable. If you have twenty telcos, for example, each using equipment from 2-3 different vendors than the chances for a single blow by an adversary that controls a back door in the equipment of a single vendor are low.

What can companies do about it?
The “text book” mitigation strategy is indeed the use of redundant equipment by multiple vendors. This recommendation conflicts with the attempt to lower the costs of deployed system (as operating two different types of equipment by the same team is of course more costly). 

Oracle released its latest vulnerability list.  What this release highlights is the fact that Oracle should provide work-around instructions rather than dogmatically stick to immediate patching as the single alternative. 

This one has 88 patches.  Only four issues are in the Oracle database server whereas six are in MySQL database server.   Key observations regarding the four database vulnerabilities, two are interesting:

• One vulnerability is severe, ranking 9 on a 10 scale.  What is significant about this issue?  It is the most severe even though exploiting it requires authentication.  In this case, the vulnerability is in a component that is installed by default and  known to have been vulnerable in the past on more than a few occasions.  What does this component do?  It allows users to do geometric searches.  However, geometric search is not used very widely.  Since the geometric search isn’t used very much, so Oracle should recommend, for example, removing the package altogether so only those who need it are exposed to it.
• The second vulnerability is a 7.1 on a 10 scale since it’s a complex exploit—but this seems low.  Why?  This vulnerability requires two procedures:  create library and create procedure.  What is of most interest here it the create library capability which maps the OS module to the database—an inherently dangerous process because you could map any OS native code to be mapped as stored procedures accessible through a DB SQL session.  We suspect that the vulnerability allows server takeover using uncontrolled mapping, and that the patch reduces the ability to map arbitrary modules.  Regardless, a better method would be to simply not allow anyone but an administrator to perform this process. 

Another mega breach headlines last week.  Though no one can say yet what happened, as usual the press statements offer some possibilities.

What is the most important clue?  Visa and Mastercard claim (in their warning to banks) that the full Track data from the card was obtained. This is an interesting piece of information as Track data is not available for web based transactions.  In fact, Track data is only available when the credit card is swiped. It means that the source of the data is point-of-sale devices rather than Internet transactions.  

What about PCI compliance?  Track data storage is forbidden according to PCI-DSS. So either Global Payments are not in compliance with PCI-DSS or the attackers were able to sniff transactions over a network.

According to a recent article, there's a new a DDoS tool from Anonymous called high-orbit ion canon or HOIC (click image to BIGGIFY):

The claim is this:  LOIC did TCP, UDP and HTTP flooding, but HOIC focuses on HTTP only. HOIC includes a new feature called 'boosters' which are files you download or add to an attack machine which enables the attacker to manipulate headers such as language, referrer, host, etc.  This new feature is designed to bypass signature based systems by using a lot of different headers. Additionally, HOIC is supposedly faster. 

But is it really an improvement?  Overall, not really.  There are several reasons:

• Problem 1:  HOIC seems like a step backwards in terms of usability as it requires client side installation and complex configuration files. LOIC offered the ability for people with limited technical skills to perform DDoS--definitely not the case with HOIC.
• Problem 2: HOIC is indeed HTTP focused. However, HTTP flood is inherently slower than UDP flood and simple TCP flood.
• Problem 3:  Just writing in the tool's description "HOIC is faster" does not make it faster and certainly does not explain why.  As they say in the automobile industry:  you can't judge until the rubber hits the road.
• Problem 4: The "boosters" are nothing but configuration files that just allows broader targeting. HOIC could allow you to diversity DDoS attack, but mostly for pretty sophisticated users.  But as we point out in bullet #2 above, are you really gaining more in firepower?

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.

Rumor has it that hackers have obtained the source code for Symantec’s Norton AV. A posting on pastebin presented the file list and hackers are claiming that they also have the code itself. While the code is not yet out, hackers are saying that it is just a matter of time as they are considering how to best publish this information.

As a major DLP vendor, this is quite embarrassing on Symantec’s part. It’s reasonable to assume that the retrieval of such a list could be a result of the files residing on a test server which was mistakenly exposed, or a posting to FTP which unintentionally became public.  It also seems, if you trust the hackers' boasting, that the code was obtained from the Indian military.  Many governments do require source code from vendors to prove the software isn't spyware.  

If the rumors turn out to be true, the implications of the anti-virus code leakage will not keep the Symantec folks awake too late at night, and certainly not their customers. After all, there isn’t much hackers can learn from the code which they hadn’t known before. Why? Most of the anti-virus product is based on attack signatures. By basing defenses on signatures, malware authors continuously write malware to evade signature detection (in 2007, antivirus could only detect between 20-30% of malware). We noted in our blog on the Black Hole Exploit that only 30% of AV would have been effective. Further, malware versions continuously evolve in such a rate where signatures cannot keep up with them in the first place. The workings of most of the anti-virus’ algorithms have also been studied already by hackers in order to write the malware that defeats them. A key benefit of having the source code could be in the hands of the competitors.

If the source code is recent and hackers find serious vulnerabilities, it could be possible to exploit the actual anti-virus program itself.  But that is a big if and no one but Symantec knows what types of weaknesses hackers could find.

The Japanese government collaborated with Fujitsu to create a virus which detects malware and collect info on the hackers. A virus on a virus?

This is the technical schematic:

I see a few problems with it:

• As we all know, most malware and attacks are distributed through non-involved 3rd parties. Obviously the "fight back" mechanism is going to affect these by standers rather than the actual attackers. There are of course tools that can be developed to try and track the actual source of the attack but I don’t see a reason to distribute them as a virus at end-points rather than take a honey-pot approach. I remember that back in the late 90s, there was a trend of "fight back", mainly trying to automatically break into the computer that sent an attack (or allegedly sent an attack) and take it down (or DDoS it). It quickly turned out to be a disaster in terms of going after the wrong people.
• Deliberately introducing viral code into end-points is a one of these things that will only end in tears. Any misconfiguration or vulnerability in the "protection" code will allow attackers to efficiently introduce their code into each end point in the organization.

In a recent data breach incident, a Saudi hacker defaced a prominent sports news web site in Israel and linked its front page to a file exposing the details of many credit card numbers of Israeli citizens.

Below is a comment from Amichai Shulman, CTO and Co-founder of Imperva:

There are two KIND OF interesting things to note from this episode:

1. SQL injection starts of the New Year with a bang:  The incident by itself is not very significant in terms of data security and does not demonstrate any significant technology advancement. The list of cards and personal details were probably not directly obtained by the Saudi hacker. It appears that these lists have been circulating around for quite some time—compiled from various Israeli applications that were broken into. In fact, some of the individuals whose details appeared in the list mentioned that their account showed weird activities already two months ago. The format and structure of the files, discussions from hacker forums and press publications indicate the hackers used mainly SQL Injection.
2. PCI noncompliance:  Interesting to note is that this breach indicates that merchants involved in the incident were anything but PCI compliant.

However, the REALLY interesting aspect to this story is the opportunities this incident created for attackers. One of the immediate effects of the breach is that people in Israel rushed over to the web to check whether they are in the list. This created a wonderful opportunity for attackers of all kinds to promote their business by posting fake links to “the file”. These links, promoted through black hat search optimization, are part of either click fraud campaigns or malware infection schemes.

Other quick entrepreneurs posted web applications which allow people to check whether their name is in the file by supplying their email (some of these are actually legit applications posted by security researchers) and Israeli ID number (clearly not legit). This is of course just a preface to the true problem coming:  phishing campaigns and phone scams that are sure follow.

In the next few days, we expect a deluge of bogus e-mails, allegedly from the credit issuer that calls for some information disclosure on the part of the recipient as part of an “account restitution” procedure.

One last anecdotal effect is that the online account management application for the Israeli issuer was displaying apparent slowdown throughout the day, to the point that it was almost not providing service – that’s what I call crowd sourcing DDoS.

Vendors like WhiteHat (registration required) and Veracode (registration required) release extremely useful and informative reports on vulnerabilities:  how many are out there as well as what kinds.  Indeed, it’s important to be aware of vulnerabilities.  But there’s something interesting about the data when you compare it to our hacker attack data from our web application attack report (registration NOT required) from last July.  While vulnerability scanners make no mention of RFI/LFI issues, our report highlighted them as one of the top four attack methods (SQL injection, Directory Traversal and XSS rounded out the list).  Why the disparity?

The main reason we don't see LFI/RFI in code review is because many website owners/security officers are not necessarily aware of the underlying tech that powers their website. For example, if you install Wordpress, the most popular content management system on the Internet, you get PHP on your server.  Not surprisingly, no one is paying attention to PHP code—especially when it comes to code scanning.  This is because most organizations who invest in code review technologies (or serious web scanning) are not using PHP for their core application. On the other hand, PHP applications are the most prevalent (in terms of absolute numbers) in the web, hence a strong interest by attackers.

Most web applications are PHP based because this is the platform of choice (at least up until now, as you can see at the end of this entry) for small, low cost applications, and MOST applications on the web are small, low cost, applications. As we all know, security expenditure among owners of small applications is very low and they will certainly not invest in Veracode or other code review technology.

How prevalent is PHP?  It's interesting to note that although PHP is by far the most frequently used Server side programming technology (see stats below) it's being ignored by the security community:

• Veracode " Approximately half of the code was in Java, one quarter in .NET, the rest in C/C++, PHP, etc."
• RFI/LFI doesn’t get much respect and visibility ,e.g. not really covered in OWASP top 10, although they are a major factor in hacking websites such as when 1.2 million websites were hacked. 

Some interesting stats and trends on PHP.  First, note the most popular server-side programming languages:

Second, note the growth of PHP into major websites, some  popular sites using PHP include:

• Facebook.com
• Baidu.com
• Wikipedia.org
• Qq.com
• Taobao.com
• Sina.com.cn
• Wordpress.com
• Weibo.com
• 163.com
• Soso.com

Sites using PHP only recently: 

• Soso.com
• Reuters.com
• Wsj.com
• Forbes.com
• 39.net

Recently Accuvant published a study on browser safety.  As the study’s sponsor, Google won!  This is in contrast to another browser comparison from NSS Labs from July 2011 whose results had IE 9.0 as the most secure browser. 

What should consumers and IT professionals believe?  Who has the manliest browser?  Which browser is the girly-man, little-baby loser that landed in their own baby poo?


Browsers are very much like cars only in earlier stage of their life cycle.  In the beginning, the competition was on who has the best basic features (e.g., driving from point A to point B or showing web content). After the basic functionality was achieved, Maslow’s law of hierarchal needs sets in.  Namely, users focus moves to functionality and efficiency (e.g., fuel consumption or speed of rendering). 

However, when comparing security features, some of the logical conundrums that plague cars similarly plague browsers:

• If one car has ABS system and the other one has air bags – who is safer?
• If one browser runs flash in sandbox and the other has anti-XSS filter – who is the safer?

The answer:  depends on the criteria.  Of course, any judgment depends on several factors such as driving/browsing habits and skills.  The problem when evaluating browsers is this:  what are your crash test criteria and how do you weigh the scoring?

Let’s look at the NSS results.  They summarize:

Socially Engineered Malware remains the most common security threat facing Internet users today. Recent studies show that users are four times more likely to be tricked into downloading malware than be compromised by an exploit.

European users have found themselves particular targets of malware authors over the last 12 months. In 2010, threat researchers discovered new ZBOT variants specifically targeting banking systems in four European countries.

According to the EU’s statistics office, Eurostat, almost one third of internet users in the European Union were victims of malware infections in 2010 despite the majority having security software installed. Of the 27 EU countries surveyed (totaling over 200,000 users), those with the highest malware infections include Bulgaria (58%), Slovakia (47%), Hungary (46%), Italy (45%) and Estonia (43%.)

The NSS study focused solely on malware blocking.  The conclusions:

• Very good results for IE – a clear leader with Chrome and others far behind.
• Reputation services are crucial for mitigating attacks – This is critical since all of the browsers are using URL reputation services. But even when everyone is using reputation services there are two main differences:
  • Quality of data – obviously IE is using a more comprehensive and rapidly updating sources.
  • Integrating several different sources of reputation service – IE9 demonstrates the combination of URL reputation services AND application reputation lead to 100% (!!!) detection rate:

The Accuvant study, by contrast, added and focused on other criteria.  URL reputation and application reputation are barely considered.  In fact, the category “URL Blacklisting” doesn't get a lot of attention:

What is the bottom line of all this?

• If you’re a geek, go for security through obscurity:  The best way to minimize accidents' consequences to is to avoid it altogether. The way to avoid cyber accident is by using a platform which is less targeted by hackers due to its small market share. Such an example would have been Firefox with Linux when Windows and IE dominated the web.  At the time, Firefox wasn't less vulnerable than IE but it was less exploited due to its marginal market share. This method is of course limited to tech geeks willing to invest in installing learning and dealing with exotic platforms in rapid manner.  But this won’t work for the masses who may not have the time nor expertise to learn a new browser.
• For consumers, use newer browsers:  We do know that while safer cars (up until now) did not dramatically reduce the number of accidents they do reduce dramatically the number of casualties. So, if randomly accessing an infected page is like having an accident you’d better be driving 2011 made browser (IE9, updated chrome, etc.) and not an AMC Pacer (IE6). The problem is that when we drive the road we assume that everyone else is trying to avoid accidents rather than plan for them to happen. This is clearly not the case with navigating cyberspace where someone is constantly plotting on getting us into accidents.