Atomicorp

I will locate them, but I have a script written for me by Parallels that generates an email and tells the user that on such and such date their password will change to xyz. Then on that date a script is run that has the passwords in it and it changes them all. My thought on this is that if this script is so pervasive and inclusive it already knows the email address and its password. One might assume that if we email them a new password it will be compromised as soon as it goes out.

Thats certainly a possibility, not sure if this will help or not but this is a shell function I use to generate random 10 character passwords:

alias newpass='tr -dc [:alnum:] < /dev/urandom | head -c 10; echo'

I was reading site logs and came across an IP or 208.xxx.xxx.xxx. I observed this IP attacking last night and blocked it on the hardware firewall. I am watching it hit all of our IP's and centralized DNS servers -- but not getting through.

208.115.117.72

It is probably a hacked box but is in Seattle.

If someone comes up with a true solution, let me know... no matter what I do, they're back today.

_________________
3.14159265358979323846264338327950
"Ok, yes... I like pie... um, I meant, pi."

Hi JimDunn and the rest,

I had the same and I have collected literally thousands of these perl scripts.
It crippled my network twice from the inside.
I even thought of changing all FTP password, but it would be a pain for hundreds of clients' domains in there (nevertheless did one and regretted it because it wouldn't work) and there was no proof it came via the FTP, nor the WEB.

My first (brute force) solution was to write and run a script to clear all scripts in cgi-bin folders and move it to a secluded folder under root. Every second, that's the only way to win, because the script once manifested itself it was straight away called via the web.
Even though we disable perl in apache, it was still deadly. Done many things but nothing works. It just kept coming back without invitation and without any trace.

Initially to eradicate:
- following your instructions over clearing stopping apache and clearing and restart apache
- Run my script and let it stay resident (every second mv command put the server a bit of strain when it was busy)
- So far it has been amazing, collection started right away
- Basically I won the fight in matter of split seconds

7 Mar morning, had a few attacks again at about 7-9AM (+0800) and what I did desperately was:
1. clear all the test folder under httpdocs and httpsdocs (the asp, php, perl, etc folders)
2. Remove the test from the skeleton
Reason I did this was I kept seeing python test.fcgi keep appearing in the ps, maybe it was a loophole.

Since yesterday morning, the attack stopped (almost 1 day of quietness)
Speculations:
- Not sure whether it was because the attack has literally stopped
OR
- The removal of test folders work and that was their way of coming in

Jim, the attack has stopped for the last 24 hours for you too? If yes, then it's the first speculation, otherwise the second

Cheers

Horn Wijaya
hwijaya@nodens.biz
http://www.nodens.biz/
http://www.antispam.com.sg/

I've always wondered about the test scripts that ended up in Google. Like, HERE I AM. COME HACK ME! Plesk released a installer patch and my guess is that the installer creates these test folders and scripts? In a small sense I am fortunate that I still have legacy Ensim customers and their passwords are encrypted with no way to decrypt them. One question to ask is how a web site is chosen for the exploit. If the hacker can do anything he wants, why the limitation?

rm -fr /var/www/vhosts/*/httpdocs/test

I'm sure someone will come along with a patch to sell to cure us The problem we see in shopping cart files and manually sorting through DIR's to see which ones are hacker files. The date helps.

Has anyone compiled a list of the dictionary filenames used?

KrazyBob wrote:I've always wondered about the test scripts that ended up in Google. Like, HERE I AM. COME HACK ME! Plesk released a installer patch and my guess is that the installer creates these test folders and scripts?

I am terrible at bash coding. How can we write a line like a do for loop that deletes all /test DIRs? Maybe that is their way in.

I'm sure someone will come along with a patch to sell to cure us

You don't need a do loop
just one command for each http folder will do

rm -rf /var/www/vhosts/*/httpdocs/test
rm -rf /var/www/vhosts/*/httpsdocs/test

those two commands will clear ALL test folders, but just in case some users did have test folder, in a safe side, what I did was

rm -rf /var/www/vhosts/*/httpdocs/test/php
rm -rf /var/www/vhosts/*/httpsdocs/test/php
rm -rf /var/www/vhosts/*/httpdocs/test/perl
rm -rf /var/www/vhosts/*/httpsdocs/test/perl
rm -rf /var/www/vhosts/*/httpdocs/test/python
rm -rf /var/www/vhosts/*/httpsdocs/test/python
etc

Ok, thx, I've deleted 37 of those /test/ folders that contained the test.fcgi (and a 100 other things).

Hopefully tomorrow at 7am all will be well.

JimDunn wrote:Ok, thx, I've deleted 37 of those /test/ folders that contained the test.fcgi (and a 100 other things).

Hopefully tomorrow at 7am all will be well.

O yeah, make sure you kill the existing process of fcgi found under ps

My two-day-without-incident coming soon

hwijaya wrote:You don't need a do loop just one command for each http folder will do
rm -rf /var/www/vhosts/*/httpdocs/test
rm -rf /var/www/vhosts/*/httpsdocs/test

Also, you might want to check for & delete subdomain test folders:

Kalimari wrote:

hwijaya wrote:You don't need a do loop just one command for each http folder will do
rm -rf /var/www/vhosts/*/httpdocs/test
rm -rf /var/www/vhosts/*/httpsdocs/test

Also, you might want to check for & delete subdomain test folders:

Code: Select all

rm -rf /var/www/vhosts/*/subdomains/httpdocs/test

test folder does not exist under subdomains (at least in my system)

and btw, it's
/var/www/vhosts/*/subdomains/*/httpdocs

hwijava,

so far so good... i run this each day, but so far, still clean:

echo
echo =========================================================================
ls -laF /var/www/vhosts/*/cgi-bin/*pl
ls -laF /var/www/vhosts/*/subdomains/*/cgi-bin/*pl
echo -------------------------------------------------------------------------
ps ax | grep -i perl
ps ax | grep -i python
echo =========================================================================
echo

glad to hear it.
Finally we hopefully had put a stop to it.
Can't find any solution on the web for days.

My clean third day coming up.
And hopefully I could disable my secondly-run-two-liner-php-script from my system.

The only fear is whether the hacker took a break coincidentally

Parallels just sent out another urgent notice with a password changing script linked to it.


Nifty little script. Thanks. I'll add a CRON that emails me the results.

KrazyBob wrote:Parallels just sent out another urgent notice with a password changing script linked to it.


Nifty little script. Thanks. I'll add a CRON that emails me the results.

But personally I think it's not related to password, because they came in via a loophole rather than via proper means.
No record of web upload
No record of FTP access

Anyway, changing of hundreds of domains password and informing everyone about it is a one hell of a work and very inconvenient our clients.

Here is my not so special contribution to the simple script provided by Jim Dunn.
Assuming you are in /root run as:
Assuming you are in /root run as:
Add this to a CRON with crontab -e to run every hur.