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!
Applied Cash Eviction through ATM Exploitation
Trey Keown and Brenda So - Red Balloon Reference →Posted 5 Years Ago- Who doesn't want to get all of the money off of an ATM!? Clearly, this is the hackers dream.
- The most impressive part of this talk was the reverse engineering of the ATM and just getting the thing to work!
- The first step to reversing is figuring out what is on the device. Originally, they desoldered the chip on the ATM but eventually broke it. However, they found out the firmware was publicly exposed and ready for download. Additionally, the device had an exposed JTAG interface which worked quite well. Moral of the story: try the easy stuff first!
- Now that they know how the device works (after reversing the firmware) they wanted to be able to run their own custom code on it. So, they decided to alter the kernel DLL's so that the signature validation just returned true.
- However, the ATM still did not work :( . They realized that the payment processor was not hooked up to the ATM. In order to get the ATM to work, they had to reverse engineer the Triton and write their own server to interpret to communicate.
- What else can we do? They created a custom OS to put on the ATM and several things running, including their CTF and DOOM (of course).
- The first thing an attacker should probably do is see what external services are exposed on it. They noticed a Remote Management Service (RMS).
- They decided to fuzz this (via Boo Fuzz) and found a buffer overflow because of a static buffer. How did they know what had happened? They could see crashes occurring over the JTAG interface.
- With NO ASLR or NX bit on Windows CE, it was easy to write shellcode to take control of the device over the RMS interface.
- From reviewing the register keys, they found what the some of the other open ports actually did. They found an XFS (extensions for financial services) interface. They smelled money and decided to take on this interface!
- In order to interface the communication (would be easy with Wireshark but NO Wireshark on Windows CE). So, they had to use JTAG to hook into the socket information in order to sniff the traffic. However, the traffic was not easy to see.
- Good thing, it is trivial to replay packets! They eventually reversed the XFS interface and wrote Python scripts to communicate over XFS. You can run any XFS command on the device! :) This means you can dump out all of the money and the ATM!
- Overall, amazing research and reverse engineering of the ATM. It was a crazy amount of effort to just get the thing working!
- Vulnerability #1 lies within Authd, which is part of an open source framework that handles authorization, authentication and privileged process spawning. While looking through the source code, a funny function group of code was noticed that copies the security entitlements. This code just copies the entitles without doing a signature check!
- This means that arbitrary entitlements can be created and sent to Authd to give those permissions away. Although this entitlements should be used all the time, several Apple specific frameworks ignore them and just require a password.
- There are a list of privileges that the author found to be usable without the password check from other frameworks. The important one (that actually worked) was system.install.* rights. This only allows for Apple signed packages to be installed at arbitrary locations :( So, we will need another bug.
- Several Apple signed packages exist online that are sort of weird! Eventually, after scouring the internet, a package was found that had a command injection as parameter 3 of a bash script, which could allow us to escalate up to a root.
- Now, on to the final vulnerability... SIP (System Integrity Protection) is used to ensure that only Apple signed binaries are run and do not alter important parts of the Kernel, such as the OS. The kextutil is what is used to load Kernel extensions.
- When kextutil loads a kernel extension it does the following:
- Copies the kernel extension to a non-modifiable directory, which is SIP protected.
- Verifies the signature of the extension.
- Reopens the extension to load and start it.
- There are TWO points here where the file is opened: it is opened to verify and opened to run! So, there is a classic time of check-time of use (TOCTOU) bug here! If the file is altered after the signature check, then a non-verified file will be ran! Because we have root permissions from the first two vulnerabilities, we can alter the file prior to it loading :)
- But this is not deterministic, is it? We are training to win a race here. Well, there is an awesome trick that the author used to always win the race! The kextutil function has a built-in interactive mode for loading kernel drivers. While loading the driver with the interactive mode, the signature is verified. Now, all you have to do is alter the driver to be whatever we want, load it in the interactive shell and we have kernel code execution! This interactive nature makes it trivial to hit the window for altering the file.
- Privilege escalation in OS's does not always have to be memory corruption! Sometimes, it is just poorly written logic in multiple places that allows for this to happen.
Script Gadgets! Google Docs XSS Vulnerability Walkthrough
Live Overflow and Others Reference →Posted 5 Years Ago- Live Overflow interviews the finder of a XSS in Google sheets and some Google Engineers on why this existed. Super interesting to hear this from both sides!
- The researcher found this bug several years ago in the Google Visualizer. The JavaScript library is closed source but the researcher reversed the obfuscated JavaScript! This proves, to me, that reversing difficult things provides much fruit.
- The bug involved an arbitrary object constructor that was found in JavaScript. It turns out that passing a function to this also executes the function! This has then created an XSS gadget.
- This bug was originally fixed but removes the worst gadget (executeFromURL) and forcing an allowlist on the allowed parameters in it. However, this vulnerability discusses a place where this regressed to remove the allowlist.
- By specifying a particular type for a chart, it was possible to register a postMessage listener via the arbitrary constructor bug. The postMessage function is used for cross-domain requests between pages.
- This postMessage handler took a URL and placed the code into a script tag! This allows for an arbitrary script to be injected into google docs!
- Wow.. simply an amazing find. Watch the whole video if you want to hear from the researcher himself and the Google Engineers.
- The Boot process is what actually brings up the Operating System once the computer is starting up. GRUB and UEFI are primary examples of this.
- Why is this important for security? If this is compromised, then there is NO trust on what is running on the OS, drivers or anything else that is being ran on the computer.
- To enforce this, the boot process keeps a list of cryptographic signatures to verify if a piece of code should be allowed to run or not. There are two DBs: one that allows certain components and one that specifically disallows. Additionally, these certificates (used for signing) derive from the Microsoft Root Certificate. For more information the chain of trust for bootloaders, please visit here.
- With the background out of the way, we can dive into the bug! The vulnerability is one that is just as old as computers: a classic buffer overflow. The vulnerability occurs in the grub.cfg file, which has configurations for the bootloader to use. The file is a good target because it is not signed (because it SHOULD be changeable) and is alterable from an administrative user.
- This file gets parsed as a Domain Specific Language (DSL) uses flex and bison to generate a parsing engine for a domain-specific language (DSL) from language description files and helper functions.Although this is great and all (as it is much more modular), a dynamic language interpreter is going to be vastly complex.
- What's the error exactly? The interpreter expects for all error messages being called to exit. However, instead, it logs something to console and continues execution. Because the execution continues with unexpected values, there are many places for memory corruption.
- It should also be noted that the Bootloader does not have modern memory protections to defend against attackers, such as NX and ASLR. So, once an overflow has been found, it is trivial to jump to shellcode and control the flow of execution.
Bypassing the OS X Transparency, Consent, and Control (TCC) Framework For User Data
Matt Shockley Reference →Posted 5 Years Ago- When sensitive data needs to be taken from MacOS, a big text box appears asking for permission to see. When permission has already been asked for and agreed, the permissions are no longer asked for.
- The permissions are stored in a database on the local file system. In order to access this database, you must have the tcc.manager permissions.
- The bug is actually pretty trivial! When attempting to access the DB, is checks for the database in the $HOME directory! See where I'm going here? The $HOME directory is an environment variable, which is editable by the user.
- So, by launching a terminal with a custom home directory in the $HOME env variable, it is possible to have trivial write access to the database. Hence, this can be used to bypass all TCC restrictions to access all sensitive data!
- This acts primarily as a privilege escalation on MacOS to access sensitive data.
- Overall, this was a classic bug! A relative file path, or a partially controlled file path should not be used! It's important to either have an absolute path or have the file path not be alterable in this type of context.
- VirtualBox is a virtualization software that is quite popular, as it is open source and free. Finding vulnerabilities in VirtualBox is a big deal because it allows for a guest to host escape.
- The author claims that hunting for bugs in VirtualBox is a good idea because you learn a ton about operating systems, virtualization in general and all guest to host escapes are very high impact.
- At the beginning of the article (in the Recon section) there are quite a few links to learning about VirtualBox and other bugs found in VirtualBox.
- The author went hunting for bugs in the TCP/IP stack. This is because this code is very complex, as translation of requests has to be done on the fly from guest to host.
- Via fuzzing, two vulnerabilities were found. One was an Out Of Bounds read via an unvalidated length (which ZDI reported as RCE for some reason) and a DoS via NULL pointer dereference.
- From reading the source code, the author found another bug! With a bad ICMP packet, the data would have already been freed. This code goes into a default case of a switch statement, which falls into a Free happening. This default case should have a GOTO to DONE instead. But, why is this a big deal? A double free vulnerability!
- In order to put this into a triggerable place, a race condition has to be won. Another thread has to allocate a buffer after it has been freed for the first time but PRIOR to it being freed a second time. Now, we have an exploitable double free vulnerability!
- The race is hard to win though... in order to win the race, the author wrote a Kernel driver to trigger the bug but never wrote a full PoC, as winning the race comes down to a few microseconds.
- Cross Site Scripting (XSS) is where either HTML or JavaScript can be added to the content of the page in order to change the look or code flow of the website. XSS can have very serious effects, including account takeover and the execution of arbitrary actions as the user of the XSS'ed page is running on.
- The main way to defend against XSS is to encode and output HTML encode all untrusted input, such as turning < into <. However, manually trying to escape all characters is difficult to do and, more often than not, can be bypassed.
- In recent years, frontend frameworks, such as React and Angular, have started automatically escaping HTML in order to take the burden from the user. Because of this, XSS has taken a major turn, in terms of relevance, on these types of sites.
- However, there are several cases that these frameworks cannot defend against. The article is just a cheatsheet for React XSS issues.
- The mitigations being added to GLibC for single linked lists (tcache and fastbin) was quite substantial! It added pointer mangling to make overwriting the fd pointers much more difficult. In most cases, a heap memory leak or a terrible brute force must be done to bypass the protections.
- TCache is the main focus of this bypass. To understand the bypass, the TCache must be understood. TCache has four fields:
- prev_size: Size of the previous chunk, if the previous chunk is not in use.
- size: Size of the current chunk, with the last 3 bits being used for metadata.
- fd: Ptr to the next chunk in the linked list.
- key: Double free protection. The value is set to the beginning of the TCache.
- Finally, the TCache is actually stored on the heap. With the above knowledge, the exploits should make sense. There are two main arrays used for storage: count and pointers. The count array holds a list of the amount of items in each linked list. The pointers array is an index of head pointers to linked lists.
- The article above explains a way to bypass the pointer mangling altogether though. The bin (head of the linked list) is not mangled. So, if we could alter the bin, it would be possible to bypass the pointer mangling.
- First (the most obvious) way is to have a negative indexing bug that allows for the ability to write backwards in memory. By editing the two important fields (count and linked list head) it is possible to write the entry for the head of a tcache bin.
- The second and third bypasses are all about abusing the key field of the TCache, which is a pointer to the beginning of the TCache. The requirement is that there is a use-after-free (UAF) on the chunk. Then, the second index (8 byte offset on 64-bit) stores a pointer.
- If the second index is then dereferenced, it will be pointing to the TCache! With an offset to this pointer, we can write to the count array and the pointer array.
- The third one is very similar. Instead of using the pointer to access the TCache, we could also free the pointer. Now, the very beginning of the TCache has been added as a valid chunk to a bin. When another chunk is allocated, then it will point to the beginning of the TCache, allowing for edits. This is similar to a House of Spirit attack.
- This was an interesting bypass for the added mitigations! It requires a very specific set of criteria but may be useful :)
- This Reddit post dives into how the Android file system actually works.
- The severity of a vulnerability is complex but comes down to two main things: how easy is the vulnerability to hit and how widespread is the vulnerability. DNS, the phonebook of the internet, is used for essentially everything on a device. Finding a vulnerability in DNS is a MAJOR deal, as it is on all Windows devices and is trivial to hit.
- The ability to trigger the bug required setting up a malicious DNS server that pertained to a particular domain. So, by clicking on a website, the DNS server that we point to does not know the IP. So, it forwards the request to something that does. Now, when this domain is looked up in the future, it will by default go to the domain.
- The vulnerability is actually pretty straight forward... By sending a very large SIG response an integer underflow vulnerability occurred on the RR_AllocateEx parameter. This integer overflow occurs because it expects a maximum size of 16 bits, which results in the code using only part of a register (cx instead of rcx). What can we do with this?
- Later on, the data is copied into a dynamic buffer via a memcpy. This results in a heap-based buffer overflow!
- However, this was not trivial to trigger... UDP DNS requests have a limit of 512 bytes. So, the team read into the DNS specification and found a way to trigger this integer underflow after several tricks, including DNS compression, to smuggle in a large enough size.
- To make this exploitable in the browser, they had to smuggle a DNS request within an HTTP POST request. By abusing several obscure features of DNS, this is again possible.
- For the purposes of exploitation, it is important to know that the binary is compiled with CFG (Control flow Guard). This makes the exploitation harder, but not impossible. Without CFG, this would have been trivial to exploit.
- With CFG on, they needed an information leak and an arbitrary write-what-where bug. The leak was done by corrupting some metadata on a DNS resource entry. Then, when a query was made back to the DNS server, the memory addresses were recoverable.
- For the write-what-where primitive, they choose to corrupt the metadata associated with a free-list heap chunk. This allowed them to control the next location for where a heap chunk was going to be allocated at. If this location was in their control, this created an arbitrary write-what-where primitive.
- To bypass CFG, they corrupted a stack return address, instead of a vtable entry or something else.
- Overall, they overcame many hurdles! From the tiny case where the actual vulnerability was hit at to the DNS smuggling, they overcame quite a bit. Amazing research and write up (as usual) from Checkpoint Research.
