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.

I don’t usually post about newly-discovered vulnerabilities, simply because there are so many of them — a dozen come out every day, especially in web applications.  However, this one has further-reaching consequences.  Security researcher HD Moore (of Metasploit fame) has discovered a vulnerability in the OpenSSL cryptographic random number generator used by Debian Linux, the widely-used distribution on which Ubuntu is based.  As I have discussed before, flaws in the RNG underlying a cryptosystem can compromise the entire system — both block ciphers and public-key systems rely on a source of entropy to create the large numbers they work with.  If the bits of entropy in this source is smaller than the key length, a “back door” is created — instead of cracking the key, you essentially “crack” the RNG, by trying all the possible seeds and seeing which one produces the key you need.

In this case, the result of this OpenSSL bug (an erroneous “bug fix” made in 2006) is to reduce the entropy in the seed to only 15 bits — a terribly small number (32,768) in cryptographic terms.  Moore was able to produce all the possible SSH keys that could be generated on this system in a matter of hours, save for those few people using 8192-bit RSA keys (and he’ll have those in a few days, too.  He’s placed them all on his website for download.

So what are the implications of this?  The most important one is SSH authorized keys.  SSH is the secure replacement for Telnet and FTP; security-conscious administrators and users use it instead of older protocols.  SSH has an option wherein instead of using a password to log in, you can save a set of keys in your user account, so that when you connect to another server the keys automatically authenticate you.  It’s quick, convenient, and generally more secure than passwords — and thus secures the most sensitive accounts (such as root) on almost all Linux-based servers.  With this exploit, it goes from being more secure than passwords to being much less secure — 32,768 guesses and you’re sure to get the right one.  This can be automated in a couple of hours if there is no lockout on the target machine (and the root account is normally not protected by a lockout since doing so means that an attacker can intentionally lock out the legitimate administrators.)  You could even use this as a local attack — log into your webhost account and run a script that will shortly give you root access to the server (from which you will have root access to most of the other servers at the hosting provider, too.)  Moore’s website includes a couple of scripts that can easily do this.

The nasty part about this is that keys are sticky.  Upgrading your Debian/Ubuntu servers to fix the bug is, of course, required.  However, also necessary is to replace every key generated on a Debian-based machine in the last two years (since 5/2/2006.)  It’s quite a task for administrators to even find all of those keys.  The first step is that if you use SSH to or from a Debian system, you need to immediately delete your authorized_keys and generate new sets (after applying the patch for this bug, of course.)  After that, it’s important to make sure all your users do the same.  Purging the SSH keys of all the users is not going to be a painless process and will undoubtedly involve some support cost, but keep in mind that not doing so is the equivalent of having all your users using 3-character lowercase alphabetic passwords.

The harder problem, though, is this: this bug isn’t really in SSH, it’s in the OpenSSL libraries.  These are commonly used by all sorts of apps to generate keys — OpenSSL is practically the Linux equivalent of CryptoAPI/DPAPI on Windows.  Everything uses them.  Essentially, every key generated on a Debian-based system for any purpose whatsoever in the last two years is potentially vulnerable.  You won’t be able to use HD Moore’s linked scripts to crack these, but they are all potentially cryptographically feasible now.  This is a major breach; if the NSA didn’t already know about this vulnerability (which I wouldn’t rule out), they’re no doubt engaging in a flurry of excited codebreaking right this minute.

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.

Hackers love wireless networking. At DefCon 15, it was easy to predict which sessions would have lines running out the door and require getting there well in advance for a seat - it was the sessions with “wireless” or “Wi-Fi” in the title. The Wireless Village was very popular, and many of the hacking contests involved wireless access points.Why do hackers love wireless networks? Really, there are two reasons, and those two together have some scary implications for risk on the modern Internet.

1.) Wireless Networks Use Shared Media

Back in the 80’s and 90’s, most wired Ethernet networks were based on shared media topologies. In principle, when you plugged into an Ethernet network and sent a packet, the packet on the wire (the actual electrical impulses) went to every other machine on the network. Hubs were simple repeaters, broadcasting everything they received. Only when your signals reached the router at the Internet edge were they actually intelligently processed. Thus, every computer on the LAN got every packet - the network cards just threw away any packets whose destination address specified another computer. However, a hacker wanting to eavesdrop on others had an easy job - just toggle the network card into “promiscuous mode” (a hard task on some network cards and OSs, but completely trivial on others) and it will receive every packet, giving you a god’s-eye view into the network. Protocols were mostly unencrypted then, too - so you saw everyone’s email, their paswords as they logged into Telnet or IMAP, etc. You could also spoof traffic - since you saw the packets sent by others, you could simply send responses back claiming to be the recipient. So long as your response arrived before the real one, yours would be accepted and the actual response discarded as out of sequence. It was the golden age of network-protocol hacking. Such easy access to passwords made other types of hacking easy, too - once you had the password to someone’s UNIX account or email box, there was a very good chance it would work on all their other accounts, too.

