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!

Java App Engine allowed arbitrary Java to be ran within the context of the sandbox. In order to make this usable to developers but still secure, there is a substantial amount of static and dynamic analysis that eventually leads to bytecode rewrites.

Rewriting Java byetcode!? How could this possibility be done securely in order to protect against all possible privilege escalation methods.

When rewriting the bytecode, it is based through ASM for an in-memory serialized representation of it. This means that a parsing difference between ASM and the JVM can allow for bytecode transformations to bypass the security checks.

The first vulnerability is in a difference between Java classfile opcodes. In a ClassFile, older versions used a bytecode of 1,1 and 2 bytes to represent the Code attribute. In newer versions, this is 2, 2, and 4 bytes in size.

By carefully crafting a file, the Classfile can be parsed valid as an older version (with smaller sizes) and the newer version with larger sizes. Using this bug, it would be possible to change interpretation of the bytecode if App Engine didn't have a minimum version of 49.0.

When Java bytecode needs to reference a string, the string data is stored as a two byte length field, followed by that many bytes of string data. ASM does not check for integer overflows on this size though. This means that a string of a very large size would be seen as 0 size by the JVM and the rest of the string would be interpreted as the bytecode.

However, it is impossible to create a string large enough to cause this overflow. So, another way to trigger the parsing error needs to be found.

The strings within ASM are parsed with the MUTF-8 encoding while Java uses UTF-8. The main difference is that NULL bytes are stored as a two byte sequence within MUTF-8.

The vulnerability occurs where ASM will allow for the input to be in the MUTF-8 format and the UTF-8 format. This slight difference between ASM and the JVM can be used to trick the length of a string to trigger the overflow bug above.

The exploit involves using the integer overflow in order to create valid bytecode. Obviously, handwriting bytecode is a tedious and annoying part of this exploit though. The rest of the article dives into how the bytecode was created in order to launch this full exploit.

In order to remediate this vulnerability, App Engine changed the flow to run the ASM again in order to check for discrepancies. By doing this, an entire class of exploits was removed.

This is an insanely long post but I appreciate the thoroughness of the post. Differences in parsers will always be an issue with security.

Rocket.Chat is an open source chat platform for team communication (like Slack). Both of these vulnerabilities are NoSQL injections in MongoDB that have a devastating impact on the application.

NoSQL queries are typically JSON objects that are based to the query object. Because of this, if the user input is simply added to this object with type validation, the meaning of the query can be changed (similar to SQLi). For example, the operator {"$ne":1} would force the query to always return true instead of being a normal input.

The first NoSQLi is in the validation of password policies. The bodies token does not have its type validated but is added directly into the query. Hence, NoSQLi operators can be injected into this in a blind fashion.

To do something meaningful with this, we need to create a blind oracle, such as a timing change or something else. In this case, the regex operator can be used to character by character to steal a users password reset. This is a horrible vulnerability that allows complete compromise of any non-2FA account.

The second vulnerability is in the users.list function. This function takes a parameter that is used for the users collection information. Because not all fields in the collection should not be accessible by everyone, there is a denylist of items.

This denylist of items does not consider the usage of MongoDB operators though! So, we have the ability to add an arbitrary operator into the query being used. The regex way would work just fine but there's a better way.

The $where operator can take JavaScript expressions for more complicated queries but only within the context of the MongoDB instance. By triggering an error message within the query via the JavaScript in the $where clause, the response could contain secrets inside of it!

This attack allows for the leakage of a controlled field! Using this, at the admin password hash and 2FA secret could be leak. Game over!

Once the admin user is compromised, it is even possible to pop a shell on the system. This is done by adding incoming and outgoing webhooks via the Integrations, code execution is trivial to get on the host machine. So, this is kind of code execution by design.

At this point, the attacker is trapped within the Node vm module which is apparently not made for security. To escape the VM context, the attacker has to get access to objects from the parent context. By referencing parameters given by the parent, a simple 3 lines of JavaScript gives access to the host machine.

Input validation is incredibly important for stopping simple attacks like this. Checking for types and values can drastically reduce the exploitability of an application.

The author is a student at Stanford who is likely living on their own. Because they needed some internet, they bought a new router for the internet but took the opportunity to hack on it.

The Telnet service running on the device has brute force protection for somebody trying to brute force a login. This is implemented by delaying the response with a call to sleep (3 seconds) prior to sending an access denied back.

The issue is that the correct password only takes 0.05 seconds regardless of how many tries it took. This means that the 3 second wait period does not need to be considered! We only need to wait 0.05 seconds in order to know if it's the proper password or not.

The author of this article joined a FinTech company called Pleo in order to help build out their billing infrastructure. Obviously, billing MUST be done properly and is complicated to do. This article is some notes on weird issues they ran into during the billing creation.

