OpenVPN Cont. - Adding username/password authentication to openvpn

This post basically adds onto the steps outlined in the previous post. By adding username/password authentication, you are essentially providing a two factor authentication mechanism to your openvpn server. The client would need a usable client certificate and key to authenticate itself to the server, as well as provide a valid username and password.

We have already discussed using certifcate authentication in the previous post so i wont be going over that here. To add the user/pass mechanism we would be adding to our already existing configuration files one or two lines.

In the server config file, add the following:
plugin /usr/lib/openvpn/openvpn-atuh-pam.so system-auth

On the server create a group called vpn
# groupadd vpn

Then we can create each user:
# useradd -s /bin/false -g vpn vpntest // this creates the user and puts them in the vpn group
# passwd vpntest // gives the user vpntest a password for authentication

On the client config file, add the following:
auth-user-pass
pull

Thats it. Keep in mind that we were adding to our config files from the previous post, so it is presumed that you already have a working openvpn server that accepts client key/certificate authentication

Resources/Good Reading:
http://www.uno-code.com/?q=node/120

OpenVPN configs made easy

If you are reading this, i'm assuming that you would already know what a VPN is. If you are not familiar with the term, you can read this Wikipedia entry to get up to speed with the technology.
This guide would not be a full featured guide on how to setup the "complicated" openvpn software. For quite sometime now, i have avoided Openvpn as i've always read about how hard it is to setup up and configure. I've used other VPN technologies such as hamachi and adito. While these solutions are great, i've always felt like i was holding myself back by not giving Openvpn a chance. After following some tutorials, some quite simple and others very complex, i am happy to say that i've finally set up Openvpn server. The best thing that i have taken from this experience is that its not all that hard to set up. There are guides out there that seem very intimidating on the topic and my hope is to try and take this confusion away and give you the quick 101 of openvpn.

---+++Using openvpn with secret key.+++---

I've used Backtrack 5 to setup my server (you can use other linux distros as well)

1. Install Openvpn. Backrack 5 already comes with it pre-installed. If your distro didn't come with it already install, you can install by issuing # apt-get install openvpn (applicable for debian based systems that use apt for managing packages)
2. Navigate to openvpns config dir. # cd /etc/openvp
   
3. Create a secret key. # openvpn --genkey --secret secret.key
   
4. By default no config file is available. Lets create one. # touch openvpn.conf
5. Using your favorite text editor, open up the config file that you've just created and enter in the following:

proto udp # protocol to use. Either tcp or udp
port 1194 # port num
dev tun # can be either tun or tap. Tun is simpler to sertup
ifconfig 10.0.0.1 10.0.0.2 # The 10.0.0.1 is the desired IP for our server's virtual interface and the other is the peer
secret /etc/openvpn/secret.key # secret key used for authentication
cipher AES-128-CBC # encryption cipher to use
user nobody # drop priveledges to this user
group nobody # same as above
verb 3 # logging level

Thats it for the server set up. Now copy the secret.key file and the openvpn.conf file to another linux client that already has openvpn installed. Note that the server and client config files are almost identical with few minor changes. Copy the files to the location /home/user/.openvpn (this location is not mandatory but lets just be organized).

1. First change permissions of config and secret key file. # chmod 644 secret.txt ; chmod 644 openvpn.conf
2. We need to add 1 line to the openvpn.conf file and modify the ifconfig parameter. So the client's openvpn.conf file will look like this

remote 192.168.0.5 # VPN's server's real ip
proto udp
port 1194
dev tun
ifconfig 10.0.0.2 10.0.0.1 # notice the change here
secret /home/user/.openvpn/secret.key
cipher AES-128-CBC
user nobody
group nobody
verb 3

Thats all for the client configurati0n.

Starting the server and client take identical commands and require root privileges. Onceyou are root, you can start the server and client like so: # openvpn --config /etc/openvpn/openvpn.conf

Once the connection is established both the server and client terminal windows should give some details similar to this:

Sat May 28 20:53:16 2011 Initialization Sequence Completed

To test your VPN connection, you can use the ping utility.

---+++Using openvpn with certificates.+++---

Server setup:

1. Copy scripts for handling certificates to /etc/openvpn directory. # cp -r /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn
2. Goto scripts dir. # cd /etc/openvpn/easy-rsa/2.0
3. Modify the "vars" file. The variables that you want to modify are at the bottom of the file. These include KEY_COUNTRY, KEY_PROVINCE etc.
4. After modifying the vars file, issue this command on the file. # source ./vars
5. Clean up older keys. # ./clean-all
6. Create CA key and certificate. # ./build-ca
7. Create the openvpn server's certifcate and key. # ./build-key-server openvpn_server
   
