Unsecured scripts and site hacking?

[Alison]

Hello,

Please help, I'm looking for confirmation from some gurus here of the exact
extent of damage that a hacker can do via an unsecured script. I'll
explain;

On Monday the 1st January my site went down on a Red Hat Fedora virtual
hosted server provided by a company in the States. After 3-days they have
now informed that my site was hacked. I was logged in via ftp at the very
moment it went down as I was transferring my Jan 1st update. The only
script I had running on the server was a logger which I had written myself
and had 755 rights.

At the time, ALL server services went down at once; POP, HTTP, FTP, SMTP.

I do not believe that a hacker would have the ability to bring down an
entire server's services even if a script was unsecured. At MOST all they
would be able to do would be to upload their own script and interfere with
the files visible to them through the http:80 service.

Please clarify as I believe my webhost is lying to me. In previous years I
worked for UUNET in Cambridge (before their MCI demise) and am aware that
server services simply do not interact in this way. For my webhost to say,
"Oh your site was hacked due to an unsecured script," says to me that they
are simply stalling. It takes a maximum of 2-hours tops to restore a site
from backups and have it running again on another server.

Please advise on the extent of damage that someone can cause via unsecured
scripts?

a. Can they bring down an entire server and it's services?
b. Are they only able to modify files from which the scripts have a visible
scope, in this case, the http server.

Thanks in anticipation,

Alison

 

[John Bokma]

Hello,

Please help, I'm looking for confirmation from some gurus here of the
exact extent of damage that a hacker can do via an unsecured script.
I'll explain;

On Monday the 1st January my site went down on a Red Hat Fedora
virtual hosted server provided by a company in the States. After
3-days they have now informed that my site was hacked. I was logged
in via ftp at the very moment it went down as I was transferring my
Jan 1st update. The only script I had running on the server was a
logger which I had written myself and had 755 rights.

Making the code available would help.

It might be possible that vunerability in Fedora can be exploited via a
script, but I have more the feeling that your hosting provider is clueless
and wants to blame it on your script. Wouldn't be the first time.

When I did a lot of CGI back in the late 90's a lot of hosting providers
blamed every thing on CGI scripts when possible. I never understood why
PHP *inside* a webserver gained so much support if Perl + CGI was already
considered way to powerful and to blame for every hack attempt and any
other issue they had (except their lack of competence, as usual).

 

[Charlton Wilbur]

A> Hello, Please help, I'm looking for confirmation from some
A> gurus here of the exact extent of damage that a hacker can do
A> via an unsecured script.

If the script has a vulnerability that the hacker can exploit in order
to execute arbitrary code, the damage the hacker can do is unlimited.

A> At the time, ALL server services went down at once; POP, HTTP,
A> FTP, SMTP.

A> I do not believe that a hacker would have the ability to bring
A> down an entire server's services even if a script was
A> unsecured. At MOST all they would be able to do would be to
A> upload their own script and interfere with the files visible to
A> them through the http:80 service.

Right. And then they use that level of access to gain more
privileges, eventually scaling right up to full root access. The
script gives them the way in.

A> Please advise on the extent of damage that someone can cause
A> via unsecured scripts?

A> a. Can they bring down an entire server and it's services?

Yes, eventually.

A> b. Are they only able to modify files from which the scripts
A> have a visible scope, in this case, the http server.

At first, yes. But they can use those modifications to get themselves
other privileges.

Charlton

 

[Alison]

It might be possible that vunerability in Fedora can be exploited via a
script, but I have more the feeling that your hosting provider is clueless
and wants to blame it on your script. Wouldn't be the first time.

Hi John,

Yes of course, this is the script;

<START>
#!/usr/bin/perl -i

use CGI;

$query = new CGI;

$query->import_names('R');

#The Main Paths and Filenames
$targetdir = "logs";
$countname = "counter.txt";
$logname = "logs.csv";

#Setup Of Variables Used
$ip = $ENV{'REMOTE_ADDR'};
$refer = $R::referrer;
$currenturl = $R::url;
$report = $R::report;

