A Visual Guide to Rich Snippets

If Google understands the content on your pages, we can create rich snippets—detailed information intended to help users with specific queries. For example, the snippet for a restaurant might show the average review and price range; the snippet for a recipe page might show the total preparation time, a photo, and the recipe’s review rating; and the snippet for a music album could list songs along with a link to play each song. These rich snippets help users recognize when your site is relevant to their search, and may result in more clicks to your pages.

For companies leveraging content strategies, there’s an especially large benefit of having mark up for authors being displayed in the SERPs with the emergence of AuthorRank. For instance, a “know” based query (informational search) that displays an author with a photo, name, and a link other articles they’ve written creates a feeling of trust and authority. It can also encourage them to click-through and read other articles they’re written, essentially making that author a new resource.

Great Post on Rich Snippets Here

Google Chrome Finally hacked at Pwn2Own

Vupen Security and Sergey Glazunov independently managed to penetrate Google Chrome’s security defenses at the Pwn2Own and ‘Pwnium’ contests respectively. The annual competition, which invites ethical hackers from around the world to attempt hacking into the most popular web browsers and in the process expose vulnerabilities and loopholes in the browser’s security, while grabbing a handsome reward.

At this year’s competition, the co-founder and head of research of Vupen, Chaouki Bekrar and his team managed to break into Google Chrome in less than 5 minutes, in the process quashing talks about the browser’s unquestionable security. They used “a pair of zero-day vulnerabilities to take complete control of a fully patched 64-bit Windows 7 (SP1) machine.” For the successful break-in, Vupen has won itself 32 points.

Google Chrome security knew that the Flash Player plugin sandbox is significantly weaker and that an exploit against Chrome’s Flash Player would have to go through a certain path.Having figured out that Vupen used that technique (from the May video), Google decided to add a specific protection for Flash. The hack qualifies him for one of the top $60,000 prizes that are part of Google’s $1 million Pwnium challenge, and could be the launch of a new security career.

VUPEN co-founder Chaouki Bekrar, an outspoken exploit writer who insisted the team deliberately targeted Chrome to prove a point, was uncharacteristically coy when asked if the faulty Chrome code came from Adobe.”It was a use-after-free vulnerability in the default installation of Chrome,” he said. “Our exploit worked against the default installation so it really doesn’t matter if it’s third-party code anyway.” Bekrar told, Zdnet reports.

IE 9 on Windows 7 was also hacked, again through a complicated hack that had to circumvent the browser’s sandbox. Microsoft, however, may not respond so rapidly, as its quality testing procedure usually takes a few months to fix bugs like these.Safari on Mac OS X Snow Leopard, along with Firefox and IE 8 on Windows XP, was also hacked.

Verizon Data Breach Report 2011

Metrics, Interpretations, and Action Plans

It’s that time of year again! I just got my hands on the 2011 edition of the Verizon/SS Data Breach Report, and I figured I’d take a moment to share my thoughts.

First of all, note that the scope of the report now includes approximately 800 “incidents” from the year prior; last year’s report was comparable in size, covering 761 events. Next, I observe that this report is by no means “complete;” while a good deal of the year’s most significant incidents have been covered, there are likely thousands of noteworthy data points which have been overlooked or otherwise left out.

Now, the report:

The Good

Verizon has some good news and some bad news; the good news – only 76% of recorded data breach targets were servers in 2010, compared to much higher percentages in 2009 and 2008. However, this implies that the focus has shifted towards endpoint and social targets, which is very bad news, indeed. Probably nothing ground-breaking at this point, but this demonstrates the consistent challenge corporations face in raising enterprise-wide security awareness; we have erected multi-million dollar defense systems, and continue to monitor our logs for interesting traffic, but we cannot fix “people” problems with products. Additionally, note that – of the breaches reported – we continue to see a steady decline in those involving multiple parties, as well as business partner attacks. This is good news to corporations, as it indicates continued success in technical and business measures to control outsider access to enterprise resources.

Deficiencies Based upon USSS/Verizon Breach Investigation Report

Next, I’d like to take a look at some of the numbers which rose consistently between the three recent years. Specifically, I’d like to dwell on the “Employed Physical Attacks” metrics; over a 3-year window, this percentage has tripled (with little fluctuation in data set size in the prior 2 years), indicating a continued focus on technical security. While improved technical security may prevent a good deal of data breaches, it is not a holistic solution, and often results in “sore thumb” deficiencies.

Trends that are Not Necessarily Consistant based upon USSS/Verizon Breach Investigation Report

Finally, I’d like to focus on the metrics provided which seemed to fluctuate between the reports issued in 2009, 2010, and 2011; note that, in 2010, the size of the breach “pool” increased tremendously with the inclusion of the US Secret Service data. Due to this, I would like to focus primarily on the metrics that rose between the 2010 and 2011 reports. Most specifically, I am concerned when I see the HUGE rise in percentage of breaches that have been discovered by a third party (+25% over a year, +17% over two years). While I’m sure corporate log monitoring initiatives have started to kick off, what is being done today is NOT enough. With “blended” attacks on the rise, there is a growing business case for event correlation and collective log management & review; if enterprise shops do not take action on this item, this number will rise exponentially. On a similar note, I observe that a steady (though slightly rising) portion of the reported breaches have been deemed avoidable, in retrospect, via simple or intermediate controls. These controls may include password policy enforcement, implementation of stateful packet inspection on firewalls, and security-focused Quality Assurance for web application content (among others). The effectiveness of such measures should be audited periodically.

