Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The headline feature of the Bob dishwasher is the Bob Cassette is that it is an all-in-one detergent cartridge. The washing machine is an IoT device and will order new cartridges when they are needed. In order to make this financially viable, they have DRM on the detergent! The detergents are very expensive.

The cartridges had a chip in them they did not allow them to be refilled. After a specific amount of uses, they stopped working. This is truly annoying and needs to be worked around! Time to bypass DRM :)

The PCB was a simple 24C02 EEPROM with I2C lines. This chip only holds 256 bytes of data. It seemed that a special connector was needed, but after rummaging around the parts bin for a while a USB-A female socket connector fit perfectly. The author then had to insulate the metal case so it would not short on the PCB contacts, which is probably would have forgotten to do.

Dumping the chip had very little on it and made no sense. After doing another wash and dumping it again, a single byte had changed! This change had to be the amount of washes still left. After changing this value, a VERY large amount of washes came on screen. It turned out that the amount of washes left was stored as the value XOR with 0x50.

The author of the article now had the ability to add washes to their own cartridge. But what good does this do? Need to find a substitute for the liquids! In the end, a 98% price decrease was found solely based upon the price of the detergent.

To remove the DRM, the author made they own PCB that simply resets the counter when a button is pressed. You can even buy one yourself! This is a fun project with practical impacts that I enjoyed reading about.

AppCache in Chrome was used for offline browsers and speed. AppCache has been announced that is permanently removed in Chrome 85. Some sites will still have it until Chrome 93, which is the last dying breath of AppCache. Because of this deprecation (and previous security issues), the author took the time to audit the security of AppCache.

This functionality works by having a manifest file that lists URLs that the browser should cache for the application. With the file, there are a few sections: Cache, Network and Fallback. The Cache is for files being downloaded, the network is for allowlisted resources that need a connection to the server and the fallback is what to do is the resource is inaccessible. For more on this, visit Mozilla.

The author was particularly concerned with the cross-origin issues, in order to find a larger impact. This gives some more context to how the author was thinking about attacking the application.

AppCache does not allow for redirects, according to the specification. However, this creates an oracle: if a redirect occurs, then the user is unauthenticated; if a redirect does not occur, they are authenticated. This could be used on Facebook, for instance, to see if a user was logged in or not. However, this was limited to did a redirect occur?

By using the Network tag, they were able to find another part to the Oracle. The network field is an allowlist of URLs that are allowed to make a request from, even across domains. By using this allowlist, it was possible to deduce a stronger primitive: which user was logged into Facebook!

If the /me endpoint on Facebook redirected to /victim, then the proper username had been found. However, if this resulted in an error message, this was NOT in the allowlisted set of domains. Because the redirect was rejected, this helps us know if the user is logged in AND which user they are.

To make this attack even stronger, there are glob (wildcard - *) characters that can be used in the manifest feature. Damn, this means that a character by character brute force can happen, which is a big cross-site oracle to have. This can also be used based upon a prefix for the URL, which acts the same way for the attack.

To make this even more efficient, binary search can be used by having a specific amount of entries in the network tab in specific orientation. For instance, have the wildcard glob start out with [a-m] range with a*, b*...m*. If this works, cut the range in half. If it does not work, then use [n-z]. Continue this process until the character has been found.

Practically, this could be used for URLs and the parameters of the URLs. While looking at the Chrome issue tracker, they noticed that CSRF tokens were sometimes in the URL parameters. Using the attack described above, the CSRF tokens were able to be stolen!

The CSRF generation endpoint would trigger each time, invalidating the old token though. So, how can we get around this? By making the request with the force-cache flag for cache, the request would be made locally from the browser, instead of the endpoint. No, it's all a matter of time to get the CSRF token!

The first fix was to remove support for the glob functionality altogether. I could not find the code for the second issue so I'm unsure how this was fixed; potentially just removed the prefix functionality.

Radio-frequency identification (RFID) cards are common for scanning for identity reasons, such as school cards or at hospitals. RFID cards do not have power themselves; the reader gives the card the power. So, what happens if a user tears the card away from the reader? Writes may be unfinished, leaving the card in an insecure state!

In a previous article, the same authors discussed this as a whole. They discuss the theoretical nature of the attack with EEPROM writes, then move into RFID specific attacks.

The original article attacks the ATA5577C RFID writer. This device attempts to protect devices from read/write operations with a password. Using a few different techniques, this security protection was able to be bypassed! In particular, by tearing the RFID card AFTER a clearing operation, only SOME of the bits were flipped. Because of this, some of the security had been defeated.

