Who Cloned the Web Site? Here's how to Tell...

One of the problems regularly encountered when dealing with phishing, fraud and other flavors of counterfeit Web site content is the process of tracking back who the original perpetrator of the crime was.

Given the stateless nature of Web application technologies and the abundance of tools capable of conveniently cloning and creating "off-line" copies of popular transactional Web sites, it's damned near impossible to tell where the copy came from unless you can uniquely "seed" the content in some way.

Over the years I've been asked by dozens of financial institutes around the world as to the best techniques and technologies that can be used to seed Web application content and tag it in such a way that it's possible to figure out who the original "copier" was - without alerting them to the fact.

There are a number of techniques available to Web application designers and architects, but I've found the best solutions (i.e. least detectable and least prone to tampering or removal) revolve around tagging the images used within the application.

It's not an easy solution to implement, but the principle of "Distribution Tracing" can be applied to Web applications in the form of anti-fraud images.

I've finally had a chance to knock up a whitepaper describing the relative merits of the different techniques after all these years, and you can find it on my main Web site under the topic "Anti-fraud Image Solutions".

Now I'm sure some people are going to question the merits of the solution - and rightly so. I'm not an overly strong proponent of this kind of tracking solution. It needs to be used carefully and with an expert eye in order to yield prosecutable results, but for some organizations (particularly financial services organizations) it adds an extra arrow to their quiver in hunting down criminals who try to defraud their customers.

So, here's a question for readers (after they've read the paper of course)... can you name some of the large international banks that have already implemented Distribution Tracing within their secure customer portals?

------------
The whitepaper's abstract:

The Use of Distribution Tracing Within Web Content to Identify Counterfeiting Sources

Many of today’s more successful Internet-based fraud tactics require the counterfeiting of popular transactional Web sites such as financial portals, stock-trading platforms and online retail sites. For the fraud to be successful, the cyber-criminal must typically clone most, if not all, of the targeted site’s content and host the counterfeit site on a Web server under their control. With some minor modifications to the underlying HTML code and changes to the application logic, the cyber-criminal will seek to steal the personal authentication or authorization credentials of unlucky victims who fall to the counterfeit site. Armed with these credentials, the cyber-criminal will subsequently attempt to defraud the accounts of their victim.

The major subclass of this attack is often referred to as “phishing” and typically targets the customers of major financial organizations; with the cyber-criminals end-goal being the removal of monies from their victim’s bank accounts. However, over time, phishing attacks have increasingly targeted a broader range of online consumer.

One key problem facing organizations targeted by these cyber-criminals is the identification of the perpetrators. While it is sometimes a simple task to shut down or have removed a counterfeit site, it is much more difficult to uncover the identity of those responsible for its creation.

Since the counterfeit sites are predominantly clones of a legitimate site, there are a number of techniques that can be employed by an organization to essentially “embed” a key in to the duplicated content which can then later be used to trace back to the original source of the content.

This whitepaper provides an overview of the techniques available to organizations that wish to undertake such identification activities – evaluating the pro’s and con’s of the various mechanisms and providing advice on how to employ this class of investigative technology.

<PDF of Anti-Fraud Image Solutions>

Google's What's Up CAPTCHA

Earlier this week there was a little chatter about a new CAPTCHA proposed by some of Google's research team. The actual paper - What's Up CAPTCHA? A CAPTCHA Based On Image Orientation - is well worth a read, and it's an interesting slant on the theme of helping deflect automated attacks against Web applications.

One criticism that I've had in the past for many of the CAPTCHA's out there and in use today is the fact that, in order to thwart the bad guys and their improved attack tools, the CAPTCHA has evolved to an almost unusable state for the "average" user - i.e. my grandma wouldn't be able to answer it even if she wore her glasses.

This proposal from the Google researchers I think addresses that concern, as it seems to be much more usable than some heavily obfuscated and random arrangement of letters and numbers we see on most sites. That said, I suspect that it's not going to be particularly successful against the bad guys - but, then again, the current generation of deployed CAPTCHA's don't solve that problem either (and I don't think they ever will).

CAPTCHA's as a defensive technology have proved to be redundant in the face of organized criminal attacks. You can find more analysis of how the bad guys have moved beyond this technology with my previous blogs - Evolving Beyond CAPTCHA - and - CAPTCHA's and Mechanical Turks.

