Wednesday, May 22, 2013

Facebook and security

I discovered something interesting recently. I knew that Facebook checked if it was a know connection before giving you access to your homepage and otherwise it tells you it is an unknown device. Well in my recent experience they made quite a lot of mistakes in the process.

I made a connection from abroad with my laptop so it was the same device but it triggered the same mechanism. To prove I was myself I had to identify people in pictures they uploaded.

The interesting thing is that some of the people I know have put family pictures up. One series of photos was the dad in one picture, the mom in another one and a daughter in the last one. Looking at the names I could figure out which name I had to select but it was interesting that it was 3 times a different person.

While doing the procedure I thought of how I would attack it and it would be actually quite easy. You just have to do some homework like figuring out family and friends which is not that hard. I guess facial recognition software would be a possibility too.

Thursday, May 9, 2013

A simple OpenVPN setup with Zentyal

The other day I needed to come up with a VPN solution for somebody with no networking or IT knowledge whatsoever. The question was of course not formulated like that. The original question was "I need a way to surf the Internet from anywhere in the world and be sure I can do everything that requires security like online banking ect."

I recently ran into Zentyal, a modified Ubuntu, and that looked like an actual tool for this job. So I ran a test the other day and I must say I was pretty impressed by the ease of setup.

The first step was the regular OS install. Once installed logged into the management console which is completely web based which is good because that would take care of the simple part for the person I was building this solution. The good part is that I still have a command line when I need something, it is still a full blown linux.

As a second step I configured the network, gave the machine a static IP address and the IP address of the gateway. Did a ping to www.google.com to test name resolution and network connectivity and it worked so I was up and running for some basic testing.

My first test was to check how the software installation from the web interface worked and I must say it was pretty slick. I installed the ClamAV module as a first test. It installed it, downloaded the latest virus definitions and ran. The next day there was an update for ClamAV on Ubuntu (I know this because CERT.be published it in its advisories). When I got home, I saw it didn't update ... I was not happy of course because. It was my mistake, I found that there is this auto-update which I tested and it works fine.

Then it was time for the real test, setting up the OpenVPN (We worked with dynamic DNS for the OpenVPN server). According to the manual, it looked pretty straight forward. When selecting the package from the inventory it said you also need the certificate authority. After creating the certificates an configuring the VPN with the certificates it was just a click to download the configuration file with the correct certificates in a tar.gz and copying them on the other machine. The files can be produced for Windows, Linux and MacOS X.

I installed Tunnelblick on the Mac, dumped the contents of the tar.gz in the appropriate directory. Last step was to configure the gateway to allow the Tunnelblick to connect to the OpenVPN server and I was ready to run a test. It worked like a charm.

I must say I am pretty impressed because the GUI allowed me to explain everything in a simple way to the end user. How to create other users, track there activities etc. I would recommend it to check it out if you are looking for a solution in a small environment.

Update: I forgot to mention I needed an extra route in my router because the VPN is a different IP range.

May 2013 ISSA-BE Wrap Up

This week there was another ISSA-BE chapter meeting. The whole evening was themed around forensics.

The first talk was given by Sally Trivino and was called Forensics Technology Solutions for Litigation Support.

First topic at hand was "what is evidence". Sally pointed out that two things come into play. The validation of suspicions and the legal facts admissible in court. A little side note I want to make here is that I learned from my legal department that to prosecute somebody, you need to be able to show you suffered damage.


Life would be simple if there was just evidence but there are different kinds of evidence. The first type is rather straight forward, direct evidence. The best example of this is "the smoking gun". You have actual direct proof of what happend and who caused it. Of course this is not the case in computer forensics so you need to find circumstantial evidence. This means that you must correlate different sources to confirm a hypothesis.

For your circumstantial evidence to be admissible in court you have to follow forensic procedures. These are a set of procedures you must follow or you can't build a case. Which forensic tools you can use depends on the jurisdiction. By using scripts, you use a tool that everybody can read thus it is most likely to be acceptable. Standard tools like EnCase, FTK, and SANS SIFT are usually part of the acceptable tools but it is better to check then to be sorry.

