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!

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.

There are a BUNCH of vulnerabilities in this. I will only touch on the unique/interesting ones.

Netgear has a protocol called Netgear Switch Management Protocol (NSDP) for network protocol discovery for switch configurations. The protocol authentication has two steps: asking for a random token and using this to generate a hash that will be used for authenticated requests.

If the first step is skipped at reboot, the random value is 0x0! Because we know the random value, we can send authenticated requests. The author shows a few ways of crashing the switch, making this a viable attack.

The firmware updating was done quite poorly. First, the firmware updating was not authenticated, which could allow for any signed version of the firmware to be put onto the device. Although this does not sound bad, downgrade attacks can common to use if a product has a previously known vulnerability.

Even with the validation check, it was not done properly. When validating the new firmware, the real file length can be spoofed and the maximum size of the firmware was not properly validated. Because of these oversights, the signature validation could be bypassed to add custom code to the device.

The device had some issues with authentication as well. The DHCP configuration functionality was completely unauthenticated and there was an information disclosure on the NSDP protocol.

Besides the items listed above, there were a plethora of general web app issues (XSS and CSRF), as well as several buffer overflows.

The IoT space is known for horrid security practices. So, this author decided to do some research into CCTV cameras.

The bulk of this attack comes down to spoofing in the architecture. When a device is camera is registered, it sends the server the details, such as the MAC address and cloud device ID. Now, the source IP is associated with this device ID.

When a client wants to see the video, the server tells the camera about a relay server and connects there to stream the data. This validates sends the username and password that the user provides prior to streaming.

Because of all of this logic, the author was interested in the registration functionality. What if you spoofed the registration under a different cloud camera ID and handled the relaying process? Because of we now control the camera, when a user tries to login, we can steal their credentials and stream their camera.

At this point, the author wanted to be a meme. So, with this far into the process of becoming a camera, they decided to inject video feed into the stream with the spoofed camera. The final video shows him launching this attack to freeze time like in National Treasure. It's pretty awesome!

The camera only requires authentication remotely. If on the same LAN as the camera, port 554 (RTSP) can be used in order to stream the contents of the camera directly.

Overall, this is an interesting attack that is different than pop a shell while still being effective. Business logic issues can be the worst bugs, they just require a deeper understanding of the system being used.

F5 Big IP allows for network traffic control and several other features. Naturally, this requires a bunch of data processing in order to do properly.

When processing response headers, there is a function that attempts to match if this is something that can be returned. While doing this processing, there is an integer underflow in a size validation. Because of this underflow, the validation does not work, this turns into a buffer overflow.

The F5 Big IP does not have any standard mitigations, such as ASLR or NX. Because of this, once the overflow occurs, shellcode can be embedded into the process to pop an easy shell.

The bug is complicated to trigger, as an attacker would not have direct access to the size of the response. So, this would take further steps in order to exploit.

SerenityOS is a Unix based hobby OS led by Andreas King. Because of it being an OS and relatively new, people love to look for bugs in it!

The vulnerability is a bad bounds check on a variable length array (VLA). The size provided from userspace (to the kernel) does not have a sanity check. The memory being written to & from has a check to ensure that the memory is in user space though.

VLAs allow us to dynamically change the size of our stack frame by altering the esp directly. This is done by taking our value and subtracting it from esp (sub esp, VALUE). The VLA acts funny when the change is larger than the stack itself!

By setting the size to a very larger value, we can put the esp to an arbitrary location in memory. This is awesome because the next usage of the stack will use the esp from this extremely weird allocation. Because we control the values being written, we can overwrite arbitrary data on the stack for a nice arbitrary write primitive!

There is one issue though: our original size being used will cause a crash to happen and end the process, removing the ability for this primitive to be used; this is a common wildcopy problem. So, we pass in very large size for our buffer but our buffer is not actually that big. This causes the syscall to gracefully exit because the buffer hits unmapped memory. This is a good thing because the exit from a userspace issue does not cause a kernel panic.

By using this primitive, we can overwrite the stack of other threads within the kernel! The easiest, and most reliable, is overwriting the kernel stack pointer for another thread when calling sleep. This allows us to always know what will be overwritten and consistently win the race. Once we overwrite the ESP of the stack frame, a ROP chain can be trivially created to become root.

