DNS Flaw: Two Practical Things You Can Do

Dan Kaminsky got two standing ovations at Black Hat yesterday - one for his detailed and thorough explanation of the DNS flaw he discovered earlier this year, and a second ovation for his handling of the matter.



He should get another ovation for media-savvy. Thanks to Kaminsky's diligence, 50% of DNS servers tested on July 25th were shown to be patched to the required levels - up from barely 15% on July 7th. 70% of Fortune 500 companies were also passing the test, as of last night (push "play" on the video above for Kaminsky's animated "DNS patch status map").

Also, by building up the focus to the August 6th announcement, and leaking out just enough information to push people to the right textbooks, he ensured that not only were the IT teams up to speed, but the journalists were as well.

But now that the applause is died down, we need to provide consumers with some practical answers.

Some of the other announcements - of flaws in various forms of VPN software and the Secure Sockets Layer (SSL - the technology that powers the padlock in your https:// secure browser sessions) were very well explained in the mainstream press reports I read last night.

But I wouldn't be surprised if there are a lot of consumers out there reading all this and saying "What the... ?" and wondering the best way to get to their bank or brokerage this morning. Let me suggest two sites: Kaminsky's own "Check My DNS" test page, and Authentium's very own SafeCentral.

If you're worried about the DNS you're using right now, head over to Dan's personal blog and click on "Check My DNS". It will run a quick test on the DNS server upstream from you to see if the patches are in place.

That check isn't going to fix anything, but it is a useful start. If you're interested in protecting your local HOSTS file and making sure that *all* of your requests are securely handled, I would strongly suggest you head over our site at www.safecentral.com and download the latest version of Authentium SafeCentral.

SafeCentral was designed to provide strong protection against many of the hacker exploits mentioned yesterday. PC Magazine and IRM have both tested our DNS security, and they say it worked 100% as advertised.

SafeCentral protects your local HOSTS file, blocks key-loggers and screen-stealers, and sends all web site requests to a secure DNS service.

Note re the patch map from www.doxpara.com: Red = Unpatched; Yellow = Patched (but NAT is screwing things up); Green = OK.

Note: Doxpara is getting *lots* of traffic this morning. Patience may be required to get in.

33,000 Customer Profiles Lost by TSA Vendor

This morning, it was announced that VIP, one of the vendors behind Clear, the smartcard that allows frequent travelers to breeze through TSA-controlled security lines at airports, lost 33,000 personal profiles of its VIP customers when one of its laptops went missing.


The 33,000 customer profiles were *not* encrypted.

Despite the company having adopted an internal policy of always encrypting important data (i.e. like customer profiles), the missing profiles may apparently be freely viewed by identity thieves, terrorists, or pawn shop owners with equal ease.

Which means that whoever now has this laptop has exactly the personal profiles most useful in engaging in acts of terrorism. A more perfect treasure trove of targeted identities could not be imagined.

I don't know about you, but I'm really tired of hearing about vendors that put data on laptops and then lose that data - data that consumers have entrusted to them.

I'm also tired of hearing vendors say "we don't think anything bad is going to happen because of our mistake". Yeah, right.

There is no reason on this Earth that anyone should ever download their entire unencrypted database of customers onto a laptop. None. Zip. Zero.

Congress - want to pass a new law? You should make this kind of action - carrying around unencrypted customer profiles on a laptop - subject to a massive fine, and I mean massive. That might start to clean things up.

Though somehow, I doubt it.

"TJ Maxx 11" Charged With 40 Million Card Theft

A group of hackers that spent several months downloading 40 million consumer credit card profiles from horribly insecure wireless networks operated by TJ Maxx have allegedly been found, arrested and charged.

Yes, I know: "TJ Maxx Eleven" isn't about to be turned into a movie. But it certainly has the makings of one.

The hackers, which took turns monitoring wifi traffic from cars parked outside the stores, found security was so lax on TJ Maxx's wifi networks that they allegedly left notes for each other in plain sight in the databases they hacked into - informing their cronies which records still needed to be uploaded/stolen.

"Dave, I'm fresh out of Doritos and trail mix... suggest you start downloading the credit card records from the August purchases table while I reload..."

Database hacks are horrible because consumers are entirely at the mercy of corporate policy - there is almost nothing they can do aside from buying insurance.

And getting hacked doesn't just mean your credit is up for grabs - it creates inconvenience, and potentially large costs for banks and credit unions who must reissue new cards.

The hack was allegedly the biggest ever. The DoJ is calling it an international conspiracy and says that nationals of The Ukraine, Belarus, China and Estonia are responsible. These guys will be going away for a long, long, long time.

The TJ Maxx IT security guys? Still at large.

Note: TJX Corp is a large holding company and operates the TJ Maxx chain, plus Barnes and Noble, BJ's Boston Market, Dave and Busters, DSW shoe stores, Forever 21, Office Max, Sports Authority and the Wholesale Club.

I'm sure they have a different group running IT security these days. Or at the very least, a much larger security budget.

Websense: 60 of Top 100 Sites Pushing Malware

Last week, Authentium partner Websense published some rather interesting statistics about what users can expect to find on the top-ranked web sites. In summary, what users can expect to find, at 60% of these sites, is malware.

"60 percent of the top 100 most popular Web sites either hosted malicious content or contained a masked redirect to lure unsuspecting victims from legitimate sites to malicious sites - Websense Security Labs."

Note that Websense in not just saying "60 leading websites" - it is saying specifically that 60 of the top 100 ranked web sites either directly or indirectly (i.e. via a link) delivered some form of malware or link to malware - to their visitors.

Part of the reason for this may be that 45 of the 100 web sites that Websense Security Labs studied support user-generated content, such as the posting of images, videos, audio files, messages, comments, email attachments, etc.

Unsurprisingly, given the rise we've seen in sophisticated key-loggers and screen-stealers in the wild, the Websense Threatseeker Network found that 29% of the malware discovered involved a key-logger, screen-stealer, or some other form of data capture malware.

More statistics can be found at the Websense site.

Beyond FDIC: Ideas for Protecting Your Cash

Most consumers and small business owners in the US are aware that the FDIC insures individual accounts up to $100,000. That is the figure that each account holder is insured for in the event of a bank failure, such as the one that just occurred at IndyMac Bank in California.


FDIC insurance provides adequate protection to consumers with total cash assets below $100,000. However, retirees and small business owners need to look at things a little differently - that $100,000 limit may not be nearly enough if your retirement savings are $1,000,000, or the monthly payroll for your landscaping business is $200,000.

I saw a number of worried-looking retirees (and possibly a few landscapers) standing behind the television reporters in the IndyMac parking lot as they announced the failure.

Hopefully, some of these retirees had split their funds into multiple sub-$100k accounts at different banks, or, if a couple, split their deposits into separate joint accounts registered to the couple, single accounts registered to the husband, and another single account registered to the wife.

However, the looks on the faces of the folks I saw on television tells me otherwise. I think it's fair to say that a lot of people who saw the same images are looking to take action. If you're one of them, here's some ideas:

One option is the one I just mentioned - if you have $200,000 in a single account at a single institution, you may want to consider splitting it between yourself and your partner, or moving half to a different institution.

Another option that concerned retirees and small business owners might also wish to consider re insuring larger short-term cash deposits is CDARS. CDARS is a program that enables small businesses to split larger (e.g. >$100k) deposits into individual, FDIC-insured CDs.

CDARS was founded in 2003 by Alan Binder, former Vice-Chairman of the Federal Reserve. Around 2,200 banks in the US now offer this option. The program offers insurance for amounts up to $50mm - but even small business owners/sole proprietors with much smaller balances of working capital should take a look at CDARS.

The typical term of the CDs is four to six weeks. The CDARS web site is here.

Another investment category that concerned consumers need to keep an eye on is their stock portfolio. Because it is so convenient, a majority of consumers now trade their portfolios online. But accounts with online brokerages are not insured by the FDIC.

If you have $100,000 on deposit at one of the leading brokerages, you are SIPC-insured by a private non-government group. How much insurance is offered depends on the individual brokerage.

Many online brokerages offer 100% coverage, but the system has not yet suffered a test involving the closure of a large brokerage. Read the small print carefully - and look at their balance sheets - before you sign up.

Finally, one additional piece of "insurance" that retirees and small business owners should definitely consider is using Authentium SafeCentral - especially while banking or trading online.

The criminals behind last year's multimillion dollar thefts from online brokerages used stolen user credentials to steal $26 million in cash from online accounts in 2007. SafeCentral was designed to prevent that kind of fraud.

SafeCentral protects consumers and small business owners from key-loggers and screen-stealing malware better than anything else we've tested. If you're worried you and your funds may become a target, just go the web site: you can download SafeCentral for free.

Note: PC Magazine just gave SafeCentral an excellent review. Check out my blog post for the link.

Note: I'm not a financial advisor, or a banker - I'm a consumer and small business owner, just like you. I suggest you check out the above suggestions with your bank - they will undoubtedly have some excellent additional suggestions.

"Same Last Name" Email Scam

The Sharp family woke up to some some good news this morning: a private investigator who works with a private bank in the UK has offered to share a fortune with us - because we are lucky enough to have the same last name as a deceased client.


In his email to "undisclosed recipients", the aforementioned P.I. says that he is "not a criminal", which is good to know. He is, apparently, doing this because "the dynamics of my industry dictates that I make this move."

Whatever.

Folks, if you receive an email from someone - anyone - saying they have found a pile of money previously owned by a deceased person with the same name as you, don't reply. It is a scam.

If someone says in an email that they have been hired to kill you - but will forget about it if you empty your bank account in their direction - don't reply. It is a scam.

If a bank or credit union asks you to change or verify or transmit your login credentials via email, don't do it. It is a scam.

An unfortunately large number of people are still are replying to these emails - and many are still being taken for a ride, to the tune of hundreds or even thousands of dollars.

I followed one of these threads to its natural conclusion a couple of years ago, and the guy on the other side - "a UK barrister" was pretty slick. I can see how to some folks a deal might just seem real enough to invest a few hundred bucks.

Bottom line: if an email from a stranger - or an institution - surprises you in some unexpected way, delete it, or if you bank with the institution in question, call customer service before clicking on anything in the email.

Vista Not "New Coke"

Okay, I've been on Vista on and off since the start of the year, and as a regular user of more than three applications, I feel qualified to comment about the comparison Forrester is making between Vista and New Coke.


My two cents: New Coke sucked. Vista is just fine.

I actually have bigger problems with the Office redesign than I do with Vista - and suspect that Vista issues may not be the only reason behind the fact that 87% of corporate PCs (and I presume laptops) are still running XP (Forrester).

Whoever redesigned Office did so with little thought to the fact that the majority of new computer users would be buying laptops with wide-screen formats. And with less thought to the fact that the canvas is the most important part of the interface.

It isn't so much a CPU hog as it is a real estate hog. The design shows the designers were a lot more enamored with the application than they were with any ideas about what magic might be done with it, in the form of documents, presentations or spreadsheets.

But Vista is a different story. After several months of using it, I would not go willingly back to XP. I like it.

Stylistically, I like the way the windows open and close. I like the Aero interface. And yes, I've even gotten used to the redesigned treeviews - to the point where the internal window "jog" has actually started to feel intuitive.

In terms of performance, on my machine - a Sony Vaio with crapware removed - Vista runs really fast, and starts up faster than any of my previous machines running XP. All my plug and play game and music stuff seems to work fine. No networking issues.

What's not to like?

As it turns out, plenty. But some of that hatred is misplaced. According to the results of the Microsoft "Mohave" experiment announced last week (in which XP users were shown a new test "post Vista" operating system and proclaimed it to be great), users may tend to react more to "fuzz and buzz" than to actual experience.

Maybe the Vista team should take the Mohave experiment on the road...

Note: Full results of the Mohave experiment are due to be posted tomorrow here. Kudos to Microsoft PR folks - great job in thinking up this idea in the first place, and getting the word out there.

U Michigan: 75% of Bank Sites Flawed

Yesterday, data presented by Carnegie-Mellon University demonstrated some of the issues that stand in the way of creating the safe Internet experience that online banking consumers are seeking.


The data, based on a University of Michigan study conducted by Atul Prakash, a professor in the Department of Electrical Engineering and Computer Science (and the author of over fifty papers in the field), and two of his doctoral students, Laura Falk and Kevin Borders, examined 241 sites in 2006, including the sites of major financial institutions.

Prakash apparently initiated the study after noticing that his own interactions with financial insitutions on the web were less than secure.

The results are worthy of study. As re-reported on Friday, Prakash and his team found that three quarters of consumer banking sites suffered from some form of fundamental design flaw impacting security.

"To our surprise, design flaws that could compromise security were widespread and included some of the largest banks in the country," Prakash said.

Some of the flaws uncovered by Prakash and his team included:

Placing "secure" login boxes on insecure pages

47% of banks were found to be guilty of this particularly transgression. Doing this is rather problematic in that it exposes user names and passwords to hackers using man-in-the-middle attacks, or siphoning data off wireless networks.

Hosting of support/help/security advice on insecure pages

55% of banks presented their support pages within a non-secure environment, allowing hackers to easily intercept support request or even set up their own spoofed web pages and call centers using DNS redirects.

Non-Domain Redirects

Prakash found that 30% of banks surveyed sent their customers to other sites in order to facilitate transactions. Unless these other sites utilize some form of identity federation or shared trust, this practice is *not good*.

SSNs and Non-Secure User IDs

Prakash and his team faulted sites utilizing social security numbers and email addresses as login credentials s user ids for exposing this information to hackers via man-in-the-middle attacks. I agree with this "outing" of this practice.

Weak Passwords

Given the ease of validation methods, allowing weak passwords to exist isn't a great idea, and doesn't safe anyone any money in the long run. According to Pradah, 28% of the sites surveyed allowed weak passwords.

Insecure Messaging

31% of the web sites of financial insitutions surveyed by Prakash were found to be emailing statements and/or passwords to customers.

None of these design problems are issues if consumers do their banking using Authentium SafeCentral, but all should be examined/fixed anyway. The cost of fixing each of these issues is minor; the benefits are potentially significant.

The fact that we are able to protect against the exploitation of these weakenesses should not be used as a reason not to fix them. Consumers will on occassion need to use a non-secure browser. Banks should perhaps examine this list for indications their own sites could be improved.

China: 253 Million Internet Users and Counting...

Ten years ago, before co-founding Authentium, I traveled to Beijing to meet with China Radio International and discuss a possible joint venture with them and the satellite company I was working for.


I've always loved going to China. But this time there were several notable highlights to the trip.

One of the highlights was a tour of CRI's multistory, mid-city facility, during which we were shown several interesting items, including their concert hall, a map of the Chinese shortwave radio grid and the China National Radio Museum.

The museum was fascinating. At the time, CRI was broadcasting over its shortwave grid (and via AM repeater stations) in 49 languages, including Esperanto. Arranged in a large darkened room in glass and wood cabinets were gifts from all over the world, including operettas in Hungarian, bottles of whiskey (unopened), and hand-written song requests.

In one cabinet, sat the polished gray and chrome microphone used by Chairman Mao to proclaim the new order, from the Peace Hotel in Shanghai.

I checked into the room Mao stayed in during a previous visit when I was there in 1995. The room cost me $140 for the night. The guys in the jazz band in the bar downstairs were all eighty years old.

After the museum, we ended up in the basement of the building looking at a map showing the shortwave repeater stations... but what really took my attention was a powerpoint slide showing the fiber being laid between the major cities.

One of the guys in our small group said something like "this is a very ambitious plan". Our translator translated this and the Chinese just shook their heads and smiled at the poor naive Westerners sitting across from them.

"This is not our plan", our guide explained. "This is our current capacity".

He went on to explain that in major cities they already had fiber passing about 70% of buildings, and broadband uptake was in double digits and growing fast. We all looked at each other, and then looked back at the maps, and wondered - could this really be the case?

Could China have really built the largest broadband network in the world?

The news out of China today - that they now have 253 million Internet users sitting in a market that is growing above 50% a year - shows that indeed they have.

I wouldn't be surprised if it is announced next week by the ITU that China already has more broadband users than the US: after all, they were ranked second by the international body at the end of 2005.

Commentators will come out in the next few days and claim these numbers are inflated. I don't think so. Based on what we saw a decade ago, I think the numbers are real, and I think the growth figures are real too.

Note: Check out the image above - yes, that really is a program guide from China Radio International in Esperanto, complete with banner ads, also is Esperanto. Don't believe me? Click on it and check out CNI's site.

Unpatched: 10 Million DNS Servers, 500 Million Browsers

A few weeks ago, I blogged about the 500,000,000 unpatched Internet browsers that the Swiss Insitute of Technology estimates are out there.

Yesterday, I blogged about the 10 million DNS servers now at risk because of the DNS vulnerability recently identified by Dan Kaminsky.

Now, let's assume that 20% of the DNS servers have been made compliant over the past few weeks, a number that I personally believe is a stretch. That still leaves 8 million DNS servers as targets for hackers looking to redirect Internet traffic, and 500,000,000 unpatched browsers.

That's a lot of potential for evil.

A friend from one of the larger online financial service providers in the US sent me a link to a quote Kaminsky made that was published yesterday. In this quote, Kaminsky is starting to sound the alarm:

"We are in a lot of trouble," said IOActive security specialist Dan Kaminsky. "This attack is very good. This attack is being weaponized out in the field. Everyone needs to patch, please. This is a big deal."

As I mentioned yesterday, we shouldn't hold our breath when it comes to hoping all the DNS servers out there are going to get patched anytime soon.

Another issue that I can see looming regarding this issue is the difficulty that the mainstream press is going to have in "sound-biting" a technically complex (for non-IT folks) problem so it can be made interested for consumers.

That initial explanation of how large and small remote Domain Name Servers and local HOSTS files all work together to resolve URL requests is going to have folks reaching for their remotes pretty quickly...

The good news is that there is a solution available. Almost five years ago, we started work on a system that would protect there requests from the origin point through to the destination server.

As I mentioned yesterday, our service, Authentium SafeCentral, bypasses the non-secure DNS infrastructure and provides a secure means of correctly connecting to transaction sites.

This patent-pending service operates securely, anywhere in the world, regardless of whether or not your ISP's DNS servers have been patched. And if you're one of the 500,000,000 who haven't updated your browser, SafeCentral will provide you with a much safer Internet.

Note: Some of you asked where the estimate of 10 million DNS servers came from. Although I thought this was was clear in the original blog, the sources of the number was the Infoblox DNS Report Card, which estimated there were nine million DNS servers in place at the end of 2007.

I simply took the previous year's growth and used that as a guide - which produces a total base of just slightly less than 10m servers.

PC Magazine Reviews Authentium SafeCentral

PC Magazine just published an excellent review of Authentium SafeCentral.


Our security features all worked exactly as advertised and the reviewer had many positive things to say about the enhanced security SafeCentral offers online consumers - especially when it comes to online banking transactions.

The only negatives were lack of a password manager, lack of support for Firefox antiphishing, and slight slowness in rendering pages. All of these feature requests/issues have already been addressed for our new release.

The review focused on three main areas: phishing/spoofing, keylogging and screen-stealing, and DNS (URL lookup) security.

With respect to our antiphishing capabilities, one of the things I liked about the review was that the reviewer understood the need for a systematic, real-time approach to preventing phishing. Here's what he said about our abilities in that area:

"If you always visit your sensitive sites by launching them within SafeCentral, there's almost no chance you'll be taken in by a phishing scam."

He also tested our secure DNS lookup capabilities by hacking his test system HOSTS file, and found that we prevent that kind of DNS poisoning.

"I added a line to make requests for www.pcmag.com go to a different site. IE and Firefox were totally fooled, but the SafeCentral browser brushed aside my amateur hacking and went directly to PC Magazine's site."

Excellent! That is exactly what is supposed to happen - poisoning of the local HOSTS file is one of the easiest hacks to pull off, and our patent-pending TSX library (now part of SafeCentral) does a great job of preventing this.

On the subject of sneaky key-loggers and screen-stealers, the reviewer used a keylogger that's "sneakier than most" (his words) and again compared us to IE and Firefox (check out the slide show on PC Mag's site for screen shots of this attempt):

