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!

Sitecore is a popular CMS used by many Fortune 500 companies. This was the target of this post.

The title of the post contains "Order of Operations Bug." Some code needs to run in a very specific order. If it's done in the wrong order, then the protections are for nothing. The author tries to explain this with an example. They have file upload code that A) prevents directory traversal, B) decrypts the file path, and C) saves the file. The problem is that the directory traversal check on the encrypted file is useless since it's the decrypted content being used.

In SiteCore, there is a file read vulnerability right along the same lines but slightly more complicated. They have a nice graph that shows how this works but I'll just put some bullet points:

1. Initial validation is done
2. Check for the folder being allowed and check the file extension.
3. URL decode and strip out some content.
4. Access the file with the path.

The issue in the process from above is that the validation happens first, then a transformation occurs. Using this fact, URL encoding the path will bypass the validation and allow for reading of an absolute file path. This fairly classic vulnerability class is found in things requiring complicated parsing. For example, here's an XSS in Skiff from Paul Gereste that relies on modifications being made after calling DOMPurify.

To trigger this, a full path needs to be known. In configurations return exceptions, it's possible to leak the absolute path via an error message. With configurations without errors, some brute forcing and educated guessing must be done. Both are viable options, though.

In .NET systems, an arbitrary file read is effectively RCE. This is because the web.config contains a validation key for sessions. The sessions have a known vulnerability (or feature) for deserialization to arbitrary objects that leads to RCE. The protection to this is normally you need the key to sign the object. But since we have the key from the file read, we can make the object now.

I enjoy reading about new tips and tricks to look for. To me, order of operations bugs make total sense and there are probably a lot more out there.

Bing Maps is similar to Google Maps. When using the dev center portal, they noticed a parameter with an embedded URL. By using this endpoint, it was possible to include maps from an arbitrary location on Bing. They call this a CORS vulnerability, which is somewhat confusing to me though.

With the ability to add configuration files to another person's account, we have opened the door for a larger attack surface. The configuration file can be hosted from any location and can also link to a KML file used for styling the map. These map files render within the context of maps Bing but have a strict blacklist.

Notice how it's a denylist and not an allowlist. The denylist appears to be just a regex with some extra logic on top of that. The denylist didn't account for mixed case characters. So, it's possible to add an href with jAvAsCriPt:(confirm)(1337) as the content. Of course, clicking on this link will now lead to XSS on the page.

The XSS takes place on bing.com, which is crazy. Using this, an attacker could have read through many Microsoft web apps because they allow requests from Bing.

The author claims this is wormable, but I tend to disagree with that. To me, if it's wormable, it should be 0 or 1 click. The user first needs to click on the page and then click on the specific link. Two clicks isn't wormable to me. Regardless, I enjoyed the vulnerabilities that were found in order to find this super impactful XSS!

Decentralized Autonomous Organizations (DAOs) are on-chain entities that can manage decisions and capital like companies do. The upside is that the formation of a DAO is much easier than a regular company. The article has many exploit types but I enjoyed the softer vulnerability on it personally versus the classic reentrancy and flash loan issues. So, that's what I'm going to post.

Proposal execution is typically decentralized. Since this was the case after a Sonne Finance governance approval, the execution to add markets should have been fine. The order of operations really mattered. By doing things out of order, $20 was stolen from the market. To resolve this, ensure that multi-step proposals happen in the specific order TOGETHER.

The next thing to consider are the proposals themselves. Since it's decentralized, anyone can make a proposal. Ensuring that these aren't approved for funky business is crucial for not getting completely pwned. Tornado Cash had a proposal for C503893 and one that claimed to be the same with a slight upgrade to it to destroy the old contract. In reality, the proposal deployed a different contract at the same location as the original proposal to add a backdoor to the system.

Eventually, this led to $1M being stolen from the protocol then mixed through Tornado Cash itself (lolz). To prevent these issues from happening, a few things can be done:

• Analyse all submitted proposals. Given that not everyone has the technical capability to review code, this is challenging though.
• Proposal template should prevent use of the CREATE/CREATE codes to do some craziness in the replacing of the code.
• DAO's are good until they're not. In this case, similar to voting in the USA, not everyone is properly informed. So, having a forum with official communication on what something is can be a major positive influence on how the voting works.

