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 Linux BSD Kernel has a classic time of check vs. time of use(TOCTOU) vulnerability. The size of a buffer (in userland) is checked prior to heap allocation in the kernel space. However, this size can be alter from the point of allocation AND the check.

The TOCTOU bug, described above, creating a linear heap based buffer overflow in the kernel.

Although the race condition has been found, we need to know when race has been won. But how? Hopefully, something deterministic instead of guessing.

The copyin syscall is used for transferring userland memory into kernel memory. To prevent a kernel panic when a bad userland pointer is passed in, the function can gracefully handle memory errors.

Because we can control the amount of memory being copied, we can force an unmapped section of memory to be just after these bytes (that we are sending to the kernel). If the copyin access fails, we know that the race condition occurred because the page no belongs to the kernel space. (not sure about this explanation but am trying...)

The kernel buffer that is overflowed is a mbuf. Mbufs, when freed, call upon a field called ext_free. Having access to a function pointer to overwrite is very useful to the purposes of exploitation.

Actually freeing the mbufs takes quite a bit of freeing and playing around though! Just keep doing actions that free mbufs and hope it is the right one.

With the ability to jump anywhere, what is next? It is not as simple as a ROP chain, as the data we control is very limited. This actually took some creativity to come to!

First, the current register context is saved in order to restore the kernel execution later.

Secondly, set the userland page tables to be executable. From the context of the kernel, the userland is NOT executable.

Thirdly, turn off Supervisor Mode Execution Protection (SMEP) and other kernel protections. This protection disallows userland to access certain pages.

Finally, jump back to the userland shellcode in order to escalate the privileges. What does the shellcode do? The shellcode patches the threads UID to be 0. Now, a call to setuid will make us root!

The BootROM is the only part of the iOS system that is not patchable. So, finding a vulnerability in the BootROM means that it will last forever on the phones that it exists on.

When Malloc runs out of memory, NULL or 0x0 is sent back to the user. In order to prevent bad accesses on 0x0, a check is made, similar to the following:

if (pointer == NULL) {
	// handle error
} else {
	// pointer is valid, continue
}

The vulnerability comes from an issue with the Malloc implementation. Older versions of Malloc improperly return 0x8 instead of 0x0 when the heap allocator has ran out of memory. Hence, because 0x8 is returned, it is viewed as a valid pointer!

Where does 0x8 point to? On ARM processors the exception vector table starts at 0x0. This is used for handling bad actions, such as OOB reads and such. By overwriting entries in the table, we can control the flow of execution upon particular error messages!

To fill up the heap, a large plethora of images are sent to the system. Once they are freed, the pointer (at 0x8) will cause an invalid memory exception and execute the code from the exception table. Now, it is game on!

Super simple bug that caused the complete downfall of the system. I wonder how many more simple bugs like this are out in the wild, just waiting to be found :)

Black magic timing attack against reused Diffie Hellman (DH) keys in TLS. NOTE: This affects all implementations, as this is a vulnerability against the specification itself.

The math in the article is beyond my knowledge. So, read the article to understand it yourself. But, I will try to provide an overview of the attack (with NO math) below.

The essence of the attack is that DH keys do have all leading zeros stripped. Although, figuring out if the start of a key with 'X' number of 0's does not sound very useful, it is a start.

From there, a well-positioned attacker could view a ClientKeyExchange message which contains g^a. With this, an attacker can construct values LIKE g^a.

Why is this useful? This can now be created to setup equations for the Hidden Number Problem (HNP).

What's the impact? People reusing DH(E) keys (about 3% of the internet) are vulnerable to this attack. However, it requires an attacker to be in a VERY well-positioned location for this to work.

Additionally, the bug with stripping zero bytes in the key affects different libraries in different ways. For whatever reason, a F5 product is vulnerable to this while NOT requiring timing measurements.

Overall, cryptography is VERY hard to do right! Even if everything algorithmically seems secure, a side channel can come back and steal your trash (Raccoon).

JavaScript object are working on the prototype-based inheritance model. The prototype is a hierarchy where the object itself goes first, but then it's prototype is then checked, if a value cannot be found. For more on this, read the article linked or Mozilla docs.

The idea behind this vulnerability is to poison the prototype (of an object) in order to cause bad behavior to occur. In the past, prototype pollution has been used in NodeJS by object being parsed literally by the program (along with a merge operation) to cause crazy behavior in the program.

In this case, the author is attacking client-side HTML sanitizers. Because of this, we have complete control over the prototypes of objects.

The first parser (sanitize-html) is found to be vulnerable to prototype pollution by setting Object.prototype['*'] = ['onload']. By setting the * on the prototype (a check for all tags usable) will pass. Now, the onload attribute will be a valid tag! Also, this library was attempting to protect itself from prototype pollution but failed.

The second parser (xss) had a field called options which dictates what can and cannot be used. By polluting a field called whiteList by setting options.whiteList it is possible to set arbitrary tags/attributes for this field.

The third parer (dompurify) is very similar to the second parser issue. A field called ALLOWED_ATTR on an object was used in order to add more attributes than what should be allowed for an image. Now, when the parsing for the image takes place, the attributes were not removed because they were added to the prototype object.

The final victim (Closure by Google) has a custom format for specifying what is allowed and disallowed (which uses objects). By setting the prototypes of this object with the custom format to include src and onerror, it was trivial to get XSS.

