antiworm

RSA, Security Division of EMC, Hacked

2011-03-19T02:06:00.000-05:00

This was not RSA's lucky day.

This will be one to keep an eye on.

RSA Hacked by automated attack

SQL Injection - So Easy, Your Server is Already Cracked

2010-03-03T15:44:00.001-05:00

In a simple demonstration, a hapless team discovers the truth. "Your server is vulnerable. It's already been cracked. Oh, and by the way, it's already distributing malware for a botnet."

A Big Case of Oops!

Attitude of management in many organizations is one of the biggest barriers to improved security on the internet. People simply don't want to believe that their systems are vulnerable. Denial is pervasive, and affects organizations from the biggest of the Fortune 500 or Federal government agencies, down to modestly sized companies, local governments, and non-profit corporations.

The attitude of the unnamed client described at the "Following the White Rabbit" blog (link above) is all too common. I suspect that an underlying cause is that people want to believe several things that worked pretty well from an evolutionary perspective, but don't work very well on the internet. When everybody around is a bunch of cave dwellers, consumed entirely with finding food, the marginal difference between the capabilities of "our team" and "the other guys" might be pretty modest, or easy to assess (e.g. "there's five of us, and ten of them... run away!") In fact, even considering the industrialized history of the world, we don't have much experience with the type of scalability that a virtual, software driven environment can provide to an attacker.

Consequently, when faced with a vague potential threat from "the internet", people tend to default to reptillian brain denial.

"These vulnerabilities and exploits look complicated. It's not very likely that anybody could actually exploit them."

