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!

Microsoft Teams administrators can use policies to control what users can and cannot do.

So, what is the bug? All of this is ONLY enforced client side. So, you can still call the APIs but the UI will not be nice and pretty for the user. According to the end of the article, this can be used to bypass Messaging Policies, Cloud File Storage Restrictions and Meeting Policies.

This issue was literally discovered by altering the response from the user. So, client-side enforcement is still out there and worth testing for!

There is a fairly standard RCE bug via command injection in this report. However, it is authenticated; so, now what? Well, time to find an authentication bypass!

In this case the manufacture added a hardcoded backdoor to the API functionality. If a specific encrypted value was included in the Authorization Header this the authentication automatically passed. Sadly, this backdoor appears to be extremely intentional, and purposely hidden. Not that uncommon with IoT devices though.

Using both of these bugs together, we have an unauthenticated RCE.

OpenEMR is a popular open source software for electronic medical records. Obviously, this is extremely sensitive.

In order to compromise this, 3 separate vulnerabilities had to be discovered: command injection, XSS & an auth bypass.

The command injection was inserted during administrative backup feature. The developers thought about protecting about SQLi but not command injection. So, later on, this SQL stored value is added into a bash script, which results in RCE. However, this is an administrative feature! Is this a big deal?

The second finding is an XSS in the users last name. By adding script tags, it is trivial to create an XSS payload. But, this information is only displayed to the current user. So, not a huge deal, right?

This is where it all ties together: the auth bypass. When creating a user, the SESSION_ID is set to ignoreAuth, which makes perfect sense. However, the permissions that are ignored are MUCH more than necessary for user creation. Now, all a user has to do, in order to have arbitrary access to all user account events, is put the user into the registering state!

With the auth bypass to edit arbitrary user information, we can edit the admin username to include an XSS payload! Once the admin visits the site, we can use the XSS to call the administrative functionality that has the command injection in it.

Gotta love these types of reports, when multiple issues are chained together in order to make a seemingly useless authenticated bug impactful. As of recent, it seems like these IoT devices are just full of authentication bypasses!

VMWare Workstation uses PhoenixBIOS 4.0 Release 6 for its legacy BIOS emulation. One backdoor (not malicious in anyway; just the lingo for emulation stuff) into this feature, was that the guest can communicate with the hypervisor during this time. This is done via an emulated I/O port.

By viewing an open source project called open-vm-tools, a few specific backdoor functions related to the BIOS emulation were found. The most interesting of the bunch ended up being BDOOR_CMD_PATCH_ACPI_TABLES because it parses configuration tables (ACPI) from the guest.

Essentially, the ACPI is an open standard that operating systems use in order to discover computer hardware components and perform power management operations. More information can be found here.

The flow for this function is as follows:

• The ACPI table is validated for legitimacy.
• The ACPI structures are used in order to find the Differentiated System Description Table (DSDT).
• Once the DSDT is found, the AML (ACPI Machine Language) code is patched out.

Both of the vulnerabilities are Time-of-check Time-of-use (TOCTOU) race conditions that lead to memory corruption.

The first one exists because of a size in the ACPI header for a checksum. First, these fields are validated and a memory mapping is made for this. However, once more the size of the length is validated once again! In order to exploit this, have the size of the table be different on the two separate fetches in order to have a cause an OOB write.

The second bug is exactly the same as the first (same size check) but it is used on a read instead of a write of the checksum calculation.

This bug is in a unique part of the system; hence, requires an interesting way to exploit it!

Although the backdoor function (from VMWare) should be disabled after booting the computer, the code is hittable via the Guest OS. Since the BIOS memory is writable, we can force the call of this function with a modified BIOS data!

First, the author creates a fake RSDP structure structure. Now, since we can overwrite the RSDT structure with our RSDP write, we can control the entire ACPI parsing process. This is important because we force the TOCTOU to happen by editing these components of the BIOS as the function calls are being made to the hypervisor.

To actually exploit this, the DSDT table (where the vuln is at) would need to be at the far end of Guest RAM. This is because the OOB write & OOB read are linear, requiring the physical mapped addresses to be at the right location in order to cause any damage.

For the OOB, the leak is super clever! By setting up the checksum to be known by the attacker and increase the size by one byte (OOB by one byte), the checksum would be recalculated. From this checksum value, you could find the leaked bytes! This process can be repeated N times to leak linearly arbitrary memory.

The write primitive is extremely constrained to what values can be written, making it a less interesting item to work with.