8. Create client keys and certificates. # ./build-key client1
9. Create dh key. # ./build-dh # this can take a 2-4 mins to create. Move your mouse around an be patient :)
10. Goto keys directory. # cd keys
11. Copy the dh1024.pem, ca.crt, openvpn_server.crt and the openvpn_server.key files to /etc/openvpn/ directory
12. Lets create our server config file:

tls-server # this would be the server in tls mode
proto udp # protocol to use. Either tcp or udp
port 1194 # port num
dev tun # can be either tun or tap. Tun is simpler to sertup
ifconfig 10.0.0.1 10.0.0.2 # The 10.0.0.1 is the desired IP for our server's virtual interface and the other is the peer

ca /etc/openvpn/ca.crt
cert /etc/openvpn/openvpn_server.crt
key etc/openvpn/openvpn_server.key
dh etc/openvpn/dh1024.pem

cipher AES-128-CBC # encryption cipher to use
user nobody # drop priveledges to this user
group nobody # same as above
verb 3 # logging level

Client setup:

1. Copy the ca.crt, client1.crt and the client1.key files to the client
2. Create its config file:

tls-client # this would act as client in tls mode
remote 192.168.0.5 # VPN's server's real ip
proto udp
port 1194
dev tun
ifconfig 10.0.0.2 10.0.0.1 # notice the change here

ca /home/user/.openvpn/ca.crt
cert /home/user/.openvpn/client1.crt
key /home/user/.openvpn/client.key

cipher AES-128-CBC
user nobody
group nobody
verb 3

Again, starting the server and client take the same commands but you must have root privileges. Once you are root, you can start the server and client like so: # openvpn --config /etc/openvpn/openvpn.conf

Once the connection is established both the server and client terminal windows should give some details similar to this:

Sat May 28 20:53:16 2011 Initialization Sequence Completed

To test your VPN connection, you can use the ping utility and ping each node.

Extra:

If you want revoke client keys:
# ./revoke-full client1

This would add client1 to a sort of black list that would not allow them to connect to our VPN anymore. The file that houses this black list is crl.pem. Create a hardlink (ln without the -s option)to this file in the /etc/openvpn/ directory.

You would also need to add this line to the configuration file on the server. This causes the server to check its revocation list whenever clients try to establish a connection to the VPN server.

crl-verify /etc/openvpn/crl.pem


I noticed that when a revoked client tried to connect to the vpn, not only were they denied service, the VPN server was also shutting down. It seems like the when openvpn shuts the connection down, it tries to reinitialize its tun interface, but fails to do so because in our config file, we dropped our priveledges to nobody. This issue is quickly resolved by commenting out or deleting the lines with the parameters user and group on the server config file.

Resources/Good Reading:
http://openmaniak.com/openvpn_tutorial.php
http://www.adamsinfo.com/quick-linux-and-windows-openvpn-howto-and-tutorial-including-vpn-routing/

Vicompress: http proxy server

Vicompress is an http proxy server, with the ability to cache requests in memory. It has a small footprint but because of its ability to cache contents in memory, it can eventually use up tons of memory resources. It has decent log statistics capabilities too and outputs to an html formatted page. Most important to me, setup and configuration is quite simple.

Installation:

1 . Download the installation package from visolve website. In my case, i downloaded the .deb version of the package.

2. To install i used the command: # dpkg -i package-name

Configuration:

For details on all configuration parameters, go here

The default configuration would do just fine, but its useful to learn of its parameters
Here is a snapshot of my vicompress.conf configuration file:

listen 0.0.0.0 8080
outgoingip 0.0.0.0
enable_compression yes
enable_caching yes
cache_memory 200
max_cacheditem_size 10000
cache_expires 2
enable_dns_caching yes
dns_expires 2
user nobody
rotatesize 10
logformat squid
enable_debug no
accesslog /usr/local/vicompress/log/accesslog
errorlog /usr/local/vicompress/log/errorlog
errorpage /usr/local/vicompress/etc/errorpage.html
logstats /usr/local/vicompress/logstats

To start the server: # /usr/local/vicompress/bin/vicompress.sh start

To view the statistics of your proxy server, usually a report gets generated every hour. You can speed this process by issueing this command:

# cd /usr/local/vicompress
# ./bin/update_log_stats /log/accesslog logstats

To view the report issue: # firefox /usr/local/vicompress/logstats/statsindex.html

Resources / Goodreading:
visolve

Inetd and perl

Just a quick simple trick that you can help you set up servers quick and easy. You don't have to know alot about programming either but it helps to know what Inetd is in linux.

