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 Sound Blaster X7 is a Digital to Analog (DAC) converter and amplifier. It takes several inputs, mixes them into a single output. There is an Android App over Bluetooth or (for Windows) over USB. The author just wanted to change their audio on their headphones!

To capture Bluetooth traffic on an Android device, there is a cool setting to output Bluetooth into a pcap file: Bluetooth HCI snoop log. The author then takes captures with VERY specific actions: on, volume up, volume down and off. This is to KNOW what each command does.

Once in Wireshark, viewing the pcap file, they had a bunch of character encoding issues (lolz); after they installed the right fonts ,every became better. The Bluetooth packet was showing RFCOMM as the information in the packet.

What do these values actually mean? 5a29050001000000 is change output to headset but we have NO idea what this means. Luckily for us, Android apps are super easy to reverse engineer using Jadx and APKTool.

From reversing the application, here is what they picked up on the format:

1. X7 Control packets start with 0x5A.
2. The second byte is the command ID, which seemed to always be 0x29.
3. The third byte is the LENGTH of the packet.
4. The rest is the command payload.

For the commands get/setSpeakerConfiguration, the first byte of the payload determined if this was a READ or a WRITE. The rest of the data, for setSpeakerConfiguration, was for changing the specific settings, such as changing the speaker being used and advanced settings.

Muting is done with the command setHardwareButtonState (38), with a byte for the button ID. Apparently, this code is reused for other applications, since this had MANY other hardware buttons that did not exist on the regular device.

The tricky part was the VOLUME. The volume being in dB, a logarithmic scale, definitely caused the author problems. First, replaying didn't work perfectly, with the same input producing different outcomes. Originally, they tried to use a percentage, which doesn't make sense in the logarithmic scale.

The inputs ended up having REALLY complicated formulas to get the actual output volume. In the end, they figured out that it was an INCREASE or DECREASE, instead of an actual value. Since this was keeping state, it made things a tad more complicated.

Overall, fun reversing project with practical implications. I appreciate the Bluetooth reversing notes!

Netgear is a popular router that is made by Comcast. While looking at attack surface analysis on the WAN interface on the Nethawk Smart Router, they noticed an already reverse engineered binary called /bin/circled. The daemon is started by default, even when turned off on the router.

They decided to target the update mechanism of this service. The check is launched at boot and every two hours; in the event of a crash, the process restarts.

The function update_database located at 0xCE38 parses a file in order to check if any updates apply. While parsing the lines of the update file, it uses sscanf to write two strings into buffers of size 256 each.

The vulnerability is that sscanf will read until a space has been found. As a result, this leads to a stack based buffer overflow. The overflow is good enough to corrupt the $PC on the stack.

To get the file for updating, it makes a request to curl. However, although the update request is made via HTTPs, the request has the -k flag, which disables certification verification. This means that the vulnerability for updating can be triggered if we can somehow control the response to this request.

In order to exploit this, the authors of the post setup a DHCP server for the Netgear routes. By doing this, it is easy to setup a DNS server and an HTTP update server as well. Since the -k is in the curl command, there is no verification on the certificate, making this attack possible.

A few things to consider for the exploitation of this bug:

• ASLR is only partially turned on (with a 1 instead of a 2) and without PIE
• Nullbytes cannot be written, this this is done via a format string.
• $R4, $R11 and $PC are the controllable registers in this request.

The authors found a magic gadget that allows them to control a parameter while calling system. Since this vulnerability was able to be hit twice, this allowed for the usage of a SINGLE nullbyte.

Although the heap is not randomized, we are not 100% sure where the string will be at but we know that the string will be in memory. As a result, they use a NOP-sled-like attack. They put a HUGE collection of As then a semi colon which is followed by the actual command. If the string hits any of the As, the first command will error out, resulting in the ACTUAL target command to run. A NOP sled for a bash command!

To patch this vulnerability, Netgear removed the -k switch and modified the parser to no longer have the buffer overflow vulnerability. To me, this felt weird for a Pwn2Own entry because it had limitations on WHEN it could be executed with a complicated networking setup. But, overall, great and fun write up!

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!