I’ve been at Black Hat Vegas last week and in the following I’ll shortly discuss some talks I’ve attended and which I found interesting.
Gabriele Fisher & Luke Valenta: Monsters in the Middleboxes. Building Tools for Detecting HTTPS Interception
This talk was about identifying if inbound HTTPS traffic reaching a server had been intercepted by a middlebox (or its software equivalent which is usually called “middleware”, a prominent example being the Lenovo Superfish piece a few years ago) on its path.
Such interception may happen for various reasons (see here why it might be generally considered a bad idea), among others
- in enterprise space in order to inspect traffic for malware (not least given that nowadays quite some malware uses Let’s Encrypt certificates).
- for surveillance purposes, e.g. see the recent discussion of the Kazakh government’s mandate that all users in the country have to install a specific certificate.
To find out if traffic had been intercepted the two researchers used a quite simple approach. As a prerequisite they built a database of fingerprints of different types of client components performing the Client Hello stage of the TLS handshake. During an actual (HTTPS) connection setup this can be compared with the HTTP/browser fingerprint of the respective session. Once there’s a mismatch (e.g. the TLS handshake indicates OpenSSL being used on the client side while the HTTP fingerprint points to Chrome) the session is presumably intercepted.
They’ve created two additional contributions:
- a tool called MITMEngine (GitHub repo here) to detect intercepted traffic.
- a public dashboard called MALCOLM displaying related statistics from their vantage point(s).
Looking at the latter it turns out there are some interesting stats as for the client OSs being intercepted, for example see this one:
(fetched 08/10/2019 at 12:00p EST, but iirc the numbers shown during the talk were pretty much the same).
Alas they did not discuss what the potential reasons for these numbers might be (I doubt they reflect the overall numbers of Internet endpoints connecting to Cloudflare based systems). I was tempted to ask this during the Q&A after the talk but the first person at one of the mic lines was, you know, that person asking a strange, somewhat unrelated question together with a bit of their own speech (don’t be that guy, please. yes, I deliberately used the male-centric personal pronoun here) so I didn’t have the opportunity. Still this was an overall quite interesting talk.
Slides here, “classic paper” from NDSS 17 here (plus its video).
===
Oliver Matula & Frank Block: APIC’s Adventures in Wonderland
This was given by two researchers from ERNW that has a rich history of discussing vulnerabilities in Cisco gear (e.g. see BHUS 2017 on Autonomic Networking, BHUS 2014 on EnergyWise, BHEU 2012 on Cisco VoIP, BHEU 2010 on Cisco WLAN stuff, also this paper on extracting keys from an AP).
Background of this year’s talk being that they were facing Cisco ACI during some customer security assessments, and not much (public) vulnerability research on the stuff was available at the time. Hence they decided to purchase some hardware, to build a lab and to get their hands dirty in order to find out on their own. I’m glad to hear that organizations exist which implement this approach… ;-).
In the end of the day overall six CVEs were assigned, together with their related security advisories (1,2,3,4,5,6). The talk was centered around four main vectors:
- Remote Code Execution on Leaf Switches over IPv6 via Local SSH Server
- Cisco Nexus 9000 Series Fabric Switches ACI Mode Fabric Infrastructure VLAN Unauthorized Access
Vulnerability - Cisco Nexus 9000 Series Fabric Switches Application Centric Infrastructure Mode Link Layer Discovery Protocol Buffer Overflow Vulnerability
- Cisco Application Policy Infrastructure Controller REST API Privilege Escalation Vulnerability
Obviously, given my IPv6 background, I found the first one particularly interesting. It turned out that on the leaf switches an SSH server was running on TCP port 1026, both for IPv4 and IPv6. Access to this port was restricted by ip[6]tables rules which essentially prohibited accessing it at all, with one small exception: inbound connections coming from source port 1025 and (only) over IPv6 were allowed. We can only speculate about the reasons for this, but in any case it shows that in real life the security stance of systems might differ between IPv4 and IPv6, in situations where one might not expect this…
In another section of their talk they discussed the role of LLDP (Link Layer Discovery Protocol) within the ACI architecture. It is mainly used for signaling purposes in the so-called infrastructure VLAN which in turn has interesting security implications, namely:
- an attacker can get access to that VLAN (which is essentially a management VLAN) incl. all services offered there by sending spoofed LLDP packets (afaik LLDP doesn’t have any authentication features).
- LLDP itself is a quite complex protocol so there might be implementation bugs. Actually they showed that there was a buffer overflow in the LLDP daemon on the involved Nexus 9K running a specific software version, and how to exploit it, together with a nice live demo. In general LLDP has a long history of bugs: back in 2008 Daniel Mende and I gave a talk at ShmooCon which also covered LLDP (video here ;-), discussion of the protocol incl. some demo crashing a Cisco 3560 with fuzzed LLDP packets starts at 23:03).
Slides of the Cisco ACI talk here, whitepaper here (for those interested list of all ERNW whitepapers here), scripts & PoC code for the LLDP RCE vuln here.
===
Altaf Shaik & Ravishankar “Ravi” Borgaonkor: New Vulnerabilities in 5G Networks
Clearly I wanted to see this one, not least given Ravi and Altaf are regular participants & speakers at the Troopers TelcoSecDay. Ravi even gave a talk on Femtocells at the very first TSD in 2012. Unfortunately he couldn’t be in Vegas for private reasons, but Altaf did a great job.
First he noted that, while 5G brings several enhancements in the space of security and privacy, the advent of additional features also introduces new vulnerabilities. In particular they’ve identified three main attack classes which they called:
- Identification attacks
- Bidding down attacks
- Battery draining attacks
The reason for those (potential attacks) mainly laying in so-called capabilities which are exchanged between the UE (e.g. a phone) and the eNodeB during the radio resource control (RRC) procedure. This exchange happens before the over-the-air (OTA) security kicks in, hence it’s unencrypted, allowing for passive (sniffing) and active (MiTM) attacks.
They build a test lab and analyzed the (capability-related) behavior of quite a few devices:
It turned out that individual manufacturers and models could be identified with a high degree accuracy, based on the capabilities they send.
It was also possible to perform specific attacks in the course of which the network was tricked into accepting modified (downgraded) capabilities for an UE:
I later had a discussion with Sergey Bratus on securing telco protocol stacks (in particular 5G), and looking at these capabilities (Altaf mentioned several hundreds of them exist) I’m somewhat sceptical if this is a reasonable goal…
Ravi just wrote a blog post with some additional information.
Slides of the talk here, whitepaper here, their main paper here (ACM access required).
===
Guillaume Tessier: Mobile Interconnect Threats. How Next-Gen Products May be Already Outdated
Guillaume had given a related talk (stemming from the same internal efforts at Orange where he has a security role) at the Troopers19 TSD but I couldn’t see that one (the TSD happened on the same day as the NGI IPv6 Security Track…).
SS7 is still one of the main protocols in the telco world (one of the reasons why we had developed ss7MAPer a while ago) but it’s an *old*, complex protocol suite developed with a “walled garden” (or at least a “communicate with trustworthy parties only” setting) in mind. This in turn might not exactly describe today’s world’s players in the telco space 😉 – hence it’s a common approach (also recommended by the GSMA) that operators filter inbound SS7 messages coming from an interconnect (“where telcos meet”, for roaming scenarios, like a GRX). The devices used for this are commonly called “SS7 Firewalls”. Guillaume and his team evaluated the usefulness/actual capabilities of several products in the space (not mentioned in detail in his BH talk) and they identified several classes of vulnerabilities, namely
- bypassing security functions by means of fragmentation, both on the IP and on the SCTP layer
- several DoS scenarios
- several RCE scenarios, some of which were based on quite classic buffer overflows.
If these look very 90s to you then, yes, that’s part of the point to be made here ;-).
Later the day Guillaume and I had a good technical chat over a coffee; it seems he and his team are doing quite interesting research and they are undertaking some serious security efforts (which hasn’t always been the case in the operator world).
Slides of the talk here.
===
I’ve seen some more talks ;-), so there might be a follow-up to this post. Stay tuned…
Everybody have a great week,
Enno