Overview: Security misconfigurations are security controls that are inaccurately configured or
left insecure, putting your systems and data at risk such as any poorly documented
configuration changes, or a technical issue across any component in your endpoints and default settings.
We can detect security misconfigurations in web applications using following test cases:
1) EXPOSED FILES AND DIRECTORIES: Files and directories when left unprotected may allow hackers to force browse the application and help them access the restricted files in root/server directory.
We can use Burp engagement tools and google dorking to find out exposed files and directories.
Example attack scenario:
site: testphp.vulnweb.com ext:bak
This search query in google will yield a list of files ending in “.bak “, an extension commonly associated with backup files and restrict search results to the domain of the target site:testphp.vulnweb.com.
Prevention:
Before pushing your changes to the live/production server you should use a test or staging environment. keep backup files on your web server out of the directory you have configured your webserver to serve. Configure your WordPress files permissions to prohibit access to the web server’s user, so that even in case of an event of a misconfiguration, the webserver will not expose the file to a client requesting it. Encryption of database backups is a good idea also the encryption key should not be accessible by the web server’s user.
Directory listings & Missing Index Files
A directory listing is a type of Web page that displays the directory contents that exist on a Web server when there is no index file in a specific website directory. File (.htaccess) protects directory contents from unauthorized viewing but can be seen and read when there is server misconfiguration.
Example attack scenario:
In a vulnerable website when a user makes a request www.vulnweb.com/admin/, the response from the server displays the directory content of the directory admin, as seen in the below screenshot.
In the screenshot you can see that in the admin directory there is a sub-directory called backup, which might include enough information for an attacker to craft an attack.
Misconfiguration of the web server has led the attacker to display the whole list of files in the backup directory such as password files, database files, FTP logs, and PHP scripts which was not intended for public view.
Prevention:
No sensitive information should be disclosed. Restrict or disable directory listings from the web server configuration. On an Apache Web server, you can disable directory listings by placing a dash or minus sign before the word Indexes in the httpd.conf file (Options-Indexes followSymLinksMultiViews).
2) DEFAULT ACCOUNTS / PASSWORDS ARE ENABLED: It is a very common security misconfiguration where the attacker gains unauthorized access to the system using vendor-supplied defaults for system accounts and passwords.
Since default credentials are often bound to administrative accounts attackers use the following common Username/Passwords in authentication guessing attacks:
username | password |
admin, administrator, root | admin, administrator, root, password, {company name}, {NULL} |
{NULL} | {NULL} |
Operator, backup | Operator, backup, {NULL} |
test, test1, qa | Test, test1, qa, {NULL} |
{company name} | {company name}, password, {NULL} |
demo, guest, private | demo, guest, private, {NULL} |
{known username} | {known username}, {NULL} |
Prevention:
Change Default Passwords and Use Unique Default Passwords: Before deploying the system on an untrusted network such as the internet, default passwords must be changed. Systems should be designed to use unique default passwords.
Force the Default Password Changes: The system should be designed so that it requires a password change the first time a default password is used.
3) OUTDATED SOFTWARE/LIBRARIES
Vendors usually release upgrades for their open-source software, fixing gaps or bugs but fail to update the application with the available upgrades which gives a chance for attackers to gain unauthorized access. Use of third-party JavaScript libraries can introduce a range of XSS vulnerabilities. Few library vulnerabilities expose every application that imports the library while some may affect only applications that use certain library features.
Example attack scenario:
www.vulnerableweb.com -> view page source -> ctrl+f: bootstrap, jquery -> library version exposed -> find exploits for outdated libraries
Below is the screenshot of outdated libraries and their vulnerabilities.
Prevention:
Ensure to apply all available security updates regularly, especially when using third-party code, since the updates usually contain patches or fixes for any vulnerabilities that were detected recently. Remove the libraries that are no longer used.
4) ERROR HANDLING AND STACK TRACES
Improper error handling reveals the users overly informative error messages that includes sensitive information about its environment, users, or associated data. It leads to stack traces.
A stack trace is a report/long error message which leaks information about program subroutines. Attacker uses this information to gain access to potentially sensitive information such as: database versions, table names, code filenames, physical file paths of relevant files, server version etc. A stack trace is not a vulnerability but make customers assume the site is broken and worry about whether their transaction will work, or perhaps assume that the site has been hacked.
Example attack scenario:
www.vulnerableweb.com -> tamper the input to the vulnerable web application by sending invalid data input or insert illegal characters to the URL or the HTTP request -> Observe whether any underlying technology, IP address, internal file path, stack trace, and SQL queries are revealed in the error message
Below are screen shots of error messages: