Facebook
Twitter
L
Limedrink
Guest
Yes, it has been mounted and secured that way for years.
Any other ideas?
Thanks again.
Limedrink.
Any other ideas?
Thanks again.
Limedrink.
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
T
Traged1
Guest
Ok the first thing is this:
127.0.0.1 - - [17/Feb/2007:09:13:36 -0600] "GET /r57shell_version/version.php?version=131 HTTP/1.0" 404 226 "-" "-"
remote shell scripts requires that the attacker makes a request to the file normally from the browser. Your mod_sec should have caught this.
Make sure you have the following in your mod_security config or rules:
---------------------------------------------------
# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type \
"!(^application/x-www-form-urlencoded$|^multipart/form-data
"
# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Length "!^$"
# Don't accept transfer encodings we know we don't handle
SecFilterSelective HTTP_Transfer-Encoding "!^$"
------------------------------------------------------
this should stop them from using the GET method to get the exploit file, and force them to try a POST command instead, when they do that the packet will be scanned by mod_sec.
Can you post the contents of r57shell ?
127.0.0.1 - - [17/Feb/2007:09:13:36 -0600] "GET /r57shell_version/version.php?version=131 HTTP/1.0" 404 226 "-" "-"
remote shell scripts requires that the attacker makes a request to the file normally from the browser. Your mod_sec should have caught this.
Make sure you have the following in your mod_security config or rules:
---------------------------------------------------
# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type \
"!(^application/x-www-form-urlencoded$|^multipart/form-data
"# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Length "!^$"
# Don't accept transfer encodings we know we don't handle
SecFilterSelective HTTP_Transfer-Encoding "!^$"
------------------------------------------------------
this should stop them from using the GET method to get the exploit file, and force them to try a POST command instead, when they do that the packet will be scanned by mod_sec.
Can you post the contents of r57shell ?
L
Limedrink
Guest
Hi traged1,
I'll try and find the r57shell contents...
For now, here's an example of an entry I found in audit_log:
==d6a1d60b==============================
Request: [domainremoved].org 82.114.188.55 - - [17/Feb/2007:10:15:50 --0600] "GET /manual/.bash_history HTTP/1.0" 500 1270 "-" "Mozilla/4.0 (compatible; MSIE 6.0)" Z9sjEX8AAAEAAAsR8W0AAAAI "-"
----------------------------------------
GET /manual/.bash_history HTTP/1.0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0)
Host: [domainremoved].org
Connection: Close
Acunetix-Product: WVS/2.0 (Acunetix Web Vulnerability Scanner - EVALUATION)
Acunetix-Scanning-agreement: Third Party Scanning PROHIBITED
Acunetix-User-agreement: http://www.acunetix.com/wvs/disc.htm
mod_security-action: 500
mod_security-message: Access denied with code 500. Pattern match "/\\.(history|bash_history) HTTP\\/(0\\.9|1\\.0|1\\.1)$" at THE_REQUEST [severity "EMERGENCY"]
HTTP/1.1 500 Internal Server Error
Last-Modified: Sat, 23 Sep 2006 02:32:38 GMT
ETag: "4c482c-4f6-c52c3d80"
Accept-Ranges: bytes
Content-Length: 1270
Connection: close
Content-Type: text/html
--d6a1d60b--
==9c686a08==============================
The IP there matches the IP I found in a file my /tmp folder. I found a few files with names like:
20070217-101508-82.114.188.55-request_body-8tEG9K
Funny thing, is that domain only had static HTML pages (as far as what the owner has told me). I'll check that out too.
Thanks for the help. I really appreciate it.
Limedrink.
I'll try and find the r57shell contents...
For now, here's an example of an entry I found in audit_log:
==d6a1d60b==============================
Request: [domainremoved].org 82.114.188.55 - - [17/Feb/2007:10:15:50 --0600] "GET /manual/.bash_history HTTP/1.0" 500 1270 "-" "Mozilla/4.0 (compatible; MSIE 6.0)" Z9sjEX8AAAEAAAsR8W0AAAAI "-"
----------------------------------------
GET /manual/.bash_history HTTP/1.0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0)
Host: [domainremoved].org
Connection: Close
Acunetix-Product: WVS/2.0 (Acunetix Web Vulnerability Scanner - EVALUATION)
Acunetix-Scanning-agreement: Third Party Scanning PROHIBITED
Acunetix-User-agreement: http://www.acunetix.com/wvs/disc.htm
mod_security-action: 500
mod_security-message: Access denied with code 500. Pattern match "/\\.(history|bash_history) HTTP\\/(0\\.9|1\\.0|1\\.1)$" at THE_REQUEST [severity "EMERGENCY"]
HTTP/1.1 500 Internal Server Error
Last-Modified: Sat, 23 Sep 2006 02:32:38 GMT
ETag: "4c482c-4f6-c52c3d80"
Accept-Ranges: bytes
Content-Length: 1270
Connection: close
Content-Type: text/html
--d6a1d60b--
==9c686a08==============================
The IP there matches the IP I found in a file my /tmp folder. I found a few files with names like:
20070217-101508-82.114.188.55-request_body-8tEG9K
Funny thing, is that domain only had static HTML pages (as far as what the owner has told me). I'll check that out too.
Thanks for the help. I really appreciate it.
Limedrink.
T
Traged1
Guest
Once the file has been uploaded I would imaging that the attacker would be able to modify any file under it's own UID which would have been "apache". So any files running as the user apache could have and most likely have been altered.
L
Limedrink
Guest
That makes sense... They use the Acunetix Scanner to see if the server is vulnerable, and then modify the scanner's files to execute the exploit.
I'm starting to think that I might have removed an important mod_security rule that caused the attack. I only removed a few, and that was because I found that a LOT of site-applications are coded poorly and won't function with those rules enabled.
I'll do a more thorough look of things and post back.
Thanks.
I'm starting to think that I might have removed an important mod_security rule that caused the attack. I only removed a few, and that was because I found that a LOT of site-applications are coded poorly and won't function with those rules enabled.
I'll do a more thorough look of things and post back.
Thanks.
T
Traged1
Guest
I would also record all those IP's and then block them out using iptables. You will most likely need to wipe this server and restore from a backup which was backed up before that attack. before you do that, you better find out where the hole is in the first place and remove or lockdown the script which is being used to get this exploit top your tmp folder.
ADD the following rule to mod_sec:
SecFilterSelective THE_REQUEST "*r57shell*"
Also I would add rules to your mod_sec like this if not present already:
#generic php attack sigs
SecFilterSelective REQUEST_URI "&(cmd|command)=(id|uname)\x20"
SecFilterSelective REQUEST_URI "cmd\?(cmd|command)="
SecFilterSelective REQUEST_URI "(spy|cmd|cmd_out|sh)\.(gif|jpg|png|bmp|txt)\?&(cmd|command)="
SecFilterSelective REQUEST_URI "\.php\?&(cmd|command)="
#php command attacks
SecFilterSelective REQUEST_URI "(chr|fwrite|system|echr|passthru|popen|proc_open|shell_exec|exec|proc_nice|proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posix_setsid|posix_setuid|phpinfo)\(.*\)\;" "id:300008,rev:1,severity:2,msg:'Generic PHP exploit pattern denied'"
#Generic PHP remote file inclusion attack signature
SecFilterSelective REQUEST_URI "\.php\?" chain
SecFilter "(http|https|ftp)\:/" chain
SecFilter "(cmd|command)=(cd|\;|rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |cmd|pwd|wget |lwp-(download|request|mirror|rget) |uname|svn |(s|r)(cp|sh) |net(stat|cat) |rexec |smbclient |t?ftp |ncftp |telnet |gcc |cc |g\+\+ |whoami|\./|killall |rm \-[a-z|A-Z])"
SecFilterSelective REQUEST_URI "\.php\?" chain
SecFilter "(http|https|ftp)\:/" chain
SecFilter "(cmd|command)=.*(cd|\;|rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |cmd|pwd|wget |lwp-(download|request|mirror|rget) |uname|cvs |svn |(s|r)(cp|sh) |net(stat|cat) |rexec |smbclient |t?ftp |ncftp |telnet |gcc |cc |g\+\+ |whoami|\./|killall |rm \-[a-z|A-Z])"
#Genenric PHP body attack
SecFilterSelective THE_REQUEST "(chr|fwrite|system|echr|passthru|popen|proc_open|shell_exec|exec|proc_nice|proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posix_setsid|posix_setuid|phpinfo)" chain
SecFilterSelective POST_PAYLOAD "^PHP\:*((cd|mkdir)[[:space:]]+(/|[A-Z|a-z|0-9]|\.)*|rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |cmd|pwd|wget |lwp-(download|request|mirror|rget) |uname |cvs |svn |(s|r)(cp|sh) |net(stat|cat)|rexec |smbclient |t?ftp |ncftp |chmod |telnet |gcc |cc |g\+\+ |whoami|\./|killall |rm \-[a-z|A-Z])"
#generic command line attack
SecFilterSelective THE_REQUEST "\|*id\;echo*\|"
SecFilterSelective ARGS "\|*id\;echo*\|"
#remote file inclusion generic attack signature
SecFilterSelective THE_REQUEST "\.(dat|gif|jpg|png|bmp|txt|vir|dot)\?" chain
SecFilter "((name|pm_path|pagina|path|include_location|root|page|open)=(http|https|ftp)|(cmd|command|inc)=)"
SecFilterSelective THE_REQUEST "\.(dat|gif|jpg|png|bmp|txt|vir|dot)\?\&(cmd|command|inc|name)="
SecFilterSelective ARGS "\.(dat|gif|jpg|png|bmp|txt|vir|dot)" chain
SecFilter "\?\&(cmd|inc|name)="
SecFilterSelective ARGS "\.(dat|gif|jpg|png|bmp|txt|vir|dot)\?\&(cmd|inc|name)="
SecFilterSelective REQUEST_URI "\.php\?.*=(http|https|ftp)\:/.*\?&cmd="
#Bogus file extensions generic signature
SecFilterSelective THE_REQUEST "[A-Za-z0-9]\.(gif|jpg|png|bmp)\.txt"
#PHP remote path attach generic signature
SecFilterSelective REQUEST_URI "\.ph(p(3|4)?).*path=(http|https|ftp)\:/"
SecFilterSelective REQUEST_URI "\.php.*path=(http|https|ftp)\:/"
ADD the following rule to mod_sec:
SecFilterSelective THE_REQUEST "*r57shell*"
Also I would add rules to your mod_sec like this if not present already:
#generic php attack sigs
SecFilterSelective REQUEST_URI "&(cmd|command)=(id|uname)\x20"
SecFilterSelective REQUEST_URI "cmd\?(cmd|command)="
SecFilterSelective REQUEST_URI "(spy|cmd|cmd_out|sh)\.(gif|jpg|png|bmp|txt)\?&(cmd|command)="
SecFilterSelective REQUEST_URI "\.php\?&(cmd|command)="
#php command attacks
SecFilterSelective REQUEST_URI "(chr|fwrite|system|echr|passthru|popen|proc_open|shell_exec|exec|proc_nice|proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posix_setsid|posix_setuid|phpinfo)\(.*\)\;" "id:300008,rev:1,severity:2,msg:'Generic PHP exploit pattern denied'"
#Generic PHP remote file inclusion attack signature
SecFilterSelective REQUEST_URI "\.php\?" chain
SecFilter "(http|https|ftp)\:/" chain
SecFilter "(cmd|command)=(cd|\;|rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |cmd|pwd|wget |lwp-(download|request|mirror|rget) |uname|svn |(s|r)(cp|sh) |net(stat|cat) |rexec |smbclient |t?ftp |ncftp |telnet |gcc |cc |g\+\+ |whoami|\./|killall |rm \-[a-z|A-Z])"
SecFilterSelective REQUEST_URI "\.php\?" chain
SecFilter "(http|https|ftp)\:/" chain
SecFilter "(cmd|command)=.*(cd|\;|rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |cmd|pwd|wget |lwp-(download|request|mirror|rget) |uname|cvs |svn |(s|r)(cp|sh) |net(stat|cat) |rexec |smbclient |t?ftp |ncftp |telnet |gcc |cc |g\+\+ |whoami|\./|killall |rm \-[a-z|A-Z])"
#Genenric PHP body attack
SecFilterSelective THE_REQUEST "(chr|fwrite|system|echr|passthru|popen|proc_open|shell_exec|exec|proc_nice|proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posix_setsid|posix_setuid|phpinfo)" chain
SecFilterSelective POST_PAYLOAD "^PHP\:*((cd|mkdir)[[:space:]]+(/|[A-Z|a-z|0-9]|\.)*|rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |cmd|pwd|wget |lwp-(download|request|mirror|rget) |uname |cvs |svn |(s|r)(cp|sh) |net(stat|cat)|rexec |smbclient |t?ftp |ncftp |chmod |telnet |gcc |cc |g\+\+ |whoami|\./|killall |rm \-[a-z|A-Z])"
#generic command line attack
SecFilterSelective THE_REQUEST "\|*id\;echo*\|"
SecFilterSelective ARGS "\|*id\;echo*\|"
#remote file inclusion generic attack signature
SecFilterSelective THE_REQUEST "\.(dat|gif|jpg|png|bmp|txt|vir|dot)\?" chain
SecFilter "((name|pm_path|pagina|path|include_location|root|page|open)=(http|https|ftp)|(cmd|command|inc)=)"
SecFilterSelective THE_REQUEST "\.(dat|gif|jpg|png|bmp|txt|vir|dot)\?\&(cmd|command|inc|name)="
SecFilterSelective ARGS "\.(dat|gif|jpg|png|bmp|txt|vir|dot)" chain
SecFilter "\?\&(cmd|inc|name)="
SecFilterSelective ARGS "\.(dat|gif|jpg|png|bmp|txt|vir|dot)\?\&(cmd|inc|name)="
SecFilterSelective REQUEST_URI "\.php\?.*=(http|https|ftp)\:/.*\?&cmd="
#Bogus file extensions generic signature
SecFilterSelective THE_REQUEST "[A-Za-z0-9]\.(gif|jpg|png|bmp)\.txt"
#PHP remote path attach generic signature
SecFilterSelective REQUEST_URI "\.ph(p(3|4)?).*path=(http|https|ftp)\:/"
SecFilterSelective REQUEST_URI "\.php.*path=(http|https|ftp)\:/"
L
Limedrink
Guest
If the modsec rules you listed above are part of the gotroot.com ruleset, than I had them in there already.
I looked at the logs for the domain mentioned in the audit_log and it was indeed the destination for the attack.
Now comes the mystery.... That domain only has about 5 .html static pages in their account. How could any hole have been exploited?
I looked at the logs for the domain mentioned in the audit_log and it was indeed the destination for the attack.
Now comes the mystery.... That domain only has about 5 .html static pages in their account. How could any hole have been exploited?
T
Traged1
Guest
Are you sure that there are no hidden files in thier account? Do they have any Applications installed from the App Vault? Do a grep like
grep *.php /home/httpd/vhosts/domain.com/httpdocs
grep *.php /home/httpd/vhosts/domain.com/cgi-bin
grep *.php /home/httpd/vhosts/domain.com/httpdocs
grep *.php /home/httpd/vhosts/domain.com/cgi-bin
T
Traged1
Guest
Well this one is most deffinetly not in the gotroot ruleset:
SecFilterSelective THE_REQUEST "*r57shell*"
SecFilterSelective THE_REQUEST "*r57shell*"
L
Limedrink
Guest
Sorry for the late reply -- I didn't get an email notification.
There are no files in the account. I checked the cgi-bins. It's a very small static HTML site.
This is really weird.
There are no files in the account. I checked the cgi-bins. It's a very small static HTML site.
This is really weird.
T
Traged1
Guest
Check the log files for this account, maybe they uploaded it, exploited and then deleted the script?
L
Limedrink
Guest
Nope...
Big client. They wouldn't do that.
I'm out of ideas.
Big client. They wouldn't do that.
I'm out of ideas.
T
Traged1
Guest
And this account did not have any Applications installed from the PLESK APP VAULT? It is virtually impossible to upload an exploit without using scripting, so if you are absolutely sure that there was no scripting files on this account, then you must have the wrong account.
L
Limedrink
Guest
Nope. I just checked again now.
I have a feeling that more than one account had attempted to be exploited.
This is going to be difficult to track..
I have a feeling that more than one account had attempted to be exploited.
This is going to be difficult to track..
T
Traged1
Guest
Try this:
grep -r "82.114.188.55" /home/httpd/vhosts/*/statistics/logs/
grep -r "82.114.188.55" /home/httpd/vhosts/*/statistics/logs/
L
Limedrink
Guest
Results came back... Only domain that comes up is the one I had investigated before.
I figured modsec should have blocked this. I guess I'll have to go over my ruleset again.
Any other suggestions?
In my opinion, even if there is an unsecure script, modsec should have blocked it.
I figured modsec should have blocked this. I guess I'll have to go over my ruleset again.
Any other suggestions?
In my opinion, even if there is an unsecure script, modsec should have blocked it.
T
Traged1
Guest
That would depend on how the srcipt is trying to exploit if the process triggers any rulesets, and if you have the proper sig/rule enabled.
L
Limedrink
Guest
I did load the ruleset from gotroot.com again and added that one rule, as well as blocked the IP in my iptables firewall.
One of the rules that really triggers and causes problems is 300018.
It prevents any URL from being passed in another. It causes some problems even with posting a URL in a post in a phpBB forum.
Is this one safe to remove or how can I tweak it?
I'm trying to be careful and not open myself up again.
Thanks.
One of the rules that really triggers and causes problems is 300018.
It prevents any URL from being passed in another. It causes some problems even with posting a URL in a post in a phpBB forum.
Is this one safe to remove or how can I tweak it?
I'm trying to be careful and not open myself up again.
Thanks.
L
Limedrink
Guest
I was looking at my php.ini file and it seems that somehow through a Plesk update or something, some of my disabled_functions have disappeared (I can confirm through backups that the disappearance wasn't related to the attack).
I think shell_exec and a few important others were missing from disabled_functions. I've added them back in.
My question is, the gotroot.com ruleset has all of these malicious commands listed. However, could an attacker have gotten around the mod_security filter? Do you think it made a difference that shell_exec and a few others had gone missing?
I'm trying to directly source out where the hole is. I put all the gotroot.com rules in, but many sites aren't functioning correctly because functions try to pass 'http://' in even a forum posting and fail. Rule #300018 seems to be the biggest problem. I listed the code in my reply above. Would it be safe to just completely remove it? How can I get around this issue?
Thanks!
I think shell_exec and a few important others were missing from disabled_functions. I've added them back in.
My question is, the gotroot.com ruleset has all of these malicious commands listed. However, could an attacker have gotten around the mod_security filter? Do you think it made a difference that shell_exec and a few others had gone missing?
I'm trying to directly source out where the hole is. I put all the gotroot.com rules in, but many sites aren't functioning correctly because functions try to pass 'http://' in even a forum posting and fail. Rule #300018 seems to be the biggest problem. I listed the code in my reply above. Would it be safe to just completely remove it? How can I get around this issue?
Thanks!
L
Limedrink
Guest
bump-deed-ump
No thoughts on this one?
No thoughts on this one?