Re: PC Week: Attacked and hacked!
On Wed, 13 Oct 1999, Ruben I Safir wrote:
> Matt -
>
> I share your sentiments but I would like to point out a few things about
> the use of CGI.pm and Embperl and/or Modperl which which would be
> different then if I was writing the uudecoding by my self.
>
> Normally, I would parse out metachars in the processes of decoding input
> from the browser. When I use embperl, (and CGI.pm by default),
> everything is in a nice HASH for me. What's to stop someone from
> entering metachars of {}, or other perl code into a field and have it
> processed by embperl?
What's unsafe about this per-se? Only if you use that data in an unsafe way
without first doing a check on that data is it truly unsafe. There's
nothing different about this to a C CGI app that doesn't check a parameter
that writes to a file doesn't contain #!/bin/sh or a filename doesn't
contain "..".
> My own decoding routines only let in what I deem safe. CGI.pm is doing
> this for me.
There's no difference that I can see in doing your own decoding and
checking and letting CGI.pm do the decoding and then you do your own
checking. Either way you have to do your own checking.
--
Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.
Re: PC Week: Attacked and hacked!
Matt -
I share your sentiments but I would like to point out a few things about
the use of CGI.pm and Embperl and/or Modperl which which would be
different then if I was writing the uudecoding by my self.
Normally, I would parse out metachars in the processes of decoding input
from the browser. When I use embperl, (and CGI.pm by default),
everything is in a nice HASH for me. What's to stop someone from
entering metachars of {}, or other perl code into a field and have it
processed by embperl?
My own decoding routines only let in what I deem safe. CGI.pm is doing
this for me.
It the data input being scrubbed or checked?
Ruben
Matt Sergeant wrote:
>
> On Tue, 12 Oct 1999, Ruben I Safir wrote:
> > Dear Boss
> >
> > Thanks for pointing this article from PC Week out.
> >
> > I've already read and reviewed this, and discussed it with the hacker
> > after it was anounced 3 weeks ago on http://slashdot.org.
> > The hacker attacked a shrink wrapped CGI application with a documneted
> > hackers weakness that has been passed around the net.
> >
> >
> >
> > See: http://slashdot.org/articles/99/09/24/1224221.shtml
> >
> >
> >
> >
> > Note this discussion below which has been reviewed. Please review it as
> > well so tha everyone is fully versed in the details of network security.
> >
> > I'm wondering if anyone else has comments on this. How secure is CGI.pm
> > and EMBPERL?
>
> All CGI scripts, no matter what language they are written in, can be
> insecure. There's no need to discuss this here - simply read the cert's CGI
> script security document. If you haven't read it and follow it's
> precautions (which the developers of the photoads script obviously didn't)
> then you shouldn't be developing secure web sites. There's really nothing
> further to discuss.
>
> --
>
>
> Details: FastNet Software Ltd - XML, Perl, Databases.
> Tagline: High Performance Web Solutions
> Web Sites: http://come.to/fastnet http://sergeant.org
> Available for Consultancy, Contracts and Training.
>
> -
> Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
> posting. To request this thread, e-mail [EMAIL PROTECTED]
>
> To unsubscribe, send a message to the address shown in the
> List-Unsubscribe header of this message. If you cannot see it,
> e-mail [EMAIL PROTECTED] instead.
Re: PC Week: Attacked and hacked!
> The original question, though, was whether embperl is *inherently* > less secure than some other strategies. Actually, the original question was: "How secure is CGI.pm and EMBPERL?" > I am no security expert, but some of the exploits that were tried > (unsuccessfully) by this cracker did in fact rely on whether > server-side includes and/or embedded Perl were active. Not quite. Precisely, the exploits relied on bugs in the CGI/mod_perl scripts to (try to) execute code. If the CGI/mod_perl script is secure, then SSI, ``, system(), eval(), and all the other ways to execute code are also secure. As far as CGI.pm and embperl are concerened, they are widely used products, and bugs in them would surely have been mentioned by now. If that's not sufficient for you, feel free to check the modules yourself. ELB -- Eric L. Brine | Chicken: The egg's way of making more eggs. [EMAIL PROTECTED] | Do you always hit the nail on the thumb? ICQ# 4629314 | An optimist thinks thorn bushes have roses.
RE: PC Week: Attacked and hacked!
> > The original question, though, was whether embperl is > *inherently* less secure > than some other strategies. As far as I see there is no specific security problem with Embperl. Embperl itself does not write any file (when not running offline), so it can't be abused to places files on your server. The only file Embperl writes, is the logfile and I can't see how anybody should place content in it, that should be useable by a cracker. The main problem is, if anybody has already write access to your server then he can place a file that is executed by Embperl and this file can do anything that the user the httpd runs as can do. That's true for CGI Scripts, Apache::Registry scripts, Mason, ASP, whatever scripting you use. The other possibility for an attacker would be to place an .htaccess file somewhere and thereby altering your configuration in an unwanted way. Gerald Important Note: Embperl before versions 1.2b10 has an security whole, when running as CGI, so anybody using Embperl in CGI mode, should upgrade to 1.2b10!! --- Gerald Richter ecos electronic communication services gmbh Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl E-Mail: [EMAIL PROTECTED] Tel:+49-6133/925151 WWW:http://www.ecos.de Fax:+49-6133/925152 ---
Re: PC Week: Attacked and hacked!
On Tue, 12 Oct 1999, Eric Strovink wrote: > Matt Sergeant wrote: > > > All CGI scripts, no matter what language they are written in, can be > > insecure. There's no need to discuss this here [snip] > > The original question, though, was whether embperl is *inherently* less secure > than some other strategies. I am no security expert, but some of the exploits > that were tried (unsuccessfully) by this cracker did in fact rely on whether > server-side includes and/or embedded Perl were active. Now, I am not saying > that directory permissions ought not to be correct and so on, but *supposing* > that there were some oversight in this area, *then* it seems to me the fact > that ssi or embperl was active *would* increase the chances of crackability. This cracker got write access to the web server via a poorly written CGI script though (searching for embperl or ssi was what he did after the fact to see if he could write to the right page), and then got further in via a bug on crond. The point is that any site is as secure as it's weakest point. If that weak point allows any kind of write access to the web server then having embperl or ssi or buggy cron's or any other way for your cracker to get further isn't going to make that much difference. Disclaimer: I'm no security expert - but I have worked on security paranoid web sites such as http://www.bbc.co.uk. -- Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: PC Week: Attacked and hacked!
Matt Sergeant wrote: > All CGI scripts, no matter what language they are written in, can be > insecure. There's no need to discuss this here [snip] The original question, though, was whether embperl is *inherently* less secure than some other strategies. I am no security expert, but some of the exploits that were tried (unsuccessfully) by this cracker did in fact rely on whether server-side includes and/or embedded Perl were active. Now, I am not saying that directory permissions ought not to be correct and so on, but *supposing* that there were some oversight in this area, *then* it seems to me the fact that ssi or embperl was active *would* increase the chances of crackability. So, a more complete answer to Ruben would address those concerns. Perhaps they are already addressed elsewhere, in which case I apologize for this post. I do not use embperl or ssi, so I disqualify myself from further comment.
Re: PC Week: Attacked and hacked!
On Tue, 12 Oct 1999, Ruben I Safir wrote: > Dear Boss > > Thanks for pointing this article from PC Week out. > > I've already read and reviewed this, and discussed it with the hacker > after it was anounced 3 weeks ago on http://slashdot.org. > The hacker attacked a shrink wrapped CGI application with a documneted > hackers weakness that has been passed around the net. > > > > See: http://slashdot.org/articles/99/09/24/1224221.shtml > > > > > Note this discussion below which has been reviewed. Please review it as > well so tha everyone is fully versed in the details of network security. > > I'm wondering if anyone else has comments on this. How secure is CGI.pm > and EMBPERL? All CGI scripts, no matter what language they are written in, can be insecure. There's no need to discuss this here - simply read the cert's CGI script security document. If you haven't read it and follow it's precautions (which the developers of the photoads script obviously didn't) then you shouldn't be developing secure web sites. There's really nothing further to discuss. -- Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: PC Week: Attacked and hacked!
Dear Boss
Thanks for pointing this article from PC Week out.
I've already read and reviewed this, and discussed it with the hacker
after it was anounced 3 weeks ago on http://slashdot.org.
The hacker attacked a shrink wrapped CGI application with a documneted
hackers weakness that has been passed around the net.
See: http://slashdot.org/articles/99/09/24/1224221.shtml
Note this discussion below which has been reviewed. Please review it as
well so tha everyone is fully versed in the details of network security.
I'm wondering if anyone else has comments on this. How secure is CGI.pm
and EMBPERL?
Ruben
PS - Note the follwing from slashdot.org. This is being sent out
broadly for increased discussion on the issue.
dated Sept 24Author: pankaj (10.0.0.1)
Date: 09-25-1999 00:16
Kudos to Jfs, here are the detail straight from the horses
mouth. We'll post them on the Linux site homepage later
First of all, I had to gather information on the remote
host, what ports the machine had open and what possibilities were
left open. After checking that most of the ports were either
filtered by the firewall or unusable due to the tcp
wrapper in the host, I decided that I was left only with the
HTTP server.
lemming:~# telnet securelinux.hackpcweek.com 80
Trying 208.184.64.170...
Connected to securelinux.hackpcweek.com.
Escape character is '^]'.
POST X HTTP/1.0
HTTP/1.1 400 Bad Request
Date: Fri, 24 Sep 1999 23:42:15 GMT
Server: Apache/1.3.6 (Unix) (Red Hat/Linux)
(...)
Connection closed by foreign host.
lemming:~#
So, it was running apache on a Red Hat box. The webpage said
that the server will also run mod_perl, but mod_perl leaves
a fingerprint in the Server: header which was not shown in
the header that this server sent out.
Apache 1.3.6 doesn't ship with any CGI programs available to
the remote user, but I didn't know about the RH distro, so I
gave the common faulty CGIs a try (test-cgi, wwwboard,
Count.cgi...)
After no results, I tried to find out what the website
structure was, gathering information from the HTML pages, I found
out that the server had this directories under the
DocumentRoot of the website:
/
/cgi-bin
/photoads/
/photoads/cgi-bin
So I got interested in the photoads thingie, which seemed
like an installable package to me. After some searching on the
WWW I found out that photoads was a commercial CGI package
from "The Home Office Online"
(http://www.hoffice.com). It sells for $149, and they grant
you access to the source code (Perl), so that you can check
and modify it.
I asked a friend if he would let me gave a look at his
photoad installation
and this is how I got access to a copy of what could be
running in the securelinux machine.
I checked the default installation files and I was able to
retrieve the ads database (stored in the
http://securelinux.hackpcweek.com/photoads/ads_data.pl) with
all the user passwords for their ads. I also tried to access
the configuration file /photoads/cgi-bin/photo_cfg.pl but
because of the server setup I couldn't get it.
I got the /photoads/cgi-bin/env.cgi script (similar to
test-cgi) to give me details of the server such as the location in
the filesystem of the
DocumentRoot (/home/httpd/html) apart from other interesting
data (user the
server runs as, in this case nobody).
So, first things first, I was trying to exploit either SSI
(Server side includes) or the mod_perl HTML-embedded commands,
which look something like:
for SSI
for mod_perl
The scripts filtered thsi input on most of the fields,
through a perl regexp that didn't leave you with much room to
exploit. But I also found a user assigned variable that
wasn't checked for strange values before making it into the HTML
code, which will let me embed the commands inside the HTML
for server side parsing:
In post.cgi, line 36:
print "you are trying to post an AD from another URL:
$ENV{'HTTP_REFERER'}n";
The $ENV{'HTTP_REFERER'} is a user provided variable (though
you have to know a bit of how HTTP headers work in order to
get it right), which will allow us to embed any HTML into
the code, regardless of what the data looks like.
Refer to the files getit.ssi and getit.mod_perl for the
actual exploit.
To exploit it, do something like:
lemming:~# cat getit.ssi | nc securelinux.hackpcweek.com 80
