I’m Matt Dunn, lead penetration tester at Raxis, and I’ve uncovered a couple more ManageEngine vulnerabilities you should know about if your company is using the platform.
Summary
I discovered two instances in ManageEngine Remote Access Plus where a user with Guest permissions can access administrative details of the installation. In each case, an authenticated ‘Guest’ user can make a direct request to the /dcapi/ API endpoint to retrieve information. This allows the ‘Guest’ user to discover information about the connected Domains as well as the License information for the installation.
Proof of Concept
The two vulnerabilities are similar in that they allow a user with ‘Guest’ level permissions to access details about the installation. Each CVE refers to a specific piece of information that the user can retrieve, as detailed below:
CVE-2022-26653 – The ‘Guest’ user can retrieve details of connected Domains.
CVE-2022-26777 – The ‘Guest’ user can retrieve details about the installation’s License.
The user with ‘Guest’ permissions can access all the Domain’s details, including the connected Domain Controller, the account used for authentication, and when it was last updated, as shown here:
Similarly, the ‘Guest’ user can access all the License information, including the amount of users, amount of managed systems, who the license is for, and the exact build number, as shown below:
Affected Versions
Raxis discovered these vulnerabilities on ManageEngine Remote Access Plus version 10.1.2137.6.
Remediation
Upgrade ManageEngine Remote Access Plus to Version 10 Build 10.1.2137.15 or later which can be found here:
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:
A common finding in web applications we test is ‘Application Supports Simultaneous Logins’. This finding occurs when both of the following conditions are met:
The application allows for multiple sessions at the same time, from different devices, browsers, etc.
The application does not alert the user to the multiple sessions through:
Email notification,
Notification inside the application, or
A session management page inside the application.
Essentially, this boils down to the user being allowed to have multiple sessions without a way to manage them or see other active sessions through notifications or otherwise.
What does this look like?
In practice, we look in several locations for the functionality to manage sessions, but the most common place we find it is in profile sections or settings. When these are not available, we’ll log in on two separate browsers — or on two devices — and navigate them both to the settings page, checking for notifications or other session management abilities. An example of multiple sessions without notification to the user in a popular online platform is shown below:
Why does this matter?
Allowing simultaneous sessions seems innocuous at first. I mean, we mostly all have multiple devices that we log in through, right? True, but the lack of insight into your account’s session management becomes a problem if your session is somehow stolen, credentials are obtained, or your account is otherwise compromised through other vulnerabilities. If multiple sessions are allowed without notification to the user, there is no way for the user to know that their account has been compromised or to terminate the active sessions that have been compromised.
Remediations
In today’s world, disallowing multiple sessions is likely not realistic due to business constraints. Most people have several devices themselves, and logging in to an application on multiple is common, so this likely needs to be a feature in your application. However, alerting the user or allowing them to view their active sessions is important so they can maintain control of their account in the event of a breach. There are several ways to do this, with varying functionality, including:
Showing users active sessions with details about the session
Allowing users to terminate specific sessions
Providing functionality to log out the user from all other devices
Combine any of the above when the account password is changed
These are all valid approaches, but the specific one you choose to implement will depend on your application’s use cases, business constraints, and design. In our Raxis One application, we provide the user both with details about their active sessions, functionality for terminating specific sessions, and a session history that includes IP Address and location details, as shown in below:
I’m Matt Dunn, a lead penetration tester at Raxis. This is the second of a two-part series, aimed at explaining the differences between authenticated and unauthenticated web application testing. I’ll also discuss the types of attacks we attempt in each scenario so you can see your app the way a hacker would.
Although some applications allow users to access some or all their functionality without providing credentials – think of simple mortgage or BMI calculators, among many others – most require some form of authentication to ensure you are authorized to use it. If there are multiple user roles, authentication will also determine what privileges you have and/or what features you can access. This is commonly referred to as role-based access control.
As I mentioned in the previous post, Raxis conducts web application testing from the perspectives of both authenticated and unauthenticated users. In authenticated user scenarios, we also test the security and business logic of the app for all user roles. Here’s what that looks like from a customer perspective.
Unauthenticated Testing
As the name suggests, testing as an unauthenticated user involves looking for vulnerabilities that are public-facing. The most obvious is access: Can we use our knowledge and tools to get past the authentication process? If so, that’s a serious problem, but it’s not the only thing we check.
In previous articles and videos, we’ve talked about account enumeration – finding valid usernames based on error messages, response lengths, or response times. We will see what information the app provides after unsuccessful login attempts. If we can get a valid username, then we can use other tools and tactics to determine the password. As an example, see the two different responses from a forgot password API for valid and invalid usernames below:
From an unauthenticated standpoint, we also will try injection attacks, such as SQL Injection, to attempt to break past login mechanisms. We’ll also look for protections using HTTP headers, such as Strict-Transport-Security and X-Frame-Options or Content-Security-Policy, to ensure users are as secure as they can be.
With some applications, we can use a web proxy tool to see which policies are enforced on the client-side interface and which are enforced on the server side. In a future post, we’ll go into more detail about web proxies. For now, it’s only important to know that proxies sometimes reveal vulnerabilities that allow us to bypass security used on the client and allow us to interact with the server directly.
As an example, fields that require specific values, such as an email field, may be verified to be in the proper format on the client-side (i.e. using JavaScript). Without proper safeguards in place, however, the server itself might accept any data, including malicious code, entered directly into that same field. In practice, this can be bypassed, leading to attacks such as Cross-Site Scripting, as shown in my CVE-2021-27956 that bypasses email verification.
Authenticated Testing
During an authenticated web application test, we use many of the same tactics, toward the same ends, as we do with unauthenticated tests. However, we have the added advantage of user access. This vantage point exposes the application to more vulnerabilities due to the expanded surface area of the application. This is why we recommend authenticated testing, to ensure even a malicious user cannot attack the application.
Once authenticated, we attempt is to see if the app restricts users to the level of access that matches its business logic. This might mean we log in with freemium-level credentials and see if we can get to paid-users-only functionality. Or, in the role of a basic user, we may try to gain administrator privileges.
As with an unauthenticated test, we also see how much filtering of data is done at the interface vs. the server. Some apps have very tight server-level controls for authentication but rely on less-restrictive policies once the user is validated.
Though it may seem simple from the outside, one of the hardest things for web app developers to secure is file uploads.
This is another topic we’ll explore further in a future post, however, one good example of the complexity involved is photo uploads. Many apps enable or require users to create profiles that include pictures or avatars. One way to restrict the file type is by accepting only .jpg or .png file extensions. Hackers can sometimes get past this restriction by appending an executable file with a double extension – malware.exe.jpg, for example.
Another problem is that malicious code could be inserted into otherwise legitimate file types such as word documents or spreadsheets. For many apps, however, it’s absolutely necessary to allow these file types. When we encounter such situations, we often work with the customers and recommend other security measures that allow the app to work as advertised but that also detect and block malware.
Conclusion
As a software engineer by training, one advantage I have in testing web applications is understanding the mindset of the developers working on them. People building apps start with the goal of creating something useful for customers. As time goes on, the team changes or users’ needs change, and sometimes vulnerabilities are left behind. This can happen in expected ways, such as outdated libraries, or unexpected ways, such as missing access control on a mostly unused account type.
At Raxis, we employ a group of experts with diverse experiences and skillsets who will intentionally try to break the app and use it improperly. Having testers who have also developed applications gives us empathy for app creators. Even as we attack their work, we know that we are helping them remediate vulnerabilities and making it possible for them to achieve their application’s purpose.
I’m Matt Dunn, a lead penetration tester at Raxis. In this series of posts, I’m going to introduce you to the Raxis method of penetration testing web applications. We’ll start with a look at what a web app test involves and how it differs from the network testing we do.
By their very nature, web apps deserve special scrutiny because they are designed in most cases to be accessible to a broad base of users, often with different roles that convey higher levels of privilege or access. Additionally, they are often used to perform wide ranging functionality, from shopping and banking transactions, to accessing healthcare data. With that accessibility and functionality comes exposure to a wide range of threats from malicious actors who want to exfiltrate data, modify the application, or otherwise disrupt its operation.
When Raxis performs a web application penetration test, we typically approach it from the viewpoint of both unauthenticated and authenticated user roles. In many cases, some of the app’s functionality is going to be behind some form of authentication. We’ll go into greater detail about authenticated and non-authenticated tests in a subsequent post. For now, however, we’ll limit the discussion to tests in which we are given credentials for all user roles.
Armed with the appropriate credentials, we examine all the functionality of the app to find out what features are accessible to users and how the application is intended to work. Can users’ profiles be changed? Are users allowed to upload files? Where can the user input their own content? What is each user supposed to be allowed to do? These are just some of the questions we’re looking to answer in the beginning of the test.
Once we know what the app should do, we’ll test all these features to see if the business logic is correct. For example, an app may allow only administrators to delete uploaded files. So, we’ll attempt to circumvent that restriction and see if we can accomplish that with lower-privileged credentials.
Raxis approaches a web application test from the perspective of unauthenticated users and authenticated users in multiple roles when more than one role exists.
Next, we will try to exploit the app’s features. For instance, we’ll test the various input fields to see if we can insert malicious code. If so, the app may be vulnerable to cross-site scripting (XSS) – a topic I’ve covered extensively on our blog and YouTube channel. In a similar manner, we’ll test areas where we can upload files to see if we can upload malicious content as part of an attack.
One question we get from time to time is whether web application testing is included as part of our network penetration tests. The answer is no, for two reasons: First, it’s unlikely that, within the time of a well-scoped network test, we will be able to find credentials to all roles and parts of your web app. Second, network tests are broader in scope and identify the highest risk vulnerabilities across the entire network (as time allows). Depending on other findings, we often test the accessible pages as well as the authentication features. These include logins and “forgot password” pages, to name just a couple. Our goal is to see if we can gain unauthorized access, perform account enumeration, or attack the application externally. But we won’t test as a verified user unless we’re able to gain authenticated access, and even then, we will not focus on the web app in the same depth as we would in a web app test.
That’s what makes web application testing so important. And with so many companies relying on (or even built around) web apps, it makes sense to conduct these tests regularly and address the findings in order of priority. Even if you are already performing network penetration tests, I strongly recommend that you conduct specific web application tests as well.
“Give a pentester a table, they submit one report. Automate making tables, they can submit reports for life.”
k0pak4
Displaying findings clearly and concisely is key to making a penetration testing report actionable. The proof of concept allows a client to replicate the finding, and a list of affected targets allows them to properly remediate all assets. On large engagements, there are often findings that affect many hosts; when presented concisely, this can be acted on much more easily. There are already amazing tools out there to scan many hosts and report their findings. (Nessus, Nexpose, and Nmap are examples.) The problem is that none were doing what I was looking for — reporting the affected hosts for one finding, concisely.
The first two tools described here quickly create tables showcasing the details behind two common findings on large external pentest reports. Clients can also use these tools to verify remediations without having to manually inspect each host. The last tool can be used to turn any list into a sorted table, which works well when you simply need a large table to display many hosts.
There are several tools that will break down the weak SSL/TLS protocol versions, ciphers, and signature algorithms used in TLS connections. Some of these are web-based, such as SSL Labs, and others are command-line based, such as the SSLScan tool. My mass-sslscan tool runs SSLScan against an entire list of hosts, parses the output of the tool, and creates a table with each host that displays which weak configuration(s) they have. This can also be used in remediation to ensure those servers have had their configurations strengthened. An example of running the tool is shown below:
On penetration tests, it’s common to find the HTTP server header, which can disclose the web server’s software and sometimes its exact version. This information leakage is typically of low severity, but helps an attacker fingerprint the server, which may disclose a vulnerable version. In more targeted attacks, it might tell them what software to build an exploit for. My tool, server-header-scan, retrieves the server header from each target, and inserts the results into a table with each retrieved value, as shown in the following example:
The table-maker is a bit more straightforward. It takes a list, either as a comma-separated list or as a file with one item per line, and turns it into a table with the desired number of columns. This can be useful for extremely large scopes or when discovering many hosts are vulnerable to a specific finding. This results in a csv ready to be opened and pasted as a table, as shown in the illustration below:
If you compile reports for large penetration tests, odds are that you’re going to be pressed for time at some point. My hope is that these tools will make it easier for you to provide more and better information to your customers in a way that helps them understand and act on your findings.
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
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
