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!

OAuth is a protocol that is used for third-party sign ons all over the place. Facebook has their own OAuth provider that can be used to login to multiple things.

The OAuth flow is quite complicated. In the context of OAuth, an arbitrary redirect is an automatic game over because of how the flow of OAuth works. The arbitrary redirect can get the users code that logs them into a site via OAuth.

Facebooks OAuth has a preformatted response when requesting an access token or authorization code via postMessage. When specifying the target origin on the request, a fallbackmeasure could be triggered if no opener window was found.

This fallback URI did NOT have a strict validation on it; it only validated that the path is ON Facebook.com. By using a previously discovered Open Redirect on instagram, we had a bypass for the redirect_uri check.

Using two chained redirects, the access token that a user has gained from logging in could be stolen. Facebook gave the author 30K for the finding and an additional 12K after a bypass to the fix had been found.

This article uses a router to get to the SoC that uses the QualComms Secure Execution Environment (QSEE). This Trusted Execution Environment (TEE) is found on many Qualcommn devices such as Linksys, mobile phones and other devices.

The first issue was trying to get as much access to the device as possible. The device had a nicely documented serial interface with supporting docs from OpenWRT. But, this only got the bootlog though.

The bootlog had a mention of U-Boot. So, by pressing a key, they were able to enter the U-Boot console, which has a plethora of useful commands.

In ARM TrustZone there are two worlds: secure (TEE) and non-secure world, which is also known as the Rich Execution Environment (REE). This is denoted by a special bit called the Non-Secure bit. The primary bootloader and secondary bootloader are used to load the rest of the system (including the QSEE binary) and run at the highest privilege.

To extract the QSEE binary from the system, they set the serverip U-Boot environment variable to be at a server they control. They load the binary into Flash and then send it off to their server. All of this can be done within the U-Boot console!

The QSEE binary is a completely flat binary with no metadata present about the structure or symbols. So, this took some time to reverse.

While using the REE env, range checks need to be done in order to ensure that ONLY TEE addresses are written to. However, this check needs to be done each time a read/write occurs within the TEE.

The authors of this article identified FOUR times that output addresses were not properly sanitized. Because of this, an attacker could write into arbitrary locations of the QSEE to compromise the TEE.

In order to access this, an attacker would need to be able to load a kernel module or get access via U-Boot. Still though, finding vulnerabilities in this has wide reaching effects.

This vulnerability was found in a Github workflow template used for integration with Discord. Github Workflows allows for automated actions to occur when some events (such as a PR) happens.

When a PR had gone through, a Workflow was made to integrate with Discord to send this in a particular channel. However, the commit field (which is clearly controllable) was not sanitized at all.

Using the lack of sanitization, it was possible to add arbitrary Markdown into a Discord message. But, this can get much worse!

The Discord API supports STRING interpolation syntax for environment arguments. The interpolation even allows the executing of arbitrary JavaScript! Using this, it is possible to write to the repository and steal other secrets from the Github Runner instance.

Overall, this is an integration issue between two powerful technologies; none of them (although, executing JavaScript seems like a little much) have direct issues with the setup. Interesting finding!

HackerOne has a warning page when a user is going to an external site. In particular, this happens on all redirects. These redirects commonly have sensitive information, such as keys or exploit proof of concepts (POC).

When a third-party site had been indexed with HackerOne links, the sensitive information in this link was shown. Because of the usage of the link, unlisted YouTube videos were found with POCs and other information was leaked.

I had never considered search engines as a way to leak information! It is quite common for sites to have this redirect page like HackerOne does. So, this bug is probably out there in other places as well.

A while back a major library whose whole existence was trying to figure out if an IP was internal or external was found out to be broken. It turns out that parsing IP addresses is MUCH more complicated than one would think! Besides 127.0.0.1, this could be encoded as 127.1, 0177.0000.0000.0001, 2130706433 and many others that I am missing.

This discrepancy was caused by a parsing mistake in treating octal (base 8) as decimal (base 10). They accidentally created a vulnerability (on the first fix) that parsed hexadecimal (base 16) integers as octal!

An additional issue was that parseInt in JavaScript will strip out all whitespaces characters. Using this parsing, it could have been possible to bypass the filtering in some way.

Although improper parsing of IP addresses does not seem like a big deal, it really is. Protections for attacks such as server-side request forgery (SSRF) and local file inclusion (LFI) rely on some library to filter internal endpoints. Being able to circumvent this is a huge deal. I have a feeling we have not seen the end of this bug!

Linux is secure by default. But, what happens if you change the default settings? Well, some have MAJOR security consequences. This article has a large collection of privilege escalation measures with misconfigurations.

Another similar repo can be found here for Windows.

