Month: January 2016

Default passwords

A network router is a device which forwards traffic between two networks. Your computer is on one segment of the internet, and your favorite web site is (likely) on a different segment. There’s at least one network router between you and your favorite web site moving the data packets back and forth.

Routers will typically more-or-less work right out of the box, but they generally need some configuration to do their jobs well (and securely). Routers frequently offer a web interface for this: you connect a computer to the router, go to a particular web address (specified by the product’s documentation), and then configure the device for its particular purpose. For example, if you’re setting up a router for an elementary school, you might configure the router to send all web traffic through some kind of content filter.

More and more devices are like this: you buy a shiny new gizmo, connect it to your network, and it offers some feature you can control with an app on your phone. This is the “Internet of Things” (IoT):

Network-enabled security cameras are another interesting example of this kind of thing. Imagine being able to log on to a camera hundreds of miles away, have it take pictures on demand, and view the images.

These devices typically ship with a default password. And that’s the big problem with these things: they don’t necessarily force you to change the password, and those default passwords are well documented and widely available: they’re in the product documentation that the manufacturer probably puts on their web site for anyone to download.

(Sometimes the manufacturer will try to assign a unique default password to every unit they sell. This is great when they do it right, but sometimes they fail hilariously.)

Shodan and Censys are projects which portscan the internet and make the data available to anyone who wants to look at it. This data often reveals the manufacturer and model number of internet routers. Netgear devices often give the full model number in the remote administration password prompt. And there are web sites (like routerpasswords.com) devoted to making it easy to look up the default password for a particular network device model.

There are two important points to remember here:

  1. If you are writing about a character who wants to compromise a network target, and if she can determine the manufacturer and/or model number of the router protecting her target (either through shodan or by portscanning it herself), she can look up the default password either through something like routerpasswords.com or by downloading product documentation from the manufacturer. If the network pukes at the target haven’t secured their router, your character could add routing table rules allowing her direct access to resources on the internal network.
  2. If you haven’t changed the password on the home router that may be sitting on your desk, now would be a good time to do so. (And unless you REALLY need it, you should disable the remote administration feature which was probably enabled by default.)
Advertisement

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.

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.