CVE-2014-0160 — „Heartbleed” (OpenSSL TLS/DTLS Heartbeat memory disclosure)

TL;DR

Heartbleed to krytyczna luka w OpenSSL 1.0.1–1.0.1f (oraz 1.0.2‑beta/beta1), w implementacji rozszerzenia TLS/DTLS Heartbeat (RFC 6520). Błędny brak kontroli długości powoduje odczyt do 64 KB pamięci procesu na żądanie, co umożliwia wyciek kluczy prywatnych, haseł, tokenów i ciasteczek sesyjnych — bez śladów w standardowych logach. Naprawa: OpenSSL 1.0.1g lub kompilacja z -DOPENSSL_NO_HEARTBEATS, plus rotacja kluczy/certyfikatów i reset sesji/haseł. CVSS v3.1: 7.5 (HIGH).

---

Krótka definicja techniczna

CVE‑2014‑0160 to buffer over-read w funkcjach przetwarzających komunikaty Heartbeat w OpenSSL (TLS i DTLS). Złośliwy pakiet żąda odesłania większej liczby bajtów niż faktyczny payload, co skutkuje ujawnieniem fragmentu pamięci procesu serwera/klienta. Błąd dotyczy OpenSSL 1.0.1 (do 1.0.1f włącznie) i został naprawiony w 1.0.1g (07.04.2014).

---

Gdzie występuje / przykłady platform

• Linux/Unix: usługi HTTPS (Apache/Nginx), proxy, poczta (IMAPS/POP3S/SMTPS), VPN (np. OpenVPN), serwery aplikacyjne — jeśli linkują do OpenSSL 1.0.1*. Przykładowe dystrybucje z podatnymi pakietami: Debian Wheezy, Ubuntu 12.04.4, CentOS 6.5, FreeBSD 10.0 itd.
• Urządzenia/IoT/appliance: część routerów/telefonów VoIP/przełączników używających OpenSSL 1.0.1* (stan historyczny).
• Windows/AD: IIS/Schannel nie były podatne; ryzyko dotyczy aplikacji na Windows, które samodzielnie używały podatnego OpenSSL.
• Chmury: własne instancje/obrazy z OpenSSL 1.0.1*, komponenty kontenerowe; w AWS/Azure/GCP po stronie klientów/serwerów, a także wszędzie tam, gdzie terminacja TLS odbywa się na oprogramowaniu z OpenSSL 1.0.1*. (Do detekcji przydają się logi IDS oraz logi operacji na certyfikatach, np. ACM/CloudTrail).

---

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

Rozszerzenie TLS/DTLS Heartbeat (RFC 6520) pozwala okresowo „pingować” drugą stronę bez renegocjacji. W podatnych wersjach OpenSSL błędnie ufano deklarowanej długości payloadu. Napastnik wysyła HeartbeatRequest z małym payloadem i zawyżoną długością; OpenSSL odsyła żądaną liczbę bajtów, dogaszając brakujące bajty z pamięci procesu (do 64 KB na żądanie). Atak można wykonywać wielokrotnie, aż do pozyskania wartościowych artefaktów (klucze prywatne X.509, hasła, tokeny sesji). Naprawa w 1.0.1g dodała kontrolę zakresu i odrzucanie niepoprawnych żądań. Skuteczność ataku wynika z: (1) prostoty (brak uwierzytelnienia), (2) braku śladów w typowych logach aplikacji, (3) wysokiej wartości wycieku (tajemnice kryptograficzne).

---

Artefakty i logi (SOC)

Źródło/log	Pole/artefakt	Wzorzec/anomalia	Uwagi
IDS (Suricata/Snort)	alert.signature / event.signature	„Heartbleed” / „OpenSSL TLS heartbeat read overrun” / „CVE‑2014‑0160”	SIDs Snort VRT: 30510–30517 (GID 1). Najpewniejszy sygnał.
Zeek	notice / skrypt ssl/heartbleed	Alerty dot. niepoprawnych rekordów Heartbeat	Wsparcie dodane 2014‑04‑08.
ALB/ELB (AWS) – Connection/Access Logs	TLS pola: protokół, cipher, status/connection_status	Piki błędów/nieudanych handshake (pośrednio); korelować z alarmami IDS	Do analizy zmian wzorców TLS, nie wykrywa samego Heartbleed.
CloudTrail (AWS ACM/IAM/ACM‑PCA)	eventName	ImportCertificate, RequestCertificate, UpdateServerCertificate, DeleteServerCertificate	Ślad rotacji certyfikatów po łataniu/kompromitacji.
Web serwer (Apache/Nginx)	error/access	Nietypowe resety połączeń, wzrost 4xx/5xx (wtórnie)	Korelacja pomocnicza; zapis TLS payloadu brak. [Uzupełniające]
Windows EID	—	—	Schannel/IIS niepodatne; brak natywnych EID dla samej luki. [N/D]
K8s audit	patch/update na Deployment/Pod	Rolling update obrazów po aktualizacji OpenSSL	Artefakt zmian remediacyjnych, nie wykrycia. [Ogólne]

---

Detekcja (praktyczne reguły)

