The second day of BlackHat 2008 began with a keynote speech by Rod Beckstrom, the director of NCSC (the National Cyber Security Center.) Most of this consisted of painfully strained Civil War analogies and the overuse of the word “Cyber” to describe absolutely everything. He made some good points — specifically, that in order to truly solve information (er, “Cyber”) security problems, we have to know the desired end state, which is more than just fixing the exploits or vulnerabilities of the week. We don’t even fully understand the physics and economics of networks, security, and risk management. The economics of security has to be based around risk management — if the marginal cost of a security measure exceeds the marginal loss it prevents, it’s counterproductive (something the government seems to often miss when it comes to “national security” anti-terrorism measures.) He seemed overly worried about the IP protocol stack as a single point of failure, and wants to keep it out of the systems it’s currently out of (say, SMS, which works even when most of the cell network is down.) I find this overly alarmist mainly because the IP protocol stack has been constantly attacked and exhaustively examined for nearly thirty years, and even the hackers have pretty much given up on this sort of attack. Yes, a successful exploit of the IP stack that let you, say, reroute, modify, or destroy traffic would be catastrophic on the same scale as Kaminsky’s DNS attacks of the last month, but so would an asteroid strike — the potential impact is huge, but the likelihood is very low.

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.)

On further investigation, it turns out that there is a reason for the DRM protection on Qtrax downloads… it’s just not to prevent piracy.

When a Qtrax-downloaded file is played, the WMA licensing notifies Qtrax of the act — so that they can divvy up advertising revenue from the site based on what people are listening to.  Since the Windows Rights Management system lets them require a bit of netcode to be run when you listen to a song, this works.

However, it still won’t fix the existing problems with DRM — specifically, that non-DRM-enabled players won’t be able to play the files (they claim they’ll be offering iPod-compatible tracks, and worry about Apple blocking them, but there’s no word from them on how they’ll do this, since WMDRM tracks won’t play on iPods) and mobility between machines is difficult.  People will still be motivated to rip the DRM off the tracks (thus breaking Qtrax’s tracking system) for convenience, or to turn to pirate downloads.

My guess is that Qtrax would prefer to pay labels based on downloads, not song plays, but the labels wouldn’t go for it, or just couldn’t stand the very concept of releasing unencumbered tracks for free no matter how much ad money they got.

If this was the way the labels had released music to begin with, I think consumers would have been happy with it.  But now, after the history of DRM, I think the public perception of “bad juju” around anything DRM-encumbered may sink it.  We’ll see, though — legal and free pulls a lot of weight with consumers.

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

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

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

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

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

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

SecurityFocus reports that a patch has been issued for a vulnerability in the Macrovision SafeDisc driver.  Apparently, due to a flaw in how the driver handles configuration parameters (which probably means a garden-variety buffer overflow), it’s possible for a local user to use the driver to elevate privilege all the way to the kernel.

This sort of security flaw is a major problem with copy-protection drivers like SafeDisc; this is also the same basic issue as caused all the controversy over the “Sony Rootkit” of 2005.  Fundamentally, the purpose of any copy-protection or DRM system is to protect data from the user.  Thus, it is attempting to create a security boundary where none exists — to prevent the user, possibly a user with administrative privileges, from performing certain manipulations of data entirely under his control while allowing other manipulations (e.g. watching a film, playing a game, listening to a CD) to continue unhindered.  The problem is that it’s just data — what copy-protection and DRM vendors are doing is the equivalent to my trying to write a book, with normal ink on normal paper, that you can read but not copy, even by hand.  It can’t be done; there is no inherent difference between reading-to-read and reading-to-copy.

So instead, DRM and copy-protection vendors, like Macrovision, create a system that runs at a level of privilege above what the user can normally achieve — on a Windows machine, at least NT AUTHORITY\SYSTEM privileges, but often kernel mode drivers.   This driver then sits, Big Brother-like, above the user, watching his activities, and preventing “illicit” operations.  Meanwhile, while being immune to manipulations by the user, this supervisor must take orders from data — that is, Macrovision SafeDisc must be told by a game that it should check for copy protection and stop the game if it fails, while the Sony “rootkit” must be told by a CD that it should allow playing but stop copying.

