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!

io_uring is a Linux kernel interface for providing asynchronous I/O. The basics of io_uring can be found here.

Most file implement the file op function read_iter. If this is not provided, then another function is called to perform an iterative read/write of the file. The pointer req->rw.addr is incremented by the size of the read/write.

Most of the time, this contains a pointer in userspace for the read/write being used. But, using the IORING_OP_PROVIDE_BUFFERS option, the pointer can contain a kernel buffer instead of a userland buffer.

Eventually, this pointer is later freed but only after the increment operation has taken place. This allows for the ability to free adjacent buffers at a controllable offset, giving a arbitrary free primitive on nearby chunks. Using this, a use after free could be trivially taken advantage of.

The patch for this vulnerability is to add a separate case to handle the kernel buffer vs. the userland buffer.

Overall, this is a super interesting primitive that could be trivially use for exploitation. This could be fun to write a full exploit for and would be a good place to start kernel exploitation at.

In iOS, there are privileges and permissions for which apps can use what data often called entitlements. Most of the time, a big dialog pops up to ask "Do you want share your location with app X?" This is post is about bypasses in the permissions for sensitive data for applications.

The XPC service for com.apple.gamed does not properly check for the com.apple.developer.game-center entitlement. As a result, any app can read the Apple IDs Email and Username, get an auth token for several apple applications, read some mail/ messages and much more.

The second vulnerability was a app enumeration issue. By making a call to the XPC endpoint com.apple.nehelper with a bundle ID, it returns an array of the UUIDs if the app with the bundle IDs is installed. Knowing what other apps a user has installed could be used for targeting users in foreign countries.

The XPC endpoint com.apple.nehelper accepts a user parameter called sdk-version. if this value is larger than 524288 the entitlement check for com.apple.developer.networking.wifi-info is skipped. This results in the WiFi information, such as the SSID, being accessible to the application.

Any installed application can access Analyticsd. This allows for the stealing of medical information, device usages, screen time, crashes and few items. The author does not say the actual vulnerability, or if this was just open.

Apple fixed the final vulnerability but never gave the author credit. The first three were unfixed for 120 days and Apple refused to comment on his messages. It sounds like the Apple Bug Bounty is not something to trust.

Overall, it is interesting to see bad permissions in iOS being so prevalent. Most of the time, we talk about memory corruption bugs, not the lack of entitlement checks.

Apache Dubbo is a Java based remote procedure call (RPC) framework. Dubbo can use a variety of protocols but defaults to the Dubbo Binary Protocol. There are a few main components:

• The Registry is responsible for the registration and search of services.
• Provider registers services to the Registry, while reporting real time info.
• Consumer gets a list of services from Registry. Then, can call the Provider directly.
• Monitor is used to view what is going on in the instance.

The author LOVES CodeQL for finding potential attack surfaces. While others use it for variant analysis, the other uses it for quickly learning about and maneuvering through the source code. In particular, they wanted to know about the specific inputs of the program.

From viewing the inputs, the hacker noticed a few potential ways to hit Hessian deserialization options, which were responsible for previous CVEs. This was done by forcing the code down unexpected paths. This was mainly found with CodeQL.

While decoding the RPC calls, there is a supposed opt-in only allowlist for specific deserialization types. However, because the deserialization type can be specified in the RPC call, we can specify any type we want. This results in a bypass of the opt-in only operation and leads to an insecure deserialization bug.

Moving away from the RPC calls, the author started to look for other potential vulnerable code sinks, which CodeQL has a good collection of. From this, they found a few potential calls that deserialize YAML. From the sink, they did a reverse search to where these inputs came from. By accessing a specific registry, we can inject malicious YAML to get code execution with no auth.

Customers can specify routes for scripts which are then executed on the host system. An attacker, with any scripting language, can create a new route that will be consumed by all users. This just feels like a vulnerability by design!

When the verifier and the user are different, bugs are bound to occur. When trying to check if the serialization is safe or not, a function is called that attempts to verify that the serialization type exists via the path. However, as an oversight, there is no error being triggered on this code!

When attempting to do the actual deserizliation, a different function is used though: lookupService(path). This will look up the service by path while the later does it by version AND path. This desync allows the verification to not find anything but the actual deserialization to successfully retrieve the object.

Overall, this is a large collection of awesome vulnerabilities. CodeQL is a great tool to have in the tool belt to making auditing much easier and learning about the flow of the application. This is a great post on the power of CodeQL in complicated code bases.

Exim is an extremely popular mail server which makes up 60% of mail servers on the internet. Vulnerabilities discovered in this that allow for code execution (especially without auth) put a lot of companies and people at risk.