"The keylogger totally captured everything I typed in IE and Firefox. It saved screenshots, it recorded data from the clipboard, and it even tracked what URLs I visited in IE. But it didn't get a single byte of information from the SafeCentral session. I tried several other keyloggers with the same result. Good job!"

The reviewer noted at the end of the review that we could do with some improvements in speed (already addressed), password manager support (also already addressed), and support for the Firefox antiphishing technology (included in the latest build).

The complete text of the review, including screenshots of SafeCentral, can be found by going to PC Mag's site, buying the magazine, or clicking here.

If you'd like to download SafeCentral for free, please go here.

The DNS Mystery Ends Badly

Okay, like a lot of security guys, I speculated on what Dan Kaminsky was going to announce at Black Hat regarding the current DNS vulnerability.

Here's a quick recap of the problem, courtesy of Wired:

"The DNS flaw that Kaminsky discovered allows a hacker to conduct a "cache poisoning attack" that could be accomplished in about ten seconds, allowing an attacker to fool a DNS server into redirecting web surfers to malicious web sites..."

"A cache poisoning attack allows a hacker to... translate a website's name to a different address instead of the real address, so that when a user types in "www.amazon.com," his browser is directed to a malicious site instead, where an attacker can download malware to the user's computer or steal user names and passwords that the user enters at the fake site..."

