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!

The main crux of this problem is taking untrusted serialized data and deserializing it. This has been a common issue with Java based applications in the passed.

This is a good example of a deserialization issue occurring in Elixir. "In Elixir there’s a much higher chance that such a function is executed later down the road, thanks to the Enumerable protocol of Elixir." This means that going for arbitrary deserialization to code execution is much easier in Elixir than other languages.

Fuzzing the kernel is crazy complex and NOT time efficient. So, moving this to userland can be useful. This article goes into fuzzing the Linux Kernel. However, this fuzzing is left as an exercise for the reader.

In a previous bug, there was a vulnerability in the handling of 32-bit vs. 64-bit but it was processed in the same area. The solution was to put this into two areas of code: one for the 32-bit and one for 64-bit.

What went wrong with this patch? The code was copy and pasted into another function where only some data was edited for 32-bit vs. 64-bit. So, some copies were happening for 64-bit instead of 32-bit! This created an OOB write primitive.

What is the take away from this? A 'fix' may not actually fix the problem! Verifying that a vulnerability has actually been patched is an easy way to find more vulns :)

SSRF allows for requests to be made within the internal network of an application. This allows for the stealing of important information or altering of information on the internal network.

The author knew they had an SSRF bug when the response was extremely fast. Sometimes, finding blind SSRF and KNOWING if you found SSRF are two different things.

Blind SSRF only has impact if you can make requests to alter state on the internal network. So, typically an attacker wants to return data.

One of the features of Google Cloud Monitoring was to validate the response in the request. By using this feature, a single character could be guessed per execution with the contains feature. Eventually, they could be used to get ALL data from an internal server.

Practically speaking, the author decided to target the Google Metadata Service in order to steal credentials to the host Google account. In practice, this service was behind a load balancer, making this difficult to do.

At the end of the day, Google gave the author a 31K payout! I found this to be interesting because of the way used in order to siphon out the data on a Blind SSRF.

This exploit revolves around TWO bugs in Facebook. By using this, it is possible to get XSS on the Facebook domain.

The first vulnerability (and an odd one at that) was an arbitrary postMessage request on the Facebook domain. Why is this bad?

postMessage is a function that allows for websites to communicate cross-domain. However, there is recommended security precaution to take: validate the domain of the request. This ensures that malicious websites cannot alter the state of other sites.

Because of this assumed security protection (being from the correct domain), finding an arbitrary postMessage from Facebook does not bare fruit by itself but could be part of a chain.

From this bug, the author found a DOM based XSS on multiple sites. However, the author only shows a single one. The interesting thing to note was that the event listener was accepting a link and add it to a form. However, it did not validate the type of link being used! So, JS URI could be used.

The attack works in the following way:

1. Visit the malicious website.
2. Load https://www.facebook.com/platform/page_proxy.
3. Load the page with the arbitrary postMessage in another tab. Use this bug to send a request to the first URL.
4. Now, we have XSS on Facebook! The author mentions that the POC they sent in would steal a first party access token.

Awesome bug. The researcher got paid 25K from Facebook! For future reference, this website has a BUNCH of great articles and research.

This vulnerability used a plethora of issues to eventually steal all cookies from an Android device. It is always fun to see multiple smaller issues chained together.

When testing the content URIs, the author noticed that Firefox was manually changing this to a FILE URI and writing the content to the OS.

First, Android has the concept of content-providers. The content-provider can help applications manage data access from itself and other applications. In this case, the content provider for Firefox was verbose; anyone with access to the Firefox content-provider could access ANY data that Firefox controls (including cookies in the SQLite DB).

The Same Origin Policy (SOP) FILE URIs is pretty clear in the Mozilla docs. For this exploit, the only relevant 'a file can access its own contents'.

Why do all of these things matter? What if we could create a file (with the content URI) that suffices the SOP but points to some other data? Using the three quirks above, it is possible!

The following steps were taken, in order to make this attack work locally:

1. Have Firefox fetch content://org.mozilla.firefox.fileprovider/root/sdcard/Download/profiles.ini.
2. Firefox fetches this content & saves it in /sdcard/Download/profiles.ini. Then, the user is redirected to THIS location.
3. Request a file with the SAME name (but from a different directory). This will overwrite the content currently being displayed by the user.
4. Files can now be accessed across boundaries IF they have the same name!

To make this work remotely, just use the deep-linking feature.

Super interesting find that took me a few reads in order to understand. At the end of the day, this came down to over verbose permissions and weird parsing functionality.

