Technological Musings

SSL has been used for years to protect against Man in the Middle attacks. It has worked quite well and kept our secret transactions secure. However, that sense of security is starting to crumble.

At Black Hat USA 2009, Dan Kaminsky, security researcher, presented a talk outlining flaws in x.509 SSL certificates. In short, it is possible to trick a certificate authority into certifying a site as legitimate when the site may, in fact, be malicious. It's not the easiest hack to pull off, but it's there.

Once you have a legitimate certificate, pulling off a MitM attack is as simple as proxying the traffic through your own system. If you can trick the user into hitting your server instead of the legitimate server, *cough*DNSPOISONING*cough*, you can impersonate the legitimate server via proxy, and log everything the user does. And the only way the user can tell is if they actually look at the IP they're hitting. How many people do you know that keep track of the IP of the server they're trying to get to?

Surely there's something that will prevent this, right? I mean, the fingerprint of the certificate has changed, so the browser will tell me that something is amiss, right? Well, actually, no. In fact, if you replace a valid certificate from one CA with a valid certificate from another CA, the end user typically sees no change at all. There may be options that can be set to alter this behavior, but I know of no browsers that will detect this by default. Ultimately, this means that if an attacker can obtain a valid certificate and redirect your traffic, he will own everything you do without you being the wiser.

And now, just to make things more interesting, we have this little beauty.

This is an SSL interception device sold by Packet Forensics. In short, you provide the fake certificate and redirect the user traffic and the box will take care of the rest. According to Packet Forensics, this box is sold exclusively to law enforcement agencies, though I'm sure there are ways to get a unit. For "testing," of course.

The legal use of this device is actually unknown. In order to use it, Law Enforcement Organizations (LEO) will need to obtain legitimate certificates to impersonate the remote website, as well as obtain access to insert the device into a network. If the device is not placed directly in-line with the user, then potentially illegal hacking has to take place in order to redirect the traffic instead. Regardless, once these are obtained, the LEO has full access to the user's traffic to and from the remote server.

The existence of this device merely drives home the ease with which MitM attacks are possible. In fact, in a paper published by two researchers from the EFF, this may already be happening. To date, there are no readily available tools to prevent this sort of abuse. However, the authors of the aforementioned paper are planning on releasing a Firefox plugin, dubbed CertLock, that will track SSL certificate information and inform the user when it changes. Ultimately, however, it would be great if browser manufacturers would incorporate these checks into the main browser logic.

So remember kiddies, just because you see the pretty lock icon, or the browser bar turns green, there is no guarantee you're not being watched. Be careful out there, cyberspace is dangerous.

I wrote a short piece on privacy about 2 weeks ago. A few things were pointed out to me about that piece that I want to address. My thanks to Lauren Weinstein of the People for Internet Responsibility and the Network Neutrality Squad for his comments and direction.

Lauren pointed out that the Constitution has no explicit provision for privacy. Instead, the constitution merely provides a number of guidelines for personal security. Specifically, the constitution provides guidance such as protection against unreasonable search and seizure. Additionally, a person cannot be compelled to be a witness against themselves.

The supreme court has, over time, upheld these guidelines and extended them to provide additional privacy protections for all. The ninth amendment, specifically, has been used to uphold that the rights provided by the Constitution do not supersede rights already held by individuals.

To be sure, the issue of privacy is a tangled one, and opinions abound. Interpretations of the Constitution will change over time. It is up to each and every one of us to ensure that our rights stay intact and to fight when necessary to uphold those rights.

Configuration management is pretty important, but often overlooked. It's typically easy enough to handle configurations for servers since you have access to standard scripting tools as well as cron. Hardware devices such as switches and routers are a bit more to handle, though, as automating backups of these configs can be daunting, at best.

Several years ago, I took the time to write a fairly comprehensive configuration backup system for the company I was working for. It handled Cisco routers and switches, Fore Systems/Marconi ASX ATM switches, Redback SMS aggregators, and a few other odds and ends. Unfortunately, it was written specifically for that company and not something easily converted for general use.

Fortunately, there's a robust open source alternative called RANCID. The Really Awesome New Cisco confIg Differ, RANCID, is a set of perl scripts designed to automate configuration retrieval from a host of devices including Cisco, Juniper, Redback, ADC, HP, and more. Additionally, since most of the framework is already there, you can extend it as needed to support additional devices.

