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 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.
Breaking HTTPS in the IoT: Practical Attacks For Reverse Engineers
Nathan Elendt - Bishop Fox Reference →Posted 5 Years Ago- HTTPS is becoming more and more standard with IoT devices. So, how do we modify/intercept traffic if we do not control the device itself? This is what the article is about.
- This article goes through three tricks for intercepting traffic without having control on the device.
- The first one: It Just Works. Simply put, just send the connection through a proxy that is controllable. This works because the library on the IoT device is not performing ANY validation on the certificate. This has worked 30% of the time, according to the article.
- The second one: the look-alike attack. Essentially, this is abusing issues with validating the Root CA in a certificate chain. The attack works as the following:
- Create a self-signed root certificate. Set certificate to be identical to Root CAs besides the self-signed aspect.
- Insert this as the Root CA for the Proxy
- Generate a new certificate from the Root CA and us this from the connection.
- The final one: the incorrect name attack. This one is also branded as the Ol' Switheroo. This works by generating a legitimate and valid certificate for something site. Then, simply using the valid certificate, just for the wrong domain.
- To make the chances of the last attack better, it could be useful to get something similar to the device that you are attacking. For example, if the site is
domain.comhaving the sitedomain.com.mydomain.comcould bypass the validation. This attack only works about 10% of the time.
- UBoot (in the non-secure version) is known to drop into a shell if the boot process does not work.
- Normally, the boot process works fine. However, by shorting out the data line at boot time, this can cause the bootloader to become confused and drop into a shell.
- What is particularly interesting about the attack in the article is that the chip is a mounted via a BGA (ball grid array). BGA has tiny little pieces of solder underneath it. Honestly, before reading this article, I did not think that this particular glitch attack was viable with BGA mounted chips.
- Once we have a shell in UBoot, the job is easy! Secrets are sometimes stored within UBoot variables. Additionally, we can add scripts to run on the host OS from UBoot. By altering these scripts, we now have a shell on the device OS itself (not just UBoot).
- Deral Heiland is one of the best IoT Hackers out there. He helps at IoT Village, works at Rapid7 and has done many, many talks/posts throughout the years. In this instance, he gives us a live demo of how he does things.
- UBoot is the main boot mechanism used on embedded devices. So, finding vulnerabilities in a device that allow you to boot in this way are fairly significant!
- UBoot is a unique compilation for each device it is on. So, features and things are majorly differ depending on the company using it.
- He shares a few tricks throughout this presentation. To start with, there may be a button to press in order to interrupt the boot process (such as CTRL+C). Pressing this may work, but differs per compilation.
- Another trick he shows (for getting into the UBoot console) is shorting out the data line for the kernel being read from external memory. By doing this, UBoot just drops into a shell because the loading of the OS failed.
- Finally, he goes over the UBoot interface itself and how it can be used in order to get data/control the device.
- This video goes step-by-step (with a camera on the device) on how to do all of the stuff described above. Super awesome talk with many demos included from a legend in the field.
