[TAC] Fool Bot Honey Pot

[TAC] Fool Bot Honey Pot [Paid] 3.0.32

No permission to buy ($29.00)
Overview Updates (79) Reviews (28) History Discussion
The StopBotters.php file wants to use the datawriter from Custom Image Captcha

Code: 
FoolBotHoneyPot/Model/StopBotters.php:          $sbWriter = XenForo_DataWriter::create('Tac_CustomImgCaptcha_DataWriter_StopBotters'); // *2 Update to use the correct DataWriter
FoolBotHoneyPot/Model/StopBotters.php:                  AND addon_id = \'CustomImgCaptcha\'
 
I have added a couple of fields to the logs

i) core classical honeypots
ii) fbhp clasical honeypots

When you notice core classical honeypots drop to 0, we know that we're probably getting bots that by pass the cores honeypots
..However, what is more telling is when they hit the fbhp honeypots but seem to be javascript enabled!

If you just see one core honeypot getting triggered (or a couple) and several fbhp honeypots, this is not because fbhp honeypots are far superior (I don't want to boast.. but I suspect they are :)...), what this is actually due to is field ordering

The order of the honeypots will alternate fbhp,core,fbhp,core ... one or more of the core honeypots will sometimes not be present (to make them random order), this is core design functionality. Although what I think is bad design by the core is that sometimes (on rare occasions) none of the core honeypots will be present, this isn't an issue anymore, since the fbhp honeypots will always be present

So, when a bot hits the form, and they are a very old type of bot, they will fill out the fields named "name, email, password, etc", and they wont hit anything else
When a different version of an old bot hits the form, they will fill out every flied including both core and fbhp honeypots
Many bots will hit just the first few fields it finds, this just happens to be mostly fbhp fields and 1 or 2 core fields

However, when the new type of bot hits the form (these are the ones we will start to see more of in the coming months, and the reason I have now re-released fbhp, it will be needed again!)
  • It will by pass all core honeypots
  • It will pass the javascript detection
  • It will pass the registration timer.
  • It will get caught by 2-4 of the fbhp new classical fields
- I've yet to see the effect of secret ingredient 1, but I'm suspecting this too will also catch the new type of bot

I've seen these new bots being caught (see logs above), they are still rare


Anyway, here are the new fields added to the logs,
I hope what I've said is clear (corehoney pots: 1 vs fbhp: 4 doesn't necessarily mean fbhp honeypots are better, but 0:x is certainly telling!)

upload_2017-2-2_16-22-11.webp
 
Last edited:
@MattW

Sorry, I rushed that fix out since it was a simple change, and didn't check it
added foolbothoneypot_v3_0_01c.zip with the proper fix
 