The Exim binary has a set-user-ID-as-root and has a user to do so called the exim user. The log directory belongs to the exim user but is written to by the Exim root binary. By creating a symlink or hardlink on this file, arbitrary content can be appended to a file, such as /etc/passwd to obtain root.

Exim has a spool directory which handles incoming mail, which is also owned by the Exim user. An attacker with the exim privileges can write arbitrary data into the spool directory. Although this seems fine, this desync creates a much larger attack surface, where Qualys shows an arbitrary file write primitive.

The flag -oP override_pid_file_path option allows to create an arbitrary file as root. However, we do not control the contents of the file. Still, could be used to turn off ASLR in SYS or something like that. An similar vulnerability exists within the same flag but for file deletion instead via a race condition between file validation and file deletion with a symlink.

In another local command, there is a heap buffer overflow in the deliver_selectstring_sender function. This appears to process a string via sprintf that can be a string of arbitrary length. The POC is literally just exim -S `perl -e 'print "A" x 128000'`.

For debugging and logging purposes Exim copies the current working directory into a heap-based buffer. This results from the name of the current directory being placed into a heap buffer via strncopy, securely. However, after this call, the pointer is incremented by the size of the string being copied, which could be larger than the allowed buffer size.

If name is blank for the -F flag is used, the parse_fix_phrase function will still write a NULL byte to the buffer, even though a buffer of size 0 was created.

When Exim receives mail, it creates two files: an input and a data file. These lines of text (such as in mail) are separated by a newline (\n). An attacker can send a local email with a newline character in it, changing the orientation and understanding of the file being processed. Turning this into code execution requires the injecting of an Exim configuration string. This type of bug happens twice in the report. The article has a lot more into how they exploited this technique though!

The Exim filter allows for the execution of configuration strings in the program. Using a CLI flag, these can be tested on the Exim binary, which is totally fine as the Exim user via a forked process on the main binary. Since the fork runs under a privileges context, the file descriptors are still present from the privileged binary! By having the ability to send arbitrary data to privileged pipes, there are several injection points that could allow for memory corruption or command injection into the binary, which are shown in the writeup. To fix this, the FDs need to be created with the closed-on-exec.

The authors found several integer overflows via bad string parsing in C. One of them is via the size of a growable string overflowing (took 5 days lolz), another is the amount of recipients on an email and finally is in an incoming mail via only sending newlines which leads to code execution.

While setting up an SMTP connection, there is a bug that leads to an out of bounds read. The index smtp_ch_index can be reset to 0 while later being processed as smtp_ch_index-1 in an array. This leads to an out of bounds read that is not super exploitable but interesting!

spool_read_header calls fgets to read lines from the spool header file. The first section is a very large buffer with a fixed size. Since the buffer is not enlarged, it is vulnerable to a truncation issue, since the call to fgets restricts the size. Using this, a newline injection vulnerability is possible, but much less versatile as before.

Exim makes good use of function pointers to abstract away the type of reading it should do. For instance, there is a TLS encrypted stream or a regular stream. When using the BDAT series of commands, another function pointer is added though, which should eventually be set back to the original one. In several cases bad code paths, it is possible to NOT get this function pointer reset, causing unintended consequences to happen. This only leads to a stack exhaustion via a re-entry problem.

The function smtp_refill is used to read input characters from an SMTP client; it calls smtp_getc to read individual characters from the buffer. The function smtp_ungetc pushes characters back into the buffer after being read by the reading function above. By swiftly closing a connection after no data has been written, a call to smtp_ungetc can be made with EOF (-1) that will write to the -1 index.

A use after free exists in the TLS functionality. A struct pointer is saved to a local stack to be used. However, at some point, the function smtp_setup_msg could be called, which frees all allocated POOL_MAIN memory. Since this local variable is not set to NULL, it creates a use after free vulnerability. This use after free is on a VERY powerful object, as it allows for a memory leak and a write-what-where primitive.

The DKIM (domainkeys identified mail) signatures have a fairly simple out of bounds read. An attacker controlled size controls the amount of data being compared, even though the actual size may be different. The bug is in a memcmp, making this a very weird thing to exploit.

This is a wonderful demonstration of the diversity of vulnerabilities that can be found in complex software. The exploit techniques are fascinating with detailed docs on how and why they did certain actions. The custom heap management system of Exim is extremely pwnable, but will likely never be fixed. Additionally, the cmd strings being executed is a favorite exploit technique of the authors. All of the bugs that are exploitable for LPE or RCE have amazing docs on how they did it.

In the Opera browser, My Flow is a shared space between your computer and phone. This allows for the sharing of links, images, videos and many other things. Seems like a good attach surface!