The actual linked above looks into a Monotonic counter that is implemented by MIFARE Ultralight EV1. In this mode, there are three operations: increment count, read the count and read the validity flag. The goal of the attack is to bypass the anti-tearing feature in order to corrupt the counter.

The validity flag is presumably written at the same time as a new counter value is written. But, the slot containing the highest value is return for the counter value, as there are multiple slots. The flag determines which slot to take.

After doing some testing, the authors noticed that at the limit of a valid flag and reading the counter multiple times that the value being read would be different! But why? One of the bits could be weakly programmed, resulting in a different value being read at different points. If this weakly programmed bit is used in conjunction with a tearing event (corrupted tearing flag), this could cause trouble!

The attack works as follows:

• Have to have a weakly programmed bit at a power of 2. This is done by executing a value that will ROLE this over from 0x100. Hopefully, this will be 0x?00, where the ? is the weakly programmed bit.
• Increment by a value of 0. At the end of the write operation, we tear this off in order to get the second slot corrupted.
• Now, the second slot needs to be recovered. Because the second slot is corrupted and part of the first slot is weakly programmed, we hope for a read of 0x000 instead of 0x100. When we increment by 0, this operation happens.
• With both values stable, the attack has reset

The EEPROM volatility via weakly programmed bits, along with a logic bug allowed for this to be possible. The proxmark now has the capability to perform this attack automatically, which is pretty awesome! This is a super interesting piece of research that is hard to pull of but impactful if it works.

WE.LOCK is a smart home access solution provider that manufactures and sells smart locks. WE.LOCK smart locks can be unlocked using a fingerprint, access codes, RFID tags, a smartphone app via Bluetooth (BLE) or the physical key supplied with a lock.

The smartphone app went CRAZY on the obfuscation. However, obfuscation is security by obscurity and will always lose to a determined attacker. The mobile app packs with Jiagu and encrypts the dex files. Additionally, the web traffic itself is encrypted using Triple DES.

Some mistakes were made though: there is no stopping on the dynamic instrumentation. Hence, the Triple DES key can be easily stolen using something like Frida (as it is hardcoded). Frida could likely be scripted to dump the decrypted dex files out of memory as well. Additionally, the app uses HTTP instead of HTTPs for communication.

The communication (although some of the content is encrypted) does not do any sort of authentication! The only parameter that determines a user is a phone number. Yikes! This means that if you know somebody's phone number, you can essentially become the user of the API.

The API gets a password that will unlock the device when paired via BLE. Because we can become any user by simply knowing the phone number, we can still the password and open the lock. Pwned!

This is a classic case of misused security. Encryption means nothing is you use a static key; the important thing was to limit who can access what by having something like an access key for the device.

Grav is a CMS. It uses a stack with Twig, Symfony and Doctrine with an administration dashboard that allows managing the whole website (structure, pages, static resources, etc.). It has a focus on flat content, which includes Markdown and other easy to write in formats.

The author dug through the code and noticed that one piece of functionality named process.twig. This means that it will apply a Twig rendering pass on the content before serving the page. The rendering step is not sandboxed, at all.

In the Twig ecosystem, this means that any tag, filter, method and properties can be invoked during the rendering step. PHP functions are not mapped into Twig templates and must be explicitly declared. From previous research James Kettle showed on to register PHP functions from Twig.

A simple template like {{ system("id") }} will easily pop a shell after the function has been redeclared! Now, an author of content can pop a shell with template injection.

The second issue was a vulnerability in the permissions check for installing arbitrary extensions from the store. The issue was that user controlled data was used for part of an authorization check instead of only the user information itself! If the user had ANY administrative capabilities, this user provided data allowed them to bypass the mechanism in place. From there, they found a vulnerable package, installed it and popped a shell on the server.

Remediating the first vulnerability was complicated because they wanted to have backwards compatibility. So, they implemented a denylist of functions to prevent attacks. This is not ideal and I see a bypass coming the future. The second vulnerability was fixed by having a stricter authorization check.

Kubernetes (K8S) is a container orchestration platform used with containers such as Docker. Being able to escape containers is a big deal, as the main idea behind them is user isolation.

The author of this article was troubleshooting some container is K8S. Because this code required a bunch of writes to local disk, they added a tmpfs in order to make their life easier. Later on, they noticed that the mount point was mounted at /run instead of /var/run.

Because /var/run is a symlink to ../run the author had an interesting question: how does containerd/runc ensure that moutns are inside the container rootfs?

While diving into the code, there is a comment that mentioning there is a race condition here IF it is possible to swap the mount out with a symlink. Interesting! This bypasses the function securejoin.SecureJoinVFS check to ensure the mount is within the proper host.

