***Please understand that this is a fluid situation and this post may be updated periodically as new information becomes available***
A critical vulnerability has been discovered in log4j that is actively being exploited. This is an issue both for systems and web administrators on campus, including those who support products with a web interface, as well as requiring the attention of those that manage relationships with Software as a Service (SaaS) vendors.
This is particularly critical because:
- If a system is vulnerable the exploit can grant full system access.
- The vulnerability requires a low level of skill to exploit.
- The exploit can be sent over https where we cannot inspect the encrypted traffic or block the port.
- We are blocking this attack pattern at our campus edge when we see it in unencrypted http traffic. We are seeing a significant volume of attempts.
- As of now, there is not a reliable way to detect it via a vulnerability scanner.
- The package may be installed and built locally, making detection via package managers like rpm more difficult.
If you manage the relationship with a SaaS vendor or run a vended product with a web interface, you should contact the vendor for more information about how they are addressing the vulnerability immediately. If you get notified by a vendor of a data breach, contact Incident Response Team via ServiceNow or help.unc.edu.
It is important that all administrators of web services review their installations for the presence of log4j and update it as needed.
- Update to version 2.16.0 that fixes the vulnerability.
- In Version 2.10.0 and newer you can set a property called formatMsgNoLookups.
- Older versions, such as 1.x, are not supported by the vendor. There are some recommendations on the web for things that might work, but we cannot guarantee any of them.
In addition, if you are running a vulnerable version you should review your web server logs for indication of compromise. You can search your logs using the egrep command below to find exploit attempts. If you find entries that appear to have succeeded based on return codes, please reach out to the Incident Response Team via a ServiceNow request or through help.unc.edu.
- egrep -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ {insert your access log file name(s) here}
Advisories and Technical Discussions
- https://www.cisa.gov/uscert/ncas/current-activity/2021/12/10/apache-releases-log4j-version-2150-address-critical-rce
- https://www.rapid7.com/blog/post/2021/12/10/widespread-exploitation-of-critical-remote-code-execution-in-apache-log4j/
- https://isc.sans.edu/diary/rss/28120
Some vendor references:
- Apache Log4j – https://logging.apache.org/log4j/2.x/
- Cisco – https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
- JAMF – https://community.jamf.com/t5/jamf-pro/third-party-security-issue/td-p/253740
- Papercut – https://www.papercut.com/support/known-issues/?id=PO-684#ng
- Oracle – https://www.oracle.com/security-alerts/alert-cve-2021-44228.html
- VMware – https://www.vmware.com/security/advisories/VMSA-2021-0028.html
- A more complete list is available at https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592