If you prefer read than watch video, there's another online post about the related exploit at fastly is easy to read. Based on the diagram from this article, I think (maybe naively, and maybe it could be sufficient as a mitigation plan, I don't know), having the firewall rules to deny all with allow lists would be the best mitigation option while waiting for a patch. This stop the "query ldap" path at the first phase, thus it won't have a chance to go to the second phase from this vulnerability.
Anyway, this log4shell vulnerability has caught attention widely since last week. It has been a disasterous event for IT team. They need to find ways to check if the servers are impacted? Look for automated ways to detect if this log4j library exists in the machines. How serious is this? Is there a patch? While waiting for patch, what's next? How to mitigate the risk for the time being? Are mitigations in place? What other potential risks is there? And things got more worrying when the first patch of log4j by disabling the jndi feature doesn't not fix this mess completely!
I could imagine what's the team reaction when R&D team downloaded the log4j patch, applied the change to the repository, rebuild the application/system, went through QA testing and ready for release... Then, alas! Another log4j patch is released. As I just checked the log4j security page while writing this, a third patch is released.
And if you are in customer facing support team... You will need to know what the vulnerabiity is about, is it impacting the system that you are supporting, what is the recommendations. You need to do a lot of studies while waiting for R&D's reply. And you need to make sure your customer feel secure, happy and satisfied with your response. (I am trying to imaging what is the customer's expectation. :D)
Lastly, if you are interested to know more about jndi, visit the tutorial here. The log4j lookup function is actually quite handy. Based on today's update for log4j 2.17.0 (3rd patch that I mentioned earlier), you must enable the jndi lookup in order to use this function. Like the YouTuber said, it is not a log4j bug, or jndi problem, it's about how the function is being called/used. And of course, with good coding practice: always validate/sanitize user inputs can avoid this!
This is not a technical post, but just my record of thoughts that I have so far. I heard developers saying, "Why use log4j? We already drop log4j from our system, other dev team should have done the same." "We should use non-popular library so no one would target on our system." I was like... huh? Found someone that is more naive than me! Other dev out there, I just... wish you well.
Useful link(s)
No comments:
Post a Comment