Category: Cybercrime

Fear, Uncertainty, and Doubt (FUD for short) can have very real effects on security, especially when used by security crackers to manipulate uninformed “experts” too quick to jump to conclusions. Mydoom was the canonical example of this idea in practice.

---

In the last week of January 2004, a new worm was discovered squirming its way across the Internet. Security researchers quickly realized this was the fastest-spreading email worm yet, eclipsing even the promiscuous Sobig worm. Craig Schmugar of McAfee saw a line of code containing the text “mydom”, and said of his decision to call it Mydoom:

It was evident early on that this would be very big. I thought having “doom” in the name would be appropriate.

The original Mydoom worm carried two payloads:

1. a distributed denial of service time bomb, set to go off on the first of February that year

2. a remote access backdoor that allowed an infected MS Windows computer to be controlled without its user’s knowledge

The DDoS Attack

The DDoS attack payload targeted SCO Group, a Unix vendor now famous for running itself into the ground making tremendously bad business decisions like trying to sue IBM on the strength of copyright claims related to Linux kernel source code. Several years of litigation led to SCO failing to substantiate its claims, breaking itself apart on the rocky shores of IBM’s stable of intellectual property lawyers like a termite-eaten rowboat in stormy seas. Novell joined in the fun, winning judgments against SCO showing that the SCO Group didn’t even “own” the copyrights it claimed were infringed by IBM and the Linux kernel in the first place. Such a DDoS attack was just salt in the wound.

SCO representatives played the event for all it was worth, of course, claiming that “the Linux community” just had a case of sour grapes and was targeting the corporation in retaliation for its copyright claims. Ultimately, however, security researchers and law enforcement agencies alike decided that wasn’t the case. They came to the conclusion that the entire SCO DDoS escapade was more smokescreen than petulant assault on an enemy of the Linux community, meant only to distract people from a much more insidious purpose of the email worm.

The Backdoor

Credulous commentators, willing to leap upon the most facile and sensational explanation that presented itself, had already bitten into the bait exactly as the worm’s author must have intended. They quickly dismissed any potential financial motivations for the creation of the worm, blaming it on those eeevil Linux “hackers“. By the time the truth started to surface, the damage was already done; while heads were turned in the direction of SCO and the Linux community, Mydoom and the Mydoom.B variant were still spreading.

Eventually, the backdoor was used to gain direct access to millions of infected computers, and on day eight after Mydoom was discovered personal data was downloaded from infected systems, resulting in billions of dollars of damage. Writers eager to publish dramatic headlines and boost readership, or just with an axe to grind, were hoodwinked and, unbeknownst to them, enlisted as part of the worm’s own disinformation campaign — which distracted just enough security researchers and law enforcement agencies, just long enough, to prove remarkably successful at its real aim.

You might say that Mydoom was one of the most successful attempts at security cracking through social engineering in history.

The Real Problem

The reasons people write viruses are many and varied. Some surely do so as a means of retribution for slights real or imagined. Many others, however, do so for profit, as was the case with the author of the Mydoom worm. This latter breed may boast very sophisticated, intelligent, and at best amoral individuals who do not hesitate to take advantage of technology commentators who leap at shadows. Security researchers, too, can be susceptible to manipulation, especially with the help of the IT trade press. Without such self-reinforcing tendencies to jump to conclusions, more attention may have been paid to the implications of the worm’s “other” payload, and much of the damage done might have been avoided.

Almost a year ago, I pointed out that security alarmism helps the bad guys win. It does more than that, though — it also directly hurts some of the good guys. The open source development community can claim many of the most respectful of copyright licenses and digital security of any software developers in the world. Despite this, incidents such as the early media frenzy about mythical disgruntled Linux “hackers” attacking SCO Group via an email worm that infected millions of computers in mere days continue to occur, creating in the minds of the most incredulous the impression that Linux is “a hacker’s OS”, with a decidedly pejorative bent to the use of the term “hacker”.

When you run across unsubstantiated claims in the information technology trade press, I hope you’ll look at the facts from every angle, and realize that many interpretations are often possible. Don’t become part of the problem — part of the social machinery that makes unsupported fear, uncertainty, and doubt so easily propagated.

When the next Mydoom comes around, your security may well depend on it.

Why do people write viruses and other mobile malicious code? The answer isn’t as simple as it used to be.

---

The image of virus writers as intelligent kids with too much time on their hands resorting to digital vandalism to entertain themselves persists. Years ago, making such a guess about why people write viruses might have been accurate most of the time, but the world has moved on. The writers of viruses and other mobile malicious code are many and varied, and their reasons are as wide-ranging as they are, themselves.

The forms of replicating mobile malicious code are multifarious, too. The most common forms are viruses, worms, and trojans, though non-replicating equivalents are gaining prominence as well. Cross-site scripting is an example of non-replicating code that serves much the same purpose as self-replicating malicious code; it can affect millions without having to actually “infect” the victim’s computer at all.

I can’t claim to know why everybody who writes malicious code does so. I haven’t met them all. I can make some generalizations about reasons people might do so, though.

• Anger Issues: There are those who, for whatever reason, just do destructive things for the sake of their destructiveness. They may be malicious narcissists, psychopaths, or just so self-centered in their impression that the whole world is against them that they will blindly lash out at anyone and everyone when they get the chance. For such people, who I believe are a thankfully rare breed, the harm they cause others has no point beyond the harm itself. They are unreasoningly destructive, and that’s pretty much all there is to it. They might think they’re misunderstood, and want to communicate with the world by harming it in some way — and maybe they’re right, that people just don’t understand them deep down. When they react to this state of affairs by maliciously setting out to harm anonymous strangers, however, I don’t think I want to understand them beyond the minimum required to track them down and put a stop to their antisocial behavior. Your mileage may vary, especially if you’re a criminal psychologist.
• Do It For The Lulz: Some still do it for the “fun” of destruction. They may get a thrill out of reading news items about their work causing people trouble, or they may just take a fire-and-forget approach, creating destructive, self-replicating programs for the joy of it without much caring whether they ever see the consequences themselves. Mostly, I’m sure they find it funny to read about people being inconvenienced by what they’ve done. In short, some people write mobile malicious code for the same reasons vandals break windows and spray paint garage doors that belong to people they don’t even know.
• Espionage: I’m not talking about sabotage here; I’ll address that later. By “espionage”, I mean attempts to gather information through underhanded means for reasons other than identity fraud and other directly, criminally profitable purposes. Viruses, worms, trojans, and even backdoors and other malicious code slipped into your software by the vendor may serve the purposes of espionage. People worry about the potential for Chinese manufactured computers having some kind of hardware backdoor built into them; conspiracy theories about commercial software vendors being required to provide backdoor access to the NSA run rampant; the government of India famously demanded that Blackberry provide universal decryption keys for all Blackberry devices sold in the country; and the NSA’s Dual_EC_DRBG NIST encryption standard may itself include a backdoor of sorts as I mentioned in What my grandmother taught me about IT security.

  Considering the fiasco of federal warrantless wiretapping violations of the law during the Bush Administration’s tenure, and the worse violations hinted at by several officials’ carefully phrased testimony that such worse violations weren’t a part of this particular program, it would be foolish to assume that government agencies never spy on people via software. How many of you remember ECHELON?

