Building
by Enno Rey

News from Old Friends, Edition 2010/06/09

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

And, yes, I can already hear all the yelling “But we absolutely need Flash on our corporate desktops.”. Maybe that’s really really the case. Maybe not. I’ve fought that fight in many environments, and usually lost it. Kind-of been there, done that. I’d just like to point out that – from a security point of view – this is a risky thing.
On a personal level I still do not get why Flash is needed. I can certainly be regarded as a “typical executive user”, being online most parts of the day and performing all sorts of (what I think) “typical actions” like travel booking, online financial services etc. All this can be done with my 64-bit browser that just has no associated Flash player. Seems my mileage as for “corporate browser use” still varies from the one in many of those – “we absolutely need Flash on our corporate desktops” – organizations…
And even if your company’s marketing dept is powerful enough to ask for large scale deployment of that fancy technology (some of you certainly know the “We have our own Youtube channel” argument) I still have to understand why it’s needed on the desktops in the engineering or R+D departments. But oh well…

Still, all this ranting is a bit outside the intended scope of this post. Actually the trigger for the post was this advisory titled “Security Advisory for Flash Player, Adobe Reader and Acrobat” and released by Adobe some days ago.
Here’s a little quote from the summary:

“A critical vulnerability exists in the current versions of Flash Player […] for Windows, Macintosh, Linux and Solaris operating systems, and the authplay.dll component that ships with Adobe Reader and Acrobat v9.x for Windows, Macintosh and UNIX operating systems. This vulnerability […] could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild via limited, targeted attacks against Adobe Reader v9 on Windows.”

Oops, sorry, in fact the quote above was from this advisory, initially released on july 22, 2009.
The current one (from 06/04/2010) goes like this (as for the summary):

“A critical vulnerability exists in Adobe Flash Player 10.0.45.2 and earlier versions for Windows, Macintosh, Linux and Solaris operating systems, and the authplay.dll component that ships with Adobe Reader and Acrobat 9.x for Windows, Macintosh and UNIX operating systems. This vulnerability (CVE-2010-1297) could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild against both Adobe Flash Player, and Adobe Reader and Acrobat.”

Note the difference?
There’s practically none: same products affected, same component to blame, same workaround [deactivating authplay.dll], same “Adobe’s quality assurance element” [discovery of the stuff being exploited in the wild] responsible for public statement.
In short: SSDD.

Mitigation Approaches

Given I try to be a responsible citizen [and, for that matter, responsible security practitioner too ;-)] I’d like to discuss potential approaches as for the efficient mitigation of the risk of being attacked “actively in the wild” due to (not only) this vulnerability.
At ERNW, for many years we’ve been using sth we called “The small catechism of IT security” which was essentially a set of simple fundamental rules as for securing complex systems. This piece included, amongst others, these ones:

Minimal Machine.
Least Privilege.
Patching.

Following these lines some approaches come to mind and I’ll discuss some of those.

a) Do not run Flash at all. Yes, we had this discussion already. And, no: I do not live in a ivory tower. And I mainly consult to very large organizations.
Sure, this might be one of the fights you (as an ISO) just can’t win. But, heck, I still dare to post this on our very personal and ranty blog: Running Flash on corporate desktops is simply asking for trouble. Asking for trouble loudly. Very loudly.

It should be noted that, according to this, removing Adobe Flash (e.g. in the way described here) will not remove the instances of Flash Player that is installed with Adobe Reader 9 or other Adobe products.

There is always a lot of trade-offs in managing complex IT environments. There are business requirements – and, as we security folks know: business pretty much always wins (and this is fully ok, as security is not the most important thing in corporate life) -, there’s “cost considerations”, all sorts of politics and in the end of the day there’s our mission of getting the best possible security stance given all these considerations and trade-offs. Running vulnerable software to provide some business functions (while at the same time inducing the risk of getting owned) obviously is such a trade-off, and it’s a common one.

As for Flash one should just be aware that – in most environments – there’s only little business value of running it, but – in all environments – there’s quite some associated risk.

b) Do not run Flash embedded in PDFs (by deactivating authplay.dll as described in the advisories).

