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 kernel is a wonderfully complicated place. Many of the vulnerabilities found only make sense with a deep understanding of the eco-system; this is one of those cases.

Inside of the Linux kernel, the function fd_install makes a file descriptor available in userland. Once the code is in userland, it is important NOT to use this file descriptor anymore! This is because the user could free the resource themselves.

For example, fd_install(fd, file); would be called. Then, some time later, the same file descriptor is used to do something else to the file. However, in this small time window, the file descriptor could be freed with a call to close(fd), resulting in a use after free.

The author has an interesting note on exploitation! Most people would use this to try to get a memory corruption primitive to get code execution. However, there is an easier way: since the file descriptors are the same size and use a dedicated slab cache.

By triggering this vulnerability, the file descriptor may point to some other file, such as /etc/shadow. It is so wild that this memory corruption bug is extremely trivial to exploit by using the program itself for the primitive.

Of note, this vulnerability was found in 3 places in the Linux kernel, with only one of them being super exploitable. Overall, I enjoyed the write up, as the bug is very clear. Additionally, the exploitation of this bug is fascinating, since it gets an impactful result with little effort.

In Windows, many of the functions work with from the GUI with callbacks. This means that after some action is performed, then the callback function is made.

While using functions such as xxxMenuWindowProc and others of the GUI API, there is an issue with the callback setup However, this pattern is complicated, especially when functions may have side effects on some objects. What if the object type changes between the original call and the callback? Type confusion!

My first thought would be a race condition, since a type change between a threaded application would make sense. Instead, there is a complicated flow of callbacks being exploited. By setting up the callback xxxClientAllocWindowClassExtraBytes to trigger the NtUserConsoleControl method.

When the NtUserConsoleControl method is ran within the callback, the type has changed! However, upon further usage of the object in its current context, there is no check for a type change.

What does the type confusion do? There are likely many things this corrupted. The main one is that this leads to a user mode pointer being treated as the offset to a heap. This leads to an out of bounds access: both a read and write.

Using the OOB read and write, exploitation in the kernel probably is not too complicated. Interestingly enough, this was found being used in the wild! It was patched in the Windows January 2022 update.

Zoho manufacturers a suite of ManageEngine Desktop Central and Desktop Central Management Service provider (MSP) setups. A classic Software as a Service (SaaS) company.

In the web.xml file there is a filter that redirects all traffic. This filter is used for checking CSRF tokens, sessions and many other things. One of the filters is stateParserGenerator.processState, which is used to process the state cookie. Within the state, there is a very dangerous field: forwardPath.

By setting the forwardPath field, an attacker can trick the server into sending data to another location directly. This redirect bypasses other filters in the chain and goes directly to other servers but does not allow calls to REST API. This is referred to as an Arbitrary Request Forward. In the article, they link to a similar bug they find in the past.

To exploit this, an attacker could exploit a directory traversal vulnerability to write a file. The directory traversal check the file name but not the path, making it still possible to exploit. They wrote a malicious .jar (as a zip) file that wold get loaded on reboot.

This exploit chain was found in the wild. What's odd to me is that the author had found the arbitrary request forward vulnerability, but did not report it since they did not have the RCE bug. Why not just report the bug as is? If that was the case, then this zero day would not have been as impactful. Regardless, still a great bug to look for!

Argo CD is a Continuous Delivery (CD) service platform used all over the world.

To build a deployment pipeline, a user crates a Git repository or a Kubernetes Helm chart. A Helm Chart is a YAML file that embedded different fields to declare resources and configurations to deploy an application. The application can contain file names and paths in order to interact with the service with a more custom configuration.

These files being referenced in the Helm files should ONLY be within the single directory. In 2019, a commit was released to make this the case. For avoid stealing data, Helm charts should not be able to see files outside of the Helm directory. Was the patch implemented properly?

While viewing the Helm files, they noticed multiple locations where a URL could be specified. When doing the validation for the directory traversal, the code path only does this validation on file paths, not URLs. So, what's the difference between a URL and a file path?

In Go, the function ParseRequestURI is used. The documentation says the following:" It assumes that url was received in an HTTP request, so the url is interpreted only as an absolute URI or an absolute path." By getting the parser to accept a local file path, the validation step can be bypassed but request will still use a local file. The path /directory/values.yaml parses like a URL but is a legitimate file path.

According to the official security advisory, symbolic links can point outside of the Helm directory as well. Damn, this is a super classic problem that we are still seeing today!

Overall, the bugs are fairly straight forward but the article is not styled very well and is sometimes hard to parse. The Go language function to treat a URL as a local file was super interesting and not something that I anticipated.

Samba is the open source implementation of the SMB protocol. This product works on Linux and MacOS. By default, it is on for many devices by default. On Apple devices, the Time Machine service uses Samba with Guest authentication allowed.