• Online Gangs: It probably sounds like something out of a 1980s vintage techno-thriller like Bruce Sterling’s Islands in the Net, but it is disturbingly becoming a reality — there are actual “gangs” of angry, or just plain ignorant, kids who engage in digital vandalism as part of a misdirected urge to enhance group identity and personal pride in a fractious, underground community. Such groups may target each other or, more often, some third party whose troubles at the hands of such a gang of vandals will be easily noticed and identified. With dramatic names like “Team Holocaust” and “Phalcon SKISMs“, such “cybergangs” may occasionally claim a higher purpose (like YAM), but may also have no pretentions of purpose other than claiming a strong group identity — like being a Denver Broncos fan, except they mark their territory with digital vandalism instead of by painting their torsos orange and waving giant foam fingers in the air.
• The Hacker Instinct: Keep in mind the difference between a hacker and a security cracker. With that in mind, people with a hacker mindset usually find themselves eventually drawn to specific fields of interest. In some cases, that interest might revolve around understanding self-replicating mobile malicious code. Sometimes, the best way to understand something is to experiment with different ways to create examples of it. Sometimes, the best way to test something you’ve created is to see it operating under real world conditions. Some immoral or amoral hackers with an interest in self-replicating mobile malicious code may test their creations by releasing them into the wild and seeing how they do.
• Money Money Money: Most writers of malicious code in the wild these days seem to fall into this category; people who are in it for the filthy lucre. Viruses and worms often carry payloads that open up avenues of intrusion into a system, providing a means for either security crackers or their automated tools to slip past the system’s defenses. Such automated tools can harvest authentication information and other sensitive data (such as for reasons of identity fraud), set themselves up as automated spam generators, or contact a centralized control mechanism of some sort such as an IRC chatroom to create a botnet of thousands, or even millions, of unwitting users’ computers, all of which can be controlled simultaneously by a single security cracker. It is increasingly common for botnets to be offered for rent, for any of a vast number of reasons.
• Political Agitation: Sometimes, digital vandalism — whether accomplished by a virus, a worm, a DDoS attack, or some other means — can be accomplished for the purpose of making a statement. Whether the reason for something like that is directly political in the sense of addressing matters related to government or more indirectly political such as unignorably interfering with certain types of Web sites and other operations of some class of people with whom one disagrees somehow, the point is sometimes to make people who aren’t directly responsible for whatever’s being targeted aware of one’s own disapproval of those targets. DDoS and other attacks against Microsoft or Yahoo! might fall into this category.

  Depending on their specific choices of targets and their motivating issues, some such political agitators (as in the case of those targeting, and protesting, Chinese and Australian national firewall policies) might even be admirable for their principles and the courage of their convictions to some degree. In extreme cases, on the other hand, such as where large numbers of innocent bystanders are materially harmed (having their checking accounts wiped out to make a political statement, perhaps), action taken on behalf of this kind of motivation might reasonably be called “terrorism”.

• Romance And Drama: Some may be drawn in by the perceived romance and drama of a criminal life itself. Just as some people may start out seduced to a life of crime by the power they perceive in street pushers in their neighborhoods, the exploits of cat burglars in movies, or the rare reports of some criminals who always seem to get away with their criminal acts in the news, the artificial mystique manufactured by the media around “Computer Hackers” can inspire the aspirations of the amoral youth with technical talents. Because of the character of certain online communities, it can be much easier sometimes to feed one’s own delusions of the romance and drama of being a “Computer Hacker” for a long time than in most other criminal enterprises where the physically gritty, and petty, reality of what they do becomes quickly inescapable. Once fully absorbed within such an insulated, self-reinforcing fantasy life, I don’t know how easy it is to overcome the illusion and realize that one has become nothing but a criminal security cracker, that being a real hacker is about skill and not 1337 h4xx0r nicknames, without being forcibly disillusioned by getting caught, prosecuted, and imprisoned for one’s crimes.
• Sabotage: Sometimes the purpose of malicious code might be directly targeted at disrupting the operations of some class of people one doesn’t like. While this sort of behavior might seem superficially similar to that of “terrorism” as described in the Political Agitation paragraph above, or to vandalism as described above, it’s not terrorism, and it’s more personal than typical vandalism. It is a simple criminal act, aimed at a specific target, more akin to assault. People with business interests may do this not for profit or for political purposes, but to damage other businesses’ ability to compete, at least temporarily. Government agencies may do so to try to bully another government into doing something it doesn’t want to do, as appears to have been the case in the Estonian “cyberwar”. The motivation to sabotage may even be based on something as petty as personal revenge.

If I had to guess, I’d say that the most common reasons to write viruses these days, by far, are at least somewhat profit-motivated. The I Love You email virus was kind of a watershed incident, in that it was the point where a lot of people really started noticing the growing trend in profit-generating mobile malicious code.

Any attempt to explain away all virus, worm, and other malicious code writing using a single generalization is unreasonably simplistic, though. Virus writers are people, too — at least in that they may have any of millions of different motivations for what they do — even if they’re often subhuman in some respects as well (notably their ethical development). Most are probably motivated by some combination of more than one of the above suggestions, in fact, and perhaps by other reasons as well.

Personal Identification Numbers, or PINs, are supposed to provide secure authentication for bank cards. Unfortunately, they are increasingly failing to do so.

---

