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!

The extended Berkeley Packet Filter (eBPF) is a revolutionary technology that can run sandboxed programs in the Linux kernel without changing kernel source code or loading a kernel module. Because this code is ran in the kernel, finding a vulnerability in this can allow for kernel code execution.

The eBPF verifier added new functionality for 32-bit bound tracking. This restriction is added to call of the registers that it is taking care of and verifying. However, there is a bug in the tracking: the function uses known bounds on a 64-bit register to infer bounds for the register’s lower 32 bits.

This bounds check is not proper, which results in bad logic happening on unsigned values because of a logic bug. Instead of verifying that BOTH the maximum and minimum are within the bounds prior to setting the values, it only checks them one by one.

Using a bug in the eBPF, the common exploit method is to get an OOB read and OOB write. From there, compromising the kernel is considering a trivial task.

John Deere is the most popular brand for tractors and other big machinery used on farms. John Deere is a major technology company now as well. They have a developer portal in order to do interesting things with the data and machinery.

The first vulnerability was a username enumeration issue. When doing this, the author used found a list of the fortune 1000 companies to see who had made an account.

After playing with the APIs for a while, the author found an authorization issue that allowed for the queries of sensitive personal information about tractor owners. This is essentially all that was found, even though the article is incredibly long.

The author was asked to join a private bug bounty program that was created just for him. Because of this, and no public disclosure, the author declined the invitation and made the research public.

Express in a web server used in NodeJS. This website even uses Express for websites! The render API was designed to only pass in template data. Although doing anything else is NOT encouraged, people still do it.

By being able to pass in arbitrary data to the request, we can control configuration options of the template! This allows exploitation with vulnerabilities of XSS or RCE, depending on the configuration of the application.

An example of this can be seen in squirrelly. This is because it mixes pure template data with engine configuration options through the Express render API. By overwriting internal configuration options, being able to set arbitrary parameters within the render API causes major vulnerabilities.

It should be noted that special control is needed over the data being based into the render API. As well, a poorly made templating engine needs to be used, such as squirrelly.

Plone is a Python based CMS system that has been around since 2002. Zope is used to closely control what a theme author is allowed to execute within a python expressions, which is ran in a RestrictedPython library. Using this, globally available functions can be overwritten or restricted easily.

Because imports in Python are weird, using the random module it was easy to reference the OS module! This was done with the following code random._os.system("<code>"). But, using underscores (_) is not allowed.

It turned out that this restriction (no underscores) was not done on some of the functionality. By using the previous payload with this other function, it was possible to run arbitrary OS commands.

Sandbox escapes are difficult and require an amazing amount of insight into how the application works. This is a wonderful example of a restricted sandbox escape.

Dragonfly is a library used for image tasks such creating thumbnails, text images or anything else. Dragonfly is used by Refinery CMS, which is where the vulnerability was initially discovered at.

When processing certain types of operations, the ImageMagick utility is used. When using the utility, it was possible to control two of the parameters for the binary.

The first idea is command injection. However, anything malicious, such as ||, has a denylist preventing this from occurring.

The next idea is argument injection. This is when arbitrary arguments can be added to the binary. By adding spaces to one of the commands, it was possible to add arbitrary arguments to the command. Exploiting this is specific to the binary!

A feature of ImageMagick is to convert non-image files to images. One of the ways this can be done is by reading rgb codes raw from input or a file. This turns into an arbitrary file read vulnerability; the example is used to read /etc/passwd.

A similar function can be done in reverse, from an attacker controlled web server. This takes the vulnerability from a file read to a file write!

Achieving RCE can be done in multiple ways depending on the system; an arbitrary file write vulnerability essentially means game over. Apparently, there is some part of the CMS that makes this impossible to exploit, which has to do with a security mechanism that is rarely disabled.

ExifTool is a Perl library for reading, writing and manipulating image, audio and other formats of files. Gitlab is a code repository that is similar to Github. At Gitlab, they will pay out 50% (now 100% after this report) for findings in open source projects they use in order to ensure their own products are secure.

ExifTool simply ignores file extensions and attempts to figure out the format on the fly in depending on the input. Because of this, Gitlab's filter for the file system on the conversion can be bypassed for the tool.

One of the supported file formats is DjVu. When parsing DjVu annotations, the tokens use the insecure eval function in Perl to convert C escape sequences. Anytime the system call is made or something is directly interpreting code on the fly, this has to be looked into.

ExifTool attempted to validate and properly escape the input. However, a backslash followed by a newline could be used to break the parsing! Once the parsing was broken, it allowed for quotes to be added, escaping the string and inserting arbitrary Perl commands.

This code injection allows for RCE on the Gitlab servers, which is demonstrated by popping a shell to read process information. Even though this was in a 3rd party tool, Gitlab paid out 20K for the finding.

AWS Cloudshell is a way to interact with the terminal on an EC2 instance from the comfort of the browser. The library used for simulating the terminal is aceterm, which is meant to simulate the xterm shell.

The specific DCS escape code ("\eP+q") has a path that leads to the output from the terminal being added to the input terminal handler. By putting a newline in this string, it is possible to escape the current line and execute additional commands on the system. Damn, command injection from the Cloudshell!?

In order to trigger this bug, an attacker needs to get the victim to view something malicious in the terminal. This could be a malicious file on the system or simply curling a specific endpoint.

Instagram is an extremely popular website in the social media category. Finding XSS in this is a huge deal!

The XSS is fairly straight forward: an unvalidated link in a URL is passed directly into an href on an anchor tag. By adding a JavaScript:// URI, clicking on the link will result in code execution within the context of the victim account.

With the XSS, the author demonstrates that a Facebook OAuth token can be asked for, which results in an account compromise. Boom goes the dynamite!

There is a small caveat to this though: the link has to be middle clicked. This is because the event handler for a regular click is overwritten by some fancy JavaScript. Regardless, the researcher was paid almost 10K for their finding.

Cookies are identifiers stored with a particular website in the browser. They are commonly used for session identifiers, tracking information, locale and many other things. Without cookies, making an authenticated website work is significantly harder.

Cookies have many settings, such as the domain, the path and various security flags, such as HTTPOnly, SameSite and a few others. Although these flags and settings seem simple, the settings can be the difference between compromise and no compromise. This post goes into the security of the domain attribute.

The domain attribute is used to set the location where the cookie is referenced too. In order to make development easy to use, the top level domain (example.com) can allow its subdomains to access the cookies as well (subdomain.example.com).

However, this creates a potential security issue. If the cookie can be accessed and used on subdomains, then any website with an XSS vulnerability can access or use this cookie that is on the main site! So, in order to make sure the main website is safe, all subdomains have to be safe: that's a very tall ask.

When scoping out the domain attribute of a website, try not to allow it on other subdomains as well; this is ripe for an attacker to exploit into something that is not serious.

Audio file format MPEG layer I, layer II and layer III (MP3) need a way to include information about the music, such as the name, artist and other information. The file format for this comes in the iXML format for WAVE files.

An author on a Wordpress site can upload media files with XML tags: this is ripe for an eXternal XML Entity Injection (XXE). By adding an external entity in this format, it is a fairly straight forward XXE issue that can be exploited to take files from the OS, including /etc/passwd.

XXE is still on the OWASP top 10, making it an extremely impactful and common bug. There are so many odd places where XML is parsed and they all need to be tested for XXE.