RANCID has a few interesting features which make life much easier as a network admin. First, when it retrieves the configuration from a device, it checks it in to either a CVS or SVN repository. This gives you the ability to see changes between revisions, as well as the ability to retrieve an old revision of a config from just about any point in time. Additionally, RANCID emails a list of the changes between the current and last revision of a configuration to you. This way you can keep an eye on your equipment, seeing alerts when things change. Very, very useful to detect errors by you and others.

Note: RANCID handles text-based configurations. Binary configurations are a whole different story. While binary configs can be placed in an SVN repository, getting emailed about changes becomes a problem. It's possible to handle binary configs, though I do not believe RANCID has this capability.

Setup of RANCID is pretty straightforward. You can either install straight from source, or use a pre-packaged RPM. For this short tutorial, I'll be using an RPM-based installation. The source RPM I'm using can be found here. It is assumed that you can either rebuild the RPM via the rpmbuild utility, or you can install the software from source.

After the software is installed, there are a few steps required to set up the software. First, I would recommend editing the rancid.conf file. I find making the following modifications to be a good first step:

RCSSYS=svn; export RCSSYS
* Change RCSSYS from cvs to svn. I find SVN to be a superior revisioning system. Your mileage may vary, but I'm going to assume you're using SVN for this tutorial.

FILTER_PWDS=ALL; export FILTER_PWDS
NOCOMMSTR=YES; export NOCOMMSTR
* Uncommenting these and turning them on ensures that passwords are not stored on your server. This is a security consideration as these files are stored in cleartext format.

OLDTIME=4; export OLDTIME
* This setting tells RANCID how long a device can be unreachable before alerting you to the problem. The default is 24 hours. Depending on how often you run RANCID, you may want to change this option.

LIST_OF_GROUPS="routers switches firewalls"
* This is a list of names you'll use to identify devices. These names are arbitrary, so Fred Bob and George are ok. However, I would encourage you to use something meaningful.

The next step is to create the CVS/SVN repositories you'll be using. This can't possibly be easier. Switch to the rancid user, then run rancid-cvs. You'll see output similar to the following:

-bash-3.2$ rancid-cvs
Committed revision 1.
Checked out revision 1.
A configs
Adding configs
Committed revision 2.
A router.db
Adding router.db
Transmitting file data .
Committed revision 3.
Committed revision 4.
Checked out revision 4.
A configs
Adding configs
Committed revision 5.
A router.db
Adding router.db
Transmitting file data .
Committed revision 6.
-bash-3.2$

That's it, your repositories are created. All that's left is to set up the user credentials that rancid will use to access the devices, tell rancid which devices to contact, and finally, where to send email. Again, this is quite straightforward.

User credentials are stores in the .cloginrc file located in the rancid home directory. This file is quite detailed with explanations of the various configuration options. In short, for most Cisco devices, you'll want something like this:

add user * <username>
add password * <login password> <enable password>
add method * ssh

This tells the system to use the given username and passwords for accessing all devices in rancid via ssh. You can specify overrides by adding additional lines above these, replacing the * with the device name.

Next, tell rancid what devices to contact. As the rancid user, switch to the appropriate repository directory. For instance, if we're adding a router, switch to ~rancid/routers and edit the router.db file. Note: This file is always called router.db, regardless of the repository you are in. Each line of this file consists of three fields, separated by colons. Field 1 is the hostname of the device, field 2 is the type of device, and field 3 is either up or down depending on whether the device is up or not. If you remove a device from this file, the configuration is removed from the repository, so be careful.

router.example.com:cisco:up

Finally, set up the mailer addresses for receiving rancid mail. These consist of aliases on the local machine. If you're using sendmail, edit the /etc/aliases file and add the following :

rancid-<group>: <email target>
rancid-admin-<group>: <email target>

There are two different aliases needed for each group. Groups are the names used for the repositories. So, in our previous example, we have three groups, switches, routers, and firewalls. So we set up two aliases for each, sending the results to the appropriate parties. The standard rancid-<group> alias is used for sending config diffs. The rancid-admin-<group> alias is used to send alerts about program problems such as not being able to contact a device.

Make sure you run newaliases when you're done editing the aliases file.