The reason for this issue existing is that when Docker/runc was first crated, they did not consider untrusted container definitions as part of the threat model. With K8S, the mount file can be altered to be a symlink to somewhere else.

To trigger this vulnerability, we use the fact that we have control over the mount target but not the mount source. Because of this, we can mount a directory containing a symlink over a K8S volume. Then, on the next mount, use this as the source to give access to the root file system.

This race condition can be exploited by continually swapping between the directory name and the symlink with the tmpfs in a C binary. While running this code, start another container and hope that the name swap as done at the perfect time to bypass the security check but have the wrong location.

The exploit took a fantastic understanding of how Kubernetes and containerization work (a lot of which is over my head). Additionally, the POC took several different attempts to get right, which goes to show that exploitation is difficult even for the smartest people out there.

Overwolf is a software platform designed to help developers create extensions for video games, which are then offered to users through Overwolf’s App Store. These extensions help provide in-game services that are not normally possible in the game.

Overwolf uses Chromium Embedded Framework (CEF) in order to host the client application. Additionally, it has a custom URI scheme in order to make links and things for the application easy to navigate to.

The error page for an invalid extension ID is vulnerable to reflected XSS. The payload for the XSS is quite trivial, with nothing being escaped and data being directly added into the DOM. The example exploit provided by the article is overwolfstore://app/apps/<img src=x onerror=alert(document.location)>/4.

XSS within a website and a native application are two separate things. While browsers do a great job at isolating machine and application, native applications do not. Because of this, there is potential to escalate from XSS to code execution on the device. In order to do this, a CEF sandbox escape needs to be found.

In the application, the overwolf-extensions:// URI scheme was opening browsers via a direct call to CreateProcess. However, the application itself was calling the binary and using this to open up the browser. By replacing this parameter with another application, such as calc.exe, another application was ran! The issue was that no parameters could be provided to the binary.

Besides this functionality with the overwolf-extensions://, another piece of dangerous functionality was found: overwolf.io.writeFileContents. This gave access to an arbitrary file write primitive, allowing for bat files to be created.

Using the last two bugs together would allow for a file to be created (#2) and then an arbitrary binary to be executed (#1). This allowed for arbitrary code to be ran on the system from the context of the application. Because of the XSS earlier, this results in a one-click RCE.

The Apple AirTag is for keeping track of your lost things. By crowd sourcing this information, things can be found. This article is a tear-down of the Airtag.

By popping off the outer plastic cover, everything is easily accessible! When tearing this down, the antenna solder point is ripped. So, you'll need to resolder this for it to continue working. What goodies are under the cover?

The first thing of note that is that the SoC is vulnerable to a known attack that allows the debug mode to be turned on. This can be found at here.

The nRF chip has a NFC and Bluetooth antenna's present. Considering the use case of this device, that makes complete sense.

The SPI flash chip was easily accessible via a website. It has 10 pins but not all of them were accessible. The author used a dead-bug to connect to the proper chips on board. From there, they hooked up a Segger J-Link to talk to the chip.

With the J-Link hooked up, the firmware can be dumped from the device. Apple leaves a nice little easter egg for us to find :)

The author has a Github repo with a detailed breakdown of the device. Additionally, the StackSmashing Youtuber has a series of videos on reversing the firmware of the device and a hardware breakdown.

The extended Berkeley Packet Filter (eBPF) is a revolutionary technology that can run sandboxed programs in the Linux kernel without changing kernel source code or loading a kernel module. Because this code is ran in the kernel, finding a vulnerability in this can allow for kernel code execution.

The eBPF verifier added new functionality for 32-bit bound tracking. This restriction is added to call of the registers that it is taking care of and verifying. However, there is a bug in the tracking: the function uses known bounds on a 64-bit register to infer bounds for the register’s lower 32 bits.

This bounds check is not proper, which results in bad logic happening on unsigned values because of a logic bug. Instead of verifying that BOTH the maximum and minimum are within the bounds prior to setting the values, it only checks them one by one.

Using a bug in the eBPF, the common exploit method is to get an OOB read and OOB write. From there, compromising the kernel is considering a trivial task.

John Deere is the most popular brand for tractors and other big machinery used on farms. John Deere is a major technology company now as well. They have a developer portal in order to do interesting things with the data and machinery.

The first vulnerability was a username enumeration issue. When doing this, the author used found a list of the fortune 1000 companies to see who had made an account.

After playing with the APIs for a while, the author found an authorization issue that allowed for the queries of sensitive personal information about tractor owners. This is essentially all that was found, even though the article is incredibly long.

The author was asked to join a private bug bounty program that was created just for him. Because of this, and no public disclosure, the author declined the invitation and made the research public.