We identified several vulnerable applications in the Google Play Store that represented over four billion installations. We anticipate that the vulnerability pattern could be found in other applications. We’re sharing this research so developers and publishers can check their apps for similar issues, fix as appropriate, and prevent introducing such vulnerabilities into new apps or releases.  As threats across all platforms continue to evolve, industry collaboration among security researchers, security vendors, and the broader security community is essential in improving security for all. Microsoft remains committed to working with the security community to share vulnerability discoveries and threat intelligence to protect users across platforms.

After discovering this issue, we identified several vulnerable applications. As part of our responsible disclosure policy, we notified application developers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR) and worked with them to address the issue. We would like to thank the Xiaomi, Inc. and WPS Office security teams for investigating and fixing the issue. As of February 2024, fixes have been deployed for the aforementioned apps, and users are advised to keep their device and installed applications up to date.

Recognizing that more applications could be affected, we acted to increase developer awareness of the issue by collaborating with Google to publish an article on the Android Developers website, providing guidance in a high-visibility location to help developers avoid introducing this vulnerability pattern into their applications. We also wish to thank Google’s Android Application Security Research team for their partnership in resolving this issue.

In this blog post, we continue to raise developer and user awareness by giving a general overview of the vulnerability pattern, and then focusing on Android share targets, as they are the most prone to these types of attacks. We go through an actual code execution case study where we demonstrate impact that extends beyond the mobile device’s scope and could even affect a local network. Finally, we provide guidance to users and application developers and illustrate the importance of collaboration to improve security for all.

Overview: Data and file sharing on Android

The Android operating system enforces isolation by assigning each application its own dedicated data and memory space. To facilitate data and file sharing, Android provides a component called a content provider, which acts as an interface for managing and exposing data to the rest of the installed applications in a secure manner. When used correctly, a content provider provides a reliable solution. However, improper implementation can introduce vulnerabilities that could enable bypassing of read/write restrictions within an application’s home directory.

The Android software development kit (SDK) includes the FileProvider class, a subclass of ContentProvider that enables file sharing between installed applications. An application that needs to share its files with other applications can declare a FileProvider in its app manifest and declare the specific paths to share.

Every file provider has a property called authority, which identifies it system-wide, and can be used by the consumer (the app that wants to access the shared files) as a form of address. This content-based model bears a strong resemblance to the web model, but instead of the http scheme, consumers utilize the content scheme along with the authority, followed by a pseudo-path to the file that they want to access.

For example, assuming that the application com.example.server shares some files under the file:///data/data/com.example.server/fileshttps://www.microsoft.com/images directory that it has previously declared as shared using the name shared_images, a consumer can use the content://[authority]/shared_images/[sub-path]/[filename] URI to index these files.

Access is given by the data sharing application most commonly using the grantUriPermissions attribute of the Android manifest, in combination with special flags that are used to define a read or write mode of operation. The data sharing application creates and sends an intent to the consumer that provides temporary fine-grained access to a file.  Finally, when a provider receives a file access request, it resolves the actual file path that corresponds to the incoming URI and returns a file descriptor to it.  

Implementation pitfalls

This content provider-based model provides a well-defined file-sharing mechanism, enabling a serving application to share its files with other applications in a secure manner with fine-grained control. However, we have frequently encountered cases where the consuming application doesn’t validate the content of the file that it receives and, most concerning, it uses the filename provided by the serving application to cache the received file within the consuming application’s internal data directory. If the serving application implements its own malicious version of FileProvider, it may be able to cause the consuming application to overwrite critical files.

Share targets

In simple terms, a share target is an Android app that declares itself to handle data and files sent by other apps. Common application categories that can be share targets include mail clients, social networking apps, messaging apps, file editors, browsers, and so on. In a common scenario, when a user clicks on a file, the Android operating system triggers the share-sheet dialog asking the user to select the component that the file should be sent to:

While this type of guided file-sharing interaction itself may not trigger a successful attack against a share target, a malicious Android application can create a custom, explicit intent and send a file directly to a share target with a malicious filename and without the user’s knowledge or approval. Essentially, the malicious application is substituting its own malicious FileProvider implementation and provides a filename that is improperly trusted by the consuming application.

In Figure 2, the malicious app, on the left, creates an explicit intent that targets the file processing component of the share target, on the right, and attaches a content URI as an intent’s extra. It then sends this intent to the share target using the startActivity API call.

After this point, most of the share targets that we have reviewed seem to follow a specific code pattern that includes the following steps:

1. Request the actual filename from the remote file provider
2. Use this filename to initialize a file that is subsequently used to initialize a file output stream
3. Create an input stream using the incoming content URI
4. Copy the input stream to the output stream

Since the rogue app controls the name as well as the content of the file, by blindly trusting this input, a share target may overwrite critical files in its private data space, which may lead to serious consequences.

Impact

We identified this vulnerability pattern in the then-current versions of several Android applications published on the Google Play Store, including at least four with more than 500 million installations each. In each case, we responsibly disclosed to the vendor. Two example vulnerable applications that we identified are Xiaomi Inc.’s File Manager (1B+ installs) and WPS Office (500M+ installs).

In Xiaomi Inc.’s File Manager, we were able to obtain arbitrary code execution in version V1-210567. After our disclosure, Xiaomi published version V1-210593, and we verified that the vulnerability has been addressed. In WPS Office, we were able to obtain arbitrary code execution in version 16.8.1. After our disclosure, WPS published and informed us that the vulnerability has been addressed as of version 17.0.0.

The potential impact varies depending on implementation specifics. For example, it’s very common for Android applications to read their server settings from the shared_prefs directory. In such cases, the malicious app can overwrite these settings, causing the vulnerable app to communicate with an attacker-controlled server and send the user’s authentication tokens or other sensitive information.

In a worst-case (and not so uncommon) scenario, the vulnerable application might load native libraries from its data directory (as opposed to the more secure /data/app-lib directory, where the libraries are protected from modification). In this case, the malicious application can overwrite a native library with malicious code that gets executed when the library is loaded. In the following section, we use Xiaomi Inc.’s File Manager to illustrate this case. We demonstrated the ability for a malicious application to overwrite the application’s shared preferences, write a native library to the application’s internal storage, and cause the application to load the library. These actions provided arbitrary code execution with the file manager’s user ID and permissions.

In the following sections, we focus on this case and delve into the technical details of this vulnerability pattern.

Case study: Xiaomi Inc.’s File Manager

Xiaomi Inc.’s File Manager is the default file manager application for Xiaomi devices and is published under the package name com.mi.android.globalFileexplorer on the Google Play Store, where it has been installed over one billion times.

Besides having full access to the device’s external storage, the application requests many permissions, including the ability to install other applications:

Further, it offers a junk files cleaner plugin as well as the ability to connect to remote FTP and SMB shares:

Vulnerability assessment findings

During our investigation, we identified that the application exports the CopyFileActivity, an activity alias of the com.android.fileexplorer.activity.FileActivity, which is used to handle copy-from-to file operations:

Since this activity is exported, it can be triggered by any application installed on the same device by using an explicit intent of action SEND or SEND_MULTIPLE and attaching a content URI corresponding to a file stream.

Upon receiving such an intent, the browser performs a validity check, which we found to be insufficient:

As depicted above, the initCopyOrMoveIntent method calls the checkValid method passing as an argument a content URI (steps 1 and 2). However, the checkValid method is designed to handle a file path, not a content URI. It always returns true for a content URI. Instead, a safer practice is to parse the string as a URI, including ensuring the scheme is the expected value (in this case, file, not content).The checkValid method verifies that the copy or move operation doesn’t affect the private directory of the app, by initializing a file object using the incoming string as an argument to the File class constructor and comparing its canonical path with the path that corresponds to the home directory of the application (steps 3 and 4). Given a content URI as a path, the File constructor normalizes it (following a Unix file system normalization), thus the getCanonicalPath method returns a string starting with “/content:/“, which will always pass the validity check. More specifically, the app performs a query to the remote content provider for the _size, _display_name and _data columns (see line 48 below). Then it uses the values returned by these rows to initialize the fields of an object of the com.android.fileexplorer.mode.c class:

Given the case that the _display_name and _data values, returned from the external file provider, are relative paths to the destination directory, after exiting from the method above, these class fields will contain values like the ones depicted below:

As shown above, the paths (variables d and e) of this file-model point to files within the home directory of the application, thus the file streams attached to the incoming intent are going to be written under the specific locations.