($second, $minute, $hour, $dayOfMonth, $month, $yearOffset, $dayOfWeek,
$dayOfYear, $daylightSavings) = localtime();
$year = 1900 + $yearOffset;$month++;
$pad = 2;$pad = "%.$pad"."d";
$hour = sprintf($pad, $hour);$minute = sprintf($pad, $minute);$second =
sprintf($pad, $second);$dayOfMonth = sprintf($pad, $dayOfMonth);$month =
sprintf($pad, $month);
$theTime = "$hour:$minute:$second,$dayOfMonth/$month/$year";

#Setup Dynamic File Path Variables
$logworkingpath = "$targetdir";
$yearworkingpath = "$logworkingpath/$year";
$monthworkingpath = "$yearworkingpath/$month";
$todayworkingpath = "$monthworkingpath/$dayOfMonth";

$yearcountpath = "$yearworkingpath/$countname";
$monthcountpath = "$monthworkingpath/$countname";
$todaycountpath = "$todayworkingpath/$countname";
$todaylogpath = "$todayworkingpath/$logname";

#Make Sure Our Logs Directory Exists, If Not Then Create It
mkdir "$logworkingpath", 0755 unless -d "$logworkingpath";
#Make Sure Our Year Directory Exists, If Not Then Create It
mkdir "$yearworkingpath", 0755 unless -d "$yearworkingpath";
#Make Sure Our Month Directory Exists, If Not Then Create It
mkdir "$monthworkingpath", 0755 unless -d "$monthworkingpath";
#Make Sure Our Daily Directory Exists, If Not Then Create It
mkdir "$todayworkingpath", 0755 unless -d "$todayworkingpath";

#Update Todays Counter
open (LOG, "$todaycountpath");
@file = <LOG>;
close(LOG);
$todaycount = $file[0];
$todaycount++;
open (LOG, ">$todaycountpath");
flock(LOG, 2);
print LOG "$todaycount\n";
flock(LOG, 8);
close(LOG);

#If The Log File Does Not Exist, Create It, and Prime It
if (-f $todaylogpath)
{
#This Stops The File Exceeding 1MByte, ie. an attack!
my $filesize = -s "$todaylogpath";
}
else
{
open (LOG, ">>$todaylogpath");
flock (LOG, 2); # file lock set
print LOG "Hit,Time,Date,URL,IP,Referrer";
print LOG "\n";
flock(LOG, 8); # file lock unset
close (LOG);
}

#Update Todays Log File
if (filesize <= 1048576)
{
open (LOG, ">>$todaylogpath");
flock (LOG, 2); # file lock set
print LOG "$todaycount,";
print LOG "$theTime,";
print LOG "$currenturl,";
print LOG "$ip,";
print LOG "$refer";
print LOG "\n";
flock(LOG, 8); # file lock unset
close(LOG);
}

#Update This Months Counter
open (LOG, "$monthcountpath");
@file = <LOG>;
close(LOG);
$monthcount = $file[0];
$monthcount++;
open (LOG, ">$monthcountpath");
flock(LOG, 2);
print LOG "$monthcount\n";
flock(LOG, 8);
close(LOG);

#Print Out Variables For Diagnostics
print "Content-type: text/html\n\n";

if ($report == 1)
{
print "monthcount = $monthcount<br>";
print "todaycount = $todaycount<br>";
print "logworkingpath = $logworkingpath<br>";
print "yearcountpath = $yearcountpath<br>";
print "monthcountpath = $monthcountpath<br>";
print "todaycountpath = $todaycountpath<br>";
print "todaylogpath = $todaylogpath<br>";

print "todayworkingpath = $todayworkingpath<br>";
print "monthworkingpath = $monthworkingpath<br>";
print "yearworkingpath = $yearworkingpath<br>";

print "todaycount = $todaycount<br>";
print "$theTime,";
print "$currenturl,";
print "$ip,";
print "$refer";
}


EOF

<END>

 

[Alison]

Hi Charlton,

Thanks for your reply. As far as root access goes, full access is only
available locally to the server. I certainly don't have full root access.
I can SSH in as root yet do not have access to even the weblogs on http
configuration.

Generally, the only administrative access I use to the site is ftp. And I
was logged in right there and then. The whole lot just 'went'.

Refer to script replied to John.

Thanks kindly,

Alison

 

[Charlton Wilbur]

A> Thanks for your reply. As far as root access goes, full access
A> is only available locally to the server.

