SOLUTION for "site was hacked" !!!

[graphicsguru]

richrf are you useing Google Safe Browsing API ?

[richrf]

Originally Posted by graphicsguru

richrf are you useing Google Safe Browsing API ?

Hi,

I have a developer looking into it. I can't really use Pligg, if spammers leave links on my site that may contain malware or porn. So, this is kind of key. Akismet also helps in this regard. I'll let you know if I am successful.

Rich

[Rodney]

It is impossible to have maintain a clean, heavily used site without these protections.

I don't think it's true that you can't have a clean/heavily used site without the Bad Behavior type plugin. I don't think all high traffic blogs or php based sites run Bad Behavior.

Not saying it's a bad plugin, but your statements are just a bit over reaching :)

You're right though, after reading the "how to" on how to get Bad Behavior working with "any" PHP script, it seems pretty straightforward.

http://www.homelandstupidity.us/soft...-bad-behavior/

By default Bad Behavior can provide protection to any PHP script out of the box, but it cannot provide logging. If you are willing to live without Bad Behavior’s detailed logs, simply install the Bad Behavior folder somewhere on your server, and then call require_once("/path/to/Bad-Behavior/bad-behavior-generic.php"); from your PHP script. I recommend placing this function call in a common piece of PHP code which is loaded from all parts of your PHP-based software, so that it can provide protection to all parts of your software.

If I had a thumbnails worth of PHP skills, I'd try porting it to pligg myself.

I may test out the "non-logging" version they describe to see if I can get it working though.

Can anybody name a common piece of PHP code in pligg that is used by almost all of the pages? I can test adding the bad behavior call to that page.

[rwallen]

This afternoon my entire site was deleted from my server at godaddy. No one knows my ftp login info and my computer is free from all rootkits / spyware / virus. Plus there were folders deleted that you are unable to delete via an ftp client. I've had something happen like this a long time ago when I was using an invision board, there was a security hole and a hacker uploaded a root kit and wiped my site.

Anyway I'm having godaddy look into it. The strange thing is is that I can not upload anything via ftp, godaddy is trying to fix that as well and they assured me the problem wasnt on there end.

Fortunately I back my site up every night and none of my db's were effected.

If there is some kind of vulnerability that godaddy finds I'll email it to the pligg devs.

[richrf]

Originally Posted by Rodney

I don't think it's true that you can't have a clean/heavily used site without the Bad Behavior type plugin. I don't think all high traffic blogs or php based sites run Bad Behavior.

Not saying it's a bad plugin, but your statements are just a bit over reaching :)

You're right though, after reading the "how to" on how to get Bad Behavior working with "any" PHP script, it seems pretty straightforward.

http://www.homelandstupidity.us/soft...-bad-behavior/



If I had a thumbnails worth of PHP skills, I'd try porting it to pligg myself.

I may test out the "non-logging" version they describe to see if I can get it working though.

Can anybody name a common piece of PHP code in pligg that is used by almost all of the pages? I can test adding the bad behavior call to that page.

Hi,

My site is a medium visibility site with about 200,000 Alexa and a PR 4. Not that big, not that small. About 2000 visitors a day, and about 100 or so are bots. Without Bad Behavior (or equivalent), my site would be totally inundated with garbage. Akismet alone, is insufficient. Once the bots get in, they can create so much havoc and consume so much CPU, that it would bring my site down (it happened very quickly when I temporarily turned off Bad Behavior). I am very confident that any site, with medium to heavy traffic has to have encountered the same problems, and must have something in place to prevent these occurrences. Captchas are ineffective.

Let me know if you are successful. I am looking into it myself and will let you know if I am. Logging is not necessary, unless you monitor it to see if Bad Behavior is having bad behavior itself, which at this time I am not doing.

Thanks.

Rich

[richrf]

Originally Posted by rwallen

If there is some kind of vulnerability that godaddy finds I'll email it to the pligg devs.

Were you using any plugins or mods other than the core modules?

Thanks,
Rich

[uidi]

You could also change the access to "read" only.

[kallu]

Originally Posted by graphicsguru

that only helps it will not stop them 100%

its from Hackers using PyCurl to bypass registration

you can see some on the morons on Pligg Beta 9 / Upcoming

add them to your ban urls

Hi,

This is my first post on this forum.
I had been facing the "unwanted users registration problem" myself, but managed to solve it (or so it seems for now :) .. haven't had a similar attack for the past ten days or so, while previously it had become almost a daily occurrence).

