Vulnerability Database for common security issues

Jul 17, 2013

Following are my notes on common security issues that were identified based vulnerability scanning or penetration testing

OS Command Injection

Description: An OS command injection attack occurs when an attacker attempts to execute system level commands through a vulnerable application. Application uses system level commands to do some functionality. In this, web interface is used to execute OS command on a web server. Any web interface that is not properly sanitized is subject to this exploit. If attackers can identify the vulnerable interface, they can inject crafted operating system commands through a vulnerable web interface in order to perform any desire actions.

Risk: An attacker can execute OS commands from web application interface, upload malicious programs to the web server directory, cause denial of service, etc.

Recommendation: Design and program the Web application to prevent client-supplied values from being treated as SQL syntax. By using stored procedures and parameterized SQL statements, it is possible to ensure that any client-supplied values used will be treated as an expression and will not be able to modify the SQL syntax. As a layered security approach, use white list input validation and output encoding on all user inputs.

References:

https://www.owasp.org/index.php/OS_Command_Injection

https://www.owasp.org/index.php/Command_Injection

http://cwe.mitre.org/data/definitions/78.html

http://capec.mitre.org/data/definitions/88.html

http://blog.pusheax.com/2012/01/os-command-injection-vulnerabity.html

ORM Injection

Description: An ORM is an Object Relational Mapping tool. ORM Injection is an attack using SQL Injection against an ORM generated data access object model.

It is used to expedite object oriented development within the data access layer of software applications, including web applications. The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standardized code templates for these objects, and usually a set of safe functions to protect against SQL Injection attacks. ORM generated objects uses SQL to perform CRUD (Create, Read, Update, Delete) operations on a database. It is possible, however, for a web application using ORM generated objects to be vulnerable to SQL Injection attacks if methods accept non sanitized input parameters.

Risk: An attacker can update, delete, modify and read sensitive data from the database using web application interface.

Recommendation: Design and program the Web application to prevent client-supplied values from being treated as SQL syntax. By using stored procedures and parameterized SQL statements, it is possible to ensure that any client-supplied values used will be treated as an expression and will not be able to modify the SQL syntax. As a layered security approach, use white list input validation and output encoding on all user inputs.

References:

http://capec.mitre.org/data/definitions/109.html

http://software-security.sans.org/developer-how-to/fix-sql-injection-in-java-hibernate

http://www.12robots.com/index.cfm/2009/11/19/ORM-Hibernate-Injection--Security-Series-14

http://minsky.gsi.dit.upm.es/semanticwiki/index.php/Object_Relational_Mapping_Injection

http://stackoverflow.com/questions/5173002/where-are-orms-vulnerable-for-sql-injection

XML Injection

Description: XML Injection is used to manipulate or compromise the logic of an XML application or service. The injection of unintended XML content and/or structures into an XML message can alter the intend logic of the application. Further, XML injection can cause the insertion of malicious content into the resulting message/document.

Risk: An attacker can bypass backend access control, execute backend database queries, make arbitrary HTTP requests which can be used to exhaust server resources (denial of service), perform privilege escalation, etc.

Recommendation: Design and program the Web application to prevent client-supplied values from being treated as SQL syntax. By using stored procedures and parameterized SQL statements, it is possible to ensure that any client-supplied values used will be treated as an expression and will not be able to modify the SQL syntax. As a layered security approach, use white list input validation and output encoding on all user inputs.

References:

https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing

http://cwe.mitre.org/data/definitions/91.html