Once these are all set up, we can run a test of rancid. As the rancid user, run rancid-run. This will run through all of the devices you have identified and begin retrieving configurations. Assuming all went well, you should receive notifications via email about the new configurations identified.

If you have successfully run rancid and retrieved configurations, it's time to set up the cron job to have this run automagically. Merely edit the crontab file for rancid and add something similar to the following:

# run config differ 11 minutes after midnight, 2am, 4am, etc.
11 0-23/2 * * * /usr/bin/rancid-run
# clean out config differ logs
50 23 * * * /usr/bin/find /var/rancid/logs -type f -mtime +2 -exec rm {} \;

Offsetting the times a bit is a good practice, just to ensure everything doesn't run at once and bog down the system. The second entry cleans up the rancid log files, removing anything older than 2 days.

And that's it! You're well on your way to being a better admin. Now to finish those other million or so "great ideas" ....

We interrupt this space for a special announcement .... *speechless*

Live free or die: Death is not the worst of evils.
- General John Stark

Is life so dear, or peace so sweet, as to be purchased at the price of chains and slavery? Forbid it, Almighty God! I know not what course others may take; but as for me, give me liberty or give me death!
- Patrick Henry

Privacy, n.
1. The state or condition of being alone, undisturbed, or free from public attention, as a matter of choice or right; seclusion; freedom from interference or intrusion.
2. The state of being privy to some act
3. a. Absence or avoidance of publicity or display; secrecy, concealment, discretion; protection from public knowledge or availability.
3. b. The keeping of a secret; reticence.
- Oxford English Dictionary

Privacy is often taken for granted. When the US Constitution was drafted, the founding fathers made sure to put in provisions to guarantee the privacy of the citizens they would govern. Most scholars agree that their intention was to prevent government intrusion in private lives and activities. They were very forward thinking, trying to ensure this protection would continue indefinitely into the future. Unfortunately, even the most forward thinking, well intentioned individual won't be able to cover all of the possible scenarios that will occur in the future.

Since that fateful day in 1787, a war has raged between those advocating absolute privacy and those advocating reasonable intrusion for the sake of security. At the extreme edge of the argument are the non-consequentialists who believe that privacy should be absolute. They believe that privacy is non-negotiable and that the loss of privacy is akin to slavery. A common argument is that giving up privacy merely encourages additional loss. In other words, if you allow your privacy to be compromised once, then those that violate it will expect to be able to violate it again.

At the other edge are those that believe that privacy is irrelevant in the face of potential evil. This is also a non-consequentialist view. Individuals with this view tend to argue that if you have something to hide, then you are obviously guilty of something.

Somewhere in the middle are the consequentialists who believe that privacy is essential to a point. Violation of privacy should be allowed when the benefit of doing so outweighs the benefit of keeping something private. In other words, if disclosing a secret may save a life, or prevent an innocent person from going to jail, then a violation of privacy should be allowed.

The right to privacy has been fought over for years. In more recent years, technological advances have brought to light many of the problems with absolute privacy, and at the same time, have highlighted the need for some transparency. Technology has benefits for both the innocent and the criminal. It makes no delineation between the two, offering the same access to information for both.

New technologies have allowed communication over long distances, allowing criminals to coordinate criminal activities without the need to gather. Technology has brought devastating weaponry to the average citizen. Terrorists can use an Internet search engine to learn how to build bombs, plan attacks, and communicate with relative privacy. Common tools can be used to replicate identification papers, allowing criminals access to secure areas. The Internet can be used to obtain access to remote systems without permission.

Technology can also be used in positive ways. Mapping data can be used to optimize travel, find new places, and get you home when you're lost. Online stores can be used to conveniently shop from your home, or find products you normally wouldn't have access to. Social networking can be used to keep in touch with friends and relatives, and to form new friendships with strangers you may never have come in contact with otherwise. Wikipedia can be used for research and updated by complete strangers to spread knowledge. Companies can stay in contact with customers, alerting them of new products, updates to existing ones, or even alert them to potential problems with something they previously purchased.

In the last ten or so years, privacy in the US has been "under attack." These so-called attacks come from many different sources. Governmental agencies seek access to more and more private information in order to combat terrorism and other criminal activities. Private organizations seek to obtain private information to identify new customers, customize advertisements, prevent fraud, etc. Technology has enabled these organizations to obtain this data in a variety of ways, often unbeknownst to the average user.

