1 Reply by zap

(28 replies, posted in PunBB 1.2 discussion)

MattF wrote:

It's worthwhile remembering, (if you have any more problems), to check your own security, setup and coding before laying blame on someone elses. smile

I did ;-) In fact, I spent almost two days checking out various things. The thing is, the other copy was on another domain which is otherwise inactive and has separate logs. Not exactly the kind of place you think of checking out. I wish I had had access to some kind of DB log.

But I know what you mean... I often waste lots of time investigating crazy theories (eg. your software only works while I'm not sitting on my chair) only to find out a user messed up something basic (eg. I forgot to mention I'm using linux-fedora-pre-alpha-bleeding-edge on a mac laptop). It seems that's just the way it is with software development. smile

MattF wrote:

It's probably still a goood idea though IMHO to drop in some sort of PunBB anti-spam solution - even a simple one like the one here - http://www.punres.org/viewtopic.php?id=3439 - may still be useful.

Given the mad stuff I implemented to work around this problem, I'm pretty sure we'll be spam-free for a long time. But I'll know where to look if it ever becomes a problem again.

Go to forum: PunBB 1.2 discussion

2 Reply by zap

(28 replies, posted in PunBB 1.2 discussion)

Smartys wrote:

zap: Could this (another copy of PunBB using the same database settings but with different pun_config options) be the issue for you?

Funny you should mention this just now, I found out that was indeed the case late friday night. The web site was tested on another domain before being deployed and apparently it was not correctly removed: access to the site itself was denied but a direct link to the forum still worked. That would explain why the spam seemed to just drop into the DB and there were no traces of anything in the server logs.

I'm pretty sure the forum will be spam-free now. I'm sorry about everyone's wasted time. I'll now go and kick someone for leaving junk on a web server which wasted several hours of my time as well.

Go to forum: PunBB 1.2 discussion

3 Reply by zap

(28 replies, posted in PunBB 1.2 discussion)

elbekko wrote:

Are you sure nobody just got hold of your DB info? It certainly seems more plausible.

Seems unlikely. The spam is pretty obviously automated and I doubt someone could grab the information of enough forum databases to make that worthwhile. Unless there's another common hole somewhere which allows that part to be automated... but it all seems farfetched.

Besides, I'm not even sure outside access to the DB is possible with only the DB login. I don't see why it would need to be. So they'd have to have some kind of access to the web server as well... at which point I'd expect problems greater than plain old spam smile The rest of our website, some of which is also in the DB, is quite intact and spam-free.

Go to forum: PunBB 1.2 discussion

4 Reply by zap

(28 replies, posted in PunBB 1.2 discussion)

Smartys wrote:

Unfortunately, that's the way it has to be done to support anyone using the mysql extension (as opposed to mysqli) and (I think) the SQLite extension. Prepared statements, stored procedures, etc aren't features that everyone with a PHP install supports, so this is the way it has to be done.
I would disagree with your overall assessment though. User input is properly sanitized (using $db->escape or intval, depending on the type of data) before being put into the query. We're not just accepting any input from $_GET and shoving it into the query.
If you have a suggestion for another way to construct queries, I'd be interested to hear it. smile

Aww, I didn't know SQL was in such a crappy state still in 2007.

As for another way, wouldn't it be possible to factor all db access into a single function where a query format string (say, something printf-like but less messy) would merged with the query arguments into a final SQL query? The idea is to have a single location where the arguments are escaped so none can be forgotten. It might also make the queries easier to read. Again, I don't do much php (mostly know how it works from perl) so maybe this makes no sense.

As it is now, there are three ways parameters can be handled: $db->escape when building the query, intval which seems to often be applied a little earlier and script-generated values which are never escaped at all. This makes it easy to mix things up and forget an escape.

I guess my point is that SQL injections are not bugs that should be fixed but something that should be designed out of the system, relying as little as possible on the developer being fully awake when he writes the code. :-)

Smartys wrote:

Are you running the latest version (1.2.15)? Have you actually checked the IPs against entries in the access_log? What mods are you using on your forum?

