There has been a fair amount of controversy as of late surrounding The Race to Zero contest to be unofficially held at DEFCON 16 this coming August. To briefly summarize, contestants are to be given samples of computer viruses/malware and access to a contest portal. The portal will take malware samples submitted by the contestants and run them through a collection of anti-virus engines, checking to see if the samples are detected. The contestants will make modifications to the malware samples in attempts to slip modified samples past the AV engines undetected. In keeping with the mischievous hacker zeitgeist of DEFCON, awards will be given for the “Most Elegant Obfuscation,” “Dirtiest Hack of an Obfuscation,” “Comedy Value” and “Most Deserving of Beer.”

AV vendors were predictably upset by the prospect of this exercise. Most objections seemed to boil down to two main assertions:

1. The contest involves the creation of new strains of malware, which can serve no constructive purpose.
2. The contest will only serve to help the bad guys learn new techniques in their arms race with AV vendors.

Contest organizers have stated their goal is simply to demonstrate the limitations of AV software, information that AV customers deserve to have. Their position is that the contest explores legitimate areas of security research and that investigation of AV bypass techniques is a worthwhile goal. Organizers have also pointed out that new malware is being created 24×7x365 in the wild, while at the contest’s conclusion any new malware samples created will be securely deleted from the contest systems.

I believe the primary arguments against the contest are specious. In order to engineer the effective detection of computer viruses and malware, one first needs to understand how these things function. Creating your own piece of malware will certainly help someone better understand how malware works. It is not at all clear that the creation of a new virus by a security researcher in a controlled environment has no constructive purpose.

There are some valid criticisms of the contest, however. This contest is not truly representative of malware development in the real world. Today’s malware is programmatically generated and engineered to bypass AV detection. Malware authors are no longer manually crafting and testing their creations. The malware ecosystem has moved on to the use of specialized tools for these purposes, written and sold by more highly skilled groups of miscreants.

Despite what the critics are saying, the bad guys are not going to learn anything new from this contest. The groups that develop malware generation kits have gone far beyond the paradigm of hand-crafted AV bypass that is being explored in the contest.

I do believe there are some positives that may come out of this contest. For one, consumers of AV software will gain valuable new insight into AV bypass resistance in a controlled evaluation, albeit a somewhat contrived one. AV software should see improvements as AV vendors that did not fare well feel customer and market demand to improve their products, or face losing business to their competitors. Last but certainly not least, the security research community will learn more about the capabilities and limitations of ubiquitous AV defenses.

My “Race to Zero” prediction? Embarrassing performance from some of the major AV vendors, especially those that haven’t made smart investments in strong heuristic detection mechanisms. Expect these AV vendors to attempt a rear-guard marketing action telling us why we shouldn’t give any credence to the results, followed by some real improvements in future releases of their products.

Last week I attended the RSA Conference, the largest information security conference in the world. Alan Turing was the conference mascot and the question “what would Turing do” was frequently asked. Turing was a brilliant computer scientist, considered the father of modern computing, capable of seeing the math in everything and envisioned an age when machines would be as intelligent as humans. He devised what is known as the Turing test, used to gauge the capabilities of artificial intelligence. We’ve all taken Turing tests, they’re used to guarantee that a human is on the other end of an application or communication stream. For example when you register for a gmail account you see an image that is obfuscated in a way that only humans can decipher, this is called a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). Therefore if the text in the image is read correctly entered there must be a human on the other screen reading it. This is an example of a Turing test.

For more information http://en.wikipedia.org/wiki/Captcha

The theme of the keynote presenters seemed to be a call for information centric security. I think this is appropriate considering they were presenting at a conference hosted by a company that was founded by (and named after) cryptographers who invented the most widely used asymmetric encryption algorithm (RSA) today. Cryptography has always served the purpose of two of the three premises of the information security triad - confidentiality and integrity (the third being availability which, it could be argued, cryptography inhibits). The need to protect information should not obviate the need to continue to protect the infrastructure. We are dependent on the infrastructure for the storage and transit of information and need to protect it.

Compared to last year there appeared to be fewer Network Admission/Access Control (NAC) vendors, fewer Data Loss Prevention (DLP) vendors and fewer Network Behavior Analysis (NBA) vendors. The newest technology based on an old idea is application whitelisting. Application whitelisting changes the logic used by many endpoint security solutions which today allow everything and deny the known bad. Instead application whitelisting denies everything and allows the known good. In an age where more malware is created than legitimate software it makes sense to invert the logic.

