The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
#1
|
|||
|
|||
![]()
Is there a way/plugin to disable password recovery for all "mod" groups (mods, smods , staff , admins...)?
I want this option because recently a hacker recovered the password of one of my admins and used it to change the emails of the smods so that he could use the recovery option later to steal them. |
#2
|
|||
|
|||
![]()
how did he do that unless he had access to that mods email. You could add a htpasswd file for all mods and admins or some kind of ip access only for mod and admin accounts
|
#3
|
||||
|
||||
![]()
Sounds like your mods need to be educated in stronger passwords on their email accounts. Almost daily I come across somebody that still thinks "rainbows" or "123456" is a good strong password. Because it sounds like his email was already hacked. If using Yahoo or Gmail, he needs education on two-step verification.
|
#4
|
|||
|
|||
![]()
The problem was that some mods/admins used a non existing email, so the "hacker" only had to create it and then use the password recovery function....
And then with the hacked admin he started changing all the staff's emails to ones he controls, to be able to "hack" them later via the same method. I want to be able to disable the password recovery function for staff members so that he can't use this method. Also, this is a bit offtopic, but is it possible that he can do an SQL injection or other xploit to gain control of my db if i am ONLY running vB 3.8.7 on my site? Could it be a not-know vulnerablity of vB that only he knows? Because that is what he did some months ago, but now it seems he can only use the method I described above... |
#5
|
||||
|
||||
![]()
That's not hacking -- it's social engineering. Your mods need a swift kick in the pants.
The only way to "disable" this would be to hide it from that usergroup. But any vB user with common sense would be able to manually enter the URL instead. This is a core function, so I don't think it could be disabled easily, or at all. Most SQL injections are easily thwarted by blocking access to key folders, using unique database settings (prefix), and running mod_security (Linux) or UrlScan (Windows) with settings aimed at squashing long scripted URLs (GET/POST commands). You can also lock users in the vB config, so their info cannot be changed via the admin panel. Everything you experienced was avoidable. ![]() |
#6
|
|||
|
|||
![]() Quote:
Code:
if (THIS_SCRIPT == 'login') { $vbulletin->input->clean_gpc('r', 'a', TYPE_STR); if ($vbulletin->GPC['a'] == 'pwd' OR $_REQUEST['do'] == 'resetpassword') { $vbulletin->input->clean_array_gpc('r', array( 'userid' => TYPE_UINT, 'u' => TYPE_UINT, 'activationid' => TYPE_STR, 'i' => TYPE_STR )); if (!$vbulletin->GPC['userid']) { $vbulletin->GPC['userid'] = $vbulletin->GPC['u']; } if (!$vbulletin->GPC['activationid']) { $vbulletin->GPC['activationid'] = $vbulletin->GPC['i']; } $userinfo = verify_id('user', $vbulletin->GPC['userid'], 1, 1); if (is_member_of($userinfo, 5, 6, 7)) { $user = $db->query_first(" SELECT activationid, dateline FROM " . TABLE_PREFIX . "useractivation WHERE type = 1 AND userid = $userinfo[userid] "); if (!$user) { // no activation record, probably got back here after a successful request, back to home exec_header_redirect($vbulletin->options['forumhome'] . '.php'); } if ($user['dateline'] < (TIMENOW - 24 * 60 * 60)) { // is it older than 24 hours? eval(standard_error(fetch_error('resetexpired', $vbulletin->session->vars['sessionurl']))); } if ($user['activationid'] != $vbulletin->GPC['activationid']) { //wrong act id eval(standard_error(fetch_error('resetbadid', $vbulletin->session->vars['sessionurl']))); } // delete old activation id $db->query_write("DELETE FROM " . TABLE_PREFIX . "useractivation WHERE userid = $userinfo[userid] AND type = 1"); $newpassword = fetch_random_password(8); eval(fetch_email_phrases('resetpw', $userinfo['languageid'])); vbmail($userinfo['email'], $subject, $message, true); eval(standard_error(fetch_error('resetpw', $vbulletin->session->vars['sessionurl']))); } } } It's just the code that would normally get called when you click on the emailed link, but if you're a member of groups 5, 6, or 7, it does everything except the actual changing of the password. I kind of like that because if someone tries it they'll probably get frustrated wondering why it isn't working. But if you prefer a message saying that you can't do it at all, then you could just do something like this: Code:
if (THIS_SCRIPT == 'login') { $vbulletin->input->clean_gpc('r', 'a', TYPE_STR); if ($vbulletin->GPC['a'] == 'pwd' OR $_REQUEST['do'] == 'resetpassword') { $vbulletin->input->clean_array_gpc('r', array( 'userid' => TYPE_UINT, 'u' => TYPE_UINT, 'activationid' => TYPE_STR, 'i' => TYPE_STR )); if (!$vbulletin->GPC['userid']) { $vbulletin->GPC['userid'] = $vbulletin->GPC['u']; } $userinfo = verify_id('user', $vbulletin->GPC['userid'], 1, 1); if (is_member_of($userinfo, 5, 6, 7)) { eval(standard_error(fetch_error("Forum staff members are not allowed to use this function."))); } } } If you decide to try one of these you'll probably want to test it. |
#7
|
|||
|
|||
![]()
how can i do this in 4.2.1?
|
![]() |
Thread Tools | |
Display Modes | |
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
![]() |
|
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|