The Security Skeptic

One congressman's opposition to SOPA worth noting

On November 16, 2011, during a House Judiciary Committee hearing, Senator Ron Wyden asked that he be permitted to include a statement opposing the Stop Online Piracy Act. The full statement is published as a press release at Senator Wyden's web site. It is a thoughtful and carefully constructed expression of concern regarding SOPA and PIPA.  In his closing statements, Senator Wyden asks that members of Congress respect the following principles:

Photo by DonkeyHotey

"1.  Be deliberate.   While rights holders and law enforcement are understandably eager to go after bad actors, we must be mindful of the precedents we set here at home, and around the world. 

"2.  Get the scope right.  Narrowly focus law enforcement’s authority on those who are willfully and deliberately breaking the law or infringing on others’ property rights for commercial gain. 

"3.  Avoid collateral damage.  Rather than frustrating the architecture of the Internet or establishing a censoring regime, consider instead promoting approaches that empower users and do no harm to the ‘Net.  More simply, fish for tuna without catching dolphins. 

"4.   Promote innovation over litigation.  Our efforts should be to protect copyrights and trademarks, not outdated business models."

These principles align very closely with an Advisory my SSAC colleagues and I prepared entitled DNS Blocking: Benefits Versus Harms. In our Advisory, we explain circumstances and care exercised where DNS blocking is used today and recommend these as principles to guide any blocking actions. Reworded slightly from the Advisory, the principles Congress should consider follow:

1. Only imposelegislation on a network and users over which you exercise control.

2. Determine that the legislation serves the objectives and/or the interests of your citizens.

3. Implement the legislation using a technique that is least disruptive to network operations and users.

4. Make a concerted effort to do no harm to networks or users outside your legislative domain. 

The similarites are striking. It's both comforting and disturbing that there is one Congressman who appreciates the gravity of the issues and the consequences of hasty, poorly constructed legislation. If you are a US citizen, contact your congressmen and encourage them to read Senator Wyden's thoughtful statement opposing SOPA.

SOPA: a great example of failing to know your enemy...or your friends

Proponents of SOPA want Congress to believe that DNS filtering will strike a death blow to online piracy. They argue that preventing the domain names that criminals use for infringing sites from resolving to Internet addresses will prevent criminals from distributing copyrighted material or selling knockoff versions of "brand" goods. The premise is false.

Photo by LesHoward

Know Your Enemy

If we have learned nothing else about electronic crime in the past decade, we do know one thing for certain. Online criminals adapt.

When an attack, stealth, or evasion technique ceases to be effective, online criminals try something different. A recent article at Dark Reading reports that security consultants and government agencies are tracking a dozen groups responsible for advanced persistent threats. What these parties have learned about one group in particular provides a wonderful teaching moment for SOPA proponents. 

APT actors identified as the Comment Crew uses HTML comments (information for web developers that is not use by a browser to render a page) to remotely control infected computers that form its botnet. An obvious countermeasure here is to strip comments from web traffic. This will disrupt communications, the botnet will be contained, and additional measures will be taken to dismantle it. 

Blocking HTML comments will be effective against Comment Crew, but for how long? History suggests that the answer is "not long at all". Does anyone seriously believe that the Comment Crew will throw their hands up in dismay and abandon their criminal or state sponsored activities?  The Comment Crew will employ a different means to communicate with its bots; specifically, they'll find a way to bypass or evade the countermeasures deployed against them.  

An important aside here is that stripping HTML comments is a good example of a proportional measure. Organizations or ISPs will voluntarily implement the HTML comment filtering countermeasure at their own site. They will enforce it within the boundaries of their own administrative domain, and will try not to harm or interfere with the daily operations of other networks in the process. Blocking the domain names of every web site that hosts HTML containing comments is not proportional. It overreaches, the results are unpredictable, and there is a high probability of disruption of desired and intended operations or collateral damage.

An unintended consequence of implementing Draconian filters when a more granular solution would suffice is that not only will criminal actors seek a way to evade such measures but legitimate users will do so as well. In Mandates Can't Alter the Facts, Paul Vixie explains that users will evade mandated filtering by using any of "dozens if not thousands of off-shore Domain Name servers they can switch to with the click of a mouse." Paul's claim is corroborated by a recent Cisco 2011 Security Report that 7 of 10 employees admit to violating IT policies in order to access the Internet. We live in a world where the prevailing attitude is that Internet access is a basic human right, US citizens will no doubt scoff the law. 

[ED: With nearly perfect timing for my article, an Addon for Mozilla Firefox - DNS Evasion to Stop Oppressive Policy in America (DeSOPA) - is now available. "When turned on, DeSopa intercepts URLs, sends the base URL to three offshore DNS services via HTTP, makes a best effort to check that two of them are equivalent, caches the IP for the browser session, redirects to the equivalent URL using the IP, and substitutes out the domain name in the source code with the IP address for future requests."]

Comment Crew is one of dozens I could cite to illustrate that SOPA proponents neither understand nor respect their adversaries. SOPA presupposes that criminals, faced with a DNS filtering shock and awe campaign, will fold tents and leave the Internet. Good luck with this.

Friend or Foe?

Sadly, SOPA proponents neither know nor respect their friends nor do they distinguish friend from foe. Individuals who oppose SOPA are portrayed as "pro-piracy", insensitive to the harm and loss musicians suffer, and other equally ludicrous characterizations. 

