The Security Skeptic

Highlights from the APWG Global Phishing Survey 2H2012

Colleagues Greg Aaron (Illumintel) and Rod Rasmussen (Internet Identity) have published another comprehensive survey on phishing patterns, behavior and impact. With Greg's permission, I'm posting his summary of highlights from the Report.

The APWG Global Phishing Survey Report (2H2012) contains key stats and analysis for the time period July-December 2012, including what top-level domains were used, phishing site uptimes, and at what registrars phishers registered domain names.  

Highlights from the Report:
 

• Attacks made by compromising virtual hosting accounted for 47% of all phishing attacks in the period.  Breaking into hosting providers has been a high-yield activity of the bad guys, since it allows them to mount phish on hundreds of domains at a time.   Those compromised sites also have higher reputations than new domains.   This activity fits into a larger criminal trend: the targeting of shared hosting environments (notably WordPress, cPanel, and Joomla installations) to create botnets, wage DDoS attacks, etc. (pages 5-6)
• The number of domain names registered by phishers has dropped by 60% since 2011.   Instead, phishers are using alternatives that are more attractive – such as those mass compromises on shared hosting platforms,  and registering subdomains -- which can be cheap and are often not well-managed by their registrar/registry.   Phishers registered more subdomains than “regular” domain names (pages 16-17).
  
  
• On the other hand, Chinese phishers generally prefer to make domain registrations, as they continue their attacks on Chinese targets such as Taobao.com and CCTV.   Some Chinese phishers are also going after gaming site Battle.net a lot.  A set of small Chinese registrars has prevalent phishing registrations (pages 14-15).

 Skeptic: The report, as always, is well worth reading and sharing.

Protecting the world from YOUR network

Image by Trevino

I came across a firewall-wizards mailing list thread on DDoS from 2007 that reminds me of how long infosec practitioners have been encouraging, cajoling, or pleading with organizations and access providers to do their part to mitigate DDoS attacks. In a 28 November 2007 thread, Patrick Darden explains that:

Properly configured, a simple firewall CAN prevent most DOS attacks.

Check out this SANS bulletin on "Defeating DDOS". Yes, that is my name in the credits. Special task force back in 2000. Sigh, and still people don't know that you can use a simple firewall to defeat most DOS attacks... as long as you are protecting the world from YOUR  network.
...
http://www.sans.org/dosstep/index.php?portal=fa88d69a3aede10976f8f2dc977d796e

Note the date of the SANS report. In that 2000 report we find this still relevant - and still largely under-implemented measure as Step 1:

Step 1: Egress Filtering to Stop Spoofed IP Packets from Leaving Your Network

Not surprisingly, the March 2000 posting of this report nearly coincides with the publication of Internet Best Common Practices (BCP) 038, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.

Fast forward to 2006. ICANN's SSAC report SAC008  DNS Distributed Denial of Service (DDoS) Attacks describes attacks against root system and top level domain name servers, and makes the same recommendation (see my summary, Do More to Prevent DDoS Attacks).

In 2007, the infosec community is still struggling to convince organizations that egress filtering is, as Paul Vixie asserted here, "Edge source address repudiation -- the dropping of packets with invalid source addresses upon their ingress across a network edge -- has more immediate beneficial impact than improving PC security." 

One reason why infosec struggles with this message is that "beneficial" is not obviously "self-beneficial"; as evidence that such skepticism impedes adoption, here's another message from that 28 November 2007 thread:

I see nothing in that article that explains how a firewall can be used to defend against a DOS (or DDOS) attack.

All I see is how to avoid yourself from being used as the source of one - where source IP addresses are forged.

When I've got an army of 100,000 pc's scattered around the globe ready to try and connect() to your web server (without spoofing an IP#), how does anything in that article help?

My thinking then and now is that, if your organization is not implementing BCP 038 - if your firewall is not actively checking for spoofed source IP addresses in traffic that emanates from your network, PCs on your network will inevitably be among that army of 100,000+ PCs. My comment to the list:

1) stopping DDOS attacks directed AT you, from multiple (spoofed)
sources, is something few firewalls can do if the attack is
large/amplified/sustained. It's hard even with additional security
measures, and cooperation from upstream providers. If someone really wants you badly and has the "connections" (pun intended) he can make life pretty miserable for you irregardless of the firewall you use. [Anycasting helped root name servers withstand DDOS amplification attacks, perhaps this is promising for other applications.]

