Hacking Exposed 5th Edition
| | ||
| | ||
| | ||
War-dialing essentially boils down to a choice of tools. We will discuss the specific merits of ToneLoc, THC-Scan, and PhoneSweep , in sequence, but some preliminary considerations follow.
Hardware
The choice of war-dialing hardware is no less important than software. The two freeware tools we will discuss run in DOS and have an undeserved reputation for being hard to configure. All you really need is DOS and a modem. However, any PC-based war-dialing program will require knowledge of how to juggle PC COM ports for more complex configurations, and some may not work at allfor example, using a PCMCIA combo card in a laptop may be troublesome . Don't try to get too fancy with the configuration. A basic PC with two standard COM ports and a serial card to add two more will do the trick. On the other side of the spectrum, if you truly want all the speed you can get when war-dialing and you don't care to install multiple separate modems, you may choose to install a multiport card, sometimes referred to as a "digiboard" card, which can allow for four or eight modems on one system. http://Digi.com (http://www.digi.com) makes the AccelePort RAS Family of multimodem analog adapters that run on most of the popular operating systems.
Hardware is also the primary gating factor for speed and efficiency. War-dialing software should be configured to be overly cautious, waiting for a specified timeout before continuing with the next number so that it doesn't miss potential targets because of noisy lines or other factors. When set with standard timeouts of 45 to 60 seconds, war-dialers generally average about one call per minute per modem, so some simple math tells us that a 10,000-number range will take about seven days of 24-hours-a-day dialing with one modem. Obviously, every modem added to the effort dramatically improves the speed of the exercise. Four modems will dial an entire range twice as fast as two. Because war-dialing from the attacker's point of view is lot like gambling in Las Vegas, where the playground is open 24 hours, the more modems the better. For the legitimate penetration tester, many war-dialing rules of engagement we see seem to be limited to off-peak hours, such as 6 P .M . to 6 A .M ., and all hours of the weekends. Hence, if you are a legitimate penetration tester with a limited amount of time to perform a war-dial, consider closely the math of multiple modems. One more point of consideration for the legitimate penetration tester is that if you have to deal with international numbers and various blackout restrictions of when dialing is allowed, this will add a level of complexity to the dialing process also. More modems on different low-end computers might be a way to approach a large international or multi-time zone constrained war-dial. Thus, you are not setting yourself up for a single-point-of-failure event if you would if you were to use one computer with multiple modems.
Choice of modem hardware can also greatly affect efficiency. Higher-quality modems can detect voice responses, second dial tones, or even whether a remote number is ringing. Voice detection, for example, can allow some war-dialing software to immediately log a phone number as "voice," hang up, and continue dialing the next number, without waiting for a specified timeout (again, 45 to 60 seconds). Because a large proportion of the numbers in any range are likely to be voice lines, eliminating this waiting period drastically reduces the overall war-dialing time. If you're a free-tool user , you'll spend a little more time going back over the entries that were noted as busies and the entries that were noted as timeouts, so once again consider this additional time burden . The best rule of thumb is to check each of the tools' documentation for the most reliable modems to use (because they do change over time). At this point in time, PhoneSweep is basically the leading commercial penetration-testing product, and the modems they wish a user to configure their product with are well known via the product documentation.
Legal Issues
Besides the choice of war-dialing platform, prospective war-dialers should seriously consider the legal issues involved. In some localities, it is illegal to dial large quantities of numbers in sequence, and local phone companies will take a very dim view of this activity, if their equipment allows it at all. Of course, all the software we cover here can randomize the range of numbers dialed to escape notice, but that still doesn't provide a "get out of jail free card" if you get caught. It is therefore extremely important for anyone engaging in such activity for legitimate purposes (legit penetration testers) to obtain written legal permission that limits their liability (usually an engagement contract) from the target entities to carry out such testing. In these cases, explicit phone number ranges should be agreed to in the signed document so that any stragglers that don't actually belong to the target become the target entities' responsibility should problems arise with the war-dial.
The agreement should also specify the time of day that the target is willing to permit the war-dialing activity. As we've mentioned, dialing entire exchanges at a large company during business hours is certain to raise some hackles and affect productivity, so plan for late night and predawn hours.
Be aware that war-dialing target phone numbers with Caller ID enabled is tantamount to leaving a business card at every dialed number. Multiple hang-ups from the same source are likely to raise ire with some percentage of targets, so it's probably wise to make sure you've enabled Caller ID Block on your own phone line. (Of course, if you have permission, it's not critical.) Also realize that calls to 800 numbers can potentially reveal your phone number regardless of Caller ID status because the receiving party has to pay for the calls.
Peripheral Costs
Finally, don't forget long-distance charges that are easily racked up during intense wardialing of remote targets. Be prepared to defend this peripheral cost to management when outlining a war-dialing proposal for your organization.
Next, we'll talk in detail about configuring and using each tool so that administrators can get up and running quickly with their own war-dialing efforts. Recognize, however, that what follows only scratches the surface of some of the advanced capabilities of the software we discuss. Caveat emptor and reading the manual are hereby proclaimed!
Software
Because most war-dialing is done in the wee hours to avoid conflicting with peak business activities, the ability to flexibly schedule continual scans during nonpeak hours can be invaluable if time is a consideration. Freeware tools such as ToneLoc and THC-Scan take snapshots of results in progress and auto-save them to data files at regular intervals, allowing for easy restart later. They also offer rudimentary capabilities for specifying scan start and end times in a single 24- hour period. But for day-to-day scheduling, users must rely on operating system-derived scheduling tools and batch scripts. PhoneSweep, on the other hand, has designed automated scheduling interfaces to deal with off-peak and weekend dialing considerations.
ToneLoc and THC-Scan are great freeware war-dialing applications for the more experienced user. Both of these DOS-based applications can be run simultaneously , and they can be programmed to use different modems within the same machine. Conducting war-dialing using multiple modems on the same machine (or on a set of machines) is a great way to get a large range of numbers done in a short amount of time. Although commercial war-dialers allow multiple modems for dialing, they tend to be much slower and take comparatively longer because they are processing information in real time for later analysis. Further, because ToneLoc and THC-Scan operate within a DOS environment, they are a bit archaic when it comes to the user interface and lack intuitiveness compared with their commercial counterpart . Therefore, knowledge of simple DOS commands is a must for getting the most out of the freeware application features and achieving accurate results when using tools such as ToneLoc and THC-Scan. Finally, to effectively use these DOS-based applications, additional knowledge of system and hardware banners is required to help positively identify carriers . This would be analogous to having a fingerprint database memorized in your head. Consequently, if dealing with a command-line interface and knowledge of a few common system banners are not issues, these applications get the job done right, for free.
On the other hand, if you are not into the DOS interface environment, commercial war-dialers may be the best choice. Commercial war-dialers such as PhoneSweep do a great job in making it easy to get around via a GUI. The intuitive GUI makes it easy to add phone ranges, set up scan-time intervals, or generate executive reports . However, PhoneSweep relies on back-end databases for carrier identification, and results are not always accurate. No matter what the PhoneSweep product proclaims as the carrier identification, further carrier investigation is usually required. As of this fifth edition, PhoneSweep's 5.0 version claims to be able to identify over 470 systems. Also, it is pretty well known in the war-dialing circles that the " penetrate " mode (a mode where an identified modem can be subjected to a litany of password guesses) has experienced problems. It is hard to blame PhoneSweep, because scripting up an attack on the fly when so many variables may be encountered is difficult. Hence, if you have to rely heavily on the results of the penetration mode, we suggest you always test out any "penetrated" modems with a secondary source. This is as simple as dialing up the purported penetrated modem with simple communications software such as ProComm Plus and seeing whether the test result can be verified .
Finally, if you have a large range of numbers to dial and are not familiar with carrier banners, it may be wise to invest in a commercial product such as PhoneSweep. Additionally, because the old-school dialers such as ToneLoc and THC-Scan are available for free on the Internet, you may want to consider getting familiar with these tools as well. Of course, depending on your pocket depth, you may be able to run them together and see what fits best with you and your environment.
ToneLoc
| Popularity: | 9 |
| Simplicity: | 8 |
| Impact: | 8 |
| Risk Rating: | 8 |
One of the first and most popular war-dialing tools released into the wild was ToneLoc, by Minor Threat and Mucho Maas. (ToneLoc is short for "Tone Locator.") The original ToneLoc site is no more, but versions can still be found on many underground Internet war-dialing and "phone phreaking" sites. Like most dialing software, ToneLoc runs in DOS (or in a DOS window on Win 9 x, NT, or Windows 2000, or under a DOS emulator on UNIX), and it has proved an effective tool for hackers and security consultants alike for many years . Unfortunately, the originators of ToneLoc never kept it updated, and no one from the security community has stepped in to take over development of the tool, but what a tool it is. ToneLoc is etched in time, yet it is timeless for its efficiency, simplicity, and lightweight CPU usage. The executable is only 46K!
ToneLoc is easy to set up and use for basic war-dialing, although it can get a bit complicated to use some of the more advanced features. First, a simple utility called TLCFG must be run at the command line to write basic parameters such as modem configuration (COM port, I/O port address, and IRQ) to a file called TL.CFG. ToneLoc then checks this file each time it launches for configuration parameters. More details and screen shots on TLCFG configuration quirks and tips can be found at Stephan Barnes's War Dialing site at (http://www.m4phr1k.com). TLCFG.EXE is shown in Figure 6-1.
Once this is done, you can run ToneLoc itself from the command line, specifying the number range to dial, the data file to write results to, and any options, using the following syntax (abbreviated to fit the page):
ToneLoc [DataFile] /M:[Mask] /R:[Range] /X:[ExMask] /D:[ExRange] /C:[Config] /#:[Number] /S:[StartTime] /E:[EndTime] /H:[Hours] /T /K [DataFile]- File to store data in, may also be a mask [Mask] - To use for phone numbers Format: 555-XXXX [Range] - Range of numbers to dial Format: 5000-6999 [ExMask] - Mask to exclude from scan Format: 1XXX [ExRange] - Range to exclude from scan Format: 2500-2699 [Config] - Configuration file to use [Number] - Number of dials to make Format: 250 [StartTime] - Time to begin scanning Format: 9:30p [EndTime] - Time to end scanning Format: 6:45a [Hours] - Max # of hours to scan Format: 5:30 Overrides [EndTime] /T = Tones, /K = Carriers (Override config file, '-' inverts)
You will see later that THC-Scan uses very similar arguments. In the following example, we've set ToneLoc to dial all the numbers in the range 555-0000 to 555-9999, and to log carriers it finds to a file called "test." Figure 6-2 shows ToneLoc at work.
toneloc test /M:555-XXXX /R:0000-9999
The following will dial the number 555-9999, pause for second dial tone, and then attempt each possible three-digit combination (xxx) on each subsequent dial until it gets the correct passcode for enabling dial-out from the target PBX:
toneloc test /m:555-9999Wxxx
The wait switch is used here for testing PBXs that allow users to dial in and enter a code to obtain a second dial tone for making outbound calls from the PBX. ToneLoc can guess up to four-digit codes. Does this convince anyone to eliminate remote dial-out capability on their PBXs or at least to use codes greater than four digits? Because we mostly use ToneLoc for footprinting (like an "nmap" program for modems), we would suggest you keep the fingerprinting exercise simple and not introduce too many variables. So in this example, if you find in the first pass of fingerprinting a PBX that requires a second dial tone for making outbound calls, test it alone and not as part of a group of tests so that you can control the result.
ToneLoc's TLCFG utility can be used to change default settings to further customize scans. ToneLoc automatically creates a log file called TONE.LOG to capture all the results from a scan. You can find and name this file when you run TLCFG in the FILES directory in the Log File entry. The TONE.LOG file (like all the files) is stored in the directory where ToneLoc is installed and has the time and date each number was dialed as well as the result of the scan. The TONE.LOG file is important because after the initial footprint the timeouts and busies can be extracted and redialed.
ToneLoc also creates a FOUND.LOG file that captures all the found carriers or "carrier detects" during a scan. This FOUND.LOG file is in the FILES directory in the TLCFG utility. The FOUND.LOG file includes carrier banners from the responding modems. Oftentimes, dial-up systems are not configured securely and reveal carrier operating system, application, or hardware-specific information. Banners provide enticement information that can be used later to tailor specific attacks against identified carriers. Using the TLCFG utility, you can specify the names of these log files or keep the default settings. ToneLoc has many other tweaks that are best left to a close read of the user manual (TLUSER.DOC), but it performs quite well as a simple war-dialer using the preceding basic configuration.
As a good practice, you should name the file for the Found File entry the same as the entry for the Carrier Log entry. This will combine the Found File and Carrier Log files into one, making them easier to review.
Batch Files for ToneLoc
By default, ToneLoc alone has the capability to scan a range of numbers. Alternatively, simple batch files can be created to import a list of target numbers or ranges that can be dialed using the ToneLoc command prompt in a single-number-dial fashion. Why would you consider doing this? The advantage of using a batch file type of process over the basic default ToneLoc operation is that with a batch file operation, you can ensure that the modem reinitializes after every dialed number. Why is this important? Consider conducting war-dialing against a range of 5,000 numbers during off-peak hours. If in the middle of the night the modem you are using that is running the ToneLoc program (in its original native mode) were to get hung on a particular number it dialed, the rest of the range might not be dialed, and many hours could be lost.
Using the same example of dialing a range of numbers, if a batch file type of program were used instead, and the modem you are using were to hang in the same place, the ToneLoc program would only wait for a predetermined amount of time before exiting because you only ran it once. Once ToneLoc exits, if your problematic modem is hung, the batch file would execute the next line in the file, which in essence is calling the next number. Because you are only running ToneLoc once every time and the next line in the batch file restarts ToneLoc, you will reinitialize the modem every time. This process almost guarantees a clean war-dial and no lost time and no hung modems on your end. Further, there is no additional processing time spent running the process in a batch file fashion. The split millisecond it takes to go to the next line in the batch file is not discernibly longer than the millisecond that ToneLoc would use if it were repeatedly dialing the next number in the range. So, if you deem this technique worth a try, we are trying to create something that looks like this (and so on, until the range is complete). Here is an example from the first ten lines of a batch file we called WAR1.BAT:
toneloc 0000warl.dat /M:*6718005550000 > nul toneloc 0001warl.dat /M:*6718005550001 > nul toneloc 0002warl.dat /M:*6718005550002 > nul toneloc 0003warl.dat /M:*6718005550003 > nul toneloc 0004warl.dat /M:*6718005550004 > nul toneloc 0005warl.dat /M:*6718005550005 > nul toneloc 0006warl.dat /M:*6718005550006 > nul toneloc 0007warl.dat /M:*6718005550007 > nul toneloc 0008warl.dat /M:*6718005550008 > nul toneloc 0009warl.dat /M:*6718005550009 > nul toneloc 0010warl.dat /M:*6718005550010 > nul
The simple batch file line can be explained as follows: run toneloc , create the .DAT file, use the native ToneLoc /M switch to represent the number mask (it will only be a single number anyway), *67 (block caller ID), phone number , > nul . ( > nul means don't send this command to the command line to view, just execute it.)
That's the simple technique, and it should make the war-dialing exercise practically error free. There is a TLCFG parameter to tweak if you use this batch file process. In the ScanOptions window in the TLCFG utility, you can change the Save .DAT files parameter to N, which means do not save any .DAT files. You don't need these individual .DAT files with the batch process, and they just take up space. The use of the .DAT file entry over and over in the single-number batch file execution example is because ToneLoc (the default program) requires it to run. Other considerations, such as randomization of the war-dialing batch file, can be important. By default the TLCFG utility sets scanning to random (found in the ModemOptions window in TLCFG). However, because you are only running one number at a time in the batch process described here, you have to randomize the lines in the batch file in some way. Most spreadsheet software has a randomize routine whereby you can bring in a list of numbers and have the routine randomly sort it. Randomization is important either because many companies now have smart PBXs or because the phone company you are using might have a filter that can see the trend of dialing out like this and focus suspicion on you. Randomization can also aid you in roundthe-clock war-dialing and can keep your target organization from getting suspicious about a lot of phone calls happening in sequence. The main purposes of randomization are to not raise suspicions and to not upset an area of people at work.
To build the preceding example (for 2000 numbers), we can use a simple QBASIC program that creates a batch file. Here is an example of it:
'QBASIC Batch file creator, wrapper Program for ToneLoc 'Written by M4phr1k, www.m4phr1k.com, Stephan Barnes OPEN "war1.bat" FOR OUTPUT AS #1 FOR a = 0 TO 2000 a$ = STR$(a) a$ = LTRIM$(a$) 'the next 9 lines deal with digits 1thru10 10thru100 100thru1000 'after 1000 truncating doesn't happen IF LEN(a$) = 1 THEN a$ = "000" + a$ END IF IF LEN(a$) = 2 THEN a$ = "00" + a$ END IF IF LEN(a$) = 3 THEN a$ = "0" + a$ END IF aa$ = a$ + "warl" PRINT aa PRINT #1, "toneloc " + aa$ + ".dat" + " /M:*671800555" + a$ + " > nul" NEXT a CLOSE #1
Using this example, the batch file is created and ready to be launched in the directory that has the ToneLoc executable. You could use any language you wanted to create the batch file. QBASIC is just simple to use.
THC-Scan
| Popularity: | 9 |
| Simplicity: | 8 |
| Impact: | 8 |
| Risk Rating: | 8 |
Some of the void where ToneLoc left off was filled by THC-Scan, from van Hauser of the German hacking group The Hacker's Choice (http://www.thehackerschoice.com). Like ToneLoc, THC-Scan is configured and launched from DOS, a DOS shell within Win 9 x , from the console on Windows NT/2000, or under a UNIX DOS emulator. Be advised that THC-Scan can be quirky and not run under some DOS environments. The workaround is to try to use the start /SEPARATE switch (and then use either mod-det, ts-cfg, or thc-scan.exe). This switch may fail also, so the suggestion at this point, if you still want to use THC-Scan, is to get old true DOS or use DOSEMU for UNIX users.
A configuration file (.CFG) must first be generated for THC-Scan using a utility called TS-CFG, which offers more granular capabilities than ToneLoc's simple TLCFG tool. Once again, most configurations are straightforward, but knowing the ins and outs of PC COM ports will come in handy for nonstandard setups. Common configurations are listed in the following table:
| COM | IRQ | I/O Port |
|---|---|---|
| 1 | 4 | 3F8 |
| 2 | 3 | 2F8 |
| 3 | 4 | 3E8 |
| 4 | 3 | 2E8 |
The MOD-DET utility included with THC-Scan can be used to determine these parameters if they are not known, as shown here (just ignore any errors displayed by Windows if they occur):
MODEM DETECTOR v2.00 (c) 1996,98 by van Hauser/THC <vh@reptile.rug.ac.be> ------------------------------------------------------------------ Get the help screen with : MOD-DET.EXE ? Identifying Options... Extended Scanning : NO Use Fossil Driver : NO (Fossil Driver not present) Slow Modem Detect : YES Terminal Connect : NO Output Filename : <none> Autodetecting modems connected to COM 1 to COM 4 ... COM 1 None Found COM 2 Found! (Ready) [Irq: 3 BaseAdress: F8] COM 3 None Found COM 4 None Found 1 Modem(s) found.
Once the .CFG configuration file is created, war-dialing can begin. THC-Scan's command syntax is very similar to ToneLoc's, with several enhancements. (A list of the command-line options is too lengthy to reprint here, but they can be found in Part IV of the THC-SCAN.DOC manual that comes with the distribution.) THC-Scan even looks a lot like ToneLoc when running, as shown in Figure 6-3.
Scheduling war-dialing from day to day is a manual process that uses the /S and /E switches to specify a start and end time, respectively, and that leverages built-in OS tools such as the Windows AT Scheduler to restart scans at the appropriate time each day. We usually write the parameters for THC-Scan to a simple batch file that we call using the AT Scheduler. The key thing to remember about scheduling THC-SCAN.EXE is that it only searches its current directory for the appropriate .CFG file, unless specified with the /! option. Because AT originates commands in %systemroot%, THC-SCAN.EXE will not find the .CFG file unless absolutely specified, as shown next in batch file thc.bat:
@@@@echo off rem Make sure thc-scan.exe is in path rem absolute path to .cfg file must be specified with /! switch if run from rem AT scheduler rem if re-running a scan, first change to directory with appropriate .DAT rem file and delete /P: argument C:\thc-scan\bin\THC-SCAN.EXE test /M:555-xxxx /R:0000-9999 /!:C:\thc-scan\bin\THC-SCAN.CFG /P:test /F /S:20:00 /E:6:00
When this batch file is launched, THC-Scan will wait until 8 P.M. and then dial continuously until 6 A.M. To schedule this batch file to run each subsequent day, the following AT command will suffice:
at 7:58P /interactive /every:1 C:\thc-scan\bin\thc.bat
THC-Scan will locate the proper .DAT file and take up where it left off on the previous night until all numbers are identified. Make sure to delete any remaining jobs by using at /delete when THC-Scan finishes.
For those war-dialing with multiple modems or multiple clients on a network, van Hauser has provided a sample batch file called NETSCAN.BAT in the THC-MISC.ZIP archive that comes with the distribution. With minor modifications discussed in Part II of THC-SCAN.DOC, this batch script will automatically divide up a given phone number range and create separate .DAT files that can be used on each client or for each modem. To set up THC-Scan for multiple modems, follow these steps:
-
Create separate directories for each modem, each containing a copy of THCSCAN.EXE and a corresponding .CFG file appropriate for that modem.
-
Make the modifications to NETSCAN.BAT as specified in THC-SCAN.DOC. Make sure to specify how many modems you have with the "SET CLIENTS="statement in section [2] of NETSCAN.BAT.
-
With THC-SCAN.EXE in the current path, run netscan.bat [dial mask] [modem #].
-
Place each output .DAT file in the THC-Scan directory corresponding to the appropriate modem. For example, if you ran netscan 555-XXXX 2 when using two modems, take the resultant 2555XXXX.DAT file and place it in the directory that dials modem 2 (for example, \thc-scan\bin2).
When scanning for carriers, THC-Scan can send an answering modem certain strings specified in the .CFG file. This option can be set with the TS-CFG utility, under the Carrier Hack Mode setting. The stringscalled nudges can be set nearby under the Nudge setting. The default is
"^~^~^~^~^~^M^~^M?^M^~help^M^~^~^~guest^M^~guest^M^~ INFO ^M^MLO"
where ^~ is a pause and ^M is a carriage return. These common nudges and user ID/password guesses work fairly well, but you may want to get creative if you have an idea of the specific targets you are dialing.
Following the completion of a scan, the various logs should be examined. THC-Scan's strongest feature is its ability to capture raw terminal prompts to a text file for later perusal. However, its data management facilities require much manual input from the user. War-dialing can generate massive amounts of data to collate , including lists of numbers dialed, carriers found, types of systems identified, and so on. THC-Scan writes all this information to three types of files: a delimited .DAT file, an optional .DB file that can be imported into an ODBC-compliant database (this option must be specified with the /F switch), and several .LOG text files containing lists of numbers that were busy, carriers, and the carrier terminal prompt file. The delimited .DB file can be manipulated with your database management tool of choice, but it does not include responses from carriers identified. Reconciling these with the terminal prompt information in the CARRIERS.LOG file is a manual process. This is not such a big deal because manual analysis of the terminal prompts presented by answering systems is often necessary for further identification and penetration testing, but when you're scanning large banks of numbers, it can be quite tedious to manually generate a comprehensive report highlighting key results.
Data management is a bigger issue when you're using multiple modems. As you have seen, separate instances of THC-Scan must be configured and launched for each modem being used, and phone number ranges must be manually broken up between each modem. The DAT-MERGE.EXE utility that comes with THC-Scan can later merge the resultant.DAT files, but the carrier response log files must be pasted together manually.
PhoneSweep
| Popularity: | 6 |
| Simplicity: | 4 |
| Impact: | 5 |
| Risk Rating: | 5 |
If messing with ToneLoc or THC-Scan seems like a lot of work, then PhoneSweep may be for you. (PhoneSweep, now up to version 5.0, is sold by Sandstorm Enterprises, at http://www.sandstorm.net.) We've spent a lot of time thus far covering the use and setup of freeware war-dialing tools, but our discussion of PhoneSweep will be much shorterprimarily because there is very little to reveal that isn't readily evident within the interface, as shown in Figure 6-4.
The critical features that make PhoneSweep stand out are its simple graphical interface, automated scheduling, attempts at carrier penetration, simultaneous multiple-modem support, and elegant reporting. Number rangescalled profiles are dialed on any available modem, up to the maximum supported in the current version/configuration you purchase. PhoneSweep is easily configured to dial during business hours, outside hours, weekends, or all three, as shown in Figure 6-5. Business hours are user-definable on the Time tab. PhoneSweep will dial continuously during the period specified (usually outside hours and weekends), stopping during desired periods (business hours, for example) or for the "blackouts" defined, restarting as necessary during appropriate hours until the range is scanned and/or tested for penetrable modems, if configured.
PhoneSweep professes to identify over 470 different makes and models of remote access devices. (For a complete list, see http://www.sandstorm.net/products/phonesweep/sysids.) It does this by comparing text or binary strings received from the target system to a database of known responses. If the target's response has been customized in any way, PhoneSweep may not recognize it. Besides the standard carrier detection, PhoneSweep can be programmed to attempt to launch a dictionary attack against identified modems. In the application directory is a simple tab-delimited file of usernames and passwords that is fed to answering modems. If the system hangs up, PhoneSweep redials and continues through the list until it reaches the end. (Beware of account-lockout features on the target system if using this to test security on your remote access servers.) Although this feature alone is worth the price of admission for PhoneSweep, many penetration testers have reported some false positives while using this penetration mode, so we advise you to double-check your results with an independent process whereby you simply connect up to the device in question with simple modem communications software.
PhoneSweep's ability to export to a file the call results across all available modems is another useful feature. This eliminates manual hunting through text files or merging and importing data from multiple formats into spreadsheets and the like, as is common with freeware tools. Different options are available. Also, a host of options are available to create reports, so if custom reports are important, this is worth a look. Depending on how you format your report, it can contain introductory information, executive and technical summaries of activities and results, statistics in tabular format, raw terminal responses from identified modems, and an entire listing of the phone number "taxonomy." A portion of a sample PhoneSweep report is shown in Figure 6-6.
Of course, the biggest difference between PhoneSweep and freeware tools is cost. As of this edition, different versions of PhoneSweep are available, so check the PhoneSweep site for your purchase options (http://www.sandstorm.net). The licensing restrictions are enforced with a hardware dongle that attaches to the parallel portthe software will not install if the dongle is not present. Depending on the cost of hourly labor to set up, configure, and manage the output of freeware tools, PhoneSweep's cost can seem like a reasonable amount.
Carrier Exploitation Techniques
| Popularity: | 9 |
| Simplicity: | 5 |
| Impact: | 8 |
| Risk Rating: | 7 |
War-dialing itself can reveal easily penetrated modems, but more often than not, careful examination of dialing reports and manual follow-up are necessary to determine just how vulnerable a particular dial-up connection actually is. For example, the following excerpt (sanitized) from a FOUND.LOG file from ToneLoc shows some typical responses (edited for brevity):
7-NOV-2002 20:35:15 9,5551212 C: CONNECT 2400 HP995-400:_ Expected a HELLO command. (CIERR 6057) 7-NOV-2002 20:36:15 9,5551212 C: CONNECT 2400 @ Userid: Password? Login incorrect 7-NOV-2002 20:37:15 9,5551212 C: CONNECT 2400 Welcome to 3Com Total Control HiPer ARC (TM) Networks That Go The Distance (TM) login: Password: Login Incorrect 7-NOV-2002 20:38:15 9,5551212 C: CONNECT 2400 ._Please press <Enter>..._I PJack Smith _ JACK SMITH [CARRIER LOST AFTER 57 SECONDS]
We purposely selected these examples to illustrate a key point about combing result logs: Experience with a large variety of dial-up servers and operating systems is irreplaceable. For example, the first response appears to be from an HP system (HP995-400), but the ensuing string about a "HELLO" command is somewhat cryptic. Manually dialing into this system with common data terminal software set to emulate a VT-100 terminal using the ASCII protocol produces similarly inscrutable resultsunless the intruders are familiar with Hewlett-Packard midrange MPE-XL systems and know the login syntax is "HELLO USER.ACCT" followed by a password when prompted. Then they can try the following:
CONNECT 57600 HP995-400: HELLO FIELD.SUPPORT PASSWORD= TeleSup
"FIELD.SUPPORT" and "TeleSup" are a common default account name and password, respectively, that may produce a positive result. A little research and a deep background can go a long way toward revealing holes where others only see roadblocks .
Our second example is a little more simplistic. The "@Userid" syntax shown here is characteristic of a Shiva LAN Rover remote access server (we still find these occasionally in the wild, although Intel has discontinued the product). With that tidbit and some quick research, attackers can learn more about LAN Rovers. A good guess in this instance might be "supervisor" or "admin" with a NULL password. You'd be surprised how often this simple guesswork actually succeeds in nailing lazy administrators.
The third example further amplifies the fact that even simple knowledge of the vendor and model of the system answering the call can be devastating. An old known backdoor account is associated with 3Com Total Control HiPer ARC remote access devices"adm" with a NULL password. This system is essentially wide open if the fix for this problem has not been implemented.
We'll just cut right to the chase for our final example: This response is characteristic of Symantec's pcAnywhere remote control software. If the owner of system "JACK SMITH" is smart and has set a password of even marginal complexity, this probably isn't worth further effort, but it seems like even today two out of three pcAnywhere users never bother to set one. (Yes, this is based on real experience!)
We should also mention here that carriers aren't the only things of interest that can turn up from a war-dialing scan. Many PBX and voicemail systems are also key trophies sought by attackers. In particular, some PBXs can be configured to allow remote dial-out and will respond with a second dial tone when the correct code is entered. Improperly secured, these features can allow intruders to make long-distance calls anywhere in the world on someone else's dime. Don't overlook these results when collating your wardialing data to present to management.
Exhaustive coverage of the potential responses offered by remote dial-up systems would take up most of the rest of this book, but we hope that the preceding gives you a taste of the types of systems you may encounter when testing your organization's security. Keep an open mind, and consult others for advice, including vendors . Probably one of the most current sites to keep up with banners and carrier-exploitation techniques is Stephan Barnes's M4phr1k's Wall of Voodoo site (http://www.m4phr1k.com) dedicated to the war-dialing community (this link is available at the Hacking Exposed companion site). The site has been up through all five editions of this book and has kept constant vigilance on the state of war-dialing, along with PBX and voicemail hacking.
Assuming you've found a system that yields a user ID/password prompt, and it's not trivially guessed, what then? Audit them using dictionary and brute-force attacks, of course! As we've mentioned, PhoneSweep comes with built-in password-guessing capabilities (which you should double-check), but alternatives exist for the do-it-yourself types. THC's Login Hacker, which is essentially a DOS-like scripting language compiler, includes a few sample scripts. Simple and complex scripts written in Procomm Plus's ASPECT scripting language exist. These can try three guesses, redial after the target system hangs up, try three more, and so forth. Generally, such noisy trespassing is not advisable on dial-up systems, and once again, it's probably illegal to perform against systems that you don't own. However, should you wish to test the security of systems that you do own, the effort essentially becomes a test in brute-force hacking.