For any of you that will be in the Atlanta area, I encourage you to come down to the Outerz0ne 4 security conference this weekend. It’s my first time attending Outerz0ne, but I’m told it has a great small conference atmosphere and plenty of end-of-day revelry. This year’s collection of talks looks to be the strongest yet.

I will be delivering a talk about cross-site scripting worms, looking in depth at the Samy MySpace worm, the Orkut worm, and rsnake’s Diminutive XSS Worm Replication Contest. The talk is being taped by the Outerz0ne organizers and will be available on Google Video some time afterwards.

I hope to see some of ya’ll there!

There is an old saying that says, “To survive a bear attack you don’t have to outrun the bear, you just have to outrun your friend.” This analogy can also be applied, to some degree, to the Internet as well. In some instances, you don’t have to completely secure yourself from hackers, you just have to be more secure than the next organization. Hackers go after low hanging fruit because it gives the most bang for their buck. This year it appears that client side attacks represent that low hanging fruit. The modern web browser is an incredibly complicated piece of software with a large attack surface. Throw on some third party software like ActiveX controls (most of which are chock full of buffer overflows) and you have a hacker’s playground. To make matters worse, all modern day browsers contain JavaScript interpreters which give attackers the ability to obfuscate their attacks in an infinite number of ways. Luckily there is a method for users to fight back against the majority of these JavaScript- based attacks: No Script (Firefox) and Trusted Sites (Internet Explorer).

These methods take the same approach to security: Enumerating the good. Instead of playing whack-a-mole with all the new type of attacks that appear you allow the list of sites where JavaScript is allowed to come from. To do this with Internet Explorer you must first disable active scripting for web sites in the “Internet” zone and then add trusted commonly access pages to the “Trusted Sites” zone. This change can be done through Active Directory and pushed out to all computers in your organization. To achieve the same effect in Firefox you must install the No Script extension. By default this plug-in will block all JavaScript, java and flash (no more flash ads) content. You can then enable this content on a per page basis or import a list of trusted sites. By using either one of these method you will be able to block the vast majority of browser- based attacks.

NoScript: http://noscript.net/

Using group policy to manage the list of trusted sites: http://support.microsoft.com/kb/816703

Recently, Core Security announced a vulnerability in VMware Workstation (Server and ESX are unaffected) that allows a guest operating system to break out of its virtualized environment and interact with the host operating systems. They discovered it was possible to break out of the virtualized environment by using a directory traversal attack on a shared folder designed to allow data to be passed between the guest operating system(s) and the host operating system. This attack is possible despite attempts to sanitize the path string for dangerous (”..”) characters because the sanitation routine is called before the path string is normalized using a Microsoft library call to convert characters from UTF-8 to UTF-16. It is better practice to normalize a string before sanitizing it for dangerous characters, but the complexity of character encoding has caused other vulnerabilities in the past.

Looking into this vulnerability made me curious about the variety of encoding schemes that are in common use today. I had a basic grasp of ASCII, and knew vaguely about Latin-1 and Unicode, but I didn’t know the kind of in-depth details that are needed in the security world. I decided that in order to really understand the issues involved I would have to go back and learn how various encoding standards were used historically and how we got from them to our most current batch of standards.

It all started with that familiar mainstay of the computer world. ASCII, or the American Standard Code for Information Interchange was first published as an American Standard back in 1963. The standard is only 12 pages long, and the Standard Code itself only described 100 characters filling 7 bits. The first standard didn’t even include lower case letters. The Standard Code was designed for information interchange between such varied devices as punch card reader/writers, tape (perforated and magnetic) machines, telegraphs and other devices. One device that ASCII was not designed for was computer monitors. In the 60’s computer time was much too valuable to use just to display information on a screen to a user. In a statement oddly presaging the legendary quote from Bill Gates about 640k of memory, Appendix A of the ASCII-1963 standard states that “A 7-bit set is the minimum size that will meet requirements” … “Both a 6-bit and 8-bit set were considered and rejected” … “the 8-bit because it provides far more characters than are now needed in general applications.” A later version of ASCII would add lower case letters and would also merge the ASCII standard with ISO-646 (also ECMA-6).

Once the CRT revolution swept the computing industry and we moved away from punch cards and teletypes, people found that there was an extra, unused bit in every byte used to record a character. This led to many different custom “extended ASCII” character sets. IBM’s version used on IBM compatible PCs was probably the most popular of these. Among other things, a primary goal of many of these extensions was to provide accented characters that are used in other Latin script based languages other than English.

