Risque Management

[Q] Detecting virtualisation

I think that it it not practically possible to detect reliably, using a piece of code, that the code is running inside a virtual machine.

But apparently there are ways to make a good guess - for example, by looking at the devices that are typical for certain VM environment (like S3 Trio64 video card in MS VPC), or virtual machine extensions installed in the guest OS.

This time I have two questions:

1. Any other ways to detect that the code is running in a VM?
2. Why malware tries to do that? It does, according to Sandi Hardmeier, a great spyware fighter and a MVP.

What the hack!

Recently I came across a Web site that sells software for predicting American Idol results: DialIdol.com

The idea is really neat: to automate diaing to the voting phone numbers, measure rate of "busy" signal, and make prediction based on that. It works with many TV shows - including Canadian Idol. And it's in true spirit of hacking - commodity technology is used to implement a brilliant heuristic with no harm done.

Well, there is a potential for harm in it. If the software goes out of control (as in: becomes hugely popular), it may pose a denial of service attack on the TV shows. Just like the Morris worm brought down the Internet.

Can the Idol show results be hacked? Obviously you can spoof your caller ID and make a million calls supporting your favourite talent. But you have to pay for the calls, which limits the impact - and avoiding the payment is a crime. Besides, even if you succeed, few will notice, as talents in question tend to be... insignificant.

This is real security

Zbigniew Brzezinski, a prominent political scientist, recently wrote an interesting article in Washington Post - Terrorized by 'War on Terror' (How a Three-Word Mantra Has Undermined America). It's an analysis of the recent change in American mentality and a worthwhile reading. But there's something that Dr. Brzezinski gets just wrong:

Just last week, here in Washington, on my way to visit a journalistic office, I had to pass through one of the absurd "security checks" that have proliferated in almost all the privately owned office buildings in this capital -- and in New York City. A uniformed guard required me to fill out a form, show an I.D. and in this case explain in writing the purpose of my visit. Would a visiting terrorist indicate in writing that the purpose is "to blow up the building"? Would the guard be able to arrest such a self-confessing, would-be suicide bomber? To make matters more absurd, large department stores, with their crowds of shoppers, do not have any comparable procedures. Nor do concert halls or movie theaters. Yet such "security" procedures have become routine, wasting hundreds of millions of dollars and further contributing to a siege mentality. 

An apparent failure to apply Occam's razor. The war on terror isn't the reason for screening visitors to the office buildings. It's a layer of physical security that exists to protect private property. It makes computer and office equipment theft, a universal problem in such environments, harder. Therefore the checks aren't all absurd.

And producing an ID isn't necessary.  Such requirements can be (and sometimes should be) successfully challenged. Here's How To Fly Without ID. That works. Similarly, if you're invited to a meeting, you don't have to prove your right (or permission) to attend. That's not like crossing border of a foreign country.

 Don't confuse real security for stupid security. There is a fine line between the two.

VoIP threats are seriously overrated

For over a hundred years, the public switched telephone network (PSTN) has gained reputation of stable and secure service. Even though it's neither: it is indeed very hard to bring down a whole telco network, but local outages are not unseen; and wiretapping is somewhat trivial attack - but financial institutions bravely offer phone banking without any additional logon protection. Cordless and mobile phones took PSTN security paradigm to radio spectrum.

Enter Voice over IP. All of a sudden, VoIP Is Scary. We have VoIP vulnerability scanners and SIP firewalls. Consultants and press endlessly warn us about VoIP threats and risks. Some bits are just lovely:

We will also start to see more and more VoIP specific attacks, particularly aimed at the enterprise. There is more and more scrutiny of VoIP systems and attackers will find more issues that are unique to VoIP and the systems that enable it. 

This is one of VoIP security trends for this year, according to Mark Collier, a VoIP security blogger and speaker. I can't help noticing that VoIP can be really replaced with any relatively new but popular technology (XML Web services, AJAX, peer-to-peer networks), and it still going to be a trend for this year. Hackers, you know.  Reminds me of the Cisco's security CTO moronic escapade about Vista.

SPF and Sender ID won't help fighting email abuse

