Securely deleting data is a requirement of most regulatory requirements. But many organizations struggle with just how to do this in a way that is both secure and compliant. Some ways to do this include using software to overwrite the data, using a degaussing tool to electronically damage the drives, and physically destroying them.

Make sure you keep in mind that whatever method you use, the goal is risk mitigation rather than risk elimination. You’re trying to mitigate the most risk for the least money. So while DBAN and smash therapy aren’t perfect, they do the job pretty well for what you need them to do. If you’re the DOD or NSA then of course you need to do something else. But if you’re the DOD or NSA you already knew that.

Another part of the HIPAA and SOX requirements is auditable documentation. NIST has a guide (linked below) which gives you a generic form for the types of data you need to track, including method of sanitization, serial number, who performed the test, etc. It is also beneficial to document your methodology since the auditors will want to see that along with your wiping logs.

DBAN is one of the most useful tools out there; it does several forms of wiping to remove data from all types of drives, including SCSI and older hardware. If the drives are all ATA and manufactured within the last five years (erring on the side of caution), the SecureErase command is more thorough and faster. This command is implemented in a number of utilities, probably the best known one being put out by UCSD and called Secure Erase (linked below). Obviously physical destruction is an option too; it can be fun and cathartic to take a sledgehammer to the drives, and old platters can make a great mobile for the crib geek’s ceiling.

Wiping portable media is a different issue entirely. Backup tapes, thumb drives and portable hard drive storage are three such examples of portable media. Each has its own challenges. I’ve addressed the hard drive issue above, but probably the best way to wipe the other two is physical destruction. It’s an easy process for small USB drives but can be difficult to do safely with backup tapes. I’d suggest contacting your paper records disposal company and asking them if they can provide this service for you. You may find that their rates are low for this sort of thing.

NIST Special Publication 800-88 – Guidelines for Media Sanitization
http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf

DBAN
http://www.dban.org/

Secure Erase
http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml

National Industrial Security Program Operating Manual DoD 5220.22-M 2006 (Deprecated)
https://www.dss.mil/GW/ShowBinary/DSS/isp/odaa/documents/nispom2006-5220.pdf

Data Erasure
http://en.wikipedia.org/wiki/Data_erasure

Data Remanence
http://en.wikipedia.org/wiki/Data_remanence

Marcus Ranum’s method of physical destruction
http://www.ranum.com/security/computer_security/editorials/diskcrypt/index.html

In the past couple of months, the Freakonomics blog asked why there has been such a downturn in the familiar Viagra and Nigerian prince Spam. The author attributed this to the cost of spamming not being worth the rates of return anymore. Most commentators pointed to better spam filtering software.

While it does seem that anti-spam filtering has improved, there might be more to the reasons of the observed downturn. There are noted temporary declines whenever some of the bad guys’ ISPs get taken down, but that the general trend is toward continued spamming. Interestingly, though, anecdotal evidence (my spam filter) doesn’t suggest that the spammers are spending much time coming up with new tricks to avoid detection.

So back to the Freakonomics theory: a change in business models. From what we’ve been seeing, cyber criminals seem to be spending more time focusing on different types of attacks on your inbox. In the last year or so, we in the Information Security business have seen a dramatic rise in phishing attacks, particularly more targeted phishing attacks.

Phishing attacks in which a criminal targets smaller regional areas have been quite popular. Criminals will try to find an area where there are only a few financial institutions and then send emails, text messages and leave voice mails for victims they believe are in that area. These messages will either be of the traditional kind, asking for sensitive information over the Internet, or they will instruct the recipient to call a 1-800 number to divulge information. The criminals then charge money on credit cards and withdraw from ATMs.

In addition, criminals are targeting businesses more frequently. Using legitimate-looking emails impersonating organizations like the IRS, UPS and Better Business Bureau are common in these attacks. The goals here are less about sensitive information and more about installing malicious software to infiltrate a company. Usually here the goal is to get access to a corporate bank account and transfer money electronically.

So it seems that the Freakonomics guys were right, it does come down to simple economics and opportunity costs. Spam is cheaper and easier per email, but phishing brings in far more money. Enough money, in fact, that organized crime groups can set up processing centers to do all the work while the cyber kingpins drive around in their Maseratis in Marseilles. That beats Nigeria any day.

Over the past year, the SecureWorks Counter Threat Unit (CTU)^SM has seen criminals continue to target Automated Clearing House (ACH) and wire transfer transactions for fraud activity, resulting in high-value losses. Small to midsized businesses (SMBs) and not-for-profits have been hit especially hard. Neustar has published an excellent overview (PDF) of this type of threat.

