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 _" <b0ilerat_private> To: <vuln-devat_private> 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 <sCript > type="javaCcript"> 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 >
This archive was generated by hypermail 2b30 : Tue Feb 05 2002 - 21:30:05 PST