Personally I'd like to see these image-based CAPTCHA's used rather than the current generation of letters/numbers ones - not so much because of their defensive value, but rather for ease of use by average Internet users. Reducing the complexity of these security hurdles is always going to be beneficial.

Bot Counting via Hijacked C&C Portals

So, the question is "can you accurately size a botnet by hijacking the Web C&C portal and counting the bot agents under management?"

The obvious answer should be "yes", but I'm sorry to say that the answer is almost certainly "not really". Not meaning to rain on Finjan's parade, but just because a C&C portal has a 'total' figure - doesn't mean that's how big the botnet actually is.

Original response is over on the Damballa site... "Caution Over Counting Numbers in C&C Portals"...

C&C Portal Counting

It’s always a struggle to get definitive information about the size of the global botnet infestation. The typical way in which security researchers build the big picture is either through extrapolation of an existing dataset (e.g. there are 1,000 infections within this class-A, therefore there are probably 250,000 infections globally) or through the summation of confirmed reports.

The former method has always struck me as fraught with uncertainty, and I wouldn’t even consider it a reliable estimating method since there are way too many factors at work. The later method tends to underestimate the global number – but is a more accurate reflection of what we know.

So, it was with interest I read today’s blog by Finjan - How a cybergang operates a network of 1.9 million infected computers – which details their investigation of a Web-based C&C platform that they stumbled upon which appears to have been managing a little over 1.9 million bot agents. It’s an interesting walk through of what they found (and well worth the read), however I think it’s important that followers of these kinds of numbers (and supporting evidence) keep a critical eye open.

Some things to bear in mind with these kinds of notable finds:

1. The absolute number quoted within these C&C portals doesn’t necessarily mean that there were (or are) as many bot agents out there.
   a. Depending upon the age of the portal, the number is probably an aggregate of all the infected hosts over time. Some hosts may have been infected and then remediated or just “lost” by the botnet herder.
   b. Just like the way in which new companies tend to start their invoices with a number other that one (e.g. start with 10000) so that their first customers don’t realize that they are so small/new, botnet herders aren’t just as inclined to start at a higher number – after all, a big number looks cool.
   c. In the majority of cases the counter increments upon the addition of a new infected host. In many cases each reinfection of an infected host (e.g. the user falls victim to the same drive-by-download attack) overwrites the malware that was first installed and creates a fresh registration to the C&C server.
   d. DHCP – an oldie, but a goodie – means that an infected host will be assigned different IP addresses (and host names if they’re subscribers of a mainstream ISP), which means that the same host can (typically) get counted each time it connects to the C&C from a different address. In conjunction with that, “new” infections that happen to reuse an older infected IP address registration may not get counted at all.
2. A basic business model has developed over the last 18 months revolving around building large botnets as fast as possible, inventorying them for low-hanging-fruit authentication credentials and network-orientated configuration info (e.g. speed of network connection, VPN, NAT and enterprise network settings), and then carving them up for sale to other botnet operators. As such, the carved off botnet subsets (often sold in the realm of $50-400 per thousand hosts) may be removed from the C&C portal. I say “may” because the large botnet herder may not bother removing them from the count (It’s only a counter after all), or that he still keeps a backdoor open to bots that have already been sold off.
3. In most cases, to gain access to the C&C portal, you need to supply login credentials. Depending upon which country you happen to be living, accessing the C&C portal without permission may constitute a legal offense – and be subject to jail time. Just because the bad-guys were operating a botnet doesn’t mean that the good guys are allowed to break in to their systems – sorry, but it’s true whether we like it or not. Some may argue that the good-guys are just breaking in to a system owned by the bad-guys, so that’s fair game. Unfortunately, theres no guarantee that the C&C server is actually running on a host that the bad-guys own – in fact there’s a higher probability that it’s running on a server they’ve p0wned (i.e. it’s another victims computer). Therefore, by proceeding with an unauthorized access to the previously-compromised computer, the good-guys could be prosecuted by the real owner of the system… and things can get really ugly of that host also has important/confidential files on it belonging to the host owner.