The tools of choice for financial credential theft are often the Zeus or Clampi malware families. In January, the CTU came across what appears to be a new piece of malware developed to facilitate this type of criminal banking activity. The CTU has been calling this new malware Bugat. Currently, it is updating its configuration data to include new financial targets. In mid-January, the installer for Bugat had moderate coverage (20/40), according to VirusTotal. The most commonly identified name (Bredolab) corresponds to a family of trojan downloaders. However, its runtime behavior did not match what one would expect from Bredolab. The installed mspdb30.dll file had almost no AV recognition (2/41). The AppInit_DLLs registry key setting changes made by the installer instruct Windows to load the Bugat DLL into any program that also loads user32.dll. This is a common mechanism used by malware to infiltrate itself into targeted processes such as web browsers and email clients.

Bugat comes with capabilities commonly found in malware used to commit credential theft for financial fraud.

Bugat Functionality

• Internet Explorer (IE) and Firefox form grabbing
• Scrape or modify HTML for targeted sites
• Steal and delete IE, Firefox, and Flash cookies
• Steal FTP and POP credentials
• SOCKS proxy server (v4 and v5)
• Browse and upload files from the infected computer
• Download and execute programs
• Upload list of running processes
• Delete system files and reboot computer to render Windows unable to boot

Bugat communicates with a remote command and control web server to receive commands and to exfiltrate stolen information. As part of this process, the malware also receives a list of URL target strings used to monitor the victim’s web browser activity. These target strings indicate a strong interest in websites used for business banking and wire transfers. Bugat may also use HTTPS in an attempt to secure its command and control communications.

New Bugat Banking Trojan Gives Hackers Choices
The emergence of Bugat reinforces that there is a strong demand for new malware to commit financial credential theft and that ACH and wire fraud remains a profitable venture for criminals. This demand may be driven by the desire for cheaper alternatives or malware that has not received as much scrutiny from security professionals. The continued introduction of this type of malware could have the unfortunate effect of lowering costs of malware and the barrier to entry into the criminal marketplace.

With the recently disclosed hacking incident inside Google and other major companies, much of the world has begun to wake up to what the infosec community has known for some time – there is a persistent campaign of "espionage-by-malware" emanating from the People’s Republic of China (PRC). Corporate and state secrets both have been shanghaied over a period of five or more years, and the activity becomes bolder over time with little public acknowledgement or response from the U.S. government.

"Operation Aurora" is the latest in a series of attacks originating out of Mainland China.  Previous attacks have been known as – "GhostNet" and "Titan Rain." Operation Aurora takes its name directly from the hackers this time – the name was coined after virus analysts found unique strings in some of the malware involved in the attack. These strings are debug symbol file paths in source code that has apparently been custom-written for these attacks. The paths were left behind in the compiled binaries as shown below:

Although the code behind Operation Aurora has only recently been discovered, and the known samples of the main backdoor trojan (called Hydraq by antivirus companies) appear to be no older than 2009. It appears that development of Aurora has been in the works for quite some time – some of the custom modules in the Aurora codebase have compiler timestamps dating back to May 2006. This date is only a year or so after the Titan Rain attacks, which largely used widely-available trojans that were already known to antivirus companies. As a result of using completely original code and then only in highly-targeted attacks, the Aurora code seems to have escaped detection for quite some time.

The compiler often offers other clues to a malware sample’s origin. For instance, if the binary uses a PE resource section, the resource’s headers will often provide a language code. The Hydraq component does use a resource section, but in this case, the author was careful to either compile the code on an English-language system, or they edited the language code in the binary after-the-fact. So outside of the fact that PRC IP addresses have been used as control servers in the attacks, there is no "hard evidence" of involvement of the PRC or any agents thereof.

There is one interesting clue in the Hydraq binary that points back to mainland China, however. While analyzing the samples, I noticed a CRC (cyclic redundancy check) algorithm that seemed somewhat unusual. CRCs are used to check for errors that might have been introduced into stored or transferred data. There are many different CRC algorithms and implementations of those algorithms, but this is one I had not previously seen in any of my reverse-engineering efforts. Below is the raw assembly code for the CRC algorithm in Hydraq:

The first thing that is unusual about this CRC algorithm is the size of the table of constants (the incrementing values in the left pane of the assembly listing). Most 16 or 32-bit CRC algorithms use a hard-coded table of 256 constants. The CRC algorithm used in Hydraq uses a table of only 16 constants; basically a truncated version of the typical 256-value table. By decompiling the algorithm and searching the Internet for source code with similar constants, operations and a 16-value CRC table size, I was able to locate one instance of source code that fully matched the structural code implementation in Hydraq and also produced the same output when given the same input:

This source code was created to implement a 16-bit CRC algorithm compatible with the implementation known as "CRC-16 XMODEM", while requiring only a 16-value CRC table. It is actually a clever optimization of the standard CRC-16 reference code that allows the CRC-16 algorithm to be used in applications where memory is at a premium, such as hobby microcontrollers. Because the author used the C "int" type to store the CRC value, the number of bits in the output is dependent on the platform on which the code is compiled. In the case of Hydraq, which is a 32-bit Windows DLL, this CRC-16 implementation actually outputs a 32-bit value, which makes it compatible with neither existing CRC-16 nor CRC-32 implementations.

Perhaps the most interesting aspect of this source code sample is that it is of Chinese origin, released as part of a Chinese-language paper on optimizing CRC algorithms for use in microcontrollers. The full paper was published in simplified Chinese characters, and all existing references and publications of the sample source code seem to be exclusively on Chinese websites. This CRC-16 implementation seems to be virtually unknown outside of China, as shown by a Google search for one of the key variables, "crc_ta[16]". At the time of this writing, almost every page with meaningful content concerning the algorithm is Chinese:

This information strongly indicates the Aurora codebase originated with someone who is comfortable reading simplified Chinese. Although source code itself is not restrained by any particular human language or nationality, most programmers reuse code documented in their native language. To do otherwise is to invite bugs and other unexpected problems that might arise from misunderstanding of the source code’s purpose and implementation as given by the code comments or documentation.

In my opinion, the use of this unique CRC implementation in Hydraq is evidence that someone from within the PRC authored the Aurora codebase.  And certainly, considering the scope, choice of targets and the overwhelming boldness of the attacks (in light of the harsh penalties we have seen handed out in communist China for other computer intrusion offenses), this creates speculation around whether the attacks could be state-sponsored.

###

During the course of 2009, the amount of publicly available information on the security of GSM cellular networks and devices has steadily increased. GSM stands for the “Global System for Mobile communications” and is the world’s most popular standard for mobile handsets. The GSM Association estimates that more than 3 billion people are now using GSM technology. With such a massive install base, addressing potential security vulnerabilities in GSM handsets or in GSM networks themselves is clearly an enormous challenge.

The DeepSec In-Depth Security Conference 2009 in Vienna, Austria saw the presentation of research on attacking GSM networks, as well as attacking GSM handsets using SMS / MMS. David Burgess and Harald Welte held a highly regarded workshop entitled “Security on the GSM Air Interface”, covering contemporary technologies and techniques for radio direction finding, including the capabilities and deployment of devices known as “IMSI Catchers.” An IMSI Catcher device functions as a rogue cellular access point and can be leveraged to aid in radio direction finding or may offer full voice and data man-in-the-middle capabilities with a variety of uses. Commercially available hardware and software from the OpenBTS and OpenBSC projects was used to demonstrate attacks and countermeasures under laboratory conditions using a private GSM network.

Continuing the thread of GSM security material at DeepSec, noted security researchers Zane Lackey and Luis Miras presented research on techniques for attacking GSM handsets using SMS/MMS, both the implementations themselves as well as architectural vulnerabilities in the carrier networks.

At the 26th Chaos Communication Congress (26C3) in Berlin, Germany, noted cryptographer and hardware hacker Karsten Nohl and colleague Chris Paget announced that their “A5/1 Cracking Project” had successfully calculated the cryptographic base needed to demonstrate cracking GSM communications secured using the A5/1 encryption algorithm. This data, commonly referred to as a “rainbow table”, is now publicly available on the Internet. Nohl and Paget also announced they have open sourced the software they used to calculate the rainbow tables. The ability to passively decrypt A5/1 secured GSM communications is critical to performing passive, difficult to detect interception. This contrasts with active and easily detectable interception techniques using an IMSI Catcher device.

GSM is being adopted in a growing number of sensitive applications including financial transactions, mobile payments, and of course sensitive voice communications. Capabilities once only available to very well-resourced organizations such as the military, intelligence agencies, civilian law enforcement and organized crime are now increasingly within reach of much less well-resourced organizations, such as smaller criminal groups or even malicious individuals.

Organizations using GSM for sensitive applications or to discuss or transmit sensitive information should adopt a proven information security risk management approach to their use of mobile communications technologies such as GSM, just as they do for more traditional IT systems. For organizations that must utilize GSM communications for sensitive applications within hostile environments, several third-party security solutions are commercially available.