2) preventing hosts protected by a firewall you administer from acting as sources for (1) is something firewalls can do (at least in a limited capacity).

My experience is that many firewall admins worry about (1) more than (2) in part because DDOS attacks are familiar to the culture and the effects of a DDOS attack directed at your organization often has a financial and reputational impact.

Reconstruct the chronology of the Spamhaus or any recent DDoS attack and you'll see that neither Spamhaus, the financials, or nation-states were able to mitigate attacks without assistance, and certainly not relying on firewalls alone. To stop DDoS attacks directed AT you, you'll need a plan and partners (see my post, Preparing for the Inevitable DDoS Attack). 

DDoS attacks are orders of magnitude larger and more frequent in 2013 than ever. The DDoS problem never be mitigated if every organization and every Internet access provider only implements measures that are seemingly self-beneficial. If you only see egress filtering as a way to help others, you've failed to understand the nature of the problem and the solution.

 

Domain Seizures Act II: Minimizing Collateral Harm

In March 2012, and on behalf of the ICANN Security Team, I published a thought paper on domain seizuers. The paper helps folks ask the right questions and gather the right information as they prepare a court order, to make clear exactly what actions the issuer expects.

Photo by West Midlands Police

This first thought paper is not an endorsement of seizures. It acknowledges that domains will beseized and that people issuing court orders for those seizures need to understand how domain names and DNS work to ensure that the seizures are done properly and, more importantly, to insure against collateral damage.

Following the Microsoft/FS-ISAC/NACHA action against the ZeuS botnet in March 2012, Michael Sandee published an analysis of operation b71 where he explained that collateral damage is not limited to suspending or making legitimate domains or web sites unreachable, that a criminal enterprise the size of ZeuS will no doubt be the target for numerous investigations, and that absent sufficient information sharing, cooperation, coordination and trust among investigating parties, there is too much room for error or interference; simply put, one party's success can hamper the erstwhile and equally important efforts of others.

In my post, Domain Name Seizures Prominent in Dismantling the ZeuS botnet, I wrote

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.

Today, and again on behalf of the ICANN Security Team, I've published a second thought paper, Domain Seizures Act II: Minimizing Collateral Harm, that discusses the collateral harm resulting from operation b71, Jotform, and Mooo.com events and recommends steps that investigators can take to minimize collateral harm in future seizure actions.

A web  and PDF version of the paper itself are hosted at ICANN's web site.

Evidence and Privacy: ICANN and the DNS

I had the pleasure of speaking on a panel with Matt Zimmerman and Pim Takkenberg on Evidence and Privacy at the International Criminal Law Network  (ICLN) Conference 2012. Read the presentation from the embedded viewer or download the presentation here.

A Visualization of Country Code TLD Name Server Records

Using a copy of the root zone file published by IANA, I created a visualization of the number of name server name (NS) records each country code Top Level domain operator publishes in the root.

Putting this visualization into context, this interactive map shows that all the CCTLD operators have a minimum resiliency in "named" name servers of two (2) in the root zone file. It does not provide any insight into diversity (whether name server instances are geographically separated or in the same data center) nor does it illustrate routing path diversity. The "named" servers could be co-situated or geographically separated, unicast or anycast, or in the same routing/AS domain.

The breakdown (249 Latin string CCTLDs only, no GTLDs, no IDN TLDs) :

Graphic courtesy of Kim Davies, ICANN	# of "named" TLD name servers	# of TLDs
	2	11
	3	31
	4	33
	5	41
	6	51
	7	39
	8	20
	9	7
	10	3
	11	2
	12	1

A Chain Saw is a Poor Choice for Surgery and for Blocking Web Content