As for any craft you will pick the tool based upon the job you need to do. Depending if the data is structured or unstructured, volatile or static, direct or indirect you will need other tools and the field of forensics has a different name.

To explain to the audience how forensics take place Sally showed us as example the EDRM general approach. Some things are obvious other things are less. It is hard to go into detail what she said but there is one thing I think is important to take away from this is that when you write your report you need to write it for non-techies a.k.a "normal" people, not lawyers. It is your job to explain what happend to a judge. To explain that story it is good to have an investigation trail.

As last part of the talk Sally highlighted a couple of best practices in forensics:
- make a safeguard as soon as possible
- make sure you have minimal impact on the system
- look at the different legal aspects
- make sure you have a chain of custody
- make sure you have an evidence trail
- make sure you have pristine copies, only work on copies.
- make sure you have reputable tools
- make sure your files are cryptographically verifiable
- factor in data skew (check against the atomic clock)
- correlate logs.

Finally we briefly touched upon the challenges in the forensics field.

First of all there is wiretapping. In Belgium this is according to the law only allowed for certain purposes by law enforcement. If you thus sniff traffic on your company/private network you might be committing a crime against the privacy laws. I recently assisted a workshop and this was one of the topics addressed during the workshop. From what I remember you can actually sniff but before you do talk to the legal department because the matter is rather complex.

Of course forensics with the whole cloud computing story becomes more complicated. A piece of advise on this was that you have to be sure where your data is because
a) you can't "export" certain types of data
b) the rules of other countries may apply to that data

When you outsource tasks you are still liable for everything, you can't outsource legal responsibility

Finally Sally gave us a heads up on the data breach notification act from the EU. If you are not familiar how it works. It is rather simple the EU makes directives and then the EU countries have a certain period to implement a law about it. On the matter of data breach notification I can recommend ENISA's text about the subject.

The second talk was by Didier Stevens on his network device forensics. Unless you have been living under a rock lately or don't read Didier's blog you must have heard about the new tool that Didier wrote recently.

His research was done on an CISCO ASA device but it is not his intention to limit it to this type of devices. He wanted to figure out what information he forensically could retrieve from a network device.

Like a regular computer system the golden advice nowadays is "do not shutdown". The devices have a small disk but everything runs in memory. It might be a good idea to disconnect the network if possible because the data coming in and out will change the memory.

The first step in forensics Didier made confirmed what Sally said in her talk. You got to have logs, and not just stored locally but centralized with a syslog-like solution. What to log is important too. By default you get some but not all information, so it is recommended that you change that in your configuration.

An example of events to log:

When you connect a laptop or a desktop to a switch is a “switch port state” change. It logs the physical connection and the logical connection. This could be useful since you now have a physical location where the person was when he/she plugged-in.

Some devices have special security features like NAC/NAP or DHCP snooping. When you use this in monitoring mode, it creates a log but no policy is not enforced. This log can then be used in forensic analysis.

Compromising a network device can be done on multiple levels:

A (running) configuration change can be made. Therefore it is important to have configuration and release management. You can dump the running configuration to a file and compair the hashes. You must know what is “running” on a CISCO device and the “written” configuration are not the same. You got to specifically say “store on disk”.

Scripts change the behavior of the device configuration. Again when you use them you must be able to compair them with the script you've put in by doing configuration and release management.

You can compromise the OS image. Didier explained how he manipulated the function that calculates the hash for the image and it always came back that the hashes were ok.

Then we were in for a treat, a little demo of NAFT. Right now only NAFT and CIR are the only open source tools for doing this kinds of forensic analysis as far as Didier is aware. The demo where you see passwords being dumped from the image was pretty cool.

It was an interesting evening, the next ISSA-BE chapter meeting will be in June. Check the website if your are interested in joining.