Topic: 1.2.6: Vulnerabilities ?

http://echo.or.id/adv/adv22-y3dips-2005.txt

____________________   ___ ___ ________
\_   _____/\_   ___ \ /   |   \\_____  \ 
|    __)_ /    \  \//    ~    \/   |   \
|        \\     \___\    Y    /    |    \
/_______  / \______  /\___|_  /\_______  /
        \/         \/       \/         \/

    .OR.ID
ECHO_ADV_22$2005

---------------------------------------------------------------------------
            PunBB BBCode IMG Tag Script Injection Vulnerability
---------------------------------------------------------------------------

Author: y3dips
Date: August, 20th 2005
Location: Indonesia, Jakarta
Web: http://echo.or.id/adv/adv22-y3dips-2005.txt

---------------------------------------------------------------------------

Affected software description:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Version: 1.2.6 and most likely below
url : http://punbb.org
Author: Rickard Andersson
Description:

PunBB is a fast and lightweight PHP powered discussion board. It is released
under the GNU Public License. Its primary goal is to be a faster, smaller
and less graphic alternative to otherwise excellent discussion boards
such as phpBB, Invision Power Board or vBulletin. PunBB has fewer features
than many other discussion boards, but is generally faster and outputs
smaller pages.

---------------------------------------------------------------------------

Vulnerabilities:
~~~~~~~~~~~~~~~~

According to the issue that affect PHPBB discovered by easyex recently
at http://www.securityfocus.com/bid/14555/info , so it also affected in
another bulletin board or forum that allow BBcode such as PunBB.

The issue is due to a failure of the application to properly sanitize
user-supplied input in bbcode '[IMG]' tags included in a message or
user signature (if allowed , default is off) .

Successful exploitation of this vulnerability could permit the injection
of arbitrary HTML or script code into the browser of an unsuspecting user
in the context of the affected site.


Exploit:
~~~~~~~~

No Exploit exposed tongue , maybe soon

The fix:
~~~~~~~~

Vendor will be info with details


---------------------------------------------------------------------------
Shoutz:
~~~~~~~

