This year, BlackHat had an entire Cloud Computing track, running all day on Thursday, of which I attended a great deal. Part of my job involves protecting cloud computing services, so it seemed very relevant, and it’s certainly a hot topic in the industry right now. It began with Alex Stamos, Nathan Wilcox, and Andrew Becherer presenting a lecture on cloud computing models and vulnerabilities.

They defined cloud computing as not just virtualization, but including general-purpose hosts, central management, application mobility, distributed data, low-touch provisioning, and soft failover. They looked at three different cloud models: Software as a Service, Platform as a Service, and Infrastructure as a Service, and the differences & vulnerabilities in each.

The Software as a Service (SaaS) model is to outsource everything. From a security perspective it’s not necessarily a bad idea — the cloud provider probably has a lot more security people than the average company. On the other hand, you also outsource all your data — the recent Twitter “breach” via somebody logging into Twitter’s Google Docs account shows the risks this can entail. You lose the perimeter, endpoint management, the ability to use better authentication than simple passwords, credential quality controls, password reset processes, and realtime anomaly detection (though you hope the cloud provider has some of these things.) It puts all your eggs in one basket — if someone can read your email, they can access all your data. SaaS products include Office Live, Google Apps, and Salesforce.com. None of these have decent audit & rollback capability; Google Apps at least provides login history (though you have to write code & call an API to get at it) but still no read/write level auditing. Salesforce.com offers some write logging. However, the biggest flaw with SaaS models may well be authentication — all your security relies on a password, with all the vulnerability that entails, and you can’t even set a strong password policy (for all the good it would do you.) Google Apps actually lets you use a SAML-based SSO system; with other SaaS apps the best you can do is set a strong password policy via employee education.

Another issue with SaaS providers is the legal concerns — the cloud service EULAs tend to promise basically nothing and disclaim all liability. Also, they forbid malicious traffic — even pentesting your own app. There’s also decreased protection from search and subpoena. Since the data is stored with someone else, there’s no Constitutional protection from search, and even statutory protection is usually only for “communication.” Are Google Docs communication? Courts haven’t really defined this yet. The net result of this is that there’s no need for a warrant, probable cause, or even notice of a search — you can’t fight a seizure before it happens, but only after the fact.

Platform as a Service (PaaS) is the model of having a common development platform provided, yet allowing people to customize their applications. This is the model of Google AppEngine, Force.com, and (maybe) Windows Azure. (Azure is a unique case, kind of halfway between PaaS and IaaS; I’ll come back to this.) This section of the presentation was rather odd, as they really looked at the common web vulnerabilities (CSRF, XSS, SQL injection) and investigated how the platform protected you from them. In short, the answer is that they don’t. Some of the platforms have some inherent protection available (e.g. Windows Azure apps are typically ASP.NET, which has some built-in XSRF protection via ViewStateUserKey, XSS protection via encoders, and SQL injection via LINQ), but it’s up to the developer to actually use them. I found this section somewhat lacking, because it wasn’t really about the cloud platforms at all, but rather the common web technologies sitting on them.

The Infrastructure as a Service (IaaS) model is that taken by Amazon EC2 and similar services. It provides virtual machines with short-lived instances, non-persistent local storage, and available helper services. Though the presenters thought of Azure as very much a PaaS model, I think it’s a little fuzzier here — while Azure does not allow you to choose an operating system (the Windows Azure OS runs on every VM), it does not constrain you to anywhere near the degree of Google AppEngine or Force.com, as you can run arbitrary native code on it. It would be impossible to use AppEngine or Force.com to run anything but a web site; Azure is like EC2 in that it could be used for any flexible computing task, not just web sites.

The problems with IaaS services are usually hypervisor flaws or problems in the helper services. However, they brought up something very new here that I don’t think any of the current cloud providers consider — lack of entropy. Virtual hardware has mostly deterministic timings — input events don’t exist and block device events are abstracted. Thus, entropy is generated very slowly if at all. What’s more, in the case of Amazon EC2, since OS images are available to everyone, an attacker can get a copy of the stored entropy pool you’re using (which will never update after the image is originally created, thus depriving the system of another source of entropy) and eliminate it as well. The net result of this is that pseudo-random number generators — even cryptographically strong ones — are unreliable and may be predictable. This attack may or may not be practical given the specifics of the system in question, but for now you may not want to build your online casino or public key infrastructure in an IaaS environment! Cloud providers may actually have to have random number generation as a helper service as well, supported by quantum hardware.

Next, Jeremiah Grossman and Trey Ford presented a sequel to last year’s talk on “making money the black hat way.” Essentially, it was a survey of interesting hacks-for-profit that have been carried out recently. They noted that hacking activity is up this year (layoffs create more hackers?) and that 69% of attacks are discovered only because a 3rd party tells the company it’s been hacked.

Some of the interesting ones: eBay gave away 1000 items for $1 in a “Holiday Doorbusters” promotion. However, almost 100% of them were bought by bots, which was evident because the items were purchased before the item description page was even viewed. StrongWebmail.com had a contest to give $10,000 to whoever could hack into the CEO’s webmail account; rather than attacking the servers, the winners of the contest sent the CEO phishing mail with an XSRF in it that stole the contents of the account. (Amusingly, they got him to open the mail by labeling it “I think I won.”) Grossman & Ford also brought up cookie-stuffing, a type of affiliate fraud that’s been around for many years; it’s a well-known technique in the affiliate marketing world (basically you spoof the referrer while iframing the advertiser’s site on your site, then drive traffic to your site in ways that would not please the advertiser if they knew about it) but was apparently new to most of the BlackHat audience. They also brought up the technique of using embedded site search to fake authority links, another well-known “black hat” SEO technique. Marketers have apparently also begun spamming Google Maps with fake businesses, so as to come up first in “local searches” with their web-based and not-remotely-local businesses. A man in Britain used Google Earth to find all the lead roofs in London, then steal the lead tile in the middle of the night.

Some of the more ambitious hacks were more intriguing, though. One man discovered that you could order “advance replacements” for broken iPods from Apple just by giving them a credit card number as collateral; he used low-balance anonymous Visa gift cards to get 9,000 iPods. Another group put their garage band music in the Amazon and iTunes stores using Tunecore, then bought hundreds of downloads of their own album with stolen credit cards (thus getting a big check from Tunecore.) One thing to note is that these people got caught only because they weren’t trying not to. The iPod guy shipped all 9,000 to his home address; the Tunecore fraud was so blatant as to get this garage band’s album onto Amazon and iTunes top-10 bestsellers.

Finally, in South America, the system for getting logging permits for the Amazon rain forest was put online. An investigation discovered that 107 different logging companies had hired hackers to compromise the site, which was full of common web vulnerabilities. All told, 1.7 million cubic feet of lumber were smuggled out of the country. Scary permit systems in the United States that are now protected only by a web site: entrance visas, hazardous material transport, and open burning permits.

