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!

postMessage is a way to send data from site to site on the client side. In particular, it tends to be used with between iFrames, such as with the Youtube player. Since postMessage is normally considered trusted input, many XSS and information disclosure bugs have appeared from this in recent years. To find bugs in this, the author uses the tool PostMessage-tracker.

When using postMessage, it is important that the website checks the origin of the request. If this is not done, then the page can be iFramed and communicated with from another domain.

At this point, it is incredibly important to see how the data is actually be used. In this case, the event data could be used to change some window settings. When reviewing how this was done, it was loading a domain from Cloudfront and a subdomain that was controllable by the user. From there, it would grab the JavaScript to run it via an eval. Was this code secure?

The goal is to make the domain match a malicious server instead of the expected domain. By messing with the parsing of the region, a region of .my.website/malicious.php?_bad would work to add our domain in the front. This code is shown below:

  var region = window.settingsSync.region;
  var subdomain = region.split("_")[1]+'-'+region.split("_")[0]
  domain = 'https://'+subdomain+'.settingsSync.com'

At this point, an attacker could load arbitrary JavaScript within the context of this iFrame! By specifying their own attacker server to host the JavaScript, an alert box could be popped. But, this was JavaScript execution within the iFrame; can we go back to the original page?

The main page had its own postMessage handler for grabbing credentials! The iFrame, that we have JavaScript execution in, is an allowed origin in the communication to the main iFrame. Now, by running JavaScript in the context of the iFrame, we can make a request for credentials for the site. Damn, that's really cool!

The second bug started while looking at the OAuth confirm page page of a website. The URL for the request would dynamically create GET request based upon the client id in the confirmation page request. While messing with the response of the request, one of the fields was being inserted into the page without any sanitization. If the response of this request could be controlled, then the site would be vulnerable to XSS.

The query parameter domain allowed for the controlling of the URL. However, setting this to an arbitrary domain was not possible because of Content-Security-Policy (CSP) reasons. When making HTTP requests, they adhere to the connect-src CSP rule. Since the actual directive was not specified, it uses the default, which contained *.companyb.com and *.amazonaws.com. Since we can easily host a page on *.amazonaws.com, we can easily bypass this restriction to load in arbitrary content.

Again, the CSP caused problems. The only acceptable locations for scripts (defined by the script-srcself and *.companyb.com. From previous work on this website, the author tried finding an open redirect on the company website to allow us to load data from an arbitrary location, bypassing the CSP.

The open redirect had a restriction for the domain though: the string had to end with companyb.com in the URL. By providing a URL encoded newline (%0A), the domain validation could be bypassed. Then, when the browser parsed for the website, it would assume that the newline was the end of the domain! As a result, the open redirect could be used to achieve XSS through the filter bypass.

Both of these bugs are amazing finds when many steps along the way! Most applications are built with a secure inner wall. But, once you penetrate that inner wall, assumptions breaks down and security is not as good. By abusing several features of the website with tiny bugs, two major compromises eventually occurred.

The device is a Baby Monitor that can be accessed remotely.

The camera uses the MQTT is a protocol commonly used by IoT services. Typically, there is a global service that the device reaches out to. In this instance, the server does not require any authentication to subscribe to, leaking device and user ids.

Real Time Streaming Protocol (RTSPS) is a protocol used for live streaming of data. To use this service, the application will request access to a specific camera feed. With this request, a destination is given back which will have the real time data.

Even though this happens via an HTTPs request, the MQTT service offers the same functionality. Since the MQTT service does not require any authentication, this call can be made to arbitrary cameras. Since we control the destination of the call, the data can be loaded to an attackers server.

The URL (destination) must be parsed by the device once it has been received from the MQTT server. However, the parsing has a fairly straight forward vulnerability: the URL is copied into a static buffer without a bounds check.

This appears to be an ARM device without very good randomization. So, to exploit this, a ret2libc attack is performed by corrupting the EIP on the stack. Since the value of r11 is controlled by the attacker, we can use the pointer to this as the string to execution in the attack.

The camera has a REST API to obtain AWS credentials used to store the recordings in the cloud; these credentials are unique per device. However, the credentials are not generated securely! By knowing the user id and device id, we can craft this authentication token ourselves.

To make matters worse, the credentials for accessing the S3 bucket are not scoped properly! By using these credentials, all data in the bucket is accessible. By simply using the S3 CLI it is possible to see all recordings for all cameras! Damn, that's real bad.

Overall, this was a really good report with many different vulnerability classes. From lack of authentication, poor password generation to memory corruption, this was an interesting write up to go through!

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!