They might look complicated to you, a manager, or even a programmer (depending on your particular skill set, which typically won't include "cracking").

They look like a modest engineering or programming exercise, to the people who routinely crack computers for a living. There are toolkits and sample code and it isn't very difficult to build a test bench and try permutations over and over until the crack works.

"Our team isn't that stupid. We wouldn't build and deploy a system that can be easily hacked."

Your site doesn't need to be easily crackable, merely crackable. Some exploits require knowledge of assembly language, SQL, C, C++, and some other specific combination of arcane skills with Internet Explorer, Microsoft Windows, Apache, SQL Server, MySQL, and so forth.

Once somebody with the proper combination of skills has developed the exploit, and shared it with the world, your site could be cracked by somebody with little more programming proficiency than a typical user of IRC (Internet Relay Chat), perhaps someone who needed only drag-and-drop proficiency with a mouse.

"Nobody is that interested in hacking us."

You might be boring, yes. You might have no secrets. But you do have something interesting to them: a computer with a full time internet connection running a web server, and people who visit your web site (sometimes they just want to use your site to spread their botnet to your customers). Furthermore, the bad guys don't know that you don't have any secrets, until they've finished perusing your hard drives and data bases.

Finally, there's the typical denial offered by individual people, when pondering the vulnerability of their own workstation:

"I don't surf to bad web sites, so I won't get a virus (trojan, rootkit, botnet, worm or other malware) on my computer!"

You don't need to point a web browser to a "bad" web site to be victimized by a browser-crawlback. The malware that gets onto your computer may also start poking around your company's internal network, and find ways to exploit or infect systems that don't "surf to a bad web site" or any other web site, at all.

The moral of this story is that we cannot afford to live in a state of denial about the importance of application, network and computer systems security. Enterprises, large and small, need to take the security of their web sites, applications, and internal systems more seriously. The bad guys are kicking your butts. They're stealing your data, and you don't even know it. They're using your systems to spread botnets to your customers.

Quantum Phishing: email is dead

2010-03-02T15:48:00.001-05:00

Phishing has matured. The bad guys are now so adept at mimicking the actual emails sent by PayPal, that PayPal support apparently cannot tell the actual PayPal email apart from the Phishing emails.

PayPal mistakes own email for phishing attack [The Register]

PayPal admits to Phishing Users [eset.com]

I've wondered for years why the phishing emails were often so terribly lame. The ideal strategy would seem to be to read some actual emails from the intended target, and mimmic those as closely as possible. The traditional excuse offered by the security community is that the emails appear often to be generated by people who speak English as a second language, but that doesn't seem like it would be such a limiting factor, given the ease with which the translations could be corrected, even anonymously, using clever internet tricks, even fairly simple ones.

The real answer seemed to be that the text content of the email didn't much matter, as people don't read them very carefully. It appears to be from their bank. It's got a link. It says to fix your login. Click!

The competitive pressure, both from education efforts which make the population of victims more sensitive to potential identity theft, and from other Phishers seeking to exploit the same population of potential victims, seems to be forcing the emails to evolve to more closely resemble the target company's web site and actual emails. Witness the inevitable result: technical support can't tell the Phishing email from the actual company-generated email contact with their customer base.

Non-authenticated email is a zombie: un-dead, walking.

Bourne Incrimination - bio identity theft, the next big problem

2009-08-17T23:45:00.001-05:00

It was only a matter of time before it became possible to create fake DNA evidence. That time is now.

DNA Evidence Can be Fabricated [New York Times]

Think it's bad when somebody steals your identity, drains your bank account, and spends thousands of dollars on credit cards they opened with your name on it? This run of the mill identity theft can cost you thousands of dollars, and many years to clean up. It pales in comparison to what will happen if biometric data becomes commonly used as proof of identity. Sometimes also called bio-print (like fingerprint) or bio-identity mechanisms, such things as retina scans and fingerprint scans are already in use, or even common use. DNA scans are likely to become possible several years from now, as the technology to read DNA is evolving rapidly. An entire genome can be sequenced by three people and equipment costing a few hundred thousand dollars, in a very short period of time, several days. When it become possible to read DNA in more or less real time, people will undoubtedly clamor to use it as an identity mechanism, for bank access, for voting, and who knows what else.

Even (or perhaps long, if you doubt that day is near) before that's possible, databases will be filled with your DNA sequences, because it will be valuable to you and your doctor. Unless we get unexpectedly better at protecting data, those databases will be protected by the same organizations, people, and technologies which today fail to protect your simple text based identity -- your name, date of birth, social security number, address, and phone number.

With current technology, you can engineer a crime scene. You can make it look like a specific, innocent person committed a homicide, for example. The technology required to do so remains expensive, but it's well within the reach of governments, and the capabilities of research labs.

If you're writing the next hollywood script for Jason Bourne or James Bond, keep your eye on this stuff. It's moving faster than Hollywood.

Master Lock Pickers and the Security Mirage

2009-06-02T15:50:00.001-05:00

If you ever doubted that the lock on your door was in place to keep out the kids, doubt no more. This fascinating article details one of the world's top lock pickers.

The Ultimate Lock Picker Hacks Pentagon, Beats Corporate Security for Fun and Profit

A good friend of mine has been picking locks as a hobby most of his life. This is a skill that can be learned by any bright, patient person.

It's a safe bet there are more people around who know how to pick locks than there are people getting paid to rethink the lock and key.

on cyber warfare, China, Kylin

2009-05-18T21:45:00.001-05:00

Yes, the Washington Times is not exactly a premier source of security information, but with analysis and reporting like this, who needs enemies? Two fascinating tidbits from this article: China blocks U.S. from cyber warfare.

The first is an absolutely classic Freudian slip:

U.S. offensive cyberwar capabilities have been focused on getting into Chinese government and military computers outfitted with less secure operating systems like those made by Microsoft Corp. (This observation isn't attributed in the article.)

That ought to have you rolling on the floor, laughing, until you realize that these are the very same "less secure operating systems like those made by Microsoft Corp." which the bureaucrats at every level of Federal, State, and local governance in the U.S. has been "standardizing" on. Then your sphincters pucker.

The point of the article is that the Chinese have developed and deployed their own operating system and "hardened" CPU architecture to run it on, and have been deploying it on Chinese government and military systems, rendering substantial portions of the the U.S. strategy for cyber counter-attack irrelevant. Various security "experts" testified before Congress to raise some alarms.

Perhaps it's just poor reporting, but these crack security experts seem to be under the impression that this Kylin thing is mysterious, and don't seem to have noticed that Kylin appears to be a hardened version of FreeBSD (an open source operating system), and that you can apparently download versions of it with a quick google search (see: Some random blogger with links to Kylin iso images.)

Which makes the next bit from this article even more amusing. This statement is attributed to Kevin G. Coleman, but this is the Washington Times, who knows if poor Mr. Coleman actually said any such thing this silly:

U.S. operating system software, including Microsoft, used open-source and offshore code that makes it less secure and vulnerable to software "trap doors" that could allow access in wartime, he explained

Of course, no real security expert would ever mean to imply that Microsoft's security issues were primarily, or even in any meaningful way at all, based on open-source software. Microsoft has used tiny amounts of BSD code in their network stack, but Microsoft's security problems are of their own, proprietary making, and everyone who can spell CISSP or SANS knows that.

The take home lessons:

do a google search before you try to panic the Congress, and

if FreeBSD derivatives can be secured such that people panic when China deploys them, maybe U.S. government agencies ought to re-think their obsession and love affair with the less secure Microsoft systems, with which they have been utterly failing to protect U.S. Government assets, secrets, and infrastructure, according to other testimony reported in this and other articles, and perhaps
rather than inciting panic, somebody ought to be downloading those ISO images, installing Kylin, and running some automated tools against its network services, looking for buffer overflow exploits.

Gimmiv worm strikes Windows

2008-10-25T21:21:00.001-05:00

That didn't take long, did it? Apparently Microsoft released their "out of band" patch in a hurry because they had already seen exploits "in the wild" for this defect. They guessed a worm couldn't be far behind, and they were right. Gimmiv: New worm feeds on latest Microsoft bug The cycle of patching will never fix this problem. If you are a CIO or manager of an enterprise or government network which has been hit by new worms this week, contact Intrinsic Security to discuss FireBreak AntiWorm. Worms are detected instantly and trapped without signatures.

Microsoft's "Out of Band" Security Bulletin

2008-10-23T10:16:00.001-05:00

Microsoft plans to issue an "out of band" patch today, e.g. a patch released on a day other than "Patch Tuesday". Microsoft Security Bulletin Advance Notification Thw defect, which hasn't been publicly described just yet, apparently exists in every version of Windows that anyone who is likely to patch anything actually uses:

Windows 2000,
Windows XP,
Windows Server 2003,
Windows Server 2008, and
Windows Vista.

Microsoft describes this update as "critical" which means they know it can be remotely exploited without user intervention (and without exploit chaining, which they don't yet consider to be critical.)

DNS flaws expose many services (exploit chaining with old defects)

2008-08-07T13:42:00.001-05:00

The flaws discovered in DNS recently by Dan Kaminsky have existed for years. He linked several of them together, a concept known as "exploit chaining" to reveal a much more serious flaw. His technique makes it possible to hijack and misdirect a user's web browser to a malicious web site, even in cases where the user types the correct URL. '

That, of course, completely makes a fool of Verisign's Ken Silva, chief technology officer, who's been running around to the press saying irresponsible if not utterly foolish things like:

"We have anticipated these flaws in DNS for many years and we have basically engineered around them."

Kudos to Mr. Kaminsky, for working in private with the major vendors of DNS server software, who had patches ready to go before the flaw was announced. This kept the script kiddies from having a field day with the vulnerabilities, which were endemic to nearly all DNS servers.

Apparently there remain some issues not yet addressed, as the vendors focused initially on HTTP and web browsers.

Net address bug worse than feared

DNS attacks are not new but Mr Kaminsky is credited with discovering a way to link some widely known weaknesses in the system so that the attack now takes seconds instead of days or hours.

"Quite frankly, all the pieces of this have been staring us in the face for decades," said Paul Vixie, president of the Internet Systems Consortium, a non-profit that makes the software run by many of the world's DNS servers.

Secrets, Lies, and Email Passwords

2008-07-30T10:52:00.001-05:00

British hacker Gary McKinnon apparently was able to crack over 90 computer systems at various government agencies of the United States, including NASA, the U.S. Army, the U.S. Air Force, and the Department of Defense in 2001 and 2002. He was apparently hunting for secrets about aliens. No, he wasn't searching for illegal immigrants, but rather, aliens from outer space. He believed that the U.S. government was hiding evidence that these aliens exist, and maybe hiding materials and bodies of dead aliens, as well. I hope that if he's extradited and then tried, the judge goes easy on him. Yes, he's guilty of embarrassing several U.S. government agencies by breaking into their computer systems and rifling through data. It shouldn't have been so easy for him to do. The layers of management who didn't take network and information system security seriously until 9/11 will not be on trial, and they certainly bear partial responsibility for contributing to this problem. Mr. McKinnon wasn't the only person to break into many computer systems at these (and other) agencies during the late 1990s and early 2000s, he just happens to be one of the very, very few who were caught. One could say that Mr. McKinnon is a victim here, too, as well as a perpetrator. That is to say, he's a victim of a free market in, and cottage industry of, ideas about conspiracy. Yeah, there probably are some government conspiracies. It's a big, big government that has done some embarrassing things they would like to hide. Most of those things are probably mundane. Hiding the bodies of aliens that crash landed in Roswell, New Mexico, is not likely to be among them. He should have been reading the Bad Astronomy blog. Phil Plait (Bad Astronomer) on UFOs Phil Plait's Bad Astronomy: Rebuttal to a Bad Boook Review from a UFO, uhm, enthusiast Apparently Mr. McKinnon was caught because some action of his was traced back to the email account of his girlfriend.

Alleged Pentagon hacker loses extradition appeal
"McKinnon has acknowledged accessing the computers, but he disputes the reported damage and said he did it because he wanted to find evidence that America was concealing the existence of aliens. He was caught in 2002 after some of the software used in the attacks was traced back to his girlfriend's e-mail account."

If there is a lesson to be learned here, it's probably this: If your Significant Other is a UFO hunting nut job and a computer whiz, don't let him or her know your passwords, change them regularly, and for good measure, use a Macintosh.

Hands-on SQL Injection - Show me!

2008-02-23T19:28:00.001-05:00

Security training for application developers is an under-funded activity in most of the organizations that build software. Fixing security defects in custom applications remains an underfunded activity, even after defects are identified. Why does this continue to be the case? It can be easier to find defects for a customer in a security penetration test than it is to convince the customer that the problem is serious enough to fix. Sometimes this is because the incentives are messed up. I'm not the only person who has observed that the Federal Information Security Management Act (FISMA) seem to have given Federal agencies a much higher incentive to find problems and write lengthy, complicated reports on those problems, than to fix them. Other times, managers may not understand the technical details of various vulnerabilities, or may be interested in a certain category of defects, while wearing blinders to other types of defects, particularly outside their comfort zone. If the manager is familiar with viruses and worms from their experiences running their PC at home, then they might understand and be more interested in network configuration defects. This might come at the expense of less attention to application design or coding defects, like those that expose an application to SQL Injection attacks. Occasionally the problem, unfortunately, is a more active dismissal of some threats. People sometimes say things along the lines of, "if I don't understand it, it must be too difficult to exploit in practice, so it can't be much of a real risk." I've even heard managers lambast their security advisers while trying to look cool, tossing in the MTV phrase, "Keep It Real". Well, folks, I hate to be the one to break it to you, but even allegedly unscripted reality television is sometimes scripted. Just like exploits to complicated security defects. It only takes one person with the right combination of skills and maliciousness to write an exploit, and give it away. Suddenly the exploit is "zero cost" for the next attacker, and the flood of attackers after that. Exploits are "scalable" in this sense, or, as an economist or MBA might say, the marginal cost of each additional use of an exploit, after it is developed, approaches zero arbitrarily close. We see this pattern clearly in remotely exploitable buffer overflows, which might not be noticeably exploited for years after a product ships, and for months after the defect is discovered and publicized. Then, "suddenly" an exploit pops up. Within days there are dozens of worm or botnet variants exploiting the same defect. (We'll ignore for now the issue that some defects actually were exploited before the defect was publicized.) The same pattern applies to other types of defects that may not be exploited with quite the same high visibility. This type of scalability is inherent in software. If you're having trouble convincing your manager do devote resources to sanitizing your web facing application, or having trouble getting a budget to train your developers in secure coding techniques, consider sharing some of these links with your manager. This first one is a very clever web article by Gustavo Duarte, which demonstrates the attack using a simple online application built into the essay. Here you can see both the ease with which such defects can be exploited, and the relative complexity of the issues facing the defender. Hands-on SQL Injection Here is some additional information on SQL Injections. SQL Injection Attacks by Example Finally, here's an amusing cartoon that you can use to bring up the subject again, if you were given the smack down last time. Exploits of a Mom (Little Bobby Drop Tables)

Microsoft Fingerprint Reader - The Fine Print

2008-02-15T14:57:00.004-05:00

If you haven't noticed, somehow lately computer keyboards and laptops in the Windows PC world are sporting a little pad for reading fingerprints.

Notice the fine print at the bottom of this page, which I'll quote here in case it goes away:

Microsoft Fingerprint Reader

"The Fingerprint Reader should not be used for protecting sensitive data such as financial information, or for accessing corporate networks. We continue to recommend that you use a strong password for these types of activities."

Why do you suppose Microsoft and all those hardware makers would go to all the trouble to add a fingerprint reader to laptops and keyboards, and then advise you not to use it?

Probably because they know something that the average consumer probably doesn't: these devices can be spoofed.

It's only a matter of time before there are clear, step by step instructions available on the internet for lifting a fingerprint and applying it to a model finger for spoofing purposes. Heck, there might be some online now, and I just haven't seen it yet.

Biometric Devices and Fingerprint Spoofing

Faking fingerprint readers (or other biometric devices) - a collection of links and papers

Failure of fingerprint locking system in prison in 2005

If you think about these things for a minute, you would never touch one without wearing a glove. Where is the digital fingerprint stored? That's right, on the same rootkit infested Windows PC prone to worm and virus attack.

Will rootkits soon be intercepting the fingerprint data and adding that to your stolen profile information in that giant hacker database in the sky? You can bet they will, because you can be assured that not everybody read the fine print. These devices are so common on laptops now that there are undoubtedly some juicy bank accounts "protected" by the Microsoft Fingerprint Reader.

The bad guys will have your biometric data in a database long before the FBI gets it done, because the bad guys do all this stuff with the lowest possible overhead. They just add another routine to their worm / virus / trojan / rootkit package and it flows out to all the zombie pc systems on the net that day. Since their data flows are mostly encrypted now-a-days, it might already be happening and we just haven't proven it yet.

Friends don't let friends use fingerprint readers. At least not today, when they are so clearly pandering a false, and perhaps even criminally negligent, sense of security. The people selling these things ought to know better. Oh, that's right. They do know better. Hence the fine print.

NOTE: Thanks to my good friend Joe S. in Tucson, Arizona for asking me, "would you touch one of these without a glove?"

Rogue DNS

2008-02-14T02:57:00.002-05:00

I haven't seen the original paper, but this article claims that researchers at Google and Georgia Institute of Technology estimate that there are 68,000 rogue DNS servers on the net. Use of Rogue DNS Servers on Rise Rogue DNS is one of the services provided by the zillions of malware, virus, worm, and rootkit infested zombie PC systems on the internet at any given time. The interesting part of this trick is that zombie PC systems might get "cleaned up" after an infestation has been detected, but their DNS configuration might (OK, probably does in nearly every case) remain pointing to a rogue DNS server, which occasionally, but not always, provides fraudulent data back to requesting clients. This is yet another reason why infested PC systems must be re-installed from clean original media whenever possible, in case you didn't have enough reasons already. The paper: Corrupted DNS Resolution Paths: The Rise of a Malicious Resolution Authority David Dagon, Chris Lee, Wenke Lee - Georgia Institute of Technology; Niels Provos - Google Inc. was presented today at the annual Network and IT Systems Symposium: NDSS 2008. Better get cracking on DNSSec. DNSSEC - DNS Security Extensions

Swatting - 911 and telephony systems are defective

2008-02-11T17:12:00.002-05:00

Several publications are running stories this week about Swatting, an extension of a prank phone call, which has the aim of eliciting response from emergency response teams, including SWAT (Special Weapons and Tactics) teams. The prank calls are made to 911 operators, who are tricked into dispatching SWAT, police, or other response units on the basis of false information. Obviously social engineering is peformed as well, operators are told of bomb threats, killings or hostages. According to some accounts, some type of caller id spoofing might be used in some of the Swatting calls, which have been directed at 911 operators in over 60 cities by the five people arrested thus far. Several stories make a point to state that 911 systems are not defective, such as this otherwise excellent story, Swatting - a dangerous new game by KSBW TV in California which reports that the masochistic pranksters are not "exploiting any real technical flaws in the 911 system" and that these systems "are actually OK". It isn't necessary to know the intimate details to make a pretty safe bet that serious defects in the security of these systems do exist. Many of the calls were apparently placed using the assistance of computer systems, and the 911 operators were led to believe that the calls were local, despite their origin hundreds of miles away. That sure waddles and quacks like a defect. It's certainly possible that the defects exploited are in the underlying telephony systems, such as the Caller ID system, and not in the 911 system itself. However, if it can result in the 911 operator being unable to reliably determine the local vs. non-local origin of the call, it's a defect directly relevant to the 911 system as a functioning whole, and certainly a defect with the potential of being significantly reduced or eliminated, given some thought and effort. See this Wikipedia article for more information about Caller ID Spoofing. According to widely publicized accounts, FBI agent Kevin Kolbye in Dallas indicated that Swatting seems at present to be a game played for bragging rights. The FBI and the Justice Department arrested and indicted folks a few months ago in Dallas, and made another announcement today. DOJ - Swatters plead guilty to conspiracy FBI Catches Five Swatters Swatting has the potential to be much more dangerous. As it stands, innocent people might be killed if they open their door to investigate suspicious noises with a weapon in their hand. It's a very short step from Swatting as a misguided or perverted game, to Swatting as a Denial of Service attack on emergency response units. A terrorist attack or other illicit activity might be coordinated with Swatting attacks, designed to slow response to the actual emergency, and thereby maximize damage, injury, and death from the attack, or increase the chances of a successful heist. I'm reminded of a scene from the movie Air Force One, where POTUS (President of the United States) played by Harrison Ford, must use an ordinary phone line to call into the White House from an "outside" line into the public switchboard. The operator doesn't believe it is the POTUS and he finally convinces her not of his identity, but to run her "standard" security procedure and trace the call, which works in record time and reveals that he is in fact calling from Air Force One. In our current telephony universe, things don't always work quite that smoothly. Imagine how much more difficult 911 calls would be, if you needed to convince the operator of your identity, location, and the fact that the emergency was real, before assistance was dispatched. Some of my colleagues design and build 911 systems. Undoubtedly Swatting will soon join the ranks of all-too-familiar terms in the field of information security.

Now Fear This: Phishers learn to craft a better spam email

2007-06-16T12:24:00.000-05:00

Phishers appear to be using techniques learned from the targeted advertising industry. Security professionals have long wondered why phishing emails are, in general, so poorly crafted, and why they don't use a handful of basic techniques which would undoubtedly improve their hit rate, and lead to increased revenue generation from phishing. In the "Today @ PC World blog, Erik Larkin discusses an email which alarms the PC World analysts (see: Threat Alert: Sophisticated E-mail Attacks Spread [PC World]). The email arrived with a well crafted text body which passed the usual "first glance" tests for spam or phishing: bad spelling, bad grammar, incorrect addressee name, mis-matched sender. It appeared to be a boring business email with a word document attached. Security researchers have known for many years that phishers typically don't employ a handful of techniques which would pretty clearly boost their success rates, techniques which are not entirely unknown in the related adware "industry". Today the following ideas might seem obvious, but it has only been recently that phishers show signs of interest in these techniques.

Copy editing text and documents Spam and phishing emails often contain many awkward phrases and other flaws which alert the intended victim that "something is amiss". Security researchers have long suspect that the simple step of using a word processor to perform spell checking and grammar checking the text of a phishing email would significantly increase the "hit rate" because many recipients cite poor grammar and spelling as the primary tip-off.
Matching the correct name to an email address for the recipient Your email might be: "john.q.public@example.com" but phishers and spammers will address their email to: "Sarah <john.q.public@example.com>" rather than to the obvious: "John Q. Public <john.q.public@example.com>"
Internal consistency within the email of the spoofed sender Spam and phishing often don't appear to be "From:" the same person who signed the bottom of the email.
Using modern software development tools and techniques to target their population of intended victims Phishers often spam many millions of people with the same email. This allows anti-spam software both sufficient time and sufficient odds to capture, analyze, and block many, even the vast majority of those emails. If instead, phishers sent Wells Fargo phishing emails only to known Wells Fargo customers, then the time it takes to capture the emails goes up, and the number of potentially profitable victims (those with Wells Fargo accounts to be drained) who are reached in the critical first few days goes up, perhaps by a lot. Phishers and spammers have access to a great deal of data. They could use that data with the help of some custom software such as a web crawler, a few plugins to their existing bot, virus, and worm code, and a database, to dramatically improve their ability to target their phishing emails.

Security researchers have pondered these issues for several years. Some of these steps are relatively simple, particularly as compared to some of the technical aspects of developing and managing a botnet without getting caught. Why don't phishers employ them? The answer, it has been thought, is simply that it wasn't necessary. Phishers were seeing a high enough hit rate and making enough money using their primitive spamming techniques. Spam was cheap to send, so sending millions of spam each time didn't cost them any more than sending a hundred spam. However, the techniques above required an expensive investment in software development. Once spam filtering became good enough, it was thought, phishers would probably see a hit to their income, and find it necessary to start improving these other aspects of their phishing systems. That time seems to have arrived. The big web mail providers, with a fire lit under them by competition from Google, have finally started to get better at spam filtering. Google and others are letting their users easily flag spam that does get through, and automatically feeding that back into their spam filters, thus protecting other users from spam and phishing. This has apparently spurred some spammers and phishers to start developing more advanced techniques for targeted spamming. Those techniques will include various ways to phish for the raw data which they can use to help map to other data already in their possession or collected in other ways. Phishers already have mountains of credit card numbers, stolen in various ways online, from compromised web servers like the recent TJX / TJMaxx incident, for example, but they may lack other details which make those numbers useful. Here is one recent example of such a data phishing email, and probably related scam, which I received in my inbox this morning. It made it past a few layers of very effective spam filtering. As you can see, the spelling and grammar of the email are not bad. Native speakers of English can pick out a few minor flaws, the most egregious of which I've noted by placing the correction in [] brackets immediately following the error. In general, however, this email is better crafted than many.

Attn: American Deaf Network has several projects planned and in the process, we [in process. We] also work along side National Organizations to build safer communities for those affected in these rural areas. American Deaf Network receives donations on a daily basses from all over the world. We are seeking your assistance to work for the foundation and get paid. We do not require your full time or effort All you will need to do is to receive donations on behalf of the foundation. Donation comes in Checks and Money Orders. You will be paid a montly salary of $1,105.00. Please get back at us [get back to us] indicating your interest on making the world a better place for the deafs [the deaf]. Send us the following information to immidiately process your application. First Name. Last Name. Address. Contact Phone Make sure you send the requested information to the below email. american_deaf2007@excite.com Have a nice day. American Deaf Network 30045 Alicia Parkway #150 Laguna Niguel, CA 92677 USA]

The first thing I did upon receiving this was wonder if there was an organization silly enough to send out such an email. I thought it unlikely, but certainly not impossible. I Googled "American Deaf Network", and found only one reference to it, declaring it to be a scam, as suspected. These two examples, from PC World and above, are undoubtedly the tip of what will be an iceberg of more sophisticated and polished phishing email scams. This is a new cycle in the phishing arms race. Additional details on the "proforma-invoice.doc email can be found here: Avinti Security Briefing: Proforma Invoice [Avinti.com].

Technorati Tags: adware, antivirus, antiworm, botnets, credit cards, data broker, data loss, data security, debit card, malware, phishing, rootkit, virus, worm

Identity Theft with a happy ending, sorta.

2007-06-15T10:22:00.000-05:00

The San Francisco Chronicle has an interesting tale describing how identity theft victim Karen Lodrick recognized a woman who had been using her stolen identity in line at a Starbucks. She called 911 and pursued the woman, who was arrested, tried, convicted, and sentenced to time already served (44 days) plus probation. I'm curious about one of the details, however. Ms. Lodrick and apparently the police believe that her identity was stolen when the perpetrator stole unsolicited bank cards which "she had not requested". Were these unsolicited accounts? Probably not. They are described as "debit/credit cards" and other details of the story indicate that the cards were used to extract cash (or equivalent) from her accounts. Banks routinely send renewal cards to account holders. The term "unsolicited" in this context is typically not used to describe this situation. If the bank sent her a debit/credit card for an account that she didn't want such a card for, then the bank needs to evaluate its policies.

Technorati Tags: Banks, fraud, debit card, credit card, identity theft, Karen Lodrick, police

Class action bank lawsuit against TJX: When the levee breaks

2007-04-26T11:35:00.000-05:00

Well this may have seemed inevitable, but the uneasy truce between retail vendors and merchant banks (credit card providers) has broken. Banks are gearing up a massive class action suit against TJX, the parent company of TJ Maxx, which recently revealed the shocking extent of the break-in which resulted in the theft of 45 million credit card numbers and other data from their network. Forty million credit card numbers were stolen over a period of two years or more by crackers who had extensive access to systems handling sensitive data throughout that time. Investigations of consumer fraud revealed a pattern of exposure at TJ Maxx stores, leading in turn to discovery of the break-in.

Banks Hit TJ Maxx Owner With Class-Action Law Suit

This is an interesting decision on the part of the banks, as the financial industry may one day find themselves on the receiving end of similar class action law suits brought about by other banks or consumer groups when data theft can be traced back to their own security foibles.

In fact, the TJX event became the largest on record to date by displacing the 2005 cracking of CardSystems Solutions, a credit card transaction processing company who suffered a network intrusion which exposed 40 million credit card accounts. (Regulators Start Inquiry in Data Loss)

If it keeps on rainin' levee's goin' to break
If it keeps on rainin' levee's goin' to break
When The Levee Breaks, got no place to stay.
-- Led Zeppelin

Technorati Tags: antivirus, antiworm, fraud, malware, class action, TJX, TJ Maxx, banks, rootkit, credit cards, identity theft, spyware, SSN, virus, worm, zero day worm

Punchscan voting system

2006-11-06T15:57:00.000-05:00

There has been a great deal of discussion about voting systems in the security community following the well documented problems with electronic voting systems in recent American elections, notably those of 2000 and 2004. A new system promises dramatic improvements in the security of voting systems. The Punchscan voting system looks like a big step in the right direction. For background information, see this primer by Bruce Schneier on The Problem with Electronic Voting Machines. To strike an even bigger blow for democracy, the Punchscan system should be extended so that it can support Instant Runoff Voting (aka Ranked Choice Voting).

Technorati Tags: democracy, election, encryption, punchscan, voting

tip of the data loss iceberg: worms == automated large scale intrusions

2006-06-29T17:22:00.000-05:00

Recently there have been a spate of incidents in which U.S. federal government agencies reported data theft or loss, particularly data which could result in identity theft. The losses include the contact information and social security numbers of, literally, millions of federal employees and contractors. Most of these recent incidents were the result of stolen laptop hardware, USB Key fobs, or other computer hardware, although at least two involved unspecified intrusions (electronic theft of the data following a break-in to an online system). In the past several months, as the reports of stolen servers, hard drives, laptops, and USB key fobs have mounted, I've only seen two disclosed instance of an intrusion (in one case apparently targeted) which resulted in the theft of identity data concerning 1,502 people at the Department of Energy: Energy ups security efforts after loss of employee data and 26,000 people at the Department of Agriculture: U.S. Department of Agriculture hacked. Despite the sparse reports of such intrusions, we know that government PC systems are not uniquely protected from these threats. Although it hasn't been reported, there is ample reason to believe that significant data loss has also occurred over the past several years through worm, botnet, spyware, trojan and rootkit infestations. Such malware routinely scans the infected PC and mounted network drives or shares and uploads files and data into the arms of organized crime. This type of loss is harder for organizations to detect and remains underreported as a result. However, it has has undoubtedly resulted in many more exposures of similar magnitude than have theft of laptops. Many tens of thousands of computers in government agencies are infected with worms, bots, adware, spyware, viruses, trojans, and rootkits every year. The infection rates of many government agencies are not radically different from private industry. Why do we see so few reports about data loss from these types of large scale intrusions? The difference is that when a laptop is stolen, a bit of government-owned equipment goes missing. This produces a few unique circumstances that malware infections don't produce. Missing hardware:

can't be ignored due to strict property accounting requirements,
can't be denied due to the loss of a physical device,
and is more easily understood by all levels of oversight and management.

If hardware went missing, and bad guys have the hardware, they have the data that was on the hardware, too. People understand that. Malware infections on the other hand (really, these are often large scale intrusions) are complex, involving many layers of abstraction. Just mitigating the spread and cleaning up often consumes all available resources of a given IT shop, and when the cleanup is over, they are crushed under the catch-up load of the regular duties which were postponed to battle the worm, bot or other malware. Analysis is often limited to finding and plugging the security hole that let the malware in. Few organizations have the ability to demonstrate conclusively that a worm uploaded files to a remote server. Worms and botnets have begun using encrypted tunnels, so even if organizations have the ability today, it won't be effective for very much longer. We were able to uncover evidence of a large scale intrusion at a customer last year. It was clear that from the earliest moments of the outbreak remote attackers were under direct control of the infected PC systems on our Federal client's network. It was also clear that the techniques used were well-honed. Our client faced several variants of a particular worm within a short span of time, and one of those variants had a defect. Were it not for the defect, there would have been no direct evidence. Most of the time with automated large scale intrusions like worms and botnets, it's very easy for weary IT staff to assume that no real damage was done. The complexity of the attacks makes it easy for management and oversight to ignore the problem, too. Many tens of thousands of infected PC systems are cleaned up each year on government networks. Those systems include servers and desktop and laptop computers with large amounts of valuable and sensitive data. The organizations performing the cleanup are understaffed and overworked and typically don't have the skills, processes, tools, and budgeted time in place to analyze the data loss which occurred. Consequently, the problem is even bigger than it seems from the recent headlines.

Technorati Tags: adware, antivirus, antiworm, data loss, data security, identity theft, malware, rootkit, security, spyware, worm, zero day worm

OMB laptop security guidelines: implications for transparency in government?

2006-06-28T10:42:00.000-05:00

Within a few years it's possible that encryption will be the norm in government data storage, and probably large organizations, too. The historical inevitability of this process was given a boost recently. The OMB has provided guidance requiring Federal agencies to take the security of desktop and laptop systems more seriously (see: OMB Sets Guidelines for Federal Employee Laptop Security)in the wake of recent disclosure of several massive losses of data which could lead to identity identity theft. Here are a few stories describing recent incidents which have prompted the concern and gained the attention of the OMB: Navy Finds Data on Thousands of Sailors on Web Site Afghan market sells US military flash drives FTC Loses Personal Data on Identity-Theft Suspects US veterans' data exposed after burglary Veterans Affairs warns of massive privacy breach Officials: Veterans Affairs Department Ignored Repeated Warnings on Data Security Latest Information on Veterans Affairs Data Security Additional background reading on the recent OBM security guidance: OMB targets desktop hole in cybersecurity Before we leap headlong into encrypting everything in the government, however, we should really ponder the technology and its other implications. Earlier this week, President Bush chastised the North Koreans, who have been preparing to test an ICBM (Intercontinental Ballistic Missile), saying that it is worrisome that a "non-transparent regime" is developing such a capability. Transparency in government is a valued characteristic of modern democratic governments. Consider, however, that even in a modern democracy there exists a tension between disclosure and transparency on the one hand, and the desire of government organizations to restrict information flow for a variety of purposes on the other. Also this week, the disclosure of further domestic spying activity highlights that very issue. More directly, even one of the agencies hit by recent data theft ran aground on the sand bar of public relations spin control run amok: Source: Theft of vets' data kept secret for 19 days. At least some organizations will opt to encrypt most data in most databases, most documents, and most filesystems, because it will be easier and cheaper to comply with directives like this by defaulting to encrypted storage for everything than it will be to analyze this mountain of content to determine if it should be encrypted or not. (Most of the stolen data that upsets people is personnel data, which is "sensitive but unclassified," for example.) Although this may help prevent massive loss of data as seen recently, it might also reduce transparency in government. It may well be legitimately more difficult and expensive to satisfy a FOIA (Freedom of Information Act) request for organizations which rely on office documents and distributed (ad-hoc) content creation and storage. Most policy setting organizations do exactly that. The recent OBM guidance is a welcome step in helping to limit the damage. (It should also be noted that encrypted storage doesn't completely solve this problem, as people tend to leave passwords laying about in plain text files to help them access their protected data, and passwords can be cracked with common tools, given sufficient CPU power and time to perform the crack.) Congress should consider the implications of encryption as a response to data theft problems upon the desirable characteristic of transparency in governance, and should attempt to mitigate the potential damage to transparency before it occurs. They might require that all encrypted archvies be searchable, for example, similar to the way email applications search encrypted mail files. Some thought on this issue would undoubtedly produce a few basic guidelines which would help preserve transparency in governance.

Technorati Tags: Afghanistan, arms control, Army, data loss, data security, encryption, identity theft, North Korea, OMB, rootkit, security, spyware, transparency, Trojan, USB, USDA, veterans affairs, virus, worm

Microsoft Excel exploit: Let's be careful out there?

2006-06-16T23:42:00.000-05:00

A new zero-day exploit of Microsoft Excel has me pondering a standard bit of security advice, "be careful what you click." This meme survives to be repeated at nearly every outbreak, yet it simply isn't very effective. You've probably seen a story or blog post about this already, but in case you haven't here's the alert from the Microsoft technet blog which got me thinking:

Reports of new vulnerability in Microsoft Excel
" In order for this attack to be carried out, a user must first open a malicious Excel document that is sent as an email attachment or otherwise provided to them by an attacker. (note that opening it out of email will prompt you to be careful about opening the attachment) So remember to be very careful opening unsolicited attachments from both known and unknown sources."

Many online article and blog postings repeated this advice, unquestioningly. Some folks even praised it, including the respected security professional Brian Krebs. In his post about the issue at the Security Fix blog, he says it's "always good advice" that one be very careful opening unsolicited attachments. Recently similar advice was given to users of various Instant Messaging systems, as a "worm" affected users of Yahoo's system. In fact, the "worm" required the user to click it, meaning that its spread couldn't possibly achieve the "every vulnerable machine got hit" levels of a real automatically propagating network worm. However, these Instant Message viruses and email viruses can affect large numbers of systems in a short amount of time. A year or so ago I saw an outbreak of an email virus hit 1.5% of the systems at a large customer. It hit so many people (over 500) so fast (within an hour or two) that we at first thought it was exploiting an automatic execution hole in the email client. In fact, it had just been a little more clever than average at social engineering—tricking people to click it. I briefly interviewed a few of the victims, some of whom were trained IT professionals, who spent a lot of time during the course of the year explaining to users that they shouldn't click unexpected attachments. Well, the virus in question was somewhat clever. It nearly always appeared to be from someone you know. It sent an attachment which appeared to be a spreadsheet (it was instead an executable virus). It used cleverly mundane subject lines. Nearly all of the victims had received a virus pretending to be a spreadsheet which appeared to be from someone that they regularly receive a spreadsheets from via email. How careful must people be? Scanning a file first wouldn't have protected the victim against zero-day threats like the current Excel threat. We give the same advice to people about web surfing. Be careful where you surf, be careful what you click. It doesn't work there, either. Corporate and home PCs alike see anywhere from 1% to 20% ambient levels of adware and spyware infestation. But the web is a treasure trove of useful and wonderful things you might never discover if, sometimes, you don't click with essentially reckless abandon. The sentiment is pure, but most users are not able to easily tell what to click from what to avoid. Only the most rudimentary of email viruses or phishing can most people filter out at a glance. I've given this advice myself many times, trying to carefully explain how to tell good from bad emails, and good from bad free downloads. I think in general the advice hasn't been helpful to most people most of the time. High levels of ongoing infestation from adware and spyware, widespread damage from Instant Message "worms" and rampant identity theft all tell us that the advice isn't working.

Technorati Tags: adware, antivirus, antiworm, identity theft, malware, security, spyware, virus, Windows, worm, zero day worm

Beware of Your Auditors

2006-06-09T00:51:00.000-05:00

Security Auditors can be a clever lot, sometimes a bit too clever. You really need to have someone on staff looking over their shoulder throughout the entire audit, from planning through probing, and reporting. If you don't have someone on staff qualified to watch them, you need an independent consultant. A very sharp generalist would do, but someone experienced in security would be better. Basically you need a check and balance system in place, to keep stories like the following from happening to your organization. First the context. The auditors created a custom Trojan, planted it in amidst various other files on USB drives, and seeded them in parking lots and areas of the client's work area where they would likely be discovered by customers. Which, of course, they were. Here's what they say about the experience: Social Engineering, the USB Way

I had one of my guys write a Trojan that, when run, would collect passwords, logins and machine-specific information from the user’s computer, and then email the findings back to us. ... I immediately called my guy that wrote the Trojan and asked if anything was received at his end. Slowly but surely info was being mailed back to him. ... After about three days, we figured we had collected enough data. When I started to review our findings, I was amazed at the results. Of the 20 USB drives we planted, 15 were found by employees, and all had been plugged into company computers. The data we obtained helped us to compromise additional systems, and the best part of the whole scheme was its convenience. We never broke a sweat. Everything that needed to happen did, and in a way it was completely transparent to the users, the network, and credit union management.

Yes, you read that right. Their custom trojan emailed the client's account names and passwords and other (presumably important) data out to the auditors' off-site email accounts. Now, unless these guys put rather a lot more effort into their custom trojan than they described, email is a plain text protocol. So, any fifteen year old kid with a summer job sitting on a router or an SMTP gateway at an ISP between the client and the auditor's email basket can read that email. Of course, it's possible the trojan was equipped with an X.509 certificate and encryption system, but it seems to me that if the auditors had thought of this, they would have mentioned it. It would have been a source of pride. For either forgetting to encrypt the data, or failing to mention it in their storytelling, they will undoubtedly be punished by the flood of email they are bound to get from every GSEC and CISSP certified security analyst on the planet. I don't want to be too critical, because they seem to have the best intentions, and their effort served to illustrate a point that clients often don't take seriously -- USB drives really can be dangerous, even if you don't inhale one. However, in their excitement to put the clever idea to the test, these auditors seem to have overlooked one important layer of the security cake and the important dictum, useful to all consultants, "first, do no harm." Of course, this isn't the most egregious error ever committed by an auditor. Far from it, in fact. I've personally seen Auditor's laptops spewing worm traffic on a client's network. Of course, it's likely that the auditor's systems were infected by a worm on the client's network, rather than the other way around, but running 3 systems known to be vulnerable to the same defect that they were spanking the client for was, pardon the pun, an oversight. In the last year or so, several incidents of auditors losing valuable client data including identity information have been reported, notably more than once incident involving Ernst & Young. So, have someone on your staff work closely with the auditors as a sponsor of the audit, or have an independent consultant watching over their shoulder for you. People sometimes get carried away in their exuberance to do great work, and other times are following bureaucratic procedures that just don't make sense. In either case, your sponsor should have veto power over any actions during the audit, to protect your data from accidental exposure. In case you're wondering, you don't need an "auditor for the auditor for the auditor" up an infinite chain. What we're really talking about here is a sponsor with veto power who isn't part of the audit team. This kind of outside watchdog can break the pattern of groupthink that causes people to run off with a half-baked idea and accidentally expose the data they are ostensibly trying to help you protect.

Technorati Tags: antivirus, auditor, security, Trojan

McAfee out of ideas - blames internet for rootkits.

2006-04-17T21:59:00.000-05:00

The recent article Does open source encourage rootkits? [NetworkWorld] discusses a McAfee report, "Rootkits", in which McAfee lays the blame for rootkits at the door of the open source community by name, security researchers by implication, and unwittingly at the very doorstep of information sharing -- books, libraries, and printed material. The report was issued due to a large jump in the number of rootkits they detected (nine times as many this quarter as the year ago quarter - a dramatic increase). They specifically blame rootkit.com. The unstated basis for their argument is a classic tension between open sharing of information about security vulnerabilities on the one hand and secret cabals of security research on the other. McAfee is clearly coming down for the "keep it secret to be safe" camp. Most independent security researchers reject this argument, because industry has a very long track record of totally ignoring security issues until they are made public. Most researchers also practice a policy of advanced notification -- give the vendor a reasonable notice before publishing the findings to the world and attempt to work with them so that a fix is available when the notice is published. However, the threat of publication is sometimes the only thing that motivates software companies to fix security problems. Blaming open source, web sites, and information sharing by implication is misguided. The folks who are writing the real malware could (and do) use secret members-only web sites to share ideas and code and whatnot in their pursuit of malfeasance. It's better for the community of researchers to have open sites sharing these ideas. The fact is that you don't need a web site. There are books that do a pretty good job of explaining how rootkits work and how to build them. Are libraries now to blame? Is the publishing division of McAfee's competitor, Symantec Press to blame? ( The Art of Computer Virus Research and Defense). No. Information sharing is not to blame. Symantec is not to blame (at least not in this respect). Books are not to blame. The internet isn't to blame, web sites are not to blame, security researchers are not to blame. I wonder if instead we can attribute the continuing and expensive thorn of malware to humanity's continuing struggle to ride a rapid wave of expanding technology while simultaneously attempting to preserving civil liberties and limit the destruction and damage that can be caused by Evil Doers(TM)? Frankly, we're not very good at it, and we will soon face analogous problems in the much more serious realm of biological engineering. Recall that open source specifications for the 1918 influenza have already been published. We need to get better at this stuff pretty quick, because the clock is ticking. The information genie can't be put back in the bottle, we had better figure out how to tame it. * NOTE: Evil Doers is a Trademark of The Bush Administration.

Technorati Tags: adware, antivirus, antiworm, botnets, identity theft, malware, rootkit, puppy, spyware, Windows

Cyberstalking & identity theft

2006-04-17T18:22:00.000-05:00

The New York Times today features an interesting article today, "A Sinister Web Entraps Victims of Cybrerstalking" [annoying but free registration probably required]. The article does a nice job of describing the problem, but it doesn't say much about how to protect yourself. Unfortunately, it's pretty difficult.

Identity Theft and the Torn Up Credit Card Application

2006-03-15T22:22:00.000-05:00

You should never throw out any piece of paper with any contact information on it. Any such papers should be shredded, rather than tossed out. In particular, never throw out credit card statements, always shred them, preferably in a cross-cut shredder. If you are not taking the risk of identity theft seriously, this article on "The Torn Up Credit Card Application" should strike an appropriate amount of fear, just enough to convince you to buy a small home-office shredder.

Technorati Tags: identity theft

Virus Vulnerability for RFID (Radio Frequency ID tags)?

2006-03-15T15:59:00.000-05:00

The breeding ground for the computer virus will be expanding continually and rapidly over the next decade as appliances, automobiles, and all manner of other things become equipped with wireless networking and miniature computers. Cell phone and similar networks may enable worms to leap between devices over long distances and other networks over short distances. Researchers have recently demonstrated that RFID tags may be vulnerable next. Articles on the topic: RFID worm created in the lab [NewScientist.com] Viruses leap to smart radio tags [BBC.co.uk] RFID tags could carry computer viruses [SecurityFocus.com] The details for the curious: RFID Viruses and Worms The AntiVirus paradigm that we [the IT community and industry] have foisted upon PC users is already breaking down under the strain of too many virus variants and too many non-technical PC users. The paradigm probably won't work at all for cell phones and the paradigm is completely broken for the typical RFID device which typically lack an end user administration interface of any kind. The AntiVirus paradigm was invented for Enterprise users who were expected to be paid to devote time to protecting a valuable asset, and technical hobbyist users who loved tweaking their PC. It's not designed for users who want to use their PC as a simple household tool, like a television or a refrigerator. The stuff people want to do with RFID technologies is truly amazing. It starts with automating inventory in retail stores, but goes all the way down to things like "washable RFID tags equipped with sensors on all my clothes will allow me to check to see if my favorite suit is at the cleaners, at home in the laundry bag, or at home ready to wear" and "RFID tags will enable my home pantry to let me check from work to see if I have all the ingredients needed to bake a birthday cake, or if I need to stop at the store on my way home". If this stuff is going to work, we will need to be careful that we don't turn the average home into the administrative nightmare that is the average enterprise network. RFID would flop because consumers can't afford to hire an IT staff to maintain IDS and AntiVirus systems for their pantry, wardrobe, stereo, library and toolshed.

Technorati Tags: adware, antivirus, antiworm, botnets, RFID, virus, worm

McAfee AntiVirus false positives - older, "reliable" signatures pose risk too

2006-03-13T11:22:00.000-05:00

False positives are the bane of AntiVirus and IDS/IPS systems. On the one hand, hundreds and even thousands of new threats are released each week, where they must be discovered, submitted to vendors, analyzed by vendors, definitions, signature files or heuristic algorithms must be tweaked, tested, released to customers, and finally deployed to customer systems. All of this must be done in as short a time as possible, since the threats often spread in minutes and hours. AntiVirus signatures are often available within two days from the first appearance of a threat on the network. Polymorphic techniques, even simple ones like automatically generating dozens or more variants at the threat's compile time, are becoming more common making it more difficult for AntiVirus vendors to keep up with the expanding threat pool every year. Today we learned that an error in a signature file caused the McAfee AntiVirus system to delete good files from production systems. This unfortunate accident affected at least a hundred of their customers and probably thousands of PC systems. The final tally of affected systems probably won't be announced. (A similar problem recently caused Microsoft AntiSpyware to zap Symantec AntiVirus from systems.) This incident is receiving more press attention than they usually do. The real wonder is that things like this don't happen more often. McAfee update exterminates Excel

Such problems with security software are called false positives and they happen occasionally. McAfee typically has to do an emergency release of a virus definition file once every three months because of a false positive issue, Telafici said. "This is our once for the quarter I think," he said.

Similar rates of false positives are probably seen from other vendors, but this might be the first time that an AntiVirus vendor publicly disclosed information about their false positive rate. Not every customer is affected by every false positive. Many affect 3rd party applications which were previously unknown to the AntiVirus vendor. In cases like these, a DLL from a valid production software system accidentally matches a signature file developed by the AntiVirus vendor, who doesn't have the system to test against. Tracking down these problems sometimes includes a finger-pointing exercise between the AntiVirus vendor and the 3rd party application vendor -- the AntiVirus companies sometimes uncover viruses in shipping code, too, and it may be difficult to tell where the problem lies at first. McAfee update exterminates Excel

However, this time around it was a particularly big goof, because the company faulted Excel, Telafici admitted. "Usually, it is either custom applications or applications that did not exist at the time we wrote the signature file," he said.

That bit is particularly interesting. The implication is that after the initial creation and testing, a given signature may not be tested as thoroughly or as often down the line. Several months later, an update to your application software might cause a signature file to break, causing catastrophic damage. In retrospect it makes some sense, as full-on testing of this stuff takes time and resources, and the pressure to test and ship the newest definition or signature files is quite high. However, this revelation probably indicates that the ongoing risks from signature or heuristic approaches may be somewhat higher than previously thought. With the number of threats multiplying every year, and with the number of signature files which require testing increasing concomitantly, older signatures which have been "thoroughly tested and validated in the customer environment" may no longer be assumed to be benign beyond doubt. The current McAfee false positive incident is discussed here: McAfee Anti-Virus Causes Widespread File Damage [Slashdot] Excel = Virus ... At Least to McAfee [RealTechNews]

Technorati Tags: adware, antivirus, antiworm, botnets, malware

Citibank PINs and the botnet arms race

2006-03-11T12:27:00.000-05:00

I noticed this tidbit from a Gartner researcher quoted in a story about the recently disclosed PIN theft.

PIN Scandal "Worst Hack Ever;" Citibank Only The Start "That's the irony, the PIN was supposed to make debit cards secure," Litan said. "Up until this breach, everyone thought ATMS and PINs could never be compromised." - Avivah Litan, Gartner

I wish the reporter or Gartner researchers would have checked with me or someone else who has direct experience auditing software systems. I've been warning my clients for years about the security exposure from data retention for e-commerce and credit card transaction systems and I know a number of other security professionals who've been doing the same. In fact, given the number of thefts of credit card data stolen from 3rd party web sites that have occurred in recent years it's unlikely that this is the first PIN number theft to have occurred, counter to the implication in this story. It might be the first that has occurred since legislation obligated disclosure of such thefts, but even that seems unlikely. There are literally thousands if not tens of thousands of different bits of software involved in credit card transaction processing, custom made, derived from free code available on the internet, purchased from third parties, custom made by third parties. Most of those systems originate in the web development world where robust software development and testing practices are not fully realized and security inspection or auditing is an afterthought if it's a thought at all. PIN numbers and the special security codes printed on credit cards are intended by the vendors to be "transient" data, used but not stored at the point of presence -- e.g. the cash register or web site where the transaction is initiated. However, it's impossible to audit all of the custom made systems in the world. In a recent article here discussing the Verified by Visa program, I speculated that proxy agents could be placed in front of an e-commerce engine on a compromised web server to defeat the Verified by Visa security measures. This technique could be used to harvest PIN numbers and security codes even more transparently. Without conducting a survey, I can tell you from my experience it appears that most organizations with e-commerce shopping carts on their web sites are not prepared to detect such an intrusion. Shopping cart systems are only the tip of the iceberg. I've seen dramatic, gaping security problems in systems that existed for years and were easy to discover by accident through ordinary use of the system. One such system provided full identity information for all accounts within the system, including bank account information, phone numbers, addresses, date of birth and other information -- matched to Social Security Number. The system's entire database could be enumerated by fetching them one at a time, simply by poking a randomly generated Social Security Number into a field. By poking them all in, one at a time, one could fetch the entire database. This could be easily accomplished by a "script kiddie" in a very short time. The system was not instrumented with any logging which would reveal that this type of enumeration has been performed. The system's database included many members of Congress and the Senate. (Surprisingly, all of the information in this paragraph doesn't narrow down the field of applications enough to give away what the application was, nor the agency which ran it.) Oftentimes when such issues are encountered it is a struggle to get the owners of the system to understand the exposure and act upon it. I spent two days trying to convince the Federal Agency that owned this system to act. I was only able to get the hole closed by identifying the private contractor who implemented the system and calling their CEO, who immediately understood the importance of the issue. If you find holes like these that are relatively easy to discover and exist in systems for extended periods of time, you must assume that they have been discovered before. In some cases you may be legally obligated to notify the persons whose data has been exposed. The complexity of e-commerce and other online software systems which handle sensitive data is high, and the cost of securing them and auditing them is very high. An audit performed by a commodity consulting shop may cost tens of thousands of dollars and take a couple weeks. Even then, the auditors will often be ill equipped to discover many of the weaknesses that exist in these systems. If you hire a specialty security firm which brings highly skilled and experienced security engineers and programmers to the table, the cost will likely be even higher. Contrast that with the money that firms typically spend on these systems. Oftentimes they don't spend much at all. They got the internet and find a "free" shopping card, don't audit the code so they really have no idea of how it works internally or even if it has already been instrumented with a data harvesting routine, and slap it up on a web server. Even large corporations are guilty of this, as the division with the need may not be given the budget to "do it right". Conventional wisdom says that the west won the Cold War by outspending the Soviet empire, leading to the eventual bankruptcy and collapse of the Soviet system. The economic principles behind this problem are similar to the issues with security and online software systems storing sensitive data like credit card, debit card, and identity information. The barrier to entry for the attacker is low. The cost to defend is high. The botnet arms race continues, and this time the stakes are your identity information, and your bank account balance.

Technorati Tags: adware, antivirus, antiworm, botnets, Citibank, Gartner, hacker, identity theft, malware, puppy

Total Cost of 0wn3rsh1p

2006-03-11T11:58:00.000-05:00

This whitepaper spoof was written a couple years ago. I tripped over it by accident, and was rewarded with health boosting laughter. Microsoft Windows: A lower Total Cost of 0wnership

Identity Theft & the Mail Box Meth Gang

2006-03-06T00:20:00.000-05:00

Botnets are the big guns in the Identity Theft world, ripping millions of identities from hard drives around the world -- not just home users, but web servers and database servers getting thousands or tens of thousands or millions pieces of data at once. However, low tech methods of data harvesting are still used. Low tech methods, too, appear to be evolving as increasingly organized, larger scale efforts are being uncovered, paralleling what we see in the internet security world. The canonical examples of organized crime driving spyware, worms and botnets has been shady advertising schemes. However, it's clear that identity theft is also a driver. But what drives the identity theft? Well, money obviously, but apparently drugs are behind some of it, too. The North County Times (San Diego) has an interesting story with quite a few details about one gang of Meth users turning to identity theft to pay for their habit. Apparently 14,000 credit card numbers were gathered by the gang of 20 people using a fairly low tech method -- they drove around suburbs looking for mailboxes with raised red flags, and extracted bills and other mail. That may seem like a lot of identity for 20 people to harvest by driving around and stealing mail, but they could probably harvest that much in a month or maybe two at most, working in pairs, and working only a few hours a day. The wonder is that they managed to do this for more than a couple days without getting caught. Neighborhood watch must not be watching the neighbor's mailboxes. The basic organization behind turning stolen data into money has been the same for decades, but the scale is larger than it's ever been.

"There is the collector who steals your identity from mailboxes or trash bins," said Alameda police Sgt. Anthony Munoz, who teaches a class about the connection for the California Narcotics Officers Association. "Then there is the converter, who turns your identity into something, and lastly there is the passer, the person who uses the fraudulent identity."

From the perspective of an individual, the short term and low cost solution to this problem is prevention -- start by getting a lockable mailbox. Make sure you shred any paper or other media (floppy, zip disk, cdrom, etc.) that has any name and address information. This includes things like bills that you don't think of as sensitive. However, on the scale of the society, this is problematic, partly because people don't always realize when they are throwing away sensitive data -- because they think of each item separately. "Here's a bill, it just has my name and address," for example. Well, it has other things. It's got your account number with the electric company. With enough different little bits of information stole from mailboxes and dug out of the trash, the Mail Box Meth Gang was able to steal identities and use them to fund expensive drug habits. By picking up several different bits of information out of the trash, or inbound mail, it's possible to assemble a more complete picture of the data needed to steal an identity. We discussed this general technique recently in another context --it's known as "the aggregation problem". In order to deter this kind of theft, a substantial majority of people would need to exercise careful practices with their sensitive data -- thereby raising the cost of gathering the raw data. In actual practice, most people don't realize it's that important, and won't go to the time and expense required. Credit card vendors have responded to the growing identity theft problem by trying to make it more difficult to use a credit card number without the card. That's what those little three-digit and four-digit numbers that appear on the back of the card are about. Those numbers don't appear on the credit card statement, and are required for some online purchases, thus making it more difficult to use a stolen credit card number. Unfortunately for the victims of identity theft, the classic trade-off between security and convenience hasn't been conquered. Further attempts to improve security of the credit card transaction system are clunky at best, typically problematic, and possibly open up new avenues for large scale identity harvesting at worst.

Technorati Tags: adware, antivirus, antiworm, botnets, malware, meth, postage, identity theft, virus

Phishing: more clever, more evil, every day

2006-03-03T14:30:00.000-05:00

This phishing scam, targeted at customers of Chase bank, is simple and direct. Fear it. Well, at least be aware of the general tendency of phishing scams to exploit basic human trust relationships with increasing sophistication. They get better and better every day, and they are building up quite a library of clever tricks.

It looks like it came from your bank.
The text is simple, direct, clear, and free from glaring grammatical errors.
It appears to be a simple request. The apparent source of the email is obscured.
It appears to be from: Chase Online Services Team
It exploits the HTML processing ability of most modern email clients to obscure the actual target of the "click here" link (which I've removed, but which was obviously something other than chase.com.)

Here's the simplest, most direct, most likely to succeed phishing scam email I've seen to date:

Dear Chase Member: We have processed your request to change your e-mail address, based upon the information you supplied. Beginning immediately, we will send all future e-mail messages, excluding Alerts, to you at allenbauer@aol.com. Any e-mail addresses that receive Alerts about your accounts will need to be updated separately. If you did not request this e-mail address change or have any questions, please cancel this action and reactivate your account by clicking here. Please do not respond to this confirmation e-mail. Sincerely, Online Services Team

Phishing scammers don't use their own systems to harvest data for identy theft and credit card fraud. They use systems that belong to other people, which they have taken over without the knowledge of the owner. Often they take over large numbers of systems with worms or botnets. Intrinsic Security is working with Internet Service Providers to help stop botnets. Help us spread the word by linking to our site from your blog. Link to Intrinsic Security - join the antibotnet campaign.

Will monthly patch cycles survive the year?

2006-02-24T01:51:00.000-05:00

Microsoft's regularly scheduled (once a month) security updates have received a great deal of criticism in the security community. The practice delays (in theory up to a month) the rollout of vital Windows patches and leaves customers exposed to worms, viruses, adware, spyware and outright hacking for more calendar days than the previous ad-hoc rollout of patches (e.g. as soon as they were ready). In today's world, where exploit code and worms show up within hours or days, these delays can be devastating. The monthly patch strategy has probably helped Microsoft with one key metric -- reducing the number of headlines per month about the latest vulnerability. In the months before Microsoft changed from ad-hoc security patch releases to a monthly schedule, negative security headlines were appearing almost daily. These headlines had begun percolating into the public unconscious, contributing generally to a vague but increasingly common perception that Windows is "insecure". Even though most people don't konw what that means, if you stop random folk on the street and ask about Windows, a significant percentage will tell you Windows is insecure. (RocketBoom dis this recently when they asked, Internet Explorer or firefox?) That torrent of negative headlines was perceived in Redmond as creating potential switchers (to Macintosh or to Linux) not among the unwashed masses, but where it counts -- the corporations on whom Microsoft has had a mind lock for more than a full decade now. The rapid growth of a tumor on the achilles heal of Windows may have contributed to the change in release policy, but that doesn't mean the change itself is entirely bad. By introducing some regularity into the patching lifecyle of Windows, Microsoft may have given IT shops everywhere the lever they needed to convince management to dedicate more resources to patching Windows, and to realize the true (substantial) expense involved. Regular monthly updates have also forced the IT community -- vendors and customer alike -- to get better at patching Windows systems. Prior to this regular and predictable delivery, most companies were still in serious denial about the need to rapidly deploy patches. They were typically going through painful gyrations to determine if every single patch applied to them or not, if they could skip deploying them, etc. in a futile effort to contain workload. They tended to lump the patches themselves into deliveries a few times each year. Now they've been forced by the regular delivery of dozens of patches at once, each month, to come to grips with more or less the non-stop patch deployment process. It can still take many days or weeks to deploy patches in a typical medium sized enterprises (say, one with more than 10,000 nodes), but that's down significantly from many months. Other vendors have been delivering patches in this regularly scheduled way, too, notably Oracle which has also been criticized by customers for untimely patch delivery (and poor documentation of patches). Despite this little ray of sunshine, it's been looking like the monthly patch cycle won't remain viable. Vendors will soon see their customers demanding weekly patch cycles, at least. What will drive this? The Patch Gap is too large in the era of the botnet and the zero day worm, driven by organized crime and state sponsored espionage. The problem with regular patch cycles is that the vendors and customers are both hoping that certain vulnerabilities have not yet been discovered by the cracker underground. Given the large number of vulnerabilities which are discovered each month, and the long period of time in which those vulnerabilities existed in widely deployed software (often years) it's almost certain that this hope is in vain. Crackers certainly know about some of these defects, and know how to exploit them, sometimes years before the script kiddies find them. Evidence that some cracker groups are well funded, probably state or corporation sponsored is mounting. Most recently a few stories have appeared which suggest that several well organized attacks have been traced back to China where state sponsorship is suspected, and industrial and governmental espionage is the motivation. Organized crime and state sponsored internet espionage rings can and do use the same techniques to explore production software for defects in a laboratory environment. The bad guys have the same debuggers and virtual machines and compilers and sniffers and Nessus plugins and documentation that are available to security researchers. The main difference is that the good guys often do this kind of research on a shoestring budget in their spare time, whereas the bad guys are increasingly making a full time job of it. The continual flood of high profile, high damage, automated exploitation of widely known and even long-patched defects which the script kiddies generate strains the security response infrastructure (trained admin and security staff, developers, testers, etc.) The enormous workload from the thousands of new viruses, worms, trojans, adware, spyware and keystroke loggers, combined with the endless stream of botnet attacks makes it more difficult for the industry to assess the real exposure to low-profile cracking from these industry practices of delayed (regularly scheduled) patch delivery. Microsoft, Oracle, and other vendors will be under increasing pressure to shorten their patch cycles, as the organized nature of botnet attacks becomes more apparent to their customers.

Technorati Tags: adware, antivirus, botnets, hacker, malware, patches, patch gap, spyware, virus, worm, zero day worm

Intrinsic Security provides uniquely effective AntiWorm technology which detects zero-day worms and brings botnets to a crawl.

Hacker 0x80 0wn3d by FBI (Arrested after Accidental Outing by Washington Post) [1]

2006-02-23T15:15:00.000-05:00

What can the botmaster 0x80's impending misfortune [1] teach us about information security? Quite a bit. What the botmaster and the reporter didn't count on is a security risk known as "the aggregation problem" or "point and click aggregation". It's not surprising, as even practicing security professionals are often unaware of this problem, or vaguely aware of the concept but not the name. Information Security dictionaries online generally lack the terms, and don't mention them in their discussion of "disclosure" either. The aggregation problem happens when a series of small facts, any one of which if disclosed present a minimal security risk, combine to present a greater security risk when disclosed together. When aggregated, information from publicly available sources may accidentally disclose information that was intended to remain confidential. As it happens, an IETF glossary contains a definition of the basic term.

RFC 2828: Internet Security Glossary aggregation (I) A circumstance in which a collection of information items is required to be classified at a higher security level than any of the individual items that comprise it.

The concept was first defined in the area of classification of national security documents, an area that provides fascinating and relevant illustrative examples. (A friend has told me that there was a story about the guy that invented the concept on NPR or Air America recently. If any of you dear readers have a link to that story, please let me know in the comments.) For several decades following the end of World War II, it was believed that the knowledge required to build an atomic bomb should be protected. (This concept might seem dated now, but it was almost certainly a valuable approach for the first few decades.) More than once during the past half century, curious students have apparently found their research classified, when they demonstrated that the basic plan for building and assembling an atomic bomb could be derived by non-experts from publicly available information. One such story, The Nth Country Project is detailed at the Guardian. This was an official project wherein the U.S. Army learned that indeed, a couple of competent physicists with no knowledge of atomic bombs could indeed figure out how to build one. This was decades before the internet, and it took two guys 30 months. The bar now is considerably lower. I have a recollection that a student created a plan for making a bomb within the last several years, using information gathered from the internet. We can't put the Djinni back into the bottle. Our hacker's [0x80's] problem with aggregation concerns disclosure of confidential information -- his identity -- that both he and the reporter desired to keep secret. Unfortunately, a series of small disclosures accumulated into an aggregation problem. Specifically, a modern, Slashdot and Google-fueled point-and-click aggregation problem. With direct implications for his daily freedom, 0x80's troubles began when he decided to allow himself to be interviewed by a reporter from The Washington Post. Brian Krebs constructed an excellent story, Invasion of the Computer Snatchers profiling what appears to be a typical young ne're-do-well -- albeit one making from $6,000.00 to $10,000.00 each month by unleashing worms which spread throughout the internet, cracking into your computer to install adware and spyware. A shady network of advertising schemes (see: The Hidden Money Trail [PC World]) funnels the money to the botmasters like 0x80, when people click through the pop-up ads which appear on their computers. (Yes, some people really do buy vitamins, Viagra and whatnot off the internet from pop-up ads delivered to their PCs by botnets. Go figure.) Within hours a story appeared on Slashdot, a discussion forum affectionately known as "News for Nerds". The editors linked to the Washington Post story, and opened a discussion, titled Interview with a Botmaster. Within minutes, discussion participants noticed that apparently minor tidbits of information could be aggregated to paint a strikingly clear portrait of the hacker. In the discussion, these facts were assembled:

male youth
21 years old
lives in small town in the midwest
slightly long hair that covers his eyebrows
lives with parents
parent's house is a brick rambler
has a small dog with matted fur
speaks with accent which is mixture of southern drawl with midwestern nasality
smoker
tall, thin build
dropped out of high school

Then it was noticed that retouched pictures showing the obfuscated hacker included meta tags -- information in plain text attached to many photos. This information revealed the name of the photographer, the type of camera used to take it, the time and date it was taken, as well as the fact that the picture was taken in Roland, Oklahoma. The pictures themselves seemed to reveal that the hacker has blond hair -- at least the hair on his arms appears blond in one photo. The handle, "0x80" might also be a reference to another smoking habit, as it represents "the high bit" (see also "dread high-bit disease") which is probably an intentional double-entendre. (e.g. Perhaps he smokes marijuana as well as tobacco.) Data aggregation led one discussion participant to post a link to a Google map. It's pretty likely that the home of 0x80's parents is within a mile of that spot. (Google appears to have since removed the detailed imagery for this location. Their map now says, "We are sorry, but we dont' have imagery at this zoom level for this region. Try zooming out for a broader look.") So the FBI knows where to look for at least one elusive botmaster. They'll find him soon enough. They probably already know where he is and who he is, and are gathering information on his desperate attempts to cover his tracks. More information on the aggregation problem can be found here: Warring on the Web internet presents web of security issues Inferential Disclosure NOTE [1] Clearly the hacker referred to in the article as 0x80 hasn't been arrested yet. This article discusses in detail the internet security issue known as "the aggregation problem" or the "point and click aggregation problem", which will likely contribute to his arrest in the near future (even if he doesn't live in Oklahoma).

Technorati Tags: 0x80, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

MS06-007 and the importance of being ernest

2006-02-14T15:01:00.000-05:00

Announced in the batch of new Valentine's Day vulnerabilities from Microsoft today, Microsoft Security Bulletin MS06-007 is an exposure to a remote Denial of Service attack. The bulletin states:

A denial of service vulnerability exists that could allow an attacker to send a specially crafted IGMP packet to an affected system. An attacker could cause the affected system to stop responding.

This is rated "important" rather than critical by Microsoft. (See the Microsoft Security Response Center Security Bulletin Severity Rating System for a description of their rating system and the criteria for each category). As a consequence of a couple "critical" defects in this monthly batch, this particular defect doesn't seem to be getting the attention it probably deserves. These types of DoS vulnerabilities are sometimes used by botnets and worms, which are frequently under control of an attacker once they have penetrated a network and spread inside it. If used by a botnet, this DoS could result in the shutdown of a large number of systems, some critical, in a very short amount of time. Brian Krebs of the Washington Post discusses two of the other vulnerabilties announced today which are rated "critcal" by Microsoft in is blog entry today, Microsoft Isues 7 Patches at Security Fix

Technorati Tags: MS06-007, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

Phishers target Verified by Visa - as predicted!

2006-02-14T01:38:00.000-05:00

Recent phishing scams have been noted to employ an SSL certificate as part of the scam web site. In combination with one of many patchable but unpatched and other unpatchable browser defects, these scam sites are now giving the end user the full appearance that they are engaging in a secure transaction with their bank. As reported by Brian Krebs today (see: The New Face of Phishing) as well as predicted here a couple weeks ago (see: Verified by Visa (Veriphied Phishing?)) the latest such phishing scams have begun to exploit the Verified by Visa program by using the name recognition of the campaign as part of their social engineering. Mr. Krebs mentions a few key facts about this latest scam in his article.

the scam targets a small bank
the scam exploits the brand awareness campaign surrounding the "Verified by Visa" program
the scam employs the use of an SSL certificate which appears to have been obtained specifically to set up the scam web site

niche markets as targets of opportunity

The pattern of targeting smaller niche markets has been used to effect in the last couple years by worms and botnets, and it's not surprising to see phishing scams follow suit. Phishers undoubtely assume that people who bank with larger banks are growing weary of the endless flood of phishing spam they receive. Their potential victims are perhaps becoming wary. By targeting smaller banks, they probably hope to find a fresh pool of victims who are not as sophisticated because they haven't yet been educated by the school of hard knocks. Expect more phishing scams targeting the customers of small banks in the future. Small and even relatively large regional banks often rely upon 3rd party vendors to provide their online banking services. Phishing scammers appear to have a better understanding of web technology and internet security than these companies and the anonymous nature of the internet, particularly email, will serve as an avenue leading to more and increasingly sophisticated and effective phishing scams.

exploiting Verified by Visa brand

Visa has been running commercials. People have heard the phrase, Verified by Visa many times by now. When an email shows up, they probably half expect it. When that email looks just like the web site of the bank, and when the holes in their web browser make it appear as though they clicked on a link and it took them to their bank's web site, they are all primed and ready to type in their vital statistics, Social Security Number, PIN number, account name and password, credit card number, and even the magic security number on the back of the card.

use of SSL certificates on the phishing scam web site

There have been previous incidents where compromised web servers are exploited to set up phishing sites with valid SSL. The novelty of this latest phishing scam is that it appears to use an SSL certificate that was obtained specifically to use for phishing in combination with the small bank target and the social engineering of the Verified by Visa program. However, the role of the SSL certificate in phishing scams warrants further consideration. However, there is very little to stop a phisher from obtaining such a certificate. They can already set up fake web servers and email accounts that can't be traced back to a person. The money they steal using stolen identities goes somewhere, too, and that doesn't seem to be easy to trace, either, as so few are caught and credit card fraud alone remains a multiple billion dollar per year industry. Many people, to the extent that they are even aware of the issue, believe that an SSL certificate provides the user with an assurance that they are talking to their bank on the other end of the internet. It most certainly does no such thing, at least not in any meaningful way that you should bet your Social Security Number on. SSL certificates used by most banks and other online shopping sites are issued by a set of companies known collectively as the Certificate Authorities. These companies have managed to place their own "root key" into the major web browsers, so that keys issued by them (for a fee) are "recognized" and "trusted" by the browser. They make only some small pretense for marketing purposes about performing due diligence on certificate purchasers. Most of them, even the big ones, really don't do anything meaningful at all in the way of due diligence. The public perception that they do is largely due to the marketing efforts of these companies as they compete with each other by building "trusted brands". Scam is a bit of a harsh word, but there are many independent security professionals who believe that the whole Certificate marketplace is a sham, if not a scam. As a retail vendor, you must buy an SSL certificate from a Certificate Authority on the pretense that your customers will "be secure" when they are shopping at your site. In reality they only "feel secure". Most of the internet shopping public doesn't really understand SSL. It provides only an encrypted tunnel that prevents 3rd parties from listening in. It doesn't really tell you much useful about the party you are connected with. Should you trust them? Even if it *is* your bank, should you type your Social Security Number into their computer? How good is your bank at protecting your data? What about the retail shopping sites you visit on the internet? The collective record is not very good. Tens of millions of credit card numbers stolen with matching names and addresses last year. Very few people outside security professionals and systems administrators understand that anyone can generate a "self signed" certificate for free, for example. The difference between a certificate you generate yourself and one generated by a root Certificate Authority is that the CA's have a rooted cert in the major web browsers, which prevents a user warning from popping up when you connect to a site over SSL. This basically forces people to pay a small fee to get a certificate from a CA, rather than generating one, to prevent user confusion and annoyance -- not to provide "security". It's probably not entirely the fault of the Certificate Authorities that people expect more from an SSL certificate than even the wildest of their marketing claims promise. There doesn't seem to be any legal requirement for them to validate the identity of the recipient of an SSL certificate. Performing even modest due diligence on a person is fairly expensive, although the cost is now down to the neighborhood of about $9 to $12 (volume discount prices, depending on options, additional fees for additional counties and types of records checked, etc.) per person for a limited records search. That wouldn't include the costs of handling incurred by the client company buying the search, evaluating it, and making a decision to issue or refuse to issue a certificate based on the results. Of course, those checks are performed against a person's name and Social Security Number. Well, if you're a Certificate Authority and you just spent, say, $15.00 validating that indeed public records show a John Smith living at a certain address. How do you know that the person buying your certificate, who claims to be John Smith, really is that person? That's an additional set of expenses, and it's probably non trivial, given that we are dealing with potential customers who have a certain expertise in passing off stolen identities. In a competitive market, optional costs are quickly cut from the production line. Sometimes there is even a race to the bottom where services and quality are cut repeatedly as companies struggle to become the low cost producer in a market. If the Certificate Authorities only make a pretense of validating the identity of a customer seeking an SSL certificate, it's probably because the only part of the entire transaction in which they have a vested financial interest is assuring the charge to the credit card that was used to pay for the certificate. In this case, that card was almost certainly stolen, and the scammer certainly had all the identity information required to make what appeared to be a valid charge on the card. Also, this is a relatively small industry, in terms of the number of providers who can handle bulk requests efficiently and nation-wide, and the Certificate Authorities do not appear to be customers of this industry. A few perhaps might be, I haven't done an exhaustive search, but I am under the impression that none of the Certificate Authorities attempt to validate identity of an SSL customer through public records, except through the most primitive means. They sometimes will call a provided phone number, but normally rely on non-human methods like getting a response click on a link sent to the email provided by the customer. These mechanisms provide some security for the customer purchasing the SSL certificate and some to the vendor selling the certificate, during the process of purchase. They provide little or no security for the customers or victims who connect to a server using the certificate. Even if each and every certificate customer were validated in some slightly more rigorous way, those validated customers could turn out to be shell companies that exist only for the purpose of setting up the scam. Furthermore, the paradigm is fundamentally flawed. Placing the root certificate in the browser for the "convenience" of the end user means that the end user is not confronted with the expectation that they need to be involved in validating each connection they make. Sure, you were connected to a certificate that was valid when it was issued. Has it since been stolen? Are you even looking at a web site that uses the certificate that was issued to your bank? Sure, it looks like your bank, but did you check the certificate to see what it said? It might be a valid user -- a different and evil scamming valid user. It's worth noting that there have been other phishing sites which had valid SSL certificates before. They were set up on compromised web servers using certificates owned by others. However, it seems like the phishers mostly don't concern themselves too much about SSL because their victims don't always remember to check for the little tiny lock symbol or look for the "s" in "https://". I'd guess that attempts to set up phishing sites with valid SSL certificates is all about an increase in marginal profit for the phishers -- the more legitimate their phishing site appears, the more data they harvest. Finally, it's possible to buy the ability to generate a rooted certificate -- one that is detected as valid and "trusted" by most web browsers. Who knows how many of those certificate granting authorities have been sold over the years. How many of them were "lost" in corporate mergers or re-organizations and have since shown up on the black market? In any case, it is an open secret that the Certificate Authorities actually do very little to validate the legitimacy of their certificate customers, and the public has a mistaken and dangerous impression that they do.

Technorati Tags: phishing, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

Are cookies spyware? WWDS?

2006-02-10T10:53:00.000-05:00

Should cookies that track your web surfing be considered spyware? What Would Dilbert Say? (WWDS). To the many millions of people trying desperately to keep their home Windows PC from collapsing under the load of adware, spyware, bots, worms and virii, and looking on the internet for help, it might seem like there is a raging (or at least simmering) debate about cookies -- are they spyware or not? This debate is mainly fueled mainly by the tension between adware vendors (typically shady or at least shadowy new media advertising outfits that match ads to web surfing habits) and anti-spyware vendors. The former need cookies to provide value added advertising, while the latter want to make the malware situation seem as bad as possible by releasing reports periodically about how much worse it's getting. Even if cookies are discounted entirely, the malware situation is indeed getting worse every year, and is very bad here in 2006. There really shouldn't be much debate about this, and there doesn't really seem to be much debate among serious and independant security professionals. Tracking cookies may not be executables, but it's reasonable to consider many of them to be spyware. A cookie can be considered to be spyware any time it's part of a larger adware system which may identify a particular user and their web surfing history, or any time it reports information back to a web server that the user didn't specifically authorize to disclose. This would certainly include disclosure to 3rd party web sites, which is seldom done with the web surfer's knowledge or permission. (I'm probably casting a bit of a wider net here than some folk would.) This argument is also a bit of a slippery slope. It's only a quick slide down that slope to see Dilbert's perspective. Dilbert would say that all cookies should be considered "spyware" unless proven innocent. Given the The Dilbert Principle, "idiots" (that's everyone at one time or another, including you, me, and Scott Adams, author of The Dilbert Principle) will assure that:

information which shouldn't be stored in cookies will continue to be stored in cookies, and
browser defects from time to time will continue to allow cookies to be read by 3rd parties.

So, to the extent that your bank (or whatever) stores identity information in cookies that are subsequently read by other web sites, any cookie on your system could be an avenue for disclosure of sensitive information. Intrinsic Security is working with DSL providers, Cable Modem service providers, and other network providers to help reduce the crushing load of spyware often managed by botnets. We're working to bring our uniquely effective anti-botnet and anti-worm technology to the DSL and Cable Modem networks that are used to spread spyware through worms and bots. Help reclaim the internet. Place an or button on your blog or web site today. Yes, this is shameless self promotion, but it's for a good cause.

Verified by Visa (Veriphied Phishing?)

2006-02-02T16:59:00.000-05:00

If you have used a Visa card to make a purchase online lately you may have encountered a relatively new program, Verified by Visa . I've encountered it twice. The system is an interesting attempt by Visa to reduce online fraud and identity theft. It's a noble effort, but the user experience is unsettling, and the security implications are not exactly crystal clear. Here's what happened to me, both times the Verified by Visa system was activated. I was redirected away from the domain at which I was shopping, to a URL which was:

not the domain where I was shopping,
not the domain of the bank that issued my card
not visa.com

I've been telling people for years that if anything like that happens to you, close your web browser immediately and do not under any circumstances enter any personal information into the form, because this is a sure sign of a man in the middle or phishing scam. (Never mind that all the best phishing scams now-a-days look like the actual domain of the bank or vendor, due to security holes in web browsers.) I would have done this myself, except that I was actually aware of the Verified by Visa program and seeking it out to take it on a trial run. I was surprised at this designed-in behavior. Apparently, Visa farms out these verification transations to third party vendors, so that a variety of domains might be encountered as one verifies different cards at different times while shopping at different online sites. They might look slightly different, one to the next. The web page that was "verifying" my card asked me for super-secret information to prove that I'm the real card holder, and/or that I was holding the card. Some of this information I had just typed into a different form at the online vendor where I was attempting a purchase. As far as one can tell without grilling Visa, this system creates, through the use of these 3rd party intermediaries, yet another web server that can be cracked to steal large pools of credit card numbers and identity information. The user experience was disconcerting. It looked and felt exactly like a low-quality phishing scam web site, except that it resulted from an online transaction that I initiated, rather than clicking on an email spam. I expect that this "Verified by Visa" system will become a target of something like a phishing or pharming scam soon enough. (When it happens, someone will probably come up with a new cute name for the "proxy in the middle verifying scam", something like the "veriphying" scam. You read it here, first.) Compromised web servers which host shopping sites but not databases full of credit card information will soon have "volunteer" administrators eagerly "verifying by Visa" in order to collect identity information that the retail site doesn't collect on its own. Only now, there won't be any easy way to tell end users how to avoid the scam. If a site isn't actually using the Verified by Visa system, such scams are likely to be detected relatively early by the vendor. Even so, for a high volume site, perhaps hundreds of identities could be stolen before the scam was detected. If a site is actually using the Verified by Visa program, the spoof intercept would probably need to proxy to the actual Verified by Visa site being used by that online vendor. This would allow the charge to complete and the scammer to evade detection, possibly for months or years. (If the veriphying scam agent wasn't a proxy, presumably the charge attempt would fail causing the intrusion to be detected.) I'll probably switch to using a different card when purchasing online for a while, at least until I have a chance to learn a little more about how it works, and how easy it might be to spoof it.

Technorati Tags: phishing, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

Gartner says IDS is dead

2005-09-05T22:33:00.000-05:00

IDS is dead, according to Gartner. This subject came up a few weeks ago in a conversation with the CEO of a network management company that works mainly with US Federal clients. He told me, "Federal Agencies have been dropping millions on IDS for years, and it's not doing them any good. They aren't getting any value out of it. My staff thought I was crazy the first time I said this." It's common for security officers, consultants, and staff to think that a lack of management support and a lack of organizational investment is the reason for IDS failure. The other side of the coin is that IDS technology is simply too expensive to operate, and doesn't provide enough ROI. If your car required a full time on-site mechanic to rebuild different parts of the engine and transmission, you couldn't afford to drive, either. One of our clients has an industry leading IDS system. They routinely receive alerts about worm outbreaks on their network from that IDS system two days after it started -- when the new fire-breathing signatures finally arrive. The IDS paradigm, like the AntiVirus paradigm, probably has a "sweet spot", things it can do well. But, like AntiVirus, IDS also has limitations that can't be overcome without stepping outside the paradigm. Stretching IDS outside the sweet spot (without stepping outside the IDS paradigm) inflates the cost of operations, and complexity of implementation. Unfortunately, every major IDS on the market today is reaching beyond the IDS sweet spot. The vendors want to help solve problems like worm and botnet invasions, because those are the most common, most damaging, and most expensive intrusions that potential IDS customers face. IDS systems are not well suited to the AntiWorm task. Even in the sweet spot of the paradigm, IDS suffers from a few basic problems:

many false positives
difficult to implement
costly to operate

The response of the IDS industry to these problems is to "tune down" (or tune off) major chunks of the promised and desired functionality of the IDS system. This reduces the rather stunning false positive rate of the typical IDS system on the typical network, (which, by the way, the IDS industry euphemistically calls "events" rather than "false positives") to a "manageable level". In other words, stop detecting needle of the intrusions so that the system can be operated by the limited and overtaxed security staff available, not by the hypothetical dedicated full time team required to sort through the haystack looking for it. That's the root problem with IDS. It's just not possible to coordinate data from so many disparate sources, looking for so many different potential "security events" without generating an unmanageable event load. Yes, Gartner sometimes has an axe to grind, but in this case I don't see it. They seem to be making an honest assessment that agrees with the honest assessment of the CEO I mentioned -- a professional who makes part of his living installing and operating IDS systems for his clients because they want IDS systems. IDS products are dreadfully out of alignment with the security demands and operational efficiency requirements of a modern network.

Technorati Tags: IDS, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

W32.Zotob.K and TFTP port 69/udp

2005-08-24T09:25:00.000-05:00

Two years and dozens of worm variants after the W32.Blaster.worm worm infected millions of machines using an easy to block TFTP callback mechanism, the latest variant of the Zotob family is using the same technique. The W32.Zotob.K worm may spread on some networks more successfully than previous variants, all of which attempt to exploit the MS05-039 buffer overflow defect in Windows systems. Using this technique, a worm author trades complexity in one area of the worm design (the overall transport logic) for simplicity in another (the code which exploits the buffer overflow). Previous variants have connected to the victim computer on port 139 or port 445, where it hopes to find an unpatched software agent listening. Then, a packet is sent containing some things that the victim expects to receive, and some things it does not -- all must be arranged very precisely. This package includes the message which trips the buffer overflow, and the code the attacker seeks to run on the remote system immediately thereafter -- which includes a copy of the worm. It turns out that most variants of the worms that exploit MS05-039 directly have been limited in their ability to spread, even on networks of systems entirely vulnerable and unpatched. Their slow spread appears to be due to a quirk -- the attempt to execute the complicated instructions and upload the entire worm to the victim will sometimes fail, causing the target system to reboot, without having first been infected. The TFTP callback allows a simpler package to be delivered through the buffer overflow, and probably makes it more reliable as a result. Instead of a big payload with lots of instructions, a small payload can be delivered. Basically, the worm says, "Hey, call me back." The attacking, worm-infested computer first sets up a listener on port 69, which is able to respond to TFTP requests. It's a small bit of code and it has become standard fare in the "off the shelf" worm building toolkits. The instructions sent through the buffer overflow ask the victim computer to fetch a file from the attacker, using a TFTP client software utility built into Windows, and then execute the resulting file. Organizations which have continued exposure of large numbers of Windows systems (unpatched for MS05-039, and with NULL sessions enabled) should consider blocking the TFTP port 69/udp on internal routers before these new variants hit your network. If this TFTP callback on port 69/udp is so easy to block, why do so many organizations still have it open on their networks? It turns out that many network devices including routers and switches occasionally use TFTP to communicate with network management consoles. This is another good reason why the port should be blocked -- just remember to leave it open to and from a small number of network management consoles or subnets, not throughout the entire network. You can easily block these TFTP callback worms without interfering with your ability to manage routers and switches. Will this become an arms race with new variants opening the TFTP callback trojan on a different port each time? Perhaps. Some worms exploiting the MS05-039 vulnerability apparently open their own FTP server on a high numbered port, using that for a callback transport rather than TFTP. However, the TFTP callback remains a popular exploit, and it's easy enough to block it. The TFTP program on Windows seems to be hard-wired to call to port 69, which explains the continued popularity of this particular port. Permanently blocking this port deprives the worm of a propagation technique with a long and successful history. Worm authors might possibly switch to a different protocol. The other obvious choices, FTP and HTTP, would seem to place a greater burden on the instructions that need to be sent through the buffer overflow exploit, sending the worm author back to square one -- a worm that doesn't propagate very well because the buffer overflow exploit is too fragile. In any case, you won't likely be chasing TFTP all over the port map. It has stayed right there on port 69 for years, and partitioning your internal network on this port remains an effective strategy for mitigating the spread of many worm variants.

Technorati Tags: TFTP, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

Reimage? Sez Who? The Fedz, that's who. And Microsoft.

2005-08-24T01:17:00.000-05:00

A number of systems administrators have asked me for some nice authoritative PDF and official looking references to support them in discussions with management regarding recovery strategies (see IRC Botnets: The Needle and The Damage Done). Senior managers are not particularly impressed by blogs, you know. Here are a few that I had handy. Note that this guidance is not universal. AntiVirus vendors, in particular, commonly claim that cleanup tools are sufficient recovery in most cases, although lately even a few of them have become more cautious in their claims for their cleanup tools. If you find any other nicely authoritative references on this topic, let me know and I'll add them to this page. The first reference actually surprised me. I was working on a large team in a gargantuan organization, and a client asked a Microsoft Security Consultant if Microsoft recommended re-imaging from worm attacks, and if they in fact practiced this type of recovery for internal problems. The gentleman responded with a clear and concise explanation that it was one of the 10 Immutable Laws of Security. I was so stunned I forgot to ask about the other 9. It turns out that it's actually number 1 and 2 on their list. (They also have a reasonable overview of Responding to IT Security Incidents . The NIST documentation is more detailed, but this overview is reasonably concise and might be helpful for managers.) 10 Immutable Laws of Security

Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore In the end, an operating system is just a series of ones and zeroes that, when interpreted by the processor, cause the computer to do certain things. Change the ones and zeroes, and it will do something different. Where are the ones and zeroes stored? Why, on the computer, right along with everything else! They're just files, and if other people who use the computer are permitted to change those files, it's "game over". To understand why, consider that operating system files are among the most trusted ones on the computer, and they generally run with system-level privileges. That is, they can do absolutely anything. Among other things, they're trusted to manage user accounts, handle password changes, and enforce the rules governing who can do what on the computer. If a bad guy can change them, the now-untrustworthy files will do his bidding, and there's no limit to what he can do. He can steal passwords, make himself an administrator on the computer, or add entirely new functions to the operating system.

Steps for Recovering from a UNIX or NT System Compromise

Keep in mind that if a machine is compromised, anything on that system could have been modified, including the kernel, binaries, datafiles, running processes, and memory. In general, the only way to trust that a machine is free from backdoors and intruder modifications is to reinstall the operating system from the distribution media and install all of the security patches before connecting back to the network. Merely determining and fixing the vulnerability that was used to initially compromise this machine may not be enough. We encourage you to restore your system using known clean binaries. In order to put the machine into a known state, you should re-install the operating system using the original distribution media.

The CERT® Guide to System and Network Security Practices

An intruder may have altered user data and application program areas. Examples where this may occur include

installing back doors to provide future access. For example, an intruder installs a program in a local user directory that is called each time the user logs in, providing an unprotected login shell that can be accessed by anyone via the Internet.
compromising user data to sabotage the user's work. For example, an intruder makes small changes to spreadsheets that go unnoticed. Depending on how the spreadsheets are used, this can cause minor to major damage.
Use the latest trusted backup to restore user data. For files that have not been compromised, you can consider using the backup that was made closest in time to when an intrusion was detected to avoid user rework. This should be done with caution and is based on having a high level of confidence that restored user files were not compromised. Regardless, you need to encourage users to check for any unexpected changes to their files and warn them about the risk of compromise.

NIST Special Publication 800-61
Computer Security Incident Handling Guide

5.4.3 Eradication and Recovery (Malicious Code Incident Handling) Antivirus software effectively identifies and removes malicious code infections; however, some infected files cannot be disinfected. (Files can be deleted and replaced with clean backup copies; in the case of an application, the affected application can be reinstalled.) If the malicious code provided attackers with root-level access, it may not be possible to determine what other actions the attackers may have performed.(91) In such cases, the system should either be restored from a previous, uninfected backup or be rebuilt from scratch. The system should then be secured so that it will not be susceptible to another infection from the same malicious code. 6.4.3 Eradication and Recovery (Unauthorized Access Incident Handling) Successful attackers frequently install rootkits, which modify or replace dozens or hundreds of files, including system binaries. Rootkits hide much of what they do, making it tricky to identify what was changed.(94) Therefore, if an attacker appears to have gained root access to a system, handlers cannot trust the OS. Typically, the best solution is to restore the system from a known good backup or reinstall the operating system and applications from scratch, and then secure the system properly. Changing all passwords on the system, and possibly on all systems that have trust relationships with the victim system, is also highly recommended.

Checking Microsoft Windows® Systems for Signs of Compromise

If a rootkit is installed on your system, it will be extremely hard to detect. At present, there are only two tools that we aware of that can aid the discovery of a rootkit, and the associated procedures are extremely difficult to follow. It is for precisely this reason we would recommend simply reinstalling the operating system ; it will take far less effort and time. Indeed, it could be argued that these procedures should only be used for either academic curiosity and forensics of an attack, or if the system is of extreme importance. Regardless of your findings, it is still highly likely that a compromised machine will always remain compromised, and thus cannot be trusted.

The following document from the US CERT is less rigorous than the others cited here, as well as a bit ambivalent. Note that it's also internally inconsistent. The document advises trying antivirus cleanup, but then states that reinstallation is "the only way to ensure" a secure recovery of a system. The US CERT should revise this document to be more clear, and to be more clearly in alignment with the overwhelming weight of sound advice, industry best practices, and with consideration of the dramatic increase in sophistication of automated botnet attacks in the last few years. Recovering from a Trojan Horse or Virus

If the previous step failed to clean your computer, the only available option is to reinstall the operating system. Although this corrective action will also result in the loss of all your programs and files, it is the only way to ensure your computer is free from backdoors and intruder modifications.

IRC botnets: The Needle and The Damage Done

2005-08-21T23:09:00.000-05:00

Since August 15th, many organizations have been struggling to recover from the onslaught of the various worms exploiting the MS05-039 Universal Plug and Play (UPnP) buffer overflow exploit. Those unfortunate enough to see large numbers of systems hit by one or more worm variants face the usual challenge of recovering the systems. Microsoft and the AntiVirus Vendors are eager to help you recover your systems, with several offering their own custom cleanup tool to eradicate the worms. Victims of this crop of botnetswould do well to heed the long standing recommendation of information security experts. Recover your contaminated systems by re-imaging them from pristine media, particularly if they were able to contact the outside world even for a few minutes using an IRC control channel. It's often difficult for non-technical management to weigh the risks involved with any given malware outbreak. This week I've heard this sentiment expressed almost exactly the same way from managers in several different organizations:

"It's just a virus, right? I have those on my home PC all the time and nothing bad has ever happened."

Well, I'm sorry to be the bearer of the bad news, but that's not the way it is, certainly not any longer. The largest identity theft to date, in which up to 40 million credit card numbers were recently stolen was reported to be due to a "computer virus". That was undoubtedly a pretty bad event for quite a few people. It can take many months, even years, for an innocent individual to recover from problems deriving from the theft of their identity. Far more people than you might think are affected by identity theft, as described in the Federal Trade Commission – Identity Theft Survey Report from two years ago. Experts acknowledge that the problem is getting worse, as large scale automated attacks by worms and botnets are employed to harvest identity data. Worms and bots execute arbitrary code on the zombied systems hosting them. They typically run with Administrator rights and can do anything the computer can do -- and they start doing it within seconds after the systems is exploited. These things are not just hypothetical. Here are a few of the things that zombied PC systems have been observed to perform, at the request of remote attackers, controlling zombied systems from outside the corporate firewall. By the way, these are not alarmist proclamations, rather, they are mundane work-a-day activities of the typical botnet, observed and documented by many independent security consultants.

contact an IRC channel at a remote location, and receive arbitrary instructions
update the bot software, install new bot modules
scan penetrated networks for other vulnerabilities
probe the vulnerable systems and spread the bots
perform denial of service attacks on other networks
harvest (find and upload to remote servers) private, sensitive, secret or classified documents from hard drives
harvest passwords, user names, and other login information (from the Windows Registry, the Internet Explorer cache, cookies, and text or document files on the system)
harvest email addresses, contact information
sniff network traffic to capture passwords and other information
install rootkits, trojans, keystroke loggers and other malicious software
use the system to send spam

Botnet controllers could also employ the zombied PC for phishing or other fraud (e.g. click fraud for internet advertising). The modern worm and bot attack has all the characteristics of yesteryear's intrusion -- a manual exploitation of a system by a hostile attacker. The universal consensus of the information security community to a crack of a system by an intruder is that a system must be re-imaged to regain assurance of its security. This recommendation hasn't changed in years, despite advances in rootkit detection techniques. The authors of such systems consider them to be useful for forensic analysis, not system recovery. When a modern Botnet invades your network, a remote person (or team of people) unknown to you has (or have) gained Administrator access to your systems. They have taken actions that you cannot trace because they were not logged and because they may have modified system files or installed a rootkit. Somehow, because these attacks evolved slowly over a period of years from mundane virus and ostensibly benign worm attacks, managers sometimes don't take them seriously. The primary difference between a classic intrusion and a botnet invasion is that the cracker quickly (within minutes) gains control of dozens, hundreds, or even thousands of compromised systems with a bot. The tasks allotted to the botnets can be automated as well. The nature of the threat is considerably greater than the virus or worm of days gone by. It's more appropriate to think of a bot as a manual intruder, multiplied times the number of contaminated systems, and treat it with the same degree of seriousness. One last motivation for treating botnet invasions more like traditional "intrusions" is provided by increasing attention of legislative, regulatory and oversight agencies. Private and governmental organizations alike may be under increasing legal and regulatory obligation to provide stronger assurances that recovery strategies are adequate. Legislation at the Federal and State level may require private industry to disclose serious computer breeches which expose their customers, business partners and employees to risk. Sometime in the next year or so, you're going to read about a big problem -- a giant identity theft, a massive leak of confidential or sensitive documents, an organization with hundreds of machines owned by a botmaster for months before it was discovered. Don't let it be your organization that you're reading about. If you didn't focus on prevention after the last botnet invasion, and you got hit again, don't try to cut corners now. Restore compromised systems from pristine media, then get to work on a layered antiworm defense posture.

Technorati Tags: IRC, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

Threat Levels: Low, Medium or High? Red, Orange or Yellow?

2005-08-18T23:50:00.000-05:00

Microsoft and the AntiVirus Vendors (perhaps a decent name for a band) tend to think of "threat" in terms of the number of machines infected, how many are vulnerable, and certain other primitive measures of damage done by a worm, such as "does it delete data files". By those measures, this worm appears benign. In fact this current crop of worms is far more harmful than some of the most famous worms from a couple years ago. Rather than hitting many millions of machines, these worms hit only a few hundred thousand or a few million perhaps (infestations inside large corporate and government networks are hard to count from the outside, hiding many infected systems.) When the worms are released, they do the most damage in the first few hours. They immediately search the hard drives for interesting files and upload them to remote servers. This damage is done, to the tune of thousands of files and hundreds of MB of data, before you learn which port to block at your firewall. They steal user identity information, documents, and files that store encrypted passwords so they can be cracked at the convenience of the attacker. They often leave very little in the way of evidence about what they have done. If you get lucky and capture an IRC session used to control these things, you'll understand the true nature of the threat. Many infected systems this week were being actively controlled from outside the corporate firewall by hostile forces. I've recently seen a captured IRC session which includes automated traffic from the zombied bots, as well as conversation traffic between members of a team of human attackers who immediately noticed (and thought it was funny) when the client blocked the IRC port published by the antivirus vendors. We have very little forensic evidence on this, but what we do have indicates that the bots appear to have automatically switched to another port/server combination and nary a beat was skipped. Managers at all levels of corporations and government need to understand that these worms are a very serious threat today. Even though the number of systems infected might be smaller than in previous outbreaks, these worms and bots are dramatically more sophisticated. The security industry needs to come up with better measures of the threat level, which include the risk of data theft, identity theft, and execution of arbitrary command and code on internal systems.

IRC Botnets: Sysyphus Part II - containment

2005-08-16T22:50:00.000-05:00

Many organizations are struggling with containment of worms and botnet invasions this week, as a result of the MS05-039 vulnerability and myriad variant worms exploiting it (Zotob, Spybot, Esbot, Rxbot, bobax, et. al.) Most of these organizations have patch management, firewalls, IDS and AntiVirus systems in place as part of a layered defense. They may suffer dozens or hundreds of compromised systems regardless of these efforts at prevention. The current crop of worms are nearly all bots -- remote controlled software agents that call out of your network to a remote server, looking for instructions from an attacker. Containing the outbreaks can dramatically reduce the cost of the later cleanup. If you have a large network, with a large population of vulnerable machines, and you don't have a containment strategy in place, consider the following tactics.

Network Partitioning

Consider partitioning your internal network on the ports used by the worm to spread. This worm seems to favor port 445, but some variants also employ port 139. Block these inbound at VPN and dial-up access points. Consider creating zones within your enterprise that are partitioned on these ports, at least until you get all your systems patched. If an outbreak occurs, the damage can be contained within a zone.

Egress Filtering

Don't wait for the AntiVirus vendors to capture and analyze all the variants to determine what ports to block. Start by blocking all of the standard IRC ports if you don't have a critical business need for IRC (most organizations don't). The standard IRC ports are used surprisingly often for botnet control, because they can sometimes be set up on existing IRC servers with relative ease. Although there is a small chance that someone in your organization might be using IRC for legitimate purposes, consider directing them to use a more modern Instant Message protocol, like AIM, Yahoo IM, MSN IM, Jabber/XMPP, etc. Standard IRC ports should be blocked indefinitely. There are other ports associated with IRC, registered with the IANA , but they don't seem to be in use for botnet control at this time. We might need to expand this list at a later time. Note also that several of these ports are identified as commonly used by IRC servers, but not registered with the IANA, they currently show as "unassigned"). 6660/tcp 6661/tcp 6662/tcp 6663/tcp 6664/tcp 6665/tcp 6666/tcp 6667/tcp 6668/tcp 6669/tcp 7000/tcp Also, in your perimeter routers, block and log the IRC ports used by the known variants, as documented by the various AntiVirus Vendors. During an outbreak, don't wait for a variant to hit your network. Block and log the IRC ports as soon as the variant is documented. Have someone one your team assigned to review the emergent documentation from three or four major AntiVirus vendor web sites, and update your perimeter egress filtering rules at least twice a day during an outbreak.

Disable NULL sessions

If you have a software distribution system in place, and if you haven't done it already, consider disabling NULL sessions on the Windows systems which haven't been patched yet. This can be accomplished with a tiny package and distributed much more quickly than large system patches. It appears that this will prevent an infection of an unpatched Windows 2000 system, allowing you more time to patch. Microsoft declined to confirm or deny that the UPnP vulnerability could be exploited with NULL sessions disabled, but apparently the current crop of worms and bots all rely on NULL session to perform the exploit.

Smart Bombs

Practice adroit and vigilant application of cleanup tools as part of your containment strategy, but not recovery (apologies to George F. Kennan). Cleanup tools can be deployed to contaminated systems to kill and delete the probing worm process which is spreading through buffer overflow exploits. If you can test and deploy it quickly enough, such tools can be part of a layered defense -- even if they are the "last line" of that defense. Focus testing on system compatibility -- will it accidentally wreck something on the system, making recovery harder? Probably not, but it's a good idea to check it out in your test lab. Don't squander precious time during the early phases of an outbreak by trying to validate that a cleanup tool kills every variant on your network. Deploy it only to systems that are contaminated and probing other systems. This is an attempt to slow the spread of the worm -- remember, you're engaged in containment, not recovery. If you have good reason to believe it will kill some of the variants on your network, send it out to contaminated systems after basic compatibility testing has been performed against your system image baseline. As follow-up, you can focus your limited forensics resources on the systems that continue to spew worm traffic, despite the cleanup tool, and return with an improved version to taunt the silly worm a second time.

Intrusion Suppression

Our FireBreak AntiWorm can help you identify those infected systems within moments of the start of an outbreak, and with an extremely low false positive rate (no false positives at all on a typical network). FireBreak AntiWorm can also significantly impede the progress of zero day worms, allowing you more time to respond. The system is appliance based and dramatically simpler than traditional IDS systems. Our AntiWorm solution can be deployed very quickly, so if you're having trouble putting the lid on the worm this week, don't wait -- call us today.

MS05-039 Zotob - and more to come

2005-08-15T02:38:00.000-05:00

Zotob reared its slimy head this morning. It exploits a defect in Windows systems (UPnP MS05-039) for which a patch has been available less than a week. Zotob is undoubtedly the first of what will be many Week Zero Worms exploiting this defect -- not quite a Zero Day worm, but close enough to wreck havoc. Every time this happens, the internet discussion forums are flooded with snide comments from smug systems administrators, along these paraphrased lines:

"I patched all 652 of my systems this week before the worm hit. Any organization being hit by this worm is incompetent."

Well, probably not. These well-run one-man shops do impress with their ability to deploy patches quickly and offer some hope for the rest of the universe. However, the prima donna types that make it happen generally don't really understand the magnitude of the problem in a large corporation with, say, 50,000 TCP/IP devices, mostly running Windows. It's not just a matter of patching 77 times as many systems in that same week. The unstable tower of complex software architectures built up on top of the typical network of Windows systems in a large enterprise makes it quite a bit more difficult to plan and execute a system upgrade or a configuration change or even an operating system patch in a larger environment. Explaining this to management in large organizations isn't very hard. Getting them to agree to do something to fix the underlying problems, however, is almost impossible. The people in charge of keeping the engines running are not the same people in charge of all the complicated attachments that get connected to them. All of these arbitrary "business drivers" may be carefully considered by IT people, who conclude that they need to meet the needs of the "customer" (e.g. another business unit, which is often a profit center carrying clout with Senior Management) and concede to the complicated attachments. These other business units are often engaged, sometimes knowingly, in a game of externalized cost. They may buy a software system that must be deployed to every desktop, rather than one that users can access from a web server. Worse yet, they may build one, without divining the best practices which help prevent high-maintenance software architectures. An increasing burden builds up on the IT staff over time. Most of this stuff is extraordinarily difficult to measure. But these costs don't go away. They come back to bite. Other times support issues arise within the IT organization itself, and a clever solution is devised. Often entirely too clever. Unfortunately, this "can do" attitude of most IT shops is sometimes their undoing. Clever solutions interwoven through the layers of the distributed systems and the various creaky but mandated optional components combine to make an overall system architecture which is relatively brittle. Then a worm hits. In a panic, patches are applied, things break, and the mess is cleaned up later. A post-mortem is performed. In the post-crisis exhaustion, the IT organization struggles to put the pieces back together and move forward on the latest set of tasks from the latest set of business drivers. In the standard ongoing chaos, the recommendations are ignored. A few weeks later, another defect, another worm, another crisis which possibly could have been averted in a better world. It's a nasty vicious cycle, but it's definitely related to the sheer size of an organization and its network. So please, all you smug fully patched systems administrators, don't be so hard on your collegues who didn't get 50,000 PCs patched in the same week that you patched 700. This worm gave you several days to patch them, and it took you more than a day. The next worm could hit before the patch is available, and it could be you turning to the forums for advice on how to impede the spread of the worm on your network, contain the damage, and recover your systems. When your number comes up, these folks will have unfortunate experience that you might be able to draw upon.

Technorati Tags: zotob, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

Witty Worm Insider? Perhaps not.

2005-06-10T02:01:00.000-05:00

In several discussions around the net it has been suggested that the author of the Witty Worm must be an insider. I'm not so sure. Although I agree that it's interesting that the worm was pre-populated with a seed target list, and also interesting that some of those hosts were on a military base, I'm not convinced of the conclusions that others have drawn from these facts, namely that the attacker had to be an insider -- either from the product vendor, or from the company who reported the defect. Likewise, the implication that the attack was directed at the US Military doesn't make sense. A few minutes of scanning could have produced a list of 100 vulnerable hosts. The scanning algorithm might have been something like this:

google to find likely customers of the company whose product will be exploited,
find address blocks likely to be associated with those clients using various DNS tools,
scan randomly until you find a vulnerable host,
then walk up and down from that IP address to find others which are likely to be nearby.

The worm could have been sitting around waiting for the seed list and the egg. Vulnerability announced, write the egg, test the worm, scan for some infect-able hosts, and fire away. No insider knowledge required. It's possible that the attack was directed at the military base, but it seems just as likely that it wasn't. The attack was global, and could certainly have been restricted to the IP address ranges assigned to the US Military, or even to major US corporations, but it wasn't. Finally, analysts seem to universally assume that writing the egg to exploit a defect like this would be hard and take a long time. Perhaps the Witty Cracker started months in advance, developing their worm against a previously well documented Windows/x86 UDP exploit, say SQL Slammer or something. When a new vulnerability showed up that was similar enough to allow a single-packet UDP exploit, perhaps it only took them a few hours to write and test their code. Has anybody narrowed down how many hours elapsed between the public announcement of the vulnerability and the start of the worm propagation? It was clearly less than 48 hours. I hope Nicholas Weaver and his colleagues are funded for further research on the Witty Worm. I'd like to see them analyze the worm to determine if it would have been possible to develop in a few hours, given the starting position of a previous "prototype" worm. Other worms are clearly developed this way from existing toolkits that are publicly available. Perhaps this worm was developed from a private toolkit.

Technorati Tags: Witty Worm, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

-- NOTE: A few days ago I saw a reference to some thoughts on the Witty Worm that Bruce Schneier had posted to his blog. Last night I surfed it up, and was inspired to post to his comments. This entry is an edited version of my observations, which I post here as our clients browsing the Intrinsic Security blog may be interested. This was quite a worm, still provoking so much thought and discussion all these months later. /gary

Device Drivers: a hidden worm threat?

2005-05-28T14:31:00.000-05:00

One of the more interesting security articles of late, Device drivers filled with flaws, threaten security from Security Focus, discusses the potential for device drivers to be exploited, due to many lurking buffer overflow defects. The article discusses Windows and Linux as examples, although presumably any platform which depends upon many 3rd party device drivers could be subject to the same issues. Drivers that listen on a network, such as network card drivers, would of course be vulnerable to remote exploits. People tend to think of device drivers as part of "the system", and the article points out that many if not most of the drivers people use are created by 3rd parties, not by the vendor of the operating system, and typically not by the core kernel developers. The article mentions that the authors of device drivers tend to have wildly varying skill levels, and that many drivers amongst a sample inspected appear not to be properly reviewed for security implications. Of course that's too kind. My own experience has been that device drivers for hardware often appear to be an afterthought of a hardware company in most cases. The article doesn't discuss mystery drivers -- I don't know if there is an industry standard term for these things. I won't point fingers, but I've been surprised a few times by a software package that installs device drivers when the need for a device driver in the application architecture wasn't really clear. Hardware drivers for peripherals and certain root level services like VPN software make sense, given the general system architecture of most contemporary operating systems. The bottom line of course is that drivers today include plenty of buffer overflows lurking. Those which can be remotely exploited provide worm fodder, while the rest provide opportunity for local privilege escalation. Exploit chaining techniques could see worms come in through non-privileged exploits, and then up the voltage through a device driver defect. At that point of course they are free to do all the keystroke logging, email spamming, trojan downloading and rootkit installing that any other administrator level worm can do. But then, one really doesn't see all that many non-privileged remote exploits on Windows. Since the system architecture demands Administrator privileges for so many things, it virtually guarantees that a remote exploit is also fully authorized from the get go.

Technorati Tags: Device Driver, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

The Next Big Worm

2005-05-25T18:22:00.000-05:00

A systems administrator at a University pondered today, "We haven't seen a really big outbreak for a few months, where are the big worms these days, like Sasser and Blaster? Aren't there any big security holes left to exploit?" Oh, yes. Microsoft releases patches about once a month, and at any given time there are usually a few serious defects that are known, not widely patched, and remotely exploitable. So what's the deal? Worm authorship seems to be more about building and maintaining botnets for revenue generating spam networks, and mining for various data like email addresses, account names and passwords, and the like. Giant worm outbreaks that infect millions of machines work against the aims of this organized criminal activity. Widespread outbreaks get the instant attention of company management, systems administrators, and AntiVirus vendors worldwide. Many small outbreaks, exploiting older known defects don't attract so much attention and serve to slowly build enormous botnets over time.

Clear Thinking & Information Security

2005-01-28T14:39:00.000-05:00

I noticed one day in a discussion with a client, that something they said resonated with things other clients have said over the years. Literally some dozens of conversations over the years have gone something like this:

So, you plan to re-install the worm infected systems from clean media, right? No. We get hit by viruses all the time and nothing really bad has ever happened. We'll just delete the worm files, whack the key from the registry and go back about our business. Do you know what the worm did after it contacted the overseas IRC remote control channel? No. How do you know nothing bad happened?

If you're a client and you recognize this conversation, don't feel bad, I'm not quoting you. I've had this same basic conversation with many other clients, you're in good company (I'm not quoting them, either!) Just about every other professional consultant in the information security world that I've ever spoken with has similar "war stories". People who make their living managing Information Technology shops need to have basic logic and reasoning skills, and for the most part, they do. Oddly, with respect to one particular class of problems -- those for which the solution is perceived to be expensive -- circular reasoning seems to be very popular. When managers don't like the answer that they know, and that the entire cadre of professional security consultants the world over agrees, is the right answer to a particularly painful problem, suddenly you can get whiplash trying to keep up with the coming and going in circles. The simple fact is, if somebody "0wnz your box, d00d!", no matter the particulars of how they came to own it, you have a very difficult time assuring the security of that system unless you re-install from pristine media. Yes, there exist a few techniques and a few tools that might help you recover certain types of systems under certain circumstances. Would you like to experiment with those techniques on your production systems today? What if the box in question is the PC on your desk? Do you trust the cleanup tool enough to know it didn't leave behind a keystroke logger that the bot downloaded over IRC? Do you mind if someone outside the organization gains access to your bank account login while your staff are learning the forensic techniques they need to find it? I thought not! I've had an email signature block around for years -- a quote from physicist Richard Feynman. It's a bit long, and I don't use it often. Sometimes when the national debate on some topic or another has degenerated into nonsense, I quietly attach it without comment at the bottom of my emails for a few days. I was deeply moved by this passage from Feynman's observations, attached as an appendix to the final report of the Rogers Commission, which investigated the accident of the Space Shuttle Challenger in 1986. It serves to remind me of the sometimes accidental and sometimes unconscious -- but nonetheless ever-present hubris of a bureaucracy. I work against this hubris at every turn, steadfast in my belief that organizations are made up of people, and most people want to do the right thing. When presented with the facts in a relaxed setting, outside of the office, away from the deadline pressures and the promotion risks and office politics, I'd guess almost all of the managers at NASA would have agreed with Feynman and a number of NASA engineers that jets of burning gas shooting out of leaky brittle O-rings and pointed at a giant tank of hydrogen was a bomb waiting to go off. And finally, after a surprising number of launches sporting extraordinary luck, it sadly did.

"Personal observations on the reliability of the Shuttle" "We have also found that certification criteria used in Flight Readiness Reviews often develop a gradually decreasing strictness. The argument that the same risk was flown before without failure is often accepted as an argument for the safety of accepting it again. Because of this, obvious weaknesses are accepted again and again, sometimes without a sufficiently serious attempt to remedy them, or to delay a flight because of their continued presence." By: Richard P. Feynman (1986) "Personal observations on the reliability of the Shuttle" Included as an appendix to: Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident (known informally but widely as "The Roger's Commission" report)

Now, in most organizations nobody will die from a worm attack. Hospitals, air traffic control, dispatch centers, train control networks, nuclear power plant control centers, various other utilities, and the enormous DoD networks being notable and important possible exceptions, of course. By the way, all of those industries are documented to have suffered worm attacks within the last few years. Certainly I don't mean to over-dramatize the case, it's just that Feynman elegantly cut through mountains of red tape to reveal the rotten core of the decision making process that led to the first space shuttle disaster. Arguably he explains the second disaster, from which NASA is still reeling, as well. Information Technology decisions require clear thinking. Circular arguments have no place in it. Epiblog: I've just got to the end of this essay, when I went to look up one last reference. Out of the blue as a bolt of lightning, I was struck by a most remarkable coincidence. You see, I was looking for a good reference on the different types of fallacies in reasoning, when I browsed one I've had on my shelf for years. Clear Thinking: A Practical Introduction by Hyman Ruchlis. I bought it on a sale table several years ago, and occasionally look up a section on a particular reasoning fallacy or another. In the section on "circular reasoning", Mr. Ruchlis includes this same Feynman quote! Additional information on the Challenger Accident can be found at the Federation of American Scientists web site.

If it's on your image, you must patch it

2004-10-21T00:57:00.000-05:00

Patches were released and risk assessment on Microsoft Internet Explorer vulnerabilities was requested. I'm sorry to report that risk assessment of this particular type is rather simple. I can describe it in three steps. (1) The risk of the vulnerability being exploited is real, and high. The nature of the vulnerability itself doesn't much factor into the assessment. What matters most is how many systems do you have running the software with the vulnerability, and how important are those systems. If history is any guide, these vulnerabilities will be exploited by dozens, hundreds, or even thousands of variants of malware, over the next days, weeks, and months. Recently announced vulnerabilities affecting the Microsoft Internet Explorer can be used to install and execute software on the system, when that system has accessed a malicious or benevolent-but-compromised web site. Vulnerabilities like this one have been exploited by literally hundreds of bits of malware in the last year. They are very difficult to trace back to an origin, but it is likely that at least one of our "W32.spybot.worm" infections came in via one of these types of holes. Most organizations presently have no defense against MSIE holes, other than patching. Most don't filter outbound http connections, and have no protection in place against this vulnerability. Most organizations don't offer a more secure web browser to their staff, such as Mozilla FireFox, as an alternative to MSIE. Even if they did, it's not practical to remove MSIE from the system image, and therefore one must patch MSIE anyway. (2) The potential cost of an infection on our network is very, very high. For most organizations, the patch management strategy is not perfect. Remote exploits in Windows within the last six months have resulted at one client site in at least 1,000 total compromised machines on the network. Most of these also contacted one of several outside IRC servers (overseas), for further instructions. (That's how these infections were detected). One of these systems was infected on October 4, 2004, several days before the Intrusion Detection System (IDS) was able to detect the infection (the ruleset to detect the new threat didn't exist on October 4). A few files left behind on the system indicate that it was able to receive instructions via the IRC channel to install other spyware and adware. Who knows what else happened on that box, and the other hundreds of boxes infected. MSIE holes can be used to launch attacks from the compromised host to the rest of the internal network, bypassing the firewall. The software installed on a single system through one of these browser holes could be a "bot" with the ability to probe inside the network looking for one or more other security holes and using them to propagate automatically to all vulnerable systems. Chaining unrelated security defects like this is a proven technique that has been used by malware (see "Virus, Worm, and Malware Evolution", which links to articles describing a very complex chain exploited this past spring which involved a number of compromised "trusted" web sites). Bots like this install adware and spyware, attempt to disable antivirus software, steal passwords, steal identity information, attempt to spread via many different types of exploits to other systems both within our network, and out to other networks, and allow external operators to execute arbitrary instructions on the compromised systems. In other words, they can, and do, anything they want to do on the compromised system. (3) In this risk assessment, there is no "step 3". Risk assessment on individual Microsoft Internet Explorer vulnerabilties is not meaningful. This is true for any and all other software on your Windows system image as well. Defects which appear to be low risk can be easily chained together with other system defects to result in a dramatically elevated risk. In some sense, this complicates the assessment of risk, and reduces opportunity to save operational costs by choosing which patches to deploy. Fortunately, the simple rule, "If it's on the image, we must patch it" can be used to mitigate these large, growing and very real risks due to exploit chaining. By the way, exploit chaining receives very little attention in the anti-virus dominated trade press. You will find only 16 references to the quoted exact phrase in google, including a few "how to hack" guides, a few analysis papers, and zero articles. However, please be advised that this technique has been known and used by "black hats" for several decades. Within the last year, automated exploit chaining was demonstrated to great effect. The Grim Reaper, the Bearer of Bad News (TM) am I. But really, I think that all is not lost. Most organizations do some stuff which helps reduce the extent of damage that they can suffer from these threats, and there is more that can be done. If you can't sell all these Windows PC things on eBay and replace them with Mac OS X systems, you have certain other options available to help with prevention of this type of browser-crawl-back exploit and the resultant, inevitable and extant exploit chaining. I recommend:

Apply all security patches to Microsoft Internet Explorer, and to Microsoft Windows, as soon as is feasible following their release. We have observed a few recent infections were confirmed to come through a hole in Microsoft Outlook. The client organization elected not to patch it, ostensibly because they don't use the software. Like MSIE, Outlook cannot be easily removed from the system image. If it's on our image, we must patch it.
Deploy a web proxy architecture with an antivirus plugin which allows you to filter http connections and provide some degree of meaningful protection against these browser crawl-back exploits. There are client-side and network based options. I prefer the network based systems because it eliminates the need to maintain Yet Another Software Package on the PC.
Deploy FireFox as an alternative web browser, and encourage staff to use it to the greatest extent possible. (Certain web sites employ proprietary techniques which work only is MSIE browsers, and sometimes only on Windows.) The design of the FireFox browser makes it much, much simpler to package and distribute than MSIE, so that on those occasions when FireFox needs to be patched, it can be patched at a much lower operational cost.
Require all web sites developed by the organization to be web standards compliant (XHTML, CSS2, etc.) and require that they be tested and work specifically with Mozilla FireFox.

Slow Scanners & Sniffer worms

2004-10-06T01:25:00.000-05:00

The discovery of the W32/Sdbot-UJ worm, which employed the technique of network sniffing, has shone a bit of light on a dark corner of the worm universe. W32/Sdbot-UJ has sometimes been reported as the first worm to perform network sniffing, but almost certainly it was not. It may have been the first such to be captured and analyzed by an AntiVirus vendor, I don't know. This worm employs a technique thought for years by some security professionals to be used by "slow scanners". I say "thought to be used" because it turns out this particular class of worms is difficult to study and not perceived universally as much of a threat. Some professionals even dispute whether Slow Scanners exist, yet. (Everyone seems to agree that if they don't, they will soon enough.) Slow Scanner worms are not widely reported in the media, partly because they are not as flashy as the worms that hit millions of machines in a day and whose propagation efforts are so aggressive that they bring the internet to a crawl. Slow Scanners are typically memory resident -- they don't write anything to the filesystem, they blink out of memory if you try to inspect them. They don't they don't do anything to the machine they infect. They don't write to the Windows registry, they don't open trojan backdoors, and they don't attempt to spread rapdily. Instead, a Slow Scanner performs reconnaissance of the local network environment, very, very slowly. They may send only a few packets an hour or a day, looking for certain open ports or other responses indicating a system type (say a router, or a Windows server or a BIND server) for example, or a particular vulnerability. The worm may not probe anything at all for hours or days. Slow scanners gather data about a network, often by "scanning", sending packets out to see what sort of response comes back. But Slow Scanners don't just scan, they also gather data by sniffing and keystroke logging. After gathering data for a while, the worm will report back out to a web site or IRC channel or email address. After sending a single report, it may blink itself out of memory. Other worms do most of this stuff too, but Slow Scanners are very difficult to detect because they try to fly low and slow -- under the radar -- to evade detection. Once in a while they try to spread to another machine, but never to all other vulnerable machines they can find, just the occasional one, usually not within the same network segment. Slow Scanner Worms hint at a dark corner of the cracker underground, hidden beneath the noise of the script kiddies and their thousands of variant mass propagating worms, and the drone of frantic AntiVirus efforts. People running corporate and government networks want to believe the popular profile of the virus writer -- worms are written by bored teenage kids seeking attention in their peer group -- other bored teenage programmers -- and they don't really mean any harm. Increasingly there is evidence that at least some worms are written for profit, not fun, and possibly for other purposes, perhaps even tailored to a given victim network, such as espionage. Slow Scanners sport all the hallmarks of being written for a stealthy and sinister purpose: they are designed to perform network reconnaissance as a precursor to a sophisticated, targeted intrusion. They propagate very slowly, so as to evade detection, even by sophisticated heuristics (rules of thumb) in modern IDS/IPS and AntiVirus systems. Here are some links to stories about one of the first widespread sniffing worms. It wasn't a Slow Scanner, but it almost certainly borrowed a technique that's been used for years. Sniffing worm snoops network PCs Computer worm 'sniffs' out passwords (September 2004) Sniffing Worm in Real World Circulation

Technorati Tags: adware, antivirus, botnets, malware, spyware, virus, Windows, worm

Exploit Chaining: Virus, Worm, and Malware Evolution

2004-07-19T01:43:00.000-05:00

All y'all might be interested in these articles. I've slogged through hundreds in the last week of evenings, and these are some of the most interesting. The first few regard using Internet Explorer features and defects for installation of trojans. With last Tuesday's release of several new Windows and IE vulnerabilities, it became clear that it was possible to chain together remote-non-root exploits and local-root-exploits, to gain Administrator access on a Windows system remotely, though indirectly. It seemed to me at the time that this would be somewhat complicated and we probably wouldn't see these types of exploits until the universe had harvested the low-hanging-fruit of remote-root exploits. After reading up a bunch this week (someday there will be pop music bemoaning the lonely nights spent with google...) I'm revising that opinion. There already exist documented examples of complex MSIE-exploit-chaining malware in the world, so we can expect to see more. Internet Explorer carved up by zero-day hole Hackers Manipulating Internet Explorer Add-Ons Internet Explorer Being Exploited Mozilla Feeds on Rival's Woes Trojan horse technology exploits Internet Explorer (This one is from 2002, but contains a good description of an interesting exploit, which, if I recall correctly, remains unpatched, and it's possible that some other Windows browsers are vulnerable to similar techniques.) The following articles discuss recent virii and worms using stealth techniques to avoid detection. This is just a sample of information I found on this area, and they don't even mention the simpler techniques used by most worms these days, like selecting process names that resemble or are identical to standard system processes, and polymorphic techniques like changing the process name at start time so it's different on different systems, etc. Stealth Virus is Stealthiest of them All Worm Sleeps to avoid detection Finally, here are some interesting related but miscellaneous bits. The "Worm Design" article is a five-year-old description of an experiment to fold many techniques into a single worm, and despite the poor grammar it's got some interesting and relatively clear descriptions of worm tricks. A few of these techniques have appeared in worms in the last couple years, and a few are becoming "standard" in modern worms. Worm Design Techniques This other article gives a hint about the complexity of virus and worm analysis, and I find it amusing. The author seems to have started out intending to simply explain at a high level how it's done, but then kept thinking of variant and exception cases that required different tools and techniques. The take-home lesson there is that even the people engaged in analyzing these things on a full time basis with the right tools and a well equipped lab have a hard time keeping up with just the technology evolution, let alone all the actual variants. Virus Algorithm Analysis - Kaspersky

Technorati Tags: exploit chaining, adware, antivirus, botnets, hacker, malware, spyware, virus, Windows, worm

Virus naming & The Public Good

2004-05-05T01:17:00.001-05:00

This appears to be a case where publicity about a particularly nasty worm has suffered because it was named something different by all the major antivirus vendors. Gaobot, which appears to be the Symantec name for this family of worms, isn't even in the title of this document. Microsoft machines and NDemon/Phatbot/Agobot Worms -- 19 Apr 2004 [Updated: 2004.04.27] It would be helpful to their customers if the AntiVirus vendors would agree to a common naming convention, and certain other standards related to identity of malware threats. A checksum should be provided with all descriptions, as well as standardized means to reference the known capabilities of threats. This probably won't happen unless an open source project, perhaps related to ClamAV finds itself so strong that the weaker AntiVirus companies suddenly find it to their advantage to play along. It's more likely that Microsoft will kill off the weaker AntiVirus vendors before that happens. The stronger AntiVirus vendors will eventually get out of the market, too, leaving a defacto standard -- the Microsoft Way, whatever that will be. It'll probably change every 18 months anyway.

Technorati Tags: gaobot, adware, antivirus, botnets, phatbot, malware, ndemon, virus, Windows, worm