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 check spelling Github Actions workflow is a spell checker on Github commits. This functionality happens whenever a PR is made on a repository. Afterwards, with advice on how to fix the mistake in updated in another PR.

When using the check spelling workflow, there is a file called advice.md that holds information about how to handle mistakes and on symlinked files themselves being spellchecked. Instead of having this be a regular file, the author made this into a symbolic link. By placing this symbolic link to /proc/self/environ, we can leak a secret and gain write privileges to the repository.

The GITHUB_TOKEN can be used to write to the repository silently. However, the token is invalidated as soon as the workflow finishes executing. But, this can be raced! By constantly pulling the comments of a PR that we have made programmatically, we can reliability get the token and make a request before anything has happened.

To fix this vulnerability, the symlinks will NOT be followed when anything goes into .git. The author of the bugs also mentions the scoping of the tokens being as small as possible.

Overall, interesting finding with a large amount of background and interesting scripts for the research. Symlinks are an awesome attack vector that is often overlooked.

The Iceland govenrment wanted to create e-licenses but was unsure on how to do so. The government decided to use the Apple Wallet API. The wallets (licenses) were distributed as PKPass files once they were done, which is just a wrapper around a signed ZIP file.

This file contained a few photos and some other interesting files. The pass.json contained a complete description of the license, such as the serial number and personal details. The manifest.json included a hash of all of the files and a signature uses for the manifest file. This is done by obtaining a key from Apple to be used on the wallet.

The idea behind the signature is that it should not be modifiable and the content safe. But, in practice, this is just not the case. Anybody can request a developer certificate from Apple and sign it with this. Additionally, the author found that NONE of the Android apps actually validated the signature. Crypto is good: just know how to use it!

Originally, a scanner for the wallets was discussed. But, this scanner for validation never came to be. As a result, forgery, to trick the naked eye of a human, is trivial. The simple look & feel is the only thing being validated for authenticity.

An easy attack would be simply taking a screenshot and modifying it with photoshop or something like this. The author shows an image that was modified in Snapchat that looks quite real with Donald Trumps picture. But, this is NOT in the wallet app, making it look suspicious.

Going a bit further though, there are multiple services on the Internet, and even mobile apps, allow you to design your own pass for Apple wallets. Using this, it would be trivial to make a replica of the license that we wanted statically or even programmatically via the provided APIs for the service.

Because of the many shortcoming of the license handling, teenagers and many others were found abusing this. As a result, a scanner was officially announced to be in the works.

Overall, the writeup is an interesting story of how a government attempted an e-license system and failed. It is really hard to write secure software!

The bug is in the memcached GET command of the MySQL plugin. The command supports multiple key-value pairs in a single query.

When using the GET command with the form @@containers.name then a few operations happen. First, the table_name is copied into a buffer. Before doing this operation, a validation is done to ensure that there is enough space. This is where the mistake is at.

An assert does the validation. Since assert is a macro that produces code only in debug builds but not in release builds, this leads to a buffer overflow that can be reached when running a release build. Boom!

The overflow and the values in the overflow are completely controllable by an attacker. A trigger for this can be seen below: get @@aaa @@aaa @@aaa ....

Each @@aaa is replaced with the table name during this operation. This bug is likely exploitable by itself but would require a memory leak in order to exploit. The patch simply removes the assert clauses and adds legit code to validate the size prior to the copy.

Validating bugs properly but messing up the error handling is not terribly uncommon. For instance, Boothole did the same thing. In the future, validating the error handling and the usage of asserts in C code is something I'm going to be looking for in the future!

The Wii Mini is a version of the Wii that is completely stripped down of the SD card, internet capabilities, GameCube functionality... it is only usable for Wii games offline. The author wanted to root the Wii Mini but with the little attack surface it was hard! After looking at the camera library, various games and a few other things, they landed on the bluetooth stack.

The Broadcom Bluetooth stack was open sourced years ago because it is used in a myriad of Android devices. The stack originally went by the name Bluedroid but goes by Floride now.

