The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

How to block a POST Text string using mod security ?

Discussion in 'Security' started by fuzioneer, Oct 5, 2013.

  1. fuzioneer

    fuzioneer Well-Known Member

    Joined:
    Dec 12, 2003
    Messages:
    98
    Likes Received:
    0
    Trophy Points:
    6
    I have mod sec installed on my cpanel server and I have installed common rules etc, but i want to block a defacement bot which is modifying files through an as yet unidentified flaw in a file somewhere

    an identifying part of the script it appends to files contains the text string "a9a007"

    so i thought it should be possible to block this in query urls etc using mod security as an interim measure ?
     
  2. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Append this to your modsec config:
    Code:
    SecRule REQUEST_METHOD "post" "deny,chain,status:500,id:9379635"
    SecRule REQUEST_HEADERS "a9a007"
    
    This is assuming that the POST data is not encoded using base64 or something. You could add this to cover that:
    Code:
    SecRule REQUEST_METHOD "post" "deny,chain,status:500,id:9379636"
    SecRule REQUEST_HEADERS "a9a007" t:base64Decode
    
    How you should really track this down, is run 'stat' on one of the modified files. Take the exact change and modify times provided, and find those times in the domains apache access log (domlog). This will really answer how it's happening, the file POSTed to at the time the other files were modified is the one doing the injection. That said, the modsec rules above might stop it. I would not recommend leaving these in place permanantly as it will deny any POST request with the string "a9a007" anywhere in the request headers.
     
  3. fuzioneer

    fuzioneer Well-Known Member

    Joined:
    Dec 12, 2003
    Messages:
    98
    Likes Received:
    0
    Trophy Points:
    6
    thx added the rules

    Having real problems trying to find the source, initially the hacker was uploading somehow a file to our server in a directory, the file was randomly named and contained a series of php code to find flaws in security (none disabled functions in php.ini etc)

    We found this file, disabled any functions it might use

    We are still getting attacked "successfully" once or twice a week with redirector code being added to .php and .html files on our site !!!
    (Note nothing since adding the mod sec extra rules but this is very early days)

    trying to find how they are gaining access and not really getting anywhere
    checked messages log but nothing happening around the time of attacks
    checked domain logs but nothing happening at time of attacks

    any other pointers of where / how to check ?
     
  4. fuzioneer

    fuzioneer Well-Known Member

    Joined:
    Dec 12, 2003
    Messages:
    98
    Likes Received:
    0
    Trophy Points:
    6
    the only facet of info I have found is from an older attack where an ip address was continuously over a very short timeframe so obviously a script accessing our forums (an old derivative of phpnuke / phpbb 2)

    http://ourdomain.com/ftoptitle-137109.html&sa=U&ei=JBgnUdXtNaTg0QHZw4CICg&ved=0CLsBEBYwMTisAg&usg=AFQjCNG0v848-sF24eoGCwqcmgJywrALNA" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"

    this may or may not be a red herring though
     
  5. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Nothing stands out to me from that request.

    What I would do in your case, aside from modsec rules, is go into the cPanel account and enable the "Raw Access Logs" archiving.

    As soon as a file gets affected again, before restoring or fixing it, just 'stat file.php' from a root shell. Note the output for Change and Modify. Technically Modify can be spoofed, however, "Change" cannot (at least, not on a system that is not root-level compromised).

    Assuming this is a webapp hack (and they don't have your FTP password or something), when you get the file stats, you will be able to match a request to that exact time in the archived Apache access logs (located in /home/$username/logs). If the times don't match up then you need to start checking your FTP logs and cPanel access log for file manager access.
     
Loading...

Share This Page