Website hack attempt identifier (online calculator) questions, comments

[SteveW]

This thread is for bug reports, feature suggestions, other feedback, or questions about my "Hack Attempt Identifier online calculator" that identifies hack attempts in website access logs and classifies them by type.

I would also be interested to know if there are classes of hack attempts that the calculator is failing to catch, or if it is misidentifying too many non-malicious requests as suspicious.

[emmdee]

Hi there
I've been using the "Hack Attempt Identifier online calculator" for a little while.
Due to a poorly written component on a joomla site, I was successfully hacked with (log file)

200.63.47.57 - - [16/Jun/2012:08:50:41 -0600] "POST /administrator/components/com_maianmedia/utilities/charts/php-ofc-library/ofc_upload_image.php?name=.598.php HTTP/1.1" 200 31307 "-" "-"
200.63.47.57 - - [16/Jun/2012:09:44:33 -0600] "POST /administrator/components/com_maianmedia/utilities/charts/php-ofc-library/ofc_upload_image.php?name=.599.php HTTP/1.1" 200 31307 "-" "-"
etc....
ending with
200.63.47.57 - - [16/Jun/2012:12:58:43 -0600] "POST /administrator/components/com_maianmedia/utilities/charts/tmp-upload-images/.599.php HTTP/1.1" 200 31538 "hxxp://www.mysite.com/administrator/components/com_maianmedia/utilities/charts/tmp-upload-images/.599.php" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14"
I guess because the request is POST it cant be flagged in your identifier?
These guys got straight into Admin no probs.
rgds
emmdee

[reason for edit by SteveW: made link to ".599.php" unclickable]

[emmdee]

BTW
599.php is encrypted and I have no idea how to decrypt it.
Can anyone help?
I want to see what it contains
rgds
emmdee

[SteveW]

Hello emmdee,

It looks like the first two POSTS use the image upload feature of the Joomla component to upload 2 hidden PHP scripts (instead of an image). I would guess those were probably web shell scripts that gave them a web interface (web page) where they could then modify files in the site.

Then the "ending with" request is a POST request to the shell script itself, probably telling it to execute a command.  

(At least) two vulnerabilities allowed this to succeed:

1) The upload feature should have detected that the uploaded file was not an image, and blocked the upload (or added an image-type extension to make it unrunnable, and/or assigned it a new random name that the person who made the upload could not know). That was the weakness of the plug-in.

2) The .../tmp-upload-images/ folder that receives uploaded images should not be accessible by web. That is, a file uploaded to that location should not be able to be requested by a browser. A generic way to do this is with an .htaccess file in that folder that says

order allow,deny
deny from all

but the instructions for the component/plugin (or for Joomla itself) might have a more specific recommendation.

----

The hack attempt identifier tries to flag requests that are definitely suspicious under all circumstances. Although the above requests are clearly suspicious when studied by a person, they don't have any distinguishing feature that the simple automated scanner could say is always suspicious every time something like it appears in a log file.  

This looks like a targeted attack aimed at that specific vulnerability of that specific Joomla plug-in. Unfortunately, identifying such a specific attack is beyond what the scanner is currently designed to do, but if I get some more reports of similar things, I might be able to identify common features and turn it into a rule for the scanner.

Although POST requests do appear in the log file, the data submitted with POSTs does not, so there is less information available for the identifier to examine for suspicious content.  

----

The scripts could be base64-encoded, or they might use some other encryption method. (Of course, remove both of them from the site right away, which I assume you've already done.) An encoded script generally must have the key to its decryption contained in it, else it's useless.

----

That was good detective work identifying those requests as the ones that accomplished the hack.

[emmdee]

Hi SteveW
In this case they got a 403.
 
188.143.232.144 - - [14/Jul/2012:08:28:09 +1000] "GET /components/com_datsogallery/sub_votepic.php?func=vote&user_rating=5&id=1 HTTP/1.1" 403 587 "hxxp://www.google.com/" "'and (select 1,2) = (select count(*),concat( (select username from jos_users limit 0,1) ,0x3a,floor(rand(0)*2)) x from (select 1 union select 2 union select 3)a group by x limit 1)and'"

It is not pinned in the Identifier however.
Thought you may be interested.
Rgds
emmdee

[Reason for edit: hxxp to deactivate probably unintentional link.]

[SteveW]

Thank you. I've put that on my TODO list for the next version of the script.

That's an SQL injection attempt in the user-agent field. I've not seen that before and at the moment can't think of any reason somebody would try to do that or what they're expecting it to do.