[http://projects.webappsec.org/w/page/13247004/XML%20Injection](http://projects.webappsec.org/w/page/13247004/XML Injection)

https://www.htbridge.com/vulnerability/xml-injection.html

XPath Injection

Description: XPath Injection is an attack technique used to exploit applications that construct XPath (XML Path Language) queries from user-supplied input to query or navigate XML documents. It can be used directly by an application to query an XML document.

Querying XML is done with XPath, a type of simple descriptive statement that allows the XML query to locate a piece of information. Like SQL, you can specify certain attributes to find, and patterns to match. By sending intentionally malformed information into the web site, an attacker can find out how the XML data is structured, or access data that he may not normally have access to.

Risk: An attacker can update, delete, modify and read sensitive data from the database using web application interface.

Recommendation: Design and program the Web application to prevent client-supplied values from being treated as SQL syntax. By using stored procedures and parameterized SQL statements, it is possible to ensure that any client-supplied values used will be treated as an expression and will not be able to modify the SQL syntax. As a layered security approach, use white list input validation and output encoding on all user inputs.

References:

https://www.owasp.org/index.php/XPATH_Injection

https://www.owasp.org/index.php/Blind_XPath_Injection

http://www.soapui.org/Security/xpath-injection.html

http://cwe.mitre.org/data/definitions/91.html

IMAP/SMTP Injection

Description: IMAP/SMTP is a protocol that allows an email client to download email from an email server. It is used for exchange for the mails between mail server and client.

IMAP/SMTP injection is possible when webmail server sit between the Internet and the IMAP or SMTP mail server and webmail doesn’t validate input from the user. An attacker can exploits weaknesses in input validation on IMAP/SMTP servers to execute commands on the server. User requests are received by the webmail servers which then query the back-end mail server for the requested information and return this response to the user. In this attack, mail-server commands are embedded in parts of the request sent to the web-mail server. If the web-mail server fails to adequately sanitize these requests, these commands are then sent to the back-end mail server when it is queried by the web-mail server, where the commands are then executed. This attack can be especially dangerous since administrators may assume that the back-end server is protected against direct Internet access and therefore may not secure it adequately against the execution of malicious commands.

Risk: An attacker can exploit vulnerabilities in the IMAP/SMTP servers and evading all the restrictions at the application layer.

Recommendation: Ensure your mail server is security hardened and running latest updated OS and patches. As a layered security approach, perform white list input validation and output encoding on all user inputs.

References:

https://www.owasp.org/index.php/Testing_for_IMAP/SMTP_Injection_(OWASP-DV-011)

http://capec.mitre.org/data/definitions/183.html

http://software-security.sans.org/blog/2011/01/14/spot-vuln-sleep-smtp-command-injection

https://www.hellboundhackers.org/articles/867-smtp-injection.html

http://www.websiterepairs.net/smtpinjection.php

User Enumeration

Description: User enumeration is possible using a built in function within the application. The system responds with different messages depending on whether valid account information is used.

Risk: By responding with different error messages depending on whether valid account information has been entered, a remote attacker will be able to determine valid email information.

Recommendation: The application should not provide specific details as to the existence of valid account information, such as when a user attempts to obtain a forgotten password. The application should not provide specific details regarding the validity of information entered. Non-descriptive error messages should be used, such as “Credentials are Not Valid or your account has been locked out due to excessive, incorrect logins. If the problem persists, please contact customer service.”

References:

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

http://cwe.mitre.org/data/definitions/204.html

http://cwe.mitre.org/data/definitions/203.html

http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/

Default credentials Enabled

Description: Application makes use of popular open source or commercial software that can be installed on servers with minimal configuration or customization by the server administrator. Moreover, a lot of hardware appliances (i.e. network routers and database servers), offer web-based configuration or administrative interfaces.

Often these applications, once installed, are not properly configured and the default credentials provided for initial authentication and configuration are never changed. These default credentials are well known by attackers, who can use them to gain administrative access to the application.

Furthermore, in many situations, when a new account is created on an application, a default password (with some standard characteristics) is generated. If this password is predictable and the user does not change it on the first access, this can lead an attacker to gain unauthorized access to the application.

Risk: An attacker can gain administrative access to the application performing actions on restricted menu, restricted data and also escalates his privilege to other level of users.

Recommendation: Review, audit and remove application default accounts or credentials. Ensure to remove all default accounts from related application modules.

References:

https://www.owasp.org/index.php/Testing_for_Default_or_Guessable_User_Account_(OWASP-AT-003)

https://www.owasp.org/index.php/Testing_for_default_credentials_(OWASP-AT-003)

http://cwe.mitre.org/data/definitions/521.html

Weak Password Policy

Description: It was observed that the application adopts weak password policy. Application allows users to set 1 character password and do not force change password on first login. Lack of password complexity significantly reduces the search space when trying to guess user’s passwords, making brute-force attacks easier.

Risk: An attacker can perform brute force attack to compromise weak user’s credentials and obtain access to restricted area.

Recommendation: Enforce a strong password policy across the application. The policy should include below points:

· Must be minimum 8-characters in length

· Must be alpha-numeric

· Password History: 5

· Must expire within 90 days

References:

https://www.owasp.org/index.php/Testing_for_Weak_password_policy_(OWASP-AT-008)

http://cwe.mitre.org/data/definitions/521.html

http://cwe.mitre.org/data/definitions/522.html

http://cwe.mitre.org/data/definitions/263.html

CAPTCHA Not Implemented

Description: The application has a registration feature. This process adopts an insecure practice by not verifying that the end user is an automated program or a legitimate user. An attacker can cause denial of service attack by constructing a custom script called bot to register millions of users within no time. This event may flood the network which can lead to DOS attack.

Risk: The risk is high as it may affect the availability of the application.

Recommendation: Implement a CAPTCHA to stop automated programs in their tracks.

A CAPTCHA, however, cannot be bypassed by automated tools and so is a better method. A CAPTCHA (an acronym for “Completely Automated Public Turing test to tell Computers and Humans Apart”, trademarked by Carnegie Mellon University) is a type of challenge-response test used in computing to determine whether or not the user is human. One of the implementations includes visual CAPTCHAs which require users to identify the word that is embedded in a picture format in the webpage and enter the same into a textbox for verification. This would prevent bots and other malicious scripts from brute forcing the application or launching denial of service attacks on the application in public registration forms.

For a safe implementation, the application should generate a dynamic image and send to the client with a random token. In response, server checks the token and returned characters from the client. If matches, request is valid. Expire token after one use.

References:

https://www.owasp.org/index.php/Testing_for_Captcha_(OWASP-AT-008)

https://www.idontplaydarts.com/2011/05/exploit-phpcaptcha-securimage/

http://cwe.mitre.org/data/definitions/804.html

http://cwe.mitre.org/data/definitions/330.html

http://cwe.mitre.org/data/definitions/287.html

Information Exposure through Browser Caching

Description: Application stores certain information in the web browser cache so if there is another request for the same URL, it can use the response that it has, instead of asking the origin server for it again. Main reason to use web cache is to reduce latency and to reduce network traffic. Cache policy of the application specifies the extent to which the page and its form field should be cached.

On the negative side if the cached information contains sensitive data is a security concern. This information need to be protected from unwanted systems/users, hence each web pages need to classified and caching sensitive information need to be avoided.

Information exposure is possible if browsers store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers.

Risk: An attacker can steal sensitive information from browser cache affecting user confidentiality by exposing sensitive and personal information of the user.

Recommendation: Caching can be prevented by setting the proper cache control attributes in the response header.

Cache-control: no cache

Cache-control: no store

The first attribute tells the browser not to use the information that is cached for that particular request-response pair. It indicates that the browser must send the request to the server each time. No-cache can also be specified for certain fields alone, in which case the rest of the page may be displayed from cache. If no field is specified, the no part of the page can be displayed from cache.

No-store indicates that no part of the request-response pair should be cached. This applies to the entire page and the browser should not remember any part of it in its cache

References:

http://cwe.mitre.org/data/definitions/525.html

http://www.symantec.com/connect/blogs/using-browser-cache-bypass-security

https://www.owasp.org/index.php/OWASP_Application_Security_FAQ

http://minsky.gsi.dit.upm.es/semanticwiki/index.php/Information_Leak_Through_Browser_Caching

http://www.jamesewelch.com/2011/07/12/securing-asp-net-web-sites-form-caching/

Direct URL/Improper authorization control

Description: It was observed that the application internal pages are accessible without authentication. A valid login is not required to exploit the vulnerability.

Risk: An attacker can access internal application pages without authentication breaching user confidentiality and integrity. Depending on access privileges, attacker can perform actions on restricted menu, restricted data and also escalates his privilege to other level of users.

Recommendation: In web application always try to distinguish users and their roles. If a page is only made for admin, then check whether the user is admin before granting access to the page or user has permission to access the page. This makes it secure and protects URL based forced browsing attack. Ensure authentication loop is enabled for every internal page.

References:

http://cwe.mitre.org/data/definitions/285.html

http://www.cvedetails.com/cwe-details/285/Improper-Access-Control-Authorization-.html

https://www.owasp.org/index.php/Top_10_2010-A8-Failure_to_Restrict_URL_Access

Malicious File Upload

Description: Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step. In this case, we successfully managed to upload and execute HTML and EXE file to the web server.

Risk: The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system, forwarding attacks to backend systems, and simple defacement. It depends on what the application does with the uploaded file, including where it is stored.

Recommendation: The files should be accepted by creating a white list of file type and applying a validation at application layer on server side. Every file must be checked for valid file type, maximum content length and content type before it is finally uploaded to the server.

The characters such as %00, 0X00, :, ;, $, _, >, <, /, \ need to be validated at application layer before uploading a file to the server.

References:

http://cwe.mitre.org/data/definitions/434.html

http://resources.infosecinstitute.com/file-upload-vulnerabilities/

http://minsky.gsi.dit.upm.es/semanticwiki/index.php/Unrestricted_File_Upload

https://www.owasp.org/index.php/Unrestricted_File_Upload

Session Hijacking

Description: The vulnerability allows an attacker to hijack another user’s session by just replaying the cookie of another user. An attacker gains a prolonged access to user’s session as application do not terminate the session on server side and no session expiry tags has been maintained by the application.

Risk: An attacker can hijack sessions of another user gaining access to unauthorized contents.

Recommendation: Invalidate any existing session identifiers prior to authorizing a new user session and renew the cookies after successful authentication. Attach a session cookie with an expiry tag.

References:

http://en.wikipedia.org/wiki/Session_hijacking

https://www.owasp.org/index.php/Session_hijacking_attack

http://technet.microsoft.com/en-us/magazine/2005.01.sessionhijacking.aspx

http://msujaws.wordpress.com/2011/02/17/xss-session-hijacking-proof-of-concept/

http://cwe.mitre.org/data/definitions/384.html

http://cwe.mitre.org/data/definitions/331.html

Insecure Direct Object References - Parameter Manipulation

Description: Application allows users to browse books, purchase books, view order status of books, etc. Due to improper mapping of user privilege role and request parameters, an adversary is able to execute action that he is not authorized to perform. Using this vulnerability, an adversary can view actions on behalf of other users.

Risk: An adversary gains unauthorized access to restricted menu, restricted data, restricted action, and also escalates his privilege to other level of users

Recommendation: When the application receives any request from the client then server should not process the request as-it-is and prepare a response. On receiving any request from any user, application should check if the request submitted by user is according to the access rights assigned to the user. It is recommended that the Session ID of the logged in user should be mapped to the user details, user’s privileges, user’s actions or any other constant parameters and this should be verified before serving any request.

References:

http://cwe.mitre.org/data/definitions/472.html

http://www.security-database.com/cwe.php?name=CWE-472

https://www.owasp.org/index.php/Web_Parameter_Tampering

http://minsky.gsi.dit.upm.es/semanticwiki/index.php/Web_Parameter_Tampering

Improper Error Handling

Description: Often, inducing errors in application results in dangerous information disclosure like stack traces, failed SQL statements, server/back-end technology banners with versions, web-server path information, user enumeration, or other debugging information. Some of these errors even expose functions that produce different results based upon different user-inputs, to the attacker. An attacker can leverage the information learnt from such error messages about the configuration and internal workings of the application to launch manual or even automated attacks focused on the technologies/functionalities being used.

Risk: Informative error messages can lead to loss in confidentiality with varying severity depending upon the information revealed, and aid an attacker to mount more powerful technology/functionality-specific attacks upon the application/web-server.

Recommendation: Ensure that only generic, customized error messages which do not reveal any sensitive information are displayed to the user.

References:

https://www.owasp.org/index.php/Improper_error_handling

http://cwe.mitre.org/data/definitions/388.html

http://www.jtmelton.com/2010/06/02/the-owasp-top-ten-and-esapi-part-7-information-leakage-and-improper-error-handling/

http://searchsecurity.techtarget.com/tip/Improper-error-handling

Insecure Cryptographic Storage

Description: Application developers should identify the data handled by the application which are sensitive enough to be encrypted properly where they are being stored. Ex: Passwords, credit cards, health records, and personal information. A strong, standard encryption algorithm should be used along with a strong key which is protected from unauthorized access. In many cases, these sensitive data are not encrypted, or the encryption process is sabotaged through unsafe key generation and storage, not rotating keys, and weak algorithm usage. The use of weak or unsalted hashes to protect passwords is also prevalent.

Risk: Sensitive data like credit card, passwords, health records, etc., when stored unencrypted, or protected with unsalted hash are prone to unauthorized disclosure through the exploitation of other vulnerabilities like SQL injection, direct object access, etc. Such leakage will result in the loss of confidentiality, privacy and trust of users, damage to reputation, and legal liabilities.

Recommendation: Identify and encrypt all sensitive data with standard, strong algorithms and strong keys wherever they are being stored, including offsite backups. Ensure passwords are hashed with a strong standard algorithm and an appropriate salt is used.

References:

https://www.owasp.org/index.php/Top_10_2010-A7-Insecure_Cryptographic_Storage

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

http://www.infosecisland.com/blogview/21796-Insecure-Cryptographic-Storage-Explained.html

http://www.veracode.com/security/insecure-crypto

http://cwe.mitre.org/data/definitions/326.html

http://cwe.mitre.org/data/definitions/816.html

Directory listing

Description: Directory listings were found enabled on the Web server. Directory listings are a complete index of all of the resources located in a directory. These directories may store documents or files critical to the Web server. The information in these folders is most likely meant to be private.

Risk: Directory listings are valuable to attackers because they display all files in a directory, not just ones that are intended to be used. Files that are supposed to be hidden (such as data files, backed-up source code or applications in development) may be visible.

Recommendation: If the files in a directory need to be listed for Web users, create an HTML page to display them. Turn off automatic directory listings and remove sample/unwanted files from the document root entirely where possible.

References:

http://cwe.mitre.org/data/definitions/548.html

http://cwe.mitre.org/data/definitions/538.html

http://cwe.mitre.org/data/definitions/23.html

http://minsky.gsi.dit.upm.es/semanticwiki/index.php/Information_Leak_Through_Directory_Listing

https://www.owasp.org/index.php/Top_10_2010-A6-Security_Misconfiguration

Privilege Escalation

Description: Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation/changes should have been prevented by the application. It was observed that the application allows lower privileged user to view records of higher privileged user. In this case, employee role user is able to change its role to administrator and able to perform admin actions.

Risk: An attacker gains unauthorized access to restricted file, restricted data, restricted action, and also escalates his privilege to other level of users.

Recommendation: It is recommended to adopt below approach to fix the vulnerability:

· Implement role based access control to assign permissions to application users for vertical access control requirements.

· Implement data-contextual access control to assign permissions to application users in the context of specific data items for horizontal access control requirements.

· Avoid assigning permissions on a per-user basis

References:

https://www.owasp.org/index.php/Testing_for_Privilege_escalation_(OWASP-AZ-003)

https://www.owasp.org/index.php/Testing_for_Authorization

http://en.wikipedia.org/wiki/Privilege_escalation

http://cwe.mitre.org/data/definitions/269.html

http://cwe.mitre.org/data/definitions/264.html

http://cwe.mitre.org/data/definitions/272.html

HTTP Parameter Pollution

Description: HTTP Parameter Pollution (H.P.P.) is an attack which targets the handling of single/multiple instances of an existing/new parameter by various server-side web technologies. Since there is no formal definition of how these parameters should be handled, different web servers handle them differently, rendering applications vulnerable to context-based attacks that vary in scope depending upon the functionality exposed by the attack-surface. In many instances, the execution of a successful H.P.P. attack depends on an understanding of the application logic and its attack-surfaces.

Risk: An attacker can alter or modify the normal application behavior, access and potentially exploit variables that are not been controlled properly, bypass WAFs rules or input validation mechanisms using concatenation of values in multiple occurrences of the same parameter.

Recommendation: It is recommended to perform URL encoding, input validation using white list and use strict regular expressions in URL rewriting to prevent HPP attack.

References:

http://cwe.mitre.org/data/definitions/235.html

http://www.acunetix.com/blog/whitepaper-http-parameter-pollution/

http://www.securitytube.net/video/278

http://capec.mitre.org/data/definitions/460.html

http://www.imperva.com/resources/glossary/http_parameter_pollution_hpp.html

https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OWASP-DV-004)

