Lecture Notes

This lecture will focus on information leakage from chatty protocols and banners.

Download here

Practical tasks

These exercises aim to explore how attackers can enumerate systems and gather information by using commonly available tools and, where appropriate, custom-developed ones. The objective is not primarily to exploit the hosts in the laboratory, but to become familiar with the tools and to practice assessing vulnerabilities in distributed systems. The activities then move into the analysis of information leakage in different formats and service types.

Everything you do here is backed by a live CTF: the lab runs a CTFd instance with a set of information-disclosure challenges (category infoleak, plus network and web). Solving a challenge means submitting the flag you found. Challenge names are deliberately opaque — the description you see in CTFd is a haiku, not a hint.

The lab you will be assessing

The student-facing tier is the service plane 10.110.3.0/24. It is the only lab network your instance can reach (besides your own gateway and the internet) — the management planes, the campus network and the other students’ desktops are dropped by design. Almost everything student-facing lives on one host:

DNS: the lab’s dnsmasq serves the local deti zone. lab-services.deti resolves to 10.110.3.72, and a wildcard *.chal.deti also resolves there — so every challenge name below is a valid DNS name whether or not you guessed it. That has consequences for “host discovery” (Task 1, item 4).

Challenge inventory (student-facing)

The four stock web apps (juiceshop, bwapp, dvwa, mutillidae) are visible on the wire and are fair game for enumeration in this lecture; exploiting them is covered by other exercises. leak4 carries a shared flag (identical for everyone); every other challenge derives a per-student flag, so a flag you found on a friend’s machine is not your flag.

What is on your desktop

The environment (Debian 13) ships with: nmap, dirb, gobuster, ffuf, sqlmap, netcat, curl/wget, python3 (with pwntools and requests), tcpdump, wireshark, exiftool, binwalk, git, gdb, build-essential, podman, plus Firefox and Burp Suite (GUI). wpscan, scapy and the snmp* clients are not preinstalled — you are root in your own container, so install what you need (apt install snmp wpscan, pip install scapy).

Rules of Engagement

• Scope: all of 10.110.3.0/24 — in particular 10.110.3.72 and every *.chal.deti name. Your firewall drops everything else inside the lab (management planes, campus, peer students); that is by design, not a bug to work around.
• Activities: the assessment should not attempt to perform penetration testing on the systems; limited exploration is allowed when necessary. No exploitation beyond what a challenge asks for, no attempts to take a host down.
• Load: 33 students share one service host. Keep scans polite — nmap -T3 or lower for version scans, small port sets and few retries for UDP, low parallelism for content scans.
• CIA: No data should be corrupted, no credentials should be modified, and availability must not be compromised. The stock apps have login forms; use the accounts they hand out, don’t spray.
• Reporting: Any abnormal behavior must be reported (a challenge returning 500s, a host that stops answering, DNS behaving oddly).

Information Gathering

This work is aligned with the OWASP PTES and especially with the Information Gathering - Internal Footprinting section. It is important to adopt a structured approach to the task. All outputs should be saved, and your findings should be documented clearly. We recommend following the reporting guidelines for OWASP PTES.

Work in a folder per target:

infoleak/
├── 10.110.3.72/
│   ├── scan-discovery.txt      # nmap -sn
│   ├── scan-versions.txt       # nmap -sV
│   ├── scan-udp.txt            # nmap -sU
│   ├── vulners.txt             # nmap --script vulners
│   ├── web/
│   │   ├── leak1-dirb.txt
│   │   └── ...
│   └── notes.md
└── report.md

Task 1 — Host discovery and service mapping

The first task is to understand your environment: how many hosts are available and what services they expose. To discover hosts, you can use any tool that sends packets into the network and receives responses. An ICMP ping may be sufficient, or you can build your own tools using sockets or Python Scapy. You can also use netcat and nmap.

The go-to tool is usually nmap, as it is both powerful and relatively simple to use. Open a terminal and run nmap -h or consult the manual with man nmap.

• Want to scan a network? nmap -sn 10.110.3.0/24
• Want to scan a host? nmap 10.110.3.72
• Want to enumerate the version of each service? nmap -sV 10.110.3.72
• Want to identify the operating system of a host? nmap -O 10.110.3.72
• Want to see the UDP side? nmap -sU -pU 8024 10.110.3.72

