Case Study: War Dialing

In one engagement, we were asked to war dial a client's entire phone bank. The client wanted to identify any insecure dial-in access among its dial-in modem banks, routers, and potential rogue modems on employee desktops. Since there is less chance users may disconnect modems during work hours or when they leave for the day, we performed the testing during both working and nonworking hours. The tests were scheduled for between 2:30 p.m. and 5:00 a.m. each day for several days.

Our approach was to run the war dialer and then analyze the carrier log for potential numbers to examine more closely. We wanted to run default password pairs against some and try a brute force method against others. To brute force the authentication challenge, we relied on the THC Login Hacker. The “surgical strike” approach was performed manually using hyper terminal.

Among the targets we identified were dial-up modems that issued a user name/password challenge, a few routers and servers that had open modem lines (which we learned were for vendors to dial in and service the machines), and even a rogue modem or two.

For the dial-in modem bank, we did not have even a list of employees and were unaware of any account lockout that may be in place. Therefore, we made limited access attempts and stuck to trying very generic accounts, such as “new user/<blank password>,” “admin/admin,” “admin/password,” and so on.

We were not successful gaining access this way. We had far greater success with the lines directly to routers and servers that were generally reserved for vendors. Vendors often have dial-up connections to their products to perform remote management and/or to upgrade software in accordance with the service agreement. Ideally, the lines should be active when they are specifically requested for a certain purpose (for example, to apply the latest Oracle patch) and removed as soon as they have finished their work. However, we do not live in an ideal world. These lines turned out to be fairly straightforward to compromise. For one thing, the banner identified the hardware and software running on the host. With this information, you can look up all default accounts for that hardware and software. Not surprisingly, the defaults work on such accounts all too often. Since multiple engineers from the vendor may be tasked to do the upgrade or maintenance, system defaults are often left in place for the sake of convenience. Further, there is an expectation that the modem line will not necessarily be available 24/7, so it doesn't seem so bad to leave the defaults in place.

Once we were into the company's Internet facing router, there was much that we could do. We attempted to crack the enable password (Cisco specific) and add our machine to the routing table so that traffic from our host would be “internal” to the subnet and therefore trusted. Once this is done, your machine is, for all intents and purposes, internal, and you can begin footprinting to gather information and proceed.

At this point, we attempted to gain access to the rogue modems attached to user desktops. (To be fair, we had no idea whether the modems were “rogue” or whether the employee had permission to have both a modem and a remote control tool on their computers. Perhaps they were telecommuting.)

The remote control tool, pcAnywhere, was found running on several of these hosts. PcAnywhere can be configured to simply grant access to incoming connections or to request user names and passwords. On several occasions, we did find pcAnywhere would simply allow access over dial-up connections. There were cases when user names and passwords were requested. Since we did not have user names and since we had already gained control of other hosts through rogue modems, we didn't proceed with a brute force attempt against both the user name and password. However, since pcAnywhere and telecommuting in general is designed to be convenient, the passwords are generally easy to crack.

At this point, we had user access to employee desktops. From there, we could read files, perform footprinting, and begin to target other hosts on the network.

Lessons Learned

Dial-in access to systems, be they routers, servers, or user desktops, represent a potential channel of unauthorized access. Telephone access must be closely monitored to ensure that dial-in lines for vendors are not left active and that employees do not have modems on their desktops. As a countermeasure, a company can use all-digital phone lines in employee workspaces. This reduces the dangers of the analog modem.

For those employees who must dial in to telecommute, deploy a two-factor authentication scheme, such as a SecurID card, to protect the access from unauthorized hackers.