Sigma (IDS → SIEM)

title: Heartbleed (CVE-2014-0160) Detected by IDS
id: 1e1a5bb3-9e6f-45f0-9d7e-ids-heartbleed
status: stable
description: Alerty IDS/IPS wskazujące na próby/wykrycia ataku Heartbleed.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2014-0160
  - https://blog.snort.org/2014/04/sourcefire-vrt-certified-snort-rules_8.html
  - https://zeek.org/2014/04/detecting-the-heartbleed-bug-using-bro/
logsource:
  product: network
  service: ids
detection:
  selection:
    signature|contains:
      - 'Heartbleed'
      - 'heartbeat read overrun'
      - 'CVE-2014-0160'
    # alternatywnie dla Suricata EVE:
    alert.signature|contains:
      - 'Heartbleed'
      - 'heartbeat read overrun'
  condition: selection
fields:
  - src_ip
  - dest_ip
  - dest_port
  - signature
  - classification
falsepositives:
  - Rzadkie; możliwe skanery audytowe (np. nmap ssl-heartbleed)
level: high
tags:
  - attack.T1190
  - attack.T1212

(Źródła reguł i nazewnictwa sygnatur: Snort VRT SIDs 30510–30517; Zeek script ssl/heartbleed.)

Splunk (SPL)

(index=ids (sourcetype=suricata OR sourcetype=snort) OR source="*eve.json")
| spath
| eval sig=coalesce('alert.signature','signature')
| search sig="*Heartbleed*" OR sig="*heartbeat read overrun*" OR sig="*CVE-2014-0160*"
| stats earliest(_time) as first latest(_time) as last values(dest_port) count by src_ip dest_ip sig
| convert ctime(first) ctime(last)

KQL (Microsoft Sentinel / Log Analytics)

Opcja A – CommonSecurityLog (appliance IDS):

CommonSecurityLog
| where DeviceVendor in~ ("Snort","Suricata")
| where Message has_any ("Heartbleed","heartbeat read overrun","CVE-2014-0160")
| summarize cnt=count(), first=min(TimeGenerated), last=max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort, Message

Opcja B – własna tabela SuricataEve_CL:

SuricataEve_CL
| where event_type_s == "alert"
| where alert_signature_s has_any ("Heartbleed","heartbeat read overrun","CVE-2014-0160")
| summarize cnt=count(), first=min(TimeGenerated), last=max(TimeGenerated) by src_ip_s, dest_ip_s, dest_port_d, alert_signature_s

CloudTrail Lake (AWS) — ślad rotacji certyfikatów po incydencie

SELECT eventTime, eventSource, eventName,
       userIdentity.accountId AS account, userIdentity.type AS actorType,
       requestParameters.certificateArn AS certArn
FROM   aws_cloudtrail_logs
WHERE  eventSource IN ('acm.amazonaws.com','iam.amazonaws.com','acm-pca.amazonaws.com')
  AND  eventName   IN ('ImportCertificate','RequestCertificate','UpdateServerCertificate','DeleteServerCertificate')
  AND  eventTime BETWEEN from_iso8601_timestamp('2025-11-01T00:00:00Z') AND from_iso8601_timestamp('2025-11-08T23:59:59Z')
ORDER BY eventTime DESC;

(Dokumentacja CloudTrail/ACM potwierdza logowanie tych akcji.)

Elastic / EQL / Kibana KQL

EQL:

network where event.module == "suricata" and event.kind == "alert" and
 (suricata.eve.alert.signature : "*Heartbleed*" or
  suricata.eve.alert.signature : "*heartbeat read overrun*")

Kibana KQL:

event.module:"suricata" and event.kind:"alert" and suricata.eve.alert.signature:("*Heartbleed*" OR "*heartbeat read overrun*" OR "*CVE-2014-0160*")

---

Heurystyki / korelacje (co łączyć)

• Korelacja IDS ↔ rotacja certyfikatów: alerty Heartbleed na IP serwera + w ciągu 24–72 h zdarzenia ImportCertificate/UpdateServerCertificate (CloudTrail) ⇒ potwierdzenie remediacji lub panic‑rotacji.
• Anomalie ruchu TLS: wzrost krótkich połączeń do 443/IMAPS/SMTPS z tej samej klasy adresów podczas skanów/eksfiltracji. [wspierające]
• Ryzyko wtórne: po wycieku klucza prywatnego — podszywanie się (MITM) i odszyfrowanie zarejestrowanego ruchu bez PFS; korelować z wymianą certyfikatów i wymuszaniem PFS.

---

False positives / tuning

• Fałszywe pozytywy są rzadkie — sygnatury na poziomie TLS są precyzyjne. Najczęstsze przypadki: testy nmap ssl-heartbleed lub skanery zgodności. Whitelistuj źródła skanerów.
• Brak alertu ≠ brak ataku — historycznie ataki nie musiały zostawiać śladów w logach aplikacyjnych; rely na IDS/Zeek.

---

Playbook reagowania (IR)

