From the Trenches: Get to know error code 444
Troubleshooting errors you get from Docusign API calls while developing or managing your Docusign integration can be challenging, especially when there’s nothing apparently wrong with your code. However, some Docusign error codes should alert you to problems, not with your code, but with your app host: one of these is error code 444. One common cause of this error code coming from Docusign is an Apache Log4j security vulnerability.
What is Log4j?
Log4j is a plugin commonly used by Java applications. Its purpose is to record and relay errors and system operations back to system administrators and system users. It is an open-source product provided for free by Apache and used in a large number of applications varying from server hosting applications to Minecraft.
Understanding the issue
One of the functions of Log4j is to overwrite diagnostic data or send data back to a remote server for processing. As given in the Apache guide, Log4j v2.x is vulnerable to attack. The exploit specifically allows for an attacker to inject code into the application, which in turn has the potential to grant remote console/shell access for a targeted system. Depending on the system and the level of access that is gained, the attacker can remotely open the equivalent of an administrative command prompt. Once the attacker has access to the command shell, they can do a huge amount of damage. Presently, this exploit is being used for tasks like forcing remote machines into botnets or launching ransomware attacks, and must be taken very seriously.
The primary difficulty with mitigating this vulnerability is that you cannot easily determine whether a specific piece of software running on an Apache server is affected; however, the vulnerability only affects Log4j v2.x. According to Apache, then, the easiest way to mitigate the vulnerability on the developer side is to upgrade the version of Log4j presently being used. Apache recommends Log4j versions 2.3.1 for Java 6, 2.12.3 for Java 7, and 2.17.0 for Java version 8 or above.
The Docusign response
As a federal contractor, Docusign has complied with CISA Emergency Directive 22-02, which includes, among other safeguards, implementing an active firewall to deny incoming requests that contain evidence of this specific exploit. Accordingly, we’ve implemented a Log4j detection mechanism within our firewall that is meant to pick up the exploit in several potential places. If you or one of your integration’s customers is receiving an API response indicating an error code 444, the Log4J vulnerability is very likely the cause. Please reach out to Customer Support with a captured API log of your createEnvelope request so we can have a closer look to determine if this is the cause.
How can you tell if your app is impacted?
If you are monitoring your request traffic, you will see a response code indicating a 444 error, which is returned by our firewall in the event that it detects evidence of the Log4j exploit. Also, keep in mind that any ports of Log4j, including log4net, a popular C# port of the original utility, may include a thumbprint of the same potential vulnerability.
Docusign, at this time, is not offering exceptions to this rule. This means that, if your application is being affected by 444 errors caused by the Log4j vulnerability, you must update Log4j on your Apache server before you can expect your integration to communicate successfully with Docusign servers.
