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!

Apache Dubbo: All roads lead to RCE- 631

Alvaro Munoz - GHSL    Reference →Posted 4 Years Ago
  • 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.

21Nails: Multiple vulnerabilities in Exim- 630

Qualys    Reference →Posted 4 Years Ago
  • 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.

XSS to RCE in the Opera Browser- 629

Renwa - Opera    Reference →Posted 4 Years Ago
  • 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.

Hardware Hacking Hands-On Workshop (Sept 25th, 2021)- 628

Aw G    Reference →Posted 4 Years Ago
  • 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.

Agent in Azure Vulnerable to RCE (OMIGod) - 627

Nir Ohfeld    Reference →Posted 4 Years Ago
  • 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!

14617 Privilege Escalation leading to post in channel without having privilege- 626

FuzzsqldbOf    Reference →Posted 4 Years Ago
  • 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!

Hacking CloudKit at Apple- 625

Frans Rosen - Detectify    Reference →Posted 4 Years Ago
  • 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.

AWS WorkSpaces Client Remote Code Execution- 624

David Yesland - Rhino Security    Reference →Posted 4 Years Ago
  • 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.

macOS Finder RCE- 623

Park Minchan - SSD     Reference →Posted 4 Years Ago
  • inetloc files are shortcuts for internet locations, such as RSS feeds. However, this can also include the file:// URI.
  • When using this with executables on MacOS, the file is simply ran! The POC is an extremely simple file that just runs the Calculator App on MacOS. It should be noted that the POC has a file URI with a large amount of slashes (/) in the XML file. However, only 3 are needed from my personal testing of the bug. I do not know why they would make such a confusing POC. When opening this as an email attachment even, arbitrary programs can be ran.
  • The fix from Apple tried restricting the file URI. However, the validation was case-insensitive! This meant that FIle:// could be used in order to bypass the check on newer versions.
  • This is a simple bug that is really easy to exploit. However, I think you would need a way to call a program with specific arguments in order to exploit this to allow for complete compromise. I wonder if the terminal can be called in this way?

5 RCEs in npm for $15,000- 622

Robert Chen    Reference →Posted 4 Years Ago
  • Package managers are a complicated ecosystem. We are installing code to run on our system. In the context of most package managers, we must choose to execute this code by calling functionality. This means that the package being installed should not be able to compromise the computer prior to being executed. With this in mind, we need to guarantee that this is the case!
  • The package node-tar promises that any extraction will NOT overwrite files outside the given directory. Since NPM install deals with tarballs, finding a bypass would be super interesting!
  • The first vulnerability is exactly this. The tarball extraction validates that an absolute path is not being used. But, this check looks weak, as only a single substring comparison; this comparison simply tried to strip off the beginning path if it had a '/'. Putting /// (three slashes) would change to // (two slashes), bypassing the filter. Now, we can write a file to any location upon installation!
  • To patch this vulnerability, some serious validation had to be done. The bulk of the patch used the isAbsolute function to check to see if the path was absolute or not. If we could find a way to get a difference between the resolve (executor) and isAbsolute (parser) we could bypass this check.
  • On Windows, C:/ can mark an absolute path. Using C:/different/root, the path.resolve function has a weird special case when the second parameter is an absolute path; it just resolves it! Additionally, the double dot (../) is only done between path deliminators. As a result, C:../ is a valid drive that we can use. This allowed for a minimal directory traversal (one directory up). Using a symlinked package, this could be used to do more damage though.
  • node-tar handles hardlinks and symbolic links (but not NPM). But, there is a guarantee that these will not overwrite files out of the current directory. However, there is a directory cache which executes these checks. If we could get a fake entry in the cache, we could use it to do the classic symlink and hardlink attack, resulting in arbitrary files being written to the system!
  • The first POC was fairly simple. Add a folder, tar this folder and remove the directory. At this point, the legit file system is different than cached system. By adding a symbolic link with the same name as our folder, extracting the archive, it will simply trust the file being written to on the symbolic link. Damn, that's real bad!
  • To patch the original bug, they just remove the entry from the directory cache. To bypass this, implementation specific Windows code could be used to cause havoc on Unix. The check for \\ should be checked on Windows but NOT Unix. Now, the same bug could bypass the filtering functionality because the FS was Unix and not Windows. The same exploit as before works except that the file name a\\x can be used instead in the cache.
  • The NEXT patch was even more defense-in-depth than before with complete path normalization (which seems great). However, MacOS does additional normalization of paths, violating the assumptions for the directory cache. Using unicode craziness on MacOs, it is possible to desync the cache and file system to use the same exploit as before.
  • These bugs were going to be endless... as a result, the project decided to drop the cache entirely if a symlink was discovered, killing the bug class. Good on them!
  • Overall, I enjoyed the content of the article but I found some of the explanations to be extremely clear; this forced me to put a lot of time into the article to figure out what the bug was. Once I understood the bugs, they were awesome though! Parsing & action is really hard to do as different systems have different expectations.