Inetd, on its manpages is known as a internet superserver. All those big words aside, it can basically listen on a given port for you and when a connection comes in, it calls the appropriate application to handle them. It so turns out that you can use Inetd's sockets for network communication instead of programming your own. What that means is that inetd can listen on port 80, and when a connection comes in on that port, we can run a shell script that simply sends back some text or html tags. Inetd's output is piped to the calling program or script's standard input and that program's output is redirected to Inetd's standard input.

Lets quickly demonstrate this with a bash script.

#!/bin/bash
echo "Hello World"

Now save that script to a file called hello.sh and give the file executable permissions.
# chmod 555 hello.sh

Now configure /etc/inetd.conf as follows

http-alt stream tcp4 nowait root /root/hello.sh

Now save the file.

Run the inetd daemon
# /etc/init.d/inetutils-inetd start

now netcat to port 8080 (which is what http-alt) service is and you should revecieve a response:

root@bt~#: nc 127.0.0.1 8080
Hello World
root@bt~#:

All should work well if done right. Now to get a lil bit more fancy, i've put together a perl script that takes an input and returns the MD5 hash of that input (an MD5 hashing service if you will).

#!/usr/bin/perl -w


# A simple inetd socket server.

use strict;

my $old_fh = select(STDOUT);
$| = 1;
select($old_fh);
print "++ MD5 pass generator ++\n\n";
print "Type \'exit\' at anytime to quit\n";
print "Enter string to be hashed: ";

while( my $line = )
{
$line =~ s/\r?\n$//;
#chomp($line);
if ($line =~ /^exit$/)
{
die "shutting down\n";
}
# do your processing here!
$line = `echo -n $line | openssl md5`;
print "$line\n";
print "Enter string to be hashed: ";
}

Save the perl script to a file like md5.pl and chmod 555 your file.
Start the inetd daemon as shown above and use netcat to connect to the service :)

Backtrack 5 is out

Backtrack 5 is out folks. Head on over to the backtrack website to get yourself a copy of this well put together masterpiece. There are 32 and 64 bit versions available now, as well as the classic KDE styled version and a new GNOME version, which put you in an Ubuntu like environment. I've decided to go with the Gnome version, as im use to Ubuntu and it was refreshing to use something other than the classic desktop environment. All versions should have the same tools and capabilities so its all a matter of preference.

What are you waiting for? Get your copy here.

Usefull malware analysis tools

Was reading some articles from an e-magazine @ haking9.org involving basic malware analysis techniques. Why would anyone (the average person) want to do this? Maybe some people just have alot of time on their hands or like me, just want to know how everything works. It is very important for anti-virus vendors to do malware analysis in order to produce signatures to identify the malware throughout scans. If you got some time on your hands, i suggest that you drop by hakin9.org and check out some of the articles including the ones relating to malware analysis.

Tools:

Regshot: This tool, as it names says, takes a snapshot of the regisrty. It basically gives you a baseline of what the registry looks like at that point in time. Given that baseline, you can then execute the suspicious executable, then take another registry snapshot. You are then able to compare both snapshots using regshot's compare feature to find out what keys have been added, modified or deleted. It has the option of outputing its results in a text file or a nicely formated HTML file.

Regmon: Like regshot, regmon is registry utility that operates in a slightly different manner. It has the ability to give real time analysis of what keys (and their location) currently running processes are accessing. It lets you know whether the process is querying information, creating new keys, setting values, etc. Just before you execute the malware, you can have regmon running in the background capturing its information. When the program has been executed, you can stop regmon's capture and perform your analysis. You would notice that while regmon was capturing data, it not only captured information for the malware process you are investigation, but also other processes as well that were recently accessing the registry. Thankfully, there is a nice filter feature that allows you to filter the captured data based on the process name. Although the filter is very limited, it is still beneficial to have. You can also look into another tool called procmon, who is the current successor of the tools regmon and filemon. It has the same capabilities of regmon and many more options. However, regmon still has its place and is simple to use and learn.

Filemon: This tool works in a similar fascion to regmon, but with files. It monitors processes that access files on the disk and log their actions(read, write, query, delete,etc) and whether they were successful or not. Like regmon, just before you execute the malware, you can have filemon running in the background capturing its information. When the target program has been executed, you can stop filemon's capture and perform your analysis.

