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 Pokewalker was a pedometer that was released with Heart Gold/Soul Silver in 2010. Since then, people have been trying to reverse how the device works without success. Dmitry (an crazy reverse engineer who works at Google) took on this challenge.
- The first part of the article goes over the hardware of the Pokewalker. It appears that this was mostly from online and publicly available data sheets.
- The Pokewalker communicates over infrared. Crazy enough, the Pokemon game cartridge itself had the IR hardware, not the Nintendo DS! To reverse the protocol, the author just recorded a bunch of traffic and correlated it with actions happening in the game.
- The SIR signaling at 115,200 and 8n1. From there, it was time to decode the protocol. The data had a bunch of 0xAAs and 0x55s. Normally, the most frequent data being sent is 0x00s and 0xFFs. So, the author deduced that the bytes being sent were being XORed with 0xAA. The packets had a header with the command type and length, then a custom implementation of LZ compression.
- So, the real question is how do we get in? The EEPROM chip is used to store data and can be read out easily using SPI. In-circuit debugging is supported, but chip will self-erase if programmed, so no way to dump it that way. This makes the situation really hard, as we are attacking blind!
- Dmitry has a good motto: "assume that any code you encounter was written by a drunk student." The main point of entry is through the IR. What can we be done here?
- The author messed with the compression algorithm, trying to find the mistakes of a drunk student. What could be done to a compression algorithm?
- Change the size of the decompression.
- Decompress to a larger size than expected.
- Double compression attacks
- To make this more exploitable, the decompressed buffer follows the compressed buffer! So, if the decompressed data is also valid compressionable data, we can keep decompressing. For sure, using this technique, a crash of the PokeWalker occurred. But now what?
- From brute forcing the offsets, the author figured out where the stack pointer was. Then, with such a small address space and an executable stack, the author wrote a payload to brute force this location. Now, we have code execution!
- Using the IR transmission in the shellcode, data can be leaked! Using this (and restarting after the watchdog timer), the entire ROM can be leaked.
- The rest of the article goes into the reversing of the ROM and the rest of the commands. This is an incredible article where a completely random attacker gets code execution with no prior knowledge. One for the ages!
- When asking for help on most Google products, it is possible to send a screenshot of the issue. When implemented, this was done by using an iFrame to handle this information then sending the data via a postMessage request.
- At first, the author tried getting XSS on the domain but after numerous hours of trying failed. So, they tried playing with the postMessage configuration and see what was going on.
- It turns out, that if a page is iFramed, we can change the iFrames
location. If the page can be iFramed, this really messes up the iFrame security of a page. - So, the attack has a few steps:
- Load the page in an iFrame (Google Docs does not have iFrame protections).
- Edit the location of the Google Doc to be your page.
- Send the help message.
- Your screenshot can be hijacked!
- Why does the changing of the location of the domain actually help? When sending a postMessage, a reference to the parent window where the request is being made is sent. When doing this, it is important to specify the domain to send this to. However, the page does NOT set this and just has a wildcard ('*').
- Now, with the changed location of the iFrame, we can hijack all of the data being sent in the screenshot!
- What allowed this to happen? First, the page itself could be iFramed. Using headers to prevent this could have prevented the attack. Secondly, the postMessage was not sending to a particular domain --
windowRef.postmessage("","*");. Both could have prevented this. Awesome find!
Protecting Against an Unfixed Kubernetes Man-in-the-Middle Vulnerability
Yuval Avrahami Reference →Posted 5 Years Ago- Kubernetes is an open source container orchestration system. CVE-2020-8554 is a design flaw that allows Kubernetes Services to intercept cluster traffic to any IP address.
- This vulnerability occurs because a Kubernetes user is able to assign arbitrary IPs to their services. So, by selecting an IP that is already assigned to another endpoint, it is possible to intercept all cluster traffic to that IP.
- The most vulnerable state is multi-tenant clusters because they may have the vulnerable configuration. At the moment, there is no patch for this vulnerability.
- 3DS (not Nintendo) is a version controlled 3D modeling software used for developing satellites, rockets and many other important IP.
- By simply googling for
"chmod 777 /etc/environment"/etc/environment of the system allows for the executing of arbitrary shell scripts at reboot. So, this is just shell script code execution because of bad permissions. - Another interesting part of the article was actually trying to get this fixed. Who should you talk to? It turned out that the original creator of the software had been bought out by another company. So, all of their contact information was faulty. Eventually, the author got ahold of security people of the larger company and got the vulnerability fixed.
- For deployment-it-yourself products, viewing boot scripts and other things feels like a good way to find misconfigurations in the system.
- By including the
Request.PathInfoparameter with theSkipAuthorizationflag, all auth can be skipped on the API. With this auth bypass, arbitrary commands can be used on the remote machine to pop a shell.
- Joomla is a content management system (CMS), very similar to Wordpress. The ACL (access control lists) are what restricts who can access what.
- The ACL list could be bypassed by including a new ACL within a parameter for a request. Even though this user should have the ability to alter the permissions of a category, they can!
- In terms of exploitability, it is fairly unlikely. In order to edit the ACL, a user has to have access to the object in the first place. The exploit situation is having three having: super-user, manager1 and manager2, where the super-user controls permissions and only manager1 has access to the resource. Manager1 could alter the permissions to allow manager2 to see it.
Insecure by Design, Epic Games Peer-to-Peer Multiplayer Service
Bill Demirkapi Reference →Posted 5 Years Ago- The author decided to look at the video game Satisfactory. This game had a unique feature: peer-to-peer multiplayer sessions. Once the hacker started analyzer, they realized that this used Epic Games Online (EOS).
- EOS has two user roles: GameClient and GameServer (backend usage). The GameClient has ReadOnly permissions to the server. So, what is a peer-to-peer client then? Well, it needs to alter the state of the machine. So, it is given the GameServer role if it wants to do anything interesting. This feels like a problem.
- An intermediate issue, that the author found, was that the EOS API had a filtering mechanisms for sessions. However, if this search had no filtering, then it disclosed a significant amount of information, such the local IP of other users and user IDs.
- The major flaw that was found with the GameServer role was the ability to create arbitrary sessions. Using the EOS API, an attacker can create a set of duplicate sessions in order to force users to join their own game, instead of somebody else's game. This is then paired with the ability to find sessions for games, with the GameServer role attached.
- This attack would allow for the hijacking of all matchmaking sessions to join a attackers session instead. This essentially acts as a DoS.
- The author got a bunch of push back on the vulnerabilities from the Epic Games side of things. I assume this is because they would have been difficult to fix, from a P2P perspective. However, Epic Games did add a new user role that was specific to P2P connections but still left the IP address exposed in the communication.
- The article seems to blow this out of proportion a little bit (it is a DoS with a small information disclosure). Other than that, the article is well-written and I enjoyed the analyzing of the Security model for P2P communication that stretched from the documentation to the actual implementations.
Exploiting a Single Instruction Race Condition in Binder
Maxime Peterlin & et al - Longterm Security Reference →Posted 5 Years Ago- In Android, interprocess communication is handling by Binder. Because this is a kernel-level feature that is accessible to the user, it is a very attractive attack surface.
- The bug is a use-after-free (UAF) while the todo list elements are being processed. Essentially, another thread could come in and free this object, while it is being processed. The patch inlines the function in order to make this happen in a single step.
- In order to trigger this bug, the following things have to happen in a very specific order in a very fast timeframe:
- A call to binder_release_work from the senders thread. This is the clean up routine for when a task is done under binder.
- A binder_work structure to dequeue from the sender thread's todo list
- A free on the binder_work structure from the receiver thread
- The timeline for this vulnerability is fairly tight. But, if done properly, it is possible to replace the binder node with another object to take control of binder itself!
- Android uses the SLUB heap allocator. This is important for triggering the UAF properly. In essence, they end up spraying 128 byte objects to eventually overlap with our vulnerable binder node. This is done by a technique described in a Project Zero post.
- Once the UAF has been successfully triggered, are we done? No, a few more steps must be taken in order to actually exploit this. Using the UAF, there is only one interesting path that can be triggered: freeing the object again (double free). Using this, the SLUB allocator will have the same heap chunk available for allocation twice. After dealing with a few specifics of handling the double free, it is time to overlap some chunks.
- The technique for spraying is super interesting! They solve the how do you know when the spraying has worked? By sending a bunch of signalfd (the P0 technique above), we can KNOW if the spray worked if the value is different than before. That is pretty nifty! They even have a straight forward diagram for explaining how this works for the overlapping process.
- With two signalfd's overlapping, it can now be used to leak KASLR, when another object is tied to the signalfd. With the KASLR leak, it is time to create the arbitrary read/write primitive. On Pixel devices, the Android OS has CFI, meaning that overwriting a single pointer is not enough to take control of the kernel.
- The authors use a technique known as Kernel Space Mirroring Attack (KSMA). This attack add an entry to the kernel's page global directory to mirror kernel code at another location that is accessible from userland. Pretty damn interesting!
- To actually overwrite the page global directory a heap corruption (from the previous bug) is used. The technique overlaps a signalfd onto another freed object. Then, overwriting the free-list pointer (similar to the fd overwrite in GLibC Malloc) to point to our page global directory. Once this pointer is there, we can set this to whatever we like.
- The mirror turned on, escalating to Root and taking the over the device is claimed to be fairly trivial. There is a read/write primitive in kernel memory; so, of course it is! The main thing is to set
selinux_enforcingto 0 and set the credentials of the current process to the inits process. - Overall, this was a very good article that went into the nitty-gritty details of binder and Android. This technique used a bag of interesting tricks to eventually gain control of the device, from a single instruction race condition.
- Most of the time, buffer overflows are exploited by using memory corruption primitives. With these cases, people will report a buffer overflow in some IoT device processing but a good chunk of these are not actually exploitable. For instance, you might need to brute force a stack cookie and defeat ASLR. So, no POC ever surfaces.
- In this case, a handler of the Connection header had a heap based buffer overflow in it. But, instead of leaving this as is, they went deeper.
- It appears that some sort of authorization data is being held near the connection header. Attackers learned that by sending exactly 29 A's that all authorization for all requests on the device were bypassed! Damn, defeating authorization with ONLY A's is awesome.
- I found interesting because it was a case of a buffer overflow leading to compromise without relying on deeper binary exploitation primitives. In the future, with all of the binary protections, this may be the 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.
- There is a race condition between setting up a new process and changing the UID on a SETUID binary. By using a well-timed call to the Ptrace API, it is possible to overwrite part of the executable being spawned, prior to the UID check occurring.
- In order to make the race more winnable, there was an action that happened after executing a call to
execvebut prior to the UID check being made. So, but running this action (unveil) a bunch of times, the race becomes more winnable. - With the ability to write code via Ptrace to this memory, you just write code into the process! However, it needs to be small, as the API only writes a small amount of bytes at a time. So, the author wrote shellcode that would run
setuid(0)to escalate privileges to root. Then, pop a shell by runningexecve("/bin/sh")with parameters passed in by argv. - During the actual analysis of the bug, the author of the OS claims that the issue is because the program is loaded THEN the process ID is changed in order to be a setuid program.
- In order to patch this, the
setuidof the program state is set prior to the program being loaded. At this point (of the setuid being set for the program), the original credentials are committed, making it impossible to use the ptrace API. Additionally, the loader is loaded at a random address in memory in order to force a memory leak to take place now. - It is cool to see OS issues in a less mature operating system. The issues in modern day Linux are complex and harder to understand from someone not deeply involved in the space. With this issue, it makes sense and did not take an expert to follow. A similar issue once existed in Linux with loading kernel modules!
- After the fact, several videos were released for this too.