Then it all changed. Shared media has significant disadvantages as it scales - since everyone is dumping packets onto what essentially amounts to a single wire, collisions occur when two systems transmit simultaneously. Both then have to back off, slow down, and retransmit their garbled packets. The packets are tiny (Ethernet frames are normally restricted to 1500 bytes or less), but if you have 100 systems communicating at once, collisions can become quite frequent. Plus, even in the late 90’s people were not totally unaware of the security risks - the fact that any student could read all the network traffic of everyone else in their dorm was not considered desirable by universities, for instance. Thus, Ethernet was converted over to switched media. Switches, unlike hubs, do not treat all ports as equal. Instead, they remember which ports they have received traffic from an address on, and only forward traffic to an address to those ports. Traffic is only broadcast to all ports when a switch has no idea for which port it is intended, or when a packet is actually marked as a broadcast. Now, when you put your Ethernet card in promiscuous mode, all you hear is traffic meant for you - everything else has been blocked by the switch. Suddenly, packet sniffers went dead - there was nothing to see anymore. Ethernet became a lot more secure.

But wireless changes things again. Wireless networks are shared media, and they are shared inherently, in a way that cannot be changed. Radio waves fly in all directions. There is no way for your laptop to transmit only to another laptop or an access point - all radio is broadcast. Thus, when you sit down in a coffee shop and turn on wireless, you begin broadcasting everything to everyone within range (about a mile, for attackers who have good antennas and high-power network cards.) The shared media nature can be mitigated somewhat via cryptography - if all the traffic to the access point is encrypted, it hardly matters if someone can eavesdrop since they can’t understand it anyway. But open access points are, by their nature, open - they’re either not encrypted at all, or they’re encrypted in such a way that everyone is using the same key. Once the hacker has the key (either by cracking it, which is not hard on most Wi-Fi networks, or by simply paying as a legitimate user of the wireless hotspot), they can read all the traffic just like in the hub-based glory days of old.

There are solid wireless encryption systems. A network based on WPA2 with a strong passcode is quite secure, about as good as a wired connection (keeping in mind that “as good as a wired connection” is not an absolute guarantee of safety, either.) Modern encryption systems like AES coupled with 802.1x certificate-based authentication can make a well-engineered corporate wireless LAN quite safe.

But hackers don’t love well-engineered corporate wireless LANs. They love the terrible ones in coffee shops and bookstores and your house. On these networks, they can listen to all traffic, they can spoof traffic, and they can even kick people off and hijack their connections, or edit their connections on the fly. The “airpwn” attack from a DefCon 2-4 years ago was particularly amusing; using two wireless cards, it would sniff everyone’s HTTP traffic on one connection, then on the other card spoof responses to all requests for images, substituting other images (such as the hacker group’s logo, or more unsavory fare like the infamous goatse.cx site; that is not a hyperlink on purpose, do not navigate to that URL as it is not safe for work or, indeed, for anywhere else.) The result was that one laptop at a security conference was able to dynamically edit the HTTP streams of everyone else there - hundreds of people. That’s the kind of power a hacker can have on a shared-media network. In addition, on these sorts of networks, it’s trivially easy to hijack sessions. This means that on any site that uses HTTPS for authentication only, but then HTTP for the actual service (a category that includes all of the Google apps like GMail, as well as all the Yahoo! and Windows Live services), a hacker gains full access to your account if they overhear any of your wireless traffic.

The only truly safe way to use a public wireless hotspot is to use it only to VPN to a network you trust. Anything else is dangerous.

2.) Wireless Networks Provide Plausible Deniability

The legal system is not terribly friendly to hackers. Even innocuous and non-destructive activity, when applied to networks you don’t own, is often illegal. Now, for the most part hackers don’t worry overmuch about getting caught - if you don’t cause more than $5,000 in damages, the FBI won’t get involved, and the average local police department is about as capable of investigating sorcery as computer crime. However, when a hacker does worry about legal prosecution, a public wireless network is the next best thing to Siberia for where to commit a crime from.

When you do anything on the Internet, a host of servers are recording your activity based on your IP address. IP address, however, is not necessarily long-lived. Depending on how you access the Internet, your IP address might change every time you plug your computer in, or reboot, or move from building to building. Thus, investigators must be able to tie the IP address they know committed a crime to a specific, physical person.