Email abuse - spam and phishing - is a big problem. There are different methods of fighting those. SPF and Sender ID propose standard of authenticating emails using DNS records: owners of certain email domain will publish information about legitimate email servers for that domain, and recipients (that support SPF/Sender ID) will check that information and mark/reject emails that come from wrong source. For example, if IP address of email server that sends emails for example.com is 10.0.0.25, then there will be the following record in the example.com DNS zone:

example.com.    IN    TXT "v=spf1 ip4:10.0.0.25 -all"

The recipient will check if an email that claims being sent by someone@example.com has originated from 10.0.0.25, and will reject if it hasn't. That is overly simplified overview, but gives an idea.

Sender ID will fail. There are several reasons for that:

• It is not clear what is real difference between SPF and Sender ID. Both claim they implement RFC 4406, an experimental Internet standard for email authentication, and its sister RFCs. However, the SPF supporters are trying to distance themselves from Sender ID (read: Microsoft) - without much success (see for yourself), and resulting in added confusion;
• We cannot detect if certian recipient supports Sender ID or not. Because of that, there is no credible measure of Sender ID adoption or efficiency, which results in a worse case of catch 22: people are waiting on other people to adopt the standard, yet they don't know how's that going;
• Spammers don't need to spoof source email address. That may add credibility but ultimately spam relies on the "From:" field and recklessness of the users.

Update on SSL VPN standards

I recently wrote that adopting PPP over SSL as common standard would be the best apporoach to standardasing SSL VPN. I must have been living on Mars: no other than Microsoft is already putting effort right into that!

They call it SSTP - the Secure Socket Tunneling Protocol. Microsoft RRAS team blogs quite a bit about it, and the beta is coming soon. The implementation is coming in Vista SP1 and Longhorn Server. I guess Microsoft will make it a standard in the Forefront Edge security products (next versions of ISA Server and the IAG) too. They should backport the protocol to Windows 2003 and XP. Microsoft won't implement the protocol on Linux and MacOS, but that should be rather trivial; what can delay the implementation is closed beta.

I'll look into testing SSTP ASAP.

Forbes on public Wi-Fi: You Get What You Pay For

Forbes, a respectable business magazine, writes about wireless security in the issue of 26 March 2007:

Computer security firm Authentium in Palm Beach Gardens, Fla. warns about an emerging Wi-Fi fraud aimed at air passengers. What road warriors sitting in a departure lounge think is a free authorized Internet connection turns out to be an "ad hoc" network broadcasting from the laptop of a scamster sitting nearby. Besides collecting passwords and credit card numbers, the crook might even install software that will later forward other private data. One tip-off: The wireless connection window the unwary traveler often sees labels the tainted free site a "computer-to-computer network".

