Video summary

Hackeo Ético: Exponiendo Vulnerabilidades en Altoro Mutual (IBM) - Análisis Completo

Main summary

Key takeaways

Educational

Main ideas and lessons

  • The video demonstrates an ethical hacking / vulnerability assessment workflow against the Altoro Mutual web page (IBM context). It emphasizes that you should first understand the target’s exposed services before testing application features.
  • Recon/scan results help determine what to test next—for example, identifying the stack (such as Apache/Tomcat) and the possibility of proxy services.
  • It highlights common, high-impact web application flaws:
    • Cross-Site Scripting (XSS) via an unsafe search form.
    • SQL Injection (SQLi) via improper handling of login input (username field), enabling authentication bypass and unauthorized admin access.
  • It also notes weak access control patterns:
    • Unprotected endpoints/sections accessible directly with GET requests without proper authorization checks, leading to exposure of data that should be restricted.

Step-by-step methodology (as presented)

  1. Identify the running web service

    • Use a port/service scan to determine what the host is running and the operating system.
    • Run Nmap with options intended to:
      • produce verbose output
      • inspect all open ports
      • identify services on those ports
      • infer the operating system
  2. Interpret scan results

    • Extract from the report:
      • IP address and latency
      • open ports and associated services
      • notable findings, such as:
        • Port 80: HTTP, with indications of Apache/Tomcat (Java-based services)
        • Port 443: HTTPS
        • a discovered proxy service (described as an “open proxy”)
      • OS fingerprinting results (described as an aggressive assumption, e.g., FreeBSD 6.2x release)
  3. Validate normal user behavior

    • Do a “baseline” interaction with the site:
      • log in using a username and password
      • view typical functions like account summary, transactions, transferring funds, and news
      • change language settings (e.g., international vs English)
  4. Test for vulnerabilities found in the application

    • XSS test (critical)

      • Target the search form.
      • Inject a script payload into the search input.
      • Because the application doesn’t treat input as safe text (it fails to properly sanitize/encode), the script executes.
      • The example payload demonstrates access to user session/cookies (e.g., triggering an alert referencing cookies) and notes the session is already present/saved.
    • SQL Injection test (critical)

      • Target the username field in the login.
      • Use input that:
        • closes quotes
        • adds a condition that is always true
        • bypasses password requirements
      • Result:
        • the login maps to the first matching user in the database (described as an administrator)
        • the attacker gains admin-level access (account access, transfers, user management)
    • Admin surface discovery

      • Inspect a GitHub repository:
        • find a web contents/admin subdirectory
        • observe JSP files consistent with Tomcat
      • Find an administrator login page and note that a password is exposed in page source/comments (as described), enabling admin login.
    • Broken access control via direct GET access

      • Note that “sections” can be reached without proper page navigation by using direct GET requests.
      • Because there’s no consistent permission verification per file/endpoint:
        • sensitive resources (e.g., an XML document) are accessible publicly
        • restricted publication data can be retrieved via query-like access patterns (publication ID/date/title/audience), even when the site indicates some items “should not be public.”

Main vulnerabilities/concepts explicitly conveyed

  • Cross-Site Scripting (XSS) through the search form

    • Root issue: input not properly validated/sanitized/encoded as plain text.
    • Impact shown: malicious script execution; ability to access session-related data (cookies).
  • SQL Injection (SQLi) in the login username parameter

    • Root issue: unsafe SQL query construction based on user input.
    • Impact shown: authentication bypass and admin impersonation with full access.
  • Information exposure / weak authorization

    • Root issue: endpoints/sections accessible via direct GET requests without permission checks.
    • Impact shown: exposure of sensitive XML/publishing metadata and responses that should be restricted.

Speakers / sources featured

  • Speakers: Not clearly identified (no explicit speaker name provided in the subtitles).
  • Sources/tools mentioned:
    • Nmap (for port scanning and OS/service fingerprinting)
    • GitHub repository (inspected for admin/JSP/admin-page information)
  • Target system/application mentioned:
    • Altoro Mutual (IBM J… page referenced; exact platform wording appears truncated)

Original video