Log4J Lessons Learnt
Christian Folini edited this page Dec 24, 2021
·
3 revisions
This is a lose list of lessons learned during our coverage of the log4j / log4shell / CVE-2021-44228 coverage
Our coverage basically consisted of the following elements
- Discussions on slack
- Discussions on github issue 2331
- Blog post about CRS and Log4j (about 8K views in 2 weeks)
- Blog post about public hunt for bypasses / false negatives - a hunt based on a new CRS Sanbox instance with our experimental rules (about 2.5K views in 10 days)
- And then a few tweets with the CRS twitter account
- Coverage is welcome and people are really looking for orientation with massive vulnerabilities the moment they hit main stream media
- People do not know about CRS. And when they learn about us, they still think it's the ModSecurity project
- People bypassing AWS WAF will get hundreds of upvotes on twitter: e.g. keywords waf bypass
- There might be some potential in covering these keywords on twitter with an off-the-shelf response like "Don't call it a #bypass unless you bypass a real #WAF like the #OWASP #ModSecurity @CoreRuleSet." and then an image of the sandbox call and its response. Ideally also with a link to the Sandbox call (via unique ID; we've discussed this).
- Initiatives like the log4j sandbox really got positive feedback all around
- Seemingly every WAF vendor ran a blog post how they protect from log4j. But unlike CRS none provided any transparency as to the rules.
- Discussing regular expressions and decisions seem to be a winning move. Creating a lot of credibility for our project.
- Several vendors reported using or being inspired by our rules. As did countless other people (also witnessed in many comments on the website). This bought us a lot of goodwill.
- Coverage is a lot of work. Christian invested about 40h in this.
- It would be better to be a team of two. Everybody is very busy in these times, so.
- The setup of a new sandbox instance must be very simple and fast. As must be adding / editing custom rules to an instance.
- We need our own collection of attack payloads for a vulnerability. A natural resource for future tests. (We did not do such a collection and it became a weak spot)
- Maybe the wiki would be a better place for coverage than a blog post. Allowing live updates, collection of payloads, etc. Problem: No history on github wiki.