Getting code execution

As previously mentioned, the application uses a plugin to clean the device’s junk files:

When the application loads this plugin, it makes use of two native libraries: libixiaomifileu.so, which fetches from the /data/app directory, and libixiaomifileuext.so from the home directory:

As apps don’t have write access to the /data/app folder, the libixiaomifileu.so file stored there cannot be replaced. The easiest way to get code execution is to replace the libixiaomifileuext.so with a malicious one. However, an attempt to do so would fail since in this particular case, the vulnerability that we described can only be used to write new files within the home directory, not overwrite existing files. Our next inquiry was to determine how the application loads the libixiaomifileu.so.

Our assessment showed that before the application loads this library, it follows the following steps:

1. Calculate the hash of the file libixiaomifileu.so, located in the /data/app directory

2. Compare this hash with the value assigned to the “libixiaomifileu.so_hm5” string, fetched from the com.mi.android.globalFileexprorer_preferences.xml file

3. If the values don’t match, search for the libixiaomifileu.so file in the /files/lib path in the home directory

4. If the file is found there, calculate its hash and compare it again with the value from the shared_preferences folder

5. If the hashes match, load the file under the /files/lib using the System.load method

Given this behavior, in order to get code execution with the file manager’s user ID, an attacker must take the following steps:

1. Use the path traversal vulnerability to save a malicious library as /files/lib/libixiaomifileu.so (the file does not already exist in that directory, so overwriting is not an issue)

2. Calculate the hash of this library to replace the value of the libixiaomifileu.so_hm5 string

3. Trigger the junk cleaner plugin with an explicit intent, since the activity that loads the native libraries is exported

An acute reader might have noticed that the second step requires the attacker to force the browser to overwrite the com.mi.android.globalFileexprorer_preferences.xml, which, as we already mentioned, was not possible.

To overcome this restriction, we referred to the actual implementation of the SharedPreferences class, where we found that when an Android application uses the getSharedPreferences API method to retrieve an instance of the SharedPreferences class, giving the name of the shared preferences file as an argument, then the constructor of the SharedPreferencesImpl class performs the following steps:

1. Create a new file object using the name provided to the getSharedPreferences method, followed by the .xml extension, followed by the .bak extension

2. Check if this file exists, and in case it does, delete the original xml file and replace it with the one created in the first step

Through this behavior, we were able to save the com.mi.android.globalFileexprorer_preferences.xml.bak under the shared preferences folder (as during the application’s runtime it is unlikely to exist), so when the app tried to verify the hash, the original xml file was already replaced by our own copy. After this point, by using a single intent to start the junk cleaner plugin, we were able to trick the application to load the malicious library instead of the one under the /data/app folder and get code execution with the browser’s user ID.

Impact

One reason we chose to use this app as a showcase is because the impact extends beyond the user’s mobile device. The application gives the option to connect to remote file shares using the FTP and SMB protocols and the user credentials are saved in clear text in the /data/data/com.mi.android.globalFileexplorer/files/rmt_i.properties file:

If a third party app was able to exploit this vulnerability and obtain code execution, an attacker could retrieve these credentials. The impact would then extend even further, since by the time that a user requests to open a remote share, the browser creates the directory /sdcard/Android/data/com.mi.android.globalFileexplorer/files/usbTemp/ where it saves the files that the user retrieves:

This means that a remote attacker would be able to read or write files to SMB shares of a local network, assuming that the device was connected to it. The same stands for FTP shares as they are handled exactly in the same way:

In summary, the exploitation flow is depicted in the figure below:

In step 1, the user opens a malicious app that may pose as a file editor, messaging app, mail client, or any app in general and request the user to save a file. By the time that the user attempts to save such a file, no matter what destination path they choose to save it, the malicious app forces the file browser app to write it under its internal /files/lib folder. Then, the malicious app can start the junk cleaner using an explicit intent (no user interaction is required) and this will lead to code execution with the browser’s ID (step 2).

In step 3, the attacker uses the arbitrary code execution capability to retrieve the SMB and FTP credentials from the rmt_i.properties file. Subsequently, the attacker can now jump to step 5 and access the shares directly using the stolen credentials. Alternatively, after retrieving the share credentials, the mobile device can connect to a local network (step 4) and access an SMB or FTP share, allowing the attacker to access the shared files through the /sdcard/Android/data/com.mi.android.globalFileexplorer/files/usbTemp/ folder (step 5).

Recommendations

Recognizing that this vulnerability pattern may be widespread, we shared our findings with Google’s Android Application Security Research team. We collaborated with Google to author guidance for Android application developers to help them recognize and avoid this pattern. We recommend developers and security analysts familiarize themselves with the excellent Android application security guidance provided by Google as well as make use of the Android Lint tool included with the Android SDK and integrated with Android Studio (supplemented with Google’s additional security-focused checks) to identify and avoid potential vulnerabilities. GitHub’s CodeQL also provides capabilities to identify vulnerabilities.

To prevent these issues, when handling file streams sent by other applications, the safest solution is to completely ignore the name returned by the remote file provider when caching the received content. Some of the most robust approaches we encountered use randomly generated names, so even in the case that the content of an incoming stream is malformed, it won’t tamper with the application.

In cases where such an approach is not feasible, developers need to take extra steps to ascertain that the cached file is written to a dedicated directory. As an incoming file stream is usually identified by a content URI, the first step is to reliably identify and sanitize the corresponding filename. Besides filtering characters that may lead to a path traversal and before performing any write operation, developers must verify that the cached file is within the dedicated directory by performing a call to the File.getCanonicalPath and validating the prefix of the returned value.

Another area to safeguard is in the way developers try to extract a filename from a content URI. Developers often use Uri.getLastPathSegment(), which returns the (URL) decoded value of the last path URI segment. An attacker can craft a URI with URL encoded characters within this segment, including characters used for path traversal. Using the returned value to cache a file can again render the application vulnerable to this type of attack.

For end users, we recommend keeping mobile applications up to date through the Google Play Store (or other appropriate trusted source) to ensure that updates addressing known vulnerabilities are installed. Users should only install applications from trusted sources to avoid potentially malicious applications. We recommend users who accessed SMB or FTP shares through the Xiaomi app before updates to reset credentials and to investigate for any anomalous behavior. Microsoft Defender for Endpoint on Android can alert users and enterprises to malicious applications, and Microsoft Defender Vulnerability Management can identify installed applications with known vulnerabilities.

Dimitrios Valsamaras

Microsoft Threat Intelligence

References

• https://www.blackhat.com/asia-23/briefings/schedule/index.html#dirty-stream-attack-turning-android-share-targets-into-attack-vectors-30234
• https://developer.android.com/privacy-and-security/risks/untrustworthy-contentprovider-provided-filename
• https://developer.android.com/reference/androidx/core/content/FileProvider
• https://developer.android.com/guide/topics/manifest/provider-element#gprmsn
• https://play.google.com/store/apps/details?id=com.mi.android.globalFileexplorer
• https://play.google.com/store/apps/details?id=cn.wps.moffice_eng
• https://googlesamples.github.io/android-custom-lint-rules/checks/UnsafeDynamicallyLoadedCode.md.html
• https://androidrank.org/application/file_manager/com.mi.android.globalFileexplorer
• https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/SharedPreferencesImpl.java;l=150
• https://developer.android.com/privacy-and-security/risks
• https://developer.android.com/studio/write/lint#gradle
• https://github.com/google/android-security-lints/
• https://codeql.github.com/codeql-query-help/java/

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post “Dirty stream” attack: Discovering and mitigating a common vulnerability pattern in Android apps appeared first on Microsoft Security Blog.

Due to the way Microsoft’s deployed Helix Core Server were configured, at no point were any of Microsoft’s internet-facing servers vulnerable to this critical vulnerability. No consumer, customer, or partner data was at risk or leaked.

Microsoft’s commitment to gaming and community security is paramount, and we worked closely with Perforce to report these vulnerabilities and drive remediation. We thank Perforce and are grateful for their team’s quick response in developing and releasing patches for these vulnerabilities.

While the three high severity vulnerabilities could be used to launch attacks such as a denial of service (DoS) against vulnerable systems, vulnerabilities with a CVSS score of 10.0 have the most severe potential impact that can extend beyond the vulnerable component, introducing a risk to software supply chains. The discovered vulnerabilities are summarized in the table below:

Helix Core Server listens on TCP port 1666 by default, though server administrators will often change this port number to hide from scanners or to host Helix Core Server via TLS. Microsoft scanned the internet in November 2023 for TCP port 1666 with a custom Helix Core Server network signature and found over 1,000 exposed Perforce Helix Core Server instances.

In this blog, we detail how we discovered each of the vulnerabilities and highlight the potential impact if exploited. Alongside applying Perforce’s patches, we also include additional mitigation and protection guidance for customers to minimize the risk of exploitation. Lastly, we’re sharing this information with the broader community to drive awareness to further improve protections across the security ecosystem, and to emphasize the importance of responsible disclosure and collaboration to secure platforms and devices.

Discovering the vulnerabilities

To keep Microsoft’s game development studios and their customers safe, we recently conducted an application security review of Helix Core Server, the source code management platform relied on by most of our studios. For our security review, we analyzed Helix Core Server version 2023.1.244.2900 and installed it on Windows 11 22H2. We used Helix Core Server’s default installation options, which resulted by-design in the Helix Core Server service running as LocalSystem:

Recovering debug symbols

In 2014, Perforce open-sourced the code for their CLI Perforce Client, and informed users we can download the code from the bin.tools subdirectory of any given release. While having any source code is invaluable for application security vulnerability research purposes, this source code is specific to the client, not the server. The latter is only distributed in compiled binary form.

The binaries that are installed by Helix Core Server’s installer have their debug symbols stripped (removed from the distributed executable images), which makes it harder to understand the disassembled code during static analysis. To aid our review, we attempted to recover these debug symbols.

Discovering debug symbols

Sometimes applications offer software development kits (SDKs) that can be mined for debug symbol data. In the case of Helix Core Server, Perforce offers a “C/C++ API” package for the Windows (x64) platform that comes in the form of a .zip file containing three directories: include, lib, and sample. The lib directory is especially interesting for us, as it contains about 400 MB of .lib files:

Like .exe files, .lib files are COFF files that can contain debug symbols. By using dumpbin.exe /symbols to inspect each .lib file, we found that the nine .lib files in the package contain a total of 1,251,756 debug symbol entries.

To understand why this is useful to us, let us consider an approximation of how .exe and .lib files are built:

In the diagram above, we can see that the SDK .obj files were linked along with server-specific .obj files to create Helix Core Server’s p4s.exe (“Perforce Service”) file. During that linking process, the debug symbols were stripped. However, the same SDK .obj files had their debug symbols retained when linked into the SDK .lib files. Since the .lib files contain debug symbols, we can match each compiled SDK function in each .lib file to its SDK function name. If we can then find those same compiled SDK functions in Helix Core Server’s .exe and .dll files, we can map the SDK function names to those functions as well, thus simplifying our analysis of the p4s.exe file.

To begin, we must first determine which SDK package to use for our analysis. If we look at the containing directory for the .zip file downloaded from the “C/C++ API” package, we see it contains 144 p4api SDK packages:

The reason we see 144 packages listed is that there is every combination of the following:

That’s nine possible values for compiler, two possible values for linking, two possible values for build type, and four possible values for OpenSSL version. In other words, multiplying those four values together leads us to 144 possible combinations. To map named functions from the SDK’s .lib files to Helix Core Server’s p4s.exe file, we’ll need to choose the correct SDK package, since, for example, a function compiled with Visual Studio 2005 may look very different from the same function compiled with Visual Studio 2022.

So how do we know which compiler, linker option, build type, and OpenSSL version were used for our installed distribution of Helix Core Server? We don’t. We could make some educated guesses and examine artifacts such as the binaries’ Rich Headers to determine the right combination, but instead we chose to use automation to test all possible combinations. (Note that “Rich Headers” is a colloquial term used in the industry, not a Microsoft-official name for this structure.)

Finding the right set of debug symbols

After downloading all of the statically linked p4api archives from Perforce’s website, we used IDA Pro’s F.L.I.R.T. technology to create signatures for each Perforce Helix Core Server SDK package. To do so, we automated the following steps:

1. Use pcf.exe (“parsecoff”) from IDA Pro’s Fast Library Acquisition for Identification and Recognition (FLAIR) SDK to create .pat (“pattern”) files for each Perforce Helix Core Server SDK package’s .lib file.
2. Use sigmake.exe from the FLAIR SDK to create a .sig (“signature”) file for all the .pat files from each given Perforce Helix Core Server SDK package.
3. Use zipsig.exe from the FLAIR SDK to compress each .sig file.
4. Disassemble Helix Core Server’s p4s.exe file with IDA Pro and save the resulting .idb (“IDA database”) file.
5. For each .sig file, open the .idb file, apply the .sig file, count the number of .sig file function matches, and close the .idb file without saving the modifications.
6. Rank the number of function matches for each .sig file.

After following the process above, we found the debug symbols from p4api_vs2017_static_openssl1.1.1.zip had the most function matches in p4s.exe:

The remainder of this blog post leverages these signatures for p4s.exe’s function names and type information.

Investigating the RPC header

Given that Helix Core Server runs as LocalSystem, local elevation of privilege attacks would certainly be worthwhile to explore. However, remote attacks via a network are much more intriguing from a vulnerability research perspective. Our next step is to investigate how Helix Core Server handles data it receives from remote users, or in our case, attackers.

Using TCPView, we can see that p4s.exe is listening for incoming connections on TCP port 1666:

Programs built for Windows that listen on TCP ports for incoming connections almost always use Winsock’s recv() function to receive incoming network data from clients. Using IDA Pro’s cross-references (“CODE XREF”s below), we can see that recv() is called by several functions:

We’re looking to assess how received network data is parsed and handled, and to save time in determining which of the functions above actually receives the connected client data via recv(), we used a debugger to set a breakpoint on recv() and reviewed its thread’s call-stack to reveal the following chain of function calls:

In the call-stack above, “Rpc” is short for “Remote Procedure Call”, a common term used for remotely executing functions.

Although we’re assessing the Helix Core Server, the function RpcTransport::Receive() (in Figure 8) is also included in the client source code discussed above (note that the comments are from Perforce’s developers, not from Microsoft):

The code above does the following:

1. On line 69, calls NetBuffer::Receive() to receive five bytes of data from the connected TCP client. We will refer to these five bytes as the RPC header.
2. On line 72, verifies that the first byte’s value equals the value of the following four bytes using the XOR operation to compute a parity byte checksum.
3. On line 78, interprets those following four bytes as a 32-bit little-endian value named length.
4. On line 85, verifies that length >= 12 and that length < 0x1FFFFFFF.
5. On line 93, allocates memory of size length and receives length bytes from the connected TCP client.

However, there’s a design risk in the code above, in that there’s not sufficient protection against asymmetric resource consumption attacks from remote unauthenticated attackers. An attacker could connect to the Helix Core Server, send a five-byte RPC header specifying a length value of 0x1FFFFFFE, and cause the server to allocate 0x1FFFFFFE bytes (about 537 MB) of memory. An attacker could exploit this vulnerability by establishing numerous connections and requesting these large memory allocations via each connection, quickly consuming all the server’s available memory. Once available memory is exhausted, the next call to Alloc() (step 5 above) will lead Helix Core Server’s memory allocator (which happens to be mimalloc) to throw an unhandled std::bad_alloc() exception from mi_try_new_handler(), causing the Helix Core Server process to crash and not restart. This denial-of-service (DoS) attack is exploitable by remote unauthenticated attackers.

This vulnerability is now identified as CVE-2023-5759 and it has a CVSS score of 7.5.

Investigating RPC handler functions

We showed in the call-stack above that RpcTransport::Receive() is called by Rpc::DispatchOne(). This latter function takes the allocated buffer received by RpcTransport::Receive(), parses it as an RPC command with optional arguments, looks up the handler for the given RPC command, and calls the handler with the received arguments. Many of these RPC commands are mapped to the p4 commands listed here. Specifically, there are 202 formally documented p4 commands, and about 450 defined RPC commands, though not all RPC commands have their handlers registered by default at runtime.

Since we’re most interested in the possibility of remote unprivileged attacks against Helix Core Server in its default configuration, we created our own Perforce client from scratch that attempts to call (without any authentication) each of the approximately 450 RPC commands defined in p4s.exe. Of those, we found that about 360 RPC commands have their handlers registered by default at runtime. This is too high of a count to manually assess in a reasonable amount of time, so we had to find other means to prioritize our RPC command analysis.