Next, Haroon Meer, Nick Arvanitis, and Marco Slaviero presented a talk on “Clobbering the Cloud.” This SensePost talk covered much of the same material as the iSec Partners talk earlier in the day. Their primary risk factors for cloud computing were as follows: lack of transparency from cloud providers (opaque EULAs), people don’t want to store regulated data in the cloud, vendor lock-in especially if the vendor goes out of business or stops offering the service, availability concerns (not just servers being down, but also things like password lockout from DoS attacks), monoculture issues (worms and cascading compromise are a big concern when you have thousands of perfectly-identical boxes), and trust in the cloud provider — you have to trust your cloud provider implicitly not to lose your data or have system failures. In addition, there’s the problem that the cloud is available to the bad guys, too — cloud boxes can be used for click fraud, DoS, or spamming (for a short time Amazon EC2 was the net’s #1 spammer.) Finally, the security of your environment is all in the hands of the account owner, who authenticates with nothing more than a password, and is (in most companies) probably a non-technical executive. Breaking into the CIO’s email now makes you the global administrator of the company’s entire infrastructure.

The presenters then went into more detail about attacks on Amazon Web Services (EC2, S3, SQS, and DevPay) in particular. I can understand why they chose AWS; due to its flexibility, it’s certainly the most fun of the cloud services for a hacker to play with (though Windows Azure is getting there, too.) EC2 is based on a modified Xen hypervisor, and supports running any OS you want that can run in that environment. Amazon provides 47 OS images, but users have contributed over 72,000 more, and an EC2 user can choose to boot any of them. Sometimes user images have interesting things in them, like other user’s EC2 credentials, for example.

Scanning EC2 is prohibited, but you can start up one of the images and scan it yourself via an SSH tunnel (or even have the machine scan itself.) They found 646 Nessus critical vulns in Amazon’s public images; you can also steal Amazon’s own Windows activation keys off their images. The DevPay system is interesting; it’s supposed to allow a user to make an image then charge other users for its use (e.g. to resell an application on EC2.) However, the presenters found you could get a DevPay image and modify its ancestor info (stored in the image itself) so as to credit use of it to you rather than the original author, then reregister it for others to use.

Simply putting up pre-owned (pun intended) images for others’ use can be an attack on AWS. If you prop up a box with a good name (e.g. “Ubuntu 9.04 Standard Image, All Patches”) and a low-numbered ID (so it shows up at the top of the list), and people will use your image to host their apps! You can get a low-numbered ID simply by registering repeatedly; since it’s a hash, eventually you’ll get lucky and have one start with zero. You can only have 20 images per account, but you can create 20 accounts in 3 minutes, so there’s no effective limit.

After that talk, I went over to the mobile track to hear Jesse Burns talk about Android. Android interests me because I’d really like a phone that behaves like a computer (i.e. a device I own) rather than like a toy the phone company is reluctantly allowing me to touch, and Android’s open-source nature has real potential to give me that. It’s not that I trust Google any more than any other wireless provider, just that the platform seems much more hackable and thus inherently harder to control.

Android has a dual security model — Android permissions on various privileges, plus Linux permissions on the filesystem. Applications have their own UIDs/GIDs and are thus somewhat isolated from each other. A package (application) is made up of Activities (GUIs,) Services (background tasks,) Broadcast Receivers (event handlers,) Content Providers (databases,) and Instrumentations (used for testing.) For interprocess communication, there are Intents, which are sets of name-value pairs with routing information. Applications are written in Java, but they’re not applets (i.e. no Java sandbox.)

Available attack surfaces for a malicious app include other apps, system services under privileged accounts (like the clipboard or the surfaceflinger, which draws the UI and owns the screen,) the binder (the inter-process communication system, similar to domain sockets,) and anonymous shared memory. There are a variety of tools available — one can just install a bash shell on Android (either interactively or over the wire or network,) use logcat to look at logs, view Android system properties, check the /proc and /sys filesystems, run dmesg to get kernel output, and all the usual Linux attacks. There’s also a file in /data/system/packages.xml that contains data about every installed app, including the location of the app and its manifest. /proc/binder contains a transaction log of the inter-process communication, and /proc/binder/proc contains data of all the processes themselves.

Another interesting detail about Android is the “secret code” handler. When you dial *#*#somenumber#*#*, this triggers the secret code handler for that number, which can do pretty much whatever an app wants it to do. The only secret codes on “stock” Android are 8351 and 8350, which turn voice dialer logging on and off, respectively. However, wireless providers may add additional codes — the presenter found some in T-Mobile’s MyFaves app, for example. Finally, the presenter had a series of Android hacking apps he’d developed — Manifest Explorer (to view the system manifest and the manifest of each app, such as to see what events they react to,) Package Play (to see the parts of a package or to directly activate Activities,) Intent Sniffer (to view Intents as they’re routed at runtime,) and Ill Intent (an Intent fuzzer.)

The last presentation of the day was Bruce Schneier, whose talk was entitled Reconceptualizing Security. Mostly, he gave the same speech he always does, about fear, psychology, security vs. security theater, why we mis-estimate risk, etc.; pick up a copy of Beyond Fear or Secrets and Lies if you want the details. However, during Q&A he did also talk about the attack on AES-256 that was just demonstrated. It’s a feasible attack on 10 rounds of AES-256 (out of 14,) in 2⁴² time. It’s a related-key attack that works only on 256-bit keys (not on shorter ones,) so there’s no reason to panic right now, but it does show that the margin of safety on AES is smaller than we thought. There may need to be a Double-AES in the same way Triple-DES was devised as a stopgap until a new cryptosystem is developed. Alternately, the standard could be changed to increase the number of rounds, but that would require replacing or updating all the AES-based crypto hardware out there.

And that wrapped up BlackHat 2009. Overall, there was nothing as Earth-shattering as last year’s DNS exploit, though it turns out that the SSL issues are pretty nasty. After BlackHat, I hit the Microsoft Security Researcher Appreciation Party at Christian Audigier, which was actually a pretty good party this year without any of the problems of previous years. It’s only drawback was that it only ran two hours. However, at this point DefCon festivities had begun, so there was still plenty going on; my next post will get into DefCon 17.

a

The obvious purpose of this is to help people scam their companies’ expense reporting system by “padding” receipts.  People who are reimbursed for hotel, meals, etc. can create receipts for slightly more than they actually pay (or for that matter, create receipts for meals they skip altogether or eat a balogna sandwich for) and pocket the difference.  Apparently the same company aims to help people rip off their employers in any way they desire, as they also run “Fake Sick Notes USA.”  (Though people running that particular scam are often caught by their own actions.)

It’s interesting that receipts are considered “proof” of purchase.  A receipt, after all, is just a piece of paper, and what’s more, there is no standard for what a receipt looks like.  People know it should be printed on “receipt paper” — which is usually thin thermal paper, but is sometimes quite heavy paper tape that’s inkjet or impact printed — and contain certain pertinent data, like the location of the purchase, the tax, the total, and some legalese at the bottom.  In the modern era, receipts often have serial numbers or bar codes on them, which makes the receipt uniquely identifiable by the issuer, but is quite useless for anyone else to authenticate them.  After all, only someone who has access to Target’s computer system can say if Target receipt #824935729345 is authentic or not.  And when it comes to small mom-and-pop retailers (which often have cash register receipts that contain literally nothing but prices) and online retailers (whose receipts are trivially-forged HTML emails), receipt as proof of anything becomes even more ridiculous.

All this false expense site does is make available to the general public an ability that’s been available to the tech-savvy for years. Someone with Photoshop and a USB thermal printer (easily available on eBay for under $100) has been able to forge receipts since the 1990s. This is another case (like checking accounts) where the “security” of a system comes not from any internal defense, but simply from the fact that most people don’t have a security mindset — most people don’t look at everyday systems and think about their weak points and where they break down.  Since a recept is used as proof of purchase, people assume it is proof of purchase.

Unfortunately, there’s really not much to be done to “secure” receipts.  To do so would require data-sharing between merchants, employers, and the IRS, so as to make receipt numbers authenticable — and that’s a case of the solution being worse than the disease (the privacy implications would be staggering.)  As an employer, the best solution may be to simply avoid the problem — have the company book hotel and travel for the employee (rather than reimbursing after-the-fact), and provide a per diem allowance for expenses rather than reimbursing exact receipts.  Any time you rely on receipts from employees, there’s the potential for fraud losses.

a

Back on December 10th, 2002, United Airlines really did file for bankruptcy.  It was all over the news, their stock plummeted, they went into reorganization (Chapter 11), and eventually emerged as a going concern.  it wasn’t a good thing for most involved, but it was over and done with.

Many online newspapers have archives of old stories that can be browsed.  The Florida Sun-Sentinel is no exception; it’s a pretty typical newspaper.  Online newspapers also often have dynamic lists of links — “Most Popular,” “Most Active,” etc., based on what articles have been read lately.  For some reason, which we may never know, the 12/10/2002 article somehow made it onto one of the lists.  Maybe it was a slow day and a couple people happened to click on it in rapid succession and it bubbled up to the list, and once it was there people started clicking on it (as the story would be pretty big news if it weren’t six years old.)  Whatever the cause, a link to this old story found its way onto the homepage — Tribune Co. says it was “due to traffic volume,” which I think lends credence to the “a few people clicked on a slow news day” theory, though it could have been deliberate, which I’ll get to later.

News aggregators, the most popular being Google News, crawl reputable news sources like online newspapers for interesting stories, then bump them up or down on their pages based on how popular they turn out to be.  Since this was on the Sun-Sentinel‘s homepage, and probably their RSS feeds as well, the Googlebot pulled it up.  However, the Sun-Sentinel‘s page did not list a dateline for the story — so, lacking any other information, the Googlebot concluded it was new; this is not unreasonable for something suddenly showing up on the front page of a newspaper.  Google News published the article in their aggregator with a dateline of 9/10/08.

People started reading the article, and that pushed it up in the rankings.  Soon, UAL’s bankruptcy was a top story on Google News, which is read by millions.  Some of those readers included stock analysts, one of whom proceeded to put the “news” on the Bloomberg wire, the primary source of breaking news used on Wall Street.  On one hand, it seems foolish of him, and this was probably a career-limiting move.  But on the other hand, Google linked him to the web site of a legitimate newspaper owned by Tribune Co. — he didn’t exactly read this on “hot-stock-picker.ru” or something; why would he doubt its veracity?  It was clearly a professionally-written news article in a major newspaper (or at least a minor paper from a major publisher.)

Wall Street today bears little resemblance to its history before the late 1980s, when “program trades” started.  Program trades are basically what they sound like — computer programs set to execute trades when certain conditions are met.  There were apparently a decent number of program trades set to dump UAL stock upon getting bad news about it over the Bloomberg wire, and they did just that.  UAL, as a mid-cap company with very high volatility, was quite heavily held by hedge funds, who are very heavy users of program trades.  Large, institutional investors — including hedge funds, perhaps especially hedge funds — limit their risk by having standing “stop-loss orders” on large positions.  These are orders to sell the entire position should its share price fall below a certain floor.  The hedge fund selling based on the news was enough to send the stock price down across a few stop-loss orders — and their selling sent it through more, and so on.  The stock dropped 79% in 15 minutes, eradicating literally billions of dollars in shareholder value.  At that point, the exchange stepped in and froze the stock, halting any further trading (as well as the runaway program trades.)

Once people figured out what was going on, the stock was bid back up to $10 again (about 85% of its original value.)  A lot of people ended up upset with Bloomberg, and Google, and the Sun-Sentinel, but there’s no one to sue — the Sun-Sentinel didn’t do anything wrong (they didn’t republish the story or try to call attention to it, it just sat in its archives like it had for the last six years), and the newswires and aggregators aren’t liable for checking the accuracy of things they link to.

What I found interesting, though, is the implications this has for deliberate manipulation.  This appears to have been an accident, but what if someone were to set out to do this on purpose?  All they would need is to find a newspaper or other reputable news source that doesn’t have reliable datelines on all their stories, then pick a stock that has recovered from old bad news or plummeted after old good news — just something where the news, if new, would affect the price substantially.  Rather than waiting for the story to coincidentally rise to the top, a botnet or set of proxies could bid the story up to “most popular” quite quickly.  The attacker would just have to keep it there long enough to be picked up by aggregators.

Essentially, this person would have tomorrow’s news today, and could trade on it.  (Well, really it’s yesterday’s news, but they’d know it before everyone else “knew” it.)  If you were doing this intentially to UAL, you’d first buy put options and short-sell the stock, in anticipation of the sudden drop.  Once it dropped 50%, you’d unwind those positions and start buying — after all, once the error is discovered, the stock will mostly revert to its original value.  It’s not even clear that this sort of manipulation would be illegal — the attacker isn’t a fiduciary, and can’t be charged with insider trading or most securities violations.  Federal law is fuzzy enough that prosecutors can sometimes find a way to charge just about any person with a crime if they really want to, but this would be quite difficult to prove.  It’s not like lots of people don’t hold put options and short sales on volatile, risky companies like UAL, and reversing the position after a big drop would hardly make you alone among traders.  Making 5-10 times their investment on something like this would not be difficult if it worked.

The interesting part about this is that it doesn’t involve an “attack” in the traditional sense.  There’s no cross-site scripting or SQL injection, no stealing of confidential data.  Nothing is involved but clicking on an old news story a few dozen times, and being positioned in the market such that the resulting chaos works to your advantage.  It’s even possible that this did happen with UAL, and the companies involved don’t want to talk about it, for fear of giving people ideas.

a

All that said, I wouldn’t argue for IP-izing currently-working non-IP networks like SMS, either. There’s simply no reason to.

Next, Arian Evans of WhiteHat security spoke on web application canonicalization, encoding, and transcoding attacks. This was one of the more interesting (and personally useful) talks of the conference for me. Web application vulnerabilities fall into two categories — syntax vulnerabilities, which fork code-paths, like SQL injection, cross-site scripting, etc., and semantic issues, consisting of errors in business logic. Syntax issues are normally fought by signature-based methods like IDS/IPS, WAFs (Web Application Firewalls), and XML firewalls. However, encoding syntax attacks can cause them to bypass these defenses.

Internationalized websites often require encoding and code page transitions in order to work. In addition, developers use encodings for type safety. An attacker can take advantage of these to get a syntax attack to its target:

1. Choose a vulnerability you want to exploit (e.g. XSS, SQL Injection)
2. Identify the parser on the target (browser, database, application, etc.)
3. Identify the supported encodings, codepages, and character sets on the target
4. Identify intermediate interpreters between you and the target that canonicalize alternative encodings, such as web browsers, web application firewalls, proxies, or other applications
5. Encode your attack such that it will be parsed in the desired way by the target after being canonicalized by all the intermediaaries

This results in complex nested encodings, such as encoding SQL with the CHAR/CHR functions, then decimal encoding that, then URI encoding that result. The resultant mess goes right past IDS/IPS, but each interpreter strips off a layer of encoding, and when the payload finally reaches the target, it is interpreted property and works. More sophisticated, internationalized apps are often easier to hit, because you have more options for submitting encoded (in another codepage) metacharacters that are later transcoded by the applications.

The solutions offered for this were the usual — strong data typing, strong output encoding (to prevent XSS), and enforcing the code/data boundary whenever possible (which isn’t often when it comes to web apps.) Still, this is very good stuff for demonstrating a SQL injection or XSS vulnerability to a business manager who insists that it’s not really exploitable.

Next, Ivan Buetler gave a presentation on smart cards, specifically the security of APDU, the Application Protocol Data Unit. Smart cards are mass-produced by a few companies, then sent out to companies or agencies that want to use them for security. The buyer initializes them with software and policy, then gives them to a user, who personalizes them with specific keys (often under the guidance of their employer.) Software from the manufacturer can be used to initialize or personalize cards. This demo used the Axalto Access Client, specifically the COVE and CMS administration tools.

The card itself enforces PIN policies and (sometimes) generates keys. During initialization, applets (written in Java and converted to a smart card bytecode) are uploaded to the card to add functionality. The upload, and all communication with the card, is done in APDU codes. These are laid out in the ISO 7816 specification, but there are many vendor extensions, which tend to be poorly documented — so many that the ISO spec is almost useless in reading APDU. However, it’s a simple command structure — a command consists of a class byte, an instruction byte, two 1-byte parameters, a data length, and a variable-length data field (and of course a checksum.) Ivan used an app called Smart Card Toolkit Pro 13.4.2 (I can find no reference to it on the Internet other than offers to pirate or crack it) to sniff the communication with the cards and read the APDUs. He also developed his own tools to hook winscard.dll so as to add himself to the stream as a man in the middle and be able to modify APDUs (and thus send arbitrary commands to the card.)

This revealed some significant vulnerabilities. For instance, during initialization, a card can be set to either generate its own keys, or to accept keys being uploaded as-is. However, this is “enforced” by the card later telling the personalization software that it would like to generate its own keys. It’s a classic trusted-client scenario; if you modify the APDUs, the application can be convinced to ignore the card’s settings, and the card takes whatever the app sends. Lacking any APDU documentation, Ivan was only able to find a few settings like this, but if the designers of the Axalto smart card system think that’s an acceptable practice, there are probably many more.

Scott Stender of iSec Partners spoke next, about concurrency attacks in web applications. This started out with an explanation of multiprocessing (in short, on any given core, two things that execute “simultaneously” don’t really — they alternate really fast, which means that they do execute in an order, and you can’t always predict what that order is.) This would have been a more interesting talk to me had I not spent years debugging crazy stress and performance issues in the past — I’m quite familiar with concurrency and race conditions.

With web applications, web app frameworks like .NET and Java Struts define an interface that contains request context (e.g. cookies, local variables, session variables.) Access to shared resources needs to be protected, but since web access is asynchronous, threads sometimes find themselves working with dirty or stale data. The classic example is a bank – imagine a money transfer process like this:

1. Collect source account number, destination account number, source account balance, destination account balance, and amount to transfer.
2. Verify that the source account balance exceeds the amount to transfer.
3. Set the destination account balance to its former balance plus the amount transferred, and set the source account balance to its former balance minus the amount transferred.

Seems perfectly sane. Now imagine that I put in a request to transfer my entire balance, then while that request is between steps 2 and 3, I start another request to transfer my entire balance, and it completes steps 1 and 2 before the first request resumes at 3. With multiprocessing this is quite possible — and it would result in my transferring twice as much money as I have (and likely without even having a negative source account balance.)

Concurrency flaws allow manipulating stateful assets (like the above bank accounts) or changing security parameters (like auth credentials or single-use redemption tokens such as gift certificate codes.)

The solution is well-established in the database world — transactions. Transactions are atomic, concurrent, isolated, and durable (the so-called “ACID test”) — a transaction succeeds or fails as a single unit (no part of it happens unless all of it happens), and none of the resources in a transaction may be touched until the transaction is complete. Web apps can implement their own transactions, or use the transactional support of their underlying database architecture. The important part is that there is some kind of end-to-end scoped lock (and global locks — that is, eliminating multiprocessing altogether and just doing one thing at a time — are both impractical for performance and lead to deadlocks.)

Concurrency flaws can be found in testing pretty easily — run load/stress tests and check for discrepancies afterwards. Usually something will show up. You can also add test hooks that encourage context changes to increase the likelihood of finding something. Scott also promised to upload his own tool, SyncTest, here in the coming weeks.

Jeremiah Grossman and Arian Evans also presented “Making Money on the Web the Black Hat Way.” This was all about business logic flaws, and the way they’ve been exploited to help underhanded people make tons of money without exploiting traditional “bugs” at all. These included:

1. Creating artificial scarcity in ticket sales for events via denial of service. When you consider purchasing tickets, the site “reserves” them for a short time until you choose to purchase or not. Since it costs nothing to reserve tickets for a few minutes… one person can reserve a lot of tickets.
2. Breaking CAPTCHAs for spammers. Some have terribly flawed implementations (e.g. the correct answer in a hidden field, or the image name), while others can be recognized by OCR software. Keep in mind that if OCR can read the CAPTCHA even 10% of the time, it’s “broken” — and it’s hard to make something that a computer can’t read even one time in ten that a human can still read. Also, there’s the Mechanical Turk solution — disguise CAPTCHA-solving as a “game” (usually one with porn as a prize) or just pay people overseas to solve them at low rates.
3. Various overseas companies offer “password recovery” services, that will tell you “your” password for a small fee, usually $30-$150. Basically, they just guess those horrible cognitive password questions (“What was your first car? Who was your favorite teacher?”)
4. Coupon fraud. Electronic coupons sometimes have predictable numbers, and some offers allow many coupons per order. Some people have bought over $150,000 of stuff with these coupons.
5. Gaming micro-deposits. When you set up an electronic transfer, the bank will sometimes send you a small deposit (less than $1), which you then tell them the amount of to verify account ownership. Michael Largent opened 58,000 brokerage accounts and collected these payments. It’s not illegal under any normal financial law — the bank is sending you a gift. However, he got charged under the USA PATRIOT Act for using fake names (58,000 of them.) This is a really dubious charge (who uses a fake name on the Internet? Oh, that’s right, everybody), but that’s par for the course in Federal law.
6. Application service provider bank robbery. Small banks don’t really make and run their own web sites — they buy a standard “banking product” from an application service provider. Some of these are really, really bad – the example one Grossman showed had no authorization. Once you logged in as a user, you could transfer money to and from any user so long as you knew the right account numbers (which other bugs in the site were very helpful in providing to you.) Crack an ASP, and you don’t just get to rob a bank, you get to rob many banks.
7. Slow order cancellation. QVC, the popular shopping channel, was apparently not very good at canceling orders. One woman started to order something, then canceled the order at the last step, and received the order anyway. Finding this interesting, she tried it again. And again, and again, until she’d received $412,000 in QVC merchandise and sold it on eBay. According to law, if you are sent merchandise you did not order you’re entitled to keep it as a free gift. She’d probably been able to keep doing it for years, too, if QVC hadn’t caught on because she sold the items on eBay still in their QVC packaging. Ah, criminals are always so entertaining.
8. Affiliate scams. People take advantage of affiliate offers in a host of ways. The most common are cookie-stuffing methods — rather than getting people to click links to affiliate sites like they’re supposed to, sneaky affiliates will embed links to the affiliate sites (often dozens or hundreds of offers) in IMG or IFRAME tags. Now whenever someone buys anything online the affiliate gets a check. They avoid referrer fields with SSL pages (or META REFRESH, or several other techniques.) Some get much more devious, with DNS rebinding, GIFAR, Flash malware, or other techniques. However, the affiliate networks can catch all this, because people sent to affiliate sites by such scams convert at a much lower rate (nearly zero) than those who clicked through to the site on purpose. This said, while people are caught constantly, apparently there is no evidence that anyone has ever been sued or charged over this sort of activity — it’s in a legal grey area where it’s not clear what, if anything, to charge them with.
9. Trading on semi-public information. BusinessWire (a popular place to post press releases for business) had a forceful browsing vulnerability — press releases that had been uploaded but not officially released were stored at publicly-accessible URLs and just not linked to the home page. When someone found out, they started reading tomorrow’s news today and making stock trades on it. They made $8 million. A federal judge declared that they did not violate SEC regulations, because they had no insider privilege or fiduciary duty to the company — they were trading on nonpublic information, but no one who was forbidden to give it to them gave it to them. They could still be prosecuted for hacking, maybe (is typing a URL directly to a page and not following a link trail “hacking”?). but that’s hard to prove if you’re remotely careful — usually we catch hackers by following the money to them, Al Capone style. If the money is legal, and you have to catch them for the technical exploit, that’s hard.

The moral of the story: business logic flaws are serious money, possibly much more than the syntax flaws we spend so much time worrying about. Test everywhere, profile users, detect leaks and aberrant behavior.

The final presentation of the day that I attended was one by Michael Slaviero and Haroon Meer of SensePost on getting data out of protected networks.

Long ago, once someone compromised a machine, they could simply enable a shell on some port, then telnet in. However, firewalls stopped that, so they began to do reverse tunneling with ssh and netcat (as well as more custom software like tcpr and fport.) Outbound filtering stopped that, too, and so we got web shells — pieces of ASP/ASP.NET/PHP/whatever-the-web-server-runs code that could be uploaded into a webroot and would provide remote control facilities and file transfers. However, there are now a host of mechanisms available for tunneling data out of a compromised machine.

For one, XP’s IPv6 support can be used as a port proxy. The netsh command can set up a proxy such that one port on one (internet-accessible) machine is redirected to a different port on another (internal, behind the firewall) machine. Thus, one compromised edge machine can provide direct network access to any machine it can reach on any port. The ssh -L and -R can be used to similar effect on UNIX hosts. This is a great reason for defense in depth — if an edge machine is owned, the firewall as a source of protection is largely eliminated.

There is also DNS2TCP. If an attacker can get this onto a compromised machine, it allows full 2-way tunneling of arbitrary TCP over DNS — the one protocol that is allowed everywhere. Once again, this bypasses the firewall. SensePost also demonstrated their own app (glenn.jsp) which encoded TCP over well-formed HTTP POST via base64 encoding. This is not just sending arbitrary traffic over port 80 (where an application-layer firewall will block it) — it’s true, valid HTTP requests against a real web page on the server, tunneling arbitrary TCP.

So with an edge web server under the attacker’s control, the firewall is bypassed in several ways, and your network is open to the attacker. But what if the attacker uses SQL Injection to get in? Then instead of a web server, they have a back-end SQL server with (hopefully) no access to the Internet, and thus no way to upload DNS2TCP or reach glenn.jsp. Well, it turns out that there are other ways that operate only on SQL.

Squeeza is an advanced SQL Injection tool. It separates content generation from return channel — you can have it return output via HTTP errors, via DNS tunneling (entirely in SQL!), or even via a blind timing channel (which is hideously slow — over a hundred milliseconds per bit — but works.) You can send all sorts of content through it — profile the version of the server, use existing OLE objects on the server in the server’s context (such as to write a working portscanner entirely in SQL), or (in many cases) take control of the machine.

SQL Server 2005 was the first SDL-developed version of SQL Server, and was intended to be far more secure by default than previous versions of SQL Server (which had over 1,000 stored procs enabled by default.) However, SQL Server is by its nature very hard to secure — it is very public, very capable, and highly targeted. What’s more, new features sell while better security doesn’t — so while most things are disabled by default, SQL 2005 has more “things” than ever before.

The downfall of a compromised SQL Server is in-band signaling. SQL Server’s configuration is controlled by stored procedures within SQL Server — so if you’ve gained sa access on a SQL Server, you can just turn all the disabled services back on. This includes the dreaded xp_cmdshell stored procedure (which runs shell commands as the server.) Using the new web service integration, you can write new SOAP endpoints entirely within SQL and place them on arbitrary ports — enable batch mode on those endpoints and they’ll allow running arbitrary SQL (thus getting you out of having to tunnel over DNS or use blind timing to get data out.) And if you enable the CLR, you can run arbitrary .NET code in the server (subject to CAS restrictions — unless you’re running as sa, in which case there are no restrictions at all.)

There are several interesting ways to get your arbitrary .NET apps onto the server. You can order the server to load them directly from a UNC path — if the server has outbound access to your server, which is unlikely. However, you can write SQL that creates the assembly in memory from raw hex and loads it. You leave no trace on the disk, and run arbitrary code.

All this talk really tells you from a defender’s perspective is the importance of defense in depth. A compromise of either the web server or the database server essentially takes down the firewall from the attacker’s perspective — they can reach anything the server can, and can run port sweeps to find out what’s within reach. Thus, it’s vital to do several things:

1. Run the web server and database server with least privilege. The attacker can’t get more access than the servers themselves have — both services should be running with only the minimal privilege required to perform their function. Web servers should only have access to the web root — and most importantly, only read access. Databases should never be accessed as sa — only as an account with execute access to needed stored procs and select access to needed tables. Don’t let a database INSERT or UPDATE — use stored procs for that.
2. Segment your network securely. The web server shouldn’t be able to hit any IPs or ports that it doesn’t actually need to hit to serve web pages. Likewise with the database server. Both inbound and outbound filtering is important.

Overall, it was a great conference, and there was a lot of good information handed out.  I’ll be posting a recap of DefCon 16 over the next few days as well (once I have a chance to boil a notebook full of notes down to an intelligible post.)

a

However, all the discussion about privacy in the article is, in my opinion, a secondary issue.  As I’ve discussed before, using an ad replacer has other effects that may be much more serious.  It means Charter is now mounting a man-in-the-middle attack on all its customers and editing the web pages they view.  Thus, if there are any security flaws in the NebuAd software (like, say, a cross-site scripting vulnerability as we saw with Barefruit in a previous post), they are now embedded in every web site viewed by every Charter customer.  When you’re a large ISP like Charter, this makes it worthwhile for hackers to try to attack the system — being able to steal the bank account passwords of every Charter customer at a given bank is almost as good as being able to do it to all customers of the bank.  It may only be 10% of people, but 10% of everyone is still a lot of people.  In addition, Charter customers are no longer contributing to the revenue of the web sites they visit (which could be interpreted as an attack on those websites by Charter — they just stole all their revenue.)  I don’t much expect Charter to care, nor their customers, but the more ad replacers that are out there, the less advertising is able to support web sites.

So, what to do if you’re a Charter customer?  Well, you can opt out of the tracking system by setting a cookie, which means the ads you’re served will not be targeted.  However, the ads probably will still be replaced, so you’re still not helping pay for the web sites you visit.  And chances are that Charter could still come up with a record of all your web surfing if they were served a subpoena.  If you want to avoid that, the only choice is using an encrypted tunnel and mix network like TOR (which law enforcement has probably at least partially compromised, but this puts them in a situation like the Allies after they broke the Enigma machine — if they use evidence from a TOR compromise to prosecute you, then they give away that they’ve compromised the network and criminals will stop using it.  Thus, you’d need to do something pretty serious for them to be willing to admit they know about it.)  And what to do if you’re an advertiser-supported website?  Not much.  You can lobby for net neutrality laws, or ban Charter customers outright (which will hurt you more than it hurts them.)  However, I would expect Google, DoubleClick, and other ad networks to start working on obfuscating their ads soon if more major ISPs embrace ad replacement.

a

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.

a

Dan Kaminsky, however, gives us another reason to oppose ad replacers in his latest presentation, which he gave last week at Toorcon 10. A bunch of ISPs (and I mean big ISPs — Comcast, Earthlink, Cox, Verizon, Quest) decided that rather than replacing ads in live pages, they’d go after something less controversial — typos. They set up their DNS servers to return ad servers run by a British company called Barefruit when a DNS lookup failed (rather than following the RFC and returning NXDOMAIN, the code for “no such domain.”) This is similar to what Verisign SiteFinder did a couple years ago (SiteFinder was taken down after a storm of bad publicity), but instead of affecting the entire Internet (VeriSign did this on the root domain name servers), it only affects customers of the specific ISPs doing it.

The result is that if you mistype “www.google.com” as “www.gogole.com” or somesuch (actually, gogole.com is registered to Google, too, but it’s just an example) on one of these ISPs, you get a “site not found” page from the Barefruit, filled with ads. Doesn’t seem too harmful — after all, you’re still getting the error message, and seeing some ads never hurt anybody.

Except for one problem. Dan Kaminsky found that the Barefruit page constructs the error message from an argument in the URL querystring (telling the server which site you were trying to hit, so it can say “Sorry, we couldn’t find an entry for www.gogole.com” or somesuch.) This is the classic cross-site scripting vulnerability — you can just toss in some JavaScript in that URL, and when someone clicks a link to the corrupt URL, the JavaScript will execute in their browser. Normally, this is bad — a site with an XSS vulnerability can be used to carry out phishing attacks, where users are sent a link to a site (say, a bank), but clicking the link executes the attacker’s script and steals their credentials to the site.

When it happens in this ad replacer that’s based on DNS voodoo, though, it’s not just bad — it’s catastrophic. The ad replacer page comes up for subdomains, too. Not only does a typo of Google send you to the Barefruit site, so does trying to go to this-domain-does-not-exist.perimetergrid.com. Since the Barefruit page comes up in response to a call to any bad subdomain, and the Barefruit page has a severe XSS vulnerability on it, this means that an attacker now has an XSS to work with on an arbitrary subdomain of every domain on the Internet. A really insidious, intelligent attacker (e.g. Dan Kaminsky) can do terrible things with this.

Luckily, Dan is a nice guy, and instead only did ridiculous things with them, crafting links to RickRolled versions of Facebook, MySpace, Apple, Microsoft, eBay, ToorCon, Fox News, etc. However, he could have just as easily crafted links to GMail, Hotmail, Chase, Bank of America, Fidelity, and eTrade that steal your credentials when you click on them.

The presentation slides do not make it obvious what exactly his script does (presumably because Dan explained that out loud during the presentation.) However, I can see from context how this attack works. The attacker writes a script to exploit a given site, and then creates a link to a nonexistent subdomain containing the script. They then send this out in a phishing email, or embed it in a hidden iFrame on a compromised site, and wait to receive credentials. Any user who clicks on the link:

http://evil-subdomain.gmail.com/index,html,aaa=bbb&ccc=ddd<script>[long evil script file here]</script>

gets sent to the Barefruit page, but with the attacker’s long evil script inserted into that page. That script then takes over:

1. The browser thinks that the script is running off of “evil-subdomain.gmail.com”, since that was the DNS query that (falsely) returned the Barefruit page.
2. The script sets document.domain to “gmail.com”. Since it is on a subdomain of gmail.com, this is allowed under the same-origin policy, and the browser lets it happen. The script is now permitted to script against gmail.com.
3. The script creates a frame that occupies the entire browser window (thus hiding the Barefruit page entirely) and loads the real gmail.com into the frame.
4. The script grabs document.cookie out of the frame. Since the frame is gmail.com, and document.domain is set to gmail.com, this is permitted. Document.cookie contains the user’s GMail credentials, or at least a session ID that will let the attacker in.
5. The script generates code to load a resource from the attacker’s malicious server, with the cookie contents in the resource value. Loading a resource (e.g. an <img src=…> tag) is allowed on other domains, without the same-origin policy applying.
6. That resource doesn’t exist on the malicious server’s pages, of course… but now the user’s cookie is in the attacker’s server logs where he can retrieve it at his leisure.

And what does the user see when this happens? Just a normal load of the GMail login page. And there’s nothing wrong with GMail in this example! It could be any site, including online banking, shopping, etc. There is nothing that the site — or the user — can do about it. Click a link or visit a malicious web page and the attacker steals your credentials to any site he wants.

All this is made possible because you’re on an ISP that is running an ad replacer, and that ad replacer contains a vulnerability. Using the ad replacers makes a simple cross-site scripting vulnerability into a full compromise of the entire Internet.

Are you on Comcast, Earthlink, Cox, Verizon, or Quest? They’re some of the biggest ISPs in the nation, so probably so. If so, be glad Dan Kaminsky found this simple, obvious XSS before some malicious hacker did, or that hacker could have been stealing credentials from half the Internet for months without detection.

“Without detection.” Yeah, maybe Dan wasn’t the first one to find this. We’ll never really know for sure.

This vulnerability is fixed now — it was very straightforward, and Barefruit fixed it within hours. But Barefruit isn’t the only ad replacer out there, and there will be more experiments like this in the future. Whether “net neutrality” becomes a law or not, it needs to be something we demand from our ISPs, or this won’t be the last internet-wide compromise we see.

a

RFID devices are becoming more and more common, and this trend will continue — they’re too convenient for many purposes for the security risks around them to stop them. You may not want every consumer good you buy to be tagged with an ID that lets people watch your shopping from 100 yards away, but the scenario of being able to check out at the grocery store by instantaneously scanning every item in your cart simultaneously is too compelling for people to resist.

Bruce Schneier has a post on the ineffectiveness of security cameras, but while calling them ineffective it does note that criminals moved their crimes to somewhere the cameras couldn’t see. This may be “ineffective” for a government camera system designed to deter crime, but it’s precisely what privately-owned security cameras are meant to do — make a target unappealing so criminals go elsewhere. This actually shows that cameras do deter crime… but only where they can see it.

However, both of these technologies can have pernicious effects, too. The HexView article points out that you could use the RFID tire monitors to commit murder — set a bomb with a radio trigger that goes off when the “right” car drives over it. It would also be just as useful to private investigators spying on citizens as it is to law enforcement chasing down criminals. And speaking of law enforcement, these cameras create a dangerous imbalance in their favor — the camera evidence is all under their control, and thus can come up when needed to prove a perpetrator’s guilt yet be conveniently lost in cases of police brutality, abuse of power, corruption etc.

This is an interesting time for surveillance — police and government surveillance ability is skyrocketing (London is practically blanketed in cameras at this point, as the British seem much less uncomfortable with them than Americans are) but it is still largely in the hands of authority figures. This is dangerous because of how fast the change is coming — our criminal laws and sentencing structures are based on the principle that most criminals get away with it. A $75 fine for speeding seems pretty reasonable, but what if that fine were levied every time a car hit 1 mph over the speed limit? Most of us would get fined a dozen times a day, every day, despite not even meaning to speed, because our behaviors are based on the idea that we probably won’t get caught and that even if we are police are unlikely to punish us for very minor transgressions. If people were caught for speeding every time, and fined every time, a $75 fine would be absurd — the fine could probably be under $1 and still bring in a few hundred dollars a month from every citizen. What is the right legal structure here? I can see two possibilities:

• Raise the speed limits to the speeds we really think no one should exceed, and continue to fine every time.  Maybe you should get charged every time you exceed, say, 85 on a highway or 55 on a city street.  Set them high enough that there’s no leeway required.
• Leave the speed limits where they are but set the fine really low, say a $0.25 per minute of speeding.  This makes speeding discretionary — you can obey the law, or not, but if you choose not to you pay a penalty.  This is a fundamental change in the whole idea of crime and punishment, and itself has some pernicious consequences — it means that a certain income level can render you “above the law,” which is not a good thing.  Obviously some crimes (such as murder) should not be treated as discretionary, but for traffic violations it could make sense.

It’s not just traffic laws that are like this; consider the War on Drugs.  If every person who ever smoked marijuana went to prison, we would have a nation of felons — there’d be few people left who could vote, get security clearances, hold most jobs, etc.  The RIAA lawsuits against file-sharers are a good example of what happens when technology that catches everyone gets used to enforce laws designed under the assumption that only the worst and most flagrant criminals will be caught — people being hit by millions of dollars in fines for using technology to do something that wouldn’t even raise an eyelash if done by old, physical means (e.g. posting a song on BitTorrent vs. handing it to a friend on a cassette tape.)

A surveillance society needs a different kind of jurisprudence — one that sets punishments that fit the crime even if applied every time.  On the bright side, actually doing this would lower crime rates tremendously due to the psychology of criminals.  Escalating punishments does little to deter crime because criminals are risk-seekers — they do not expect to get caught.   Even a small punishment can be a strong deterrent if applied every time — if criminals are usually caught, such that all criminals have some first-hand experience with being caught and punished, it would break this idea.  On the not so bright side, a surveillance society must have very liberal laws to avoid being a police state — our current legal system, applied to everyone every time, would result in tyranny.  We all break 10 laws a day, it’s only sloppy enforcement that allows us to live our lives.  Unfortunately, the technology for ubiquitous enforcement will come well before the legal system changes to make it livable do.

What’s interesting to me is what will happen when surveillance becomes even more common: that is, when it is no longer monopolized by authority.  This has already started with cellular phones.   Almost everyone carries around a device which, while primarily for communication, contains a camera and often a voice recorder and videocamera as well.  Everyone is equipped to carry out impromptu surveillance at any time.  Devices like these glasses from ThinkGeek (found via BoingBoing) coupled with the rapidly falling cost of storage capacity will change this to everyone actually carrying out impromptu surveillance all the time.  This will have a chilling effect on human behavior at first — would you act differently if you knew everyone around you was videotaping everything you did?  Everything you say will, indeed, be able to be used against you, and not just in a court of law.  However, look at what young people put on MySpace and Facebook these days — the next generation does not have the assumption of privacy.  They’ve grown up in a world where they know everything goes on a permanent record, and have simply accepted it.  Sure, they’ll be occasionally shocked by it (e.g. the first time their party photos on MySpace disqualify them from a job), but the knowledge of permanence has not stopped them from sharing themselves, and eventually the rest of us will adjust, too.

Consider what the democratization of surveillance does to government power.  When we’re all recording, someone is watching the watchers.  Corruption, abuse of power, etc. all rely on the fact that authority figures can get away with crimes because they are more reliable witnesses in court than their victims are.  When everything is on the record — and not just the official record, but everyone’s record — police and government officials become compelled to act within the law.  While this may not be much of an impediment in truly totalitarian societies like China where the courts are as corrupt as everyone else, it’s a very strong bulwark of freedom in any society with an independent judiciary and a liberal tradition like the Untied States and Europe.  This is the next generation of surveillance — everyone sucking in light and sound from their glasses, or lapel pens, or even contact lenses, recording every moment of their lives on multi-terabyte devices that fit in their pockets.  It’s probably only 5-7 years away, and it washes away the current problems of a surveillance society and replaces them with new ones.

I think this cycle will continue for some time.  After all, once we’re past the era of democratized surveillance, computer graphics and artificial intelligence technology will improve to the point that ordinary people can modify their recordings to create perfect video of events that never happened, indistinguishable from the real thing.  What happens to recordings in law courts then, when they cease to be reliable evidence and become hearsay?  Tapes will become the new eyewitnesses, known to be unreliable and requiring corroboration from others.  When it becomes truly easy to make forged video, perhaps we will have emerged from the surveillance society from the other side — why bother to record anything when there’s no way to tell if it’s real?  Sometimes the only way out is through.

a

They make a big deal out of their privacy practices.  They do not maintain histories on browsers the way Google does — they just replace ads on pages based on the page’s content, kind of like Google AdSense but for image and rich-content ads as well.   Customers, unsurprisingly, don’t really care either way about this service — what’s it matter if I get CNN’s own banner ads on their pages or my ISP’s banner ads?  They’re still ads, and nobody likes them, but whose ads they are isn’t high on a consumer’s priority list.

However, products like this (generically called “ad replacers”) are going to be extremely important to the future of the Internet.  The linked article talks about how ISPs’ profit margins are narrow given their customers’ increasing appetites for bandwidth, and how this advertising revenue will help them recover.  What it doesn’t mention, though, is where this revenue comes from – it’s the ad revenue that would otherwise be given to the sites you browse.

In other words, ubiquitous use of ad replacers would boost ISP revenue while destroying ad revenue paid to web sites.  This is a tremendous threat to Google as it eliminates their sole revenue stream!  For that matter, if an ad replacer can substitute ads, why not substitute the first page of Google search results?  Google won’t sell you #1 placement in organic search… but with an ad replacer, Comcast (for example) could sell you #1 placement on Google for Comcast users.  In addition, all the small niche websites that currently pay their hosting bill (and their owners’ salaries) off of advertising revenue may find themselves unable to do so.  People hate advertising, but what happens to the Internet without it?  The free, ad-supported Internet goes away, replaced with paid, subscription-based walled gardens.  Nobody wants that, but that’s the world ad replacers lead to — and ironically, it’s a world that has no room for them, as they would then have no ads to replace.  This is difficult to fight economically, though — an ad replacer can be a tremendous source of revenue so long as there aren’t many of them.  There’s lots of incentive to make them, even though in the long run they kill the ecosystem.

What this will lead to is a new security arms race.  Publishers will have to start finding ways to “hide” ads in their pages, so that ad replacers do not recognize that they’re ads and replace them.  This will be particularly hard for the large ad networks like Google’s where the ads must be embedded in thousands of dissimilar web pages.  As the publishers come up with better ways to hide ads, the ad replacers will be updated to find them.  The result is likely to be quite a mess, and result in neither the ISPs nor the publishers getting as much revenue as they’d like.  In addition, while Phorm may promise not to build up profiles of private information on you, an ISP who did engage in Google-like privacy invasion would be able to do it far better than Google can — after all, they have all your billing info since you’re a paying customer.  Unlike Google, they really do know who you are, personally, and not just by your browsing habits.

In the long run, international backbone providers could even start replacing ads in order to avoid local legislation, though this would lead to the ridiculous situation of the same ad on a page possibly being replaced several times on its way to the user.  I don’t see any solution to this other than legislation — the same sort of “net neutrality” laws  that forbid content-based traffic shaping or Comcast-like protocol tampering could also forbid ad replacers.  Unfortunately, economic incentives aren’t likely to have much effect, since the actual end users won’t change ISPs to go to one that promises not to run ad replacers — as only the publishers, not the end users, care whose ads are seen.

a

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.

a

First, for those not working in the information security industry: something being classified as personally identifiable information (PII) is a big deal. If data is PII, you are liable for damages if the data is ever released, and you are required by statute to take significant and often expensive measures to protect it. If you’re a public corporation, Sarbanes-Oxley requires you to do all sorts of things to protect the data (e.g. encryption.) If your company takes credit card payments, the Payment Card Industry Data Security Standard requires you to do even more (e.g. physical protection of the hardware the data sits on, specific firewall/router configurations, etc.) Most large companies have their own standards for how PII must be protected that combine or even go beyond the regulatory and industry requirements. Overall, the required protections around PII are onerous enough that companies strive to minimize how much PII they have at all — it’s often cheaper and easier to just delete the data than to protect it the way you need to protect it. Companies must make the decision of “How much business value do we get out of storing, say, our customers’ addresses, and does it exceed the cost of protecting that data?” Often the answer is no.

On the surface, calling IP addresses PII is ridiculous. IP addresses are found on every packet anyone sends on the Internet; if IP addresses count as a personal identification, then logging basically anything about Internet traffic makes the logs PII. It takes a label currently applied only to a small amount of high-value data and applies it to something that everyone everywhere logs; it seems absurd. But as I think about it more, I’ve come to realize that Scharr has a point.

The EU is much more aggressive about privacy law than the United States. The United States Constitution guarantees privacy from the government through the Fourth and Fifth amendments; this sharply limits what the government can collect on you and what it can do with the data it does collect. However, there is no Constitutionally or legislatively defined general right to privacy — anyone can collect whatever data they want, so long as they’re not a branch of government. This is usually an adequate protection against government abuse, but it does mean the private sector can accumulate a frightening amount of data about you, and that could be prone to abuse as well. EU nations, on the other hand, often have a general right to privacy and various data collection expected in the United States is often illegal; in addition, where the data can be stored, sharing it with any third party without express user consent is almost always illegal.

If IP addresses are PII, what really happens? It requires changing a lot of current practices, but this is not the same as breaking scenarios. Remember, the privacy issue isn’t with transmitting or using IPs — it’s with storing them or sharing them with a third party.

• Currently search engines like Google use your IP to identify where you are geographically, so as to establish search profiles for regions and target ads. They store the first 24 bits of your IP (dropping the last octet) as a proxy for location. They would need to switch to storing a different proxy for location (e.g. latitude and longitude), though they could still base this proxy on your IP.
• Pay-per-click ad networks would still function. When they’re clicked, the ad network records the click (so as to be able to bill the advertiser), then issues a 301 redirect to the advertiser, who also records the click (to know it happened and the ad was effective.) These records would need to leave out IP, or be protected as PII. Lacking IP, however, would make detecting and preventing click fraud (spoofed clicks, or many clicks from the same person) much more difficult. Currently a skilled fraudster can evade IP-based click-fraud prevention, but losing even that would make click fraud easy. Also, without IP addresses, the ad networks would have a hard time proving to advertisers that clicks were real if an advertiser chose to sue them. Large ad networks would probably have to just eat the cost of protecting their logs as PII.
• Contrary to RSnake’s comment, I do not think this would affect embedded content. Embedded content comes in two forms — content linked to on a page, which your browser loads (objects), and content retrieved by the server and displayed on the page (mashups.)
  • In the object case (e.g. viewing a YouTube video on someone’s web page), the web site owner is not leaking your IP to the third party — you are. The web site is not sending your IP to YouTube at all; your web browser is sending it in response to a link tag in the page.
  • In the mashup case (e.g. web pages that get data from an API, like Facebook pages, pages embedding Google Maps, etc.), the web site owner is also not leaking your IP to the third party. You access the site, and then the site accesses the third party not as you, but as itself. The site leaks its own IP, not the customer’s. No PII is released.
• Sites that do user tracking (via logins simply recognizing users between sessions) would be unaffected; they use cookies, not IP, to track users. Most ad networks work this way, too.
• The biggest change, though, is to simple website logs. Currently every time you access any web page, it makes a note in a log of your IP and which site you accessed, which is used for statistical analysis, forensics, etc. Even this blog is doing it; with most web providers you can’t even turn this logging off if you want to. Sites will either have to stop doing this or take substantial steps to protect the logs (or else be subject to significant statutory liability if they don’t.) Not keeping logs is, from a security perspective, very dangerous — if something happens, you have no idea what happened and thus may not be able to fix it.

However, despite all that cost and difficulty, when you think about it… IP addresses really are personally identifying. If you have an always-on broadband ‘net connection, your IP address changes very rarely (maybe only once in several months), so all your web traffic everywhere, complete with your search queries, emails, etc., can be tied together with that number. Your ISP can connect that number to your name, address, etc. If you’re at a corporation, the IP is tied to a corporate gateway or proxy… which has logs tying each communication (based on date and time) to your desktop’s IP, which once again likely uniquely identifies you (unless you always compute from a shared machine.)

IP is a unique identifier for confirming identity, but not so much for initially finding it. In other words, if someone attacks my website, and I have only their IP address, it may not do me much good in finding out who they are unless I can get someone with subpoena powers to get it from the ISP. However, if I suspect a specific person of something, I can probably find out their IP and check it against my attacker’s IP, thus confirming their identity. Likewise, if I am an ad network or search engine with a lot of IP data, I don’t know who you are based on your IP, but the commonality in IPs between all the data I have may enable me to figure it out based on data aggregation.

I think this is a case where something is considered ridiculous merely because it changes things. Yes, a lot of business models and current practices would have to change if IP-as-PII became the default assumption. Yes, it would make some security people’s jobs harder, and cause web providers to incur a lot of costs. But does that mean it’s wrong? Perhaps what it means is that current businesses & web sites under-value their users’ privacy, and are freeloading while providing inadequate protections. It’s a different world if we have to discard IPs or protect them as PII, but I’m not convinced it’s a worse one.

a

First of all, the AP reports that AT&T is still considering filtering backbone traffic. They say they’ve noticed the massive amount of copyrighted data being shared over P2P networks, and feel a need to do something about it — “It’s like being in a store and watching someone steal a DVD. Do you act?” However, I think it’s likely that this is not just AT&T having an attack of conscience (not exactly something Ma Bell is known for), but rather AT&T being pressured by the usual suspects, the MPAA and RIAA.

They’re looking at this as a security problem — how do we stop unauthorized traffic (piracy) while allowing authorized traffic? From this perspective, it’s tractable — the technology exists to do it, albeit clumsily (you either miss a lot of piracy or you throw out a lot of legitimate traffic.) However, this is more than a security problem — there are legal and business problems here that in my opinion should overwhelm the security concern.

I’m surprised that AT&T is actually considering it. Currently, AT&T is shielded from lawsuits over content carried over their network by having “common carrier” status — they do not discriminate based on content. If they begin discriminating based on content, they may cut down on music and movie piracy — but they also render themselves vulnerable to being held liable for what music and movie piracy does occur. Perhaps the MPAA and RIAA have offered to indemnify AT&T in exchange for its help with the filtering. There is another problem with filtering, though — AT&T’s Internet backbone lines carry a staggering amount of traffic, so any kind of filtering would of necessity have to be very rudimentary or the processing power requirements would be enormous. Essentially, they would have to do something like what Comcast did with the Sandvine system — just interfere with all BitTorrent (or other P2P) traffic, without making any attempt to differentiate between legal and illegal content.

Perhaps AT&T has another ulterior motive, though — P2P traffic is representing an increasing proportion of all Internet traffic, at this point more than half. If killing P2P would drop AT&T’s bandwidth requirements by 60% while not affecting their revenue, this would have to be tempting for the corporation.

The increasing amount of P2P traffic is causing another major Internet company to consider sabotaging their own business — Time-Warner Cable. Ars Technica reports that Time-Warner is considering switching to metered rates, where users pay different amounts based on how much bandwidth they are using. They’re undoubtedly considering this due to the public’s reaction to Comcast’s filtering of P2P traffic (outrage and lawsuits.) Cable companies are in a bind — they built their networks under the assumption that traffic is extremely asymmetric — many users send small amounts of traffic (requests, acknowledgments) to centralized servers which respond with large amounts of traffic. This made sense when almost all Internet traffic consisted of web pages, but P2P networks destroy this assumption, with each user uploading as much, or more, than they download. Essentially, with P2P everyone is a server, and the cable companies simply can’t handle this without massive, expensive upgrades to their entire infrastructure. Their problem is one of failure to plan — they didn’t see this coming, and spent billions of dollars in capital building the wrong network. Even without piracy, P2P would be an increasing proportion of Internet traffic today — the world has changed, and it won’t be changed back again.

On one hand, metered pricing is fair. Right now, the people who use P2P are getting their Internet connections below-cost — we’re unprofitable for the ISPs, who can only support us because the masses of people who do nothing but occasional web-surfing are so profitable that they subsidize P2P users and result in an overall profit for the ISP. ISPs can afford to offer “unlimited” broadband only so long as they can be sure almost no one will use it. With metered pricing, heavy users pay for their heavy use, and light users can pay less since they don’t have to subsidize the heavy users. On the other hand, there’s a problem — customers despise metered pricing, especially when they’re used to flat-rate. In the 90′s, phone companies experimented with metered local service, and it was outrageously unpopular even with people whose phone bills decreased as a result. Sure, they were paying less, but now they felt limited.

Switching to metered pricing will indeed save money. However, it will do so by driving away customers, starting with the unprofitable heavy users. Perhaps this is intentional — banks set up their fee structures to drive away unprofitable customers, too, so it’s not unprecedented. But in the long run, P2P use is increasing, and the old usage patterns are decreasing — if the networks don’t adapt to this, eventually they’ll have no customers left. Competitors like Verizon FiOS, which (due to a fiber-optic last mile) don’t need to limit upstream bandwidth and have been built in the modern P2P world will kill off any network that tries to live in the past.

a

It turns out that I had nothing to worry about. Despite its title, there are only four paragraphs about resilience in the 41-paragraph article, and even those are wrong.

So what does Giuliani think must be done to defend a society from terrorism? Primarily a command-and-control response process combined with offensive attacks on the sources of terrorism.

With regard to prevention, Giuliani favors deployment of massive detection nets to fight against the attacks we’ve already faced — radiation and biohazard detectors at every port and point of entry. The cost-benefit ratio of this would be astronomically poor; as a free society with mostly open borders, there are a phenomenal number of entry points to the United States, and only very rarely (possibly never, so far, though the government would not be likely to tell us if it did happen) does anyone try to smuggle weapons-grade nuclear material or biological weapons through it. This isn’t to say that these measures would do no good, but they protect only against specific attacks and are obvious. They signal to terrorists “you can’t bring a nuclear or biological weapon through a shipping container in a port,” thus letting them know they should instead a.) use conventional weapons, b.) acquire nuclear/biological materials already inside the United States, or c.) enter via uncontrolled border space. If I, in three minutes, can think of three easy ways around a measure that will take billions of dollars to implement, it’s not very cost-effective.

