scan function has been broken up into a multiple functions which should make it more modular if future scan types are needed.
--comment, -a flag was added which prints the first comment to appear prior to the matched pattern in the pattern file.
--Fixed a bug with the out function. Previous updates of mine did not update all calls to the out function which I changed the parameters for. Fixed this by replacing the out function with an 'error' function.
--Alphabetized function definitions and did some general tidying up
--Made all functions private except the constructor.
--Created parseArgs function to handle reading in options.
--Fixed a bug with 'extra-check' where htaccess and googleBot were being pushed to the pattern array each time a file was scanned.
This bug was created when I moved the pattern initialize code to the constructor. Moved extra-check code with the rest of the initialize pattern calls.
--Added -no-color, -time, and -checksum flags. I'd prefer if the output was only as spammy as the user requests. Time should be helpful in tracing when the attack occurred and if files are related to the same hack. Time and checksum do not display by default. no-color flag makes it easier to dump to plain text files.
checking for comments and whitespace lines in pattern files should only be done once when the patterns are loaded.
Added this code to the loadPatterns() function and removed it from the 3 scan loops.
Verbose flag was not proceeding with the next scan due to !found being set. Added a check to see if it is verbose when it decides to do the next scan.
Patterns should be loaded once and only once. The files aren't large so not a problem with memory, however it might impact performance if we are loading the same 3 files ever time we scan a file.
Previous limit of 750 chars enclosed in php tags in a single line was too low... false positives were being triggered by a w3 total cache file because some guy decided to print one gigantic long message in a single line.
Raising to 1100
- Gave each flag option a short or long option; like i:ignore or d:directory or k:hide-ok
- Added a verbose option that instructs the scan to scan a file for ALL matches and not just stop at the first one.
- Restructured the output code to allow for the verbose flag, mainly a new function printPath and where the md5 hash is computed
- Modified the output to be cleaner, checksum is printed first as it is fix-width and to make it easier to paste into the whitelist file.
- Modified the output to be 'bash safe', ie when I accidentally paste my scan results into my terminal, the '#' should make sure everything is treated as a comment. This is in contrast to possibly attempting to execute absolute paths to potentially malicious PHP scripts and the usage of the '>' which tells the shell to write to a file. Also enclosed each path in {} for similar purposes.
- Printing the matched string/pattern in $color... might change later depending on preference.
the 's' flag tells preg_match to operate in multi-line mode. the 'm' flag does the same, but allows line begin and ends to still be matched which is useful in some cases.
One common tactic is to shove all of your PHP code into a single line, often contained within its own PHP tags, and drop it into any .php file that you want. This pattern should detect if more than 750 characters are contained within PHP tags on a single line.
Added a single short flag for every long flag and a single long flag for every short flag.
This now gives us 2 ways to set each flag.
Also updated the showhelp.
Dropped an unnecessary 'else' statement.
str_ will match 13 separate php functions, many of which can be used for string/modifcation aka obfuscation
function added to catch function defining.
echo added as it is a common php keyword, though experimental... may cause a of false positives
include added as it is often used to link in other malware files.
This is a file containing a list of PHP keywords converted to base64. It's designed to be used as a pattern file to identify common keywords used in obfuscated code.
Found a couple of cases where the php functions array_shift and addcslashes were used in base64 encoded malware.
Adding strings to catch any references to 'cslashes' which will catch both addcslashes and strip cslashes
Adding strings to catch any references to 'array_' which will catch about a dozen array modification functions.
removed mail b64, added chr b64
mail was generating too many false positives.
chr has only one pattern that is long enough to use with any sort of reliability, but it is one that we want to look out for anyway.
Example usage:
I want to see if a giant block of base64 code contains any references to the string 'base64'.
The naive approach is to convert the string to it's base64 equivalent, YmFzZTY0.
There are two problems with this approach. The first is that the string will be different depending on the position of the first character 'Y' in the input string. Possible offents are 0 bits, 2 bits or 4 bits. The above example only calculates the 0 bit offset. There should be 3 separate base64 strings to look for.
The second problem is that base64 strings use a 6 bit encoding, so the characters don't align the same as 8 bit encoding. This leads to character bleeding at the beginning and ends of a string where the string will change depending on its immediate context. This script calculates the maximum constant string length that should be present. Unfortunately it requires trimming characters which can often lead to very short strings.
Found a bug in my base64 converter
My base64 conversion script is supposed to find the maximum length string that is guaranteed to be present if the input plain text string is somewhere in the original plain text code, however there was an off by 1 error which made some patterns 1 character longer than they should have been. Short patterns (ie 4 chars) were prone to false positives because they really were 3 character patterns which is too short to be useful. Long patterns were likely missing results.
Should be fixed now.
shortened the base64 fingerprints of 'base64_decode' to just 'base64'. will also catch cases of base64_encode which isn't quite so bad but still worth finding.
interesting note from the php.net manual on create_function:
Caution
This function internally performs an eval() and as such has the same security issues as eval(). Additionally it has bad performance and memory usage characteristics.
This file just contains a list of internal php 7 functions (probably incomplete depending on extensions etc) and their 3 base64 fingerprints. It is designed to be used as either a pattern file to explore potential patterns that may be effective, or simply as a reference to translate between plain text php and the 3 different base64 versions.