Money is not always decimal. What this means is that different countries are charged based upon their currency. The US dollar can have decimals in it ($1.50); but, in Japan, the JPY cannot. In order to handle this, the author used as integers for storage then added the decimal points in later.

Another interesting thing is that invoices cannot be cancelled or voided once created in the EU for tracking reasons. Instead, a full credit amount has to be made in order to reverse the invoice.

Who would have guessed this one: Not All Billing Systems are Compliant. This causes issues when implementing logic for handling payment platforms. An example is that the VAT number in the EU must be checked before every sale, which Stripe does not do.

What happens when a user changes plans? For instance, if a user wants to upgrade a service level in the middle of their free trial. How can this be done without making a messy invoice? Depending on the service, there are an endless amount of ways to change up plans.

Customers aren’t companies. They’re people. And different people have different needs. There are a lot of small edge cases that need to be considered. For instance, "Some companies wanted to pay up-front at the end of 2020 for 2021, because they had a leftover budget which couldn’t be used in 2021."

From a hackers perspective, I read about the complicated things that developers complain about and see them as good attack vectors. Additionally, understanding more about the system makes it easier to break as well.

WiFi is a large part of every day life. This is a common way that computers of all kinds have internet access. The Wifi protocol being secure is the only thing that isolates the devices in a network from being inaccessible to attackers.

By carefully injecting frames unencrypted frames into a WiFi network, it can be used maliciously to break the security of the network. For instance, it could be used in order to trick the client into using a malicious DNS server or bypass NAT/firewall protections.

The plaintext injection vulnerability described above can be triggered remotely when an attacker sends a malicious TCP packet as a response to some request from the user. This request can be used to trick WiFi into believing the request is actually a part of a WiFi frame instead of a normal TCP connection. The plaintext injection is a class of vulnerabilities that allow the WiFi to accept broadcast fragments even when sent unencrypted

The first vulnerability is in the frame aggregation functionality. In order to increase the throughput of the application, WiFi has the ability to put multiple frames into a larger super frame. In order to do this, there is a header in each frame that contains a flag on whether or not this is a single or aggregated frame.

The vulnerability is that the is_aggregated frame flag is NOT authenticated. Hence, a malicious actor can trick the WiFi to processing the transported data in an unintended way. In particular, it can be abused to inject arbitrary frames and the combining of single frames into an aggregated frame. This vulnerability is not an issue with the specification but a common issue with implementation.

The second issue is a design flaw in the fragmentation feature of WiFi. When fragmenting a large frame into smaller frames, the data should be encrypted with the same key. However, receivers are not required to check this! So, an attacker could theoretically exfiltrate data this way (even though the author does not explain how).

The third issue is a common issue with caching. The fragments are cached whenever they are used. However, an attacker could send a fragmented packet, which may be used by the user later. Again, an attacker could theoretically exfiltrate data this way (even though the author does not explain how).

These protocol confusion attacks have been taking off recently. In particular, the re-discovery of HTTP Smuggling and the revamping of the NAT Slipstreaming. This attack also reminded me how important HTTPS can be as a defense-in-depth measure for all sorts of crazy attacks.

These findings are extremely impactful and complex in nature. Even though the protocols look secure, there are always ways to poke holes into random backbones of the internet.

TODO... add more documentation on how the fragmentation attack works.

Azure VMs are virtual machines running on Microsoft hardware; this is similar to EC2 instances at AWS. This is the essence of cloud computing.

Azure VM allows developers and admins to integrate custom plugins in order to add additional components to the VM, such as diagnostics, network watcher and others. These extensions are loaded via the Guest Agent. In order to update itself, the Guest Agent polls the Fabric Controller in order to deploy extensions.

The agent communicates with the controller by accessing a local IP address at 168.63.129.16. In order to communicate securely, asymmetric encryption are used. To get the keys to communicate, a Certificate endpoint is used in order to get the keys (cert in the configuration file).

By crafting your own key and certificate, the endpoint would simply send the keys over! So, this lack of validation of the user making the call is clear problem, as this leaks some serious information. With these keys, it was possible to decrypt the Azure VM extension configuration files, which sometimes held important secrets.

However, the bug above did not work as a non-root user because of IP tables setup to prevent that exact issue! In order to bypass the security mechanism, a different IP was used. The IP 164.254.164.254 was not blocked by the IP tables but resolved to the proper address. That was a really simple bypass!

Overall, these were two simple bugs: lack of proper authentication and a poorly implemented denylist. Reversing is sometimes the hard part while the bugs are the easy part.

Tesla is a high class and amazingly technical car brand. Finding vulnerabilities in Tesla could potentially lead to stolen property and control over the driving of the car.

All Tesla's comes with a hardcoded WiFi SSID that can be connected to. Other researchers had discovered a hardcoded password, which allows anybody to join this WiFi network. This is a vulnerability by itself but just allows the research to be possible.

