DB Driven Website Hacks

killo · 2010-02-01T08:39:30+00:00

I have analyze the website haking problem that is currently happening, and i manage to find something in common these website have in design 1. http://www.tzuk.com/administrator/ 2. http://www.tra.go.tz/administrator/ 3. http://www.globalpublisherstz.com/administrator They are all database driven, below are tips for the Web admins which will help them to avoid such attaks The information provided in this document is critical to stopping these attacks and must be taken into immediate consideration. As many of you know there has been a large surge of hacking activity targeted at Joomla and Mambo powered websites. The attackers are using various exploits in 3rd party add-ons to compromise websites. Some attacks seem as simple as defacement, others are much worse. I advise you all to take this advisory into immediate consideration if your website shows any sign of compromise or attempted compromise! The majority of the problems are caused from 3rd party components not properly checking that they are being called from Joomla and continuing execution if they are requested directly. This is not proper behavior. It is very important that 3rd party components/modules/etc check to make sure they are being requested by Joomla itself. All .php files of 3rd party add-ons should include the line below as the first command executed: Code: defined( '_VALID_MOS' ) or die( 'Restricted access' ); This applies to components/modules/mambots under the Joomla root directory and also those under the Administrator directory. If a .php file from a 3rd party component does not include this line it could leave your system at risk! When we first started getting reports of these attacks they seemed pretty superficial, usually just overwriting configuration.php but now that I have had more time to analyze the logs, talk to users, and investigate the various commands and requests I have realized that some of the attackers are using more advanced scripts and performing increasingly dangerous commands. Some of the files I have investigated have turned out to be Perl scripted worms and others are PHP scripts like "Redworm" and various other file browsing and alteration tools. These files are usually downloaded into the servers /tmp directory or Joomla's cache or media directories, executed and then in the case of the Perl scripts, deleted in order to make discovery more difficult. It is imperative that these scripts be killed and removed immediately, especially the Perl worms as they are capable of launching various DDoS (Distributed Dial of Service) attacks as well as performing search engine queries to scan for and attack other vulnerable websites. The Perl worms are the scripts that I am particularly worried about as they are capable of connecting back to the attacker's IRC network to wait for commands from the attackers. From that point your website's server could be used to launch various forms of DDoS attacks as well as attack and infect other vulnerable websites. The Perl scripts also appear to be rather difficult to kill as they set themselves up to ignore interrupt and kill signals as well as renaming their own process-name to an empty string or sometimes to "httpd" making it more difficult to detect their presence. If your website has been compromised or you have noticed attempted attacks in your log files you should report this activity to your Hosting Provider/System Administrator immediately so they can investigate the attacks and assess whether the server has been compromised or a worm or other hacking tools have been downloaded to it. If you are the system administrator I suggest you very carefully recursively check your Joomla directory as well as the servers /tmp directory. Additionally, you should check for any rogue Perl scripts using ps -aux | grep perl or similar. If you are of the extra cautious persuasion, which in my opinion is warranted in this situation, I would check for rogue cron scripts and then give the server a reboot just to make sure there are no rogue Perl scripts running on it. It might also be worth using a root kit locator or other similar tool to assess the security of the whole server and verify that it has not been rooted. Additionally, I recommend you (compellingly) request that your host disable PHP's register globals (RG), if they are still enabled, as this setting creates more opportunities for small bugs to be taken advantage of, often turning them into major security issues. Furthermore, it has been recommend that users edit globals.php in the Joomla root directory. On line 12, change: Code: define( 'RG_EMULATION', 1 ); to Code: define( 'RG_EMULATION', 0 ); This modification will tell Joomla not to emulate the behavior of register globals and prevent the potential for Joomla to open up more security issues. (NOTE: I am awaiting an evaluation from the core team as to whether Joomla's RG emulation is safe to use) Lastly, it is imperative that you take care of any files that do not have the proper "VALID_MOS" check, again, the line below should be in ever .php file of every third party component. Code: defined( '_VALID_MOS' ) or die( 'Restricted access' ); If you had a component installed that is known to be vulnerable but have since uninstalled it, please make absolutely sure that the files have been physically removed from the directory structure as sometimes this does not happen due to file permission issues. It is possible for a 3rd party add-on to appear uninstalled from within Joomla but still reside on the server. If this happens, your server is still vulnerable! Hope this helps

Thread starter killo
Start date Feb 1, 2010

killo

JamiiForums uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Accept Learn more…

Back

Top Bottom

Forums

New posts

DB Driven Website Hacks

killo

JF-Expert Member

Our Community

Regional Communities