New user's registration have been closed due to high spamming and low trafic on this forum. Please contact forum admins directly if you need an account. Thanks !

Admin account locked out

Got problems with your B2 or B3? Share and get helped!
Post Reply
PerN
Posts: 28
Joined: 20 May 2010, 15:07

Admin account locked out

Post by 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
Posts: 1461
Joined: 10 Aug 2011, 03:18

Re: Admin account locked out

Post by 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
Posts: 28
Joined: 20 May 2010, 15:07

Re: Admin account locked out

Post by 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
Posts: 1461
Joined: 10 Aug 2011, 03:18

Re: Admin account locked out

Post by 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
Posts: 28
Joined: 20 May 2010, 15:07

Re: Admin account locked out

Post by 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
Posts: 1461
Joined: 10 Aug 2011, 03:18

Re: Admin account locked out

Post by 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
Posts: 28
Joined: 20 May 2010, 15:07

Re: Admin account locked out

Post by 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
Posts: 1461
Joined: 10 Aug 2011, 03:18

Re: Admin account locked out

Post by 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.
Post Reply