Jump to content

Archived

This topic is now archived and is closed to further replies.

biosfixdepot_osc

Hacking attempt in our store. Check this

Recommended Posts

Hi to all fellow oscommerce members,

 

Someone attempted to hack our store by trying to access the admin interface.

 

Heres the log.(Aug 28,2011, around 12 noon).

 

00:07:16 0 Guest 209.126.254.136 12:56:46 12:56:46 /product_info.php?products_id=163811/admin/categories.php/login.php?cPath=&action=new_product_preview

00:07:19 0 Guest 209.126.254.136 12:56:43 12:56:43 /product_info.php?products_id=163811/admin/file_manager.php/login.php

00:07:27 0 Guest 209.126.254.136 12:56:35 12:56:35 /product_info.php?products_id=593606/admin/categories.php/login.php?cPath=&action=new_product_preview

00:07:28 0 Guest 209.126.254.136 12:56:34 12:56:34 /product_info.php?products_id=593606/admin/file_manager.php/login.php

00:07:31 0 Guest 209.126.254.136 12:56:31 12:56:31 /product_info.php?products_id=596385/admin/categories.php/login.php?cPath=&action=new_product_preview

00:07:32 0 Guest 209.126.254.136 12:56:30 12:56:30 /product_info.php?products_id=596385/admin/file_manager.php/login.php

 

Trace route shows this is one user of: net.ibizdns.com

 

7 30 30 30 216.98.153.93 gi2-2.gw65-50.c5.sdcix.net

8 30 30 30 216.98.153.70 -

9 31 30 30 209.126.254.136 dish4151.net.ibizdns.com

 

 

Obviously the hacker attempted to access "admin" thinking

its the admin interface. Clever but not clever enough.

 

To all fellow members, while IP's are pooled at ISP side,

block this IP in your store.

 

 

Also, can you recommend any other anti hacking contribution

for oscommerce. We have secured our site, but just to fortify

our security layer to the maximum if possible.

 

thanks,

Share this post


Link to post
Share on other sites

Hi,

 

we get access attempts like those all the time - as long as you have the basic security fixes then they will fail.

 

We akso have Sams Anti-Hacker account Mods, PHP IDS, Sitemonitor, Anti XSS, Ip Trap and .htaccess to protect image directory + some others.

 

Fingers crossed all is well to date.


Now running on a fully modded, Mobile Friendly 2.3.4 Store with the Excellent MTS installed - See my profile for the mods installed ..... So much thanks for all the help given along the way by forum members.

Share this post


Link to post
Share on other sites

I install OsC on September 2011 and suddenly there are some attempt recorded on my server try to hack my site. How they know I install osCommerce on my server, even my wife did not know that. I guess added "powered by oscommerce" trigger that :D

 

Here my logs on September 2011. Mostly try to find myphpadmin folder.

 

 

/admin/file_manager.php/login.php (4 times)

/index.php%3fosCsid=gjavemkei13n5o58n56m30ir2gt79ega/admin/file_manager.php/login.php (2 times)

/admin/categories.php/login.php (2 times)

/phpmanager/ (1 time)

/db/webadmin/ (1 time)

/mysql/admin/ (1 time)

/db/phpmyadmin/ (1 time)

/mysql/dbadmin/ (1 time)

/qql/ (1 time)

/mysqladmin/ (1 time)

/web/ (1 time)

/~/admin/ (1 time)

/admin/phpMyAdmin/ (1 time)

/phpmya/ (1 time)

/database/database/ (1 time)

/sl2/data/ (1 time)

/webadmin/ (1 time)

/admin/pMA/ (1 time)

/3rdparty/phpMyAdmin/ (1 time)

/PHPMYADMIN/ (1 time)

/administrator/pma/ (1 time)

/cpadmin/ (1 time)

/cpanelsql/ (1 time)

/web/phpMyAdmin/ (1 time)

/pma/ (1 time)

/administrator/web/ (1 time)

/phpMyAdmin2/ (1 time)

/database/phpMyAdmin2/ (1 time)

/administrator/admin/ (1 time)

/sql/phpMyAdmin/ (1 time)

