InfoSec Blog

Adding SSL to Ubuntu / Apache2 / Ruby on Rails

Adam Brand — Thu, 27 Aug 2009 22:39:51 GMT

There are many sources on Google for configuring SSL with Ubuntu, Apache2, and Ruby on Rails, but there isn’t one that I feel is straightforward and comprehensive. So here is the skinny on how to get SSL going in your Rails app on Apache 2 / Ubuntu.

For this case, we are assuming you are getting a certificate from GoDaddy (not a self-signed cert), but you can get your cert from any certificate authority and the steps should be the same.

I’ll use www.yourdomain.com as the example domain we want to secure.

NOTE: The blog column width has wrapped some of the command lines, so be mindful of that.

Set Up Your Cert Directory

There are four crypto-related files for SSL that need a home: 1) the CSR (you send to GoDaddy), 2) the private key (which you keep), 3) the actual cert sent to you by GoDaddy, and 4) the intermediate certificate (GoDaddy will send you).
If you have Ubuntu, you probably have an /etc/apache2 folder. So create a folder in there called ssl.

Create Your Private Key

You need openssl for this, so first do:

sudo apt-get install openssl

Then you actually make your private key, like this:

sudo openssl genrsa -des3 -out www.yourdomain.com.key 1024

It will ask you for a password. You’ll remove this later but for now just type something you will remember. This key you will keep locally (don’t send it to GoDaddy).

Create Your CSR

This is the file you’ll actually send to GoDaddy to get your certificate:

sudo openssl req -new -key www.yourdomain.com.key -out www.yourdomain.com.csr

Get Your Cert and Intermediate Cert

Now you go through Godaddy’s (or your certificate authority’s) process for getting your certificate and their intermediate certificate. You’ll send them your CSR to get these. Drop them in your /etc/apache2/ssl folder.

Remove the Password from Your Private Key

This step is optional, but if you don’t do it Apache won’t start automatically on reboot (it will prompt for a password).

sudo mv www.yourdomain.com.key www.yourdomain.com.passkey
sudo openssl rsa -in www.yourdomain.com.passkey -out www.yourdomain.com.key

Set Appropriate Permissions on Your Key Files

You don’t want random people to snag your keys. At this point if you do an ls -l in the /etc/apache2/ssl folder you should see that the files are owned by root. Now we just need to change the permissions so only root can read them:

sudo chmod 400 /etc/apache2/ssl/*

Prep Apache by Installing Mods

Your Apache install probably doesn’t have mod_ssl or mod_headers installed, so you will need to do:

sudo a2enmod ssl
sudo a2enmod headers

Adjust Site Config File in Apache

Assuming your site is already operational with http, you should have a config file already under /etc/apache2/sites-available (like default). Edit that file so that it looks like:

<VirtualHost *:443>
ServerName www.yourdomain.com
ServerAlias www.yourdomain.com
DocumentRoot /var/apps/yourapp/public

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/www.yourdomain.com.crt
SSLCertificateKeyFile /etc/apache2/ssl/www.yourdomain.com.key
SSLCertificateChainFile /etc/apache2/ssl/gd_bundle.crt

#For RoR "Mongrel"
RequestHeader set X-Forwarded-Proto "https"

#Hack for IE
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
</VirtualHost>

…you of course will need to put in your domain where applicable and also put the name of your key files in there as well.

Restart Apache

These changes don't take effect until you restart apache, so do:

sudo /etc/init.d/apache2 restart

Adjust Your Rails App

Now we need to adjust your rails app so that it supports SSL. Edit your /app/controllers/application_controller.rb and add this at the bottom:

def ssl_required?
true
end

If you wanted to get fancy, you could add in some code there to return false if local_request or RAILS_ENV == ‘test’.

That’s it! Hope this saves someone else some web research!

Configuring Egress (Outbound) Rules with iptables (ubuntu style)

Adam Brand — Wed, 26 Aug 2009 22:49:08 GMT

There is a lot of information on iptables (the Linux firewall) out there, but most of them focus on ingress rules.

Unfortunately, in many cases, simply creating ingress rules are insufficient. On systems you really want to secure, you should also set up egress (outbound) rules to restrict outbound traffic.

NOTE: The commands in this post assume a Debian-based distribution (e.g., Ubuntu server). The iptables commands should be the same across distributions, but check your own distro’s reference guide for how to save and load iptables as those steps vary.

ALSO NOTE: Because of the column width in this blog, some of the rules wrap to a second line. Keep in mind that all the lines start with "sudo iptables".

In the below example, we’ll set up fairly common rules for a server that only really needs to get package updates. Remember that these are case sensitive commands, and also that the order you type them is the order that they are evaluated (i.e., if you are connecting over SSH, don’t do the -A OUTPUT -j REJECT first).

sudo iptables -A OUTPUT -o lo -p all -j ACCEPT
sudo iptables -A OUTPUT -m state --state RELATED, ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 80 -d security.ubuntu.com -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 80 -d us.archive.ubuntu.com -j ACCEPT
sudo iptables -A OUTPUT -j REJECT

IMPORTANT: Do not add the security.ubuntu.com or us.archive.ubuntu.com rules unless you make a /etc/hosts entry for those...otherwise you will also need to let DNS out and it will be SLOW.

Let’s take a look at each of these rules:

sudo iptables -A OUTPUT -o lo -p all -j ACCEPT

This is adding an entry saying that we should accept any traffic that wants to go outbound on the local (127.0.0.1) interface. Some applications use this interface to exchange information, and we don’t want to break those.

sudo iptables -A OUTPUT -m state --state RELATED, ESTABLISHED -j ACCEPT

This is the “secret sauce” rule, and one that is often forgotten, leading to disconnected sessions and confusion. What this says is allow outbound traffic that associated with a session that is already established or related to an established session. For example, if you have SSH on your server, you can open up port 22 inbound, but how will the server send data back to clients (that may even suggest an alternate higher port for subsequent communications)? That’s what this rule allows.

sudo iptables -A OUTPUT -p tcp --dport 80 -d security.ubuntu.com -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 80 -d us.archive.ubuntu.com -j ACCEPT

These rules simply tell iptables to allow traffic going to port 80 for ubuntu’s update servers. These may be different depending on your region, and there may be more, so you will have to do an apt-get update after you do this to make sure that it works for you. IMPORTANT: As I mentioned before, DO NOT enable these rules without first putting an entry mapping the appropriate IP’s in /etc/hosts. Also if Ubuntu changes these IP’s, you will need to update your hosts entry. Otherwise you would have to enable DNS to resolve those names and there could potentially be an external lookup for every outbound packet (ouch!).

sudo iptables -A OUTPUT -j REJECT

This is the rule that kills all the other traffic. This should definitely be the last rule in your chain, or the other rules won’t work.

That’s it!

Don’t forget to do:

sudo sh -c "iptables-save > /etc/iptables.rules"

if you want to keep the rules, and then add:

pre-up iptables-restore < /etc/iptables.rules

under the interface (eth0 or whatever) in /etc/network/interfaces.

Here are some other egress rules you may be interested in:

To allow “ping” to work (from the server):

sudo iptables -A OUTPUT -p icmp --icmp echo-request -j ACCEPT
sudo iptables -A OUTPUT -p icmp --icmp echo-reply -j ACCEPT

To allow DNS to work (from the server):

sudo iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

So now you have no excuse to leave your outbound traffic unguarded…get to it! :-)

Digital Evidence Collection

Brennen Reynolds — Fri, 19 Jun 2009 18:17:54 GMT

Today it’s not if your organization will have an electronic incident it’s when will that incident occur. Regardless of the type of incident there is a high likelihood your organization will need to collect digital evidence and build some form of a case file. However, it is often in the first moments after an incident is detected that crucial mistakes are made by the organization.

Most organizations are not able to justify having a fulltime forensic examiner on staff. The result of this is when incidents do occur the first responders often have not been properly trained on sound evidence collection procedures. This post is going to cover some of the basic steps and precautions that first responders should follow to ensure they aren’t permanently damaging, altering or destroying critical digital evidence.

Physical evidence

More times than not the organization’s IT staff is called upon as the first responders. While these individuals have a deep understanding of the internal technical details of the organizations electronic systems they often do not realize the importance of the physical world surrounding the systems. When first arriving at the scene care should be taken by all to not alter the physical environment. Extensive photographs of the cubical, room, etc should be taken to document the location of all items in the environment.

Once the collection of items begins, proper protection should be taken to preserve physical evidence such as fingerprints on keyboards as well as protect the responders from any harmful substances in the area. Additionally, proper storage containers used to collect physical evidence ensuring there is no opportunity for contamination as the evidence is transported.

Volatile storage evidence

The proliferation of Web 2.0 applications has greatly complicated the collection of digital evidence as many times the information is either scattered in render scraps across a massive hard drive or only stored in a systems volatile RAM while the application is being accessed. Therefore, when the system is powered off the data is lost forever unless it can be captured while the system is still live.

A number of forensic tool vendors have developed solutions to aid in the capture of volatile information from systems. e-fense Live Response USB key allows first responders to acquire a comprehensive copy of all critical system settings and memory contents from a live system. Guidance Software’s enCase Enterprise application has a privileged read-only process running on your organizations systems that can be used to transfer volatile information from a system to a central repository without alerting the user of the system or requiring physical access to the device.

Critical business system

Finally I want to discuss how to handle a critical business system being involved in an incident. Obviously these systems usually cannot be taken off-line and sent to a forensics lab for processing. They tend to be multi-user systems with a high volume of traffic and activity. This means that the system state is changing quickly and potential evidence may be lost if not captured in a timely manner. The challenge is how to make an image of the system while it’s still online and constantly changing.

Again, there are many vendors with different tools available that can do network-based image transfers of live systems including Access Data , Guidance Software or even the open source dd utility piped over a netcat tunnel (for those who aren’t looking to spend a lot of money). While this may not be as ideal as a standalone drive imaging process given the restrictions of dealing with these critical systems this is the best option available and any image (even a smeared one) is better than none.

In the end organizations should be prepared to handle incidents when they occur. By acquiring a few key tools, having documented and proper incident response procedures and providing those who will be initial responders with some basic training can be the difference in success or failure of building sound evidence backed cases.

Multifactor Authentication

Ray Zadjmool — Wed, 27 May 2009 23:32:42 GMT

What is Multifactor Authentication?

Multifactor authentication can best be described as a string of authentication methods from two or more of the three categories of factors. Considered a form of strong authentication, Multifactor authentication is used to create a higher form of assurance on protected assets.

How is it different from Two Factor Authentication?

Its not. Two factor authentication is a form of Multifactor Authentication. The term Multifactor Authentication was created as a means to describe strong authentication methods that might not neccessarily fit the more narrow and traditional definition of Two Factor Authentication. Where as Two Factor authentication is "something you know, and something you have", multfiactor authentication can just as easily be "something you have, something you are" or "something you know, and something you are"

How is it different from "Strong Authentication"?

Strong authentication can simply be multiple

According to the FFIEC,

"By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category ... would not constitute multifactor authentication."

The three categories of factors from which two or more are required to be true multifactor authentication are:

Human Factor: Something the user is (biometric characteristics, voice, fingerprint, retina).
Personal Factor: Something the user knows ( password, PIN);
Techincal Factor: Something the user has (OTP Token, ATM card, smart card)

Types of Multifactor: Biometric and Pin

"Something you know, something you are"

Something you have - your finger, voice or your eye.

Something you are - Pin.

When to use it: Datacenters doors.
When not to use it: Anything consumer facing (Online banking, portals)

Pros:

very cool

secure as can be - just make sure you tell tech support if you lose an eye.

low learning curve - scan, pin, repeat.

Considered non-repudiatable - almost 100%. (There is always the chance for the old but goody: "It wasnt me, it was my twin" excuse)=

Cons:

Expensive capital costs.

Expensive maintenance costs. Tech support is incremently more difficult. Supporting remote users becomes an interesting problem....

Interoperability. For some reason alot of bio metric solutions are just now catching up to the whole integration bandwagon. While integration support is ramping up, interopility with things like LDAP should not be assumed.

Types of Multifactor: Smart Card and Pin

"Somethign you know, something you have"

Take a smart card reader and a pin and what do you have? Multifactor authentication for less than 13 bucks (11.25 for the reader, 1.75 for the card).

Something you have - smart card, credit card, usb token

Something you know - Pin or password.

When to use it: Consumer applications, building entry, credit cards
When not to use it: Emergency exits.

Pros:

Cheap to start, cheap to scale.

Most operating systems have native support for smart cards.

Good for consumer facing applications.

Cons:

Can be reproduced. (Track data anyone.. the first skimming scam happened 24 seconds after the first credit card was issued).

Higher learning curve

Types of Multifactor: Profile Questions and Browser

Something you have, something you know

Think 20 questions. If the resource needs to be protected at a higher assurance level than just a simple password, then a process by which multiple profile questions could be asked. Once correctly answered, and out of band procedure is done to validate the "browser" or "workstation". A security validation cookie is set and from then on, the browser acts as the second factor.

Something you have - out of band validated browser, workstation, email

Something you know - Pin or password.

When to use it: Consumer portals, online bankcing

When not to use it: VPNS

Pros:

Extremely cost effective. This is how you raise the assurance level of 200,000 users across the country.

Low learning curve. Answer some questions, and you are off. Change computers? Do it again.

Cons:

Is it really multifactor? I think the argument can be made the "browser" is something you have but only if you have an out of band procedure to assign the browser to the user (SMS, email, letter). Having said that, be prepared for a geek battle.

Not really non-repudiate-able. The "what if my wife used my computer" scenario is always cited as proof of its illegitimacy.

Two Factor Authentication with OTP

Ray Zadjmool — Wed, 27 May 2009 19:28:04 GMT

What is Two factor authentication?

"Something you have, and something you know."

Two Factor authentication has become a standard when non-repudiation or higher assurance is needed to protect an asset. The premise behind it is easy; prove that you are who you say you are. The idea is as old as the credit card (itself a two factor device); combine a physical device with a username or pass code.

OTP [One Time Passcode] solutions for Two Factor dominate the industry and are usually referred to as Tokens.

How Does Two Factor OTP work?

A "Seed" is used to get the server and token in sync. The OTP is generated using several factors such as time, crypt althorithm and the seed to generate the OTP. As the name applies, the postcode is designed to be used "one time" and usually is configured to expire shortly after its been generated.

Types of Two Factor OTP:

Depending on your need, several options exist for deploying Two Factor OTP.

Hard Tokens: A physical device with battery.These can come in many forms: USB based, Display only, or Display with Pin PAD.Note: The latest invotations with Tokens included credit card hard tokens.

Software Tokens: Same as hard tokens but innstead of a battery, its software that is installed on the PC, Laptop or Smart Phone. Several environmental factors such as the computer bios clock and network time are used in addition to the seed to keep the OTP in sync with the server.

On Demand OTP: SMS/EMAIL. Directory profile information about the users cell phone or email address is used to deliver the OTP.

Scratch Card: Unique to Entrust, the user has a scratch card that has a bingo style grid on it. The server challenges an OTP much like bingo - A5, B7, C9, D8. You have to have the scratch card to figure out what the OTP challenge is from the server.

OTP Considerations:

Pros: What are the advantages of Two Factor OTP for strong authentication?

Easy to setup.
Very mature technology. Most vendors include self service.
Universally supported across most technologies. Usually integrated with Radius but most vendors provide out of the box support with popular access platforms like Siteminder or CoreID.

Cons: OTP is not perfect. What are some of the issues with deploying Two Factor OTP?

Can be somewhat difficult to scale- logistically. Although there are a lot of options available, a lot of questions must be answered prior to deployment.

How do you deliver the tokens?

What happens when a user loses a token?

What if they are traveling and they lose a token?

What sort of permissions do they need to install a soft token?

Do I have accurate employee info in a directory to use SMS or email Tokens?

How do I prevent someone from changing them

High costs to scale - especially hard tokens. Hard tokens can range from $5-$70 bucks a user. Not bad at a 100 but at 10,00. Also consider that hard tokens do have a battery and therefore a shelf like of 5-7 years

Future: Look to the clouds. Several vendors like Verisign (See VIP Network) are starting to offer cloud based authentication services to allow for cross domain trust.

Presumably these type of services will be a platform to offer additional services like risk based authentication or integration with identity provider frameworks like OpenID, or Federation.

Vendors:

RSA - SecureID with Authentication Manager
Activ Identity
Entrust - Identity Gaurd Mini Token, Scratch Cards
Verisign - Unified Authentication

Data Proliferation, Attacking the Monster We’ve Created

Jason Pieters — Tue, 26 May 2009 17:41:50 GMT

Within our homes, small and medium business settings, and enterprise environments we use data. We manipulate it, we report on it, we use it to create more data, we may ship it off site, we bring it in, and we send it out. While we need all of it to do our jobs; are we watching or keeping up with where we are placing it?

Are we concerned that some of the times that we send it out that we do so unknowingly or accidentally?

Do we ever stop and think about what the exposure to the company is if we continue to create these stores of data that could expose us to legal proceedings, loss of business, or worse?

Data proliferation is occurring everywhere around us and surprisingly enough the majority of it is legitimate use of data and a good portion of that data is sensitive and protected under any number of regulatory concerns (PCI, HIPAA, California SB 1386, etc.). So how do we understand data proliferation and what can we do to manage it?

Understanding data proliferation is often times a mix of psychology, computer science, and business processes re-engineering. It is frustrating at times but hopefully I can put you on a path that will, if nothing else, assist in getting your hands around your own data. Dealing with data proliferation is a continual fight that can be summed up as follows:

1. Identify Possible Locations

2. Discover Sensitive Information

3. Identify Business Process

4. Re-Engineer or Remove Process

5. Identify Third Party Locations

6. Repeat the Process

Each one of these steps will be expanded upon. Often times it is easy for us to pick out the obvious locations where data is and or should be stored. This isn't our problem. The problem is all of those areas where data is unexpectedly stored. So we will turn to a tool to see what the damage is. For this I suggest using an open source tool. I recommend Spider if you are in a Windows environment. It does the job of identifying the obvious credit card numbers, social security numbers, etc. without the cost associated of an enterprise data loss prevention solutions.

The problem is there will be false positives, but at this point in the game we are just trying to hone in on our data stores and there is no cost justification for acquiring a more powerful solution.

First identify all areas within the business that may use or work with sensitive data. The immediate areas are typically, Human Resources, Accounting, Internal Audit, all corporate file servers, and backups. This is not by any means an exhaustive list of possible locations but these areas, in my experience, are typically the largest stores of sensitive and protected information.

A typical scenario is that we use a tool like Spider within our network and we identify a user workstation with multiple excel spreadsheets containing what appears to be sensitive data. We talk to the user who has these files, and we find out that they use these excel files to facilitate and monitor the charge back process and then at the end of the quarter they can go back and show the charge back percentages and they use it for profit analysis and any other number of legitimate business needs.

So we now have an idea of why but what happens with the data when it is compiled into these reports, are there subsystems that are involved?

Are there applications that are handling this data?

Where are the backups located for these systems?

Are there additional file shares that are used to share these excel files?

Are there any laptops that are used to perform these business processes?

Now the scope of our search has expanded from finding these excel files to maybe two or three other departments, several other file servers, maybe some offline systems like laptops, and of course the backups for these systems. At this point we need to stop the bleeding of data and the exposure. So we have to dig deep into each process that is occurring within the charge back department to understand how they are using the data and how much of it they actually need. Is there a secure way to share this information and is a credit card number needed for profit and loss statements. Often we will find out that
only a portion of the jobs associated with the data gathering require all subsets of the data.

Could we provide secure jobs that ship these reports to the charge back department with sanitized data? Could a system be put in place to present full credit card numbers only when needed? At this point we merge the psychological and technological parts of our minds to understand the business process and develop the solution. Often times we find these data stores and the business process is that it is following doesn't need the data, they are just doing what has always been done.

Ask the question to people, do you absolutely need this data to perform your job? Get documentation and regulations that require this to be done. Then implement the appropriate controls on those systems to meet or exceed the regulatory requirements affecting that data. Often times once more stringent controls are put in place people realize that maybe they don't need all of the data to run their reports and there may be a better way to do it.

Following the loop through though we now have to perform all of these steps with each business process that could have had the sensitive data spread to it. Now at this point the potential for understanding our data proliferation dilemma could be overwhelming.

Using a more advanced solution to understand your data proliferation could be considered and in that realm there are two solutions that should be considered McAfee's Network DLP Discover and Symantec's Vontu DLP solution. Both of these solutions are maintained by leaders in the security space and should be placed on the score sheet for any company looking to acquire a DLP discovery solution.

Maltego... the Information Gathering Swiss Army Knife

Brennen Reynolds — Fri, 22 May 2009 01:02:17 GMT

Maltego from Paterva is to information gathering as Nmap is to port scanning or Nessus is to vulnerability scanning. It’s an all in one, Swiss army knife toolkit for everything related to online information gathering.

Maltego provides a single canvas to investigate all things digital: domain names, IP addresses, email addresses, phone numbers and even just a person’s name. Two building blocks make up the majority of Maltego’s functionality: entities and transforms. Entities are objects or things. Transforms are actions performed against entities which often result in the creation of new entities. (Note: there is a really nice user’s guide on the Maltego site so I am not going to cover how to install and get it up and running.)

To demonstrate the power (aka usefulness) of Maltego lets see what we can find out about Tevora. First I created a “Website” entity for blog.tevora.com. Running the To Domain [DNS] transform created a new domain entity for tevora.com (no big surprises there). This domain entity allows many new transforms to run. After running the available DNS transforms we are presented with the following image.

Removing all the sub-entities lets see what information we can find from this blog and its contents. Maltego’s To Email Addresses transform crawls a website and retrieves all the emails addresses it find. The results show only a handful of addresses and most appear to be specifically created for use on the blog (a good security practice by the way).

Another transform, To Website [Incoming links SE], when run on the blog.tevora.com entity shows 3 other sites which have linked to this blog. The results of this transform provide a picture of other sites linked to or mentioning your website or blog.

As a final example let’s shift the focus from this blog’s website to me, the author. Creating a “Person” entity and running the To Website [SE] transform on the person object with my name assigned to it we are able to see websites and blogs where my name was found. (And if you are looking at the image close enough I will tell you there are 2 individuals named Brennen Reynolds to be found on the net and no I am not the one who rides horses).

As this mini-tutorial shows, Maltego is capable of providing a wide array of information gathering tools in a single package. Next time you are doing a pen-test or just looking to get a better picture of a site / domain / person, go download the Community Edition and take it for a test drive.

Deleted Files … are they really gone?

Brennen Reynolds — Fri, 13 Mar 2009 18:00:14 GMT

Does deleting a file on a computer really mean its lost forever?

Short answer: no. Longer answer: it depends, but probably not.

Given you are still reading this that must mean you are wondering “depends on what?”.

Deleting a File

Deleting a file in most current operating systems does not actually modify any of the data contained in that file. Operating systems maintain an internal list of where files are physically and logically located within the hard disk and file system. Different file systems have different names for these lists including:

Master File Table (MFT) for NTFS
File Allocation Table (FAT) for FAT16 and FAT32
Catalog File for HFS

When you the user choose to delete a file, the operating system will remove that files entry from this internal list and mark the space on the hard disk (called clusters) as empty and available. However, the actual file contents are still sitting on the disk unchanged! The delete files contents will remain on the disk until a new file is created and the OS chooses to use the clusters of the old file to store the new information.

The process of recovering deleted files and information is known as data carving. Two freely available data carving tools are Foremost and Scalpel. Using either of these tools it is extremely easy to search for and extract out any deleted data left on a hard drive or other storage device (including USB thumb drives).

A Little Experiment

To find out just how effective these tools are I decided to experiment on an old USB thumb drive I found in a drawer. It’s only a 256 meg stick and hasn’t been used in a couple years. Plugging it into my Windows workstation and viewing its contents showed no files on the drive and all 256 megs of space available. So it appears there is nothing on it… right?

I booted up my forensics laptop using the Helix3 Forensics LiveCD, plugged in the USB stick and created an image file containing an exact copy of the entire drive using the dd utility . Now it was time to find out if the disk really had nothing on it.

Moment of Truth

I ran the image files through both Foremost and Scalpel and instructed each tool to extract as much information as possible. This included all possible types of files and even partial remains of files. The results were slightly different between the two tools but each one found almost 100 files and file fragments! Everything from Office documents to music files and even installation executables for some small utilities I had once used was extracted.

Moral of the story is even though your files may be out of site they really aren’t gone for good. So remember this, the next time you decide to toss out an old hard drive or USB stick you might want to look into a secure wiping tool like Eraser .

The Curious Case of 1392

Jason Pittman — Thu, 19 Feb 2009 02:30:57 GMT

There are occasions in technology where events or results inspire feelings of mystery. Those, "it must be magic" moments when our existing body of knowledge is incapable of processing the situation. I encountered one such event today, so I thought I would share a bit.

Some time ago I designed an architecture for a business partner whereby a series of system updates could be delivered into a closed network topology. Meaning, the target computers were behind a gateway system with no direct ingress/egress points. We needed an engine of the gateway system that would take the staged system updates, distribute them securely and with integrity to the inward-facing computers and oversee the installation of said updates in a safe manner (read: catch exceptions, manage installation order, etc.). It took a few days but we finally nailed it. Another few days were spent in rigorous QA since one of the updates was quite large and made serious modifications to the target system architecture. All use cases passed.

Then we tried in in a pilot production environment. Failure.

We tried again the next night after some modifications to the deployment architecture. Failure again.

Another day or two was spent analyzing the logs from the deployment but nothing stood out. So, I recommended that we manually install the system updates to see if the deployment architecture might not be handling some kinds of exceptions (missing files, corruption, etc.). This was tricky due to the closed network topology but we pulled it off. Lo and behold- there was corruption and it was an entire directory.

Enter stage left- error 1392.

1392 is a return error code from the system's native copy function. Although my initial prediction rang true, I was stunned. First of all, an entire directory was corrupt but the systems had never encountered any issues. Secondly, I had a strange feeling that this corruption might be systemic; part of a base image that had been rolled out some time in the past. What was I to do?

I solved the curious case of 1392 by writing a shell script that did the following:

1) Take an empty text file and copy it into the possibly corrupted directory. This is key since it forces the target system to tell us if it indeed has a corrupted directory.

2) If we get a return code 0 (zero), go ahead and begin the deployment process.

3) If we get a return code of anything but 0 (zero) and 1392, toss an error and exit.

4) If we get a return code of 1392, take a (pre-staged) copy of the now-known-to-be corrupted directory and overwrite the corrupted one. Then start the deployment routine.

Case solved. We were able to begin full deployment on schedule.

Find, the Power

Jason Pittman — Tue, 17 Feb 2009 23:55:14 GMT

I was doing some work on a very large log correlation server recently. By large I mean copious amounts of log files, not necessarily large in size. Essentially, the chief task was that I needed to audit what was being kept as online history. As you, dedicated readers, remember PCI-DSS requires one year of history to be kept with 90 days active and online. That can mean quite a bit of data in most cases. Being both technically-adept and lazy, I turned to the "find" command.

Naturally, I first needed to confirm that enough history was present. To do so, I went with some find-fu along these lines:

find -mtime +364 -type f -exec ls -lah {} \;

Let's break that down a little:

1) find -> our basic find command
2) -mtime -> this means we're going to be "finding" by modified time
3) -type f -> we're searching for files of course
4) -exec -> run a command for me
5) ls -lah -> the command I want to run; I opted to list the directory because I also want to see the files, their sizes, etc.
6) {} -> this gives our command string an empty parameter set to feed ouput into (so, input kinda). Basically, this is how we'll be able to see the file names, sizes, etc.
7) \; -> this signals the end of the command

Cool. Now I have a list of files with a modified time older than 364 days (note: this ran in the current working directory by intention), evidencing that at least one year is being kept online. Cool enough but what other stuff can we do with the find command?

You can move files based on a size limit:

find -type f -size +10M | xargs -i -t mv {} /target/directory/to/move/files/to

The above would take all files (again, in the current path) that are greater than 10Megabytes and move them to a different directory. This can be useful for log rotations, in preparation of purging data based on size requirements, etc.

Of course, everyone in security should know this one:

find / -type f $ -perm -4000 -o -perm -2000 $ -print

A free alcoholic beverage of your choice to the first person who identifies the above correctly!

Lions, Tigers, and...IP Addresses

Jason Pittman — Fri, 13 Feb 2009 02:18:48 GMT

For anyone who remembers their zoology, or has watched enough Animal Channel or National Geographic, the concept of large animal herds escaping predators by concentrating in tight groups should not be foreign. After all, there's safety to be had in numbers. But have you ever asked yourself, "what about those poor animals on the edge of the herd?" Those poor water buffalo, gazelles, etc. that are caught on the edge are obviously very interested in reaching the interior of the herd. There be lions and tigers (figuratively of course; tigers do not roam the savannas!) in those bushes after all.

Now, standing back at a thousand-foot view we can gain a view of a writhing superorganism. The edges constantly in flux, collapsing inward towards the center whilst the interior is shuffled outward.

Zoology lesson aside, what does this have to do with IP addresses? Moreover, what does this have to do with information security?

Question: what prevents us from conceptualizing our IP addresses (more specifically, subnets) as herds? It would make sense that our lions and tigers (read: adversaries) lurk nearby- nearby being at the lower ends of our subnets. I'm not sure I've ever seen a piece of network-enabled malware or human take a binary search approach to network mapping as an example. No, logic would tend to dictate that any asset inventory effort begin at the logical starting point. For a subnet, that means .1 most commonly.

So, if our subnet is herd, wouldn't it make sense then to "herd" them into the center of the range? Yes, I would avoid starting at the top of a range since that could logically also be the beginning and, within the context of our analogy here, serve as the same kind of herd edge as the true .1 beginning. It would also stand to reason to make the herd as large as possible I would put forth...none of those pesky, small class C's! Now, what if I had truly dynamic IP capabilities? I don't mean DHCP, rather a truly dynamic IP mechanism that was more akin to how dynamic rekeying works in IPSec or WPA2 technologies. Wouldn't that (somewhat) resemble the natural ebbs and flows of a large herd? I think so.

In that kind of environment, how would an adversary ever close in on his/her prey? Moreover, how much longer would this extend any kind of autodiscovery attempt (port scanning, etc.) thereby allowing our IDS to kick in "sooner". Good security is, afterall, a simple time trade-off calculation. I need to make sure it takes longer for "you" to compromise an asset than it does for me to detect "you".

Yeah, there be lions and tigers here. Of course, the zoology analogy is intentionally simplistic- this a security blog and all- but I rather think there is an opportunity to re-examine how we manage our IP schemes and perhaps an opportunity for some new technology.