Horizon3.ai Breaks Down Fortinet Vulnerability

Zach Hanley, Horizon3.ai Chief Attack Engineer, and James Horseman, Exploit Developer, join John Furrier of theCUBE to discuss Fortinet CVE 2022 40864.

The post Horizon3.ai Breaks Down Fortinet Vulnerability appeared first on Horizon3.ai.

Many penetration tests are only point-in-time and/or manual. In this Horizon3.ai sponsored webcast from SANS, take a First Look at how Horizon3.ai’s NodeZero takes on the pen test problem. 

Listen to SANS Senior Instructor Dave Shackleford and Horizon3.ai’s CEO and Co-Founder Snehal Antani discuss the platform’s highlights and why it might be right for your organization.

The post SANS Webcast w/ Sponsor Horizon3.ai appeared first on Horizon3.ai.

Managed security service providers (MSSPs) and managed services providers (MSPs) tell us that in today’s cyber threat
environment, securing customer environments while still maintaining profit margins and growing adoption of their services is an ongoing challenge. The NodeZero^TM platform enables you to proactively and efficiently probe your customers’ networks for weaknesses that go beyond known and patchable vulnerabilities, such as credentials open to compromise, exposed data, misconfigurations, poor security controls, and weak policies.

The post NodeZero™ from Horizon3.ai Optimized for MSSPs and MSPs appeared first on Horizon3.ai.

State, local and education (SLED) organizations have unique cybersecurity pain points. Because they rely on taxpayer dollars, SLED organizations are often trying to do more with less.

The post SLED U.S. State, Local, & Education appeared first on Horizon3.ai.

Demand for #pentesting expertise is at an all-time high, and many orgs are struggling to meet their annual requirements for the PCI DSS v4.0. This webinar explains how our services fulfill your pentesting requirements and help you streamline your remediation efforts. You’ll learn about:

– Horizon3.ai’s human-machine teaming approach for compliance pentesting
– How we fully address requirement 11.4 of the PCI DSS and pentesting for the Self-Assessment Questionnaires (SAQs)
– A practitioner’s view of how #NodeZero helps orgs efficiently interpret and remediate their penetration test report

The post No waiting, no wondering: Streamline your PCI pentesting process with Horizon3.ai appeared first on Horizon3.ai.

See your enterprise through the eyes of an attacker – More than a concept — a Proof of Value

The post NodeZero: More than a concept — a Proof of Value appeared first on Horizon3.ai.

Horizon3.ai delivers sophisticated and timely penetration testing services tailored to fulfill the internal and external pentesting requirements of your cardholder data environment outlined by the Payment Card Industry Data Security Standard (PCI DSS) v4.0. Our offerings are executed with comprehensive coverage and meticulous attention to detail to fully address these stringent pentesting requirements.

The post Horizon3.ai PCI 11.4 Pentesting Engagement appeared first on Horizon3.ai.

Winner, Security Today Govies for Autonomous Penetration Testing

The post Security Today Govies Award appeared first on Horizon3.ai.

The NodeZero^TM platform is easy-to-use, safe for production, and scales to support your largest networks. You are empowered to test a very broad scope in a single test, orchestrate tests concurrently, and simultaneously test your enterprise from different attacker perspectives.

The post Autonomous Penetration Testing with Horizon3.ai appeared first on Horizon3.ai.

The NodeZero^TM platform empowers your organization to reduce your security risk by autonomously finding exploitable weaknesses in your network, giving you detailed guidance about how to prioritize and fix them, and helping you immediately verify that your fixes are effective.

The post NodeZero Capability Statement appeared first on Horizon3.ai.

How Autonomous Pentesting Transformed University Protection

Given the pivotal role of education in shaping future leaders and driving innovation, safeguarding the integrity and security of educational systems is paramount. The educational sector continues to be a prime target for cyber threat actors due to its vast repositories of sensitive data, ranging from student records to innovative research findings. As universities increasingly rely on digital platforms for administrative functions, online learning, and collaborative research endeavors, the volume and diversity of data stored within their systems become lucrative targets for cybercriminals. Breaches not only compromise the confidentiality of student and faculty information but also undermine the institution’s reputation and erode trust among stakeholders. Moreover, the interconnected nature of academic networks exposes them to a wide array of cyber-attacks, including phishing attempts, malware, ransomware, exploits, and data breaches, which can disrupt operations and compromise the integrity of academic activities. By prioritizing cybersecurity, educational institutions not only fulfill their duty to protect the interests of their stakeholders but also contribute to the broader goal of building a secure and resilient digital ecosystem that fosters innovation, collaboration, and learning.

About Moravian University

• Moravian University’s liberal arts education prepares each individual for a reflective life, fulfilling careers, and transformative leadership in a world of change.
• Year Founded: 1742
  (6th oldest college in America)
• Number of Staff: 372
• Operational Reach: Moravian University is a small private institution known for offering undergraduate and graduate degrees that blend a leadership focus, career development, and global experiences with liberal arts programs. Moravian University is committed to making our private education affordable to as many students as possible.

Playing by the Book

Additional to safeguarding information and networks, educational institutions are also subject to various laws and regulations governing data protection, privacy, and cybersecurity. Compliance with these requirements is not only a legal obligation but also essential for maintaining the institution’s reputation, avoiding penalties, and protecting against cyber-attacks. This may include standards such as the General Data Protection Regulation (GDPR), the Health Insurance Portability and Accountability Act (HIPAA), the Payment Card Industry Data Security Standard (PCI DSS), and various other State and Federal higher education regulatory policies and guidance. For our higher education customers, a key aspect of compliance includes conducting continuous cyber risk assessments of their environments. This not only ensures they comply with regulations, but to also find, fix and remediate potential cybersecurity vulnerabilities within their environment before cyber threat actors exploit them.

As explained by alumni and Director of Information Security at Moravian University, Jim Beers,

Compliance is one of the main driving factors behind why Moravian needed to implement solutions that identify vulnerabilities so that we can fix them quickly.

Being with Moravian for over 25 years, Jim innately understands the need for higher education institutions to implement tools to ensure compliance and see their environment as an attacker does. Like many others in Jim’s situation, implementing solutions (such as pentesting) is crucial for universities to proactively identify and address security vulnerabilities, fortifying their digital infrastructure against cyber threats and ensuring the confidentiality, integrity, and availability (CIA) of sensitive academic and personal data.

However, unlike Jim, many educational organizations often opt to do the minimum in cybersecurity compliance. Limited budgets and resources often constrain their ability to invest in robust cybersecurity measures. Additionally, often there is a lack of awareness or understanding of the evolving cyber threats and regulatory requirements at the leadership and administrative levels. The decentralized nature of many educational institutions, with numerous departments and stakeholders operating independently, can create challenges in implementing cohesive cybersecurity policies and practices. This can also result in the perception that cybersecurity is not a top priority compared to other competing demands within the institution.

What these organizations fail to realize is that a once a year traditional pentest often costs more than an autonomous solution that continuously assesses their environment. Additionally, traditional vulnerability scanners are good at identifying and describing vulnerabilities in general, but often fall short in providing actionable guidance. Jim explains, “our past vulnerability scanner told me what vulnerabilities were of high or low severity and if there is an exploit, but it didn’t tell me why…there was too much information without enough direction or actionable insights.” For an educational institution to proactively stay ahead of threats, Jim needed to look further and find a solution that not only saved him time and frustration, but also provided him with immediate results and fix actions to quickly resolve vulnerabilities before threat actors exploit them.

Enter NodeZero^TM