The Internet creates extraordinary opportunities for large populations to monitor and influence politics and lawmaking. Engaged citizens have raised firestorms against antipiracy bills, while powerful lobbies urged politicians to mandate the use of technical measures to protect copyrights. Demonstrators have blogged or tweeted about anti-government protests from rally sites, circumventing governments’ best efforts to prevent the news media from reporting on these events.

In these scenarios, lobbyists and governments looked at the technical measures enterprises and ISPs had used to control user access to or remove content, and they hastily concluded, “This works for them. Why not for us?”

There are several scenarios where the motives to block or remove access are controversial. In some cases -- when technical measures to block access or remove content are incorporated badly into laws -- you end up choosing a chain saw for surgery where a laser or scalpel would suffice. Worse, you often don’t accomplish what you intended.

Yar! Pirates!

In the alphabet soup of antipiracy and content protection legislation, the Stop Online Piracy Act and Protect IP Act are poster children for incorporating technology into law badly. These bills would have mandated the use of DNS filtering to combat illegal use or distribution of intellectual property and copyrighted material. These bills targeted rogue Websites offering access to copyrighted material. Specifically, they would have given the US attorney general the power to ask federal courts to order ISPs to prevent users from accessing rogue sites hosted outside the US by blacklisting the domain name (“DNS filtering”) and redirecting users to a page telling them the site violated copyrights.

This looks very similar to how an enterprise might configure its DNS servers when using a block list to filter spam domains. Those behind bills like SOPA see that this works for the enterprise, and they conclude it would also work at a national level. The difference is that an enterprise imposes the policy uniformly for all of its users and only for its users. The proposed bills targeted sites hosted outside the US. If they had passed, their mandated technical measures would have ultimately proven ineffective, because:

1. The removal orders could be issued only to US ISPs.
2. The orders would not compel hosting providers to remove content.
3. The orders would not compel non-US ISPs to change their DNS servers to block rogue sites or redirect pirate domain names to the attorney general's notice.

The bottom line is that the content would remain there to be found, and determined users could use a non-US ISP’s resolver to circumvent DNS filters. In fact, workarounds became available as anti-SOPA sentiments intensified.

Great walls of fire

If SOPA had become law, it would have caused Internet users to receive different answers from the DNS depending on which resolver the user queried. This is exactly the kind of behavior that organizations with mobile workforces encounter when their people travel to countries where access to content is restricted.

In such countries, IP address blocking and URL or keyword filtering are used in conjunction with DNS filtering or redirection techniques to ensure that only state-sanctioned material is available to the population and visitors. The DNS measures are applied today on domain names, but the addition of the XXX top-level domain has caused other nations to investigate whether it is practical to block top-level domains in their entirety. The worry is not whether nations will block TLDs, but what technical measures they would use, how these measures would affect the global DNS, and whether the global Internet will eventually balkanize.

DNS is a critical component of your infrastructure, and some of the issues I’ve been discussing may cause you to think more about how you’re providing name service to your users. (See: Preventing Access or Removing Content: Laser, Scalpel, or Saw? and Shutdowns, Suspensions, & Seizures… Oh, My!) For example, when you consider how DNS blocking is used today, you might include “we’ve been blocked” scenarios as risk factors. My guess is you’ll realize it’s important to stay familiar with pending legislation and know how to remedy false positives.

You should also be thinking about measures you can take to ensure universal resolvability of domain names for your users, especially your mobile workforce. Configuring end points you administer to use name servers or resolvers that you operate or have managed on your behalf may be a proper course for your organization.

 

Originally posted at The Champion Community 9 May 2012

Photos by StartAgain, robotson, redmind, LividFiction, teach42

Preventing Access to or Removing Content: Laser, Scalpel, or Saw?

There are many legitimate though controversial reasons to prevent users from accessing content. There are also legitimate reasonse to enact laws that call for the removal of content, and these are controversial as well. You may be familiar with the technical measures used to block access or remove content, because you’ve already implemented them to protect or manage content for your organization. But you also may be interested to learn about the unintended consequences when these measures are included in legal orders to remove or control content hosted on publicly accessible servers. Here are some examples.

Blocking a link

