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!

In Git, there is a concept known as pull requests. This request is asking to merge code into the repository. A change is labeled via a hash called a commit hash. A named commit hash is a branch.

The author was messing around with Github and noticed that it was possible to replace the base branch on a pull request with a commit hash. This gives off funky error messages in the console, but the Github API appears to accept it. It should be noted that this was only possible via editing the pull request; this was not possible to set initially.

Github Actions is a feature of Github that allows for automatic operations, such as running tests, for something happening to the repository. When running in this isolated ENV, it is common for secrets to be needed. However, how do you give access to secrets but not leak them on the automatic operations? Github Actions does not allow access to secrets upon a Pull Request being made.

Here is where this all comes together! Github Actions dictates who to trust based upon the value of the main branch. If the value of the current branch (or commit) is the same as the pull request, then the secrets are accessible. But, we can set the value of the main branch to be our commit hash! By doing so, we have tricked Github Actions to think this is a trusted user.

By using the commit hash, we are able to steal arbitrary Github Action secrets from repositories on Github. That's an incredibly powerful bug! The default GITHUB_TOKEN is now retrievable, giving the attacker the ability to write to the Github repo.

Input validation is important, even if it does not feel that way. With loads of functionality being added daily, people do not understand the small/weird quirks of other parts of the code.

TikTok is the new vine or the twitter for videos only. This is quite popular among the kids today!

The first vulnerability is an XSS bug via a deep link in the mobile app. It turns out that lots of mobile applications are embedded with lots of web pages! In order to test this bug as fast as possible, the author hooked the function with Frida to see what was going on. This was done because of concatenating of strings to run JS commands from part of the URL.

The second bug was another XSS in a Webview. This was possible because the link validation was only done on https/http links. So, it was trivial to add a link with a JavaScript URI for XSS.

From the second XSS, it was possible to run intents in the Android application. Using an intent called in TmaTestActivity in split_df_miniapp.apk, we can download arbitrary zip files in order to update the SDK!

This activity had a directory traversal vulnerability as well. Using the intent and the directory traversal, it is possible to overwrite system libraries to something malicious.

Finally, there was an intent to reload the application. Putting all of this together, the library will run at startup and a shell has been popped.

It is pretty amazing that a single click on a link could lead to compromise because of TikTok. And XSS on a webview leads to RCE!? That's something I'll be looking out for in the future.

The DSP (digital signal processing) driver is reached from untrusted applications on Samsung phones; this code is publicly available to review. For some reason, there is an ioctl that can be used to upload custom firmware! With code execution on inside the DSP, what can we do?

Once the firmware is uploaded, the location of a pointer (dsp_util_queue_enqueue) can be edited to point to an arbitrary location. However, only a minimal amount of data can be controlled that is written.

The uploaded DSP firmware file is not the only file loaded in the DSP address space. The DSP driver contains a custom ELF loader to load additional libraries and link them. Really, a custom loader!?

This custom loader does not vet the ELF very well. By using a larger size of one of the ELF fields, memory can be leaked from the kernel to break KASLR and a task struct (which holds many important Android vital fields).

As a mitigation, the DSP firmware functionality has been completely removed. On DayZeroSec, they hypothesized that this was leftover test functionality that should not have been there in the first place.

In vulnerability hunting, deep reversing can yield bugs quickly! Sometimes, it is about finding the weird functionality that has been overlooked.

Paper Mario and the Thousand Year Old Door (TTYD) is a popular gamecube video staring Mario. This video discusses how to warp to the end credits by using very specific inputs.

Events in TTYD are stored in a large queue (FIFO), with at most 256 events on a frame via a custom scripting language. Although this seems like a lot of space for a single frame and there is a validation on the size of the queue, there are ways to get around this. By pausing and hammering, the queue can be completely filled up. Eventually, this can lead to a buffer overflow on the event table which bleeds over into our important memory.

This was discovered by a crash via an invalid memory read in the event table. The idea of the attack is to point event data to a place that is controllable so that we control the custom scripting language. Using this, a credit warp can be performed.

