I’m Matt Dunn, lead penetration tester at Raxis. Recently, I discovered a stored XSS in Support Center Plus. Here’s how a malicious actor might exploit it — and what you can do to prevent it.
Summary
A low-privileged user (e.g., the default guest user) can inject arbitrary JavaScript into the description of a new Request. When another user (including a high privileged user) views that request’s edit history, the payload is executed in the context of that new user’s browser. This can cause privilege escalation or other payload execution from low privileged users to other, possibly higher privileged users.
Proof of Concept
The vulnerability can be triggered by inserting html content in the description field of a new request. The payload I inserted as a guest user was:
"><img src=x onerror="alert(document.cookie)"/>
This payload being inserted is shown here:
When another user (in this case an admin) views that request’s edit history, the JavaScript is executed in the context of the new user’s browser, as shown here:
This vulnerability allows any low privileged user to execute JavaScript on higher privileged or other low privilege user’s browsers once they view a request’s edit history. While the payload used here launches an alert box with the page’s cookie values, more dangerous payloads could be executed in this context as well.
Affected Versions
Raxis discovered this vulnerability on Manage Engine Support Center 11.0 Build 11019.
Remediation
Upgrade ManageEngine AD Support Center Plus to Version 11.0 Build 11020 or later immediately which can be found here:
I’m Matt Dunn, a lead penetration tester here at Raxis. Recently, I discovered a stored Cross-Site Scripting vulnerability in Zoho’s ManageEngine AD SelfService Plus.
Summary
The vulnerability exists in the /accounts/authVerify page, which is used for the forgot password, change password, and unlock account functionalities.
Proof of Concept
The vulnerability can be triggered by inserting html content, specifically tags that support JavaScript, into the first or last name of an Active Directory user. The following was inserted as a proof of concept to reflect the user’s cookie in an alert box:
<img src=x onerror=”alert(document.cookie)”/>
An example of this in the Last Name field of one such user is shown here:
The next time that user forgets, attempts to change, or is locked out of their account and they load the authVerify page, their name is presented without being sanitized. The unescaped HTML as loaded can be seen in Figure 2:
After the user attempts to reset their password, the malicious content is executed, as shown in Figure 3:
If the user must change their password on login, the malicious content is executed, as shown in Figure 4:
If the user attempts to unlock their account, the malicious content is executed, as shown in Figure 5:
Affected Versions
Raxis discovered this vulnerability on Manage Engine AD SelfService Plus 6.1 Build 6119.
Remediation
Upgrade ManageEngine AD SelfService Plus to Version 6.1 Build 6121 or later immediately:
People are often surprised to find that a hacker doesn’t only attack a website through the authentication process. Our team members are experts at demonstrating why just enforcing password policies and lockout times doesn’t fully protect applications.
In this article, we’re going to pull back the curtain and show you how hackers use web proxy tools to help exploit applications in ways you might never expect.
How the Proxy Tool Works
The proxy tool is software that follows the path data takes step-by-step from your device to the application server. Several such tools exist, but Burp Proxy (included in all versions of Burp Suite) is one of the most popular. Using Burp Proxy, hackers can bypass the user interface – the page you see when entering data – and change the information before it is sent to the application server. This makes it possible to avoid client-side controls, such as those that check that a phone number is only numeric or that an email address is formatted correctly. If the application server expects the client-side controls to have already validated data, the server code may not have all of the proper protections in place.
In the image below, Burp Proxy, in “Intercept” mode, shows each step along the path that data follows from your device to an application server. The tool allows a user to tab from step to step and change the data that was input originally. If security features are built into the client (the interface you see) but not present on the application server, the proxy enables hackers to enter compliant data first, but change it however they want before it reaches the server.
One example of how hackers exploit this setup is through the commonly used buttons or checkboxes found in many apps. Most app developers are cautious about user input fields, but, because buttons, checkboxes, and radio buttons apparently limit data entry to “on-off” or “yes-no” choices, they often see little inherent risk. The problem is that, even though the user options are limited at the interface (client-side), they may not be limited by the code on the server itself (server-side).
How a Proxy Tool can Reveal a Vulnerability
The three illustrations below show how even a simple “submit” button can present opportunities for hackers.
The choice here seems straightforward — either you click the button or you do not. But that choice masks what happens after you click “submit.”
“Submit” is really just a request being sent to the server. Here, using Burp Proxy to intercept the data, we can see the request as it will appear to the application server.
Now, rather than a simple yes-or-no choice, a user can modify the data any way they’d like and enter it by pressing the “Forward” command.
How Hackers Turn the Exploit into an Attack
With the ability to effectively bypass safeguards on the client-side interface, hackers can send information directly to the application server. Here are a couple of examples of the types of attacks they can execute if the application server is not secure. (For clarity, we’ll use text-based fields, rather than check-boxes in these examples.)
Example 1: Cross-Site Scripting (XSS)
Cross-site scripting (XSS) is a reflected attack that injects malicious client-side executable code into web application parameters to be returned by the application output and ultimately executed by the browser. Because it appears that the script is from a trusted source, the end-user’s browser accepts it and runs the script, permitting the attacker to take actions on the application’s behalf, such as accessing cookies and session tokens as well as other sensitive data. (Source: Raxis Glossary).
The following walk-through demonstrate how a simple guestbook submission form request works normally and then how an attacker can use a web proxy to insert malicious code.
This is the submission form as it appears to users:
Our Burp Proxy tool reveals the actual request sent to the application server:
Here the attacker enters an innocuous submission that should not be caught by client-side injection controls:
And now the attacker captures the entry using Burp Proxy:
Before allowing the proxy tool to move to the next step, the attacker replaces the original harmless data with a malicious script:
The application server, without server-side controls to stop it, accepts the script and returns the payload to the browser. This is what the attacker sees in Burp Proxy:
And here we see the successful cross-site scripting result in the browser:
Example 2: SQL Injection (SQLi)
In this attack, a SQL query is injected into the application via input parameters. A successful attack could read sensitive data from the database, modify data in the database, execute operations on the database (including administrative operations), recover files on the DBMS file system, or issue commands to the operating system. (Source: Raxis Glossary)
Here we demonstrate how a user ID field can be manipulated to enable a SQLi attack.
We start with a simple user ID entry field with a submit button where we enter a name and submit:
Again the attacker intercepts the submission using Burp Proxy en route to the application server.
As above in the XSS exploit, the attacker then modifies the data in Burp Proxy, this time to include escape characters and a SQL query:
With no server-side controls in place to stop the attack, the server returns the data requested in the SQL database query. This is what the attacker sees in Burp Proxy:
And here we see the successful SQL injection result in the browser:
Summary
It’s tempting here to focus on the Burp Proxy tool and its capabilities, but the more important point is to recognize that vulnerabilities can exist in places we as users might not think. Something that seems innocuous, like a simple submit or on/off button, can be manipulated by a hacker with relative ease. The same is true for any field, button, or widget that sends a request to an application server.
Remember that the mindset of a hacker is always to look at something as it’s expected to be used, then attempt to use it differently. That’s why pentesting by skilled professionals is so important. It takes trained, ethical hackers to prevent the work of their malicious counterparts.
Would you like to learn how Raxis can help your organization? Reach out. We have a guaranteed, no-pressure approach, and – after all – we’re all on the same side.
This is the second video in my three-part series about cross-site scripting (XSS), a type of injection attack that results from user-supplied data that is not properly sanitized or filtered from an application. In the previous video, I discussed the basics of how XSS works and offered some recommendations on how steps to protect against it.
In this video, we’ll take it a step further. I’ll show you some techniques hackers use to get past common remediation efforts. First is filter evasion, which uses different types of tags to insert malicious code when filters are in place to prevent scripts from running. The second is a technique I call sideloading content, importing third-party content in order to deliver a malicious payload.
Injection attacks are number three on the OWASP Top 10 list of frequently occurring vulnerabilities, and, indeed, they are a finding Raxis discovers quite frequently. (Over the past year, I have discovered five XSS CVEs.) So, in addition to explaining how these attacks work, I also explain how to stop them.
In my next video, we’ll take a look at some more advanced methods for cross-site scripting, again with some remediation tips included. So, if you haven’t done so already, please subscribe to our YouTube channel and watch for new content from the Raxis team.
Cross-site scripting (XSS) has been a popular finding for me in 2021, discovering five XSS vulnerabilities that have been assigned CVEs. Additionally, it’s been present on recent application testing as well, so I thought it would be beneficial to cover XSS in more depth.
This video is the first in a series of blog posts that will describe various cross-site scripting attacks, remediations, and specific areas to look out for that I have seen overlooked in the sanitization of user-supplied data. This video covers the basics of cross-site scripting, including reflected, stored, and DOM-based XSS. Additionally, I’ll discuss remediation to protect against these attacks. Future videos will cover filter evasion and side-loading payloads, as well as cookie theft and advanced payloads.
I hope this video and the ones that follow give you a better idea about how cross-site scripting works, why it’s dangerous, and how to prevent it from happening to your company.
Recently, I discovered a stored cross-site scripting (XSS) vulnerability in Nagios XI v5.8.5. The vulnerability exists in the dashboard page of Nagios XI (/dashboards/#) when administrative users attempt to edit a dashboard. The dashboard name is presented back to the user unencoded when the edit button is clicked, which can allow dashboard names with malicious JavaScript to be executed in the browser.
Proof of Concept and Exploitation Details
The vulnerability can be triggered by inserting html content that contains JavaScript into the name field of dashboards. The following payload was used to launch an alert box with the number 1 in it as a proof of concept:
“><script>alert(1)</script>
An example of this in the dashboard’s name field can be seen in the image below:
After clicking the edit button for the dashboard name, the dashboard’s name is loaded as unencoded HTML, as shown below:
After clicking the edit button for the dashboard name, the JavaScript from the script tag is executed as shown in the following image:
Vulnerable Software Version
Raxis discovered this vulnerability on Nagios XI v5.8.5.
Remediating the Vulnerability
Upgrade Nagios XI to version 5.8.6 or later immediately.
Disclosure Timeline
August 5, 2021 – Vulnerability reported to Nagios
August 6, 2021 – CVE-2021-38156 is assigned to this vulnerability
September 2, 2021– Nagios releases version 5.8.6 addressing this vulnerability
Cookies are a way to store information across multiple HTTP requests. HTTP is a stateless protocol, meaning each request is completely independent of subsequent requests. Cookies are set by the web server, and then stored in the user’s web browser. Each subsequent request to the domain specified in the cookie will then include the set cookies in the HTTP request headers, so the web server can continue to associate the following requests to that user. Some common use cases for cookies are authentication, analytics IDs, and user preferences.cook
So, what are cookie flags, then?
Cookie flags are attributes for a cookie that are set when the cookie is initialized. These attributes live for the duration of the cookie’s lifespan, so it’s important that they are set with secure attributes, especially for important cookies used for maintaining sessions or other sensitive user information. These attributes can quickly be seen by looking at a cookie in the browser, as shown below:
HttpOnly Flag
The HttpOnly flag prevents a cookie from being accessed from protocols other than HTTP. This flag is mostly used so that client-side JavaScript cannot access the cookie.
Security Impact
When the HttpOnly flag is not set, client-side JavaScript is able to access and use the cookie. From an attacker’s perspective, it means the cookie is vulnerable to being stolen or used during other client-side attacks, such as in a Cross-Site Scripting (XSS) attack. For example, in our recently discovered XSS Vulnerability in ManageEngine Applications Manager (CVE-2021-31813), cookies were accessed through the inserted JavaScript and reflected back to the screen, as shown below:
In a real scenario, an attacker may send the cookie to themselves instead of reflecting it to the screen. However, if the HttpOnly flags had been set, the malicious JavaScript could not have accessed the application’s cookies in the first place.
Secure Flag
The Secure flag prevents a cookie from being sent over HTTP and enforces the cookie to only be sent over HTTPS. This flag is used to prevent attackers from stealing cookies by sniffing unencrypted HTTP traffic. Even though there is a high usage of HTTPS, cookies can still be sniffed on redirects and through other means without the Secure flag.
Security Impact
When the Secure flag is not set, the user’s cookies will be sent over HTTP if a request is made to that website’s HTTP port. Most websites now support HTTPS, but there are still multiple ways for cookies to be sent over HTTP even when the server supports HTTPS. For example, if a website’s web server redirects HTTP requests to use HTTPS, it’s possible the initial web request will have sent cookies that are not using the Secure flag. Similarly, if a user clicks on a link (e.g., from a phishing email) that doesn’t have https:// appended to it, the initial request will send any cookies for that website that are not using the Secure flag. An attacker that is sniffing traffic would then be able to see the cookie’s value in cleartext. The Strict-Transport-Security header can help to mitigate some of this impact, but, to ensure cookies are never sent over an unencrypted channel, the Secure flag should always be used.
Recently, I discovered a stored Cross-Site Scripting vulnerability in PRTG Network Monitor Version 21.1.66.1623+. The vulnerability exists in the email field of user details on the “User Accounts” page at /systemsetup.htm?tabid=5 when users are loaded from Active Directory. After the page loads, the email field is loaded with unescaped content, allowing malicious JavaScript to be reflected back to the user.
Proof of Concept and Exploitation Details
The vulnerability can be triggered by inserting HTML content, specifically script tags, into the email field of an Active Directory user. The following was inserted as a proof of concept to reflect the user’s cookie in an alert box:
<script>alert(document.cookie)</script>
An example of this on one such user can be seen in the image below:
After loading the list of users, the HTML is then presented unescaped on the web page, which allows the script tags to be loaded as valid JavaScript. The unescaped HTML, as it loads in the browser, is seen in the next image:
Once the page loads, the JavaScript executes, displaying the user’s cookie to the screen, as shown in this picture:
Vulnerable Software Version
Raxis discovered this vulnerability on PRTG Network Monitor version 21.1.66.1623+.
I’m Matt Dunn, lead penetration tester here at Raxis. This is a summary of the second stored cross-site scripting vulnerability I discovered while testing several Zoho-owned ManageEngine products. This vulnerability exists in the Key Manager Plus Version 6000.
Summary
Recently I discovered a stored Cross-Site Scripting vulnerability in the Zoho-owned ManageEngine Key Manager Plus for Version 6000 (CVE-2021-28382). The vulnerability exists in any of a user’s details fields when they are imported from Active Directory. This can be performed in one of the name fields or the email field, and is executed when visiting the /apiclient/index.jsp#/Settings/UserManagement page. After this page loads, the user’s details are loaded with unescaped content, allowing for malicious JavaScript to be reflected back to users.
Proof of Concept
The vulnerability can be triggered by inserting html content, specifically script tags, into the first name, last name, or email field of an Active Directory user. The following was inserted as a proof of concept to reflect the user’s cookie in an alert box:
<script>alert(document.cookie)</script>
An example of this in the Last Name field of one such user can be seen here:
After that user’s details load on the UserManagement page, the HTML is then presented unescaped on the web page, which allows the script tags to be loaded as valid JavaScript. The unescaped HTML, as loaded, can be seen here:
After loading the UserManagement page, the malicious content is executed, as shown below:
Affected Versions
Raxis discovered this vulnerability on Manage Engine Key Manager Plus 6000 (6.0.0), but any version below 6001 could be vulnerable when importing users from Active Directory.
I’m Matt Dunn, lead penetration tester at Raxis.This is a summary of the first stored cross-site scripting vulnerability I discovered while testing several Zoho-owned ManageEngine products. This vulnerability exists in the AD Self Service Plus Version 6.1.
Summary
Recently I discovered a stored cross-site scripting (XSS) vulnerability in the Zoho-owned ManageEngine AD Self Service Plus for Version 6.1 (CVE-2021-27956). The vulnerability exists in the email field of search results on the page: /webclient/index.html#/directory-search. After searching for a user, if the “More” tab is clicked, the email field is loaded with unescaped content, allowing for malicious JavaScript to be reflected back to users.
Proof of Concept
The vulnerability can be triggered by inserting HTML content, in this case script tags, into the email field of an Active Directory user. The following was inserted as a proof of concept to reflect the user’s cookie in an alert box:
<script>alert(document.cookie)</script>
An example of this on one such user is shown here:
After searching for that user, the HTML is then presented unescaped on the web page, which allows the script tags to be loaded as valid JavaScript. The unescaped HTML as loaded is shown here:
After loading the search page, clicking the “More” tab triggers the vulnerability, which is shown in Figure 3:
Affected Versions
Raxis discovered this vulnerability on ManageEngine AD Self Service Plus 6.1, build 6100.
Remediation
Upgrade ManageEngine AD Self Service Plus to Build Version 6104 immediately. The ServicePack can be found here with release notes here.
Disclosure Timeline
February 19, 2021 – Vulnerability reported to Zoho
February 19, 2021 – Zoho begins investigation into report
March 5, 2021–CVE-2021-27956 assigned to this vulnerability
May 8, 2021 – Zoho releases patch for this vulnerability
