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!

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!

James Forshaw showed techniques that abuse NTFS Junctions and Symbolic links to escalate privileges back in 2015. Since then, using this has became an extremely popular method for hacking Windows clients.

The client (running as SYSTEM) writes a log file to C:\ProgramData\Hotspot Shield\logs. However, this location can be altered by any user! So, what does this mean? Arbitrary write to any file, using the log file!

To exploit this, the following must be done:

1. Delete all of the files in the logs folder.
2. Create an NTFS Junction (soft link) to \RPCCONTROL object directory.
3. Create a symbolic link between \RPCCONTROL\ and any destination file.

Although, because these are log files, this only results in a DoS because the content of the logs is not trivial to control to gain code execution. Still though, good find and explanation of the Windows bug that keeps on giving!

Security audits for websites are becoming more and more normal as security becomes a must-have for companies. However, the average person cannot afford a pentesting firm. So, they use freelancers.

The author of this article paid 7 people to test the same website which had two MAJOR vulnerabilities (auth bypass to admin and SQLi/hardcoded password on the login). What were the results?

The bulk of the testers (at different prices), just ran Nessus or some other automated security tool on the site. With this, very little was found. Out of the 7 testers, each bug was discovered and successfully reported ONCE. What does this tell you?

Hire professionals and people who know what they are doing. If you pay $50 for a security audit, expect to get a Nessus scan.

Arbitrary redirects are an interesting vulnerability class. The reason for this is that the impact is typically minimal (some bug bounties do not even accept this bug class) but can be immensely impactful in other situations.

In an interesting case, the url_for function in Ruby On Rails was accepting arbitrary parameters to it. Although this does not sound like a big deal, controlling the settings of a function can cause many issues!

To start with, a low-severity reflected XSS was found by setting the script_name field of the url_for function. This XSS required 2 clicks and the CSP blocked it. So the author decided to look for more.

By adding the script_name with just a domain, an arbitrary redirect was achieved. Although this seemed nice, what can be done with this?

When are arbitrary redirects really bad? OAuth! This exact vulnerability affected the Github Gist OAuth implementation. With the redirect, if a user clicked on a malicious link, it would be possible for them to login then be redirected to the malicious actors site. Now, with the redirect, the auth code would just be sitting on the bad actors site, waiting to be used.

Overall, this was a super interesting bug that was ONLY found because of source code review. I love the finding and would like to see more application bugs like this in the future.

Vakzz has MANY great writeups on his site; I highly recommend visiting this site for high quality writeups.