One last observation about this type of botnet C&C discussion - you’ll note that there are multiple malware samples associated with the botnet. This is a common modus operandi as botnet herders use their C&C channel to force down new malware packages to be installed – often from various organized cyber-crime malware distribution gangs – for a fee (this is part of the money making process) – and the infected host may subsequently be remotely controllable by a whole bundle of different botnet operators. As a consequence of this multiple-install process, the infected host is effectively “sub-leased” my multiple tenants – and disagreements can often result in mini-battles as the various botnet herders try to wrestle ultimate control of the host away from the other operators. There’s no trust amongst criminals.

The Fine Art of Attack Prediction

Internet security is gradually evolving from an art in to a science - particularly the evaluation of vulnerabilities in terms of threat impact and business risk (to which I think that CVSS has played a significant role in galvanizing the major software vendors). That said, one security realm still firmly entrenched as an art is "threat prediction".

The way I see it, "Threat Modeling" is quite a bit different from "Threat Prediction". While the former focuses on using existing threat information to model trends and evaluate risk profiles (often incorporating measurement systems such as CVSS), the later tends to assume longer timescales and deals with factors or industry trends that can not be reasonably precomputed and modeled.

Threat prediction typically requires the crystal ball to be rolled out and, depending upon the diviner, can be a little hit or miss at the best of times. However, I've found that threat predictions tend to become more accurate if you assume a few things first:

1. If the bad-guys can make money from exploiting it, then you bet that they'll try.
   
2. The more sophisticated the technology, the more vulnerable it is to primitive attack.
3. The lowest hanging fruit are the first to fall.
   

There's also a fine line to be walked between keeping it real and flooding the airwaves with FUD (which the industry is only too keen to keep on perpetuating), and I often find myself wishing some security commentators would bear those three assumptions above before launching a press release.

Common Sense Threat Prediction
Threats are evolving at an increasing pace, but in most areas it's not too hard to predict a few years in to the future. While many "new" threats appear original at first glance, if you study your Internet security history you'll soon be able to draw parallels with past and present threats. In fact, the more you understand the mechanisms that shaped past threats, the better you'll be able to predict how new ones will evolve.

For example, look at how protection against password guessing as evolved...

• [Whitehat] Force the user to supply a password in order to login - thereby stopping the blackhat from logging in with just the UserID.
• [Blackhat] Passwords can be guessed, automatically cycle through popular passwords to find the right one for the UserID and gain entry to the system.
  
• [Whitehat] Implement an account lockout procedure consisting of a maximum failed guess threshold (e.g. three failed password attempts and the account becomes inactive).
• [Blackhat] Abuse the threshold procedure to lockout lots of users accounts and construct a denial of service attack - seeking to make money via extortion.
• [Whitehat] Setup a proceedure to automatically 'unlock' locked accounts after a few minutes or hours - thereby negating the DoS threat and inconvenience to the end user.
• [Blackhat] Implement horizontal guessing of passwords. Armed with a long list of known UserID's, try the same password against each UserID before trying a different password - thereby making use of automated account unlocking without adversely hindering the guessing process.
• [Whitehat] Implement CAPTCHA's to stop the blackhat from using automated tools to pass the Turing test and guessing the USERID password.
• [Blackhat] Socially engineer or recruit other Internet users to answer the CAPTCHA's and include the results in to the automated password guessing tool. [more discussion on these techniques can be found here and here].
  

A thing to bear in mind with the example above is that the overall "password battle" between blackhats and whitehats evolved throughout a decade - with the most rapid change occuring within the first couple of years (note that CAPTCHA's have only been popular as an anti-automation technique for 2-4 years, and it's only in the last year that we've seen the criminal blackhats recruit and pay Internet employees to break CAPTCHA's).

It's probably also worth pointing out that particular Internet threats and attack techniques never actually disappear, and it's not uncommon for the same threat to reappear several years later in a slightly different guise because of some new implementation of an old (and vulnerable) technology. I wrote a whitepaper on the topic a couple of years ago - Old Threats Never Die.

With all that in mind, It's also worth pointing out that threat prediction is getting easier. While the technologies are getting more and more sophisticated (and integrated), if you keep the thought "how would I make money from exploiting it?" at the forefront of your mind, you'll probably be reasonably good at predicting what the bad-guys will do

