Printable View
homenet,
Well that helps some, at least now, I know more about the password file. Im going to have to look to find out how to access it.
I had thought that leaving yourself vulnerable to file reading would have meant there would have been a ways to compromise the system with realtive ease. I guess I am mistaken.
just thought i`d add that theirs a fair few password crackers that can be set to brute force the password file, it`ll take a long time on a good password but as it goes through every combination of letters and numbers it will eventually get the password. just be ready to leave the computer at it for a day or so!!
mark
You type faster than me :)
But you are quite correct that if someone can read and copy files from your system, you are vulnerable to an exploit.................we just have to make it difficult for them?
Cheers
Homenet,
I have to disagree with you there. If these programs are to work, they have to be able to match the password to something that makes sense, or try every possible character against the system?
If it is the latter, then the system should kill the link after the third attempt. If it is the former, then they need a dictionary file, which means they are looking for known words or phrases. That is why they are called "brute force"? Otherwise how can they tell that they have made a match?................or maybe I am just being a bit dumb again?
cheers
A simple way to prevent 0-day exploits from being an issue in this instance would be to disallow remote users from traversing directories. (this setting is found in the security policy) Additionally set anon users to only have access to objects they are explicitly granted access to. (also found in the security policy)
Now you have a situation where _three_ different mechanisms need to be broken.
As far as what can be done with the ability to read files, if you can read every file on the system, the system has been completely compromised. Effectively the system has little else to offer most of the time. I personally would start with the cache files email, web, etc. Download everything sort it later. Next target the user files as these may contain valuable information as well. Once this is complete review the system for any services, start with their configuration files, review these later for flaws. Finally review these services for private/confidential material typically requiring authorization by the service.
End result? Frequently people get account information emailed to them that contains authentication data not unlike that for the system (which may lead to possession of the host at a later date) valuable information may be discovered in the web cache files as well. Authentication data is also frequently found in whatever mechanism the server uses to protect private/confidential data.
All of this should give you plenty of leverage and this isn't even touching on the social engineer opportunities made available to you with all of this private data.
catch
Nice post catch............you covered a lot there.
Guess all that you missed out was the traditional "Desert Eagle to the head" and "you have until this 50cent coin hits the deck" :)
I suppose the only answer is my usual fallback plan...........make them login and change their passwords after every typo :D
Sorry...............did not mean to be facetious, just a little humour...............but your Users are the weakest link, as you rightly observed at the end of your post.
Cheers
hey nihil,
sorry i didn`t explain myself correctly, i was talking about if someone had been able to get hold of a copy of your sam and performed the brute force cracker on it locally, i know lopht have made a program to do it and i`m sure theirs another called John the ripper or is that for linux password files, have to excuse my bad memory.
but your quite correct on trying to crack a password remotly, i wouldn`t even bother trying.
mark
The example you provided exposes two security holes not just one(probably more :)). First off the .php script (and any others for that matter) should ALWAYS ALWAYS ALWAYS sanitize and validate input.Obviously in the case of CSS,SQL injection,etc this is not done. This would have stopped that **** right off, but todays sites can be extremely complex and some people are very good at finding CSS vulns and other scripting weakpoints which exist in heavy script reliant sites. Second, if your are able to read boot.ini then the file permissions were set by a jackass. The webserver has an account used for anonymous access to webpages (meaning everyone on the internet reading your boot.ini :)) if this account has read access to the system or root directory then once again the permissions were set by a jackass. The web server's user account should not be able to access ANY parts of a file system other then what is strictly necessesary, usually the htmldocs and any assets web apps might need. Use the same prudence when congfiguring a DB account we wouldnt someone running amok on your system after they figure out your Mysqld is running as root with no password. File permissions are a great thing, unfortunately neglecting them can have serious ramifications. Lucky for us ,Windows allows the 'Everyone' group access to the system drive by default, for reasons I will most likely never fathom and hence makes an improperly configured IIS server any easy target.
-Maestr0
Edit: Just a quick thing on brute forcing, brute forcing over a network is stupid. Its slow, and it will be detected (Assuming this isnt the jackass admin who let you read his system directory). And it will take more then a day, as anyone who has actually BF'd a password will tell you, its usually a last resort. One can BF a PW locally because of the speed with which you can try. For an 8 digit password, 50 years is a pretty good time for a home PC. Dictionary attacks usually yield much better results much faster.
Not to be rude, but... did you post this in the wrong thread? Here we are talking about the issues of system level remote file reads and you are talking about CSS, SQL injection, mysql and root? Windows doesn't even have a root user and how did we get to the IUSR_<system name> account permissions? You are the first person to mention IIS, so you can see why I am confused.Quote:
Originally posted here by Maestr0
The example you provided exposes two security holes not just one(probably more :)). First off the .php script (and any others for that matter) should ALWAYS ALWAYS ALWAYS sanitize and validate input.Obviously in the case of CSS,SQL injection,etc this is not done. This would have stopped that **** right off, but todays sites can be extremely complex and some people are very good at finding CSS vulns and other scripting weakpoints which exist in heavy script reliant sites. Second, if your are able to read boot.ini then the file permissions were set by a jackass. The webserver has an account used for anonymous access to webpages (meaning everyone on the internet reading your boot.ini :)) if this account has read access to the system or root directory then once again the permissions were set by a jackass. The web server's user account should not be able to access ANY parts of a file system other then what is strictly necessesary, usually the htmldocs and any assets web apps might need. Use the same prudence when congfiguring a DB account we wouldnt someone running amok on your system after they figure out your Mysqld is running as root with no password. File permissions are a great thing, unfortunately neglecting them can have serious ramifications. Lucky for us ,Windows allows the 'Everyone' group access to the system drive by default, for reasons I will most likely never fathom and hence makes an improperly configured IIS server any easy target.
-Maestr0
catch
PS. FYI my boot.ini file is comepletely empty, what valuable information is suppsed to be in here?
Catch ,
Thanks good post.
But I dont feel like the system is compormised just by being able to read files. This scenario actually stemmed from a real problem on my friends machine where he is the 'jackass'. After I told him about his php problem his reply was so what you still cant "own" my system, and in this case own means to have full control.
I had thought ok this shouldnt be too hard, I will how have to prove that I can own your system.I wasnt so familiar with the windows directory structure so this was the first hurdle. I can read any file but I have to know its location. I was hoping there was someway to open folders like *nix and see what is in the directory but so far no good. I had thought to read the password file as stated in previous post, but this seems quite challenging.
One thing that worked is he has mysql running to i put in 'c:\wint\my.ini' and I was able to get the admin account on mysql.(note to self--mysql really shouldnt store an admin password in the clear), but alas I still do not own his system.
So he may be right. Unless I can find information that gives me control of the system then even though he is a jackass and should be using *nix with apache(we wont get into that now) I cnat do anything more than guess where certian files are and read the contents.
This was the post I was referring to, and since the subject says Windows, I figured IIS was a safe bet. I mentioned CSS and SQL injection because these also exploit the failure to properly validate data which is the basic heart of this problem. Any script which does not check to see what it is requesting can be used to return system files to a malicious user. Any php script that lets me jam in my own path and actually passes it through sucks. Same with SQL queries. As for MySQL, since php users usually use mysql because it is free and native from php I used it as an example that care in validation and file permissions should be used for other web accessible information. I think tricking a server into returning the contents of its database is a least if not more dangerous then it returning any requested files, and although windows does not have a root account mysql does and I think we all know what that access level is equivalent to on a Windows box.Quote:
No, I am not talking about sharing. Im talking about some vulnerablilities with php. For instance I can go to some sites with php not configured correctly and put in a specific url (example www.thisurl.com/php?c:\boot.ini) and read the boot.ini file or any other file on the drive as long as I know the path. So I wasnt sure about how windows stored password I looked where you said but I still cannot see a password file there. I do not hide any files is it possibly stored anywhere else?
Edit: I think Security Angels last post should answer your question. :)
S3cur|ty4ng31 ,
Your friend is 1 step away from being 0wn3d completely.
-Maestr0