Page 1 of 1

Checking for Exploits... [Server Based Shell Script]

Posted: Thu Feb 03, 2011 9:50 pm
by RussW
This script has been replaced by a newer php type script that is easier to use and contains many more patterns. The new script can be found here:
http://forum.joomla.org/viewtopic.php?f=621&t=777096


Ok folks,

Following a rather lengthy and fruitless discussion regarding some very old shell exploits on the developer mail-lists by upset and exploited user, I decided to update and re-issue my old "sploitFinder" shell script (originally posted in the J!1.0 Security Forums in September of 2006) in the hope that it may be of use to some again.
IMPORTANT NOTICE
This script is a Unix SHELL SCRIPT and not useful for everybody.
If you host on Windows or do not have Unix/Linux SSH/Shell access to you host, you will not be able to make use of it. However....

PHP Developers
If any smart-cookie PHP Developer would like to convert this from a shell script to either a standalone, single user, browser ready php script or a Joomla! Extension, feel free to go for it.
Information/Overview:
A reasonably effective script to search for particular known patterns within .php and .cgi files that MAY present exploit capabilities.
sploitFinder-1.00-2011.sh.txt

The simple logic is by no means "fool proof" or "exhaustive" but gives a reasonably good indication that the target script maybe part of an exploit set. False positives are extremely possible due to the fact that many valid scripts make use of the same logic/technologies to acheive required activities, therefore some "human intelligence" must be applied to the final reports.

Installation:

1) FTP/Copy sploitFinder.sh.txt to your server
2) Rename to either sploitFinder.sh or just sploitFinder
3) Make the file executable (chmod 755 sploitFinder) or run "sh sploitFinder.sh"
4) READ the comments and instructions in the file (it is fully documented)
5) run it to test with all the different switches, setup crons etc etc


sploitFinder: list possible exploit scripts and optionally email output
Usage: ./sploitFinder(.sh) [-a] [-c] [-m ] [egrep pattern]
-m : email output to instead of writing to stdout
-a : shows all files not just changes since last run
-c : shows matching lines with context
-r : reset/delete history


The script is well commented, only a couple of internal variables to be configured and select your command line execution switches.

Configuration:

searchpath=/home (Default : /home)
sploitdir=/sploitFind (Default : none)


This is the search pattern criteria. Listed are some of the signitures of some exploits we have heard of, these ARE NOT exhaustive. Obviously, the more variables there are, the longer each run will take.

sploitpattern='[removed]|[removed]|[removed]|r57shell|c99shell|shellbot|phpshell|void\.ru|phpremoteview|directmail|bash_history|\.ru/|brute *force|multiviews|[removed]|vandal|[removed]|eggdrop|guardservices|[removed]|dalnet|undernet|vulnscan|spymeta|[removed]|Webshell'

(Feel free to post additions to the sploitpattern to enhance the scripts capability and share your experience and knowledge.!)


This script may be run adhoc if prefered, another option is via crom, for example: TWO regular cron jobs.

The first cron runs every 4 hours on Monday through Sunday at 02.10hrs, 06.10hrs, 10.10hrs, 14.10hrs, 18.10hrs & 22.10hrs
- Showing only new files since the previous run and mailing the report

The second cron runs once a week on Sunday at 01.10hrs
- Resets/rebuilds the Baseline and mails out a full report of ALL files (-a implied)

EG:
10 2,6,10,14,18,22 * * * //sploitFinder.sh -m [email protected] >& /dev/null
10 1 * * 0 //sploitFinder.sh -rm [email protected] >& /dev/null


As ever, This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY or support; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Re: Checking for Exploits... [Server Based Shell Script]

Posted: Wed Feb 09, 2011 11:52 pm
by PhilD
Script setup and installation

* Download the script

* Open the file in a text editor (such as Notepadd++) and change the search path and sploitdir paths to reflect where you intend to upload the file to. In the following example I have uploaded the script outside of public_html and have told the script to search all of public_html and to create the scripts working directory at the same level as where I placed the script.

Code: Select all

# Where you want to search
  searchpath=public_html

## The location where the sploitFinder DB is to stored. This will be auto-generated at first execution
## Example: /opt/adminTools/ is where the sploitFinder script is and you want the DB stored in /opt/adminTools/sploitFinderDB/

  sploitdir=sploitFinderDB
* Save the file as sploitfinder.sh

* Upload the file to your domain placing the file outside of public_html. You do not want the script (or any other shell scripts) accessible from a public_area as this could be considered a security risk.

* Now we need to set the permissions on the script to 700 so that the script owner has read, write and execute privileges while we are testing.

* The script should now be ready to test.

Testing the script operation

Testing the script can be accomplished in a couple ways. The method you use for testing depends on your host service and your level of experience.

a. Testing the script if you have shell access to your account.
b. Testing the script if you do not have shell access

Testing the script if you have shell access:

Using PuTTY open a terminal session to your account and change the directory to where you uploaded the sploitfinder.sh script.
Enter the following command and press return:

./sploitFinder.sh -ac

The result of the command will scroll by on the screen. View the result and make sure no errors were generated. If there were errors, correct them before proceeding.

If no errors were generated check and make sure the directory sploitFinderDB was created. It should have permissions of 700.

Check inside of directory sploitFinderDB for 2 text files; one called pid and one called last.

If everything checks out you can set up a cron job to run the script automatically.

Testing the script if you do not have shell access

If you do not have shell access to your account, you can use a cron job to test the script. Most hosting services will have this ability.

Go to your domains control panel and create a cron process following the procedure your domains control panel provides.
In the minute field enter
*/2
This will run the script every 2 minutes. Leave the rest of the time date settings as asterisks (*)
In the command line enter the command desired.
/<your_loacation>/sploitFinder.sh -ac -m [email protected]

Save the cron job and if the cron runs without errors it will create the directory "sploitFinderDB" and the directory should have permissions of 700.

Check inside of directory sploitFinderDB for 2 text files; one called pid and one called last.

If everything checks out you can set up a cron job to run the script automatically.

Scheduling the script to run from Cron at a reasonable times.

Create or set the cron job you made above in testing to run at something reasonable such as every 8 hours on Monday through Saturday at 02.10hrs, 10.10hrs & 16.10hrs.

Add the >/dev/null 2>&1 to the end of the command when your making modifications to the time and days.
Example:
10 2,10,18 * * 1-6 /<your_loacation>/sploitFinder.sh -c -m [email protected] >/dev/null 2>&1

This cron job runs every 8 hours on Monday through Saturday at 02.10hrs, 10.10hrs & 16.10hrs only of files changed since last report, showing context information and email report.

The second cron below runs once a week on Sunday at 02.10hrs and Resets/rebuilds the Baseline and mails out a full report of ALL files (-a implied)
Example:
10 2 * * 0 /<your_location>/sploitFinder.sh -rm [email protected] >/dev/null 2>&1

Once you are done with testing the script you should be able to change the permissions to 500 (read, execute) to make it more secure.

Troubleshooting

Most issues with the script will be the result of the wrong path information being supplied to the script.
Example error:
find: /public_html: No such file or directory

This error generally means that the search path is incorrect

Errors of permission denied when attempting to run the script can be the result of improper permissions on the script.
The permissions on the script should be 500 (700 while testing) and permissions on the directory sploitFinderDB should be 700.

Another cause of permission denied errors can be that your host has changed the command find to something else to increase security. In this case you will need to ask what the command to use instead of find and change the find command in the script ( ~ line 191) to the correct command.