I think this is – security-wise – a very feasible approach (following that good ole security principle called “minimal machine”). Only problem might be that the stuff gets re-deployed/re-enabled next time you patch Adobe Reader. So operational processes might have to be adjusted to ensure it does not re-appear.
And, of course, this is an ugly one (deleting a dll), which might not be “aligned with your sw management and deployment processes” 😉
This document mentions that deleting another dll as well avoids the crashes when invoking a file with SWF code in it. Haven’t tested this though.

Btw: this is a preventative control. Whereas patching is a reactive one. Most probably I don’t have to tell any reader of this blog that preventative controls tend to have a better cost-impact ratio than reactive ones, do I? 😉

c) Patching. Hmm, unfortunately there is no patch as of today. And the stuff is “exploited in the wild” (Adobe, thank you! for letting us know, once more. What about just adding a checkbox somewhere in “Preferences” that allows to disable playing embedded SWF stuff at all?).
Furthermore patch cycles for Adobe products are quite long in most environments (due to the number of integration aspects and side effects).

So, dear reader who’s still sympathetic to patching (as for Adobe stuff): do not pass go, do not collect $200, but maybe re-read the last sentences of the two former points.

d) Use of an alternate PDF reader, like Foxit Reader. Looking at this I’m not sure if this is really better (security-wise) and most probably it’s not an option for most corporate environments anyway (for reasons outside the security realm).

e) Security measures/approaches from the “Least privilege” space like “running Adobe stuff on a low integrity level” (on Windows systems disposing of integrity levels, that are Win Vista or Windows 7). While this can certainly help and can be regarded as a nice preventative control, it has the big disadvantage that taking the route of “least privilege” usually has, that is added complexity and high operational cost… (which is, btw, why it practically never works out to a satisfactory degree).

f) Gateway-based controls. In a number of environments there will be quite some praying that “our malicious content protection saves us”. This may happen. or not. Taking the “detective/reactive way” (which is what most anti-malware controls do) has well-known weaknesses…
Sanitizing Flash (like Blitzableiter does) could be a much better approach. Hopefully technologies like this will gain some deployment in the near future.

And hopefully in the upcoming world of HTML5 we won’t see that high risk software piece called Flash player anymore (alas, experience tells there will be other similarly awful stuff. but that’s another story…)

have a great day,

Enno

Continue reading
Breaking
by Enno Rey

Some reflections on virtualization security, part 1

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 ;-)]

Out of some whim, I’d like to give a spontaneous response here (to the underlying question, which is: “is it a good idea to do this?”).

At first, for those of you who are working as ISOs, a word of warning. Some of you, dear readers, might recall the slide of my Day-Con3 keynote titled “Don’t go into fights you can’t win”.
[I’m just informed that those slides are not yet online. they will be soon… in the interim, to get an idea: the keynote’s title was “Tools of the Trade for Modern (C)ISOs” and it had a section “Communication & Tools” in it, with that mentioned slide].
This is one of the fights you (as an ISO) can’t win. Business/IT infrastructure/whoever_brought_this_on_the_table will. Get over it. The only thing you can do is “limit your losses” (more on this in second, or in another post).
Before, you are certainly eager to know: “now, what’s your answer to the question [good idea or not]?”.