Overall, this is a really interesting article which talks about the internals of VMWares virtualization and about very low level interfaces that are seldomly talked about.

In Java 6 and before, classes were verified at runtime with a special verifier which would emulate if the actions were legal or not.

In Java 7 and after, there is compiler information added known as Stack Map Frames that make it trivially easy to verify whether or not a class is legit or not.

The remain backwards compatible, both of these methods are still added with each version of Java; they are compiled into separate libraries. Different methods are used depending on the version of the class file.

So, what is the vulnerability here? Well, it is pretty simply: let's just hook the libraries! Because these libraries have no protections, we can hook the functions in Rust and return true.

This does not feel as useful as first finding (in older versions), as it cannot be used in browser exploits. However, this still does have impact, if running the code on your local machine.

When Java was originally created, it was built to run everything, including the web. Because of this, security protections had to be in place to ensure that valid (non-corrupted) code was being uploaded/executed in the web browser.

In terms of security protections, there were three main items put in class:

• Access Checker: Checks access flags for fields, classes and methods.
• Verifier:Verifies that the classes have legal bytecode.
• Security Manager: Prohibits actions like accessing the file system.

In Java, there is a validation check to ensure that classes are allowed to inherit from each other. But, there is a special class in Java called Reflection, which allows for the ability to modify or examine the behavior of classes and interfaces at runtime. Naturally, this has to bypass all of the security mechanisms in order to do this. The Security Manager bans the usage of this API in the web too.

To prevent the complete abuse of this API, the class was made private and only accessible by sun.reflect packages. So, what is the issue? Well, we can use a class that extends the reflection API. Now, we can bypass all access controls for class usage and extension :)

From this, it was possible to bypass the other two security mechanisms trivially to run invalid Java Code. However, this bypass only worked in versions prior to Java 8 because of some package reorganizing.

QCMAP (Qualcomm Mobile Access Point) architecture is a software suite in charge of the handling devices. This interface allows for administrative configuring of the devices using the MDM modem, such as LTE routers, mobile hotspots and smart meters.

The web administrative portal is vulnerable to a classic command injection on the web interface. Simply appending a semi colon, then with the specified command, results in RCE.

The web admin portal uses a bunch of CGI scripts in order to run actions on the device. Because of this, the standard set of memory corruption vulnerabilities apply! In one of the CGI scripts, that parses the parameters, there is a finite amount of space for the number of parameters. So, by adding a crazy amount of parameters, this buffer can be overflowed.

An additional issue is a NULL pointer dereference because of bad string parsing. The strstr function returns a pointer to a substring in a string. However, there is a chance that NOTHING is returned from this and this case needs to be checked.

An additional command injection exists within a basic CLI interface that is restricted to what the user can do. Once of these functions has a really simple command injection vulnerability in it.

Overall, cool findings in a classically bad IoT device.

A subdomain takeover is a vulnerability that is very similar to this one; there is a dangling record that can be used in order to assert oneself as another user.

This blog post discusses the same type of attack but for hijacking Github repositories.

There were three main ways identified:

• A Github Username user renames their account
• A Github user transfer their repository to another user or organization & deletes their account
• A user deletes their account

Additionally, Github has repository redirects which is another scenario that has to be looked out for.

After doing an analysis of all of Github, it was discovered than 18,000 projects were vulnerable to this attack! Now, going down the dependency chain, at a depth of 5, 70,000 projects are impacted by this with only 1.5 million stars combined.

To remediate this issue, do not use Github as a package manager.

Overall, great article with an interesting analysis. Huge S/O to my co-worker Indiana for his research!

The bug impact of a Samsung store URL is over HTTP instead of HTTPs. Because of this, a crazy Person in the Middle (PiTM) attack can be performed. This attack, therefore, require that the victim is on an attacker controlled WiFi.

The HTTP URL is found within a NFC tag that the user scans. Once this is scanned, the NFC tag can guide a user to either open an app or download an app.

When some JavaScript is ran from the HTTP URL, an attacker can then intercept the request and make the user download a malicious application.

This vulnerability looks really flashy but is quite theoretical. Two make this exploit work, the following has to happen: a user must be on an attacker controlled WiFi network AND must scan an attacker NFC tag. A vulns a vuln but this does require quite a bit of user specific interaction to pull off.

This article goes into a plethora of techniques for decapping chips and the safety that also goes into it.

In this, the trials and errors for different techniques and solutions are detailed for decapping chips. Overall, good introductory reading for this!