[kaipowerat_private] Fri, Apr 05, 2002 at 09:04:33AM +0800 wrote: hello, I am no expert but here goes, There are tons of papers written about the methodogy of finding bugs/vulnerabilties, but unless you have lots of free time or work in penitration testing / security field it can sometimes be tough to devote a lot of time understanding and finding holes. The best thing i have come to understand is just that knowing how the software or O/S works, you better understand what can and cannot ( i use that loosly ) or should not be done when running a particular peice of software. When something unexpexted happens ask yourself, why did that happen ? can i reproduce this ? is this a known problem ? configuration problem ? etc.. understanding what goes on behind the scences gives you a better insight of why such and such program did what it did when that "unexpected" thing happened. If you can't come to a resolution from the vendors , peers, etc..You can then go about digging into the possiblility of getting the program to do something that was not intended by its authors. This pretty much covers ANY piece of software. It turns into the questions "Can i make the program do ... ?" some programs will get you elevated access, some will not, either case the goal is to make the program do something it was not intended to do. the ultimate question is "Can i obtain a level of unauthorized access using this bug ?" At least this how i go about looking at it. > 4) Unexpected input - e.g. SQL injection? I'll just add a little bit for this one, but as i said this carries over to any bug/vuln in any program or o/s. Not really sure how i was going to respond since others have pretty much hit the nail on the head, so i'll just give an example of something i did a while back, and some of the steps i took to reach the goal i was looking for. I am mostly going from memory so, well, here goes. ;-) I wanted to better understand input validation/SQL injection, ( though this example deals with a web application, any program that uses a database is supceptible to SQL injection type attacks if not coded with proper security in mind ) so i searched the net for some free database driven software and came accross a small fairly simple PHP based mesg board "tForum version b0.915". I contacted a freind had him set me up with MySQL, and some webspace required for the installation. I read the readme installed the software and i was good to go. Now what was i going to do. the first thing i did was grab some info about PHP programming and some MySQL started playing with the database and writing some small PHP programs etc. since i knew sqat about either, then started looking through the code. for the most part, the code syntax itself it didn't make much sence to me but i have some programming skills in C & shell scripting so i could pretty much figure out the flow of the program. I then started playing with the program adding users, differen't access levels, messages etc.. and at the same time watched the databse, web, as well as setting up a sniffer on my client machine to watch the web traffic. once i understood what the program was doing as i did different things i then started seeing if i could "break" the program. try to get it to do something it was not supposed to do. I did some more reasearch on different types of web based "input validation" attacks on PHP and read some "secure PHP programing" docs. This gave me some insight as to some of what PHP would or should allow for input if coded right. I started looking through the sorce code for any santity/bounds checks on different variables entered in the URL while watching the logs looking for something "unexpected" If i saw something i thought was off, i would check into it further, reading more PHP and SQL docs, etc.. For example i found that i could reveal the installation path of the program that later truns out to be a configureation problem, i would then fix any known problems and move on Taking note of anything out of the ordinary. once i got to a point where i thought i have found a problem/bug i then concentrated my efforts on that particular script/bug. In this case it happend to be a file called "upgrade.php" Entering the URL like http://server/path/upgrade.php?query[]=bla would return and error. I wish i had the error as i am going by memory, but it was i belive a error returned by the SQL database. so i started working on seeing if i could use this script to get the database to execute a command. in this case "update t_users set Password=newpass where ID=1" wich in this case ID 1 was the admin user. this file did not do any input validation what so ever and was used to upgrade the database taken from the README: [....] UPGRADE INSTRUCTIONS - IMPORTANT FOR WEBMASTERS UPGRADING... This is for upgrading from 0.91p3 to 0.915 ONLY! Overwrite the old files with the new ones. Your settings should not be changed. Remember to change the line: include("changeme.php"). Then run upgrade.php from your browser to update the database. [.....] by default this file is in the same dir as all the other files, no where in the readme does it say move,remove,rename this file, so i thought "well i didn't move/rename the file chnaces are i wasn't the only one", so i concentrated on this file. This really, i woun't consider a major problem but more of a default configuration problem. anyway. what i have now is 1: A default database config 2: no mention in the readme about a pontental problem with the file "upgrade.php" 3: "upgrade.php" does not check input. 4: from installation of the database i know that ID 1 is the admin 5: i know that issueing the command "update t_users set Password=newpass where ID=1" will change the tforum admin's password with proper access to the database. After triing differnt URLs attempting to enter SQL commands, triing esacpe charaters, etc, i ended up with a URL in the form of http://server/path/upgrade.php?query[]=update%20t_users%20set%20Password=blala%20where%20id=1 would in fact issue a command to the database "%20" HEX code for a "space" however, ( triing to pull from memory ) the part "Password=blala" the "blala" was filtered by PHP, giving it a ' or " i forget. anyway, so i tried using numbers to see if it would be accepted by PHP, So now my URL looked like this http://server/path/upgrade.php?query[]=update%20t_users%20set%20Password=222222%20where%20id=1 and , what do ya know joe, the tfourm admin password was reset to "222222". i then thought to myself "ok, thats not good, i wonder if i went to google..." i think most know where i am going with that ;-). anyway. Like i said this particular problem i feel is more of a config problem, and the tfourm version i was playing with i belive was in beta at the time. But at any rate. I hope this gives at least a little insight of the steps of finding a bug/hole/vuln etc.. I realize this is a little long and my spelling sucks, but i always as most, learn by doing. Mabee i need a class in writing , heh but at any rate. what i have done here was nothing new. just a basic input validation problem on the script itself if you look at the code of "upgrade.php" you'll see why, all it does is connect to the database and issues commads using an empty $query[] ( array? ) var. nothing more, all i did was change the first instance of query[] to something else, and it issued the rest on its own. I spent a lot of time playing with tfourm and learned a little bit of PHP and SQL in the proccess giving me a better understanding of PHP / SQL security. granted the methods i used were nothing new and having the source code helped a lot but, when a new bug for PHP or Input validation, or SQL bug comes accross the wire i get a better understanding of how or where the problem is. ;-) I hope this helps a bit. Please no flames since this is my first REAL ( or lack there of ) post. -- - nocon ====================================== noconat_private http://nocon.darkflame.net ======================================
This archive was generated by hypermail 2b30 : Fri Apr 05 2002 - 20:33:12 PST