Target, Home Depot, Ashley Madison, and third-party vendors

If you are interested in writing about large-scale data and credit card theft, you could look to the Target, Home Depot, and Ashley Madison data breaches for inspiration. Much of what we know about these breaches comes from reporter Brian Krebs. His blog is fascinating, and I recommend it very highly. This post will refer heavily to his reporting.

(This post will refer to Target the retailer and targets of crime. Mind the capitalization to tell the difference.)

The retailer Target was the victim of a large data breach during the 2013 holiday shopping season. Criminals stole credit card information of 40 million customers and personal information (names, email and mailing addresses, phone numbers) of 70 million customers. The numbers here are so large that the thieves had trouble selling all the stolen credit card numbers before banks were able to cancel the credit cards, and some banks had trouble re-issuing cards, because the people who turn plastic into credit cards had a huge backlog of orders. (Target recently agreed to a $39.4 million settlement with banks and credit unions as a result of this breach.)

The picture that Krebs’ reporting paints about the Target breach is that it involved an external HVAC company that worked for Target. Someone at the HVAC company fell for a phishing attack, which probably installed a keylogger or some other malware on that person’s (the HVAC company employee) PC, and this enabled the criminals to acquire login information to servers that Target’s vendors use to interact with Target (for work orders, billing, etc.). The criminals were able to use this access to install malware on the point-of-sale (POS) devices at target stores. (Yes, there are probably several steps missing there, which I don’t understand, either, but it’s not the point of this post.) The POS malware was able to upload credit card data to another compromised server on Target’s internal network, and then that internal server exfiltrated the stolen data (gigabytes of it) to external FTP servers all over the world. (See Krebs’ coverage of the Target data breach for more details.)

Much the same thing happened to Home Depot in 2014. Criminals installed malware on thousands of self-checkout lanes at nearly every Home Depot location. The criminals got away with 56 million credit card numbers and 53 million customer email addresses. As happened with Target, the Home Depot network was initially breached using login credentials stolen from a third-party vendor. (Again, Krebs has more details about the Home Depot data breach.)

Although it didn’t involve credit card theft, the Ashley Madison story is similar. Ashley Madison is a social networking site created with the specific intention of enabling elicit (e.g., extra-marital) affairs. Someone managed to download and publish the account information of many or all of the AM users. Little is publicly known about how that information was acquired, but the CEO of AM’s parent company implied that it was the work of a non-employee who had previously had access to the AM information resources.

The takeaway here is something that might be useful for writing any kind of story about corporate hacking and espionage. In all three of these examples, a confirmed or suspected method of infiltration involved a vendor hired by the target company. Even if the vendor isn’t complicit, the vendor may be a softer target with lower standards of security (or with more access than they really needed). Breaching the vendor may give the attacker a foothold into the larger target.

Advertisements

January 2016 updates from Microsoft and Adobe

Microsoft and Adobe have released software updates for Microsoft Windows, Adobe Reader, and Adobe Acrobat. Both vendors rank these updates as critical.

Here’s Adobe’s security bulletin, and here’s the Microsoft security bulletin.

Being a sysadmin is not sexy (part 2)

In the previous post we learned a bit about servers and sysadmins, and how the sysadmin’s job is usually fairly unexciting.

But then occasionally something will go wrong. A server application which was working perfectly well five minutes ago is now giving the users nothing but error messages. This is when the job becomes terrifying, because some users feel compelled to explain to the sysadmin how (s)he has personally failed them. The phone starts ringing off the hook, the email inbox fills up in a hurry, and people stop by the sysadmin’s desk to point out the painfully obvious fact that the system is down. Boredom is far preferable to this.

When things go off the rails, there are a number of things the sysadmin can do to diagnose the problem:

  • She might look at a list of active processes running on the server to see if something important is missing. Sometimes a service will stop for some reason, and simply restarting the service will get things moving again. After everyone settles down a bit, the sysadmin can try to figure why the damn thing stopped in the first place.
  • A program called a packet-sniffer can help analyze the server’s network connections. It could be that something about the network (completely external to the server itself) has changed, and that this is causing connectivity problems. This is the sysadmin’s favorite explanation, because everything immediately becomes someone else’s problem, and it gives the sysadmin an excuse to go yell at the network pukes.
  • Log files may be the most common diagnostic tool. If the server application experiences some kind of problem, it will hopefully write a useful message to a log file. Often (not always, but often) looking at the log file will reveal the problem, and hopefully there will be a straightforward solution that the sysadmin can apply promptly. Getting things back to normal in a hurry is certainly a priority in these situations, but it’s not always that easy. Sometimes it takes a while to diagnose a problem, and the solution may require unscheduled downtime.

The adage about an ounce of prevention governs the work of an experienced sysadmin, who will expend no small amount of effort putting a lot of canaries in the coal mines. A big part of this job is avoiding common or recurring problems. Examples of this might include some of the following:

  • Setting up a process that emails the sysadmin when a hard drive starts to run out of space.
  • Reviewing log files every day. (This is deadly dull, but sometimes it identifies problems before they break things.)
  • Keeping a detailed list of upgrades and configuration changes so you can put stuff back the way it was days or weeks later.

Anyone who has been doing this kind of work for a while has horror stories, and I have a few of my own. I’ll write those up as short posts from time to time.

