When All You Can Do Is Read
Mon 8th Nov 10
If you could get read access to any file on a Windows Server 2003 system what would you read? To make it a little harder, what if you couldn't do a directory listing and so had to know the file existed before reading it?
I got this on a test where I found a web server with a directory traversal attack which allowed me to read any file but didn't give me any way of listing what files existed. I initially went in with the standard boot.ini and win.ini to prove I had access but then wanted to get something more juicy. Normally, with directory indexing, I'd have a look through the users home directories and allow intuition to guide me, but doing this blind I needed to focus on files that I knew would exist.
The web server was a proprietary one, part of a control system app, and I couldn't work out the correct path to try to read the source. IIS was installed but was only showing the default "Under Construction" page so no go on the web apps. At this point I ran out of time so moved on to the next target happy that I had at least proof of the vulnerability.
I know that there are some lists out there that are used as part of LFI but running a brute force list against a web app isn't too stealthy, I'd rather be surgical and choose my target files and so make as little noise as possible and leave little trace.
To be a bit more armed for next time I asked on the PaulDotCom mailing list for recommendations, someone else then started a second thread asking what if this was a Linux system, what would you look for? Both got some good answers so I though I'd document the results. If anyone has any other suggestions please let me know and I'll update the list. Thanks to all who contributed.
Windows
- Rather than try to go through a long list of the locations of password files I'll start by referring you to a list on the NirSoft site which has info on a lot of apps. NirSoft - Password Storage Locations For Popular Windows Applications.
- The following paper was suggested, Dan Crowley, Windows File Pseudonyms. I don't think this would have helped in my situation but there are some good references in there to different ways to address common files and locations that could help if the read access isn't straight forward.
-
Common web app files:
- c:\inetpub\wwwroot\index.asp - And other common variations, also check for any other files you can browse to.
- web.config in every directory you are traversing through
- c:\windows\system32\logfiles\httperr\httperr1.log
- c:\system32\inetsrv\Metabase.xml
- .NET framework files - Check in c:\windows\microsoft.net\framework for different versions.
-
A quick pair for permissions, if you can read these it shows you can read files owned by the Administrator
- c:\documents and settings\administrator\ntuser.ini
- c:\documents and settings\administrator\desktop\desktop.ini
Linux
-
ssh keys - You've got the root user to try but if you've managed some user enumeration then you might be able to check their home directories as well. The files you are looking for are all in the .ssh directory:
- authorized_keys
- id_rsa
- id_rsa.keystore
- id_rsa.pub
- known_hosts
-
Similar to above but this time GnuPG files, again, all these are in the .gnupg directory
- gpg.conf
- pubring.gpg
- pubring.gpg~
- random_seed
- secring.gpg
- trustdb.gpg
-
Some entries from the proc could be useful:
- /proc/mounts
- /proc/config.gz
- /proc/self/fd/fd[0-9]*
-
Other things from the users home directories:
- .bash_history
- .mysql_history
- .my.cnf