Insider Threats sound like science fiction but they are real. Threat actors like join companies in order to get the secrets and steal funds. Additionally, a rogue engineer can even steal the funds sometimes. To prevent these attacks from happening, carefully vet who you hire and ensure there are no single points of failure.

Another problem is decentralization is doing stuff quickly or at all. In the case of Swerve Finance the team was completely anonymous. Additionally, they entrusted their multi-sig to big players like SBF. Eventually, when governance operations were needed, there was no one there to be found. Anon's can disappear in a moment. To resolve this, ensure people have reputations on the line and do not have ulterior motives.

Timelocks are used to execute code after a specific time after the proposal; this gives users time to leave the system if something happens or perform an emergency stop if it's deemed to be malicious after approval. Compound, a defi loan system, had proposed a code change that had a serious bug in it that allowed COMP rewards to be claimed, which shouldn't be possible. Since there was a timelock on the governance actions, the code couldn't be fixed fast enough.

The pro of DAOs is that you can be anonymous and methodical. At the same time, these can be cons. Developing the DAO in such a way that A) people are held responsible for their actions and B) swift action can be taken in times of need is essential. Good write-up discussing some of the edge cases of DAOs!

WatchTowr monitors and protects various clients as a service. Fortinet had a nasty vulnerability in FortiManager, leading to many users getting popped. To fully understand the vulnerability, the authors decided to setup a lab environment to play around with this. In the process of doing this, they found even more bugs.

FortiManager is the tool for administrating Fortigate devices. FortiManager communicates to the devices using the FortiGate-To-FortiManager (FGFM) protocol. This runs over TCP and is tunneled over TLS. The authors were messing around with this and trying to create their own client. The binary fgfmsd contained functionality for decoding the protocol and creating packets for it.

put_json_cmd had a large amount of functionality and things that it could do. They say that " vulnerabilities often congregate around functional boundaries, as one side of the RPC interface often makes differing assumptions about the obligations of its counterpart" which I believe is really true. It's a good place to look for bugs for sure.

On the FortiManager side, they reverse-engineered the handler for this function. While looking in there, they found a trivial command injection and multiple arbitrary file writes. Since they found the sink first, they had to reverse engineer the source to trigger the functionality. After some time, they figured this out.

This wasn't the vulnerability that was being exploited though! Will binary diffing, there are several other command injections being exploited.

They also release a full proof of concept and how to work around Mandiants indicators of compromise. To me, this is unnecessary and doesn't help anyone besides threat actors. There are ways to write a test that your vulnerable binary without doing a full exploit. Additionally, posting workarounds with Indicators of Compromise (IoCs) doesn't serve much purpose for resolving this issue either.

I think the story and the vulnerability are fun. However, I didn't like the tone of the article very much. Although I'm slightly exaggerating the tone felt like, "These people are idiots, and we're so smart." At the end of the day, security researchers are trying to help vendors, so we should act this way. Companies make mistakes in their security, and we should help improve that in a non-condescending way.

iOS 18 contains a new security feature—an inactivity reboot. This feature was widely discussed in the media, with the potential for a wireless component, with other iOS phones communicating with it as well. So, the author decided to investigate how the feature worked.

There are two important states of an iPhone for this post: before first unlock (BFU) and after first unlock (AFU). BFU requires the passcode, not Face ID, to unlock the phone. This is because the user data is encrypted with the PIN. Once it's unlocked for the first time, the user data is decrypted, giving access to much more functionality and attack surface. The AFU state is much more susceptible to attacks than the BFU state as a result.

Apple code contains a lot of DEBUG strings. A quick search shows a string called inactivity_reboot on Github. After reverse engineering some logs and kernel drivers, they came to the Secure Enclave Processor (SEP) as the source of this reboot happening from. Recently, the firmware keys for this were leaked, allowing for reverse engineering of the code via binary ninja. Unfortunately, there are no symbols and very few debug strings.

The rumor is that the reboot happens after 72 hours. So, the author searched for the constant in seconds and milliseconds. Sadly, optimizations are made, but binary ninja knows how to undo these optimizations to search for the values still! Crazy! They found a series of values that corresponded to 3 days, 2 days, 1 day, and 2.5 hours as an enum in the code. Neat!

