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!

Microsoft has a security research portal. With this, updates are sent to all engineers who are involved on the project over email.

In the Microsoft system, the vulnerability report ID is VULN-####. This ID is used for the bug report. The IDs are easily guessable, as they are sequential.

Here is the weird part: if an attacker sent an email to the vulnerability report mail ID with the subject as the report ID above, they would be added to the email chain! Using this, an attacker could see updates to a bug report. This could include information such as a proof of concept and other details about the vulnerability.

Since they likely use BCC, the original discoverer of the bug would not have seen the message get sent to somebody else. Even though this was fixed by Microsoft, it was marked out of scope (no bounty). Overall, good find though!

When integrating an application with Google Drive, there are 3 ways: client side embedding, CDN URL then download the data on the server side or fetch the file via the GDrive API. The first two are what we normally see from a user perspective. The final one is where the fun beings.

When applications use this endpoint, they typically add a file parameter to access the information with the Authorization of this user. Then, a link is given back to the application to make another request to get the actual file. Since the file parameter is provided to the user, we can not only include the file but other parameters associated with this file. Would this be useful?

The parameter alt=media on the request to get an element from Google Drive. By placing this parameter, the contents of the file are returned instead of a JSON blob to make the next request. Now, if we can control this file on Google Drive we can control the JSON blob being returned for the next request. This could be used for a deadly SSRF attack.

Using this implicit trust of the application data being returned, the author found some other bugs. First, in a private program using the Google Drive API they used a path traversal to get fully control the item being grabbed. However, it did not suffer from the parameter injection but DID suffer from CRLF injection. Using the CRLF injection to alter the body of the request, they were able to get a limited SSRF.

Dropbox has a similar vulnerability as well. Using the exploit, they were able to make requests in the AWS EC2 instance to steal credentials.

Overall, this is an interesting piece of technology that is all over the place! This vulnerability is likely in many different applications that have yet to be discovered.

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!