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:
According to
SANS NewsBites Vol. XII, Issue 53
recently published there’s a lack of 3rd party developer support for some
security features Microsoft introduced already years ago. We at ERNW have made
similar observations when performing security assessments of COTS [commercial
off-the-shelf] software. We therefore created a methodology, a
proof of concept tool
and a metric to test and to rate closed source software, where (amongst other
approaches) these security features are checked and their (non-) presence
contributes to an overall evaluation as for the trustworthiness of the
applications in question. The concept “How to rate the security in closed source
software” was presented to the public at Troopers10
and at Hack in the Box 2010 in Amsterdam.
The slides can be found
here.
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 😉
Yesterday we made our way to Vienna to participate and contribute to NinjaCon
(formerly known as PlumberCon, before Nintendo Inc. claimed their rights ;)).
After our arrival Oliver held a five hour workshop on
Penetration Testing and did the finishing
touches on his slides about
‘Attacking Cisco Enterprise WLANs‘, which
he will deliver later today together with Daniel. And last but not least Daniel
will be the Packet Master of PacketWars™ Vienna taking place in the evening.
I’m happy to announce that the presentations and a majority of the videos from
TROOPERS10 are finally available to you.
You’ll find the slides at the conference’s website
troopers.de, more precisely
here. Plenty of videos
were uploaded and are now ready for streaming at
viddler.com/TROOPERS. Enjoy!
Please excuse the long waiting time – this is a big point on our ‘improvements
for upcoming events’ list. Talking about improvements: If you have any
suggestions, criticism or even praise for past or upcoming events – let us know
in the comment section.
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.
