MoBiC-10 Bonus: another PHP-Nuke CAPTCHA bypass

22:54 10.11.2007

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 8-) . 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.


16 відповідей на “MoBiC-10 Bonus: another PHP-Nuke CAPTCHA bypass”

  1. KrasivayaSvo каже:

    Don’t work at PHP-Nuke 8.0

  2. MustLive каже:

    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.

  3. KrasivayaSvo каже:

    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);
    }
    }

  4. KrasivayaSvo каже:

    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.

  5. MustLive каже:

    KrasivayaSvo.

    You are welcome.

    If you found bugs at PHP-Nuke in future please emailed me.

    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.

  6. MustLive каже:

    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.

  7. Tiggy каже:

    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

  8. MustLive каже:

    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.

  9. Tiggy каже:

    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

  10. MustLive каже:

    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.

  11. Tiggy каже:

    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

  12. MustLive каже:

    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.

  13. Tiggy каже:

    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 :)

  14. MustLive каже:

    Tiggy, thanks for additional testing ;-) .

    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.

  15. ADEL каже:

    How Can I use it ?? help me :? : :? : :? : :? :

  16. MustLive каже:

    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).

Leave a Reply

You must be logged in to post a comment.