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!

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!

Where does one request start and another end? There is an issue in implementations of the HTTP protocol that gave wind to a vulnerability known as HTTP Smuggling. The author of this article expanded on this research and found a similar issue in HTTP2 in Cleartext (h2C).

Additionally, another researcher had discovered the ability to smuggle requests over websocket connections to bypass reverse proxy access controls in this article. The issue was triggered by upgrading a websocket connection.

Typically, HTTP/2 is initiated with a TLS negotiation. However, an HTTP/1.1 Upgrade header can also be used for cleartext communication, even when TLS has already been established. The author had to create a custom client in order to test this.

The author of this article wanted to see if the protocol upgrade issue on websockets could also be used with HTTP/2 protocol upgrades. So, they setup an Nginx configuration that denied access to a specific route (/flag) but not others. Making a direct request to the /flag route would return a 403 error.

By doing the following steps, the technique worked:

1. Client submits an HTTP/1.1 upgrade request the proxy.
2. The proxy forwards the Upgrade and Connection headers to the backend, which responds with "101 Switching Protocols" and prepares to receive HTTP2 communications.
3. Upon seeing the 101 response from the backend, the proxy upgrades the connection to an unmanaged TCP tunnel.
4. Using HTTP/2 multiplexing, a request is made to /flag and the data is returned because the the proxy is no longer monitoring the tunnel.

The crux of this issue is that the connection has turned into an unmanaged TCP tunnel. So, proxy servers need to not pass thru the Upgrade and Connection headers during the call to the backend. By default, only three proxies DO exactly this, while a large amount of them don't but can be configured to.

Bypassing access controls via tunneling is quite clever! The author took existing research and applied it to their own area; it definitely pays to read and apply small changes to existing research.

Richmedia Studio is a platform used to manage online advertisement campaigns. This includes HTML pages, videos, pictures and other assets.