Jim wanted to get away from basic vulnerability scanners and adopt something that could not only meet regulatory and compliance requirements but one that could exceed them. His goal was to “move from a limited theoretical vulnerability scanner to a scanner that allows me to see more information and reports on the things that can really be exploited.” Additionally, his current vulnerability scanner was “somewhat expensive” and was limited in its scanning capability, along with its poor actionable results. Jim was also concerned that his current tools could not scan and illuminate their entire network, highlighting that “security is about visibility, and you have to know what is there to protect, and our ability to do that was limited.” As the Department of Education (DoE) continues to implement more stringent cyber policies, regulations, and guidance, pentesting is the main driver for compliance across the board. That coupled with cyber insurance requirements, Jim explains, “they [DoE and insurers] want to see that you’re identifying exploitable vulnerabilities and you’re fixing them,” and the only way to do that is through continuous assessments.

The things that you [NodeZero] are finding, we didn’t know existed.

Too new – let’s go traditional

We often hear that some of our higher education customers were hesitant to move from traditional, manual pentesting efforts to an autonomous pentesting solution like NodeZero. Some universities may be inclined to stick with traditional pentesting methods due to familiarity, comfort, and the perception of reliability. Many institutions may have established relationships with pentesting firms or internal teams that have been conducting tests using traditional methodologies for years. Additionally, there might be a lack of awareness about the limitations of traditional pentesting and the advantages of newer autonomous pentesting solutions.
However, most educational institutions that use traditional (manual) pentesting approaches tend to pentest one time to meet regulatory compliance requirements. Moravian did just that. Jim explains that before he explored solutions like Horizon3.ai’s NodeZero, they had “done one traditional pentest nearly 10 years ago, and it was a hefty sum.” Furthermore, Jim’s management thought that these emerging autonomous solutions were too new to the market, and that traditional pentesting was reliable, even if it was pricey. They implemented another traditional pentesting effort prior to choosing NodeZero. “For the amount we paid, [the pentesters] did a good job, but it was not exactly what they expected,” says Jim. The results Jim received from the traditional pentest were good, but he explained that “it was a one and done test…I have all year to fix the issues, but the environment keeps evolving and changing as we are going along…next year, how am I going to be surprised in the next pentest and during that gap, what if something goes wrong and I don’t know about it?”

Shifting to an Autonomous State of Mind

As Jim is keenly aware of the evolving cyber landscape, he decided that continuous, autonomous pentesting would not only meet compliance standards, but keep Moravian at the forefront of proactively securing their environment and keeping sensitive data safe. After their second time using traditional pentesting was somewhat unsuccessful, Jim decided it was time to give NodeZero a chance.

Right away, Jim realized that they had made the right decision, especially because NodeZero now allowed Moravian to implement unlimited testing of their environment, as well as the ability to schedule pentests at will. He also mentioned that NodeZero allows him to “check for vulnerabilities, find out how they’re exploited, and then fix it immediately…I was amazed at how easy it was…I can use the 1-click verify shopping cart to quickly verify our remediations, saving countless hours.” With NodeZero, customers can ensure fix actions were properly implemented with 1-click verify, enabling them to quickly check that remediations fixed the issues. Further, Jim explains how NodeZero PDF reports and CSV files are highly informative, allowing him “to download it all as a package, slice and dice as needed, and get them distributed to the right people.”

On top of that, Jim also noted that he liked that he “could spin up NodeZero on different parts of the network and try to get into a place that I didn’t think we could get to…testing my defenses and giving me visibility.” NodeZero doesn’t just scan your network, it looks at your network as an attacker would. Our attack paths show how an attacker weaves into a network and what they did to get domain admin, host compromise, or sensitive data exposure, for example. He was also impressed with our proactive Rapid Response capability outside of NodeZero’s interface, calling to an additional Follow, Alert, and Review (FLARE) notification he received via email from our Customer Success and Engineering teams.

“Starting about 5 years ago, we had a 6.8% response rate [to phishing campaigns] and we’re down to .22%”

Lastly, Jim mentioned that one of “the biggest risks [to Moravian] is users coughing up their credentials because they were phished.” Recently added to NodeZero, customers can now harness the Phishing Impact test that allows security professionals to integrate into their existing phishing training and awareness platforms. Jim thinks that this test will be eye opening, and help organizations shift policies and guidance to better educate staff. Jim says, “using phished credentials from the phishing test and injecting them in other pentests would be a lesson for not only the individual whose credentials were phished, but for the entire institution about how quickly something could happen.” His goal is to use the new capability to educate management and staff as to why phishing is a huge risk to their organization and what can be done to continue driving their response rate down.

My first impression was ease of use…to be able to just copy and paste a command and BAM! You’re inside attacking my network!

“Compliance drove us to trying to find a pentesting solution”

NodeZero revolutionizes the landscape for educational institutions seeking an autonomous pentesting solution, empowering a proactive strategy to illuminate how an attacker sees their environment. Additionally, NodeZero also enables institutions to comply with and exceed State and Federal higher education regulatory policies and guidance. “To sum it all up, compliance drove us in trying to find a pentesting solution, but what you had to offer [Horizon3.ai] covered not only pentesting, but vulnerability management,” says Jim. NodeZero provides universities and alike with actionable insights and prioritized recommendations for remediation, as well as the ability to verify fix actions. This enables security teams to focus their efforts on addressing the most critical vulnerabilities first.

Overall, while traditional pentesting methods may have served higher educational institutions well in the past, we have witnessed first-hand that the transition to an autonomous pentesting solution like NodeZero offers countless benefits, including enhanced efficiency, scalability, adaptability, and actionable insights, hardening the institution’s cybersecurity posture in an increasingly complex threat landscape.

Download PDF

The post Empowering Educational Compliance: Navigating the Future with Autonomous Pentesting in Academia appeared first on Horizon3.ai.

2024 Partner Program Guide

The post The Channel Co. Partner Program Guide appeared first on Horizon3.ai.

Business Wire 03/25/2024

Horizon3.ai, a pioneer in autonomous security solutions, has been honored by CRN^®, a brand of The Channel Company, with inclusion in its 2024 Partner Program Guide. This annual guide provides essential information to solution providers exploring technology vendor partner programs…

Read the entire article here

The post Horizon3.ai Garners Spot in 2024 CRN® Partner Program Guide appeared first on Horizon3.ai.

The post Elevate Your Cybersecurity Strategy: Download the 2023 Year in Review appeared first on Horizon3.ai.

Introduction

In a recent PSIRT, Fortinet acknowledged CVE-2023-48788 – a SQL injection in FortiClient EMS that can lead to remote code execution. FortiClient EMS is an endpoint management solution for enterprises that provides a central location for administering enrolled endpoints. This SQL injection vulnerability is caused by user controlled strings that are passed directly into database queries. In this post we will examine the internal workings of the exploit. Our POC can be found here.

An improper neutralization of special elements used in an SQL Command (‘SQL Injection’) vulnerability [CWE-89] in FortiClientEMS may allow an unauthenticated attacker to execute unauthorized code or commands via specifically crafted requests.

FortiClient EMS Architecture

For the purposes of understanding this vulnerability, FortiClient EMS consists the following components:

• FmcDaemon.exe – The main service responsible for communicating with enrolled clients. By default, this service listens on port 8013 for incoming client connections
• FCTDas.exe – The Data Access Server responsible for translating requests from various other server components into SQL requests. This service interacts with the Microsoft SQL Server database.
• One or more endpoint clients – These clients communicate with the FmcDaemon on the server (by default tcp/8013)

Finding the Vulnerable Component

Since we know the vulnerability is a SQL injection, our initial triage consisted of scanning the installation folder for common SQL strings.

Upon further examination, we find that FCTDas.exe has established connections to the local database over tcp/1433. We also see that it listens for incoming connections over localhost port tpc/65432.

Examining other services on this server, we find that FcmDaemon.exe makes connections to FCTDas.exe and listens externally on tcp/8013. We have a decent hunch now that we can use tcp/8013 to interact indirectly with FCTDas and make database queries.

Finding and Triggering the Vulnerability

We wanted to see what normal communications between a client and the FcmDaemon should look like. To accomplish this, we configured an installer and deployed a basic endpoint client. We found that normal communications between an endpoint client and FcmDaemon.exe are encrypted with TLS, and there didn’t seem to be an easy way to dump TLS session keys to decrypt the legitimate traffic. Luckily, after we enabled Debug logging, the FcmDaemon log provided some detail about the communications.

