We have a strange issue at the place I work at. We have a vendor that is acting strange and refuses to support us further with our FreePBX system that they set up. Unfortunetly we are locked out of the root account and even the main admin account for the FreePBX portal. They have refused to give us the paswords and have dared us to break into the box. My question is what is the best course of action to regain control of the root account and admin on the server. I believe it is running CentOS 4.x on the box I’m still verifying it on this side. The freePBX is version 2.2.1. Any help would be appreciated and if I can provide any specific information I would certainly do my best.
Thank You
Rafal
UPDATE: Got our passwords! Woo Hoo! Turns out there was no imaginery Intellectual Property the vendor was playing hard ball. No damage on the box as far as i can tell. the passwords were set to something somewhat derragatory but no skin off my back. .history files are all cleared but logs go back a whiles… so all looks good so far now to find a new vendor. Anyone who knows a good FreePBX vendor in the Chicago area, feel free.
Simply editing the password file will not work. Besides, the utility for recovering a lost password is already there if you have physical access to the server.
If the box was properly secured there is not much. That is one of the strengths of linux. the only way in would be a brute force user/password attempt. and there are programs available to do it, google for it.
The best course of action would be to settle your differences, be it pay the bill, etc. If needed use a agreed upon third party who can handle the transaction so that funds are not handed over until the needed passwords provided have been verified.
If there is no battle over dollars (be it a personal disagreement over something) and you own the box outright and can legally prove it, small claims court.
If there was a easy way to hack Linux it would be all over the internet, which would also mean that people would not be using it.
You can edit out the password field in /etc/shadow from a rescue/live/boot CD/floppy, but you’re right: if you’re going to reboot anyway, and nobody put in a grub password, then you can just boot into single user mode and change the root password.
I’d also caution you to check through /etc/passwd and /etc/shadow for any extraneous users that this shady company may have added. Also check to make sure there are no uid 0 users besides root.
Edit: I wrote a small document on understanding the boot process over that the trixbox wiki. Within that document is an explanation on how to boot into single user mode.
This works most of the time, but as fskrotzki said, sometimes they may have single user mode protected by a password. Trixbox doesn’t, and CentOS doesn’t out of the box.
If it is, the rescue CD / edit /etc/shadow is an option, but they may have encrypted the filesystem, if that’s the case you’ve go no options.
Well… their “genius” techs probably just locked you out of grub, so the livecd, rescue cd, or putting the drive in another machine and accessing it (possibly using chroot to ensure paths are correct, etc) is 99% of the time effective in recovering/re-accessing a machine you were locked out of.
However, I wanted to throw my 2 cents into this discussion, as I am a RHCE, so I may point out a few thoughts about recovering a system like that that everyone may not otherwise have thought about.
Here’s the steps I would take, to hopefully recover/re-access the system. (Read entire possible steps before trying any of them)
Try to go into Grub and edit the boot line (the one with the kernel in the line) by appending the number “1” (or if in Lilo, then go to single user by typing “linux single” or “linux 1”)… Hope this works, the rest of the possibilities are more challening! If you get in, (you will automatically be “root”, just type “passwd” and enter a new password.
Use a Centos Install CD, and when it boots select “Rescue”, which should
(Note: If you do not have a CDrom in this system, open it up and add one !!! At this point, check if the BIOS is also password protected, if it is, it’s decision time… Tip: TIME FOR A NEW SERVER !)
You can also try a livecd, occasionally I find they may make it easier to gain access to files, but usually the #2 option above works.
If you have gained access at this point GOOD… if you don’t know which files to edit (password/possibly shadow, password-,shadow-, etc) STOP… you may make it worse!! If you know (or have a rescue/chroot environment, just do a “passwd” and change the password, it will know what files to change)
If the filesystem is encrypted (not extremely often do I see this however), it may just be a single partition ( like /etc ) so you may be able to backup /var/www at this point… if so, DO IT… also your mysql databases (/var/lib/mysql/) as mysql isn’t running, so it may be an easy way to backup the freepbx data. If you can access the machine at all… BACKUP SOME DATA… AT LEAST try to backup the following list of folders:
/var/lib/mysql/
/var/www/
/etc/*
/root/*
/var/lib/asterisk/backups/
/var/log (this can have invaluable information for a system restore on a new machine in many cases)
etc… With mysql and an asterisk backups file, a restore on a new system may not be so much work, and your system would come back almost exactly as it is now… with new passwords of course. Of the two that were filesystem encrypted that I have run across (well, two where the admin’s left the company on bad terms and dared us to get back in)… he encrypted the /etc folders, but nothing else, so I was able to get 99.99% of the system backed up, reloaded it, and copied the data back. VOILA. I just had to manually re-configure a few things like the network settings, firewall, and password… C’est La Vie!
If you still can’t access anything yet, now is a good time to do something smart. Get a new hard drive (identical drive if possible) and do a “dd if=/dev/sda of=/dev/sdb” (copy one drive to another) before you do any other “playing” or try any encrypted filesystem cracking, or brute force attacks, etc… at least, if you are going to attempt any of this!.. or, you can reload the machine, but keep this drive around in case you get a password from them later, you could go back and review what was on this one
If you still can’t access anything (and, as was mentioned before, if you don’t owe them $$) visit your Attorney’s office. This is like a car dealer selling you a car, dropping it off at your house, and taking the car keys away. I would also call the BBB and tell everyone I knew not to do biz with them. If you owe them money… pay them, get your passwords, and stop fighting with your phone system.
Still having a problem? YOU NEED A HIGH PRICED CONSULTANT (aka… legal hacker) to try to help you.
If #6 or #7 isn’t up your alley… reload the machine and rebuild your phone system. That’s your last hope, or run with what you have until it dies. But then again, if you can’t login, I bet you don’t have backups either, so start over, and do it right.
** Disclaimer - Read these !!! **
-All of the above assumes you have physical access to the machine.
-BACKUP BACKUP BACKUP… if you don’t have a backup… GET ONE…
-Once you have access to the machine as root, there are lots of other docs on how to re-secure your freepbx, and how to check your system.
-Be sure to check your passwd/shadow files for unknown usernames… review all of your crontabs for any lines that may just give them access later, or ensure your data isn’t being just sent offsite… check filewall (configure one if it’s not there already… PLEASE)… check in EVERY user’s home directory for a .ssh/ folder, and any authorized_keys2 files to make sure they are not SSH’ing using a ssh-key. Lock down your apache configs appropriately…
-Anytime I have a system with a situation like this, even if I re-gain access, I recommend reloading it for security reasons. This is your business life… without a phone system, you’re dead in the water. Do you really want to be wondering “what else might they have done that I didn’t think about?” No.
