Please, read out !Most people think that hackers are computer criminals. They fail to recognise the fact that criminals and hackers are two totally different things. Media is responsible for this. Hackers in reality are actually good and extremely intelligent people who by using their knowledge in a constructive manner help organisations, companies, goverment, etc. to secure documents and secret information on the internet.
Showing posts with label PHP Injection. Show all posts
Showing posts with label PHP Injection. Show all posts
PHP Script Injection Exploit in WordPress 2.7.11 comments
I experienced my first site hack this weekend thanks to a warning message from Kaspersky Internet Security. When I logged into the admin panel of WordPress, it detected the gumblar.cn/rss/?* in my Firefox browser. After a little Google research, I found out that this was a PHP script injection that had found its way into many of the PHP files of my site, including the index.php and index-extra.php of the wp-admin folder, functions.php in the wp-includes folder, index.php in the wp-content folder, custom-functions.php in the Thesis theme’s custom folder, and even the main wp-config.php file in the root. The code was in the beginning of these php files, and started out as follows:
gumlar-exploit Even after removing the code from the above pages, I still encountered the same warning message from Kaspersky, which meant the injection was in even more php files. I decided that checking each php file was going to take a lot of time, so I downloaded a fresh installation of WordPress 2.7.1 and the Thesis Theme. I only saved my original wp-config.php and custom-functions.php files after removing the injected PHP script because of the custom settings and code within them. After the fresh installation, I still had the malware code on my site. The final folder that I didn’t check was my plug-ins. Sure enough, after I deleted all of my plug-ins, my site was finally free of the malicious code. In summary, these were the steps I took to remove the code from my site, which took about two hours: * Saving the original wp-config.php and custom-functions.php from Thesis after the removal of the script in the top line of the PHP * Downloading and installing a fresh copy of Wordpress 2.7.1 and my current theme, Thesis 1.5 * Deleting all plug-ins and re-installing them from inside the WordPress admin panel * Changing my WordPress and FTP login passwords to (hopefully) protect my site from further attacks I can say with certainty that if I had not upgraded earlier in the week to the new WordPress 2.7.1 and Thesis Theme that this cleanup process would have been much more difficult, simply because I would have been forced to do the full upgrade in the middle of dealing with the hack would have been even more stressful. Plus with previous WordPress versions, I would not have been able to simply search and install the new plug-ins through the admin panel – it would have been the download, unzip, upload, and activate. And with any other theme, I would have certainly lost my custom coding in all of the theme template files without a recent backup. Fortunately with Thesis, all of the custom PHP coding is handled in the one custom-functions.php file. I believe that the code was only on my site for more than four hours, as I had worked on my site earlier around 7pm, and did not receive the first warning message from Kaspersky until 11:30pm. Nonetheless, this goes to show that you should always make sure your antivirus and spyware programs are up to date, and that any coding customizations to your site should be saved often. Any website, trusted ones and even your own, is susceptible to unwanted surprise attacks. Script Exploits Overview0 commentsFrom the perspective of a browser, a Web page is simply a long string of characters. The browser processes the string sequentially, displaying some characters while interpreting other characters, such as and according to special rules. If a malicious user can insert some of those special characters into a page, the browser will not know that the characters are not supposed to be there, and it will process them as part of the page. A simplistic script exploit might work as follows. If an application allows users to post comments about the latest movies for other users to read, the exploit steps might be:
There are other ways that malicious users can exploit script. Most script exploits require the application to accept the malicious input and inject it (or echo it) into a page where it will be executed by the browser. The potential damage from such an exploit depends on the script that is executed. It can be trivial, such as an annoying message that pops up in the browser. But it can also do serious damage by stealing cookies, stealing user input (such as a password), and, if Internet security is lax, running native code on the user's computer.
Subscribe to:
Posts (Atom)
Who am i ???![]()
Blog Archive
FollowersShout here! |