This was enough information to get us started with a Python script to communicate with the FcmDaemon, however, we weren’t able to get it to respond with anything besides a continuation message.

At this point, we opened FcmDaemon.exe and IDA and began reverse engineering the message format. We noticed that many of the message handling functions were making use of functionality from policyhelper.dll. Instead of reverse engineering the entire message format, we opened Windbg and set a breakpoint on policyhelper!processRequest. After some time, the client beaconed to the server and we are able to see the message buffer in rdx.

We can see that the message format is a pretty simple text based format. We have a message header with various fields each separated by a newline, a carriage return and newline separating the header from the body, and two carriage return newlines to end the body. With this information, we are able to update our Python script to meaningfully communicate with the FcmDaemon.

In the DAS log, we were able to see many SQL statements that used the FCTUID as part of the query. For example:

Based on this, we were hopeful that by simply updating the FCTUID present in many of the FcmDaemon messages, we would be able to trigger a SQL injection. We constructed a simple sleep payload of the form <fctid>' AND 1=0; WAITFOR DELAY '00:00:10' -- '. We noticed the 10 second delay in response and knew that we had triggered the exploit!

From SQL Injection to RCE

To turn this SQL injection vulnerability into remote code execution we used the built-in xp_cmdshell functionality of Microsoft SQL Server. Initially, the database was not configured to run the xp_cmdshell command, however it was trivially enabled with a few other SQL statements. The POC we are releasing only confirms the vulnerability by using a simple SQL injection without xp_cmdshell. To enable RCE, altering the POC is necessary.

Indicators of Compromise

There are various log files in C:\Program Files (x86)\Fortinet\FortiClientEMS\logs that can be examined for connections from unrecognized clients or other malicious activity. The MS SQL logs can also be examined for evidence of xp_cmdshell being utilized to obtain command execution.

Its important to realize that an attacker may have used different techniques to gain execution or may have cleaned evidence from logs after exploitation.

NodeZero

NodeZero Attack Path utilizing CVE-2023-48788 to load a remote access tool and dump LSASS 

Horizon3.ai clients and free-trial users alike can run a NodeZero operation to determine the exposure and exploitability of this issue.

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

 

The post CVE-2023-48788: Fortinet FortiClient EMS SQL Injection Deep Dive appeared first on Horizon3.ai.

Early in 2023, soon after reproducing a remote code execution vulnerability for the Fortinet FortiNAC, I was on the hunt for a set of new research targets. Fortinet seemed like a decent place to start given the variety of lesser-known security appliances I had noticed while searching for the FortiNAC firmware. The first target I landed on was the Fortinet Wireless LAN Manager (WLM). The security audit of this appliance began what became the successful, but failed journey of what I dubbed the “Forti Forty” – a goal to find 40 CVE’s in Fortinet appliances. The journey ended in 16 mostly critical and high security issues identified across the FortiWLM, FortiSIEM, and another appliance before it was cut short when Fortinet’s download portal no longer provided access to download their appliances.

This blog details several of the issues discovered in the FortiWLM that have since been patched:

1. CVE-2023-34993 – Multiple Unauthenticated Command Injections – PSIRT-23-140
2. CVE-2023-34991 – Unauthenticated SQL Injection – PSIRT-23-142
3. CVE-2023-42783 – Unauthenticated Arbitrary File Read – PSIRT-23-143
4. CVE-2023-48782 – Authenticated Command Injection – PSIRT-23-450

Additionally two vulnerabilities that have not received patches leading to appliance compromise:

1. Unauthenticated Limited Log File Read – Allows retrieval of arbitrary log files which contain administrator session ID tokens
2. Static Session ID Vulnerability – Session IDs do not change between sessions for users. Chained with the above issue allows trivial compromise of the device.

Fortinet Wireless LAN Manager Overview

Fortinet’s Wireless LAN Manager allows for ease of management of wireless devices throughout an enterprise. It remotely monitors the devices health, performance, and any RF interference all in a single pane of glass. It’s commonly deployed in large campus settings like universities, hospitals, and other large office footprints – making it a valuable target of interest in today’s threat landscape.

Figure 1. FortiWLM Dashboard

FortiWLM Web Framework and Middleware

The FortiWLM web services are built atop the Apache2 and Django frameworks. The Apache configuration has defined several rewrite rules from the frontend on tcp/443 and passes them back to the Django framework middleware which listens on localhost tcp/8000.

The core of the Django middleware logic lies within the /opt/meru/etc/ws/wlmweb directory. Inspecting the file /opt/meru/etc/ws/wlmweb/wlmweb/wlmrbac.py, within the process_view() function, we see that several endpoints depending on the request path are validated against the current requests session authentication information.

On line 86, the two endpoints are explicitly allowed for any request without any authentication checks:

1. /ems/cgi-bin/ezrf_upgrade_images.cgi
2. /ems/cgi-bin/ezrf_lighttpd.cgi

Figure 2. wlmrbac.py authentication checks

Path to Remote Code Execution #1

CVE-2023-34993: Fortinet FortiWLM Unauthenticated Command Injection Vulnerability

This vulnerability allows remote, unauthenticated attackers to inject a crafted malicious string in a request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint that will be executed in the context of root. The issue results from the lack of proper validation of results and calls to the potentially dangerous function system(). 

The first endpoint explicitly allowed without authentication, /ems/cgi-bin/ezrf_upgrade_images.cgi, can be found at /opt/meru/etc/ws/cgi-bin/ezrf_upgrade_images.cgi. All CGI endpoints are Perl scripts which, depending on the endpoint, parse different request parameters which are sometimes validated, but sometimes not. 

This ezrf_upgrade_image.cgi endpoint parses the op_type request parameter, and depending on the value, passes control to different defined functions within the script.

Figure 3. ezrf_upgrade_images.cgi operation types

The deleteprogressfile() function extracts the progressfile request parameter and then directly passes it to a call to system() without any input validation.

Figure 4. ezrf_upgrade_images.cgi’s vulnerable deleteprogressfile()

Sending a request to this unauthenticated endpoint with op_type=deleteprogressfile and a  malicious string in the progressfile parameter results in remote code execution in the context of the root user.

Figure 5. Unauthenticated RCE as root via ezrf_ugprade_image.cgi endpoint

Path to Remote Code Execution #2

CVE-2024-???? (0-day): Fortinet FortiWLM Unauthenticated Limited File Read Vulnerability

This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to read specific log files on the system via a crafted request to the /ems/cgi-bin/ezrf_lighttpd.cgi endpoint. This issue results from the lack of input validation on request parameters allowing an attacker to traverse directories and read any log file on the system.

The second endpoint explicitly allowed without authentication, /ems/cgi-bin/ezrf_lighttpd.cgi, can be found at /opt/meru/etc/ws/cgi-bin/ezrf_lighttpd.cgi. Again, this CGI endpoint is a Perl script in which different request parameters are not always validated.

When the op_type is upgradelogs, control is passed to the upgradelogs() function. This function will read the specific log file from the system and return its content in the response.

Figure 6. ezrf_lighttpd.cgi upgradelogs() function

Inspecting how the $filename variable is constructed we see that it is partially controlled by the imagename request parameter.

Figure 7. ezrf_lighttpd.cgi attacker controlled input unvalidated

Abusing the lack of input validation, an attacker can construct a request where the imagename parameter contains a path traversal, allowing the attacker to read any log file on the system.

Luckily for an attacker, the FortiWLM has very verbose logs – and logs the session ID of all authenticated users. Abusing the above arbitrary log file read, an attacker can now obtain the session ID of a user and login and also abuse authenticated endpoints.

Figure 8. Leak Session ID with Unauthenticated Arbitrary Log File Read

CVE-2023-48782: Fortinet FortiWLM Authenticated Command Injection Vulnerability