Threats from rogue wireless access points aren't new - I wrote about disabling Windows firewall and exploiting Intranet zone using those a while ago. However, this Forbes article highlights two important problems with communicating technology issues to the businesspeople: wrong assessment and wrong advisory. I am under strong impression that by using executive summary language, consultancies, research companies and the press fail communicating real issues to the decision makers. That's because they often those translating the original information into executive summaries and press releases, often are saying what their audience want them to say - and without much understanding of the information in question. And if quality of the original research is substandard (which I think is the case with Authentium's Wi-Fi alert), the things only get worse.

Another evidence - IDG's PC World's take on the same Wi-Fi issue:

The next time you're at an airport looking for a wireless hot spot, and you see one called "Free Wi-Fi" or a similar name, beware -- you may end up being victimized by the latest hot-spot scam hitting airports across the country.

You could end up being the target of a "man in the middle" attack, in which a hacker is able to steal the information you send over the Internet, including usernames and passwords. And you could also have your files and identity stolen, end up with a spyware-infested PC and have your PC turned into a spam-spewing zombie. The attack could even leave your laptop open to hackers every time you turn it on, by allowing anyone to connect to it without your knowledge.

If you're a Windows Vista user, you're especially susceptible to this attack because of the difficulty in identifying it when using Vista...

The problem is that it's not really a hot spot. Instead, it's an ad hoc, peer-to-peer network, possibly set up as a trap by someone with a laptop nearby. You can use the Internet, because the attacker has set up his PC to let you browse the Internet via his connection. But because you're using his connection, all your traffic goes through his PC, so he can see everything you do online, including all the usernames and passwords you enter for financial and other Web sites.

In addition, because you've directly connected to the attack PC on a peer-to-peer basis, if you've set up your PC to allow file sharing, the attacker can have complete run of your PC, stealing files and data and planting malware on it.

Such a pile of rubbish - as usually, with a twist of Vista-bashing.

Now, let's analyse:

• Positioning the rogue AP attack as happening mostly in airports is wrong. We get those rogue access points everywhere now, the last one I saw in the lobby of Westin hotel in Seattle. Municipal Wi-Fi projects will set expectation for wireless service being available not just in select spots, but in entire business districts;
• Name of the service/access point, or the fact that the service is free, is irrelevant. Title of the article in Forbes - You Get What You Pay For - falsely attributes the attack to free services. In fact, paying customers of T-Mobile access points (found in Starbucks all over the States - I'm using one in SFO airport right now), and other commercial operators, are perfectly susceptible to the attack;
• It's not only computer-to-computer networks that may exploit unsuspecting users - access points are equally dangerous;
• There is no "free authorized Internet connection" that is mentioned by Forbes. The word "authorized" doesn't make sense here.

Keeping your system locked down, and using SSL or VPN for sending credentials and accessing private information will make the man-in-the-middle attack much harder if possible at all - and Vista does help here. I challenge black and white hats of the world to compromise my laptop using a rogue wireless connection. I'm afraid, fixing communications around information security issues will be at least as difficult.

Architecting enterprise for federated identity

InfoCard is the way to go. The concept is very well engineered. It is commonly accepted by various influentials of the IT industry, and some other industries (think of showbiz); it has a number of open-source implementations, as well as Microsoft one (known as Windows CardSpace); and Kim Cameron is a legend. The missing layer of the Internet - the identity - is now found.

So where are the adopters?

Today, there aren't any of importance (measured by monetary value). The reason is the enterprises, and their ways of architecting their systems. There are two issues - actually, two sides of the same problem:

• Enterprises are designing their identity management systems and applications assuming they will be in full control of the client identity; and
• Application service providers are not ready to accept identity assertions issued by other parties - instead, they issue their own, sometimes providing limited delegation.

When talking about the application service providers (commonly referred to as just ASPs), I don't mean it in the pure dot-com sense. Taking into account various B2B scenarios, there are much more ASPs than most of you think - in reality, most enterprises provide access to their applications to other parties.

And we have a problem right there. If I'm an organisation that is using a 3rd-party application for my staff and customers, I still need to be in control of their access to the application. If I give access to a 3rd-party, I want a way that allows that party to manage their access the way they do that, and I don't want to carry the burden of co-managing and supporting access control for other organisations. InfoCard solves the problem. Enterprise applications and identity management systems should be designed for the Identity Metasystem.

They aren't yet. Enterprise architects must adopt the new paradigm, ditch few utopian concepts (i.e., single customer view) in process, and actively confront empire building and control freakdom that plague enterprises today. The outcome is worth it. Think of simplified B2B relationships and acquisitions. Think of new ways of doing outsourcing.

Support from big names is needed. Big business looks at Oracle and SAP to make the first step and make their products (and, not less important, hosted solution offerings) compatible with InfoCard. Microsoft has to walk the talk and start offering support in the server and business software (I'll be looking at the Intelligent Application Gateway and Hosted Messaging and Collaboration and CRM solutions). And those offering identity management solutions - Microsoft, IBM, Sun, BMC - should also provide support.

But for now we have a catch 22 situation - everybody's waiting for everybody else. Well, Microsoft is in front again, but that's clearly not enough. Alternatives to the Identity Metasystem look solid - just like SNA looked good compared to TCP/IP some 25 years ago (scalable, secure and supporting QoS - yet mainframe is required). Alas, you'll be making a mistake if your solution isn't compatible with the Identity Metasystem today.

Why a 127-character long password is not necessarily stronger than a 4-character long password

The title of this posting comes from Marcus Murray's blog. Marcus blogged in great detail about the NTLM issue that I've mentioned before. He also pointed out that I was mistaken referring to the hash in question as NTLMv2 hash - v2 applies to session security protocol but not to the hash. My bad.

Just to re-iterate the effects of possibility of using NTLM hash instead of the user name/password combination:

• There's no need to brute force your password - throw away your rainbow tables, you only need the hash;
• The Great Debates: Pass Phrases vs. Passwords are over - none is good, as the weakest link is  elsewhere;
• All those people who over years asked thousands of times how to disable NTLM and become Kerberos-only environment, had a bloody good reason; and
• Securing the enterprise against targeted attacks suddenly becomes much harder, as we must pay special attention to pretty much all logon scenarios and make sure the environment is safe.

Now we're in position to discuss if the NTLM issue is, well, an issue. Mark Russinovich quickly pointed out that full control over an "attack base" workstation (or server) is required in order to compromise the domain accounts, and that is the main issue. Here's two reasons why this isn't a good response:

1. Trivial: in most enterprise environments, workstations are extremely easy to compromise - SOE integrity checks are basic to non-existant, and forensic capability is limited;
2. And another one: not necessarily one should compromise a tightly controlled domain member in order to get NTLM hash - they might as well ask nicely from a Web server etc. (I will experiment with different scenarios and report back).

So Microsoft shouldn't brush off this one as a non-issue.

I had a great discussion with Shauna Kelly, a Microsoft Word MVP, about security of NTLM enviironments (our government in particular). She asked couple of great questions. For example - are there any bad guys who are doing this? The answer is - I don't know, and we mustn't assume there aren't. And - if current encryption systems are okay? Bitlocker, and Office password protection are good; EFS - it depends: EFS soft keys are a part of user profile that's available using NTLM, thus only smart cards are good.

I'm not overreacting. Will keep posted.

The weakest link

Windows provides the best platform for security solutions. So I said.

Now, let's imagine the perfectly secure enterprise. Everyone is using smart cards to log on to the systems - user passwords aren't used at all. AD, Kerberos and SSL where applicable. What can go wrong?

A lot. Because backward compatibility is a big issue. For example, you are a smartcard-only Windows user. You don't use a password - but you still have a password. Really long and random - if you get a NTLMv2 hash and try to brute force it, you are likely to come across a collision before getting the true password (pure speculation on my side). But NTLM (v2 - whatever) still exists in this ecosystem. It may be used in remote administration and service account scenarios.

Marcus Murray, a security MVP, and his colleagues of Sweden's Truesec, came up with a spectacular technique of using NTLM hashes instead of logon credentials in NTLM-based environment (which is every Windows environment, for now). Here's a video of the attack. Marcus is blogging - in English - about the attack as I type this.

So opportunity is there. All that is required is owning (as in: 0wn1ng, or having local system-equivalent rights) a workstation in an enterprise, and getting a privileged domain user, or a domain service account, to log on to the workstation - and then I can account of those, with all the privilege, in the entire domain.

There are ways to mitigate the risk. You can make it really hard to compromise a workstation - full disc encryption is a very good first step. You can limit the scenarios of remote logons to the workstations - using technology and process.

But the right approach would be phasing out NTLM. Mark Russinovich of Sysinternals fame, a MS Technical Fellow, told me they are working on that but couldn't provide details. Just like we can disable LM and NTLM, we should be able to do same with NTLMv2. I guess it's possible to create a rootkit that will do just that - but we want that coming from Microsoft. Something to do in Windows "7". Generally, it's a good idea to include backward compatibility as a feature. But software vendors should provide an option to turn off legacy protocols.  As long as we are in control and can to testing and plan migration, that would be the right balance.

Wireless security... What?

This is getting ridiculous: an Internet search on "wireless security" returns over a million results, while "wired security" is fetching much less, and the results aren't much to do with transmission of data over networks.

There is no difference in wireless and non-wireless security. Layer 1 of the OSI model - the Physical - is in question. Anyone who assumes their physical layer is secured (e.g. no one can wiretap etc) should ask themselves a question - what makes them so sure? It is not a trivial task to locate a wireless bridge opening the network to external connections; it takes much more effort and sometimes very sophisticated electronics to find wire taps.

You should design infrastructure and applications as they were residing on public Internet. Saves a lot of grief further down the road.

Back to wireless security. They have some good ideas, like 802.11i - the security suite that requires endpoint authentication and encrypts traffic to the access point - however, that just highlights the fact that corporate switching and routing infrastructure too often is considered secure. What really makes a difference is wide adoption of secure configurations of wireless networks. Therefore it's time to shift the emphasis from wireless back to OSI levels 2 to 7.

Release Windows Vista Service Pack 2 now!

I'm surrounded by Microsofties right now. While at it, I have a serious thing to ask: Microsoft, please, release Vista Service Pack 2 ASAP!

 Too many people are waiting for it - even to start looking at Vista. So give them what they want:

• A 500MB+ download;
• Must break something (I suggest FoxPro 2.5 applications); and
• Changes the version strings and adds an obscure but useful utility.

That will remove the biggest obstacle for Vista adoption. I let Microsoft figure out an excuse for skipping SP1.

Mobile banking is a bad idea

New mobile banking products are rolled out every so often. The latest example is www.takeyourbankwithyou.co.nz. That's a Java applet that Kiwis are to download on their Java-compatible mobile phones (but not BlackBerry handhelds; and not Windows Mobile devices) to manage their accounts at National Bank of New Zealand.

Someone's not getting the signal. WAP's dramatic failure wasn't enough. Just to remind you: WAP (Wireless Application Protocol) was was a protocol similar to HTTP, using a cut-down version of HTML (called WML). It was optomised for small-screen, small-bandwidth devices. WAP picked up really well in the devices (e.g. mobile phones) . However, while new WAP services tried to make it to the market. all high-end phones started to support HTML quite well, eliminating the need for WAP (the other part of the mobile phone market doesn't need much but voice calls and perhaps SMS).

So WAP has been doomed. However, ideas of special services designed for mobile devices with special features - those different from general-purpose PCs - are still popping up every now and again. Even after Apple's iPhone presentation, which point was to show that the general-purpose Web browsers will make it to the phone.

So enterprise architects and business people - please, stop designing something for my mobile phone. Just make sure that your Web application works on a smaller (not that small) screen. And doesn't require separate user registration.

A new cult of personality

Inspired by Qantas inflight entertainment.

Devil Wears Prada is about a despotic CEO who turns out to be kinda cool - after transforming somebody to someone else, more to her standards.

The Queen is not about a CEO. Well, not only. It's about a chairwoman who is detached from what's going on in her organisation (having only a limited exposure through senior management) and tries to get to terms with the CEO. Tony Blair in the movie looks more like Nicolas Sarközy today - I wonder if the authors plan a sequel.

Anyhow the micro cults are all over the place, fueled by the media. Linus Torvalds doesn't play the cool CEO game, and suddenly he doesn't matter. Meanwhile, Eric Schmidt, a hired suit who presided over chain of failures at Novell and Sun, suddenly becomes a visionary. That is really stupid.

Readers who are current or aspiring CxOs - please don't take it personally. There's nothing wrong with your aspirations or achievements as such. Plus, I have an ultra-excuse: I'm very jet lagged.

[Q] IP-connected fire alarm bell?

Can anyone please recommend me a decent Ethernet/Wi-Fi and IP-connected fire alarm bell? Something that looks like this:

- and is easily... invoked from Windows and Linux scripts? 

Tomorrow's firewalls

As today's enterprise firewalls are rubbish, what would be the right firewall solution?

Here's how it will look like:

• No deny rules;
• Source are users and groups that are allowed access - no IP addresses, since those are not relevant;
• Destinations are applications and groups of applications (defined via XML properties of the Web service in most cases).

The most secure modern OS, Part II

Part I was about the OS with zero known vulnerabilities and no real trend towards worse situation. Mind you, source code for that OS's kernel is available, so it must be really hard target indeed.

My next favourite provides the best platform for security solutions - standards support, rich set of APIs that make integration an easy task, and an excellent sofware stack on top of that as a proof.

The OS in question is Windows. I haven't seen better support for security yet. there are attempts. I've come across this one (on Slashdot, of all places), which is rather impressive:

I believe I have one of the most advanced LDAP/Kerberos/Samba/Bind "Open Directory" setups. I have two Samba 3 Domain Controllers, both Kerberos and Bind Enabled. with OpenLDAP and MIT Kerberos. I have no
need for NFS.

My OpenLDAP stores:

POSIX User Attributes
Samba User Attributes
Radius User Attributes
eGroupware User Attributes (Egroupware accounts.)
DNS Information for our internal DNS Server
DHCP Lease information.

I use Kerberos with ssh-agent to distribute software RPMS for Mandriva Linux to mass distibute RPMs with a single command.

I have Samba Kerberos enabled so that Samba will not repeatedly ask for usernames and passwords, and requires zero configuration.

I have had the code to Egroupware modified so that eGroupware, and Nagios can use Apache's mod_auth_kerb addon to authenticate eGroupware users with a single click instead of a whole second login process.

I'm currently workong on creating a Samba Authenticated gateway with NTLM-SPNEGO support so that kerberos will handle Squid too.

All I need now is for someone to make the modifications nesessary to eGroupware's XMLRPC so that Kontact could use Kerberos and I would have the "Exchange Killer" I always wanted.

All of my users use Samba for network browsing under KDE's Konqueror, with Kerberos and LDAP, it just works.

I consider this my shining accomplishment. I like to have myself believe that I accomplished "Active Direrctory" under Linux now. I don't use Windows at all in this network, so keep that in mind. The eGroupware people can attest to what a past I am. bugging them to include Kerberos detection in session management. But it all works.

That is rather impressive. As a qualified Linux engineer, I can attest the big scale of assembly required to achieve this.

Which is exactly my point. On Windows, I'm used to similar kind of setup since 2000. Plus, we have robust smart card support integrated with Kerberos. Pluse, we use IPsec in transport mode - also with Kerberos authentication. All within the reach of an average MCSE. Life is good. Windows is by far the best security platform.

Standards for SSL VPN - available, but not accepted

PPTP, IPsec and L2TP are long-established standards for virtual private networking. And they aren't good enough. The reason is simple: when planning connectivity, allow it through authenticating HTTP proxies. That explains the need for SSL VPN as a mean of user-friendly connectivity.

But why SSL VPNs aren't considered a way to connect multiple sites within a organisation? A part of the issue is lack of the standards for SSL VPNs - and no interoperablity between different implementations.

What is the best candidate for the standard? In my opinion, that's PPP over SSL. The point to point protocol is widely available, widely adopted and there's nothing apparently wrong with it - therefore it exists without major makeover for many years (it had bumpy start in early nineties but easily took over SLIP as supporting not only IP over serial lines).

And it turns out that the standard is adopted by at least one major VPN vendor - F5. Here's how to connect pppd to F5 FirePass SSL VPN (and a discussion of implications).

Full DIY solution not involving FirePass as a server is also available. You need Linux (or another UNIX-like system running pppd) and Stunnel (which should be a part of any security professional toolkit). The guidelines can be found here - and don't forget to patch Stunnel to support HTTP proxies).

A big thing that is missing from the DIY solution is actually Windows support. There is no pppd for Windows, and Windows PPP implementation doesn't allow things like redirecting to terminals. How sad.

I should have added something about Microsoft SSL VPN but today the gigabyte download threw a CRC error unpacking virtual machine image at me (the virtual machine-based demo kit is available here). However, the requirement to install a Socket Forwarding component on Linux and MacOS X clients doesn't give me much optimism - likely, we are dealing with (not) good old port redirection. I understand that requirement to run a non-SSL VPN over VPN (that doesn't work with port forwarding but works over PPP) might be considered very strange, but it's real in some organisations. Remember, VPN itself is IP-over-IP solution.

Looking at proliferation of iPod and BlackBerry, one might think - what's real value of open standards? I might be a little old-fashioned but I'd prefer to have an option to create interoperable solutions using multiple platforms. So common standards for SSL VPN supported by multiple vendors would help.

Compromising desktop single sign-on

Desktop single sign-on systems allow using your primary (i.e. Windows) logon to provide access to legacy/alien applications (i.e. mainframe green screens) by caching credentials securely and supplying those automatically on behalf of the users. They also allow enterprise administrators to assign credentials to the users so that they don't even know their TN3270 logons and such.

Examples of the products I'm talking about are ActivIdentity SecureLogin SSO and BMC Enterprise Single Sign-On. And the vendors are pitching their solutions as the ways to achieve regulatory compliance. For example:

GLBA (Gramm-Leach-Bliley Act, a US law mandating financial institutions to maintain consumer privacy - SP) requires financial institutions to employ extensive physical, electronic, and procedural controls to protect customers’ personally identifiable financial data. This is essential in light of the rapid growth of online services, such as paying bills, transferring funds, and trading stocks.
One of the easiest, fastest and most effective technologies to institute and document compliance is Enterprise Single Sign-On. Financial applications are often not properly locked down – many users are under one account. Financial institutions and their service providers need to assure that applications are password protected in order to prevent improper access. Sometimes many users share one password, but GLBA mandates an audit trail. One password would make it difficult to track usage and culpability. Users need individual passwords with strict selection criteria to make it more difficult for the criminal to gain access. Passwords should be changed regularly to keep systems secure.

Single sign-on makes it easy for every user to start every computerized session with proper authentication. The result is simple to use security combined with verified privacy. Audit trails facilitate accountability for personally identifiable information usage.

So we have a crappy application, but this new system hides the logon from the users and requires them to log on - with individual complex passwords, or even smart cards - and offers audit trail.

Do you see a problem? To me, it's obvious. The old and insecure application is still there, fully accessible by the users (thus SSO). What if I want to avoid audit trail provided by the SSO solution? I need to find out what my legacy credentials are. The TN3270 password that SSO system sends to the host on my behalf. How do I do that? I can always capture network traffic and recover passwords in clear. But what if the password is sent over SSL or SSH?

I'll spoof the target then. That is, I'll change the network environment so that the URL, or the host name will point not to a legitimate system but to something that I control - running TN3270 server, or SSH daemon; I'll mimic the prompts and the dialog boxes too. Chances are, the SSO system doesn't verify trust (SSL cert, SSH key) - it will imply that the user does that. It will send password to the host that I control. Done. I have user name, password and the application - all available to me and accessible without the SSO system and its audit trail.

Which means we need to know what issues SSO will fix for us and what it doesn't. Fixing insecure applications is a better approach to security. Just very expensive sometimes.

I must note that this is pure speculation (regarding the products mentioned) and it will be couple of months at least until I prove myself right or wrong. I feel rather confident though - I have seen too many issues with implicit trust (I've written about it before).

Analysing phishing white noise

Phishing is a big problem, and it grows in both volume and sophistication. Nothing new. The sky is falling. You've been warned.

There's one thing that was bothering me for a while: why the absolute majority (at least four out of five) of the phish that I receive in my personal mailbox appears to be from Fifth Third Bank, an American financial institution?

There's only one logical explanation of that: stupidity of the perpetrators.

This is what happens: they become a part of a illegal get-rich-quick scheme. They pay money to people who claim fortune from phishing and ready to share the technique for a small fee. They receive a kit that contains a ready to use phishing Web site (the Fifth Third bank) and the instruction. They use it as is, without modifications. They have not much luck phishing, and they start to resell the kit.

Cybercrime underworld isn't much different from the traditional criminal worlds. It's full of deception. Go to any hangout of the cybercriminals (i.e. www.carder.info) and you'll observe a toxic place with a bunch of sad liars who try to get a buck from each other and aspiring criminals as much as they want to defraud naïve Internet users.

And financial outcome of phishing won't be that great. In Freakonomics, Steven D. Levitt and Stephen J. Dubner ask a question - why do drug dealers still live with their moms? - and give the answer. Phishers are officially into the high tech crime, but the outcome won't be much different. The phishing white noise is the proof.