MoBiC-10 Bonus: another PHP-Nuke CAPTCHA bypass
22:54 10.11.2007Continue 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.
Insufficient Anti-automation:
PHP-Nuke CAPTCHA bypass3.html - bypassing captcha by another method and data confirmation page and finishing registration.
Guys not overdo with this Captcha bypass test. This exploit for educational purposes only. Don’t use it for malicious purposes at any site on PHP-Nuke.
You need to setup exploit to test it (set site’s URL and others data). If you want to test it immediately, here is online example.
Insufficient Anti-automation:
phpnuke.org CAPTCHA bypass.html
Guys not overdo with this Captcha bypass test. This exploit for educational purposes only.
Moral: never make such vulnerable captchas.
Четвер, 13:19 15.11.2007
Don’t work at PHP-Nuke 8.0
Четвер, 22:57 15.11.2007
KrasivayaSvo, thanks for information.
As I wrote I tested in PHP-Nuke 8.1 (at phpnuke.org). So if 8.0 version is not vulnerable, than it seems that it’s hole in new version PHP-Nuke 8.1.
How about previous captcha bypass vulnerability in PHP-Nuke? Did you tested it in 8.0 - it will be interested to know about work of that hole in previous version of this CMS.
П'ятниця, 03:22 16.11.2007
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);
}
}
П'ятниця, 03:31 16.11.2007
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.
П'ятниця, 20:22 16.11.2007
KrasivayaSvo.
You are welcome.
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.
П'ятниця, 20:48 16.11.2007
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.
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).
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.
Четвер, 11:07 13.12.2007
I think I found an easier way to fix the problem
More info below:
QUOTE
Hi all,
There seems to be a bug in PhpNuke 8.1 …
At the “New User” registration the “security code” seems not to be checked when registering … entering wrong code doesn’t affect anything …
I could solve the problem by simple adding “$gfx_chk” at the end of the “global …. ” line in “Modules/Your_Account/index.php” for function “confirmNewUser” & “finishNewUser”.
Hope this helps you guys out
/QUOTE
Четвер, 16:33 13.12.2007
Tiggy
Thanks for your suggestion.
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.
Четвер, 21:06 13.12.2007
Hi,
I just tried on my local PN 8.1 install which I patched and it didn’t work anymore … if others can confirm it solved the problem I think this is the bugfix
Greetz
П'ятниця, 00:43 14.12.2007
Tiggy, it’s good that it works on your PN
.
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.
Субота, 00:31 15.12.2007
Hi again,
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)
Greetz
Субота, 01:30 15.12.2007
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.
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.
Понеділок, 18:53 21.01.2008
Hi all,
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
Понеділок, 23:38 21.01.2008
Tiggy, thanks for additional testing
.
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).
So for now we’ll be recommending to use your solution (with putting $gfx_chk to global) to fix these Insufficient Anti-automation holes.
Середа, 15:39 05.11.2008
How Can I use it ?? help me
: 
: 
: 
:
Середа, 18:47 05.11.2008
ADEL
Use exploit PHP-Nuke CAPTCHA bypass3.html which I published. Download it and setup it (e.g. set site’s URL in source code).