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!

This is a high value target, as a large amount of people use Office 365. Being able to compromise this at any company would be the dream for a nation-state actor.

Exchange Server exposes a number of web APIs as well as a powershell remoting interface for users and administrators. This looks like a good target for trying to find a command injection of some sorts.

There is an API that takes in a list of strings which are then executed in the CLI as a powershell command. If an attacker can control this data, then it is essentially game over.

It appears that reversing this was super easy; the code that the author has looks really nice! I assume this is because C# code can be easily decompiled into its original form.

Microsoft failed to patch this bug twice. This was because they attempted to use a denylist from the attackers first payload. The author was able to bypass the restrictions twice and got additional payouts from Microsoft. Denylists are extremely difficult to set properly.

YouTube (who is owned by Google) has the ability to use three settings on YouTube video publicity: Public (what is sounds like), Unlisted (not in search but can be found via a direct link) and Private (only my account has access).

The general idea of this attacker was trying to view Private videos on YouTube in some way. The author of the article was mostly hunting for insecure direct object reference (IDOR) bugs that allowed access to a private video.

From testing all of the YouTube endpoints of the, none of this worked. But, what about other services that would have access to the internals of YouTube? As stated above, YouTube is owned by Google.

It turns out that Google Ads can take in video Ids and use them on ads services! This seems like an interesting place to look for an IDOR.

After testing several of the YouTube video based APIs on, Google Ads the author tested the /GetThumbnails API. And it sends back a base64 encoded blob, which was a frame of the Private video!

After discovering this single frame IDOR, the author wrote a script to steal the entire video (frame by frame). Of course, because this was a thumbnail, no audio can be heard. Additionally, the video ID must be known.

I really enjoyed the cross service aspect of this attack. This is something that I will definitely need to consider in the future.

In the world of virtualization, there are two types: 1 & 2. Type 1 runs on bare metal (no OS in between hardware and hypervisor) essentially BEING the OS. Examples of type 1 are Xen, VMWare ESXi and Hyper-V. Type 2 runs on top of an OS, such as Virtual Box, VMware Workstation and others. A good picture to see the difference can be found here.

The vulnerability in this post discusses an issue found in the Type 1 hypervisor Xen.

The bug was discovered a NULL pointer dereference in an IRQ handler from the guest to the Xen host. The IRQ is a way for events to be handled by hypervisor. This can be triggered when an interrupt occurs for the IRQ to be handled AND the IRQ has just been freed.

At a minimum, triggering this bug can result in a DoS by taking down the hypervisor. At the worst, this IRQ position could be REUSED in another IRQ allocation. If this comes from a different physical device, the IRQ would have an entirely different structure, which could lead to a complete compromise of the hypervisor.

The vulnerability is a complete lack of input sanitization when going to kernel functions. This leads to a linear heap overflow, a TOCTOU race condition, an out of bounds read with a controlled index and an arbitrary add primitive. These are all very serious bugs where any one of them could take control of the process.

The heap overflow looks like a good primitive because we can overflow values at the end of the ION buffer allocation in kernel space. This is done by winning a race to change the size of the array AFTER the size of another value has been chosen. This OOB write has mostly complete control of the buffer.

The OOB addition can add a single value to any point. This is important because it may be possible to increment a pointer to an arbitrary value. This is done by setting an offset to find an array of address_vector structs. The offset has no bounds or alignment checks. This offset does have a constraint in order to perform the OOB write though.

The next section is rather instead. The author goes into HOW this could be exploited on iOS first, then dives into Android. The author hypothesizes the exploitation on iOS and references several CVEs.

The author chose to go with the arbitrary add primitive because the location of the data was next to kernel thread stacks! Using this, we could overwrite a size parameter for a syscall in memcpy in order to cause further memory corruption.

The next problem to solve was HOW to put a thread stack at this location? The main pain point is that on Linux, kernel memory is placed into a unpurged_vm_area and eventually placed back into the usable heap memory. In order to combat this issue, the author spammed a bunch of allocations of binders to create arbitrary sized mappings to flush the cache. Then, spammed a bunch of threads. With a little luck, the thread stack was aligned in the proper place for our overflow.

Something that I was not familiar with is blocking. Blocking is when the execution of a program stops then re-executes later on, after some criteria has been met. This is useful for this primitive because the contents of a blocked thread appear on the thread stack.

Once the thread stack was in the proper area, the goal was to get a nice memory leak. This was done by first causing a page fault in one thread. When this page fault occurs, the fault sends data back to a thread stack which will send some errors back to userland. By altering a thread stack variable (the size of the data), an arbitrary memory leak can be performed to leak stack addresses, canaries and so on.

An additional idea (for the arbitrary write) was to overwrite a threads SPSR (saved process status register). Doing this would change many parts of the execution environment, such as whether this thread was from user or kernel space. Unfortunately, some quirks of this technique caused issues too terrible to work around.

The final solution (for the write) was to corrupt the value of 'n' of a file descriptor counter. Using this, an OOB write could occur, on the stack, to gain control of a RET address. Because this primitive allowed for an indexed partial write, the RET address could be changed without editing the canary! This came with several complications, but read the article on how this was handled.

