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!

Berkeley Packet Filter (eBPF) is used in the Linux kernel for custom extensions for packet filtering and other operations. Because this is user defined code running the kernel, with only static-analysis for verification, it is a high point for attackers.

The eBPF takes two passes at the data: one to check for loops and the other to check for memory violations. This memory violations area is where attackers like to lurk at.

While attempting to validate the BPF_RSH (unsigned right shift) function, it attempts to edit the dst_reg max/minimum values for writing. This verification process is flawed though! A wrongful value is used for the max/min shifts, allowing for the verification to be bypassed.

Triggering the bug in the eBPF is another thing though... They do mention that to use one of the necessary flags in the eBPF, you need to be an administrative user.

Once this bypass has been done, a user has an arbitrary read/write primitive for the eBPF itself. Using this, further escalation can likely be used to takeover the kernel.

Kindles are a device that people use for reading ebooks. Kindles can download books and have other features as well. The author discovered a chain of three bugs that lead to RCE on the kindle.

Kindles have a feature called Send To Kindle that allows users to send an email to special Amazon Kindle email which will load the book onto the device automatically. However, there is an allowlist on the email for who can send these.

Email servers are commonly unauthenticated and do not validate the authenticity of the sender of the email. So, an attacker can spoof the sender email address and send a device to ANY Kindle.

With the ebook on the device, is there anything that can be done? This is the question that the author asked themselves. Books have a lot of functionality, such as image rendering, font rendering and many other things.

After getting off all of the binaries on device (jailbroken kindle) a particular library stood out: libjpegXR. This is an obscure image format, which looked like a good attack surface.

While looking at the official reference implementation of the parsing format, the author came up with some ideas for potential things that a developer would miss. One of these identified checks was indeed missing, which made for an excellent exploit. This buffer overflow in the image parsing format was easily repeatable and allowed for a nice arbitrary write primitive by overflowing a nearby object.

To make matters worse, the binary is loaded at a constant address and does not have the Nx flag; this means that some memory can be writable, readable and executable! To exploit this, the author used the arbitrary-write to overwrite a GOT address to jump to the authors shellcode.

At this point though, the user has NO privileges. There was a script (running with higher privileges) that allowed debugging of the binary using GDB. However, one of the passed in parameters to GDB was NOT escaped (shell metacharacters). Using this, an attacker could inject a shellscript into the GDB startup!

This trick was a known issue to the developers, which they attempted to prevent by validating with a call to atoi. However, atoi will only validate the number if it is used at the beginning. This means that something like 1 hello would parse as the number 1.

Additionally, the developers attempted to use the regex ^[0–9]*$, which says only numbers. However, this will match per line! Adding a newline into the could match for the first line, not the second, and still pass the check. According to the people at DayZeroSec, this is a fairly common issue.

The fixes are as follows:

• In cases where Amazon cannot authenticate the sending email address, they now send a verification link to the approved address.
• The buffer overflow just added a sanity check on a size parameter.
• The GDB script now validates that ONLY numbers are in the string.

An additional thing to note is that a user would have to click on an ebook then a link within the ebook in order to exploit this. Although this is NOT zero-click, it is still a really good collection of findings.

The classic DNS spoofing attack is back! In a particular DNS implementation, there are several issues. As a brief history, DNS is how a domain (google.com) gets turned into an IP address. The process for this is unauthenticated and over UDP, which creates issues.

To resolve a domain, the DNS server goes and asks another server to see if it knows. A callback ID is sent with the request and the server waits. This goes up and up until somebody knows the domain. The major issue with this (discovered by Kaminsky in 2008) is that if someone knows the callback ID, then they can spoof the connection.

DNS is broken by itself. At this point, the implementations are putting a band-aid in order to make the internet still work. In order to make this attack not feasible, a bunch of randomization is added, such as a larger callback ID, randomized ports and other things. Breaking the randomness makes it feasible launch the original attack.

The first issue is that the random ID of a UDP packet is 26 bits instead of 32. Although this is not going to be brutforcible but itself, this helps remove some of the randomness.

The second issue has to do with the verification of the proper request. It has to have a proper challenge-responses and a proper ID. In order to validate this, a hash is taken of the values. The issue stems from the fact that the hashing algorithm is not cryptographically secure (CRC32) making it possible to guess these values to return the wrong domain name.

An additional bug is that multiple requests for the same domain name can be used. When this is done, ANY valid response will work for this. Practically, this means that an attacker needs to guess any one of the ports and any one of the TXIDs right! Using these three bugs, the odds of spoofing a DNS request are 2^19 or half a million requests. This takes about 5 minutes from a single computer to send and is a practical attack.

The typical solution for DNS spoofing is to a) add more randomness or b) change to DNSSEC. But, what if there are vulnerabilities in DNSSEC!?

