Skip to main content
Question

RCE 0-day exploit found in log4j

  • December 10, 2021
  • 42 replies
  • 251 views

Show first post

42 replies

Forum|alt.badge.img+3
  • Author
  • New Contributor
  • December 13, 2021

We have just confirmed our on-premise server is compromised, found a malicious jamf.ps file, not sure if the best course of action is to restore from backup and update server or to simply remove jamf.ps file and update server?


Where did you find this file?


Forum|alt.badge.img+6
  • Contributor
  • December 13, 2021

Where did you find this file?


It was initially downloaded to the root of c:


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • December 13, 2021

It was initially downloaded to the root of c:


Depends on the content of the script. Can you read powershell and understand what is being done there?


Forum|alt.badge.img+6
  • Contributor
  • December 13, 2021

Depends on the content of the script. Can you read powershell and understand what is being done there?


The jamf.ps script is encoded, our security team are currently trying to access it


donmontalvo
Forum|alt.badge.img+36
  • Hall of Fame
  • December 13, 2021

log4shell

^^^Just adding so it comes up in a search.


jmahlman
Forum|alt.badge.img+17
  • Valued Contributor
  • December 13, 2021

What would be the best course of action on investigating if your server has been compromised?


Forum|alt.badge.img+6
  • Contributor
  • December 13, 2021

What would be the best course of action on investigating if your server has been compromised?


Not sure about your environment but our security team detected the use of encoded powershell on our jss from a specified IP that downloaded a jamf.ps file to our JSS server, root of c:. We blocked the IP, isolated JSS, triaging now. 


Forum|alt.badge.img+2
  • New Contributor
  • December 13, 2021

Not sure about your environment but our security team detected the use of encoded powershell on our jss from a specified IP that downloaded a jamf.ps file to our JSS server, root of c:. We blocked the IP, isolated JSS, triaging now. 


When did you patch your server?


Forum|alt.badge.img+5
  • Contributor
  • December 13, 2021

I don't find any of the files referenced in this mitigation article.:
https://docs.jamf.com/technical-articles/Mitigating_the_Apache_Log4j_2_Vulnerability.html
Are they someplace else?


Forum|alt.badge.img+6
  • Contributor
  • December 14, 2021

When did you patch your server?


Server is isolated at present, looking to patch today hopefully


Forum|alt.badge.img+6
  • Contributor
  • December 14, 2021

I don't find any of the files referenced in this mitigation article.:
https://docs.jamf.com/technical-articles/Mitigating_the_Apache_Log4j_2_Vulnerability.html
Are they someplace else?


I found this a good resource for information https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance


Forum|alt.badge.img+10
  • Valued Contributor
  • December 14, 2021

I’m looking through the JSSAccess.log I really don’t see anything out of the ordinary what am I looking for?


@mvanstone Hi.  In your JSSAccess.log you would want to look for unusual account names, or possibly failures.  Look for anything that seems out of the ordinary.  If you run IIS I highly recommend you search your IIS logs for the string 'jndi'.  The string containing jndi will most likely be the attack string.


Forum|alt.badge.img+13
  • Valued Contributor
  • December 14, 2021

Apparently 2.15.0 was only a partial mitigation.  log4j 2.16.0 has been released that disables JNDI completely.  CVE 


Forum|alt.badge.img+3
  • New Contributor
  • December 17, 2021

A new, simpler to exploit, log4j vector using websockets and not much more than a normal page load.

https://www.zdnet.com/article/security-firm-blumira-discovers-major-new-log4j-attack-vector/ 

 

remediation advise is the same as before, patch log4j to 2.16 and monitor in/out requests


donmontalvo
Forum|alt.badge.img+36
  • Hall of Fame
  • December 17, 2021

A new, simpler to exploit, log4j vector using websockets and not much more than a normal page load.

https://www.zdnet.com/article/security-firm-blumira-discovers-major-new-log4j-attack-vector/ 

 

remediation advise is the same as before, patch log4j to 2.16 and monitor in/out requests


Ok, ok, I didn't really want to go to the movies tonight.

Jamf Pro 10.34.2, here I come.


Forum|alt.badge.img+3
  • New Contributor
  • December 17, 2021

Ok, ok, I didn't really want to go to the movies tonight.

Jamf Pro 10.34.2, here I come.


You bet, we're all eagerly waiting.

I'd rather patch Jamf to 10.34.2 with log4j patch included, then patch log4j in isolation.


Forum|alt.badge.img+5
  • New Contributor
  • February 8, 2022

I have applied the patch from Jamf and can confirm that JNDI code from the log is no longer triggered.
log4j2.formatMsgNoLookups: true is no longer necessary if you are on 10.34.1.

If you want to test it yourself, generate a domain at http://www.dnslog.cn/ and build a jndi command with the domain and try to log in to your jss with the jndi string. If you are still vulnerable, your dns records should be visible on the page where you generated the domain.


I would strongly recommend against using a service based in China to test/reveal whether your system is vulnerable or compromised.  Really bad idea.