/sql/websql/ (1 time)

/3rdparty/pma2005/ (1 time)

/myadmin/ (1 time)

/db/db-admin/ (1 time)

/program/ (1 time)

/db/phpMyAdmin-2/ (1 time)

/admin/pma/ (1 time)

/db/phpmyadmin2/ (1 time)

/database/phpmyadmin2/ (1 time)

/sql/phpmyadmin2/ (1 time)

/sql/sqladmin/ (1 time)

/phpmy/ (1 time)

/roundcube/ (1 time)

/db/phpMyAdmin2/ (1 time)

/sqlweb/ (1 time)

/admin/banner_manager.php/login.php (1 time)

/phppma/ (1 time)

/sql/webadmin/ (1 time)

/pma2005/ (1 time)

/3rdparty/dbadmin/ (1 time)

/db/webdb/ (1 time)

/admin/phpmyadmin/ (1 time)

/database/phpmyadmin/ (1 time)

/sql/sqlweb/ (1 time)

/cpdbadmin/ (1 time)

/mysql/pMA/ (1 time)

/PMA/ (1 time)

/index.php%3fosCsid=gjavemkei13n5o58n56m30ir2gt79ega/admin/banner_manager.php/login.php (1 time)

/mysql/db/ (1 time)

/database/phpMyAdmin/ (1 time)

/php-myadmin/ (1 time)

/phpadmin/ (1 time)

/db/dbweb/ (1 time)

/admin/web/ (1 time)

/mysqladminconfig/ (1 time)

/shop/admin/banner_manager.php/login.php (1 time)

/~/phpadmin/ (1 time)

/admin/sysadmin/ (1 time)

/cpphpmyadmin/ (1 time)

/index.php%3fosCsid=gjavemkei13n5o58n56m30ir2gt79ega/admin/categories.php/login.php (1 time)

/SQL/ (1 time)

/sql/sql/ (1 time)

/PMA2005/ (1 time)

/db/ (1 time)

/cpanelphpmyadmin/ (1 time)

/MyAdmin/ (1 time)

/administrator/phpmyadmin/ (1 time)

/phpmy-admin/ (1 time)

/sql/phpMyAdmin2/ (1 time)

/phpmyadmin/ (1 time)

/mysqlmanager/ (1 time)

/mysql/ (1 time)

/sql/webdb/ (1 time)

/mysql/mysqlmanager/ (1 time)

/websql/ (1 time)

/cffgmqsdtgkfbczo.html (1 time)

/db/dbadmin/ (1 time)

/phpmyadmin2/ (1 time)

/3rdparty/ (1 time)

/sql/php-myadmin/ (1 time)

/administrator/PMA/ (1 time)

/sql/sql-admin/ (1 time)

/sql/phpmanager/ (1 time)

/admin/sqladmin/ (1 time)

/phpMyAdmin-2/ (1 time)

/3rdparty/myadmin/ (1 time)

/cpadmindb/ (1 time)

/admin/ (1 time)

/mysql/pma/ (1 time)

/php-my-admin/ (1 time)

/bbs/data/ (1 time)

/3rdparty/setup.php (1 time)

/database/ (1 time)

/phpmyadmin1/ (1 time)

/webdb/ (1 time)

/mysql/sqlmanager/ (1 time)

/typo3/phpmyadmin/ (1 time)

/db/phpMyAdmin/ (1 time)

/db/myadmin/ (1 time)

/db/websql/ (1 time)

/3rdparty/pma/ (1 time)

/sqlmanager/ (1 time)

/sqladmin/ (1 time)

/administrator/phpMyAdmin/ (1 time)

/sql/myadmin/ (1 time)

/administrator/db/ (1 time)

/p/m/a/ (1 time)

/~/myadmin/ (1 time)

/mysql/web/ (1 time)

/sql/phpmy-admin/ (1 time)

/cpanelmysql/ (1 time)

/phpMyAdmin/ (1 time)

/~/phpmanager/ (1 time)

/mysql-admin/ (1 time)

/3rdparty/admin/ (1 time)

/admin/db/ (1 time)

/dbadmin/ (1 time)

Share this post


