Security Watch

FinCEN Hack Shows Importance of Role-Based Security

Hackers go phishing at the U.S. Treasury Department.

• By Russ Cooper
• 10/24/2005

This incident aptly demonstrates an age-old Cybertrust Essential Practice violation: namely, to separate the functionality of servers. Why should a Web server have any capability to send e-mails directly, and why should it maintain a list of e-mail addresses itself? Cybertrust Essential Practices dictate that server functionality should be split according to role; ergo, there should’ve been a Web server and a separate and independent mail server. Sending e-mails to the FinCEN subscriber list isn’t something the Web server needs to do automatically -- instead, a mail server could’ve been tasked with that role completely separate from the Web server. If such a configuration had been in place, the phishing e-mail would not have been possible simply by virtue of the Web site being compromised.

This same approach should be applied whenever possible. For example, why should a Web server be able to do a complete lookup of all database records it may have created? For example, let’s assume that a Web server created client records, including sensitive information such as the client’s e-mail address. At some point in time it needs to retrieve that client’s record. It should do so in a specific fashion, not a wholesale retrieval of all records and subsequent dataset search to find the one needed. As such, any attempt to execute a full select, or anything more than a single record lookup, should not be allowed by the database server. Should the Web server be hacked and an attempt made by the criminal to retrieve all records from the database, the database security would make it impossible to do so. The attacker would be limited to making repeated, single entry queries, presumably only with some knowledge of the data or key they are attempting to retrieve. This would make theft of, for example, entire credit card databases near impossible. Therein lies the value of role-based security.

Malicious Code
The Common Malware Enumeration (CME) initiative was released earlier this month. An extension of the Common Vulnerability Enumeration (CVE) exercise created by Mitre and several other organizations several years ago, this effort attempts to assign unique identifiers to high-priority malware events, thereby facilitating the coordination of malware information. The goal is to improve the current state of public information needed to respond to malware events. CME is not an attempt to solve the challenges involved with naming schemes for viruses and other forms of malware. Instead, CME is working with the security community to facilitate the adoption of a shared, neutral indexing capability for malware. An example of a CME identifier would be: CME-123.

If we ever needed proof that anti-virus vendors name viruses for purely marketing reasons, this is it. After all, who in the world actually cares what a virus -- or any piece of malware for that matter -- is called? Only the criminal who created it and the AV company who announced its detection have any vested interest. The public only cares that they can get rid of it, and they do that simply by running their AV product and hoping it will detect and remove the malware. If it cannot, they aren’t likely to go out looking for information on a name of a virus.

I was part of the founding board for CVE, and during its formation we had many debates about whether or not the effort should replace existing naming conventions (in that case, for vulnerabilities that vulnerability scanners could detect). There was so much pushback from the scanner vendors that it was decided we should simply create an enumeration, a numbered list, and leave the existing naming scheme alone. CME has followed this approach, showing that consensus can still not be reached.

So we will continue to have a malware naming debacle. For example, Zotob, the recent worm, had no less than 10 different names. Worse, Zotob.b from Vendor X might actually be Zotob.A for Vendor Y. CME will highlight these problems but won’t resolve it. Hopefully, someone will eventually put together a database of AV malware names versus CME numbers and vice versa. While such a database would prove interesting, even it won’t solve the problem.

Finally, talk now is that there won’t be a CME number for every piece of malware seen. Instead, only “significant” events will be given a CME number. Significant, presumably, means events that have more than X copies seen in the wild, but it may turn out to be events that multiple AV vendors have detected. In any event, a CME number will be an afterthought. Further, it may be that all variants of a given original piece of malware will get the same CME number. Should that happen, the number of viruses detected will go down dramatically when one looks at the CME database. That should make Microsoft very happy, even if it doesn’t ease your pain.

SymbOS/Cardtrap.A is a Symbian Trojan which also tries to infect the victim’s PC if the infected SymbOS phone’s memory card is inserted into the PC.

While this one isn’t a significant risk in the wild, it does demonstrate the potential for us having to revisit some very old anti-virus concepts.

In years gone by, we used to be very worried about floppy disks being brought into our organization without being checked for boot sector viruses. Now, with all of the portable media formats we have and use today, this concept may have to be brought back into fashion. Be it a memory card from a phone, camera, MP3 player or USB drives and their ilk, we have to accept that almost any of these devices could conceivably contain a virus. When those devices automatically launch programs (or have the capability to do so) when inserted into a PC, bingo, you have the old floppy disk problem all over again.

Since Windows 95, the Windows OS has had the ability to recognize the insertion of removable media. Today, that includes cameras and other memory card storage devices. If the device is recognized as a drive, it can contain a file called AUTORUN.INF. This file, if present, is read by the OS to determine what the OS should do when it recognizes the storage device. It can, for example, instruct the OS to execute a program contained on the removable storage. It is, therefore, no different than the old boot sector viruses that we worried about floppies containing.

Microsoft Knowledge Base article 150449 contains information about how to disable the AutoPlay feature in Windows, while KB article 895108 contains information about how to do this via Group Policy.

How far away are we from having D-Link 7-in-1 card readers at our reception desks connected to systems that automatically scan cards for viruses? Probably not as far away as we’d like.

Human Factors
The law firm White & Case LLP of New York recently conducted a survey of U.S. citizens asking how they felt about data security breaches. The results show respondents are not happy with how and when they’re being notified, even if they are being notified according to the laws that are in place.

The bottom line of the survey seems to be that the more personal and direct you can make notification, the happier your customers will be about the event. Twelve percent of the more than 9,000 individuals surveyed indicated they had been notified of a data breach involving their personal information, and the vast majority of those were customers or consumers, not employees. Twenty-eight percent of those surveyed said they had no idea about the facts of the incident, even after being notified. Most importantly, 20 percent said they were going to break their relationship with the company that suffered the breach, another 40 percent said they were considering it, and 5 percent said they had retained legal counsel. Don’t notify your clients well and you stand a good chance of losing the customer completely.

Online games may be as valuable as banks when it comes to phishing scams. With virtual currency abounding in the online gaming world, phishers are targeting such environments more often.

And why should this surprise anyone? Chances are your Runescape credentials are very similar to your on-line banking credentials given how people hate to have multiple passwords.