As a general rule, anyone who has shell access to the box can acquire
root access. Someone who can exploit flaws in a Perl script to get
access to the machine can exploit flaws in other things to get root
access.

A> I certainly don't have full root access. I can SSH in as root
A> yet do not have access to even the weblogs on http
A> configuration. Generally, the only administrative access I use
A> to the site is ftp.

You aren't breaking into the system for malicious purposes.

A> Refer to script replied to John.

Er, why? I believe your question has been asked and answered.

Charlton

 

[Alison]

Er, why? I believe your question has been asked and answered.

Charlton

I was trying to be helpful laying myself bare for the world to see.

Update: O/S is to be reinstalled by host, backups restored, all scripts
disabled.

My future plans are to have someone (a unix security person with whom I used
to wind non technical people up at work, Directors and alike) put together a
hugely cut down version of Linux and go dedicated on a 1U box.

I really do hate computers. Everything was fine with Multiplan, Chart and
Wordstar, the output all looked the same.

 

[John Bokma]

A> Thanks for your reply. As far as root access goes, full access
A> is only available locally to the server.

As a general rule, anyone who has shell access to the box can acquire
root access. Someone who can exploit flaws in a Perl script to get
access to the machine can exploit flaws in other things to get root
access.

Question is, does the script of Alison fall into this category? I think
it's way more probable that the hosting provider just spew some bullshit.

Also, since this is virtual hosted, it's very doubtful they got to the
actual root level and harmed the entire server. If they got into the
virtual server I would say, reinstall the whole thing (probably one
command and pressing enter) and let the customer reinstall his/her site.

Alison's story smells of incompetence at the hosting provider level wether
his script is to blame or not.

 

[Alison]

Hi John,

The host has come back to me when I requested the logs for 1-hour leading up
to when it went down.

They replied that the entire server is totally blank with it being likely
that the malicious would have simply issued a...

"just did "rm -rf /" means delete everything."

I've calmed down a bit but I'm still suspicious that I'm being spun. Also
they gained access through port 80 I'm told (http).

The outcome being that I'm going to totally lock the site down when it comes
back up and look for a new host then get the DNS entries repointed. There's
only one guy at this company who I've had any real communication with and I
think he's genuine, I like him, he's in sales and I think the sysadmins are
lying to him. We used to do precisely that to Sales when I worked for an
ISP, tell them whatever techno-babble to get rid.

There's either a gaping great hole in the latest release of Fedora that
everyone else missed or my script has done it. It wasn't as if it had 777'
rights and even if it did, I can't see how it would affect the whole server.
O/S services work as seperate entities precisely for these reasons. Or I
think.... It's how I would design one.

Alison

 

[Charlton Wilbur]

JB> Question is, does the script of Alison fall into this
JB> category? I think it's way more probable that the hosting
JB> provider just spew some bullshit.

Depends on the hosting provider. Everything that Alison reports the
provider to have said is plausible; how likely it is depends on a
whole lot of facts not in evidence.

JB> Also, since this is virtual hosted, it's very doubtful they
JB> got to the actual root level and harmed the entire server. If
JB> they got into the virtual server I would say, reinstall the
JB> whole thing (probably one command and pressing enter) and let
JB> the customer reinstall his/her site.

Depends on how the virtual hosts are set up. Again, evaluating it
further depends on facts not in evidence.

Charlton

 

[Alison]

<SNIP>

Depends on how the virtual hosts are set up. Again, evaluating it
further depends on facts not in evidence.

Charlton

Hi Charlton,

Unfortunately I don't have those. The servers are configured via Plesk,
which is some sort of GUI thing for setting up a unix box. And as far as I
know that's all they use throughout their servers. The specialist core unix
skills, ie. geek with terrible communication skills, I don't believe is
employed by them. They're Microsoft qualified engineers supporting unix
boxes.

I've never spoken to their admins as they've never responded to my mails or
queries. That I find slightly worrying as well as elitist and rude.

All things aside, I just have to wait for the next 24-hours to have the 2GB
site restored from backup (should take 30 minutes...)

Alison

 

[Randal L. Schwartz]