The first vulnerability was an IDOR on the uploaded pictures for a 'preview'. The request took no authentication (it's on another domain) and only had two random values. The first one was correlated with the user accounts ID and the second was the upload time. Using this IDOR, it was trivial to find other assets on the application.

The platform supports multiple user levels, where there is an administrator on the site. By using a user with NO access to anything, a single forced browsing technique could be used to see the campaigns. To make matters worse, this could be used to see campaigns in other accounts!

The author claimed that the cross-account campaign viewing did not work for admin-to-admin accounts. For some reason, a user with no permissions at all could see the items cross account and in their own account with forced browsing. This appears to be an odd fail to true bug.

The author found several more IDORs for campaign information and authorization issues, but does not elaborate on it too much.

The old-school PS1 and PS2 consoles have had hardware exploits with modchips but never software mods to allow the playing of arbitrary games. This is a software exploit for the original Playstation console.

The software mod uses a buffer overflow that is quite common save state functionality. By modifying parts of the save game state on a memory card to be an extremely large string, it causes an insecure snprintf to occur in a stack buffer.

With this buffer overflow, the EIP can be overwritten on the stack to jump to customized code for the customized loader. This first stage loader is used in order to get the console back to a working state to load games.

Besides fixing the game console to load games, the loader changes the configuration of the console itself! The console has DRM protection to make using copied games impossible. The exploit code disables the verification on the cd loader with undocumented CD commands found at here to allow copied games to be used.

The save game exploit works in several games in the Tony Hawk franchise but has been discovered in a few other games as well.

The older consoles are being taken down, hard! With modern consoles, the Xbox 1s security has yet to be broken but the PS4 and Switch have been taken down. When security is done properly with no way to see inside the box, it is hard to get in.

Being able to understand the external techniques of hacking (and all other aspects of life), is important. However, the author of this book makes the claim that we over focus on the outward and forget the inner or mental game. This book is how to work at peak performance all the time, as well as how to learn fast.

There are two inner selves that we must deal with: self 1 and self 2. Self 1 is the brain and self 2 is the body. The body is amazing and learns stuff quickly; the brain is a skeptic, over analyzer and tries to take all of the credit. The goal of the inner game is to calm self 1 and rely on self 2.

We always say "Kids learn languages better... start kids on new languages when they are young" But why is this? Clearly adults are much more capable of learning! This comes down to how we attempt to learn.

Kids naturally let things come to them; they do not think about how they are learning. They simply do an action, observe the outcome and naturally adjust; this comes from doing things yourself and watching others. Adults use flashcards, read books and so on. The kids natural learning is how the book recommends we go about learning.

For example, let's take golfing. Normally, somebody would focus on the placement of the feet, the speed of the swing simple and 200 other things. Instead, focus on where you want the ball to go and observe the outcome without judgement. If you observe the ball sliced too far to the right, tell yourself this without judgement; your body will naturally make the change the next time you swing. I did this recently with golf and was amazed but how much better I was at the game!

The second major part of the inner game is focus. During a game (or anything else), we are worrying about so many things. For instance, what's for dinner that night, how you are having a bad game, how good the other players are... what if we just focused on the game?

In Golf, focus on the location of the ball, the surroundings of the course, the distance to the hole; worrying about other external things does nothing for you in the moment.

Growing up, I played a ton of baseball and basketball. Now, I play mostly dodgeball and wiffleball. The best moments that I had in sports 100% fell into this category.

A good story comes from dodgeball. I was an outsider in a large dodgeball tournament where the previous year I had taken last in the 1v1 tournament. Because I had nothing to lose and did not know anyone, I simply focused on the game itself. By some miracle, I took 2nd place and won 5 straight 1v1 games versus better players. The following year, I was focused on reputation and lost in the first round.

This book showed me the proper way to learn and the power of true focus. I had never fully understood this until now. These lessons go passed sports however; these lessons can be implemented in many parts of life.

In the inverse, trash talking to get other players out of the focused zone is a good strategy.

Recently, Github had a security report that a couple of users had been logged in as the wrong users. This sounds absurd but this is what happened.

After reviewing all infrastructure and code changes, they came to the conclusion that only the response of the request for the session cookie was wrong. How could this be though?

One of the recent code changes moved the logic to check a user's enabled features into a background thread. Additionally, error reporting from the background thread to the main thread would show information about the data from both threads. Although this was not a direct issue, it's still very odd.

In Unicorn, the underlying Rack HTTP server on the Rails application, the ENV object is the same for reach request (global variable). This global variable is changed between threads via the Hash#clear function. This, combined with the error reporting led to the sharing of data across requests.

If an exception occurred at just the right time and if concurrent request processing happened in just the right sequence across multiple requests, Github ended up replacing the session in one response with a session from an earlier response.

Github worked with Unicorn to have new requests use their own ENV hashes. Additionally, they removed the threading issue that had existed in the code.

I really enjoy the transparency of Github to explain an issue that occurred! It makes me trust them more now that they take security seriously.

This is the first of a series of posts on a full Android exploitation chain: from browser, to sandbox escape to kernel breaking. This first article only looks at the Qualcomm kernel vulnerability.

The author took a look into the kgsl driver because it is directly accessible from userland. Very few drivers can be reached directly from the apps itself, which is what made this a juicy target. The vulnerability itself lies in the IOCTL_KGSL_GPUOBJ_IMPORT and IOCTL_KGSL_MAP_USER_MEM iotcl, which these calls are used by apps to create shared memory between itself and the kgsl driver.

While handing this iotcl call, there are multiple memory allocation methods that can be done which triggers different logic. By using a type-confusion on the type of memory being used, a failed path on the call can lead to a freeing of this memory that should NOT be freed. This created a use-after-free (UAF) in the kernel.

With the UAF on the sg_table object, any call to DMA_BUF_IOCTL_SYNC will trigger a UAF. This object is quite diverse in its usage, depending on the function called and the values of the table. The functionality of this iotcl is to synchronize the CPU view of the DMA buffer used by the GPU.

With the UAF, the author allocates a similar sized object in the kernel to get control of this memory. But, can this be useful in our vulnerability iotcl? One of the paths in the syncing function uses a list with a specified size. The pointer being referenced is validated for the location and the size is NOT validated. This looks like a semi-useful for a read/write primitive.

With control over the table but NO leak, we need a candidate object to replace the scatterlist field in the sg_table. Using a CodeQL query got them some candidate objects but not anything that would work. To find a proper object to fill this gap, another technique had to be used.

The original bug created a UAF that was not powerful enough. So, by using the original UAF the author created an additional UAF but only on the scatterlist. This was done via some trickery on threads but freed values that should not be freed; these are not bugs in the code but the first UAF made this an issue.

With this threat trickery came what appeared to be a newly impossible to win race condition. Using a technique of queuing and scheduling made this race condition achievable though!

The Software Input Output Translation Lookaside Buffer (SWIOTLB) or bounce buffer is a not-so-popular section of memory that handles proxied request between the DMA buffer to allow access to it from another device. This buffer is located at a fixed point in memory, depending on some Android kernel settings. This is where the path for the UAF occurred at.

By using forcing SWIOTLB memory to be allocated via some trickery, we can point the DMA buffer to a location that is controlled by the attacker from the UAF. Now, we have the ability to read/write to anywhere we want BUT we do not know WHERE to write. I am a little fuzzy on how this part works to give us the read/write primitive though...

Using heap feng shui, we use the OOB read via the UAF to read memory from a DMA buffer that is controlled. By using patterns in the memory of the FILE structs in binder, we can determine where the proper spots in memory are at.

By setting a FILE struct to our controlled memory location, we can point this to a fake file_operation to run arbitrary functions of our choice. With the kernel though, code execution does not mean game over; these is still another step to take.

By calling the function __bpf_prog_run32 Berkley Packet Filter bytecode can be used for an arbitrary read/write/execute primitive in the kernel. There was some mitigations in place that make privilege escalation harder but they are bypassable (just not done in this post).

Dropbox does a lot of obfuscation and encryption on the network traffic and native clients. The native client uses Python, but a heavily altered version.

The main Python interpreter (pyc file) is encrypted and the author could not find the key. Because of this, they altered a library to add a backdoor into it. Using this backdoor, it was trivial to execute code in the Python interpreter now.

Several of the features that make Python easy to reverse were removed from the interpreter, such as co_code. Additionally, the Python disassembler had been removed. Finally, all of the opcodes had been completely remapped!

So, Vincent decided to remap the remapping! The idea is to take a common library, such as socket.py and do an opcode comparison to find the mapping changes. However, to even do this, the code objects had to be decrypted, which was done via some reverse engineering and scripting.

After the decrypting and remapping of the opcodes, the author could use the uncompyle6 tool to get back the original Python source code.

With the ability to patch the files now, they turned on debugging functionality and added the ability to inject code into the Dropbox process.

I really enjoy this article because the amount of references made to previous work; it makes me feel that we are standing on the shoulders of giants instead of figuring everything out for ourselves the first time.

After being able to inject JavaScript or HTML, most people just leave it there. But, what if you could only inject HTML and no JavaScript because of a secure CSP? Can anything be done?

The example of this is a parameter being reflected onto a login form. The site is Froxlor.

Using ONLY HTML contents, we can still leak some data; this technique is called dangling markup. In this case, the base element is used. This is because base will change the default location to send requests to.

When the user logs in to the site after clicking on the link with the dangling markup, the login request will be sent to our attacker controlled domain! So, an attacker now has access to the credentials of the user!

Using the base tag is one example of how this could be exploited; there was likely otherwise HTML could be used to perform actions, phish or leak data.