This vulnerability allows remote, authenticated attackers to inject a crafted malicious string in a request to the /ems/cgi-bin/ezrf_switches.cgi endpoint that will be executed in the context of root. The issue results from the lack of proper validation of results and insecure use of the dangerous system calls. This endpoint is accessible for both low privilege users and admins.

The ezrf_switches.cgi endpoint supports several op_type subfunctions related to adding a LAN switch for monitoring. This CGI script can be found at /opt/meru/etc/ws/cgi-bin/ezrf_switches.cgi.

The updateStatus() helper function, called in two different op_type functions, is vulnerable to command injection of both the $switche_table_k_Hostname and $switche_table_k_CommunityString variables which are derived from user input.

Figure 9. ezrf_switches.cgi vulnerable updateStatus()

Both addSwitche() and editSwitche() functions call the vulnerable updateStatus() helper function without validating any input. 

Figure 10. ezrf_switches.cgi addSwitche() calls updateStatus()

Tracing those variables to where they are declared, they are derived straight from the request parameters Hostname and CommunityString, and are never validated along the way.

Figure 11. ezrf_switches.cgi request parameters unvalidated

Combining both the unauthenticated arbitrary log file read and this authenticated command injection, an unauthenticated attacker can obtain remote code execution in the context of root.

Figure 12. Abusing Unauth Log Read and Auth Command Injection to obtain root RCE

Other Security Issues

The initial report to Fortinet contained a total of 9 specific security issues, largely concentrated on the unauthenticated endpoints discovered in the Django middleware. The authenticated attack surface is large, and at the time contained numerous issues that were similar in nature to the ones detailed here stemming from a lack of input validation. Two additional security issues of note reported and patched, but unused in the attack paths were:

CVE-2023-42783: Fortinet FortiWLM Unauthenticated Arbitrary File Read Vulnerability

This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to read specific log files on the system via a crafted request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint in the uploadstatus function with the progressfile parameter. This issue results from the lack of input validation on request parameters allowing an attacker to traverse directories and read any file on the system.

CVE-2023-34991: Fortinet FortiWLM Unauthenticated SQL Injection Vulnerability

This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to list images on the system via a crafted request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint in the editimage function with the imageName and description parameters. This issue results from the lack of input validation on request parameters allowing an attacker to modify a SQL query string.

CVE-2024-???? (0-day): Fortinet FortiWLM Static Session ID Vulnerability

The web session ID token of authenticated users remains static, and unchanged, for users between sessions. Each time a user logs in, they receive the exact same session ID token. This token remains static for each boot of the device. An attacker that can obtain this token can abuse this behavior to hijack sessions and perform administrative actions. This session ID is retrievable with the unpatch limited log file read vulnerability above and can be user to gain administrative permissions to the appliance.

Internet Exposure

While we found it to be popular with State, Local, and Education (SLED) and healthcare focused customers, luckily the internet exposure is fairly limited to around 15 instances.

Figure 13. Shodan Exposure

Indicators of Compromise

The FortiWLM logs the majority of its application activities in the /data/apps/nms/logs directory. Specifically activity related to the exploitation these issues can be observed in the /data/apps/nms/logs/httpd_error_log.log file. Example entries of the log file included below show the exploitation of the unauthenticated remote code execution vulnerability, CVE-2023-34993. If defenders suspect that an appliance has been compromised, the logged request parameters should be analyzed to determine if they appear malicious.

Figure 14. httpd_error_log.log example entry

Timeline

12 May 2023 – Submitted report to Fortinet PSIRT

15 May 2023 – PSIRT acknowledges receipt

10 July 2023 – PSIRT reproduces issues and indicates fix is in-progress

10 August 2023 – Ask for update, PSIRT responds fix is awaiting release

11 October 2023 – PSIRT releases fixes for 2 reported issues

14 November 2023 – PSIRT releases fixes for 2 more reported issues

21 November 2023 – Indicate to PSIRT of intent to publicly disclose all issues

22 November 2023 – PSIRT indicates remaining 3 vulnerabilities will be patched soon

7 December 2023 – PSIRT releases 1 fix for more reported issues

23 February 2024 – RingZer0 conference talk discussing some of these vulnerabilities

14 March 2024 – This public disclosure after 307 days with two unpatched vulnerabilities

The post Fortinet FortiWLM Deep-Dive, IOCs, and the Almost Story of the “Forti Forty” appeared first on Horizon3.ai.

You can now fully assess the impact of phished credentials on your organization. Tune into this webinar to watch the NodeZero platform evaluating the blast radius of every phished credential as it comes in using the Phishing Impact test.

The post What’s the true impact on your organization when an employee is phished? appeared first on Horizon3.ai.

With the advent of generative AI, AI chatbots are everywhere. While users can chat with large-langage models (LLMs) using a SaaS provider like OpenAI, there are lots of standalone chatbot applications available for users to deploy and use too. These standalone applications generally offer a richer user interface than OpenAI, additional features such as the ability to plug in and test different models, and the ability to potentially bypass IP block restrictions.

From our research, the most widely deployed standalone Gen AI chatbot is NextChat, a.k.a ChatGPT-Next-Web. This is a GitHub project with 63K+ stars and 52K+ forks. The Shodan query  title:NextChat,"ChatGPT Next Web" pulls up 7500+ exposed instances, mostly in China and the US.

This application is vulnerable to a critical full-read server-side request forgery (SSRF) vulnerability, CVE-2023-49785, that we disclosed to the vendor in November 2023. As of this writing, there is no patch for the vulnerability, and since 90+ days has passed since our original disclosure, we are now releasing full details here.

CVE-2023-49785: A Super SSRF

NextChat is a Next.js-based Javascript application, and most of its functionality is implemented as client-side code.

There are, however, a few exposed server endpoints. One of these endpoints is at /api/cors, and it functions by design as an open proxy, allowing unauthenticated users to send arbitrary HTTP requests through it. This endpoint appears to have been added to support saving client-side chat data to WebDAV servers. The presence of this endpoint is an anti-pattern: it allows clients to bypass built in browser protections for accessing cross-domain resources by accessing them through a server-side endpoint instead.

For instance to access Google through this proxy, one can make the following request:

SSRF vulnerabilities vary considerably in terms of real-world impact. This particular SSRF is about as bad as it gets. It’s dangerous because:

• It enables access to arbitrary HTTP endpoints, including any internal endpoints
• It returns the full response from any accessed HTTP endpoints
• It supports arbitrary HTTP methods such as POST, PUT, etc by setting the method header. Request bodies are also passed along.
• URL query parameters can be passed along with URL encoding.
• It supports passing along an Authorization header in requests.

If this application is exposed on the Internet, an attacker essentially has full access to any other HTTP resources accessible in the same internal network as the application. The only limitation is passing along other headers such as Cookie or Content-Type, though there may be creative ways to inject these headers.

Here’s an example of accessing the AWS cloud metadata service to retrieve AWS access keys off an AWS EC2 instance running with IMDSv1 enabled:

sh-3.2# curl http://54.145.48.76:3000/api/cors/http/169.254.169.254/latest/meta-data/iam/security-credentials/REDACTED
{
  "Code" : "Success",
  "LastUpdated" : "2024-03-08T00:22:17Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA-REDACTED",
  "SecretAccessKey" : "C2CW-REDACTED",
  "Token" : "IQoJb3JpZ2luX2VjENH-REDACTED",
  "Expiration" : "2024-03-08T06:58:15Z"
}

Reflected XSS

Almost all reflected XSS vulnerabilities are of little value to attackers. But we thought it was interesting to note that this vulnerability can be used to directly trigger an XSS without loading another site. This is because the fetch method used by the /api/cors endpoint also supports the data protocol.

For instance, the following payload:

data:text%2fhtml;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pPC9zY3JpcHQ+%23

will be decoded to <script>alert(document.domain)</script> at the server and sent back to the client, resulting in XSS:

Mitigations