2015-12-28 Adobe updates

Adobe has released updates to Adobe Flash Player. This update addresses critical security problems. If you you have Flash Player installed on your computer (which is likely), please update it.

Looks like if you let Firefox and Google Chrome update themselves, that may be enough to update Flash Player in those browsers. Otherwise, the Adobe Flash Player page can tell you if you need an update (you may want to visit this page in each web browser you use).

For more technical information, see the Adobe security bulletin.

This bulletin also includes an update for Adobe AIR. If you think AIR is installed on your computer, here’s the Adobe AIR page.

Being a sysadmin is not sexy (part 1)

A sysadmin is someone whose job is the care and feeding of one or more servers (sysadmins frequently look after several servers). This is a job which is mostly boring (day-to-day stuff) but which is occasionally terrifying (when something unexpectedly stops working). There’s often not a lot in between those two things. If you are writing a story with a character who does this kind of work, don’t portray them as someone whose job is constant excitement, because no one will believe that.

A sysadmin’s celebrity among the non-technology people in the organization is often inversely proportional to how well she does her job. If this sysadmin is effective at her work, people tend not to know who she is. If that sysadmin is not good at her job, many people tend to know her name. This is a job where anonymity can be desirable.

Servers tend to run server applications (also known as services), which can be all kinds of things:

  1. A server might run an application commonly called a web server (Apache and Microsoft’s IIS are popular web servers). You typically interact with this service through your web browser.
  2. A server might be a file server. If you’ve ever used the “map a network drive” feature, then you’ve downloaded files from (or uploaded files to) a file server.
  3. If your organization runs a centralized accounting system, then that accounting system likely runs as a service on one or more servers. You might interact with this service through a desktop application or even a sophisticated web-based interface.
  4. email is another good example of a high-profile server application. Although users interact with email through a single desktop application (like Outlook), email usually happens by way of a pair of services: one for sending and receiving email (to and from other email servers), and one for retrieving email messages from the server to the desktop application.

A single server might run several different services.

Ideally a server and its server applications run smoothly and don’t need a lot of help beyond ordinary maintenance. This is the relatively tedious part of the job:

  • The server requires backups, which are frequently automated processes.
  • If the sysadmin manages a complicated application running on a server, that application may have many users. As people come and go, there’s a lot of giving this new person access to that, taking away that person’s access because they left, etc.
  • The server and its applications often have upgrades become available. This is a never-ending chore. It’s not uncommon for the organization to schedule a maintenance period during which the services will not be available to users. This is called “downtime,” and it is unpopular with users. The sysadmins use this time to apply the updates. This is typically routine, but can be stressful, because it can be difficult to recover from a failed upgrade (this may require restoring data and/or the operating system from a backup). These maintenance periods are commonly at night, over a weekend, or even during a holiday, which is not a fun time for the sysadmin to have to work.

In the next post we’ll look at what happens when things don’t go smoothly.

The worst explanation of networking, ever

(This post is going to introduce a lot of jargon, and I’ll probably refer to it from future posts.)

Making a network connection to a computer involves an IP address (the computer’s address on the internet) and a port number. This is a flimsy analogy, but you could think of it like finding your way into a house: the IP address (the host) is like the street address, and the port number is like which entrance to use (the front door, or the window on east side).

For example, most web sites are on port 80 or 443: 80 is the standard port for web servers, and 443 is the standard port for a secure web site (HTTPS). When you want your browser to display the CNN homepage, your browser figures out the IP address for http://www.cnn.com (which at the moment appears to be 23.235.44.73), connects to port 80 on that host, and begins an HTTP transaction to download the home page.

A firewall is network software that allows or rejects network traffic according to a set of rules. An organization which hosts its own web site might have a firewall which allows the Internet to connect to the web server on allowed ports like 80 and 443, but the firewall would reject other inbound traffic to that host.

A port scanner is a program used to interrogate a host’s ports, looking for services listening on those ports. If you point a port scanner at a web server, it’s likely to tell you that a web service is listening on port 80 (and maybe also on port 443). Port scanners are powerful programs which can be used in many ways. A company might hire a security analyst who would use a port scanner to identify weak points on the company’s network (a good analyst would also give the company some suggestions about how to address those shortcomings). A malicious person might use a port scanner to the same effect but for a different reason: the port scanner can tell the attacker the ports on which services are listening on the company’s hosts, identifying targets he or she might try to compromise.

Sophisticated port scanners can identify specific software products listening on a port, and even the version of that software. If a cybercriminal used a port scanner to determine that a host was running version 2.2.15 of the Apache web server, he could use a search engine to look for vulnerabilities in that version of that product. He might find that that version has a race condition error resulting in a remote execution vulnerability and that someone has published an exploit which takes advantage of that software defect. He could download the exploit and run it against the web server for any number of malicious purposes (like stealing otherwise inaccessible information, sending spam and phishing attacks, etc.).

nmap has been a popular port scanner for a long time (it was first released in 1997). In The Matrix Reloaded, Trinity uses nmap to port scan a host she wants to compromise. nmap identifies a vulnerable version of a network service called ssh, and she then uses an exploit to elevate her privileges on that host. This is a good (and rare) example of credible hacking in popular media: the writer(s) included enough realistic detail to make the scene plausible.

nmap has starred in lots of films.