Most of you have probably heard about ATMs with skimmers mounted over the card slot that can read your card on the way in and out of the machine, with carefully placed cameras to read your PIN as you type it in. The person setting up this little trap can then clone the card with the skimmed data, and with the pin gets access to your bank accounts. The first time I remember hearing about that method for cracking PIN security on bank cards was in the early ’90s, so it’s not exactly a new technique.

More recent developments in bank card security cracking include malicious phishing Websites, cross-site scripting, and legitimate Websites that have been directly compromised by security crackers. It’s an especially disturbing phenomenon because bank cards don’t usually have the same zero liability protections as credit cards — a fact most users of debit cards don’t think about when they use their bank cards the same way they’d use credit cards.

A new, and even more disturbing, security vulnerability for bank cards has arisen.

A research fellow at the French National Institute for Research in Computer Science and Control (say that five times fast) named Graham Steel wrote a paper in 2006 that addressed vulnerabilities in the hardware security modules that tie the bank card authentication network together. The paper, submitted to British HSM manufacturer nCipher, provided guidelines for hardware security module configuration that would help mitigate the vulnerability of the devices to attack, but it also pointed out that other aspects of HSM vulnerability were inherent to their design. To really and truly fix the problem of HSM vulnerability, the devices would have to be fundamentally redesigned in a manner that is not backward compatible. Payment processing networks across the globe would have to be reimplemented using a different, improved standard.

HSM manufacturers such as Thales-eSecurity maintain that they address the security vulnerabilities addressed by Steel’s paper, but thus far they seem to be taking an approach remarkably similar to the way Microsoft OSes are “secured” against viruses. Other reassurances that HSM manufacturers are seeing to our security involve statements about how the devices are delivered in a very secure configuration by default, which is all well and good if you don’t need them to actually do much. Unfortunately, most payment processing transactions require functionality to be enabled that exposes the devices to significant potential for compromise. As Brian Phelps of Thales-eSecurity put it, according to the Wired article PIN Crackers Nab Holy Grail of Bank Card Security:

It’s a very difficult challenge to protect against the lazy administrator. Out of the box, the HSMs come configured in a very secure fashion if customers just deploy them as is. But for many operational reasons, customers choose to alter those default security configurations — supporting legacy applications may be one example — which creates vulnerabilities.

He went on to confirm Steel’s estimation of the scope of the problem, saying that redesigning the payment processing system to comprehensively address the current vulnerabilities due to legacy systems compatibility needs “would require a mammoth overhaul of virtually every point-of-sale system in the world.” If this doesn’t send a chill down your spine, either you aren’t paying attention, or you don’t actually use a bank card.

It is only recently that verifiable incidents of PINs being skimmed from HSMs, either gathered unencrypted from the device’s volatile memory or picked up as encrypted PIN blocks and decrypted. In some cases, at least, the decryption is made possible by the fact that the HSMs themselves contain decryption keys, and once one encrypted PIN block is decrypted it becomes much easier to decrypt the rest of them.

At first glance, one might think that the idea of storing decryption keys on devices scattered around the country that relay PINs from point to point using a model conceptually similar to Internet routing itself should have been immediately recognizable as a bad one, thanks to the example of the inherently flawed concept of digital DRM. Of course, the design of payment processing hardware security modules predates the AACS key for HD-DVDs, the Sony DRM rootkit, and Microsoft’s WGA. HSM designers get a free pass on learning from the mistakes of others, although the fact the mistake was made in the first place should have been avoidable.

For the most part, the problem is the way HSMs pass PINs around, tend to have scads of unnecessary features enabled at any given time, and contain the keys needed to decrypt the encrypted PINs. A couple of key points include:

• End-To-End Encryption: The PINs should be encrypted and decrypted only at the end-points. Encrypting and decrypting anywhere between those points just increases the options for unauthorized interception.

• Private Key Encryption: Using standardized encryption keys is tantamount to criminal negligence in this age of private key cryptography. Each and every end-point, including the bank cards themselves and the receiving systems that need to authenticate a request, should have a private and public key set. This way, you’d only be able to read data if you’re one of the unique end-points that is supposed to have access to it.

As things currently stand, however, the likelihood of the system being overhauled is pretty slim due to the immense cost that would be involved in replacing an entire global payment processing network with an incompatible standard. As a result, this problem is likely to be addressed only in a superficial, “it works right now and that’ll have to be good enough” manner. In many cases, it may not even be secured that well. Be extremely careful where you use your bank cards in the future. While liability protection for credit cards tends to be better than for debit cards, even there you should be wary of the potential threat.

I, for one, prefer to use cash anyway. Credit card and ATM transactions often impose fees on the user, and even when they don’t, it’s usually because one financial institution or another involved in a given transaction just “eats” the cost. Such behind the scenes payments contribute to price inflation, depressing the value of my money, which I tend to consider a bad thing.

With the revelation of incidents in the wild where the vulnerabilities discovered by Graham Steel (and others) are exploited to harvest PINs directly from payment processing networks around the world, I have one more reason to prefer cash transactions.

The PCI Security Standards Council has stated that it will begin a hardware security module testing program that focuses on “security properties that are critical to the payment system.” I hope the problem turns out to be more easily solved than the evidence thus far seems to suggest, but I’m not holding my breath. The problem appears to be endemic to the system itself, as it is currently designed and implemented.

The Tibetan Government in Exile asked the Information Warfare Monitor consortium to investigate allegations of cyberspying. It appears they’ve found evidence of spying plus a whole lot more and that should concern all of us.
——————————————————————————————————————-

To begin, Information Warfare Monitor (IWM) is a well-regarded research team consisting of the SecDev Group and the Citizen Lab, Munk Center for International Studies, University of Toronto. The following skill set will explain why the Tibetan government asked the IWM for help:

Operational Case Studies: Consisting of active operational research employing a cross-disciplinary fusion of intelligence gathered at the field level with advanced network monitoring/visualization techniques.

Analytical products: Generate case study data that illustrate the strategic significance of cyberspace and highlight the opportunities, challenges, and threats implicit to a militarization of cyberspace, including effects generated by third-party actors.

From the beginning

This compelling story about the Dalai Lama and the Tibetan Government in Exile started almost a year ago. That’s when office workers began to complain about misbehaving computers. To us IT types that may seem like business as usual, yet it was the first clue of something being drastically wrong.