Wrapping up:

  • Shift in focus from Servers to Endpoints and Staff
  • Shift to Physical Compromise, as opposed to Technical
  • Social Compromise percentage consistent between 2009 and 2011 reports, although 2010 report indicates huge increase
  • VAST majority of breaches are avoidable through simple controls
  • Insider attacks are down, as are business partner breaches
  • Third parties are disclosing breaches before first parties

 

Action Items:

  • Know your assets
    • Accurate, comprehensive, and authoritative inventory is encouraged
    • Not just servers and endpoints, but identity assets as well
    • Pre-requisite to next item:
  • Monitor your logs
    • Consider Event Collaboration & Correlation tools (not necessarily a product or a service, this can be a series of well-crafted scripts); note that the return presented by a product will be extremely limited, based upon organizational structure.  From my limited perspective, I see that most enterprise organizations should have comprehensive identity and asset inventory systems to get the most out of vendor SIEM products.  Even with SIM/SEM, individuals need to review their relevant logs frequently
  • Invest in simple, easily monitored, controls (such as account usage policies, password complexity and refresh requirements, etc)
    • If they are already in place, audit your controls for effectiveness; more importantly, adjust accordingly
  • Continue to raise enterprise awareness against breach indicators, consider random employee awareness drills
  • Continue to raise enterprise awareness against physical security threats, enforce physical security policies (for example, laptops must be locked and docked within the office)
  • Secure your endpoints, aggregate event logs, AV logs, etc. from workstations to a common environment for review

Original Blog Post

Comodo RA Compromise

On March 15th 2011, a Comodo affiliate RA was compromised resulting in the fraudulent issue of 9 SSL certificates to sites in 7 domains. Comodo claims no root keys, intermediate CAs or secure hardware was compromised. The compromise occurred at an affiliate who is authorized to perform primary validation of certificate requests. The RA account in question has been suspended pending on-going forensic investigation.

The attack came from several IP addresses, but mainly from Iran.

IP Address Location
 
IP Address 212.95.136.18
City Tehran
State or Region Tehran
Country Iran, Islamic Republic of
ISP Pishgaman TOSE Ertebatat Tehran Network.
Latitude & Longitude 35.696111 51.423056

 

The affected domains according to Comodo are:

  • login.live.com
  • mail.google.com
  • www.google.com
  • login.yahoo.com (3 certificates)
  • login.skype.com
  • addons.mozilla.org
  • Global Trustee

Comodo has revoked these certificates and listed them in its revocation list. Microsoft also is releasing an update that will blacklist these certificates.

The attacker obtained username and password to log into the partners systems, and was able to issue the fraudulent certificates. According to Comodo, the breach was discovered quickly and they are pretty sure that the attacker only issued the now blacklisted certificates.

Was this a state-driven attack?  Iran recently deployed DPI (Deep Packet Inspection), high-end network equipment that uses ultra-fast microchips to read and classify internet traffic in transit. The Iranian authorities used DPI to detect the highly specific parameters Tor uses to establish an encrypted connection. Since the Tor project developers have redesigned the software so that its traffic looks just like any other when it sets up an encrypted connection, and Iranian Tor users are now back to normal.

Google to remove malware by reaching into your Android Device

Android-Logo-LeaningGoogle’s Android Market Place recently thought to have been loaded with 21 malicious applications, which is now thought to actually be closer to 58 applications, will soon be cleaned up. The Android Market operates on a trusted-developer model: Once you’re in, you can publish and update software at will.

Google’s latest reaction, Saturday night by Android security head Rich Cannings, is the remote removal from users’ phones of applications identified as malware. Google also plans to release a security update “”Android Market Security Tool March 2011″ to infected phones.

The kill switch is actually software that’s downloaded onto an Android smartphone and installed automatically, removing the apps in question with no user action required. In its Google Mobile Blog, the company announced:

“We are pushing an Android Market security update to all affected devices that undo’s the exploits to prevent the attacker(s) from accessing any more information from affected devices. If your device has been affected, you will receive an email from [email protected] over the next 72 hours. You will also receive a notification on your device that “Android Market Security Tool March 2011” has been installed. You may also receive notification(s) on your device that an application has been removed. You are not required to take any action from there; the update will automatically undo the exploit. Within 24 hours of the exploit being undone, you will receive a second email.”

Google downplayed the harm caused by these malware apps, assuring users that none of their personal data has been compromised:

“For affected devices, we believe that the only information the attacker(s) were able to gather was device-specific (IMEI/IMSI, unique codes which are used to identify mobile devices and the version of Android running on your device). But given the nature of the exploits, the attacker(s) could access other data.”

Android devices are still vulnerable because of existing security holes at the system level, which must be fixed by cellular carriers and hardware manufacturers. The problem is made worse by cellular providers sticking with older versions of Android, unfortunate because the security exploit only affects Android versions 2.2.1 and older.