Password Revisitied

I've been hearing a lot about HTTP-based brute-forcing of Web email accounts lately - in particular the use of automated tools - and there are few interesting aspects here that I think commentators are missing.

Firstly, the easiest (and fastest) way to brute-force a webmail account is to not use HTTP. Ignoring the major free-mail services (e.g. gmail, yahoo mail, hotmail, etc.), many people rely upon ISP-provided webmail services for their every-day mail access. What you will find is that these ISP-provided webmail services come bundled with the ability to host your own personal Web site - as part of the service. And, you've probably already guessed it, you use your email address and it's password to access via FTP or WebDAV. Therefore, brute-forcing via FTP/WebDAV is possible - in fact it's not only possible, it's also much faster and more efficient (in many cases, FTP won't lock out the account after too many password guess failures).

Another aspect for consideration is the fact that in most cases today you don't actually need to brute-force the password, instead you can focus on a much smaller subset of probabilities via the "forgotten your password" interfaces. While an account password may be 8 characters long and contain numbers, uppercase characters and extended characters, the password recovery may be as simple as guessing a favorite color or pet's name. Even security aware geeks fall for this - and I wonder how many passwords can be recovered by answering the "your favorite movie?" recovery question with "Star Wars"? - too many I bet.

So, what happens after all that? What if you want to "recover" a webmail account (yours or someone elses)? Hire an expert of course...

Password Recovery Services

If you have regular access to the Internet, the odds are pretty high that you’re also making use of the email services from one of the popular free Webmail providers. In fact, most people I know have multiple personal accounts on several of the most common platforms (e.g. gmail.com, hotmail.com, yahoo.com, etc.).

Unfortunately, remembering the passwords for these accounts can be troublesome – particularly if you don’t use an account regularly or (more commonly nowadays) if you’ve been using some application’s “remember my account/password” functionality.

What happens when you’ve forgotten the password (or never knew it to begin with)? If contacting the email provider and answering the “forgotten password” questions hasn’t worked, there are several ways to gain access to the password.

If it’s been “remembered” by the Web browser or “saved” by the email client (e.g. Microsoft Outlook) there are several installable tools freely available to help recover the password. Most of the tools are very small and effectively do a little registry or memory hooking to “see behind” the *** asterisks, and present the password back to you. Meanwhile, others perform a little crypto magic and decode the stored password from somewhere else on the host.

I’ve used these tools many times in the past – both personally (e.g. recovering passwords for DSL modem dialup's when trying to migrate to a replacement PC) and professionally (having gained control of a remote host during penetration testing and needed to recover other user-level passwords for deeper penetration) – but you have to be pretty careful. Today, more often than not, you’ll find many of these “free” tools come bundled with spyware and keyloggers built in.

Someone Else’s Account

OK, but what if you’re in need of hacking in to someone else’s free Internet email account? What about if you don’t want the owner of the account to know you’re interested in getting their password and gaining access to their account? Well, in this age of hacking-as-a-service, you’d be right in guessing that it’s pretty easy to engage on-demand “password recovery” hacking services.

But why would someone want to use these hacking services? Funnily enough, the hacking-as-a-service web sites themselves will give you plenty of excuses why you’d want to engage their services in breaking in to personal email accounts…

• Online Infidelity (Cheating Spouses)
• Identifying Cyber Stalkers
• Internet Security Audit
• Background Search
• Online Fraud Investigations
• Employee Data Theft
• Cyber harassment
• Internet Surveillance
• Password Recovery
• Identity Theft
• EBay (Online Auction) Fraud
• Child Predators and Pornography

I think most people have a fair amount of personal information in their free webmail accounts. With the webmail providers continuously increasing their free storage capabilities (and making it very difficult to actually “delete” any emails), most users probably have several years of stored emails – emails likely containing order confirmation details, photo’s of loved ones, banking and personal account details, address details, etc. – all of which has a value to an identity thief and can be sold through any number of channels.

But it can go further than that. It must be hard for some employers not to engage these services themselves. How many times have you seen farewell emails go around the corporate email system with the leaving employee saying that they can be contacted at such-and-such webmail address? What if that farewell was from a manager or executive who was off to work for a competitor, or launch a start-up organization, and the likelihood of other employees following them was high? If the (former) employer could inspect that webmail account every so often they could probably figure out who was about to jump ship and maybe take preventative action.

Is it Legal?

Depending upon which country you happen to be living in, maybe – but more than likely “probably not”. You’d have to check with your own legal team (I’m not a legal expert), but the services being provided sound pretty-much like criminal hacking to me. At the very least they’re going to breach the terms and conditions of the webmail provider.

You’ll also find that many of the hacking-as-a-service providers will have their own “terms and conditions” and disclaimers for self preservation. By way of example, here’s a snippet from one such site:

"Use of Sites Services
We don't have any partnership or alliance with Yahoo, Hotmail, AOL, Rediffmail. If you lost your password from these sites you have to first contact the corresponding authority. We are recovering passwords using some of our softwares, brute forcing and dictionary attacks. We will not responsible for any damage occur in the email id you supplied.
We will not crack passwords of another persons. If you are contacting us to crack another users password, that will be 100% with your own risk. Password hacking of another persons account is illegal. So all legal and government actions relating to the case is against you only.”

Service Levels and Reassurances

Competition in the password hacking business is fierce, and you’ll find no shortage of suppliers. At the moment the market is fragmented, with many smaller hacking-as-a-service providers specializing in a handful of local country-specific webmail providers. For example, a quick search will reveal dozens of specialist Russian and Czech sites focusing on popular .ru webmail services – such as Mail.ru (list.ru, bk.ru, inbox.ru) and Pochta.ru ( fromru.com, front.ru, hotbox.ru, hotmail.ru, land.ru, mail15.com, mail333.com, newmail.ru, nightmail.ru, nm.ru, pisem.net, pochtamt.ru, pop3.ru, rbcmail.ru, smtp.ru).

I’ve also come across a lot of portals that “specialize” in hacking any email account as long as it doesn’t belong to a .gov or .edu domain (which is interesting in its own right). But I’ve also stumbled across a few that cater exclusively to .gov and .edu mail services - so none are "safe".

That said, you’ll also find the competition has driven some of the larger international service providers to present polished commercial facades that promote the quality and professionalization of their services, with many offering money-back guarantees should they fail to retrieve the password of the account you’re interested in.

While most search engines will quickly uncover stacks of service providers, you’ll also come across lots of hacker forum postings promoting their services – each offering their own unique reassurances of their service. For example, with the help of an online translator:

To start probably need to reassure potential customers:
A) We are not advances. [i.e. they do not need advanced payment]
B) We are carrying out transactions through the guarantors of the forum in which you find this announcement.
C) We provide daily report on the work done.
D) We are not physically stronger orders.
E) We maintain our established time frame.
F) We are polite and attentive, what you want.
About rules, see no need to write, because each order individually discussed with the client.