After some initial troubleshooting by the Tibetan IT personnel, the IWM group was called into help. It didn’t take analysts from IWM long to determine that several computers were indeed victims of a Trojan program called Gh0st RAT. For those interested, it’s an offspring of the famous Poison Ivy trojan.

Infection via e-mail

The next step was to figure out how the computers were being compromised. IWM researchers eventually determined that opening an attached document (containing malware) was the catalyst for becoming infected. I couldn’t find any mention as to what dropper program was used. Moot point I guess, as the goal was to successfully get Gh0st RAT on the intended computer. The research paper did mention:

“Only 11 of the 34 anti-virus programs provided by Virus Total recognized the malware embedded in the document. Attackers often use executable packers to obfuscate their malicious code in order to avoid detection by anti-virus software.”

Even so, malicious attachments are a well-known attack vector and that method shouldn’t have worked, right? Maybe, except these attackers were very creative, using appropriate e-mail addresses and realistically-named attachments like “Translation of Freedom Movement ID Book for Tibetans in Exile.doc”. Honestly, the following example looks official to me:

Even sneakier

Misleading the office workers became easier for the attackers once several computers were infected, simply because the attackers then have authentic documentation and contact information:

“Once compromised, files located on infected computers may be mined for contact information, and used to spread malware through e-mail and document attachments that appear to come from legitimate sources, and contain legitimate documents and messages.”

Something I didn’t think about was the coincidental spreading of Gh0st RAT. Since the attachments looked real and Gh0st RAT typically doesn’t affect normal computer operations, workers may have inadvertently sent the malicious attachments to others, hastening the trojan’s propagation:

“It is therefore possible that the large percentage of high value targets identified in our analysis of the GhostNet are coincidental, spread by contact between individuals who previously communicated through e-mail.”

I’m not sure how you combat social-engineering; it’s been around a long time and appears here to stay.

Sadly enough, that wasn’t the Tibetan system administrator’s only problem. They had the exploitable operating system vulnerabilities (we all know and love) to deal with. The report didn’t offer any more detail, so I’m not sure whether the attackers used zero-day exploits or if the computers weren’t fully updated.

What’s Gh0st RAT capable of?

Ghost RAT (Poison Ivy) is considered a Remote Administration Tool (RAT), basically a remote access program like VNC. Allowing the attacker almost complete control over the victim computer. Poison Ivy/Gh0st RAT is capable of the following:

• Files can be manipulated completely and the attacker can upload/download files to and from the system.
• The registry can be viewed and edited.
• Active services can be viewed, suspended, or shut off.
• Enabled network connections can be determined and shut disabled.
• Installed devices can be viewed and some devices can be disabled
• Installed applications can be viewed and entries can be deleted or programs uninstalled.

Being recently updated, Gh0st RAT has a few additional features that make it an effective spy tool:

• Screenshots of the desktop can be taken,
• Web cams, microphones, and audio/visual recording programs can be enabled to act as surveillance devices.
• Passwords and password hashes are saved.
• Key loggers can be used in conjunction with other devices to steal information.

All and all, it appears to be an efficient remote admin tool. If you aren’t convinced, check out Symantec’s detailed video that explains Gh0st RAT’s capabilities.

Many Gh0st RATs equal GhostNet

I consider the discovery of the GhostNet to be exemplary detective and forensic work. Initially the IWM team didn’t know what to expect as they worked their way from individual computers infected with Gh0st RAT back to the GhostNet control servers:

“During this process we were able to find and access web-based administration interfaces on the control server identified from the OHHDL data. These servers contain links to other control servers as well as command servers, and so therefore we were able to enumerate additional command and control servers.”

Once they had penetrated the control servers they began to get an idea as to how many computers were members of the GhostNet:

“In total, we found 1,295 infected computers located in 103 countries. We found that we were able to confidently-on a scale of low, medium, high-identify 397 of the 1,295 infected computers (26.7%), and labeled each one as a high-value target. We did so because they were either significant to the relationship between China and Tibet, Taiwan or India, or were identified as computers at foreign embassies, diplomatic missions, government ministries, or international organizations.”

Further insight

I’d recommend listening to Jesse Brown’s (CBC.ca) podcast titled, “Exposing the world’s biggest cyberspy ring“, as he interviews members of the IWM team who were directly involved with the project. I’d also like to recommend the IWM’s official report, “Tracking GhostNet: Investigating a Cyber Espionage Network“; I consider it to be an exceptional document, offering proof as well as a definitive explanation of the entire investigative process. It’s the report that I’ve quoted numerous times in this article.

Final thoughts

It sounds like the Internet is slowly becoming a war zone. How prevalent is this type of electronic espionage? Who’s involved, or is it easier to say who isn’t involved? Depressing isn’t it. Odd as it sounds, I remain hopeful because of organizations like IWM. Their hard work is making the Internet a safer place.

TechRepublic’s IT Security e-mail newsletter (delivered every Tuesday) is a great way to keep on top of security issues related to Information Technology. Please make sure to sign up.

Still looking for an easy, affordable solution for encrypting USB storage?  Working on a limited budge while trying to figure out how to force encryption of mobile data?  Your problems may be over if you can wait for Windows 7.

——————————————————————————————————————-

Windows 7 contains several new features, including one I’m pretty excited about: Bitlocker To Go.  Expanding the Bitlocker offering in Vista, Microsoft provides encryption support for removable USB storage—a wide channel for escaping data—on the Enterprise and Ultimate versions of its new, still in beta, OS.

Bitlocker ToGo Features Overview

Bitlocker To Go (BtG) provides a right-click selection to enable encryption, as shown in Figure 1.  The drive selected is a Lexar 512MB USB flash drive.

Encryption time is pretty fast, and the final result is a mobile storage device which can be accessed only with a password, passphrase, or PIN.  And access isn’t limited to Windows 7 systems.

Files on a BtG protected device are not only accessible by Windows 7 systems.  They are also available using Windows XP and Vista.  Files written to the drive during the encryption (shown in Figure 2) process make this possible.  If auto-running applications when connecting a USB drive is disabled on your computer—and it very well should be—selecting the drive via Windows Explore displays the BtG application (arrow).  The files shown in this picture are only items accessible until the drive is unlocked.

Unlocking a BtG encrypted device on a Windows 7 system allows a user to see it as standard drive, with both read and write privileges.  However, using XP or Vista provides read only access, requiring copying a file to the local drive before access is granted.