While reversing the Tesla, they found an open source library called Connman that was being used. This application is a lightweight DHCP server and client with a DNS forwarder. Because the parsing in this small module looked poor, they wrote an AFL harness and found several bugs in it quickly.

Within the forwarding functionality they got a crash in the uncompress function for backreferencing previous strings of characters to get the new one. This function contains a fixed size memcpy that does NOT check the actual size of the buffer. By creating a very small buffer, this resulted in a stack based buffer overflow.

But what about stack canaries!? The exploitation came to a halt because the binary contained stack canaries. There are three options for bypassing the stack canaries: brute force it, leak it or jump over it. It turned out that option 3 (jump over it) was the way to go.

The parsing in this function goes in a loop over a set of strings. When it finds a string it will use the string length (calculated by strlen) to iterate the next string pointer. By overflowing directly in front of the canary, the program can be tricked to continually iterate past the expected buffer to jump over the stack canary!

By jumping over the stack canary, the return address can be overwritten! This was a super awesome trick that was particular to this situation but worked quite well. Now, we have code execution... but what about ASLR?

To break ASLR, a leak was required. This was done by targeting the DHCP implementation .By sending a DHCP packet with no option data, a path was found that assumed this was filled out. Eventually, when this information was sent back, it contained uninitialized memory, resulting in a leak of library addresses and stack addresses.

To make this bug more powerful, the length of the domain that is being offered changes the stack address being viewed! By adding this padding, different parts of the stack can be read in order to leak the necessary locations.

The full exploit uses the two bugs above to create a ROP chain. This ROP chain marks part of the stack as executable with mprotect then executes some small shellcode. This shellcode loads the second stage shellcode into a heap buffer then executes.

The exploit uses a drone. This is because an attacker needs to be near the car in order to attack it. Damn, using a drone to control a Tesla is pretty amazing!

The author includes a few pointers at the end:

• Automotive research is possible without the actual hardware, use emulation!
• Stack overflows are still a problem despite the mitigations.
• Understand the bugs you fuzzed. Otherwise, you will miss some amazing gems.
• Infotainment Systems have become similar to desktop systems.

The Linux kernel uses a pseudo-filesystem called proc which allows for interfacing with OS. The storage format on the OS is normally /proc/<pid>/. The different sub-directories share information about the running process, such as registers, memory mappings and other things.

The vulnerability exists in the /proc//syscall location. This location outputs the register state of a given process. When loading in the registers from the userspace process, they are placed into an array of size __u64 per item.

However, this is where the bug comes in. On 32-bit systems, the array in the print function are effected to be 32 bit per item. In the printf, the llx format specifier is used, which stands for long long numeric value outputted in hex.

The difference between the ACTUAL size of the elements and the EXPECTED size causes 24 bytes of kernel memory to be leaked from the stack. Using this, an attacker could break KASLR or other randomization primitives.

Considering this bug could be seen by simply viewing the procfs, this probably was not hard to find! In fact, a careful observer on a 32-bit system may have encountered this bug and not realized what was going on. When testing, be observant of odd behavior; rabbit holes are your friend :)

Workplace is a self-managed Facebook for an enterprise environment. Having access to this is a privilege based upon the requirements set by the administrator.

When creating an account, the server was not correctly verifying the email used on registration if the self-invite feature was turned on. For example, only employees with @domain.com should be able to self-register. This is a horrible bug that allows for anybody to join the organization.

An attacker needed to know the community_id in order to launch this attack. However, the author of this post found a way to link an id to a company, making this a little more impactful.

This is unbelievable that this simple bug existed in Facebook Workplace. Does Facebook do internal pentests? I really hope they do! Bugs like this seem to be all over the place.

The Direct Composition Windows API enables graphical effects such as image conversion and animations. In Windows 10 a group of system calls were batched into one action. Since this, several vulnerabilities have been found in this component.

Some of the code in the direct composition API has a circular dependency of pointers; one object references another and vice versa. When one of the objects is freed, it is important to remove the reference so that a dangling pointer does not exist. In the base case, this is done properly.

There is an assumed 1 to 1 relationship between these shared objects though. So, if the object is referenced by two different TrackerBinding objects, the original objects pointer is forgotten about. When the other object is freed, it creates a dangling pointer on a TrackerList object. This was CVE-2020-1381.

The patch for this vulnerability involved validating that TrackerList was not being referenced by another TrackerBinding. However, there is a small edge case that can bypass this fix. Natalie at P0 says that 25% of zero days do not receive a proper patch, which makes the case for looking for bypasses in recent patches to find vulns.

By updating the entry_id to 0 Windows sees the entry as unnecessary. This calls a function that will remove the binding but not the entry for ONE of the sides! So, when the check attempts to validate if the TrackerList is currently in use by another TrackerBinding it will fail. Thus, we can trigger the vulnerability in the same way as before.