CVE‑2014‑6271 — “Shellshock”

Co znajdziesz w tym artykule?

1 TL;DR
2 Krótka definicja techniczna
3 Gdzie występuje / przykładowe platformy
4 Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)
5 Artefakty i logi
6 Detekcja (praktyczne reguły)
7 Heurystyki / korelacje (co łączyć)
8 False positives / tuning
9 Playbook reagowania (IR)
10 Przykłady z kampanii / case studies
11 Lab — przykładowe kroki
12 Mapowania (Mitigations, powiązane techniki)
13 Źródła / dalsza literatura
14 Checklisty dla SOC / CISO

TL;DR

Shellshock (CVE‑2014‑6271) to krytyczna podatność RCE w GNU Bash (do 4.3 włącznie), która pozwala na wykonanie komend podczas parsowania zmiennych środowiskowych zawierających definicje funkcji. W praktyce była nadużywana głównie przez wektory HTTP/CGI (np. mod_cgi), ale także przez OpenSSH ForceCommand, klientów DHCP i inne komponenty, w których Bash jest odpalany po przekazaniu środowiska. Z perspektywy ATT&CK najlepiej mapuje się na T1190 (Initial Access), a dalsze uruchamianie komend — na T1059.004 (Unix Shell).

Krótka definicja techniczna

CVE‑2014‑6271 wynika z błędu w sposobie, w jaki Bash importuje funkcje ze środowiska: trailing‑string po definicji funkcji może zostać zinterpretowany jako komenda i wykonany w nowym procesie powłoki. Jeśli napastnik kontroluje wartości nagłówków/parametrów (np. przez CGI), osiąga zdalne wykonanie kodu (RCE) bez uwierzytelnienia.

Gdzie występuje / przykładowe platformy

Linux/UNIX (w tym macOS): serwery WWW z CGI (mod_cgi, mod_cgid), skrypty powłoki, usługi systemowe.
OpenSSH (ForceCommand): możliwość wstrzyknięcia przez SSH_ORIGINAL_COMMAND przy logowaniu do powłoki Bash.
Klienci DHCP (np. dhclient): złośliwe opcje DHCP jako nośnik.
Aplikacje/appliance’y sieciowe i środowiska kontenerowe: skrypty entrypoint, obrazy z podatnym Bashem; jeśli endpoint jest publiczny → T1190.
ESXi/appliance’y: niektóre systemy oparte o BusyBox/Bash (rzadziej), ale T1190 obejmuje też urządzenia brzegowe.
Chmury (AWS/Azure/GCP): po RCE na serwerze/pojemniku często obserwuje się dostęp do IMDS (169.254.169.254) w celu kradzieży poświadczeń — dalsze fazy.
AD/M365: brak typowych wektorów dla Shellshock — wpływ pośredni po uzyskaniu przyczółka na hostach Linux.

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

Bash umożliwia „eksport” funkcji przez zmienne środowiskowe. W podatnych wersjach parser Basha wykonywał łańcuchy znaków następujące po definicji funkcji, co otwierało drogę do RCE, jeśli napastnik mógł wstrzyknąć zawartość środowiska (np. przez nagłówki HTTP obsługiwane przez CGI). Pierwsza łatka okazała się niepełna (CVE‑2014‑7169), co dodatkowo zwiększyło okno ryzyka. Skuteczność ataku wynikała z: (1) powszechności Basha, (2) prostoty ładunku, (3) wielu wektorów przekazania środowiska przez granicę zaufania (HTTP, SSH, DHCP). W efekcie w ciągu godzin od ujawnienia obserwowano zautomatyzowane skanowanie i budowanie botnetów DDoS.

Artefakty i logi

Warstwa	Źródło	Pole / EID	Wskaźnik / wzorzec	Notatki
Aplikacja WWW	Apache/nginx access/error	`User-Agent`, `Referer`, `URI`, status	Wzorzec funkcji Basha w nagłówkach/parametrach (np. sekwencja funkcja+trailing)	Często wzrost 4xx/5xx przed właściwym RCE
System (Linux)	`auditd`	`type=EXECVE`	Rodzic: `httpd`/`apache2`/`nginx`/`cgi-fcgi` → dziecko: `/bin/bash -c …`	Łańcuch procesów po RCE
System (Linux)	`syslog`/journald	komunikaty serwisu WWW/CGI	Nagłe spawny powłoki, błędy CGI	Koreluj z access logami
EDR/telemetria	Procesy/sieć	—	`bash` uruchomiony przez konto serwisu WWW + wyjścia do Internetu	W tym wywołania narzędzi typu `curl/wget`
Chmura AWS	CloudTrail	`userAgent`, `sourceIPAddress`, `eventName`	Po RCE — nagłe API (np. `ListBuckets`, `GetCallerIdentity`, `AssumeRole`) z roli instancji / nietypowe UA	Często po próbie dostępu do 169.254.169.254 (IMDS) z hosta ofiary.
K8s	Audit log	`verb`, `objectRef`, `userAgent`	Niespodziewane `create pods/exec`/`attach` z SA serwisu WWW; enumeracja `secrets`	Efekt wtórny po RCE w podzie
M365	Unified Audit Log	—	[brak bezpośredniego wektora]	Koreluj tylko, gdy atak przechodzi w chmurę SaaS