Link to post
Share on other sites

Hackers deploy bots that test EVERY website looking for vulnerabilities. It is not personal, it is a broad attempt to find sites they can exploit. With a properly secured site there is nothing to worry about.

 

 

 

Chris


:|: Was this post helpful ? Click the LIKE THIS button :|:

 

See my Profile to learn more about add ons, templates, support plans and custom coding (click here)

Share this post


Link to post
Share on other sites

Another hacking attemp. Using little script to log it, now I can see how it was blocked.

 

- OSCSEC means blocked by osc_sec addon

- BADCALL means blocked by .htaccess configuration

 

 

//IP | HOST | DATETIME | BLOCK-BY | USERAGENT

91.121.149.31 | ks357488.kimsufi.com | 2011-10-06 04:34:17 | OSCSEC | Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4
91.121.149.31 | ks357488.kimsufi.com | 2011-10-06 04:34:18 | BADCALL | Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4
91.121.149.31 | ks357488.kimsufi.com | 2011-10-06 04:34:57 | BADCALL | Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4
91.121.149.31 | ks357488.kimsufi.com | 2011-10-06 04:43:48 | OSCSEC | Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4
91.121.149.31 | ks357488.kimsufi.com | 2011-10-06 04:43:49 | BADCALL | Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4
91.121.149.31 | ks357488.kimsufi.com | 2011-10-06 04:46:56 | BADCALL | Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4
91.121.149.31 | ks357488.kimsufi.com | 2011-10-06 04:46:57 | BADCALL | Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4

Share this post


Link to post
Share on other sites

Maybe we should create a pinned thread like this one where anyone can report the IPs or Hosts that try to launch the attack... so other users get noticed. Or, we can follow up by reporting them to hosting provider/ISP where it's located.

 

@zaenal

Share this post


Link to post
Share on other sites

There are only a limited set of vectors that the attackers are using to seed sites with shell code, but unlimited amounts of proxy servers that attackers can use to parse the attacks onto sites. So the logical way to deal with the attacks is to identify the hole in the security gate and fix it.

 

The actual fix => http://forums.oscommerce.com/topic/380144-fixing-the-admin-login-bypass-exploit/

Once patched the attacks will still roll in, and will do for as long as the majority of users of obsolete versions of osCommerce continue to run sites that are not properly cleaned out and patched.

 

There certainly are a regular list of proxy servers that are being used and I suppose there is no harm in blanket banning them. But many of the sites being used to parse file content are in themselves just infected websites by the same type of attack. They will eventually either be shut down by the WSP or the owners, or cleaned.

 

User-Agents: well they can be spoofed so there will always be new spider names as long as the HTTP Header User-Agent remains as it is now. Yes there are a list of regular spiders that are a complete waste of bandwidth and they should be blocked at the gate, but at the end of the day once the site is patched, the main attack will come to nothing.

 

What osC_Sec does in its default setting is (along with the actual patch of the security hole like that in the above URL) reduce the CPU usage of each attack to the lowest usage by calling a 403 permission denied. The reason I say that is for example, calling www.somesite.com/index.php/login.php on a correctly patched site that is not using osC_Sec or other script to catch the actual request, still results in a full page load, albeit, the correct page, resulting in correct calls to the database, images to be loaded etc.

 

Match that against the CPU usage and bandwidth usage of a 403 redirect.

 

and suddenly there are some attempt recorded on my server try to hack my site. How they know I install osCommerce on my server

 

The search bots look for more than just the Powered by statement, they will also look for common file names, once pages are loaded they will be able to tell from the cookie name osCsid and the existance of a number of other files that are specific to osCommerce that they are viewing an osCommerce website.

 

I was able to prove this myself by loading a regular Wordpress site with the osCommerce cookie. No sooner had google spidered the site did the attacks shift from the regular vectors targetted at Wordpress addons to what one would expect to be aimed at an osCommerce site.


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

Hi Taipo,

 

I use osc_sec and that the only security addon I use alongside 'some block of my ht.access' configuration. But I made a litle change to osc_sec when dealing with 400 redirection (just for logging as above).

 

My ht.access look like:

 

 


