Just wanted to let you know that we sent out ERNW Newsletter 32 end of last week. As we promised it includes the results of research regarding the question “Is browser virtualization a valid security control in order to mitigate browser based security risks?”.
Simon did a great job with writing the latest newsletter. It’s a 30-page document which should help you to have a basis for well-informed decisions when it comes to the deployment of an application virtualization technology.
Everybody who is interested in our newest tool ‘Loki’ is welcomed to head over to ERNW’s tool section and download it. Take this monster for a spin and let us know in the comments how you like it. Loki’s coding father Daniel is more than happy to answer your questions and criticism.
You don’t even know what Loki is?
In short: An advanced security testing tool for layer 3 protocols.
One of the biggest pains in the ass of most ISOs – and subsequently subject of fierce debates between business and infosec – is the topic of “Browser Security”, i.e. essentially the question “How to protect the organization from malicious code brought into the environment by users surfing the Internet?”.
Commonly the chain of events (of a typical malware infection act) can be broken down to the following steps:
1.) Some code – no matter if binary or script code – gets transferred (mostly: downloaded) to some system “from the Internet”, that means “over the network”.
… recently published here.
While I certainly agree with those comments stating that there’s a fishy element in the – conspiracy theory nurturing – story itself, this reminds me that Graeme Neilson (who gave the “Netscreen of the Dead” talk at Troopers, discussing modified firmware on Juniper and Fortinet devices) and I plan to give a talk on “Supply Chain (In-)Security” at this year’s Day-Con event. We still have to figure out with Angus if it fits into the agenda (and if we have enough material for an interesting 45 min storyline ;-)) though. Stay tuned for news on this here.
Today was an interesting day, for a number of reasons. Amongst those it stuck out that we were approached by two very large environments (both > 50K employees) to provide security review/advise, as they want to “virtualize their DMZs, by means of VMware ESX”.
[yes, more correctly I could/should have written: “virtualize some of their DMZ segments”. but this essentially means: “mostly all of their DMZs” in 6-12 months. and “their DMZ backend systems together with some internal servers” in 12-24 months. and “all of this” in 24-36 months. so it’s the same discussion anyway, just on a shifted timescale ;-)]
A number of customers has approached us with questions like “Those new MiTM attacks against SSL/TLS, what’s their impact as for the security of our SSL VPNs with client certificates”?
In the following we give our estimation, based on the information publicly available as of today.
On 11/04/09 two security researchers (Marsh Ray and Steve Dispensa) published a paper describing some previously (presumably/hopefully) unknown MiTM attacks against SSL/TLS. CVE-2009-3555 was assigned to the underlying vulnerabilities within SSL/TLS.
The attacks described might potentially allow an attacker to hijack an authenticated user’s (SSL/TLS) session. In an IETF draft published 11/09/09 and describing a potential protocol extension intended to mitigate the attacks the following is stated:
“SSL and TLS renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client’s initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data.”
… this would not have happened. At least this is what $SOME_DLP_VENDOR might tell you.
Maybe, maybe not. It wouldn’t have happened if they’d followed “common security best practices” either. Like “not to process sensitive data on (presumably) private laptops” or “not to run file sharing apps on organizational ones” or “not to connect to organizational VPNs and home networks simultanously”. yadda yadda yadda.
Yesterday I took a long run (actually I did the full distance here) and usually such exercises are good opportunities to “reflect on the world in general and the infosec dimension of it in particular”… at least as long as your blood sugar is still on a level to support somewhat reasonable brain activity 😉
Anyhow, one of the outcomes of the number of strange mental stages I went through was the idea of a series of blogposts on architectural or technological approaches that are widely regarded as “good security practice” but may – when looked at with a bit more of scrutiny – turn out to be based on what I’d call “outdated threat models”.