Detekcja (praktyczne reguły)

Sigma (HTTP/CGI — próby Shellshock)

title: Possible Shellshock Attempt in HTTP Headers
id: 6b7e2d8d-2a0e-4b6b-9c5f-3d7a5f2d1b01
status: experimental
description: Wykrywa klasyczne wzorce importu funkcji Bash w nagłówkach/URI (np. wzorzec funkcja + trailing), charakterystyczne dla Shellshock.
author: Badacz CVE
date: 2025/11/08
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2014-6271
tags:
  - attack.T1190
  - cve.2014-6271
logsource:
  category: webserver
detection:
  sel_any_header:
    c-uri|contains:
      - "(){"
      - "%28%29%7B"    # URL‑encoded
    cs-user-agent|contains:
      - "(){"
      - "%28%29%7B"
    cs-referer|contains:
      - "(){"
      - "%28%29%7B"
  condition: sel_any_header
fields:
  - src_ip
  - http.request_referrer
  - http.user_agent
  - url
  - status
falsepositives:
  - Skany bezpieczeństwa/WAF test strings
level: high

Splunk (web access → wzorzec + łańcuch procesów)

(index=web OR index=proxy) (sourcetype=apache:* OR sourcetype=nginx:* OR sourcetype=haproxy*)
| eval raw=coalesce(cs_User_Agent," ") . " " . coalesce(cs_Referer," ") . " " . coalesce(uri," ") . " " . coalesce(query," ")
| where match(raw, "\\(\\)\\s*\\{\\s*:\\s*;\\s*\\}")
| stats count earliest(_time) as first latest(_time) as last by src_ip, cs_User_Agent, uri, status

Korelacja (Splunk) — procesy na hoście Linux (jeśli zbierasz dzienniki systemowe/EDR):

index=os_linux (sourcetype=auditd OR sourcetype=sysmon_linux OR sourcetype=edr*)
| where (parent_process IN ("httpd","apache2","nginx","lighttpd","cgi-fcgi") AND process IN ("bash","sh") )
| stats values(process_cmdline) as cmd by host, parent_process, user, process

KQL (Defender for Endpoint / Azure)

// RCE → bash uruchomiony przez proces WWW
DeviceProcessEvents
| where OSPlatform in ("Linux","macOS")
| where InitiatingProcessFileName in~ ("httpd","apache2","nginx","lighttpd","cgi-fcgi")
| where FileName in~ ("bash","sh")
| extend suspicious = iif(ProcessCommandLine has_any ("() {","%28%29%7B"), 1, 0)
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, suspicious

CloudTrail (CloudWatch Logs Insights) – post‑exploitation z roli instancji

fields @timestamp, eventSource, eventName, userAgent, sourceIPAddress, awsRegion
| filter eventCategory="Management"
| filter userAgent like /aws-cli|Boto|Go-http-client|curl|wget|python-requests/i
| filter eventName in ("GetCallerIdentity","AssumeRole","ListBuckets","GetObject","DescribeInstances","ListAccessKeys")
| sort @timestamp desc
| limit 200

Uzasadnienie: po RCE atakujący często odczytuje IMDS 169.254.169.254 i zaczyna wykonywać API przy użyciu roli instancji. Monitorowanie userAgent i nietypowej sekwencji API pomaga to wyłapać.

Elastic EQL (host Linux — łańcuch WWW → powłoka)

process where host.os.type == "linux" and
  process.name in ("bash","sh") and
  process.parent.name in ("httpd","apache2","nginx","lighttpd","cgi-fcgi")

Heurystyki / korelacje (co łączyć)

Anomalia HTTP → 4xx/5xx/niestandardowe metody/URI → spawn powłoki przez proces WWW → wyjście sieciowe lub IMDS 169.254.169.254 → aktywność API w CloudTrail.
Jednorodny UA/źródła IP atakujące wiele hostów + identyczne wzorce nagłówków = kampania skanowania.
Po RCE: zapis webshella (T1505.003) lub pobranie binarek (T1105) — koreluj z tworzeniem nietypowych plików w katalogach serwisu WWW.

False positives / tuning

Skany bezpieczeństwa/WAF test strings — przepuść przez allow‑listy znanych skanerów i Twoich narzędzi QA.
Zaszyfrowane/URL‑encoded warianty — rozszerz regex (np. %28%29%7B).
Reverse proxy — upewnij się, że widoczny jest oryginalny UA i IP (X‑Forwarded‑For).
Systemy bez CGI — same ślady w logach HTTP ≠ RCE: szukaj łańcucha procesów (rodzic WWW → bash).

Playbook reagowania (IR)

