With the passage of time and the current development of fast Internet access technologies, the security community has started to forget the good old days of breaking into networks through Plain Old Telephone Service (POTS). Although old dial-in systems used for remote access into a company's internal infrastructure are being widely replaced with modern VPN technologies' reduced costs, greater speed, and added flexibility, a great number of organizations are too slow, too bureaucratic, or see no practical need to switch to VPN.
Although wardialing is one of the oldest methods of gaining unauthorized access to the targeted systems, it is one of the dangers most commonly forgotten by network engineers and system administrators especially for those young enough to have never encountered remote dial-in access. However, a single improperly configured machine with a modem connected to a telephone line might make the whole perimeter defense useless.
Rather than launching a frontal assault, a hacker can sneak past all the expensive firewalls and IDS and head straight into the core of the net. Through wardialing, an attacker searches for the devices located in the target network infrastructure that are also accessible through the telephone line. You might argue about the relevance of wardialing to the Cisco devices if you forget that most Cisco hosts can communicate via modem. Before we get to the part of how someone can abuse such a device, you must know about situations when you are likely to find these devices and why such means of access do exist.
The three main reasons for attaching a modem to a Cisco router are either remote access to the Cisco device itself, dial-on-demand, or dial backup.
Remote access is often required for a device stationed in a distant location, when physical access to the unit is troublesome or impossible . If something major goes wrong with the device, a remote out-of- band way of connecting to it and fixing the problem is available. Service companies often install designated lines to such equipment on the client site, so that administrators have additional means of accessing it to perform maintenance, upgrades, or otherwise manage the device.
Dial-on-demand is commonly used to establish connectivity on an as-necessary basis, maintain it as long as required, and drop it when it is no longer needed. Dial-on-demand routing (DDR) is commonly found in networks where access to external resources is required on an occasional basis and the volume of the transferred data is low. It could also be a way to provide redundancy and traffic load balancing under a heavy load. Dial backup is most frequently found in networks where redundancy is necessary. Such an option is exercised in situations where a constant link exists between sites, but the dial-up option is kept on standby in case the main link goes down. In case of the fault, the system automatically initiates a dial-up connection so that the connectivity remains uninterrupted.
For dial-on-demand and dial backup, we are interested in situations when a router is configured not only to initiate the call, but also has an ability to receive and respond to one (the difference in the config file being modem inout and modem callout commands).
One of the distinct features of the Cisco routers allows us to identify devices that listen on the serial interfaces without actually doing any wardialing, thus saving time and money. To understand how this can be achieved, you need to understand how a Cisco router differentiates between its serial lines.
The possible line types are as follows :
auxN The router's auxiliary port, commonly used for modem backup connections
console The router's console port
ttyN The router's asynchronous port used for modem connections
vtyN The virtual terminals, the router's Telnet and rlogin connections
To make the matter a bit more complicated, two numbering notations are used: absolute and relative . While in relative line numbering addresses, the first TTY present is tty0, first vty-vty0, and so on, the absolute line numbering is calculated by its location on the system. The following table shows the absolute/relative numbering scheme:
On newer modular Cisco routers, the TTY numbering is different, since the modular extensions have reserved TTYs allocatedfor example, Slot 0 has reserved lines 132, slot 1 has reserved lines 3364, and so on. So the AUX port absolute numbering on the router with two modules slots would be 65.
Let's look at asynchronous ports (TTYs) and the auxiliary port in more details. A TTY port directly corresponds to the asynchronous interface of the router to which the modem is connected. Note that when you configure the TTY port, you configure the hardware aspects of the connectivity between the port and the attached serial device. To configure the overlaying protocol, you need to specify the corresponding asynchronous interface. The typical configuration example of the modem attached to TTY interface 2 set for dial-in is shown here:
line tty 2 login local modem dialin modem autoconfigure discovery speed 115200 flowcontrol hardware
The AUX port is typically configured as the asynchronous serial interface on routers without built-in asynchronous interfaces or as a backup asynchronous port. It is also possible to configure it as a backup console port, but more often it is used for remote dial-in purposes. As compared to the normal asynchronous line, its performance is much slower and it misses some essential functions supporting up to 38400 Kbps (on older hardware) but would an attacker really moan and complain if he or she can get in this way?
A sample configuration of the AUX backup link looks like this:
chat-script arh0nt ABORT ERROR ABORT BUSY "" "AT" OK "ATDT \T" TIMEOUT 45 CONNECT \c ! dialer-list 1 protocol ip permit ! interface Serial0/0 ip address 192.168.30.202 255.255.255.0 encapsulation ppp backup delay 10 1 backup interface Async65 no ip mroute-cache ! interface Async65 ip address 192.168.30.222 255.255.255.0 dialer in-band dialer string 123456789 dialer-group 1 async dynamic routing ! line aux 0 script dialer arh0nt modem InOut
Once you are set up in testing conditions, try Telneting to the IP address of the serial 0/0 interface to port 2001. You'll see a prompt. By Telneting to one of the upper ports, the router redirects the request back out of a selected asynchronous line, the so-called reverse telnet connection process in Ciscospeak. By connecting to the port 2001, the router executes the login procedure and connects the session to a mapped line. The mapping of the ports is rather straightforward: subtract 2000 from the Telnet port to get the number of the TTY to which you are connected. The same rules apply to the numbering of the AUX port, but on the router with absent TTY ports, the AUX interface would always map to port 2001. Additionally, you might want to check 400(TTYn) and 600(TTYn). The former is usually used for sending data directly to a printer, while the latter is the same as port 200(TTYn), except that it turns off the carriage -return translation.
The enumeration of such devices is easily achieved with the use of the excellent tool ADMcisco from the ADM crew ( http://www.adm.freelsd.net/ADM/ ):
#arhontus / # ./ADMdialout ADMdialout by plaguez - reading from stdin 192.168.66.202 FOUND DIALUP host: 192.168.66.202 port: 2001 !
This tool tries to open a connection to the host sequentially on the port in the range between 2001 and 2011, and it sends the Hayes-compatible .I command if it gets an OK response; such a host is considered vulnerable, thus not requiring authentication to use the serial device connected to it. What a great opportunity to use a modem remotely! You can even write a small shell script that will connect to the host and dial out to wardial in a foreign country without having to pay a huge phone bill. (Speaking of phone bills, you have most certainly come across some premium phone numbers where you are charged ridiculous amounts per minute. You get the idea of how a malicious hacker can make a bit of cash.)
Moving back in time, let's pay more attention to "real" wardialing and the available software. Hacking networks through wardialing has been covered in great detail in other editions of Hacking Exposed . Although this book is about hacking Cisco networks, we will cover wardialing software available for Linux, introducing our readers to the tools suitable to do the job on the most famous Unix clone.
Although they have no fancy GUIs or huge databases of fingerprints of the responding devices or any other colorful options you might find in the commercial products, these tools are written with one purpose in mind: effectiveness.
One of the best and quickest wardialing scanners available is ward, a tool currently being developed and maintained by Marco Ivaldi. You can visit its homepage at http://www.0xdeadbeef. info ; the latest version at the time of writing is v2.3, released on January 22, 2005.
Once you download the source code, you'll need to compile it by executing the following command:
arh0ntus ward # gcc -lm ward.c -o ward23
The tool should compile flawlessly. (If you get any error messages, write to email@example.com for suggestions.)
arh0ntus ward #./ward23 -h ward.c v2.3 - Fast wardialer for UNIX systems (PSTN/ISDN/GSM) Copyright (c) 2001-2005 Marco Ivaldi <firstname.lastname@example.org> usage: ./ward23 [ [-g file] [-n nummask] ] [-r] (generation mode) ./ward23 [-s file] [-t timeout] [-d dev] (scanning mode) generation mode: -g generate numbers list and save it to file -n number mask to be used in generation mode -r toggle random mode ON scanning mode: -s scan a list of phone numbers from file -t set the modem timeout (default=60secs) -d use this device (default=/dev/modem) help: -h print this help
The tool presents you with two modes of operation. In a generation mode, you can create a list of numbers that you want to check and feed back into ward later in scan mode. Note that when you generate the number list, it is advisable to specify the -r option to randomize the order of the phone numbers in the list, so that you are less likely to be identified by telcos as conducting wardialing from your landline .
Before executing any wardialing, be familiar with the attitude of your phone company toward such activities.
By executing the following command, you will generate the phone number list of 12,000 11-digit numbers that start with 0313371 :
arh0ntus ward #./ward23 -g hecisco-pn.txt -n 0313371xxxx -r
You can feed the list into ward for immediate wardialing or split it into several parts to be dialed on different machines or by different instances of ward, providing you have several modems connected.
Once satisfied with the layout of the number file, feed it into ward, setting the delay of the total time ward will spend on each phone number and specifying the device to which a modem is connected:
arh0ntus ward #./ward23 -s hecisco-pn.txt -t 30 -d /dev/ttyS0
You can relax now and continue with other tasks , since wardialing is a rather timely process, especially if you have a large list of numbers to go through.
All the activities of ward are written into the file with phone numbers, so as ward continues its work, you can monitor the progress by looking for changes in the phone number files, which will have a format similar to this:
03133712679 - 03133713370 CONNECT 03133714050 - 03133712287 UNSCANNED 03133715449 UNSCANNED
The number files reflect the progress of the current session, so that numbers that haven't been scanned yet will be marked as UNSCANNED ; therefore, ward can safely be stopped and the session can be restored another time.
Ward does not make any distinction as to whether or not the prompt presented is a Cisco device, so you will have to search through the numbers that have the CONNECT response to check for device type. The current version of the tool is also incapable of differentiating between data or fax response.
Identifying a device that gives you a prompt doesn't mean much. You can't be sure that this device is in fact the one you are looking for or that it even belongs to the network that you are determined to break into. As with every proper pentest, root is what really counts, so you have to gain access to this device. For the most part, the only option available to you if you come across a Cisco device is the boring old bruteforcing option. But this is what this chapter is really about. We have described the Telnet bruteforcing earlier on and nearly the same rules apply to the dial-in devices bruteforcing, although the tools useful for this job are different and the whole process is painfully slow. So cut your standard usernames/passwords list in half and go on downloading THC-Dialup Login Hacker.
THC-Dialup Login Hacker is one of the few tools that is able to dial a specific number and try different combinations of username/passwords against modem carriers . The tool has been developed by Van Hauser from The Hacker's Choice (THC), and the latest version1.1 as of this writing, released on June 25, 2003can be downloaded from http://www.thc.org/download.php?t=r&f=login_hacker-1.1.tar.gz . In fact, it is a collection of different minicom scripts that are called and controlled from the main bash scripts, so in order to run it, minicom and bash must be installedstandard with every Linux distribution. In fact, the tool comes in two parts: the login_hacker part is responsible for checking the presence of the login prompt, while ppp_check is used to verify the presence of passwordless Point-to-Point Protocol (PPP) dial-ins on the other end.
Let's have a look at which options are available:
arh0ntus login_hacker-1.1 # ./login_hacker Modem Login Hacker v1.1 (c) 2003 by van Hauser / THC <email@example.com> Syntax: ./login_hacker PHONENUMBER type1 COLONFILE ./login_hacker PHONENUMBER type2 LOGINFILE PASSWORDFILE ./login_hacker PHONENUMBER type3 PASSWORDFILE ./login_hacker PHONENUMBER your_own_script INPUTFILE [INPUTFILE] Options: PHONENUMBER number to call and try to break in LOGINFILE input file with logins to try PASSWORDFILE input file with passwords to try COLONFILE input file with LOGIN:PASSWORD entries Types: type1+type2 should work against any login/password type modem prompts type3 should work against any password type modem prompts This script is really flexible, it works against Unix, Cisco, Shiva, ROLM PABX, Modem dialin password protection, and many, many more. Take a look in the README. Use allowed only for legal purposes! You can always find the newest version at http://www.thc.org
What catches your eye straightaway is the different modem prompt types. Type1 and type2 are used against exactly the same modem promptsthe only difference being that with the former you have to use a colon -separated login and password list while with the latter they are supplied in two different files, so that for every login all passwords from the list will be tried. The type1 script works against the modem prompts where authentication into the system is granted upon successful presentation of the correct login and password pair and supports the following modem prompts:
Login: asdf Enter login name: asdf Login: bin Password: Enter login name: qwert Welcome to system abc. Login incorrect. Enter login name: admin Last login: never Login: password: $ Username: asdf @login: root Password: password: % Authentication failed password: Username: password:
The dual authentication logins are found on the Cisco routers where aaa new-model authentication is enabled. On the contrary, the type3 scripts are used against standard password-only authentication and are able to recognize the following prompts:
Password: Enter password: Password: Enter password: Password: Enter password: % Bad passwords PASSWORD> #### Password please: ***** PASSWORD> ### Password please: ***** PASSWORD> ####### Password please: ***** Invalid passwords, bye!
Among the two authentication schemes, the tool covers the whole range of IOS routers, AccessPoints, CatOS switches, and PixOS firewalls. You can easily expand the abilities of the recognized prompts by modifying the typeN.scr script file and adding more signatures.
The only other things you need to specify are the phone number of the host you are attacking and the login/password files with your favorite pairs. Once you specify this information, the minicom window will appear and the bruteforcing process starts. The progress is shown in real-time in the minicom window and saved to the logfile in the directory from which the tool was run.
The second part of the login hacker suite is used to check for the passwordless dialins that use PPP. The only thing you need to supply to the script is the phone number that you want to check, and in case your default modem is not /dev/modem , you would have to fire up VIM and change the path to the serial device you want to use (for example, /dev/ttyS0 means the device is connected to the first serial port on your computer). Once you are done, THC-Dialup Login Hacker will dial the number and initiate the connection to a host. Upon the successful negotiation, you will see the PPP dial-up procedure, and if the PPP dial-in requires authentication, the following output would appear:
Serial connection established. using channel 2 Using interface ppp0 Connect: ppp0 <--> /dev/ttyS0 rcvd [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0xa0000> <auth pap> <magic 0xa28e4641> <pcomp> <accomp> <mrru 1506>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xada708b9> <pcomp> <accomp>] No auth is possible
You can appeal to both common sense and the previous editions of Hacking Exposed: Network Security Secrets & Solutions for more general recommendations on how to protect yourself from those phreaky wardialers. We already covered possible security measures against user credentials guessing when talking about Telnet and other services' bruteforcing.
Specifically with Cisco wardialing, we can offer two useful tips.
Use dial-back authentication when the remote party hangs up the incoming connection and dials out a predetermined telephone number. Unless the device is used to allow remote connections into the network by a large crowd of road- warrior users, this solution can be considered feasible when both communicating parties' locations are known. Here's an example of a dial-back router configuration:
username <username> callback-dialstring <number> password <password> username <username> callback-dialstring "" password <password> ! ! chat-script <script name> ABORT ERROR ABORT BUSY """ATZ" OK "ATDT \T" TIMEOUT 30 CONNECT \c ! interface Loopback0 ip address <IP> <netmask> no ip directed-broadcast ! interface Serial1/1 no shutdown physical-layer async ip unnumbered Loopback0 no ip directed-broadcast encapsulation ppp dialer in-band dialer hold-queue 2 timeout 30 async mode interactive peer default ip address pool <pool name> no cdp enable ppp callback accept ppp authentication chap ! ip local pool <pool name> <IP addresses> ! line <line number> autoselect during-login autoselect ppp script callback <script name> login local modem InOut modem autoconfigure type usr_sportster transport input all callback forced-wait 30 stopbits 1 speed 115200 flowcontrol hardware
Two factor authentication mechanisms, such as hardware tokens or smartcards, can be considered practical, especially if you are managing a large pool of remotely connecting users. This can be done using both secureID server and TACACS+/RADIUS. Such a mechanism relies on users possessing two authentication credentialssomething the user has (a token) and something the user knows (a password)and is viewed as difficult to bypass.