Friday, February 24, 2006

Will monthly patch cycles survive the year?

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: , , , , , , , , , ,

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

Thursday, February 23, 2006

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

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: , , , , , , , , ,

Tuesday, February 14, 2006

MS06-007 and the importance of being ernest

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: , , , , , , , , ,

Phishers target Verified by Visa - as predicted!

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 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: , , , , , , , , ,

Friday, February 10, 2006

Are cookies spyware? WWDS?

Should cookies that track your web surfing be considered ? (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 , "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. 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.

Thursday, February 02, 2006

Verified by Visa (Veriphied Phishing?)

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 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: , , , , , , , , ,