Microsoft pptp vpn vulnerabilities Exploits in Action

© SANS Institute 2000 - 200
                                                5
, Author retains full rights.
 
 
 
 
 
 
 
 
 
 
 
 
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 
 
© SANS Institute 2000 - 200
5                                                                                                                 
Author retains full rights.
51
Client connected before and during attack:
Connected client after rebooting server, and server had to run chkdsk, 
connected no problem.
start attack: 04:51:00
CPU jumps, client can't ping internal VPN at all instantly, and starts getting 
about 50-75%+ packet loss externally from server
04:51:51 stopped attack, CPU drops back down, client can ping again (still 
connected, hadn't dropped VPN yet), memory climbed up to 68mb from 32mb, 
levels off as soon as attack stopped.
04:53:00 resume attack:
same results, CPU jumps back up to 60%, memory climbs quickly. client looses 
pings.
a few packets pings respond at 04:53:55 
04:54:16 CPU pegs. but client still connected and getting occasional pings
04:54:23, stop attack CPU remains pegged, memory at 128mb (50%).
04:55:01 client suddenly starts getting  100% pings back again from VPN and 
external!
04:55:35 client suddenly loses ALL pings via VPN and external.
attempt to run any programs meets with expected results.
04:57:00 attempt to shutdown, same results and pop-ups occur.
note client is getting pings again, but can't get any resources (shares) from the 
VPN server, though able to get resources from other machines on the network 
behind the VPN server!
Detailed Lab Notes:
PPTP Attack #4:
Laboratory Log notes:
Ok, the attackpptp4 script showed the following once a connection started to be 
established by the client:
[root@bofhlnx pptpattack]# ./attackpptp4
192.168.50.8 <- 10.0.0.2 CHAP Challenge
Using MS-CHAP v1
192.168.50.8 <- 10.0.0.2 CHAP Response
10.0.0.2 <- 192.168.50.8 CHAP Response
Then in the output file chall-resp1.out were the following contents:
VIRTUDOMUser (Server 10.0.0.2 Client 
192.168.50.8):0:314357FD599070F2:5CC96E21D78E3F633C1B231647B327A3
0B3E621706F3DD12:43BBBE7E3692D2E19659F45129DD4ADEB2A54055D8
E0AF1E
0

---