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!

Opyn is building DeFi-native derivatives and options infrastructure in DeFi. Anything handling money needs to be extremely secure.

Opyn allows any user to open a vault, with adequate assets and oTokens. Once the oTokens have been burned and the assets have been taken, the OptionContract pays out the assets in the vault to the user via the exercise function.

When exercise is reached, the function loops through a given list of vaults. When it pays the user the assets, this is done via the transerFrom ERC20 function call. The contract validates that the user has sent enough money for the assets via a checking msg.value.

Remember how this is done via a loop with multiple vaults? The validation checks the msg.value, which is a global variable in the context of Solidity. The contract only validates that msg.value is enough for the single item being validated in the vault; not for the multiple items being taken.

This means that the contract is vulnerable to a double spend attack. By specifying two vault items worth the same amount, we can trick the contract to allow us to get paid out for multiple vaults while only paying once.

To fix this problem, the amount being paid out should have been stored in a local variable. When taking out one item from the vault, the worth of the item should have been subtracted from the amount to ensure that the amount is correct. To me, it is amazing that the contract supported multiple payouts at once but this bug was never caught.

Little Snitch is a host machine firewall on MacOS. It is used to monitor egress network traffic. When an application on a system running Little Snitch makes a new, previously unseen connection, Little Snitch will present a pop-up asking the user if the connection should be permitted or not.

While testing this out, the authors noticed that Little Snitch only altered the user once any data was sent over the TCP connection. For instance, simply connecting via netcat, with no data being sent, would not trigger a notification.

Although this seems benign, data can be encoded via simply making a connection! In the proof of concept provided by the article, they encode bits using different ports on the host machine. This could also be done via DNS and other smuggling methods though.

This bug is unfixable (according to the developers) since the product must support domain-to-IP connection features. What's the point of an egress firewall if data can be smuggled out? I think this needs to be redesigned, honestly.

Within the legacy_parse_param function of the Linux kernel, there is an integer underflow in a verification for a bounds check. The verification can be found at here.

The bounds check is attempting to validate that the length is not larger than PAGE_SIZE - 2 - size where SIZE is a user controlled value. In this if statement, the size can be larger than PAGE_SIZE which leads to an integer underflow.

The underflow breaks the validation on the buffer being written to. As a result, an attacker can freely write data out of bounds linearly into this buffer. The authors wrote a LPE for exploiting this as well. They noted that although the CAP_SYS_ADMIN permission is required to exploit this bug, the permissions could be given in a namespace, allowing to call this vulnerable function.

The fix simply flips the math around to not include any subtractions. By doing this, the underflow on the verification is not possible. Any time there is weird math going on in a bounds check or length calculation, always check for overflows and underflows.

XNU is an operating system developed by Apple. Several parts of this ecosystem are open source, making it nice for vulnerability research.

While Ian beer was auditing code, he was looking for code with strange or unexpected semantics, including obscure failure cases. While reviewing the function ipc_port_copy_send, they noticed interesting return cases that may not be checked.

In the context of XNU ports, there are 4 possible states for ports that can be sent to this function. IP_NULL, IP_DEAD, a dead port and a live port. If you sent a dead port in, then the code needs to validate that the port does not return an error condition of IP_DEAD. Since the reference count is not incremented on the callback, the error handling is extremely important.

If the function is called without the return value being validated, the reference count may not be updated. The author found a code path with just this at ipc_right_copyin_two! What happens when there is a desync in reference counting? A use after free, since there is a pointer to an object being used which could be freed at any point.

Ian Beer comments on the mitigations added to the system, such as pointer authentication (PAC), heap allocation randomization and validation to make port faking with UAFs harder. To Apple, the name of the game is overarching mitigations instead of writing secure code.

There is a discussion on the exploitability as well. A large chunk of the discussion appears to be about bypassing the mechanisms put in place by Apple to make exploitation harder. This is over my head but would be worth reading if you are into iOS or MacOS exploitation.

OpenSea is a decentralized application for selling NFTs. Items can be listed on the application for a specific price, removed or sold from this.

On OpenSea, NFT sellers need to de-list their item fully in order for it to be completely removed from the list of sellable items. OpenSea offers a transfer feature to move the NFT from a main wallet to a secondary one.

There is the problem with this functionality though: the frontend for the website de-listed the NFT but the blockchain never did. The desync between the frontend view and the backend created problems.

In particular, the many of the listed NFTs that appreciated in value since their original listing. So, the attacker exploited this vulnerability to buy the NFTs at their original value for way less money. Damn, that's a real clever attack!

To get away with this, the attacker put their money into a mixer, making it untracable. From a single transaction of a Bored Ape NFT, they made off with 200K in ETH.