Wireshark and Netcat: It is known that some malware tend to want to replicate themselves over the network. Some may try to covertly download software or try to log onto some IRC channel to query its commands (google: botnet). These tools are coded to work covertly, so while you're sitting at your desktop, you would not see any indication that anything is going on. Wireshark can help us understand the why, where, what, when and who questions. Why is the malware connecting out to port 4444; where is the malware trying to connect to; when or at what intervals does the malware initiate any type of network traffic; what is the malware trying to do or accomplish; who is involved (source IPs, mac addresses, domains etc.). Netcat can be set up to intercept this traffic in a proxy mode and also be used to interact/respond to services and requests.

Netstat and tasklist: Before analyzing any piece of malware, having a baseline is very vital. You are gonna need to have an idea of what the system looked like before and after the malware was run. Running netstat and tasklist before running the executable can give us a baseline of what network sessions are open and ports that are listening etc. while the tasklist command utility can give us a list of currently running processes. Tools that you can be use as well are sysinternal's process explorer and tcpview.

Debugger, Ollydbg: To really get in depth with exactly what the executable is doing, you will have to use a debbuger to step through the system opcodes and system calls. Using a debugger is not easy for most and can take a little bit of getting use to. However, to be good at malware analysis, you cannont escape not learning how to use a debugger like IDA pro or in my case, Ollydbg.

Virtual environment: To avoid potentially infecting your main system and possibly breaking your Windows OS, you will definitly want to perform most, if not all, your analysis in a virtual environment. Virtual machines also provides us with a mechanism to roll back a host to a snapshot of a system at an earlier time. This allows us to restore the state of a system to a point just before an event occured (say the malware caused the OS to no longer start up) withing minutes. There are quite a few options avaialble for virtualization but i myself use the Virtualbox technology. Remeber to check out the system requirements of these technologies before installing to your old pentium three laptop with 256 ram.

PE tools: Sometimes malware may be packed by common packer tools, like UPX. The benifit of using a packer on an EXE file is that it can allow for the compression of the executable. However, by doing so, the original exe's form is thus changed. Eventually, what you get is an exe within an exe. The outer layer exe will be the packers decompression code that decompresses the internal exe in memory and then executes it. The additional benifit of this is that it can make debugging of this packed executable a pain in the but. In order to properly debug the functionality of the packed executable, it must first be decompressed in order to be analyzed. Tools like PeID can help us identify a packed executable's packer. By knowing this, we can potentially in some cases use the same packer to unpack the executable back to its original form. Another PE tool that i use is Lordpe, which allows for the modifying of the PE headers of binary executables.

These are just some tools that can be utilized in malware analysis process. I encourage you to do your own research and look up the malware analysis articles in the hakin9.org website. The articles are available in PDF format and is a little bit difficult to directly link to :(

Resources/Good Reading:
hakin9

Windows and its PE file structure

I'll start this post of by asking a question; WTF is a PE file? A PE file is something we use on a day to day basis when we use our computer systems. The files that have the ".exe" and ".dll" extensions are what we refer to as PE (Portable executable) files. A PE file contains one of the most complex file structures that i've ever seen and its very important to understand most, if not all of it if you want to be modify the binary file or become a reverse-engineer. Becasue there are so many structures, i can't go through them all (i don't even understand 50% of them) but i will try to focus on the most common ones.

For a visual of what the structure looks like, goto google images and search "PE file format".
Here is one that i found and usually reference: link

[ MZ header] - "hex bytes: 4d 5a"
[ Dos stub ] - "This program cannot be run in dos mode"
[PE header] - "Hex bytes: 50 45 00 00"
[optional header]
[Data directory] - "Structure of important locations such as import table, export table, etc."
[Section table header] - "array of structures describing the properties of each section."
[section 1]
[section 2]
[section n]

Every PE file should contain the above information. The very first two bytes of the file should be "4d5a", which is MZ. This indicates the start of the dos header. At position 0x3c in the Dos header, is a dword (4 bytes) that indicates the offset of the start of PE header. Directly after this should be the DOS stub that basically prints a string saying that this program cannot be run in dos mode or something similar.

Following the dword offset at positon 0x3c should take you to the start of the PE header and should containt the hex bytes "50 45 00 00". Other useful information contained in here include . the machine type (i386, i686, etc.) , the number of sections and size of optional header.

24 bytes from the PE header starts the Optional header. This structure is in every PE file and isn't really optional as it may suggest. It contains many relevant fields that the windows loader needs in order to load the file correctly into memory.

The data directory is a listing of the locations of important data such as the import tables (when you use functions from windows DLLS, you have to import them.) and export tables.

Section header is a structure containting the properties of each section. This information includes its name, its size on disk and in memory and its location.

The last sections will house the individual sections referenced in the section header. You can use the information in the section header to find the relevant offsets and size of each section.