Domain Name System (DNS) is used for determining which domain name (https://google.com) matches which IP address. Who likes to type IP addresses straight into the browser? DNS makes it possible to use domains instead of IPs.

Quote from article "Still, the most common transport protocol for message exchange is UDP, which has the advantages of being fast, ubiquitous and requiring no setup. Because UDP is stateless, the pairing of a response to an outstanding query is based on two main factors: the source address and port pair, and information in the DNS message. "

The issue is that the sessions are unauthenticated. As long as an attacker knows the IP address & port of the connection, the domain name can be spoofed. However, back when DNS was made, this was thought of; each request has 2 bytes of entropy at the beginning of the message.

The first attack is simple, yet works. "...whenever a recursive resolver queried the authoritative name server for a given domain, an attacker would flood the resolver with DNS responses for some or all of the 65 thousand or so possible message IDs". When the DNS server gets this result, this is the expected domain that will now be sent back to the user.

What was the fix to this first attack? Port Randomization! By randomizing the port of the request, an attacker did not know WHERE to send the IDs to. This takes the amount of IDs to brute force from 65 thousand to 1 billion (which is infeasible). The next few attacks discussed are about figuring WHICH port something is on to launch the OG attack.

The bypass to the port randomization was the fragmentation attack. UDP allows for packets to be broken into multiple fragments. So, an attacker could do the following:

1. Create a legitimate connection that is fragmented & send the first packet.
2. In the second packet, CHANGE the ID of the packet. Now, the previous attack works because we can NOW spoof the usage of the previous request. Although, this packet MUST arrive prior to the actual request packet.
3. Do this over & over again until the proper ID is guessed.

NOTE: This does not go around the port randomization itself but figures how to use an attackers OWN connection in order to spoof the the ID.

The solution to the previous problem (with Cloudflare) was to make a request from MULTIPLE DNS servers at once and check against each other. Although the 65 thousand (2 bytes) can be brute forced on ONE connection, 2 or more connections becomes nearly impossible.

I asked myself: "What if you did a port scan in order to know WHICH ports were in use for a query"? That is the idea behind this next attack, but it requires a little bit more intricacy than using nmap. This is done with ICMP error messages & rate limiting.

Some background information on ICMP rate limiting. First, if the port is open for ICMP (for a specific IP address) then the rate limit is NOT changed. If the port is NOT open (for the IP address), then the rate limit is increased. Recall, that if we spoof the IP address in the UDP request, we will NOT get the request back.

So, what is the problem? The rate limiting can be used as an Oracle to figure out WHICH ports are NOT open! If the rate limit HAS been met, then we know that the spoofed request went through. Otherwise, it did not. Using this, we can figure out which ports are open for the specific IP!

Once we know the port open for this IP, we can launch the original DNS spoofing attack again. Cloudflare mitigated this bug by switching a connection over to TCP if port enumeration attempt is done.

In this a good solution though? Considering these bypasses have come & gone, there has to be a better solution to this: authenticated DNS. In fact, there is such a thing: DNS over HTTPs (DoH) and DNS over TLS. There IS a solution to the original DNS problem but these other DNS solutions have not been widely adopted yet.

Certificate validation is incredibly important for a secure internet!

However, what happens if a certificate gets revoked? Well, the certificate, being validated, must be ALSO be checked against a list of known bad certificates. The problem is that this is a hard problem to solve.

The Online Certificate Status Protocol (OCSP) is a way that allows to find a certificate is has been revoked. Apple has this setup to check for the revoked certificate.

Why did MacOS user applications stop working? The OSCP endpoint was OVERLOADED with traffic. Because of this, the validation of the certificate could not been done, resulting in applications not running.

What was the temporary solution? To redirect the hosts file to a different IP (that is not on). Applications must work if offline so the request ONLY happens when the computer is online.

Debuggers (such as GDB) are pretty amazing! They allow us to jump around in execution, see values of the registers... and so on. This article goes into how the debugger actually achieves what it does.

In order to pause the point of execution, there are special purpose registers that indicate when to stop. These registers (only 4 of them) are labeled DR0-DR8. DR6/7 are both used for status and control registers.

To get the general purpose registers (RAX, RBX, RSP, flags) inline assembly can be used once execution has stopped in order to grab the data from the registers. Additionally, the ptrace API can be used in order to get this information too. The ptrace API is commonly used to alter the data.

The floating point registers are a bit more complicated. The content of the floating point registers can be dumped with the FSAVE instruction and restored with the FRSTOR instruction with some additional instructions for 64 bit.

This functionality is really important for context switching. Switching between applications with context switching allows for the one program to debug and understand the other program. The ptrace API is awesome but very complicated.

This articles goes through how to setup a debugging ENV for the Linux kernel.

Step by step, this looks like the following:

1. Build Kernel
2. Build Image
3. Launch the Virtual Machine in QEMU
4. Attach a Debugger

Huzzah! A good test environment has been made.

The term wormable is over used in the age of the modern internet. This vulnerability is TRULY wormable.

The bug exists in a video game called Alien Swarm that is open source and build in 2010.

The vulnerability exists on BOTH the client side and the server side: a malicious file upload. There are multiple protections in place that had to be bypassed for this to work.

First, the file upload attempts to ensure that NO files with specific file extensions are used. The SENDFILE API is 260 bytes but later copied into a buffer of 256 bytes, after the validation. So, the last 4 bytes can have a valid extension but WON'T be used!

What else can we bypass? There are two validations for the paths of the file. First, there is a validation that directory traversal is taking place and that specific directories are not being used.

The directory traversal check can be bypassed by writing to the '/' directory. This is done because the validation happens THEN a call to FixSlashes is made. So, by using a directory starting with '/\\', the fix slashes will give us the root directory.

The second validation can be bypassed by using all capital letters. In Windows, paths are case insensitive. So, using ADDONS instead of addons allows for this validation to be bypassed.

On the server side, the API can be used in order to add a malicious plugin. Then, the server can use the SAME vulnerability to affect other players. To me, this is the definition of wormable!