Our assessment of this vulnerability puts the CVE base score at 9.1 (critical). The vulnerability not only enables read access to internal HTTP endpoints but also write access using HTTP POST, PUT, and other methods. Attackers can also use this vulnerability to mask their source IP by forwarding malicious traffic intended for other Internet targets through these open proxies.

As of this writing, there is no patch for the vulnerability. More than 90 days has passed since our original contact.

• Nov. 25, 2023: Horizon3 reports security issue to ChatGPT-Next-Web via GitHub vulnerability disclosure process
• Nov. 26, 2023: Vendor accepts the report
• Dec. 6, 2023: GitHub CNA reserves CVE-2023-49785
• Jan. 15, 2024: Horizon3 asks vendor for an update using the GitHub security issue. No response.
• Mar. 7, 2024: Horizon3 asks vendor for an update using the GitHub security issue. No response.
• Mar. 11, 2024: Public disclosure

We recommend that users not expose this application on the Internet. If it must be exposed to the Internet, ensure it is an isolated network with no access to any other internal resources. Beware that attackers can still use the application as an open proxy to disguise malicious traffic to other targets through it.

Detection

The following nuclei template can be used to detect this vulnerability. The vulnerable code was introduced in Sept. 2023. The majority of instances online, including any instances using the more recent “NextChat” name, are highly likely to be vulnerable.

id: CVE-2023-49785

info:
  name: CVE-2023-49785
  author: nvn1729
  severity: critical
  description: Full-Read SSRF/XSS in NextChat, aka ChatGPT-Next-Web
  remediation: |
    Do not expose to the Internet
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
    cvss-score: 9.1
    cve-id: CVE-2023-49785
  tags: cve-2023-49785,ssrf,xss

http:
  - method: GET
    path:
      - "{{BaseURL}}/api/cors/data:text%2fhtml;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pPC9zY3JpcHQ+%23"
      - "{{BaseURL}}/api/cors/http:%2f%2fnextchat.{{interactsh-url}}%23"

    matchers-condition: and
    matchers:
      - type: word
        part: interactsh_protocol # Confirms the DNS interaction from second request
        words:
          - "dns"
      
      - type: dsl
        dsl:
          - 'contains(body_1, "<script>alert(document.domain)</script>") && contains(header_1, "text/html")' # XSS validation in first request
          - 'contains(header_2, "X-Interactsh-Version")' # Or got HTTP response back from Interact server

Conclusion

Over the last two years, we have observed the rapid pace of development of new generative AI applications, and there is a big appetite to use and experiment with these applications. We’ve also observed a steady blurring of lines between personal use and corporate use. While NextChat is primarily meant for personal use, we’ve seen it in a few of our own client environments.

Security has simply not kept up, both AppSec practices and vulnerability disclosure processes. The focus of the infosec community and media at large has been on “security harms” like prompt injection or model poisoning, but there are lots of high impact, conventional vulnerabilities to be found. We recommend users exercise caution when exposing any unvetted Gen AI tools to the Internet.

References

• NextChat, a.k.a ChatGPT-Next-Web

The post NextChat: An AI Chatbot That Lets You Talk to Anyone You Want To appeared first on Horizon3.ai.

On February 27, 2024, Progress released a security advisory for OpenEdge, their application development and deployment platform suite. The advisory details that there exists an authentication bypass vulnerability which effects certain components of the OpenEdge platform. Our proof of concept can be found here.

When the OpenEdge Authentication Gateway (OEAG) is configured with an OpenEdge Domain that uses the OS local authentication provider to grant user-id and password logins on operating platforms supported by active releases of OpenEdge, a vulnerability in the authentication routines may lead to unauthorized access on attempted logins.

Similarly, when an AdminServer connection is made by OpenEdge Explorer (OEE) and OpenEdge Management (OEM), it also utilizes the OS local authentication provider on supported platforms to grant user-id and password logins that may also lead to unauthorized login access.

OpenEdge Architecture

The OpenEdge platform has several different components that can be deployed across an environment:

1. OpenEdge Management (an enterprise version of OpenEdge Explorer)
2. OpenEdge Enterprise RDBMS
3. OpenEdge Replication
4. OpenEdge Authentication Gateway (OEAG)
5. Progress Application Server (PAS) for OpenEdge
6. Progress Develop Studio (PDS) for OpenEdge

Typically the OpenEdge Management, OpenEdge Enterprise RDBMS, and PAS roles are deployed on a system and act as the backend, central source of information for developers using PDS as clients to develop applications. If an the Authentication Gateway is in use, it centrally manages authentication across the OpenEdge ecosystem.

Figure 1. Example OpenEdge Deployment

Finding The Vulnerable Component

In this case, we were unable to obtain a patched system to perform patch diffing, but there are quite a few interesting details that can be picked from the advisory. The advisory states: “The AdminServer logins are always potentially vulnerable because they only support OS local logins”. Additionally the temporary mitigations specify:

The following mitigation options are intended for short-term use until you can apply the provided OpenEdge Update to your deployments. The revised “auth.dll” library associated with the OS you’re using should be copied into $DLC/bin to replace the vulnerable version of the “auth.dll” library that existed in LTS Updates 11.7.18, 12.2.13 or 12.8.0.

Given this information, we install OpenEdge Manager, RDBMS, and PAS on a single Windows server and inspect the installed services with TaskManager and find that these roles will start the vulnerable “AdminServer” service referenced in the advisory.

Figure 2. AdminServer service running

Now that we have the vulnerable component running – an often overlooked part of reversing is spending hours reading documentation, we find documentation on the AdminServer service and what its used for. The documentation states that its a Java RMI service listening by default on tcp/20931 and references several command line utilities to communicate with the service:

• This is the RMI port used by command line utilities: proadsv, asbman, wtbman, nsman, restman, and pre OpenEdge 12.0 fathom cmd line tooling
• The default listening port for the AdminServer (-port) remains 20931 for all versions.

Inspecting our listening connections on the Windows server, we find that the AdminServer is indeed listening on tcp/20931.

Figure 3. AdminServer service listening

Inspecting the command use to kick off the Java process we find it’s loading several Progress JARs and calling com.progress.chimera.adminserver.AdminServerStarter.

Figure 4. AdminServer command line

Reversing the AdminServer Service

We find that the com.progress.chimera.adminserver.AdminServerStarter class is defined in C:\Progress\OpenEdge\java\progress.jar. Inspecting the class, we find that when a remote connection is made the connect() method is called and expects a user supplied username and password.

Figure 5. AdminServer connect()

The connect() method interestingly loads a native system library, auth.dll, and eventually calls the authorizeUser() method defined in it. Replacing auth.dll was mentioned in the temporary mitigations so we’re likely on the right track.

Figure 6. Loading auth.dll

Opening up auth.dll in Ghidra, we find that it exports several functions to be available as Java interfaces, one of which is our authorizeUser() function.

Figure 7. Java Interfaces from auth.dll

The authorizeUser() function performs some basic input validation, ensures the supplied credentials meet certain criteria, and passes control to a function we named vulnerable_checks() (defined at 0x1800051a0). This function does further validation, but getting right into the meat of the vulnerability we see that on line 262 the user supplied AccountName (username) is compared the NT AUTHORITY/SYSTEM. If it matches, you are authenticated.

Figure 8. If username == “NT AUTHORITY/SYSTEM”: you may pass

Thats the vulnerability.

Figure 9. Its a feature

Impact

While we’ve bypassed authentication, finding attack surface to abuse to drive some impact like remote code execution was the next goal.

Deserialization

Java Remote Method Invocation (RMI) interfaces typically suffer from deserialization vulnerabilities, but in this case there were no classic libraries in the class path of the service to easily abuse with a ysoserial gadget. We did confirm that deserialization is possible with a simple out-of-band DNS request payload, but did not spend the time to develop a custom gadget with the in scope libraries. Remote code execution is likely possible with this avenue.

Abuse of Built In Functionality