My own speculation involved an assumption of stupid levels of randomness. But if Thomas Dullien (aka Halvar Flake) turns out to be right (and as of this writing, most people seem to think that he is), I was off by a force of magnitude - in terms of both stupidity levels and the ease with which this vulnerability can be exploited.

The vulnerability allows hackers to basically take over a DNS cache "in about ten seconds" (see above quote). Wired predicts the first root kits will be in circulation by *tomorrow*. Here's a link to the post from Dullien.

So if the problem is known, why do I say this ended badly? Because we're looking at a massive, Internet-wide problem. Even though vendor patches are available, Internet security - and DNS lookups - are going to be compromised for as long as it takes for everyone to get compliant.

There are an estimated 10 million DNS servers out there. According to the Infoblox DNS Report Card survey in 2006, by the end of 2006, less than two thirds of DNS servers (61%) had been upgraded to BIND 9 - an improvement of barely 3% over 2005 levels.

With no policing forces at work (other than customer complaints and market forces), I predict that it will take years for all servers to be brought compliant. Which means this problem - DNS insecurity - is going to be around for a while.

I wouldn't be doing my job if I didn't point out that our secure transaction service, Authentium SafeCentral, uses an independent system of secure DNS servers linked to a secure client to make sure that every request for a bank or brokerage web site goes to the right place.