Links associated with malicious code or phishing campaigns are identified, verified as harmful, and distributed in "lists" maintained by MalwarePatrol, PhishTank, and others. Security products (antivirus, antispam, or firewall) make use of commercial-grade or in-house block lists (also called reputation data) to prevent users from visiting dangerous content. It’s important to note that users, businesses, or ISPs voluntarily use block lists to protect against infection, fraud, or impersonation. Block lists are commonly used to filter email messages containing dangerous URLs before they are delivered to users and to warn or prevent users from visiting dangerous Websites.

Photo by Andrea Pacelli

Removing a link

Blocking actions prevent users from visiting dangerous links, but other actions must be taken to remove the malicious content. Security professionals will often attempt to contact a site operator to notify it of the presence of dangerous content and to ask that it be removed. If the security folks cannot identify the site operator (perhaps as a result of subdomain registries) or if the operator refuses to assist, they may work with law enforcement agencies to obtain a legal order to compel cooperation. Blocking and removing links are surgical approaches. They affect only the identified content, which may have been hosted at an otherwise legitimate Website that was compromised and used by the attacker to host or direct users to malicious content.

Photo by Andre Weason

Blocking a domain name

When security professionals determine that a domain name is being used to support spam, phishing, or criminal activity, they can seek to block the domain name. "Harmful" domains appear in the SURBL and SpamHaus domain block lists (DBLs), among other places. This is a coarser approach than link blocking, because users cannot resolve any host name in a domain and cannot access any service associated with the domain name (Web, mail, file sharing). Blocking actions of this kind are again voluntary.

Link and domain block list providers are careful to minimize false positives. But it’s worth designating someone in your organization to be responsible for list removal and whitelisting services and for maintaining complete and accurate Whois information for all of your organizations’ domains.

Suspending a domain name

Security professionals typically query the Whois service to identify the party that registered a harmful domain name. If they cannot reach this "registrant," they contact the registrar (also available from Whois) and request that the domain name be suspended. If the registrar (or registry) determines that the registrant has violated its terms of service, it may act directly. In other circumstances, the registrar (or registry) may insist on a legal order before acting. Domain name suspension requests don’t always make clear what actions registrars should take. Loosely, suspend means, "Stop the DNS from resolving the IP address of the server that hosts harmful content." When this is the intention, a legal order or request typically instructs the registrar or top level domain (TLD) registry to delete the domain name and associated name server records from the TLD zone file, and the TLD name server for harmfuldomain.tld will produce "nonexistent domain" responses.

Photo by H Dagon

This may be an appropriate action for indisputably harmful domains, but it can have unintended consequences, because no host name listed in the harmfuldomain.tld zone file resolves. An incident involving Jotform offers a good example of the unintended consequences of taking this action instead of blocking specific content or an individual account in a multiuser Website. The entire site was taken offline, all the user accounts were unreachable, and email service was interrupted for the operator and users for several days. Consider whether your customer organization is prepared for a similar false positive scenario.

Other options permit continued monitoring or notification. For example, a legal order may instruct the registrar or registry to change the name server records associated with harmfuldomain.tld to a designated DNS operator, which will assume name resolution. The designated operator may be instructed to configure name resolution so that www.harmfuldomain.tld resolves to a Text of Notice page (as SOPA would do). Alternatively, the designated DNS operator may be instructed to have the name harmfuldomain.tld resolve to the IP address of a supervised botnet command and control host for traffic collection and analysis. Consider false positives in both scenarios and what these might mean for your organization.

These types of actions are performed every day, typically with very low false positive rates, minimal or no collateral damage, and due process observed. These actions are generally accepted as "appropriate and preventative," but it’s worth asking whether your customer is prepared to respond in a false positive scenario.

In my next and final post in this series, I’ll look at more controversial actions involving content filtering, DNS filtering, and the seizure of equipment, assets, or content.

Originally posted at The Champion Community 9 May 2012

 

 

Domain Shutdowns, Suspensions, & Seizures… Oh, My!

 

Images by poetography, opensourceway, isaacmao, Southworth Sailor

What do censorship, intellectual property protection, dismantling criminal botnets, identity theft prevention, and stopping online child abuse have in common? They all involve remediating actions that prevent user access to content or remove content entirely.