Alison> open (LOG, "$todaycountpath");
Alison> @file = <LOG>;
Alison> close(LOG);
Alison> $todaycount = $file[0];
Alison> $todaycount++;
Alison> open (LOG, ">$todaycountpath");
Alison> flock(LOG, 2);
Alison> print LOG "$todaycount\n";
Alison> flock(LOG, 8);
Alison> close(LOG);

How many mistakes can I see in that chunk of code?
{sigh}

- open without error status check
- broken for multiple updates (in spite of presence of flock)
-- reads the data without obtaining a read lock
-- zeroes the file without obtaining a write lock (!)
-- uses flock 8, which is pretty pointless, and sometimes harmful
- doesn't use File::CounterFile, which would have done all this correctly

I *didn't* see any other relative exploits, but *this* caught my eye

Alison> I was logged in via ftp at the very moment it went down as I was
Alison> transferring my Jan 1st update.

*FTP*? *FTP*? What is this, 1995?

How do you know a bad guy didn't sniff your password in cleartext? All
they had to do is own a machine near yours and run a password sniffer.

Any hosting service that provides FTP as their upload means should be closed
down. You can use that to determine if they have the clues or not.

Also, don't use "NOSPAM.com" as your domain name, unless you happen
to be the person listed here:

% whois nospam.com
[...]

Domain name: NOSPAM.COM

Administrative Contact:
administration, domain (e-mail address removed)
P.O. Box 309 ,Ugland House
George Town, Grand Cayman
KY
212-937-2077 Fax: 212-937-2077

Technical Contact:
administration, domain (e-mail address removed)
P.O. Box 309 ,Ugland House
George Town, Grand Cayman
KY
212-937-2077 Fax: 212-937-2077
[...]

If that's not YOU, then YOU need to stop being a bad netizen.

print "Just another Perl hacker,"; # the original

 

[Dean G.]

Hi John,

The host has come back to me when I requested the logs for 1-hour leading up
to when it went down.

They replied that the entire server is totally blank with it being likely
that the malicious would have simply issued a...

"just did "rm -rf /" means delete everything."

I've calmed down a bit but I'm still suspicious that I'm being spun. Also
they gained access through port 80 I'm told (http).

If they tell you they have no logs at all, but that they know it
occured via port 80, then they are liars. Simply put, they either have
the logs and can see the port 80 activity that caused the problem
(access on port 80 alone means nothing) in which case they are lying
about not having the logs, or they are lying about the port 80
"attack".

Dean G.

 

[Alison]

*FTP*? *FTP*? What is this, 1995?

How do you know a bad guy didn't sniff your password in cleartext? All
they had to do is own a machine near yours and run a password sniffer.

Any hosting service that provides FTP as their upload means should be closed
down. You can use that to determine if they have the clues or not.

How else would you suggest I upload 50MB weekly updates of adult pornography
to my site?

 

[Eric Schwartz]

How else would you suggest I upload 50MB weekly updates of adult pornography
to my site?

SFTP, scp, HTTPS, just to name three off the top of my head.

-=Eric

 

[Alison]

Umm, the same way one of my clients handles their several hundred
megabytes a DAY ... rsync. Don't like rsync, use scp. Like the FTP
user interface, use sftp.

You are clearly clue retardant. *plonk*

**** off you prick. No wonder you're single.

 

[Tad McClellan]

**** off you prick.

He told you how to avoid the problem you came here asking for help with,
so what is with the potty mouth?

And you _are_ clearly lacking in clue (we've seen your code).

Don't get mad about it, just resolve to acquire clue.

 

[brian d foy]

Hi Charlton,

Thanks for your reply. As far as root access goes, full access is only
available locally to the server.

The only secure computer is the one that's turned off, unplugged,
encased in concrete, and dropped into the ocean. Even then, I wouldn't
be surprised to see a CERT advisory.

There's no such thing as "only".

 

[Ian Wilson]

If they tell you they have no logs at all, but that they know it
occured via port 80, then they are liars.

It's possible that Alison requested webserver logs, which have gone, but
the ISP has firewall logs from a separate firewall appliance.

However, in Alison's shoes, I'd move to another hosting service.

 

[Mirco Wahab]

SFTP, scp, HTTPS, just to name three off the top of my head.

rsync over ssh


Regards

M.