Loading...
 
Features / Usability

Features / Usability


Admin Bypass flaw attack attempt

posts: 27

Seems I have an ongoing attempt to get around an old vulnerability with the admin account from earlier versions (or works for any account just admin is only one useful or easily found?) . See https://portswigger.net/daily-swig/tiki-wiki-authentication-bypass-flaw-gives-attackers-full-control-of-websites-intranets

Someone keeps trying to login in to the admin account unsuccessfully. Thus disabling it. The only way I have found to re-enable the admin account is to edit the MySQL tables to clear out the flags and retry attempts. What are my options to keep this from happening? I have it set to disable an account after just 10 failed login attempts. They are disabling it again within hours of me re-enabling the admin account. The header of the email shows:
X-PHP-Script: h600.org/wiki/tiki-login.php for 5.188.62.214
X-PHP-Originating-Script: 32827:Sendmail.php

Can I rename the admin account setup during the configuration? (Do not recall if the name is baked-into the code or not.)

I tried to block their IP address (5.188.62.214) for all services using the "Banning" feature but that does not seem to have any affect. Guess the login page service is not an included service. The IP is from St Petersberg, Russia.

I already changed the email address for the admin account as I was getting fake emails to the admin email through other software installed on the system (TNG). The fake emails are composed with garbage but a return email address given of revers at o5o5.ru Not sure if related.

posts: 27
Rick Sapir / Tiki for Smarties wrote:

This was addressed in a prior release . You should upgrade your Tiki ASAP. See
https://tiki.org/article473-Security-Releases-of-all-Tiki-versions-since-16-3


I am at a release that fixes the flaw so it presumably will not allow them to enter. But I cannot keep the admin account active long enough to upgrade to the absolute latest release!

I just went ahead and put a deny line in my .htaccess for the class C network including the ISP and others nearby. Cuts out innocents but resolves the issue. Hopefully, they are just a bot and won't pay attention / notice and try to get around that with a VPN to somewhere else. Something they could do if the banning mechanism worked anyway. Guess the real long term solution is to remove menu / module items for login and add a recaptcha to the login PHP page itself. Or allow a site-set initial admin account name.

But would still like to know if I can safely rename the main, first admin account to something not so easily determined.

posts: 126762 United Kingdom
RandyH wrote:
I am at a release that fixes the flaw so it presumably will not allow them to enter. But I cannot keep the admin account active long enough to upgrade to the absolute latest release!


Hi RandyH

Sounds grim! I presume and hope you have made another account with an unpredictable username and strong password and added that to the Admins group, and once you have done that you can use the validate button on the admin user page to unlock the default admin account if necessary... but if you're under such continuous attack (and have an alternative admin login) you could also just leave it locked which might save time?

Hope that helps.

posts: 27
Jonny Bradley wrote:

Hi RandyH
I presume and hope you have made another account with an unpredictable username and strong password and added that to the Admins group, and once you have done that you can use the validate button on the admin user page to unlock the default admin account if necessary... but if you're under such continuous attack (and have an alternative admin login) you could also just leave it locked which might save time?

I had not yet but will do so. Guessing this means it is a hard coded name that cannot be changed. For now, the .htaccess deny on the Class C network is working to block them. Hopefully they will not get more sophisticated using VPNs and such. Likely some middle school kid just learning the tricks of the trade.