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.
Back on track as for one of our favorite rant subjects: desktop security. This stuff, commonly called the “LNK vulnerability”, has gained quite some momentum in the last days, including the release of a Metasploit module and a temporary raise of SANS Internet Storm Center‘s Infocon level to yellow (it’s back on green in the interim).
CVE-2010-2568 has been assigned and some technical details can be found here and here.
To give you a rough idea how this piece works, here’s a quote from the US-CERT advisory:
Interesting research from Stuart Schechter et.al. here.
They evaluated the effect that the removal or modification of online banking sites’ security features had on the users’ behavior (as for entering or withholding their passwords). Maybe for some of you not too surprising it turned out that the vast majority of users entered their passwords even if obviously alarming clues were present on the websites.
This, again, shows how important it is to understand how users behave, what their motives and incentives are and how to build environments that help them acting securely. This even more applies to corporate space. At times, bringing an industrial/organizational psychologist in might be a much better investment than writing yet-another-ignored-piece-of-policy.
Some days ago my old friend Pete Herzog from ISECOM posted a blog entry titled “Hackers May Be Giants with Sharp Teeth” here which – along with some quite insightful reflections on the way kids perceive “bad people” – contains his usual rant on (the uselessness of) risk assessment.
Given that this debate (whether taking a risk-based infosec approach is a wise thing or not) is a constant element of our – Pete’s and mine – long lasting relationship I somehow feel enticed to respond 😉
This is the first post of a – potential – series of rants on ubiquitous pieces of crap (security-wise), bothering pretty much every ISO I know.
I’m talking about “common desktop applications” and today’s topic is going to be the beloved Adobe Flash Player. Some of you who had the opportunity (or imposition 😉 to listen to one my talks covering “modern enterprise security space” (e.g. this one) might remember me saying sth like “If a fairy godmother turned up and asked me for three things to get rid of in order to enhance overall corporate information security in a sustainable way, my answers would be…” and then giving Adobe Flash as the first mention. (before you ask: amongst the other candidates are Apple Quicktime, Windows GDI and “Javascript in Acrobat Reader”).
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”.