Technology is technology is technology. But is it really? One of the reasons why I fell in love with the topic of information security more than 25 years ago is that it allowed me to meander through knowledge areas that are dauntingly vast, but also immeasurably deep. I can roam on the surface and explore endlessly, but I can also dive off a cliff and end up spelunking a very narrow place that builds up very specific knowledge. Today we’ll explore that reality with some recent real life examples of why technology, and our understanding of its limitations, matters in making smart decisions about their use, their implementation, and how we rely on them.

To kick things off, there are a few things that most people hold to be true:

  • If you want to protect data from being readable on a stolen device, use Bitlocker.
  • Do not build your own cryptographic functions but rely on those available to you.
  • On hardware devices, secure boot ensures system integrity.

Just in the last week, we’ve seen a deluge of vulnerabilities in networking technology from vendors like Juniper, Fortinet, and Ivanti. All products we often take for granted and rely on to secure our organizations.  

In Bitlocker We Trust

Reference : https://www.youtube.com/watch?v=wTl4vEednkQ

In the above video we see Thomas Roth, a well-known German researcher extract a Bitlocker key from a recent device in under 50 seconds.

So yes, Bitlocker is great and so are Trusted Platform Modules. However, the implementation of Bitlocker really matters and not all TPMs are created equal.

In essence, when we rely on a TPM, we rely on the trust relation built between the TPM and the hardware it interacts with. If that trust relationship is intact, the TPM will release things like the Bitlocker key it is trusted with in clear text and an attacker can successfully sniff that key with very low cost hardware.

The best defense for organizations is to set Bitlocker with a PIN code. If that is not something you have done in your organization, you can find the necessary information to do that here: https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/configure?tabs=common.

In (Not so) Random Number Generators We Trust!

Reference: https://www.sjoerdlangkemper.nl/2024/01/17/mysql-mariadb-rand-random-number-generator/

This may be my favorite blog post from 2024 so far but that is mainly because I am a nerd for cryptographic stuff. Sjoerd takes us by the hand for a very detailed analysis of the RAND function in MySQL and MariaDB, which functions as as a Random Number Generator (RNG) and how it is not actually very random.

Now, RNGs range from “Cryptographically Secure” (CSRNGs, which are either theoretical or serve a very narrow use case) to “Pseudo” (PRNGs, the large majority). One example of such an RNG is CloudFlare’s implementation based on a wall of lava lamps (https://www.cloudflare.com/en-gb/learning/ssl/lava-lamp-encryption/). Another fairly public example that displays the importance of sound cryptographic practices was the DNSSEC Root Signing Ceremony (https://www.cloudflare.com/en-gb/dns/dnssec/root-signing-ceremony/). The same goes for the ZCash Ceremony (https://www.coinbureau.com/education/zcash-ceremony/). I’m providing these examples as an easy entry into the supporting practices without delving into the boring details.

In my activities as a penetration tester and a secure development consultant, one of the often returning recommendations was around not developing your own cryptographic implementations. In that light, leveraging MySQL/MariaDB’s available RAND function would be sound practice, providing that it is well understood. Well, Sjoerd helps us understand it and his analysis shows that the randomness provided by this PRNG is less than sufficient.

The natural question is “Why should I care?”. Well, today we are using cryptography for everything from authentication, over integrity, to complying with regulations such as GDPR. If your database containing personal data is based on MySQL or MariaDB and leverages its PRNG to encrypt or obfuscate that personal data, the data probably isn’t as protected as it should be.

In Hardware We Trust!

Reference: https://blog.xilokar.info/firmware-key-extraction-by-gaining-el3.html?s=09

Nowadays we often buy very sleekly designed hardware that we assume to be secure just by its fancy looks. Blue LEDs that flicker randomly do help to build trust between the user and the device.

In the above blogpost Xilokar, a French embedded software developer, delves into the process of extracting a firmware key from a fiber gateway. They beautifully combine a variety of techniques and approaches to reach their ultimate goal: extracting the firmware key and, with that, subverting the device’s secure boot process.

It isn’t exactly rocket science but it goes to show that subverting seemingly secure technology requires just a few things. Determination, a variety of skills, and time.

Conclusion.

I’m not sharing these examples to show that the world is burning, and we can’t ever even dream of securing our environments. This couldn’t be further from the truth. Most organizations want to rely on just a few vendors in the hopes that these partners have figured things out and can help us get a handle on the hard security problems. Unfortunately, there is only one thing that can help us and that’s a keen understanding of how we string technology together to support our business. By understanding its capabilities and, more importantly, its limitations we do gain deep insight into our gaps and the protection level we achieve.

At spotit, we aim to provide this understanding across all services we provide.