The Security Skeptic

APWG Global Phishing Survey 2H2011: Trends both encouraging and disturbing

Colleagues Greg Aaron and Rod Rasmussen have published the 2H2011 APWG study on global phishing trends. Some of the major findings from the report are encouraging. The average up time for phishing attacks has noticeably decreased, down from 73 hours in 2H2010 to a much improved 46 hours in 2H2011, with a median uptime of 11 hours. Most of the damage a phish inflicts occurs in the first two days of a campaign so the dramatic improvement in the average uptime is welcomed. While the median uptime for 2H2011 is roughly the same as 2H2011 and more improvement would be welcome (the 11 hours is a larger window than a suggested 4 hours, see Clayton2009, Moore2008) .

Also encouraging finding is that the number of brands targeted by phishers decreased. Well, this is at least encouraging to those brands that fell off the phishers' radars.  Those that remained targeted, however, are weathering a storm. Greg and Rod comment that "phishers launched fewer attacks on such targets through 2011, concentrating on larger, more prominent targets. We believe they did so because:

1. "There is less money to be made off the smaller targets. It is easier for phishers to sell stolen credentials associated with more popular institutions.
2. "Phishers advertise via spam. It is less efficient for them to spam out lures related to smaller targets, unless the phishers possesses a qualified list of e-mail addresses.
3. "There is a growing emphasis on gaining access to e-mail accounts, which enable phishers to spam from whitelisted services such as Gmail, Hotmail, and so on."

CNNIC, APAC Join the Hunt

The staff at China Internet Network Information Center (CNNIC) and the Anti-Phishing Alliance of Chine (APAC) provided more information about Chinese phishing than was available for prior surveys. These data allowed Greg and Rod to call attention to behaviors unique to Chinese phishers, who prefer to use malicious registrations to host phishing attacks, for example, than to host phishing URLs on compromised servers. The data also show Taobao.com as second only to PayPal as the most targeted brand.

Whois from Domain Tools

The 2H2011 Survey is the first in this series to analyze where phishers register domain names. This kind of analysis relies on acquiring the Whois records that reflect the registration data that was used by the phisher at the time of registration. This analysis was made possible via WHOIS data captured byDomainTools.com. Domain Tools attempts to maintain histories of registration records from the time of domain name creation, so their contribution was critical to this analysis. The scores for registrars with more than 25 phishing domains and 1000 domains (from the Report):

Subdomain registrations: 'told you so...

In November 2008, Rod Rasmussen and I published an APWG report, Making Waves in the Phisher’ Safest Harbors: Exposing the Dark Side of Subdomain Registries, where we observed that phishers were beginning to use what subdomain registrations to host phish sites. We discussed measures individuals and organizations can consider if they opt to make these harbors less attractive and effective to phishers. Apparently, few people paid attention, because phishers registered more subdomains in 2H2012 than domain names.

As with all the bi-annual reports of this series, Global Phishing Survey: Domain Name Use and Trends in 2H2011 analyzes data from multiple phish reporting and monitoring resources to assess phishing and e-criminal activity. Greg and Rod are also able to use past survey results to illustrate trends that reports from anti-malware companies often do not include.

The report is always worth reading in its entirety. It's always done professionally, with great attention to detail and a disciplined approach to intepreting data that is hard to find and easy to admire.

Domain Name Seizures Prominent in Dismantling the ZeuS botnet

On 19 March 2012 Microsoft, FS-ISAC , and NACHA filed a Complaint with the US District Court, Eastern District of New York, against thirty nine John Doe defendants who allegedly participated in a criminal enterprise, the Zeus botnet.

Microsoft alleges that ZeuS botnets have purportedly infected an estimated 13 million PCs and have been used to steal over $100M during the past five years. The official Microsoft blog post provides a summary of Operation b71, which involved seizures by US Marshalls of command and control servers in Scranton, PA and Lombard, IL., sinkholing of traffic for subsequent analysis, and the seizure of Harmful Domains and IP addresses used to manage and operate the criminal botnet infrastructure.

Photo by ElDave