Building a Successful SDK

Software Development Kits are a big part of what we do at Authentium.


For more than a decade, we have packaged and released system-level tool kits, including Linux and Windows-based antivirus SDKs, personal firewall SDKs, and system-level file-hardening tools.

These tool kits have been used by many industry leaders in the security, SAAS-based managed services, and telecommunications industries to create new products and services.

Based on this experience, we have learned a lot about what tool kits need to offer engineering teams. But first, let's start with a proper definition.

Software Development Kits (SDKs) should enable developers outside of the distributing organization to access and utilize the code/intellectual property in a way that clearly defines both the scope of the intellectual property (IP), and the scope of what is allowed to be done with it.

The commercial model needs to closely match the scope of the toolkit. If your toolkit effectively allows other companies to compete with you, or includes some significant ongoing service commitments (both these are true with respect to anti-virus tool kits, for example), then your model needs to take into account the need to price using a "co-opetition" model and fund the ongoing service costs.

SDKs by definition also need to be well-documented, starting with the licensing schema.

It is extremely important to let developers know up-front what can and can't be done with the code. In my opinion, Firefox does an excellent job of explaining what is covered under general public license (GPL) and what is owned by the third party developer. Knowing what the tool kit owner owns, and what you could potentially own, based on your use of the kit, is important when licensing in code.

Documents designed to inform engineers are the next step. There is nothing worse than "snobby" or badly-written documentation. Engineers face deadlines and have limited time to learn your code. They need to know that your engineers are dedicated to bringing them up to speed and helping them make this deadline - the quality of your documentation reflects this better than anything else.

For me, the first step in testing your documentation should be to ask someone that has never tried your toolkit to build something with it. Does the documentation clearly enable the engineer to create something using your toolkit, without resorting to calling the manufacturer? If the answer is yes, and your legal agreement is clear, proceed.

Features found in the product that a toolkit is based on are often not included in the SDK. In my view, this is wrong - rather than force your partners to "reinvent the wheel" you should present them with features as part of your commercial model. Include them in the code and value them correctly - that way, everyone wins.

The final thing any decent open platform code-base or SDK needs is good support, provided by people who are proud of the code and willing to help. SDK need to be supported either by an interactive, wiki-based community, such as is the case with Linux, PayPal or Firefox, or by a dedicated team of engineers prepared to answer questions from other developers.

In summary, SDKs need precise legal and commercial definitions, an appropriate and understandable commercial model, great documentation, cool features, and solid support. If you have all these, your SDK should be successful.

Note: My thanks to Vladimir Dubovik at US Bank for asking the question that led to this post.

DNS Insecurity

Imagine an attack in which the hacker controls all your Internet traffic, and is able to redirect your web site requests away from your requested destination to a spoofed web site that they control.

This scenario is called a Man-In-The-Middle (MITM) attack, and is achieved when a hacker is successful in "poisoning" or modifying the Domain Name Server cache.

Once a DNS cache is poisoned, it enables intelligent interception and redirection of web site requests to be managed from a point remote from the client (and the destination.) DNS poisoning is, in many ways, a case study in online criminal efficiency.

Next month, as everyone in the security industry now knows, Dan Kaminsky is going to step up to the mic at Black Hat and talk about something everyone already knows is a big problem - DNS insecurity.

So what is Kaminsky going to tell us? The fact that an out-of-sequence patch was issued by Microsoft two nights ago (a patch that apparently kicked users of Zone Alarm firewalls off the Internet) explains where the problem probably lies.

The Register (which refers, accurately, to DNS insecurity as "the mad woman in the attic" and a "peripheral, forgotten issue") added some color today, unearthing a 2005 paper from Ian Green which makes for some interesting reading. Here's a peek at his paper:

"...as the infamous Mitnick vs Shimomura attack and other subsequent attacks have shown, many weaknesses in network protocols are a result of poor implementation rather than weaknesses in the underlying protocol. In the Mitnick attack, 'IP source address spoofing and TCP sequence number prediction were used to gain initial access'."

Hmmm. Can you can tell what is coming next? Three pages later, post a few hours of research, Green writes, of his target research (the XP DNS Resolver):

"The DNS transaction ID always begins at 1 and is incremented by 1 for each subsequent DNS query; and... the UDP source port of the query (which becomes the UDP destination port of the response) remains static for the entirety of a session (from startup to shutdown)."

In other words, Green has followed Mitnick's advice and found exactly what was predicted: stupid levels of predictability. The DNS transaction ID, which is allowed to be a random number 16 bits long, has been implemented in such a way it can be easily guessed ("n" + 1).

In his paper, Green faults Microsoft's flawed implementation of DNS in XP ("ten years after the Mitnick attack"). The Register article uses this as the basis of a theory about what Kaminsky is going to talk about - a theory that was bolstered by MSFT's out-of-sequence patch this week.

Anyway, let's assume that's right. That leaves us Internet users with a problem. Mitnick first paved the way 13 years ago. Green's paper, which was published by the SANS Institute, came out three years ago, in 2005.

If it turns out this is what Kaminsky is going to talk about, why is everyone assuming the problem will be taken care of quickly?

The truth is, it won't. Only a minority of vulnerable users will hear about this and download and install the patch - leaving lots of room for those folks looking to pull off the perfect Internet crime - the MITM, or Man In The Middle attack.

Note: It would not be proper for me to sign off without pointing out that a solution exists for XP users: Every single DNS request made inside Authentium SafeCentral is handed off to our secure DNS service.

This ensures that even users with totally compromised machines get to where they want to go, without experiencing a MITM attack.

Hartford Courant Does Good

This morning, the editors of the Hartford Courant took a walk down the Yellow Brick Road and found courage, smarts - and a heart.

In an editorial this morning entitled "Drop The Charges" the Courant challenged Connecticut prosecutors to drop the bogus charges they have lined up against Julie Amero and take the retrial off the books.

In writing the piece, they proved that it is never too late to right a wrong, or claim back some respect.

For anyone unaware of this case, Julie Amero was the schoolteacher who was kicked out of her job after pornographic pop-ups appeared on an un-patched, unprotected school computer in front of several students.