I first tried using the email verification route.
That only succeeded in preventing the spam accounts getting activated, as all the email addresses were, of course, fake.
The en masse creation of accounts continued without fail.

Eventually I had to replace the default captcha with a new one and this finally stopped the account creation.

The quoted article:
Hackers using PyCurl to bypass registration
seems to suggest that the problem lies with a piece of code within libs/user.php.
It goes on to say:
"..Rather than using the captcha, it is just dumping in users by latching directly onto the users.php file.."

If I understood it right, the article seems to suggest that the hacker is bypassing the regular registration mechanism (register.php) totally (thus not going through captcha at all) and directly using user.php somehow.
My argument that follows is based on this. Please correct me if my understanding is flawed.

For using email verification, I added a new field to the users table, that holds
a random unique string that is emailed to the new user at the address he provides at registration time. This string has to be returned by the user for activating his account.

My question is, if what the aforesaid article says is true, how was the bot script still able to insert a new user record in the users table, complete with the random string in the new field?
Clearly it had to go through the routines in register.php.
Had it used user.php directly, I doubt if the new field would have been populated (I'd like someone conversant with pligg source code to comment on this)

I figured out that the captcha used was too weak for the bot and then replaced it with another one.
This seems to have done the trick.

Hope this helps somebody else too.

[AshDigg]

Originally Posted by kallu

Hi,

This is my first post on this forum.
I had been facing the "unwanted users registration problem" myself, but managed to solve it (or so it seems for now :) .. haven't had a similar attack for the past ten days or so, while previously it had become almost a daily occurrence).

I first tried using the email verification route.
That only succeeded in preventing the spam accounts getting activated, as all the email addresses were, of course, fake.
The en masse creation of accounts continued without fail.

Eventually I had to replace the default captcha with a new one and this finally stopped the account creation.

The quoted article:
Hackers using PyCurl to bypass registration
seems to suggest that the problem lies with a piece of code within libs/user.php.
It goes on to say:
"..Rather than using the captcha, it is just dumping in users by latching directly onto the users.php file.."

If I understood it right, the article seems to suggest that the hacker is bypassing the regular registration mechanism (register.php) totally (thus not going through captcha at all) and directly using user.php somehow.
My argument that follows is based on this. Please correct me if my understanding is flawed.

For using email verification, I added a new field to the users table, that holds
a random unique string that is emailed to the new user at the address he provides at registration time. This string has to be returned by the user for activating his account.

My question is, if what the aforesaid article says is true, how was the bot script still able to insert a new user record in the users table, complete with the random string in the new field?
Clearly it had to go through the routines in register.php.
Had it used user.php directly, I doubt if the new field would have been populated (I'd like someone conversant with pligg source code to comment on this)

I figured out that the captcha used was too weak for the bot and then replaced it with another one.
This seems to have done the trick.

Hope this helps somebody else too.

You are right. The article is incorrect.

[sc2000]

Originally Posted by kallu

Hi,

This is my first post on this forum.
I had been facing the "unwanted users registration problem" myself, but managed to solve it (or so it seems for now :) .. haven't had a similar attack for the past ten days or so, while previously it had become almost a daily occurrence).

I first tried using the email verification route.
That only succeeded in preventing the spam accounts getting activated, as all the email addresses were, of course, fake.
The en masse creation of accounts continued without fail.

Eventually I had to replace the default captcha with a new one and this finally stopped the account creation.

The quoted article:
Hackers using PyCurl to bypass registration
seems to suggest that the problem lies with a piece of code within libs/user.php.
It goes on to say:
"..Rather than using the captcha, it is just dumping in users by latching directly onto the users.php file.."

If I understood it right, the article seems to suggest that the hacker is bypassing the regular registration mechanism (register.php) totally (thus not going through captcha at all) and directly using user.php somehow.
My argument that follows is based on this. Please correct me if my understanding is flawed.

For using email verification, I added a new field to the users table, that holds
a random unique string that is emailed to the new user at the address he provides at registration time. This string has to be returned by the user for activating his account.

My question is, if what the aforesaid article says is true, how was the bot script still able to insert a new user record in the users table, complete with the random string in the new field?
Clearly it had to go through the routines in register.php.
Had it used user.php directly, I doubt if the new field would have been populated (I'd like someone conversant with pligg source code to comment on this)

I figured out that the captcha used was too weak for the bot and then replaced it with another one.
This seems to have done the trick.

Hope this helps somebody else too.

Changing the the captcha from the default pligg captcha to one of the others provided on the list of captchas solved the problem completely? Or do I need to install a specific one? Thanks.