Gary Warner and Brian Krebs have again posted excellent analyses of the ZeuS botnet takedown.  Rather than duplicate their efforts,  I’ll instead highlight what I thought to be aspects of the ZeuS Complaint that went beyond actions from earlier takedowns (see Coreflood). I’ll then focus on the seizure of Harmful Domains and comment on the value of providing complete and accurate DNS, Whois, and registry information in legal orders. 

The Complaint and the xTRO 

Microsoft, FC-ISAC, and NACHA identify the 39 John Doe Defendants by their fictitious names: the user IDs of email addresses of the defendants found in Whois records for the thousands of domains enumerated in the Complaint. The claims for relief include the usual suspects Microsoft has included in prior complaints against Rustock, Coreflood or Kelihos: computer fraud or abuse, spam, electronic communications privacy violations, trademark or Lanham Act violations, trespass, unjust enrichment...

New among the claims for relief is the allegation that the 39 defendants acted in concert and conspiracy and thus violated the RICO (Racketeer Influenced and Corrupt Organizations) Act.

John Does 1-3 are alleged to have organized the racketeering enterprise and John Does 4-39 to have contributed various skills to the enterprise: botnet, exploit, and web software development, mule recruiting, botnet and hosting administration, domain and IP registrations.  Botnet customers and "cash out" operators who sold credit card and credentials obtained via infected PCs were also listed.

The Complaint thus alleges that certain defendants conspired as a group to construct the botnet, others used (“leased”) to commit criminal acts, and still others turned stolen properties into cash.

The Temporary Restraining Order is ex parte because the fraudulently composed Whois records are the only identification available to the plaintiffs.The Court accepted the plaintiffs' claims that harms cited in the Complaint will continue unless the defendants are restrained, and ordered simultaneous actions at hosting companies (Continuum Data Center LLC and Burstnet Technologies, Inc.) 'to disable and seize servers and associated stored data' at hosting centers and to monitor and collect traffic for analysis.

Photo by xfordy

John Doe Defendants

The Court also ordered domain registries with US presence to assist in discovering the true identities of John Does 1-39, redirect traffic to servers at a Microsoft secured IP address and to disable Defendants' IP addresses.

It's noteworthy that the order sought to minimize collateral damage to parties that are not named as defendants but are affected by the seizure of equipment and disconnects.

Seizing Harmful Domains

Domain names and name servers play a prominent roles in the ZeuS criminal enterprises. "eCrime" name servers operated by criminals are used to resolve host names for command and control servers and for servers that host ZeuS files.  In Guidance for Preparing Domain Name Orders, Seizures & Takedowns, I explain that providing complete and unambiguous information to domain name registration providers can prevent confusion or delay, and may help prevent or minimize collateral damage. The ZeuS xTRO is a good case study for why I believe this guidance paper is important. 

In my thought paper, I point out that seizures typically instruct registries or registrars to modify the TLD zone file, the domain name registration record (and what is displayed by Whois), and the registry database (of domain names). In the ZeuS botnet xTRO, the Plaintiffs instruct the TLD registry operators to take the following action:

"2. For currently registered domains, the domain name registrant information and point of contact shall not be changed and associated WHOIS information shall not be changed;

"3. Domain names shall not be deleted or otherwise made available for registration by any party, but rather should remain active and redirected to IP address 199.2.137.141;

"4. Domain names shall not be transfered to any other person or registrar, pending further notice from the court.

"5. The Registries shall assume authority for name resolution of domain names to IP address 199.2.137.141 using the name servers of the Registries;

"6. Name resolution services shall not be suspended"

Instruction (2) is clear with respect to preserving registrant and point of contact information, but a consequence of saying only that "associated WHOIS information shall not be changed" is that some of the Whois returned is exactly what was in the registration data "pre-seizure",some of the Whois returned has the registrant/contact information the same as "pre-seizure" but the name server information is changed to NS1.MICROSOFTINTERNETSAFETY.NET, and Whois for some (try FILMV.NET) returns conflicting NS data from the the "thin" .NET registry and the sponsoring registrar. These inconsistencies might have been prevented if specific instructions for how name server information associated with the domain name had been provided.