Lots of people have since looked at the exact code she was looking at at the time (thank you archive.com) and found unmistakable evidence that this is probably among the worst cases of injustice ever perpetrated in the short history of Internet-related crimes.

Amero was without any shred of doubt very unjustly punished - there were links in the code that I saw that led to places other than those advertised, popups that aggressively spawned new popups, and let's face it, even if Amero went everywhere the prosecutors claim, why isn't the IT guy at the school attracting attention for not keeping the schools filters up to date?

The whole idea of having filters is so that kids don't get exposed to stuff like this - no matter what actions adults take.

The Courant compares Amero's current dismal state with that of some of the borderline inmates waiting for trial in Guantanamo. This isn't nearly as crazy as it sounds. Amero is also sitting in limbo waiting for prosecutors to get off their butts and admit they don't have anything.

Hartford folks, when your local politicians come to you for re-election, please do all of us a favor and ask them where they stand on the Amero issue. Make it a local issue.

Take a brave action - like the Courant has done today - and vote some prosecutors into place that will make your community worthy again of respect.

Update: Re the last paragraph, an alert reader has pointed out to me that things are not done quite so democratically in Connecticut. Click "Comments" (and watch for future entries in the Authentium InSecurity blog) for more...

500,000,000 Unpatched Browsers

IBM, Google and the Swiss Federal Institute of Technology have just come out with a really interesting study. The subject was the relative security of the 1.4 billion users of the four main browsers currently in distribution.


Browser security is the hot area of study right now. Last week I wrote a piece in the blog on man-in-the-browser attacks, describing why it is so important that you use a secure browser. If you haven't read it, you should. But back to the study.

The study looked mainly at two things: the security "holes" or exploits that currently exist, and the effectiveness of the update strategies used by the 1.4 billion users of the four main browser developers - Mozilla (Firefox), Microsoft (IE), Opera (Opera) and Apple (Safari).

Firefox, which uses a completely automated update strategy, won the day with 83.3% of users patched up to the latest version, compared to less than 50% of IE users. IE users chose to ignore patches far more often because of IE's "permanently put-off this update" approach - leaving them more open to browser-based attacks.

As the ArsTechnica overview of the report states:

"Firefox and Opera are both credited for including an auto-update feature, but the team notes that "Firefox’s auto-update was found to be way more effective than Opera's manual update download reminder strategy." How effective? way more effective."

We like Firefox at Authentium. Authentium's SafeCentral end-to-end transaction security solution utilizes a specially-hardened version of Firefox 3 in conjunction with our system-level hardening technologies and a secure DNS system.

If you're thinking of downloading FF3, or upgrading, I'd recommend you go over to the site and get yourself a really secure browser.

Note: the ARS article was entitled "40% of Surfers Don't Bother With Browser Security Updates" - for us and all the other people working in risk mitigation, the fact that there are half a billion unpatched browsers out there is one scary fact.

Security 101: Locking Down Your Premises

Bank Infosecurity's Linda McGlasson has an excellent post over at her site today on what happened during a real-world, real-person penetration testing exercise at an (unnamed) financial institution.


I had had two discussions this week CSO at banks who said they are becoming overwhelmed with similar real-world security problems, like social engineering of their call-center staff and proper checking of vendors and hosting companies at the front desk.

The bottom line is that a lot of nice people just want to be nice - and that makes them easy targets for people looking to do "walk-in" style attacks. These nice people need to be better trained to understand that sometimes being nice involves being firm and inflexible.

In any case, locking down these vectors is the correct place to start. The correct prioritizing of security efforts involves first locking down the physical premises. Putting in place advanced network security is only effective in conjunction with a robust and wide-ranging set of security policies that includes every potential attack vector.

Linda's blog can be found here.

Insecurity and the Need for Heroes

I was in Lower Manhattan on 9/11 when the planes hit. And as the horrible events of that day unfolded, I, like many other New Yorkers, tried to help.


I went first to St Vincents in Greenwich Village to donate blood, watching as thousands of dust-covered refugees from the City streamed north, past white-coated doctors and nurses waited in vain beside a line of empty gurneys.

Then, once it became clear that blood wasn't what was needed, I headed with a group of other guys over to the docks to volunteer to help dig people out - only to be turned away because they wanted people "with tools and experience" - as in, experience in digging and cutting through steel and concrete.

So I went back to the neighborhood - just as the National Guard arrived and started locking everything down, from 14th St south to Battery Park.

As it turned out, the only heroic act that I managed to perform during 9/11 was the procuring of emergency supplies and the refilling of Kristen Johnson's water cooler (it's a long story). Hardly the stuff of legend. I went to bed - late - deeply unsatisfied with my contributions.

Meanwhile, the real heroes became more heroic to us New Yorkers by the day.

That afternoon, and for all the next day, and days after that, we would cheer them on from the east side of West St, as the firefighters and cops and construction workers kept digging, looking for "the people in the pictures" as we came to call the missing in the weeks after the tragedy.

The experience was unprecedented for me. I'd never felt such insecurity - or been in the middle of a disaster scene before. I had never ever before seen real life heroes up close, working to save lives - except for doctors and nurses and mothers. This form of heroics - the disaster response - I had no ability to comprehend it beyond the obvious sacrifice happening right in front of me.

Which brings me to the subject of this blog.

In his book "The Black Swan", Nassim Taleb postulates that a forward-thinking, highly-placed politician could have prevented the tragedy of 9/11 - by forcing the adoption of laws mandating additional security in the form of terror-proof, secure cockpit doors on aircraft.

He then explains that had this additional security been put in place, 9/11 would probably not have occurred, and New York, and the WTC, would have continued much as before.

But as Taleb explains, every action has a cost. Imagine the life of our politician as he faces re-election one year after his successful legislation. His success in forward-thinking has, unexpectedly, created a large personal problem: His overwhelming success has resulted in the complete destruction of a whole class of threats.

What remains, once the threat of an attack has been removed? The cost. And only the cost. Ask George W. Bush and Dick Cheney.

And so it ends with our hero. Taleb's story concludes with our lawmaker - the politician who "prevented" the attack - being turfed out of office for imposing such a ridiculously costly and unnecessary "security burden" on the airline industry, perhaps after the running of an ad campaign explaining how "all that money" could have been "better spent".

Taleb's story (originally told to explain the theory of Black Swans, like 9/11) goes a long way to explain why CSO's and their hard-working IT security staff often feel unappreciated.

It explains why boards and governments almost never sign up for large-scale security spending. It explains why "adequate amounts of security" and "heroics" will forever be incompatible. It explains why firefighters get depressed and sometimes light fires.

It also explains a lot about the security software industry. Analysts and engineers working in antivirus facilities like Authentium's Virus Lab sometimes get frustrated when criminals and hackers get lionized by the press - especially after an all-nighter spent securing the world from the threats they've created.

Taleb's story illustrates why when insecurity is rife, as it was on 9/11, heroes are needed. But it also explains why, with few exceptions, the names of the most successful folks in the threat prevention business are seldom heard outside of the industry.

Because, by improving security, they have killed off the likelihood of threats, and the need for heroes. They have made the terrible event go away, before it could occur, and become invisible as a result.

Thanks, Bill

I read several of the articles this evening describing the departure of Bill Gates from Microsoft, and quite a lot of the commentary.