There is a section of memory called the Effect heap. These are effects that happen in the game, such as dust particles flying up. When data is allocated, it tries to find the next free chunk in the list. Additionally, data that is written is NOT erased.

Because the location of this data is somewhat controlled and we control the data on it, this was an ideal place to write! The heap grooming is predictable and we can easily keep data around if it is at the end of the heap.

After a month of reverse engineering and documentation, they found out that Mario's X-position will be set to a specific location if a specific combination of actions occurs. The X-coordinate is a controllable value! So, using this as a pointer (I assume there is no ASLR) was a good option. This pointer can be a reference to the code to jump to.

Although, there is an issue with this... Mario's X-coordinate is stored as a floating point value. The memory address they originally wanted to reference was impossible to reach because of this.

However, there are two types of memory on the gamecube: cached and uncached memory. It was possible to reference the uncached memory location in order to specify the location, as this was a valid x-position. We have this set, but where to jump to exactly?

The devs set controller inputs to be at a specific part of memory. The values being stored range from 0x0 to 0xFF depending on how hard the button is being pressed! This gives us 6 bytes that can be fully controlled from controller inputs and 2 other ones that have limited values. These are copied 4 times for the 4 different controller slots.

With a proper reference to the fake event, upon opening a door with a full queue the magic occurs. The improper index, set with the buffer overflow, now references the fake event struct in the effects heap. This struct has a pointer to our code to get the end credits, which was written with Mario's X-coordinate. Finally, this pointer is dereferenced to jump to our code, written via the controller inputs on the extra controllers. Now, we're at the end credits.

This was an incredibly technical and detailed video. The amount of subtle tricks and sanity checks bypassed to make this work was truly incredible. The author of this article is quite a good speaker too!

In 2020 a critical vulnerability was discovered in the processing of DNS on Windows. Using this memory corruption bug, it was theorized that a malicious website could take over a computer just by using a few calls to DNS. This article is an explained POC on how this was actually weaponized.

The vulnerability is an integer overflow on a size allocation. The issue is that the size of the buffer is 16-bits and has a header size appended to it. So, by having a size of 0xFFFF and a header size of 0x2, the buffer size would underflow, resulting in a large buffer overflow.

Hitting this code was extremely complicated, from a DNS perspective though. In reality, DNS compression had to be used in order to trigger this bug, which I had no idea was a thing!

The awesome part of this article is the explanation of the exploitation method, mainly the heap grooming. WinDNS allocates its own memory pools of 0xA0, to prevent constant calls to the heap allocator. If the size is larger than 0xA0, then the regular Windows allocator is used. When the WinDNS buffered are freed, they are inserted into a singly linked list of chunks (LIFO) instead of going back to the native heap allocator.

With an integer underflow bug like this, we have created a wildcopy scenario. The memcpy will cause the code to crash, as we are writing outside of the bounds of the allocated heap after a while. In order to avoid this, the size of the overflown buffer had to be allocated at a specific size in order to have enough room to continue writing.

To keep the program from crashing because of overwritten data, the author allocates and frees a bunch of chunks. Now, when the data structures we do not want to corrupt are allocated, they will take these spots.

In order to leak memory, a structures size was overwritten with a larger value in order to induce an OOB read. Once this happens, the chunk above the overwritten chunk is freed, resulting in a pointer being inserted as part of the linked list. Because of the overwritten size from before, this will be leaked in the next request.

To break ASLR for program addresses, the author used the same trick from above to leak a program address. A structure called DNS_timeout was put into this place to leak library addresses and had a function pointer in it (to be used later).

The DNS libraries are compiled with control flow guard (CFG). So, getting code execution is not as simple as overwriting a function pointer, which would have been trivial to do via a function pointer used for leaks.

In order to bypass CFG, the author found the address of system. Then, they replaced the address of the function pointer with system. Here is the real kicker though: they controlled a parameter being passed in! So, they could control the string being passed to system in order to get RCE.