Part of the bluetooth stack includes the l2cap layer. This is similar to a TCP packet in the web stack, as it provides packet segmentation/reassembly, retransmission and a port-like interface called channels. When a connection is made, a channel is allocated for that service.

When passing back information about the channels in the l2cap packets, there is a bug. The channel structure (Channel Control Block - CCB) has a helper function for locating a CCB given a channel ID. The helper function validates that reserved IDs are not used. However, it does NOT have an upper bounds check! This leads to an out of bounds access on the CCB.

In order to exploit this, we needed to create a fake CCB structure. Luckily for us, this sits in the .bss section (which is static)! After doing manual code review, the author found a small buffer that handles the SDP client. This buffer is an array of 0x15 elements of type uint32_t. Even though our structure is much larger than this, the only things needed to make this structure work are in the beginning of the struct!

To make this exploitable though, it becomes much harder to actually do. Many of the final elements would have been nice to have control of, such as a function pointer. The author saw the channel state, a doubly linked list pointer and id fields.

Using the doubly linked list, we can create an arbitrary write primitive when unlinking the element! This does write in both directions but we can definitely make this work. To avoid crashing, we can set specific settings to hit only code that we want to hit. After some investigating, this was possible to do.

The author uses the arbitrary write with the doubly linked list to overwrite a function pointer with address to shellcode. Because the Wii has no ASLR or DEP, code execution from this point is trivial. Since the SDP client provides another big 1000 byte buffer in the bss section that is controllable, we send execution here. This is a secondary loader that fixes the state of the program and loads a USB loader as a secondary part of the exploit. Wii compromised!

Microsoft Exchange is used all over the place in big organizations and is extremely complex. As a result, this is starting to become a goldmind for bug hunters.

Microsoft Exchange creates two sites in IIS. The first site is for web access (OWA) and is known as the frontend. The frontend website is mostly a proxy to the backend. For all post-authentication requests, the front end’s main role is to repackage the requests and proxy them to corresponding endpoints on the Exchange backend site. The other site is known as the backend and handles the bulk of the actual interactions.

Exchange supports a feature called Delegated Authentication supporting cross-forest topologies. Because the frontend cannot perform the authentication in this situation, the request is forwarded to the backend. But, the backend only authenticates the request if the DelegatedAuthModule is loaded.

If the DelegatedAuthModule is not loaded then we have a problem. The frontend forwards the request to the backend for authentication. However, the backend has no idea that it needs to do auth on the SecurityToken header. What does this mean? A complete auth bypass!

This small authentication bypass can be used to change the configuration actions on an Exchange site for an arbitrary user. As a result, a copy of all emails can be seen by the attacker, almost undetected. Boom!

Location based security is really hard to do! Do you send the exact coordinates? Partial? City? All of this is particular to the application and is really easy to get wrong. This is a case where this was done wrong in Bumble.

Originally, Tinder showed distances of where people were located at (in terms of closeness) to them. The exact distance away was being sent to the other person then rounded down. Using triangulation, it was possible to find the exact location of where somebody was located. This was fixed by calculating the distance on the server within a mile.

To find the exact distance, you can use triangulation. This strategy involves moving at various points in the city to get different distances. Then, using three different distances you can calculate the exact location. A good picture is shown in the article about this.

On Bumble, the distance away from taken then rounded down to the nearest mile. Can this be abused? Considering that the location is technically an input to the system (if you spoof it) then we can!

In the Tinder exploit, we knew the exact distance; here, we do not have this same information. By finding a point where the location goes from one mile marker (3) to another (4) we can find the exact distance away again.

Using the strategy mentioned in the previous bullet point, an attacker can get multiple exact distances. As a result, we can use the previous method (triangulation) to find the exact location!

The article includes some interesting information about making this attack feasible. Most importantly, it was about automating the API requests from Bumble, which have signature validation on them.

