Brute forcing account logins.

[superfrink]

The technical staff at a client of ours resigned. They left a list of about 40 passwords and variations but we do not know which accounts or machines they belong to.

Ideally we want to minimize downtime to reboot and reset passwords. Especially since we don't know how things are configured in case say a switch config was not saved.

There are Linux servers, switches, and routers. I don't want to manually try every combination. It's tedious but I am more worried I will make a typo and miss an account.

I was thinking of writing a script using some modules like Net::Telnet::Cisco , Net::SSH::Perl , and Net::Telnet . Then it hit me there is probably already a program like this. Any suggestions?

Update: Thanks to everyone who posted a useful reply. Someone recommended http://freeworld.thc.org/thc-hydra/ . It can read files of usernames and passwords so we can avoid writing code. It still looks like we will be rebooting some machines to reset passwords. mr_mischief, good idea to drop in a machine acting as a transparent bridge running a packet dumper on interfaces as needed. To address the suggestions to work with the previous admin, sometimes people are not willing to work together.

[johngg]

Not a Perl answer and probably not feasible but, if you could contact the resignee, see if they would accept some free beer for an hour or two of their time to annotate the list. It might be a long shot but it could save you a lot of time and effort if it came off.

Just a thought.

Cheers,

JohnGG

[starbolin]

Wow, that's funny! Though I'm sure not for your client. Has anyone tried calling the previous employees? Perhaps one of them could be persuaded to come in and unlock the routers in exchange for beer money.

Do the routers respond to multiple accounts? Perhaps the solution set is not 40 x 40 but a single password may unlock multiple routers?

Your code idea may be a case of premature optimization. Assuming 40 routers times 40 passwords; four seconds to type each one in and a four second backoff; typing each in would consume less that four hours. Could you write and debug your code in that time? Plus writing your code would be a non-parallel task whereas cracking the routers could be partitioned out to multiple 'work units'.

As for the Linux boxes I know there are craker programs out there. I have a disk with a Live Linux distro on it that cracks a Windoz box in about 20 seconds from power on to thank-you-very-much. I believe it uses Ophcrack. Linux may be only slightly tougher to crack . John-the-Ripper is another password cracker.

[jhourcle]

Your code idea may be a case of premature optimization. Assuming 40 routers times 40 passwords; four seconds to type each one in and a four second backoff; typing each in would consume less that four hours.

You forget that he also said they don't know which accounts -- if there were multiple staff members (which I assume there were, based on the comments), you've just increased the complexity of the problem.

Personally, I'd look at using Expect (it's been a few years since I've done similar work ... there's now an Expect::Simple which might be easier to learn)

[BrowserUk]

Did you look under the keyboards? ;)

[mr_mischief]

One more thing you need to consider, unfortunately, is how trustworthy the former staff members are. If untrusted parties have access to the machines and you don't, this is a far more urgent issue.

If they are trustworthy the first attempt should be contacting them, as others have said. Paying one of them for half a day is better than being locked out of the equipment.

Expect, Net::Telnet, Net::SSH2, and more might be good ways to try the passwords. Perl is a good tool if this is the route you need to take, but this is a path you'd really rather not resort to using.

If all else fails, you should be able to figure out enough configuration information with a protocol analyzer and port scanners to recreate the router, firewall, and switch configs on redundant equipment. Then, you just swap in the newly configured gear and reset the configs on the originals at your leisure. The actual servers are a bit trickier, but they are easier to get into with, for example, a live CD.

One thing this should teach your client (and teach you to teach your clients) is that backups of data are not enough, and that backups of configs are necessary too.

[Fletch]

If there were in all likelihood it'd be found in the back of an old 2600 issue and the comments would be liberally sprinkled with '1337 sP34k. From the problem description it sounds like this would be in the class of trivial cracking tools that if you needed it you'd either already have written it already (if one were a white hat with the requisite minimal programming knowledge) or would have trolled a less respectable forum where such things would be circulated (were one a script kiddie).

[dwm042]

I can't speak for the switches or routers, but you have a list you can't trust for passwords on servers whose status you don't know. I'd be thinking about live disks and commenting out the root password in /etc/shadow.

[plobsing]

If he had access to the shadow file, he could just hash the passwords and create a lookup table to run on the shadow files.