In HE2 I discuss 5 domains but indicate that the first domain LHF, really is it's own domain and should not be considered a brute force domain in the sense that we are going to brute force script up an attack. LHF is pure simple guessing at defaults and poking around at the keyboard. Usually it's the thing that gets you in the most and the techniques describes throughout the rest of the domains factor in things such as that you have the time or necessity to try to hack away at the connections that fall into the various domains. It's brute force guessing gang and just automating the scripts at this point. Since tools like L0phtCrack and John and such don't exist for dial-up (the commercial dialers think they have the goods but they are still far off) you have to roll your own - or basically home brew it. Hence the title of the add on materials
Brute Force Scripting - The Home Grown Way
So, our first serious domain takes the theoretical least amount of time to attempt to penetrate (outside of LHF) but can be the most difficult to properly categorize. This is because what might appear to look like a single authentication mechanism such as the example (FIG 1) below might actually be dual-authentication once the correct userid is known (FIG 2). An example of a true first domain is shown in (FIG 3). Here we see a single authentication mechanism that allows unlimited guessing attempts.
In this example below 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 brute force attempt with a dictionary of passwords will be the process to undertake moving forward.
(goes on unlimited)
For our 1st domain example we now need to undertake the scripting process, which can be undertaken 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 your dictionary is large. As mentioned earlier, one of the most widely used scripting tools for scripting modem communications is Procomm Plus and their 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 turn that script into an object module. Once we have the object module, we need to test it for usability on say 10-20 passwords, and then script in a large dictionary. Hence the first step in our goal is to create an ASPECT source code file. In old versions of Procomm Plus these were referred to as .ASP files as the source and .ASX as the object. In new versions of Procomm Plus these are referred to as .WAS and .WSX files (source and object) respectively. Regardless of version the goal is the same: to create a script using our dialogue shown above that will be durable and last for a large dictionary.
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 external files that we will feed into the script as a password variable (say from a dictionary list) as the script is running, however our experience indicates that having the password attempt hard-coded in a single script will reduce the amount of program variables during script execution and hopefully increase chances for success.
Since our approach and goal is 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 previous[SDB1] example. We will call this file 5551235.BAS (.BAS extension for QBASIC). This program can be used to create the script required to attempt to brute force our 1st 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 1st domain target example above and a dictionary of passwords. The complete script also assumes that the user would pre-make a dialing entry in the Procomm Plus dialing directory called 5551235. The dialing entry typically has all of the characteristics of the connection and allows the user to specify a log file. The ability to have a log file is an important note to be discussed shortly when attempting a brute force script with the type of approaches that will be discussed here.
Your dictionary files of common passwords could contain any number of common words including:
Any size dictionary can be used and creativity is a plus here. If you knew anything about the target organization such as first or last names or local sports teams, those words could be added to a 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 resulting 5551235.WAS file and bring it into the ASPECT script compiler, compile and then execute the script.
IMPORTANT MUST DO NOTE!!!!: Since this script is attempting to repeatedly guess passwords, you MUST turn on logging before you execute the script. In all of my examples in these pages and throughout the Hacking Exposed War Dial sections you have to turn on logging. Logging will write the entire script that is on the screen to a file so that you can come back later and view the file to determine if 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 or getting the correct connection) and the answer is simple. Since youdon’t know what you will see next after you theoretically reveal a password or correct guess, it is difficult to be scripted. There is a possibility here should you want to script further. Should you know what the result looks like upon a successful password entry or guess, you could then script a portion of the ASPECT code to do a WAITFOR whatever the successful response would be and set a flag or condition once that condition is met. Once again, more chance for random events to occur. I like the logging process and albeit tedious to review, it is simple in design. Also, we are assuming that we don’t have any pre-information about the connection. This might be different if you were a security consultant or auditor working in conjunction with people who know the characteristics of their dial-in connections.