Overall, great article with a fun story. Location based services are hard to implement! Whenever you come across sensitive information that is relative, it may be possible to find the original.

While playing laser tag, the author decided they were tired of the pay to win model. A group of college students were absolutely dominating because of this and something had to change! The author starts with that laser tag is not meant to be secure by design; this is just them reversing and figuring out how everything works.

The lasers of laser tag are just infrared lights transmitting the signal. The shot in laser tag is simply the signal being turned on. The technology is very similar to a TV remote! The red light coming out of the gun is an added feature; infrared light is not visible to the human eye. Normally, people wear vests. These vests, with the shiny lights, have multiple receivers. In comparison with the TV example, the vest is the TV and the gun is the remote.

There is a backend that sends data back to the gaming server. Who shot the gun? Is this a respond? Did somebody get hit? This may be bluetooth, Zigbee or something well.

The same code is constantly being used. As a result, a replay attack is possible to pwn this. Can we do better though? This could definitely be codified to kill everyone in sight and make an unstoppable player! The design considering are interesting for the context: small/concealable, high power, a UI to customize and data logging to see what was going on. Take it to the limit!

The author bought an infrared light that had 1 amp pulses. Additionally, shine is shaped in a 20 degree cone, which grows quickly. While using a 5 degree overlap, it created a ridiculous 70 degree location that just hit over and over again. To make this setup work with 5 LED at precise angles, the author 3D printed a case.

One of the important things to the author was having all commands run in the background and it was controllable via the phone. To connect to the device, the author created a hotspot and has a web server running on this. The physical commands were sent over pins with pigpio to the buck converter (voltage downgrader) and this went to the LEDs. It should be noted that IRRpy for sending infrared signals.

The flow for this working is interesting! First, shot a gun at the device and record it. Then, repeat again to validate we have got the right signal. Once we sure this is the signal, we can replay this when we want! Of course, this can be done multiple times for other fancier parts of the game, such as bombs or re-spawn points.

How did it work!? The normal gun can get about 2 shots off per second. The fake gun can get 20+ shots off per second. In practice, this absolutely killed everyone playing laser tag at the arena. To make matters worse, they realized they could clone the healing frequency as well; this would allow the team to be unstoppable and never die!

Interesting project and what happens when no one thinks about security. Although the tools take time to make, anything that is insecure will eventually be broken by somebody.

Everyone knows what a kindle is! Luckily for us, it has a wonderful attack vector: e-books. E-books are parsed in a multitude of file types with different parsers depending on the file type.

The architecture of the Kindle is tiered (wonderful diagram here). Of note, is the LIPC, which is an IPC library that links all of the Kindle components together. For instance, a HTML application (webkit) can use LIPC to interact with the native applications running.

The parsing starts with the Java functionality but gets passed on to native C libraries. As a result, the authors decided to focus on these libraries to hunt for memory corruption. How does Java interact with the library though?

The library functions have to be called somehow! By reversing the entry points in the Java file, they were apply to find the callable functions. In particular, openPDFDocumentFromLibrary, getCurrentPage and renderpageFromLibrary were used. These make excellent hooks for fuzzing!

The fuzzing setup for this did not pan out anything though. So, they decided to fuzz a specific object or stream filter or codecs from FoxIt technologies. They setup AFL in QEMU mode for the blackbox fuzzing the different stream types. Eventually, they found a bug.

The authors found an integer overflow on a oversized rectangle. When trying to expand the image to its new dimensions, there is no check that an overflow occurs. For example a result, an allocation of 0x100 is made when the actual size is 0x400000100.

The actual vulnerability occurs in the expand function, which is part of the refine functionality. By using the overflow to corrupt the refine data outside of our expected buffer for an arbitrary write primitive but only with XORed specific bits of memory.

The data and heap segments are RWX and ASLR is set to 1 on Linux; this means that the heap is not randomized! No further details are made on how a shell is popped within the process besides that it is trivial from here.