The author was looking from Universal XSS in Safari. This vulnerability is essentially just as bad as complete browser takeover since you can run code on any website, such as banks or Facebook.

After reading through several writeups for Safari UXSS bugs, the author decided to focus on Web Archive files. These files are created by Safari as an alternative to HTML when a user saves a website locally.

An insanely powerful feature of these files is that they specify the web origin that the content should be rendered in and the code for the website being ran. From an article in 2013, if an attacker can modify this file, it would lead to code execution by design.

There are two things that need to happen for this to work. First, forcibly get a user to download a file. Second, get them to open this file in the browser. If this was done, UXSS could be achieved. The author decided to look at custom URI schemes that specifically are allowlisted so they do not cause popups. After looking around, they settled on ShareBear because it was used for downloading files.

With the ShareBear application, the app validates if the user wants to open the file from the custom URI. However, this ask only happens if the user has not opened the file before! So, the user could click on the link, agree once, only to have the file changed to a completely different file type later. Yikes! This looks like it is waiting to get abused.

Unfortunately for the attacker, we cannot simply change the file type: gatekeeper gets in the way. This is because ShareBear gives files the com.apple.guarantine attribute.

Are there any other file types we can use? Apple has applications loaded as DMG files and shortcuts. While digging around with Shortcuts, the goal was to find a file type that would tell Safari to open the Web Archive without triggering the prompt. Symlinks tend to bypass things so I thought the shortcuts was a clever way to go with this.

By creating a shortcut to the Web Archive file, Safari would happily open it with no verification required from GateKeeper! Now, we can use a shortcut to open the Polymorphic file that we downloaded earlier that is now a Web Archive file. At this point, we have UXSS by clicking on a single link.

Another way to open the Web Archive file was also found. The obvious way to open Safari is via Launch Services with a local HTML file. When this is opened, via the file URI scheme, other file URIs can be accessed. When using this with a Web Archive Safari hangs.

For whatever reason, Safari does not perform validation for a Web Archive file if it has a host value in the file URI! Damn, this is such a weird bug that led to terrible consequences. Fuzzing and playing around for the win!

Another way to exploit this the vulnerability was via osax files or "Scripting Additions". The XML-based parser contained an AppleScript application that could contain HTML. It turns out that this HTML renderer and JavaScript application did not follow the Same Origin Policy (SOP). Now, stealing files is trivial to do, since Gatekeeper will happily open these files for us.

The final vulnerability was completed unrelated but still interesting. While fuzzing the icloud-sharing URI, they noticed a lack of domain validation when opening the file in a new tab. Since Safari lacks the URL to open a new tab but does not validate it, this allows an attacker to open arbitrary tabs. When in an iFrame, this should not be possible, leading to a sandbox escape of some sort.

Amazing research with so many weird rabbit holes. To me, there are a few main takeaways:

• Read the docs! This helps you zoom in on the fruitful surface quickly and learn expected vs. unexpected functionality to find bugs.
• Even in the web, fuzzing is useful. The author appeared to have found 2 bugs via fuzzing.
• Don't be afraid to go back to old research! Sometimes, little hints of ideas come back to be useful in the future, which was the case with the Web Archive files exploitation.

Multi Factor Authentication (MFA) is using a second form of authentication after the standard username and password. This is commonly a text message with a code or a TOTP app like Google Authenticator.

Box allowed for SMS messages and an TOTP MFA process. There is a insecure direct object reference (IDOR) on the the TOTP verification flow. An attacker could include their factor ID (app ID) and the code from their app to authenticate. Yikes!

The second bug in this was that the user being authenticated did not need to have the TOTP flow enabled; only the SMS flow was required. By initiating the SMS flow, grabbing the cookie for the user and sending the request to the TOTP endpoint with the bug above, this vulnerability could be exploited.

The authors explains the bug as being mixing MFA modes. Although this is true, I assume that this bug would still be valid even if the user had TOTP on. However, this is not explicitly stated in the article. Overall, good bug find!

Polkit is a SUID-root program installed on all Linux Distros. It is used to control system-wide privielges in Unix-like operating systems. Additionally, non-privileged processes can use this as a proxy to communicate with privileges processes.

The beginning of pkexec (sudo-like binary) main function processes command line arguments and searches for the program to be executed in the directories provided by the $PATH environment variable. When parsing this information, it makes the assumption that argv is not empty.

When argv is empty, it starts a FOR loop with an iterator starting at 1 with no validation for argv being empty. This leads to an out of bounds read and out of bounds write on argv[1].

What do we actually overwrite? And what with? When execve calls a new program, the kernel copies the arguments and ENV strings to the end of the new programs stack. Each element in an array contains a pointer to a string for either the ARGV array and ENVP, with the ending containing a NULL.