When was the last time you went to the airport and waited for someone to arrive at the gate? How about escorting someone to the gate before their flight? As recently as 20 years ago, it was possible to do both. However, since that time, security measures have been put in place to prevent non-ticketed individuals access beyond security checkpoints. Since the 9/11 terrorist attacks, security has been enhanced to include random searches, bomb sniffing, pat downs, full-body scanners, and more. In fact, the Transportation Security Administration (TSA) started random screening at the gate in 2008. Even more recently, the TSA has authorized random swabbing of passenger hands to detect explosive residue. While these measures arguably enhance security, it does so at the expense of the private individual. Many travelers feel violated by the process, even arguing that they are assumed to be guilty, having to prove their innocence every time they fly.

Traditionally, any criminal proceeding is conducted with the assumption of innocence. A criminal is considered innocent of a crime unless and until they are proven guilty. In the airport example above, the passengers are being screened with what can be considered an assumption of guilt. If you refuse to be screened, you are barred from flying, if lucky, or taken in for additional questioning and potentially jailed for the offense. Of course, individuals are not granted the right to fly, but rather offered the opportunity at the expense of giving up some privacy. It's when these restrictions are applied to daily life, without the consent of the individual, that more serious problems arise.

Each and every day, the government gathers information about its citizens. This information is generally available to the public, although access is not necessarily easy. How this information is used, however, is often a source of criticism by privacy advocates. Massive databases of information have been built with algorithms digging through the data looking for patterns. If these patterns match, the individuals to whom the data belongs can be subject to additional scrutiny. This "fishing" for wrongdoing is often at the crux of the privacy argument. Generally speaking, if you look hard enough, and you gather enough data, you can find wrongdoing. More often, however, false positives pop up and individuals are subjected to additional scrutiny without warrant. In some cases, individuals can be wrongly detained.

Many privacy opposers argue that an innocent person has nothing to hide. However, this argument can be considered a fallacy. Professor Daniel Solove wrote an essay explaining why this argument is faulty. He argues that the "nothing to hide argument" is essentially hollow. Privacy is an inherently individualistic preference. Without knowing the full extent of how information will be used, it is impossible to say that revealing everything will have no ill effects, assuming the individual is innocent of wrongdoing. For instance, data collected by the government may not be used to identify you as a criminal, but it may result in embarrassment or feelings of exposure. What one person may consider a non-issue, others may see as evil or wrong.

These arguments extend beyond government surveillance and into the private sector as well. Companies collect information about consumers at an alarming rate. Information entered into surveys, statistics collected from websites, travel information collected from toll booths, and more can be used to profile individuals. This information is made available, usually at a cost, to other companies or even individuals. This information isn't always kept secure, either. Criminals often access remote systems, obtaining credit card and social security numbers. Stalkers and pedophiles use social networking sites to follow their victims. Personal information posted on public sites can find its way into credit reports and is even used by some businesses to justify firing employees.

Privacy laws have been put in place to prevent such abuses, but information is already out there. Have you taken the time to put your name into a search engine lately? Give it a try, you may be surprised by the information you can find out about yourself. These are public records that can be accessed by anyone. Financial and real estate information is commonly available to the public, accessible to those knowing how to look for it. Criminal records and court proceedings are published on the web now, allowing anyone a chance to access it.

Whenever you access a website, check out a book from the library, or chat with a friend in email, you run the risk of making that information available to people you don't want to have it. In recent years, it has been common for potential employers to use the Internet to obtain background information on a potential employee. In some cases, embarrassing information can be uncovered, casting a negative light on an individual. Teachers have been fired because of pictures they posted, innocently, on their profile pages. Are you aware of how the information you publish on the Internet can be used against you?

There is no clear answer on what should and should not be kept private. Likewise, there is no clear answer on what private data the government and private companies should have access to. It is up to you, as an individual, to make a conscious choice as to what you make public. In an ever evolving world, the decisions you make today can and will have an impact on what may happen in the future. What you may think of as an innocent act today can potentially be used against you in the future. It's up to you to fight for your privacy, both from the government, and from the companies you interact with. Be sure you're aware of how your data can be used before you provide it. Privacy and private data is being used in new, interesting, and potentially harmful ways every day. Be sure you're aware of how your data can be used before you provide it.