CTO Observations from Hacker Summer Camp 2022

BSides LV / Black Hat 25 / DEF CON 30 (aka Hacker Summer Camp 2022) in Las Vegas is now in the rear-view mirror. In addition to news that continues to come out, especially around DEF CON, I wanted to highlight some sessions I attended across the three conferences and offer some perspectives. 

BSides Las Vegas is the smallest of the three conferences I attended during Summer Camp but provides a more casual type of vibe. 

Here are some talks/briefings/sessions that I found interesting:

Scaling the Security Researcher to Eliminate OSS Vulnerabilities Once and For All
(Jonathan Leitschuh, OSS Researcher, HUMAN Security and Patrick Way, Sr Software Engineer, Moderne)

This talk focused on solving the following questions:

1. How can someone efficiently scale themselves as a researcher to automatically submit pull requests (PRs) to vulnerable software packages?
2. How can the PRs that get submitted be automatically generated in the same language / style / syntax that the target project uses?

The idea here is that once you find a vulnerability in a project, chances are really good that you’ll find the same vulnerability in other projects. But how do you find those projects and, once you do, how do you automatically generate a PR that includes a fix that will get accepted/merged? This last point is important since, if you submit a PR that legitimately fixes a problem but doesn’t match the same naming convention/style/syntax as the project you’re submitting the PR to, it will likely get ignored. The speaker used sample vulnerabilities to illustrate the talk including: 

• Partial path traversal issues (by using unsanitized user input to construct file paths, allowing games like “../../../path” to be hijacked. 
• The well-known zip slip attack where someone uploads a .zip file to an application (that accepts .zip files) but doesn’t validate the pathnames in the zip file don’t contain relative paths like ../../ . 

Working with a company called Moderne, HUMAN made a tool called OpenRewrite which helped them submit a boatload of PRs and get them accepted upstream.

See You Later, Allocator!’: Updating Volatility’s Analysis of Modern Linux Memory Allocators
(Daniel A. Donze, LSU Applied Cybersecurity Lab)

In this session, the speaker discussed extending volatility (the memory dump analysis tool) to handle Linux SLUB-based allocators. Until recently, volatility couldn’t handle SLUBs, which are the new type of allocators being used by Linux. The speaker also outlined how SLUB analysis can be done via SLAB carving, which actually aligns with Deepfactor’s ability to do heap analysis in an application via libdf. 

After the smaller, more casual BSides, it was on to Black Hat. 

Sessions of interest:

Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling
(James Kettle, Director of Research, Portswigger)

This session on HTTP client-side desync was really interesting— about how someone can cause a desync on the client side (server-side desync has been known for a while) to fake out the server using a variety of protocol downgrades. This is done in a several different ways, sometimes using content length confusion, sometimes using timeouts, but the overall goal is to get the server to downgrade your connection after it has authenticated it (well, more like “accepted it”). This allows someone to easily create advanced SSRF attacks; the speaker was able to create a client-side desync worm and poison a bunch of Amazon shopping carts using this technique. The speaker also showed other examples of the same kind of attack against different products. The issues are all on the server side; fixes were detailed in this talk but generally involved upgrading server side components.

Return to Sender – Detecting Kernel Exploits with eBPF
(Guillaume Fournier, Senior Security Engineer, Datadog)

How can eBPF be used to detect if your kernel is actively being compromised? How do you use eBPF to detect kernel side exploits? To answer these questions, the speaker used an even-handed approach; the talk started with a disclaimer saying something along the lines of, “you probably don’t want to do it this way, but if you’re curious how you might try to do it this way, here’s how…”. Kudos to the presenter; the disclaimer was key to avoiding having most of the audience questioning everything said (since you can’t use two pieces of code [eBPF and kernel] at the same privilege level to try and out-maneuver each other; it just doesn’t work). 

Having said that, the speaker laid out an interesting approach that could be used to validate certain security constraints. For example, is a syscall coming from a legitimate syscall dispatcher, or has someone hollowed out a process and “rolling their own”? Or, for every syscall, verify that the kernel syscall dispatch table hasn’t been tampered with, etc. The speaker created a toolkit called KRIE to help with self-defense in these places, which is now available on GitHub.

(You can also check out our white paper Observing Application Behavior via API Interception where we review various API interception techniques including callbacks [with eBPF] and import table rewriting.)

Go With the Flow: Enforcing Program Behavior Through Syscall Sequences and Origins
(Claudio Canella, InfoSec PhD candidate at Graz University of Technology)

The thesis discussed in this session was about how they developed a technique that fingerprinted an application’s syscall pattern and sequence. This allowed a developer/security team person to enforce the same sequence (or detect drift) and enforce syscall origins. (It should be noted that syscall origin enforcement is something OpenBSD has done for a few years now, but this may be a new angle on it.) 

At DEF CON, you always find talks on a variety of subjects—not only software, but lock picking, car/automotive security, social engineering, voting machine security, and probably more than 100 other things on the periphery of hacking. DEF CON has an interesting registration system; no names or personal information are collected— you present payment at the door and are handed an electronic badge. You may choose to introduce yourself to fellow attendees as your real name, a hacker handle, or some made-up name. No photos are allowed inside the conference of any attendee (unless permission given).

DEF CON is arranged into talk tracks and “villages”; each of the many villages has a specific focus. For example, the voting machine village focused on voting machine security and had a few machines available to take apart and hack. The car hacking village had a Tesla and a Honda available for hacking via the CAN bus and other buses. The hardware hacking village had different SBCs (single board computers) and other things to hack on.

At DEF CON, you can also:

• Rent a virtual machine on the DEF CON network for a dollar, on a server housed inside a soda machine
• Inject yourself with an RFID tracker
• Participate in 100 CTFs (capture the flag hacking contests)
• Try and create the world’s best tinfoil hat (with an actual RF checker to see how well you block those nasty RF mind control waves)
• Wear safety goggles and gloves and use corrosive chemicals to try and destroy locks and tamper with “anti-tampering” package sealing tape
• Try and hack various kinds of avionics in different types of planes
• Get yourself on the “wall of sheep” if you connected to the DEF CON WiFi network and used any non-encrypted login, anywhere
• Hack an MRI or CAT scan machine

DEF CON has a cool badge culture; each badge is a wearable computer that does … something. It’s up to attendees to try and figure out what the badge does and complete the badge challenge. This year’s badge was a mini piano keyboard with a Raspberry Pi-style microcontroller that you could connect to other badges for games. If you played certain notes on the keyboard, you got instructions to “call Jenny” (at 9035768; the reader can figure out the hidden meaning there) at a phone located at a vendor booth. If you called Jenny, you were given further instructions on what to do with your badge, and from there it was several more steps to complete the challenge. Fun stuff. I approached the badge challenge from the hardware perspective; the badge attached as a umidi(4) device on my OpenBSD machine, and it allowed recording (sadly, no playback). The firmware on the badge could be extracted from the onboard flash for proper reverse engineering, but I forgot my SOIC-8 Pomona clip at home; fortunately a friend who was also attending said you could visit the soldering stations at the conference and solder a header on your badge if you wanted, and then extract the firmware (which we did). A true geekfest!

2022: A More Well-Attended Summer Camp

I thought it was a really good week, several notches above last year in terms of attendance, content, networking opportunities and overall energy. There’s always something to learn and it’s great to connect with the community to get new ideas. Sadly, I hear “DEF CON 31 is canceled” next year, so maybe it’s only going to be two conferences next time. Or maybe I’ll just head to the pool on the roof instead.