He discusses the difficulties in information sharing between law enforcement and military agencies, clearly seeing these as an unalloyed negative. He’s right that there have been clear communications breakdowns, where these organizations had information that they were legally free to share, but chose not to out of myopia or the desire to preserve the institutional sovereignty of their silo. Despite the Central Intelligence Agency being founded to ensure all military and civilian intelligence agencies share information, it has in many cases become the most isolated hoarder of information of them all, and this is a problem. However, in other cases the obstacles to information-sharing are the civil liberties guaranteed by the Constitution. Giuliani has no issue with sweeping these away — this is, after all, the person who claims “Freedom is about authority. Freedom is about the willingness of every single human being to cede to lawful authority a great deal of discretion about what you do. You have free speech so I can be heard.” (That quote is not taken out of context in any way. He did not, however, go on to add “War is Peace. Freedom is Slavery. Ignorance is Strength.”)

Judicial oversight is not inimical to detecting and stopping international terrorism. Judges do not want terrorist attacks to happen, either; these protections exist to ensure that normal people are able to live their lives without constant monitoring. Surveillance is not unintrusive. Comamnd-and-control executives like Giuliani think that it does not matter if people are being watched, as only the “bad guys” will be prosecuted, but this simply isn’t true. First of all, people change their behavior when they know they’re being watched. It has a chilling effect not just on actually criminal behavior, but also on any behavior that people consider “socially unacceptable.” Surveillance drives everyone toward the mainstream center of society, homogenizing them; it creates the very opposite of a free society. (For a chilling illustration of this, I highly recommend Charles Stross’s sci-fi novel Glasshouse, one of the best and most terrifying books I’ve ever read, though it requires a high tolerance for transhumanist concepts.) Second, who watches the watchers? Even if Giuliani’s motives are pure (they’re not), and he wants to use these tools of warrantless surveillance, imprisonment without trial, etc. only against international terrorists, no one can possibly believe the entire law enforcement apparatus of a 300-million-person nation is entirely free of corruption and petty tyranny. Security has a cost — Giuliani looks only at how these measures benefit security, ignoring their unintended consequences. Security is of limited value — a terrorist attack is tragic but it does not end the world. We must not embrace “security at any cost” — instead we must consider security at a cost that we can bear, and most importantly, not allow the cost of security to exceed the cost of terrorism.

