Wow, what a whirlwind! I can’t believe that Black Hat USA went by in such a flash and not only that, it’s now firmly in the rearview mirror! Let’s take a look at my big takeaways from this year’s event and what I’ve learned.

The Probely Booth

The main focus for my time this year was to be present on the Probely booth throughout the Black Hat event. 

After the recent announcement that Security Headers would be joining forces with Probely, we had some dedicated space to celebrate that on the wall of the booth! Alongside that, I was there to meet and take questions from a whole range of people including new and prospective customers, along with conducting live Security Headers scans at the booth and giving out information and advice to help people improve their score. We recently hit the milestone of conducting 250,000,000 scans on Security Headers, and we conducted hundreds more whilst at Black Hat!

If you’d like to take 2 seconds to conduct a free scan right now, you should head over to the Security Headers website.

The Briefings

Admittedly, I did have more briefings that I intended to watch in person, but the jet lag got to me a little on my first day and the booth was just so busy throughout that I ended up not wanting to cut conversations or demos short to go and watch them! If you found yourself in a similar position to me, check your emails for the “On-Demand Experience” and you can go and watch anything that you missed at the time.

As a self-confessed encryption geek, there were two particular briefings that stood out to me and they were:

A SSLippery Slope: Unraveling the Hidden Dangers of Certificate Misuse Bill Demirkapi - Security Engineer Microsoft Security Response Center

mTLS: When Certificate Authentication is Done Wrong Michael Stepankin - Security Researcher GitHub

The first talk, by Bill Demirkapi, looked at the fundamental differences between a Domain Validation certificate, used for server authentication in TLS connections for HTTPS web browsing, and Code Signing certificates, used for ensuring the integrity of software. From a technical standpoint, there is really no difference between these two certificates. They’re both x.509 certificates that conform with the same standard, they have the same layout and even the fields of data they contain are largely the same. Where they differ greatly is their intended usage, and this is controlled by a field known as the Extended Key Usage field, or EKU. 

When a certificate is issued, the organisation that issues it, known as the Certificate Authority, will specify the EKU and it will be written into the certificate itself. The idea here is that you can then only use that certificate for its intended purpose, it makes total sense! This is where things go a little wrong, though. Of course, you should check that you are using certificates for their intended purpose, but what really matters is that any client you present that certificate to is also checking that you are using that certificate for its intended purpose. This is where Bill started to find issues and they were the focus of the briefing. It was discovered that there were implementations not checking for the proper EKU within a certificate used for code signing and instead of expecting a “valid certificate that can be used for code signing”, they were effectively just expecting “a valid certificate”, two very different things… Yikes!

The second talk, by Michael Stepankin, discovered implementation flaws in libraries supporting Mutual TLS (mTLS) that lead to authentication bypasses, privilege escalation, LDAP injection attacks and more! You may not be familiar with mTLS, and whilst it has become a little more popular recently due to the rise in Zero Trust adoption, I have to say that it still seems quite rare in my experience. Most people will be familiar with the idea of authentication via more traditional mechanisms like providing a password and being issued a cookie/JWT as a result. With mTLS, you’re using a client certificate to prove your identity instead of knowledge of a password. This approach does have some benefits and drawbacks compared to the traditional methods, of course, but it is a valid approach and I have seen it implemented to great benefit in large organisations.

The complexity introduced by mTLS is quite high when compared to something as ‘simple’ as checking a password matches, and this is where some of the issues arose. One example that stood out was handling the order in which a client presents their certificates, because a client can present more than one certificate during the TLS handshake and their order is important. Other problems surfaced in handling potentially unsafe data like that provided in the Subject field or other fields in the client certificate which were used before signature validation had taken place on the certificate which would have identified it as invalid due to being self-signed. Finally, Certificate Revocation had to make an appearance (of course!) and it was shown how Server-Side Request Forgery (SSRF) attacks could be launched by exploiting the use of the Authority Information Access (AIA) fields in client authentication certificates.

What struck me about both briefings after watching them is how it still seems like it can be quite easy to make mistakes when delving into the world of TLS and PKI. We looked at client-side implementation issues in the first talk, and server-side implementation issues in the second talk, giving us quite the range of problems and concerns, but it was great research from both Bill and Michael.

The People

Beyond great briefings and learning from those around me, events like Black Hat are also a great opportunity to make and develop connections. We had countless members of the security community stop by our booth for a selfie and some swag, we attended countless social events and even hosted our own!

As I’ve long been told in life, sometimes it’s who you know and not what you know that helps you get by, and I’ll never miss an opportunity to shake hands with the amazing people we have in our community. Maybe I’ll see you there next year?