Answers: Module 01 — Introduction to Ethical Hacking¶

Answer Key¶

Easy Questions¶

Q1: The single most important difference is authorization. An ethical hacker has explicit written permission from the system owner to test the systems in question. A malicious attacker does not. The tools and techniques are often identical; the legality and ethics depend entirely on authorization.

Q2: CFAA stands for the Computer Fraud and Abuse Act (18 U.S.C. § 1030). It prohibits accessing a computer "without authorization" or in a way that "exceeds authorized access." It does not require causing damage — the unauthorized access itself is a federal crime.

Q3: The five phases in order: 1. Reconnaissance (information gathering) 2. Scanning (port/service/vulnerability enumeration) 3. Exploitation (proving vulnerabilities are exploitable) 4. Post-Exploitation (determining impact, lateral movement) 5. Reporting (documenting findings with evidence and remediation)

Q4: Any three of: DVWA (Damn Vulnerable Web Application), Metasploitable (2 or 3), HackTheBox, TryHackMe, VulnHub machines, picoCTF, OverTheWire, PentesterLab, WebGoat (OWASP)

Q5: CVE stands for Common Vulnerabilities and Exposures. It is maintained by MITRE, funded by the US Department of Homeland Security (CISA). Each CVE has a unique identifier in the format CVE-YYYY-NNNNN.

Medium Questions¶

Q6: The CIA Triad: - Confidentiality — data is only accessible to authorized parties. Example attack: An attacker exploits an IDOR vulnerability to read another user's private messages. A data breach where customer records are exfiltrated violates confidentiality. - Integrity — data has not been tampered with. Example attack: An attacker with SQL injection access modifies account balances in a banking database. A supply chain attack that injects malicious code into a software package violates integrity. - Availability — the system is accessible when needed. Example attack: A Distributed Denial of Service (DDoS) attack floods a web server with traffic, making it inaccessible to legitimate users.

Q7: This is unauthorized access regardless of good intentions. The CFAA does not have an exception for good intent or responsible disclosure — testing out-of-scope systems is illegal. Professionals must: immediately stop testing the out-of-scope system; note the discovery in their report as "observed out-of-scope system at [URL], no testing was performed"; consider contacting the company separately via responsible disclosure channels (security@company.com) if they have a responsible disclosure policy, without testing the out-of-scope system.

Q8: - Passive reconnaissance — gathering information without directly interacting with the target. Examples: WHOIS lookups, Google dorking, searching Shodan, reviewing LinkedIn for employee names, checking certificate transparency logs for subdomains. - Active reconnaissance — directly interacting with the target system. Examples: port scanning with nmap, banner grabbing, web crawling with a spider, making HTTP requests to discover endpoints. Active recon may be detectable by the target's monitoring systems.

Q9: Post-exploitation determines the real-world business impact of a vulnerability. Simply demonstrating exploitability ("I got a shell") is not enough for a professional report — a client needs to understand what an attacker could actually do: what data they could access, whether they could move to other systems, whether they could maintain persistent access. A medium-severity SQL injection that exposes 10,000 customer credit card numbers is a much more serious business finding than a high-severity vulnerability in a system containing no sensitive data. Impact justifies remediation priority.

Q10: A trust boundary is a point in a system where data crosses from one trust level to another — where the system begins trusting the data provided without fully verifying its integrity or safety. Web application examples: 1. The web application trusts the user's session cookie to identify who is logged in — if the cookie can be forged or stolen, the trust boundary is exploited (session hijacking). 2. The database trusts the SQL query sent by the application layer — if user input is embedded unsanitized in that query, the trust boundary is exploited (SQL injection). Other examples: HTTP headers trusted by the server, JSON/XML data trusted by deserialization code, file paths provided by the user trusted by the filesystem layer.

Hard Questions¶

Q11: - Immediately: Stop all testing against the external system. Log the exact time and the single request made (URL, HTTP method, response code). Do not attempt further access. - In the report: Include a section noting the incident: "During testing on [date] at [time], a redirect from [in-scope system] led to an HTTP GET request to [external URL]. Testing was immediately halted. No further requests were made to the out-of-scope system. We recommend the client review whether this redirect is intended and whether the third-party system is properly secured." - Lesson: Scope boundaries can be crossed accidentally through redirects, API calls, or application navigation. Rules of Engagement should specify what to do when out-of-scope systems are encountered. Testers should configure their tools to alert when a request would go to an out-of-scope domain.

