Monitoring - Inky systems are not affected by the recently discovered log4j vulnerability. Late last week an announcement was made of a vulnerability in the ubiquitous log4j library in Java. Inky began investigation and testing for evidence of systems vulnerable to the log4j bug. We have been able to determine that none of the Java components that we utilize have exposure to the log4j vulnerability. We have updated and or disabled the log4j components on all backend systems to ensure no future changes could lead to an exposure.
Dec 15, 13:38 UTC

Monitoring - The log4j vulnerability means that threat actors can potentially trigger malicious code execution in customer systems running Java simply by including certain character sequences in email headers or body text. Specifically, malicious code can run when carefully crafted text in an email is logged by a Java runtime running unpatched log4j code.

Here are some examples of how an attacker’s email could lead to malicious code execution on an INKY customer’s backend system:

- The customer runs an Outlook add-in that sends emails matching certain criteria to a backend system implemented in Java, incorporating unpatched log4j, and allowing Java Naming and Directory Interface (JNDI). A real-world example is Salesforce, which can be fed emails in this manner.

- The customer logs or analyzes emails via a Java backend process running unpatched log4j and allowing JNDI.

- The customer has end users who read emails using a mail client implemented in Java, where the Java mail client supports JNDI and logs email contents using unpatched log4j.



New INKY detection method and banner

To limit bad actors’ ability to exploit this new vulnerability via email, INKY has deployed new detection models that can identify this threat, add a red danger banner, and direct the email to user/admin quarantine (if the customer is using INKY’s delivery settings feature).

This new detection method looks for indicative log4j exploit sequences such as a dollar sign followed by a left brace followed by the string ”jndi”. The detection code includes additional heuristics to spot attacker attempts to obfuscate these indicative sequences; for security reasons we won’t publish details of these heuristics; if you would like details, please contact us.

VERY IMPORTANT: while this new detection method identifies the vast majority of attempted log4j exploits, attackers may yet have clever methods to subvert even these checks. Customers should patch all systems that rely on log4j as soon as possible.

The log4j exploit underscores why INKY examines email prior to its delivery to the inbox, eschewing API-based post-delivery approaches: once an email is delivered to a user inbox, it can then be logged and trigger the exploit. Only an inline pre-delivery detection system like INKY can truly mitigate this kind of exploit – by preventing delivery of malicious emails to end users.



Additional recommendations and mitigating factors

INKY recommends customers audit their mail processing tools and environments to ensure that they are not vulnerable to the log4j exploit.

Note, however, that simply receiving an email with a log4j exploit sequence alone does not execute malicious code; malicious code can only be executed by a Java runtime both running unpatched log4j code and enabling JNDI.

If you have questions or concerns about whether you may be affected by the log4j vulnerability, please connect with us to schedule a discussion. We are here to help!
Dec 20, 18:34 UTC