Does anyone seriously think that the best Internet and security minds in the world have never considered broad brush filtering of domain names as a measure to stop online piracy? We have, and we concluded long ago that this measure will not work, is not scalable or enforceable, and not without consequences. Despite this, SOPA proponents argue something along the lines of "despite the warnings and criticisms you've offered regarding DNS filtering we still want to add the considerable weight of federal legislation and force everyone to use it because doing this is better than doing nothing." In doing so, these proponents dismiss and disrespect the members of the technical community that work daily to defeat all forms of online criminal activity. Ironically, some of these members are employed by the very organizations most vocal in supporting SOPA, and they are probably collaborating with security and law enforcement to takedown a piracy site as you read this article. 

A practical resource for managing advanced persistent threats (APTs)

You don't have to search very hard to find some Chicken Little fluff piece heralding sky-falling doom in the form of an advanced persistent threat (APT). If your experience is like mine, however, fewer than one in ten of the resources you find do more than tell you what an APT is, warn you that you are already a victim or a victim in waiting, or promise you that you'll be better protected if you buy *this* product.

Photo by Lori

Kudos to the folks at Public Safety Canada for compiling a concise report entitled Mitigation Techniques for Advanced Persistent Threats. They helpfully deconstruct APT by offering a practical, consumable interpretation of each term. 

Advanced

The context for Advanced, for example, is further broken down into sub-contexts. The Report explains that malicious software is not always advanced in the sense that it is "sophisticated" but that it is often readily available exploit code that is simply better leveraged than earlier attacks. Advanced applies more to the growing body of evidence that indicates that state actors and sponsors "select their targets and refine the attack such that selected individuals in targeted organizations become the conduit to the organization's information assets".

Persistent

The context for Persistent is also broken into aspects. The reconaissance aspects is a panoply of P's: the attackers are patient, painstaking, precise, purposeful, and persevering. The execution aspect of a APTs is very "spy" oriented: clandestine and credibly socially engineered.

Threat

The threat is simple: exfiltration of information of a sensitive or secret nature that provides an APT sponsor with "a strategic, diplomatic, military, competitive, technological or economic advantage." 

Most online resources I've found stop here (feel free to recommend any in a comment). This Report goes on to explain the chronology of an APT attack, describing each stage - reconaissance, social engineering, establishing backdoor and C&C, achieving the objective, and maintaining presence. This chronology is a great segue to the remainder of the Report because it gives context for the strategies Public Safety Canada recommends that potential target organizations should take, how to monitor for and detect potential APT activity, and mitigation measures.

The information Public Safety Canada shares in these sections is not radically new; in fact, there isn't a single monitoring, detection, mitigation or remediation measure that hasn't been recommended before. The value of these sections, however, is twofold: first, Public Safety Canada's taken the initiative to gather this information from reputable sources (Aus DSD, McAfee, RSA, GAIC...), consider the growing body of work, and then condense the information into a single reference. More importantly, by creating a single reference, it allows us to realize that defending against APTs is as much a matter of doing better what we do today, with existing instrumentation, as it is introducing new techniques or technology.  

I'm always excited to share when I find a resource that is FUD free and full of useful information. This Report doesn't contain a silver bullet, but it will lend clarity to APT discussions and it may help you define a better strategy for defending against APTs than you have today.

In search of... Foreign Language Spam Filter for Apple Mail (Mail.app)

Foreign language spam is a problem everyone shares, not just folks who read English. If you don't understand a language, and can't read the characters of the script used, you probably won't get much value from messages you receive. Worse, you won't understand the "text" of the links embedded in the message.

Common sense would dictate that you don't click on something you can't read but decades of evidence proves otherwise.  A practical solution to foreign language spam is to prevent it from appearing in your In Box.

If you are an Apple Mail (Mail.app) user, and your organization isn't filtering foreign languages at a mail server or antispam gateway, you'll find that filtering foreign spam is problematic for several reasons. First, there are thousands of languages. Many of these can be written using characters from one or more scripts and many of these can be encoded using  one of (again) many character sets. I receive mail daily composed using Arabic, Chinese, Russian, Japanese, and Korean. Examining the raw source email  From: and Subject: headers of these messages reveals they are encoded using UTF-8, windows-1251, GB18030 iso-2022-jp, KOI8-R, respectively. Filtering based on  these encodings alone is a messy Mail Rule.  

Filtering based on the "language" found in email messages has similar scaling and messiness issues. The problem is compounded by the fact that email messages encoded to support languages that are not represented using 7 bit ASCII can also have multiple body "parts" (as well as attachments) . Body parts are typically distinguished and bounded by the use of Content-Type: headers. Apple's Mail.app seems to examine only the first encountered of this header type, which is often (perhaps intentionally by spammers) multipart/alternative or multipart/mixed so a rule that is supposed to filter  text/plain; charset="windows-1251" as junk will fail to match.

I found a solution at Buzzdroid that works on the principle that certain words (of, the, and, is, a) are found in nearly any rationally composed English message body. Buzzdroi'ds logic is straightforward: if these words are not present, the message is probably not "readable English". A Mail Rule of this kind looks like this:

My variation to this theme (below) is working well, as the Junk folder illustrates:

This is an imperfect solution to be sure. For example, Exchange Calendar invitations match the rule. Tempting...  I created an exception rule "Calendar" and made certain the rule preceded the Foreign Language Spam rule.  Occasionally I receive email composed as if it were a text or Tweet and for these, I may whitelist the sender. After 10 days of testing, I'm happier with a 1 in 10 false positive in my Junk folder than the distraction of messages I cannot read in my In Box. 

As the Buzzdroid folks say, "Any Apple Mail Rule should only be the last line of defense against spam." This problem can be handled at mail servers or antispam gateways but there is an administrative cost for organizations with language diversity: while it might serve me to block all languages that do not use characters from Latin alphabets, many of my colleagues would be inconvenienced. 

I'm curious to hear from others whether a similar approach would work for other languages. If you come up with an Arabic, Chinese, Japanese, Korean, or Russian "only" Rule for Mail.app, let me know.