There are many flags that influence this tool’s behavior. You can make it more or less aggressive with -T, specify ports to scan, use -PS, and much more. Save every run: -oN file.txt (plain), -oX (XML, for later processing), -oG (grepable).

Tasks

1. How many hosts are there on 10.110.3.0/24? Which addresses answer, and what do you think each one is? (Hint: not all of them are challenges.)
2. Build a port → service → challenge map for 10.110.3.72: which port belongs to which challenge name? Cross-check your map against DNS and against what CTFd lists.
3. Find the UDP service. Which protocol speaks it, and what does it volunteer when you ask? (It is a challenge — solve it and submit the flag.)
4. DNS work: confirm the *.chal.deti wildcard, enumerate which names resolve, and note what a wildcard does to your host-discovery assumptions (e.g. why a “no response” from a name is not proof the service is down).
5. Fingerprint the stack: which challenges share the same Server banner / headers? What does that tell you about how they were built and maintained?
6. Write a short discovery report: hosts, services, stack, surprises.

Task 2 — Version and CVE enumeration

Using nmap -sV, it is possible to infer the version of the software running on each service. This information can then be cross-referenced with public repositories such as CVE Details or NVD, allowing an initial assessment of public vulnerabilities, expressed as CVEs. In this case, the assessment is based on public vulnerabilities, but it may miss custom vulnerabilities or configuration flaws. Furthermore, hosts may deliberately misrepresent the software they are running or the versions they expose.

An interesting feature of nmap is that it allows you to run specially crafted scripts that automate many tasks. From the perspective of an assessment, these scripts can test for the existence of specific vulnerabilities or enumerate issues based on the versions of the software detected. You can list the scripts by inspecting /usr/share/nmap/scripts/; the single-purpose ones worth running here include http-enum, http-headers, http-title, http-robots.txt, snmp-info and the catch-all vulners.

Tasks

1. Enumerate the software versions for every service on 10.110.3.72.
2. Run nmap -sV --script vulners 10.110.3.72 and triage the output: which findings are real, which are noise?
3. For the stock web apps (juiceshop, bwapp, dvwa, mutillidae, wordpress): identify the exact version of each component (core, framework, bundled libraries), list the applicable CVEs, and rank them. The WordPress core is older than it should be — how far does that get you?
4. Are any CVEs critical? What recommendations would you make from this assessment? Be realistic: there is no such thing as perfect security.
5. Write your conclusions in your notes and support them with the logs obtained from running the tools.

Task 3 — Web content discovery

Some machines host a web page, and the scope of this assessment also includes these services. Web pages present a different challenge from network discovery because the services they expose are richer and more complex, and therefore often less secure. Web portals are a common path to compromising a system’s security.

For this lecture we focus on configuration and content issues. Classic injection bugs (SQLi, LFI, IDOR, XSS) are covered by dedicated exercises — but the xss* and notes1 challenges are on the wire, and enumerating them (what do they expose before you exploit them?) is in scope here.

Three content-discovery tools are preinstalled: dirb, gobuster and ffuf. All three are dictionary attacks against a web server that analyze the responses; they differ in speed, flexibility and wordlist handling. dirb is the classic, gobuster its maintained successor, ffuf the fast and most flexible of the three.

dirb  http://leak1.chal.deti:8010 /usr/share/wordlists/dirb/common.txt
gobuster dir -u http://leak1.chal.deti:8010 -w /usr/share/wordlists/dirb/common.txt
ffuf -u http://leak1.chal.deti:8010/FUZZ -w /usr/share/wordlists/dirb/common.txt

DIRB includes a set of preconfigured attack wordlists for easy use, but you can also use custom wordlists (try gobuster’s lists and SecLists). A limitation shared by all three is that their effectiveness depends heavily on the quality of the wordlist — if the chosen wordlist is not suitable for the host, it may find little or nothing. This is why several wordlists are available.

Before any of them, do the 404 baseline by hand: request a path you know does not exist and record the exact status, headers and body length. Every scanner is only as good as its 404 detection, and a host that returns 200 for everything (or 404 with a full HTML page) will defeat naive filtering.

