+- Sinisterly (https://sinister.ly)
+-- Forum: Hacking (https://sinister.ly/Forum-Hacking)
+--- Forum: Tutorials (https://sinister.ly/Forum-Tutorials)
+--- Thread: Misconfigurations: detecting, exploiting and fixing (/Thread-Misconfigurations-detecting-exploiting-and-fixing)
Misconfigurations: detecting, exploiting and fixing - unknownAttacker - 09-29-2012
While 'traditional' exploits are about finding a weakness in programming and business logic exploits (which are becoming more and more popular) are about weakness in software desing and functionality, misconfigurations are basically mistakes made in administration. Most of exploitable misconfigurations are in some way related to privileges or passwords.
What is a misconfiguration?
Misconfigurations are a broad category, although for strictly security purposes we may define them as situations when a security measure (password protection, user privileges etc.) is programmed and in use, although because of administrator's mistake it doesn't protect certain critical functions or files.
Purpose of exploiting:
Succesful exploitation of misconfiguration may reveal sensitive information. Depending on what exactly is misconfigured, the consequences can range anywhere from enumeration to full OS access.
Examples: (please note that these are only some of the possibilities)
Unprotected configuration files - configuration files containing important information (for example login and password to the database) can be accessed by anyone.
Unprotected root - something (usually a database although in extreme cases even a whole OS) is controlled through a standard user account, which is a good security procedure... while the root account is either completely unprotected or uses a default password (i.e. 'toor') - this of course is a terrible security procedure (I know it sounds silly but believe me, it happens).
Default password - something (usually an online device like a router, but might be something else) requires valid user credentials to access; those credentials are factory defaults and by no means a secret.
Unlinked but unprotected - only privileged users can see links to certain parts of a website but anyone can access them if he knows the URL (happens VERY often); tangentially related to many CSRF exploits where accessing certain parts of a website without authorization returns an error message but sending valid POST commands executes them anyway but CSRF is definitely a programmer's fault so not what this tut's about.
Unprotected backup - backup files (especially database backups) often contain important data like logins and passwords or password hashes. If PHP files are backed up and stored on server without PHP interpreter (sounds strangely specific but I found something like this once), source code will be disclosed.
Protected catalog, unprotected content - accessing example.com/secret/ requires a password and/or being on IP whitelist but the restriction wasn't applied to example.com/secret/topsecretdata.txt
Protected but cached - a file cannot be accessed by an unauthorized user but its cached version can be seen through a search engine
Blackbox detection:
It's obviously difficult to automate searching for misconfigurations. Vulnerability scanning tools can only search for misconfigs in known software and maybe detect possible hash and password disclosures with a web crawler. Fortunately, there are better ways:
Google hacking - many google dorks are searching for privilege misconfigurations; when searching for misconfigurations on a certain website you should also:
- look for certain filetypes (.ini, .bak and .sql often give nice results)
- look for certain strings (for example 'dbuser' and 'dbpassword' are common in Zend misconfigurations)
- look for files inside restricted catalogs (i.e. example.com/admin/)
- look for cached versions of interesting files
- use various search engines, not only Google
Filename brutforcing - there are some nice programs for bruteforcing files and catalogs (I use DirBuster) that might help you find hidden but unprotected shit; it's time-consuming and not very reliable but sometimes helps.
Reading source - sometimes, interesting URLs can be found in website's source; not the most interesting things as you see the interpreted version (simply speaking - HTML and JS but no PHP) but some nice things might be there anyway.
Webapp specific misconfigurations - if website runs on a known application, search for files you know are there and might be unprotected; you know, sometimes it's Wordpress installation catalog, sometimes it's Lotus Domino's Names.nsf.
Port and service scanning - if you know what you're doing, good old nmap is an invaluabe tool. Check every open port for a chance of logging in without a password or with a default/weak password. Pay attention to additional webservers - yeah, some admins think that placing their adminpanel on a different port is enough to protect it from attackers.
Exploiting misconfigurations:
Misconfigurations rarely give you full OS access. If you need it, they provide you with a nice foothold for a multi-step attack. FTP access will allow you to place something evil on the website and often so will the database, although database can also contain e-mails and passwords - and if the victim uses the same passwords everywhere, you can access his mail. Accessing SSH allows you to use normal privilege escalation attacks against the victim system. Of course getting access to the database or FTP server might be enough for you, depeneding on the purpose of your attack.
For administrators - preventing and fixing misconfigurations:
Preventing misconfigurations is a very basic thing but also very easy to overlook. Basic guidelines are:
- apply privilege settings of a catalog to its files and subcatalogs first, then assign special privileges to single files if needed
- if a guest or user can live without seeing something and protecting it doesn't render your website unusable, protect it; chmod700 is usually enough
- IP whitelist is your friend
- sometimes, the more passwords the better - it's easier to hack into something protected with webapp's auth procedure than to something that's protected with IP whitelist, webapp's auth and HTTP auth; obviously, it's also more tedious to use something protected this way so pick your poison
- never use default passwords, never live privileged accounts without passwords and NEVER leave root without password
Always one step ahead - fake misconfiguration as a honeypot:
Now it's time for some good old whitehatting. Setting up a decoy files that look like misconfigurations is awesome. First of all, it slows down the attackers who'll spend time trying to exploit a nonexistent vulnerability by cracking hashes from fake database backup. A hacker will often center his attention on something that looks like a misconfiguration because it's an easy way to gain access. Second thing is - it might be a nice and simple honeypot. If you look into the logs and see someone accessing the 2012-09-29.sql file you prepared and then using fake credentials contained in it to try to access the website, it's obvious that you have an attempted attack.
I hope it was helpful!
Greetings,
uA