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!

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.

VoIPmonitor is open source network packet sniffer with commercial frontend for SIP and our protocols. The authors of this find a vulnerability in this popular software.

The author used their open source tool sipvicious to fuzz the SIP protocol parsing. Initially they got no results. However, after turning on the live sniffer, they found a crash almost immediately.

The bug was a simple buffer overflow in a fixed size buffer by blindly adding the data from a header into the array. The REGISTER header had this vulnerability in it.

The make file of the project showed lots of binary protections. But, the actual release of the product had NONE of these turned on! So, the pwning of a simple buffer overflow was live :)

The exploit overwrites the RET address on the stack to point to a ROP gadget. This ROP gadget increases the value of RDI to point to the place of the overwritten packet, which has user controlled values! system takes in a single parameter. Once this is controlled, we can pop a shell!

This is confusing because LibC would be randomized with ASLR but they use a ROP gadget later to increase the value of RDI to an attacker controlled location. Regardless,the author could have referenced the PLT entry for system instead with ASLR on the system and not PIE.

Overall, I really liked this post and enjoy the content this company puts out. I love the logo of a man screaming into the phone; you know this is a group of hackers when you see that!

Microsoft Sharepoint is a product that integrates with the rest of the office suite, including Word. It is very common at the enterprise-level for Microsoft houses.

A replay attack is about taking a legitimate message and using it again. The idea is that the message is authorized for the one action but this does not prevent usage from an attacker once it has been seen.

Another attack is insecure deserialization. Within complicated applications, it is common to receive or process serialized objects. These objects can be code, integers or anything else. Sometimes, the process of deserializing this can lead to code execution.

Sharepoint had a deserialization in the code for specific non-user controlled objects. However, the serialized data is not directly controlled by an attacker. If we could trick the system to use our input for this state functionality, we would have easy code execution.

The session state and stored file information are stored in serialized formats. By abusing this fact, we may be able to trick Sharepoint to deserialize the stored file information as the session by changing an identifier.

The steps in the article are sort of confusing... but, the idea is we can trick the application to follow the insecure deserialization path for the session handling with the file functionality. By making this happen, we can get code execution with our user controlled data.