How much does it cost?

Whether you’re dealing with the hacking-as-a-service providers Web portal, or directly with the password recovery purveyor, “100” appears to be a popular figure for a single email account. That “100” may be in US dollars, Web-money WMZ, or some other form of currency, and can be paid using any of the usual online payment systems.

In the majority of cases, the providers do not require advanced payment, and the process of engaging a service provider is pretty easy. For example, the Crackpal service (pictured above) lists five easy steps to the password recovery of your targeted webmail account:

1. Email the target id to crackpal@crackpal.com or click to order password
2. After Successful Crack we will send you the proofs
3. Verify proofs and if you are well satisfied then you can reply back
4. We will send the Detailed Payment information after getting reply
5. After payment confirmation we will send the original password

Interestingly enough, while several payment options are available, it looks like they will only accept direct bank deposits from Malaysia, Singapore, the Philippines and India – which likely hints at their operational location.

Password recovery prices tend to increase once you move from popular webmail accounts to other email accounts. For example, hirehackers.net charges a lofty $200 per retrieval session for POP3 email account passwords…

…and you’ll also uncover plenty of scam artists operating in this field.

Behind the Scenes

There’s actually not a lot going on behind the scenes in the attacks. As you’d expect, in almost all cases the hacking of the targeted email accounts are done through standard automated guessing techniques (e.g. dictionary attacks and brute-forcing) using commonly available tools and scripts.

