Module 6:Exploiting Application-Based vulnerabilities — part 2

Exploiting Authentication-Based Vulnerabilities

An attacker can bypass authentication in vulnerable systems by using several methods. The following are the most common ways to take advantage of authentication-based vulnerabilities in an affected system:

• Credential brute forcing
• Session hijacking — A web session is a sequence of HTTP request and response transactions between a web client and a server. A large number of web application keep track of information about each user for the duration of the web transactions. Several web application have the ability to establish variables such as access rights and localization settings. These variables apply to each and every interaction a user has with the web application for the duration of the session. Once an authenticated session has been established, the session ID is temporarily equivalent to the strongest authentication method used by the application, such as username and password, one-time password, client-based digital certificate, and so on. In order to keep the authenticated state and track user's progress, applications provide users with a session ID, or token. This token is assigned at session creation time and is shared and exchanged by the user and the web application for the duration of the session. The session ID is a name/value pair. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (in the standard HTTP header), URL parameters and rewriting (defined in RFC 3986), and URL arguments on GET requests. Application developers also use body arguments on POST requests. For example, they can use hidden form fields (HTML forms) or proprietary HTTP headers. There are several ways an attacker can perform session hijacking and several ways a session token may be compromised:
• Predicting session tokens: This is why it is important to use non-predictable tokens, as previously discussed in this section.
• Session sniffing: This can occur through collecting packets of unencrypted web sessions.
• On-path attack (formerly known as man-in-the-middle attack): With this type of attack, the attacker sits in the path between the client and the web server. In addition, a browser (or an extension or a plugin) can be compromised and used to intercept and manipulate web sessions between the user and the web server. This browser-based attack was previously known as a man-in-the-browser attack.

If web applications do not validate and filter out invalid session ID values, they can potentially be used to exploit other web vulnerabilities, such as SQL injection (if the session IDs are stored on a relational database) or persistent XSS (if the session IDs are stored and reflected back afterward by the web application).

• Redirecting attacks — Unvalidated redirects and forwards are vulnerabilities that an attacker can use to attacker can use to attack a web application and its clients. The attacker can exploit such vulnerabilities when a web server accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. The attacker can modify the untrusted URL input and redirect the user to a malicious site to either install malware or steal sensitive information. It is also possible to use unvalidated redirect and forward vulnerabilities to craft a URL that can bypass application access control checks. This, in turn, allows an attacker to access privileged functions that he or she would normally not be permitted to access.
• Exploiting default credentials — A common adage in the security industry is "why do you need hackers, if you have default passwords ?" Many organizations and individuals leave infrastructure devices such as routers, switches, wireless access points, and even firewalls configured with default passwords. Attackers can easily identify and access systems that use shared default passwords. It is extremely important to always change default manufacturer passwords and restrict network access to critical systems. A lot of manufacturers now require users to change default passwords during initial setup, but some don't. Attackers can easily obtain default passwords and identify Internet-connected target systems. Passwords can be found in product documentation and compiled lists available on the Internet. An example is http://www.defaultpassword.com, but there are dozens of other sites that contain default passwords and configurations on the Internet. It is easy to identify devices that have default passwords and that are exposed to the Internet by using search engines such as Shodan (https://www.shodan.io).
• Exploiting weak credentials
• Exploiting Kerberos — In Module 5, "Exploiting Wired and Wireless Networks," you learned that one of the most common attacks against Windows systems is the Kerberos golden ticket attack. An attacker can use such an attack to manipulate Kerberos tickets based on available hashes. The attacker only needs to compromise a vulnerable system and obtain the local user credentials and password hashes. If the system is connected to a domain, the attacker can identify a Kerberos ticket-granting ticket (KRBTGT) password hash to get the golden ticket. Another weakness in Kerberos implementations is the use of unconstrained Kerberos delegation, a feature that allows an application to reuse the end-user credentials to access resources hosted on a different server. Typically, you should only allow Kerberos delegation on an application server that is ultimately trusted. However, this could have negative security consequences if abused, so Active Directory has Kerberos delegation turned off by default. NOTE Refer to Module 5 for additional information on the Kerberos authentication process and the flaws mentioned here.

Exploiting Authorization-Based Vulnerabilities

