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 Apple Filing Protocol (AFP) is an alternative for the SMB protocol for sharing files over the network. Netatalk is an implementation of the AFP protocol on Unix platforms. The authors were attacking the Western Digital NAS for pwn2own. They exploited a known vulnerability in the project, labeled as CVE-2018-1160.

The AppleDouble file format aims to store files metadata to allow sharing of that information between file systems. When reading data in for the file format, it checks to see how many entries are allowed for the header. However, if there are too many entries then the header should be invalid and stop. For some reason, this ONLY logs an error message and does not exit. This error occurs three different times.

When calling this functionality, the header contains an offset that can be used out of bounds. As a result, an out of bounds reads and writes with calls to memmove; an attacker has some control over the source, destination and full control over the size of the copy. The binary has most modern protections (NX, PIE and ASLR - 2). This means that this cannot be a one shot exploit - an information leak followed by code execution will be required.

It should be noted that the configuration of the service allows anybody (anon) to create, read or modify files in the public share (without any authentication). So, to get the memory leak, they forced the memmove() source to be outside of the stack buffer to leak data that was being copied to a file. By reading the file, they got their information leak with specific offsets.

While testing the info leak, they came to an interesting realization: if the file being written is larger than 0x1000 bytes, then it is mmapped at a high address next to the other libraries. Of interest, the library ld-2.28.so was always 0xC000 bytes after the beginning of the file. So, how to get code execution?

memmove is a more optimized version memcpy but has specific requirements on alignment. If this alignment is not met, then a function pointer called _dl_rtld_lock_recursive would be hit. By overwriting this variable in the loader with a badly aligned memmove, the authors controlled a function pointer with a single parameter going into it. Using the leak from before, they could call system and know where their data was at for the payload.

For pwn2own, they got this to work on the third try! The main difference between their setup and the pwn2own setup was that they needed to extend the sleeps for all of the shenanigans to happen in a timely manner. Good write up!

Spring4Shell is a vulnerability in the spring framework that is similar to Log4Shell. This article explains why this new vulnerability occurs.

When a controller is used to map a request (@PostMapping("/myroute")) it will attempt to transform the object into a Plain Old Java Object (POJO).

Spring uses serialization under the hood to map these values to a Java object. As a result, it is possible to set other values, including properties of a class.

By exploiting the use of serialization on arbitrary objects, Java classes can be loaded to execute arbitrary Java. In particular, the authors write a simple .jsp file to to output HACKED.

Of course, if this can be done, then a complete reverse shell can be added as well. The original proof of concept uses Tomcat but there are likely other ways to abuse this. According to JFrog, the exploit uses Tomcat to use AccessLogValue to write to an arbitrary file with content.

Overall, crazy & bad vulnerability with awesome stuff going on. The bug seemed fake at first but it really is the second-coming of Log4Shell!

Pritunl VPN is a distributed VPN service. This product is open source product, making it easier to audit as well.

When a user imports a VPN configuration file to the client, it is at %APPDATA%\pritunl\profiles\[profile_ID].ovpn. While doing this, it attempts to sanitize malicious characters from the file then writes it to %PROGRAMDATA%\Pritunl\[profile_ID].ovpn.

Here is the kicker: ANY user can create new configurations files in %PROGRAMDATA%\Pritunl\[profile_ID].ovpn with the default security permissions. As a result, an attacker can add malicious directives into the configuration file. Once openvpn is executed, it runs it with the security-script 1 flag, preventing external commands from being executed. Good work on the defense!

There is one oversight though: the logging directive can be set in the configuration file. Using this, the output of a specified file can be written to as SYSTEM, with partially controllable contents. Arbitrary file write primitive!

Using the arbitrary file write with limited control over the file, code execution can be gained pretty easily. What is the best primitive for this? ipconfig is ran without an absolute path. This means that if we add ipconfig.bat to the execution path, it will execute this first! Neat trick for a relative path.

Overall, this is a good article on privilege escalation and how misunderstanding dependencies can lead to problems.

LI.FI is a cross-chain bridge aggregation protocol. This allows for a multi-chain strategy.

When performing a swap or transfer of coins between chains, the public function swapAndStartBridgeTokensViaCBridge is called. Eventually, this hits the library function LibSwap.swap() with additional validation checks to ensure no shenanigans are being performed.

The function swap() makes a low level function call to call(). In order to make this call, both the variables callTo and callData are fully controlled by the user making the swap.

In the context of smart contracts, this gives the ability to invoke arbitrary smart contract functions within the context of this contract; even a function that we create! In other words, we can run system on this. They seem to have static analysis in place for the smart contracts, as they added // solhint-disable-next-line avoid-low-level-calls as a comment to prevent it from looking at this bad call. Lolz.

