Hacking Exposed 5th Edition

BRUTE-FORCE SCRIPTINGTHE HOMEGROWN WAY

Once the results from the output from any of the war-dialers are available, the next step is to categorize the results into what we call domains . As we mentioned before, experience with a large variety of dial-up servers and operating systems is irreplaceable. How you choose which systems to further penetrate depends on a series of factors, such as how much time you are willing to spend , how much effort and computing bandwidth is at your disposal, and how good your guessing and scripting skills are.

Dialing back the discovered listening modems with simple communications software is the first critical step to putting the results into domains for testing purposes. When dialing a connection back, it is important that you try to understand the characteristics of the connection. This will make sense when we discuss grouping the found connections into domains for testing. Important factors characterize a modem connection and thus will help your scripting efforts. Here is a general list of factors to identify:

• Whether the connection has a timeout or attempt-out threshold.

• Whether exceeding the thresholds renders the connection useless (this occasionally happens).

• Whether the connection is only allowed at certain times.

• Whether you can correctly assume the level of authentication (that is, user ID only or user ID and password only).

• Whether the connection has a unique identification method that appears to be a challenge response, such as SecurID.

• Whether you can determine the maximum number of characters for responses to user ID or password fields.

• Whether you can determine anything about the alphanumeric or special character makeup of the user ID and password fields.

• Whether any additional information could be gathered from typing other types of break characters at the keyboard, such as CTRL-C, CTRL -Z, ?, and so on.

• Whether the system banners are present or have changed since the first discovery attempts and what type of information is presented in the system banners. This can be useful for guessing attempts or social-engineering efforts.

Once you have this information, you can generally put the connections into what we will loosely call war-dialing penetration domains . For the purposes of illustration, you have four domains to consider when attempting further penetration of the discovered systems beyond simple guessing techniques at the keyboard (going for Low Hanging Fruit). Hence, the area that should be eliminated first, which we will call Low Hanging Fruit (LHF), is the most fruitful in terms of your chances and will produce the most results. The other brute-force domains are primarily based on the number of authentication mechanisms and the number of attempts allowed to try to access those mechanisms. If you are using these brute-force techniques, be advised that the success rate is low compared to LHF, but nonetheless, we will explain how to perform the scripting should you want to proceed further. The domains can be shown as follows :

In general, the further you go down the list of domains, the longer it can take to penetrate a system. As you move down the domains, the scripting process becomes more sensitive due to the number of actions that need to be performed. Now let's delve deep into the heart of our domains.

Low Hanging Fruit

This dial-up domain tends to take the least time. With luck, it provides instantaneous gratification. It requires no scripting expertise, so essentially it is a guessing process. It would be impossible to list all the common user IDs and passwords used for all the dialin-capable systems, so we won't attempt it. Lists and references abound within this text and on the Internet. One such example on the Internet is maintained at http://phenoelit.darklab.org/cgi-bin/display.pl?SEARCH= and contains default user IDs and passwords for many popular systems. Once again, experience from seeing a multitude of results from war-dialing engagements and playing with the resultant pool of potential systems will help immensely. The ability to identify the signature or screen of a type of dial-up system helps provide the basis from which to start utilizing the default user IDs or passwords for that system. Whichever list you use or consult , the key here is to spend no more than the amount of time required to expend all the possibilities for default IDs and passwords. If you're unsuccessful , move on to the next domain.

Single Authentication, Unlimited Attempts

Our first brute-force domain theoretically takes the least amount of time to attempt to penetrate in terms of brute-force scripting, but it can be the most difficult to properly categorize. This is because what might appear to be a single-authentication mechanism, such as the following example (see Code Listing 6-1A), might actually be dual authentication once the correct user ID is known (see Code Listing 6-1B). An example of a true first domain is shown in Code Listing 6-2, where you see a single-authentication mechanism that allows unlimited guessing attempts.

Code Listing 6-1A: An example of what appears to the first domain, which could change if the correct user ID is input

XX-Jul-XX 09:51:08 91XXX5551234 C: CONNECT 9600/ARQ/V32/LAPM @ Userid: @ Userid: @ Userid: @ Userid: @ Userid: @ Userid: @ Userid:

Code Listing 6-1B: An example showing the change once the correct user ID is entered

XX-Jul-XX 09:55:08 91XXX5551234 C: CONNECT 9600/ARQ/V32/LAPM @ Userid: lanrover1 Password: xxxxxxxx

Now back to our true first domain example (see Code Listing 6-2). In this example, all that is required to get access to the target system is a password. Also of important note is the fact that this connection allows for unlimited attempts. Hence, scripting a bruteforce attempt with a dictionary of passwords is the next step.

Code Listing 6-2: An example of a true first domain

XX-Jul-XX 03:45:08 91XXX5551235 C: CONNECT 9600/ARQ/V32/LAPM Enter Password: Invalid Password. Enter Password: Invalid Password. Enter Password: Invalid Password. Enter Password: Invalid Password. Enter Password: Invalid Password.

(goes on unlimited)

For our true first domain example, we need to undertake the scripting process, which can be done with simple ASCII-based utilities. What lies ahead is not complex programming but rather simple ingenuity in getting the desired script written, compiled, and executed so that it will repeatedly make the attempts for as long as our dictionary is large. As mentioned earlier, one of the most widely used tools for scripting modem communications is Procomm Plus and the ASPECT scripting language. Procomm Plus has been around for many years and has survived the tests of usability from the early DOS versions to the newest 32-bit versions. Also, the help and documentation in the ASPECT language is excellent .

