[HackerNotes Ep.98] Team 82 Sharon Brizinov - The Live Hacking Polymath

Hacker TLDR;

• Firmware Extraction Techniques for OT/IoT Devices: One of the key steps to pwn OT/IoT devices is obtaining the firmware. Here's how you can do it:

  Firmware Acquisition Methods:

  • Download from Vendor Websites: Some vendors let you download firmware directly. Also, check developer portals and communities; they might have what you need.

  • Dealing with Encrypted Firmware: Encrypted firmware can be a pain. Look for "transition" firmware versions where the vendor switched from unencrypted to encrypted firmware. These versions often include the encryption keys and algorithms needed to decrypt newer firmware.

• Hardware Hacking Techniques

  • Desoldering Flash Chips: Physically remove the flash memory chip from the device and read the firmware using a chip reader.

  • Using JTAG Interfaces: Connect to the device's JTAG interface to dump the firmware directly from RAM.

  • Gaining Root Access: Exploit vendor-provided debug interfaces like SSH or Telnet, or find vulnerabilities to achieve remote code execution (often requires prior authentication).

• Emulating Devices Without Physical Hardware: Sometimes hardware comes with its own problems and friction (see above) so virtualisation can be the way to go. Some tips for this:

  • Use QEMU and Unicorn: Emulate the device's firmware to set up a dynamic debugging environment without needing the physical device. This lets you analyze and test the firmware efficiently.

  Overcome Emulation Challenges:

  • Patch Binaries to Bypass Checks: Modify firmware binaries to skip hardware-specific checks not present in the emulator. This might involve altering code to always return successful responses for hardware calls.

  • Provide Required Binaries and Libraries: Supply the necessary files, directories, and libraries the firmware expects. Create dummy files or simulate hardware responses to satisfy firmware requirements. Tools like Ghidra or IDA Pro will be your go-to.

• Quick Scripting for Competitions like Pwn2Own: Use the Pwntools library to quickly develop exploits and interact with targets. It offers handy functions for networking, binary exploitation, and payload crafting.

• Intercepting Device-to-Cloud Communications: This can be a very rich attack surface, some tools and tips for this:

  • Mitmproxy: An interactive HTTPS proxy for intercepting and modifying traffic.

  • Mitmrouter: Perform MiTM attacks at the router level, useful for device traffic.

  • Certmitm: Test certificate validation vulnerabilities to bypass SSL pinning.

• We’ve got SO much more content below but we ran out of space here. Make sure to check it out!

Remote workforces are a ticking time bomb!
Hybrid and remote work expand your company's surface area of attack beyond corporate firewall boundaries. Employees’ personal computers introduce shadow IT, and home networks with default settings are easy targets, compounded by public Wi-Fi vulnerabilities.
You need to develop a strategy to stay secure while remote employees work across untrusted networks.
To learn how you can secure your company's workforce, get a free copy of the latest ThreatLocker® whitepaper on how to secure remote workforces.

Learn More About the ThreatLocker® Cyber Health Report Here

Hacker Profile - Sharon Brizinov

Well, Sharon has ticked off just about every single hacking ‘to do’ one can ever think of. He’s got over 200 CVEs, Pwn2Own awards, LHE awards and just about everything else that comes with it. You can check out his stacked, and quite frankly impressive, portfolio here: https://sharonbrizinov.com/

Sharon's current role dives deep into the world of SCADA (Supervisory Control and Data Acquisition), OT (Operational Technology), and IoT (Internet of Things) protocols and device reverse engineering.

If you're unsure what these devices and protocols are used for, think of them as the behind-the-scenes systems that control everything from industrial machinery to critical infrastructure like power grids and water treatment facilities.

One of the coolest things he’s dabbled in is researching PMSs (no, not that kind). We’re talking about Property Management Systems, the backbone of modern buildings. These systems handle everything remotely: HVAC, water, door controls, you name it. Basically, they’re like the master control panel of a building.

And imagine this, he figured out how to abuse it to shut down all the lifts in the building. Like, lifts stopped, doors locked, and panic mode activated. Proper Judge Dredd vibes.

When exploring this line of research, every physical command on one of these devices - whether it’s to operate a lift, open or close a valve for oil or gas, or perform another action - has an equivalent command in the network world to execute the task remotely.

Naturally, after doing a ton of SCADA and IoT reversing, the next step was a no-brainer: Pwn2Own. Sharon and his team took their shot at the competition, tackling SCADA, IoT, and ICS challenges. And guess what? They’ve crushed it, and have a tonne of war stories, CVEs and awards to show for it.

Let’s jump in.

Pwn2Own & LHEs

Pwn2Own is a bit different from traditional live hacking events. With teams having a 3-month run-up time, Sharon and his team take an interesting approach when selecting a target for their chosen category.