The next stage is to find a local privilege escalation bug to go from a user to root. After analyzing all of the permissions for this user, they found a flaw in the permissions. The database /var/local/appreg.db stores application registry information and it writable (without restrictions) to our user.

As a result, we can write an SQL query to change one of the command properties to a shell script that we own to become the root user. Game over :)

Defense in depth is important, even on modern day binaries. These protections need to be taken seriously in case of something like this. ASLR being set to 2 and PIE for the binary would have made this exploit much harder, if not impossible. Permissions are also important to check, even if they do not seem critical at the time.

IoT devices are notoriously insecure, even though things are getting better. As a result, people need to know if the claims by the company, such as privacy and security, are valid. Additionally, the only way to know a used device is clean is to root it yourself. So, being able to root the devices is important for functionality, security and claim validation. The author device gave a similar talk in 2018 about another roomba-like and discusses the state of rooting for these.

This new cleaner stepped up its game in security though! The Ubuntu version had an obfuscated root password, a custom ADB version, a watchdog enforcing copy protection and a firewall via IP tables to prevent malicious access (this only worked on IPv4 and not IPv6 though). Additionally, the firmware is not signed and each vacuum has its own encryption keys. Good steps up!

The author noticed an open UART connection on the device. However the root password was obfuscated. Dennis de-obfuscates the password then uses this to gain access, but never mentions how this was done. An additional way was setting up single user mode in UBoot while the device was starting up. At this point in time, both of these methods are not restricted.

Prior to the research, 3 different robots were unrootable. While looking for a new methods of rooting, the author noticed that all of the previous exploits had been removed and decided to reverse the PCB. The SOCs by Allwinner all have a FEL or flashing mode. By disabling the flash IC or pulling the FEL pin on the chip, we can boot our own OS on the system! Since FEL mode is burned into the BOOTRom of the device, it cannot be removed.

This approach sounds simple in theory. However, actually loading a proper version of the Linux kernel is complicated because NAND support is proprietary. The steps are as follows:

1. Extract kernel config from the RockRobo kernel. This was likely done by JTAG or from previous rooting attempts.
2. Create a file system with custom tools on it.
3. Compile a minimal kernel using the Nintendo NES Classic source code. This works because they both use the same chip for running.
4. Create custom UBoot version with the extracted Roborock configuration.
5. Trigger the FEL mode by shorting TPA17 to GND.
6. Load everything (UBoot, kernel and new FS) via USB.
7. Patch original OS with our own. Now, our OS should just run! :)

ADB uses special authentication with a challenge-response method. This is based upon a secret file and the mode is controlled via an adb.conf file. Luckily for us, this is stored on an unencrypted and unprotected partition. By using in-system programming (ISP) or replacing the chip entirely, the configuration or secret can be changed by us. Access to the device is now given!

The next step is disabling SELinux. Currently, access to /dev and the network is blocked. However, bind mounts and kill are usable. By replacing the client with our own bash script via a bind-mount and kill the currently running client, the watchdog will attempt to turn the client on, which is just our bash script. Now, SELinux is disabled.

Finally, we need to get persistent access. There is custom ELF signature verification running within the kernel, which means we cannot add custom code to the device. However, there is a backdoor that allows all files with the name librrafm.so to run. Now, we have rooted the vacuum cleaner! What else can we do? OPTEE, which uses ARM Trust Zone, will decrypt firmware updates if we ask nicely. With this, we can reverse the firmware to find other issues.

Another device that the author was looking at had a debug interface for UART, USB and easy access to the boot selection pin. Using the FEL, this device could also be rooted quite easily. The author mentions getting the firmware off of the device as well.

This device (Dreame) has a backdoor in it that is accessible from the cloud. The credentials for the server are publicly facing and this is used for development. The user has sudo privileges, to make matters worse. There is an open FTP server that downloads debug scripts that could be altered as well. These devices have predictable root passwords: it's base64(SHA1(serial number)). The password for debug firmwares is #share!#, making it trivial to break into these devices from the internet.