No action is necessary to relock a drive other than removing it from the USB port.  Security managers don’t have to worry about someone forgetting to lock a device or copy a file to a secure area before taking it on the road.  Further, use of BtG on any connected USB storage is controllable with group policy object settings.

So what didn’t I like?  Not much, actually.  The biggest issue I had during testing was the lack of an un-encrypt function to restore the drive to an unprotected state.  It might exist, but like other functions in Windows 7 beta it might simply be in an  inconvenient (where I can easily find it) location.  Otherwise, I think this is a great new feature; one I wish was available on all versions of Windows 7 and Vista.

If you’re interested in a more detailed description of how to use BtG, read on.

Setup and testing

For my test, I used a Dell desktop running Windows 7 beta (Ultimate) and a Dell laptop running Windows XP SP2.  There’s nothing to download or set up to get started.  BtG is part of the standard install.
I plugged the 512MB Lexar drive into a USB port on the desktop and waited for Win7 to set it up for use.  I then brought up the drive list, right-clicked on the Lexar, and selected Turn on Bitlocker, as shown in Figure 1.

The first window to appear is shown in Figure 3.  I had a choice between using a password, a smart card, or both.  I chose password only.  The application checks the strength of the password entered.  If it doesn’t meet the requirements for a strong password, you can’t proceed until one is entered which does.  If in doubt, help is available in Win7 which describes what makes up an acceptable password or passphrase, as shown in Figure 4.

After entering a strong password, the drive was encrypted (less than two minutes) and I was asked how I wanted to store my unlock code.  The unlock code is used when the password or passphrase is forgotten or a smart card lost.  As shown in Figure 5, I could save it to a file or print it.  Although Microsoft recommends doing both, I opted to only store it in a text file on my desktop’s local drive.  And that’s it.

To test unlocking the drive, I removed it from the USB port, waited a second or two, and plugged it back in.  Win7 immediately saw it was a BtG enabled device, and displayed the unlock window shown in Figure 6.

The first time I tried this, I entered my password and the drive was instantly ready for use.  During the second test, I clicked I forgot my password which brought up the unlock key entry screen in Figure 7.

Note the recovery key identification code.  This is written to the drive when encrypted to identify the device.  It is also written to the text file or printed with the recovery key so you know which recovery key goes with which drive.  I copied and pasted the recovery key from the text file created earlier.  The next step provided the option of changing the password or authentication method to facilitate future access.

Since this worked flawlessly, it was time to test accessing the drive from my XP-based laptop.  Since autorun is disabled, I had to select the drive from Windows Explorer and manually run BtG, as shown in Figure 2.  This brought up the unlock window in Figure 8.

Note the difference between the XP unlock and the Win7 unlock shown in Figure 6.  At any time I can tell BtG on Win7 to automatically unlock my device.  This is not an option for XP.

I entered my password, and an Explorer-like window appeared telling me to copy the files I wanted to view to the local drive.  This is necessary on non-Win7 systems or the files are not accessible.  I also attempted to copy a file back to the drive without success (not a supported feature, but you never know…).

Overall, I found BtG a great addition to Windows for both individual and business users.

In November 2007, I wrote about the Identity Theft Enforcement and Restitution Act of 2007, its stated intent, and some possible results of the passage of such an Act. At the time, it had only passed the Senate, and was still being debated in the House.

Since then, it became the Identity Theft Enforcement and Restitution Act of 2008, and was eventually passed as an attachment to the Former Vice President Protection Act of 2008. In its final form, the ITERAct turned out to be roughly what I expected: a largely pointless, uninteresting increase in the amount of bureaucratic red tape that applies to the legal treatment of computer related crimes, a collection of special case instructions to the courts.

The best possible outcome, as I pointed out in my previous article on the subject, might have included protections of citizens’ privacy with a federal legal recognition of the unethicality of willfully violating personal privacy regardless of the perpetrator. Instead, it reads more like a cross between redundant “hate crime” laws and grandstanding “tough on crime” three strikes legislation — the kind of legislation that may actually encourage greater crimes in cases where doing so might reduce the likelihood of getting caught.

I was reminded of this 2007 article of mine, titled What my grandmother taught me about IT security, when I received news this morning that my grandmother had passed away. Her words to me when I was young, quoted at the bottom of the article, carry the essence of the wisdom that sustains my integrity when dealing with others’ secrets. She said:

It’s not you I don’t trust with my secrets. It’s the people you’d tell.

Of course she didn’t mean me, per se. She made a point to me about keeping someone’s confidence, stressing that when one is entrusted with a secret, it is not up to me who is worthy of the trust of sharing that secret. Only the person who imparted it to me may rightly make that decision. It is a lesson I have carried with me for the rest of my life.

She also taught me to spell “refrigerator” at an age when many children aren’t even expected to be able to spell their own names. It’s funny, the things that spring to mind sometimes. Just as I’ll never forget these lessons, I’ll never forget her.

Customers and employees of firms that trade stocks and options beware, the Tigger.A trojan is targeting you. Learn how and why.
——————————————————————————————————————-

Lately, I’ve been spending an inordinate amount of time fighting malware. My latest adventure started when a friend called me last Friday complaining that his computer was acting weird (his words). After a few questions, I sighed as the computer had all the signs of having caught something.

Normally this isn’t a big deal. I have a spare notebook that I let people use while I’m working on their computer and my friend was counting on that. His stress level went up considerably once I told him that the spare was already loaned out. It seemed like only seconds later that my friend dropped off the computer and said please help.

To explain, my friend makes his living as a day trader (even in these tough times) and he needed his computer by early Sunday evening for the Far East stock markets. After his ranting subsided, I couldn’t resist mentioning about all the times I reminded him that he needed to have a spare computer just for situations like this. I’m not going to repeat what he said.

Curiosity prevented an immediate rebuild

I normally consider this type of problem an immediate rebuild, but I wasn’t looking forward to that as I’d forgotten to image his computer when I originally set it up. That hesitation coupled with the fact that I wasn’t super busy, (don’t tell my friend that) allowed my curiosity to get the best of me. I really wanted to find out what was causing the problem, simply because I setup his computer identical to mine. I also know he religiously keeps his computer up to date. So this shouldn’t have happened, as he told me repeatedly.