What you will find though is that some degree of specialization has been necessary by the hacking-as-a-service providers due to CAPTCHA use. The smaller providers appear to be making use of tuned auto-CAPTCHA-breaking scripts, while the other “general” providers are more than likely employing human CAPTCHA breakers (you can find out more details of these CAPCHA breaking trends in an earlier blog entry on Mechanical Turks).

This approach is not necessarily guaranteed to retrieve all passwords – especially if it is a long and complex password (i.e. a “good” password). And it’s often for this reason that the providers won’t charge in advance (most common with fixed price recovery schemes). I suspect that each provider has decided upon a “maximum effort” level (or duration) that they’re will to expend in earning their 100 whatever-monetary-units.

But, as you’d expect, there are also a handful of hacking-as-a-service providers that charge based upon a sliding-scale of effort involved. You’ll often see such portal sites including details of how many IP addresses or botnet agents they will be using in their password recovery efforts – and you can sometimes select how much effort (as in time and agents) you’re willing to pay for.

Protection

How do you protect against someone employing these services to hack in to your webmail account? Unfortunately, there is very little you can do beyond the obvious.

1. Use a webmail provider that is known to have good anti-bruteforce protection (e.g. check out the details of how they handle account lockout processes and alerting).
2. Use a “good” password. There are plenty of guides on selecting appropriate passwords, but in general make it long and unpredictable. But beware – some webmail services don’t actually allow users to select passwords that would meet the “good” criteria (such as artificially restricting password length to 10 characters). If you’re currently relying on one such webmail provider, I’d recommend changing to another one that does – there’s no shortage of free webmail providers out there.
3. Don’t keep your entire email history online if at all possible. Delete regularly – especially personal information!

If you’re like me and don’t really use free webmail services that much, but find you need something like them for handling all those bothersome web sites that require an email address so they can send you a confirmation email with a URL to download or access they thing you were actually interested in, then I’d recommend disposable webmail services such as dodgeit.com (or dodgit.com).

These types of email service allow you to specify any email address you want within that domain (e.g. brochuresfromhell@dodgeit.com), and then access that “account” anytime without requiring a password. Obviously, they’re no good if you’re expecting any personal information to be received – and most don’t allow you to send emails either.

Cleaning up botnet infestations

Why is cleaning up after a botnet not the same as cleaning up after a worm or other malware infestation?

I've answered that question today over on the Damballa blog - A not-so-obvious botnet cleanup strategy.

Ignorance is bliss (in Web application security)

One of my favorite security maxims relates to "Ignorance is bliss" - i.e. the confidence that people have in security is inversely proportional to how much they know about it.

It's particularly true in the field of Web application security.

I continuously monitor the major Web application security discussion forums, and occasionlly chime in on a few items, but it's become increasingly clear that too often the folks discussing Web security (as experts) are operating on a plane several layers removed from how real people use those applications and what "security" really means to the end user. That's not to say the security experts are wrong - they're not - but the root cause of the security threat is often quite remote to the technical or technological solution proposed by the experts.

An area of interest to me within Web application security is "security ergonomics" - which is a label I tend to use to describe just how well the security elements of an application fit (and work) with the end non-security user, and how much they impact the safe use fo the application. The net impact for a poorly thought out security mechanism is typically counterproductive to the overall security of the application is was designed to operate in. Which, when translated to non-geek basically means "if it gets in the way of how the user wants to use the application or causes them to think about it, it'll be ignored and bypassed".

For technical minds, the sign on the machine in the photo above - "CAUTION - This machine has no brain use your own" - is what is expected of application users today. Unfortunately, I don't believe that such warnings work, and more effort needs to applied by Web application developers to embed their security and make it invisible to the end user.

Reconsider the warning above. While it sounds like a great message that should be applied to Web application security, there are some key reasons why this is inappropriate. Firstly, the probability that Joe Public can randomly walk around within an industrial environment and come face to face with this machinery is pretty remote. Secondly, the warning was designed for the skilled and trained employees who regularly work within that particular environment - not as a warning, but as a reminder of the systems capability.

By way of example of where a divergence in security thought occurs. Examine the login panels for various Web mail portals to the right.

Most technical users and those with some degree of security paranoia would know what to do next. But, as for Joe Public, what the hell is "Advanced Login"? Why should it be important? Why should they use it? Whats the difference between "advanced" and "secure"?... "let me in to my webmail damn'it, and don't ask me stupid questions!"

