phpBB 2.0.11 exploits in plesk 7.5.3???

[tekmage]

Anyone have an rpm to upgrade to 2.0.15?

Twice in 3 days EV1's had to disconnect my box because someone's using it to udp flood some server in europe with a irc shellbot that seems to arrived via apache or some apache related service.

I've fully patched RH and plesk, but it happened again today with more scripts showing up, again owned by apache in /tmp.

Anyone else seeing this script kiddie stunt?

Thanks.

-=Dave

 

[voodoochile]

Protip: Create a group that the user apache does not have access too. Chown wget so that it's group executable. Problem solved.


All of these "exploits" rely on using wget to download scripts to your server to run/packet stuff. If the little script kiddies can't use wget, they're effectivley screwed. =)

 

[NightStorm]

I think the main point here is that people are still paying for the Application package, but the applications are not being kept up to date.
I'm finding that I'm having to disable more and more applications from the vault because they are too easily exploitable or too buggy, and not being updated by PSA. It's almost getting to the point where there's no point in paying for the Vault, since I have to install everything from the source anyway.

 

[uhoh]

Originally posted by NightStorm
I think the main point here is that people are still paying for the Application package, but the applications are not being kept up to date.

Thank YOU Plesk is dropping the ball here in this matter

Originally posted by NightStorm
I'm finding that I'm having to disable more and more applications from the vault because they are too easily exploitable or too buggy, and not being updated by PSA. It's almost getting to the point where there's no point in paying for the Vault, since I have to install everything from the source anyway.

Wonder how a company stays in business with this lack of support it seems to have towards its own maintanence

 

[tekmage]

I chmod'd wget days ago.. didn't do squat.

-rwx------ 1 root root 202772 Jan 21 10:36 /usr/bin/wget

 

[atomicturtle]

Yeah badguys can just upload their own wget.

 

[NightStorm]

The easiest way to fix this problem and still offer your clients the same great service you already provide is to take about 2 hours and read up on the building of application packages...
Then take the Plesk-built phpBB2.0.11, and from it build a package for phpBB2.0.15.
I admit that the one I did was sloppy (you have to go in and edit the setup after the site install, so that reconfigure is run), but for the most part, it works and I'm happy... well, happier.
If ART is bored, he could always take a look at it and see about tossing an updated copy in the repository, but I also hear he's become a real busy guy lately.

 

[atomicturtle]

I was always a real busy guy

 

[Herby]

Originally posted by atomicturtle
Yeah badguys can just upload their own wget.

agree

BUT

there are only few "bad guys" out there. 99% are only stupid script kiddies giving up if a process is not working as expected.

 

[voodoochile]

Bingo. There's always the "shoulda woulda coulda" stance with security, but we've gotta be honest with ourselves here.

1. If we see an updated phpBB in the app vault soon, that doesn't fix current installations, I don't see an easy way for SW-Soft to implement that either, unless they make a "package" consisting of patchfiles. This is gonna trash custom stuff done to phpBBs though, so probabally not a good idea on a hosting box. I don't see a clean way to do mass automation of something so customizable and widely installed. What happens if a customer just installs it themselves, without the app vault? Ther'es no record, no easy way to update it, let alone know where and how it's installed.

2. as has been stated, the wget fix is nothing but duct tape. It's ghetto and I freely admit that, but as of right now, it's a bit of duct tape that has kept my servers from hammering out crazy amounts of bandwidth due to scans/DOSs and psyBNCs. You really have to look at the level of "expertise" of the people pulling off these "hacks". They're script kiddies. They ahve zero clue of what they're doing, they just know they can run a script and own a box. If their script doens't work, they keep on scanning. As of yet, I haven't seen anything that puts it's own wget binary on the server (I'm sure it's out there, just not widespread as of yet.)

We can either sit here and b*tch about what sw-soft should do, gripe about a fix not being "perfect" or we can do what we get paid to do and keep our boxes safe to the best of our abilities until something better comes along.

I dunno about you, but my boxes have been just fine lately and I can now work on a better way to deal with this instead of spending my time cleaning up /tmp and killing ./stealth and ./bind processes.

I apologize if I come off as harsh, but we really need to be realistic about these things and save the hate threads for when they're necessitated.

 

[atomicturtle]

You nailed it with the management nightmare of updating all your users apps, if you automatically update them all at once, you run the risk of knocking out the custom ones. Any kind of automatic updater is going to be application specific. Playing with noexec flags, or permissions on binaries was an equally difficult and ineffective method, so in comes the security-in-depth approach that we're using in ASL. Assume you cant fix the applications, and you cant educate your users. 1) Add in an IDS layer (a la mod_security/mod_dosevasive). This deals with known patterns of attack, this is called "Misuse detection" and while effective on known attacks, it shares the same weaknesses as anti-virus, in that it can only deal with known attacks on known applications. (not so great on custom apps, or if you dont keep it up to date) 2) harden the kernel. By adding in the ability to control the role of a particular account, you can implement much more simple but effective security policies. Two examples, the first is called Trusted Path Execution (TPE), which if you're familiar with the /tmp noexec idea this is the logical next generation. The idea of setting /tmp noexec is this, an attacker when exploiting your webapp will upload their exploit to /tmp and run it from their because they know the path and they know they can write to it. If it cant execute, then they cant get in. The shortcoming of course is that they can write their attack code to places other than /tmp, like /var/tmp, or the users home directory. TPE does the same thing, except its effect is "If the file isnt owned by root, it cannot run" . Meaning the attacker can upload their exploit anywhere, /tmp /var/tmp, the mail spool, the home dir, etc and it wont run. Furthermore the granularity on this is based off the user ID, you can enforce TPE on just specific users (apache in this case, this effectively mitigates the php attacks). Example #2, establishing a clearly defined role for an account, meaning you could dictate much more specific rules to the way a user can interact with the system, in a simple case of apache I would define its role as it can only bind to ports 80 and 443, except when it calls sendmail, in which case it could bind to port 25. These rules would prevent a spammer\ from uploading their own MTA and sending spam out on port 25, since apache isnt allowed to bind to that port, it would work similarly on an attacker uploading and trying to run a BNC irc proxy on port 1234. Consider that the Cliff's notes on kernel hardening (Im leaving out a lot!) The policy mechanism alone is far more powerful than Ive described here, and thats why its such a big deal with SELinux and Grsec. At any rate, if you're looking for more info on either, you can bone up on SELinux at www.nsa.gov/selinux/ (no joke, they're involved ), and grsecurity.net