With wireless, this is a problem. All the sites being attacked don’t see the IP address of the hacker - they see the IP address of the wireless access point. Thus, they have to subpoena the owner of the access point and demand to know who was using it. In the case of a well-designed corporate wireless LAN, they can check their logs to see which 802.1x certificate was using that IP at that time, and uniquely identify you. But in the case of a public hotspot, there probably aren’t any logs at all! They’re completely incapable of giving you up. And even should someone who was there say “I saw a shifty guy in the corner using a laptop!” to the police, that’s not going to be enough evidence. And if there are logs, they will tie your traffic to your MAC address, a unique code assigned to your network card at the factory.

Most people think MAC addresses cannot be changed, so it uniquely identifies your network card. If the police get a hold of your network card, they’ve caught you. This is actually totally untrue. Many network cards will allow you to change the MAC address to whatever you want (in Windows, it’s on Connection Properties -> Configure -> Advanced -> Physical Address), though this is entirely up to the network driver. Many Windows drivers block this functionality, thinking that users don’t need it. On Linux, however, the network drivers have been written by geeks, who operate under the impression that users need everything. Thus, on Linux systems changing your MAC address is as simple as typing one command (”macchanger eth0 00:11:22:33:44:55″), and you can even configure the network stack to give you a new, random MAC address every time you connect to a network.

As a result, a trail that leads to a wireless hotspot is basically a dead end for investigators. They get nothing but a fake MAC address that could correspond to any computer within a 1-mile radius - the hacker might not have even been in the building. Hard to get “beyond a reasonable doubt” out of that.

And those are why hackers love wireless networking. It’s like the 80’s phone networks, where a hacker can be a ghost in the machine, undetectable, and with tremendous power. It’s a dangerous place.

You might wonder, if wireless networks are so anonymous, how hackers ever get caught. Actually, there are three main ways:

1. They get stupid, and brag about what they did.
2. They get stupid, and while performing their illegal activities they also do something that identifies them, like log into their email account.
3. Investigators follow the money. We don’t catch you breaking into the bank, we see where you sent the money to. We don’t catch you stealing credit card numbers, we catch you using them.

Luckily for those of us in the business of investigating and preventing computer crime, wireless networks won’t save criminals from their own stupidity, and you can’t send cash through the airwaves.

Windows file sharing operates via an old protocol called SMB (Server Message Block.) In modern Windows operating systems, it operates over TCP/445, though older versions of Windows also made use of NetBIOS (UDP/137, UDP/138, and TCP/139). Due to the ubiquity of Windows file shares on corporate Intranets, in general these ports are open to basically everyone on the internal network, though they are blocked at edge firewalls. Even UNIX/Linux machines often use these ports, due to a Windows-file-sharing-compatibility package called SaMBa.

There have been many security vulnerabilities in NetBIOS in the past, and some in SMB, so these protocols are (rightly) considered moderately risky by network administrators. However, scarier than any of these patched vulnerabilities is the flaw in the design — SMB is subject to a sort of replay attack, called SMB Relay or SMB Reflection.

SMB at first appears safe from replay attacks. After all, it uses challenge-response authentication (normally; there is a protocol for SMB with cleartext, but basically no client or server will accept this protocol now), whose whole purpose is to prevent eavesdropping and relay. If you try to replay the same response to a server, it won’t work, because the challenge is different. There are three ways SMB allows challenge-response authentication — LANMAN, NTLM, and two-way NTLM. In any case, the principle is the same — the client asks to authenticate, the server sends a challenge, the client encrypts the challenge with a password, and sends the encrypted result as a response.

So how do you perform a replay attack on SMB? Via SMB Relay (to attack another host) or SMB Reflection (to attack the client.) It goes like this:

1. Client (C) connects to you (a malicious server, M) and asks for a challenge.
2. M connects to C in a separate sessions and asks for a challenge. It still has the connection from (1) on hold, having not responded yet.
3. C receives the request from M, and responds with a challenge (challenge_C).
4. M takes challenge_C, modifies it to appear to be coming from M (challenge_M), and responds to the connection from (1) with it.
5. C finally receives the challenge (challenge_M) that it asks for. It uses its credentials to respond to it (response_M).
6. M receives response_M, which is correct for challenge_M, and so grants C the access it requested. Of course, this response also matches up with the challenge it’s holding onto (challenge_C). It forwards it right back to C as response_C.
7. C receives response_C, which is correct for challenge_C, and so grants M the access it requested.

No, C doesn’t ever realize that it just received and responded to the challenge that it, itself, sent out moments before. By requesting access to M, I have unwittingly given it all it needs to authenticate against me at the same time. It can’t be carried out later — the reflection attack has to happen at the moment I am trying to connect.