We found that p4s.exe statically imports 382 API functions. Of those, we identified the most interesting functions that could potentially achieve remote code execution, assuming an unauthenticated remote attacker could both execute an RPC function that calls one of these API functions and control the arguments to that API function. These functions are:

• CreateFileMapping()
• CreateProcess()
• DeviceIoControl()
• LoadLibrary()
• LoadLibraryEx()
• MapViewOfFile()
• MoveFileEx()
• RegSetValueEx()
• ShellExecuteEx()
• WriteFile()

Assessing this short list of API functions and analyzing code-flow paths from RPC handlers to these functions was a much more tractable problem than manually reviewing each of the approximately 360 registered RPC handlers.

The bgtask command

By reviewing cross-references with IDA Pro, we were able to identify the following call-chain from an RPC command handler to CreateProcess():

According to Perforce’s documentation, the p4 bgtask command “enables a Helix Core superuser on the p4 command-line client to run commands or programs remotely on the server in the background.” It’s thus not surprising that this type of command would end up calling CreateProcess(), but since the documentation states that this command can only be run by a superuser, our only hope of finding a security vulnerability here was if there was a bug in the authentication component or in how the RPC arguments were getting parsed.

To begin our assessment of p4 bgtask, we used the custom Perforce client that we wrote to see how the server would respond if we tried remotely calling bgtask without any authentication. To our surprise, the server didn’t return any errors. In fact, the server ran the command line that we sent to it, and this child process ran as LocalSystem.

Upon further investigation, this is by design, with the manual noting to “Run p4 protect immediately after installing Helix Server for the first time. Before the first call to p4 protect, every Helix Server user is a superuser and thus can access and change anything in the depot”. In this context, “every Helix Server user” also includes unauthenticated anonymous remote users.

If an administrator does not manually perform those post-installation steps, this missing authentication for a critical function allows unauthenticated remote attackers to run arbitrary command lines (including PowerShell command lines with script blocks) as LocalSystem when Helix Core Server is installed with its default configuration.

This vulnerability is now identified as CVE-2023-45849 and it has a CVSS score of 10.0.

The rmt-Shutdown RPC handler

When a user (or attacker) uses the p4 bgtask discussed above with the standard Perforce Client, the client sends the RPC command name user-bgtask to the server to execute that command. However, some RPC command names that are accepted by the server don’t have a corresponding Perforce Client command; one of those RPC command names is rmt-Shutdown.

Although it’s not possible to send the rmt-Shutdown RPC command with the standard Perforce Client (nor the Perforce Admin Tool), and it doesn’t appear to be documented on Perforce’s website, we were able to send the command with our custom Perforce client. We found that the handler for rmt-Shutdown requires a username of remote but doesn’t require any authentication credentials for that username. When the Perforce Helix Core Server receives this command, it terminates the Helix Core Server process, thereby allowing unauthenticated remote attackers to perform DoS attacks against the server.

This vulnerability is now identified as CVE-2023-35767 and it has a CVSS score of 7.5.

The rmt-UpdtFovrCommit RPC handler

Similar to the rmt-Shutdown RPC command name, the RPC command name rmt-UpdtFovrCommit (which is likely short for “remote update failover commit”) cannot be sent via the standard Perforce Client nor Admin Tool and doesn’t appear to be documented on Perforce’s website but can be sent with a custom Perforce client. This RPC function piqued our interest when we first tested for registered RPC handlers, since when our custom-built scanner sent a rmt-UpdtFovrCommit RPC command as an anonymous user and without any command arguments to the Helix Core Server, the Helix Core Server process crashed.

We can see the reason for the crash in the decompiled rmt-UpdtFovrCommit handler code below:

As previously discussed, RPC messages sent from the client to the server contain the RPC function name and can optionally contain RPC function arguments. In the code above, StrDict::GetVar() is used to get the client’s RPC function arguments from the pRpc object. If the given argument name was not provided in the client’s RPC message, then StrDict::GetVar() returns zero. In the first line above, StrDict::GetVar() is used to get the value of the user RPC function argument. However, if the user (or attacker) does not specify a value for user in their RPC message then pStrPtrUser gets set to zero. In the last line above, we see pStrPtrUser passed as the second argument to StrOps::PackOctet(), (the source code for which is available in the client source code discussed above):

As can be seen in the code above, when StrOps::PackOctet() is called with zero as the value for s, StrBuf::Append() gets called with zero as the value for t. This results in StrBuf::Append() trying to dereference the length field of t, where the buffer field of t is at offset 0 relative to the beginning of the t object and the length field of t is at offset 8 relative to the beginning of the t object (since char *buffer is 64-bits). When the value of t is 0, dereferencing length leads to reading from virtual memory address 0x0000000000000008, which results in a read-access violation or segmentation fault. We found that these types of exceptions are not handled gracefully by the server and that such read-exceptions cause the entire server process to crash and not restart. This DoS attack is exploitable by remote unauthenticated attackers.

This vulnerability is now identified as CVE-2023-45319 and it has a CVSS score of 7.5.

Coordinated disclosure

Microsoft reported these four security vulnerabilities to the vendor Perforce at the end of August 2023. Immediately afterwards, on September 1, Perforce acknowledged these four vulnerabilities and began work to investigate and remediate them. Throughout September and October, Perforce communicated status updates to Microsoft on implementing fixes and putting those fixes through their QA processes. Perforce reserved CVE IDs on October 24, 2023, shared those IDs with Microsoft on October 25, 2023, and informed Microsoft at that time that the patches would be published by mid-November 2023. On November 7, 2023, Perforce published Perforce Helix Core Server version 2023.1/2513900, which mitigates these four vulnerabilities. Perforce has also published patches for the older Perforce Helix Core Server versions 2022.2, 2022.1, and 2021.2. Perforce recommends upgrading to the latest Perforce Helix Core Server version 2023.2.

Microsoft would like to thank Perforce for their professionalism and for their rapid response in addressing these security vulnerabilities. Microsoft is grateful for this partnership and for Perforce’s commitment to security.

Mitigation and protection guidance

Microsoft is not aware of any adversaries exploiting these vulnerabilities, but mitigations should be applied by all Helix Core Server customers as soon as possible.

Risk detection

Extend vulnerability and risk detection beyond the firewall with platforms like Microsoft Defender External Attack Surface Management. Customers can identify internet-exposed infrastructure running Perforce Helix Core Server in their inventory and use the insights tile under the Attack Surface Summary dashboard to surface assets vulnerable to CVE-2023-5759, CVE-2023-45849, CVE-2023-35767, and CVE-2023-45319.

What to do now if you’re affected

Update your Perforce Helix Core Server: https://www.perforce.com/downloads/helix-core-p4d.

Defense-in-depth

In addition to following Perforce’s guidance on “Securing the server”, Microsoft recommends adhering to the following defense-in-depth tactics to minimize the risk of exploitation of these or other Perforce Helix Core Server vulnerabilities.

• Regularly monitor for and apply patches for third-party software.
• Use a VPN and/or an IP allow-list to limit who can communicate with your Perforce Helix Core Server.
• Issue TLS certificates to legitimate Perforce users and use a TLS termination proxy in front of Perforce Helix Core Server to validate client’s TLS certificates before allowing them to connect to Perforce Server.
• Log all access to your Helix Core Server, both via your network appliances and via Perforce Helix Core Server itself.
• Configure alerting to notify IT administrators and your security team if the Helix Core Server process crashes.
• Use network segmentation to ensure that if your Helix Core Server is compromised, an attacker’s ability to pivot in your network is limited.

Appendix

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• CVE-2023-5759
• CVE-2023-45849
• CVE-2023-35767
• CVE-2023-45319

Microsoft 365 Defender Threat analytics 

• Vulnerability profile: Critical remote code execution vulnerability in Perforce Helix Core Server

Jason Geffner

Microsoft Threat Intelligence Community

References

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-5759
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-35767
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45319
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45849
• https://ftp.perforce.com/perforce/r23.1/bin.ntx64/
• https://portal.perforce.com/s/article/3925
• https://swarm.workshop.perforce.com/projects/perforce_software-p4
• https://www.perforce.com/downloads/administration-tool
• https://www.perforce.com/downloads/helix-command-line-client-p4
• https://www.perforce.com/downloads/helix-core-c/c-api
• https://www.perforce.com/downloads/helix-core-p4d
• https://www.perforce.com/manuals/cmdref/Content/CmdRef/commands.html
• https://www.perforce.com/manuals/p4sag/Content/P4SAG/protections.when_to_set.html
• https://www.perforce.com/press-releases/perforce-open-sources-popular-version-control-tools