In the last month, SecureWorks’ Counter Threat Unit^SM (CTU) has seen a general increase in malicious email campaigns trying to infect online users with the Zeus Trojan (one of the most pervasive financial-credential stealing Trojan) on the market. In the last three weeks, the CTU has also monitored a large increase in the number of email lists being sold on the underground hacker forums, coinciding with the start of the holiday shopping season.

Online shopping always increases during the holidays and with this comes more criminal activity so consumers need to ensure that they take precautions, whenever they are making online purchases. The CTU expects to see an array of scams including those involving fake holiday gift cards, coupons, electronic greeting cards, etc. Shoppers need to be on the lookout for any type of suspicious email or online offer.

Security Tips from the Counter Threat Unit for Online Shoppers

1. Be wary of holiday gift cards and holiday coupon offers sent via e-mail-these often have malicious links within the offer which lead to downloads of info-stealing trojans or the hackers try to scam you out of your bank account information.
2. When visiting your favorite online retailer to purchase gifts, be sure to type the actual Web site address of the retailer into your browser. Do not follow links provided by e-mail offers or pop up ads. Many times these are fraudulent sites made to look like the legitimate retail sites.
3. When making online purchases, always use a credit card that limits your fraud liability. Avoid using debit cards to do online purchases when possible so as to limit your personal exposure to any possible fraudulent transactions.
4. When making online purchases, always look at your Web browser for the https (as opposed to http) protocol that proceeds a Web address. The “s” let’s you know that the Web site is providing a layer of security for transmitting your personal information over the Internet.
5. Be wary of unsolicited e-mails, even from senders that you know, that include links or attachments. Before clicking on links or attachments, ALWAYS verify that the correspondent sent you the e-mail and enclosed link or attachment.
6. Be wary of e-mails notifying you that your banking certificate or token is out of date and to download a new certificate or token. Before taking any action, verify with your financial institution by calling them on a number that is not provided in the email.
7. Online computer users should avoid using weak or default passwords for any online site.

I am looking forward to participating on a panel at the SANS Incident Detection Summit December 9-10, 2009. The event is being organized with help from Richard Bejtlich, an industry powerhouse in the area of incident detection and response. It looks to be another world class security conference we have come to expect from SANS. For more information go to http://www.sans.org/incident-detection-summit-2009/

There are two things one can count on every year at ToorCon: the amazing San Diego weather and excellent presentations about new and emerging security research. This year’s ToorCon 11 did not disappoint, and delivered a lot of great content and new security research throughout the weekend.

The conference started with a non-traditional keynote address from Vernor Vinge, an award-winning science fiction author, who presented his thoughts, insight and concerns about the future of ubiquitous computing. As a nice follow-up to this theoretical presentation, Dan Kaminsky spoke next about his research into the flaws behind X.509 public key infrastructure, which he previously spoke about at Black Hat USA 2009 / DEFCON 17 this past summer. These presentations set the tone for this year’s ToorCon, showing that anything and everything is open for discussion.

Saturday’s session featured in-depth one-hour presentations which ran the gamut of security-related topics. Brandon Enright presented an excellent summary of various botnets and how they work and stay operational, which can be a very confusing topic to people who aren’t in the trenches with botnets on a regular basis. Julia Wolf provided a mountain of data about various viruses and other malware that have been in the news, and the kinds of things security geeks dream about at night. A Hollywood-style presentation by Jason Ostrom and Arjun Sambamoorthy demonstrated their freshly released UCSniff tool for IP video eavesdropping and injection by performing a “theft” on stage reminiscent of something out of “Sneakers.” Later in the day, Josh Wright released a framework for the ZigBee wireless protocol, which is appearing in more and more places such as home automation and hospital care.

Last on Saturday, but not least, the CTU’s own Ben Feinstein presented an in-depth analysis of the Koobface malware which has plagued social networking sites throughout 2009, exposing its capabilities, problems and other data that has been gathered over the past several months. Two other CTU members presented on Sunday at this year’s ToorCon. Kevin Stevens spoke about the “pay-per-install” industry, how it has changed over the years and recent “reforms” players in this industry have made. Dennis Brown presented on the underground economy of trading video game currencies for real money which is driving the popularity of game password stealers.

Sunday focused on quick, 20-minute presentations, consisting mostly of new or in-progress research, but there was no decline in the quality of these presentations. One of the presentations that stood out was by Ron Bowes, who released some great information about scanning with nmap over SMB/RPC to obtain detailed system information. Another presentation of note was by Joel R. Voss who presented a new method for static code analysis, and demonstrated its effectiveness in finding flaws in common software. There were many other presentations that contained a wealth of information, as well as a couple impromptu Q&A sessions with Dan Kaminsky and others which were as humorous as they were informative.