Note that this is a design flaw — there’s no “bug” to patch here (I suppose Microsoft could modify SMB to ensure that it’s not responding to its own challenges; it would be possible but not trivial), this is the behavior of SMB since time immemorial. No buffer overrun is exploited; SMB is acting precisely as it’s intended to. This issue has been known since 2001.

Host firewalls like Windows Firewall and ZoneAlarm help some — at least, they keep SMB Reflection attacks out. However, they don’t help if the attack is coming from a zone you trust — i.e. if you’re sharing files with your corporate Intranet, someone on the corporate Intranet can attack you this way if you try to authenticate against them. And it also doesn’t stop SMB Relay – if I connect to M with my firewall up, he can’t use reflection to attack me, but he can relay to yet another host and impersonate me, passing me its challenge and relaying my response to the remote host.

It actually gets a bit worse than this, because the NTLM package used to authenticate SMB is the same one used to authenticate you against Intranet websites in Internet Explorer. The attacker might not need to get you to try to make a file-share connection to him; a web connection can be sufficient.

This attack sounds relatively tricky to carry out, and it is… by hand. However, the ever-popular Metasploit Framework contains an SMB Relay module (which also works for SMB Reflection) that makes it quite quick and easy (you need the live-tree version of Metasploit out of CVS, not the release build, as the module is relatively new and was just demonstrated at Defcon 15 this August.) You do have to disable SMB on your computer to use it, though (which is simple on Linux, but on Windows involves unbinding the Server service.)

This makes SMB reflection trivial. You load the module, tell it your IP address, load your choice of many payloads (such as having a shell started and passed to you, or simply having an SMB connection opened that you can do with as you will), and then wait for someone to connect to you. You can either specify a target server if you want SMB Relay, or leave that unspecified for an SMB Reflection back to the person connecting. The only thing Metasploit won’t do for you is make people connect to you.

So the moral of the story is apparently to be careful who you connect to, especially on local networks where your file-sharing ports are open. That’s a pretty good moral in general… but it’s really not enough. People who run Windows Firewall often have a blanket exception for File & Printer Sharing, which opens port TCP/445… if you’re not behind a home firewall or router, this sort of attack may be able to be carried out on you from any site on the Internet. And tomorrow, I’ll be talking about why nothing of any kind is ever safe on a public wireless hotspot.

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.

A company called Elcomsoft has just put out a press release promoting the newest version of their Distributed Password Recovery tool, which is now capable of making use of the GPU (graphics processing unit) on modern 3D video cards for breaking password hashes.

Password hashes have been weak for quite a while now — as far back as 1997, it was practical, if you got a hold of the SAM hive from a Windows machine or the shadow file from a UNIX machine, to brute-force crack the passwords stored inside so long as they were relatively short and didn’t make use of obscure characters (hence all those “password complexity” guidelines urging you to use long, incomprehensible passwords.) However, at this point you could usually crack even a strong password in a few weeks using a desktop machine. This development cuts password cracking time by a factor of 20 or more.

Why is the GPU so much better than the CPU for cracking password hashes? Parallelism. Rendering a screen of graphics essentially consists of doing one task — figuring out what color a pixel on the screen should be — many, many times every second. As a result, graphics cards are optimized for doing many simple tasks simultaneously. CPUs, on the other hand, can do one task much faster than a GPU, but only do one thing at a time (multitasking is largely an illusion, as the CPU switches between tasks very quickly.) We’re just now seeing dual-core and quad-core CPUs, but a “dual-core GPU” would be nonsensical — they’ve got 10 or more processing pipelines already.

The Elcomsoft software further speeds up password cracking by allowing you to offload processing to many different machines, so each box tries a different section of the keyspace. If you have access to many machines, this can make it a very quick task.

Of course, sometimes you don’t need to go through this much work to crack a password. For any Windows password 14 characters or shorter, you can already crack it in seconds with a rainbow table attack. There are even online services that will do it for you for a small fee — you input the hash and PayPal a few bucks to them, they give you the password; if you’re willing to spend a few days on BitTorrent getting 64+ GB of data, you can get your own rainbow table for free.

So how do you make a safe password, when a table can crack it in seconds or new software in days, no matter how good it is? You don’t. There is basically no such thing as a strong password anymore — there is the total insecurity of having no password, or the moderate security of having a password. If someone manages to break into a server that your password works on, they will get your password if they want it. Not re-using passwords on multiple sites and servers is thus quite important if you care about what’s on it (we all use the same password on random registrations on the Internet, but you shouldn’t use that password for banking, too.) However, the only long-term solution to this is two-factor authentication; the password alone just isn’t enough anymore.