(3) and (4) instruct registries or registrars to set domain status codes. These are adequately clear, but to eliminate any ambiguity, the order might have specified the exact EPP Status Codes for both registrar (client) and registry (server).

(3) further instructs the registries to keep the domain names "active and redirected to IP address 199.2.137.141." Neither instructions (3) nor (5) make clear whether the Plaintiffs are asking for changes to TLD name server configuration, name service for each domain name listed in the Complaint, or hosting, so they could be interpreted to mean that the registries are supposed to modify the name server configuration information ("glue") in the TLD zone file. They could also mean that Registries should provide name resolution for the Harmful Domains (which would be well out of scope).

A DNS lookup using the dig command shows that 199.2.137.141 is asssociated with a name server, NS1.MICROSOFTINTERNETSAFETY.NET.  In this case it was easy to deduce that the Plaintiffs' intention was that Microsoft was to act as the authority for the nameservers and would provide authoritative name resolution for the domains from a name server operating at IP address 199.2.137.141. In other (future) cases, orders could more accurately say "we want TLD name servers to be configured so that the authoritative name server for all the Harmful Domains listed in the Complaint is NS1.MICROSOFTINTERNETSAFETY.NET/199.2.137.141". The Plaintiffs are then in a position to decide whether to host zone data for the Harmful Domains or to return NXDOMAIN for hosts in the Harmful Domains".

(6) instructs that "name resolution services shall not be suspended". A random sample of the names in the xTRO shows that some return non-existent domain (NXDOMAIN) and some timeout without a response. So by some definition, either (6) was not executed properly by some parties subject to the order but the instruction did not make clear whether "name resolution services" applied to the TLD, which is responsible for identfying the name server(s) associated with the Harmful Domains listed in the Complaint, or resolution of host names associated with the Harmful Domains.

Closing remarks

Inaccuracies and ambiguities are not uncommon in legal orders, in part because the courts or plaintiffs are unfamiliar with the DNS or domain registrations, are imprecise when using domain name-related technology, operations, and terminology, or pressed for time. Checklists like those provided in Guidance for Preparing Domain Name Orders, Seizures & Takedowns may be beneficial in minimizing omissions and inaccuracies. 

David Dittrich has written a brilliant post on the Zeus botnet civil action entitled Thoughts on the Microsoft "Operation b71". One of the points he makes dovetails nicely with what I've discussed here:

"The act of writing up a complaint, backing it up with declarations in support of the plaintiff's motions, and having a federal judge review and grant plaintiff's motions is a very clear, very thorough, and very public justification for taking bold action. This process explains of who is being harmed, how they are being harmed, what can be done to stop the harm, and why the court should grant the plaintiff's motions. If this were a federally funded research study on developing a treatment for a disease, it is this level of detail that must be provided in order to get approval from ethics review boards. If we require such justification of doctors doing risky medical research that can harm us, why should we not have to similarly justify risky actions we take to resolve infected computers? This is the kind of standard that is warranted in order to show defensible justification for taking risky and aggressive action, before such action is initiated."

A late, final word

A recent analysis of operation b71 by Michael Sandee calls attention to the easily overlooked issue that collateral damage is not limited to suspending or making legitimate domains or web sites unreachable. A criminal enterprise the size of ZeuS will no doubt be the target for numerous investigations. Absent sufficient information sharing, cooperation, coordination and trust among investigating parties, there is too much room for error or interference, and one party's success can hamper the erstwhile and equally important efforts of others. Looking ahead, providing clear instructions for domain registries or registrars can be an important part of the level of detail that Dittrich insists must be provided.  Coupling this with the kinds of reasonable efforts Sandee encourages to verify that domains listed in complaints are "harmful" when the legal orders are executed is equally important to minimize collateral damage.

More Thoughts on Damage Mitigation as the New Defense

Earlier this month, Kelly Jackson-Higgins interviewed me for a Dark Reading article, Damage Mitigation as the New Defense.  Kelly also sought perspectives from Richard Bejtlich (Mandiant), Neal Creighton (CounterTack), Bruce Schneier (BT Counterpane), George Kurtz (CrowdStrike), and Tim Rains (Microsoft Trustworthy Computing). In the article, Kelly explores “security’s new reality”, which put simply is a growing fatalistic acceptance that trying to prevent attacks by well funded and determined attackers is futile and that security professionals should shift focus to early detection, rapid mitigation, and damage containment.