Judgments about access to content, of course, are highly subjective. You need only look at the debates over legislation (SOPA, ACTA, or CISPA), punitive actions (WikiLeaks) or state-sponsored control of communications (the Great Firewall) to appreciate that opinions vary and emotions run high whenever access to content is involved.

Why is Access to Content Controversial?

Much of the controversy surrounding access focuses on the motive, authority, or constitutionality of suppressing or removing content. But what’s often overlooked in these discussions is that the technical actions a security expert takes to prevent people from visiting malicious links, or the legal orders that grant officials the authority to remove a child abuse site from the Web, can also be used to suppress free speech.

In the first example, harmful content is identified, and users or their organizations choose to participate. In the second, law enforcement agents collect sufficient evidence to obtain a court order to remove a child abuse site. In the third, an action is popularly disputed on the basis that the content was taken down without consideration of a perceived human right.

Asserting or disputing the correctness of these examples requires an individual effort to distinguish between motive and actions. We must separate why an action is taken (e.g., to comply with a legal order) from how it is taken (e.g., taking Web content offline). We also must consider the actor (a user, a private enterprise, a government) and how the scope of the actor’s authority (domain) is defined and bounded.

Technical Consequences when Access is Denied

All this brings us to the consideration of some common technical consequences involving corporate datacenters, networks, and impact on users when access is denied. For example, when an enterprise blocks an entire Top Level Domain, it has a certain effect. When a sovereign nation chooses to take the same action, the impact is dramatically different. Much of the dialogue today about shutdowns, filters, blocks, seizures, and takedowns fails to consider the less-than-black-and-white context of the action. And this is what instigates such strong reactions.

Sorting through these issues is very similar to untangling fishing line. At this point, you may be asking, "What does any of this have to do with my day job as a network systems engineer?"

Beyond the possibility that certain business or customer communications could be hurt if universal resolvability were no longer assured, you may be interested because you understand how blocking works. You are either concerned or outraged that the same technique you’d use to block a phishing site can be used by a sovereign nation to suppress free speech and control the content you can access when you visit that country.

In the next installment of this three-part series, I’ll look at some familiar practices -- blocking hyperlinks or domain names -- in a broader-than-technical context to illustrate the different effects that motives, actors, and technical measures have on Internet users. In part three, we’ll look at the more complex scenarios, where the motives are controversial, the actions have more sweeping consequences, and the effects on Internet users can be unpredictable.

Photo by Modern Relics

Originally posted at The Champion Community 2 May 2012

Reducing Phishing Up Times

In Shadow Warriors, Tom Clancy relates events surrounding the 1985 hijacking of the Italian cruise liner Achille Lauro, one of numerous incidents that influenced the evolution of US special forces. Here's how Clancy describes the four men who hijacked the cruise liner:

"The terrorists were not dumb. They knew our reaction time, based on the distance that had to be traveled and the time the Washington decision-making cycle usually took, and they operated inside these times. Every minute counted."

Had Tom Clancy sought to characterize phishers rather than terrorists, he could well have written:

Phishers are not dumb.  They know our phishing reaction time, based on the time it takes to identify the phish site and the "web site takedown" decision-making cycle, and they operate inside these times.

The time it takes to get to a phish site is the sum of the time to identify an email as a phish, examine the phish URL, extract the domain from the URL, and then identify and report the phish to the domain registrant or web site operator. In most cases, these tasks are accomplished quickly. The "web site takedown" decision-making cycle can involve several parties: registrant, the web site operator's business and technical staff (who should remove the phish site), sponsoring registrar and in the extreme, a registry or a court of law. This cycle can prove a lengthy process.

What do phishing response times look like?

The APWG Global Phishing Surveys report Phishing Site Up Times biannually. The 2H2011 Report provides a graph of up times from 2008 through 2011.

In the graph, the mean (average) is larger than the median: the distribution skew is positive. The "tail" extends into multiple days and in some cases weeks or months.

