Re: Problems with the scripts by Solution Scripts

["Veins" <veins () skreel org>]

renamming a file so its name starts with .ht (dot ht)
will prevent the downloading of the file and will also
make your error_log smaller than if it has to record
every 500 error...


----- Original Message -----
From: "b0iler _" <b0iler () hotmail com>
To: <vuln-dev () securityfocus com>
Sent: Wednesday, February 06, 2002 4:27 AM
Subject: Problems with the scripts by Solution Scripts


> #!/possible/exploits/by/b0iler
> #
> #scripts from: http://solutionscripts.com
> #
> #don't take anything I say too seriously in this, as it is mostly guess
> work.
>
> Problems with the scripts by Solution Scripts
>
> solution script's powerlist script:
>
> It seems the author doesn't check for anything when removing user's
emails.
> So someone (you) could code a simple script to get all the addresses from
> address.txt and remove them from the list. This would completely delete
the
> mailing list database.  Many mailing list scripts have this bug.
>
> Fix: add this to .htaccess:
> <Files "address.txt">
> order deny,allow
> deny from all
>
> or rename address.txt to something that will be interpreted by perl, such
as
> address.cgi.  This will create an error 500 when trying to be retreived
via
> http.
>
>
>
> the topsites list:
>
> The script lacks input checking when user's sign up for an account. It
does
> not check for the character which seporates the database fields:
>
> $newline = join
("\|",0,0,0,$fields{'url'},$fields{'banner'},$fields{'name'},$fields{'email'
},0,0,$new_id);
> $newline .= "\n";
>
> open(DB, ">>members.db") || &error(2);
> if ($use_flock) {
> flock DB, 2;
> }
> print DB $newline;
> close (DB);
>
> Nowhere does it check to see if your $fields{'url'} contains a newline
> character or |.  $fields{'url'} is inputted by the user at signup. Also
this
> script does not check the referrer.  Just adds to the easy of
exploitation.
> Exploit: sign up with a name which contains |'s and newlines to create
false
> entries in the database.
>
> Fix: filter meta characters:
>
> ($fields{'url'}, $fields{'banner'}, $fields{'name'}, $fields{'email'}) =~
> s/([\&;\`'\\\|"*?~<>^\(\)\[\]\{\}\$\n\r])/\\$1/g;
>
>
>
>
> alias-mail script:
>
> I can't believe I forgot all about this.. let me explain.  Along time ago
I
> played a game and I was on the last level and got bored, so I started
> playing with the scripts on the server.  I found a problem in the mail
> script they ran and I tried to exploit it to gain access to one of the
> admins of the site's account.  It worked, I got the password.. but he
> changed his password after he noticed that I tricked him.  I totally
forgot
> about this until the other day when I was looking through an old backup cd
I
> had and saw the html page I used to trick him.  I'm sure none of you care
> about that crap, so let me get to the exploit.
>
> The problem is in alias-mail and it's lack of filtering javascript. This
> means cross site scriptting on a web-based mail script.. oh no trouble.
You
> can** send mail, delete mail, change password , and other goodies like
that.
>   Again, since this script costs money I don't have access to it's source
to
> find out more about this vuln. I only used it once over a year ago. All I
> did was redirect the user to a page that looked like the login page and
once
> they submitted their login:password I recorded it with a cgi script to a
> text file.
>
> **probably, I cannot test this since it costs money
>
> Ok, problem is: It filters <script type="javascript"> but not <s&#67ript
> type="java&#67;cript"> since it checks for the string "script" and the
mail
> cgi prints out html. (btw: javasCript found by Georgi Guninski a few years
> ago - I just tested it with this).
>
> These settings (filtering and html) might not be on by default, but they
> both worked when I did this at that game site wich ran the script. I doubt
> they changed the defaults much.  I also believe you could put javascript
in
> the subject.. so it would be executed from their inbox, not just if they
> viewed the email.
>
>
>
>
> while using the demo at solutionscript's site for alias-mail I found a
cross
> site scriptting vuln for their 404-manager:
>
> This is another simple cross site scriptting vulnerability in a
> solutionscript's script. This time it's the 404 Manager script. Very
simple
> to do, just go to any url like this:
>
> www.site-with-404-manager.com/<script
> type="text/javascript">alert('vulnerable to cross site
> scriptting');</script>
>
> This is what you will see:
>
> The file you requested:
> /warehouse/(this is where the script will be placed, totally unfiltered)
> was not found on this server.
>
> Not really an issue at all.. but as long as I am posting I thought I might
> throw this in.
>
>
>
>
> A *possible* vulnerability in the Homelands script:
>
> This was the orignal advisory by kombat:
> http://g0tr00t.fuckmicrosoft.com/releases/ReDeeMeR/homelands.txt
>
> Again, I do not have the source to this script.. so this is pretty much
> guess work (that's why this is going to vuln-dev - maybe someone can try
it
> or give me the source [I won't use the script, just audit the code] ).  I
> figure since the script is not checking for | it probably doesn't check
for
> newlines ether.  In that case depending on how the script checks user
logins
> you could effectively take over another user's account.  If you create a
new
> account with the following username:
>
> |(email address)|(name)|(password)|2.581|997823993|997824103||on|(site
> name)|(site
> description)||||||||||||||||||||||,,,|||||||(cookie)|0|1|||||||||||||(last
> logon IP)|(account name)\n|(email
> address)|(name)|(password)|2.581|997823993|997824103||on|(site name)|(site
> description)||||||||||||||||||||||,,,|||||||(cookie)|0|1|||||||||||||(last
> logon IP)|(existing name)
>
> where \n is a newline and existing_name is the name of user who's account
> you would gain access to.
>
> This would work if the login subroutine is like this (this is guess work):
>
> open(DB, "<db");
> @db=<DB>;
> close(DB);
>
> foreach(@db){
>    ($name, $email, $password, undef, undef, undef, undef (etc..) ,undef,
> $account_name) = split(/\|/, $_);
>    if($input{'loginname'} eq $account_name && $input{'password'} eq
> $password){ &loginok($account_name); }
> }
>
> or any other method where it doesn't stop after the first time it sees the
> account name (also depending on how the database is set up and the check
> routine it could work even if it does stop after the first sight of the
> account_nam), then it is possible to take over total control of someone's
> site.  Simply edit the db so that you do a newline and fill in the fields
> and put the account name the same as whoever's you want to take control
> over.  Then login with that username and the value you put in the password
> field. I am sorry I cannot confirm all of these possible vulnerabilities..
> But hopefully someone on vuln-dev can clear things up.  Vendor has not
been
> contacted.
>
> -http://b0iler.advknowledge.net
>
>
> _________________________________________________________________
> Join the world's largest e-mail service with MSN Hotmail.
> http://www.hotmail.com