Thus, the user’s computer is put into a rather odd state — the user doesn’t control it, a piece of supervisory code does.  And if that piece of code is flawed (as it was in both the Macrovision and Sony cases), attackers can write malware that issues instructions to that supervisory code, imitating “protected” media.

If you’re a non-Administrative user (such as almost all Vista or UNIX/Linux users, but only a few Windows XP-and-before users), you are protected from running code that does certain potentially-harmful things to your system.  You can’t write to the Windows directory, or modify installed programs, or register a driver.  However, these copy-protection drivers supply an end-run around this protection — you can supply data to the copy-protection driver (after all, you have to be able to tell it to check up on you), which means that any malware you run can also supply data to the copy-protection driver.  And since it runs with greater privilege than you, it can do all the harmful things you supposedly can’t.  Copy-protection drivers, to make content more secure for the copyright-holder, make your computer less secure for you.

From a theory perspective, the problem here is that there is no security boundary (a line which code and data cannot cross without being subjected to a security policy), on a general-purpose computer, between an administrative user and all the data on the system.  This is what the copyright-holders want, but it’s not really possible for them to get it.  All of these systems can be circumvented by simply placing a new supervisor above the one added by the copyright holder (e.g. run the system in a virtual machine, or with a kernel debugger attached, or in the most extreme scenario, just walk through the code execution by hand, choosing to ignore instructions you don’t like until you get a fully unprotected data stream.)  Thus, they fake it, in ways that make the system less secure, simply to make it more difficult for a nontechnical user to get the unencrypted stream.  The result is a simple arms race between copyright-holders and hackers, which has a side effect of harming innocent users by making them increasingly vulnerable to malware.

According to a recent Reuters article, the unrepentant pirates of Sweden’s The Pirate Bay are working on developing their own peer-to-peer networking system.  It turns out that this is a relatively fascinating security problem, even though in this case it’s the criminals needing the security, vs. the law-abiding companies trying to break it — a bit of a reversal, to say the least.

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 man named John Stottlemire has found himself in some legal trouble for developing a piece of software that bypasses the coupon-protection DRM used by Coupons.com. Essentially, to keep users from printing dozens of copies of one of their free online coupons, Coupons.com forces you to install some client-side software which assigns a unique ID to your computer, which the server uses to verify that you’ve printed the coupon only once.

This is a rather pitiful way to enforce security, because it relies on a trusted client. Never trust the client — anything on the end-user’s PC is totally under the end-user’s control, and thus can’t be relied on to enforce security policy. What Coupons.com has done here is no different from websites putting their input validation in JavaScript running on the user’s browser — as if the user couldn’t disable JavaScript, or even save the page to their own hard drive and edit it.

Stottlemire’s hack simply deletes the unique ID, so every visit to Coupons.com is your “first” visit. He’s now being sued, on the grounds that this is bypassing digital rights management, and thus illegal under the Digital Millenium Copyright Act. The DMCA is very broad, and does prohibit any kind of encryption-cracking for the purpose of defeating copyright protection, even if what you do with your encryption-cracking is otherwise completely legal.

However, this is a pretty dubious legal claim. No encryption was bypassed — all his hack does is delete files off your own computer. Essentially, it’s no different from deleting your cookies to make ad networks forget who you are. As Stottlemire says, “I honestly think there are big problems when you are not allowed to delete files off of your computer.” In addition, he’s cracking a system whose purpose is to give away free coupons, so it’s going to be pretty hard to demonstrate monetary harm here.

The DMCA is often ridiculous in that it attaches legal protections to systems that are painfully weak. After all, Stottlemire wouldn’t be in any trouble for, say, printing out Coupons.com’s coupon, and then making 1000 photocopies of it. Nor if he just used their printer app, but told it to print to an image writer (thus creating a binary file rather than a piece of paper) and then printed that repeatedly. But when he writes software to perform these simple and obvious tasks, suddenly he’s a criminal?

In Coupons.com’s defense, the reason that their security is so bad is that their problem is impossible. You can’t send an image to someone’s machine, then trust that the machine will do only what you want (print one copy) and not what you don’t (print 1000 copies.) Someday, DRM vendors may even figure this out.