On 13.12.21 11:48, Olivier D wrote:
Hello there,If you don't know yet, a CVE was published on friday about library log4j, allowing a remote code execution with a crafted HTTP request. We would like to filter these requests on HAProxy to lower the exposition. At peak times, 20% of our web traffic is scanners about this bug ! The offended string is "${jndi:". It must be filtered on any fields that could go to log servers: - URL - User-Agent - User name What would be the easier way to do that ? If I give it a try : http-request deny deny_status 405 if { url_sub -i "\$\{jndi:" or hdr_sub(user-agent) -i "\$\{jndi:" } What do you think ?
Basically it could be any header which is used by the application which uses to send it unchecked and unverified to the logging library. The assumption or the fields are valid but not enough, from my point of view. There is a quiet nice blog post https://isc.sans.edu/diary/28120 about this topic. For my point of view is the key statement in the blog below. "as long as it reads some input from an attacker, and passes that to the log4 library" There are 2 main question here. 1. Why is a input from out site of the application passed unchecked to the logging library! 2. I the lookup really necessary for the application or only a lazy way to solve some topics? This CVE creates a lot or noise but I haven't seen anywhere that someone asked this simple questions. The sad fact is that one of the main development rule is broken here from the developing peoples, and this is a quite old rule. Check and verify EVERY Input from the "User". From my point of view can the "http-request deny" rule be added but which else header should be included? The "referer" Header is also a nice injection option because some apps want to know from which location a request is cumming and this is a know header how about some specific app headers "X-???"?
Olivier
Jm2c Regards Alex
