A felhasználói felület gyorsasága és reszponzivitása mögött az aszinkron rendszerekben gyakran egy rejtett, de kritikus komponens húzódik meg: a várakozási sor. Ez a digitális „előszoba” felel a feladatok (pl. képanalízis, adatfeldolgozás, modell-inferencia) rendezett ütemezéséért. Egy red teamer számára ez a sor nem csupán egy technikai részlet, hanem egy potenciális támadási felület, ahol a rendszer logikáját és erőforrásait a háttérben, észrevétlenül lehet manipulálni.
A várakozási sor mint támadási felület
Amikor egy feladat bekerül egy sorba, általában több attribútummal rendelkezik: egyedi azonosító, a végrehajtandó művelet, a hozzá tartozó adatok és esetleg egy prioritási szint. A támadások célja ezen attribútumok vagy a feladatok sorrendjének illegitim megváltoztatása a sorba kerülés után, de a feldolgozás előtt. A sikeres manipulációval elérhető célok:
- Erőforrás-kimerítés (Denial of Service): A rendszert alacsony prioritású, de erőforrás-igényes feladatokkal árasztjuk el, megakadályozva a legitim, magas prioritású kérések feldolgozását.
- Jogosultság-kiterjesztés: Egy alacsony jogosultságú felhasználó feladatának prioritását magasra emelve olyan erőforrásokhoz vagy gyorsabb végrehajtáshoz juthat, amihez nem lenne joga.
- Logikai hibák kihasználása: A feladatok végrehajtási sorrendjének felcserélésével a rendszer üzleti logikájában rejlő sebezhetőségeket aknázhatunk ki.
- Adatmanipuláció: A sorban várakozó feladat adatainak módosításával kikerülhetők a bemeneti validációs lépések, mivel azok jellemzően a sorba helyezés előtt történnek meg.
Főbb támadási technikák
A várakozási sorok elleni támadások több formát ölthetnek, attól függően, hogy a rendszer architektúrája milyen gyengeségeket rejt.
Prioritás-manipuláció és eszkaláció
Sok rendszer lehetővé teszi, hogy a felhasználók (vagy a rendszer különböző komponensei) prioritást rendeljenek a beküldött feladatokhoz. Ha a szerver vakon megbízik a kliens által küldött prioritási értékben, egy támadó könnyedén eszkalálhatja saját feladatainak sürgősségét.
{
"taskId": "user-generated-uuid-123",
"taskType": "image_analysis",
"dataUrl": "https://example.com/image.jpg",
// A támadó egy magasabb értéket (pl. 'CRITICAL') ad meg,
// mint amit a jogosultsága (pl. 'NORMAL') engedne.
"priority": "CRITICAL",
"userId": "user-free-tier"
}Ezzel a triviális módosítással a támadó feladatai megelőzhetik a fizetős vagy adminisztrátori felhasználók kéréseit, ami egy célzott DoS támadáshoz vezethet a prémium szolgáltatások ellen.
Feladat-mérgezés (Task Poisoning)
Ez a technika a TOCTOU sebezhetőségek egy speciális esete. A támadó először egy ártalmatlan, validáción átmenő feladatot küld be a sornak. Azonban a feladat adatai nem magában a feladat-üzenetben, hanem egy külső referencián (pl. egy S3 bucket URL-jén) keresztül vannak megadva. A támadó, kihasználva a sorba kerülés és a feldolgozás közötti időablakot, kicseréli a referencia mögötti tartalmat egy kártékonyra.
Sor-elárasztás (Queue Flooding)
Ez egy alkalmazás-szintű DoS támadás. A cél nem a hálózat, hanem a feldolgozó kapacitás leterhelése. A támadó nagy mennyiségű, triviálisan sorba helyezhető, de a feldolgozó (worker) számára idő- vagy számításigényes feladatot küld. Például egy MI-alapú videófeldolgozó szolgáltatás esetén ez lehet több ezer kérés egy-egy hosszú, nagy felbontású videó transzkódolására.
import requests
import time
# A támadó egy API végpontot céloz, ami feladatokat vesz fel
API_ENDPOINT = "https://api.service.com/v1/process_video"
HEADERS = {"Authorization": "Bearer cheap_user_token"}
for i in range(10000):
# Minden kérés egy új, erőforrás-igényes feladatot indít
payload = {"source_url": f"https://storage.com/long_video_{i}.mp4"}
try:
requests.post(API_ENDPOINT, json=payload, headers=HEADERS, timeout=0.5)
print(f"Feladat {i} sorba helyezve.")
except requests.exceptions.ReadTimeout:
# Nem is érdekel a válasz, csak hogy a feladat bekerüljön
pass
time.sleep(0.05) # Lassú küldés a hálózati szintű védelem elkerüléséreSzekvencia-manipuláció
Bizonyos rendszerekben a feladatok végrehajtási sorrendje kritikus. Gondolj egy kereskedési platformra, ahol az „eladás” és „vétel” parancsok sorrendje pénzt jelent. Ha a támadó képes befolyásolni, hogy a feldolgozó melyik feladatot vegye ki előbb a sorból (pl. egy nem kellően egyedi feladat-azonosító manipulálásával vagy a rendszer belső logikájának ismeretével), akkor az üzleti logikát sértheti.
| Szándékolt sorrend | Manipulált sorrend | Eredmény |
|---|---|---|
| 1. Feladat: ‘SELL’ 100db @ 50$ | 1. Feladat: ‘BUY’ 100db @ 49$ | A támadó alacsonyabb áron vásárol, mielőtt a saját eladási megbízása felhajtaná az árat. |
| 2. Feladat: ‘BUY’ 100db @ 49$ | 2. Feladat: ‘SELL’ 100db @ 50$ |
Azonosítás és Kihasználás Red Teaming Szemszögből
Ezeknek a sebezhetőségeknek a felderítése türelmet és a rendszer mélyebb megértését igényli. A folyamat lépései:
- Felület feltérképezése: Azonosítsd azokat az API végpontokat, amelyek aszinkron feladatokat indítanak. Keress olyan paramétereket a kérésekben, mint `priority`, `jobId`, `callbackUrl`, vagy külső adatforrásokra mutató hivatkozások.
- Időzítés elemzése: Mérd a feladat beküldése és a tényleges végrehajtás (pl. egy email megérkezése, egy fájl létrejötte) között eltelt időt. A hosszabb késleltetés nagyobb támadási ablakot jelent.
- Paraméter-fuzzing: Manipuláld a feltételezett prioritás- vagy sorrend-befolyásoló paramétereket. Küldj be két feladatot gyors egymásutánban, de eltérő prioritással, és figyeld a végrehajtás sorrendjét.
- Versenyhelyzetek provokálása: A feladat-mérgezés teszteléséhez automatizált szkriptekkel próbáld meg a referencia-adatot a beküldés utáni pillanatokban felülírni.
- Erőforrás-monitorozás: A sor-elárasztás hatékonyságának méréséhez figyeld a szolgáltatás válaszidejének növekedését vagy a hibák megjelenését egy kontrollált terheléses teszt során.
A sikeres kihasználáshoz gyakran több sebezhetőséget kell láncba fűzni. Egy gyengén implementált azonosító (pl. egy egyszerűen növekvő sorszám) felfedése például utat nyithat a szekvencia-manipuláció előtt.