Giuliani also wants a “good Samaritan” law for people who report suspicious activity, protecting them from lawsuits. This is a terrible idea. Lawsuits are there to provide a cost for making a false of frivolous report — people will still report the man walking down the street with a pile of dynamite, but they think twice about reporting possibly-suspicious but almost certainly innocuous activity, like speaking Arabic in an airport, or loitering in a parking lot. Making reporting costless means you’ll get an inevitable excess of it, resulting in both the chilling effect of universal surveillance and a waste of law enforcement’s time. When people are encouraged to report everything unusual, you drown in reports and make people paranoid. This teaches people to react to the unknown with fear — that is, it accomplishes precisely what terrorists aim to accomplish. People reporting suspected terrorist activities should not be immune from lawsuits; rather, courts should decide whether the report was reasonable and take appropriate action. Often the reporters should be held blameless, having had a reasonable reaction that turned out to be incorrect, but doing so automatically makes filing false reports a simple way for private citizens to use the nation’s law enforcement apparatus as a means for private revenge.

Giuliani also calls for “tamper-proof biometric ID cards” for all non-citizens. As a security professional I can’t help but chuckle when anyone uses the word “tamper-proof.” But there’s nothing terribly wrong with this… except that it doesn’t do any good. We already know when people enter the country legally, and we identify them then; if they sneak in, they’re not going to have a “tamper-proof biometric ID card” any more than they have a regular ID card now. In addition, identity alone does not provide security. The fact that you know who someone is does you little to no good if he does not have a background in committing terrorist acts. And if he has a background in committing terrorist acts, why would you hand him a “tamper-proof biometric ID card?” Just deport him!