While some of it was appropriately complementary, I thought a lot of it was kind of spiteful and missed the mark. One of the comments that I did see that I agreed with was from Rob Pegoraro of the Washington Post:

"...one of the foremost virtues of Microsoft's operating systems has been the staggering variety of third-party programs available for them."

Pegoraro is correct. This really is Gates' legacy at Microsoft: unlike the Apple world, which until very recently was a (relatively) closed environment, Gates perpetrated a non-Jobsian world in which we all got to write software and compete with each other.

Yes, there's that whole monopoly situation that happened, but for all the word processing companies that were put out of business, there are a bunch of other software developers - including several extremely large companies - that would not (could not) have existed without the hobbyist approach taken by Gates and Allen.

For anyone interested in these *real* early days of Micro-Soft (when it was three employees - Gates, Allen and Davidoff - and still had a hyphen), check out the text of the letter written by then-hobbyist Gates pleading with hobbists to pay him and Allen royalties for BASIC so they can "hire ten programmers and deluge the hobby market with good software".

Like the shareware/hobbyist generation of developers he helped get started, he lists his apartment as the suggested drop point for donations - 1180 Alvarado SE, #114, Albuquerque, New Mexico, 87108.

Did Microsoft simply do a better job of engaging the user? Or did convenience (and bundling, as in Office) win the day? The release of FireFox 3 may settle once and for all the questions about whether better design (and investment in innovation) eventually win out over time.

For me, the most interesting aspect of Gates is not his company but the approach he is taking to deploying his wealth. He and his wife are doing some pretty remarkable things around the world, and are, unlike many organizations, attempting to deploy their money in ways that will ensure the bulk of it is used efficiently.

I think a century from now, Microsoft will almost certainly no longer exist. Gates' wealth distribution - and the results of his actions in this area - will be his lasting legacy.

Internet DNS Root Managers Attacked

In the past hour, various news outlets have reported that users to the web sites of ICANN (the Internet Corporation for Assigned Names and Numbers) and IANA.org, the Internet Assigned Numbers Authority, have been redirected by a Turkish hacker group calling itself "NetDevilz".


According to the New York Times, users visiting the servers of the above organizations were re-routed to a domain called "atspace.com" and greeted by the message ""You think that you control the domains but you don't! Everybody knows wrong. We control the domains including ICANN! Don't you believe us?"

This is obviously *not* good news. These two organizations manage the core (root) servers that match domain names (i.e. web sites) with the http requests made by your browser (the site you type into the address field - i.e. www.google.com).

When hackers "poison" DNS servers (Domain Name Servers) in the manner they did today, their intention is most often to take your request for the web site of a bank and redirect it to a site "dressed up" to look like your bank.

This is usually called a "DNS poisoning" or "pharming" attack, but the points are usually much closer to your PC: common points of attack include your local hosts file, your cable router, the DNS server at your ISP - in short, places relatively close to home.

An attack on the root DNS system would be of a different magnitude entirely. Attacks on the root DNS system are potentially far more damaging than attacks on your local ISP DNS servers. Rather than just re-route a single request, or group of requests from a user, a prolonged attack on the root DNS system could have potentially quite harmful effects if the rerouting were to involve targeting of banking or financial systems, or government addresses.

I'm frankly amazed that attacks of this nature are still possible at organizations like this. To me, the attack, labeled a "cyberprank" by some news organizations, is anything but a cyberprank. A different, lower-level hack involving manipulation of records for financial gain or terrorism could have created quite a different story.

DNS security is an often overlooked requirement and something that almost no security software suites provide an answer for.

When we were designing the core concepts for SafeCentral at Authentium, one of the requirements that I added to the service early on was a requirement that every DNS request generated by the user should be send to a secure infrastructure for resolution - rather than into the non-secure DNS system as it currently exists. We've since added additional security methods to ensure that these DNS requests reach the right destinations.

Today's attack shows why such diligence is necessary - and why the Internet remains a somewhat unpredictable and non-secure environment - and why you should use the best security possible when banking or transacting online.

The Non-Innovator's Dilemma

"The Innovator's Dilemma" refers to the value-reducing situation that arises when a company decides not to innovate, and chooses instead to focus on merely sustaining its existing products and processes.


This phrase was first introduced by Clayton M. Christensen in the best-selling book of the same name. However, I personally think the title doesn't provide an accurate description of the situation.

I would have gone with "The Non-Innovator's Dilemma". Yes, it's less catchy, but it potentially better reflects what actually goes on inside a company populated by both innovators (who are typically not managers) and managers (who are typically not innovators).

First of all, some definitions. The word 'dilemma' comes the Greek words "di" (meaning two) and "lambanein" (meaning, "to take", as in choosing a path). Not every decision results in a dilemma. A dilemma only occurs when the choice becomes difficult, and the decision process becomes prolonged. Dilemmas last only as long as the decision-making process.

"Innovation" usually involves a new or novel approach to solving a problem - i.e. the invention of the telephone solved the need for inter-personal communication, the automobile solved the need for inter-home transportation, the assembly line solved the need for mass-production (in the face of mass-demand), and the advertiser-supported search engine enabled advertisers to place targeted advertisements in front of users via the Internet.

Innovations are often termed "disruptive technologies" because they "disrupt" the markets they enter, displacing older technologies (hello TV dinner, goodbye home-cooked meal) and creating new disruptive manufacturing processes (and new marketing channels, markets and support systems) in the process.

Because true innovators are usually future-aware and focused of the potential value of their innovation, they rarely find themselves in any kind of dilemma at all when it comes to plotting the company's forward path. To them, the reason for the disruption they are proposing is obvious, and value of their tinkering and suggested changes abundantly clear.

The real dilemma usually starts when the non-innovative decision-maker, typically a manager of the type produced by the various business schools, is forced into a room with an innovator and asked (by the innovator) to change his capital allocation budget or the course of the company, either slightly, or in a very disruptive way.

It is this executive, not the wild-eyed innovator/developer, that now faces the true dilemma. Depending on the scope of the new idea, the challenges the manager faces in making a choice whether or not to pursue the disruptive innovation may be enormous, and involve every facet of the corporation's life. Here's an imaginary summary of half a minute's worth of his/her brain activity upon hearing about this new approach:

"I have 'x' amount of capital. I have made firm commitments to my investors as to what our existing product will produce in terms of an ROI (return on investment) for the next three years.

"The cost of ripping up my business plan, disrupting my staff, recruiting new experts, reinventing my processes and legal forms, retraining my sales and support networks, pitching new customers on the new idea, refocusing my development team, and repositioning us in the market is going to be enormous...

"Not to mention the cost of emptying my warehouse/servers of all that old product/code and upgrading customers and the potential liabilities of sunsetting that business - this is going to require me to spend hours engaged with board members and lawyers and other executives and require me to rewrite the budget, and..."

Faced with these kind of challenges, many executives will often just politely tell the innovator "let me think about it", and back away from the table. Or, if they can't articulate these feelings to this basic level, they may instead decide to say something along the lines of:

"You damn guys are the *exact same team of guys* that asked me for millions of dollars to come up with the product that we're shipping *right now* - and now you're saying that it isn't good enough?!"

Sometimes, a decision-maker will listen and respond in cool fashion to disruptive ideas with this time-honored answer - "prove to me that a market exists for this innovation."

