[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 261
  • Last Modified:

Perl and Security Issues

Hello everybody,

I am running a website (www.vehicleaid.com) and was recently contacted by the host saying that "your account has been comprimised and foreign files uploaded which were causing a high server load and attacking other website/s. We need the issue to be resolved and the hole closed in your website."

I was graciously wondering if someone could look through a couple of my files (their really short for perl) and see if you can see any security flaws, and what to do to fix it.

They can be found in plain text here:
http://www.vehicleaid.com/testing/askthread.txt
http://www.vehicleaid.com/testing/login.txt
http://www.vehicleaid.com/testing/index.txt
http://www.vehicleaid.com/testing/search.txt

P.S. There is a couple other files if nothing is found there.

Thankyou for any future help,
-Stephen
0
stjowa
Asked:
stjowa
  • 13
  • 10
  • 5
  • +1
2 Solutions
 
kanduraCommented:
A cursory look doesn't show any way to upload files. Maybe if you'd provide links to the libraries, I could tell more. You _are_ very vulnerable to sql injection attacks, I can tell that much already.

There is a lot more room for improvement, but I don't feel like depressing you too much all at once. Please realise that any criticism from me is meant to be constructive; I'm quite willing to help you out.
0
 
kanduraCommented:
stjowa,
> your account has been comprimised

Did they give you any more details on how your account was compromised? Do you know your scripts got hacked, or have they cracked your account's password?
0
 
stjowaAuthor Commented:
What libraries? (haha now you can tell im vulnerable :)) Are you talking about the require files?

Thanks for helping me out,
-Stephen

P.S. Don't worry, I take criticism really well... especially it is for my benefit... so be honest even if it hurts
0
Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

 
kanduraCommented:
By the way, I would be proactive if I were in your shoes. Disable _all_ your scripts, and delete them from the server. You cannot trust _any_ code that's on there anymore. Consider your database contaminated as well. Change all your logins and passwords. And communicate this to your ISP, so they know you're taking this serious.
0
 
kanduraCommented:
stjowa,
> Are you talking about the require files?
0
 
kanduraCommented:
argh. sorry, my browser is having fits.

Yes, I was refering to the require'd files. I expect most of the dirty work to be done in there.
0
 
stjowaAuthor Commented:
0
 
stjowaAuthor Commented:
and they did not give me any details on how they were hacked, just notified me of it... in fact i know that they don't know how they were hacked
0
 
kanduraCommented:
I'd also like to note that I'm not a security expert professionally, but I do build large web applications for a living. I have quite a bit of experience in this field; nevertheless I urge you to try to get opinions from other people as well. I'm sure I'll miss things that others might spot.

ExpertsExchange is a pretty good place to ask for code review, but there are many more sites I could recommend. At the very least I recommend you post a small pointer in the Perl Topic Area; it's more active than the CGI section, and the regulars there are quite knowledgeable. I think we can use their help :)
0
 
kanduraCommented:
You'd better replace all passwords in those two files with XXXX asap. Don't want this to become public.
0
 
stjowaAuthor Commented:
i don't have enough points (dad gum it EE is not free)
0
 
kanduraCommented:
Posed a link there myself.
0
 
stjowaAuthor Commented:
ok, i did the following since the host announced i was being compromised:
add the -t paramater to all the perl pages
added a line in the form parser that accepts input data to strip all tags from the form input (that includes script and applet commands)

i was just wandering if there was anything else needing to be done... like you mentioned SQL injection... i've heard of it, but dont know what it is
0
 
kanduraCommented:
stjowa,
> like you mentioned SQL injection... i've heard of it, but dont know what it is

Short definition: the injection of arbitrary sql code from outside your program.

An example is this line:

    $CUserName = $dbh->selectrow_array("SELECT uname FROM $table_members WHERE uname='$CUserName'");

Where you use the $CUsername directly in the sql statement.
If a malicious user were to log in with a clever loginname, they could put any sql in there. For instance, such that the $CUsername would contain something like "%'; delete from discuss_members; select '".
This would completely wipe out your member table.

The simplest way to guard against this is by using placholders and bind values. I would rewrite your line as follows:

    $CUserName = $dbh->selectrow_array("SELECT uname FROM $table_members WHERE uname=?", undef, $CUserName);

The questionmark will be filled in with the $CUserName value, but properly quoted and escaped. (The undef is there because DBI uses the second parameter for attributes; check the manual for details).

Other things you need to do are the way you do the form parsing (use CGI instead), and some general improvements to the code, but we'll get to those in due time.

Another thing you should do now rather than later is remove the line "use CGI::Carp qw(fatalsToBrowser);". While that is a great aid in developing the scripts, it leaks far too much information to the visitor when errors do occur. You would be better off with the carpout and set_message functions of CGI::Carp.
0
 
stjowaAuthor Commented:
wow, im pretty ignorant at this stuff. However, you are really smart...

kandura
> This would completely wipe out your member table.

hehe, I'll go ahead and remove my scripts for the time being

thanks for the help so far... it is greatly appreciated
0
 