The interviewed parties frame out the problem space and identify security technologies that are likely to play prominent roles in the solution space, but all acknowledge that the solution space is, at the moment, incomplete and that its efficacy is unproven. The resulting column gives a good insight into how the security industry may change course or re-invent itself in “era” of the Advanced Persistent Threat.

Editors often collect far more during interviews than they use or quote. With Kelly’s permission, I’m sharing a transcript of our interview as a complement to her column:

Jackson Higgins: “First, I’d love to get your thoughts on the premise that there’s now a philosophy of accepting that ‘you’ve already been breached, so focus on minimizing the damage.’”

Piscitello: “Organizations that are only now coming to the realization that their network perimeters have been compromised are late to the game. Malware ceased being obvious and destructive years ago. The criminal application of collected/exfiltrated data is now such an enormous problem that it's impossible to avoid. The notion that our only recourse is to focus on minimizing the damage, however, troubles me. It's a concession of defeat. I think this is wrong thinking. Would we respond to oil spills by only focusing on minimizing the damage? I'd rather have us adopt a more aggressive strategy where we actively seek out, identify (and where we discover) contain threats, identify root causes, and take measures to eliminate or mitigate these.”

Jackson Higgins: “Where did the security industry/vendors go wrong that led us to this phase? Did we fail as an industry? Why or why not?”

Piscitello: “Given the evidence, it's hard to argue we haven't failed. Plenty of blame and directions to point fingers and most of that is of little benefit.  Organizations have relied too long on traditional security architectures. Unified threat management, policy enforcement points, next generation firewalls are all incarnations of securing perimeters. They are relevant, necessary, but not sufficient primarily because they are mainly static defenses and most (especially the consumer, small business) largely rely on a knowledge based on what we've seen before. We need to be more proactive in looking for anomalous behavior.”

Jackson Higgins: “Where did organizations go wrong in how they deal with security?

Piscitello: “I think organizations have been too passive, placing too much trust in the security we've implemented to notify us when something's wrong with our network. We don't do enough active monitoring and analysis. Most organizations have little insight into what traffic is flowing across their network and through their firewalls. Most organizations don't really understand what the expected traffic mix looks like for their networks: they have no baseline to gauge "healthy and secure" We need this baseline to help us identify what is anomalous/suspicious and then we need to pursue these leads.

Jackson Higgins: “What is the next phase?

Piscitello: “Saying ‘the bad guy's in’ is marketing hype, not security practice. The solution involves more than re-packaging SIEM along with other or new monitoring, analysis and automated intervention tools. These play perhaps a bigger role in the future and it’s a good thing that we’re heightening awareness of how much they are needed. But we should also admit that we want too desperately to rely on automation. Adjustments to the human side – modifying user behavior, reducing administrative error, expanding the staff that defend networks and digital assets as well as their skill sets – are as desperately needed as new tech."

Presentation: Guidance for Preparing Domain Name Orders, Seizures & Takedowns

Here is a copy of my presentation, Guidance for Preparing Domain Name Orders, Seizures & Takedowns. The thought paper can be found here.

Why hackers keep breaking software: Insanity, or something more?

This Twitter thread instigated an email thread with Mitja Kolsek
(CEO of ACROS Security, www.acrossecurity.com, @mkolsek).
We agreed that it is worth sharing because the conversation goes 
goes to the root of several problems that frustrate not only Mitja
 and me, but others as well. Enjoy and join the conversation:-)

Skeptic: If doing same things over & over expecting different results = insanity why do hackers keep breaking software to show vendors it's breakable?

Mitja: Breaking software is also a social experiment, not just scientific/technical.

Skeptic: I'd love to hear why you think so but not in 140 characters.

Mitja: The premise that "doing same things over & over expecting different results = insanity" applies to repeatable experiments, where "same thing" actually means something very close to  "identical." E.g., physics experiments or highly simplified psychological ones.