I'll let you in to a dirty little secret, 99.9% of users to using these webmail portals believe they're secure already. The "Advanced" and "Secure" login options are redundant for them. Not because they willing choose to be insecure, but because they have assumed that they are already secure (or secure enough).

Sure, the security geeks can argue all they like about the merits of providing these enhanced security options, but for 99.9% percent of their user base those options are redundant. On top of that they add to the users confusion about how to use the application.

So, with that in mind, and in the context of "security ergonomics", the correct Web application security model should have been:

1. The maximum security option is the default - i.e. HTTPS - not the other way around.
2. There should be no other login options visible on the first login panel.
   
3. Only after they fail to log in the first time should they be offered the facility to lessen their security settings (e.g. offer to turn off HTTPS - and provide a visible warning that it is now less secure).
   

Try a little common sense folks.

Handling Secret Documents

"Whoops!" - although I'm guessing the real phrase contained a long string of expletives - after a senior UK government official managed to get snapped on camera emerging from a car with secret documents (outside No 10) - unfortunately the paparazzi were able to read the document in hand through their lens.

This kicked of a chain of terror raids...

Full story is over on the BBC -"Terror raids follow files blunder"

//Updated: Friday 10th, April//

He's a photo of the document in question...

Mobile Phone Viruses

There's a very interesting article in the latest issue of Science titled "Understanding the Spreading Patterns of Mobile Phone Viruses". While the whole article isn't online, the supporting documentation is available - but if you want to read the article, then you'll have to pick up a copy of the latest Science magazine.

The article covers the spread of mobile phone viruses and makes use of a dataset associated with 6.2 million mobile customers and some 10,000 mobile phone towers. I hope that data was sufficiently anonymized.

From the abstract:
"We model the mobility of mobile phone users to study the fundamental spreading patterns characterizing a mobile virus outbreak. We find that while Bluetooth viruses can reach all susceptible handsets with time, they spread slowly due to human mobility, offering ample opportunities to deploy antiviral software. In contrast, viruses utilizing multimedia messaging services could infect all users in hours, but currently a phase transition on the underlying call graph limits them to only a small fraction of the susceptible users. These results explain the lack of a major mobile virus breakout so far and predict that once a mobile operating system’s market share reaches the phase transition point, viruses will pose a serious threat to mobile communications."

I've been looking in to mobile phone viruses and methods for protecting against them for a few years now, and I'd largely agree with the findings of the article and there are some very pretty diagrams as to how the viruses propagate via Bluetooth and MMS, which is helpful in introducing others to the topic.

An area of contention though relates to the MMS propagation path. While MMS viruses can propagate very fast and to a much broader population (requiring no physical proximity), unlike Bluetooth viruses, they are much easier to stop. Since the payloads have to pass through the carriers MMS transport, it is easy to intercept the malicious content centrally - thereby halting propagation.

To some degree the major carriers have started down this path, and were eventually successful against mobile viruses like CommWarrior a few years back. Future mass-MMSing malware will be easy enough to detect and stop using the technologies already in place - subject to client-side polymorphism adoption (which hasn't been done seriously beyond some proof-of-concept samples -- yet!).

An area of future concern though is standard Web propagation techniques. Since most new smartphones allow comprehensive Internet access and have their own Web browsers (and other online services), I believe that mobile phones are increasingly going to fall to drive-by-download attack vectors and most of the badness that desktop hosts have been combating for several years.

That said, I don't think that third-party developed host-based protection (e.g. "desktop" Anti-virus) is a real solution for mobile phones. The dynamics between carrier, device and customer are very different when compared to desktop relationships. The consequence of this different relationship is that the mobile phone carrier has to do the heavy lifting in protection but, more importantly, they're in a much better position to do this.

"Unnamed", unloved, "invisible" and unprotected...

So, whats an "unnamed" threat, and how well are you protected against it?

Given the industry reliance upon reactive signature systems, an "unnamed" threat is something you genuinely need to be scared of.

Then there's those "invisible" threats too. How about them?

Dealing with those pesky "unnamed" threats are covered within the Damballa blog I wrote this afternoon.