Once the targets have dropped, they begin OSINT on each device. They’re looking for how many CVEs, prior research, documentation, attack surface, how many times it was targeted before, how easy to pull the firmware - anything that could shed light on how easy (or hard) the device would be to attack.

Equally, speed is a key factor in Pwn2Own. A lot of these devices are using custom protocols which little/no tooling exists for, so being able to quickly script something together to read/fuzz/debug is a necessity. For this, Python and Bash are the two go-tos.

Note: The Pwntools package in Python comes in useful for this. It contains a bunch of easy-to-use functions for converting, connecting and communicating in various contexts.

The topic of LHEs v Pwn2Own came up previously on the episode with Sinsynolgy, but as someone who participates in both LHEs and Pwn2Own Sharon can appreciate the differences in the events; the pros and cons.

If you’ve ever wondered whether to try and give LHEs or Pwn2Own a go, he broke down some of the aspects of both:

LHE (Live Hacking Events)

What H1 Does Right:

• Show and tell is awesome.

• Lots of activities to strengthen community connections (hackers - H1 - vendors).

• Amazing locations & venues.

What H1 Does Wrong:

• Sometimes H1 triagers unjustifiably disqualify bugs (mainly due to large volume).

• Difficult to solve disagreements.

Pwn2Own

What ZDI Does Right:

• Accurate and relevant targets.

• Decent bounty prices.

• Enough prep time.

• Great team: understands security in-depth.

• Defends researchers and pushes vendors to fix bugs.

• Live exploit demonstrations are super cool.

• The bar is very high: pre-auth exploit or STFU (aka Proof of Concept).

What ZDI Does Wrong:

• Not so much wrong per se, but the nature of the beast: duping can result in a 50% reduction on payouts, and it's RCE or GTFO.

LHE vs. Pwn2Own: Which is More Fun?

• Both are fun and different:

  • Pwn2Own: In-depth binary exploitation/CTF style with long prep and satisfying results (if the pointer/ROP lands in the right place 😊).

  • H1 LHE: Lighter, focused on web/recon, and more fun in terms of friends and community.

Sharon pointed out something interesting about Pwn2Own competitions: when you report a bug there, the ZDI (Zero Day Initiative) actually goes to bat for you. If the vendor tries to downplay the bug or argue about its severity, ZDI will step in and fight to make sure your findings are recognized. That’s a massive contrast to the bug bounty world, where you’re often stuck battling with triagers just to prove the bug is valid or get it reopened after a mis-close.

That said, you can’t directly compare the two directly. Pwn2Own is all about pre-auth RCE or nothing; it’s the heavyweight division of vuln discovery. On the other hand, Live Hacking Events (LHEs) are more flexible, covering a broader range of vulnerability categories, which makes them a different kind of challenge.

It makes sense. Pwn2Own is hosted by ZDI who aim to buy exploits to supplement their EDR and research solutions. LHEs, on the other hand, are an opportunity for companies to thoroughly assess their exploitable attack surface by some of the world’s elite hackers.

OT/IoT Hacking Methodology

When starting to hack IoT devices, the most important initial goal is to obtain the firmware. While some vendors conveniently list their firmware on their websites, more often than not, alternative methods are required to acquire it. Firmware acts as the foundation for understanding and manipulating the device, so having access to it is crucial.

However, you may encounter firmware that is encrypted. In such cases, a practical approach is to examine historical firmware packages, going through them one by one to see if an unencrypted version ever existed.

Look specifically for a "transition" firmware - the version where the vendor switched from unencrypted to encrypted firmware. This transition firmware often contains the encryption key and algorithm, as the device needs instructions on how and what to encrypt moving forward.

By extracting this information from the transition firmware, you can unlock and decrypt the latest encrypted firmware. Once you have access to the firmware, the next significant milestone is setting up a dynamic debugger on the device. The method for achieving this varies from device to device.

Sometimes, you might not have physical access to the device at all. In such scenarios, emulating the device using tools like QEMU and Unicorn is going to be the route to take. Sharon, for instance, often emulates devices to remove friction without needing the physical hardware.

Emulating the device can initially feel like a game of cat and mouse. The virtualized binary may attempt to access partitions or libraries at specific locations that don't exist in your emulated environment. To address this, you might need to place the required binaries in the correct directories or, if certain functionalities aren't needed for your research, patch the binary to bypass these checks altogether.

This could involve modifying the binary to always return a specific value (it could be as simple as returning True or False) to simulate successful checks. Tools such as Ghidra or IDA Pro will be the go-to when performing this type of work.

When it comes to actually getting to the first step of grabbing the firmware, there are a few ways to go about this:

1. Downloading from the Vendor’s Website: This is the easiest method if the firmware is readily available. If the firmware is encrypted, you can refer back to earlier, unencrypted versions to extract encryption parameters.