Acknowledgments

Microsoft would like to recognize https://www.keysight.com/blogs/tech/nwvs/2022/06/08/a-sneak-peek-into-the-protocol-behind-perforce for previous work done in analyzing Perforce’s RPC protocol.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on Twitter at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Patching Perforce perforations: Critical RCE vulnerability discovered in Perforce Helix Core Server appeared first on Microsoft Security Blog.

CODESYS is compatible with approximately 1,000 different device types from over 500 manufacturers and several million devices that use the solution to implement the international industrial standard IEC (International Electrotechnical Commission) 611131-3. A DoS attack against a device using a vulnerable version of CODESYS could enable threat actors to shut down a power plant, while remote code execution could create a backdoor for devices and let attackers tamper with operations, cause a PLC to run in an unusual way, or steal critical information. Exploiting the discovered vulnerabilities, however, requires user authentication, as well as deep knowledge of the proprietary protocol of CODESYS V3 and the structure of the different services that the protocol uses.

Microsoft researchers reported the discovery to CODESYS in September 2022 and worked closely with CODESYS to ensure that the vulnerabilities are patched. Information on the patch released by CODESYS to address these vulnerabilities can be found here: Security update for CODESYS Control V3. We strongly urge CODESYS users to apply these security updates as soon as possible. We also thank CODESYS for their collaboration and recognizing the urgency in addressing these vulnerabilities. 

Below is a list of the discovered vulnerabilities discussed in this blog: 

In this blog, we provide an overview of the CODESYS V3 protocol structure, highlighting several key components, and describe the main issue that led to our discovery of the vulnerabilities. The full research and the results can be found in our report on Github. We also provide an open-source forensics tool to help users identify impacted devices, security recommendations for those affected, and detection information for potentially related threats.

CODESYS: A widely used PLC solution

CODESYS is a software development environment that provides automation specialists with tools for developing automated solutions. CODESYS is a platform-independent solution that helps device manufacturers implement the international industrial standard IEC 611131-3. The SDK also has management software that runs on Windows machines and a simulator for testing environments, allowing users to test their PLC systems before deployment. The proprietary protocols used by CODESYS use either UDP or TCP for communication between the management software and PLC.

CODESYS is widely used and can be found in several industries, including factory automation, energy automation, and process automation, among others. 

Discovering the CODESYS vulnerabilities

The vulnerabilities were uncovered by Microsoft researchers while examining the security of the CODESYS V3 proprietary protocol as part of our goal to improve the security standards and create forensic tools for OT devices. During this research, we examined the structure and security of the protocol that is used by many types and vendors of PLCs.  We examined the following two PLCs that use CODESYS V3 from different vendors: Schneider Electric Modicon TM251 and WAGO PFC200.

CODESYS V3 protocol

The CODESYS network protocol works over either TCP or UDP:

• Ports 11740-11743 for TCP
• Ports 1740-1743 for UDP

The CODESYS network protocol consists of four layers:

1. Block driver layer: The layer that creates the capability to communicate over a physical or software interface, over TCP or UDP.
2. Datagram layer: The layer that enables communication between components and endpoints through physical or virtual interfaces. 
3. Channel layer: The layer that is responsible for creating, managing, and closing communications channels.
4. Services layer: Represents a combination of several layers of the ISO/OSI model session layer, presentation layer, and application layer. It consists of components, each of which is responsible for a portion of functionality of the PLC and has services that it supports. Other tasks of the Services layer include encoding/decoding and encrypting/decrypting the data transmitted on that layer. Additionally, the Services layer is also responsible for tracking the client-server session. Each component is identified by a unique ID, such as:

These components use the Tags layer for data transmission and encoding, which is transmitted over the Services layer.

There are two types of tags: parent and data. Both tags have identical structure but different sizes and purposes. The following table provides the basic structure of tags:

Tags can represent any type of data, and it is extracted by the component. The difference between a parent tag and a data tag is that a parent tag is used for linking several tags into one logical element.

Tags contain several important structures, including BTagReader and BTagWriter, which include the following fields:

• Data
• Current position in data
• Size of data

These structures are allocated for each request and exist only in the context of the request. Each request handler creates BTagWriter and BTagReader tags and uses them to parse and handle requests. Tag IDs are not unique across services, meaning each service may have its own definition for a tag ID. Tag IDs are handled in the context of each service.

The following figure provides an example of a Tag layer and relevant fields.

This example contains the following tags:

• Tag1 – )TAG ID 0x01( 10 00 00 00
• Tag2 – (TAG ID 0x23) Authentication method type
• Tag3 – (TAG ID 0x81) Parent tag that contains two sub tags
• Tag4 – (TAG ID 0x10) Username tag
• Tag5 – (TAG ID 0x11) Hash of a password tag

CODESYS components

CODESYS consists of components and each component is responsible for a portion of functionality of the PLC. The following is a list of example components:

• CmpAlarmManger – Manages alarm events, registers clients that receive events, etc.
• CmpApp – Manages running applications and application event usage.
• CmpAppBp – Manages breakpoints in IEC tasks.
• CmpCodeMeter – Manages the CodeMeter License containers.
• CmpCoreDump – Manages creating, reading, and printing to file coredumps.
• CMPTraceMgr – Enables tracing of information inside the IEC tasks.

Each component includes a number of services that the client can ask to use. For example, CMPTraceMgrincludes the following:

• TraceMgrPacketCreate – Creates a new trace packet
• TraceMgrPacketDelete – Deletes a trace manager packet
• TraceMgrPacketStart – Starts tracing, which is triggered by the TraceTrigger
• TraceMgrRecordUpdate – Records the current value of the TraceVariable together with the current timestamp
• TraceMgrRecordAdd – Creates a new TraceRecordConfiguration and adds it to a specific trace packet for a specific IEC task/application

Each service is identified by a unique number for the specific component.

Tags layer vulnerability

A security issue was discovered inside the tag decoding mechanism that led to multiple vulnerabilities that could put devices at risk of attacks such as RCE and DoS.  

In order to understand the security issue, let’s analyze the service TraceMgrRecordAdd of the component CMPTraceMgr by examining the code that activates the relevant service.

The TraceMgrRecordAddByTag appears to correspond to TraceMgrRecordAdd.

As displayed in Figure 5, the following code initializes structure from tags that are sent to the service.  

The following figure looks at the code for the TraceMgrAddNewRecordPartByTag method, which copies data from different tags into an output buffer.

The whole tag is copied into the buffer without validating the size, causing buffer overflow.

Fifteen places in CODESYS V3 SDK were found with the same issue in different components that could lead to remote attackers gaining full control over the device.

Exploitation approach

We were able to apply 12 of the buffer overflow vulnerabilities to gain RCE of PLCs. Exploiting the vulnerabilities requires user authentication as well as bypassing the Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) used by both the PLCs. To overcome the user authentication, we used a known vulnerability, CVE-2019-9013, which allows us to perform a replay attack against the PLC using the unsecured username and password’s hash that were sent during the sign-in process, allowing us to bypass the user authentication process.

IEC tasks

IEC tasks are the execution unit of CODESYS runtime. It is the equivalent to thread in operating systems. A single component can have more than one task and will have at least one IEC task. The tasks are managed by CODESYS runtime. 

Each IEC task has a memory segment with read, write, and execute permissions. If a threat actor writes code there, it could be run without the data execution prevention mitigation being applied.

The IEC task segment is also where the stack is defined, meaning we don’t need to handle DEP.

Since the IEC tasks are part of the CODESYS code, they are present on all PLCs of all vendors that utilize CODESYS.

Full exploit

By looking for gadgets, we can bypass the ASLR. In the examples below, we can see part of the gadgets that we used in our exploit.

The complete exploit steps:

1. Steal credentials with CVE-2019-9013.
2. Create a new channel for the attack.
3. Sign-in to the device with the stolen credentials.
4. Exploit the vulnerabilities with a malicious packet that triggers buffer overflow.
5. Gain full control of the device.

We were able to exploit the two PLCs that we researched.