The fruit module in Samba is an added enhancement for the Apple SMB client to communicate with the Apple Filing Protocol (AFP). Using the open source implementation of AFP (Netatalk), Unix-lie systems can communicate with Apple devices. Once a session is established, smbd allows for users to set extended file attributes on a file via the SMB2_SET_INFO. Besides a few select attributes, all attributes can be set.

The Netatalk metadata of a file is stored in the extended attribute named org.netatalk.Metadata. Since this attribute is not in the denylist listed above, an attacker can arbitrary set this attribute. The Netatalk protocol assumes that the Metadata information is benign, which results in catastrophic results.

The function fruit_pread function reads the metadata of a file. When attempting to read from a buffer, an attacker controls the value of ADEID_FINDERI, which is used as an offset into a buffer. Although there is a bounds check to make sure the original index is within the bounds of the buffer, the value being read in is fixed at 32 bytes. As a result, if the index is put at the last possible byte on the buffer, we get an out of bounds read of 31 bytes.

The function fruit_pwrite writes metadata to a file. The same bug above also affects the write path as well. This allows for a memcpy with attacker controlled data to write 31 bytes of data onto the heap. It is interesting that both the read and write versions of this code path suffer from the same vulnerability.

The vulnerabilities above are enough to get code execution. However, the author of the post found a variant of the vulnerabilities above while writing this up. The bug above occurs because of bad validation for the index being used in a memcpy. The variant has the same problem but when handling dates. Since the entries are much smaller, this leads to only a 3 byte OOB read and OOB write.

The vulnerability was exploited by Nguyen Hoang Thac and Billy Jheng Bing-Jhong from STAR labs at Pwn2Own in 2021. Additionally, Orange Tsai independently found this vulnerability. The ability to set the file attributes of the metadata seems like a round-about way of exploiting this. I'm personally curious how they found this. To me, after finding the bad sync (memcpy) they could trace it back to the inputs. Or they noticed the file attributes being written arbitrarily was weird (source) then traced all paths to eventually find this vulnerability.

To patch this vulnerability, the application now validates the index being used. Additionally, the AFPINFO_EA_NETATALK file attribute is now a denylisted attribute to write. Overall, great primitives to lead to code execution in an obscure part of the Apple Ecosystem.

Apache HTTP Server is the most popular web server on the internet and needs no introduction. Apache has many runtime loadable modules to extend functionality. One of these is mod_lua, which allows for Lua scripts to be written within the configuration file.

The HTTP specification has many different Content-Types. One of these is multipart/form-data which sends data in multiple parts with each one containing a Content-Disposition header with some other formatting as well.

In the Lua plugin, there is a function called r:parsebody() which parses the body of a POST request. When calculating the element data in the request, it subtracts the CRLF amount then 8 bytes more for the two CRLFs prior to the data. This size check ends once the -- string is found. However, what happens if this is improperly formatted? Any time there is a subtraction on a size, we should always think integer underflow!

If the form element is not properly formatted with the boundary string (--) appears less than 8 bytes into the payload, an underflow will occur. Since the variable is unsigned, it turns a small negative number into a very large positive number. Although this does not seem exploitable, there is a saving feature: later on, an allocation of size+1 is done, which will overflow into an allocation of size 0 if our original subtraction bug resulted in -1.

Down the road, this size is used for a memcpy to copy the elements data into a buffer. Since the buffer is no where near this size (because of the overflow), this result sin a large buffer overflow. Although they claim this leads to code execution, I feel like this would crash the server since it is a wildcopy with no stopping factors.

Overall, good find! I wish the write up had more pictures (instead of ALL text) as it is quite dense.

Apache HTTP Server is the most popular web server on the internet and needs no introduction. Apache has many runtime loadable modules to extend functionality. One of these is mod_lua, which allows for Lua scripts to be written within the configuration file.

The HTTP specification has many different Content-Types. One of these is multipart/form-data which sends data in multiple parts with each one containing a Content-Disposition header with some other formatting as well.

In the Lua plugin, there is a function called r:parsebody() which parses the body of a POST request. When calculating the element data in the request, it subtracts the CRLF amount then 8 bytes more for the two CRLFs prior to the data. This size check ends once the -- string is found. However, what happens if this is improperly formatted? Any time there is a subtraction on a size, we should always think integer underflow!

If the form element is not properly formatted with the boundary string (--) appears less than 8 bytes into the payload, an underflow will occur. Since the variable is unsigned, it turns a small negative number into a very large positive number. Although this does not seem exploitable, there is a saving feature: later on, an allocation of size+1 is done, which will overflow into an allocation of size 0 if our original subtraction bug resulted in -1.

Down the road, this size is used for a memcpy to copy the elements data into a buffer. Since the buffer is no where near this size (because of the overflow), this result sin a large buffer overflow. Although they claim this leads to code execution, I feel like this would crash the server since it is a wildcopy with no stopping factors.

Overall, good find! I wish the write up had more pictures (instead of ALL text) as it is quite dense.

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!

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.