During penetration tests, we often find interesting files on web servers. Almost as often, those files enable us to carry out further attacks with much higher impact. Inspired by Chris Gate’s great series From Low to Pwned, we decided to share the following small piece.
The web server under test did not deliver directory listings. However, the directory contained a .DS_Store file (one of macOS’ many — lets say special — traits). While .DS_Store files store various information, a simple cat shows one relevant characteristic:
$ cat .DS_Store
testfile1.txtIlocblobQ�
testfile2.txtIlocblob�(��
When found in a web directory, this basically results in a directory listing without web server support for it 🙂
Thinking about mitigating controls, we decided to compile a small collection of files you should consider blocking for delivery by your web server (hint: these are also file types you want to check for during a pentest 😉 ):
- .dot files in general. In particular:
- .ht*
- .DS_Store
- .git*
- .svn*
- .pkcs12 .pfx .p12, .pem, .key, .der, .crt
- *.log
- *.swp
- *.bp/*.bak
- /^~/ or /~$/
- *.dmp/*.core
- thumbs.db/*.db
- *.raw
- *.sqlite
- *.conf/*.ini
- *.txt/*.csv
While it is true that most of those files should never end up in a “web-served” directory in the first place, we identified such results of “common operational needs” in a variety of pentests and found plenty of those files in the past. And since you should work with a hardened web server configuration template (of course you do, right?), this control may actually offer a reasonable ratio of security benefit and operational effort/impact.
Thinking about it, we also came across the approach of whitelisting file types which are delivered by your web server. Given that most applications should only use a handful of filetypes ,which in turn can even be evaluated in an automated way, this can actually be feasible with reasonable effort.
In any case you need to analyze the file types used by your application. The following script creates a quick and dirty list of file extensions found in a directory structure:
find . |perl -nle ‘@t=split(/\//);@f=split(/\./,$t[$#t]);print $f[$#f] if $#f>0’ | sort | uniq
This will not always be overly helpful due to directory includes or more complex applications/application containers, so the safest bet would be to analyze the logfiles of your application for filetypes delivered in the past — the small Perl hell above may be of help in that as well ;-). For simple applications without authentication or dynamic functionality, wget’s –spider functionality (or any sitemap generator) can be relevant input, too.
We’re also striving to provide different web server configuration templates for this in our hardening repository soon!
Happy hacking/hardening from your ERNW crew!