Chrome: Fully sandboxed flash engine protect users

The truth is that not everyone gets updates to chrome as soon as its released. And as its usually the case a lot of holes get discovered only after its exploited in the field. Google has finally announced a fully sandboxed flash engine which prevents the malicious code running within the flash component to fully exploit the system. It should keep you safe from unexpected security threats until an update arrives.

Google says sandboxing is now available for Flash “with this release” of Chrome. The most recent version, Chrome 23, arrived last week, which is when the four-year-old browser received its usual dose of security fixes (14 in total), as well as a new version of Adobe Flash. 

Yet the company today wanted to underline today that Chrome’s built-in Flash Player on Mac now uses a new plug-in architecture which runs Flash inside a sandbox that’s as strong as Chrome’s native sandbox, and “much more robust than anything else available.” This is great news for Mac users since Flash is so very widely used, and thus is a huge target for cybercriminals pushing malware. 

Malware writers love exploiting Flash for the same reasons as they do Java: it’s a cross-platform plugin. Such an attack vector allows them to target more than one operating system, more than one browser, and thus more than one type of user. What Google is doing here is minimizing the chances that its users, namely those using Chrome, will get infected by such threats.

Top security threats from Oracle, Adobe and Apple

Kaspersky labs came out with its Q3 report and not surprisingly Oracle and Adobe have some of the worst holes impacting the largest number of users. What I was surprised more about was that Apple made it to that list even though Microsoft didn’t explicitly get named. The map below shows the % of users infected.

Also found it interesting that iTunes has a lot of holes. Who would have thunk it.

IT Threat Evolution: Q3 2012 – Securelist

What are software defined radios ?

I had never heard of SDRs until today. But now that I know it, I can understand why some folks are so excited about it. This is almost like a swiss army knife for the radio hackers.

The HackRF can shift between different frequencies as easily as a computer switches between applications–It can both read and transmit signals from 100 megaherz to 6 gigaherz, including frequencies as low as the range used by FM radio up to the gigaherz frequencies used by Wifi or experimental wireless protocols for cars communicating in traffic. In between those bookends lies everything from police radio to cellular signals from AT&T; and Verizon to garage door openers–all signals that HackRF can instantaneously intercept or reproduce. 

The point of catching exceptions

Using Try-Catch block is a very good way to detect run-time exceptions. But one of my code reviewers recently pointed out that over using them can be dangerous. I was pointed out that I should only catch those exceptions which I understand and should correctly handle them once its caught. Catch-all try-blocks may generate less user facing errors, but could hide the more serious issues.

Nothing else describes the danger of this way of ignoring exceptions than this post on android-ssl.org [ More details in this paper ].

To evaluate the real threat of such potential vulnerabilities, we have manually mounted MITM attacks against 100 selected apps from that set. This manual audit has revealed widespread and serious vulnerabilities. We have captured credentials for American Express, Diners Club, Paypal, Facebook, Twitter, Google, Yahoo, Microsoft Live ID, Box, WordPress, IBM Sametime, remote servers, bank accounts and email accounts. We have succesfully manipulated virus signatures downloaded via the automatic update functionality of an anti-virus app to neutralize the protection or even to remove arbitrary apps, including the anti-virus program itself.

To be honest I haven’t see how these apps have implemented this… but based on my java/python background I’d say there is a good chance that either a flag was passed to ignore certificate errors, or a try catch block was implemented to catch+ignore all exceptions (which included valid security exceptions).

Beast and Crime : How chrome is impacted

One of the first discussions I noticed around TLS/SSL was in a news report last year.

At the Ekoparty security conference in Buenos Aires later this week, researchers Thai Duong and Juliano Rizzo plan to demonstrate proof-of-concept code called BEAST, which is short for Browser Exploit Against SSL/TLS. The stealthy piece of JavaScript works with a network sniffer to decrypt encrypted cookies a targeted website uses to grant access to restricted user accounts. The exploit works even against sites that use HSTS, or HTTP Strict Transport Security, which prevents certain pages from loading unless they’re protected by SSL.

These guys came back again this year with another attack called “CRIME“. A simplified version of how this attack is executed is described here along with the plan on how chrome is going to address is.

The problem that CRIME highlights is that sensitive cookie data and an attacker controlled path is compressed together in the same context. Cookie data makes up most of the red, uncompressed bytes in the diagram. If the path contains some cookie data, then the compressed headers will be shorter because zlib will be able to refer back to the path, rather than have to output all the literal bytes of the cookie. If you arrange things so that you can probe the contents of the cookie incrementally, then (assuming that the cookie is base64), you can extract the cookie byte-by-byte by inducing the browser to make requests.

Data URLs and XSS injections

I knew there were ways to embed an image into an HTML page by adding a ‘src’ to the ‘img’ tag which contained the whole base64 encoded image file. What I didn’t know is that there are ways to use similar methods to invoke javascript in context of the current page.

For example, HTML tags like the following could be used to inject XSS into any page. Most browsers (especially chrome) do protect against this, but it may be possible to get around some of the security measures.

“>clickme 


PHNjcmlwdD5hbGVydChvcGVuZXIuZG9jdW1lbnQuYm9keS5pbm5lckhUTUwpPC9zY3JpcHQ+“>clickme 

Read this for little more background.

Nexus devices have no SD card slots. Why ?

Missing SD card slots in Nexus devices shouldn’t be looked at as a disadvantage. Read this to get the full picture.

Google still supports removable storage in Android, but it is leading by example and providing phones (and now a tablet) with one big block of storage that users can use for anything they like — be it media, documents, or apps. There are a couple of side benefits to this approach as well. The first one is a bit geeky — it allows the device to use ext file systems instead of a mix of ext and FAT. This is faster and safer — both for the data on the device and the way it’s handled, and access to our own personal data. A journalized file system means fewer file errors, and ext preserves file system permissions so random code can’t find your pictures or documents folder.

Organized crime and trojan hacks to attack banking customers

An international gang of cyber crooks is plotting a major campaign to steal money from the online accounts of thousands of consumers at 30 or more major US banks, security firm RSA warned. 

In an advisory Thursday, RSA said it has information suggesting the gang plans to unleash a little-known Trojan program to infiltrate computers belonging to US banking customers and to use the hijacked machines to initiate fraudulent wire transfers from their accounts. 

If successful, the effort could turn out to be one of the largest organized banking-Trojan operations to date, Mor Ahuvia, cybercrime communications specialist with RSA’s FraudAction team, said today. The gang is now recruiting about 100 botmasters, each of whom would be responsible for carrying out Trojan attacks against US banking customers in return for a share of the loot, she said.

Chrome hole patched in 10 hours

If you are not blocking chrome updates, you will be automatically patched very soon. No need to wait for the monthly ‘patch tuesday’. 

Google has fixed a hole in its Chrome browser that earned a white hat hacker $60,000 at the recent Pwnium 2 hacking contest. 

The company released the fix for the vulnerability on Wednesday, around 10 hours after it was revealed at the Pwnium competition at ‘Hack in the Box 2012’ contest in Kuala Lumpur, Malaysia on Tuesday. The hacker — who goes by the name of ‘pinkie pie’ — found the vulnerability in the browser by combining two separate exploits, and netted a cool $60,000 for his discovery, as well as a free Chromebook.

Book review: Zero day – A brilliant novel

Zero Day by Mark Russinovich is a brilliant novel about why we should fear an online attack by a rogue non-state-sponsored terrorist before any other forms of spectacular attacks.

I didn’t know that Boing 787 was fully fly by wire, and that medication in hospitals were controlled by networked computers. While attacking that type of software would require specialized knowledge on internals of those systems, it may not be as far fetched as most of us assume it to be.

The fact that zero day exploits are available for sale is also not a secret anymore. There are organizations out there who are willing to pay big bucks for those who prefer money than fame. Why do you think pwn2own doesn’t require exploits to be fully documented anymore ? The proliferation of networked computers is good idea, but our inability to patch them on time is a recipe for disaster.

I’ve worked long enough in IT to know that not all patches are applied immediately to all systems as soon as they are released. There is a long, expensive process to make sure that patches don’t bring down the entire network. And because of this, a lot of organizations patch the most critical systems at the very end (after everything else is patched).  And thats for the holes for which patches are available from the software vendor. There are tons of other holes which are still being researched by the vendor, and even more which are not reported to the vendor yet.

Though it may be hard to believe that an attack as big as the one described in this book would go unnoticed by all of the security vendors, its definitely plausible and shouldn’t be ignored.

I highly recommend you to read this book if you are even remotely concerned about how fragile our infrastructure can be. The least you could do is patch your own systems.