Yes, I upgraded when the spam started coming in but it didn't make a noticeable difference. I checked the IPs but found zero references to them. Unfortunately I've deleted all the spam users since so I can't check again. I even tried to roughly scan the log by date/time for suspicious stuff but couldn't see anything fishy. I'll try to find some time to look again since there was a new spam episode a few days ago (it had been quiet for a week or two). There are no mods that I know of on the forum, it's a plain install with a few stylesheets changed to make it fit in our website.

Smartys wrote:

Could you provide a link to your forum? I'd like to investigate this a bit myself.

Sure, drop me an email and I'll point you there.

Smartys wrote:

Before I forget to say it, zap, thank you for clarifying your post smile

You're welcome :-) And thanks for actually caring about the issue.

Go to forum: PunBB 1.2 discussion

5 Reply by zap

(28 replies, posted in PunBB 1.2 discussion)

StevenBullen wrote:

Idiot!

Smartys.... fair play for even replying to him. He dont deserve it... 10/1 he is under 15.

And you are obvisouly far, far older to have so much wisdom.

FWIW, I'm well into my 20s and a software developer. Smartys at least knows how to deal with criticism.

Go to forum: PunBB 1.2 discussion

6 Reply by zap

(28 replies, posted in PunBB 1.2 discussion)

Smartys wrote:

Do you allow guest posting? Do you use any of the anti-spam mods? Do you require users to verify their registration via email? Using an unmodded, completely open version of just about any forum software is going to get you spam.

No, no, yes.

Smartys wrote:

Assuming you're not using any of the anti-spam mods that have been released, might I suggest doing so? A lot of homemade anti-spam solutions I've seen people come up with have mistakes in the code that renders them ineffective. Using one of the mods should avoid that issue.

That's what I would have considered until I realized it would be pointless if they didn't go through the registration page...

Smartys wrote:
zap wrote:

Having read through some of the code it becomes clear that this was never written with security in mind.

Security is something we take very seriously, so I'm surprised to hear you say that. I'm not exactly sure what you mean though: care to clarify?

For one thing, there's SQL sprinkled all over the place in the php scripts without systematic (AFAICS) protection against injection. SQL queries built on the fly with user input screams "it's the 90s and security isn't an issue yet". Maybe there's something I don't see (SQL/php isn't really my domain) but it sure doesn't look solid.

Smartys wrote:
zap wrote:

The spammers we get are injecting users and posts straight into our database without ever going through the registration page. This means most of the "fixes" posted here won't work.

I have to go with Dr Jeckyl and say that without more information, this is a bogus claim. I've seen anti-spam solutions work extremely well (I've also seen PunBB forums which have never experienced spam) and I have never seen an SQL injection in PunBB that would allow something like that. If you think you've found an SQL inject in PunBB though (I'm talking about PunBB itself, not a mod you installed or coded yourself), I would encourage you to report it so we can fix it.

Well for one, we didn't get the registration alert emails for the spammers' users. I also implemented a few checks here and there in the register and post scripts and it was clear by looking at the db afterwards that the users/posts had not gone through there. For example, I tried a "minimal first post delay" which was enforced when I manually registered a user but which the spam posts got around like it was a joke (the db often had delays under 10 seconds).

I'd gladly report any SQL inject bug if I only knew how to track it down. Server logs were quite unhelpful; anyone who can inject stuff can obviously fake their IP in the db so it's like looking for a needle in a haystack...

Smartys wrote:
zap wrote:

I had to spend several hours coding my own anti-spam thing which, for now, seems to hold up.

Doesn't that directly contradict what you said earlier, that it was "no use" to try to deter spam from a PunBB forum?

Yes and no. I wouldn't expect most people to be able to come up with some php/SQL to get around spam. And it doesn't really block spam, it simply detects it automatically and hides it.

Go to forum: PunBB 1.2 discussion

7 Reply by zap

(28 replies, posted in PunBB 1.2 discussion)

It does like crap, to put it mildly. We had PunBB installed on our site by the person who built the whole thing and have been spammed pretty heavily for the last few months. I updated to the latest version, hacked a few scripts here and there to fool bots but it's not use. Having read through some of the code it becomes clear that this was never written with security in mind. The spammers we get are injecting users and posts straight into our database without ever going through the registration page. This means most of the "fixes" posted here won't work. I had to spend several hours coding my own anti-spam thing which, for now, seems to hold up.

I know the PunBB people are not going to like this but I feel you should be warned.

Go to forum: PunBB 1.2 discussion