Thankfully, I didn’t have to worry about data as my friend keeps all of his files on secure flash drives. So, I started investigating, at least as much as I could. The computer was indeed acting flaky. One thing that I look at first is the list of Microsoft updates that are installed on the computer.

I use Windows explorer to drill down to C:\Windows and all the updates are listed there. As I compared what was visible on my friend’s computer to a known good list I noticed that $NtUninstallKB956803$ was missing. Hmmm. That update refers to MS08-066. I wonder why that didn’t get installed during the Windows Update cycle. Could that be the chink in the armor? The above slide shows what is supposed to be there:

Malware named Tigger, how dare they

Before I started scanning the problematic computer, I did some digging on the Internet. Almost immediately, I came across an article titled Why I Enjoyed Tigger/Syzor by Michael Ligh an iDefense security analyst and malware reconstruction expert. Whoa, that’s one bad trojan. According to Ligh, Tigger/Syzor is one of the most sophisticated pieces of malware that exists today:

“The trojan uses a privilege escalation vulnerability (MS08-066), which is almost an exact replica of the public exploit on Milw0rm. It disables Windows Defender, Windows Firewall, Outpost, Avira, Kaspersky, AVG, and CA products in unique ways such as posting malformed messages to windows owned by the daemon processes, sending special byte codes over named pipes, and using the products’ own API.”

Did you notice the reference to MS08-066? That’s what tripped my Google search and caught my attention. Ligh continues to explain:

“It installs a rootkit that runs in safe mode. The rootkit disables kernel debuggers, hooks FAT and NTFS file system drivers, and also prevents other processes from accessing the kernel driver’s memory so tools like GMER and IceSword can’t recover the .sys from RAM.

Tigger of course also injects code into user-mode processes. This component takes screen shots, hooks COM for spying on browser events, and exports passwords (protected storage, network and dial-up, and at least 11 popular chat, email, and remote access applications). It also steals web cookies, steals certificates, and puts the NIC in promiscuous mode to sniff FTP and POP3 passwords.”

Just those abilities make Tigger/Syzor pretty impressive as trojans go. Yet the list goes one. According to ThreatExpert.com, the trojan also logs keystrokes, collects system information, enables a backdoor on compromised computers, finally trying to initiate communications with command and control servers. To learn what domains are being used check out the Malware Domain List Web site.

Tigger/Syzor tries to do some good

In what may be construed as an ironic twist, Tigger/Syzor tries to remove other forms of malware (up to 20 different types) from its host computer. Experts feel that this was included to try and make the computer act as normal as possible. The part that I find intriguing is how it does all of this while keeping a very low profile. Ligh further explained how Tigger/Syzor is able to accomplish this:

“The method that it uses to fork commands to the system and capture the output involves the use of temporary desktop stations so that window messages output by the programs don’t get posted to the same desktop station as the logged-in user.”

Tigger/Syzor targets people into stocks

While researching this resourceful piece of malware, I came across an article by Washington Post’s Brian Krebs titled The Tigger Trojan: Icky, Sticky Stuff and immediately noticed that this trojan introduced yet another unique twist. For some reason, Tigger/Syzor is specifically targeting people that work for or are customers of firms that trade stocks and options. According to Krebs, it’s a very short specific list:

“Among the unusually short list of institutions specifically targeted by Tigger are E-Trade, ING Direct ShareBuilder, Vanguard, Options XPress, TD Ameritrade and Scottrade.”

My curiosity was greater than my concern of yet another tirade from my friend, so I called and asked if he had dealings with any of the above mentioned firms. Sure enough, he dealt with several of them on a regular basis. So beware if you are associated with any of those institutions.

Relatively unknown

Krebs mentioned that Ligh first found evidence of the Tigger/Syzor trojan in November of 2008. After four months, I thought there’d be more information about this trojan, but oddly there’s not much at all. It could be due to the lack of rational displayed by the anti-malware industry when it comes to labeling these threats, causing me to miss some information. I doubt it though, it appears that Tigger/Syzor is just going about its business quietly.

Back to my friend’s computer

The fact that it’s relatively unknown had me wondering if I was going to have any luck in removing the trojan. I also could tell it was a smart piece of malware as it wouldn’t allow me to install HiJackThis or MBAM. I didn’t even try GMER, based on what Ligh mentioned in his article.

I used a trick that I learned from several TechRepublic members and renamed the MBAM installation file, which allowed MBAM to be installed. I then renamed the MBAM executable and it ran as well. I found several files that were considered malware by MBAM and removed them. Ran MBAM several more times, eventually resulting in a clean machine.

On the surface, I could tell the computer was now operating normally. Still, I didn’t trust it and eventually rebuilt the system, just to be safe. I made an image this time as well. Still, I’m glad I took the time to determine what was happening. It sure was an eye-opening experience.

Final thoughts

I mentioned earlier that the Tigger/Syzor trojan is designed to be very quiet, leaving the user totally unaware of its presence. So my friend was fortunate in that something must not have been right between the operating system and the trojan as it was far from quiescent.

I’d like to leave you with one final thought from Michael Ligh as it’s my perception as well:

“The scary part is, none of us are really sure how Tigger is even being distributed. I look at a lot of info-stealing malware, and this is the first one I’ve seen in a while that goes to the trouble of removing other pieces of malware.”

Worried about security issues? Who isn’t? Delivered each Tuesday, TechRepublic’s IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

The browser is typically blamed for most if not all Web-related security problems faced by business and home users. But the browser isn’’t the problem. The real problems still sit under the browser and about 19 inches from the monitor.

——————————————————————————————————————-

Security blogs and articles about browser problems abound. The browser is typically blamed for most if not all Web-related security problems faced by business and home users. However, this position doesn’t resonate with the way I see security today. It isn’t the browser that’s the problem. The real problems still sit under the browser and about 19 inches from the monitor.

Ok, so a browser with some security features is a good idea. Why open the gate completely when you’re certain barbarians are lurking on the other side. But relying only on the gate to defend the castle is a bad idea.

Another way of looking at the problem is from the perspective of disease control. Melith Abdulhayoglu wrote about this in a recent Security Focus article.

There was a time when most diseases were fatal for humans. Intense study and research helped doctors manage diseases better, and subsequently even prevent them altogether.