With the ability to overwrite a RET address with 15 64-bit values on the stack, it was time for the ultimate ROP chain. The BPF (Berkley Packet Filter) is a subsystem of Linux that allows for arbitrary commands to be ran. By using this, an arbitrary read/write/execute primitive could be created by calling this from the ROP chain.

Command injection is when you can insert arbitrary shell characters into a system call to modify it. This is a well-known and explored attack vector; people will commonly try to protect against this by escaping the meta-characters, such as [;`"'|&${}]. Instead of a straight command injection, it is about moving around the protections created. But, is there anything missing here?

The valid character (and normally used) - is missing from this set of characters. This character is used for flags in many commands. Although the meta-characters themselves are escaped, can we add flags to the command? Yes!

In this situation, the author has the ability to set flags for tar, a compression tool on the Unix. RTFM.

There are several options, in tar, that give us code execution, including --to-command command_script, --checkpoint=1 --checkpoint-action=exec=<command> and -T <file>. Recall, the equals sign is not usable, which leaves us with a fewer selection of options.

All of the options that could execute code require a file path to know where to execute at. So, can we control a file path? Using a prior tar command (multiple in one set), the -P option can be used to write to the files absolute location instead of relative location.

The exploit flow can be completed. We use one tar command to put a file into a known file in /tmp by using the -P. Then, we use one of the file include flags to include a file to execute during the scripting of tar. At the end of the day, this required an additional step to get the code to execute, but it is essentially the same.

Long live command injection! Although this is slightly different, it is a good case of understanding what you have and using that to the fullest.

The Pokewalker was a pedometer that was released with Heart Gold/Soul Silver in 2010. Since then, people have been trying to reverse how the device works without success. Dmitry (an crazy reverse engineer who works at Google) took on this challenge.

The first part of the article goes over the hardware of the Pokewalker. It appears that this was mostly from online and publicly available data sheets.

The Pokewalker communicates over infrared. Crazy enough, the Pokemon game cartridge itself had the IR hardware, not the Nintendo DS! To reverse the protocol, the author just recorded a bunch of traffic and correlated it with actions happening in the game.

The SIR signaling at 115,200 and 8n1. From there, it was time to decode the protocol. The data had a bunch of 0xAAs and 0x55s. Normally, the most frequent data being sent is 0x00s and 0xFFs. So, the author deduced that the bytes being sent were being XORed with 0xAA. The packets had a header with the command type and length, then a custom implementation of LZ compression.

So, the real question is how do we get in? The EEPROM chip is used to store data and can be read out easily using SPI. In-circuit debugging is supported, but chip will self-erase if programmed, so no way to dump it that way. This makes the situation really hard, as we are attacking blind!

Dmitry has a good motto: "assume that any code you encounter was written by a drunk student." The main point of entry is through the IR. What can we be done here?

The author messed with the compression algorithm, trying to find the mistakes of a drunk student. What could be done to a compression algorithm?

• Change the size of the decompression.
• Decompress to a larger size than expected.
• Double compression attacks

In the end, the bug was that while decompressing LZ backreferences, size checks are only performed at the end, and they are performed for equality and not 'greater than or equal'. This means that it will keep decompressing until a particular byte is met.

To make this more exploitable, the decompressed buffer follows the compressed buffer! So, if the decompressed data is also valid compressionable data, we can keep decompressing. For sure, using this technique, a crash of the PokeWalker occurred. But now what?

From brute forcing the offsets, the author figured out where the stack pointer was. Then, with such a small address space and an executable stack, the author wrote a payload to brute force this location. Now, we have code execution!

Using the IR transmission in the shellcode, data can be leaked! Using this (and restarting after the watchdog timer), the entire ROM can be leaked.

The rest of the article goes into the reversing of the ROM and the rest of the commands. This is an incredible article where a completely random attacker gets code execution with no prior knowledge. One for the ages!

When asking for help on most Google products, it is possible to send a screenshot of the issue. When implemented, this was done by using an iFrame to handle this information then sending the data via a postMessage request.

At first, the author tried getting XSS on the domain but after numerous hours of trying failed. So, they tried playing with the postMessage configuration and see what was going on.

It turns out, that if a page is iFramed, we can change the iFrames location. If the page can be iFramed, this really messes up the iFrame security of a page.

So, the attack has a few steps:

1. Load the page in an iFrame (Google Docs does not have iFrame protections).
2. Edit the location of the Google Doc to be your page.
3. Send the help message.
4. Your screenshot can be hijacked!

Why does the changing of the location of the domain actually help? When sending a postMessage, a reference to the parent window where the request is being made is sent. When doing this, it is important to specify the domain to send this to. However, the page does NOT set this and just has a wildcard ('*').

Now, with the changed location of the iFrame, we can hijack all of the data being sent in the screenshot!

What allowed this to happen? First, the page itself could be iFramed. Using headers to prevent this could have prevented the attack. Secondly, the postMessage was not sending to a particular domain -- windowRef.postmessage("","*");. Both could have prevented this. Awesome find!