Amíg mi, Red Teamerek az időzítési mellékcsatornák finom jeleit keressük, a védők (Blue Team) pontosan ugyanilyen éberen figyelik a mi tevékenységünk árulkodó jeleit. Egy sikeres időzítési támadás nemcsak precíz méréseket, hanem lopakodást is igényel. A zajban való elrejtőzés képessége gyakran fontosabb, mint a nyers technikai kivitelezés.
A detektálás alapja egyszerű: az időzítési támadások természetüknél fogva anomáliákat generálnak a rendszer normál működéséhez képest. A mi feladatunk, hogy ezeket az anomáliákat a normál működési zaj szintje alatt tartsuk.
Az időzítési támadás árulkodó lábnyoma
A védelmi rendszerek (legyen szó akár WAF-ról, IDS/IPS-ről vagy egyedi anomália-detektorokról) többnyire statisztikai alapon működnek. Folyamatosan figyelik a beérkező kérések és az azokra adott válaszok jellemzőit, és riasztanak, ha szignifikáns eltérést tapasztalnak a megszokottól (baseline).
A leggyakoribb metrikák, amiket figyelnek:
- Átlagos és medián válaszidő (Latency): A legegyszerűbb mutató. Ha egy adott végpont válaszideje hirtelen megugrik, az gyanús.
- Válaszidők szórása (Jitter): Nem csak a magas, hanem a szokatlanul konzisztens vagy éppen extrém módon ingadozó válaszidő is feltűnő lehet.
- Percentilis értékek (pl. p95, p99): A kiugró értékek detektálására szolgál. Egy jól megtervezett rendszer figyeli a leglassabb 1-5% válaszidőt, mert a támadások gyakran itt jelennek meg először.
- Kérések gyakorisága: Az előző fejezetben tárgyalt sebességkorlátozás (rate limiting) alapja. Egy adott forrásból érkező, szokatlanul sűrű kéréssorozat azonnal gyanút kelt.
Gyakori észlelési technikák a védő oldalán
Nézzük meg konkrétabban, milyen mechanizmusokkal találkozhatsz a terepen.
1. Statisztikai anomália-detekció
Ez a legelterjedtebb módszer. A rendszer megtanulja, hogy egy adott végpontnak milyen a „normális” válaszidő-eloszlása. Ha egy kérés válaszideje jelentősen eltér ettől (pl. 3-4 szórással nagyobb, mint az átlag), azt megjelöli anomáliaként. Több ilyen anomália egy forrásból rövid időn belül riasztást vált ki.
# Pszeudokód egy egyszerű anomália-detektorra
def is_timing_anomaly(request_time, endpoint_stats):
# endpoint_stats egy objektum, ami tárolja az átlagot (mean) és a szórást (std_dev)
# A küszöbérték (threshold) általában 3 vagy 4
threshold = 3.5
# Kiszámoljuk, hány szórásnyira van az aktuális kérés az átlagtól (Z-score)
z_score = (request_time - endpoint_stats.mean) / endpoint_stats.std_dev
if z_score > threshold:
# Gyanús! Ez a kérés sokkal lassabb volt a megszokottnál.
log_suspicious_activity(request)
return True
return False
2. Kérések mintázatának elemzése
A kifinomultabb rendszerek nem csak egy-egy kérést vizsgálnak, hanem a kérések sorozatának mintázatát. Egy tipikus időzítési támadás, ami például egy titkosító kulcs bitjeit próbálja kitalálni, gyakran jellegzetes mintát hagy maga után. Például egy bináris kereséshez hasonló logika, ahol a kérések paraméterei és az azokra adott válaszidők korrelálnak.
A diagramon jól látszik, hogy míg a normál forgalom válaszideje egy bizonyos sávban ingadozik, addig egy strukturált támadás (mint egy adatbázis-lekérdezésen alapuló „igen/nem” válaszokat kereső támadás) egy sokkal szabályosabb, periodikus vagy más módon feltűnő mintázatot hoz létre.
3. Erőforrás-használat korrelációja
Egyes időzítési támadások nemcsak a válaszidőt növelik, hanem a szerveroldali erőforrás-használatot is. Például egy komplex reguláris kifejezés (ReDoS) vagy egy mély rekurziót igénylő feladat aránytalanul nagy CPU terhelést okozhat. A modern APM (Application Performance Monitoring) eszközök képesek összekapcsolni egy-egy lassú tranzakciót a mögöttes CPU- vagy memóriacsúccsal. Ha egy adott IP címről érkező kérések konzisztensen korrelálnak a szerver terhelésének megugrásával, az erős indikátora egy támadási kísérletnek.
| Időbélyeg | Forrás IP | Válaszidő (ms) | CPU Terhelés (%) | Észrevétel |
|---|---|---|---|---|
| 14:32:01.125 | 198.51.100.10 | 85 | 12 | Normál kérés |
| 14:32:01.340 | 203.0.113.25 | 1250 | 89 | Anomália: Válaszidő és CPU terhelés korrelál |
| 14:32:01.610 | 198.51.100.12 | 92 | 14 | Normál kérés |
| 14:32:02.150 | 203.0.113.25 | 1190 | 85 | Anomália: Ismétlődő minta ugyanarról a forrásról |
Hogyan maradj a radar alatt? (Red Teamer nézőpont)
A célunk az, hogy a támadásunk által generált jelet a rendszer természetes zajába rejtsük. Minél „zajosabb” egy rendszer normál működés közben, annál könnyebb dolgunk van.
- Lassíts (Slow and Low): Ne siess. Ahelyett, hogy másodpercenként több tucat kérést küldenél, oszd el a támadást órákra vagy akár napokra. Egy-egy anomália még nem vált ki riasztást, de egy sűrű sorozat igen.
- Vigyél bele véletlenszerűséget: Ne küldd a kéréseket pontosan 100 ms-onként. Adj hozzá véletlenszerű késleltetést (jitter) a kérések közé. Ez megtöri a periodikus mintázatot, amit a védelmi rendszerek keresnek. Erről a következő fejezetben részletesen is lesz szó.
- Változtasd a forrást: Használj több IP címet (proxy, botnet), hogy a kérések ne egyetlen forrásból származzanak. Így a forrásalapú korrelációs szabályokat kijátszhatod.
- Utánozd a normál forgalmat: Ne csak a támadó kéréseket küldd. Keverj közéjük ártalmatlan, normálisnak tűnő API hívásokat is. Ezzel tovább hígítod a támadási mintázatot.
Az időzítési támadások észlelése egy macska-egér játék. A védők egyre jobb statisztikai modelleket építenek a mintázatok felismerésére, míg a támadók egyre kifinomultabb módszereket dolgoznak ki a zajban való elrejtőzésre. A sikered kulcsa, hogy megértsd, mit figyel a védő, és ennek megfelelően alakítsd a stratégiádat.