Giuliani supports fences around borders and stepping up guards, but claims to want to avoid turning the nation into a “fortress” in order to “deepen the connections between America and the Islamic world that will prove essential in prevailing over radical Islamic extremism.” On one hand, he’s on to something there — the only way to truly prevent terrorism is to eliminate the motivation for terrorism. Otherwise, 100% prevention is impossible — total prevention requires that you succeed every time, while the villains only have to succeed once. On the other hand, he simultaneously advocates precisely the foreign policy that creates that motivation — worldwide interventionism and American control and support of often-corrupt foreign governments. Now, the fact that a given policy makes people want to kill you doesn’t necessarily mean that that policy is wrong – but it is a cost of that policy that must be taken into account, and to claim that it will not have this effect is disingenuous.

Stepping up epidemiological surveillance and data gathering is the one good idea Giuliani has. Not only would it be helpful to detect bioterror attacks, but more importantly, it can help detect and contain natural pandemics. The emergence of a serious disease threat at some point in the future is a certainty, and unlike surveillance of people’s activities, this sort of surveillance has very little civil liberties cost.

Giuliani is obvious very proud of New York’s CompStat method of crime detection and prevention, given his desire to apply the same methodology to everything. For terrorism and border control, it makes some sense, as these are essentially law enforcement problems with a lot of parallels. However, for emergency preparedness it does not. Dividing up funding based on “need” determined by a statistical formula is absolutely certain to result in “gaming the system.” Emergency preparedness must be decentralized; there is no way for the Federal government to take care of it on a nationwide basis, or even to effectively coordinate and monitor it. Fundamentally, preparedness requires having appropriate materials on site and appropriate plans made, and no one can make those plans from afar.