This is not as simple as running system in order to steal all of the money. To do this, the attackers created their own contract could be executed to drain user accounts. Since they were in the context of the main contract, they could perform actions on tokens of users that had trusted this contract with infinite approval.

Using this, they drained the accounts of 29 wallets, which is about 600K in US dollars. The post-mortem claims that "...LI.FI is safe to use." Frankly, I wouldn't believe this after such a blatant and horrible attack.

In 2012, an attack was launched on GitHub. In this attack, a public key was added to the Rails organization. As a result, they were able to access data and files in this organization. How did this happen?

The root cause of this vulnerability comes down to a Mass Assignment vulnerability. This occurs as a failure to check incoming parameters on a request that will then update an object. In this case, the API call was an public key update form, which they likely changed the account this was attached to by using the Mass Assignment bug.

Amazingly, the attack occurred at 8:49am but was fixed at 9:53am; this is a 4 minute turn around in which I have NO idea how they discovered and fixed the problem this quickly. Of course, the keys were removed immediately. Plus 1 for good threat detection and log management.

From there, they did a complete audit of the code base for more mass assignment vulnerabilities but do not say if more were discovered. They later discovered that that the attacker compromised three accounts (two were tests and one was Rails). This meant that the attack was found quite quickly, which is awesome.

Mass assignment vulnerabilities are probably more common than you would expect, especially in languages such as Ruby, Java and C#. They are hard to find without source code access but relying on the output of other requests could leak information about the internal state. Interesting bug!

Last year, a crazy vulnerability and exploit was discovered in PDF parsing of iOS. This exploit created a weird machine to get arbitrary code execution. However, since the messages is sandboxed, they still had to escape the sandbox. This is a post about how the sandbox escape worked.

Within the complicated weird machine is only a single call to NSFunctionExpression; there is no complicated ROP chain or anything else. This call does two things: cover its tracks and trigger a logic bug within NSPredicate. Covering the tracks is interesting but it is all about cleaning the things up, which I'll skip.

In Objective-C, there is a piece of functionality called NSPredicates. This is used for iterating over collections, such as arrays, to perform functionality. While using predicates, expressions can be used as well. This expression in a small query language, which is similar to SQL in some ways. In OS X 10.5 in 2007, the ability to use the FUNCTION keyword to invoke arbitrary methods was added.

Using these expressions, it is possible to write full-on Objective-C code. Using this, they write our code in order to exploit the sandbox issue. In particular, they make a request to NSXPC, which is a remote procedure call which allows for the instantiation of proxy objects in one process which transparently forward method calls to the "real" object in another process.

There are some restrictions on what objects can be allowed to traverse the boundaries. In particular, the objects must define as protocol for the NSXPC to designate what happens when it is invoked or used. An attack surface analysis from 2019 shows that "subclasses of classes with any level of inheritance are also allowed, as is always the case with NSKeyedUnarchiver deserialization." This means that any object which declares a particular type for a field will accept any subclass of that type, opening up the attack surface.

To dive into the exploit more, they read through the usage of the objects being exploited. While grepping through code, they found an NSXPC interface that accepted NSObject*, which would include NSPredicate. Although this looks like a game over (code execution from the expressions), there is a specific mitigation in place for this. When an NSPredicate is deserialized, a flag is set to disable the evalulation of the predicate. Good job Apple!

The protection above is an application controlled feature though; if the validation is NOT done properly, then the execution could still occur. Within the Sections, the code sets the allowEvaulation flag to true. This means that the predicate is trusted and will be ran, but they never evaluate the predicate. As a result, the predicate gives us code execution within the context of CommCenter.

Now that the attackers have the ability to execute code within the context of a process outside of the IMTranscoderAgent sandbox, they run several expressions. The final expression is to make a request to a URL to download an AES encrypted expression to evaluate this as well. This secondary payload was whatever the attackers wanted at this point, all without any memory corruption.

In response to this exploit, Apple did a two things. First, they reduced the ability of NSExpression to prevent easy code execution with a similar bug. Secondly, they added restrictions onto the PTSection and PTRow objects for parsing NSPredicates. So, good job Apple for hardening this area against future attacks.

The author of the post was quite stunned by how large this attack surface is for the sandbox. By using these tricks (NSObject pointers in protocols and library loading gadgets), all of the initWithCoder implementations could be attacked, with more code execution gadgets being found. NSXPC seems like a powerful attack surface across boundaries, even though it was designed with this exactly in mind.

The final paragraph is the most daunting to me: advent of Memory Tagging Extensions (MTE), likely shipping in multiple consumer devices across the ARM ecosystem this year...innovate too, and are likely already two steps ahead with a renewed focus on logic bugs." There is more to exploitation than memory corruption and hackers are smart. Overall, great post!

Is an arbitrary file deletion anything other than a denial of service (DoS)? To me, I would have said no, but this article shows us how this can be useful on Windows to escalate privileges.

