Rack of Ethernet switches.

General Cybersecurity Information

General Information About Cybersecurity

If your experience is at all like mine, you will find that you need to both educate and convince people — from the "on-the-front-lines" users to management.

Here's some help.

Telecommunication Outages

Big-Money Losses

Target / Neiman Marcus hack of 2013

Major U.S. discount retailer Target suffered a security breach between Nov 27 and Dec 15, 2013. Up to 40 million consumer credit and debit cards may have been compromised, including customer names, card numbers, expiration dates, and CVV codes, making this the second-largest retail cyber attack to this point (after the 2007 TJX Companies compromised affecting 90 million). Debit card PIN data was also stolen, although it was encrypted with Triple-DES (nice use of 1998 technology...), and the names, mailing addresses, phone numbers and email addresses of up to 70 million additional people was also been stolen.

The malware involved is called BlackPOS and Картоха. The second of those is spelled in the Cyrillic alphabet, maybe looking a little different in Italic, Картоха, and pronounced car-toe-kha and not cap-tock-sa.

News and details include:

Luxury retailer Neiman Marcus revealed a breach based on the same malware, running 16 July through 30 October 2014.. See a Reuters story of 12 Jan 2014 and an initial Dark Reading report of 13 Jan 2014; then a Neiman Marcus announcement updated 21 Feb 2014 and Ars Technica (24 Jan) and Dark Reading (23 Jan) analyses of a theft of 1.1 million customers' debit and credit cards. Also see the New York Times story of 23 Jan 2014.

Other Big-Money News

Cyberwar — Military applications of network attack and defense

This section grew enough to get its own page addressing:

Click here for that page.

COMSEC (Communications Security) — attacking cellular/mobile & GSM telephony

Harris StingRay mobile phone interception and tracking system.

Harris StingRay GSM / UMTS / CDMA2000 / iDEN intercept and tracking system, U.S. Patent and Trademark Office picture.

DNS (Domain Name System) Security Issues

DNS should work as follows:

  1. The human user types www.cromwell-intl.com into a browser. The browser recognizes that this is not an IP address, and it makes a library call to the resolver. That creates a DNS query packet asking for an A record for the fully-qualified domain name (FQDN). This is a relatively simple UDP datagram.
  2. That DNS query is sent to the client's nameserver. If you are reading this at home, that means the DNS server specified by your ISP when your system used DHCP to get its IP configuration. If you are at work, then it would be your corporate DNS server. Either way, the DNS server is willing to do some work on behalf of the client and answer its questions because it's a client.
  3. That nameserver (labeled "ISP nameserver" below) doesn't know and it doesn't know who to ask. So it asks a server authoritative for the entire .com domain, "Where is the nameserver for the cromwell-intl.com domain?", asking for an NS record. The root servers are authoritative for .com and so its IP address is coded into the DNS server software.
  4. The .com server answers the direct question and also passes along the answer to the obvious next question, "What are their IP addresses?". As it turns out, there are two. One question was asked, there were two answers and two additional pieces of useful information.
  5. Your nameserver now picks one of those servers and asks the original question, "What is the IP address for www.cromwell-intl.com?".
  6. That nameserver responds that www.cromwell-intl.com is really an alias. The canonical name is cromwell-intl.com and its IP address is 75.146.106.233. This information should be good for a while, feel free to cache it for 3,600 seconds.
  7. Your ISP returns that information to your client, which receives it and passes the information along to the browser application. It makes a connection to TCP port 80 on that IP address, and this page loads.
  8. Meanwhile your nameserver is caching that information in case some client asks the question within the Time To Live value.

Below you see those numbered steps as ASCII art:

[1,2] client -----------------------> ISP nameserver
              DNS query:
              www.cromwell-intl.com A record

[3]                                   ISP nameserver --------------------> .com name server
                                                     DNS query:
                                                     cromwell-intl.com NS

[4]                                   ISP nameserver <-------------------- .com name server
                                                     DNS answer:
                                                     cromwell-intl.com NS = ns31.domaincontrol.com
                                                     cromwell-intl.com NS = ns32.domaincontrol.com
                                                     Additional resource record:
                                                     ns31.domaincontrol.com A = 216.69.185.16
                                                     ns32.domaincontrol.com A = 208.109.255.16

[5]                                   ISP nameserver --------------------------------> ns31.domaincontrol.com
                                                     DNS query:
                                                     www.cromwell-intl.com A

[6]                                   ISP nameserver <-------------------------------- ns31.domaincontrol.com
                                                     DNS answer:
                                                     www.cromwell-intl.com CNAME = cromwell-intl.com
                                                     Additional resource record:
                                                     cromwell-intl.com A = 75.146.106.233
                                                     TTL = 3600 seconds

[7,8] client <----------------------- ISP nameserver <---> cache
               DNS answer:
               www.cromwell-intl.com CNAME = cromwell-intl.com
               Additional resource record:
               cromwell-intl.com A = 75.146.106.233
               TTL = 3600 seconds

What the attacker wants to do:
The attacker wants to fool many people into looking at the wrong web site. They build a bogus web site on some server. It looks like something people would trust, for example, a clone of the citibank.com web site. Of course, it is just going to steal information if anyone visits it and believes it's really Citibank!

They will then try to fool as many DNS servers as possible into beliving that the IP address for www.citibank.com and citibank.com is whatever IP address they have for their bogus site.

Note that they could have a digital certificate from Verisign or whoever, completely valid for their IP address and whatever their domain really is. Your browser would be happy to connect to that server via HTTPS and it would report no problem. You would have to examine the certificate details and see that it was issued to some organization in Russia instead of Citibank, and what is the probability of you doing that every time you use a banking site?

So how do the bad guys fool the world-wide DNS infrastructure?

Problem #1 — Stateless DNS
Early versions of the BIND DNS server did not keep track of which questions they had asked. If they got an answer, they assumed it was relevant and put it in the cache. So the bad guy does this:

Problem #2 — The Kaminsky DNS Vulnerability
Dan Kaminsky discovered a very serious problem in DNS and publicized it in the summer of 2008. Left out of the above explanation was the detail that DNS packets contain a field called the Query ID. This allows a DNS server to match answers to questions, and it allows newer DNS implementations with some sense of state to tell if a given answer corresponds to a question that they had asked.

The problem is that the Query ID is reasonably easy to guess in many DNS server implementations. The bad guy now:

This is also a cache poisoning attack, but it is far more powerful.

So, how do you avoid being a victim?

The djbdns DNS server by Daniel J Bernstein has correctly randomized both the source UDP port and Query ID since the beginning. Many people find his djbdns easier to configure than the much more commonly used BIND software from ISC.

Incidents and Anecdotes

Government Warnings and Reactions

Further Reading


Back to the Security Page