Today, vaccination is an established and permanent method of preventing diseases by strengthening the body’s natural defenses against the causal elements. The solution lies in eliminating the threat by shoring up the immune system and creating a wall of defense, and not in just managing the symptoms.

The same principle applies to Internet browsers too. True, browsers do come with a built-in security mechanism. However, it should not be their job to be on watch all the time. Browser[s] are there to perform a function: to browse the Internet. Rather than also attempt to secure the user, they should work together with security products to protect the computer network and data against intruders and prevent attacks.

Source: Don’t Blame the Browser, Melith Abdulhayoglu, Security Focus, 6 February 2009

The key statement here is that browsers are intended to perform a specific function, browsing, not protect your computer from the thousands of exploits floating around the net. And they should never be expected to protect the business network from user behavior. The browser can only do so much, and we have to expect bad things to come through it into our systems. The question, then, is not how well our browsers stop exploits. Rather, we need to ask ourselves how prepared we are to defend against inescapable successful infections of one or more computers connected to our enterprise networks. And what precautions do we take when risky Web browsing is either necessary or inevitable?

Let’s start with the second question first. How DO we ensure safe browsing? For example, I’m always visiting new and interesting Web locations in my research. No browser on the market today can completely protect me from automated nasties I occasionally encounter. Further, I want to click on the unknown just to see what will happen. So how do I protect myself?

First, I don’t rely on my browser. Although I use Firefox for general browsing, I use Google’s Chrome for research. Yes, Chrome. I find that it is a much better tool than Firefox to support the way I work. Do I rely on Chrome to protect my computer? Not a chance. I do, however, rely on the steps I take to minimize the risk to my home research network.

1. I run Chrome sandboxed with Sandboxie. Any stuff that finds its way onto my computer is not permanently stored. When I close the sandbox session, all unwanted visitors are deleted. This is supplemented in the new version of Sandboxie with a DropMyRights-like setting that allows me to work within the sandbox without local admin rights.
2. All computers are protected with a firewall, anti-virus, and anti-spam software.
3. All computers are patched with the most current security patches. This is the most important path to an inoculated computing environment.

I also use good old common sense. However, I can’t rely on common sense at the office. So, I add the following:

1. The network is monitored for anomalous behavior, including extrusion and data leak prevention.
2. Web filtering to minimize inadvertent visits to high risk sites.
3. Awareness training in the hope that it will cause at least some users to think before they click.
4. Where possible, users are not given local admin rights on desktops and their use of handheld devices is controlled.

Finally, I assume there will be an infection or a breach, and I plan for it. No one should expect a strong layered approach to stop a strongly motivated attacker. Nor should we expect any number of security controls, no matter how strong, to protect our networks when users continue to invite disaster. So how can we expect a browser, any browser, to provide end-user device or network security?

My only expectation of a browser is that it works as advertised with no vulnerabilities caused by careless programming or negligent design. Maybe we should ask our browser vendors to focus on these outcomes while we look for other ways to secure our computing environments.

Before you install a wireless monitoring and control system, check to see if it uses DECT/CAT-iq technology. If it does, make sure you’re not filling the local 1.9 GHz airwaves with information you’d rather not release to an attacker.

——————————————————————————————————————-

Use of Digital Enhanced Cordless Telecommunications (DECT) has been growing rapidly outside the United States. Since 2005 it has been gaining ground in the U.S. as well. DECT brings to wireless communication several improvements over traditional solutions. Starting with cordless phones, it has spread to credit card readers and other wireless devices used every day in businesses around the world. But there’s a catch. A group of security researchers has found a serious flaw in DECT’s proprietary encryption solution.

Before looking at the encryption issue and associated risk, it’s important to understand why you should care, even if you don’t currently use DECT enabled devices in your organization.

The Opportunities

Typically operating in the 1880 to 1900 MHz band, DECT “…provides a general radio access technology for wireless telecommunications,” as shown in Figure 1 (DECT Forum, 1997). In the U.S., DECT is licensed by the FCC to operate in the 1920 to 1930 MHz, or 1.9 GHz band (DECT, Wikipedia.org).

According to the DECT Forum, initially planned uses for DECT applications included,

• Residential
• PSTN access
• Wireless PABX
• GSM access
• Wireless local loop
• Cordless terminal mobility (CTM)
• LAN access, supporting
  • Voice
  • Fax
  • Email
  • Internet

Some of the need existing in the era during which the DECT standard was created (1990’s) has been met with the rapid spread of cell phones. However, the advantages DECT brings to today’s communication challenges have resulted in it finding its way into other areas, including wireless credit card readers and data transfer. So what’s the big deal? Why not just stick with the old technologies? There are several reasons in the voice realm (DECT Features, Wikipedia.org), including:

1. DECT does not typically cause or experience interference problems when installed in areas where Wi-Fi, Bluetooth, or other wireless technologies exist
2. A single base station can support multiple phones
3. DECT enabled phones can place intercom calls to each other
4. Base-to-phone range can extend up to 100 meters, depending on environment
5. DECT devices use less power resulting in extended battery life

And DECT was expected to spread to data networks due to its ability to overcome many of Wi-Fi’s challenges (DECT for Data Networks, Wikipedia.org), including:

• Range up to 200 meters indoors or 6 km using directional antennae outdoors
• Dedicated spectrum
• High interference immunity
• Open interoperability
• Expected data rates of 500 Kbps to 1Mbps

DECT did not quickly become a replacement for Wi-Fi, primarily due to U.S. restrictions on its use until 2005. Now, however, it is emerging as a possible option for many voice and data solutions requiring high reliability, low power consumption, and lower data transfer rates.

The DECT standard makes use of several advanced digital radio techniques to achieve efficient use of the radio spectrum; it delivers high speech quality and security with low risk of radio interference and low power technology. TDMA (Time Division Multiple Access) radio access, with its low radio interference characteristics, provides high system capacity to handle up to 100,000 users per km floor space in an office environment. DCS/DCA (Dynamic Channel Selection/Allocation) is a unique DECT capability that guarantees the best radio channels available to be used. This happens when a cordless phone is in stand-by mode, and throughout a call. This capability ensures that DECT can coexist with other DECT applications and with other systems in the same frequency, with high-quality, robust and secure communications for end-users. Other features of the DECT standard include encryption for maximum call security and optimized radio transmission for maximum battery life.