Finally, Giuliani gets to the putative subject of the essay, resilience. He says, rightly, “Government should harness the inherent strength of the American people and the private sector in order to build a society that may bend—but not break—if catastrophe does strike.” It is somewhat ironic to hear this from Giuliani, who has just spent the preceding 30 paragraphs calling for increased central control of everything. His entire resilience proposal is as follows:

• Create government-organized response teams of private citizens who have been trained and equipped by government to respond to disaster,
• Pass a law shielding people from lawsuits if they are trying to help in disaster response, and
• Set government standards for how businesses, citizens, and charitable organizations should respond to disasters.

Ah, for every problem a government solution. This is precisely what resilience isn’t. A resilient society is one that responds to and recovers from disaster on its own — one that is not broken by disaster but continues to function mostly unchanged. The model of a resilient society is England during the IRA period: terrorist attacks happened, and life went on largely unchanged.

Western society is still phenomenally resilient, but not as much as it once was. You cannot build a resilient society using only government. A resilient society comes from a variety of factors, and these can do more to protect against the impact of terrorism than any technological or centralized security measure. They include:

• A culture of hope. People have to believe that every terrorist attack is an abberation, and that life will return to normal. This is what prevents a localized disaster from having repercussions on an entire nation for years to come; without this, with a culture of fear instead, the damage of a terrorist attack is multiplied a hundredfold.
• A citizenry that trusts itself. People must believe they are competent to solve their own problems, so the first reaction to a disaster is not “how will I get help,” but rather “what do I need to do?” Government cannot save everyone; if the able-bodied and passably intelligent people save themselves, government is freed up to help those who genuinely need it, and not simply those who abrogated their responsibility to plan.
• A populace that cares for others while still expecting them to take care of themselves. When disasters like Hurricane Katrina or 9/11 occur, there is an outpouring of charity from the populace to help. It doesn’t take government to solicit this; general benevolence will do, the desire to help anyone hurt by a disaster rather than using disaster as am impetus to hoard more for yourself and your tribe. However, people also must recognize the limits of charity, and be willing to go back to their own lives as time passes.

All of these are cultural shifts; we can’t impose them, and as Giuliani is running for head of government, it makes sense for him to talk about government actions. However, the statements he’s making are precisely what damages resilience. When all we hear from government is how they are expecting impending doom, and how government will save us when it happens, it does not teach us to have hope, trust ourselves, and help others! It teaches us to always anticipate disaster, do nothing and wait for help when it happens, and expect the government to do all the helping. Regardless of what the government does, this rhetoric from our politicians itself reduces the resilience of our society.

a

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.

a

This is not an uncommon perception.  Many people who think nothing of handing over their credit card or writing a check when at a store or restaurant hesitate to use the same card online, regardless of communication protections (e.g. SSL/HTTPS), third-party assurances like the preposterously-named HackerSafe, or the size and stability of the vendor.  After all, it’s the Internet, there are bad people out there.

However, the perception just isn’t true.  There are two ways in which the Internet particularly helps thieves, though:

1. Once they’ve stolen an identity or credit card number, thieves often use the card online, as they don’t have to present themselves (and thus show up to witnesses and potentially security cameras) to use the card.  This is actually probably what the credit card company in my experience meant — not that the transactions are more dangerous, but that fraudsters often use stolen cards online.
2. Hackers stealing credit card information online often steal entire databases.  They don’t steal your credit card while you’re buying something online — they break into the online store and steal everybody’s card.

However, they could just as easily have broken into the servers of a brick-and-mortar store — it’s not the fact that you used the card online that makes it possible for them to steal it, it would have been just as at risk handing it to a cashier.

In many ways, it’s a lot more risky to make non-cash payments in person!  When you hand your credit card to a waiter or clerk or cashier, they could easily copy the number, expiration date, and CCv2 code (the three-digit code on the back than an online site often won’t even get.)  With a debit card, they have the opportunity to watch PINs being typed.  Whereas in an online store, only relatively few, well-paid professionals will have access to your data (system administrators, etc.), every $7 per hour sales clerk can see a hundred card numbers per day, and probably has significantly more financial motivation to steal them (although in my experience, the fact that someone doesn’t need money won’t stop them from stealing it if they’re the type to steal — just look at Michael Milken, who defrauded people out of hundreds of millions of dollars at the same time he was making hundreds of millions legitimately.)

Some people — usually those of us who remember the days before debit cards — eschew all these fancy online and electronic forms of payment and instead stick to good old fashioned checks.  After all, no one can possibly steal those!  They’re paper, and have your signature on them.  This is the ultimate in perception differing from reality — it’s hard to imagine a less secure way to make a payment than a paper check.

First of all, there’s the ease of committing fraud with checks.  A thief with a stolen check (or deposit slip) has all they need to take money from your account — the routing number and account number (found at the bottom of the check in MICR letters.)  Note that the thief doesn’t need any kind of ID… or a PIN… or a physical card… or a CCv2 code… or even to know your name.  No, the numbers will do.  What can they do with a stolen check?  There are three basic things:

• Order up a whole book of checks with your information and account numbers on them.  No ID is required to order checkbooks online.  They can then spend these checks anywhere, and the bank will process them — you probably won’t find out until your account is empty and you start getting NSF notices.
• Remove the amount and recipient from the check and write it out to themselves instead.  This is a bigger problem for institutional checks, which are often printed on a laser printer.  It’s really easy to remove laser-printed text from an offset-printed check — just lay some Scotch tape over the laser text, rub it hard with your fingernail, and peel the text off.  Then you can print out a new amount and recipient with your own laser printer, and it looks just like the real thing.  Chemical agents (“check washing”) can do this with ball-point pen ink, too, though it’s not so easy.
• Issue a demand draft (“paperless check.”)  This is what happens when you pay by phone with your checking account number, or use an automated bill pay service, or send money via PayPal.  Using your routing number and account number, money is simply removed from your account and put into someone else’s.  No authorization or authentication is used, your name is not even required.  Yes, really.  Anyone can do this from any account to any other account.  For a while, you used to be able to do this from a web site.

Second, there’s the difficulty in getting your money back or even stopping the fraud!  With a credit card (and to a lesser extent, a debit card), it’s pretty simple — you call the bank, say you did not authorize a charge, and the credit card company removes the charge.  It is then up to them to prove you did make the charge, such as by getting a signed receipt from the merchant and matching your signature.  So long as you report the fraud within 30 days, you are not liable — the worst the card company can do to you is to cancel your card (but you still don’t have to pay for the charge you didn’t make.)  In theory, you’re liable for up to $50, but almost no card issuers really charge this since it’s terrible customer service (“Sorry you were stolen from!  Give us $50!”)

With checks, the money is already gone.  If you report a check as fraudulent, there is no federal law saying the bank is liable — it’s up to the bank’s own policies and in some cases a hodgepodge of state laws whether they have to help you at all.  The bank may get back to you in 60 to 90 days (during which you don’t have the money, even if it was the entire contents of your checking account.)  You have to report the fraud on a paper letter, with a notarized signature, usually by certified mail.  What’s more, you have to prove that the checks were not authorized — the burden of proof is on you, not the bank or merchant — and you have to do it to each party from which you’re trying to reclaim money.  If a thief wrote bad checks in 20 different jurisdictions, you may be dealing with this for years.

Worse yet, you can’t stop the fraud from taking place.  The thief can keep writing checks on your account even after you’ve started reporting them as fraud, and even after you’ve closed the account.  Every time the thief writes a bad check on a closed account (the classic practice known as “paperhanging”, a favorite of Frank Abagnale during his criminal youth), your bank will reopen the account and send you an NSF notice.  You have to dispute all of these, too.  And finally, your account (and possibly your name) will go into ChexSystems (the equivalent of the credit bureaus used to check people’s checking account history) as fraudulent, which will make it difficult or impossible to get new checking accounts for many years.  On the bright side, it will make it harder for the thief to open accounts in your name, but that’s little consolation since he can keep using the closed one he already has.

From a security perspective, checking accounts are horrid.  They come from a day when authentication and authorization were unheard-of, and security came mainly from the idea that no one would figure out how to subvert the system.

What can you do to protect yourself?

• Don’t use checks.  If any method of payment is offered aside from checks, use that.
• Don’t use demand drafts, either — they’re checks.  Don’t pay by phone using a checking account number — use a credit/debit card.
• If you must write paper checks, use them only to pay bills, dealing with relatively trusted merchants.  It doesn’t make you totally safe, of course, but it helps some.  Use gel ink to write checks (it’s harder to wash), or a dot-matrix printer to print them (the impact-printed ink is nigh-impossible to remove.)  According to Abagnale’s The Art of the Steal, this makes check-washing nearly impossible (though ordering up new checks in your name still works.)  Incidentally, The Art of the Steal is a fantastic (and very short) book, and I highly recommend it to anyone interested in security — it gives a great view into the security mindset, looking at all parts of a system and seeing how it can be subverted.
• Don’t store any more money in your checking account than you have to.  You’ll still have to fight every fraudulent transaction to stop the bank trying to collect it from you, but at least you’ll still have your money while you’re doing it.

