Given the CfP for Black Hat US in Vegas ends in a few days – and as apparently some people have already started to think about their TR18 submissions – I’ll quickly provide some loose recommendations on how to write a submission here. There’s quite some reasonable advice out there already (the BH CfP site lists this and this which you should both read as well) but some of you might find it useful to get (yet) another perspective. Continue reading “Some Quick Tips for Submitting a Talk to Black Hat or TROOPERS”Continue reading
A few months ago I had the opportunity to visit this year’s Black Hat in Las Vegas. Due to a few weeks of vacation following the conference here are my delayed 2 cents (part 1)
Abusing Bleeding Edge Web Standards For AppSec Glory – Bryant Zadegan & Ryan Lester (Slides)
Bryant and Ryan talked about new web standards which are already implemented in parts of the current browser jungle. Namely these standard were:Continue reading
Just a few days ago I had a blast again at this year’s Black Hat. Some of the talks were really worth listening to, so I wanted to point them out and give a short summary.
USING UNDOCUMENTED CPU BEHAVIOR TO SEE INTO KERNEL MODE AND BREAK KASLR IN THE PROCESS – Anders Fogh & Daniel Gruss
They had the last slot at the last day of Black Hat which resulted in a kind of empty room, but in my opinion it was an awesome talk and I even had the pleasure to meet these two guys at our ERNW dinner.
The talk was about a very weirdly documented Intel instruction which does not check for privileges or throw exceptions:Continue reading
I won’t be in Vegas for Black Hat this year as there’s a direct conflict with one of my kids’ birthdays, but I thought one or another reader might find it helpful to get some inspiration as for selecting the talks to catch (not least as there’s so many interesting ones). I hence decided to quickly write this post.Continue reading
While searching for some photos for my last blog post on Thinkst Canary I found a couple more from our recent trip to Black Hat USA and DEF CON, which I consider worth sharing. Nothing too technical, just some visual impressions and comments from my side. Let’s get it on!Continue reading
What is a Miner’s Canary?
Well, it’s a canary (these cute yellow songbirds some people have as a pet), and its main feature is that it dies before you will.
What the hack [pun intended]? And by the way… what has this to do with IT Security? Well… let me first quote Wikipedia on the birds:Continue reading
This year’s Black Hat US saw a number of quite interesting talks in the context of Windows or Active Directory Security. For those of you too lazy to search for themselves 😉 and for our own Windows/AD Sec team (who couldn’t send anyone to Vegas due to heavy project load) I’ve compiled a little list of those.Continue reading
Information security conferences are known to be attended because of several reasons. For some it’s the technical content, for others the networking potential and for some others simply meeting old friends. Pinpointing our motives is clearly a challenging task, but the following wrap-up ought to share our personal highlights of the week we spent visiting Black Hat USA 2014 and DEFCON 22 in Las Vegas.Continue reading
Last week we had the opportunity and pleasure to present some of our research results at BlackHat US 2014 (besides of meeting a lot of old friends and having a great researchers’ dinner).
Enno and Antonios gave their presentation on IDPS evasion by IPv6 Extension Headers, described here.
Ayhan and me presented our results of the security analysis of Cisco’s EnergyWise protocol. The protocol enables network-wide power monitoring and control (ie turning servers off or on, putting phones to standby — basically controlling the power state of all EnergyWise-enabled or PoE devices). The main problem (besides a DoS vulnerability we found in IOS, see official Cisco advisory) is its PSK-based authentication model, which enables an attacker to cause large-scale blackouts in data centers if the deployment is lacking certain controls (for example our good old favorite, segmentation…). There will be a longer blogpost/newsletter on this topic soon.
The material can be found here: Slides & tools
if you’re following this blog regularly or if you’ve ever attended an ERNW-led workshop which included an “architecture section” you will certainly remember the “Seven Sisters of Infrastructure Security” stuff (used for example in this post). These are a number of (well, more precisely, it’s seven ;-)) fundamental security principles which can be applied to any complex infrastructure, be that a network, a building, an airport or the like.
As part of our upcoming Black Hat and Troopers talks we will apply those principles to some VoIP networks we (security-) assessed and, given we won’t cover them in detail there, it might be helpful to perform a quick refresher of them, together with an initial application to VoIP deployments. Here we go; these are the “Seven Sisters of Infrastructure Security”:
- Access Control
- Entity Protection
- Secure Management
Now, let me discuss them in a bit more detail and put them into a VoIP context.
Access Control (“try to keep the threats out of the environment containing the assets to be protected”)
This should pretty much always be an early consideration as limiting access to “some complex infrastructure” obviously provides a first layer of defense and does so in a preventative way. Usually authentication plays a major role here. Please note that in computer networks the access control principle does not only encompass “access to the network [link]” (where unfortunately the most prevalent technology – Ethernet – does not include easy-to-use access control mechanisms. And, yes, I’m aware of 802.1X…) but can be applied to any kind of (“sub-level”) communication environment or exchange. Taking a “passive-interface” approach for routing protocols is a nice example here as this usually serves to prevent untrusted entities (“the access layer”) from participating in some critical protocol [exchange] at all.
In a VoIP scenario limiting who can participate in the various layers and communication exchanges, be it by authentication, be it by configuration of static communication peers for certain exchanges (yes, we know this might not scale and usually has a bad operational feasibility) would be an implementation of the access control principle.
Isolation (“separate some elements of the environment from others, based on attributes like protection need, threat potential or trust/worthiness”)
In computer networks this one is usually implemented by network segmentation (with different technologies like VLANs or VRFs and many others) and it’s still one of the most important infrastructure security principles. I mean, can you imagine an airport or corporate headquarters without areas of differing protection needs, different threat exposure or separate layers and means of access? [You can’t? So why do you think about virtualizing all your corporate computer systems on one big unified “corporate cloud”? ;-)]
Again, it should be noted that “traditional network segmentation” is only one variant. Using RFC 1918 (or ULA, for that matter) addresses in some parts of your network without NATing them at some point, or refraining from route distribution at some demarcation point constitute other examples.
In the VoIP world the main realization of the isolation principle is the commonly found approach of “voice vs. data VLAN[s]”.
Restriction (“once [as of the above principle] isolated parts get connected try to limit the interaction between those parts at the intersection point”)
This is the one most people think of when it comes to network security as this is what the most widely deployed network security control, that is firewalls, is supposed to do.
Two points should be noted here, from our perspective:
In some network security architecture documents phrases going like “the different segments are [to be] separated by firewalls” can be found. Which, well, is a misconception: usually a firewall connects networks (which would be isolated otherwise), it does not separate them. It may (try to) limit the traffic passing the intersection point but it still is a connection element.
And it should be noted that the restriction it applies (by filtering traffic) always has an operational price tag. Which is the one of the reasons why firewalls nowadays tend to fail so miserably when it comes to their actual security benefit…
Still it should be noted – again – that it has an operational price tag (key management and the like). Which – again – is the very reason why it sometimes fails so miserably when it comes to providing actual security…
This encompasses all measures intended to increase the security of individual elements. It’s not limited to simple hardening though, but includes all other “security [posture] quality assurance” things like pentesting or code reviews (when the element looked at is an application).
Adding a comment again I’d like to state that, in times of virtualization and vaporizing security layers (deploying shiny apps pretty much directly connecting customers to your ERP systems, by means of fancy webservices) this one might become more and more important. In the past many security architectures relied on layers of isolation & restriction and thereby skipped the hardening/quality assurance step (“we don’t have to harden this Solaris box as there’s a firewall in front of it”). As the talks’ case studies will show this one is a fundamental (and overlooked) one in many VoIP deployments.
Secure management usually can be broken down to:
- Restrict the endpoints allowed to establish management connections.
- Either use a trusted environment (network link) or use secure variants of mgmt. protocols instead of their less secure counterparts (SSH vs. Telnet, HTTPS vs. HTTP, SNMPv3 vs. community-based SNMP and the like).
- Require sufficient authentication (as for methods, authenticator [e.g. password] quality, personalized accounts etc.).
- Logging of security related events and potentially all management actions performed.
While this is (should be) an obvious security principle, daily assessment experience shows that failures/weaknesses in this space account for the majority of critical vulnerabilities when it comes to infrastructure security. This applies in particular to VoIP implementations (see the case studies for examples).
This is where logging (+ analysis), monitoring etc. come into play. We’d like to note that while this is a valid infrastructure security principle, its actual security benefit is often overestimated given the “detection/reaction” nature of this principle and its subsequent bad operational feasibility.
As the above application to VoIP shows, these fundamental security principles allow for tackling any type of “securing assets within a complex overall setting” by going through a simple (checklist-type) set of questions derived from them. These questions could look like
- Can we limit who’s taking part in some network, protocol, technology, communication act?
- Any need to isolate stuff due to different protection need, (threat) exposure or trust(worthiness)?
- What can be done, filtering-wise, on intersection points?
- Where to apply encryption in an operationally reasonable way?
- What about the security of the overall system’s main elements?
- How to manage the infrastructure elements in a secure way?
- How to provide visibility as for security-related stuff, with reasonable effort?
 As it requires the usually most scarce resource of an organization, that is humans and their brains. The part that can not be easily substituted by technology…
 In general preventative controls have a better cost/benefit ratio than detective or reactive ones. And this is still true in the “you’ll get owned anyway that’s why you should spend lots of resources on detective/reactive controls” marketing hype age…
 To provide another example from the routing protocol space: the “inter-operator trust and TCP-” based nature of BGP (as opposed to the “multicast and UDP-“based nature of other routing protocols) certainly is one of the most fundamental stability contributing properties of the current Internet.