Fortress modifies Article title to Fortress Alarm @ sitename

Corporal Joined: Apr 25, 2003 Posts: 53 Location: Sweden

I second that. A statusreport sure would be nice and possibly some estimate on when the new version will be realeased.

Nuke Cadet Joined: May 17, 2004 Posts: 2

Hi this may seem stupid, but what do you mean by 'comment out' I to have this problem you see, and would like to get it fixed. Does it mean to delete it? or put " " around it, or what? If possible can someone post the code with it commented out.

Nuke Cadet Joined: Dec 03, 2003 Posts: 6

I did a series of global replaces on the fortress.php file, changing the name of the 5 configuration variables by prepending them with "fortress" - for instance, $subject becomes $fortresssubject .

I am not an experienced php programmer, and maybe there are more idiomatic ways of solving this, but changing variable names to something that is unlikely to occur anywhere else in the codebase dodges the problem nicely in practice.

Nuke Cops Founder Joined: Nov 14, 2002 Posts: 5939

Sorry, I've been giving reports via the front page news. But in a nutshell its progressing nicely. You can check fortress.htm to see the kinds of hits we're logging, and then check fortress.csv to see who is actually banned.

I'm still fine tuning Union Tap Code as it now finds:

union
update
insert
drop
delete
truncate

You see, everyone in these 'exploit' announcements always focus on 'select' piped in by 'union'. No one ever mentions:

update
insert
drop
delete
truncate

Do you really want someone figuring it out one day and truncating all your tables?

The current UTC (not yet released) handles all these, but it needs to be refined. So its currently a work in progress.

The UTC you should now be running catches any "union" attacks in either plaintext, base64, or hex. The new UTC will just increase its focus to a laser beam.

The next version of Fortress(tm) (currently running on CCSP and NC) will not only ban suspects, but will also allow to ban user-agents. The aspects I'm working on right now:

-the actual ban page the suspect sees
-the user-agent banning system
-username exclusion filtering

This new version also sends SMS pages to your cellphone or pager, not just your email.

And, I'm undecided if the new release will support distributed banning from a centralized location. Certainly it's in the development pipeline.

As for the $subject issue, I've renamed certain variables for the new release. Apparently some sites fall victim to $subject but others do not. Even if the ReleaseVars() is used. Odd, but renaming it globally will do the trick.

You see, the idea of ReleaseVars() was to unset the variables before and after application use. And why some sites didn't handle it well, well... that's an enigma.

Corporal Joined: Apr 25, 2003 Posts: 53 Location: Sweden

Excellent work!

Distributed banning from a centralized location would be great but I think it is more important to release the new version.

Is a release still planned for this weekend?

Nuke Cops Founder Joined: Nov 14, 2002 Posts: 5939

If I cannot get Fortress(tm) out in time I plan on getting UTC out of the gate with its new rendition. But yes I'm still planning for this weekend. Just keep in mind I'm working on switching hosts this week perhaps, so that may delay the release.

Corporal Joined: Apr 25, 2003 Posts: 53 Location: Sweden

Fingers crossed then.

Smile

Nuke Soldier Joined: Apr 29, 2004 Posts: 12

Back on topic for just a sec..

As suggested above, prefixing all of the variable names in fortress.php and the module added to mainfile.php with 'fort_' resolves any possible conflicts with global nuke variables. I use a heavily modified version of XForum (hacked to work with phpNuke 6.5^) and was running into some of the same conflicts. It appears that XForum used the $subject variable for thread topic names. This got quite ugly when post after post was coming up with the same topic title.

I do have a question, with SO many header() calls in phpNuke, I've found that my raw webhost errorlog is bombarded by "cannot write header, already opened by <foo>". I've changed the existing fortress.php file to use the headers_sent() php function. The way I have it written, if headers have not been sent, then they are directed to index.php and then die(), if headers HAVE been sent, they just die(). Is there a better method?

Nuke Cops Founder Joined: Nov 14, 2002 Posts: 5939

Interesting points, I'll look into them. TY

Nuke Soldier Joined: Mar 05, 2004 Posts: 20

Hello;

We are having this issue as well. We are also using the suggested version UTC beta 4b and fortress 1.01 beta.

The ReleaseVars(); statement does appear in our code, yet the problem still exsists.

Should anyone have a fix for this, it would be appreciated.

Thank You!

Nuke Cops Founder Joined: Nov 14, 2002 Posts: 5939

Yes change all $subject to $fort_subject and all $realname to $fort_realname.

Nuke Soldier Joined: Mar 05, 2004 Posts: 20

Thank You very much; that fix did the job.

Very appreciated.

COOPVETS