Q12: Four vulnerabilities in the form: 1. GET method for credentials — Using GET sends credentials in the URL query string, which is logged by web servers, proxies, and browser history. Fix: use method="POST". 2. HTTP not HTTPS — The form submits to http:// not https://, meaning credentials travel in plain text over the network. Fix: use HTTPS everywhere; enforce HTTPS with HSTS. 3. redirect hidden field (Open Redirect) — An attacker can craft a URL like ?redirect=https://evil.com to redirect users to a phishing site after login. Fix: validate redirect targets server-side against an allowlist of internal paths. 4. role hidden field (Privilege Escalation / Mass Assignment) — A hidden field with the user's role means an attacker can change their own role by modifying the form. Fix: never trust client-supplied role/permission data. The role must be determined server-side based on the authenticated identity.

Q13: Example correct implementation:

# AUTHORIZED TESTING ONLY - Use only against systems you have
# explicit written permission to test. Never use against
# systems you do not own or have authorization to test.

import time
import urllib.request
import urllib.parse
import datetime

TARGET_URL = "http://localhost/login"  # Hardcoded for safety

# Safety check: only allow localhost or RFC 1918 addresses
def is_authorized_target(url: str) -> bool:
    """Only allow testing against local/private network targets."""
    allowed_prefixes = ("http://localhost", "http://127.", "http://192.168.", "http://10.")
    return any(url.startswith(prefix) for prefix in allowed_prefixes)

def test_username(username: str, password: str = "test") -> str:
    """Send a single login attempt and return the response status."""
    data = urllib.parse.urlencode({"username": username, "password": password}).encode()
    try:
        req = urllib.request.Request(TARGET_URL, data=data, method="POST")
        with urllib.request.urlopen(req) as response:
            return f"HTTP {response.status}"
    except Exception as e:
        return f"Error: {e}"

if not is_authorized_target(TARGET_URL):
    print("[-] Safety check failed: target is not a local/private network address.")
    print("    This script must only be used against authorized targets.")
    exit(1)

with open("usernames.txt") as f:
    usernames = [line.strip() for line in f if line.strip()]

for username in usernames:
    timestamp = datetime.datetime.utcnow().isoformat()
    result = test_username(username)
    print(f"[{timestamp}] Tested '{username}': {result}")
    time.sleep(2)  # Rate limit: 1 request per 2 seconds

Q14: - Morris Worm (1988): Exploited buffer overflow in fingerd, sendmail debug mode, and rsh/rexec. Intent was reportedly experimental (curiosity about internet size) rather than malicious, but the worm reproduced aggressively. Impact: ~6,000 machines infected (10% of the internet), \(10M-\)100M in damages. Lesson: Default-deny network access, keep services updated, defense-in-depth. - WannaCry (2017): Exploited EternalBlue (CVE-2017-0144), an NSA-developed exploit for Windows SMB. Intent was clearly criminal (ransomware). Impact: 200,000+ systems in 150+ countries infected, hundreds of millions in damages, NHS operations disrupted. Lesson: Critical patches must be applied urgently; nation-state exploit hoarding creates catastrophic risk when tools are stolen/leaked; network segmentation limits blast radius.

Expert Questions¶

Q15: Expense Report Application Threat Model:

Assets: - Employee financial data (expense amounts, receipts — PII and financial) - Authentication credentials - Uploaded file content (PDFs, images — may contain sensitive business data) - MySQL database (all stored expense records) - Email credentials/SMTP configuration

Trust Boundaries: - Internet → Web Application (user input via browser) - Web Application → MySQL Database (SQL queries) - Web Application → File Storage (uploaded files) - Web Application → Email Server (outbound notifications) - Employee → Manager (approval workflow)

Entry Points and Vulnerability Classes:

Top 3 Threats (prioritized by likelihood × impact): 1. IDOR on expense records — High likelihood (common in CRUD apps), high impact (one employee viewing all others' financial data). Priority: Critical. 2. Malicious file upload — Moderate likelihood, potentially critical impact (RCE if server executes uploaded PHP/script). Priority: High. 3. Stored XSS via description field — High likelihood (managers render submitted data), high impact (session hijacking of manager accounts). Priority: High.

Q16: Full credit for essays that accurately represent both positions and make a defensible argument. Key points that should appear:

• Full disclosure argument: Vendors delay patching without public pressure; public knowledge enables users to take mitigating action; vendors minimize severity without transparency; the security community benefits from shared knowledge.
• Coordinated disclosure argument: Immediate disclosure harms users before patches are available; most organizations need more than 90 days for complex patches; responsible disclosure with a timeline is a fair middle ground; burning zero-days publicly may destabilize systems that cannot be patched quickly (ICS/SCADA, medical devices).
• Strong answer: The 90-day coordinated disclosure timeline (pioneered by Google Project Zero) is a well-reasoned compromise. For an open-source library critical vulnerability: notify the maintainers immediately with full details; offer to help with the fix; publish after 90 days regardless of patch status (with a warning to users). Note that for actively exploited zero-days, publication should be immediate to protect users.

Grading Records¶