DNSSEC is safe. However, 4 buffer overflow vulnerabilities were identified that could be useful for memory corruption primitives. The most impactful (heap based buffer overflow) is caused because an attacker controlled size value for a write, but the buffer is static in size.

Another one of the buffer overflows was caused by hitting the same code and with different path. Using this path, the location of the buffer was offset by a length value and could be used to write OOB, even with nullbytes.

The final two bugs were wildcopys from length validation issues that are only good for DoS attacks.

An interesting set of bugs! Vulnerabilities in popular DNS software (such as this) could be used to make a large impact. To me, the DNS spoofing was a little overhyped because most connections use HTTPS, which means the certificate needs to be validated with a wrongful domain name (which won't work).

Shazam has deeplink functionality for its mobile application for both Android and iOS. One part of this functionality allowed loading a website into a webview, within the application.

However, the URL parameter, specified for the deeplink, was not being validated. This meant that either website can be put into the webview, or using a JavaScript URI. The webview included some JS interfaces that allowed for polling of specific data on the device.

In particular, physical location data could be tracked by someone who loaded a malicious site inside of the webview.

The attack flow was pretty cool. A user clicks on a deeplink URI which opens the Shazam application. Once the application is open, the webview with the malicious site is used. The malicious site can then extract the GPS information about the user!

This is a ever interesting use of deeplinks in exploitation. In the future, I'll keep this a little more on my radar.

YouTube is used from placing videos and watching them later. YouTube has 4 built in playlists, where the IDs can be derived from the account ID.

YouTube videos can be embedded into iFrames. However, it is a common use case to want to start/pause the video in JavaScript from the home site. This is not possible (because of the SOP) so the best way to do this was to add a postMessage API for the parent frame to talk to the child YouTube frame.

Using this API, the YouTube video can be started, paused, moved and so on. An important thing to note: if YOU are logged into YouTube, so is the embedded playlist.

Anybody see where this is going? This is essentially a cross-account stealing of YouTube data! Because the user is logged in and we can predict the playlist ID of these private playlists, a bunch of information can be stolen over the postMessage API. This data includes stealing you Watch Later videos, Liked Videos with no problem, because we can leak the playlist ID information based upon your account ID.

To make this even worse, there is an uploads playlist. With YouTube, there are three settings for videos: public, private and unlisted. Unlisted is public for anybody that has an ID, but meant to NOT be on the regular YouTube search. By stealing the uploads playlist IDs, it would be possible to watch a load of unlisted videos for the victim account.

This bug was fairly high level; a purposeful bypass for the SOP by YouTube resulted in a major issue. The author finishes with a quote that I can not agree with more: "In my opinion, the more you understand a system, the more ideas about how to break it will just naturally come to mind."

This vulnerability was used as a challenge in the Real World CTF at the beginning of 2021. The challenge came with a hint that sent people to the SCSI driver.

The SCSI device implements a simple state machine with a global heap allocated buffer. When initiating the state machine, we can set the buffer size and the state machine will set a global buffer pointer to point to the start of said buffer. From there on, we can either read one or more bytes, or write one or more bytes. Every read/write operation will advance the buffer pointer. This means that after reading a byte from the buffer, we can’t write that same byte and vice versa, because the buffer pointer has already been advanced.

This driver has some simple operations. Mainly, read/write a byte and read/write a string. The driver has logic in place to ensure that this global heap buffer is not written out of, but the logic is flawed.

There is a sanity check to ensure that no operation exceeds the maximum size (read/writes). However, this is the wrong check. Instead, it should validate from what is left! An example is that there are 40 bytes in the buffer. If we are at offset 30, it should validate that we do not read/write more than 10 bytes (for a total of 40).

A repercussion of this bad input validation is an integer underflow on the cbBufLeft(size left in buffer). Because this wraps around to a very large number (when it overflows), this creates a buffer overflows on read/write operations after this point. With this overflow, we have a linear heap write/read.

In order to exploit this, a special driver was made. To make their lives easier, the driver just acted as a way to funnel data from userland.

With this primitive, it was time to get all of the leaks necessary for code execution. The first order of business was to find an object that was suitable for exploitation. The author was looking for a pointer to a DLL, heap addresses and function pointers; the HGCMMsgCall was used to spray this.

This works well for the code leak from a function pointer in a VTable to break ASLR for the object. The heap leak required viewing two objects within a linked list in memory in order to understand their relative location in the heap.

To gain control over the RIP, we just alter the VTable pointer that we used earlier for the code leak. However, code execution and RIP control are two different things.

JOP (jump oriented programming) is the only option because there is no control over stack registers. This requires good register control, in most cases. Here, the authors of this exploit only had control over the r8 register.

With control over the r8 register, a JOP chain was used in order to get control over the RSP register to control the flow of execution for future iterations. Eventually, this led to a ROP chain that leaked an address of kernel.dll in order to call WinExec().

This VM escape was pretty amazing! It goes into many common issues with Windows exploitation and how to get around them.

Lucee is a dynamic, Java based, tag and scripting language used for rapid web application development. It is a common backend to use to many applications. The CMS that Facebook was using on these sites, used Lucee.

While testing on Lucee locally, the author found a misconfiguration that allowed for the execution of arbitrary ColdFusion files. There was an authentication misconfiguration of Lucee for the CMS.

Using imgProcess.cfm (with the auth bypass described above), it was possible to upload a file to any location because of a directory traversal vulnerability. However, this is NOT as simple as it seems! The firewall blocks the string ../ by default.

Using the same authentication bypass as before, there is a bunch more functionality. One of these is the ability to copy a file using an absolute path.

Using the arbitrary file write and the arbitrary file copy (with absolute paths) in tandem with the auth bypass, this leads to remote code execution by writing a shell script!

The above vulnerability only existed in imgProcess.cfm, which was in older versions. So, another vulnerability had to be found in order to make this work.

ext.applications.upload.cfm had another arbitrary file upload, with the same auth bypass as before. This endpoint accepts .lex files, which are just zip files for lucee extensions.

Once the zip file has been uploaded, another odd feature of the program can be used. This feature is that the zip, file and other URIs can be referenced. With this, the zip file can be unzipped in the webroot of the application, causing a code execution again.

In order to get this to work, intruder had to be used! This is because a load balancer was being used, which directed traffic to different hosts.

Besides the actual finding, a few things caught my attention. First, the firewall actually made a large impact on the exploitation of this vulnerability. In the future, I may consider asking clients to implement this as a defense-in-depth measure.

The other important thing to note was that this was a 0-day in the CMS and lucee, not an issue with Apples product. Yet, Apple still played 50K bounty for this!? They do not own the product, but they still paid out. In the future, finding vulnerabilities in important software used by companies may get a payout, even if the software does not payout.

Have a SSRF vulnerability that is blind? How do we exploit it!? Although it is not always possible, there are multiple ways of going about it.

This blog post is a huge list of blind SSRF techniques. Here is a quick reference list:

• Elasticsearch
• Weblogic
• Hashicorp Consul
• Shellshock
• Apache Druid
• Apache Solr
• PeopleSoft
• Apache Struts
• JBoss
• Confluence
• Jira
• Other Atlassian Products
• OpenTSDB
• Jenkins
• Hystrix Dashboard
• W3 Total Cache
• Docker
• Gitlab Prometheus Redis Exporter

Some of the above can get you code execution, while others cause DoS issues.

CodeQL lets you query code as though it were data. Using this taint analysis can be done in order to find anti-patterns.

The author used a CodeQL query in order to track user controlled sizes being used. Although this is NOT a vulnerability by itself, it is a good pattern to follow to find bugs. After running this query, several data points were returned, with a single one leading to memory corruption.

While parsing a frame, two main bugs occur. First, the header length is subtracted from the buffer, even if an invalid packet was sent. If this size was smaller than the subtracted value, this turns the value into a large positive number.

The second bug (with the size) is that an allocated buffer is created from the size passed in, but not restricted to this size. So, while uncompressing the data, an overflow occurs in a linked list structure.

To me, the interesting thing was the usage of CodeQL. CodeQL did not discover the bug. But, it gave a nice place to point in order to look for bugs. I may be adding to this my toolbox in the near future.

SerenityOS is a free and open source operating system created by Andreas Kling. It is designed to be a Unix-like operating system that draws inspiration from the graphical user interface of the 1990s. This was found during a CTF in 2019.

SerenityOS attempts to validate the location of syscalls, if a pointer is passed in. If the memory is not properly mapped, then an EFAULT status code should be returned.

The issue is that this validation allows for too mucg. Instead of validating if the memory just exists in the user process, it also accepts valid pointers into kernel space! So, this is essentially an arbitrary read/write built into the syscalls.

Additionally, dmsg (kernel debug messages) will just output the kernel stack addresses. So, at this point, we have a kernel address stack leak and an arbitrary read/write primitive into the kernel. This looks good enough to me!

In order to exploit this, the author forks into two processes. In the child process, the program goes to sleep. With the parent process, the author reads until they find the stack addresses they are looking for (from dmesg). Once it finds the right address, it uses the arbitrary write primitive in order to overwrite the return address of the child process.

The child process return pointer is then sent back to the userspace program (which you should not be able to do). With the ring0 process, we have access to all kernel-level functions. To solve the challenge, the author loads a block device and reads from it.

In order to fix this, the address validation is now only done for userspace pointers and not the kernel ones. Additionally, a check was implemented that only allows userspace writes by checking an expected program mask.

For the dmesg leak, SerenityOS made a few changes. First, running dmesg now requires a root account. Furthermore, the author is attempting to find all memory addresses leaks in dmesg and leaking these. However, there is value in having addresses available for the users for debugging. So, if root, you can probably leak kernel space memory still.