As a result, if argv[1] is the used, then it is the same as envp[0]. It first does this by reading from argv[1], which is really envp[0]. It takes this value (which is controlled by us) to find the program based upon the path.

Once it finds the path for the program, it writes it back to argv[1]. When calling a SETUID binary, many ENV variables are thrown out in order to not allow for trivial privilege escalation. Since this is really envp[1], this gives us an interesting primitive: the ability to add environmental variables back into the process! This is a non-memory corruption primitive, which means it is consistent, but powerful primitive. Data-only attacks are becoming more and more popular.

The exploitation is somewhat limited since pkexec clears its ENV only a few lines later. Is this even possible to exploit then? It turns out, there is a way to get an ENV variable used early enough in the program via the error handling!

In pkexec can print error messages to stderr via the call to g_printerr. It normally prints messages in the UTF-8 charset. To convert messages from one charset to another, iconv_open executes a shared library. However, the environmental variable GCONV_PATH can be used to load this in by force the above function being called.

So, by adding in the GCONV_PATH environmental variable, a shared library is loaded in as root. This is a complete user to root privilege escalation within most distros of Linux. Damn, that is impactful!

Joe Grand is an OG hacker from the days of the L0pt. He runs hardware hacking trainings all over the world. In this instance, somebody had a crypto wallet with 2 million of a cryptography, but forgot the password. Joe is trying to free the coins off of the wallet with hardware hacking black magic.

The wallet is a piece of hardware that stores the private key of the crypto wallet. By getting this information from the wallet, an attacker can get the bitcoin. In this case, the wallet has a pin on it that will give the private key if the pin is correct. Luckily for them, the source code for this product is open source.

Joe Grand (King Pin) thought that fault injection would be a good avenue to attack this from. Fault injection is the act of forcing the computer into a bad/unexpected state. If a fault is created, such as with clock or voltage glitches, instructions could be skipped, ran twice or values changed altogether. This is done by physically modifying the hardware of the computer, which he practiced on other wallets prior to this one.

The Micro Controller for the wallet has a protection that makes it impossible to read the contents of the memory. The goal is to glitch this check to allow for the reading of the memory by putting it into a DEBUG mode. Since the key is copied into RAM via a memcpy, this allows for the secret information to be recovered.

Practically, setting up the glitch is complicated though; even the teardown is hard! The author first removes all of the protection gunk of the chip to be able to connect to the proper headers on the PCB. After this, they remove the capacitors that are explicitly there to protect against voltage fluctuations. If these were still on there, then the glitching would be less consistent and harder to do.

To set this up properly, the authors used a Chip Whisperer. This was done by externally providing power to the chip via this tool then activating the glitch programmatically through the tool. If the attack worked, then a JTAG debugging menu should appear; the author has a JLink setup to communicate with the chip in the event that the attack works.

The Chip Whisperer has an amazing software interface. Using this, the author tries many different glitch timings. On every run, they see if the interface is open to connect. Otherwise, they try again. What is amazing about this, is that the process is completely automated. At this point, they simply have to wait!

After the glitch succeeds, Joe Grand used a Python program to dump the memory contents via JTAG. After running strings on the memory dump, a pin appears to unlock the device! At this point, they can recover the key from the device to get the money.

Hardware hacking requires lots of failures, patience and knowledge. This was an amazing article on how the hardware hacking was done to get the key off of the wallet. Trezor, the maker of the wallet, has a list of security vulnerabilities on their website as well.

In Wordpress, the post slug is the title put into a URL. However, the slug can be manually set by an author.

The function sanitize_title() governs how the title to slug transformation is done. When this is done, it converts all characters into ASCII, numbers, underscores and dashes. This sounds restricting but looking at the source code unearths some hidden functionality: the sanitization preserves URL-encoded octets, and, indeed, slugs can contain URL-encoded characters. What can a URL encoded string do for anything though?

Within post.php, the slug will eventually be URL decoded. If the slug does contain any URL-encoded characters, it gets encoded once again. Here is where the problem occurs: utf8_uri_encode only encodes Unicode characters. Crazily enough, utf8_uri_encode('<script>alert(1)</script>', 200) will output <script>alert(1)</script>. So, the URL encoding does not work as expected on the way back!

This functionality exists within the call to __truncate_post_slug(). The only time this gets called is when Wordpress is saving a post that has the same slug already. Since the post slug should be safe, but can now have arbitrary input, the character expectations have been violated. Pretty quickly the authors found an easy place that XSS was triggered on the page.

The fix for the vulnerability was to properly URL encode the data after the modification. According to the authors, extra care needs to be taken when modifying a value once it has been sanitized. Overall, this is a super interesting vulnerability that would only be possible to find through source code review and confirming assumptions about the code path.