Demo video:

Critical importance of ICS security 

With CODESYS being used by many vendors, one vulnerability may affect many sectors, device types, and verticals, let alone multiple vulnerabilities. All the vulnerabilities can lead to DoS and 1 RCE. While exploiting the discovered vulnerabilities requires deep knowledge of the proprietary protocol of CODESYS V3 as well as user authentication (and additional permissions are required for an account to have control of the PLC), a successful attack has the potential to inflict great damage on targets. Threat actors could launch a DoS attack against a device using a vulnerable version of CODESYS to shut down industrial operations or exploit the RCE vulnerabilities to deploy a backdoor to steal sensitive data, tamper with operations, or force a PLC to operate in a dangerous way.

Mitigation and protection guidance

CODESYS V3 versions prior to 3.5.19.0 are vulnerable to the discovered vulnerabilities. It is recommended to first identify the devices using CODESYS in your network and check with device manufacturers to determine which version of the CODESYS SDK is used and whether a patch is available. It is also recommended to update the device firmware to version to 3.5.19.0 or above. 

General recommendations: 

• Apply patches to affected devices in your network. Check with the device manufacturers for available patches and update the device firmware to version to 3.5.19.0 or above. 
• Make sure all critical devices, such as PLCs, routers, PCs, etc., are disconnected from the internet and segmented, regardless of whether they run CODESYS.  
• Limit access to CODESYS devices to authorized components only. 
• Due to the nature of the CVEs, which still require a username and password, if prioritizing patching is difficult, reduce risk by ensuring proper segmentation, requiring unique usernames and passwords, and reducing users that have writing authentication.   

To assist with identifying impacted devices, the cyberphysical systems research team has released an open-source software tool on GitHub that allows users to communicate with devices in their environment that run CODESYS and extract the version of CODESYS on their devices in a safe manner to confirm if their devices are vulnerable. In addition, the cyberphysical system research team also released a tool for performing a forensics investigation on CODESYS V3 devices as part of its arsenal of open-source tools available on GitHub.

Microsoft 365 Defender detections 

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

Microsoft Defender for IoT 

Microsoft Defender for IoT with all versions of the sensor and TI package after April 2023 provides the following protections against these vulnerabilities and associated exploits and other malicious behavior:  

• Defender for IoT detects and classifies devices that use CODESYS.  
• Defender for IoT raises alerts on unauthorized access to devices using CODESYS, and abnormal behavior in these devices.  
• Defender for IoT raises alerts if a threat actor attempts to exploit these vulnerabilities. Alert type: “Suspicion of Malicious Activity”

Microsoft Defender Threat Intelligence 

Microsoft Defender Threat Intelligence shows devices running CODESYS that are exposed to the internet by searching for “CODESYS” components on IPs.  

Vladimir Tokarev

Microsoft Threat Intelligence Community

References 

• https://www.codesys.com/the-system/codesys-inside.html
• https://store.codesys.com/engineering/codesys.html
• https://github.com/microsoft/CoDe16/tree/main
• https://store.codesys.com/en/alarm-manager.html
• https://content.helpme-codesys.com/en/libs/CmpApp/Current/index.html
• https://content.helpme-codesys.com/en/libs/CmpAppBP/Current/index.html
• https://content.helpme-codesys.com/en/libs/CmpCodeMeter/Current/index.html
• https://content.helpme-codesys.com/en/libs/CmpTraceMgr/Current/index.html
• https://content.helpme-codesys.com/en/libs/CmpApp/Current/AppStartApplication.html
• https://help.codesys.com/webapp/TraceMgrPacketCreate;product=CmpTraceMgr;version=3.5.16.0
• https://help.codesys.com/webapp/TraceMgrPacketDelete;product=CmpTraceMgr;version=3.5.16.0
• https://help.codesys.com/webapp/TraceMgrPacketStart;product=CmpTraceMgr;version=3.5.16.0
• https://help.codesys.com/webapp/TraceMgrRecordUpdate;product=CmpTraceMgr;version=3.5.16.0
• https://help.codesys.com/webapp/TraceMgrRecordAdd;product=CmpTraceMgr;version=3.5.17.0
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9013
• https://customers.codesys.com/index.php?eID=dumpFile&t=f&f=12943&token=d097958a67ba382de688916f77e3013c0802fade&download=
• https://www.codesys.com/download
• https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2023-192-04&p_enDocType=Security+and+Safety+Notice&p_File_Name=SEVD-2023-192-04.pdf&_ga=2.25212925.1579834642.1689503846-267712980.1687697317
• https://cert.vde.com/de/advisories/VDE-2023-026/
• https://ics-cert.kaspersky.com/publications/reports/2019/09/18/security-research-codesys-runtime-a-plc-control-framework-part-1/
• https://ics-cert.kaspersky.com/publications/reports/2019/09/18/security-research-codesys-runtime-a-plc-control-framework-part-2/
• https://ics-cert.kaspersky.com/publications/reports/2019/09/18/security-research-codesys-runtime-a-plc-control-framework-part-3/

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post Multiple high severity vulnerabilities in CODESYS V3 SDK could lead to RCE or DoS  appeared first on Microsoft Security Blog.

August 8, 2023 update: Microsoft released security updates to address CVE-2023-36884. Customers are advised to apply patches, which supersede the mitigations listed in this blog, as soon as possible.

Microsoft has identified a phishing campaign conducted by the threat actor tracked as Storm-0978 targeting defense and government entities in Europe and North America. The campaign involved the abuse of CVE-2023-36884, which included a remote code execution vulnerability exploited before disclosure to Microsoft via Word documents, using lures related to the Ukrainian World Congress.

Storm-0978 (DEV-0978; also referred to as RomCom, the name of their backdoor, by other vendors) is a cybercriminal group based out of Russia, known to conduct opportunistic ransomware and extortion-only operations, as well as targeted credential-gathering campaigns likely in support of intelligence operations. Storm-0978 operates, develops, and distributes the RomCom backdoor. The actor also deploys the Underground ransomware, which is closely related to the Industrial Spy ransomware first observed in the wild in May 2022. The actor’s latest campaign detected in June 2023 involved abuse of CVE-2023-36884 to deliver a backdoor with similarities to RomCom.

Storm-0978 is known to target organizations with trojanized versions of popular legitimate software, leading to the installation of RomCom. Storm-0978’s targeted operations have impacted government and military organizations primarily in Ukraine, as well as organizations in Europe and North America potentially involved in Ukrainian affairs. Identified ransomware attacks have impacted the telecommunications and finance industries, among others.

Microsoft 365 Defender detects multiple stages of Storm-0978 activity. Customers who use Microsoft Defender for Office 365 are protected from attachments that attempt to exploit CVE-2023-36884. In addition, customers who use Microsoft 365 Apps (Versions 2302 and later) are protected from exploitation of the vulnerability via Office. Organizations who cannot take advantage of these protections can set the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. More mitigation recommendations are outlined in this blog.

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

Targeting

Storm-0978 has conducted phishing operations with lures related to Ukrainian political affairs and targeting military and government bodies primarily in Europe. Based on the post-compromise activity identified by Microsoft, Storm-0978 distributes backdoors to target organizations and may steal credentials to be used in later targeted operations.

The actor’s ransomware activity, in contrast, has been largely opportunistic in nature and entirely separate from espionage-focused targets. Identified attacks have impacted the telecommunications and finance industries.

Tools and TTPs

Tools

Storm-0978 uses trojanized versions of popular, legitimate software, leading to the installation of RomCom, which Microsoft assesses is developed by Storm-0978. Observed examples of trojanized software include Adobe products, Advanced IP Scanner, Solarwinds Network Performance Monitor, Solarwinds Orion, KeePass, and Signal. To host the trojanized installers for delivery, Storm-0978 typically registers malicious domains mimicking the legitimate software (for example, the malicious domain advanced-ip-scaner[.]com).

In financially motivated attacks involving ransomware, Storm-0978 uses the Industrial Spy ransomware, a ransomware strain first observed in the wild in May 2022, and the Underground ransomware. The actor has also used the Trigona ransomware in at least one identified attack.

Additionally, based on attributed phishing activity, Storm-0978 has acquired exploits targeting zero-day vulnerabilities. Identified exploit activity includes abuse of CVE-2023-36884, including a remote code execution vulnerability exploited via Microsoft Word documents in June 2023, as well as abuse of vulnerabilities contributing to a security feature bypass.

