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 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!

SSO's (single sign on) applications are used in order to give users access to an application while using another providers credentials. Alongside the SSO, certain permissions must be granted (by the user) to have at the third party site.

The issue was that if user deleted the account on the third party site or revoked access, the Gitlab SSO did NOT revoke access to the previous permissions.

Although this is a weird finding, permissions should be given and taken at will. This should be a normal test case going forward.

Brute force protections gone wrong! After 20 failed login attempts, an email attempts to be sent to the user/admin.

After 50 attempts, the password is cleared in order to indicate that the password should be reset. But, by sending a blank password, it will login the user!

This is a ridiculous auth bypass but is super interesting!

An LPE on a Linux machine? Who would have thought that! Linux OS's are typically secure. This privilege escalation ONLY exists within the Desktop version of Ubuntu & not the server version.

The first bug is a denial of service within the accountservice daemon. The user sets the file .pam_environment to be a symlink to /dev/null. This makes the file infinitely long when trying to read it.

When the daemon decides to read this file, it DROPS the privileges down to the same as the user in order to prevent privilege escalation. Because of this privilege drop, there we have the ability to send signals to this process! What signal should we send? How about SIGSTOP? This will pause the running process.

Now, he is the real kicker. You log out of the current user! Once at this screen, we wait until the user dialog box pops up to create a new user. Why does this happen?

When there are no users on the system, GNOME is instructed to create a new user. It knows how many users there are by talking to the accountservice daemon!

The bug is in when the accountservice daemon is unresponsive and a timeout occurs. With this code path, the field that matters if knowing if a account exists for a user is the field priv->have_existing_user_accounts. However, this defaults to false! So, if the timeout occurs when trying to talk to the service daemon, then the functionality acts like there are no users on the system!

In a nutshell, this stops the accountservice daemon by first putting it into an infinite loop to drop the privileges then stopping the service with a signal. Then, by logging out and trying to log back in, the unresponsiveness of this daemon allows for the attacker to restart the user initialization process.

I love this type of finding! When I see bugs like this I wonder "What could I do better in order to find this bug in the future?". The crux of this bug was that an insecure state was used in the initialization of a field that was relying on a time-delimited action to fill it out. In the future, look for bad/insecure initialization of values.

By the way, the author found this bug by accident and it took them some help in order to find the root cause of the issue. As I would say, you miss 100% of the shots you don't take! At least by trying this guy gave himself a chance to get lucky.