~ m0by, the_day, comex, z3r0byt3, K-159, c-a-s-e, S`to, lirva32, anonymous
~ waraxe , LINUX, Heintz , slimjim100 , lunix, easyex all member of waraxe
~ newbie_hacker@yahoogroups.com ,
~ #e-c-h-o & #aikmel @DALNET

--------------------------------------------------------------------------
Contact:
~~~~~~~~

     y3dips || echo|staff || y3dips[at]gmail[dot]com
     Homepage: http://y3dips.echo.or.id/

-------------------------------- [ EOF ] ----------------------------------

Is this serious ?

[no signature]

2 (edited by Smartys 2005-08-30 22:09)

Re: 1.2.6: Vulnerabilities ?

It's not the issue you think it is wink
http://lists.grok.org.uk/pipermail/full … 36348.html
I found that listed under references.

I edited out the rest, since it was an unreadable jumble tongue
Basically, because PunBB requires the ID parameter before you logout, each image could only logout one person. Plus, it uses referrer checks (speaking of which, a referrer check on login.php?action=out that determines if you get a second confirmation page to check if it really is you might not be a bad idea) which means that the admin/mod tools shouldn't be vulnerable.
If you're really paranoid, you can turn off images in your preferences or for your board in Admin Permissions, but I can't really see this as any more of a problem then someone being able to make text the same color as the background to hide it from people just glancing over smile

Re: 1.2.6: Vulnerabilities ?

Yes, this really is a non-issue. It annoys me somewhat because it is not a script injection vulnerability. It's a brand new request for the browser. It's not that you can inject PHP code that gets executed together with the rest of the page. Also, the logout trick is, as far as I know, the only thing you can do with it. All "important" actions in PunBB require you to submit a form (e.g. POST).

"Programming is like sex: one mistake and you have to support it for the rest of your life."

Re: 1.2.6: Vulnerabilities ?

Yay for teh 1337 h4x0rs tongue

5

Re: 1.2.6: Vulnerabilities ?

From the descriptions above I'm not sure if these are separate exploits, but anyhow this is clearly not a non-issue.
Apparently it allows to run php scripts from other servers and perhaps injecting Javascript to the site. In both cases it can be used to phish user account details by redirecting the user to some other site that looks like punBB requesting for login and then reverting back to the originating bbs. People who won't actively follow what address bar says all the time could be fooled to give their credentials. And this is just one possible use for an exploit like this.

If I weren't so busy I would dig my sources for copy/pasteable proof of consept. Something quite similar was tried before inthe web based game I'm developing.

Re: 1.2.6: Vulnerabilities ?

Not this vulnerability wink
You shouldn't be able to retrieve a cookie from forums.punbb.org when you're loading the Javascript or w/e from evilsite.com via the img tag tongue

7 (edited by Jacq 2005-08-31 15:19)

Re: 1.2.6: Vulnerabilities ?

So you're asking for a proof of consept, right wink. I accept the challenge. If I understood the reports correctly check back tomorrow. Anyway it might just be the wind blowing through my lips, because right now I don't have time to verify the vulnerabilities.

Btw. Cookies are to be consumed with milk or tea tongue

Re: 1.2.6: Vulnerabilities ?

A proof of concept would be nice, although if you can do it I would send it to security @ this domain (if it starts working again tongue) or find Rickard on IRC

9

Re: 1.2.6: Vulnerabilities ?

Now that I've read the description the flaw is not in bbcode itself, but any method of linking an off site image can be used to (for example) phish.

10 (edited by CodeXP 2005-09-01 00:38)

Re: 1.2.6: Vulnerabilities ?

I think I've posted this before, but in case I didn't, here's a modification of parser.php that ensures that any potential img tag vurnabilities is a thing of the past. This version is the one I'm using on my site, so you may want to remove the image caching function I've written if you don't have enough storage space + bandwidth.

It does have some drawbacks, and will not work on every server, but if you're really concerned about this, then I don't think there's many other ways to do it.

1. Open include/parser.php

2. Find, line 282:

//
// Turns an URL from the [img] tag into an <img> tag or a <a href...> tag
//
function handle_img_tag($url, $is_signature = false)
{
    global $lang_common, $pun_config, $pun_user;

    $img_tag = '<a href="'.$url.'"><'.$lang_common['Image link'].'></a>';

    if ($is_signature && $pun_user['show_img_sig'] != '0')
        $img_tag = '<img class="sigimage" src="'.$url.'" alt="'.htmlspecialchars($url).'" />';
    else if (!$is_signature && $pun_user['show_img'] != '0')
        $img_tag = '<img class="postimg" src="'.$url.'" alt="'.htmlspecialchars($url).'" />';

    return $img_tag;
}

3. Replace with:

//
// Turns an URL from the [img] tag into an <img> tag or a <a href...> tag
//
function handle_img_tag($url, $is_signature = false)
{
    global $lang_common, $pun_config, $pun_user;
    
    $expire = '604800'; // How long should we wait to download the image again? Defaults to 1 week.
    $remove = array('://www.', '://', '%20', ' ', '/', '\\', ':'); // Remove unwanted characters etc. from our URL's...
    $file = str_replace($remove, '_', $url); // ...and replace them with a underscore
    $localfile = 'cache/img/'.$file.''; // This is the filename of the local cached copy.
    $AltTextName = basename($url); // Get the remote filename, for use as the ALT text in the <img> tags.
    
    if(file_exists($localfile) && (time()-filemtime($localfile) < $expire)) { // Check it image exists, and if it's expired.
        $url = $localfile; // Local copy is OK, and not expired, thus we provide don't need to do anything more right now.
    } else {

    switch(@exif_imagetype($url)): 
        case 1: // GIF \
        case 2: // JPG - For more image types: http://www.php.net/manual/en/function.exif-imagetype.php
        case 3: // PNG / 
                $pos = strrpos($url, '.');
                $ext = substr(strtolower($url), $pos+1, 3); // Get the file extension
                $NotAllowed = array('php', 'cgi', 'htm'); // Even though we know it's a valid image, we still check the extension just in case the image contains any EXIF exploits
            if($is_signature) {
                break; // Allow dynamic signatures (Don't cache them), but we'll still check if it's a valid image.
            }
            else if(in_array($ext, $NotAllowed)) {
                $url = 'img/warning.png'; // The file was not a valid image, or a dead link, so we'll show a warning image
            } else {
                $remote = @file_get_contents($url); // Get contents of the remote file
                $fh = @fopen($localfile , 'w' ); // Create a local file, ready for writing
                @fwrite ($fh, $remote); // Do the actual writing
                @fclose ($fh); // Done, let's close the file
                @chmod($localfile, 0777); // Don't want to run into permission problems later on, so let's chmod the file
                $url = $localfile;
            }
        break;
        default:
            $url = 'img/warning.png'; // The file was not a valid image, or a dead link, so we'll show a warning image
        break;
    endswitch;

}
     
    $img_tag = '<a href="'.$url.'"><'.$lang_common['Image link'].'></a>';

    if ($is_signature && $pun_user['show_img_sig'] != '0')
        $img_tag = '<img class="sigimage" src="'.$url.'" alt="'.htmlspecialchars($AltTextName).'" />';
    else if (!$is_signature && $pun_user['show_img'] != '0')
        $img_tag = '<img class="postimg" src="'.$url.'" alt="'.htmlspecialchars('Cached version of the file "'.$AltTextName.'"').'" />';

    return $img_tag;
}

4. Create the following folder, and chmod it to 777:

   <forum directory>/cache/img


5. Create a new file named .htaccess containing the contents below, and upload it to the directory you created in step 4.

<Limit GET POST PUT>
Order Allow,Deny
Allow from All
</Limit>

6. Create a warning image (for invalid images, or dead links) named warning.png, and upload it to:
   
   <forum directory>/img/


7. Save & upload.

EDIT: Updated to protect against any potential EXIF exploits, as recommended by Smartys smile

EDIT 2: As requested, I updated with a version that doesn't cache the signature images (so you'll be able to use dynamic sigs). It still checks if it's a valid image type though, so you're still protected against exploits.

Re: 1.2.6: Vulnerabilities ?

CodeXP: No it doesn't wink
I'll email you about it wink

12 (edited by CodeXP 2005-08-31 20:32)

Re: 1.2.6: Vulnerabilities ?

Smartys wrote:

CodeXP: No it doesn't wink
I'll email you about it wink

Actually, yes, it does smile Just sent you a mail about why it does...

13

Re: 1.2.6: Vulnerabilities ?

Almost forgot. If someone wants to use the image cache function, this admin panel plugin might prove useful smile

Clear Image Cache Plugin

14 (edited by Jacq 2005-09-01 05:38)

Re: 1.2.6: Vulnerabilities ?

It would be better to check which extensions are allowed because it is still possible to use perl, asp, php3, python or domino scripts and if you have access to the server you can change the extension to whatever you wish. .jpg for that matter.

15

Re: 1.2.6: Vulnerabilities ?

Jacq wrote:

It would be better to check which extensions are allowed because it is still possible to use perl, asp, php3, python or domino scripts and if you have access to the server you can change the extension to whatever you wish. .jpg for that matter.

That's where the get_imagetype check comes in. It's impossible to bypass that check, no matter what you do. The only reason I added that filetype check, was to ensure that a potential .php (only?) exif exploit couldn't happen.

16

Re: 1.2.6: Vulnerabilities ?

Btw. That non caching version doesn't work, because it still writes the data and points the url to a local file.

17 (edited by Jacq 2005-09-01 07:00)

Re: 1.2.6: Vulnerabilities ?

While it seems quite hard to redirect the browser with an image (as if the exploit doesn't work as described) it was quite easy to pass that exif_imagetype test as it checks only for three characters in the path (which happens to be a directory this time) and with supplying an authentic image when the exif data and the image data is correct. I believe with getimagetype the result would be same.

If the redirect worked you would get the phishing example shortly, but some things can be made with the exploit I just made. In the forums which use php sessions the users with cookies off will publish their session id in the address bar. By checking referrer in the "image" it is possible to steal that info and the identity with it. Not in punbb, but perhaps in phpbb.

CodeXP and Smartys: you'll have an email inbound shortly.

18 (edited by CodeXP 2005-09-01 10:12)

Re: 1.2.6: Vulnerabilities ?

Jacq wrote:

While it seems quite hard to redirect the browser with an image (as if the exploit doesn't work as described) it was quite easy to pass that exif_imagetype test as it checks only for three characters in the path (which happens to be a directory this time) and with supplying an authentic image when the exif data and the image data is correct. I believe with getimagetype the result would be same.

If the redirect worked you would get the phishing example shortly, but some things can be made with the exploit I just made. In the forums which use php sessions the users with cookies off will publish their session id in the address bar. By checking referrer in the "image" it is possible to steal that info and the identity with it. Not in punbb, but perhaps in phpbb.

CodeXP and Smartys: you'll have an email inbound shortly.

I've just read your e-mail, and you're right, it could possibly be used to exploit phpbb, but definetely not PunBB. Seeing as the image is in fact an image, it would make no sense to block it, just because it was produced by a directory w. an index.php file. Of course, as you mentioned, you could get session data passed to the URL, but that does not apply to PunBB smile

I could add an additional check to check if the URL is a directory, but as the fix is for PunBB only, it's not really needed.

EDIT: If you'd like to make sure using a directory name, containing an index file that in turn returns a valid image, is impossible, just add the following to the IF statement:

            else if(@fopen(''.$url.'/', 'r') !== FALSE) {
                $url = 'img/warning.png';
    }

Be aware that this could result in some linked images failing where certain remote servers uses some special 404 error documents.