The author of this article decided to fuzz a file viewer. They choose this target because not many people had fuzzed it. Additionally, they chose to fuzz the CUR format because none of the CVEs reflected this. In general, fuzz things that people have not looked at in order to find bugs.

Peach Fuzzer is an older fuzzer that does not apply binary instrumentation to the programs. The program takes in an input, mutates it then sends it to the program to see what happens. With Peach Fuzzer, you can ask for random mutations or ask it to common a set file format.

The Peach Fuzzer smart fuzzing can be used to specify the structure of the data, the flow of data, set testing blocks and a bunch more. Although things like AFL are much better when things can be instrumented, Peach still has its place.

Using Peach fuzzer the authors find a buffer overflow via the setting the BitCount to be very larger. Using this, an integer overflow occurs that leads to a stack based buffer overflow.

To actually exploit this, the author overwrites the SEH Chain on the stack to control the flow of execution. Because the Windows program does not turn on ASLR or DEP, popping a shell is quite easy. However, the author made POCs that bypass both of these protections just for the fun of it.

Overall, this was a good article on fuzzing! The art of fuzzing looks a little less scary after reading this article.

Gitlab allows users to delete their account. In order to do this, you need to send an email to somebody.

The issue is that the email verification and deletion is done by humans. Because the sending address can be spoofed, it is trivial to delete any uses account.

Bugs are not always technical! Sometimes, it is just a lapse in the attack surface.

Small Computer System Interface (SCSI) data transport is for connecting computers via peripheral devices on older devices. Even though this functionality is not common by itself and was written 15+ years ago, many Linux packages rely on this for weird reasons.

While visually scanning for bugs in this area, the author noticed that the string handling of SCSI did not look secure. There was a pointer to a string that was being copied via snprintf directly without any length checks! This creates a very large buffer overflow for all strings that are bigger than one page.

When a iSCSI transport handler is registered, it is available via the SYS file system at /sys/class/iscsi_transport/$TRANSPORT_NAME/handle. When read, the function leaks the handle, which is simply a pointer to a kernel address.

The final bug was an out of bounds kernel read (many of them). A netlink message can be crafted with malicious size lengths that are simple NOT validated. Using this, an OOB read can be performed by specifying invalid length values.

To get a full POC, we need to leak a bunch more data. The SCSI string buffers are neither NULL terminated or initialize the memory. So, by grooming the heap properly and specifying a size larger than the amount of data written, a leak occurs via the kstrdup function. Using this, we can break KASLR. The second vulnerability above leaks a pointer to the kernels module's global region.

The SLUB allocator maintains a cache of objects of the same size by using a singly linked list. By using our previous heap overflow to overwrite one of these pointers, we can specify the next location for where the kernel creates a chunk at. Of course, this requires proper heap grooming, which is discussed in the article. Additionally, this would not work with distros of Linux with harder checks on freelists.

The target of this overwrite is the iscsi_transport structure within the ib_iser module. This structure contains several function pointers with parameters that we control, making it an ideal target.

The functions are replaced with seq_buf_to_user and seq_buf_putmem in order to obtain a simple read/write primitive. There are some caveats to this, as the pointers are not exactly what we expect though.

With the read/write primitive in the kernel, how do we become root? The exploit calls run_cmd in the kernel SE Linux context. The function takes a parameter from the iscsi_transport struct that points to a shell script in userland. Because the attack never dereferences or executes memory from userland in the kernel, the exploit bypasses SMEP, SMAP and KPTI.

Overall, this is an awesome article! Sometimes, finding the right place to look for bugs is the most important thing. In this case, it netted the author some easy/obvious bugs.

H2C smuggling is a fairly new form of HTTP smuggling that allow the bypassing of reverse proxy access controls via tunneling. If a company relies on the reverse proxy for access controls, this is a major security concern.

The H2C attack relies on the fact that specific headers will be sent that allow for the smuggling to occur (not all do). However, the original author makes a little comment that "not all backends are compliant. Using the idea to test with non-compliant header variants, the headers may sneak past the reverse proxies to the backend server.

The author of this article had to make a substantial amount of alterations to the Go H2C libraries in order to run these non-compliant tests for both the client and server. This tool can be found here.

The main piece of non-compliance was to use the Connection: Upgrade variant, where the HTTP2-Settings of the Connection header is omitted. Because this is not an expected issue by the proxies, this could be used to smuggle a protocol upgrade request to the backend.

The author finds this bypass to work with Cloudflare and Azure with some other providers not allowing for disclosure at this time. This smuggling bypass technique worked fairly well!

Originally, I mentioned that the author not having any examples of exploitable servers made this theoretical and not very useful. However, on reddit the author commented that some servers vulnerable (such as traefik) but they were not pointed out in the article. Interesting!