remote file reading on windows

So remote file reading is a huge security risk and I was just pondering how easy it would be to gain remote access to the computer if you can do this. My guess is youd have to know certian things about the widows file hiearchy meaning that WINNT probably has certain files in c:\WINNT that could give information. What are the possible attacks that someone can use if they can read local files on a windows machine?

Does windows have a password/shadow file similar to *nix systems?
Is it possbile to open folders as files and see what contents are inside?

Also since an attacker would have to know the directory structure it would seem like a good ideas to have your drive start with another letter other than c and to store certain files in other locations other than the default. Obviously the best thing would be to eliminate any remote file reading but if a zero-day exploit popped up, being prepared is the next best thing.

Hey,

Interesting question..................there are people here who will "eat it for breakfast" so to speak, so I will not be boring with my ignorance.

But, what about hidden virtual drives?............I have one on this machine............it's my mirror backup..(and on a different physical drive!)...........I can get to it via a DOS boot disk. It is visible only as a very big file that is encrypted and compressed...............only one amongst 30,000 or more?

I have this to be able to do an almost "instant" restore...............paranoid...yes I learnt it from my cat :)

nice post

cheers,

johnno

Is this file visible when you do a normal start up or only when you use the dos boot disk. Since its on your own drive I guess you could tell windows to disable that piece of hardware but then how do you actually back things up?

Sorry, I did not explain myself too well there :(

The DOS disk is only to get me in if all else fails.

The actual software would usually run under Windows. You call the proggy on your disk, and tell it to run, it comes back and asks for the file location/id. You give it that and it "mounts" the file. You then give it up to 4 passwords (all have to be correct) and it creates the new drive.

In other words it loads the virtual drive as F or G or whatever.

You cannot see the virtual drive on normal startup, as it is just one of thousands of files. You will know it...but a virus will not :D

Just use any sort of backup software to create the contents of this virtual drive...........or just copy stuff there (then you do need a boot disk if anything goes wrong!)

Does this answer your questions?

cheers

Sounds like one of the PGP disk drives. They're quite handy those are, but I've never thought of using it for a secure backup. Cheers nihil!

Ok, yes that answers that question.
But my initial question is still open, and this backup will be good in restoring your system but it does nothing to help in the prevention of compromise initially.

Umm, yes, windows does have password files. In 9x they are located in c:\windows\USER NAME.pwl and no they aren't shadowed, just encrypted (at least in 9x and NT4, I'm not sure about the later versions).

If by remote file reading you mean file sharing (i.e. the ability for one networked computer to read files and download/upload (with the right permission) them), then a client can only see the directorys contained within the file that you have created as shared. i.e. if you share the root of c:\ then they can read everything, but if you shared for example c:\shares, then they could only read files within that directory. This would include the directory c:\shares\share1, but not c:\windows.

And lastly, yes it is a very good idea to install windows in a non standard directory (i.e. d:\my9xOS\), although you can only do this with OS's after 9x, as 9x has to be on the primary partition. So, if you're running NT4.0 or XP then do this!

There you go, hope I helped!!

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?

i take it your running NT, if so then your log on passwords are kept in an encrypted file called sam. if i remember right its in your winnt\system32 folder. i know their is software out thier but genrally you should not be able to access it locally or remotely when windows is running. the way to access it locally would be to get hold of one of those boot disk that can read from NTFS disks. i know theirs one or two ways to access it remotely but i cant remember how and as far as i know its not an easy job. Lopht have made tools to unencrypt the sam file but its quite a time consuming process.
anyway hope that answers one of your questions.
mark

S3cur|ty4ng31

Sorry If I seemed a little dumb, but there are plenty of people more qualified than I to answer you question in detail.

I thought I would mention the virtual drive out of interest? As it is sort of related from a security viewpoint?

I also have a system restore feature that must store the passwords somwhere inside it.........haven't really tried to take a look as it uses its own weird compression utility.

Another thing is that the swap or page file is another place to look for passwords.....and they are unencrypted there! Not to easy to do remotely though IMHO? And, as they are so large, they would take a long time to extract remotely?



Which Windows OS are we talking about anyway? The password files are no great secret, and could probably be quite quickly downloaded via a trojan, physically, malformed website exploit or whatever.

OK so now we have this file.....what do we do with it?........use a password cracker?...there is no such animal in the average hacker's zoo............you need to have intelligence agency budgets for that kind of stuff (the real thing I mean) and the kit to run it!

The stuff you see uses a "dictionary" as in it looks for known words and phrases. Use English on a Spanish password file and you might as well save your electricity bill. ;)

If you use proper, secure passwords, there is little chance that the average cracking program can break it; so even if PHP is insecure and someone steals your password file, it should be no good to them? if it is...got to be your fault?

I hope this is a bit more help?

Cheers

BTW you need to enforce password changing on a regular basis, that way, even if the password is cracked....it will be no longer valid. :)

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.

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

---

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.

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.

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?

---

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.

Edit: I think Security Angels last post should answer your question. :)

S3cur|ty4ng31 ,
Your friend is 1 step away from being 0wn3d completely.


-Maestr0

For the purposes of your game, yes you'd need full control of the system. In the real world however full system control is frequently just plain not needed. Just remember the CIA, topple any of the three and the controls have failed. (If the computer can no longer keep secrets, what else is it good for?) Typically I would rather allow an attacker to control the system than to be able to access private material. (one does not equate to the other)

I think if you follow my adivce you will have a good chance of complete control, but as far as the directory structure goes, the stuff could be anywhere. You'd do well to start in C:\Documents and Settings\ if it exists.

catch

PS. PHP and mySQL on a Windows system? Heh some people are so silly.

Maestro,
Well that 1 step seems to have stumped me for now, but I guess when I have a little more free time I will do what catch has reccomended and see where this gets me.

He has lots of services but they all seem to be current version with exploits not found. There is NETBIOS though ....