Symantec Security Alerts
Print version
PDF version
Reactive Phishing Defenses - Part 2
My previous blog article was intended to highlight two new features observed in a number of phishing kits that held the aim of making the lives of security analysts more difficult. I want to now focus my attention on another trick that has been used in phishing kits in order to protect the attack against a technique called "dilution." Dilution is a method of providing a certain amount of false credentials, names, account numbers, and other personal information to a phishing website. With this technique, real credentials are diluted in a sea of false data, making the fraudster's job harder.
There are several different kinds of dilution strategies, classified by the type of data provided to the phishing site:
- Properly Formatted Data: a large amount of properly formatted data is submitted. This process avoids the drawback of the first dilution type, but still fills up the collection point.
- Tag Data: this time, the fake data submitted is indeed valid and accepted by the institution's website. The injection of this data allows financial institutions to more easily track criminals and gain additional forensic information.
Fraudsters are aware of these techniques and are continuously trying to optimize their attacks and thus their profits. As a proof of concept, shown below is a piece of PHP code revealed from a phishing attack that is intended to check the validity of the credit card number provided by the user according to card number conventions:
Figure 1. Fraudster checks for a valid card number
After performing this check, the fraudster tries validating the card number by using the Luhn algorithm (figure 2). If both conditions are met (the card number appears to be correct and the Luhn algorithm is verified) the information is delivered to the drop box. This approach makes the Random Data Dilution strategy described above useless, because invalid data won't be accepted.
Figure 2. Fraudster using the Luhn algorithm
Even if Random Data Dilution is useless against phishing sites implementing the tricks described above, the Properly Formatted Data Dilution continues to work because the provided data passes both tests described above and is correctly delivered to drop boxes. However, we have recently observed some phishing kits implementing a new feature that helps fraudsters fight against even the Properly Formatted Data Dilution strategy. The piece of code in figure 3 (below) shows one of these tricks, which checks to see if the credentials provided by the user are indeed valid. It has been implemented by submitting the credentials to the original website and then identifying specific patterns in the response page in order to verify their validity. Only after this validation step is other information requested-such as credit card numbers, cvv2/cvc2 codes, or sometimes even the entire battleship card-and if provided, then delivered to the fraudster's drop box.
Figure 3. User credentials validation
This technique actually makes the second type of dilution ineffective, because fake credentials, even if properly formatted, are no longer accepted. So far, the evidence collected demonstrates how some dilutions techniques may be avoided through the validation of both the card number and the credentials provided. However, "tag data" is a very efficient strategy, allowing financial institutions to more efficiently monitor and identify fraudulent activities. By using this means of detection, and once the source of the attacker is known, organizations can correlate this information with login records in order to identify other compromised accounts and take reactive countermeasures in order to prevent the loss of money in a much more efficient way.
Message Edited by SR Blog Moderator on 10-27-2008 11:05 AM
MS08-067 Exploited in the Wild
I am sure by now that many have read about Trojan.Gimmiv exploiting the new MSRPC vulnerability. While we have not seen any evidence of Gimmiv replicating by itself, we analyzed a second component, related to Gimmiv, which is able to exploit the vulnerability patched on Wednesday. Interestingly though, Gimmiv exploits a 2006 vulnerability described in MS06-040 along with its MS08-067 exploit. Because of the way that Gimmiv does this, Symantec IPS definitions circa August 2006 will block this attack.
Because the MS08-067 vulnerability can be exploited without triggering the 2006 IPS signature, we strongly recommend that all users run LiveUpdate to get the latest signatures. This will add specific coverage for MS08-067 for Symantec Endpoint Protection (SEP) and SCS customers as well as all NAV/NIS/N360 customers. It is quite likely that this vulnerability will be used by a widespread worm in the near future.
The vulnerability defined by MS08-067 will be detected by the following IPS signatures:
The attack used by Gimmiv will be detected by the following 2006 signatures first, however:
Symantec AntiVirus will also detect the files associated with this attack as Trojan.Gimmiv.A.
Web Attacks Using Microsoft Help and Support Center Viewer
Public examples of this new attack typically employ file-overwrite and file-download vulnerabilities in ActiveX controls to download a malicious file onto the target machine. In the past, attackers were able to download files without much difficulty, but until recently the options for attackers seeking to have malicious programs executed on a victim's system were limited. In order to execute a malicious file on an affected computer, attackers generally needed to place the file in one of the load points such as the "Startup" directory in Microsoft Windows, or use social-engineering or other attacks to have the file executed. This presented a problem for attackers since they were forced to wait for the victim to reboot their machine or execute the file, which could take some time and therefore increase the chances of discovery and failure of the attack.
In some recent exploit developments, we observed that it is possible to utilize the "Microsoft Help and Support Center Viewer" application in conjunction with a file-overwrite or file-download issue to immediately execute a malicious file on a vulnerable computer. A typical attack scenario using this technique takes place like this:
1. An attacker creates a malicious Web page that uses an arbitrary file-overwrite issue to place their malicious binary on the victim's machine. The attacker then tricks their victim into visiting this page.
2. When the victim visits the page, the attacker exploits the same vulnerability to overwrite one of the Help and Support Center's HTML files, such as "C:\WINDOWS\PCHealth\HelpCtr\System\sysinfo\sysinfomain.htm." The attacker overwrites this file with script code that performs malicious actions on their behalf.
3. Once the previous steps have been carried out successfully the attacker redirects the victim's browser using the "window.location" method such as "window.location = hcp://system/sysinfo/sysinfomain.htm."
4. The Microsoft Help and Support Center viewer, which handles "hcp://" links, runs the attacker's script, which in turn executes their malicious binary.
What makes this attack remarkable is that because the Help and Support Center can run script commands in the context of the local user, attackers can utilize inherent ActiveX controls not marked as "Safe for Scripting" to execute a malicious binary that they have already placed on the vulnerable user's computer.
It's worth noting at this point that in order for this attack to be successful the user must be logged in with Administrator privileges. However, since the standard Windows XP setup on stand-alone systems often has Administrator privileges enabled, and most users don't follow best practices to set up a limited user for general use, this attack may be possible on a large number of machines.
The DeepSight Threat Analysis team has also created the following video which demonstrates an attack of this type:
Message Edited by SR Blog Moderator on 10-23-2008 07:38 AM
A Guide for Beating Phishing Attacks
Once you click the link you are taken to a website that looks like the real website of the company the email is purporting to be from. But it is not. You enter your details and the phishers now have the information they need to steal your identity. What just happened? The phishers lured you in on false pretenses and stole your account information and passwords, which will allow them to buy things with your money and potentially damage your credit history.
By utilizing the following steps it is possible to keep safe from phishing:
- Know that your bank will never ask you to confirm your details via email. So if it looks like it's coming from your bank and asks you to confirm details, you should not click it. Remember that you can always call your bank directly and ask them about any email you receive. They will know if they've requested that you update your account details.
- Is it addressed to you? It is common for phish messages to begin with salutations such as "Dear Valued Customer" and "Please Confirm" instead of your actual name. If it's not addressed to you, don't click it.
- Rest your mouse pointer on the URL in the body of the email. The real destination of the URL will be displayed. If the URL looks like a different name than the name of the company, don't click it.
- Look for spelling mistakes. If there are spelling mistakes, or the email doesn't look professional, don't click it.
- Get security software that includes anti-phishing and identity protection features. Symantec has products that do just this.
- Don't use links in emails to get to websites. Instead, manually type in the URL destination into the address bar of your Web browser. It may take a little longer, but you will be more effective at protecting your identity.
Message Edited by SR Blog Moderator on 10-22-2008 04:48 AM
The Security Response Blog Will be Changing its RSS Feed
This is an informational blog for the readers of the Security Response
Blogs, particularly those that prefer to use an RSS client to keep
up-to-date with our articles.
This Thursday morning (Pacific Daylight Time), October
23rd, we will switch over our RSS feed to a new URL. Please be sure to
update your RSS feeds to use the new URL:
http://www.symantec.com/xml/rss/srblogs.jsp
The URL for our main page remains unchanged, please add it to your bookmarks:
http://www.symantec.com/business/security_response/weblog/
We hope you can visit very soon!
Message Edited by SR Blog Moderator on 10-21-2008 04:02 AMVulnerabilities in Malicious Code - Owning the Owners, Part I
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 AMKeep It Simple Stupid
When someone is asked to present an analysis of a modern threat, the explanation often becomes complicated very quickly. Here I will present a brief analysis of a Trojan that uses the KISS approach-"keep it simple, stupid."
The reason for this article is that upon hearing what I do for a living, people often ask, "why do people write viruses?" After explaining the various dangers of using a computer online, people often follow up with the following question: "I don't bank online, I don't shop online, etc... so why would someone want to attack my computer?" This article is dedicated to anyone who has ever sat beside me on a plane/train/automobile and asked me these questions. ;-)
The Trojan that is shown below will help to explain why a computer is still valuable to an attacker, even if that computer contains no sensitive data. The Trojan presented is a Trojan that does not steal private data (such as banking credentials, etc.); however, it does contribute to one problem of online computer usage that everyone is familiar with-spam.
What is presented here is nothing new or groundbreaking. Anyone up-to-date on security will be familiar with these Trojans. These Trojans have been around for some time now, but what caught my attention was the simplicity of this particular sample and how easy it is to understand it-perfect for a simple explanation of how these types of Trojans operate. (No encryption, no obfuscation, no time delays or crazy features.)
The threat is called Trojan.Spamthru. It is a threat that simply runs silently in the background whenever an infected computer is online, and its goal is to continuously send spam. When Trojan.Spamthru is executed it immediately connects to a control server to receive configuration data. This configuration data is received as plain text and consists of the following variables:
- A generic email template
- A list of first names
- A list of last names
- A list of subjects
- A list of domains
- A list of URLs
- Other data that is not essential to this article
This is the template that was received the first time the Trojan was executed:
Date: {DATE}
From: {$FNAME$} <{$FNAME$}_{$LNAME$}@{$DOMAIN$}
To: {TO}
Subject: {%SUBJECT%}
This message is intended for {TO}:
*SAVE! SAVE! SAVE!*
*TOP SELLING {SCRAMBLE:MEDICATIONS}*
- Available without a prescription
- Our brands simply cost less
- Fastest processing times online
http://www.{$URL$}
{$WIKIARTICLE$}
Use http://www. {$URL$}/a.php for removal
Anything within curly brackets (shown in bold) in the above template will be replaced with appropriate data before the spam email is sent. The Trojan knows what appropriate data to use by checking the lists that were previously received as part of the configuration data.
For example, in the configuration data downloaded, the variable {$FNAMES$} refers to a list of 5,494 first names:
mary
patricia
linda
barbara
elizabeth
jennifer
maria
susan
margaret
etc.
Before the Trojan sends a spam email it will replace all occurrences of {$FNAMES$} in the template with a randomly chosen first name from the list above. The same procedure is followed for all of the other variables in the template:
{$SUBJECTS} = a list of 189 different subjects:
Leading Online Pharmacy For Generic Medication
You Are Invited To The Leading Online Pharmacy For Generic Medication
Save money by buying generic brand medications
Generic leading brand weight-loss products
Generic Medication For Everyones Needs
No prescription is required for our medications
Get your medications without a prescription
Huge invetory of generic medications
Substantial savings on your medications
etc.
{$DOMAINS} = a list of popular webmail companies and ISPs to target for sending spam to.
{$URLS} = a list of spam URLs that sell fake products:
rateyaec.com
jeailkic.com
cosatamm.com
kralpeal.com
chinmich.com
liatioslo.com
mistatok.com
slapoute.com
inmidels.com
etc.
The Trojan chooses a random entry from each of these lists, inserts those entries into the template, and then sends a spam message. It then repeats the process while choosing new random entries from the lists.
Here is a sample mail that the Trojan was attempting to send:
From: booker
To: , , ,
Subject: Generic Medication For Everyones Needs
This message is intended for , , , :
*SAVE! SAVE! SAVE!*
*TOP SELLING M:ICEITLONBEMDAS*
- Available without a prescription
- Our brands simply cost less
- Fastest processing times online
hxxp://xxx.[removed].com
The URL at the bottom of the email was a fake medical supplies site that looked something like this:
The templates are continuously changing. Also, the Trojan reconnects the control server at specified intervals and receives new templates. Here is an example of another spam email that was sent a few days later:
From: justin
To:
Subject: Own your own Rolex
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Huge discounts on Gucci bags
hxxp://xxx.[removed].com
This site was trying to sell fake watches and designer bags-the name of the site was Kings Replica, which is a name associated with a well known spam campaign that has been running for a long time. (See here for more details.)
A colleague of mine, Dermot Hartnett, who works in our anti-spam team was recently interviewed about the current trends within spam. Although the interview is from July, the information presented is still relevant and shows what you might expect to see in your inbox (or, rather, what was blocked before it ever got to your inbox):
This Trojan is an example of a very simple threat that can use an infected machine for purposes other than stealing data. Malicious code authors will try to infect thousands of computers with similar Trojans and then use the infected computers in unison, allowing them to send millions of spam emails every minute. A network of 10,000 infected computers would not be considered large!
Although this simple Trojan is capable of sending out a torrent of spam, due to its simplicity it is very easy to detect-both the actual Trojan file and the spam that the Trojan sends. Symantec detects these types of threats as Trojan.Spamthru.
P.S.> The good news is that the end of this spam campaign may be in sight. The FTC is taking action against the supposed organizers of these spam campaigns, as reported here: http://www.theregister.co.uk/2008/10/14/prolific_spammers_targeted/Message Edited by SR Blog Moderator on 10-17-2008 04:49 AM
Image Spam Trying a Comeback - Without Success
Symantec has observed an increase in the use of image spam attacks over the past few weeks. Symantec defines image spam as an unsolicited message containing an image in the body.
In August, image spam attacks accounted for approximately 1.6% of total spam. In September we observed that image attacks almost doubled, representing approximately 2.6% of total spam. Over 50% of image attacks observed are English, and the second largest group of messages is Russian. In the first ten days of October, image spam messages have averaged approximately 8.6% of total spam. This is the highest mark to date over the last 90 days. From May of this year up to September, image spam was relatively quiet. As stated above, these numbers have been increasing since mid-September. We have not seen image spam of this volume since February of this year.
Commonly seen image spam messages have included Russian online dating offers, random product offerings with an image opt-out, and the all too familiar Viagra offers. Nothing is blatantly new here, but the recent volume increase is notable enough for us to ask if this old trend could be trying for a comeback.
Another observation with image spam is its connection to phishing attacks. Several phishing attacks have used images recently, which have in turn classified them as image attacks. We recently observed some large phishing attacks on banks with attached logo images. The good news is that anti-spam effectiveness is not being negatively impacted due to this trend. Symantec is effectively protecting our customers from these attacks with our anti-spam products.
Microsoft Patch Tuesday for October 2008
There are 10 critical issues this month affecting Internet Explorer, Excel, Active Directory, and the RPC service of Host Integration Server. All of them are remote code-execution issues, but the issues affecting Host Integration Server and Active Directory do not require any user interaction, making them potentially the worst of the bunch. The remaining issues (rated Important and Moderate) affect Message Queuing Service, Internet Printing Protocol (IPP), Windows Kernel, Ancillary Function Driver, Virtual Address Descriptors (VADs), and Server Message Block (SMB).
As always, customers are advised to follow these security best practices:
- Block external access at the network perimeter to specific sites and computers only.
- Avoid sites of questionable or unknown integrity.
- Never open files from unknown or questionable sources.
- Run all software with the least privileges required while still maintaining functionality.
Microsoft's summary of the October releases can be found here:
http://www.microsoft.com/technet/security/bulletin/ms08-oct.mspx
Some of the notable vulnerabilities this month are:
1. MS08-058 Cumulative Security Update for Internet Explorer (956390)
CVE-2008-3472 (BID 31615) HTML Element Cross-Domain Vulnerability (MS Rating: Critical /Symantec Urgency Rating 8.5/10)
A cross-domain remote code-execution and information disclosure vulnerability affects Internet Explorer because it incorrectly interprets the origin of script code. An attacker can exploit this issue by enticing a victim into viewing a specially crafted web page. Code execution in the context of another domain or security zone is only possible when exploited through Internet Explorer 6 SP1 running on Windows 2000 SP4, otherwise a successful exploit will result in information disclosure only.
Affects: Internet Explorer 5.01 SP4, Internet Explorer 6, Internet Explorer 6 SP1, and Internet Explorer 7.
CVE-2008-3473 (BID 31616) Microsoft Internet Explorer Event Handling Cross Domain Security Bypass Vulnerability (MS Rating: Critical / Symantec Urgency Rating 8.5/10)
A cross-domain remote code-execution and information disclosure vulnerability affects Internet Explorer because it incorrectly interprets the origin of script code. An attacker can exploit this issue by enticing a victim into viewing a specially crafted web page. Code execution in the context of another domain or security zone is only possible when exploited through Internet Explorer 6 SP1 running on Windows 2000 SP4, otherwise a successful exploit will result in information disclosure only.
Affects: Internet Explorer 5.01 SP4, Internet Explorer 6, Internet Explorer 6 SP1, and Internet Explorer 7
CVE-2008-2947 (BID 29960) Microsoft Internet Explorer 'location' & 'location.href' Cross Domain Security Bypass Vulnerability (MS Rating: Critical / Symantec Urgency Rating 8.5/10)
This is a previously documented cross-domain security-bypass vulnerability affecting Internet Explorer originally disclosed on June 26, 2008. The problem occurs when handling the "location" or "location.href" property contained in a window object. An attacker can exploit this issue to execute arbitrary code in another browser window's security zone.
Affects: Internet Explorer 5.01 SP4, Internet Explorer 6, Internet Explorer 6 SP1, and Internet Explorer 7
CVE-2008-3475 (BID 31617) Microsoft Internet Explorer Uninitialized Object Remote Memory Corruption Vulnerability (MS Rating: Critical / Symantec Urgency Rating 7.1/10)
A remote code execution vulnerability affects Internet Explorer when it accesses an object that has not been properly initialized or has been deleted. An attacker can exploit this issue by tricking a victim into viewing a specially crafted web page. A successful attack will result in the execution of arbitrary code in the context of the currently logged-in user.
Affects: Internet Explorer 6, and Internet Explorer 6 SP1
CVE-2008-3476 (BID 31618) Microsoft Internet Explorer HTML Objects Uninitialized Memory Corruption Vulnerability (MS Rating: Critical / Symantec Urgency Rating 7.1/10)
A remote code execution vulnerability affects Internet Explorer because it attempts to access uninitialized memory in certain situations. An attacker can exploit this issue by tricking a victim into viewing a specially crafted web page. A successful attack will result in the execution of arbitrary code in the context of the currently logged-in user.
Affects: Internet Explorer 5.01 SP4, Internet Explorer 6, and Internet Explorer 6 SP1
2. MS08-059 Microsoft Host Integration Server RPC Remote Code Execution Vulnerability (KB956695)
CVE-2008-3466 (BID 31620) HIS RPC Buffer Overflow Vulnerability (MS Rating: Critical / Symantec Urgency Rating 8.2/10)
A remote code execution vulnerability affects the SNA Remote Procedure Call (RPC) service of Host Integration Server. An attacker can exploit this issue by sending a malformed RPC request to the affected service. A successful exploit will result in the execution of arbitrary code in the context of the affected service. This could facilitate a complete compromise of the affected computer.
Affects: Microsoft Host Integration Server 2000 SP2, Microsoft Host Integration Server 2000 Administrator Client, Microsoft Host Integration Server 2004, Microsoft Host Integration Server 2004 SP1, Microsoft Host Integration Server 2006 32-bit, and Microsoft Host Integration Server 2006 x64.
3. MS08-057 Vulnerabilities in Microsoft Excel Could Allow Remote Code Execution (956416)
CVE-2008-3477 (BID 31702) Microsoft Excel Calendar Object Validation Remote Code Execution Vulnerability (MS Rating: Critical / Symantec Urgency Rating 7.1/10)
A remote code execution vulnerability affects Excel when processing a VBA Performance Cache. An attacker must trick a victim into opening a malicious project file to exploit this issue. A successful attack will result in the execution of arbitrary code in the context of the currently logged-in user.
Affects: Excel 2000 SP3, Excel 2002 SP3, and Excel 2003 SP2 and SP3
CVE-2008-3471 (BID 31705) Microsoft Excel File Format Parsing Remote Code Execution Vulnerability (MS Rating: Critical / Symantec Urgency Rating 7.1/10)
A remote code execution vulnerability affects Excel when processing a malformed Excel file. An attacker must trick a victim into opening a malicious file to exploit this issue. A successful attack will result in the execution of arbitrary code in the context of the currently logged-in user.
Affects: Excel 2000 SP3, Excel 2002 SP3, Excel 2003 SP2 and SP3, Excel 2007, Excel 2007 SP1, Microsoft Office Excel Viewer 2003, Microsoft Office Excel Viewer 2003 SP3, Microsoft Office Excel Viewer, Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats, Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats SP1, Office 2004 for Mac, Office 2008 for Mac, Open XML File Format Converter for Mac.
CVE-2008-4019 (BID 31706) Microsoft Excel Formula Parsing Remote Code Execution Vulnerability (MS Rating: Critical / Symantec Urgency Rating 7.1/10)
A remote code execution vulnerability affects Excel when parsing a malformed formula embedded in a cell. Specifically, a REPT function call can be exploited to cause an integer overflow. An attacker must trick an unsuspecting victim into opening a malicious file to exploit this issue. A successful exploit will result in the execution of arbitrary code in the context of the currently logged-in user.
Affects: Excel 2000 SP3, Excel 2002 SP3, Excel 2003 SP2 and SP3, Excel 2007, Excel 2007 SP1, Microsoft Office Excel Viewer 2003, Microsoft Office Excel Viewer 2003 SP3, Microsoft Office Excel Viewer, Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats, Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats SP1, Microsoft Office SharePoint Server 2007, Microsoft Office SharePoint Server 2007 SP1, Microsoft Office SharePoint Server 2007 x64 Edition, Microsoft Office SharePoint Server 2007 x64 Edition SP1*, Office 2004 for Mac, Office 2008 for Mac, Open XML File Format Converter for Mac.
4. MS08-060 Vulnerability in Active Directory Could Allow Remote Code Execution (957280)
CVE-2008-4023 (BID 31609) Microsoft Windows Active Directory LDAP Request Handling Remote Code Execution Vulnerability (MS Rating: Critical / Symantec Urgency Rating 8.2/10)
A remote code execution vulnerability affects Active Directory on Windows 2000 because of insufficient validation of LDAP requests. A remote attacker can exploit this issue by sending a malformed LDAP packet to an affected server. A successful exploit will result in the execution of attacker-supplied code in the context of the affected service. This may facilitate a complete compromise of the affected computer.
Affects: Active Directory
More information on this and the other vulnerabilities being addressed this month is available at Symantec's free SecurityFocus portal and to our customers through the DeepSight Threat Management System.
Trojan.Silentbanker Decryption
Trojan.Silentbanker's configuration files have always been protected, ever since the first version of the Trojan that we encountered. The reason for this protection is to make it difficult to understand what the Trojan is doing, and in particular, to hide which sites the Trojan is targeting. The original version targeted over 400 banking pages. Although, the actual list of pages being targeted was only clearly visible after the protection had been removed from the configuration files.
In order to discover the list of sites being targeted by any version of the Trojan the protection needs to be removed from the configuration files first. The old version of the Trojan used some simple tricks to hide its configuration; however, upon inspecting the new version of the Trojan, it is immediately obvious that something has changed. The protected configuration files look very different from previous versions.
Here I will describe the new configuration files and the steps necessary to view these files in plain text. The old protection technique was to first use character translation (a=x, b=s, c=f, etc.) on the plain text configuration files and then to compress the resulting character translated text to a smaller binary format that could be downloaded quickly.
Here are some examples of what the old configuration files looked like-I'm showing the fully decrypted configuration file format first and working backwards towards the encrypted file that was downloaded by the Trojan. This is the plain text configuration file; it contains URLs to send the stolen data to, URLs to download updates from, and the URLs of targeted bank sites (the data shown has been sanitized to remove dangerous or targeted URLs):
Each new section of the configuration file starts with [..]. So, the first section is [dfgdf]. Inside each section there is a list of data for the Trojan to use. Each string of data to be used is stored after an identifier (e.g. bg1=, bg2= , bg3=, etc.).
Presented below is the text configuration file after character translation has been carried out. The character translation is only used on strings that are preceded by an "=" sign. An example of the translation is:
"b" was changed to "o"
"l" was changed to "y"
"a" was changed to "n"
"h" was changed to "u"
So that "blah" becomes "oynu"
(b=o,l=y,a=n,h=u,.=8,c=p,o=b,m=z,/=#,e=r,u=h,r=e,/=#,i=v,n=a,d=q,e=r,x=k,.=8,p=c,h=u,p=c)
The file shown above is not exactly what the Trojan downloads though, what the Trojan downloads is a compressed binary configuration file, shown here:
We can see that the compressed binary format starts with FF and on the right we can still make out some of the character translated text, too. The fact that the file starts with FF is one tell tale sign that this is a Trojan.Silentbanker configuration file, and the Trojan also stores its configuration files in files named [9-11 digits].cpx. The current Trojan.Silentbanker configuration files look different though:
As we can see, there is no 0xFFh at the start. So, the Trojan must be using some other type of encryption on these new configuration files. After some analysis of the Trojan we come to the following routine:
This is the decryption routine for the configuration files. Now we can start to make some sense of the configuration file shown above. Searching online for the constants used in the code above, namely C6EF3720 and 61C88647, shows us that the code used is probably a TEA encryption routine (tiny encryption algorithm) or a modified version of it.
After we run the decryption routine shown above, we end up with a file that looks like this:
Does this look familiar? This is, in fact, the same format as the Trojan was using previously. Notice that it starts with FF. (The "x"s on the right were an IP address that has been removed.) The latest version of the Trojan has just added a layer of encryption on top of the old protection layers. Once the TEA encryption layer has been bypassed, we can decode the configuration files in exactly the same way as for the older version of the Trojan.
P.S.> there is also a short cut to get to the decrypted files, but I'll save that for another time.Message Edited by Liam O Murchu on 10-10-2008 02:06 AM
Symantec - At the Cutting Edge of Technology
The theme of this year's conference was "How We Win." In a way, everything we discussed boiled down to one thing: we win by making our customers win. We win by helping to solve their problems, adding value to their businesses, and making their lives more secure. Sounds obvious, but how do we do that? We touched on a number of approaches, from the macro down to the micro. For example, at the macro scale we talked about our Open Collaborative Architecture which uses open standards and API's to allow our products (and third party products) to take advantage of and leverage each other. We also shared lots of cool technologies and approaches that can be used across our products to improve reliability, scalability, usability, availability, and flexibility. Actually, I think we touched on virtually every "-ility" you can imagine.
As the leader of Symantec Research Labs (SRL), I was proud of the large number of engineers presenting papers on our latest research, demonstrating new technologies, and generally soaking up and dispensing as much information as possible. At Symantec, our job is to focus on winning through innovation, whether it is a revolutionary change to the way we approach a problem, an idea in a space that we aren't currently in, or an algorithm that improves an existing product. To win, we have to create differentiated innovation at many different scales and we have to do it over and over again.
Cutting Edge is a really effective way of facilitating all of these forms of innovation as well as sharing the excitement and fun of designing and building world leading products. This year's event did a great job of both.
NetBackup for VMware: Buy One (Restore), Get One Free
I was recently reading an article by Alan Radding for SearchStorage about VMware backups, and he described how one of the industry's frustrations is that when backing up VMware servers, it's necessary to back up the data twice in order to be able to perform the two types of restores that people perform the most (individual file restores and restores of entire virtual machines). This article really surprised me, because it didn't seem to demonstrate awareness of NetBackup's support for both types of restores based on a single VCB-based backup pass. You see, with NetBackup, backing up once enables you to restore either the entire VM or individual files (like that Powerpoint file your colleague deleted by accident when he borrowed your laptop). This scriptless single-backup, dual-restore capability results from a proprietary Symantec technology that helped us win a "Best of VMworld" award.
So, I feel that running NetBackup is like getting to keep both of your umbrellas; but, unlike with umbrellas, the two-for-one deal is one that you might actually really appreciate when it comes time to restore an individual file or, if it starts to rain inside your data center, your entire virtual machines.
Symantec - How We Win at Securing Customers in a Virtual World
Symantec's Cutting Edge 2008 engineering conference had a remarkable symmetry on the second day. The first keynote was delivered by Enrique Salem, COO of Symantec, and the last one by Chris Hoff, Chief Architect of Unisys.
Remarkably, they spoke with almost color-coordinated phrases. Enrique said that the way Symantec was going to differentiate itself from competitors was to focus on virtualization, information risk management and SaaS (software as a service). Chris Hoff talked about the "virtualization of security" or as he said, the three most important trends in the industry at the moment: virtualization, security and management of risk, and lastly, "cloud computing"/SaaS. Chris described the four horsemen of the apocalypse (be afraid, be very afraid) in trying to focus attention on the challenges posed in the brave new world of network security in a virtualized world.
It brought to mind the biggest opportunity and the biggest challenge facing Symantec at the moment. How do we work better together - using our products and our teams to solve customer problems? Enrique called attention to the unique positioning of the Symantec product portfolio in responding to these challenges. He gave the example of the Symantec Open Collaborative Architecture (OCA) through which Symantec products can share data, workflow, and management capabilities to jointly address customer problems. What is different about the OCA from previous integration efforts? The answer is that it is based on a proven product set--the Altiris (now Symantec) management platform--and on industry web services standards. The Symantec OCA allows products to collaborate through the Symantec Workflow Engine, by exposing web services or by utilizing the Altiris platform and console.
Another takeaway from the conference was Joe Fitzgerald's reference to the number of patents in the Symantec patent portfolio. Fitzgerald, the VP of our legal department, referred to the Wall Street Journal's Technology Index, in part based on the patent portfolio owned by technology companies, which is considered to be critical to success. (Remember, the conference is about "How We Win.") Symantec is 16th on the WSJ Technology Index. Overall, a very insightful day.
Dramatic Spike in the Number of Email Messages Containing Malware
Also noted in this month's State of Spam Report is the increase in zombie activity. The report notes that while zombie activity decreased from July to August, it increased more than 100% between August and September. For this period, the EMEA region was the leading source of all zombie IP addresses. Countries showing the highest increase in the number of zombies include South Korea, Kazakhstan, Romania, and Saudi Arabia, among others. Not surprisingly, countries with the big increase in zombies also figured in the top five countries by spam sent. However, the United States still leads overall in spam sent.
To read about these or other trends in the report, such as messages leveraging current events (for example, the US presidential race and the US economic concerns), please visit the State of Spam website and the October State of Spam Report.
Trojan.Silentbanker Adds Rootkit Functionality
Trojan.Silentbanker has been in the wild since late last year; however, the most recent release of this Trojan has had some interesting features added to it. Namely, the most recent version has added rootkit functionality to make the Trojan even stealthier. If you are unfamiliar with Trojan.Silentbanker, have a look at this blog first.
In particular, the Trojan tries to hide its own files from the system in order to avoid someone noticing the files and to hide its configuration from prying eyes. This is a common technique used by other Trojans to stay invisible on a system. Trojan.Silentbanker stores its executable files and configuration files in the "system32" folder using a file name that consists of a series of numbers followed by the extension .cpx or .cpl. (I'll explain what the numbers mean a little later.)
In order to become invisible the Trojan needs to hook the FindFirstFile / FindNextFile functions of the system so that when the system is about to return a listing of files to the user, the Trojan can sanitize the list first and remove any references to the Trojan's files before the user is presented with the list. To illustrate the addition of rootkit functionality to the Trojan, review the table below, which shows the functions that were hooked by the Trojan in January 2008 and in the most recent version:
Fig 1. APIs hooked by Trojan.Silentbanker
(Note: A "?" in the above table signifies that the information regarding whether or not that API was hooked in a specific version was not available at the time of writing.)
The interesting additions to the list are the FindNextFile APIs. Let's take a look at what these functions do now that they are hooked. First though, here is what the FindNextFileW code should look like on a clean system:
Now, here is the code when the Trojan is running and the function is hooked:
We see that the real FindNextFileW code has been replaced with a jump to address 1610000. The code at that address sets some variables and then jumps to the attacker's version of FindNextFileW, which is stored at 0x0A3DF27 and is shown below in IDA:
Here we see that the malicious FindNextFileW will call the real FindNextFileW first. Then, it will check if the filename returned is a file name that should be hidden; it does this in the FilterFindNextResults function. If it is a filename that should be hidden, then the code will call the real FindNextFileW once more. So, even though the system intended to call the real FindNextFileW function once, the attacker causes it to be called twice and to return the results of the second call only. So, the information about the file to be hidden is never returned by the function.
Let's have a look at the criteria that the FilterFindNextResults function shown above uses to hide files. There is various code involved, but the most important is the function shown below. It calculates a hash of the computer name:
The resulting hash - and 8 digit number - is what is used as the numbers before the the .cpx or .cpl extension that I mentioned earlier. For example, the hash of the test pc was 38477686 and during testing the following files were created: 3847768621.cpx , 38477686212.cpx, and 38477686221.cpx (another number is appended to the hash in order to be able to store more than one .cpx file, in this case the numbers appended were 21, 212, and 221, respectively).
So, the malicious FindNextFileW calculates the hash of the computer name and compares that hash to the file names that are returned from the real FindNextFileW. If there is a match the real FindNextFileW is called a second time, effectively causing the last file found not to be reported.
There are a few things to note about this threat, one is that FindFirstFileA and FindFirstFileW are not hooked, only FindNextFileA and FindNextFileW are hooked. This means that if the Trojan's file is the first in a directory listing, it will not be hidden.
Also the hash of the filename is calculated everytime FindNextFileW is called. As well as not being very efficient coding, this means that if you change the name of your computer then the files will no longer be hidden, because the hash of the new computer name will not match the hash that was used when creating the Trojan files in the first place.
Another interesting fact is that no registry APIs were hooked, so the registry entries created by the Trojan can still be seen. The Trojan creates the following registry key in order to start when the computer is restarted:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32\wave1:"[hash of computer name].CPX"
As well as adding rootkit functionality to the latest version of the Trojan, the authors have also added an extra layer of encryption to the configuration files. I will discuss this extra layer and how to decrypt it tomorrow.
The latest version of this Trojan is detected by Symantec as Trojan.Silentbanker. The writeup, available here, has been updated with the latest changes to the Trojan.
Message Edited by SR Blog Moderator on 10-06-2008 09:05 AMCutting Edge - By Engineers, For Engineers
This year's theme is "How We Win," and there are three key areas where we see this taking shape. First, we must highlight the Symantec innovation model, which is a balance between organic innovation and innovation by acquisition of leading technologies. Second, the direction of our innovations must be driven first and foremost by our customers. Our customers are telling us that they like our products, and we must continue to listen to their needs and include features to help them do their business better. Third, making our products work together is a priority among our product groups. Many people in the Cutting Edge sessions mentioned that the way we want to get products to work together better is by utilizing the Symantec Open Collaborative Architecture (OCA). The Symantec OCA enables collaboration among Symantec products (and third party products) in several ways: through exposing web services, by utilizing the mature and polished Symantec Management platform and by utilizing the Symantec Workflow engine.
* * *
Random Cutting Edge observations: watching four wild and crazy guys playing Rock Band and capturing at least two "entertaining" videos of the entire performance at the Tuesday night reception was a sight to behold (and to laugh at as well). Engineers congregated around the various exhibits and seemed to be in their element and enjoying themselves.
Overall, it was a fantastic start and made all of the hard work and preparations worthwhile. "A conference by engineers, for engineers" is our mantra, and the event gets better each year.
The (File)Name Game!
Digging into our honeypots and spam-trap systems to look for malicious attachments is always an interesting exercise. We can identify different spam campaigns and map together malicious binaries by correlating attachments and filenames. Nevertheless, it's also funny to see how the bad guys are still trying to entice users to run executable attachments-pushing their creativity and social engineering skills to extreme levels. Invoices, contracts, delivery notices, and all types of tickets are travelling by mail everyday, hitting millions of mailboxes; all in the hope that a few users, sooner or later, will be fooled by a perfectly orchestrated malicious e-mail (yes, it does still work, and old tricks are always the best).
Just for fun, I tried to create a picture of the breakdown of the most common malicious spam campaign observed on a set of emails received during the month of September. As you will notice from the chart below, the "Fees_2008-2009" attachment is still the most prevalent, followed closely by "e-card" and various "video codec" Trojans. A series of fake "Contract, Abstract, and Approved" Trojan files are also making the rounds these days.
Looking from a different perspective, we can still gather interesting information about filenames commonly used by malicious program by digging into generic antivirus detections. Many of these malicious binaries are compressed or encrypted with custom-made packers, often armored with exotic anti-emulation and somewhat funny anti-debugging tricks to evade antivirus detections. Using the polymorphic abilities of a packer, the bad guys generate hundreds of different samples from a single malicious executable in order to minimize the chance of being detected. These bad packers-used only by malicious programs-are very common for a lot of different Trojans and misleading applications, which jump from one packer variant to another every time they are detected by generic detections.
Generic antivirus detections for files created by bad packers are frequently released for our products with the prefix name of "Packed.Generic." It is nice to see a single generic detection catching thousands of different malicious samples in one shot, as shown by the chart below, calculated only during the month of September. Spikes in volumes usually occur either when a new spam campaign starts, or when there's a shift in the threat landscape (with a malicious code family moving from one packer to another).
Packed.Generic detections are also useful for identifying different malware families that share the same bad packer. I always wonder if this fact means that there's a single guy behind the distribution of different Trojans, or if it's just a coincidence.
Here are some filename statistics related to some of our recent generic detections having good hits recently:
Name: Packed.Generic.177
Description: Commonly used by misleading applications such as AntiVirus2008,
AntiVirus2009, AntiVirusXP2008 and their Downloaders.
Filenames:
av2009.exe
av2008xp.exe
AV2009Install_*.exe (e.g. AV2009Install_880401.exe)
xpa.exe
skypecomm.dll
winsrc.dll
Name: Packed.Generic.186
Description: Commonly used by Trojan.Blusod, Trojan.Fakeavalert and Downloaders.
Filenames:
InstallAntivirus_trXP.exe
lphc*.exe (e.g. lphcjooj0ecg4.exe)
mssadv_sp.exe
Name: Packed.Generic.187
Description: Used by AntiVirus2009 droppers and Downloaders.
Filenames:
A9installer_*.exe (e.g. A9installer_770522157731.exe)
MultyCodecUpgr*.exe (e.g. MultyCodecUpgr.7.20765.exe)
av2009.exe
Contract.doc.exe
Approved.doc.exe
msxml71.dll
video*.cfg.exe (e.g. video1055.cfg.exe)
video(*).cfg (e.g. video1054.cfg)
Name: Packed.Generic.188
Description: Used by Trojan.Blusod, Backdoor.Tidserv and AntiVirus2008.
Filenames:
lphc*.exe (e.g. lphcjooj0ecg4.exe)
AV2008install.exe
file.exe
.tt4.tmp
scan.exe
TDSS*.tmp
TDSS*.dll
Regardless of the spam campaign, filenames, and/or packer used, the thing that you may have noticed these days is the fact that pretty much all of these malicious emails and samples are somehow related to misleading applications. In most cases, these misleading apps end up downloading and installing an antivirus clone program or a fake security product. So, now that you know the common filenames used by the bad guys these days, watch what you click when you receive your next email!
How We Win - Openly
Here at Cutting Edge we have a lot of exciting technological developments and innovations to share. At the top of the list for me is the Symantec Open Collaborative Architecture (OCA), which prescribes a technology direction to enable collaboration among Symantec products and third-party and partner products.
The architecture is based on a loosely coupled interoperability model that requires products to adhere to a limited set of technology requirements in order to be considered OCA-enabled. The Symantec OCA enables products to interoperate for the purpose of data/information sharing among multiple products. This allows task and operational control of one product to be initiated by another product while creating loosely integrated process automation solutions for IT domain-specific processes, as prescribed in ITIL, for example. Working across IT domains, sharing and exchanging data, and enabling automation all contribute to greater cost effectiveness and risk management for the enterprise.
Open Collaborative Architecture is neither a product nor a solution in itself and cannot be purchased independently of the products that adopt its technologies. The idea is to prescribe an evolutionary approach to interoperability and solution construction, building on the Altiris solution model that is available today. As a common solutions and software architecture, the OCA enables various forms and multiple models for interoperability, none of which are mutually exclusive.
Using standard technologies around web services, web-based security, workflow management, and configuration management, the OCA provides greater flexibility and openness to build complex, multi-disciplinary, and multi-vendor solutions that can be tailored to meet specific business needs.
It's All About Reputation
Unlike traditional antivirus, all of our reputation data is stored in the cloud - that is, in Symantec data centers - meaning that if and when we shift to this model, we can drastically reduce the memory and performance impact of traditional antivirus software. Given this fact, Symantec's approach should work just as well for a cell phone as a desktop PC.
It's different than some of the other "cloud-based AV" systems that are being announced, in that it can detect and protect against entirely new malicious code - even malicious code on just one person's PC that's never been seen by a security company. From what I've read, these other systems still rely on fingerprints to detect new malware. They're just hosting some of those fingerprints on servers instead of on your PC. (This is only my speculation, so take it with a grain of salt.)
We're not quite ready to completely replace our traditional antivirus technology, but soon we hope to release hybrid security products that leverage both old and new techniques. I'd be proud for Symantec to be the first company to finally kick the fingerprint habit.
In any case, I'm expecting a fair amount of spirited debate about the results. I'm not expecting too many people to defend traditional fingerprinting, however. Symantec's R&D leaders long ago agreed that this model is destined for the way of T-rex and Triceratops.Message Edited by SR Blog Moderator on 10-06-2008 12:29 PM
Losing Touch with Fingerprinting
Unfortunately, while the industry had its head down honing the blacklisting approach (Symantec can automatically analyze and fingerprint up to 6M samples per week - how's that for honing?), the rest of the world changed. Recent Symantec studies show that the volume of malware released now outpaces good software (potentially representing up to 65% of all unique software apps). Furthermore, industry reviews show that many new malware programs slip past all major antivirus products - it often takes days or weeks for antivirus vendors to catch up and protect against a newly released threat. And, some threats never get detected - a threat that's personalized by an attack server for a single user may never be discovered by security vendors!
And of course, while we could just ratchet up the model and ship 20, 30, or 50 thousand fingerprints per day to customers, before long you'll have no RAM left to run legitimate software. The model is close to being broken. Fortunately, Symantec's been anticipating this problem for a long time. In fact, we started working on a replacement approach to classic blacklisting about two years ago.
This Cutting Edge is exciting for me because for the first time we're sharing the results of our project with our colleagues, and the results are extremely promising: in many use cases it appears to be significantly better than traditional fingerprint-based antivirus software at detecting new threats. So good that the project's lead engineer, Vijay Seshadri, is afraid to publish the initial results, even internally, given the stir they might make.
Stay tuned this week for more information on Symantec's pioneering efforts in this space.Message Edited by SR Blog Moderator on 10-06-2008 01:28 PM