Admin account locked out

[PerN]

Hi,

for some strange reason can I no longer log on to my B3's admin web's using the admin account, it insists that the credentials are wong (even though I haven't changed them and "know" they are correct).

Is there a way to reset the admin password? I can ssh to the B3 and su to root.

[Gordon]

If you are root you can simply issue `passwd admin` and it will ask you to supply a new password (without asking for the old one). My guess however would be that the bubba-admin service has failed and the pages are now being served by the web server's user that is lacking the correct privileges. Running the passwd command can't really hurt, but should it not give the expected result you could try restart bubba-admin service, possibly restart apache as well to be sure, or simply reboot all together.

[PerN]

Thanks for your reply - found the problem.

As I read your reply I embarrassingly recalled having fiddeled about in the filesystem some while ago, doing clever stuff such as renaming the /usr/bin/perl to something else (due to it eating a lot of CPU). Renaming it back solved the issue.

Thanks and sorry for wasting time & bandwidth.

[Gordon]

Uhm... Are you still running the original Debian based system? If you see a lot of CPU activity on perl you may want to verify whether these processes are running as user `www`. Also check the crontab for user www, this should be empty but I suspect it won't be.

[PerN]

Yes, it's running the old squeeze dist.
Hmmm should probably uggrade I guess.
Been a bit reluctant to do it as I don't want to screw the whole thing up.

crontab -u www -e
gives
"crontab: user 'www' unknown"

crontab -u www-data -e is empty

[Gordon]

Ah... yes. Haven't run Debian for a while www-data sounds familiar. Crontab being empty is a positive but does not guarantee that a worm can't restart itself when being killed. The well known entrance on your OS version is php.cgi by the way and this is not needed to run your system; you should locate the cgi-bin directory (it will have a file named `upload.cgi` in it) and delete everything with php in the name. If you run something like wordpress, reconfigure your apache confs to only expose these pages on a named vhost; worms usually access your IP address directly and if apache only shows bogus content for the default host the worm can't do its thing.

[PerN]

Right. Thanks for the advice.

I do depend on php quite a lot but primarily from the LAN side and have denied most non 192.168 access in the apache config.

[Gordon]

I guess this requires some additional explaining.

There are four possible methods for using php:

1. command line execution - this is not web accessible
2. as an Apache module - all scripts will be executed as the www/apache user
3. as a dedicated service - this is commonly referred to as FastCGI or FPM method, all scripts will be executed using the service's account
4. as a CGI - allows scripts to run using the folder owner's credentials if Apache is configured with userdir module

On the B3, Apache is configured to use method #2 for every accessible php file, except for the admin pages that are routed through the bubba-adminphp service which is method #3. The cgi that was installed as part of the Debian php packages just sits there doing nothing, waiting for a hacker to find it and test for known vulnerabilities. A number of B3 users were thus infected with a worm that used their machine to send spam and run password guessing scripts.