The sooner we move on from this antiquated and unsafe payment system, the better.

a

The SAFE Act (Secure Adolescents From Exploitation Online; another case where the acronym almost certainly came first) aims to protect children and teenagers from exploitation by increasing enforcement of child pornography laws.  Not, on the surface of it, a bad thing.  The controversy comes from its means: it requires anyone operating an internet service to report not just actual child pornography, but also fully-clothed minors in “lascivious poses” (whatever that means) and any “drawing, cartoon, sculpture, or painting” consisting of an obscene depiction of minors.  This troubles people for two reasons: first of all, due to the vagueness of what is prohibited (can you tell if a drawing, cartoon, sculpture, or painting is of a 17-year-old or an 18-year-old?), and second, because of the apparent requirement that providers monitor all their traffic in order to make these reports.

According to C|Net News, the monitoring requirement would apply to anyone providing an open Wi-Fi node, such as coffee shops, restaurants, and even homes that simply don’t choose to encrypt their Wi-Fi, in addition to social networking sites, web-based email providers, domain name registrars, etc.  Were the bill interpreted in this way, this would place an impossible burden on any provider of connectivity — there is no automated way to scan the traffic of all your subscribers for vaguely-defined unlawful depictions of fictional minors, you would need to have a person manually inspect all the traffic, which is obviously impossible at any scale (not to mention a terrible privacy invasion.)

However, I think that this is an overly alarmist reading of the bill.  It’s certainly not the author’s intent (indeed, Rep. Rick Lampson’s office has responded to the C|Net article) for the bill to apply to every small Wi-Fi provider, though author’s intent is often beside the point once a law is passed.  More importantly, though, the bill does not mandate surveillance or detection at all — it mandates reporting if child pornography (or something that kind of sort of looks like it) is detected.  In other words, it forbids finding out about illegal activity and looking the other way; it does not mandate actually looking for it.  I think that Ars Technica has a much more balanced article about the bill.  Overall, I think it’s feel-good “for the children” legislation that won’t accomplish much (ISP’s are already required by law to report child pornography if they detect it, this just raises the penalties and expands the definition), and that prohibiting fictional depictions of children where no actual children are involved is a poor idea from a legal standpoint (since it is very open to abuse by subjective interpretations of judges, prosecutors, and jurors), but that this bill, if it passes — which is likely — will not impose a serious technical burden on service providers.

Meanwhile, the Electronic Frontier Foundation reports on the PRO IP Act (“Prioritizing Resources and Organization for Intellectual Property (PRO IP) Act of 2007″ — doesn’t anyone ever just name a bill and then come up with the acronym anymore?), which aims to fight copyright infringement in the typical ineffective way, presumably to shore up the music industry’s failing business model.  It increases penalties for peer-to-peer file sharing from their current ridiculous levels (which build animosity toward the recording industry via outlandish million-dollar damages levied against ordinary university students) to new even more ridiculous levels, while also creating a new $25 million federal bureaucracy to step up copyright enforcement.

Having a copyright system is important.  However, you would think that by now the music industry would realize that if suing customers for $250,000 does not stop piracy, the problem is not that they’re not suing them for enough money, and stepping up the penalties will have no effect.  People believe either a.) that they’re not doing anything wrong or illegal, or b.) that they’re extremely unlikely to get caught (this latter belief being true.)   In order to change this, they’ll need to either offer a legal alternative that at least approaches the convenience and usability of illegal downloading (which you would think would not be a high bar — BitTorrent is not very convenient) and is affordable for broad categories of consumers, or they’ll need to decrease the penalties while increasing the percentage of people who get caught.

With regard to the former, coming up with a pricing model seems to be their stumbling block.  Some customers buy several CDs a month, spending $100 or more on music.  These customers would love a monthly-fee option, and would pay a substantial amount for unlimited downloads.  Other customers buy one CD in a great while, and a subscription model is terrible for them — and thus they prefer individual song downloads like iTunes.  All customers hate DRM, as it prevents them from using music in ways we now take for granted (e.g. playing on multiple devices.)  What the music industry is doing now is akin to the government trying to win the War on Drugs by dropping defoliant in Colombia while doing nothing to reduce local demand — if the demand for illegal material exists, an infrastructure will spring up to fill it.

With regard to the latter, the recording industry faces a backlash when they impose penalties that vastly outstrip the perceived seriousness of the crime.  People have an idea of what fair use entails, and anything you could do with a tape recorder in the 1980′s pretty much fits in that category.  Thus, multi-million-dollar prosecutions of parents and students seems grossly unfair.  However, people also know that “everyone” shares files, yet we only occasionally hear about these huge lawsuits, and thus people assume it won’t happen to them.  The only people who believe they’ll get caught for file-sharing are those that already have.  However, if being caught file-sharing leads to financial ruin, this must of necessity be only a very small percentage.  If university students got caught by the thousand file-sharing and got fined $100 for it, they might consider legal alternatives a better option after a fine or two.

All this said, I think the future will eventually be in DRM-free downloads, and that that future will result in less profit both for recording companies (which may die entirely) and for hit artists (though it will result in substantially more profit for well-known local and regional acts, or less-popular national acts, which currently get almost nothing from the “star” system of the recording industry.)  It’s understandable that the recording industry and the most-successful recording artists want to fight this future, but I don’t see any way that continuously stepping up penalties for actions taken by half the American population is going to do it.

As for creating a new federal bureaucracy to fight copyright infringement, having law enforcement involved in what is essentially a civil matter (as copyright should be) is always dangerous, because it eliminates risk and return from the equation.  When something is a civil matter,  the injured party must decide that its worth its while to pursue a given enforcement action.  Industrial-scale piracy would certainly be worth a lawsuit; a university student running Kazaa probably isn’t.  However, when the injured party can simply ask the government to use taxpayer dollars to go after infringers, then why not go after everyone?  it doesn’t cost them anything; instead we get to pay for it.

DRM is a dead end; as a trusted-client problem, it is unsolvable.  I think this “get tough” legislative approach is a dead end as well.

a

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

To people not very familiar with cryptography, it may seem odd that random number generators are very significant.  However, all modern key-based cryptography is based on having a source of entropy (true randomness) — somewhere it can get a key that is unlikely to be guessed or otherwise determined.  When we talk about “40-bit” or “128-bit” encryption, we’re really talking about the key length, which provides an upper bound on available entropy.  Ideally, cryptography would be based on true random numbers, for which every bit of number is a bit of entropy.  However, true random numbers have to be generated physically — we have devices that do it based on radioactive decay, but you can also get it by asking a human to move a mouse around or bang on a keyboard, as PGP does when generating keys.  Thus, for most applications, we settle for pseudo-random number generators — programs which generate a stream of numbers that are unrelated to each other, have a uniform distribution, and are for most purposes entirely random.

However, a psuedo-random number generator usually needs a seed — a starting point for the generator.  If you use the same seed, you’ll get the same stream of “random” numbers.  Thus, the seeds chosen are usually very large numbers.  Cryptographic pseudo-random number generators are considerably more processor-intensive than the regular “random” number generators used in non-security applications, as they’re usually based on multiple iterations of a hashing algorithm.

What happens if your pseudo-random number generator isn’t very good?  Well, in the early 2000s, an online casino in the Caribbean (I wish I could remember the name of it to provide a link to the news coverage) lost several million dollars.  Apparently, a player realized that to shuffle the decks of cards, they used a standard, non-cryptographic random number generator — the sort of thing that’s built into Windows and Linux and such.  A shuffled deck of cards is very random — there are 8×10⁶⁷ ways to shuffle a deck, which is about 225 bits of entropy. However, the random number generator used only a 32-bit seed!  There are only 4×10⁹ 32-bit numbers.  This is still a lot, but with modern computer aids, it’s a manageable number.  So what did this player do?  He had his computer generate shuffled decks for each of the four billion 32-bit seeds.  He then wrote a program that let him enter specific cards that were drawn (e.g. “fourth card was a queen of spades, fifth card was a 9 of diamonds…”) based on the draws he could see (such as his own cards in poker, or the up cards in blackjack) and it would pare down the four billion decks to the ones that could have potentially produced those draws.

It turns out that when you know that almost all decks are invalid (not able to be generated by the random number generator in use), there aren’t many decks that can produce a given set of cards.  Thus, within 3-5 known cards, his program would spit out the entire deck, and that player could now predict the future.  He would know exactly what cards would be coming out, and what ones already had.  Thus, poker and blackjack were trivial, and he won a ton of money.

Many things in cryptography operate similarly.  If you can predict the random numbers being used, you drastically simplify cracking the code.  It is generally still not what a layman would call simple — but it brings a message from “even the National Security Agency with its thousand acres of supercomputers couldn’t crack it in our lifetime” to “it’s still out of reach for you and I, but, well, the NSA could probably crack it in a day or two.”  Well-funded, skilled adversaries can use any small defect in a cryptosystem that lowers entropy to shorten the time to break codes.

And that’s why the NSA would be interested in putting a back-door in a pseudo-random number generator.  Did they actually do this?  In my opinion, the evidence Schneier presents is pretty convincing, and while Schneier is today best known as a popularizer of security rather than a technical expert, one would do well to remember that he also wrote Applied Cryptography, a very technical book that sits on the bookshelf of basically every security developer, including mine.  The NIST publication presents four random number generators, based on different algorithms, and then recommends the use of one, Dual_EC_DRBG, that is about 1,000 times slower than the other three.  Unlike the others (Hash_DRBG, HMAC_DRBG, and CTR_DRBG), however, with this particular algorithm it would be possible to craft a set of input constants that are defective in a specific way — such that someone armed with a corresponding set of constants could predict the output of the generator.

Now, we don’t have proof that the NSA actually did this.  It’s possible that the input constants in the NIST publication are truly random, chosen arbitrarily, and the NSA does not have a matching key that will break the generator.  But the NSA is pretty smart, and almost certainly knew about the flaw in the algorithm — in general, people in the cryptographic industry assume that the NSA is a few years ahead of them and just hasn’t said so.  The old adage about not attributing to malice what simple incompetence will explain usually applies to government pretty well, but not to the NSA.

Really, this is a rather ingenious way to backdoor a crypto algorithm.  The normal method — just make a cryptosystem with a mathematical flaw or known backdoor key — has a serious issue: if you can figure out the mathematical flaw, so can someone else.  The NSA wants to be able to listen to our phone calls — it doesn’t also want every other country to be able to do so.  To backdoor a cryptosystem requires making it so you can read messages without also weakening it for everyone else.  This method does exactly that — without the specific numbers that match the provided input constants, the system isn’t flawed at all.  The NSA has the key (if, indeed, they do), and no one else does.  Putting it in the random number generator rather than the cryptosystem itself is a good way to draw attention away from it, too.

And if the NSA didn’t choose the constants to have a backdoor, why recommend an elliptic-curve based generator that’s three orders of magnitude slower than several other generators, all believed to be just as secure, that are based on much more easily understood mathematics like hashing?  It just doesn’t seem to make much sense.

a

Currently, the Pirate Bay is probably the world’s most popular BitTorrent tracker for downloading pirated media, receiving 1.5 million unique visitors a day.  With a quick trip to the Pirate Bay, you can quickly acquire any piece of music, any episode of any recent television show (usually within a couple hours of its first airing), any movie (generally while it’s still in theaters), etc.  Membership is required to enforce ratios (i.e. ensure you upload as well as download), but is free and open to all.  However, they’re unsatisfied with the BitTorrent protocol for a variety of reasons — chiefly the legal risk that their “customers” take.  Downloading from the Pirate Bay via BitTorrent runs two risks — first, that a copyright holder will grab your IP address and send a cease-and-desist order to your ISP, or worse, a subpoena which under the DMCA in the United States could carry a fine of tens of thousands of dollars, and second, that your ISP itself will cancel your subscription for using too much upstream bandwidth.  Comcast, in particular, is notorious for doing this without being willing to admit how much “too much” is, even as they cut you off for using it.

BitTorrent is an ingenious protocol.  The idea is to prevent massive load on single servers for downloading popular files by ensuring that everyone who downloads the file also shares it with others, even as the download occurs.  You don’t need the entire file to start sharing it — you register with a BitTorrent “tracker” like (The Pirate Bay) as working on a file, and all the other peers who either have or want that file are notified of your existence.  Peers then communicate with each other, swapping whatever parts of the file they have for the parts they don’t.  Thus, everyone’s upload bandwidth is being used at the same time as the download, unlike some previous P2P protocols.  This is used for many legal purposes — for one, Blizzard’s World of Warcraft uses it to update the game, to get around the obvious difficulty of having about 4 million of its 6 million subscribers all trying to download a 450-meg content update on the same day.  Thanks to BitTorrent, these updates go smoothly every time.