How long is the tail? An ongoing APWG survey of companies reporting phishing incidents gives us some insight. We asked, "How much time elapsed from the first notification of a compromise and when the phishing web site was discovered?" The graph to the right shows that the while ~40% of discoveries and notices are less than one day, the tail among the 415 reported cases extends beyond 14 days.

Improving Reaction time

The mechanics of identifying, reporting, and removing phishing web pages - Clancy's "reaction time" - are becoming more familiar across the security and operations communities. As Rasmussen and Aaron report in 2H2011, this has proven beneficial in several respects:

"sites are now coming down in under 10 hours. That makes for fewer victims, which may partly explain why phishers are putting up more sites. However, if they continue to put up shorter-lived sites, their overall effectiveness is lower, and thus their 'costs' are higher. Making things harder for criminals and raising their 'cost of doing business' is a goal that all anti-abuse forces share."

As we move phishers from their comfort zone, they are responding by putting up more sites. This means that every organization with an online presence is both a potential target for a phishing attack and a potential host for a phishing web page. To continue to improve reaction times, every company should take steps to:

• "Harden" your web site against attacks.
• Scan your web site for vulnerabilities and mitigate these before you put it into production.
• Prepare a plan for how to respond to a compromise of your web site by phishers.
• Monitor your web site, your domain registrations, your brand, and your DNS for signs of a phish.

In so doing, you'll better protect your own online presence and your efforts to prevent your site from being compromised and serving as a phish page hosting site will help protect other online businesses as well.

Improving the decision making cycle

Clancy describes incidents in Shadow Warriors where special forces were ready to respond but missions were hampered due to poor coordination, lack of authorization or inadequate communications. Some of these same problems plague the "web site takedown" decision-making cycle. Your organization can ensure that you don't contribute drag to this  decision making cycle by making certain that all your comms channels ready and available in the event of an incident:

1. Provide complete and accurate contact information in your domain name and IP address Whois records. 
2. Keep accurate contact information for technical or abuse contacts at your sponsoring registrar, ISP, DNS and hosting provider.
3. Share internal contact information with all parties from whom you may need assistance in the event of an incident (e.g., registrar, ISP, hosting provider).
4. Join and participate in antiphishing community social networks or mail lists to stay informed, to seek advice from industry colleagues, and to establish contacts.

Helping to reduce the long tail of Phishing Up Times may seem like a strictly "pay it forward" effort, but any involvement in a phishing attack can have direct costs to your organization, so there is an element of self-benefit here as well.

How much of the web is IPv6 reachable?

Following the 2011 World IPv6 day, I published a post where I compared the Netcraft Top 100 Domains that returned AAAA records on World IPv6 day against the Netcraft Top 100 Domains that returned AAAA records about one month later. The number dropped from about 50% to, well, not nearly so many. One of my conclusions was that "It would be nice if more participants demonstrate a longer term commitment." Another was that "If there's a short list of priority issues to resolve for IPv6 deployment, engaging edge device manufacturers should be near the top."

World IPv6 "launch" day 2012 is come and gone. More ISPs, more edge devices, and a tad more traffic. But how much more? In light of the publicized rallying cry "This time it's for real!", and rather than repeat the same check, I decided to (literally) dig deeper to estimate how much of the web is IPv6 reachable.

On June 26, I downloaded Alexa's Top 1,000,000 web sites (csv), for no better reason than Alexa's data were freely available. Over the next week, I  batch processsed tens of thousands of queries of the form dig aaaa +noall +answer until I had queried 500,000 web sites.

As the graph of the distribution across the Top 500,000 web sites shows, IPv6 "adoption" is fairly consistent.

Other observations from these data: 12% of the Top 1000 web sites have AAAA or CNAME records 4.9% of the Top 500,000 web sites have AAAA or CNAME records Of the 14097 AAAA records, 13337 are unique IPv6 addresses The web site domains names span 207 Top Level Domains COM, BR, IN, NET, and RU have the highest concentration of domain names that are IPv6 reachable n this sample.

So, assuming that 5% reachability is an improvement over 2011, is this satisfactory progess for IPv6 adoption? What do you think should be done to accelerate adoption, or are you happy to let market forces shape or decide?