Unit 3: Headers · Lesson 5 of 5 · 22 min

Case file: finding a vulnerable library in hours

Use software bills of materials to answer the question Log4Shell forced on everyone: where do we run this library, and who owns it?

case file

Log4Shell

Apache Software Foundation (Log4j) and its users worldwide · 2021

A critical flaw (CVE-2021-44228) in the Log4j 2 logging library was disclosed in December 2021 and exploited at scale almost immediately. Because Log4j sits inside countless Java applications, many organisations could not quickly tell where they were exposed.

What went wrong

A lookup feature in log4j-core processed untrusted text written to logs, and organisations lacked inventories of where the library was used, which slowed patching.

What would have stopped it

  • Keep software bills of materials so a vulnerable component can be located within hours.
  • Upgrade to fixed releases and remove risky features you do not use.
  • Restrict outbound connections from application servers.
  • Give every application a named owner so fixes have someone to land with.

What defenders could have seen

  • Dependency scanner or SBOM match for log4j-core in an affected version range.
  • Unexpected outbound connections from Java application servers.

sourceslogging.apache.orgcsoonline.com

mission

You are
The analyst asked one question by the CISO: are we affected?
Situation
Headers tell you what product a server runs, but not what is inside it. The shop keeps a software bill of materials (SBOM) for each of its five Java apps.
Goal
Find every app with a vulnerable log4j-core, rank them by exposure and name an owner for each.
Hand in
A list of affected apps, their versions, whether they face the internet and who fixes them.

From advisory to fix

  1. AdvisoryComponent and affected versions
  2. SBOM searchWhich apps contain it
  3. ExposureInternet-facing first
  4. OwnerSomeone accountable
  5. Upgrade and verifyNew SBOM proves it
01

What does a header reveal?

learner@web-lab
curl -sI http://127.0.0.1:8000/ | grep -i '^server'
Server: shop/1.4

you should see A product and version, nothing about the libraries inside. You need an inventory for that.

02

Find every copy of the library

learner@web-lab
grep -l '"log4j-core"' cases/inventory/sbom-*.json
cases/inventory/sbom-billing.json
cases/inventory/sbom-legacy-admin.json
cases/inventory/sbom-reports.json
cases/inventory/sbom-search.json
for f in cases/inventory/sbom-*.json; do jq -r '.metadata.component.name as $a | .components[] | select(.name=="log4j-core") | $a + " " + .version' $f; done
billing 2.17.1
legacy-admin 2.11.2
reports 2.14.1
search 2.20.0

you should see Four of five apps include log4j-core. Storefront uses a different logger.

03

Compare with the fixed version

The fully fixed line for Java 8 and later is 2.17.1. sort -V sorts version numbers the way people read them.

learner@web-lab
printf '%s\n' 2.17.1 2.14.1 2.20.0 2.11.2 | sort -V
2.11.2
2.14.1
2.17.1
2.20.0

you should see Anything sorted before 2.17.1 needs an upgrade: 2.11.2 and 2.14.1.

04

Rank by exposure and find owners

learner@web-lab
grep -E '^(reports|legacy-admin),' cases/inventory/owners.csv
reports,finance-eng,no
legacy-admin,unknown,yes

you should see legacy-admin faces the internet and has no known owner, so it goes first and someone must be assigned. reports is internal.

defender tip An app with no owner is a finding in its own right. Log4Shell lingered longest in exactly those systems.

What a defender takes away

  1. 1Response speed depends on the inventory you already have.
  2. 2An SBOM per app turns are we affected into one search.
  3. 3Fix internet-facing apps first, and give every app an owner.

Questions

0 of 3 solved

Answer each one from what you find on your lab machine.