web.flow.opera.com is the domain that loads this data. This appears to be a plain HTML on the page, which can be viewed with the browser dev tools. The page interacts with the browser extensions, but it was not apparent in the browser toolbox.

Why is this? Opera can add hidden browser extensions, which is really interesting! After using the flag –show-component-extension-options, the hidden extensions are shown, which shows Opera Touch Background.

This is a special browser extension that has lots of permissions. Finding XSS would essentially be game over, if it was found. When looking at the page. they found the code below:

const html = e.dataTransfer.getData('text/html');
const src = html.match(//);
if (src && src[1]) {
   const parser = document.createElement("span");
   parser.innerHTML = src[1];
}

This code is present when dragging an image. The vulnerability is the user controllable input going directly into the DOM with the call to innerHTML. If an attacker can control this input, they can get code execution in the context of the page.

The dataTransfer object on something being dragged does NOT have to be the location of an image. In fact, it can be anything. As a result, setting dataTransfer to <img src=x onerror=alert(1)> pop an alert pop, resulting in XSS.

To make this more believable, the author creates a POC, using some social engineering, to demonstrate the impact. When you start dragging the image, the page is redirected to the flow site. If you let go of the drag, the vulnerable code is ran and XSS is triggered. Can we go further though?

The Opera Touch Background extension had big time set of permissions. Most importantly, it had the SEND_FILE and OPEN_FILE permissions. Using this, we can write to a file with an executable script then open a will, which will execute it on demand.

I really appreciated the convincing POC, with the drag & drop into the redirect. Then, besides the XSS, they took this bug a step further to pop a shell. The impact of this bug is awesome and could have been used for some real damage.

This is a hands-on hardware hacking workshop. The creator of this has been hacking on hardware for years, has ALL of the tools and loves to share his knowledge. Instead of forgetting what I learned, I thought it would be wise to write it down somewhere.

Here is the guys philosophy:

• Identify Parts on the board
• Find datasheets for these boards
• Find potential attacks
• Do the attacks

When identifying chips on the board, there tends to be a logo for the brand and an serial identifier. The first few alphanumeric characters represent the brand (Atmel, Intel, etc.). The next set of characters represent the specific chip by the brand. Finally, the ending is to track the manufacture location. As a result, too many characters in the search will actual ruin it!

Another question: once you find the datasheet, how do you know the direction? There are multiple ways!

• Labeled with a '1' on the PCB.
• Indent dot on the corner.
• On chip with pins on only one side, the half circle indent and below the text.
• If there is only text, it is likely on the bottom left cover.

When batteries die, they go below their voltage threshold. For instance, a 9 volt battery can go to 90% of 9 (8.1 volts) before it stops working. I always thought that all of the juice left the battery. But, only 10% is actually used!

JTAG is a universal debugging protocol with amazing capabilities, such as data dumping and debugging capabilities. When a board is being manufactured, it needs to be tested. The most common way to test the board is over JTAG and with test points. It is common for the JTAG to be left on on many devices. But, it may have seemingly random pins around, making it hard to find.

If you see huge capacitors or resistors, it is likely for the power regulation and not super useful for pwning.

Overall, the creator of this workshop is incredibly knowledgeable with great war stories. I am excited to go back and learn more from the guy.

Open Management Infrastructure (OMI) is an open source project managed by Microsoft for managing Windows/Linux systems. Essentially, it’s Windows Management Infrastructure (WMI) for UNIX/Linux systems. This is installed on all VMs within Azure by default to send arbitrary commands to the server.

OMI is an amazing thing to target. First, it runs as Root, has been a UNIX socket and HTTP API. This looks great for both privilege escalation and remotely gaining access to the system. On some systems, this is even exposed remotely!

The flow is going from the CLI to the server. However, due to a coding error, if the authorization error is not present then the authorization is passed through. As C programmers are expected to do, the memory for the authinfo struct is initialized to 0. These two facts turn the user into root from the request!

The next bug has the same result, but comes from an entirely different location. The architecture has three parts: CLI (where users make calls), the OMIEngine that is a lower privilege process that proxies requests to the next section and OMIServer which executes the commands.

OMIserver trusts the OMIengine for the identity of the user; the OMIengine is expected to validate the auth state of the user as well. Some message types get proxied straight to OMIserver while others are validated for auth. What would happen if we used a forwarded request, which added the auth header, without initializing it? Root yet again! Same initialization issue as before.

The final bug is a race condition in handling the authentication request. When authenticating to OMIengine a socket connection is made to the OMIserver as it awaits a response on the auth request. However, since the handling of the auth is NOT different between OMIcli and OMIserver, we can impersonate the response!

Only a valid id is needed on the request, which appears to be somewhat sequential; hence, this is not a problem. So, making an auth request with a bad password, then racing the response, we can provide our own authentication response. If we control it, of course we are now root!

Considering these agents run as root, they are installed on all Azure VMs and some are publicly exposed, this is one of the worst bugs that could possibility be found. It is amazing how bad the authentication process was in this; some of it was just bad luck while some of it was bad logic. Interesting finds though!

Mattermost is a self-hosted Slack alternative for communication. This is the protect in test for the HackerOne report.

Mattermost has a conversion feature for permissions in channels. If a channel is private but moved to public, any user can join the channel and post comments on it. Whether or not a member can post a comment or not is a permission as well.

The permission for removing the ability to comment on a public channel does not work properly. This allows anyone to speak on the channel, even though they are explicitly denied from doing so.

Complex permissions environments commonly have weird edge cases. This is one of those times. From the H1 report, I am unsure if the bug is caused from the transition state or not. Regardless, still a bug!

Cloudkit is a data storage framework written by Apple, which is their equivalent of Google's Firebase. The access controls on this are vastly complicated and the author constantly made mistakes while trying to set it up himself.

Cloudkit has lots of features. If you want more, read the docs. But, this is a good overview:

• Containers are the top level storage system within Cloudkit. They all belong within a single iCloud account.
• The container has a production and a development environment.
• There are three different scopes. Private is when a data is only accessible by the one user. Shared is used for data shared between users. Public is accessible anyone with a public API token.
• Each environment has different zones. These zones are created by users to store the data and the organization is defined called record types.
• The record types have standard fields, such as INT, BOOL and TEXT.
• Each record type has records, which are individual stored data.

The main reason for this research was "It was quite complex to understand all different authentication flows, and security roles, and this made me curious. Could it be that this was not only complex for me to understand, but also for teams using it internally at Apple?" This is a wonderful reason for the research, since Apple eats its own dogfood.

While browsing through lots of websites, they found a few bugs, all relating to access control issues within Cloudkit. The first one in iCrowd+. They found that the public token had write and deleting permissions, which allowed them to modify the website directly.

Different APIs may interact with Cloudkit differently. While testing the the iCloud app, they wanted to see if the iCloud container was accessible from the Notes application. By changing the scope of the request, this appeared to be possible! What does this mean though?

By using this API instead of the more complicated iCloud one (which had been semi-reverse engineered by this point), the calls were easier to make. Through this API, the author made a substantial amount of calls, such as creating, updating, replacing and many other things. However, the forceDelete action actually worked on AppleNews!

This meant that any channel or article could be deleted that were stored in the com.apple.news.public container. This is because authenticated calls to Cloudkit were being made through the Notes app, which was improperly scoping the requests being sent.

The final bug was found in Apple Shortcuts, which allows you to trigger actions across app on the devices. Even though this should have been in the shared scope, it was in the public scope with a large GUID. Doing the standard API testing (like it was done above), did not work though. So, the author decided to use their own container and change the scope to com.apple.shortcuts instead. This mis-configuration did not allow for direct editing but got him a properly scoped token.

After a while, the author looked at the zones on this site. They noticed that even though iCloud did not support other zones, shortcuts did for some reason. With a permissions overlook, they could add their own zones. Finally, they tried to delete a zone and ... they bricked Apple Shortcuts.

The author was shocked when the deletion worked. Bricking something this big is bad, but I felt they took precautions to prevent this from happening. How else are you supposed to find this bug unless you try and test it? From these bugs, they author made 64K!

Overall, it is interesting to see Cloudkit used in action and real bugs that were wrong with it. I found the permissions issues to be interesting, particularly the deletion cases, since this is not seen all the time.

Desktop clients install custom URIs. In this case, AWS installed the workspaces URI on the system. This allowed for the launching of applications with username, password and other things using the URI only.

A common attack for desktop clients with custom URIs is finding an argument or command injection at the load up of the application. Since the browsers specifically URL encode items for this reason (%20 for a space), argument injection is becoming less and less common for these though.

The URI handler deliberately URL decodes the string and passes it as a parameter to the Workspaces command without sanitizing the input. The new command is passed to Workspaces executable. Although this seems fine, this uses that uses uses the Chromium Embedded Framework (CEF). Since the --gpu-launcher of this is known to have a command injection problem, this is bad!

The URI workspaces://anything%20--gpu-launcher=%22calc.exe%22@REGISTRATION_CODE will launch a calculator on Windows systems, which demonstrates code execution on the device.

Even though the browser protects against this nicely, people still make mistakes. Additionally, true command injection is unlikely in this context with commands being escaped by modern frameworks. But, argument injection can be just as bad and is not thought about as an attacker vector nearly as often.