Continue our talk about last participant of the project - PHP-Nuke captcha. Which is using at User Registration form (and also at Login form). Like previous one I also found this hole at phpnuke.org. Vulnerable version is PHP-Nuke 8.1 (the latest) and all previous.

This captcha in addition to MustLive CAPTCHA bypass method is also vulnerable for null string bypass method. This Insufficient Anti-automation hole I found 21.10.2007.

If in MustLive CAPTCHA bypass method for bypassing captcha you need to use the same gfx_check and random_num values for every post. Than in null string bypass method you not need to use these parameters at all. Just send empty strings or not send them at all.

Null string bypass method - it is hardcore method . It’s design only for hardcore guys and gals. If you not feel yourself hardcore enough, don’t use it.

I’m tested it at PHP-Nuke 7.6, 7.7, 7.9, 7.9.3.20, 8.0, 8.1.
Bug found at version early 7.9 (not include) and 8.1.
Bug not found at 7.9, 7.9.3.20, 8.0.
As I know phpnuke.org use version 7.6.
You are right about: So if 8.0 version is not vulnerable, than it seems that it’s hole in new version PHP-Nuke 8.1.
For patching this bug user must include at mainfile.php strings
// Posting from other servers in not allowed
// Fix by Quake
// Bug found by PeNdEjO

if ($_SERVER[’REQUEST_METHOD’] == “POST”) {
if (isset($_SERVER[’HTTP_REFERER’])) {
if (!stripos_clone($_SERVER[’HTTP_REFERER’], $_SERVER[’HTTP_HOST’])) {
die(’Posting from another server not allowed!’);
}
}
else {
$posttags = “Warning: your browser doesn’t send the HTTP_REFERER header to the website.”;
$posttags .= “This can be caused due to your browser, using a proxy server or your firewall.”;
$posttags .= “Please change browser or turn off the use of a proxy”;
$posttags .= “or turn off the ‘Deny servers to trace web browsing’ in your firewall”;
$posttags .= “and you shouldn’t have problems when sending a POST on this website.”;
die($posttags);
}
}

Sorry for my forgetfulness.
Thanks to your work.
If you found bugs at PHP-Nuke in future please emailed me. I can test it on different version PHP-Nuke and talk to you which version vulnerable.
Thanks again.

It’s quite possible. In addition to two Insufficient Anti-automation holes, I also found two XSS holes in PHP-Nuke. When I’ll wrote annoucement of these XSS (without details) and inform developers, I’ll also write to you details of these holes, so you will check which versions are vulnerable.

I’m tested it at PHP-Nuke 7.6, 7.7, 7.9, 7.9.3.20, 8.0, 8.1.
Bug found at version early 7.9 (not include) and 8.1.

Thanks, man. So versions <7.9 and 8.1 are vulnerable.

Did you test only second hole (MoBiC-10 Bonus) or both holes (including MoBiC-10)? It's interesting to know if the same versions are vulnerable to both Insufficient Anti-automation holes.

As I know phpnuke.org use version 7.6.

Really? I thought that official site uses the latest version. Why are they not using new version - it’s rhetorical question - maybe they know that it has many holes, so not trust it (if official site not use the latest version - it’s sign for users).

It is why I said that vulnerable version 8.1, because I thought that this version is using at phpnuke.org. And I was right about 8.1 (by intuition, if official site is using old version). And you confirmed that version 8.1 is vulnerable (and also old versions of PHP-Nuke <7.9).

For patching this bug user must include at mainfile.php strings

It’s good that you fixed already this hole and gave your suggestion. Thanks, it will be usefull for users of this engine.

But I must tell you that this fix will not help much. Because it can be easily bypassed - referer checking can be byppased by referer forgery. It will help only from amateur, but professional easily bypass it - this will not fix Insufficient Anti-automation hole (only CSRF attacks), so this method will not stop attack from hacker. Users of PHP-Nuke need more advanced protection from these vulnerabilities.

As I told KrasivayaSvo before, referer checking will not help with Insufficient Anti-automation hole, because this checking can be bypassed. Hope your sugestion will fix this vulnerability in PHP-Nuke.

Did you checked only on this exploit (MoBiC-10 Bonus) or on two others PHP-Nuke CAPTCHA bypass exploits (MoBiC-10) also? It’s interesting to know if your patch fix one hole or both Insufficient Anti-automation holes.

I tried all our exploits (this one and the two others) but no new user was created.

I must say I get that “KrasivayaSvo warning (see code above)” on my official site and the local PN 8.1 site, but I am pretty sure adding “$gfx_chk” to both functions solves that problem.

I found out that users could register even if “gfx_check” & “random_num” were different while adding some mods to my site. After searching were the problem came from I found out “$gfx_chk” was empty (echoed all values) and that made me decide to add “$gfx_chk” to global for both functions. After that only “gfx_check = random_num” registrations seems to pass.

Hope someone with version without “KrasivayaSvo warning” can try it out (for example with same version of PN as for phpnuke.org)

Tiggy, I asked you about that, because I had feelings that you have some others reasons (besides your trick) which prevent exploits from work.

Like I said before, KrasivayaSvo trick will not help with Insufficient Anti-automation hole, because referer checking can be bypassed. But this trick is anti CSRF filter, so it stop my PHP-Nuke exploits (all 3 exploits), because they not designed to bypass anti CSRF. You need to use exploit with bult-in anti CSRF bypassing to test at your sites.

I must say I get that “KrasivayaSvo warning (see code above)” on my official site and the local PN 8.1 site

It’s why you have this warning and why exploits don’t work - because of anti CSRF filter. So you need to remove this anti CSRF code from your site (for example at localhost) to check my exploits or to make new exploit with anti CSRF bypassing function to check at your current sites.

I wrote many times at my site about such exploits. You need to use script languages to make such program (Perl, PHP or others) - you can use any of my perl exploits (with anti CSRF bypassing), which I published in MoBiC project, and make from it exploit for PHP-Nuke. To find out if your suggestion is working.

I finally did some more tries on my local server and without that $gfx_chk added a new user was created on the site; when I added it I got an error saying the security code isn’t correct (normal coz it wasn’t checked before).

I couldn’t find that Quake thing thingy on my local 8.1 so I suppose it isn’t there :p

I also removed the “Quake Fix” on my official site and tried the 4 exploits but they didn’t work; maybe my phph version there isn’t vulnerable … (running PN 7.8 I think).

I would appreciate if others did try it out to see if adding gfx_chk to gloabls fixes the problem; but I think it will … in 8.1 it will anyways

I also removed the “Quake Fix” on my official site and tried the 4 exploits but they didn’t work; maybe my phph version there isn’t vulnerable … (running PN 7.8 I think).

Man, as KrasivayaSvo wrote above, versions PHP-Nuke < 7.9 are vulnerable. So it’s interesting why exploits don’t work at your site. But he tested at different PN versions except 7.8, so maybe this one is not vulnerable (or you have 7.9 or other version).

in 8.1 it will anyways.

So for now we’ll be recommending to use your solution (with putting $gfx_chk to global) to fix these Insufficient Anti-automation holes.