Source: Wireless Technology Choices Abound for Medical Monitoring, Tim Moore, RTC, January 2005.

Solutions include manufacturing and medical devices for monitoring and control. Figure 2 (Source: Moore, RTC, 2005) depicts how DECT might be used in a health care environment.

Moore provides a comparison of ten candidate wireless technologies for monitoring and control systems, shown in Table 1 (Source: Moore, RTC, 2005). DECT is becoming an even bigger contender in the wireless space with its “next generation” iteration known as CAT-iq.

DECT has stood up well as the best technology choice, based on this list of categories, until 29 December 2008. On that day, security researchers demonstrated a serious flaw in DECT’s security design.

The Risks

One of the security features of DECT is its proprietary encryption. This and other characteristics of DECT allowed proponents to tout it as a very secure technology. According to a 2007 whitepaper on DECT security,

The risk that intruders could pick up DECT signals and hack their way to critical information in telephone conversations is unfounded, due to the lack of suitable equipment to perform such an intrusion.

Even in the very unlikely scenario of DECT radio signals being picked up by a third party, it would require an enormous amount of computer power and transactions collected over a period of several months to make anything meaningful out of the signals.

Source: DECT provides high protection against unauthorized access, Jabra, 2007

That was then. At the 25th Chaos Communications Congress in Berlin, German security experts demonstrated their ability to easily and economically force unencrypted DECT communication and intercept it.

The attack on DECT, demonstrated at the 25th Chaos Communications Congress in Berlin on 29 December, used a Linux laptop with a modified €23 laptop card.

It can intercept calls and information directly, recording it in digital form. Even if encryption is switched on, the system can bypass encryption - simply by pretending to be a base station that doesn’t support it.

Source: DECT Phones and POS terminals are vulnerable, Peter Judge, Techworld, 5 January 2009

The weakness found in DECT is not a bug. It is part of its design, enabling communication even if the handset and the base cannot establish an encrypted session. I called three DECT compatible phone resellers and none knew of a way to only allow encrypted sessions. So an attacker could potentially intercept any DECT traffic, voice or data, even if it contained patient or credit card information.

This is a serious flaw in an otherwise very promising technology. The DECT Forum, the driving force behind the standard, issued an ambiguous response to the December demonstration:

“The DECT Forum welcomes open discussions about how the implementations of the DECT standard can be improved”, says Erich Kamperschroer, Chairman of the DECT Forum. “Therefore we are looking forward to collaboration with researchers in order to discuss their research results and find measures how to further improve a reliable and mature technology that is used worldwide every day by millions of users.”

[…]

With the introduction of CAT-iq (Cordless Advanced Technology), the successor of DECT, the DECT Forum has demanded highest possible security protection measures as mandatory, which will be implemented into a globally applicable standard.

Source: DECT Forum Statement on DECT Wireless Technology, 13 January 2009

So before you install a wireless monitoring and control system, check to see if it uses DECT/CAT-iq technology. If it does, make sure you’re not filling the local 1.9 GHz airwaves with information you’d rather not release to an attacker. Hopefully the organizations behind the DECT Forum are working harder on a solution than the press release indicates. This technology has a lot of potential.

Tell us about your organization’s use of this technology

Are strong passwords still the best defense, or is a layered controls framework, including intrusion/extrusion response, sufficient to effect strong access control?

——————————————————————————————————————-

I’ve long been a proponent of not imposing strong login passwords on business users.  There are several reasons for this, not the least is user willingness to write down complex passwords and post them where conveniently accessible–by anyone.  This behavior defeats strong passwords every time.

Now there might be a reason to reconsider, maybe…

A complex computer worm has infected corporate networks and has affected more than 10 million computers this week, experts say. Infecting computers in the U.S., Europe and Asia, the Downadup worm - which focuses on Microsoft Windows - scans company networks trying to guess passwords in order to access corporate networks, experts found. If the password is guessed, the worm can then infect a computer and the entire network of servers it is connected to.

As a result, experts are calling for all computer users to install a patch from Microsoft and to use long, difficult passwords that cannot be deciphered.

Source: Security patch and passwords defend against the Downadup worm, Help Net Security, 18 January 2009

Downadup (a.k.a. Conficker) exploits a Windows vulnerability patched in October (MS08-067) and is rated as LOW risk by Symantec.  According to F-Secure:

It checks for a suitable computer around the network using NetServerEnum, then attempts to log on to any found computer with one of the following login credentials:

1. Using the existing credentials of the infected user account; if this account does not have admin privileges on the target machine, this operation will not succeed. 
2. Acquiring the list of usernames from the targeted computer using NetUserEnum API, then attempting to log on to the targeted computer using the existing user accounts and one of the following passwords:  (See F-Secure site for list).

The controllers of Downadup don’t seem to want anything more than payment for forcing users to install rogue anti-virus software.  However, infected machines (conservatively, between 500,000 and 1 million at this time) can also be forced to participate in spamming, or worse.

Like most exploits that take advantage of both system and configuration weaknesses, there are several ways an organization can protect its network from worms like Downadup.

1. Patch, patch, patch.  Although most organizations like to test before applying a patch, how long does it take?  Or rather, how long should it take for a network manager to apply a patch for a vulnerability so critical that Microsoft issued MS08-67 outside its normal patch cycle?  Effective patch management processes should enable a quick response when critical security patches are released.  And you might not have to patch 100 percent of your systems to achieve a reasonable level of protection.  See Herd immunity and security patching: How much patching is enough?   Don’t allow the excuse that every system can’t be patched as a reason to ignore patching altogether.
2. Be sure to set password policies that protect against internal and external attempts to bypass system access controls, including:
   • Locking accounts after three to five unsuccessful login attempts.
   • Forcing password changes at least every 90 days.
   • User awareness about how to select a good password or passphrase, including tools to test their strength.
3. Segment your network and control traffic.  Limit the number of systems, including servers, an infected desktop or server can reach.
4. Implement log management to quickly detect anomalous behavior.
5. Implement, manage, and monitor anti-virus protection at the desktop level and for email at the perimeter and on email servers.
6. Monitor for extrusion.
7. Document and practice an incident response process.

There are other control layers to consider, but these should be very effective in preventing a worm like Downadup from performing as designed after gaining a foothold in your network.  In any case, I still believe strong passwords are no substitute for patching and a solid layered security controls framework.