Blokada na brzegu: reguły WAF/IPS dla wzorca funkcji Basha; tymczasowe ograniczenie dozwolonych metod/ścieżek.
Izolacja hosta (serwer/Pod) + snapshot dysku/pamięci.
Triage artefaktów: access/error logs, auditd, łańcuch procesów, nowe pliki w docroot, klucze/sekrety.
Weryfikacja IMDS/poświadczeń: sprawdź ruch do 169.254.169.254 i następujące wpisy w CloudTrail; rotacja kluczy/rol.
Patching Bash do wersji załatanej (dystrybucyjny update), weryfikacja wyłączenia/ograniczenia CGI.
Hunting w SIEM: zapytania z sekcji 7 na całą flotę.
Hardening: wymuś IMDSv2, segmentację DMZ, least‑privilege dla kont serwisów.

Przykłady z kampanii / case studies

Szybka weaponizacja (2014): w ciągu doby od ujawnienia powstały botnety DDoS; liczne ataki obserwowali m.in. Kaspersky i media branżowe.
Raporty vendorów/CSIRT: Cisco Talos dokumentował masowe próby eksploatacji w sieci; Akamai opisywał rekrutację hostów do botnetów.

Lab — przykładowe kroki

Cel: przetestować detekcje bez wykonywania exploita. Wykorzystujemy syntetyczne dane i odizolowane środowisko testowe.

Symulacja logów HTTP: wygeneruj sztuczne wpisy access.log zawierające charakterystyczny wzorzec funkcji Basha w formie zanonimizowanej (bez komend), np. () { :; }; <marker>; wgraj plik do SIEM i uruchom reguły z pkt 7.
Symulacja łańcucha procesów: w kontenerze testowym uruchom skrypt, który (lokalnie) tworzy proces bash jako dziecko procesu o nazwie „httpd” (np. wrapper), tak aby telemetria EDR/auditd wygenerowała ślad parent=apache2 -> bash — bez wykonywania zewnętrznych komend.
Symulacja post‑exploitation w chmurze: używając konta testowego z rolą instancji, wykonaj bezpieczne GetCallerIdentity i ListBuckets, aby sprawdzić reguły CloudTrail (CloudWatch Logs Insights) — wyłącznie w środowisku testowym.

Uwaga: celem jest walidacja detekcji i playbooków IR zgodnie z zasadami bezpieczeństwa.

Mapowania (Mitigations, powiązane techniki)

Mitigacje ATT&CK:

M1051 – Update Software: szybkie łatanie Basha/aplikacji publicznych.
M1031 – Network Intrusion Prevention: sygnatury na brzegach/WAF/IPS dla typowych wzorców Shellshock.
M1030 – Network Segmentation: separacja DMZ i serwerów publicznych.
M1040 – Behavior Prevention on Endpoint: blokowanie podejrzanych łańcuchów procesów (WWW→bash).
M1016 – Vulnerability Scanning: regularne skany z szybkim SLA na krytyczne ujawnienia.

Powiązane techniki:

T1059.004 – Unix Shell (wykonanie komend po RCE).
T1505.003 – Web Shell (utrwalenie po pierwszym włamaniu).
T1105 – Ingress Tool Transfer (dociągnięcie narzędzi po uzyskaniu RCE).
T1190 – Exploit Public‑Facing Application (wektor wejścia).

Źródła / dalsza literatura

NVD: opis, CVSS 9.8/10.0 i wektory (Apache CGI, ForceCommand, DHCP). (NVD)
CVE.org: rekord CVE‑2014‑6271. (CVE)
Red Hat: strona podatności Shellshock (jak działa, zalecenia). (Red Hat Customer Portal)
CERT/CC VU#252743: nota o wykonaniu komend przez eksport funkcji. (kb.cert.org)
CISA/US‑CERT: alerty o rodzinie błędów Bash (CVE‑2014‑7169 i pokrewne). (CISA)
MITRE ATT&CK: T1190 (Initial Access) i T1059.004 (Unix Shell). (MITRE ATT&CK)
Przykłady „in‑the‑wild”: Wired (botnety), Cisco Talos, Akamai. (WIRED)
IMDS (AWS/Azure): dokumentacja i wskazówki detekcyjne. (AWS Documentation)

Checklisty dla SOC / CISO

SOC (operacyjne):

WAF/IPS: aktywne sygnatury na wzorce Shellshock (w tym URL‑encoded).
Reguły SIEM: HTTP wzorce + łańcuch WWW → bash + próby IMDS + CloudTrail sekwencje z roli instancji.
Hunting: poszukaj procesów bash z rodzicem httpd/apache2/nginx w całej flocie.
Telemetria: włącz auditd/EDR na hostach Linux oraz pełne access/error logs.
Kwarantanna + rotacja kluczy po wykryciu nadużyć API.

CISO (strategiczne):

Polityka patch management dla komponentów publicznych (SLA dla krytycznych CVE).
Segmentacja DMZ i minimalne uprawnienia kont serwisowych.
IMDSv2 tylko + kontrola egress do 169.254.169.254 z usług WWW.
Testy podatności i testy regresji detekcji (syntetyczne dane, bez exploitów).
Przeglądy architektury: unikać CGI/Bash w ścieżkach request‑handling.