2. Utilizing Google Dorking: If only the latest encrypted firmware is available, dorking for historic firmware versions can uncover the older unencrypted version, or the patch for the crypto containing the private key and so on.

3. Hardware Hacking Techniques:

   • Desoldering the Flash Chip: Physically removing the flash memory chip from the device to read the firmware directly.

   • Using JTAG Interfaces: Connecting to the device's JTAG (Joint Test Action Group) interface to dump the firmware from RAM.

   • Gaining Root Access:

     • Via vendor-provided debug interfaces like SSH or Telnet.

     • Through exploiting vulnerabilities to achieve remote code execution (often requiring prior authentication).

These hardware methods aren’t really considered “attacks” but are more like standard tools of the trade for serious hardware analysis and firmware extraction. Depending on the method, you’ll need varying levels of skill and equipment, but these techniques can be a lifesaver when there’s no other way to access the firmware.

To sum it up, getting and analyzing firmware isn’t exactly a quick process. It can lead you down rabbit holes of reverse engineering, emulation, and even hardware manipulation. If you tackle it step by step: start by acquiring the firmware, decrypt it if required, and configure a solid dynamic debugging environment, you’ll be ready to dive in and start hunting.

If you want to dive into this a bit more, we have some pretty good writeups from other IoT specialists; Matt Brown and Sinsynology - you can check them out here:

• https://blog.criticalthinkingpodcast.io/p/bounty-landscape-iot-matt-brown

• https://blog.criticalthinkingpodcast.io/p/hackernotes-ep80-pwn2own-vs-h1-live-hacking-event-feat-sinsinology

IoT Communications to Cloud

Most IOT devices communicate with the cloud in one form or another. Exactly how this is done varies, but at some point, they need a ‘call home’ method whether it’s for authentication, over-the-air (OTA) updates or general usability.

This type of communication provides a great attack surface; one example - if there’s functionality to talk to or communicate with your device, could you perhaps talk to another device if the auth is broken?

These types of bugs do crop up and they are critical; if you find one, you essentially have a pivot into someone else’s network entirely. A lot of focus is often put around securing the user → cloud communications, but as the devs assume no one is going to see the device → cloud communications, it can be a good patch to hack on.

MiTM’ing the cloud

When it comes to getting hands-on with the traffic, Sharon’s personal preference is to use his own router that he can fully control. With the device connected, he attempts a downgrade attack to downgrade the traffic to HTTP instead of HTTP/S.

It’s worth mentioning this can be done in quite a few ways; you can inject your own CA into the device, you can patch the binary to replace the existing CA with your own and so on. A bunch of tools exist to help with the process too.

This is by no means an extensive list, but it at least gives you somewhere to get started:

• Mitmproxy.org: A free and open-source interactive HTTPS proxy.

• Mitmrouter: For, as the name suggests, performing MiTM attacks

• Certmitm: A one-stop shop for testing certificate validation vulnerabilities

If you’re lucky, the device might even have a configuration option to switch between HTTP and HTTPS for its cloud communications. That little setting can make your job significantly easier when analyzing traffic.

When the device is emulated, your flexibility skyrockets. For example, when the device tries to resolve the host it’s calling home to, you can step in with your own DNS server and resolve to your own IP. Essentially, you trick the device into thinking your machine is the cloud server it’s supposed to communicate with.

From there, you can perform SSL termination, giving you full visibility into the communication as the device chats with your fake “cloud.” It’s a clever way to position yourself right in the middle of the conversation.

An interesting attack surface when you’re going down this route is the device’s IPv6 interfaces. These are often overlooked or forgotten during setup, especially since they rely on a different IP tables configuration than IPv4. This oversight can create an opportunity for exploitation.

For example, while the IPv4 interface might be properly secured, the IPv6 interface could be wide open, exposing services that should only be accessible from the LAN to the WAN interface. This misconfiguration could allow attackers to access a range of unintended attack surfaces, giving you a potential foothold for further exploitation.

Always check those IPv6 interfaces as they might just be the weak link you’re looking for.

Device identifiers

With IOT devices, vendors need a means of tracking devices. This usually means devices come with a unique identifier which is then associated with a user or an account. This usually comes in the form of a token, a serial, a MAC address or a combination of any of the latter.

In some cases, these device identifiers aren’t particularly secure or strong. This means it’s entirely possible to guess or brute force these values. So, what happens if you’re able to associate a device identifier that doesn’t belong to you, with your own account?

This scenario has some implications for how the cloud communicates with the device. This will essentially allow you to perform device cross-account-takeover.

Let’s say a device uses a serial and a Mac for its identifier, which is quite common. These two identifiers are essentially used for the device authentication to the cloud.