They didn't look much deeper than this. But, they did find out that there is nothing to do with phones communicating with each other to do this - it's all just an internal timer.

This was an interesting dive into a new security feature by Apple. Law enforcement doesn't seem happy with this change but it also acts as a major improvement against theft. Good writeup!

OvrC cloud is a cloud based remote management and monitoring system used by IoT devices. It's used by Control4, Wattbox and many other products. Alongside this, it can be used to integrate with third party products for management such as Roku and Sonos.

In the OvrC platform, the MAC address is used as the identifier. The MAC address has two parts - device manufacturing vendor and an organizationally unique identifier (OUI). Since the first three bytes are known, the space is 2^24 or about 16 million. Using the /v1/devices/find endpoint, it's possible to find all device MAC addresses.

Seeing MAC addresses isn't a big deal until you chain this knowledge to perform more damage. The /v1/devices/confirm API is used to register a device to a particular user. When doing this, they must know the serialNumber that must be on the IoT device itself. However, the serialNumber is checked - this allows people to register arbitrary devices.

The above attack only works if the device is unclaimed - what about already claimed devices? A hub is a device that controls multiple IoT devices at a time. Since this can be done on already registered devices, they were curious about the permission capabilities of the hub. The hubs have the ability to unclaim arbitrary devices! So, using this, it was possible to register a device and use the previous attack from before. dsUpdateFoundDevices can be used to a similar effect as well.

Using these attacks from before, it's possible to claim arbitrary devices. For instance, it's a camera, we can watch the stream. The hub has hardcoded superuser credentials. The hub has hardcoded superuser credentials that are just the mac address and ServiceTag on the account, both of which can be viewed from the cloud on a claimed device. This is accessible locally or remotely using the OvrC cloud.

The superuser account has the ability to run arbitrary bash commands on the device by design. All of these vulnerabilities are fairly simple. The interesting part was having them all paired together to go from not knowing anything about the device to executing arbitrary commands on it. Good research!

AWS WAF only supports plain text and JSON by default. When invalid JSON is found (such as a duplicate key), the default option is to proceed on with the JSON. Another option is to evaluate as plaintext.

The evaluation of the JSON is done before the string matching. So, by providing a JSON object with a duplicate key (that AWS considers invalid), we can now add arbitrary text to bypass the WAF.

Another issue they found was around escape sequencing. AWS did not evaluate JSON escape sequences but most servers do. If there is a situation where input validation is important on a particular key in JSON, the escape sequences can be used to bypass this check in the name.

Trying to make the perfect WAF is a losing battle. I do enjoy parser differential vulnerabilities so I did enjoy this article though!

multipart/form-data is used for forms that include binary data, which can be broken into multiple parts. Each part has a boundary string (declared in the actual requests headers) that contains its own headers. The Content-Disposition sub header is used to define parameter name and filename content of the request. Content-Type is used to specify the media part of the content like a normal header as well.

While creating a WAF in Lua, they noticed it was super easy to bypass the parsers for this. In the end, no parsers follow the RFC was well as they should. File validation is important for file extension checks, MIME type validation, size limitations and several other things. The rest of the article is bypasses for tricking WAFs and servers.

In practice, the application/x-www-form-urlencoded can be used as the content of a multipart/form-data. Many WAFs do not support the multipart/form-data and will effectively ignore it. Since the WAF can't handle it by the server can, URL encoded data will be decoded on the backend but not by the WAF itself, giving a difference between check and usage. This was true of HAProxy, AWS WAF and AWS Lambda.

The next bypass is the handling of duplicate parameters. Both name and filename can be duplicated - if this happens, one may parse the first while the other may parse the second. This is also true with the full header data.

CRLF Parsing seems inadequate in many cases too. Some only delimit from \r\n\r\n while others will just use \r. Single quotes on parameter names instead of double quotes causes a similar effect. In PHP, if the closing boundary string is missing, it will parse fine while other things will not.

The final bypass, and the authors favorite, has to do with a RFC update. With the update, filename* parameters allow for special characters and the ability to specify an encoding. For instance, filename*=utf-8''filename.pdf if s valid parameter. In practice, this allows for URL encoding the filename information which most WAFs are not going to do. They give an example of PHP file validation.