This talk was enough content for 5 talks! It's amazing how much information is crammed into the talk and how much this researcher got done. I hope to see more rooted vacuums in the future and to get better with hardware hacking, such as this hacker.

Most users will mainly know the video chat functionality, but there is also a quite full featured chat client included, with the ability to send images, create group chats, and many more. Within meetings, there’s of course audio and video, but also another way to chat, send files, share the screen, etc. We made a few premium accounts too, to make sure we saw as much as possible of the features.

When starting to reverse the application they found a large quantity of the libraries to be apart of an open source SDK. As a result, they decided to target these. Most of the Zoom code is written in C++, which has many nice foot-guns removed from C.

The authors noticed an interesting but benign issue when OpenSSL functions were being used. The size of the buffer being created for a base64 function should be 3/4 of the size. However, a buffer is created by shifting the size by 4. Although this is not a vulnerability, it is a code smell! Because of this code smell, they decided to look at all of the handling for OpenSSL integration.

The paid version of Zoom includes an Advanced Chat Encryption. When doing this, a handshake process takes place where some encryption is done. While decrypting, a fixed size buffer of 1024 bytes is used for AES However, there is no validation that the decryption result will fit into the buffer for AES, unlike RSA.

As a result, a heap-based buffer overflow could occur by sending a message that needed to be decrypted. This overflow is fairly ideal since we control the size and all of the bytes being sent over. But, exploiting bugs in real life is MUCH more complicated than in a CTF.

This article has extensive knowledge on how the Windows heap allocator works. I'll summarize a few points here:

• Windows has two different heaps: Segment Heap for very specific applications and NT Heap for everything else. In the NT heap, there are the front-end/Low-Fragmentation Heap and the back-end allocator.
• The back-end allocator is fully deterministic and functions like the GLibC malloc implementation. The LFH is used for sizes that are requested often and has a bit of randomization involved with it.
• If more than 17 blocks of a specific size range are allocated and still in use, then the LFH will start handling that specific size from then on.
• Each heap allocation (of less than 16 kB) has a header of eight bytes. The first four bytes are encoded, the next four are not. The encoding uses a XOR with a random key, which is used as a security measure against buffer overflows corrupting heap metadata.

Grooming the heap is just the right way took a significant amount of effort and testing to get properly. They needed to line up the proper object with a function pointer close enough to overwrite them in OpenSSL (no CFG on these functions). Additionally, they required an information leak to break ASLR.

For the information leak, they targeted a different part of the application. By finding a link that the authors could control, they would overwrite the URL that was being sent back for the connection. This overwrite would corrupt the NULLbyte, resulting in a bunch of extra data being sent. A little bit more groomer had to be done in order to put an OpenSSL object after our URL.

After hours upon hours of trying different TLS settings, orderings and things they got the leak to work! They found that using TLS renegotiation made the exploit much more stable by spraying the object we wanted to leak in the URL over and over again.

With the leak armed, they could go tackle the code execution problem. The class FileWrapperImpls had an insane amount of function pointers to overwrite. By lining this up next to our overflow, we can corrupt these values and jump to whatever we want!

To get code execution via a function pointer means we start with COP or call orientated programming. The next step is getting a stack pivot; but, we still need to know where to write to. The second problem was solved by sending a bunch of GIFs to file up the address space. If we fill up the address space we can make an educated guess of where the new stack will be at.

The COP chain starts by calling a gadget that allows us to control the RSP value afterwords. This gadget pushes value we control then pops it directly into RSP: how convenient! With control over the RSP, we can start a standard ROP chain.

The ROP chain calls VirtualProtect over the region where our GIF may be at after calling a different function to get the address of our region. Since we control all of the contents of the GIF, this is a perfect location to make executable. Finally, we have got arbitrary code execution!

Overall, this article has very good insights into competing in Pwn2Own. Additionally, the methodology and bugs found are amazing for learning how to make real exploits.