In order to have a better way to represent a larger number of languages, the ISO developed the ISO-8859 standard. The ISO-8859 standard defines 15 different character sets designed to be used to represent different language groups, each ISO-8559 character is encoded in one byte, so there are 256 possible characters. The most commonly used of the ISO-8859 family is ISO-8859-1 (also known as ISO-8559-Latin-1, or just Latin-1). The Latin-1 standard is designed for Western European languages. The ISO-8859-1 standard supports the following languages: Afrikaans, Albanian, Breton, Danish, Dutch, English, Estonian, Faroese, French, Finnish, Galician, German, Icelandic, Irish, Italian, Latin, Luxembourgish, Norwegian, Occitan, Portuguese, Rhaeto-Romanic, Scottish Gaelic, Spanish, Swahili, Swedish, Walloon, Welsh and Basque. Other ISO-8859 standards cover other languages, such as ISO-8859-5 for Cryllic based languages and ISO-8859-8 for the Hebrew language.

In the same way that IBM extended ASCII, the ISO-8859-1 character set consists of the base of the printable ASCII characters in the same position and then additional characters to fill the extra space made available by using the 8th bit. The ISO-8859-1 standard was first published in 1985. The ISO-8859 standards allow a large number of languages to be encoded in one family of standards. This allowed much greater interoperability and standardization between speakers of different languages, but there were still some things that could not be done by these standards, such as capturing if a language is ordered right to left or vice versa. There was also the issue of multi-byte sequences used by symbol based languages. There was a desire to have one universal character encoding system. The desire for this universal character encoding system was so great that there ended up being two universal systems.

The ISO’s solution to these problems was the Universe Character Set, or ISO 10646. This extremely ambitious undertaking planned to create a truly universal character set. With over a million possible characters (earlier drafts had the space for over two million), the goal was to encode every historic, current or future language in one standard. This massive code space is broken up into different planes to simplify things. Almost all commonly used characters inhabit the Basic Multilingual Plane (BMP). But there are other planes for symbol based languages and also a private code space, analogous to RFC 1918 private IP space for imaginary languages. There is even an organization, ConScript, devoted to unofficially sharing this space to make sure every imaginary language has unique code points. With over 130,000 code points allocated to private use, there should be plenty of space for languages like JRR Tolken’s Tengware and Cirth (better known to all but his most die hard fans as Elvish and Dwarish), or not just the expected Klingon, but also Frenghi. I think my favorite of the made up languages is Dr Suess’ extensions to the Latin character set. What’s not to like about a character called ABCDEFGHIJKLMNOPQRSTUVWXYZ?

In addition to the UCS, there was a second universal encoding scheme known as Unicode. Its goals were merely to encode all modern languages, and it was designed to use a smaller 2 byte (64K) character space. Thankfully the two organizations realized that the world didn’t need more than one universal encoding system and has merged the two. Like any merger of two preexisting projects, there have been some complications created, but it’s still probably for the best.

ISO 10646 originally defined two different encoding options for using the UCS. There were UCS-2 and UCS-4, which encoded the UCS in 2 or 4 bytes. However, UCS-2 can use special escape sequences to address characters outside of the Basic Multilingual Plane. One big problem with the UCS encoding is that most common ASCII characters are encoded with leading NULL bytes. This causes all kinds of issues for Unix operating Systems, which traditionally use NULLs to terminate strings.

Unicode was originally designed to be encoded in a simple two byte format known as UTF-16. However, Unicode decided to address the entire Universal Code Space, so it needed a trick to allow UTF-16 to address code space beyond that of a value that can be stored in two bytes. That trick is known as surrogate characters.

Surrogate characters are special two byte values that are used to indicate a four byte character. To ensure compatibility between ISO 10646 and Unicode, surrogate code points have been officially reserved in the UCS code space and will not be used for any other purpose. Surrogate characters solved the problem of allowing what was originally a two byte code to address four bytes worth of address space.

There was another problem with Unicode. A large part of the Unix world was (and still is) based around the concept of one character per byte and binary compatibility with the old ASCII standard. One evening a gentleman named Ken Thompson (whom you may be familiar with for such modest innovations as the B programming language and the UNIX operating system) decided to scribble a better encoding standard on a New Jersey diner placemat. This new standard was called UTF-8 and was a variable length encoding which preserved the original one byte encoding of printable characters from the ASCII set. The entire UCS could be addressed by using up to 6 bytes.

