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!

SSLVPN is essential protection for defenders. As a result, threat actors are constantly looking for bugs in it. This article describes and explains a vulnerability being used in an active campaign. They do this by doing some diffing on the changes.

The first interesting diff they did was on the Nginx route configuration for /etc/nginx/conf/locations.conf. The changes were setting a bunch of proxy_headers to the empty string and one of them to 'on'. Most notably, the X-pan-AuthCheck header was now being set to on.

The X-pan-AuthCheck header is used as part of an authentication check in uiEnvSetup.php. Authentication is entirely bypassed by providing this header and setting it to off. Hype!

Once logged in an application like this, RCE is practically a feature. AuditLog.php has a fairly obvious command injection. However, they were not only sure where the actual input came from but just knew it had to do with user impersonation. After trying a bunch of endpoints, they eventually found one that triggered the command injection from the username parameter on the call.

I personally liked the patch-diffing part of this article. As a defender of other companies, like this one, understanding what the vulnerability is and what you're up against is a requirement. So, I imagine so do a good amount of reverse engineering for these types of patches. Good work and knowledge sharing!

us-east-1 is the most popular region at AWS. Since the name is in many domains, such as S3 domains, the author decided to purchase us-east-1.com to see if it got any exciting traffic. The connecting computers are likely misconfigured somehow, but it's interesting nonetheless. They are flat out, but this domain or some higher-level domain string was accidentally left out.

prod-backend-db.cc66xuedqt2t.us-east-1.com had the most DNS queries. Given that there's some random identifier, I'd expect this to be some hosted database service URL from AWS. The root domain had a lot of hits as well.

loopback-streaming.us-east-1.com is likely some internal testing URL at AWS because it has loopback.

Another interesting one was Cisco Static File Reputation Host. Apparently, this is part of the legacy version of their email security gateway. Since this domain is incorrect, this email security gateway is misconfigured and could allow malicious files into the org.

Many other domains like storagegateway.us-east-1.com and s3.us-east-1.com were in there as well. The author thinks it was from somebody types out the wrong domain by hand instead of copying it. It's weird that these lasted for this long, as I'd expect them to notice the errors in the returned data. My personal favorite was the final one: smtp.mail.us-east-1.com

They kept getting a lots of emails from the AWS test environments as well. It appears that these test domains were configured incorrectly. For instance, aws-supply-chain@us-east-1.gamma.app.ketchup.aws.dev sent loads of emails. This is interesting and could potentially lead to data exposure of testing accounts.

The security of this domain matters. To me, many of the requests would be a lot more if it was the expected result to the end user. Once it fails, they probably reconfigured things. A malicious adversary could have returned unintended data or harvested the data if it was a storage system like S3. Additionally, phishing can be an issue as well. Overall, a good write up and money well spent on the domain!

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!