The problem, however, comes when the files being shared are illegal.  In the United States, uploading copyrighted media can result in rather substantial fines and statutory damages, and the RIAA and MPAA are actively suing people by the thousand to get them charged.  People want to download copyrighted media, so sites like the Pirate Bay exist.  But RIAA and MPAA agents can connect to these trackers, too — they’re open to all — and the tracker shares everyone’s IP address with them.  Since with BitTorrent, downloading and uploading go hand in hand, there’s no way to download copyrighted material without not only breaking the law but also advertising your IP to anyone who wants it.  There are blacklists of known RIAA/MPAA peers that will protect a pirate from the most ham-fisted detection, but it would be trivial for the copyright holders to evade this sort of blocking.  The Pirate Bay itself is largely immune to prosecution — they are located in Sweden, where copyright law subjects them to at worst a $300 fine every time they’re arrested (which has happened more than once.)  For the most part, legal threats just amuse them.  However, they’re concerned about their downloaders — as without people sharing files, they cannot exist.

In addition to the legal issues, there is the issue with ISPs.  “Unlimited” low-cost home broadband survives because people generally use only the tiniest fraction of their upstream bandwidth.  Comcast allocates me, and everyone else in my area, 384 kbit/sec.  If I used this bandwith to full utilization for an entire month, I’d have uploaded 118 gigabytes.  This is actually quite a lot — by way of comparison, playing World of Warcraft 24/7 for an entire month would use only 1.2 megabytes, or 1% as much.  This is fine by Comcast, because most of their users are only surfing the web, using only a few hundred kilobytes per month.  If everyone used their entire allotment of 118 gigabytes, Comcast would have to raise rates tremendously — from the current $50 or so per month to probably 5 times as much (or more.)  Compare business Internet rates (which assume you are hosting servers, and thus upload a lot) with residential ones (which assume you almost always download and upload very little) to see the difference. Instead, the many light users subsidize the few heavy users.  BitTorrent, in which everyone helps take load off servers by uploading everything they download, often many times over, threatens this model — if everyone uploads, Internet rates will have to go way up.

Thus, ISPs often try to stop BitTorrent and other peer-to-peer systems.  They use copyright as an excuse, but really, they don’t care about copyright — they care about cost.  Your downloading costs very little.  Your uploading to other customers on the same ISP costs very little.  Your uploading to the Internet costs them quite a lot by comparison.  The most primitive way they’ve tried this is simple port-blocking — they ban connections to the port TCP/6119 (BitTorrent’s default) on all their customers PCs.  This doesn’t work very well — for one, it’s obvious (BitTorrent simply fails to function), and for another, BitTorrent doesn’t need to use any port in particular.  Due to the tracker, other peers can find you no matter what port you choose, so simply changing the default in your BitTorrent client gets around this.  Slightly less primitive is “traffic shaping” — the ISP slows traffic to the default port, or it inspects all traffic for BitTorrent headers and slows any packets showing them.  (The latter approach is much more expensive for the ISP, since it requires a deep inspection firewall on all traffic.)  Once again, changing port is easy.  In addition, some BitTorrent clients have added a header encryption feature to evade traffic shaping — this limits which peers are usable (specifically, to only other peers that support the header encryption), but evades the traffic shaping.  Comcast has recently been using the Sandvine intelligent traffic management system, which has caused some controversy since it actually impersonates the user and sends forged traffic on their behalf, in a further attempt to limit BitTorrent and other P2P traffic.

The above problems are inherent to BitTorrent, and at first, they seem inherent to all peer-to-peer systems.  However, the buccaneers of the Pirate Bay have come up with a rather ambitious plan to improve on BitTorrent, developing their own protocol to better suit their needs.  They’re still working on the specification (there’s a wiki up for suggestions), but I find it interesting the security and privacy issues they need to overcome.  At first glance, it seems the problems they must solve are the following:

• How can people upload pirated files without their IP addresses being detected by groups like the MPAA and RIAA?
• How can people hide the use of a file-sharing application so their ISP does not detect it and cut them off?

But that’s actually rather short-sighted, and the suggestions on the wiki seem to indicate that they’ve realized that, too.  Creating a new peer-to-peer protocol to replace BitTorrent for pirates requires not looking at the current attacks, but rather at the threats themselves.  The problem they really want to solve is simply to defend against these two threats:

• Legal prosecution for uploading pirated files
• ISP retribution for uploading large amounts of data

This is rather different!  What they want to avoid is not detection per se, but rather the current consequences of that detection.  In addition, they seek to address several technical/functional shortcomings of the BitTorrent protocol while they’re at it (such as that the tracker software does not scale to their traffic volume, and that upload bandwidth use in BitTorrent is suboptimal — many peers are not uploading anything.)

Right now, ISPs face no legal liability for transferring all this pirated media, since they are only content-indifferent carriers.  Thus, a system that allowed users to also be content-indifferent carriers (i.e. sharing data they did not choose to download as well as the files they acquire on purpose) might provide some legal protection.  The problem is that right now, users are from a legal standpoint sharing media they have, not simply transmitting media.  Thus, a system of “reflector nodes”, where the aforementioned suboptimal bandwidth use instead has the empty bandwidth filled by data relayed from other peers might work.  The ideal from an anonymity perspective would be onion routing, as performed by the TOR Project.  Unfortunately, this causes a serious growth in bandwidth requirements for all peers — basically defeating the purpose of BitTorrent.  Some balance must be found between true anonymity, as can be provided by a high-latency encrypted mix network with traffic-analysis resistance like TOR, and simple obfuscation, or even juggling around what is transmitted to be able to stick to the letter of the law while violating its spirit.  No one would believe that pirates don’t mean to transmit pirated software, the mix network just makes it look that way, but it doesn’t matter if anyone believes it so long as they can’t prove it beyond a reasonable doubt in a court of law.

Avoiding ISP retribution is a bit harder.  You can encrypt and use random ports, thus making detection impossible.  However, this causes a problem — if everyone does this, and everyone uses P2P, then everyone’s Internet rates go up!  This is hardly the desired outcome.  An ISP administrator has contributed some novel suggestions regarding changing the protocol to help ISPs save costs.  If the peer-to-peer system would deliberately prioritize other peers on the same ISP (ideally using WHOIS/ARIN data, though even simple CIDR subnets would help) for uploads, it could drastically reduce the ISP’s costs.  Napster provides a good example — during their heyday, when Napster pirated transfers were killing college networks, they worked with universities to institute just this type of solution.  The Napster client would look for other users at the same university to share with, only going to the Internet when this failed.  This type of solution — not fighting the method by which ISPs hurt P2P but rather fighting its motivation — is bound to work better.  It’s a good example of thinking about the threat, not about the particular vulnerability.  In addition, it’s probably the only way to fight things like Sandvine (which, due to the way it works, can’t be stopped by a BitTorrent client unless it went to full encryption with all the negative effects that has — lightweight ways to evade Sandvine require patching the TCP/IP stack and altering RFC-mandated behavior, which is doable by people willing to hack their OS but not something you can just bundle into your P2P software.)

Another issue that the Pirate Bay has is with fake files.  Sometimes, a user (either an RIAA/MPAA shill or just someone who likes being obnoxious) will upload a file of the approximate right size with a filename matching something new and popular (like a just-released movie or album) that contains no or bad data.  With nothing but the filename to go on, users download the fakes, causing the seed count to go up and making the fake appear even more “realistic” on the tracker — and hundreds of gigabytes of bandwidth are wasted.  Currently, the only thing to be done about this is to look at the uploader and ensure he is someone trusted, but identity is impossible to verify.  Some sort of digital signature/PKI system would be very helpful here.

Overall, it will be very interesting to see what they come up with.  Like all open-source projects, it may or may not actually get off the ground, and pirates are of course not well-known for their altruistic contributions.  However, it’s not likely the BitTorrent creators (who don’t get any money from pirates) will work on these problems, so it falls to people like the Pirate Bay to try.  Even if you don’t want pirated media, the resultant system could be useful for a host of purposes — the same technologies being used for fighting piracy and cutting ISP bills in the United States are used for hunting down dissidents and limiting free access to information in totalitarian nations.  In addition, a sufficiently large peering system with deep storage and forced reflectors (i.e. people sharing data they did not specifically choose to download or share) could result in a sort of distributed information well in which any human knowledge could be stored for easy access and rendered almost indestructible.  Criminals have been putting legitimate technologies to underhanded uses for centuries — an illegitimate technology can be put to beneficial uses as well.

a

Unfortunately, there is a slight problem with either solution: it’s pretty much impossible.

First, a bit about how ad networks work.  Whenever your browser loads a page with a banner or text ad on it, the page contains a link to the ad network’s web server telling it to load the ad.  As it does with any site, your browser first checks to see if it has a cookie recorded for that site.  If it’s the first time you’ve ever visited that ad network, then it does not; if you have visited before, then there is a unique ID number for you in the cookie.  The browser then sends a request to the ad network, along with a cookie (if any) and a referrer header (saying what page the ad was loaded from.)

The ad network site then looks up the ID in the cookie.  This ID is linked with a list of all the referrer headers it’s ever received from you — this is the “tracking” component.  It adds the new referrer header to the list, and then uses the list to try to puzzle out what sort of things you like and pick the ad it thinks you’re most likely to click on.  It then returns that ad.  If no cookie was received from you, it also creates an ID for you and sends that so as to set the cookie for next time.

That’s pretty much all it does.  There are variants, which also use script to inspect the pages you linked from and use that to make better predictions of what you want to see adds for, but the overall effect is the same.  The ad network doesn’t know who you are, or any demographic info about you — all it knows is that some person with a random ID has visited a specific list of sites.  In addition, there’s a simple way to dump all that tracking information — tell your browser to delete all the cookies (or just the ones for ad networks.)  Whenever you do this, the ad networks will all think you’re a “new” person and provide you with a new ID number.

So, how do we stop the ad tracking (should you even really want to)?  I can see a few possibilities, but all have some significant difficulties associated with them:

1.) Set a cookie that essentially sets your ID as “don’t track me, use random ads instead.”  Whenever you visit an ad network, this “do-not-track” ID is sent, and the ad network sends you back a random ad without bothering to record your referrer.  Issues: due to the same-site rule, this cookie must be set by each ad network itself.  So there’s no common registry — you have to opt out with each ad network, and then trust each ad network to continue to obey the opt-out.

2.) Install an app or modify the browser to dump cookies.  Works great; no more tracking.  Issues: also breaks half of the Web.  If you allow even per-session cookies, some limited tracking is possible, and if you don’t allow session cookies, you break pretty much all of the Web.

3.) Have your ISP scan all your web traffic, find cookies that are going to ad networks, and strip only those.  This makes the web work normally while killing ad networks.  Issues: requires all the ISPs offering this sort of technology to keep track of every ad network in the world so they know which cookies to block.  What about single-site ad networks? (e.g. the New York Times tracking which articles on their site you read and targeting ads based on those.)  There are probably tens of thousands of them.

Also, the above three examples are only pointing out issues when ad networks are not malicious – that is, they want to allow you to opt out if you so desire.  If they are hostile, then they can work around any of the above options.  They can simply disregard the do-not-track cookies and set a different ID, or track you via codes embedded in image tags.  The latter method is inferior, since it does not persist across sessions (it forgets who you are whenever you close your browser) without the cooperation of the actual sites the ads are on, but it does still allow some tracking capability.  Affiliate networks are constantly advertising and improving their “cookieless traffic” capabilities.

Of course, if the government cares to get involved, it can simply mandate that all ad networks offer an opt-out, and pursue legal action against any who don’t, or who evade their own opt-out systems.  However, what it can’t do is offer a centralized list like the Do Not Call Registry.  After all, the ad networks do not know who you are – they only know you are some random ID number who has visited various sites in the past.  Thus, they have no way to check against a list and see if you’re on it.  And since cookies can only be sent to the site they came from, the government site can’t set some kind of master “do-not-track” cookie — your browser would refuse to send the cookie to any ad networks!

However, before instituting a system like this at all, we should perhaps consider the unintended consequences.  The reason that ad networks institute tracking is that targeted ads are more valuable to advertisers than random ones.  A car company would rather show ads to car buffs than to people who don’t drive, and it will pay more for ads it knows are going to interested parties.  Thus, if ad networks cannot target ads with tracking, they will have to charge less for ads.  This means that sites will get paid less per ad for placing ad network links on their sites.  Therefore, eliminating ad network tracking means sites will have to carry more ads.  Is “more ads” really what we want here?  Are we willing to accept more ads to ditch the tracking?  How big a privacy threat is this, anyway?  There are people I don’t want to track my web surfing, certainly, but DoubleClick and Aquantive are not the people I’m thinking of here.  Perhaps what we need is not a way to opt out of ad tracking, but more limits on who can get that data?  Were ad tracking data illegal to resell and not admissible in court, would we care about it at all?  I’m not sure that I would.

Of course, much of this is moot if instead of opting out of the tracking systems, you just “opt out” of the ad networks altogether, either with a plugin like AdBlock (which advertisers hate) or a custom hosts file.  It doesn’t get 100% of the networks, of course, but it sure gets a lot of them.

a