Year after year, ToorCon continues to deliver, while still feeling like a smaller conference. One of the great things about ToorCon is that the presenters, and everyone else for that matter, is very accessible and usually happy to talk about what they’ve been working on and share their insight into what’s going on in security. This is often hard to do at the larger conventions, and makes ToorCon special in that regard. It’s definitely worth the trip!

The SecureWorks Counter Threat Unit^SM (CTU) has been carefully monitoring the activity of the Monkif/DlKhora botnet. This bot is an example of a Downloader trojan, in that its primary purpose is to receive instructions to download and execute other malware. The trojan also attempts to disable anti-virus and personal firewall software to maintain its foothold on the system.

One interesting technique the Monkif botnet utilizes to hide its intent on the network is to encode the instructions to appear as if the command and control server is returning a JPEG file. The server sets the HTTP Content-Type header to “image/jpeg” and prefaces the bot commands with a fake 32-byte JPEG header. The bot checks if the header matches and decodes the rest of the response to retrieve its commands. The commands are encoded using a single byte XOR with 0×4. The malware that CTU has observed being installed by Monkif is a BHO (Browser Helper Object) trojan commonly referred to as ExeDot, which performs Ad Hijacking and Ad Clicking.

The botnet makes no attempt to pad the commands to make the data size representative of a true JPEG. In addition, the data will not parse to a legitimate JPEG. These attributes may provide opportunities for generic countermeasures to detect the traffic by identifying malformed image data.

Recently, programmer Ruben Unteregger released the source code for a Trojan that allows an attacker to listen in on a victim’s Skype conversations [1]. For approximately seven years, Unteregger has worked as a software engineer for ERA IT Solutions AG where he developed the trojan. Skype traffic is encrypted using a 256-bit AES block cipher [2], the kind approved by the US Government to protect “TOP SECRET” information.

The Megapanzer trojan variant was released as free software by Unteregger under the GNU General Public License (GPL). The trojan works by injecting a thread into the Skype process and hooking several API calls. While Unteregger’s trojan does not break Skype’s encryption, this method allows an attacker to bypass it as PCM audio data is captured after being decrypted and converted to MP3 digital audio files. The MP3 recordings of the Skype call may then be uploaded to an attacker-controlled server [3].

Fig. 1: Skype Trojan Overview [1]

Governments around the world worry about the use of Skype for nefarious purposes, as the service may be used to place calls that cannot be traced or monitored using contemporary lawful interception techniques. The NSA has reportedly offered billions of dollars to anyone who can “offer reliable eavesdropping on Skype IM and voice traffic” [4]. Even though no backdoors or weaknesses in Skype’s encryption scheme have been disclosed, this trojan demonstrates that an attacker doesn’t need to exploit a flaw in Skype to eavesdrop on Skype communications. This is essentially a variation on the Man-in-the-Browser (MitB) techniques used by malware to steal information and commit financial fraud.

It seems novel that a programmer would release a trojan as free and open source software, however Unteregger stated in an interview that he wanted the code to be available to anyone who wanted to learn or add additional functionality [5]. In addition, since the code is published, it will be detected and blocked by most AV products. The trojan is currently detected by AV as Trojan.Peskyspy.

Fig. 2: Skype Trojan Source Snippet

After becoming infected, the trojan will attempt to disable the following firewalls (if they are present):

• Outpost firewall
• McAfee firewall
• ZoneAlarm firewall
• BitDefender firewall
• F-Secure firewall
• Kerio firewall
• AVG firewall
• Webroot firewall

A backdoor will be created, allowing an attacker to communicate with the victim’s machine. Once connected, an attacker may upload captured MP3 files, update the trojan, or remove the trojan from the machine. The released trojan does not contain a mechanism to spread itself, and has not been weaponized. The CTU believes that we may see variations of this trojan in the future and as always recommend keeping gateway and host AV signatures up to date and the use of a defense in depth approach to security.

References:

1. http://www.megapanzer.com/source-code/
2. https://support.skype.com/faq/FA145/What-type-of-encryption-is-used
3. http://blogs.zdnet.com/security/?p=4133
4. http://www.theregister.co.uk/2009/02/12/nsa_offers_billions_for_skype_pwnage/
5. http://www.megapanzer.com/2009/08/25/interview-on-gulli-com-about-the-skype-trojan-and-trojans-in-general-english/