Still getting errors (I've uploaded the whole TAC collection to stop them)

Code: 
Server Error Log
Error Info
XenForo_Exception: Invalid data writer 'Tac_CustomImgCaptcha_FoolBotHoneyPot_StopBotters' specified - library/XenForo/DataWriter.php:2055
Generated By: Unknown Account, 2 minutes ago
Stack Trace
#0 /home/minepeak/public_html/library/Tac/FoolBotHoneyPot/Model/StopBotters.php(47): XenForo_DataWriter::create('Tac_CustomImgCa...')
#1 /home/minepeak/public_html/library/Tac/FoolBotHoneyPot/Model/StopBotters.php(21): Tac_FoolBotHoneyPot_Model_StopBotters->localStopBottersSubmit(false)
#2 /home/minepeak/public_html/library/Tac/FoolBotHoneyPot/ControllerPublic/Register.php(261): Tac_FoolBotHoneyPot_Model_StopBotters->stopBottersErrors('FBHPUser', 'peter', 'peter.jone0086@...', '2da6a50bf884414...', '1', '1', 0)
#3 /home/minepeak/public_html/library/XenForo/FrontController.php(351): Tac_FoolBotHoneyPot_ControllerPublic_Register->actionRegister()
#4 /home/minepeak/public_html/library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#5 /home/minepeak/public_html/index.php(13): XenForo_FrontController->run()
#6 {main}
Request State
array(3) {
  ["url"] => string(37) "http://minepeak.com/register/register"
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(21) {
    ["93a3ca2ba43a8f52f21a10c1772e8e97"] => string(0) ""
    ["username"] => string(0) ""
    ["d8e082e09d5a214f0fc9a82725a35a57"] => string(5) "peter"
    ["1582bcac48d1bbd91528875a2161827a"] => string(0) ""
    ["e30c82f53174f8775f4889a2ac9f6409"] => string(0) ""
    ["5de7387648a51a216b8383fb3d4e9e8d"] => string(24) "peter.jone0086@gmail.com"
    ["password"] => string(8) "********"
    ["468fd9ce918af1012ed3d97e6191c844"] => string(0) ""
    ["4e9bc11b3341d90552cc240d1947c8ee"] => string(32) "aed75dd15ba3ad7e17472914fccc7b6c"
    ["93098af0e81953e10a0c2d4c227c1e60"] => string(0) ""
    ["dob_month"] => string(1) "3"
    ["dob_day"] => string(2) "14"
    ["dob_year"] => string(4) "1995"
    ["505ea5177b70c9d8ff189d828a131a51"] => array(1) {
      ["nzy0ytazywu"] => string(0) ""
    }
    ["custom_fields_shown"] => array(1) {
      [0] => string(11) "nzy0ytazywu"
    }
    ["7a6808203f9091df368dc348ee369566"] => string(12) "Asia/Kolkata"
    ["recaptcha_challenge_field"] => string(206) "03AHJ_Vut2ELw1S_SpQj87IHFHM1Q7uL2ruZhEGgTYINW7pGcK2jRMkTM-mdgi1GuDqKtfhD8xGB9hak0IPb7FIoJKHNjAAPT8nqRZ0KkUzRW53wBzzmrDrIhGx8oIG1CaElJOCZxaF60wgIyQIh_nuCiMcBwnTOivEPsmOq8HW_wjRmNnOEMqDJEdSMlrkWbQjbCjhoLbCgv-"
    ["recaptcha_response_field"] => string(12) "ncepeth ATHE"
    ["agree"] => string(1) "1"
    ["_xfToken"] => string(8) "********"
    ["reg_key"] => string(32) "764a03ae36dcd12a846301717611b624"
  }
}

Just added to a different site to test with only that addon installed

Code: 
# grep -iR CustomImgCaptcha *
upload/library/Tac/FoolBotHoneyPot/ControllerPublic/Register.php:                       $addonCICActive = (array_key_exists('CustomImgCaptcha', $addOns) && $addOns['CustomImgCaptcha'] > 0 && $options->captcha == "Tac_CustomImgCaptcha_Captcha_Captcha" && $options->fbhpCaptchaRegOff == 0? true : false);
upload/library/Tac/FoolBotHoneyPot/ControllerPublic/Register.php:                       $addonCIC = XenForo_Model::create('XenForo_Model_AddOn')->getAddOnById('CustomImgCaptcha');
upload/library/Tac/FoolBotHoneyPot/ControllerPublic/Register.php:                       $addonCICActive = ($addonCIC && !empty($addonCIC['active']) && $options->captcha == "Tac_CustomImgCaptcha_Captcha_Captcha" && $options->fbhpCaptchaRegOff == 0? true : false); 
upload/library/Tac/FoolBotHoneyPot/ControllerPublic/Register.php:               $CICWriter = XenForo_DataWriter::create('Tac_CustomImgCaptcha_DataWriter_Counts');
upload/library/Tac/FoolBotHoneyPot/ControllerPublic/Register.php:       protected function _getCountsModel(){return $this->getModelFromCache('Tac_CustomImgCaptcha_Model_Counts');}
upload/library/Tac/FoolBotHoneyPot/ControllerPublic/Register.php:       protected function _getUuidsModel(){return $this->getModelFromCache('Tac_CustomImgCaptcha_Model_Uuids');}
 
version c shouldnt have that issue, I've checked the zip, line 47:

Code: 
$sbWriter = XenForo_DataWriter::create('Tac_FoolBotHoneyPot_DataWriter_StopBotters'); // *2 Update to use the correct DataWriter

However, this dopey mistake *the one mentioned in your error logs" was in version B (due to me rushing out a fix):
Tac_CustomImgCaptcha_FoolBotHoneyPot_StopBotters

version c fixes it, and makes no reference to the non existent model (the error you are seeing above comes from version b)
 
This is quite interesting, I'm seeing this pattern quite a lot

This is a re-attempting bot(possibly GSA)

  • A bots tries to register .. it hits both classical and core honeypots
  • The IP for this bot is caught by many APIs (its already known)
  • So.. it re-attempts
  • It 1st switches IP address
  • This ip address happens to be one that is not caught be any APIs (they really know what they're doing)
  • on re-attempting, it gets past all classical fbhp honeypots (GULP)
  • on re-attempting, it gets past all core honeypots except one (I expect this is due to the count of hp being pushed up by fbhp, since all core hp are the same, I've seen the same type of bot pass these on the older fbhp version)
  • However, on re-attempting it still fails secret ingredient 1 (this is not a classical type of honeypots, bots wont even think about this)

These are smart bots, not the bots I was exactly targeting, but these bots are targeting classical honeypots and bypassing them !!! (I think it might be a GSA bot)
I think it's GSA, since I believe the xrumer bots now pass javascript detection (and I've seen them), however, this re-attempt bot doesn't, yet it still bypasses classical honeypots
See: https://forum.gsa-online.de/discussion/22020/can-gsa-bypass-xenforo-hidden-fields-honypots?new=1

Here's the pattern I keep seeing, secret ingredient 1 is holding up (and I know how GSA works, so it should continue to hold up):

upload_2017-2-6_12-58-25.webp
 
Last edited:
Now, I am looking at browser based bots

I have already said (if not, I am now)

Both browser and non browser based bots are targeting the core honeypot hidden fields

While secret ingredient 1 detects non browser based bots, and it does it very successfully, what about browser based bots that are now bypassing the honeypots?

That's where secret ingredient 2 will come into play.

I will be targeting the strengths of these browser based bots and making it their weakness!

They are after all still bots, if you know how to fool bots and you know how they work, you can stop them.



Secret Ingredient 1: Stops non-browser based bots that bypass the hidden fields (it simply detects if the user is using a browser with a very uniuqe mehhod)
Secret Ingredient 2: Stops browser based bots that bypass the hidden fields (it looks a user interaction, using the methods that browsers provide us)

I am working on Secret Ingredient 2 now

All of these methods are elegant, and humans do not even notice them
 
Yep, that's exactly the sort of bot I need to catch with secret ingredient 2. It's what I've been looking out for !!!

The new hidden fields will hold it back to some degree, they are fairly hard to target with xrumer since it looks for close labels (intel form), and my honeypots also have honeypot labels,
but I don't want to rely on these claassical honeypots, just like the core honey pots, they're getting targeted (I've seen GSA get pass them, thankfully GSA can't get passed secret ingredient 1)

It's JavaScript enabled, and bypassed the core honeypots, bypasses the reg timer, and even gets passed secret ingredient 1

This strongly implies it's a browser based bot, but more than that, I think this is the new version of xrumer that I've been looking out for
xrumer said:
Also, this updated technology is decoding arithmetical anti-bot protection, JS-protections, CSS-protection and honeypot.
Click to expand...
I think xrumers solutions to js detection and all other browser types of detection, is to actually use a browser automation as part of the registration

They haven't targeted secret ingredient 1, it's simply passed, because it is a browser!

Pretty scary

Anyway, we knew this was happening, that's why I'm back in the game
When a craked version of xrumer is released, and it gets widely used, fbhp is going to be highly needed again

So yes, indeed cause for concern
 
Last edited:
tenants said:
Yep, that's exactly the sort of bot I need to catch with secret ingredient 2. It's what I've been looking out for !!!

The new hidden fields will hold it back to some degree, they are fairly hard to target with xrumer since it looks for close labels (intel form), and my honeypots also have honeypot labels,
but I don't want to rely on these honeypots, just like the core honey pots, they're getting targeted (I've seen GSA get past them, thankfully GSA can't get past secret ingredient 1)

It's JavaScript enabled, and bypassed the core honeypots, and even gets past secret ingredient 1

This strongly implies it's a browser based bot, but more than that, I think this is the new version of xrumer that I've been looking out for

I think xrumers solutions to js detection and all other browser types of detection, is to actually use a browser automation as part of the registration

They haven't targeted secret ingredient 1, it's simply passed, because it is a browser!

Pretty scary

Anyway, we knew this was happening, that's why I'm back in the game

So yes, indeed cause for concern
Click to expand...
Ok, thanks for the response. I will keep an eye out for any more that fail SE1 to see if they ramp up in frequency.

Let me know if you need me to do anything else.
 
Deebs said:
@tenants cause for concern?

View attachment 147687
Click to expand...

upload_2017-2-7_7-33-57-png.147687


This is strong evidence that the core honeypots and the core registration timer are now beaten, it's only a matter of time until we start seeing swarms of spam (although, this should be reduced a fair amount due to the core API's).

My classical honeypots will also see this fate over time (xrumer usually only targets cores / common mechanisms, but it's customisations that worry me)

But these honeypots below are strong, they are non classical (not hidden fields):

Secret ingredient 1 will hold up for non browser based bots (I can't see them beating this, they shouldn't even be able to tell what it is from the front end)
Secret ingredient 2 will hold up for browser based (for quite a while, more than a few years, so long as the core doesn't use it too).

I might change the log names from
"Failed Secret ingredient 1" to "Non Browser Based Bot Detection"
"Failed Secret ingredient 2" to "Browser Based Bot Detection"

That way, people should understand why we only expect one of these to pass and the other to fail for all bots
 
You must log in or register to reply here.
Back
Top Bottom