Why would we think this wouldn't be helpful? Well, it MUST be something that fails open, if the file is deleted. Additionally, Windows OS files are locked behind the TrustedInstaller , which cannot be overwritten by system. So, what is useful to delete then?

Adelhamid Naceri found this exact type of vulnerability in Windows via the User Profile Service running as SYSTEM. The author turned to the Windows Installer for privilege escalation, which is responsible for installing applications with .msi extensions.

The Windows installer must have rollback functionality for when an installation goes poorly. Namely, if a file is deleted with a newer version and the installation fails, then a copy is saved just in case the changes need to be reverted. In order to do this, the installer service creates a folder named C:\Config.Msi. In this folder are .rbs (rollback scripts) and older versions of some files.

If an attacker can delete this folder while this process was taking place, they could add in scripts that would run as SYSTEM. The next trick is for an arbitrary file deletion instead of an arbitrary folder rename/deletion. But, this only required one additional trick: abusing the NTFS file system.

In Windows, each folder has metadata stored in a seperate file. For instance, C:\MyFolder would have a file called C:\MyFolder::$INDEX_ALLOCATION. If the metadata file is deleted, then it essentially deletes the entire folder. By specifying the metadata file to some of the Windows commands, this can happen.

Finally, the author details a technique for escalating privilege in a situation where the contents of the folder are deleted but we do not control the files themselves. In minimum words, it abuses symlinks within oplock callbacks in order to delete the C:\Config.msi folder.

These techniques turned a seemingly useless vulnerability into a powerful privilege escalation. It is interesting to see how this exploit primitive was developed!

Chrome PDF Engine has a function called RequestThumbNail. When an embedded PDF is added to a page, the thumbnail of the PDF can be accessed via a postMessage. Specifically, a call like embed.postMessage({type: "getThumbnail", page: 2});

When requesting a thumbnail there is no validation on the page number when attempting to get the thumbnail. There is a call to DCHECK, but this is only is test builds and NOT production builds.

The object that is accessed out of bounds contains a function pointer that is immediately invoked. Hence, a properly placed object could easily lead to code execution.

Another situation where an error check is done via code but not in the production version!

APC is a subsidiary of Schneider Electric. They have Smart-UPS (Uninterruptible Power Supply) that provide emergency backup for ICS, server rooms, hospitals and many other things. Finding vulnerabilities in these products could be quite bad for the world.

The reason for the name TLSStorm is that the vulnerabilities originate in the TLS handling. In order to handle the TLS communications, they use nanoSSL. However, by not properly handling the errors from this library, many security issues arise from it.

When doing the initial TLS handshake, there is a ClientHello and a ServerHello message. After this, they exchange cipher suites. However, if the client decides to use a cipher suite that the server does not support then the exchange will fail. According to the documentation of nanoSSL, this should result in the termination of the connection.

In the case of the software using the library, not error checking was done from the function. This saves the TLS master session key as ZERO. Hence, by using TLS resumption, it is possible to convince the server that this is a trusted user, bypassing the certificate validation. Neat!

While reassembling a packet, there is a maximum size that the payload can be (2389). Anything bigger than this and the library will return an error message and not reallocate the buffer. If an attacker sends a packet with a huge length field, the buffer will never get reallocated and it will copy in packet data until that length is reached. Another neat bug!

The final one is that the firmware updates use symmetric encryption in order to keep it from being tampered with. However, an attacker can figure out the key, reencrypt their own package and upload the firmware. Instead, they should be using a digital signature to validate that the firmware is legit.

The complexity of the firmware supply chain creates the potential for many security vulnerabilities. Additionally, the need to update things ONLY as an authenticated user is complicated in the context of firmware; cryptography is not always easy to do securely.

The vulnerability is within the USB Data handling code. The complexity of the code cannot be secure by design, as they have found 8 CVEs in this location in the past six years. The UsbRt API interface tends to take in pointers that are read, written to or do other things. In CVE-2017-5721, this exact problem was found.

The "patch" (bunny quotes) for this was to use a CRC on the data. Of course, an attacker can simply generate a valid CRC themselves to call this. As a result, the patch from the previous CVE was insufficient, which led to the ability to call arbitrary functions with arbitrary parameters. Yikes!

To prevent this type of bug from being used to, Intel added a protection to NOT allow code from outside of the SMRAM from being executed. This is done in order to prevent a class of vulnerabilities known as System Management Mode (SMM) call out. However, this protection can be bypassed by using a ROP chain, as detailed by Synactiv. The authors of the post claim that ROP chains are simple to create because of how the builds work on UEFI.

Overall, an interesting blog post in an area that most of us never get to look at. I wish the blog post had a lower level of entry, since many of the acronyms and previous research were unknown to me.