HTTP Response Splitting

Description: HTTP Response splitting happens when a lack of input sanitization which allows an intruder to insert CR and LF characters into the headers of the application response and to ‘split’ that answer into two different HTTP messages. First HTTP message is a request which is partially controlled by attacker and second one is a response.

Risk: An attacker can perform cross site scripting and CSRF on the victim browser by sending script or malicious payload in the header.

Recommendation: Use server side validation and disallow CRLF characters in all requests where user input is reflected in the response header.

References:

https://www.owasp.org/index.php/HTTP_Response_Splitting

https://www.owasp.org/index.php/Testing_for_HTTP_Splitting/Smuggling_(OWASP-DV-016)

http://en.wikipedia.org/wiki/HTTP_response_splitting

http://www.acunetix.com/websitesecurity/crlf-injection/

http://www.acunetix.com/vulnerabilities/crlf-injectionhttp-respon/

Cross Site Flashing

Description: The vulnerability relates to executing a Flash document that passes commands or calls to a Flash player browser plugin. The vulnerability takes advantage of the fact that Flash files can reference external URLs.

Risk: An attacker may steal user’s session identifiers, force install malware/trojan using flash components on user’s machine.

Recommendation: It is recommended to review the domains which are allowed by the Flash cross-domain policy and determine whether it is appropriate for the application to fully trust both the intentions and security posture of those domains.

References:

https://www.owasp.org/index.php/Testing_for_Cross_site_flashing_(OWASP-DV-004)

http://minsky.gsi.dit.upm.es/semanticwiki/index.php/Cross-Site_Flashing

http://kb2.adobe.com/cps/142/tn_14213.html

http://capec.mitre.org/data/definitions/178.html

http://erlend.oftedal.no/blog/?blogid=99