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”.