We spent the better part of a day looking for easily abusable functionality within the available RMI interfaces. Easily reachable functionality allows a user to start, stop, and list performance metrics of applications. Deeper attacker surface looks like it may allow a user to deploy new applications via remote WAR file references, but the complexity increased dramatically in order to reach this attack surface because of the use of internal service message brokers and custom messages. We believe there is again likely an avenue to remote code execution via built in functionality given enough research effort.

Creating a Proof of Concept

We continue our investigation by re-examining the AdminServer class and dbman.bat which makes use of the AdminServer. We find that we can connect to the AdminServer over RMI at rmi://<target_ip>:29031/Chimera. We get back an IAdminServerConnection which exposes two connect methods that require a username and password. With our knowledge from dbman.bat we know we need to encode the username and password using an Encoder from oeauth-12.8.0.jar.

Now that we are connected to the AdminServer, what can we do? We can use the following code to display all interfaces available to us from the AdminServer‘s getPlugins method:

We get the following output:

com.progress.system.SystemPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.system.ISystemPlugIn

com.progress.agent.database.AgentPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.agent.database.IAgentPlugIn
com.progress.ubroker.tools.NSRemoteObject
com.progress.chimera.common.IChimeraHierarchy
com.progress.ubroker.tools.IYodaRMI
com.progress.ubroker.tools.IYodaSharedResources
com.progress.ubroker.tools.UBRemoteCommand
com.progress.chimera.common.IChimeraRemoteCommand
com.progress.juniper.admin.JAPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.juniper.admin.IJAPlugIn
com.progress.agent.smdatabase.SMPlugIn
com.progress.chimera.common.IChimeraRemoteObject

From here, we leave it as an exercise to the reader to figure out what you can do with the above interfaces. Our proof of concept can be found here.

NOTE: We will not be distributing the Progress JARs given we do not own that code. These JARs can be obtained from an OpenEdge installation and are required to run the proof of concept.

Indicators of Compromise

When a connection is made to the AdminServer service, logs are generated at C:\OpenEdge\WRK\admserv. An example log entry can be seen below where it records the user authenticating as well as the Java interfaces that user is accessing, the UBRemoteCommand class in our case. While it seems that accessing this service via the NT AUTHORITY/SERVICE account was intended, we did not observe log entries associated to this account outside of service startup. We also were not running a production server where more service traffic may be generated and observed.

The post CVE-2024-1403: Progress OpenEdge Authentication Bypass Deep-Dive appeared first on Horizon3.ai.

Business Wire 03/05/2024

Horizon3.ai, a pioneer in autonomous security solutions, today announced the availability of the Horizon3.ai Pentesting Services for Compliance. Horizon3.ai recognizes that demand for pentesting expertise is at an all-time high…

Read the entire article here

The post Horizon3.ai Unveils Pentesting Services for Compliance Ahead of PCI DSS v4.0 Rollout appeared first on Horizon3.ai.

You can now fully assess the impact of phished credentials on your organization. Tune into this webinar to watch the NodeZero platform evaluating the blast radius of every phished credential as it comes in using the Phishing Impact test.

The post What’s the true impact on your organization when an employee is phished? appeared first on Horizon3.ai.

Introduction

On February 19, 2023, ConnectWise published a security advisory for their ScreenConnect remote management tool. In the advisory, they describe two vulnerabilities, an authentication bypass with CVSS 10.0 and a path traversal with CVSS 8.4 (both currently without assigned CVE IDs). In this post we will dive into the technical details of the authentication bypass. You can view our POC here.

Update: On February 21, 2023, the authentication bypass vulnerability was assigned as CVE-2024-1709 and added to CISA’s Known Exploited Vulnerability (KEV) catalog.

Patch Diffing

Comparing versions 23.9.7.8804 and 23.9.8.8811, we find a small update to SetupWizard.aspx. We see that a check was added to make sure that the initial application setup has not been completed if a user it trying to access the SetupWizard. The SetupWizard is responsible for creating an initial user and password, so it makes sense that this page should be locked down after an initial user has been created.

Figure 1. SetupWizard.aspx

The Vulnerability

There is a HTTP request filter in SetupModule.cs that has two responsibilities:

• If the application hasn’t been setup, redirect all requests to SetupWizard.aspx
• If the application has been setup, deny any requests to SetupWizard.aspx or redirect to Administration.aspx

Figure 2. SetupModule.cs OnBeginRequest

However, there is an issue with how this code checks if the request URL is SetupPage.aspx. The use of string.Equals checks for exact equality, so a URL like <app_url>/SetupWizard.aspx will match. However, there are other URLs that resolve to SetupWizard.aspx that don’t match. If we simply add a forward slash to the end of the URL (<app_url>/SetupWizard.aspx/) we get access to the setup wizard, even after the application is already setup.

Figure 3. SetupWizard.aspx

We can observe the differences in responses using Burp Suite. Notice the request path /SetupWizard.aspx responds with a 302, but the malicious path /SetupWizard.aspx/ responds with a 200.

 

Indicators of Compromise

The application’s Admin -> Audit page displays a list of recent login attempts along with the IP address. You can check this page for any unrecognized users or IP addresses.

Figure 4. Audit Logs

As soon as we had sufficient information, we shared it with GreyNoise for which they developed a tag. Check out their tag here: https://viz.greynoise.io/tags/connectwise-screenconnect-auth-bypass-rce-attempt?days=1

Summary

This vulnerability allows an attacker to create their own administrative user on the ScreenConnect server, giving them full control over the server. This vulnerability follows a theme of other recent vulnerabilities that allow attackers to reinitialize applications or create initial users after setup. See our recent writeup for a CVE-2024-0204 as an example.

Unfortunately, this vulnerability has not yet been assigned a CVE. Users of ConnectWise ScreenConnect should patch immediately to prevent attackers from leveraging this vulnerability.

NodeZero

Horizon3.ai clients and free-trial users alike can run a NodeZero operation to determine the exposure and exploitability of this issue.

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

 

Figure 5. NodeZero Attack Path to Exploitation

Figure 6. Proof of Accessing the SetupWizard.aspx page

The post ConnectWise ScreenConnect: Authentication Bypass Deep Dive appeared first on Horizon3.ai.

Horizon3.ai introduces a groundbreaking test type in its NodeZero^TM platform: the Phishing Impact test. It delivers tangible insights into the potential consequences of phishing attacks on your organization’s infrastructure.

The post Introducing the NodeZero Phishing Impact Test appeared first on Horizon3.ai.

Business Wire 02/07/2024

Horizon3.ai, a pioneer in autonomous security solutions, today announced the launch of its first-to-market Phishing Impact test capability within NodeZero™. This new capability marks a significant…

Read the entire article here

The post Horizon3.ai Unveils Phishing Impact Testing to Help Organizations Understand the Impact of Phished Credentials appeared first on Horizon3.ai.

“Who cares that the intern was phished during our phishing campaign? It’s an intern, they don’t have access to anything important.”

As a security practitioner, that mindset among business leaders drove me nuts. There are many ways a credential as innocuous as an intern’s could be used by an attacker to compromise a domain or gain access to sensitive data, but it was very difficult to articulate the “blast radius” of a phished credential.

That’s why I’m really excited to launch the new Phishing test type within NodeZero…

The NodeZero Phishing Impact test is first-to-market and gives you the ammunition required to drive meaningful improvements to the credential attack surface of your organization.

“Actually boss, the intern’s credentials enabled the attacker—NodeZero—to gain access to our sensitive financial data. Take a look for yourself…”

Why is understanding the blast radius of a phished credential important? Here’s a real-world example of how a phished credential led to a domain admin compromise…

Setup:

1. A phishing campaign was configured and executed using KnowBe4.
2. A few lines of javascript were added to the fake KnowBe4 page to safely channel phished credentials into a running NodeZero internal pentest.
3. As phished credentials started flowing into NodeZero, NodeZero used them as part of its attack.

Attack path:

