0.15.1. Kezdeti felderítés – gyenge pontok keresése

Mielőtt egy hegymászó nekilátna egy sziklafalnak, nem rohan oda és kezdi el kapkodva keresni az első kapaszkodót. Ehelyett távolabbról szemléli: tanulmányozza a repedéseket, a kőzet szerkezetét, a potenciális útvonalakat és a lehetséges veszélyeket. 

A kezdeti felderítés az AI rendszerek elleni támadások során pontosan ugyanez a folyamat. Nem a brute-force törésről szól, hanem a megfigyelésről, a következtetésről és a támadási felület feltérképezéséről. Ez az a fázis, ahol a türelem és a kíváncsiság többet ér, mint bármilyen szkript.

A célunk nem az, hogy azonnal sebezhetőséget találjunk. A célunk, hogy megértsük a rendszert. 

• Hogyan épül fel? 
• Milyen technológiákat használ? 
• Milyen adatokon tanították?
• Ki készítette? 

Minden apró információmorzsa egy puzzle-darab, és a teljes kép kirajzolásával válnak láthatóvá a gyenge pontok.

A felderítői gondolkodásmód: Két alapvető megközelítés

A felderítést két fő kategóriára bonthatjuk, amelyek gyakran egymást kiegészítve működnek:

• Passzív felderítés (OSINT – Open-Source Intelligence): Ez a fázis arról szól, hogy anélkül gyűjtsünk információt, hogy közvetlenül interakcióba lépnénk a célrendszerrel. Olyan, mintha a hegyről készült fotókat, térképeket és más hegymászók beszámolóit elemeznénk. Az interneten fellelhető nyilvános adatok aranybányát jelentenek!
• Aktív felderítés: Itt már „megkocogtatjuk a falat”. Közvetlen interakcióba lépünk a rendszerrel, de még nem támadó jelleggel. Célzott kéréseket küldünk, figyeljük a válaszokat, a hibaüzeneteket, a rendszer viselkedését. Finom tapogatózás, nem pedig faltörő kos.

Esettanulmány: A „LegDocSum” jogi asszisztens modell

Képzelj el egy startupot, amely egy „LegDocSum” nevű AI modellt fejlesztett ki. A modell célja, hogy jogi dokumentumokat elemezzen és foglaljon össze. Nyilvánosan elérhető egy webes demó felületen keresztül, ahol a felhasználók feltölthetnek rövid szövegeket. Nézzük, hogyan térképeznénk fel ezt a rendszert.

1. Fázis: Passzív felderítés – A digitális lábnyomok követése

Mielőtt egyetlen karaktert is beírnánk a demó felületbe, körülnézünk az interneten:

• Céges blog és sajtóközlemények: Egy bejegyzésben büszkén említik, hogy a „LegDocSum v2 egy Transformer-alapú architektúrára épül, amelyet a legújabb Hugging Face könyvtárakkal implementáltunk”. Kulcsinformáció: Ismerjük a technológiai keretrendszert, ami leszűkíti a lehetséges sebezhetőségek körét.
• Fejlesztői LinkedIn profilok: A cég vezető AI mérnöke a profilján feltünteti, hogy a rendszer backendje „FastAPI-alapú és egy AWS EC2 instance-on fut”. Kulcsinformáció: Megvan a webszerver technológia (FastAPI) és a felhőszolgáltató (AWS). A FastAPI ismert hibái vagy az AWS S3 bucketek helytelen konfigurációja potenciális támadási vektor lehet.
• Akadémiai publikációk: A kutatócsapat publikált egy tanulmányt a modell tanítási folyamatáról. Ebben megemlítik, hogy egy „anonimizált szerződéses adatbázist” használtak. Kulcsinformáció: Ha az anonimizálás nem volt tökéletes, a modellből esetleg visszafejthetők érzékeny adatok (tagsági következtetés támadás).
• Álláshirdetések: Egy korábbi DevOps mérnöki álláshirdetésben „Docker és Kubernetes ismeret” szerepel elvárásként. Kulcsinformáció: A rendszer valószínűleg konténerizált, ami sajátos konfigurációs hibákhoz vezethet.

Már ennyi információ birtokában sem egy fekete dobozt látunk, hanem egy rendszert, aminek ismerjük a főbb építőköveit.

2. Fázis: Aktív, de nem tolakodó felderítés – A rendszer megszólaltatása

Most, hogy van egy alapvető képünk, óvatosan interakcióba lépünk a demó felülettel. Nem célunk a törés, csak a reakciók megfigyelése.

Egy egyszerű Python szkripttel elkezdjük vizsgálni, hogyan reagál az API a nem szokványos bemenetekre. A célunk, hogy hibát provokáljunk ki, ami esetleg többet árul el a belső működésről.

import requests
import json

# A demó API végpontja
URL = "https://api.lecdocsum-demo.com/summarize"

# 1. Próba: Túl hosszú bemenet küldése, 
# ami túlterheli a puffert vagy időtúllépést okozhat
long_text = "a" * 50000 
response = requests.post(URL, json={"text": long_text})
print(f"Hosszú szöveg válasza: {response.status_code}") 
# Vajon 4xx vagy 5xx hibát kapunk?

# 2. Próba: Strukturált adat (JSON) küldése szöveg helyett
# Ez megzavarhatja a backend feldolgozó logikáját
malformed_input = {"nested_key": {"another_key": "some_value"}}
response = requests.post(URL, json={"text": malformed_input})

# A válasz elemzése - vajon kapunk-e részletes hibaüzenetet?
if response.status_code == 500:
 print("Belső szerverhiba!")
 # Egy beszédes hibaüzenet aranyat érhet
 # Pl. "TypeError: a 'dict' object is not iterable in process_text.py line 42"
 print(response.text)
 

Tegyük fel, hogy a második próba egy 500-as belső szerverhibát ad vissza, a válasz törzsében pedig egy részletes Python stack trace látható, ami felfedi a belső fájlstruktúrát (`/app/services/processing.py`) és a használt könyvtárak pontos verzióit. Ez már kritikus hiba, ami közvetlen utat nyithat a további támadásokhoz.

Az információk szintézise: A gyenge pontok feltérképezése

A felderítési fázis végén összegezzük a gyűjtött információkat. Ez nem csak egy lista, hanem egy összefüggéseket kereső elemzés. A cél, hogy a passzív és aktív módszerekkel szerzett adatokat egyetlen, koherens képpé fűzzük össze.

A LecDocSum esettanulmányunk alapján a következő táblázatot állíthatnánk össze:

Ezen a ponton a támadás már nem vaktában lövöldözés. Van egy térképünk, amelyen bejelöltük a legígéretesebb helyeket. A részletes hibaüzenet egy nyitva felejtett ajtó, amin keresztül megkísérelhetjük az első behatolást. 

A felderítés sikeres volt: a fekete dobozból egy átláthatóbb, sebezhetőbb rendszert formáltunk, előkészítve a terepet a következő, aktívabb fázisokhoz.