manav_mathurCommented:
Apart from what Kandura has mentioned here,
Do ask your website host to check whether the Perl distribution is unharmed. 'Compromised' is a very vague term to define what actually happened. If the attacker (or whatever) got actual access to the system, he/she might have modified your system/Perl binaries.

Wonder why they havent brought the system off-network. Least to say, your hosting ppl should have given you a complete description of what they found out. For a compromised system, primary point of focus should be the system binaries instead of the applications.

If it has been a CGI exploit, yes there's a problem with your script. If your account has been compromised, that has entirely different connotations.



0
 
ahoffmannCommented:
> $CUserName = $dbh->selectrow_array("SELECT uname FROM $table_members WHERE uname='$CUserName'");
> $cpoints = $dbh->selectrow_array("SELECT cpoints FROM $table_members_stats WHERE uname='$FORM{user_name}'");
> $level = $dbh->selectrow_array("SELECT level FROM $table_members WHERE uname='$FORM{user_name}'");
> .. and much more ..
are vulnerable to SQL injection, use a prepare() and execute() like in your other examples

> sub parse_cgi ...
does not filter incomming data proper, possible threats are:
  SQL injection
  command injection
  cross-site scripting
  HTML injection
'caue you use a white list for filtering (script, applet, etc.)
0
 
stjowaAuthor Commented:
ahoffman,

You said that I should use prepare() and execute() instead of what I already had... what about using the following like kandura said:
$CUserName = $dbh->selectrow_array("SELECT uname FROM $table_members WHERE uname=?", undef, $CUserName);

Is this just as secure as prepare and execute?
And also does using the CGI->param('input') under the standard library parse input properly? Or should I customize my own function?

Thanks again!
0
 
stjowaAuthor Commented:
Ok as a reply to manav_mauther's post, here is what the host said:
"Our binaries haven't been comprimised. Your site was (i.e. account), and a file uploaded to /tmp again. You need to check your scripts for any injection type exploit or a way that a remote user could upload a file using your scripts.."
0
 
kanduraCommented:
stjowa,
> You said that I should use prepare() and execute() instead of what I
> already had... what about using the following like kandura said:
> $CUserName = $dbh->selectrow_array("SELECT uname FROM $table_members
> WHERE uname=?", undef, $CUserName);

> Is this just as secure as prepare and execute?

Yes, you can safely use selectrow_array, as long as you are using placeholders. the selectrow_array is a shortcut method that does the prepare and execute for you, so it's basically equivalent. Only less typing.

> And also does using the CGI->param('input') under the standard library
> parse input properly? Or should I customize my own function?

CGI is almost certainly safer. You can help yourself by doing just this:

    use CGI;
    my $cgi = new CGI;
    %FORM = $cgi->Vars;

0
 
ahoffmannCommented:
> .. $dbh->selectrow_array(..)
> .. Yes, you can safely use selectrow_array, as long as you are using placeholders ..
well, I didn't check DBI's implementation of selectrow_array() , but if your're not 101% shure that it uses prepare() and execute() then you do it better yourself.
I agree that "proper espaing/quoting" makes it secure, but that's the hard and eroor-prone way.
Why should I do that if there is a prepare() ;-)

> CGI is almost certainly safer.
no offence to anyone, but CGI is not safe at all according web application security!
it does not know about any filters, nor the threats (see http:#13823802), it's just a stupid/sophisticated/tranparent API to a web server's CGI
You have to code anything yourself!
Use perl's tainted mode (-T option) to make your scripts more secure, at least to see where perl itself can detect potential problems. But -T does not secure your SQL access, that still ave to be done yourself.
0
 
stjowaAuthor Commented:
So, what's the best secure form parsing code out there?
0
 
ahoffmannCommented:
there is no "best"
data validation depends on the usage of the data

for mySQL you probaly can do following for each variable used as data in your tables:

  $var=~s/'/''/g;
  $var="'".$var."'";
0
 
kanduraCommented:
ahoffmann,
> for mySQL you probaly can do following for each variable used as data in
> your tables:

>   $var=~s/'/''/g;
>   $var="'".$var."'";

why do you insist on doing that? Using placeholders is so much easier, and safer, and less error-prone! I'm trying my bit to rid the world of crappy insecure sql handling here! ;^)
0
 
ahoffmannCommented:
kandura: full ACK
but the questioner asked for that ;-)
0
 
kanduraCommented:
stjowa,
> So, what's the best secure form parsing code out there?

I can recommend CGI::Untaint (http://search.cpan.org/~tmtm/CGI-Untaint-1.25/lib/CGI/Untaint.pm).
0
 
ahoffmannCommented:
nice module, but now support for data validation like XSS, SQL injection, etc. :-/
0
 
kanduraCommented:
SQL injection is handled by consistently using placeholders, so that's no longer an issue.
XSS can be dealt with using the various handlers, by stripping out everything you don't need.
0
 
stjowaAuthor Commented:
Hey guys, I believe I fixed everything.

Used proper placeholders and proper form parsing...

Thanks for all the help!
0

Featured Post

Upgrade your Question Security!

Add Premium security features to your question to ensure its privacy or anonymity. Learn more about your ability to control Question Security today.

  • 13
  • 10
  • 5
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now