I had personally never thought of exploiting VLAs like this before. It requires a very specific circumstance to do but is deadly when done properly.

All the way back in 2006, a vulnerability was found in the Apache Module mod_auth_kerb. The ISC BIND server (most popular DNS server on the internet) shared the vulnerable code in the SPNEGO component but was the patch was never merged.

At the beginning of a function, an allocation is used in order to get heap memory. After this, two indexs are set but only one subtraction on the length (more of a max size) variable occurs. Because of this off-by-one error, a single integer overflow occurs (4 bytes).

The article includes a description on how this could be exploited on GLibC 2.27. As a note, heap grooming in quite easy, as we control the amount of iterations on a loop and can free chunks at will.

To get an arbitrary write, the following is done:

• Use the buffer overflow to overwrite the chunk size of the next chunk.
• Allocate & free the corrupted chunk on the next request. Now, we have a chunk overlapping with a free chunk in a different tcache bin.
• Overwrite the 'fd' pointer of the free tcache chunk to set it to an arbitrary value. Once this is allocated, we will write to any location we want!

Because all Linux mitigations are enabled by default for BIND, we need to defeat them. The author includes a potential way to get a leak via a tcache dupping technique but it was unsuccessful because malloc would eventually abort, resetting the randomness.

This article rediscovers a 14 year old bug in a popular piece of software. This makes me wonder if there are other dependency issues in popular open source software that was never patched; the answer is probably yes!

Palo Alto SSL VPN is used to separate the corporate environment to outside attackers. It requires access to the VPN to even get on the internal network in the first place. Because the VPN itself has to be on the internet, this is an amazing attack surface which would be a high impact if something was found.

In C, format strings are used in order to dynamically add content to a string (printf, snprintf, etc.). However, what if the user can supply a format string? This is the bug! Because of an improper amount of parameters being passed to the function format string vulnerability was found.

By adding a format string (%n, %s, etc.) to a processed string, data can be read or written to at will! This bug class is almost dead (probably because compilers tell you this is a major security issue). But, if found, this vulnerability is enough for a read/write primitive by itself!

To verify this server on the backend, they initially for used a %n to crash the server. To the authors, this was not enough though. So, they sent 9999999%c in order to induce huge time delays to determine if this was a legit bug or not.

In order to exploit this bug, they use the %n specifier to overwrite the Global Offset Table (GOT) to be system. Now, we can trivially pass in a command, which will be ran in the terminal, to pop a shell. There appears to be no PIE on this binary, making this attack easy to exploit.

Palo Alto had recently found this bug and fixed it without telling anyone though... So, a CVE was never released and Palo Alto did not prompt anymore to update. Eventually, Orange Tsai and the crew found that a Uber server was vulnerable to this attack and compromised it. Posting about patched vulnerabilities is important!

Information disclosure vulnerabilities are not nearly as sexy as gaining control over the flow of execution. However, with modern binary protections that provide randomness, such as PIE and ASLR, memory leaks are a crucial point in the exploit chain.

PDFs have a section called the trailer. This is used for making application reading the file (Reader) have easy access to objects via cross-references. This is implemented as a key-value pair.

The exploit uses a field called ID and writes an extremely large value in it. The vulnerability occurs when processing this data.

The ID field is stored as a fixed sized value of 0x100. However, clearly the user controls the actual size when this gets operated on. At this point, the actual value is on the stack (truncated to 0x100) and a heap allocation is made of the large size (0x400).

When a memcpy is ran on this to copy the stack buffer to the heap buffer, a 0x300 byte OOB read occurs! 0x300 extra bytes, which can be queried by the application, allows the user to break ASLR and find the locations of Windows libraries.

When inserting an avatar link for support chat request, there is improper validation. Instead of strictly validating the domain it just checks if the domain contains the URL. Because of this, a user controlled link to an arbitrary server can be provided.

There are two ways to exploit this. First, because than attacker can control the link, they can see the IP address of the user. This creates a privacy violation that could be used in other attacks.

The second way to exploit this is a persistent denial of service (DoS) attack via a logout CSRF. By setting the avatar to be a logout request, the support agent is locked out of their account. To make matters worse, the avatar was loaded for all support professionals! Damn, that is an impactful DoS.