I’m tempted to give a simple one here: “it’s all about risk [=> so perform risk analysis]”. This is the one we like to give in most situations (e.g. at conferences) when people expect a simple answer to a complex problem ;-).
However it’s not that easy here. In our daily practice, when calculating risk, we usually work with three parameters (each on a 1 [“very low”] to 5 [“very high” scale), that are: likelihood of some event (threat) occurring, vulnerability (environment disposes of, with regard to that event) and impact (if threat “successfully” happens).
Let’s assume the threat is “Compromise of [ESX] host, from attacker on guest”.
Looking at “our scenario” – that is “a number of DMZ systems is virtualized by means of VMware ESX” – the latter one (impact) might be the easiest one: let’s put in a “5” here. Under the assumption that at least one of the DMZ systems can get compromised by a skilled+motivated attacker at some point of time (if you would not expect this yourselves, why have you placed those systems in a DMZ then? 😉 … under that assumption, one might put in a “2” for the probability/likelihood. Furthermore _we_ think that, in the light of stuff like this  and the horrible security history VMware has for mostly all of their main products, it is fair to go with a “3” for the vulnerability.
This, in turn, gives a “2 * 3 *5 = 30” for the risk associated with the threat “Compromise of [ESX] host, from attacker on guest” (for a virtualized DMZ scenario, that is running guests with a high exposure to attacks).

In practically all environments performing risk analysis similar to the one described above (in some other post we might sometimes explain our approach – used by many other risk assessment practitioners as well – in more detail), a risk score of “30” would require some “risk treatment” other than “risk retention” (see ISO 27005 9.3 for our understanding of this term).
Still following the risk treatment options outlined in ISO 27005, there are left:

a) risk avoidance (staying away from the risk-inducing action at all). Well, this is probably not what the above mentioned “project initiator” will like to hear 😉 … and, remember: this is a fight you can’t win.

b) risk transfer (hmm… handing your DMZ systems over to some 3rd party to run them virtualized might actually not really decrease the risk of the threat “Compromise of [ESX] host, from attacker on guest” 😉

c) risk reduction. But… so how? There’s not many options or additional/mitigating controls you can bring into this picture. The most important technical recommendation to be given here is the one of binding a dedicated NIC to every virtualized system (you already hear them yelling “why can’t we bring more than ~ 14 systems on a physical platform?”, don’t you? 😉 ). Some minor, additional advise will be provided in another post, as will some discussion on the management side/aspects of “DMZ virtualization”. (notice how we’re cleverly trapping you into coming back here? 😉
So, if you are sent back and asked to “provide some mitigating controls”… you simply can’t. there’s not much that can be done. You’re mostly thrown back to that well-known (but not widely accepted) “instrument of security governance”, that is: trust.

In the end of the day you have to trust VMware, or not.
We don’t. We – for us – do not think that VMware ESX is a platform suited for “high secure isolation” (at least not at the moment).
The jury is still out on that one… but presumably you all know the truth, at your very inner self 😉
For completeness’ sake, here’s the general advice we give when we only have 60 seconds to answer the question “What do you think about the security aspects of moving systems to VMware ESX”. It’s split into “MUST” or (“DO NOT”) parts and “SHOULD” parts. See RFC 2119 for more on their meaning. Here we go:

1.) Assuming that you have a data/system/network classification scheme with four levels (like “1 = public” to “4 = strictly confidential/high secure”) you SHOULD NOT virtualize “level 4”. And think twice before virtualizing SOX relevant systems 😉
2.) If you still do this (virtualizing 4s), you MUST NOT mix those with other levels on the same physical platform.
3.) If you mix the other levels, then you SHOULD only mix two levels next to each other (2 & 3 or 1 & 2).
4.) DMZ systems SHOULD NOT be virtualized (on VMware ESX as of the current security state).
5.) If you still do this (virtualizing DMZ systems), you MUST NOT mix those with Non-DMZ systems.

For those of you who have already violated advice no. 4 but – reading this – settle back mumbling “at least we’re following advice no. 5″… wait, my friends, the same people forcing you before will soon knock at your door … and tell you about all those “significant cost savings” again… and again…

Continue reading
Breaking
by Enno Rey

New SSL/TLS MiTM Attacks

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

Obviously this _could_ have dramatic security impact on most SSL VPN deployments. Still, within the research community the impact on SSL VPNs seems unclear at the very moment.
On monday, Cisco issued a somewhat nebulous security advisory classifying the Cisco AnyConnect VPN Client as _not_ vulnerable (but quite some other products). OpenVPN disposes, for some time already, of a particular directive (tls-auth) which is regarded as an effective way to mitigate the vulnerabilities. Other vendors (e.g. Juniper) have not yet issued any statements or advisories at all (see also here for an overview of different vendors’ patch status).
This might be a good sign (“no problems there”), it might just be they’re still researching the pieces.

After discussing the problems with other researches we expect more concrete attack scenarios to emerge in the near future and we expect some of those future attacks to work against _some_ SSL VPN products as well. In case you have some SSL VPN technology in use pls contact your vendor _immediately_ asking for an official statement on this stuff.
Sorry for not having better advise for you right now. We do not want to spread FUD. On the other hand it might be a cautious approach to “expect the worst” in this case. There’s vast consensus amongst researchers that this _is a big thing_ that most people did not expect in this protocol. A first public break-in based on the vulnerabilities has already been reported.