# 400 + 403 ErrorDoc & Redirect
# Note: virtual_path_to_triger_error_400/403 did not exist, it's just for triggering error

ErrorDocument 400 /secret/path/to/log/400error.php
Redirect 400 /virtual_path_to_triger_error_400

ErrorDocument 403 /secret/path/to/log/403error.php
Redirect 403 /virtual_path_to_triger_error_403

SetEnvInNoCase The_Request (some.*very.*(bad)?request(.*))  TOTALBLOCK

SetEnvInNoCase The_Request (some.*very.*(suspicious)?request(.*))  BADCALL
SetEnvInNoCase Request_URI (some.*other.*(suspicious)?file(.*))  BADCALL

Deny from env=TOTALBLOCK

#deny from some IPs
Deny from 999.999.999.999

RewriteMode on
RewriteBase /

# AUTO TRIGGER E=400 FOR BADCALL using path Redirect 400 above
# Apache will issuing header 400 bad request while internally redirect it to /secret/path/to/log/400error.php

RewriteCond %{ENV:REDIRECT_STATUS} !=400
RewriteCond %{ENV:BADCALL} >0
RewriteRule .* /virtual_path_to_triger_error_400 [L]

...

 

As for osc_sec, I simply redirect it to /virtual_path_to_triger_error_400 without send header 400 in PHP, because Apache will issuing it.

 

So, when the users come, it will be handled in the "first gate" by ht.access TOTALBLOCK and BADCALL env. But if they pass the "first gate" there is osc_sec in the back. And because ht.access BADCALL env and osc_sec using same E=400 handler, now I can see that some attack passed the "first gate" and being hadled by osc_sec in the back, as shown in column "BLOCK-BY" in my log.

 

//IP | HOST | DATETIME | BLOCK-BY | USERAGENT
91.121.149.31 | ks357488.kimsufi.com | 2011-10-06 04:34:17 | OSCSEC | Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4
91.121.149.31 | ks357488.kimsufi.com | 2011-10-06 04:34:18 | BADCALL | Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4

 

You right about the IP, Host or user-agent. Maybe it's better to log query string instead of host and user-agent, so we can evaluate the trend of the attack.

 

... But many of the sites being used to parse file content are in themselves just infected websites by the same type of attack. They will eventually either be shut down by the WSP or the owners, or cleaned.

 

User-Agents: well they can be spoofed so there will always be new spider names as long as the HTTP Header User-Agent remains as it is now.

 

 

At least, I have to say your osc_sec is really rock! Thank you.

 

 

@zaenal

Share this post


Link to post
Share on other sites

I know there are a couple of htaccess based security addons in the addons repository, most seem to have been abandoned by their authors, but many are still used by site users and developers of custom packaged versions of osCommerce.

 

If you haven't done so already you might want to also take a look at the BULLETPROOF plugin for Wordpress and see if there are some ideas in there that might be useful as well in your htaccess.

 

That is where I was hoping the current htaccess addon authors might have taken their addons to but sadly they have been talked out of further developments by other members.

 

Bulletproof not only has some excellent use of query blacklisting but also has a very helpful install process => while being a bit clunky.

 

The principles used could well be applied to a similar addon for osCommerce, at least to work on the root directory if you had the time and inclination to take a look at it.

 

Example Code from Bulletproof:

 

# FILTER REQUEST METHODS
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
# QUERY STRING EXPLOITS
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\:  [NC,OR]
RewriteCond %{QUERY_STRING} http\:  [NC,OR]
RewriteCond %{QUERY_STRING} https\:  [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(execute|exec|sp_executesql|request|select|insert|union|declare|drop|delete|create|alter|update|order|char|set|cast|convert|meta|script|truncate).* [NC]
RewriteRule ^(.*)$ - [F,L]

 

 

I am not suggesting that all of this is applicable to osCommerce as some of those blacklisted items above may break the way some addons work. But I am of the opinion that if it can be blocked at the htaccess level then that is the most efficient way in terms of CPU and bandwidth usage.

 

Either way at the very least there are a number of ideas in Bulletproof that could also be applied in an htaccess file for the root directory of an osCommerce website.


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

×