This is an awesome blog post into real world heap grooming and bypasses for Windows CFG.

The TP-Link is a RTOS router that runs MIPS. To setup a proper debugging environment, they attached to the UART connection. However, the inputs were completely ignored; this forced them to directly connect to the PCB trace on their device.

With an easy UART shell, they compiled gdbserver, strace and busybox in order to make testing much easier. Additionally, the device does not prevent firmware downgrade. This allowed them to use old firmware issues to pop a root shell to do further recon.

Once on the device, they did a significant amount of reversing to eventually find a server called Sync Server. Its goal is to synchronize data from the TDPServer and output this content to /tmp for other services to consume.

This service parsed all incoming mesh network devices to pass it into an array of structs with only a IP address and MAC address. This array was never expected to have more than 32 devices, but there is no bounds check! So, by adding more than 32 devices, a pointer overflow occurs that overwrites $fp and $ra pointers registers when this resumes execution.

These pointers (on the heap), have controlled data! Because the router has a RWX heap and the overwritten pointer is to the heap with controllable data, we can write shellcode.

The data being sent in the MAC address is only limited to 17 bytes and had character restrictions. The character restrictions were bypassable by unicode escaping the characters though. With the shellcode, the author jumps to the system PLT and starts another service that is not on by default but it riddled with vulns.

The reason a backdoor shell is not initially used is because of the restriction on the amount of allowed characters. So, they had to turn on a different service in order to exploit that instead. With control over the other service, a root shell is gained!

The authors submitted this to Pwn2Own and have included a nice POC at the end of the article. They claim that the TP-Link has many other vulnerabilities that are still waiting to be found! Overall, this was an awesome exploit with interesting bugs throughout.

VMWare ESXi is a bare-metal hypervisor. The component being attacked was the service location protocol (SLP). This is a network service that listens on TCP and UDP on default installations. This serice runs as root without authentication.

First, a use after free (UAF) exists while parsing an SLPMessage. The message pointer is added to a database but then freed with specific code paths from the call.

The second bug stems from improper use of strstr. This function is used in order to find a needle in a haystack (substring search). During the usage of it in VMWare on a URL, the string being parsed is NOT properly NULLed. Because of this, a memcpy later uses an improper size that leads to a buffer overflow.

To actually get code execution from this buffer overflow requires a lot more work though. It appears that no NULL bytes can be written using the current overflow, so the author wanted to upgrade the bug using the original bug.

The SLP uses a struct called SLPBuffer to handle events it sends and receives, where a sendbuf and a recvbuf are made for each socket connection. The goal is to overwrite a length value in this struct to eventually leak memory.

With the NULL limitation, it is not so simple to overwrite the size in the struct to leak memory; some heap feng shui must be done first on GLibC Malloc. The author puts in a hole just below the target chunk. Using the heap overflow, we change the size of the next chunk to overlap with our target chunk. Once this overlap occurs, we can now overwrite the target with NULLbytes and get leaks via the receiving buffer.

The author ran into an issue with calloc. Calloc is just like malloc except that the parameters are slightly different and all values are NULLed out during allocation. In order to get around this, the author sets the is_mmap chunk bit so that calloc does not overwrite with all 0s.

The author has a nice step-by-step for this happens. The only new thing is how a shell is popped. The author gets an mmap address to be leaked, which can be used to infer the location of LibC. With this, the curpos of a connection can be written to get an arbitrary write primitive. With this, overwrite the __free_hook to hijack the flow to start a ROP chain.

The analysis of the heap grooming here was really awesome. Sometimes, a buffer overflow without NULLbytes feels like a death sentence. But, proper heap feng shui can be used to create a leak and then a more powerful primitive. Additionally, the author references libraries that are open source that VMWare uses but did NOT fix. Reversing is hard but finding similar libraries can make life easier.

VOO is an internet provider in Belgian. They have created two different table modems: a Netgear and a Technicolor.