In response, the innovator will often mention that the inventors of the car, Coca-Cola, canned food, the radio, the television, PCs, Kool-Aid and Guitar Hero were all unable to show that a market existed for their innovations - until after they were released.

Which brings us to the dilemma.

The imagined scenarios above are, of course, gross simplifications. But regardless of the relative complexity (or not) of the events that lead up to the decision point, it is at the decision point that the non-innovator's dilemma actually begins.

Will the non-innovative decision-maker choose merely to sustain the existing business? Or get in behind the disruption/innovation? (It should perhaps be pointed out that at the moment the executive makes the decision in favor of disruptiveness, he is no longer a non-innovator, but has joined the ranks of the innovators - maybe Clayton has the right title after all.)

I am lucky enough to work with a smart bunch of guys at Authentium, both on the board and in management, that understand that disruptive technologies - like SafeCentral - are solely needed in the security software space. But many other inventors and innovators aren't as lucky - which means their companies wont be as "lucky" either.

Nassim Taleb, author of The Black Swan, suggests that businesses succeed only when they create environments within which "aggressive trial and error" is tolerated - and he goes further to suggest that only with "endless tinkering" can innovative companies get "lucky" and deliver to stockholders the future Black Swans/Googles of the business world.

I think he's right. Interestingly, when you look at shareholder growth, it is the tinkerers that make for a good long-term bet - Bell (Bell), Marconi (Marconi), Edison (GE), Ford (Ford), Jobs (Apple), Page and Brin (Google) all returned huge multiples to their investors.

In fact, several studies have shown that public companies led by an entrepreneur/tinkerer (i.e. Steve Jobs at Apple, or Fred Smith at FedEx) grow 8% faster year on year than companies led by a non-tinkerer. One more myth exploded.

Speaking of myths, in addition to the excellent Nassim Taleb (who causes me to wear a permanent wry smile while reading), I would recommend Scott Berkun's book "The Myths of Innovation".

Berkun does a great job of debunking the stereotypes associated with the typical inventor-genius and provides instead an overview of the kind of hard work - and tinkering - that has always been required to create a successful new product.

SafeCentral "Free Trial Version" Link

A couple of you wrote in yesterday asking for the downlink link for the "free trial version" of Authentium SafeCentral.


Rather than bury this response in the "Comments" section... the "free trial version" link is the same as the main link I quoted in the blog: http://www.safecentral.com

Just head over there, enter your email address, and the download should start immediately. That's all there is to it.

Note: kudos to Daniel Sullivan of Konceive. The new SafeCentral site design looks really nice, Dan.

Gpcode and the "Long Tail" of Ransomware

Many years ago, when I used to work in parts of the world that were considered unsafe (e.g. Washington D.C.), I was sent by my former employers to a day course on "kidnapping and ransom insurance" so I would know what to tell my abductors if I were ever bundled into a stolen SUV, tied up with coarse ropes, and held for ransom in a damp basement somewhere.

