Guests bypassing username in v2.2.6

Hi all,

I will be away for a week, but I noticed a problem that had been corrected in the release of v2.2.6 that I cannot reproduce.

A guest user has posted a message without supplying a username. Prior to version 2.2.6, vBulletin would not check the username value, however beginning with 2.2.6 it checks. When I attempt to post without a username, I get a standard error telling me that I need to supply one. Searching the database for the actual post resulted in a match for "" (nothing). I tested various alternatives, such as a space,  , etc. without being able to see the problem. I'm assuming that whatever characters are being used to exploit this are being stripped before going into the database, although I haven't checked the code to confirm this.

I wanted to post this now before I left to see if anyone could find the problem. This cannot be done easily (as my tests have confirmed) so I am forced to assume that these are the acts of a malicious user.

I should restate that this problem occurs with guests being permitted to post. Restricting the forum to registered users only is not an option.

I will be unable to reply until next weekend.

Many thanks,
Paul

* bump * Has anyone been able to take a look at this?

Are you using the fix posted by mike at http://www.vbulletin.com/forum/showt...5&pagenumber=2 ?

Sure am. That's why I'm kinda shocked.

Actually I dont believe it is a space or no username, it may be a character which isnt visible in your current font. There was an issue with topics having this problem where type alt+0160 created a space like character.

Try using that as a username when testing and see what happens.

I'm almost certain that the ALT+0160 issue was corrected in v2.2.6 (I'll have to scan through the changes file again). I know I read a few posts on it. Looking at the database, the value is null (""). My first thought was that it was a hidden character. I have just ran a test and it turns out that ALT+0160 is NOT blocked. I was able to post using that username, however checking the database for the following statement:

SELECT * FROM `post` WHERE USERNAME = "", returned three messages and DID NOT show the test message I posted. This is definitely someone posting without a username (not a hidden character).

I'm stumped.

the 0160 was blocked for thread and post titles by adding replacements to the censortext function.

When was the posts without a username posted and are they all from the same IP?

I'm sorry to say that I've been manually editing the database and changing the username to "Guest" whenever I have encountered one of these messages. Doing a search for the username "Guest" in the database shows 8 matches that were most likely this problem manifesting itself. In the past two weeks, the majority of those were posted. (The other posts with a username of "Guest" are for archived posts brought over from our old forum system made by persons using the same username as long time regulars, etc.).

Some of the IP addresses match, however some do not. The style of writing in all of these messages suggest the same writer, so I don't think it would be unfair to assume that this is one person posting from multiple places. Other than the lack of a username, the messages do not appear to be abusive.

Thanks,
Paul

P.S. - Is it possible to add the check for ALT-0160 to username
while we're looking at this?
P.P.S. - What file(s) would be performing a valid username check? I want to verify that this isn't caused by a hack, or anything similar.

I am still having problems with this. Can someone confirm this as a bug?

It has become clear that the person doing this on our forum is doing it intentionally and is attempting to hide themselves. Posts exhibiting this problem are now being made from open proxy servers on the Internet (i.e. mail.*.com, ns1.*.com).

There is an exploit occuring here and I cannot reproduce it. I have verified that there are no blank characters in the database and that the values are empty for username. I have corrected all issues discussed in the bug fixes forum and will now attempt to find the code that checks for the presence of a username.

Here's the code in question from newthread.php:

PHP Code:

// Bug fix for ability for Guests to use registered nickname // if (isset($username) and !isset($bbuserinfo['username'])) { if (isset($username) and $bbuserinfo['userid']==0) { // End bug fix $username = trim($username); $username = eregi_replace("( ){2,}", " ", $username); if (!$username) { eval("standarderror(\"".gettemplate("error_nousername")."\");"); }

What exactly is eregi_replace replacing there? Could a value be inserted into $username that would pass the nousername check?

Paul

There are no chr(160)/chr(173) checks on a username, although I don't think they would match a WHERE username = '' query. There are also no stripped out characters and looking at the code I don't see anything wrong with it off hand.

Just out of curiosity, could it have anything to do with the bug fix? I'm wondering if your code includes that.

Paul

Just saw your updated post -- eregi_replace is replacing 2 or more spaces with one. So that way "Ed--Sullivan" is replaced with "Ed-Sullivan" and would find my username.

The code I was looking at had my bug fix and I don't see any way that would have an effect on this.

Actually, while typing this out, I did have an idea. Will need to test it.

Thank goodness for the folks at #php.. I've been staring at this code for a while now. I'm thinking it's either something to do with !$username or with the query that actually inserts into the table...

Will keep looking myself :)

Edit: It's not the query that inserts it into the table. I'm now going to look at the possiblity of the value of $bbuserinfo['userid'] being changed to something other than zero and getting around the whole username check. If you do that, you could successfully insert $postusername as $bbuserinfo['username'], which for a guest would be '' ....

Paul

Quote:

Originally posted by Ed Sullivan
Actually, while typing this out, I did have an idea. Will need to test it.

Nope, didn't work. Right now, I don't have any further ideas but I'll keep my eyes open.