1. NodeZero uses the phished credential to successfully exploit PrintNightmare on Host1. PrintNightmare (CVE-2021-34527) is a remote code execution vulnerability in the Windows Print Spooler service that allows an attacker to run arbitrary code with system privileges. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
2. With those system privileges, NodeZero successfully drops a remote access tool (RAT) on the compromised host, which allows it to access sensitive processes like Security Account Manager (SAM), LSA, etc. A properly configured EDR like CrowdStrike, SentinelOne, or Fortinet is supposed to prevent the RAT from successfully deploying, but it’s easy to misconfigure these tools.
3. With the RAT successfully deployed, NodeZero then dumps SAM and harvests several user-ids and their corresponding NTLM hashes. SAM is a database that is present on Windows machines that stores user accounts and security descriptors for users on that machine.
4. The compromised credential has both local admin privileges on the host and has domain admin privileges within the domain. This means the attacker (NodeZero) now has the keys to the kingdom.

tl;dr PrintNightmare is the CVE that enabled the attack path. An attacker requires a valid domain user credential in order to exploit Printnightmare. In this case, the attacker – NodeZero – successfully obtained that valid domain user credential via the phishing integration.

In addition, the customer had to investigate why their EDR did not successfully stop the deployment of the RAT on the compromised host, which provided the second critical step in the journey to domain admin compromise.

The post Gone Phishing: How an Intern’s Credentials can be a Gateway to Your Crown Jewels appeared first on Horizon3.ai.

On January 19, 2024, Microsoft disclosed a major security incident in which the email of Microsoft senior executives and other staff were accessed by Midnight Blizzard a.k.a Cozy Bear, a nation-state threat actor affiliated with Russia. Microsoft determined that the actor got initial access using password spray to compromise a legacy non-production test tenant account in Microsoft Entra ID (formerly Azure AD). The actor then moved laterally using the excessive permissions granted to that test account to access the email of Microsoft employees.

Password spray is a surprisingly simple and effective technique we’ve written about before. In a password spray attack, an attacker tries to login to a lot of accounts using a few probable passwords, with the hope that at least one account is using a weak password.

In this real-world external pentest, we’ll show NodeZero conducting a password spray attack against Microsoft Entra ID to get initial access to a client’s tenant account, similar to what Midnight Blizzard did. From there NodeZero detects that multi-factor authentication is disabled and breaks into the email of the compromised user.

A Real World Example

In this example, a client conducted an external pentest using NodeZero. NodeZero ran from Horizon3.ai’s cloud environment and was not provided any credentials.

Configuring an External Pentest for Password Spray

When defining the assets in scope for this pentest, the client provided NodeZero a list of company-owned domains. NodeZero uses these domains to enumerate Azure tenants that belong to the client.

In the Attack Configuration for the pentest, the MS Entra (Azure AD) Password Spray flag was also enabled. This is on by default.

To avoid locking out accounts, NodeZero only attempts three passwords an hour. A duration of time can be set for how long the pentest runs, in order to get in more password spray attempts.

Attack Path

Here are the steps NodeZero took in this test to get to business email compromise:

1. NodeZero used the provided domains to discover a Microsoft Entra tenant associated with the client.
2. NodeZero used open source intelligence (OSINT) to discover potential usernames associated with the client.
3. NodeZero verified which users are actual users belonging to the client’s tenant.
4. NodeZero sprayed a highly probable password against all verified users. One of the users hit!
5. NodeZero then discovered that MFA was disabled for the user. NodeZero logged into the user’s account and acquired an Azure access and refresh token.
6. NodeZero then accessed the user’s Microsoft365 inbox.

The full attack path is shown below:

Takeaways

It took NodeZero less than 10 minutes to execute this attack path leading to business email compromise, starting with no privileges in the form of credentials or network access. This attack was performed autonomously with no human assistance or prior scripting.

The impact of business email compromise is huge. Not only can attackers access potentially sensitive data, they can use the compromised account to conduct lateral phishing attacks and further escalate privileges.

Microsoft has been rolling out MFA for all its tenants, but in practice we’ve seen that there have been gaps in this rollout, just as Microsoft experienced with its own legacy test tenant. The application of MFA also depends on how the tenant is configured. Use NodeZero to verify your true security posture!

 

The post NodeZero APT: Azure Password Spray Leads to Business Email Compromise appeared first on Horizon3.ai.

Introduction

Memory safety issues have plagued the software industry for decades. The Cybersecurity & Infrastructure Security Agency (CISA) has been leading a charge for secure-by-design and encouraging developers and vendors to utilize memory safe languages like Rust to eradicate this vulnerability class. 

Google Chromium, the engine used by the majority of browsers around the world, reports that approximately 70% of their high severity issues are memory safety issues. Microsoft reports the same percent of issues affecting it’s Windows OS are also memory safety. But, what vulnerabilities are being exploited by threat actors today? CISA maintains and publishes its Known Exploited Vulnerability (KEV) catalog of all vulnerabilities that they have insight into having been exploited by threat actors. 

We have analyzed all critical vulnerabilities from the CISA KEV catalog starting from January 2023 through January 2024, categorized the vulnerability root causes, and attempted to analyze if the current efforts in the information security industry match with the current threat vectors being abused.

Executive Overview

1. Insecure Exposed Functions Lead the CISA KEV

Nearly half of vulnerabilities are enabled by insecure exposed functions. At a strategic level we’ve seen recent pushes for security improvements by pursuing memory safe languages and software bill of materials (SBOM), but a seemingly asymmetric amount of effort or strategy around addressing this vulnerability category.

Figure 1. Vulnerabilities by Root Cause

Vulnerabilities fall into this category when:

• It is not apparent that the developer made any effort to prevent an unauthenticated user from reaching dangerous code
• Often, the exposed dangerous code allows authorization bypass or remote code execution via insecure usage of command execution libraries, unrestricted deserialization, or file operations.

2. Rust Won’t Save Us, But It Will Help Us

Memory safety issues were the second (tied) leading cause of vulnerabilities in the data set, coming in at 20%. Interestingly, 75% of the analyzed memory safety vulnerabilities have been exploited as 0-days by threat actors. Additionally, 25% were discovered by security researchers and retroactively discovered to have been exploited as 0-days. When vulnerabilities are exploited as 0-days they typically have a much more widespread effect on the world given that patches often lag by weeks once they are discovered.

Figure 2. Vulnerabilities due to Memory Corruption

3. Web Routing and Path Abuse Tied for Second

Nearly 20% of vulnerabilities in Figure 1 are the result of routing and path abuse in web applications. These vulnerabilities typically manifest in the “glue” between web frameworks when a developer attempts to route application traffic from one service to another.

Vulnerabilities fall into this category when:

• The developer has made an apparent effort to prevent an unauthenticated user from reaching dangerous code. Developer mistakes include reverse proxy regex issues, framework filter issues, path normalization issues, and internal application path inspection issues.
• Similarly, once this code is reached, developers have abandoned defense-in-depth and secure coding practices which allow abuse of insecure functions.

4. Threat Actors Love Exploiting Appliances

This isn’t a new trend, but its clear from the analysis that they are the target of choice coming in at 49%. They’re commonly found on network boundaries and exposed to the internet. They also have low defender visibility – no PSP’s installed and sparse logging.

Figure 3. Vulnerability by Software Type

For the purpose of this analysis, appliances are any product or software that is commonly deployed as a hardware appliance or as a virtual appliance.

Technical Breakdown

There are 212 vulnerabilities that have been added to the CISA KEV catalog since the start of 2023. Of that, only 41 vulnerabilities are rated critical. Below is a snapshot of those 41 vulnerabilities and the root cause leading to the vulnerability being exploitable.

CVE-2023-34362: Progress MOVEit Transfer

Category: Routing / Path Abuse

Reference: Horizon3.ai

The application exposed an endpoint, /moveitisapi/moveitisapi?action=m2, that attempted to limit functionality to just localhost, but had a header parsing bug leading to any function being reachable.

Figure 4. Header Bypass to Invoke Arbitrary Function