The case with breaking software to show vendors it's breakable is far from that: not a single experiment can be convincingly repeated, not even with the same hacker and the same vendor (much less the same vulnerability). Much of the outcome depends on the mood, feelings, persuasions, ethics, culture, geography, ego and many other human/social parameters, making every try quite unique.

That said, the underlying hope of these researchers (occasionally including me)  is - among other things - that they will make a small difference in how the vendor percieves their products' security. And looking back a decade or so, there has been a difference made: without it, we probably wouldn't have SDLs, bug bounties and many vendors actually trying hard to make their products secure. (IOW, without it, security would be entirely a PR thing to them, but now it's only "mostly" that :)

But closer to your point, it arguably makes little difference if one finds and demonstrates a vulnerability in MSFT, Oracle, Adobe etc. products, as these vendors have already set their policies in stone, for better or worse.

Skeptic: Well put.

I do take issue with how we are trying to make software secure. You make the point that finding and demonstrating vulnerabilities isn't contributing to making products more secure. This goes beyond vendor policies and goes to a more fundamental problems with software in general; there's no real accountability or liability in selling software that is not secure. The same is not true in medicine or manufacturing (autos for example, and certainly every electronic device that runs software exposes a vendor to greater liability from faulty electrical problems than software). It's not merely policy, it's complete lack of incentive borne from a nearly self-regulating industry.

Mitja: Indeed. I went to the Schneier vs. Ranum discussion about software liability at RSA Conference - and Schneier (pro liability) just had better arguments for my taste. Besides, as hard as I try, I cannot think of any other way to elevate software security to the point where it would be damn hard to break it. Arguably the society may not actually need that level of security (hey, we haven't been hacked out of existence yet, so why worry?) but it is obvious that more and more critical processes are being more and more exposed to SW vulnerabilities: 10 years ago, it would not be possible to remotely attack an insulin pump or a car, 10 years from now there will probably be dozens of ways for embedded software to kill or injure you every day. And if we let that software be remotely exploitable, it won't be particularly good. Though the way things are going, that software will be 10 times larger than today, remotely accessible and with the same vuln/KLOC ratio.

OTOH, liability will likely be either avoided ("This product is not intended for use in this and that way, or any way") or passed on to developers or security reviewers - and finally to insurance companies, with the cost of insurance transferred to the buyers. I wonder if this cost will be so huge that it will suffocate the industry :/

Skeptic: I also think we have reached a point where everyone wants to break software and no one wants to write good (secure) software. Part of this is the result of hype, part glamor, and part lingering adolescence (not on everyone's part, but a great many who "profess" to hack certainly). How many conferences have speakers demonstrating cool hacks? Hundreds. Why? It's easy to show off what you accomplish, as in "look how I am remotely controlling the screen of this Android phone from my PC". How many conferences have speakers demonstrate how their software is resilient against malicious insertion of invalid input, or malicious installation of executable software? I won't say "zero" but let's agree it's a small number? Why? It's not easy to demonstrate, it's not viewed as clever. This is rather sad, don't you think? History and sports history in particular are full of examples of "great defenses". That so few people are interested in the glory of a defense, the pride of producing "safe" software, or recognizing this kind of excellence with the equivalent of a vehicle safety or medical practice excellence awards is surprising... and sad.

Mitja: I absolutely agree. Adding to the effect is the fact that one can actually *prove*insecurity (and glamorously demonstrate it on stage) while it is *not possible* (not just not-easy, like you said) to really prove security in any meaningful way. We have the notion of "secure until proven broken" engraved in our industry's DNA without reasonable expectations for that to change.

And I'm really not impressed any more with on stage live hacks, however clever the minds behind them - there's just too much of it everywhere and it's more like entertainment than security. (Although it's useful for offensive purposes.) It would be nice if SW got really hard to break some day. Then I would enjoy an occasional demonstration of a live hack.

Skeptic: This was a great thread, thanks.

I may cobble it together into a blog post, would you mind? It's the kind of discussion that ought to have more visibility than merely we two.

Mitja:  Fire away, just allow me to review it if you plan on quoting me :)