There is also an encoding called UTF-7 which was designed to allow Unicode characters to be used in places ( such as SMTP ) which are required to be 7 bit clean. It is not a Unicode or ISO standard, but did have an RFC devoted to it. Another UTF encoding is UTF-32, which just uses four bytes to represent the code, trading space for simplicity.

We now have quite an assortment of encoding options - ASCII, ISO-8559-1, UCS-2, UCS-4, UTF-7, UTF-8, UTF-16, UTF-32. It gets even more interesting when you add in the World Wide Web. Some regular ASCII characters have special meaning in URLs, so a scheme was developed to encode those in a special way on top of a normal ASCII encoding. This is known as URL encoding and is specified in RFC 1738. In this encoding format a special character is represented by a percent symbol followed by two hex digits, which specify the code of the character that is being represented. For example, a space is represented as %20. But because one standard will never do when you can have two, there is another way to represent characters which aren’t allowed in a URL. The ISO also specifies the Numerical Character Reference as ways to represent characters from the UCS in various markup languages. NCS is a sequence of decimal or hex digits prepended by an ampersand and a hash mark. A literal x follows the hash if the characters are in hexadecimal. Σ, or Σ are examples of NCS encoding. It’s also possible to encode UCS characters using the format by prepending the code point with a %u.

With all these different encoding schemes it’s easy to see how the seemingly simple task of interpreting text can become very complex. Areas of complexity make it hard for programmers to understand exactly what their programs are doing. That lack of understanding leads to vulnerabilities. Until the encoding landscape gets simpler and more robust libraries are commonplace for translating from one encoding scheme to another. Security professionals will have to keep an eye on this area.

Last week something very interesting happened in the IT world. Microsoft made a pledge to open up many of the of the APIs and communication protocols that are used in the Windows OS, SQL Server, Office file formats, Exchange, and others. If this holds true, it marks a big change in the way that they’ve protected their internal data, and that is going create a big stir throughout the IT industry. But, the stir is going to mean different things to different people.

For developers, creating software to interact with Microsoft products, this will provide an incredible source of information, and should lead to much greater interoperability in sharing data between various applications. Soon, there should be more realistic alternatives to the Microsoft giants of Office and Outlook, which are very good at what they do but are pretty heavyweight for a lot of smaller businesses. Samba (a Linux program that works with Windows File and Print Sharing) should also be able to keep current and be much more stable and Feature-rich now that they don’t have to guess/reverse the protocols.

But we are a security company and a security blog, so how does this affect security? Likely, it will affect it negatively in the immediate future. In the short term, the information about protocols and file formats will allow for much easier fuzzing, and there will be some interesting vulnerabilities found in previously unchecked codepaths. Which is great… as long as folks with malicious intents don’t find and exploit them before the good guys can create a fix. In the end though, more open access to this information will lead to more secure software and a better framework for tools to be developed in, but that doesn’t mean it might not be an interesting, if not bumpy year on the security front.

I spent some time this week analyzing the recently disclosed vulnerability in the Linux kernel syscall, vmsplice. Several POC’s have been released and I was curious as to how they exploited the kernel.

Background on the vulnerability: the vmsplice function is a system call that allows a programmer to map an I/O vector (basically, an array of buffers) to a pipe. From the man page:

The vmsplice() system call maps nr_segs ranges of user memory described by iov into a pipe. The file descriptor fd must refer to a pipe.  

The kernel adjudicates the whole transaction, dutifully mapping/copying the user specified memory to the pipe’s buffers or vice versa.

The trouble is that the routine for sys_vmsplice didn’t follow best practices for kernel programming and check the pointers passed from userspace for validity.”  In at least three places in fs/splice.c, data in the user-specified iov array was copied to or from without verifying it’s validity via access_ok().

The exploit I examined only worked on kernel versions 2.6.23 to 2.6.24.1. Rafal Wojtczuk has an excellent write-up on the 2.6.17 and up exploit - you should check it out.

In 2.6.23, code was added to handle copying from the pipe to the user iov.

Unfortunately, there was no check that this destination address was a valid mapping for the user process:

linux/fs/splice.c:
1400/*
1401 * For lack of a better implementation, implement vmsplice() to userspace
1402 * as a simple copy of the pipes pages to the user iov.
1403 */
1404 static long vmsplice_to_user(struct file *file, const struct iovec __user *iov,
1405                             unsigned long nr_segs, unsigned int flags)
1406 {
1407        struct pipe_inode_info *pipe;
1408        struct splice_desc sd;
1409        ssize_t size;
1410        int error;
1411        long ret;
…
1425                /*
1426                 * Get user address base and length for this iovec.
1427                 */
1428                error = get_user(base, &iov->iov_base);
1429                if (unlikely(error))
1430                        break;
1431                error = get_user(len, &iov->iov_len);
1432                if (unlikely(error))
1433                        break;
1434
1435                /*
1436                 * Sanity check this iovec. 0 read succeeds. 1437                 */
1438                if (unlikely(!len))
1439                        break;
1440                if (unlikely(!base)) {
1441                        error = -EFAULT;
1442                        break;
1443                }  

Note that base and len are only checked for being non-zero, rather than the more detailed check performed by access_ok(). Thus, we can pass in values that are unmapped (less useful for exploitation) or are mapped but unwritable.

This later case is what qaaz’s exploit utilizes. By specifying the entry point of another system call (in this case, the rarely used sys_vm86old) as the “base” for copying, qaaz tricks the kernel into overwriting it’s own syscall table:

addr = get_target();
printf(”[+] addr: 0x%lx\n”, addr);

if (pipe(pi) < 0)
      die("pipe", errno);

iov.iov_base = (void *) addr;
iov.iov_len  = TRAMP_SIZE;

write(pi[1], TRAMP_CODE, TRAMP_SIZE);
_vmsplice(pi[0], &iov, 1, 0);

gimmeroot();

Here, get_target() finds the target system call. TRAMP_CODE is a static buffer containing our privilege escalation syscall. gimmeroot() is a macro to invoke the newly overwritten syscall with function to set our process’s UID/GID to root’s:

#define gimmeroot() syscall(TARGET_SYSCALL, 31337, kernel_code, 1, 2, 3, 4) 

You would expect the user process to be terminated for an access violation. After all, it is asking the kernel to write to what should be a protected area of kernel memory. Moreover, kernel memory isn’t usually mapped into a process’s address space. Trying to access it should generate a page fault and subsequent kernel oops, plus a SIGSEGV for the userland process.

However, this is not the case with system calls: they must be mapped in userland as well as kernelspace, since user processes need to call them. This exploit takes advantage of this, as the copy is done with the current process’s memory mappings but with the elevated permissions (and reduced access checks) of running in kernel mode.

There are a number of steps that could be taken to prevent this exploit from working:

1. Obvious: Check user addresses for validity before copying anything to/from them.

2. Protect certain chunks of kernel memory from being overwritten after it’s initial load. Unfortunately, the syscall table isn’t a very good candidate for this tactic: it needs to be modified at runtime, at the very least for registering new system calls from loadable modules.

3. Audit system calls and flag any ones with unusual parameters. In this case, the user process was passing a pointer into what should have been (from the process’s perspective) an unwritable page. This tactic would be very expensive, since you’d essentially be double checking most of what the kernel already verifies. Or, at least it should verify.

4. Careful code auditing to make sure #1 always happens.

Note that the tactic of preventing user processes from mapping very low memory (used in the other vmsplice exploit) as suggested elsewhere would not have prevented this particular exploit from working. It uses a different path through sys_vmsplice to achieve it’s code execution and no zero page mappings or any such funkiness.

By the way, the vulnerability has been patched in 2.6.24.2. Though it is a local-only exploit, it is still a significant risk.

A federal judge has ordered spammers to pay more than $2.5 million for violating federal laws including the CAN-SPAM Act. SecureWorks provided expert testimony including an analysis of spam messages and an explanation of the methods used to send the spam.

This is the first case of its kind involving “web form hijacking” or, technically, the abuse of open HTTP-to-SMTP proxies.

Forms on websites are often used to initiate email messages to people who handle feedback, customer service, and order fulfillment. Spammers have figured out how to hijack these forms and use them to send their messages to as many recipients as they wish. Recipients often mistakenly believe the company whose website was hosting the vulnerable form is endorsing the advertised products or services. Meanwhile, the company’s reputation is damaged and legitimate business traffic from their networks could be blocked as a result of the unintentional association with the spammer.

In this case, Sili Neutraceuticals, LLC and Brian McDaid operated as Kaycon, Ltd. and used web form hijacking to send spam messages which U.S. District Court Judge David H. Coar agreed violated CAN-SPAM. The spammers also violated the FTC Act by making false and unsubstantiated claims regarding the Hoodia weight-loss and the HGH (human growth hormone) anti-aging products promoted in the spam messages and on their website.

Based in part on the assistance provided by SecureWorks, an injunction against the defendants’ operations was issued, their assets frozen, and a default judgment was entered against the defendants for $2,569,851.77. SecureWorks is honored to have had the opportunity to assist the FTC in its mission of protecting America’s consumers.

See the FTC news release here

Other files related to this case can be found here

It is tax time in the United States, and scammers are seizing the opportunity to launch new attacks on your bank accounts and steal your identity.

One new twist involves the use of SMS text messages sent to phones. In this phishing attack, the message reads similar to:

NOTICE: You have 71 IRS UNITS pending for refunding, please visit xxxxx website.com ASAP

Users of most smart phones can visit the scammer’s site using their phone simply by following the link. Others must type the address into their browser once they get to a computer. Once there, a phishing site asks for personal and banking account information.

In another scam, an email bearing the name and logo of the Internal Revenue Service tells recipients that they must register for direct deposit at an official website in order to get their rebate check as promised by the proposed “economic stimulus” package. These messages contain subjects such as “2007 fiscal activity rebate”. The link in the email points to yet another phishing site asking for personal information and bank accounts numbers.

Keep in mind that the proposed stimulus package has not yet passed and the terms of the deal are still being debated on Capitol Hill. Also, the IRS and U.S. Treasury do not require individuals to use direct deposit.

Similar scams using dishing (voice phishing) phone calls have also been reported. These scams usually hide or spoof the Caller ID information to seem more credible.

These types of scams are expected to increase throughout the American tax season, which ends on April 15. The scams involving the economic stimulus package could go on for while longer. Until the plan is finalized, no one will be getting checks from the government. Current estimates put possible check mailing dates in June or July.

All the usual warnings regarding phishing apply, and user education is really the only way to combat this sort of social engineering. Treat unsolicited SMS messages and phone calls with the same critical eye that you would use for unsolicited email.

In the movie “Live Free or Die Hard,” street-wise cop John McClain battles it out with the bad guys using computers to carry out their crimes. In this movie, we are introduced to a term called a “Fire Sale” where hackers take out critical systems to cause chaos. It is literally a movie plot terror threat, and seems pretty unlikely to happen outside of the theaters.

But late last week we got news of a similar scenario being carried out in foreign countries. Cyber criminals extorting public utilities with threats of taking down the facility. It seems that in at least one case, the attackers made good on their threats, affecting multiple cities. The Daily Mail of London indicates that these attacks have been carried out as near as “Central and South American countries including Mexico.”

Given what I know about SCADA systems from reading public documents and making some guesses based on my experiences, I’d say it’s entirely plausible that unauthorized access could be gained to these systems. While the speech mentions utilities outside the US, I wouldn’t be surprised if there are unauthorized users inside some American public utility companies. And we know that SCADA systems have been compromised before. Both with and without “insider information.” Just recently, a 15 year old kid was able to take control of city trams in Lodz, Poland with an IR remote control and caused one car to jump the tracks and hit another tram.

One set of regulations, NERC-CIP, was passed, ironically, the day before the big Northeast blackout of 2003. It’s ironic because the outage may have been exacerbated, by systems failing to perform as they were intended because of the Blaster worm. Recently some SCADA systems were put through a well publicized attack scenario where the adversarial team gained full control and was able to damage physical equipment in the scenario.

Organized crime has been doing this kind of thing for years, operating by extorting companies for “protection money.” The difference here is that someone around the world can threaten and carry out these attacks. Cyber criminals have been known to extort companies in other industries. A type of malicious software called “ransomware” encrypts or steals documents from your hard drive and extorts you to get the data back. Hiding one’s tracks is only slightly easier (you have to deliver the money somewhere), but where it’s really different is that the attacker never has to set foot in the jurisdiction of the place where the action is carried out. He can be sitting in a cafe in a non extradition country.

Will we see this kind of extortion happening in the US? I doubt it. Cyber criminals need to be able to get away with the money. Disrupting the American power grid would cause too much attention to be put on them from the wrong people — those who could and would spare no expense to make sure they were caught. As Hans Gruber says in the original “Die Hard” movie, “When you steal $600, you can just disappear. But when you steal $600 million, they will find you.” In other words, the higher value your target, the more that will be invested to track down the attackers.

SCADA systems have traditionally been more impervious because they are arcane. But as this 2006 SANS webcast and this Information Week article indicate, in the last few years SCADA systems have been connected to the Internet and wireless networks, and have been transitioning to Windows architecture. In other words, many systems run on a platform that attackers know well and are connected to systems which allow greater external access. So the lesson is clear that anyone running SCADA systems needs to be especially diligent in protecting them.