Ransomware activity

In known ransomware intrusions, Storm-0978 has accessed credentials by dumping password hashes from the Security Account Manager (SAM) using the Windows registry. To access SAM, attackers must acquire SYSTEM-level privileges. Microsoft Defender for Endpoint detects this type of activity with alerts such as Export of SAM registry hive.

Storm-0978 has then used the Impacket framework’s SMBExec and WMIExec functionalities for lateral movement.

Microsoft has linked Storm-0978 to previous management of the Industrial Spy ransomware market and crypter. However, since as early as July 2023, Storm-0978 began to use a ransomware variant called Underground, which contains significant code overlaps with the Industrial Spy ransomware.

The code similarity between the two ransomware variants, as well as Storm-0978’s previous involvement in Industrial Spy operations, may indicate that Underground is a rebranding of the Industrial Spy ransomware.

Espionage activity

Since late 2022, Microsoft has identified the following campaigns attributable to Storm-0978. Based on the post-compromise activity and the nature of the targets, these operations were likely driven by espionage-related motivations:

June 2023 – Storm-0978 conducted a phishing campaign containing a fake OneDrive loader to deliver a backdoor with similarities to RomCom. The phishing emails were directed to defense and government entities in Europe and North America, with lures related to the Ukrainian World Congress. These emails led to exploitation via the CVE-2023-36884 vulnerability.

Microsoft Defender for Office 365 detected Storm-0978’s initial use of the exploit targeting CVE-2023-36884 in this phishing activity. Additional recommendations specific to this vulnerability are detailed below.

Notably, during this campaign, Microsoft identified concurrent, separate Storm-0978 ransomware activity against an unrelated target using the same initial payloads. The subsequent ransomware activity against a different victim profile further emphasizes the distinct motivations observed in Storm-0978 attacks.

December 2022 – According to CERT-UA, Storm-0978 compromised a Ukrainian Ministry of Defense email account to send phishing emails. Identified lure PDFs attached to emails contained links to a threat actor-controlled website hosting information-stealing malware.

October 2022 – Storm-0978 created fake installer websites mimicking legitimate software and used them in phishing campaigns. The actor targeted users at Ukrainian government and military organizations to deliver RomCom and likely to obtain credentials of high-value targets.

Recommendations

Microsoft recommends the following mitigations to reduce the impact of activity associated with Storm-0978’s operations.

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants.
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Use Microsoft Defender for Office 365 for enhanced phishing protection and coverage against new threats and polymorphic variants. Defender for Office 365 customers should ensure that Safe Attachments and Safe Links protection is enabled for users with  Zero-hour Auto Purge (ZAP) to remove emails when a URL gets weaponized post-delivery.
• Microsoft 365 Defender customers can turn on attack surface reduction rules to prevent common attack techniques used in ransomware attacks:
  • Block process creations originating from PsExec and WMI commands – Some organizations might experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI, including Impacket’s WMIexec.
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Use advanced protection against ransomware
  • Block all Office applications from creating child processes

CVE-2023-36884 specific recommendations

August 8, 2023 update: Microsoft released security updates to address CVE-2023-36884. Customers are advised to apply patches, which supersede the mitigations below, as soon as possible.

• Customers who use Microsoft Defender for Office 365 are protected from attachments that attempt to exploit CVE-2023-36884.
• In addition, customers who use Microsoft 365 Apps (Versions 2302 and later) are protected from exploitation of the vulnerability via Office.
• In current attack chains, the use of the Block all Office applications from creating child processes attack surface reduction rule prevents the vulnerability from being exploited
• Organizations who cannot take advantage of these protections can set the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. 
  • No OS restart is required, but restarting the applications that have had the registry key added for them is recommended in case the value was already queried and is cached.
  • Please note that while these registry settings would mitigate exploitation of this issue, it could affect regular functionality for certain use cases related to these applications. For this reason, we suggest testing. To disable the mitigation, delete the registry key or set it to “0”.

Detection details

Microsoft Defender for Office 365

Microsoft Defender for Office 365 customers are protected from attachments that attempt to exploit CVE-2023-36884.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects post-compromise components of this threat as the following malware:

• Ransom:Win32/IndustrialSpy
• Trojan:Win32/RomCom
• Trojan:Win64/RomCom
• HackTool:Win32/Impacket
• HackTool:Python/Impacket
• Exploit:Script/Teefey

Microsoft Defender for Endpoint

Alerts with the following titles in the security center can indicate threat activity on your network:

• Emerging threat activity group Storm-0978 detected

Microsoft Sentinel

Microsoft Sentinel also has detection and threat hunting content that customers can use to detect the post exploitation activity detailed in this blog in addition to Microsoft 365 Defender detections list above.

The following content can be used to identify activity described in this blog post:

• Potential Impacket Execution
• Commands executed by WMI on new hosts – potential Impacket

References

• Void Rabisu’s Use of RomCom Backdoor Shows a Growing Shift in Threat Actors’ Goals. Trend Micro
• Technical Analysis of Industrial Spy Ransomware. ZScaler
• CERT-UA#6940. CERT-UA

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post Storm-0978 attacks reveal financial and espionage motives appeared first on Microsoft Security Blog.

The Security Science team studied exploits that emerged for the most severe vulnerabilities in Microsoft software between 2006 and 2013. The exploits studied were for vulnerabilities that enable remote code execution. The timing of the release of the first known exploit for each remote code execution vulnerability was examined, and the results were put into three groups:

• Zero day: the first exploit was discovered in the wild before a security update to address the vulnerability was released
• Within 30 days: the first exploit was discovered in the wild within 30 days following the release of the security update that addressed the vulnerability
• After 30 days: the first exploit was discovered in the wild after the first 30 days following the release of the security update that addressed the vulnerability

Figure 1 shows us that there was a 70 percent decline in the total number of remote code execution vulnerabilities that were exploited in Microsoft products between 2010 and 2013. This is likely a result of the continued evolution of security mitigations in Microsoft products, like Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP), that make it much harder and more expensive for attackers to develop reliable exploits for vulnerabilities.

Of those vulnerabilities that do get exploited, the greatest potential risk comes from zero-day exploits, which are discovered in the wild before the publisher of the affected software is able to release a security update to address the vulnerability. Figure 1 illustrates that the number of zero-day exploits detected each year for severe vulnerabilities in Microsoft software decreased from its peak of 18 in 2011 to 13 in 2013. The rapidly shrinking number of remote code execution vulnerabilities that were exploited between 2010 and 2013 is good news, but subsequently zero-day exploits accounted for a larger proportion of the total number of exploits in each of the last three years.

With new remote code execution vulnerabilities becoming harder to find and exploit, as secure coding practices improve across the software industry, developing new exploits has become more expensive and the value of previously undisclosed exploits in the underground economy has increased. This reality provides “black hat” security researchers and exploit developers with a powerful incentive to maximize their own profits by selling exclusive access to a vulnerability and exploit to an attacker before the affected vendor has knowledge of the vulnerability and can issue a security update, and before security software vendors can update their detection signatures.

By contrast, remote code execution exploits that first appear more than 30 days after security update publication have become rare, with only one such instance in 2013. The number of exploits in the “after 30 days” category decreased from the peak of 11 in 2010 to 1 in 2013. A big part of this reduction is likely due to the work Microsoft and others in the industry have done to make it easier for customers to test and deploy updates quickly after release, even in large organizations. As the share of computers receiving updates within the first month of release continues to increase, exploiting older vulnerabilities becomes less profitable for attackers.

The number of remote code execution vulnerabilities exploited within the first 30 days after a security update has been released has also decreased substantially since 2010. In 2010, 42 exploits for severe vulnerabilities were first discovered in the 30 days after security updates for the vulnerabilities were released. But there has been a large reduction in this category of exploits in each subsequent year, 23 in 2011, 10 in 2012, and 6 in 2013.

There is likely a combination of reasons for the positive reduction in exploitation in all three categories First, as I mentioned earlier it is much harder to find and reliably exploit remote code execution vulnerabilities because of all the security mitigations layered into Microsoft software. Second, there has been increased usage of Microsoft Update and Windows Update services over the years, providing faster protection to more systems. Organizations have more sophisticated security update deployment and risk management methodologies supported by better and more efficient deployment technologies. Another contributing factor is the parties that are using the exploits and what is motivating them. You can get more insight into this aspect from an article I recently published called “Who Exploits Vulnerabilities: the Path from Disclosure to Mass Market Exploitation.” This data shows us that of the 16 remote code execution vulnerabilities studied, that were known to be exploited between January 2012 and February 2014, the majority of them (9 of the 16) were initially exploited in targeted attacks against specific targets. Attempted mass exploitation using the same exploits via exploit kits occurred months after the security updates that addressed the vulnerabilities were published and widely distributed.