The second half of the article are bypasses that they found in various engines. When running this on OpenResty with Lua in front, literally all of the bypasses above worked. In the case of the Nodejs library Busboy, it's super permissive. The filename parameter with and without the encoding supported created different priorities locally than in most servers, creating an easy bypass.

In Flask, the trick for Busboy also works. Additionally, if separator of a semicolon is left out (only a space) in a header as a delimiter then Flask won't parse it either. Finally, duplicate disposition headers will use the first instead of the expected second. This was also true on FortiWeb WAF.

The issue isn't a single implementation - the issue is that all of the different implementations do different things. By combining these parsers, similar to HTTP smuggling, we can bypass security protections. There are going to be more and more bug classes like this in the future for things that have 10's of parsers and are complicated. Good write up!

In macOS, most processes run in a restricted sandbox with the com.apple.security.app-sandbox entitlement. These sandbox restrictions are applied before the app's main function via containerization via the dyld library. Files that are dropped from the app are quarantined by default. Forked processes inherit the properties.

The Service Sandbox, such as Apple daemon services, manually call the sandboxing via app specific sandbox properties. In this mode, the quarantine functionality has to be manually invoked and is not done automatically. A common way for a sandbox escape in the past was targeting Mach services running the System or User domain. The PID domain seems to be accessible to all sandbox apps, giving us some more attack surface without extra entitlement checks.

The Application service type is a newer XPC service. When loading an application, it appears that it is automatically registered to the XPC service when loaded. The key insight is that we have an access control issue - the sandbox applications are able to call this API with lots of permissions. To exploit this, they started finding all applications that were XPC services registered to the PID domain that were XPC Applications.

SystemShoveService.xpc has powerful entitlement for com.apple.rootless.install to work around Protection (SIP). The XPC service does not check the incoming client. This allows us to drop an app folder that will not be quarantined or a DMG file to be executed. They have a separate blog post on this one.

storagekitfsrunner runner only had a single function that took in an executable path and arguments. Obviously, this leads to the ability to start a process that isn't sandboxed to escape.

Many of the other vulnerabilities are similar to this pattern. Call XPC from the sandbox to execute a privileged action. "Privileged" in this case is interesting though. If there is any file handling, these files will be created without quarantine, thus resulting in them being directly executable. Much of figuring out the vulnerable apps required a ton of reverse engineering to do.

Another one was an app with the Full Disk Access TCC entitlement. It's purpose is to give an app complete read/write access to the file system. This is done by calling the sandbox_extension_issue_file to issue a file token under the hood. This pattern of proxying permissions from an XPC app to the underlying app is a somewhat common pattern but can suffer from a confused deputy problem. Another attack uses this to access Photos and the camera directly to bypass a TCC permission check.

Several of the issues required funny symlink or folder creations to exploit properly. All in all, they ended up with 10+ vulnerabilities with 5 still in the patching queue. Once you find a new attack surface that seems unexpected, hit it hard until all of the bugs are gone! Good post on the root cause of the vulns and how they were exploited.

CyberPanel is a free web hosting control plane. Under the hood, it's a fairly simple Django app. The main purpose of it is setting up services like FTP, SSH, etc. on a box. It has a login screen to prevent everyone from being able to do this of course.

While reviewing the code, they noticed that authentication checks were added manually to every API instead of being global through a middleware. From reviewing previous finding, they found an authentication bypass for file upload through a missed authentication check. From reading about previous findings, they determined that command injection and authentication issues were likely. Do your homework kids!

Using Semgrep, they stumbled across upgrademysqlstatus. This is missing authentication and executes arbitrary commands on the OS. The best of both worlds!

Unfortunately, the command injection didn't work because of a recently added secMiddleware that was doing input validation on inputs to prevent these types of issues. After fuzzing it and trying some Linux tricks they didn't find anything. However, they did notice a funny design flaw with the input validation!

secMiddleware was only checking the inputs IF it was a POST request. However, each request in Django can be processed by more than one verb. So, by making an OPTIONS request the verification is bypassed. This means we have a successful pre-auth command injection. They found another variant of this as well.

Good write-up! I like that the author did their homework on previous bugs in order to identify pervasive bug patterns in the code base. The bypass for the input validation was quite funny as well.