In order to understand the device, the hacker decided to reverse engineer the firmware. After connecting to a UART interface, a CM console popped open. Although this was not a root shell, there is a nice tool that can be used in order to dump the firmware by running commands in the CM console. It took a few tries to setup the configuration just right though.

After reverse engineering the recovered firmware, the author discovered that a weak pre-shared key (PSK) generation algorithm is used. By knowing the MAC (which is advertised), an attacker can connect to the network.

Additionally, several interfaces (web, ssh and SMB) all have default passwords that are likely never changed by its users. There is also a buffer overflow in several of the web API commands. Because there is a modem, there are likely no binary protections, making this easy to exploit.

A compromise has now occurred when in close range. But, can this be done remotely? Because the web admin portal is only reachable on the LAN, this did not seem possible. However, the author cooked up some good stuff!

By using a DNS rebinding attack on a malicious site, the localhost domain can be verified to be the correct one (bypass for the Same-Origin Policy). Using the default credentials or the weak PSK issue from before, we can connect to the device to exploit the buffer overflow to pop a shell.

Overall, this article is a little long for the amount of bugs (3ish) in it. But, the usage of the DNS rebinding and the crypto attack were interesting.

Cross-site request forgery (CSRF) is the drive-by attack of the web. By sending a request to a known website from a malicious website, the cookies will be used in the request. This can be used to force actions to occur that should NOT happen.

In order to help prevent this attack, browsers came up with the SameSite cookie flag. This flag prevents the sending of cookies across party lines. So, what do you mean by party lines? That is what this article is about!

There is a distinction between origin and site, which matters for the use of the cookie flag. Origin is defined as the same scheme (https), host (domain) and port (443). A site is domain in at the eTLD+1. The site is more confusing because there is a list of eTLDs that are used for this to determine the actual site.

For an attacker, this actually makes a large difference. The Same-Site cookie flag prevents a large class of cross-origin requests, but not all of them. The definition of site is quite important in this context.

Apport is the Ubuntu crash handler. When an application crashes Apport is executed by the kernel, reads information about the crashed process, and then creates a crash report that can be sent to Ubuntu developers.

When a process crashes in Linux a core file is created. A core file is the recorded working state of the memory of the process at a specific time. When Apport takes this over, it stores the core file in its own special location with its own parameter. Using a newer feature, the | prior to a user path can be used in order to allow for a userspace program to handle the crash, where the input is given via stdin to the program. Because Apport is running as root when debugging a user space process, it becomes a very attractive attack surface.

Apport is supposed to create a crash report at /var/crash and create a cordump in the directory of the crashed process. When writing a core dump, it takes the formatted stdin to create a coredump file. What if we could issue parsing issues with this? We may be able to control the content and the file write location.

The Apport process normally drops privileges in order to prevent easy privilege escalation. However, by changing the name of the process to contain \r, the parsing of the status file gets messed up, resulting in spoofable content! Now, we can set the UID and GUID to 0 in order to prevent the dropping of the privileges.

With the program running as root, can we cause any other parsing issues? Not quite yet. The program has a check to ensure that the current uid is for whoever created the process, which, because of setuid checks, fails to write the contents of the file. To bypass this check, we start with a setuid program, drop the privileges, then use the trick above. To control the name, we need to use a symlink to the setuid binary.

Apport is given 1 for a regular process and 2 for a setuid process. The setuid process has a core file dump size of 0, results in nothing being written. However, because this validation is based upon a PID, what would happen if we killed the process then replace it with a new setuid process? The final piece to the attack is PID recycling.

Even though the recycling is a good idea, Apport thought of this! They have a validation done by reading the /proc/ file system to ensure that the start time of the process and the old process are the same. However, using the original parsing bug again can be used to manipulate the file check locations.

To eventually get a shell, the authors eventually wrote to /etc/logrotate.d with their coredump. This configuration file change can be used to pop a shell because of the scripts being executed and the non-strict parsing.

This is a super awesome collection of bugs but all stems from bad parsing because of improper parsing of newlines and spaces. Parsing is hard to do properly.