CVE-2023-20887: VMware Aria for Operations for Networks

Category: Routing / Path Abuse

Reference: @SinSinology

A lax rewrite rule in the appliance’s Nginx configuration allowed an attacker to reach services which were meant to be unexposed. The request /saas./resttosaasservlet will route to /resttosaasservlet.

Figure 5. nginx Routing Bypass

CVE-2023-20198: Cisco IOS XE

Category: Routing / Path Abuse

Reference: Horizon3.ai

The appliance’s routing rules for which requests required authentication did not account for double URL encoded paths.

Figure 6. Double URL Encoded Path Authentication Bypass

CVE-2023-33246: Apache RocketMQ

Category: Insecure Exposed Function

Reference: Rapid7

The application insecurely exposed an endpoint that calls Java’s getRuntime().exec() with an attacker controlled variable.

Figure 7. FilterServerUtil getRuntime().exec()

CVE-2023-22515: Atlassian Confluence

Category: Insecure Exposed Function

Reference: Rapid7

The application insecurely exposed an endpoint, /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false, that allows modification to the server’s configuration state. Setting this state to false allows an attacker to re-enter application setup and add an administrative user.

Figure 8. Exposed Configuration Endpoint

CVE-2023-47246: SysAid Server

Category: Insecure Exposed Function

Reference: Huntress

The application exposed an endpoint, /userentry?accountId=/../../../tomcat/webapps/<webshell_dir>, which wrote attacker controlled data to a filepath also influenced by the attacker, but vulnerable to path traversal in the parameter.

Figure 9. Insecure File Write

CVE-2023-1671: Sophos Web Appliance

Category: Insecure Exposed Function

Reference: VulnCheck

The application insecurely exposed an endpoint, /index.php?c=blocked&action=continue, which did not sufficiently sanitize user input which results in second-order command injection.

Figure 10. Sanitization Bypass to Command Injection 

CVE-2023-27350: PaperCut MF / NG

Category: Insecure Exposed Function

Reference: Horizon3.ai

The application insecurely exposed an endpoint, /app?service=page/SetupComplete, used for first time administrator login during the install process.

Figure 11. Exposed SetupComplete formSubmit()

CVE-2023-46747: F5 BIG-IP

Category: Request Smuggling

Reference: Praetorian

The appliance used a custom Apache library which contained a known request-smuggling vulnerability: CVE-2022-26377. By abusing this vulnerability, with specific considerations for the F5 application stack, authentication bypass was achieved.

Figure 12. Request Smuggling Payload

CVE-2023- : Apache SuperSet

Category: Default Secret

Reference: Horizon3.ai

The application sets the underly Flask SECRET_KEY to a default value. This secret key is used to create session tokens, which can be forged when the secret key is known.

Figure 13. Default SECRET_KEY

CVE-2023-38203: Adobe ColdFusion

Category: Insecure Exposed Function

Reference: Project Discovery

The application exposed an insecure function at the endpoint, /CFIDE/adminapi/accessmanager.cfc?method=foo&_cfclient=true, which called a dangerous Java sink with attacker controlled input leading to deserialization.

Figure 14. Call to WDDXDeserialize() with Attacker Controlled Input

Conclusion and Looking Ahead

The lions share of vulnerabilities that are being exploited in the last year are trivial to exploit. While memory safe languages like Rust may help eliminate some of portion of breaches, there is much work to do to address the risk that comes with building complex software systems.

Looking at 2024 and beyond my advice would be:

1. Vendors
   1. Develop the depth of knowledge of your engineers in the frameworks they use
   2. Harden, standardize, and audit the use of those frameworks across products
   3. Enable and expose verbose logging for your products
2. Developers
   1. Assume all code you write is reachable from an unauthenticated context
   2. Practice defense-in-depth programming and don’t make it easy for an attacker to shell out
3. Defenders
   1. Reduce any attack surface exposed to the internet if its not needed there
   2. Proactively enable logging, and remote logging if possible, for all products that touch the internet
4. Researchers
   1. Look for bugs in the places frameworks come together

We’re already seeing similar trends in 2024 with the recently exploited Ivanti Connect Secure vulnerabilities back-to-back – more path abuse and SSRF to “RCE-as-a-feature” code. An interesting attack surface surrounding application re-initialization vulnerabilities has sprung up this last year and I think we’ll continue to see similar vulnerabilities discovered.

Community

This analysis is made possible by the collective information security community publishing their analysis and research to the world. The following organizations or people were referenced while performing this research:

Rapid7, Mandiant, Project Discovery, Praetorian, VulnCheck, Huntress, SonarSource, AssetNote, BishopFox, Lexfo, Palo Alto Networks, and many more.

Analysis Bias

This is an analysis based on my observations as both a software engineer and a vulnerability researcher. The analysis likely has bias and shortcoming stemming from:

1. Only considering the vulnerabilities that have been discovered recently
   1. My assumption is that more recent vulnerabilities are better representative of this issues that affect us today
2. Filtering Vulnerabilities Based on CVSS 3.0 >= 9 Score
   1. There are vulnerabilities in KEV that are not critically scored but can been combined with other vulnerabilities to achieve some critical effect

Raw Data

The full spreadsheet of all 41 vulnerabilities and their analysis can be found here.

RingZer0 Conference

This research was done in preparation for a talk I’ll be giving at RingZer0’s BOOTSTRAP conference on Friday, February 23.  I’ll briefly touch on this research along with vulnerability research I’ve conducted against Fortinet appliances over the last year that fall directly in line with the trends highlighted here.

 

 

 

The post Rust Won’t Save Us: An Analysis of 2023’s Known Exploited Vulnerabilities appeared first on Horizon3.ai.

On 22 January, Ivanti published an advisory stating that they discovered two new, high-severity vulnerabilities (CVE-2024-21888 and CVE-2024-21893) after researching previously reported vulnerabilities affecting Ivanti Connect Secure, Ivanti Policy Secure and ZTA gateways. Ivanti provides enterprise solutions, including patch management and IT security solutions to over 40,000 customers worldwide.

While there is no evidence of any customers being impacted by CVE-2024-21888, Ivanti has acknowledged CVE-2024-21893 has impacted some customers in targeted instances. 

• CVE-2024-21888 (CVSS Score 8.8) – A privilege of escalation vulnerability in the web component of Ivanti Connect Secure (9.x.22.x) and Ivanti Policy Secure (9.x.22.x) allows a user to elevate privileges to that of an administrator.  
• CVE-2024-21893 (CVSS Score 8.2) – A server-side request vulnerability in the SAML component of Ivanti Connect Secure (9.x.22.x), Ivanti Policy Secure (9.x.22.x) and Ivanti Neurons for ZTA allows an attacker to access certain restricted resources without authentication. 

In response to the new Ivanti vulnerabilities, the Cybersecurity & Infrastructure Security Agency (CISA) ordered all federal government agencies to disconnect all instances of Ivanti Connect Secure and Ivanti Policy Secure from their networks until proper mitigation steps are taken and reported to CISA.

Who is Affected?

Users who are running Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x) and Ivanti Neurons for ZTA.

How Can I Fix It?

Ivanti has released patches for Ivanti Connect Secure (versions 9.1R14.4, 9.1R17.2, 9.1R18.3, 22.4R2.2, 22.5R1.1 and 22.5R2.2) and Ivanti Policy Secure version 22.5R1.1 and ZTA version 22.6R1.3.

According to Ivanti, users can also import the “mitigation.release.20240126.5.xml file as a temporary workaround.

How Can NodeZero Help?

All NodeZero™️ users can run an autonomous pentest to determine if their systems are vulnerable to the Ivanti vulnerability. We also recommend running a follow-on pentest to verify that any remediation steps taken, such as patching, are effective.

Example Impacts:

Example Attack Path:

The post CVE-2024-21893: Another Ivanti Vulnerability Exploited in the Wild. Verify with NodeZero Today! appeared first on Horizon3.ai.