Our first goal for the scripting exercise is to get a source code file with a script and then to turn that script into an object module. Once we have the object module, we need to test it for usability on, say, 10 to 20 passwords and then to script in a large dictionary. The first step is to create an ASPECT source code file. In old versions of Procomm Plus,.ASP files were the source and .ASX files were the object. Some old versions of Procomm Plus, such as the Test Drive PCPLUSTD (instructions for use and setup can be found at http://www.m4phr1k.com), allowed for direct .ASP source execution when executing a script. In new GUI versions of Procomm Plus, these same files are referred to as .WAS and .WSX files (source and object), respectively. Regardless of version, the goal is the same: to create a brute-force script using our examples shown earlier that will run over and over consistently using a large amount of dictionary words.

Creating the script is a relatively low-level exercise, and it can generally be done in any common editor. The difficult part is inputting the password or other dictionary variable into the script. Procomm Plus has the ability to handle any external files that we feed into the script as a password variable (say, from a dictionary list) as the script is running. You may want to experiment with password attempts that are hard-coded in a single script or possibly have external calls to password files. Reducing the amount of program variables during script execution can hopefully increase chances for success.

Because our approach and goal are essentially ASCII based and relatively low level in approach, QBASIC for DOS can be used to create the raw source script. The following code listing shows a simple QBASIC file used to script out the previous example. We will call this file 5551235.BAS (the .BAS extension is for QBASIC). This program can be used to create the script required to attempt to brute force our first domain example. What follows is an example of a QBASIC program that creates an ASPECT script for Procomm Plus 32 (.WAS) source file using the preceding first domain target example and a dictionary of passwords. The complete script also assumes that the user would first make a dialing entry in the Procomm Plus dialing directory called 5551235. The dialing entry typically has all the characteristics of the connection and allows the user to specify a log file. The ability to have a log file is an important feature (to be discussed shortly) when attempting a brute-force script with the type of approaches that will be discussed here.

'QBASIC ASP/WAS script creator for Procomm Plus 'Written by M4phr1k, www.m4phr1k.com, Stephan Barnes OPEN "5551235.was" FOR OUTPUT AS #2 OPEN "LIST.txt" FOR INPUT AS #1 PRINT #2, "proc main" PRINT #2, "dial DATA " + CHR$(34) + "5551235" + CHR$(34) DO UNTIL EOF(1) LINE INPUT #1, in$ in$ = LTRIM$(in$) + "^M" PRINT #2, "waitfor " + CHR$(34) + "Enter Password:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + in$ + CHR$(34) LOOP PRINT #2, "endproc"

Your dictionary files of common passwords could contain any number of common words, including the following:

apple apple1 apple2 applepie applepies applepies1 applepies2 applicate applicates application application1 applonia applonia1

(and so on)

Any size dictionary can be used, and creativity is a plus here. If you happen to know anything about the target organization, such as first or last names or local sports teams , those words could be added to the dictionary. The goal is to create a dictionary that will be robust enough to reveal a valid password on the target system.

The next step in our process is to take the resultant 5551235.WAS file and bring it into the ASPECT script compiler. Then we compile and execute the script:

333;TrackType=0;><$&~Frame 476 (9)>: ;><$&~Frame 476 (9)>: <$THAlign=L;SpAbove=333;TrackType=0;><$&~Frame 476 (9)>:

Because this script is attempting to repeatedly guess passwords, you must turn on logging before you execute this script. Logging will write the entire script session to a file so that you can come back later and view the file to determine whether you were successful. At this point you might be wondering why you would not want to script waiting for a successful event (getting the correct password). The answer is simple. Because you don't know what you will see after you theoretically reveal a password, it can't be scripted. You could script for login parameter anomalies and do your file processing in that fashion; write out any of these anomalies to a file for further review and for potential dial-back using LHF techniques. Should you know what the result looks like upon a successful password entry, you could then script a portion of the ASPECT code to do a WAITFOR for whatever the successful response would be and to set a flag or condition once that condition is met. The more system variables that are processed during script execution, the more chance random events will occur. The process of logging the session is simple in design yet time-consuming to review. Additional sensitivities can occur with the scripting process. Being off by a mere space between characters that you are expecting or have sent to the modem can throw the script off. Hence, it is best to test the script using 10 to 20 passwords a couple times to ensure that you have this repeated exercise crafted in such a way that it is going to hold up to a much larger and longer multitude of repeated attempts. One caveat: Every system is different, and scripting for a large dictionary brute-force attack requires working with the script to determine system parameters to help ensure it can run for as long as expected.

Single Authentication, Limited Attempts

The second domain takes more time and effort to attempt to penetrate. This is because an additional component to the script needs to be added. Using our examples shown thus far, let's review a second domain result in Code Listing 6-3. You will notice a slight difference here when compared to our true first domain example. In this example, after three attempts, the "ATH0" characters appear. This (ATH0) is the typical Hayes Modem character set for Hang Up. What this means is that this particular connection hangs up after three unsuccessful login attempts. It could be four, five, or six attempts or some other number of attempts, but the demonstrated purpose here is that you know how to dial back the connection after a connection attempt threshold has been reached. The solution to this dilemma is to add some code to handle the dial-back after the threshold of login attempts has been reached and the modem disconnects (see Code Listing 6-4). Essentially, this means guessing the password three times and then redialing the connection and restarting the process.

Code Listing 6-3: An example of a true second domain

XX-Jul-XX 03:45:08 91XXX5551235 C: CONNECT 9600/ARQ/V32/LAPM Enter Password: Invalid Password. Enter Password: Invalid Password. Enter Password: Invalid Password. ATH0

(Note the important ATH0, which is the typical Hayes character set for Hang Up.)

Code Listing 6-4: A sample QBASIC program (called 5551235.BAS)

'QBASIC ASP/WAS script creator for Procomm Plus 'Written by M4phr1k, www.m4phr1k.com, Stephan Barnes OPEN "5551235.was" FOR OUTPUT AS #2 OPEN "LIST.txt" FOR INPUT AS #1 PRINT #2, "proc main" DO UNTIL EOF(1) PRINT #2, "dial DATA " + CHR$(34) + "5551235" + CHR$(34) LINE INPUT #1, in$ in$ = LTRIM$(in$) + "^M" PRINT #2, "waitfor " + CHR$(34) + "Enter Password:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + in$ + CHR$(34) LINE INPUT #1, in$ in$ = LTRIM$(in$) + "^M" PRINT #2, "waitfor " + CHR$(34) + "Enter Password:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + in$ + CHR$(34) LINE INPUT #1, in$ in$ = LTRIM$(in$) + "^M" PRINT #2, "waitfor " + CHR$(34) + "Enter Password:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + in$ + CHR$(34) LOOP PRINT #2, "endproc"

Dual Authentication, Unlimited Attempts

The third domain builds off of the first domain, but now because two things are to be guessed (provided you don't already know a user ID), this process theoretically takes more time to execute than our first and second domain examples. We should also mention that the sensitivity of this third domain and the upcoming fourth domain process is more complex because, theoretically, more keystrokes are being transferred to the target system. The complexity arises because there is more of a chance for something to go wrong during script execution. The scripts used to build these types of brute-force approaches are similar in concept to the ones demonstrated earlier. Code Listing 6 - 5 shows a target, and Code Listing 6 - 6 shows a sample QBASIC program to make the ASPECT script.

Code Listing 6-5: A sample third domain target

XX-Jul-XX 09:55:08 91XXX5551234 C: CONNECT 9600/ARQ/V32/LAPM Username: guest Password: xxxxxxxx Username: guest Password:xxxxxxxx Username: guest Password: xxxxxxxx Username:guest Password: xxxxxxxx Username: guest Password:xxxxxxxx Username: guest Password: xxxxxxxx

(and so on)

Code Listing 6-6: A sample QBASIC program (called 5551235.BAS)

'QBASIC ASP/WAS script creator for Procomm Plus 'Written by M4phr1k, www.m4phr1k.com, Stephan Barnes OPEN "5551235.was" FOR OUTPUT AS #2 OPEN "LIST.txt" FOR INPUT AS#1 PRINT #2, "proc main" PRINT #2, "dial DATA " + CHR$(34) + "5551235" +CHR$(34) DO UNTIL EOF(1) LINE INPUT #1, in$ in$ = LTRIM$(in$) + "^M" PRINT #2, "waitfor "+ CHR$(34) + "Username:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) +"guest" + CHR$(34) PRINT #2, "waitfor " + CHR$(34) + "Password:" +CHR$(34) PRINT #2, "transmit " + CHR$(34) + in$ + CHR$(34) LOOP PRINT #2, "endproc"

Dual Authentication, Limited Attempts

The fourth domain builds off of our third domain. Now, because two things are to be guessed (provided you don't already know a user ID) and you have to dial back after a limited amount of attempts, this process theoretically takes the most time to execute of any of our previous domain examples. The scripts used to build these approaches are similar in concept to the ones demonstrated earlier. Code Listing 6 - 7 shows the results of attacking a target. Code Listing 6-8 is the sample QBASIC program to make the ASPECT script.

Code Listing 6-7: A sample fourth domain target

XX-Jul-XX 09:55:08 91XXX5551234 C: CONNECT 9600/ARQ/V32/LAPM Username: guest Password: xxxxxxxx Username: guest Password:xxxxxxxx Username: guest Password: xxxxxxxx +++

Code Listing 6-8: A sample QBASIC program (called 5551235.BAS)

'QBASIC ASP/WAS script creator for Procomm Plus 'Written by M4phr1k, www.m4phr1k.com, Stephan Barnes OPEN "5551235.was" FOR OUTPUT AS #2 OPEN "LIST.txt" FOR INPUT AS #1 PRINT #2, "proc main" DO UNTIL EOF(1) PRINT #2, "dial DATA " + CHR$(34) + "5551235" + CHR$(34) LINE INPUT #1, in$ in$ = LTRIM$(in$) + "^M" PRINT #2, "waitfor " + CHR$(34) + "Username:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + "guest" + CHR$(34) PRINT #2, "waitfor " + CHR$(34) + "Password:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + in$ + CHR$(34) LINE INPUT #1, in$ in$ = LTRIM$(in$) + "^M" PRINT #2, "waitfor " + CHR$(34) + "Username:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + "guest" + CHR$(34) PRINT #2, "waitfor " + CHR$(34) + "Password:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + in$ + CHR$(34) LINE INPUT #1, in$ in$ = LTRIM$(in$) + "^M" PRINT #2, "waitfor " + CHR$(34) + "Username:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + "guest" + CHR$(34) PRINT #2, "waitfor " + CHR$(34) + "Password:" + CHR$(34) PRINT #2, "transmit " + CHR$(34) + in$ + CHR$(34) LOOP PRINT #2, "endproc"

A Final Note

The examples shown thus far are actual working examples on systems we have observed . Output and a detailed discussion of these techniques are available at http://www.m4phr1k.com. Your mileage may vary in that sensitivities in the scripting process might need to be accounted for. The process is one of trial and error until you find the script that works right for your particular situation. Probably other languages could be used to perform the same functions, but for the purposes of simplicity and brevity, we've stuck to simple ASCII-based methods . Once again, we remind you that these particular processes that have been demonstrated require that you turn on a log file prior to execution, because there is no file processing attached to any of these script examples. Although it might be easy to get these scripts to work successfully, you might execute them and then come back after hours of execution with no log file and nothing to show for your work. We are trying to save you the headache .

Dial-Up Security Measures

We've made this as easy as possible. Here's a numbered checklist of issues to address when planning dial-up security for your organization. We've prioritized the list based on the difficulty of implementation, from easy to hard, so that you can hit the Low Hanging Fruit first and address the broader initiatives as you go. A savvy reader will note that this list reads a lot like a dial-up security policy:

1. Inventory existing dial-up lines. Gee, how would you inventory all those lines? Reread this chapter, noting the continual use of the term "war-dialing." Note unauthorized dial-up connectivity and snuff it out by whatever means possible.

2. Consolidate all dial-up connectivity to a central modem bank, position the central bank as an untrusted connection off the internal network (that is, a DMZ), and use intrusion detection and firewall technology to limit and monitor connections to trusted subnets.

3. Make analog lines harder to find. Don't put them in the same range as the corporate numbers, and don't give out the phone numbers on the InterNIC registration for your domain name . Password-protect phone company account information.

4. Verify that telecommunications equipment closets are physically secure. Many companies keep phone lines in unlocked closets in publicly exposed areas.

5. Regularly monitor existing log features within your dial-up software. Look for failed login attempts, late-night activity, and unusual usage patterns. Use Caller ID to store all incoming phone numbers.

6. Important and easy! For lines that are serving a business purpose, disable any banner information presented upon connect, replacing it with the most inscrutable login prompt you can think up. Also consider posting a warning that threatens prosecution for unauthorized use.

7. Require two-factor authentication systems for all remote access. Two-factor authentication requires users to produce two credentialssomething they have and something they knowto obtain access to the system. One example is the SecurID one-time password tokens available from RSA Security. Okay, we know this sounds easy but is often logistically or financially impractical . However, there is no other mechanism that will virtually eliminate most of the problems we've covered so far. See the "Summary" section at the end of this chapter for some other companies that offer such products. Failing this, a strict policy of password complexity must be enforced.

8. Require dial-back authentication. Dial-back means that the remote access system is configured to hang up on any caller and then immediately connect to a predetermined number (where the original caller is presumably located). For better security, use a separate modem pool for the dial-back capability and deny inbound access to those modems (using the modem hardware or the phone system itself). This is also one of those impractical solutions, especially for many modern companies with tons of mobile users.

9. Ensure that the corporate help desk is aware of the sensitivity of giving out or resetting remote access credentials. All the preceding security measures can be negated by one eager new hire in the corporate support division.

10. Centralize the provisioning of dial-up connectivityfrom faxes to voicemail systemswithin one security-aware department in your organization.

11. Establish firm policies for the workings of this central division, such that provisioning a POTS (plain old telephone service) line requires nothing less than an act of God or the CEO, whichever comes first. For those who can justify it, use the corporate phone switch to restrict inbound dialing on that line if all they need it for is outbound faxing or access to BBS systems, and so on. Get management buy-in on this policy, and make sure they have the teeth to enforce it. Otherwise, go back to step 1 and show them how many holes a simple wardialing exercise will dig up.

12. Go back to step 1. Elegantly worded policies are great, but the only way to be sure that someone isn't circumventing them is to war-dial on a regular basis. We recommend at least every six months for firms with 10,000 phone lines or more, but it wouldn't hurt to do it more often than that.

See? Kicking the dial-up habit is as easy as our 12-step plan. Of course, some of these steps are quite difficult to implement, but we think paranoia is justified. Our combined years of experience in assessing security at large corporations have taught us that most companies are well protected by their Internet firewalls; inevitably, however, they all have glaring, trivially navigated POTS dial-up holes that lead right to the heart of their IT infrastructure. We'll say it again: Going to war with your modems may be the single most important step toward improving the security of your network.