Previous month:
December 2016
Next month:
March 2017

February 2017

Is this a hack or an attack?

An earlier version of this post originally appeared at ICANN blog on 15 Sep 2015.

Nearly every day, we see news stories or tweets that reveal another "cyber attack" against a well-known brand, bank or government agency are commonplace today. These are almost always characterized as sophisticated hacking schemes. Some are described as acts of hacktivism. In an effort to characterize certain attacks as the most sophisticated ever, one enthusiastic Wikipedia contributor uses the phrase advanced targeted computer hacking attack. However, the reality is that a cyber attack doesn't necessarily involve hacking, and a great many hacks have nothing to do with attacks.

What is a Hack?

1393811350_2280cecf0e_m
Image by Andrew Eland

The term "hack" was originally intended to describe a cleverly written or "coded" piece of software. Often, these kinds of software solved an immediate and thorny problem quickly and efficiently. For example, in the early days of computing, memory was a precious resource, so the developer of a piece of software that made remarkably efficient use of memory might have been complimented as having hacked a great bit of software, and he may have been acknowledged as a terrific hacker. The "hacker" label was a sign of respect. Unfortunately, hacking is now more often associated with cyber attacks, cyber espionage or online criminal activity.

What is a (cyber) attack?

The simplest definition is that a cyber attack is an criminal act, or an act of espionage, terrorism, hacktivism or war that is conducted wholly or partly in cyberspace. 

 

Are all cyber attacks conducted by hackers?

No. Invariably, news and social media channels characterize or glamorize attackers as talented individuals who write very sophisticated software. These characterizations are generally wrong in several respects; while there may be some talented individuals who write crime or attack software, much of what is used as attack software is often not very sophisticated but just clever enough to exploit a vulnerability. Very often, components of the attack software's "package" are not even the attacker's original work. In fact, it's increasingly common that individuals who launch attacks simply buy attack packages in underground marketplaces or download them from public repositories.

Do all cyber attacks involve hacking?

No. Let's use password attacks to illustrate. An attacker who uses social engineering to convince a helpdesk operator to disclose the user name and password for an account does not use a software hack. Such attacks, including some high profile Twitter account and DNS hijacking attacks, don't rely on hacking. Compare this to an attack where an attacker scans a network, installs exploit software on a vulnerable computer and uses that computer to gain access to a sensitive database. Here, hacking – the use of specially crafted software – is a critical component of the attack.

Does the distinction really matter?

Yes. Accurately characterizing a cyber attack may be helpful to your organization's incident response team or law enforcement. For example, if the attack was the result of an attacker applying social engineering to a helpdesk staffer, inspecting call or chat logs is more important than inspecting computers for unauthorized (exploit) software.

It never hurts to get the language right.


Protect your organization from expired name server domain threats

Matthew Bryant's recent post, Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target, describes attacks against authoritative name servers. These are the name servers that host DNS records for your domain name (A, NS, MX, CNAME, TXT...) and thus the definitive or authoritative sources for resolution, i.e., they host the database that applications use to resolve host names such as your web site name to an Internet address. 

Name server hijack example

Bryant's post describes scenarios where domain name resolution for an organization's domain name can be hijacked by an attacker. In one scenario,

(a) an organization has assigned authoritative name server hostnames from several domain names. This is an accepted best practice for name service redundancy. For explanation purposes, let's assume that the organization's domain is example.COM and the organization has hosted authoritative name servers at ns1.example.NET and ns1.example.TOP.

(b) through an error or oversight, the example.TOP registration expires and the organization fails to renew.

(c) the attacker discovers that example.TOP is available, seizes the opportunity to exploit the organization's error, and registers the expired domain name, example.TOP.

The attacker completes the registration process and provides a public IP address for a name server for example.TOP. The TOP registry publishes this in the TOP TLD zone. The attacker also creates a zone file for example.TOP and in this zone file the attacker creates an address record for ns1.example.TOP, the authoritative name server that the targeted organization uses. The attacker can now arrange that ns1.example.TOP resolves to an IP address the attacker controls, or can mimic the address records from ns1.example.NET and wait for an appropriate time to begin its attack.

Next, the attacker publishes bogus  zone data of his own composition at ns1.example.TOP; for example,  attacker may publish a wild card record that says "send all connections to any host name in the victimized organization's domain to an IP address that I control", where he can now host opportunistic content (e.g., pay per click advertising) or malicious content (malware, phishing).

There are now two different authoritative zone data sets: one that the organization publishes and controls at ns1.example.NET and one that the attacker publishes and controls at ns1.example.TOP. When users query any name in this now vulnerable zone, the user's computer will randomly use ns1.example.NET or ns1.example.TOP for authoritative name resolution and thus some users will visit the host the organization intended and others will visit the attacker's host.

Renewal Considerations for Domain Names, Revisited 

ICANN's SSAC wrote an advisory in 2006 to describe "incidents where, by choice or oversight, registrants allowed a domain name registration to expire, anticipating that no harm would come from allowing the registration to lapse".  At that time, the committee considered the incidents that illustrated how commercial risk, reputational harm or potential asset loss might ensue following non-renewals of domain names.

Matthew Bryant's post reveals a more nefarious non-renewal threat landscape, a hijacking of name service that allows an attacker to impersonate, deface, spam, or perpetrate fraud using the victim organization's web or other Internet services.

Fortunately, domain name registration protection practices recommended by ICANN's SSAC can help you mitigate threats of this kind.

Protect your organization from threats of this kind!

Consider implementing these recommended practices to minimize name server hijacking threats of the kind Matthew Bryant has discovered:

  1. Create complete and accurate copies of the domain name registration data (Whois) for all of your domain names and for all of the domain names that you use to assign your authoritative name server names Make certain that you create copies of your intended bindings of authoritative name server names to IP addresses as well.

  2. Gather abuse point of contact information for the sponsoring registrars of all of these domains and for any DNS hosting provider you use. You'll need these contacts for immediate notification, investigation and correction should you see unexpected changes.

  3. Monitor Whois for all your domain names and and all the domain names that you use to assign your authoritative name server names. You can easily write  and routinely execute a script using command line Whois executables and commands such as cron. Compare your routinely obtained Whois responses against your copies of the Whois you intended to publish. If they do not match, investigate immediately.

  4. Monitor the DNS to verify that the names of all of your authoritative name servers resolve to the IP addresses you expect to host your DNS information. Again, you can easily write and routinely execute a script to query NS resource records using command line executables such as dig or nslookup and commands such as cron. Compare your routinely obtained DNS responses against your copies of the responses you expect to receive. If they do not match, investigate immediately.

While you're mitigating this particular threat, consider adding domain name portfolio management as part of your organization's overall risk management program. Delegate the responsibility to manage all aspects of domain name registration to an individual or team, or choose from several DNS hosting or monitoring service providers who can do this for your organization. Whether in house or outsourced, staff assigned to this activity should manage approval, registration, brand protection, DNS hosting, monitoring and renewal for all domains you register directly. They should also monitor all domains that you depend upon for correct DNS operation of your domains as well.

Treat your DNS operations as a critical element of your online presence and you are likely to reduce your organization's threat landscape.