This is a follow-up post to ModSecurity Advanced Topic of the Week: Malware Link Detection in which we will highlight a new capability within ModSecurity v2.6 that allows for removal of data within response bodies.
In the previous blog post, we should how you can use the new @gsbLookup operator to query a local Google Safe Browsing DB file to identify potential malware links within response bodies of your web traffic. While identifying malware links is obviously quite useful, the next logical question is - what do you want to do about it?
In the previous blog post, when the GSB rule identified a malware link within the response body, we isused a redirect action within ModSecurity.
SecGsbLookupDB GsbMalware.datSecRule RESPONSE_BODY "@gsbLookup =\"https?\:\/\/(.*?)\"" "phase:4,capture,log,redirect:http://www.example.com/,msg:'Bad url detected in RESPONSE_BODY (Google Safe Browsing Check)',logdata:'http://www.google.com/safebrowsing/diagnostic?site=%{tx.0}'"
This action does help to ensure that the end client does not recieve the response page with the infected link in it, however the end user experience is certianly still impacted as they have no real indication as to why they were suddednly redirected.
What would be ideal from both a security and end user experience perspectives would be to sanitize the response bodies and remove the offending data while still delivering the page to the client.
In the latest version of ModSecurity (2.6), we also introduced an extremely powerful new operator called @rsub which is short for RegEx Substitution. As the name indicates, this operator allows you to match variable data and then do a substitution. What makes this new operator even more powerful is that is has macro expansion capabilities. This is extremely useful when you need generic data matching (see below).
The @rsub operator is really cool, but what makes this use-case possible is another new feature in ModSecurity v.2.6 and that is the new STREAM_OUTPUT_BODY variable which gives direct filter level access to the live data. Here is an updated ruleset that uses these new capabilities:
SecGsbLookupDB GsbMalware.datSecStreamOutBodyInspection OnSecContentInjection OnSecRule STREAM_OUTPUT_BODY "@gsbLookup \Whttps?\:\/\/(.*?)(\"|>)" "chain,phase:4,capture,log,pass,msg:'Bad url detected in RESPONSE_BODY (Google Safe Browsing Check)',logdata:'http://www.google.com/safebrowsing/diagnostic?site=%{tx.0}'" SecRule STREAM_OUTPUT_BODY "@rsub s/%{tx.0}/MALICIOUS_URL_REMOVED/"
This ruleset will play Whack-a-Mole and actively swap out the malicious domains found within the GSB DB with the string MALICIOUS_URL_REMOVED in the response pages and still issue alert messages locally in ModSecurity so that security teams can investigate infected pages.
I decided to test out this new feature. The first step was to identify a site that was infected by LizaMoon malware links. After some quick google searches, I found the following site.
I then tested the new GSB data substitution capabilities by configuring my local browser to use my local Apache+ModSecurity server as a forward proxy. I then browsed to this same site. Here is a screenshot of the infected after being cleansed by ModSecurity:
The ability to alter live http transactional data is a huge step foward, not only for ModSecurity, but for WAFs in general. This allows for much more flexibility in responding to issues vs. the limited choice of blocking the entire transaction. This particular use-case of removing malware links from infected pages is just the first example of this new feature. More to come...