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!

VoIPmonitor is open source network packet sniffer with commercial frontend for SIP and our protocols. The authors of this find a vulnerability in this popular software.

The author used their open source tool sipvicious to fuzz the SIP protocol parsing. Initially they got no results. However, after turning on the live sniffer, they found a crash almost immediately.

The bug was a simple buffer overflow in a fixed size buffer by blindly adding the data from a header into the array. The REGISTER header had this vulnerability in it.

The make file of the project showed lots of binary protections. But, the actual release of the product had NONE of these turned on! So, the pwning of a simple buffer overflow was live :)

The exploit overwrites the RET address on the stack to point to a ROP gadget. This ROP gadget increases the value of RDI to point to the place of the overwritten packet, which has user controlled values! system takes in a single parameter. Once this is controlled, we can pop a shell!

This is confusing because LibC would be randomized with ASLR but they use a ROP gadget later to increase the value of RDI to an attacker controlled location. Regardless,the author could have referenced the PLT entry for system instead with ASLR on the system and not PIE.

Overall, I really liked this post and enjoy the content this company puts out. I love the logo of a man screaming into the phone; you know this is a group of hackers when you see that!

Microsoft Sharepoint is a product that integrates with the rest of the office suite, including Word. It is very common at the enterprise-level for Microsoft houses.

A replay attack is about taking a legitimate message and using it again. The idea is that the message is authorized for the one action but this does not prevent usage from an attacker once it has been seen.

Another attack is insecure deserialization. Within complicated applications, it is common to receive or process serialized objects. These objects can be code, integers or anything else. Sometimes, the process of deserializing this can lead to code execution.

Sharepoint had a deserialization in the code for specific non-user controlled objects. However, the serialized data is not directly controlled by an attacker. If we could trick the system to use our input for this state functionality, we would have easy code execution.

The session state and stored file information are stored in serialized formats. By abusing this fact, we may be able to trick Sharepoint to deserialize the stored file information as the session by changing an identifier.

The steps in the article are sort of confusing... but, the idea is we can trick the application to follow the insecure deserialization path for the session handling with the file functionality. By making this happen, we can get code execution with our user controlled data.

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.