Author: raxis-sys-admin

  • New Metasploit Module: Azure AD Login Scanner

    Summary

    In June of 2021, Secureworks Counter Threat Unit (CTU) discovered that the protocol used by Azure Active Directory (AD) Seamless Single Sign-On (SSO) allows for brute-forcing usernames and passwords without generating log events on the targeted tenant. In addition to brute-forcing credential pairs, the Azure endpoint returns error codes that allow for username enumeration. This post details the vulnerable endpoint, and how it can be exploited to brute-force usernames and passwords in a succinct Metasploit module.

    Vulnerability Description

    In addition to the normal Azure AD authentication workflow for SSO, which utilizes Kerberos, the usernamemixed endpoint of Autologon accepts single-factor authentication. Authentication attempts to this endpoint are in XML, as shown here:

    Example XML Authentication Request

    The Autologon endpoint takes these credentials and sends them to Azure AD to authenticate the user. If the credentials are valid, the authentication is successful, and the Autologon endpoint responds with XML containing a DesktopSsoToken, which is used to further connect and authenticate with Azure AD. When a successful logon occurs, Azure AD properly logs the event.

    However, on authentication attempts that are unsuccessful, the authentication attempt does not get logged by the tenant. If the credentials are invalid, the Autologon endpoint responds with XML containing a specific error code for the authentication attempt, as shown here:

    Detailed Error Code in XML Response

    The error code provided in this response can be further used to determine valid usernames, whether MFA is needed, if the user has no password in Azure AD, and more. The error codes used in the Metasploit module I developed are shown below:

    Error Codes
    Metasploit Module

    The Metasploit module (auxiliary/scanner/http/azure_ad_login) can enumerate usernames or brute-force username/password pairs based on the responses from the Autologon endpoint described above. If you have a target tenant using Azure AD SSO and usernames/passwords to validate, you can use this module by setting the following variables:

    • DOMAIN – The target tenant’s domain (e.g., bionicle.dev)
    • USERNAME or USER_FILE – A single username to test or a file containing usernames (one per line)
    • PASSWORD or PASS_FILE – A single password or a file containing passwords (one per line)

    When you run the module, every username/password pair is tested using the authentication XML request shown above to validate the pairing. When a valid username/password pairing is found, the DesktopSsoToken is also displayed to the user, as shown here:

    Example Azure AD Login Module Usage
    Remediation and Protection

    As of the writing of this post, there is no direct remediation to this vulnerability if your organization is using Azure AD with Single Sign-On. Microsoft has deemed this part of the normal workflow, and thus there are no known plans to remediate the endpoint. From a defender’s point of view, this vulnerability is particularly difficult to defend against due to the lack of logs from invalid login attempts. Raxis recommends the following to help defend against this vulnerability:

    • Ensure users set strong passwords in Active Directory by having a strong password policy.
    • Enable Multi-Factor Authentication on all services that may use AD credentials in case a valid username/password pair is discovered.
    • Consider setting a Smart Lockout policy in Azure that will lock out accounts targeted by brute-force attacks. This won’t help with password spraying, but will for single user brute-forcing.
    • Monitor for unusual successful logins from users (e.g. unusual locations).
    • Educate users about password hygiene so that they can learn to set strong passwords that won’t be caught by password spraying attacks.
    Metasploit Module Details
    References

     

  • Cross-Site Scripting (XSS): Filter Evasion and Sideloading

    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.

    Want to learn more? Take a look at the first part in our Cross-Site Scripting Series.

  • Introduction to Cross-Site Scripting

    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.

    Want to learn more? Take a look at the second part in our Cross-Site Scripting Series.

  • OWASP Top 10: Broken Access Control

    The Open Web Application Security Project (OWASP) Top 10 is intended as a guide to help security professionals prioritize the most common and urgent web application threats that they or their clients are likely to face. By collecting and analyzing data over time, OWASP is a source of both intelligence and awareness for the people responsible for building secure applications. Raxis uses the OWASP Top 10 as a baseline when assessing web applications, ensuring that our customers are guarding against each of the most common threat categories. Of course, our testing goes well beyond the items on the list, but it is an effective starting point for security assessments.

    What Is a Broken Access Control?

    Broken access control, not to be confused with broken authentication, happens when a user unintentionally is granted elevated permissions or access to an application, user role, or domain. But what does that mean to website users? It means that the user, whether a hacker or someone unintentionally discovering the vulnerability, gains access that was never intended, whether that is access to private information for other users or access to an admin page that allows them to perform actions few people should be allowed to do.

    When a web app fails to enforce proper access controls, the results can be unauthorized disclosure of sensitive information, modification or destruction of data in the system, or the ability to perform business function the user should have no authority to perform.

    This vulnerability has moved from the fifth position all the way to first in the new 2021 OWASP Top 10 update. According to the OWASP Foundation, 3.81% of the applications tested had some form of broken access control. While that may sound like a small percent, the cost is high when you realize the sensitive data & systems that could be exposed.

    A Few Examples

    Many web applications can have a user login page with data such as credit card, phone number, or address information. Let’s consider two users of that application, Fred and Karen. If Karen was logged into her profile, she might see a URL similar to the link below:

    website[.]com/app/acctinfo?user=karen

    But what happens if she can simply change “karen” on the end of the URL to “fred”? We would get the URL below:

    website[.]com/app/acctinfo?acct=fred

    By itself, that is not broken access control. If the application is secure, Karen would be denied access. However, if Karen was then able to see the information in Fred’s account, it would be an example of broken access control. But why stop there? Once Karen realizes she can see Fred’s personal information, she might write a script that tries common names of other people to gather thousands of credit cards to sell on the dark web.

    Another example of a broken access control is the ability to access a server status or web app information page that should not be public to all users. If an unauthenticated user can access either of the two example pages below, it would be a form of broken access control.

    website[.]com/server-status
    website[.]com/app/getappinfo

    Why would that be important? Many attacks require multiple steps, and each step that provides information helps the hacker understand if their actions are working or not. A hacker may use a server-status page to see if their attack is successful, or they may use the getappinfo page to find out what software the server is using so they know what type of attacks to try.

    How to prevent Broken Access Control

    Remediating broken access control is not a one-size-fits-all concept. Just like people are all unique and beautiful in their own way, and deserve to be treated fairly, not tossed aside… err [deep breath] ahem. Really sorry. Website developers must implement trusted server-side code or APIs that do not allow attackers to modify the access control checks or metadata.

    The list below is a good place to start with hardening Access Controls in your environment:  

    • Implement deny-by-default on everything except public resources.
    • Minimize Cross-Origin Resource Sharing (CORS), instead implementing access control mechanisms once and reusing them throughout the application.
    • Enforce record ownership rather than accepting that the user can create, read, update, and/or delete any record.
    • Ensure file metadata and backup files are not present in web roots.
    • Disable web server directory listings.
    • Set rate limits for API and controller access to minimize the attack surface of automated attack tools.

    Want to learn more? Take a look at the second part in our 2021 OWASP Top 10 Series.

  • 2021 OWASP Top 10 Focus: Injection Attacks

    This is the first in a series of blog articles that will provide some deeper insight into the vulnerability types that made the latest OWASP Top 10 list.

    The Open Web Application Security Project (OWASP) recently released a draft of its periodic Top 10 vulnerabilities list. The open-source list is based on both raw data collected through automated testing, as well as the real experiences of cybersecurity and other IT professionals. 

    How Raxis uses the OWASP Top 10

    The OWASP Top 10 isn’t an exhaustive accounting of all the potential vulnerabilities in applications. Instead, it’s intended as a guide to help security professionals prioritize the most common and urgent threats they or their clients are likely to face. By collecting and analyzing data over time, OWASP is a source of both intelligence and awareness for the people responsible for building secure applications.

    As a penetration testing company, Raxis uses the OWASP Top 10 as a reference, ensuring that its customers are protecting against each of the most common threat categories. Of course, our testing goes well beyond the items on the list, but it is an effective starting point for security assessments.

    Why injection is a major concern

    In 2017, the last time the list was published, injection was the number-one concern. In 2021 this vulnerability moved down into the third position and now includes Cross-Site Scripting (XSS), which was its own category in 2017. However, that doesn’t necessarily mean it has diminished in severity; only that other vulnerabilities have increased in frequency.

    How an injection attack works

    The underlying cause of injection attacks is from user-supplied data that is not properly sanitized or filtered from an application. This can include various attacks such as SQL-injection, command injection, XSS, and more. While each of these attacks are different, they are all successful because of an application trusting user-supplied data, which led OWASP to combine Injection and XSS in this version of the Top 10.

    Raxis is well-versed in Injection attacks and has continued to see a high presence of these vulnerabilities in 2021. In particular, we have continued to see XSS be prevalent in applications, as evidenced by the five XSS CVEs I discovered and helped remediate this year: 

    How to prevent injection vulnerabilities

    The best defense against an injection attack is to not trust user-supplied data. Specifically, applications should sanitize or filter all user-supplied data before processing it, reflecting it back to users, or sending it to a database. In addition to user-supplied data, applications should not trust data coming from third parties such as external APIs, Active Directory, or other external sources. Four of the above CVEs involved data coming from an external source, which demonstrates the need for applications to not trust any outside data.

    Want to learn more? Take a look at the first part in our 2021 OWASP Top 10 Series.

  • Nagios XI Stored Cross-Site Scripting (XSS): CVE-2021-38156

    Vulnerability Summary

    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:

    Stored XSS Payload

    After clicking the edit button for the dashboard name, the dashboard’s name is loaded as unencoded HTML, as shown below:

    Unescaped JavaScript Tags

    After clicking the edit button for the dashboard name, the JavaScript from the script tag is executed as shown in the following image:

    JavaScript Execution to Launch an Alert Box

    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

    CVE Links and More

     

  • Keep Your Cookies in the Cookie Jar: HttpOnly and Secure Flags

    What are cookies, anyway?

    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:

    Example of cookies set with Secure and HttpOnly flags
    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:

    Cookie accessed by inserted JavaScript in XSS vulnerability (CVE-2021-31813)

    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.

  • PRTG Network Monitor Stored Cross-Site Scripting Vulnerability (CVE-2021-29643)

    Vulnerability Summary

    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:

    Stored XSS Payload

    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:

    Unescaped JavaScript Tags

    Once the page loads, the JavaScript executes, displaying the user’s cookie to the screen, as shown in this picture:

    XSS Payload Execution to Display User’s Cookie in an Alert Box
    Vulnerable Software Version

    Raxis discovered this vulnerability on PRTG Network Monitor version 21.1.66.1623+.

    Remediating the Vulnerability

    Upgrade PRTG Network Monitor to Version 21.3.69.1333 or later immediately. The release notes and upgrade instructions can be found here: https://www.paessler.com/prtg/history/stable#21.3.69.1333.

    Disclosure Timeline
    • March 22, 2021 – Vulnerability reported to Paessler Technologies.
    • March 25, 2021 – Vulnerability confirmed by Paessler Technologies.
    • April 12, 2021 – CVE-2021-29643 assigned to this vulnerability.
    • July 6, 2021 – Paessler releases version 21.3.69.1333 to address this vulnerability.
    CVE Links & More

     

     

  • Meet the Team: Matt Mathur, Lead Penetration Tester

    Hi, I’m Matt Mathur. A few days ago, I did an interview with Jim, our marketing guru. The idea is to introduce you to Raxis through the eyes of our team, how we found our way to this profession, and to help you understand what drives our passion for penetration testing. Read on to learn more about my personal story, and if you’re interested in joining our team, check out our careers page and see if you might be a good fit.

    Jim: Tell me a little about your background. How long have you been with Raxis?

    Matt: I grew up on Long Island in New York and got my B.S. in Computer Science from Northeastern University in Boston. I now live in Philadelphia with my fiancée Natasha, who’s finishing up medical school. I joined the Raxis team last November after working on building some automated attack tools to assist in cybersecurity testing and training.

    Jim: How did you come to focus on cybersecurity?

    Matt: Well, I had some experience as a software engineer, in malware research and other security research before turning towards offensive security. I liked all those things, but the idea of offensive security – of using our hacking ability to help companies become more secure is really what excites me.

    Jim: Helping people seems to be a theme in your career and in your personal life. Is that right?

    Matt: Yeah, I think that’s really what led me to cybersecurity in the first place, helping people protect their users and important data. Outside of that, I try to volunteer at organizations such as Black Girls Hack and Women’s Society of Cyberjutsu to help empower people to succeed in cybersecurity. I’m also just inspired by Natasha, who is helping people every day.

    Jim: How does working on the Raxis team fit into that mix?

    Matt’s homemade macarons

    Matt: When we help companies remediate vulnerabilities, we’re helping them secure their users, data, and company. The team is passionate about this, and about helping other security researchers by sharing knowledge with the community.

    Jim: Help our readers and me understand what you mean by that.

    Matt: The Raxis team is fully remote, and we’re constantly updating each other on the newest attacks, tools, and vulnerabilities. On top of that, we’re encouraged to publish our findings, tools, and techniques to help others in the community remediate them too.

    Jim: Do you have an example?

    Matt: Sure, I recently published a Metasploit Module based on a new vulnerability I discovered in Microsoft’s Remote Desktop Web Access application. This module helps people detect the vulnerability, and Raxis not only gave me the time to work on this, but also actively encouraged it. The team celebrates these things, and the same is true for team members who earn new certifications, find creative ways to breach a customer’s network, or develop other tools.

    Jim: You’ve talked about a lot of advantages to being part of the Raxis team. What’s your favorite part of the job?

    Matt: Outside of being able to use offensive security to help people, I like being challenged while learning new things. Outside Raxis, I like to play strategic games like MtG, go hiking and biking, and improve my cooking and baking. These are varied, but it’s nice to get outside my cybersecurity headspace.

    With that said, my favorite part about the job is that it’s an ongoing challenge. We work with clients in various industries with vastly different networks, applications, and security postures. Even very similar companies can have entirely different tech stacks, so there’s constantly room to learn.

  • ManageEngine Applications Manager Stored Cross-Site Scripting Vulnerability (CVE-2021-31813)

    I’m Matt Dunn, lead penetration tester here at Raxis.This is a summary of the third stored cross-site scripting vulnerability I discovered while testing several Zoho-owned ManageEngine products. This vulnerability exists in the Applications Manager product.

    Summary

    Recently I discovered a stored Cross-Site Scripting vulnerability in ManageEngine Applications Manager. The vulnerability exists in a users’ name fields when they are imported from Active Directory. This can be performed in any of the name fields and is executed when selecting the user for import on /admin/userconfiguration.do after fetching users from the domain. After the import loads and the user is selected, the user’s name is loaded with unescaped content, allowing malicious JavaScript to be reflected back to the user.

    Proof of Concept

    The vulnerability can be triggered by inserting html content, specifically script tags, 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:

    <script>alert(document.cookie)</script>

    An example of this in the Last Name field of one such user can be seen here:

    Stored XSS Payload

    After that user is selected and the details load on the “User Imported from Active Directory” page, the HTML is 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:

    Unescaped JavaScript Tags

    After loading the selected user, the malicious content is executed, as shown below:

    JavaScript Execution to Display User's Cookie in an Alert Box

    Affected Versions

    Raxis discovered this vulnerability on Manage Engine Applications Manager 15, Build 15080.

    Remediation

    Upgrade ManageEngine Applications Manager to Version 15.1 Build 15130 or later immediately which can be found here:

    Disclosure Timeline

    • March 18, 2021 – Vulnerability reported to Zoho
    • March 18, 2021 – Zoho begins investigation into report
    • April 27, 2021 – Zoho releases fixed version 15.1 Build 15130
    • April 27, 2021 – CVE-2021-31813 is assigned to this vulnerability

    CVE Links

  • ManageEngine Key Manager Plus Cross-Site Scripting Vulnerability (CVE-2021-28382)

    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:

    Stored XSS Payload

    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:

    Unescaped JavaScript Tags

    After loading the UserManagement page, the malicious content is executed, as shown below:

    XSS Execution Displaying the User's Cookie

    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.

    Remediation

    Upgrade ManageEngine Key Manager Plus to version 6001 or later immediately. Version 6001 can be found here: https://www.manageengine.com/key-manager/release-notes.html#6001

    Disclosure Timeline

    • March 5, 2021 – Vulnerability reported to Zoho
    • March 8, 2021 – Zoho begins investigation into report
    • March 13, 2021 – Zoho releases version 6001 to mitigate vulnerability
    • March 15, 2021 – CVE-2021-28382 assigned to this vulnerability

    CVE Links

  • Cross-Site Scripting Vulnerability in ManageEngine AD Self Service Plus (CVE-2021-27956)

    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:

    Stored XSS Payload

    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:

    Unescaped JavaScript Tags

    After loading the search page, clicking the “More” tab triggers the vulnerability, which is shown in Figure 3:

    XSS Payload Executed
    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

    CVE Links