1. Izolacja & inwentarz: zidentyfikuj hosty z OpenSSL 1.0.1–1.0.1f/1.0.2‑beta*.
2. Łatowanie: aktualizacja do OpenSSL 1.0.1g lub nowszej gałęzi; alternatywnie rekompilacja z -DOPENSSL_NO_HEARTBEATS (krótkoterminowo).
3. Rotacja kryptografii: wygeneruj nowe klucze prywatne, ponownie wydaj certyfikaty, unieważnij stare (CRL/OCSP); w chmurze weryfikuj ślad w CloudTrail (ACM/IAM/ACM‑PCA).
4. Unieważnienie sesji: wymuś re‑logowanie użytkowników, rotuj tokeny/cookies.
5. Reset haseł: jeśli wyciek dotyczył serwisów z authem — wymuś zmianę.
6. Hunting: przeszukaj IDS/Zeek pod kątem wzorców Heartbleed i anomalii TLS; koreluj ze zmianami certyfikatów.
7. Komunikacja: zgodnie z wymogami regulacyjnymi (np. healthcare — przykłady incydentów niżej).

---

Przykłady z kampanii / case studies

• Canada Revenue Agency (CRA) — kradzież 900 numerów SIN w oknie 6h tuż po ujawnieniu luki; zatrzymano podejrzanego.
• Mumsnet (UK) — reset ~1,5 mln haseł po incydencie powiązanym z Heartbleed.
• Community Health Systems (USA) — wyciek danych 4,5 mln pacjentów; wektor przypisano exploitacji Heartbleed.
• Konsekwencje systemowe — Heartbleed przyspieszył powstanie Core Infrastructure Initiative (funding krytycznych OSS).

---

Lab — przykładowe komendy

Wyłącznie w kontrolowanym środowisku i na własnych hostach.
Celem jest weryfikacja detekcji, nie ofensywa.

Uruchomienie podatnego serwisu (Docker):

# przykładowy obraz demo (podatny OpenSSL)
docker run -d --name hb -p 8443:443 vulnerables/cve-2014-0160

Test wykrycia (Nmap NSE – bezpieczne sprawdzenie):

nmap -p 8443 --script ssl-heartbleed 127.0.0.1

(Nmap skrypt ssl-heartbleed jednoznacznie wskazuje podatność.)

IDS/Zeek:

• Włącz reguły ET/Suricata lub Snort VRT (SIDs 30510–30517).
• Zeek: załaduj skrypt policy/protocols/ssl/heartbleed.bro (obecnie w master).

---

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK Enterprise):

• M1051 Update Software — szybkie łatowanie (OpenSSL ≥1.0.1g).
• M1031 Network Intrusion Prevention — IDS/IPS z sygnaturami Heartbleed.
• (Dodatkowo) M1048 Application Isolation and Sandboxing, M1050 Exploit Protection — ograniczenie skutków.

Powiązane techniki ATT&CK:

• T1190 Exploit Public-Facing Application — wektor wejścia.
• T1212 Exploitation for Credential Access — pozyskanie sekretów.
• T1210 Exploitation of Remote Services — ruch boczny po kompromitacji.

---

Źródła / dalsza lektura

• NVD — opis i CVSS v3.1: 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). (NVD)
• Heartbleed.com — zakres wersji i kontekst operacyjny. (heartbleed.com)
• RFC 6520 — TLS/DTLS Heartbeat Extension. (RFC Editor)
• OpenSSL 1.0.1g — release notes (fix CVE‑2014‑0160). (slackware.cs.utah.edu)
• CISA alert — charakterystyka luki i wyciek porcji 64 KB. (CISA)
• Snort/Suricata — sygnatury wykrywające Heartbleed (SIDs 30510–30517) + dokumentacja aktualizacji reguł. (Snort Blog)
• Zeek — detekcja Heartbleed. (Zeek)
• AWS — CloudTrail/ACM (logowanie operacji na certyfikatach) i Connection Logs ALB. (AWS Documentation)
• Case studies: CRA, CHS, Mumsnet. (TIME)

---

Checklisty dla SOC / CISO

SOC (operacyjnie):

• Włączone reguły IDS/IPS na „Heartbleed” (Snort/Suricata/Zeek).
• Dashbord/alert: korelacja IDS Heartbleed ↔ CloudTrail Import/UpdateServerCertificate.
• Monitoring anomalii TLS (krótkie połączenia, skoki błędów).
• Procedura natychmiastowej rotacji certyfikatów/kluczy i unieważniania sesji.

CISO (strategicznie):

• Potwierdzona eliminacja OpenSSL 1.0.1* w środowisku (obrazy bazowe/kontenery).
• Wymuszenie PFS i polityki silnych zestawów szyfrów.
• Testy podatności (skan nmap NSE) — wyłącznie autoryzowane.
• Plan komunikacji i notyfikacji (zgodność regulacyjna); lekcje z incydentów (CRA/CHS).

Uwaga końcowa: Heartbleed to historyczna luka, ale nadal pojawia się w długowiecznych obrazach/urządzeniach. Minimalna obrona to łatanie (M1051), IDS/IPS (M1031) oraz rotacja kryptografii po każdym podejrzeniu ekspozycji.