1. Parameter Pollution HTTP parameter pollution(HPP)vulnerabilities can be introduced if multiple HTTP parameters have the same name. This issue may cause an application to interpret values incorrectly. An attacker may take advantage of HPP vulnerabilities to bypass input validation, trigger application errors, or modify internal variable values. An attacker can find HPP vulnerabilities by finding forms or actions that allow user-supplied input. Then the attacker can append the same parameter to the GET or POST data — but with a different value assigned. Consider the following URL — https://store.h4cker.org/?search=cars This URL has the query string search and the parameter value cars. The parameter might be hidden among several other parameters. An attacker could leave the current parameter in place and append a duplicate, as shown here: https://store.h4cker.org/?search=cars&results=20 The attacker could then append the same parameter with a different value and submit the new request: https://store.h4cker.org/?search=cars&results=20&search=bikes After submitting the request, the attacker could analyze the response page to identify whether any of the values entered were parsed by the application. Sometimes it is necessary to send three HTTP requests for each HTTP parameter. If the response from the third parameter is different from the first one — and the response from the third parameter is also different from the second one - this may be an indicator of an impedance mismatch that could be abused to trigger HPP vulnerabilities.
2. Insecure Direct Object Reference Vulnerabilities Insecure Direct Object Reference Vulnerabilities can be exploited when web application allow direct access to objects based on user input. Successful exploitation could allow attackers to bypass authorization and access resources that should be protected by the system. This type of vulnerability occurs when an application does not sanitize user input and does not perform appropriate authorization checks. An attacker can take advantage of Insecure Direct Object References Vulnerability by modifying the value of a parameter used to directly point to an object. In order to exploit this type of vulnerability, an attacker needs to map out all locations in the application where user input is used to reference objects directly.
3. "HTTP parameter pollution and Insecure Direct Object Reference are authorization-based vulnerabilities. Kerberos weakness, session hijacking, and default credentials are authentication-based vulnerabilities."
4. Understanding Cross-Site Scripting (XSS)Vulnerabilities Cross-site scripting(XSS)vulnerabilities, which have become some of the most common web application vulnerabilities, are achieved using the following attack types: → Reflected XSS → Stored(persistent)XSS → DOM-based XSS Successful exploitation could result in installation or execution of malicious code, account compromise, session cookie hijacking, revelation or modification of local files, or site redirection. The results of XSS attacks are the same regardless of the vector. You typically find XSS vulnerabilities in the following: → Search fields that echo a search string back to the user. → HTTP headers → Input fields that echo user data → Error messages that return user-supplied text → Hidden fields that may include user input data → Application(or websites) that display user-supplied data Note — Attackers can use obfuscation techniques in XSS attacks by encoding tags or malicious portions of the script using Unicode so that the link or HTML content is disguised to the end user browsing the site.
5. Reflected XSS Attacks Reflected XSS attacks occur when malicious code or scripts are injected by a vulnerable web application using any method that yields a response as part of a valid HTTP request. An example of a reflected XSS attack is a user being persuaded to follow a malicious link to a vulnerable server that injects the malicious code back to the user's browser. This causes the browser to execute the code or script. In this case, the vulnerable server is usually a known or trusted site. Step 1 → The attacker finds a vulnerability in the web server. Step 2 → The attacker sends a malicious link to the victim. Step 3 → The victim clicks on the malicious link, and the attack is sent to the vulnerable server. Step 4 → The attack is reflected to the victim and is executed. Step 5 → The victim sends information(depending on the attack)to the attacker.
6. "Reflected cross-site scripting(XSS)attacks occur when malicious code or scripts are injected by a vulnerable web application using any method that yields a response as part of a valid HTTP request. An example of a reflected XSS attack is when a user follows a malicious link to a vulnerable server that injects the malicious code back into the user's browser, causing the browser to execute the code or script."
7. Stored XSS Attacks Stored, or persistent, XSS attacks occur when malicious code or script is permanently stored on a vulnerable or malicious server, using a database. These attacks are typically carried out on websites hosting blogs posts, web forums, and other permanent storage methods. An example of a stored XSS attack is a user requesting the stored information from the vulnerable or malicious server, which causes the injection of the requested malicious script into the victim's browser. In this type of attack, the vulnerable server is usually a known or trusted site. "Stored cross-site scripting attack(XSS)attacks occur when malicious code or scripts are permanently stored on a vulnerable or malicious server using a database. These attacks are typically carried out on websites hosting blog posts, web forums, and other permanent storage methods."
8. XSS Mitigations → Use an auto-escaping template system. → Never insert untrusted data except in allowed locations. → Use HTML escape before inserting untrusted data into HTML element content. → Use attribute escape before inserting untrusted data into HTML common attributes. → Use JavaScript escape before inserting untrusted data into JavaScript data values. → Use CSS escape and strictly validate before inserting untrusted data into HTML — style property values. → Use URL escape before inserting untrusted data into HTML URL parameter values. → Sanitize HTML markup with a library such as ESAPI to protect the underlying application. → Prevent DOM-based XSS by following OWASP's recommendation at https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html. → Use the HTTP Only cookie flag. → Implement content security policy. → Use the X-XSS-Protection response header.
9. Understanding Cross-Site Request Forgery and Server-Side Request Forgery Attacks Cross-site request forgery attacks occur when unauthorized commands are transmitted from a user who is trusted by an application. CSRF attacks are different from XSS attacks because they exploit the trust that an application has in a user's browser. Note — CSRF vulnerabilities are also referred to as one-click attacks or session riding. CSRF attacks typically affect applications that rely on a user's identity. Attackers can trick the user's browser into sending HTTP requests to a target website. An example of a CSRF attack is a user authenticated by the application through a cookie saved in the browser unwittingly sending an HTTP request to a site that trust the user, subsequently triggering an unwanted action. "Cross-site request forgery(CSRF or XSRF)attacks occur when unauthorized commands are transmitted from an application's trusted user. CSRF attacks differ from XSS attacks because they exploit an application's trust in the user's browser."
10. Understanding Clickjacking Clickjacking involves using multiple transparent or opaque layers to induce into clicking on a web button or link on a page that he or she was not intended to navigate or click. Clickjacking attacks are often referred to as UI redress attacks. User keystrokes can also be hijacked using clickjacking techniques. An attacker can launch a clickjacking attack by using a combination of CSS stylesheets, iframes, and text boxes to fool the user into entering information or clicking on links in an invisible frame that can be rendered from a site the attacker created. According to OWASP, these are the two most common techniques for preventing and mitigating clickjacking: → Send directive response headers to the proper content security policy(CSP)frame ancestor to instruct the browser not to allow framing other domains. → Use defensive code in the application to make sure the current frame is top-level windows. NOTE — The OWASP Clickjacking Defense Cheat Sheet provides additional details about how to defend against clickjacking attacks. The cheat sheet can be accessed at https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet.
11. Exploiting Directory Traversal Vulnerabilities A directory traversal vulnerability can allow attackers to access files and directories that are stored outside the web root folder. Note — Directory traversal has many names, including dot-dot-slash, directory climbing, and backtracking. It is possible to exploit path traversal vulnerabilities by manipulating variables that reference files with the dot-dot-slash ../ sequence and it's variations or by using absolute file paths to access files on the vulnerable system. An attacker can obtain critical and sensitive information when exploiting directory traversal vulnerabilities. The vulnerable application shows the contents of the /etc/passwd file to the attacker. It is possible to use URL encoding, as demonstrated in the following example to exploit directory (path) traversal vulnerabilities: %2e%2e%2f is the same as ../ %2e%2e/ is the same as ../ ..%2f is the same as ../ %2e%2e%5c is the same as .. An attacker can also use several other combinations of encoding — for example, operating system-specific path structures such as / in Linux or macOS systems and in Windows. The following are a few best practices for preventing and mitigating directory traversal vulnerabilities: → Understand how the underlying operating system processes filenames provided by a user or an application. → Never store sensitive configuration files inside the web root directory. → Prevent user input when using file system calls. → Prevent users from supplying all parts of the path. You can do this by surrounding the user input with your path code. → Perform input validation by only accepting known good input. "A directory traversal vulnerability allows attackers to access files and directories stored outside the web root folder. In this case, you were able to access the passwd file located in the/etc directory by traversing the directory structure. The /etc directory is in a separate directory tree from the web page root directory."
12. Cookie Manipulation Attacks Cookie manipulation attacks are often referred to as stored DOM-based attacks. Cookie manipulation is possible when vulnerable application store user input and then embed that input in a response within a part of the DOM. This input is later processed in an unsafe manner by a client-side script. An attacker can use a JavaScript string to trigger the DOM-based vulnerability. Such scripts can write controllable data into the value of a cookie. An attacker can take advantage of stored DOM-based vulnerabilities to create a URL that sets an arbitrary value in o user's cookie. NOTE — The impact of a stored DOM-based vulnerabilities on the role that the cookie plays within the application.

Exploiting File Inclusion Vulnerabilities

1. Local File Inclusion Vulnerabilities A local file inclusion vulnerability occurs when a web application allows a user to submit input into files or upload files to the server. Successful exploitation could allow an attacker to read and execute files on the victim's system. Some LFI vulnerabilities can be critical if a web application is running with high privileges or as root. Such vulnerabilities can allow attackers to gain access to sensitive information and can even enable them to execute arbitrary commands in the affected system.
2. Remote File Inclusion Vulnerabilities Remote file inclusion(RFI)vulnerabilities are similar to LFI vulnerabilities. However, when an attacker exploits an RFI vulnerability, instead of accessing a file on the victim, the attacker is able to execute code hosted on his or her own system. NOTE — RFI vulnerabilities are trivial to exploit; however, they are less common than LFI vulnerabilities.

Exploiting Insecure Code Practices

1. Comments in Source Code Often developers include information in source code that could provide too much information and might be leveraged by an attacker. For example, they might provide details about a system password, API credentials, or other sensitive information that an attacker could find and use. NOTE — "MITRE created a standard called the common weakness enumeration. The CWE lists identifiers that are given to security malpractices or the underlying weaknesses that introduce vulnerabilities. CWE-615, "Information Exposure Through Comments", covers the flaw described in this section. You can obtain details about CWE-615 at https://cwe.mitre.org/data/definitions/615.html."
2. Lack of Error Handling and Overly Verbose Error Handling Improper error handling is a type of weakness and security malpractice that can provide information to an attacker to help him or her perform additional attacks on the targeted systems. Error messages such as error codes, database dumps, and stack traces can provide valuable information to an attacker, such as information about potential flaws in the applications that could be further exploited. A best practice is to handle error messages according to a well-thought-out scheme that provides a meaningful error message to the user, diagnostic information to developers and support staff, and no useful information to an attacker. "Improper error handling can provide information that helps attackers. Error messages such as error codes, database dumps, and stack traces can provide valuable information to an attacker, such as information about application flaws and the type and versions of server software, the frameworks in use, and database type and version. When penetration testing web applications, it is useful to force error to get an understanding of the error handling practices that were included in the code."
3. Hard-Coded Credentials Hard-coded credentials are catastrophic flaws that an attacker can leverage to completely compromise an application or the underlying system. MITRE covers this malpractice(or weakness)in CWE-798. You can obtain detailed information about CWE-798 at https://cwe.mitre.org/data/definitions/798.html.
4. Race Conditions A race condition occurs when a system or an application attempts to perform two or more operations at the same time. However, due to the nature of such a system or application, the operations must be done in the proper sequence in order to be done correctly. When an attacker exploits such a vulnerability, he or she has a small window of time between when a security control takes effect and when the attack is performed. The attack complexity in race conditions is very high. In other words, race conditions are very difficult to exploit. NOTE — race conditions are also referred to as time of check to time of use (TOCTOU)attacks. An example of a race condition is a security management system pushing a configuration to a security device such that the process rebuilds access control lists and rules from the system. An attacker may have a very small time window in which it could bypass those security controls until they take effect on the managed device.
5. Unprotected APIs Application programming interfaces(APIs)are used everywhere. A large number of modern applications use APIs to allow other systems to interact with the application. Unfortunately, many APIs lack adequate controls and are difficult to monitor. The breadth and complexity of APIs also make it difficult to automate effective security testing. There are a few methods or technologies behind modern APIs: → Simple Object Access Protocol(SOAP): This standards-based web services access protocol was originally developed by Microsoft and has been used by numerous legacy applications for many years. SOAP exclusively uses XML to provide API services. XML-based specifications are governed by XML Schema Definition(XSD)documents. SOAP was originally created to replace older solutions such as the Distributed Component Object Model(DCOM) and Common Object Request Broker Architecture(COBRA). You can find the latest SOAP specifications at https://www.w3.org/TR/soap. → Representational State Transfer(REST): This API standards is easier to use than SOAP. It uses JSON instead of XML, and it uses standards such as Swagger and the OpenAPI Specification for ease of documentation and to encourage adoption. → GraphQL: GraphQL is a query language for APIs that provides many developer tools. GraphQL is now used for many mobile applications and online dashboards. Many different languages support GraphQL. You can learn more about GraphQL at https://graphql.org/code. NOTE — "SOAP and REST use the HTTP protocol. However, SOAP is limited to a more strict set of API messaging patterns than REST. As a best practice, you should always use Hypertext Transfer Protocol Secure(HTTPS), which is the secure version of HTTP. HTTPS uses encryption over the Transport Layer Security(TLS) protocol in order to protect sensitive data." API documentation can include the following: → Swagger(OpenAPI): Swagger is a modern framework of API documentation and development that is the basis of the OpenAPI Specification(OAS). Additional information about Swagger can be obtained at https://swagger.io. The OAS specification is available at https://github.com/OAI/OpenAPI-Specification. → Web Services Description Language(WSDL)documents: WSDL is an XML-based language that is used to document the functionality of a web service. The WSDL specification can be accessed at https://www.w3.org/TR/wsdl20-primer. → Web Application Description Language(WADL)documents: WADL is an XML-based language for describing web applications. The WADL specification can be obtained from https://www.w3.org/Submission/wadl. When performing pen testing against an API, it is important to collect full requests by using a proxy such as Burp Suite or OWASP ZAP. (You will learn more about these tools in Module 10.) It is important to make sure that the proxy is able to collect full API requests and not just URLs because REST, SOAP, and other API services use more than just GET parameters. When you are analyzing the collected requests, look for nonstandard parameters and for abnormal HTTP headers. You should also determine whether a URL segment has a repeating pattern across other URLs. These patterns can include a number or an ID, dates, and other valuable information. Inspect the results and look for structured parameter values in JSON, XML, or even nonstandard structures. The following are several general best practices and recommendations for securing APIs: → Secure API services to provide HTTPS endpoints with only a strong version of TLS. → Validate parameters in the application and sanitize incoming data from API clients. → Explicitly scan for common attack signatures, injection attacks often betray themselves by following common patterns. → Use strong authentication and authorization standards. → Use reputable and standard libraries to create the APIs. → Segment API implementation and API security into distinct tiers; doing so frees up the API developer to focus completely on the application domain. → Identify what data should be publicly available and what information is sensitive. → If possible, have a security expert do the API code verification. → Make internal API documentation mandatory. → Avoid discussing company API development on public forums.
6. Hidden Elements Web application parameter tampering attacks can be executed by manipulating parameters exchanged between the web client and the web server in order to modify application data. This could be achieved by manipulating cookies and by abusing hidden form fields. It might be possible to tamper with the values stored by a web application in hidden form fields. Let's take a look at an example of a hidden HTML form field. Suppose that the following is part of an e-commerce site selling merchandise to online customers: <input type="hidden" id="123" name="price" value="100.00"> In the hidden field shown in this example, an attacker could potentially edit the value information to reduce the price of an item. Not all hidden fields are bad; in some cases, they are useful for the application, and they can even be used to protect against CSRF attacks.
7. Lack of Code Signing Code signing (or image signing) involves adding a digital signature to software and applications to verify that the application, operating system, or any software has not been modified since it was signed. Many applications are still not digitally signed today, which means attackers can easily modify and potentially impersonate legitimate applications. Code signing is similar to the process used for SSL/TLS certificates. A key pair (one public key and one private key) identifies and authenticates the software engineer (developer) and his or her code. This is done by employing trusted certificate authorities (CAs). Developers sign their applications and libraries using their private key. If the software or library is modified after signing, the public key in a system will not be able to verify the authenticity of the developer's private key signature. Sub resource Integrity (SRI) is a security feature that allows you to provide a hash of a file fetch by a web browser (client). SRI verifies file integrity and ensures that files are delivered without any tampering or manipulation by an attacker.
8. Additional Web Application Hacking Tools Many ethical and malicious hackers use web proxies to exploit vulnerabilities in web application. A web proxy, in this context, is a piece of software that is typically installed in the attacker's system to intercept, modify, or delete transaction between a web browser and a web application. Two of the most popular web proxies used to hack web application are Burp Suite and ZAP. Burp Suite is a collection of tools and capabilities, one of which is a web proxy. Burp Suite, also simply known as "Burp", comes in two different versions: the free Burp Suite Community Edition and the paid Burp Suite Professional Edition. TIP — Burp Suite was created by a company called Portswigger, which has a very comprehensive (and free) web application security online course at https://portswigger.net/web-security. This course provides free labs and other materials that can help you prepare for the PenTest+ and other certifications. OWASP ZAP is a collection of tools including proxy, automated scanning, fuzzing, and other capabilities that can be used to find vulnerabilities in web applications. You can download OWASP ZAP, which is free, from https://www.zaproxy.org. Figure 6–26 shows how OWASP ZAP is used to perform an automated scan of a vulnerable web application. In this example, OWASP ZAP found two vulnerable JavaScript libraries that an attacker could leverage to compromise the web application.