For the WordPress host, wpscan is the specialist (not preinstalled — apt install wpscan): it enumerates plugins, themes, users and known vulnerabilities of a remote WordPress installation. Its results are only valid for WordPress, which is why the other tools remain the general purpose workhorses.

It should be noted that while automated tools are useful for discovering issues quickly, they should always be complemented by a thorough manual assessment.

Tasks

1. Run a content scan against every leak* host and notes1. Save the output (one file per host). Which hosts expose something they should not?
2. For each hit, classify the leak (backup file, hidden route, directory listing, VCS metadata, robots directive, …) and note the exact URL that produced it.
3. Repeat one scan with a different wordlist. What did you miss the first time?
4. WordPress: run wpscan (or do it by hand), record the core version, the plugin/theme inventory, and the CVEs that apply to this installation.

Task 4 — The infoleak suite, one by one

Each leak* challenge hides exactly one flag behind one class of information leakage. Work them in difficulty order. For each: find the leak, record the exact request that produced the flag, and submit the flag to CTFd. The “starting point” column tells you where to look — it does not tell you what you will find.

Tasks

1. Solve all ten. For each, write down: the class of the leak, the exact request (a curl command or raw HTTP), and the response fragment that carried the flag.
2. leak7: write your own client (python3 + requests is enough). How many requests does your reconstruction need? What character set did you assume, and how did you verify it?
3. leak5: which field should never have been serialized? What would you change in the API to fix the leak without breaking the client?
4. leak6: decode the token by hand (base64url, no library). What part is signed, what part is not — and why is that the whole problem?
5. leak4: the flag is in the history, not in the working tree. Which files in the exposed VCS directory do you read first, and why?
6. snmp1: walk the tree (snmpwalk -v2c -c public snmp1.chal.deti 1.3.6.1). Separate the standard MIB-II data (system group, interface table) from the private enterprise tree. Which node is generated on demand, and what does that imply about what the agent can be made to execute?
7. notes1: you have a guest account. Enumerate what the app shows you, then ask for what it does not. (This one is web category — the leak is in the access model, not the content.)

Task 5 — Manual techniques (no scanner)

Repeat the discovery with only curl, a browser and your eyes. This is the skill the scanners are training; the scanners exist because doing this by hand is slow, not because it is optional.

Tasks

1. 404 baseline. For three different hosts, record the exact response (status, headers, body length) for a nonexistent path. Why does this matter for every other technique you use?
2. Headers. Compare Server, X-Powered-By, Set-Cookie and the presence/absence of Content-Security-Policy across the leak* hosts and the stock apps. What does each header leak?
3. Methods. curl -X OPTIONS and curl -X TRACE against a few hosts. What do the Allow headers say, and which hosts answer TRACE at all?
4. JavaScript. Download and read the JavaScript of the API host. What constants does the client carry that the server never advertises?
5. Tokens. Capture a session artifact (cookie or token) from two hosts. Compare the formats. Which one can you read without a key, and what did reading it give you?
6. Fuzz by hand. Pick one host and probe ten paths of your own choosing (no wordlist, no scanner). What did you find that the scanner missed — and what did the scanner find that you did not?

Task 6 — Hardening report

For each host you assessed, write the recommendations you would give the owner: banner suppression, directory listing off, backup files out of the web root, VCS directories removed, debug routes deleted, tokens redesigned so secrets never ride in the payload, SNMP communities rotated (and the private tree gated), error handlers made quiet. Rank the recommendations by (impact, effort) and say which one you would do first.

Deliverable

One report.md per target folder plus a top-level summary, following the PTES reporting guidelines:

1. Scope and method (tools, versions, exact flags used).
2. Host and service inventory (your table from Task 1).
3. Findings: one section per leak class — what was exposed, the evidence (exact request + response fragment), severity, recommendation.
4. CVE table: software, version, CVE, CVSS, your note on exploitability in this lab.
5. What the automated tools found versus what you found manually.
6. Open questions and anything you could not determine.

Further activities

• In TryHackMe, review the following modules:
  • Network Exploitation Basics
  • Web Hacking Fundamentals
  • Basic Computer Exploitation
  • Introduction to Pentesting
  • Intro to Web Hacking
• Read the OWASP WSTG information-gathering chapters (WSTG-INFO) and map each technique to one of the tasks above.