Endpoint Protection

 View Only

Vulnerabilities in Malicious Code – Owning the Owners, Part I 

Oct 17, 2008 01:52 PM

Volume XIII of the Symantec Internet Security Threat Report highlighted the fact that the number of vulnerabilities affecting web applications is growing. However, these security issues are not only affecting common legitimate applications, but also malicious code. In fact, a source code analysis of several samples revealed serious vulnerabilities that could, ironically, open security holes in programs designed to compromise other users' security.


The investigation originated while analyzing a phishing kit (that is, a package containing a clone website of a financial institution) including a PHP page that was neither called nor apparently used by the fraudster to accomplish his task. The phishing kit contained the following code:

 

 

 
The code does nothing special except getting a parameter and using its value within an include() function to load another PHP file. However, it could also be used to force the application to load a piece of remote code and then execute it in the context of the server on which the caller application resides. By exploiting this scenario, it may be possible to trigger a vulnerability called "remote code execution" that could allow gaining access to the server.


But, why has this vulnerable code has been included and distributed within several phishing kits? Probably the fraudster hopes that a system administrator will ignore the file because it has a familiar name, even after discovering that a server has been compromised. This would allow the fraudster to maintain access on the server and re-deploy the web pages used for the phishing attack.


On the other hand, it is not uncommon that the person building the kit is not the one who is supposed to use it. So why not consider the hypothesis of a back door intentionally left behind in order to allow the writer access to all the servers compromised by the people using the kit? This could help the malware author save time and effort since a huge amount of systems could be easily conquered without the need of identifying how to compromise them.


The existence of back doors in malicious software is not unusual. Take, for example, the time malware started using IRC as a control channel, when a specimen called SlackBot joined an undocumented channel under the control of the author. This allowed the virus writer to control infected systems at no additional cost.


Recently, a new version of the vulnerable file discussed above has been identified, with some changes in the code:

 

 

 

This time, the script includes a legitimate website when provided with the vulnerable parameter, not the PHP code the caller is willing to execute. Indeed, a new parameter should be used in order to emulate the original behavior: the new piece of code has probably been added in order to hide the vulnerability still keeping the door open.

Message Edited by SR Blog Moderator on 10-23-2008 07:52 AM

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.