Summary

• Effective security mitigations in Windows, and changing vulnerability market economics have contributed to a rapid reduction (70 percent reduction) in the number of remote code execution vulnerabilities that were exploited in Microsoft software over the past three years
• In 2013 there were 20 remote code execution vulnerabilities in Microsoft software that were known to be exploited, down from 70 in 2010
• There have been relatively large positive reductions in the number of zero day exploits, vulnerabilities exploited within the first 30 days after a security update is released and vulnerabilities exploited more than 30 days after a security update is released. 
  • 13 zero day exploits in 2013, down 28 percent from 2011
  • 6 remote code execution vulnerabilities exploited within 30 days of the security update being released, an 86 percent reduction from 2010
  • 1 remote code execution vulnerability exploited more than 30 days after of the release of a security update, a 91 percent reduction from 2010

Using this Information
One way to interpret this data is that attackers are accelerating their efforts and being more targeted, in an effort to use the vulnerability they have access to before it is disclosed, rapidly addressed across the ecosystem, and security vendors add detection for it to their tools and products. There are a few tools that I will highlight here that will help to mitigate such risks.

• Use the Microsoft Security Response Center Exploitability Index
• While the bulletin Severity Ratings (Critical, Important, Moderate, Low) assumes that all vulnerabilities can be successfully exploited all the time, the Exploitability Index focuses on the potential likelihood that a successful exploitation of the vulnerabilities in the bulletin could occur based on currently known exploitation techniques. The Exploitability Index makes an assessment on the likelihood that code will be released that exploits the vulnerability or vulnerabilities addressed in a security bulletin within the first 30 days after that bulletin’s release. For more details see Understanding How to Use the Microsoft Security Response Center Exploitability Index.

• Run the latest software versions and keep them up-to-date
• Windows 8.1, Internet Explorer 11, and Office 2013 all take advantage of improved security features that more effectively mitigate techniques that are currently being used to exploit vulnerabilities. Deploying these product versions widely can help mitigate the risk an organization faces from several of the most commonly detected exploits, as Figure 3 illustrates. Using the 64-bit edition of Internet Explorer 11 with Enhanced Protected Mode enabled can also help protect users from a range of Internet-borne threats. Rapid deployment of critical rated vulnerabilities that are likely to be exploited (see Microsoft Security Response Center Exploitability Index above) can help mitigate risk while providing organizations with the flexibility to optimize deployment decisions, as Figure 4 suggests. More details on Figures 3 and 4 can be found in the Microsoft Security Response Center (MSRC) Progress Report 2013.

• Use Enhanced Mitigation Experience Toolkit (EMET)
• EMET can be used to protect applications that run on all supported versions of Windows. The features included in EMET are specifically designed to break exploitation techniques that are currently used by attackers. You can get more details on EMET here.

Tim Rains
Director
Trustworthy Computing

The post When Vulnerabilities are Exploited: the Timing of First Known Exploits for Remote Code Execution Vulnerabilities appeared first on Microsoft Security Blog.

There is a sense of urgency because after April 8, Windows XP Service Pack 3 (SP3) customers will no longer receive new security updates, non-security hotfixes, free or paid assisted support options or online technical content updates.  This means that any new vulnerabilities discovered in Windows XP after its “end of life” will not be addressed by new security updates from Microsoft.  Still, I have talked to some customers who, for one reason or another, will not have completely migrated from Windows XP before April 8.  I have even talked to some customers that say they won’t migrate from Windows XP until the hardware it’s running on fails.

What is the risk of continuing to run Windows XP after its end of support date?  One risk is that attackers will have the advantage over defenders who choose to run Windows XP because attackers will likely have more information about vulnerabilities in Windows XP than defenders. Let me explain why this will be the case.

When Microsoft releases a security update, security researchers and criminals will often times reverse engineer the security update in short order in an effort to identify the specific section of code that contains the vulnerability addressed by the update. Once they identify this vulnerability, they attempt to develop code that will allow them to exploit it on systems that do not have the security update installed on them. They also try to identify whether the vulnerability exists in other products with the same or similar functionality. For example, if a vulnerability is addressed in one version of Windows, researchers investigate whether other versions of Windows have the same vulnerability.  To ensure that our customers are not at a disadvantage to attackers who employ such practices, one long standing principle that the Microsoft Security Response Center (MSRC) uses when managing security update releases is to release security updates for all affected products simultaneously.  This practice ensures customers have the advantage over such attackers, as they get security updates for all affected products before attackers have a chance to reverse engineer them.

But after April 8, 2014, organizations that continue to run Windows XP won’t have this advantage over attackers any longer.  The very first month that Microsoft releases security updates for supported versions of Windows, attackers will reverse engineer those updates, find the vulnerabilities and test Windows XP to see if it shares those vulnerabilities.  If it does, attackers will attempt to develop exploit code that can take advantage of those vulnerabilities on Windows XP.  Since a security update will never become available for Windows XP to address these vulnerabilities, Windows XP will essentially have a “zero day” vulnerability forever.  How often could this scenario occur?  Between July 2012 and July 2013 Windows XP was an affected product in 45 Microsoft security bulletins, of which 30 also affected Windows 7 and Windows 8.

Some of the people I have discussed this scenario with are quick to point out that there are security mitigations built into Windows XP that can make it harder for such exploits to be successful.  There is also anti-virus software that can help block attacks and clean up infections if they occur.  The challenge here is that you’ll never know, with any confidence, if the trusted computing base of the system can actually be trusted because attackers will be armed with public knowledge of zero day exploits in Windows XP that could enable them to compromise the system and possibly run the code of their choice. Furthermore, can the system’s APIs that anti-virus software uses be trusted under these circumstances? For some customers, this level of confidence in the integrity of their systems might be okay, but for most it won’t be acceptable.

As for the security mitigations that Windows XP Service Pack 3 has, they were state of the art when they were developed many years ago.  But we can see from data published in the Microsoft Security Intelligence Report that the security mitigations built into Windows XP are no longer sufficient to blunt many of the modern day attacks we currently see.  The data we have on malware infection rates for Windows operating systems indicates that the infection rate for Windows XP is significantly higher than those for modern day operating systems like Windows 7 and Windows 8.

I recently wrote about the findings of a new study on exploit activity that we just published: Software Vulnerability Exploitation Trends – Exploring the impact of software mitigations on patterns of vulnerability exploitation.  This seven-year study indicates that attackers have evolved their attacks to overcome one of the key security mitigations that Windows XP has: Data Execution Prevention (DEP).  Figure 3 shows the number of common vulnerabilities and exposures (CVEs) that had exploits that would have been mitigated if DEP were enabled compared to the number of CVEs that had exploits that bypassed DEP. With the exception of 2007 and 2008, there appears to be a clear downward trend in DEP’s ability to retroactively break exploits. This trend is not because DEP is no longer effective; rather, it is an indication that attackers have been forced to adapt to environments in which DEP is already enabled—at increased cost and complexity. The evidence is the increasing number of CVEs that had exploits that bypassed DEP.

This new data shows us that the predominate threats that individuals and organizations face are now much different than they were when Windows XP Service Pack 3 was released. Turning on the Windows Firewall in Windows XP Service Pack 2 and later operating systems forced attackers to evolve their attacks.  Rather than actively targeting remote services, attackers now primarily focus on exploiting vulnerabilities in client applications such as web browsers and document readers. In addition, attackers have refined their tools and techniques over the past decade to make them more effective at exploiting vulnerabilities. As a result, the security features that are built into Windows XP are no longer sufficient to defend against modern threats.  Windows 8 has significantly superior security mitigations compared to Windows XP.

Organizations need a level of certainty about the integrity of their systems. Minimizing the number of systems running unsupported operating systems is helpful in achieving that. End of support for Windows XP is April 8, 2014.

Tim Rains
Director
Trustworthy Computing

The post The Risk of Running Windows XP After Support Ends April 2014 appeared first on Microsoft Security Blog.