The first 3 bytes (24 bits) of a MAC address are reserved for the manufacturer identifier, known as the OUI (Organizationally Unique Identifier). These bytes are assigned to manufacturers by the IEEE, and they define the specific vendor or company that created the network interface hardware.

Since a MAC address is 6 bytes (48 bits) in total, this leaves the remaining 3 bytes (24 bits) for the unique device identifier assigned by the manufacturer. This means the space required to brute force and result in mass device takeover, is only 24 bits which is a very plausible attack vector.

Tip: eBay and YouTube unboxing videos can provide you with a means of retrieving a valid Mac and serial number for a given device 😅

Of course, not all devices are this easy to exploit. Some manufacturers step up their game by implementing more secure methods for generating identifiers. For example, they might use an OTP (One-Time Programmable) fuse, embed a private key, or rely on a hardware characteristic to derive the identifier. These approaches are far more robust because they’re tied directly to the hardware itself, making them nearly impossible to extract without physical access to the device.

In those cases, the attacker is out of luck unless they can physically get their hands on the hardware.

Approaching Bug Bounty

When Sharon hits a target, he goes after some pretty niche and interesting attack surfaces (having competed in an LHE with him, I saw this first-hand) and he dropped a few interesting ones on the pod:

Database-to-Host Escapes

Modern databases are beasts of complexity. They’re not just storing data anymore, they’re juggling features like load balancing, redundancy, sharding, backups, and connection pooling. All of this additional functionality DBs now have to offer is great, but it creates a sprawling attack surface.

If you can gain even partial control over a database, it opens the door to some seriously interesting possibilities. By leveraging these features, it’s possible to pivot from the database to the underlying host. For example, you could exploit misconfigured backup routines, abuse sharding mechanisms, or target native debugging tools to escape the database sandbox. The attack vectors might be niche, but the rewards can be huge if you manage to pull it off.

External Scanning: Non-HTTP Services

While HTTP-based services are often the focus of bug bounty hunters, there’s a wealth of attack surface in non-HTTP services. If you’ve ever done some port scanning on a target or poked around tools like Shodan or Censys, you’ve likely seen a ton of services pop up that don’t rely on HTTP. These could include anything from FTP servers to database interfaces, mail servers, or custom protocols.

What’s great about these services is that they’re often less focused on by other hunters. Focusing on them can lead to big opportunities, as they might expose vulnerable functionality or configurations that haven’t been fully explored.

It’s a reminder that sometimes stepping off the beaten path can yield great results.

Documentation tracking

With Sharon’s focus on exotic and underexplored attack surfaces, he takes a proactive and automated approach to tracking potential vulnerabilities. He uses a documentation tracker to stay updated on new releases, updates, and services. In bug bounty, this can give you quite the edge.

What He Tracks:

• Product Pages: Any updates to official documentation or product descriptions can reveal new features or configurations that might be exploitable.

• GitHub Repositories: Watching repositories for commits, pull requests, and changelogs can highlight interesting code changes or security fixes.

• Release Notes & Patch Notes: These are a goldmine for hints about what’s been fixed (or what’s still broken) and where to direct your focus.

How It’s Automated:

Automation plays a big part in this. Some of the automation is used to:

1. Scrape data from the sources mentioned above (product pages, repos, release notes).

2. Compare the newly scraped data to the last known version.

3. diff to highlight any changes, such as:

   • New features or services.

   • Updates to existing functionality.

   • Security-related changes or bug fixes.

4. Flag anything new and potentially interesting for further investigation.

reCaptcha bypass

For some POCs, Sharon needs 100s or even 1000’s of accounts. If you’ve ever created an account, you’ve probably hit a Captcha at one point or another which makes the process longer and more painful (by design).

So, what do you do when you need to create accounts at scale? Using services such as 2catpcha.com can bypass a few of them. To add to this, if Google’s reCaptcha v3 is used, some simple GUI automation using tools like Ui.Vision can go a long way.

A key takeaway for me is realizing just how much attack surface I likely overlook without even thinking about it. Since so few people focus on these areas, investing the effort to get past the initial hurdles would probably be well worth it.

TL;DR: Don’t ignore exotic or non-HTTP attack surfaces, they’re packed with potential.

If you wonder where and how he’s capable of doing all of this, here’s a gem straight from the show notes:

“My "secret" is that I read A LOT of work done by others and try to replicate. I built a small utility that grabs all the interesting research and I spend at least an hour every day reading and replicating some of it: link - (great research groups to follow - synacktiv, talos, devcore, Team82 ;) )”

It might be a solid habit to take away and start implementing.

And that’s a wrap. Sharon is clearly a seasoned and well-versed hacker; the episode was packed with golden nuggets of advice. Definitely one to revisit.

Till next time!
As always, keep hacking!