Continue reading
Breaking
by Enno Rey

If they had used DLP…

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

Don’t get us wrong here. We’re well aware that these practices are not consistently followed in most organizations anyway. That’s part of human (and corporate) reality. And part of our daily challenge as infosec practitioners.

This incident just proves once more that quite some security problems have their origins in “inappropriate processes” which in turn are the results of “business needs”.
(all of which, of course, is a well-known platitude to you, dear reader ;-).

The problem of data leakage by file sharing apps is not new (e.g. see this paper), nor is the (at least our) criticism of DLP.

Did you notice how quiet it has become around DLP, recently? Even Rich Mogull – whom we still regard as _the authority_ on the subject – seems not to blog extensively about it anymore.
Possibly (hopefully), we can observe the silent death of another overhyped, unneeded “security technology”…

Continue reading
Breaking
by Enno Rey

Series on “Outdated Threat Models” – Part 1

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

This series is intended to be a quite provocative one but, hey, that’s what blogs are for: provide food for thought…

First part is a rant on “Multi-factor authentication”.

In practically all large organizations’ policies, sections mandating for MFA/2FA in different scenarios can be found (not always being formulated very precisely, but that’s another story). Common examples include “for remote access” – I’m going to tackle this one in a future post – or “for access to high value servers” [most organizations do not follow this one too consistently anyway, to say the least ;-)] or “for privileged access to infrastructure devices”.
Let’s think about the latter one for a second. What’s the rationale behind the mandate for 2FA here?
It’s, as so often, risk reduction. Remember that risk = likelihood * vulnerability * impact, and remember that quite frequently, for infosec professionals,  the “vulnerability factor” is the one to touch (as likelihood and impact might not be modifiable too much, depending on the threat in question and the environment).

At the time most organizations’ initial “information security policy” documents were written (at least 5-7 years ago), in many companies there were mostly large flat networks, password schemes for network devices were not aligned with “other corporate password schemes” and management access to devices often was performed via Telnet.
As “simple password authentication” (very understandably) was not regarded sufficiently vulnerability-reducing then, people saw a need for “a second layer of control”… which happened to be “another layer of authentication”… leading to the aforementioned policy mandate.

So, in the end of the day, here the demand for 2-factor auth is essentially a demand for “2 layers of control”.

Now, if – in the interim – there’s other layers of controls like “encrypted connections” [eliminating the threat of eavesdropping, but not the one of password bruteforcing] or “ACLs restricting which endpoints can connect at all” [very common practice in many networks nowadays and heavily reducing the vulnerability to password bruteforcing attacks], using those, combined with single-auth, might achieve the same level of vulnerability-reduction, thus same level of overall risk.
Which in turn would then make the need for 2FA (in this specific scenario) obsolete. Which shows that some security controls needed at some point of time might no more be reasonable once threat models have changed (e.g. once the threat of “eavesdropping on unencrypted mgmt traffic from a network segment populated by desktop computers” has mostly disappeared).

Still, you might ask: what’s so bad about this? Why does this “additional layer of authentication” hurt? Simple answer: added complexity and operational cost. Why do you think that 2-factor auth for network devices can _rarely_ be found in large carrier/service provider networks? For exactly these reasons… and those organizations have a _large_ interest in protecting the integrity of their network devices. Think about it…

Continue reading
Misc
by Enno Rey

Welcome to insinuator.net

Welcome to insinuator.net, the semi-official blog of ERNW GmbH.
You may ask: Why yet another infosec blog? Aren’t there already just too many around? Well, possibly. But that opulence is part of blogging in general, isn’t it? 😉
Given we are trying to contribute to “public space & opinion” in a number of ways anyway [e.g. by our presentations or our newsletter] it seemed just too logical – and we’ve been asked by various people as well – to add another element to global blogosphere. Voilà, here we go!
What can you, dear reader, expect? Of course all kinds of shameless self-references, maybe occasionally a little bit of insight or even wisdom (yes, you’re right: modesty is not amongst our key virtues, at times) and – hopefully – some entertainment.

Enjoy!

Continue reading