(Note to any would-be potential kidnappers - the policy I'm referring to above lapsed over a decade ago. Please take me off your list.)

Aside from the surge of vanity that came over me at the thought that I might be of value to a kidnapper, one of the other things that struck me as strange during this briefing was that their instructions went against everything I'd ever seen in a movie.

In fact, what my instructors advised me to do was this: be boring. Do *not* try to be a hero and/or try to escape (this was, according to them, when most injuries/deaths happen). Tell the kidnappers the dollar amount you're insured for - and hand them the phone number of your insurance company (this was conveniently printed for me on a plastic-coated, wallet-sized card).

I was to do zero negotiating myself - they were adamant about this. It was critical to tell the kidnappers the correct dollar amount. It needed to match the dollar amount the kidnappers would hear upon calling the insurers.

According to these guys - who, despite the apparently exciting nature of their work, were insurance salesmen - having this "fixed value" would be helpful in reducing the time in captivity and the phone number/trusted party would keep me alive.

Not only would it reduce the "back and forth" of negotiations, and allow everyone to get back to a happy place (i.e. home/the jungle) faster, it would reduce the possibility of a "long tail" - which is the (belated) subject of this blog.

What is the "long tail", in kidnapping terms? That's what happens when your distressed wife empties out your bank accounts, then drives to the alloted meeting point under the train tracks on 10th Avenue at midnight, expecting to see your bloodied and battered face in the headlights - only to be told by the kidnappers "we want more".

I could keep telling this story, but you can probably see where this is going. The first demand was simply the start of a very long process of wringing every last dollar out of the "channel" - in this case, the distressed spouse, her family, your family, your employer. This, dear reader, is the "long tail" of kidnapping. And this is unfortunately is what also occurs in the kidnapped home computer version of our story.

By now, everyone has probably heard of "ransomware" - the kind of virus that somehow gets onto your c: drive, encrypts your data using terrorist-grade encryption, then asks you to buy a "key" to unlock it.

Failure to buy the key, the hackers warn, will cause your data to be "publicly released" (almost always a bogus claim, because they don't have the server space to store your 80 gigabytes of downloaded videos, along with everyone else's).

Alternate claims include the threat that your personal data will be permanently deleted on date "x" (also bogus - because most of these programs don't include a "delete" function), or rendered "permanently inaccessible" (unfortunately, probably true).

You may have also heard via the media that there is a new version of this form of malware, identified last week by Kaspersky as the "Gpcode.ak virus", that will wrap your personal data up into a ball and then encrypt it using a 1024 bit key.

How much encryption is 1024 bits? A lot. The government standard-length key used by your browser to encrypt transactions is billions of times easier to crack. In fact, the largest number that has ever been factored by anyone was this number, and according to several experts, that outcome has been achieved precisely once.

What this all means is that unless you can get you hands on the key (or find some flaw in the implementation of the encryption mechanism, which is what Kaspersky is attempting to do, in partnership with other security firms), your data is staying locked up. Which leaves you with a stark choice: Either give up on your data permanently, or pay the ransom demanded by your kidnappers.

My advice? Do *not* pay the money.

Yes, I know - this contradicts my opening story. But in the real world example that I provided above, an entire industry has gone to work to understand the myriad factors at work when a real-world kidnapping is committed, and has determined that the best course of action is a one-time payment, negotiated via experts, and executed via a trusted party.

In the case of ransomware, or the kidnapping of your computer data, no such trusted party exists, and there is no guarantee that the first payment isn't simply the start of a "long tail" that could get extremely ugly.

How long? How ugly? Well let's look first at the payment mechanism - do you really want to give these hacker/ransomware guys a credit card? Do you really think they'll just ding it once and send you a receipt? Of course not.

Sure, you could potentially bypass that problem by using a debit card purchased from that nice lady at the mall - and you could potentially have them send you the key to a free email account you'll use only once - but what if they send you an executable? Do you think it will just install and magically unlock all that personal data that has been sewn up and then uninstall and you'll never hear from the hackers ever again?

Talk about a "long tail" - when I think of all the possible things that their "data unlocking" executable might include, and could do to your credit, your bank accounts, and your PC over time (please see yesterday's post on Man in the Middle attacks for one example), it makes buying a new PC look like a cheap option.

Which brings us to the happy ending: the reason that ransomware has yet to become a plague on the computing subset of humanity is that most folks, by the time they get set to enter their credit card or unlock their data using the "unencrypt" package they just received via Hotmail, have cycled through the above options, made the right call, and said "goodbye" to their data.

That's what you should do too.

ADVICE #1: PC users have one excellent option available for thwarting potential hostage takers that unfortunately doesn't exist in the real world: it's called "data backup". If you haven't already reached for your backup drive after reading this, now would be an excellent time to do so. One backup a day, and you'll never feel like a victim. Easy.

ADVICE #2: Since I wrote this, Kaspersky has posted a happy ending of their own - a free utility based on Christophe Grenier's PhotoRec utility that Kaspersky claims will restore data and file paths erased by Gpcode. You can get it here. Kaspersky suggests that users who have suffered from Gpcode donate to the author of the PhotoRec utility rather than pay cybercriminals. I agree.

Note: Don't count on this fix working the next time - it is going to get harder as the Gpcode versions get higher. Back that data up!

ADVICE #3: A final piece of advice: make sure your browser disallows "drive-by downloads" - or downloads from unknown or non-trusted sources - so you can avoid getting hit by Gpcode and its clones at the outset. The best solution in this area is Authentium's very own SafeCentral.

First Amero, Then Fiola, Then...

You'd think after the mess created by the prosecution of the Julie Amero case in CT, State Prosecutors (and employers) in nearby North Eastern states (i.e. MA), might have become a little more informed as to the myriad ways in which "bad content" can find its way onto a computer - other than via the hand of the computer user.


Apparently not. Anthony Fiola, a 53-year -old MA resident (and a former accident investigator with the Department of Industrial Accidents - tell me *that* isn't irony), is the latest guy to be told to clean out his desk and frog-marched from his former employer's offices a la Amero after a search of his laptop revealed porn on the computer.

And because this story is now out there, you know it didn't stop there. After a forensic investigation by the State, Fiola was charged with downloading "unauthorized content" onto a laptop he was given by his former organization's IT department and sent up for trial - a series of events that led to Fiola losing his paycheck, his insurance, and his employment benefits.

Although most friends deserted Fiola, his wife did not. Fired up, she hired a lawyer and the lawyer hired an independent expert. And as a result, Fiola became the second person to be saved from jail time for an act he most probably did not have anything to do with.

Memo to MA state computer crime detectives and consultants: Guys, the kind of spyware that causes this stuff is rife, and well-documented (check out Alex Eckelberry's site over at Sunbelt Software for some great analysis and commentary on the Julie Amero case, or Authentium's very own Robert Sandilands for more technical analysis).

In any case, maybe it's time that state forensic experts also started relying a little less on one piece of fairly well-discredited forensic analysis software. You all know the application I'm talking about.

Anyway, for those wishing to get mad at the world (and at over-eager state prosecutors) all over again, PC World has a very well-researched article on the Fiola story here that I couldn't hope to embellish or improve. It's told by Fiola in his own words, and its pretty candid, and pretty darn sad.

If this guy's a liar, I'll eat this blog.

Man in the Browser Attacks - Worse Than Viruses?

The problem with computer security terminology is that while some forms of attack sound appropriately nasty, some of the emerging forms of malware sound more like cartoon characters than serious threats. Take, for example, the "Man in the Browser" attack.


The idea that a computer can become "infected" with a virus, or piece of self-replicating malicious code, is universally understood as "bad", because the analogy is fairly straight-forward, and viruses are universally bad things.

But the idea of using CPU cycles to replicate viruses is considered pretty old-hat these days. Most criminals think it better to use your CPU to process transactions, or ship online banking credentials.

In fact, that's all they think about. Today's villains don't spend their time figuring out how to open your CD tray remotely or clog up your memory - they spend their time engineering ever-smarter ways to get their hands on your money.

So while virus-like behavior can sometimes still be helpful, the model for emerging attacks is no longer the infectious agent. Today's model is the "secret agent", or "snitch". Criminals are now focused on placing their malware in line with your transactions.

Which explains why the focus - and the battleground - for security threats and preventative measures alike is now your browser.

Your browser acts as the central interface for almost every transaction on the internet. Browsers are relatively simple creatures - over ten years, they have evolved to simply render the code passed to them into "pages" of text and images, forms, flash objects, popups, and javascript alert boxes, among other things.

When you make a request to your bank, via your browser, both you and the bank's server are saying to your browser, "render this". Unfortunately, your browser can sometimes prove to be a little too obliging.

Man in the Browser (MITB) attacks have been around for several years, but have recently begun receiving more attention because of their (now proven) ability to thwart the additional security that was supposed to be provided by expensive two factor authentication devices, including physical tokens.

Talking to an authentication token salesman about "challenges" used to invoke funny stories about pocket-lint and what happens when tokens accidentally go through the wash, or end up at the cleaners, or in the hands of valet parking attendants.

This is no longer the case - most two factor token sales reps are now extremely aware of the limitations of these devices - and somewhat nervous about the future of their industry. In the past two months, several large banks - including Abbey and HSBC - have announced rollbacks of these programs.

If you're a two factor authentication user, you should be nervous too. Because those sleek black physical security tokens with the gorgeous flashing red LED readouts are fairly easily bypassed using pretty standard social engineering techniques. Read on.

The "hack" looks like this: You head on over to your bank's site, and tab into the wealth management portal. You enter your user name and pull out your expensive, clock-based, two factor authentication token. You turn it on and key the PIN into the site.

What happens next varies, according to the criminal's MO, and the type of malware installed on your machine. But typically, as your page is being rendered, a piece of software now resident in your browser (that you - or your teenage daughter - previously installed because the video you were watching said "you need a new video codec") wakes up and inserts a few additional lines into the code - maybe five lines of javascript - an alert box, a timer function, and maybe some in-page content -and sends a message to a hacker, far far away.

What happens next looks perfectly normal. Upon loading, the alert box pops up - something like the dialog box pictured above - and says "Server synchronization in process... please be patient", accompanied maybe by a nice animated GIF in the bank's colors.

Except at that moment, as you sip your coffee and watch the seconds pass, secure in the knowledge that these sophisticated systems and occasion waiting periods are the "price of modern security", a hacker somewhere is receiving a timely message that you have started an authenticated session and are ready to transact, using the credentials contained in the message. At which point, he can simply log in as you.

Now this doesn't happen every time. Sometimes, the hackers choose to wait, secure in the knowledge that this capability will be there many sessions into the future, and that at some future point an increased account balance may make it more worthwhile to have waited.

And sometimes, the crimeware is configured to allow the hacker session to kick in when you "log out" (was that really the bank's "log out" screen that you just saw? Really?)

As the guys in our labs are quick to point out, there are many variations on the MITB theme, most of them horrible, and well-funded. In some instances, MITB malware is programmed to decrypt and load only when the users requests content from a particular bank (this is apparently a common approach right now in Brazil).

The bottom line is this - no matter what you see going on during your session, if you see something "different" or unexpected happening during your online banking session, close your browser immediately, and call your bank or online broker.

Most online banks are exceedingly good at *not* changing things within their UI - because their user interface designers know that changes make users nervous. So if you see something new, like an alert box, please don't assume that the bank has changed their policy. This almost never happens.

Luckily, this story does have a happy ending. For a solution to the above conundrum (at least one that doesn't involve getting in your car and going to the branch), check out some of my previous posts on SafeCentral - an end-to-end secure session technology that stops MITB attacks from happening in the first place.

I strongly recommend that you download and use this protection - regardless of how sophisticated your authentication token may appear to be. It's free, and it works.