The author created an automated way for finding prototype pollution methods for the HTML sanitization library! This can be found at pollute.js.

Although the author uses JavaScript in order to pollute the objects, this is STILL possible to trigger without JavaScript. In particular, insecure parsing of the JSON is often required.

Overall, great read that takes old research and brings it to be new again! :)

Adobe products are vastly complex! Because of this, they are riddled with security flaws. In this article (by a third party for a bug discovered by Mark Yason) in Adobe Reader.

Adobe Reader has a JavaScript interpretation engine itself. With EScript objects, associated with JavaScript objects, the data was stored in cache.

When this caching scheme is used, a data ESObject with the same PDDoc structure and name are reused from the cache.

The issue is that the ESObject pointer is freed, a pointer to it still exists in the cache. This creates a classic use after free (UAF) vulnerability.

The actual exploitation technique is only explained at a high level, but it is referred to as a classic method. At a VERY high level, it causes the garbage collection to free the object then uses the object again by accessing the cache. After this, the exploit is very down into the JS engine exploitation weeds.

Cisco Jabber is a video conferencing and instant messaging application used at many businesses. Jabber is built with Chromium Embedded Framework (CEF), which allows for embedded browsers to be put into the application.

The first vulnerability is a classic XSS bug. The application was using a deny list of bad attributes for custom style HTML. However, the list was not comprehensive and could be bypassed.

Although the CEF is in a sandbox, a way to escape this sandbox was identified. A function called CallCppFunction was noticed that calls an arbitrary executable on the system. By abusing this, and a built in file transfer feature, it was possible to execute arbitrary code on the system by XSS!

A vulnerability was discovered with several of the custom URI handlers. The protocol handler does not consider the case where a space is used. Because of this, we can inject arbitrary arguments into the binary, allowing for RCE on the CEF handling.

The next bug discovered was that SMB links were clickable within application. This is very bad because NTLM hashes will be sent to the user, allowing for the ability to learn the users password. This vulnerability can also be exploited by putting the link into an img tag instead of a clickable link.

Overall, several really good vulnerability classes here that demonstrate the importance of good Desktop security.

PPP is the Point-to-Point Daemon on Ubuntu (aka, a way to print).

The PPP makes an interesting target because 1) it is a setuid binary and 2) modprobe sometimes invokes the binary. Why is modprobe interesting?

The modprobe has ENV variables set for itself by setting MODPROBE_OPTIONS. The ENV variables not being reset have caused issues in the past, including CVE-2010-4170 and CVE-2017-0358. Because of this prior research, attacking PPP from the perspective of modprobe seemed like a good idea.

The MODPROBE_OPTIONS can be used in order to load an arbitrary kernel module, essentially spelling game over for the system.

What's the main takeaway? Specifically, not clearing out ENV variables when a new call is made is very dangerous. When running on a local system, ensure that ENV variables are used in a secure fashion.

A side-channel is a game over vulnerability when confidentiality is an important factor. For instance, if a nuke is going to be sent from Washington D.C., the amount of pizzas is D.C. increases because more people are working long nights from home. The pizza is not an issue with the confidentiality, but a result of something else (side-channel).

The most common side-channel in computer science is a timing attack. This is references to how much time an operation takes to occur. Some examples of these are the following:

• Fast failing comparison functions
• Cache-timing vulnerabilities
• Memory access patterns

Another common leakage, which requires physical access, is power usage. Different algorithms or operations require differing amounts of energy. Because of this, it is possible to leak secrets if the operations being done is known.

An additional side-channel is electromagnetic emissions. The computer gives off large amounts of electronic emissions, such as radio waves. Some of these emissions may leak information.

How do we prevent these attacks? For timing, this looks like having constant-time algorithms, or an algorithm that returns the data in the same exact amount of time every time. This article goes VERY deep into proper constant-time algorithms. Constant time math is not as simple as it seems.

For preventing power usage, it is very difficult to do and usually is just a bunch of obfuscation (instead of real security). An example of this is adding random operations of random time intervals to prevent any useful information from being gathered. Another way is to use different cryptographic algorithms, such as BearSSL using Montgomery Multiplication instead of square-and-multiply.

CGI (command gateway interface) is essentially an API, but differs in that it is meant for lower level operations. FastCGI and CGI are libraries in the Go language for the case of this article.

Differences between parsers can cause major issues when dealing with the security of an application. This is a well known fact! When it comes to HTTP, another example of this exists known as HTTP Request Smuggling.

When requesting something via the CGI directly, the default Content-Type (type of the file being sent) is NOT the png or anything else. Instead, it defaults to text/html. See where this is going?

Because the default type is set to text/html anything directly called by the CGI is now vulnerable to XSS, if the content can be controlled.

This is super interested because it is a XSS on ALL sites that use this functionality, not just a particular site!

GOG Galaxy is a video management software by GOG.

After installing the client, the author was looking at Wireshark packets to see what was happening. He noticed a file path within the Wireshark dump and thought this was interesting.

First, the author just replayed the original packet sent and the System command was ran. Upon modifying the payload, it did not work.

From reversing it, he noticed that the code was using an HMAC with a key on the local system. After finding out the key and the algorithm, the author was able to sign the payload and execute arbitrary commands. Because this was running as System (on Windows), it allowed for a very serious priv esc.

For the devs, secrets inside of executables are not secret!

Decoding protocols on the system in Wireshark is a good way to find issues; local traffic (on the machine) is rarely authenticated for third-party services.