Posted on Leave a comment

Az aggregált adat és a GDPR


Az előző posztban megnéztük hogyan definiálja a GDPR a személyes adat fogalmát és mi számít személyes adatnak a definíció szerint. Ebben a posztban egy mérnöki (és talán jogi) szempontból jóval izgalmasabb kérdést vizsgálunk: Személyes adatnak minősülhet-e az aggregált/statisztikai adat?

A probléma azért érdekes, mert a legtöbb cég/kormány/szervezet többnyire aggregált adatokat oszt meg, bízva abban, hogy ezek nem személyes adatok. Valóban, a GDPR így nyilatkozik a statisztikai adatról (26. preambulum): "[...] Az adatvédelem elveit [...] az anonim információkra nem kell alkalmazni, nevezetesen olyan információkra, amelyek nem azonosított vagy azonosítható természetes személyre vonatkoznak, valamint az olyan személyes adatokra, amelyeket olyan módon anonimizáltak, amelynek következtében az érintett nem vagy többé nem azonosítható. Ez a rendelet ezért nem vonatkozik az ilyen anonim információk kezelésére, a statisztikai vagy kutatási célú adatkezelést is ideértve." Később (162. preambulum): "[...] Statisztikai célúnak minősül a személyes adatok statisztikai felmérések vagy statisztikai eredmények kiszámításának céljából történő gyűjtése és kezelése. [...] A statisztikai célból következik, hogy a statisztikai célú adatkezelés eredménye nem személyes adat, hanem összesített [aggregált] adat, és hogy ezt az eredményt vagy a személyes adatokat nem használják fel konkrét természetes személyekre vonatkozó intézkedések vagy döntések alátámasztására." Mindazonáltal a GDPR is elismeri a 89. cikkben, hogy a statisztikai adatok nem feltétlenül anonim adatok, és azokra az adatvédelmi szabályozás már alkalmazandó.

Ebben a posztban megmutatjuk, hogy aggregált adatokból valóban rekonstruálhatók személyes adatok (pontosabban egyének rekordjai egy adatbázisban amin az aggregált adatot számolták), és így aggregált (összesített) adat is lehet személyes adat, akár még a GDPR 4. cikkének értelmezésében is. Példaként azt is megmutatjuk, hogy ha egy telekom cég kiadná a mobiltelefon-tornyok látogatottságát az idő függvényében (vagyis minden egyes toronynál levő előfizetők számát fél óránként), akkor ebből az aggregált adatból az egyes előfizetők által meglátogatott tornyok (helyek) listája közel 80%-os pontossággal rekonstruálható. Így az ilyen összesített adat lehet személyes (sőt akár érzékeny), és ebben az esetben az ilyen adat megfelelő anonimizációja/torzítása lehet szükséges.

Mi az aggregált adat?

A GDPR ugyan nem definiálja az aggregált (összesített) adat fogalmát, de valószínűleg több egyén adatán számolt statisztikai/összesített adatot ért alatta. Például az 1. táblázatban aggregált adat a betegek vércukrának átlaga, vagy szórása, vagy eloszlása, stb. Valójában az aggregált/statisztikai adatok előállíthatók több elemi ún. számláló lekérdezések (counting query) eredményeinek valamilyen függvényeként. Ilyen lekérdezés például: Hány olyan beteg van az adatbázisban akik Alzheimerben szenvednek? Vagy, hány olyan beteg van akiknek a vércukra 4.1 és 4.2 közé esik? Az ilyen lekérdezéseket egy mintával definiáljuk (pl. betegség attribútum értéke "Alzheimer", vagy vércukor attribútum értéke egy adott tartományba esik), és eredményük azon rekordok száma az adatbázisban, amelyekre az adott minta illeszkedik (úgy mondjuk, hogy az ilyen rekordokat a lekérdezés lefedi). Például az 1. táblázaton alkalmazva az első lekérdezés eredménye 1, mivel csak egy beteg szenved Alzheimerben (vagyis ez a lekérdezés csak a 3. rekordot fedi le). A második lekérdezés eredménye viszont 0, mivel egy beteg vércukra sem esik 4.1 és 4.2 közé.

A számláló lekérdezésekkel szinte az összes statisztikai adat kiszámolható. Például ha kiváncsiak vagyunk betegségek eloszlására/hisztogramjára az adatbázisban (vagyis az egyes betegségek gyakoriságára), akkor minden betegség előfordulását meg kell számolni az adatbázisban (annyi lekérdezés szükséges ahány betegség lehetséges). Építhetők finomabb eloszlások specifikusabb mintával; pl. Hány olyan beteg van az adatbázisban akik Alzheimerben szenvednek és 40 évnél fiatalabb és Budapesten laknak? Numerikus attribútumra (pl. vércukor) hasonló az eljárás, de ott a minta értéktartományokat tartalmaz (pl. hány olyan beteg van akiknek a vércukra 4.1 és 4.2 közé esik?). Az ilyen eloszlásokból pedig további statisztikák számolhatók; átlagok, szórások, medián, max, min, stb.

Rekord Nem Irányítószám Vércukor Betegség
1. Kovács Attila 1123 4.3 Meningitis
2. Kovács Attila 1123 5.2 Crohn-betegség
3. Kovács Ferenc 1114 6.1 Alzheimer
4. Kovács Ferenc 8423 3.2 Crohn-betegség
5. Kovács Ferenc 1114 7.1 Lábfejtörés
6. Nagy Tibor 1113 6.2 Crohn-betegség

1. táblázat: Kórházi adatok

A számláló lekérdezések univerzitása miatt általában elég ha csak a számláló lekérdezések eredményeit osztják meg (mint aggregált adatot), amit aztán további statisztikai adatok számításához felhasználhatnak a kérdezők. Ezért a továbbiakban csak ilyen lekérdezésekre fókuszálunk, és aggregált (statisztikai) adat alatt számláló lekérdezések eredményeinek összességét értjük.

FONTOS: A vizsgálat célja csakis az aggregált adat, nem az adatbázis amin az aggregátumot számoljuk. Más szavakkal a kérdés, hogy személyes adatnak minősülhetnek-e az aggregátumok (bizonyos mintára illeszkedő rekordok száma) egy olyan támadó számára, aki nem fér hozzá az adatbázishoz?

Interaktív és nem interaktív lekérdezések

Van amikor a cég megengedi, hogy a kérdezők (támadók) specifikálják a lekérdezéseket a korábbi lekérdezéseik függvényében (interaktív, online eset), de van amikor csak előre meghatározott lekérdezések eredményeit teszik közzé (nem interaktív, offline eset). Nyilván az interaktív eset veszélyesebb adatvédelmi szempontból, hiszen akkor a támadó a lekérdezéseit a korábbi lekérdezések eredményeinek a függvényében állíthatja össze (adaptív támadás).

Célzott támadás

Tekintsük Zsuzsa nénit az előző posztból, aki a Facebookon talál egy K. Ferenc nevű felhasználót. K. Ferenc megosztott képei alapján egy kis községben lakik, aminek az irányítószámát is megadta (8423), a 20-as éveiben jár, és krónikus bőrkiütésben szenved (a pontos betegségét ez alapján még nem ismeri). Zsuzsa néni ugyan az 1. táblázathoz nem fér hozzá, de jogosult az alábbi lekérdezéshez: Hány olyan beteg van aki az $X$ irányítószám alatt lakik és a betegsége $Y$? Ezután lefuttatja az összes olyan kérést, ahol $X=8423$ és $Y$ pedig egy olyan betegség, aminek tünete a krónikus bőrkiütés. Ha csak egy ilyen lekérdezés értéke 1 a többié pedig 0, akkor Zsuzsa néni megtalálta K. Ferenc pontos betegségét (erre jó esély van ha K. Ferenc vidéki, és a községben ahol él más nem volt a kórházban krónikus bőrkiütéssel).

Ismét látható, hogy a támadó háttértudása (a publikus információ, hogy egy fiatal K. Ferenc krónikus bőrkiütésben szenved és egy ismert községben lakik) lehetővé teheti személyes adatok visszafejtését aggregált adatokból. Ahogyan azt az előző posztban is megmutattuk, manapság a legtöbb emberről rengeteg nyilvános adat elérhető maguk vagy mások által, így a hasonló támadások létezését lehetetlen kizárni. Például előfordulhat, hogy Zsuzsa néni nemcsak bőrkiütést hanem egyéb más tünetet is megfigyel K. Ferencről a képei alapján, így a szóba jöhető betegségek száma kevesebb, vagyis még kevesebb lekérdezésből még nagyobb eséllyel kiderítheti K. Ferenc pontos betegségét. Például videón szereplő személyek pulzusa megállapítható pusztán a videóból az illetők tudta nélkül.

Naívan gondolhatnánk, hogy az ilyen támadások megelőzhetők ha nem válaszolunk meg olyan lekérdezéseket, amelyek eredménye túl kicsi (vagyis túl kevés rekordot fednek le). Sajnos ez nem mindig segít; pl. az 1. táblázatban az összes Crohn betegek száma 3 (első lekérdezés), a budapesti Crohn betegek száma 2 (második lekérdezés), akkor a kettő különbsége adja a vidéki Crohn betegek számát amire csak egy rekord illeszkedik (K. Ferenc), és amit így már nem kell lekérdezni (differencing attack). Az ilyen "problémás" lekérdezések detekciója nem mindig könnyű, mivel általános esetben két lekérdezés ekvivalenciája eldönthetetlen, valamint az egyes rekordok kiszámíthatóságának eldöntése adott aggregátumokból gyakran nehéz probléma.

A következőkben több személyt érintő globális (mass) támadásokra fókuszálunk, és a fenti differencing támadás ötletét általánosítjuk; megmutatjuk, hogy ha elég sok lekérdezést válaszolnak meg, akkor egy támadó képes lehet az eredeti rekordokat visszaállítani a lekérdezések összességéből függetlenül az egyes eredmények nagyságától. Először ezt egy olyan példán mutatjuk be, ahol a támadó a lekérdezéseket ő maga választja. Látni fogjuk, hogy kb. a rekordok számával megegyező lekérdezésekből a rekordok jó része helyreállítható. A második példában a támadó nem interaktív, vagyis nem képes a lekérdezéseket megválasztani, de így is rekonstruálhatja a rekordok több mint 70%-át az adat jellemzőit (mint háttértudást) kihasználva.

Globális támadás 1: Rekordok interaktív helyreállítása

A támadás alapötlete, hogy minden egyes megválaszolt lekérdezéssel növeljük egy sikeres differencing támadás esélyét valamely rekordra. Kicsit pontosabban, minden megválaszolt lekérdezés egy egyenletet definiál a lefedett rekordokon mint ismeretleneken. Ha elég sok egyenletünk (megválaszolt lekérdezésünk) van, akkor azok egyértelműen megoldhatóvá válnak és az ismeretlenek (rekordok) meghatározhatók.

Vegyük példaként a 2. és 3. táblázatot, ahol a 2. táblázat a 3. táblázatban szereplő egyének kvázi azonosítóit tartalmazza. A 3. táblázat első attribútuma az illető korának felel meg (ugyanaz mint a 2. táblázat 3. oszlopa), a többi attribútumok pedig Budapest főbb helyeit (POI) reprezentálják, és értékük 1, ha az illető meglátogatta az adott helyet, egyébként nulla. Tegyük fel, hogy a két táblázat rekordjai ugyanahhoz a személyhez tartoznak (vagyis a 3. táblázat $i$-ik sora és 4. táblázat $i$-ik sora ugyanazon személy adatai).

Rekord Nem Kor Lakhely
1. Férfi 23 Budapest
2. 43 Budapest
3. Férfi 45 Budapest
4. 36 Budapest
... ... ... ...

2. táblázat: Demográfiai adatok (kvázi azonosítók)

A 2. táblázathoz hozzáfér a támadó, viszont a 3. táblázathoz nem. Tegyük fel továbbá, hogy a támadó az alábbi $Q([X,Y],Z)$ lekérdezést hajthatja végre: Hány olyan személy van a 3. táblázatban, akiknek kora az $[X, Y]$ intervallumba esik és meglátogatták a $Z$ helyet? Vagyis $Q([X,Y], Z)$ azon rekordok számát jelöli, ahol a kor értéke legalább $X$ és legfeljebb $Y$, valamint $Z$ attribútum/hely értéke 1. Tegyük fel, hogy nem válaszolunk meg túl kevés rekordot lefedő lekérdezéseket (pl. ha $Q([X,Y],Z) < 10$), az adatbázisban pedig több száz rekord van. A támadó célja a 3. táblázat rekonstruálása a lekérdezések eredményeit és a 2. táblázatot felhasználva.

Rekord Kor Móricz Zsigmond körtér Allee Mom Park ... Széll Kálmán tér
1. 23 0 1 1 ... 0
2. 43 1 1 1 ... 0
3. 45 0 0 0 ... 1
4. 36 0 0 1 ... 1
... ... ... ... ... ...

3. táblázat: Helyzeti adatok

Először csak egy oszlopot rekonstruálunk, a többi hasonlóan történik. Legyen $Z$ egy előre kiválasztott hely (pl. $Z$ = "Allee"). A cél a 3. táblázat $Z$ értékének megfelelő oszlopának rekonstruálása, amit $x_1, x_2, \ldots, x_n$ ismeretlenekkel jelölünk és ahol $n$ az összes rekordok száma a táblázatban (vagyis $x_i=1$ ha a támadó szerint az $i$-ik rekord meglátogatta a Z helyet, egyébként $x_i=0$). A támadás lényegében egy egyszerű lineáris egyenletrendszer megoldásából áll:

  1. Válaszd a kor lehetséges értékeinek egy véletlen intervallumát (pl. $[X=32;Y=40]$)?
  2. Kérdezd a $Q([X,Y],Z)$ értékét
  3. Ismételd meg a fenti műveleteket $t$-szer, így kapod $t$ darab lekérdezés eredményeit: $Q_1([X_1, Y_1], Z), Q_2([X_2, Y_2], Z), \ldots, Q_t([X_t, Y_t], Z)$
  4. Minden $Q_j$ lekérdezéshez határozd meg azon $S_j \subseteq \{1,2, \ldots, n\}$ rekordok halmazát a 2. táblázatból, amelyet a $Q_j$ lekérdezés lefed (vagyis a koruk a $[X_j, Y_j]$ intervallumba esik).
  5. Old meg az alábbi $t$ egyenletből és $n$ feltételből álló lineáris egyenletrendszert: $$ \begin{matrix} \sum_{i \in S_1} x_i = Q_1([X_1, Y_1], Z),\\ \sum_{i \in S_2} x_i = Q_2([X_2, Y_2], Z), \\ \vdots\\ \sum_{i \in S_t} x_i = Q_t([X_t, Y_t], Z), \end{matrix} $$ $$\text{ahol:}\; 0 \leq x_i \leq 1$$

  6. Kerekítsd $x_i$ értékeit: $x_i = 1$ ha $x_i > 1/2$, máskülönben $x_i = 0$

Bebizonyítható, hogy $t= n \log^2 n$ megválaszolt lekérdezés esetén a 6. lépésben kapott $x_i$ értékek nagy része helyes (tehát $x_1, x_2, \ldots, x_n$ megegyezik a 3. táblázat $Z$ értének megfelelő oszlopával), és így az eredeti adatbázis $Z$ értékének megfelelő oszlopa rekonstruálható. Pl. ha az adatbázisban 128 rekord van, akkor abból legalább 124 helyreállítható így.

Természetesen a 3. táblázat egy visszaállított oszlopa önmagában még nem minősül személyes adatnak, hiszen ahhoz minden visszaállított értékhez hozzá kellene rendelni egy természetes személyt. Ezért a fenti támadás megismételhető több, mondjuk $k>20$ oszlopra/helyre. Ha valaki szerepel az adatbázisban, akkor annak 5-10 helye már egyértelműen azonosítja azt, ezért az illető publikusan elérhető Facebook/Instagram profilja összevethető a rekonstruált rekordokkal; jó eséllyel csak az ő rekonstruált rekordja fogja a Facebook profiljában szereplő helyek együttesét tartalmazni. Mivel a rekonstrukciós pontosság magas, a támadás sikervalószínűsége elég nagy. Így ha a támadás plauzibilis (a támadó valóban hozzáfér a 2. táblázathoz és a személyek közösségi profiljához), akkor a lekérdezések összessége személyes adatnak minősülhet a GDPR szerint.

Megjegyzések:

  1. A 4. lépésben megoldandó egyenletrendszer azért lineáris, mert a lekérdezések (subset-sum query) az attribútum-értékek lineáris függvénye (jelen esetben összege). Az egyenletrendszer bármely LP solver-rel megoldható (pl. CPLEX, glpk, stb.).
  2. Az eredeti adatbázis visszaállíthatósága $t= n \log^2 n$ lekérdezés esetén garantált, ahol minden lekérdezés minden rekordot 1/2 eséllyel tartalmaz. Ez a fenti példában nem feltétlen igaz, hiszen ott a kor alapján választunk egyenletes eloszlás szerint nem pedig magukat a rekordokat 1/2 valószínűséggel (ebből az is következik, hogy a fenti támadás nem adaptív). Ennek ellenére a gyakorlatban a támadás jó eséllyel működik.
  3. A megoldandó egyenletrendszer $n$ változót és $t= n \log^2 n$ egyenletet/feltételt tartalmaz. Létezik olyan támadás, ami $t= n$ lekérdezéssel hasonló rekonstrukciós pontosságot ér el, viszont itt a lekérdezéseket determinisztikusan és nem véletlenszerűen választják.
  4. Ezek a támadások akkor is működhetnek, ha a lekérdezések értékéhez véletlen zajt adunk hozzá (query perturbation). Ebben az esetben egyenletek helyett egyenlőtlenségek rendszerét kell megoldani, aminek megoldása az első támadással a legrosszabb esetben $O(n^5 \log^4 n)$ lépést, míg a másodikkal csak $O(n\log n)$ lépést igényel. Ha a zaj által okozott abszolút hiba legfeljebb $E$, akkor $n - 4E^2$ rekord helyreállítható. Pl. ha $n=256$ és $E=3$, akkor 220 rekord helyreállítható. Viszont érdekes módon $E > \sqrt{n}$ torzítás már megakadályozhatja a rekordok rekonstrukcióját.

Globális támadás 2: Telekom (CDR) adatok nem interaktív helyreállítása

A fenti támadás azért működik, mert a támadó a lekérdezéseket (pontosabban azok mintáját) képes megválasztani. Ebben az is segíti, hogy hozzáfér minden rekord kvázi azonosítóihoz (2. táblázathoz), és így pontosan tudja, hogy melyik lekérdezés melyik rekordokat fedi le. Ha ezt nem tudná, akkor az 5. lépésben definiált egyenletrendszer nem lenne megoldható, hiszen nem tudná, hogy pontosan melyik ismeretlenek (rekordok) szerepelnek az egyenletek bal oldalán. Felmerül a kérdés: sikeres lehet-e egy olyan nem interaktív támadás, ahol a lekérdezéseket a támadó nem tudja megválasztani, a rekordok többségének kvázi azonosítóit nem ismeri, és csak előre definiált lekérdezések eredményét ismerheti? Ez egy gyengébb támadó jóval kevesebb háttértudással, és így sokkal inkább plauzibilis a gyakorlatban. Ha egy ilyen plauzibilis támadó sikervalószínűsége elég nagy, akkor gyanítható, hogy az aggregált adat személyesnek minősül még a GDPR 4. cikkének értelmében is. Ezt megerősítve a következőkben bemutatunk egy közelmúltban publikált támadást egy gyakorlati alkalmazáson a fenti plauzibilis támadót feltételezve.

Az adat

Napjainkban népszerű statisztikai adat az emberek térbeli sűrűsége, vagyis bizonyos helyek (POI-k) látogatottsága az idő függvényében. Ez az aggregált adat értékes, hiszen felhasználható közlekedési hálózat optimalizációjára, új szolgáltatások (pl. áruházak) telepítési helyének meghatározásához, de akár járványok terjedésének modellezéséhez is. Egy populáció ilyen térbeli eloszlása jól becsülhető a használatban levő mobiltelefonok helyzeti információiból; amikor egy előfizető hívást vagy adatforgalmat kezdeményez/fogad, rögzítésre kerül a telefontorony (és az időpont), amellyel az előfizető telefonja kapcsolatban van. Mivel az ilyen tornyok elég sűrűn helyezkednek el (főleg sűrűn lakott területen), így a tornyok pozíciójából az előfizetők térbeli helyzete jól becsülhető.

Ezt felismerve sok telekom cég monetizálná az ilyen hívási (ún. CDR) meta-adatokat. Viszont, ahogy az előző posztban is utaltunk rá, egy ilyen adatbázis nagy valószínűséggel sok személyes adatot tartalmaz, hiszen egy előfizető 4-5 tornya már jó eséllyel egyedi azonosítónak számít. Ezért a telekom cégek többsége a CDR adatot nem osztja meg, hanem csak az abból számolt aggregátumokat; minden toronyhoz az ott tartózkodott előfizetők számát minden fél órában (vagyis minden toronyhoz egy idősort). A következőkben megmutatjuk, hogy az ilyen statisztikai adat is lehet személyes.

A támadás célja

Adott $n$ előfizető akiknek hívási adataikat rögzítik $m$ toronynál az eredeti CDR adatbázisban. Az egyes tornyokat jelölje $T_1, T_2, \ldots, T_m$. Ebből az adatbázisból a cég minden $t$ időpontban kiszámolja a $\mathbf{P}^t = (p_1^t, p_2^t, \ldots, p_m^t)$ torony-látogatottságokat, ahol $p_j^t$ jelöli az $T_j$ toronynál levő előfizetők számát a $t$-edik időintervallumban/időpontban (pl. egy fél óra alatt). A cég csakis a $\mathbf{P}^t$-t osztja meg másokkal, bízva abban, hogy az ilyen aggregált adat nem minősül személyes adatnak.

Legyen $Y_{i,j}^t = 1$, ha az $i$-edik előfizető meglátogatta $T_j$ tornyot a $t$ időtartományban, máskülönben 0. Így $\mathbf{Y}^t$ egy $n \times m$ méretű bináris mátrix ami az egyes előfizetők toronylátogatásait reprezentálja $t$ időpontban. A támadás célja az $Y_{i,j}^t$ értékek rekonstruálása minden $i$ előfizetőre, $T_j$ toronyra, és $t$ időpontra úgy, hogy (1) $\sum_{i=1}^n Y_{i,j}^t = p_{j}^t$, vagyis az $\mathbf{Y}^t$ mátrix $j$ oszlopában található elemek összege a $T_j$ tornyot meglátogatott előfizetők száma egy időpontban, valamint (2) $\sum_{j=1}^m Y_{i,j}^t = 1$, vagyis egy előfizető egy időpontban (itt fél órában) csak egy tornyot látogathat meg. Ha többet látogat meg, akkor vesszük a legtöbbet meglátogatott tornyot az adott fél órában. Mivel vannak előfizetők akik nem minden fél órában használják a telefonjukat, az ilyen fél órákban a feltételezett toronylátogatásokat interpolációval becsüljük az ismert toronylátogatásokból.

A támadás alapötlete és menete

Ugyan a támadás első hallásra meghökkentő, az adat jellegét megnézve már nem tűnik olyan hihetetlennek. Valójában az adat három fő tulajdonságát használják ki:

  1. Predikálhatóság: Minden előfizető tornya egy adott időpontban jól becsülhető a korábban meglátogatott tornyokból; az időben következő torony szinte mindig közel van földrajzilag az éppen meglátogatott toronyhoz. Ezt azt is jelenti, hogy az előfizetők (ill. rekordjaik) jól szeparálhatók, hiszen ha két rekord $t$ időpontban távol van egymástól, azok jó eséllyel a $(t+1)$-ben is távol lesznek egymástól.

  2. Regularitás: Az előfizetők többsége minden nap hasonló (gyakran ugyanazon) tornyokat látogatja meg hasonló időkben, mivel a legtöbb ember napi rutinjai azonosak.

  3. Egyediség: Az előfizetők egymástól elég különböző tornyokat látogatnak meg, amit már több tanulmány szemléltetett; egy több milliós populációban egy előfizető bármely 4 meglátogatott tornya (az időpont órás pontosságával) egyedivé teszi őt az előfizetők között az esetek 98%-ában.

A három tulajdonságot szemlélteti az alábbi ábra, ahol 5 különböző előfizető térbeli helyzete látható két egymást követő nap.

alt text

A támadás először a rekordok predikálhatóságát felhasználva rekonstruálja a rekordokat (azaz az $\mathbf{Y}^t$ mátrixot) minden $t$-re egy napon belül, feltéve, hogy $\mathbf{P}^t$ ismert. Ezt megismétli minden egyes napra külön-külön. Végül a rekordok regularitását és egyediségét felhasználva az azonos előfizetőhöz tartozó rekonstruált rekordokat összerendeli a napok között.

Rekordok rekonstruálása adott $t$ időpontban

Tegyük fel, hogy a $(t-1)$-beli toronylátogatások ismertek $\mathbf{Y}^{t-1}$ formájában, valamint az összes torony látogatottsága $t$-ben $\mathbf{P}^t$ formájában. Hogyan tudnánk ezekből rekonstruálni $\mathbf{Y}^{t}$-t? Ha egy előfizető a $(t-1)$-ben a $T_j$ tornyot látogatta meg, akkor jó eséllyel a $t$ időpontban a $T_j$ toronyhoz közelebbi tornyokat fogja meglátogatni, vagyis lesznek tornyok amiket nagyobb eséllyel látogat meg, és lesznek amiket kisebb eséllyel a korábban meglátogatott tornyok (pl. $T_j$) függvényében. Így minden előfizető-torony $(i,j)$ párhoz hozzá tudunk rendelni egy $c_{i,j}^t$ "költséget" az idő függvényében, aminek értéke nagyobb, ha az $i$ előfizető kisebb eséllyel látogatta meg a $T_j$ tornyot, és kisebb, ha nagyobb eséllyel látogatta azt meg a $t$ időpontban. Keressük azt az előfizetők és tornyok közötti összerendelést $t$ időpontban (vagyis $\mathbf{Y}^{t}$-t), ami az összes előfizetőhöz az általuk legnagyobb eséllyel meglátogatott tornyokat rendeli. Lényegében az alábbi optimalizációs problémát kell megoldanunk minden $t$ időpontban, ahol az ismeretlenek $\mathbf{Y}^{t}$ mátrix elemei:

$$ \begin{matrix} \text{Adott}\; P^t = (p_1^t, p_2^t, \ldots, p_m^t), \\ \text{minimalizáld}\; \sum_{i=1}^n \sum_{j=1}^m c_{i,j}^t \times Y_{i,j}^t\; \text{összeget,}\\ \text{feltéve, hogy }\; Y_{i,j}^t \in \{0,1\},\: \sum_{i=1}^n Y_{i,j}^t = p_{j}^t,\: \sum_{j=1}^m Y_{i,j}^t = 1 \end{matrix} $$

A feladatot elképzelhetjük mint az alábbi gráf probléma megoldását minden $t$ időpontban. A gráf bal oldalán vannak az előfizetőknek megfelelő csúcsok, a jobb oldalon pedig a tornyoknak megfelelő csúcsok. Élek csakis a két oldal között lehetnek, ahol minden él súlya megegyezik az adott előfizető-torony pár költségével. Egy $i$ előfizető és $j$ torony között akkor van él, ha az $i$ előfizető meglátogatta $j$ tornyot a $t$ időpontban. A feladat a bal és jobb oldali csúcsok összekötése úgy, hogy (1) minden jobb oldalon levő csúcshoz (toronyhoz) csakis annyi bal odalon levő csúcsot (előfizetőt) köthetünk, ahányan meglátogatták azt a tornyot $t$ időpontban (ez adott $\mathbf{P}^t$ által), (2) egy bal oldali csúcshoz (előfizetőhöz) csakis egy jobb oldali csúcs (torony) rendelhető, mivel egy előfizető bármely időpontban csak egyetlen tornyot látogathat meg, (3) az összes így kapott él súlyának összege (összköltség) minimális legyen (vagyis keressük a globálisan legvalószínűbb toronylátogatásokat). Ez egy összerendelési probléma (assigment problem) ami hatékonyan megoldható a magyar módszerrel, viszont ehhez a gráf minimális átalakítása szükséges.

Egész pontosan a magyar algoritmus olyan esetekben működik, ahol egy bal oldali csúcshoz csakis egy jobb oldali csúcs tartozhat, és egy jobb oldalihoz csakis egy bal oldali. Az így kapott súlyozott teljes páros gráfon képes az eljárás minimális/maximális összsúlyú teljes párosítást keresni. Ez könnyen elérhető a mi esetünkben, ha minden tornyot annyi csúccsal reprezentálunk, ahányan meglátogatták azt a $t$ időpontban, valamint egy adott előfizetőt egy torony "replikált" csúcsaihoz azonos költséggel rendelünk (más szavakkal egy $i$ előfizetőt a $T_j$ toronyhoz tartozó csúcs bármelyikéhez csakis $c_{i,j}^t$ súlyú éllel köthetünk). Ebből következik, hogy az átalakított gráf bal és jobb oldalán levő csúcsok száma megegyezik. A két gráf közötti különbséget szemlélteti az alábbi ábra, ahol $p_1^t=2$ és $p_2^t=1$ (vagyis az első tornyot ketten látogatták meg $t$-ben, ezért azt két darab csúccsal reprezentáljuk az átalakított gráfban, míg a másodikat csak eggyel).

Eredeti gráf Átalakított gráf
alt text alt text

A támadás menete a következő: A $t=1$ időpontban tetszőlegesen kitöltjük az $\mathbf{Y}^1$ mátrixot azokkal a feltételekkel, hogy (1) $Y_{i,j}^1 \in \{0,1\}$, (2) $\sum_{i=1}^n Y_{i,j}^1 = p_{j}^1$, és (3) $\sum_{j=1}^m Y_{i,j}^1 = 1$. Ezek után alkalmazzuk a fenti optimalizációs eljárást, és rekonstruáljuk $\mathbf{Y}^t$-t minden $t>1$ időpontra egymás után egy napon belül, majd ezt az eljárást megismételjük minden napra külön-külön. A kérdés már csak az, hogyan kell a $c_{i,j}^t$ költség-értékeket beállítani? Az alábbiakban látni fogjuk, hogy ennek beállítása napszaktól függ: mivel nappal az előfizetők másként mozognak mint éjszaka, ezért $c_{i,j}^t$ értéke ennek megfelelően különböző a nappali és éjszakai időszakokban.

Éjszakák és nappalok

Éjszaka az emberek többsége otthon van, és nem mozog; ahogy a szerzők is megmutatták, az előfizetők több mint 60%-a csak egyetlen tornyot, míg 20%-a csak két különböző tornyot látogat meg az éjszaka folyamán. Sőt (nem meglepő módon) az emberek 90%-ának ez egyben megegyezik a leggyakrabban meglátogatott (otthonukhoz közel levő) toronnyal.

Ennek megfelelően feltételezhető, hogy éjszaka minden torony költsége arányos a legutolsó időpontban meglátogatott toronytól mért távolságával. Pontosabban legyen egy $T_j$ torony földrajzi pozíciója $q_j$ minden $1 \leq j \leq m$-re. Ha egy $i$ előfizető a $t-1$ időpontban a $T_j$ tornyot látogatta meg (vagyis $Y_{i,j}^{t-1} = 1$), akkor $c_{i,k}^t = \text{distance}(q_j, q_k)$ minden $1 \leq k \leq m$-re.

Nappal viszont az emberek gyakran mozognak, ezért a költségek máshogy alakulnak. Nappal egy előfizető által meglátogatott torony jól becsülhető az utolsó időpontban meglátogatott toronyból, valamint az előfizető mozgási sebességéből. Pontosabban ha egy $i$ előfizető a $(t-2)$ időpontban a $T_{s}$ tornyot, $t-1$-ben pedig a $T_{j}$ tornyot látogatta meg (vagyis $Y_{i,s}^{t-2} = 1$, $Y_{i,j}^{t-1} = 1$), akkor $c_{i,k}^t = \text{distance}(q_k, q_j + (q_j - q_s))$ minden $1 \leq k \leq m$-re.

Rekordok összerendelése egymást követő napokon

Egy megoldás lehet ha a $\mathbf{Y}^t$-t a fenti módszerrel rekonstruáljuk tetszőleges $t$ időpontig figyelembe véve a nappalok és éjszakák közötti különbségeket. A gyakorlatban viszont a rekordok regularitása és egyedisége miatt jobb eredményt kapunk, ha az egész folyamatot minden nap újrakezdjük, és az egyes napokat egymástól függetlenül rekonstruáljuk, végül az azonos előfizetőhöz tartozó rekordokat összkapcsoljuk az egyes napok között a következő módszerrel.

Vegyünk két rekonstruált rekordot két egymást követő nap. Ha a két rekord ugyanahhoz az előfizetőhöz tartozik, akkor a két rekord relatív (egymáshoz viszonyított) információ tartalma kicsi, mivel mindkét rekordban hasonló gyakorisággal látogatták meg ugyanazon tornyokat (regularitás miatt). Vagyis ha az egyik nap ismerjük az előfizető rekordját, akkor a következő napi rekordja már nem hordoz túl sok információt az előző napihoz képest. Precízebben, ha kiszámoljuk a két rekord entrópiájának átlagát, illetve a két rekord összefűzéséből kapott összesített rekord entrópiáját, a két értéknek hasonlónak kell lenniük ha a rekordok is hasonlóak, és a kettő közötti különbséget nevezzük információs nyereségnek (information gain). Tehát ha két rekord hasonló, akkor a kettő relatív információs nyeresége 0-hoz közeli, máskülönben 1-hez közeli.

Miután két egymást követő nap rekonstruáltuk az összes rekordot (ezeket az egy naphoz tartozó $\mathbf{Y}^t$ mátrixok azonos sorszámú sorainak az összefűzéséből kapjuk), akkor kiszámoljuk az összes így kapott rekord és a következő nap hasonló módon kapott rekordjai közötti információs nyereséget. A feladat ezután a különböző napok rekordjainak összepárosítása úgy, hogy a kapott párosítások összköltsége (a páronkénti információs nyereségek összege) minimális legyen. Ez szintén a fentihez hasonló összerendelési probléma, és szintén megoldható a magyar módszerrel. Ez az összerendelés azért fog működni, mert minden rekord egyedi, és az azonos előfizetőhőz tartozó rekordok minden nap nagyon hasonlóak.

Eredmények

A szerzők kipróbálták a fenti támadást két adatbázison. Az első (Operator) 100 000 előfizető CDR adatát tartalmazta, vagyis minden előfizetőhöz rögzítették az időpontot és tornyot amikor az illető a mobilhálózatot használta 1 hetes időtartományban. A második (App) adatbázis 15 000 felhasználó tornyát rögzítette 2 hetes időtartományban, amikor azok elindítottak egy adott alkalmazást. Mindkét adatbázis ugyanabból a városból származik, amely 8000 toronnyal van lefedve. Mindkét esetben kiszámolták, hogy csakis $\mathbf{P}^t$-t felhasználva átlagosan egy előfizető hány torony-látogatását tudják helyesen rekonstruálni (vagyis a látogatás tornyát és idejét). Az eredményt az alábbi ábra mutatja.

alt text

Stage1/Stage2 jelenti az éjszakai időtartománynak megfelelő rekordrészek átlagos rekonstrukciós pontosságát, míg Stage3 az egész támadás átlagos pontosságát a rekordrészek összefűzése után. Látható, hogy átlagosan egy rekord 91%-át sikeresen rekonstruálták az App adatbázisból számolt statisztikai adatból, míg ez az érték 73% az Operator adatbázis esetén.

Mivel a rekonstrukciós pontosság magas és 4-5 rekonstruált toronylátogatás már 95%-os eséllyel egyedi egy előfizetőre nézve akár egy több milliós populációban, ezért a támadás sikervalószínűsége nagy. Sőt, az előfizetők azonosításához szükséges 4-5 torony meghatározása könnyű publikus Facebook/Instagram/Twitter profilokat felhasználva. Mivel más háttérinformáció nem szükséges az előfizetőkről, a támadás plauzibilis is, vagyis az egyes tornyok látogatottsága az idő függvényében ($\mathbf{P}^t$) jó eséllyel személyes adatnak minősül a GDPR 4. cikke szerint is.

Konklúzió

Láthattuk, hogy statisztikai adatok azért minősülhetnek személyesnek, mert azokból az eredeti adatbázis rekordjainak nagy része gyakran helyreállítható. Ennek oka, hogy ha túl sok aggregált adatot adunk ki (pl. túl sok lekérdezést válaszolunk meg), akkor még ha egyenként nem is, de a válaszok együttvéve jelentős információt szivárogtatnak ki az adatbázis egyes rekordjairól. Azt is láthattuk, hogy a lekérdezések tiltása az eredményeik nagysága alapján (vagyis amikor túl kicsi eredményű lekérdezést nem válaszolunk meg) nem feltétlen nyújt védelmet az ilyen támadások ellen, mivel nem a lekérdezések értéke, hanem a megválaszolt különböző lekérdezések száma és a támadó háttértudása (pl. az adat jellemzői) számítanak.

Hogyan védekezhetünk? Alapvetően két megközelítés létezik:

  1. A lekérdezések auditálása (query auditing), vagyis annak ellenőrzése, hogy a megválaszolandó lekérdezések lehetővé teszik-e valamely rekord rekonstruálását (pl. a fentihez hasonló egyenletrendszer megoldásával). A megközelítés feltevése, hogy ismerjük a legjobb rekonstrukciós eljárást, és megnézzük, hogy az sikeres lenne-e ha megválaszolnánk a lekérdezéseket. Ez a GDPR-nak meg is felelhet, ha a rekonstrukció sikervalószínűsége nem túl magas és a rekonstrukciós eljárás "plauzibilis" a gyakorlatban (vagyis a potenciális támadók valóban nem fognak ennél jobbat használni). Viszont az eddigiek tükrében két problémával érdemes számolni: (1) A legtöbb auditálási eljárás feltételezi, hogy a támadónak nincs háttértudása a rekordokról. Ahogy fent láttuk, ez a gyakorlatban nem mindig igaz; pl. ismerhet néhány rekordot, vagy ismeretlen rekordokról lehet részleges tudása (ld. predikálhatóság, regularitás, egyediség). Ez a támadót segítheti, hiszen például a vártnál kevesebb lekérdezésből képes lehet az ismeretlen rekordokat visszaállítani. Ugyanakkor ezt a háttértudást a gyakorlatban szinte lehetetlen modellezni az egyének magukról vagy másokról megosztott információk sokasága miatt. (2) Ha mégis sikerül detektálni a problémás lekérdezést (ami egyébként nehéz), akkor dönthetünk úgy, hogy azt nem válaszoljuk meg. Ekkor viszont nem adunk ki adott esetben értékes adatot, aminél van jobb megoldás is (ld. alább).
  2. A lekérdezések eredményeinek zajosítása/randomizálása (query perturbation), vagyis mielőtt kiadnánk a lekérdezések eredményét, hozzáadunk azokhoz egy zérus várható értékű $\lambda$ szórású zajt. Ha $\lambda$ (és így a zaj várható nagysága) kisebb, az érték pontosabb, viszont a fenti támadások nagyobb eséllyel működhetnek. Ha $\lambda$ nagyobb, akkor az adat jobban védett a nagyobb zaj miatt, és a fenti támadások kisebb eséllyel működnek (viszont a kiadott adat is pontatlanabb). Ez egy alapvető kompromisszum a statisztikai adatok hasznossága (pontossága) és a személyes adatok védelme között az informatikában. A zaj nagyságának megfelelő beállítása nem könnyű és szakértelmet igényel, ami a manapság egyre szélesebb körben alkalmazott Differential privacy-nek is az alapja. A gyakorlatban ezt a megközelítést alkalmazta már a Google, majd később az Apple és Uber is.

A CrySyS laborban lekérdezések auditálásával illetve lekérdezések eredményeinek torzításával is aktívan foglalkozunk.

Posted on Leave a comment

DEFCON '17 – A verseny

A Föld legelismertebb hacker versenye a DefCon konferencia Capture-the-Flag versenyének döntője, amit minden évben Las Vegas városában rendeznek, idén már 21. alkalommal. Az előző évekhez képest változás volt, hogy az eddig megszokott Bally’s helyett a Caesars Palace-ben rendezték meg a versenyt. A döntőbe jutáshoz egész évben rendeznek kvalifikációs versenyeket, és nagy örömünkre hackercsapatunk, a !SpamAndHex idén is részt vehetett a döntőben, immár harmadszorra.

A döntő egy több napos esemény, ahol a világ legjobbjai mérik össze tudásukat és stratégiájukat, idén 15 csapat. Mert ugyan nagyon fontos megtalálni és javítani a hibát, valamint a sikeres támadás pontot ér, de ez nem minden. A versenyen valóshoz közeli szituációban kell helyt állni: a csapatoknak a sérülékenység-keresés és a titkos információk megszerzése mellett IT rendszert is kell üzemeltetniük. És ha nem elérhető egy szolgáltatás, akkor a csapat pontokat veszít, mert a való életben sem örülünk, ha nem férünk hozzá a szükséges szolgáltatáshoz.

És itt jön képbe a stratégia. Ha sikeresen támadunk a versenyen és megszerezzük a titkos információt, pontot nyerünk. Ha nem elérhető egy-egy szolgáltatás, pontot veszítünk. Viszont minden csapat ugyanazokat a szolgáltatásokat üzemelteti, vagyis ha megtámadunk valakit, azzal nem csak pontot szerzünk, hanem a hibára is rávezetjük a másik csapatot. Ráadásul mutatunk nekik egy működő támadást, amit akár ellenünk is felhasználhatnak. Szóval védekezni is kell: ha megtaláltuk a sérülékenységet, nem csak ki kell használnunk mások rendszerében, hanem javítanunk is kell a sajátunkban.

Az üzemeltetési felelősség miatt a csapatok kapnak némi felkészülési időt, hogy kiismerjék a rendszert, amiért felelnek. A döntőben ez a verseny kezdete előtti nap volt. Itt találkoztunk először a cLEMENCy platformmal, ami nagyon távol áll a megszokott IT rendszerektől. Hagyományos rendszerekben a memóriában a legnagyobb helyi értékű számjegyet vagy a szám végén (big-endian), vagy a szám elején (little-endian) szokás tárolni. Ezzel szemben a cLEMENCy middle-endian, vagyis a legnagyobb helyi értékű számjegy a szám közepén helyezkedik el. Ez kihívássá teszi a memória olvasását és értelmezését, ráadásul nem léteznek kész eszközök, amik ezt kezelni tudnák. Arról nem is beszélve, hogy a cLEMENCy-n minden byte 9 bitből áll az általánosan megszokott 8 helyett. Vagyis adott egy nagyon különleges platform és egyetlen egy nap (!), hogy elkészüljenek azok a szoftverek, amelyek segítenek a platformra készült feladatok megoldásában.

Alapvetően háromféle szoftverre van szükség: assembler, wrapper és disassembler. Először az assemblert készítettünk el, hogy a saját magunk által írt programokat lefordíthassuk a cLEMENCy platform nyelvére és futtathassuk azt. A futtatáshoz egy emulatort kaptunk, vagyis nem egy fizikailag létező számítógépen futottak a feladatok, hanem egy kibertérben futtatott számítógépen. Az emulator köré készítettük el a wrappert, hogy szüneteltethessük a programok futását és futás közben megnézhessük a memória, valamint a regiszterek tartalmát. Ez sokat segített hibakeresés közben, de még mindig hiányzott a disassembler. Ugyanis a futtatható binárisok értelmezését és visszafejtését nem gépi kód szinten szoktuk végezni, hanem megpróbálunk visszalépni az ún. assembly szintre, ami ugyan sokkal kevéssé olvasható, mint egy jól ismert programozási nyelven írt forráskód, de legalább az utasításokat és operandusaikat nem számokként látjuk, hanem olvasható formában tudjuk értelmezni.

A verseny első napján a szervezők reggel 9 órakor nyitották meg a CTF termet a versenyző csapatok előtt. A csapatok 1 órát kaptak, hogy felállíthassák hálózataikat, majd 10 órakor megkezdődött a verseny.

A tavalyi megmérettetéshez hasonlóan a csapatok szolgáltatásai egy központi helyen futottak. A szolgáltatásokhoz tartozó futtatható binárisokat egy webes felületen lehetett lecserélni, azonban minden csere látható volt minden más csapat számára. Ezt az jelentette, hogy akár egy másik csapat által készített futtatható binárist is használhatott egy csapat. Ez azonban veszélyeket is rejt magában. Ha értelmezés nélkül kezdenénk el lecserélni a futtatható binárisainkat azokra, amiket a többiek készítettek, előfordulhat, hogy hátrányba kerülünk a többiekkel szemben, mert pl. nem képes futni a progam, vagy rejtett csapdát helyeztek el benne a készítők.

A legelső feladatot rubix névre keresztelték a szervezők és a Rubik-kocka megoldását implementálta. Az első dolog, ami megütötte a szemünket, az volt, hogy a program az emulátorban csak bináris adatokat jelenített meg a képernyőn. Ezért nagyon gyorsan le kellett fejlesztenünk egy kisebb szoftvert, ami a 9-bites bájtokat lefordította 8-bites bájtokra. Ezután tudtuk csak elkezdeni értelmezni a feladat kimenetét. Ezt a feladatot először a HITCON csapat oldotta meg, majd lassan a többi csapattól is elkezdtek beérkezni a megoldások.

A nap folyamán további 2 feladatot adtak ki a szervezők, amiket szinten a HITCON csapat oldott meg elsőre. Összesen 10 órán keresztül tartott ez a nap, ami elég fárasztó volt. Sikerült támadást készítenünk a rubix feladathoz és két másikhoz is. Azonban hamar rájöttünk, hogy az eszközeink nem elég hatékonyak, nem tudjuk elég gyorsan megérteni a futtatható binárisok működését. Ezért egyre nagyobb hangsúlyt helyeztünk a hálózati forgalom elemzésére is. A célunk az volt, hogy a hozzánk érkező hálózati forgalomból ki tudjuk emelni a támadásokat, amiket más csapatok indítottak ellenünk. Azonban ez csak első olvasásra ilyen egyszerű, mivel a folyamat tele volt hamis riasztásokkal a szervezők által beszúrt direkt félrevezető forgalom miatt. Ráadásul a hálózatelemző szoftvert (Wireshark) is át kellett írnunk, hogy 9-bites bájtokkal dolgozzon.

A második nap végére a 15. helyen álltunk.

A verseny utolsó napja már csak 4 órás volt. A korábbi évekhez hasonlóan a scoreboardot nem láthattuk így csak az előző este eredményeire lehetett támaszkodni. Ez a nap is egy új szolgáltatással indult babyecho néven, ami gyakorlatilag egy nagyon egyszerű format string sérülékenységet tartalmazott. A feladat érdekessége az volt, hogy a nyilvánosságra hozatalt követően 1-2 percen belül a Tea Deliverers már meg is oldotta. A verseny után a szervezőkkel beszélve Ők ennek kapcsán arra gyanítanak, hogy már előtte valahogyan meg tudták szerezni a binárist és úgy dolgoztak rajta előtte. Az persze kérdéses, hogy a verseny szabályzatával ez mennyire összeegyeztethető, de ezt most nem célunk megítélni. A lényeg, hogy ezt sérülékenységet mi is sikeresen kihasználtuk és javítottuk. A méréseink alapján az utolsó napon még 3 támadásunk sikeresen szerzett és küldött be flageket.

A verseny a szokásos módon a ‘Europe – The final countdown’ klasszikusával ért véget 2 órakor. A verseny után beszélgettünk több csapattal köztük a Shellphish-sel Santa Barbarából, a pasten-nel Izraelből vagy például az Eat, Sleep, Pwn, Repeattel Németországból.

A verseny záró eseményén a szokásokhoz híven csak az első három helyezettet sorolták fel, akik név szerint az immár negyedszerre győztes (és ezáltal a legsikeresebb csapat a DEFCON 21 éve alatt) PPP (USA), HITCON (Taiwan), A0E (Kína). Őszinte gratuláció a csapatoknak ezért a hihetetlen eredményért!

Összességében elmondható, hogy a tavalyi évhez hasonlóan nagyon sokat számított, hogy egy adott csapat milyen eszközkészlettel rendelkezett a verseny megkezdése előtt, illetve mennyire ügyesen tudta ezeket a toolokat felhasználni. Nálunk sajnos ezek nem tudtak eléggé kiforrni a verseny ideje alatt, így elég nagy hátrányban voltunk a verseny többi szereplőjéhez képest. Ettől függetlenül úgy gondoljuk, hogy ismét nagyon sok gazdag élménnyel gyarapodtunk.

Végül, de nem utolsó sorban hivatalosan is megköszönjük minden támogatónknak, hogy lehetővé tették a kiutazásunkat és ezáltal szerepelhettünk ismét ezen a világszintű megmérettetésen. A verseny tényleges eredményétől függetlenül büszkék vagyunk arra, hogy a világ 15 legjobb csapata között tudhatjuk magunkat évről évre és ezáltal nemcsak magunknak és a CrySyS Labornak, hanem talán az egész országnak is öregbítettük a hírnevét.

microseccrysysbalabitmrg-effitasesetukatemivikeuro-onetresoritpadi

Posted on Leave a comment

Defcon 2017 CTF – kezdetek

A CrySyS Lab egy olyan szervezet, ami folyamatosan fejlődik, átalakul, szervez, csinál, kitalál, megold, és úgy általában, aktív és dolgozik. Van egy hacker csapatunk, a neve !SpamAndHex. Van saját twitterük is https://twitter.com/SpamAndHex.

De mit csinál egy hacker csapat? A black hat hacker feltör rendszereket a saját előnyére, a white hat hacker biztonságosabbá teszi az Internetet, azáltal, hogy a felfedezett hibákat kezeli. A responsible disclosure az a folyamat, amikor egy hacker felfedez egy hibát, és azt nem csak úgy beleönti az Internetbe, hanem felelősségtelejesen segíti a hibát elkövető céget, hogy ki lehessen azt javítani. Az ethical hacker egy white hat hacker aki felkérésre dolgozik, általában pénzért.

A hacker csapat viszont más. A hacker csapat hacker versenyeken versenyez. Minden nagyobb biztonsági konferenciának van hacker versenye, ezeket többnyire CTF-nek (Capture The Flag) hívják, ami a hagyományos zászlófogásos harci játék megfelelője akar lenni. Itt azonban a flag többnyire egy titkos információ, ezt kell megszerezni egy szolgáltatás megtörésével, egy kriptográfiai feladat megoldásával, vagy bármi más hasonlóval. Hacker feladattal. A feladatokat más hackerek készítik, a szervezők. Nem éles rendszereket kell feltörni, hanem valóshoz hasonló megoldásokat. Például egy banki rendszerhez hasonló megoldást, melynek a biztonsági problémája hasonló egy valódi bankban potenciálisan elkövetett hibával. Vagy feladat lehet egy hangfájl analízise, amely fájlban valaki elrejtett egy titkos információt.

A hackercsapatok versenye tehát arról szól, hogy ki érti jobban a hacker technikákat, ki gyorsabb, okosabb, ügyesebb. Nem ezért, hogy majd jól feltörje a szomszéd hálózatát, hanem azért, mert ezzel a tudással jót tud tenni. Megvédeni a céget, az országot, megtalálni a hibát a hálózatban, a programban, kezelni a beeső támadásokat vagy éppen feltárni egy korábban elkövetett támadás menetét a nyomokból. Tehát megvédeni a világot.

Sokféle verseny – sokféle feladvány. Nem egy konferencia van, nem egy CTF verseny, hanem tucatszámra bonyolított versenyek. Senki nem tud indulni mindegyiken. A legjobb értékmérő talán a CTFTime.org. Ők összegzik az összes hackerverseny eredményét, súlyozzák azokat és végül kibökik, abban az évben melyik csapat hogyan teljesít. Most éppen a !SpamAndHex 18. éves szinten, de voltunk már 5. helyezettek is. Ötödiknek rangsorolt csapat a Földön! Szerintünk ez nagyon durva. A 18. helyezés is olyan, hogy nagyon durván jó. És nyilván függ a helyezés a tudáson túl attól is, hogy mennyi idő marad a csapatnak egy évben több tucat versenyen részt venni. (A felkészülésre is kellene idő persze…). Egy ötödik hely olyan, hogy csak négy országot tudsz elénk képzelni, pedig nem egy informatikában fejlett ország van a világban. Találgass, ki végzett előttünk!

Szóval van egy hacker csapatunk. A Föld (világot nem írok, hátha vannak kint is) legelismertebb hacker versenye a DefCon konferencia CTFdöntője Las Vegas városában. Ez a konferencia már évekkel ezelőtt is kb. 20 000 fős volt, olyan tömegrendezvény, amit nehéz elképzelni. 1000 fő fölötti előadótermeknél nem lehet bejutni, mert telt ház van az aktuális előadásra. Olyan konferencia, ahol a sima buheráció, a hackelés, vagy éppen a cosplay is összejön. Állsz a folyosón és szembejön egy terminátornak beöltözött ember, és ezen a legkisebb mértékben lepődsz meg. Viszont az árnyoldalakról is érdemes megemlékezni: alig jutsz be előadásokra, mert későn érsz oda, az ebédre meg beállsz egy olyan gyorsétterem sorába, ahol 1 óra várakozással bírsz venni egy hamburgert. A magyar árak duplájáért.

Küldtünk hírt korábban: A !SpamAndHex bejutott a DefCon döntöjébe, ahova 15 csapat kerülhet a Földről. Nem először jutott ide be a csapat, hanem sorban a harmadik alkalommal. Ez nyilvánvalóan nem véletlen. Köszönjük a Forbes hasonlatát, egyben gratulálunk Hosszú Katinkának a friss eredményeihez, boldogság, ha sikereinket hozzá hasonlítják. Szóval most indul a döntő. Fontos látni: nem az a kérdés, hogy megnyerjük-e vagy 15. helyezést fogunk elérni. Az a lényeg, hogy ott vagyunk, harmadszorra. Az a lényeg, hogy a kimenő csapatainkat ismerik, elismerik, beszélnek velük. Az, hogy már sok helyen tudják, milyen a magyarok hacker csapata. Ebben az évben a hacker csapat már kb. 5 olyan külföldi versenyen is részt vett, ahol helyileg is meg kellett jelenni, nem csak távolról versenyezni, és ezek többségében a szervező fizette az útiköltségeket is. Körbebarangolni a világot Oroszországban, Kínába, Lengyelországan, vagy éppen most (szponzori támogatásból) Amerikában, azért az álma lehet sok diáknak. Várjuk, hogy ők is a csapatunk tagjai legyenek egyszer.

Szponzoraink:

microseccrysysbalabitmrg-effitasesetukatemivikeuro-onetresoritpadi

Posted on Leave a comment

A személyes adat és a GDPR

Ebben a posztban először áttekintjük a személyes adat fogalmát példákkal illusztrálva, ahogyan azt a 2018. május 25-én érvénybe lépő új európai adatvédelmi rendelet (GDPR) definiálja. A GDPR kötelezettségei bárkire vonatkoznak, aki európai uniós polgár személyes adatát tárolja vagy dolgozza fel (függetlenül ezek helyétől), és a kötelezettségek mulasztása jelentős anyagi és jogi következményekkel járhat. Viszont az adat személyes jellegének megítélése korántsem könnyű, amit különböző példákkal is szemléltetünk. Megmutatjuk, hogy egy Budapest nagyságú városban a tömegközlekedést használó emberek által meglátogatott állomások listája egyedi, és kevesebb mint 5 állomás ismerete elég ahhoz, hogy egy ilyen adatbázisban bárki azonosítson egy utast. Más szavakkal kizárólag az állomások listája utasonként (név, cím, stb. nélkül) jó eséllyel személyes adatnak minősül. A probléma aktualitását a közeljövőben Budapesten is bevezetésre kerülő elektronikus jegyrendszer adja, ami lehetővé teszi az utasok által meglátogatott állomások rögzítését.

Mi a személyes adat?

Az általános európai adatvédelmi rendelet (General Data Protection Regulation (GDPR)) értelmében személyes adatnak minősül minden olyan információ, ami egy azonosított vagy azonosítható természetes személyre vonatkozik (Cikk 4(1)). Például ha egy kórházi adatbázisban szerepel a betegek neve, lakóhelyük irányítószáma, valamint a betegség diagnózisa (1. táblázat), akkor ez személyes adat ha „valaki” (egy támadó, aki az adatbázishoz hozzáfér) képes meghatározni, hogy egy rekord (sor) melyik személyhez tartozik. Első pillantásra az 1. táblázat személyes adatnak tűnik a megjelenő nevek mint azonosítók miatt. A valódi válasz egy kicsit árnyaltabb, mivel előfordulhat, hogy minden névhez több olyan természetes személy tartozik a populációban (pl. Magyarország), akik ugyanabban a kerületben laknak és az adatbázisban nem szerepelnek.

Rekord Név Irányítószám Betegség
1. Fehér Csaba 1123 Appendicitis
2. Kovács Kálmán 1117 Meningitis
3. Nagy Tibor 1113 Gastroenteritis
4. Kovács Ferenc 1114 Alzheimer
.. ... ... ...

1. táblázat: Kórházi adatok

Tegyük fel, hogy Terike néni szomszédja Kovács Ferenc, aki Budapesten lakik. Terike néni nagy valószínűséggel nem fogja tudni megmondani, hogy a 4. rekord a szomszédjához tartozik, mivel több Kovács Ferenc is élhet a XI. kerületben azonos adatokkal, és nem tudja, milyen betegségben szenved a szomszédja. Ha viszont Terike néni és szomszédja egy 100 fős községben lakik vidéken, ahol csak egyetlen Kovács Ferenc lakik (2. táblázat), akkor Terike néni teljes bizonyossággal kikövetkeztetheti, hogy a 4. rekord a szomszédjához tartozik. A név és irányítószám külön-külön „kvázi” azonosítója a vidéki K. Ferencnek, de együtt már egyedi azonosítók Terike néni számára. A budapesti K. Ferencnek (1. táblázat) viszont együttesen is csak kvázi azonosítója a két attribútum.

Rekord Név Irányítószám Betegség
1. Tóth Csaba 1123 Appendicitis
2. Nagy Kálmán 1117 Meningitis
3. Nagy Tibor 1113 Gastroenteritis
4. Kovács Ferenc 8423 Alzheimer
.. ... ... ...

2. táblázat: Kórházi adatok vidéki betegekkel

Vagyis a 2. táblázat tartalmazhat személyes adatot (Kovács Ferenc, aki egy kis községben lakik), még akkor is, ha a többi rekord nem minősül személyes adatnak Terike néni számára (pl. mert a többi beteg Budapesti, és rekordjaikhoz több természetes személy illeszkedik).

Most tegyük fel, hogy Zsuzsa néni nővér, aki nem ismeri K. Ferencet, és hozzáfér a 1. táblázathoz. Mivel Zsuzsa néni férje NAV ellenőr, ezért hozzáfér minden budapesti demográfiai adatához is (3. táblázat), és látja, hogy Budapesten a XI. kerületben három K. Ferenc él, akik rendre 26, 35, es 65 évesek. Tehát az 1. táblázat 4. rekordja a 3. táblázat 3. rekordjához tartozik, mivel az Alzheimer ritka 26 és 35 éves korban. Vagyis Zsuzsa néni jó eséllyel újra azonosította a kórházi adatbázis 4. rekordját, és így az személyes adat Zsuzsa néni számára (ahol az egyedi azonosítók a név, irányítószám és betegség együtt).

Rekord Név Adóazonosító jel Irányítószám Születési idő
1. Nagy Olivér 2346758913 8417 1965-12-12
2. Kovács Ferenc 6730861841 1114 1991-03-01
3. Kovács Ferenc 9770861942 1114 1952-05-08
4. Kovács Ferenc 4730361143 1114 1982-11-28
5. Nagy Rajmund 8462051823 1434 1954-11-30
6. Papp Lajos 7351233971 5423 1988-05-24
... ... ... ... ...

3. táblázat: Demográfiai adatok

Utolsó példaként vegyünk egy átalakított kórházi adatbázist (4. táblázat), ami abban különbözik az elsőtől, hogy minden beteghez tárolják a születési dátumot is, viszont a nevük helyett csak a nemüket (férfi/nő) rögzítik.

Rekord Nem Irányítószám Születési dátum Betegség
1. Férfi 1123 1943-01-02 Appendicitis
2. Férfi 1117 1976-08-12 Meningitis
3. Férfi 1113 1981-01-31 Gastroenteritis
4. Férfi 1114 1971-03-01 Bronchitis
... ... ... ... ...

4. táblázat: Kórházi adatok átalaktíva

Első ránézésre egy ilyen adatbázis már nem tartalmaz személyes adatot, hiszen a nevet (mint attribútumot) eltávolítottuk. Paradox módon, egy ilyen adatbázis is tartalmazhat személyes adatot, mivel a születési dátum, nem, és írányítószám együttese azonosíthat valakit (ugyan sok ezer ember született azonos napon mint K. Ferenc vagy lakik azonos irányítószám alatt, azon emberek száma akik azonos napon születtek és az irányítószámuk is azonos K. Ferenc irányítószámával már jóval kevesebb). Több tanulmányban is megmutatták, hogy egy több milliós populációban az egyének közel 63%-ának egyedi a nem- irányítószám-születési dátum együttese, vagyis jó eséllyel nincs még egy olyan ember Magyarországon, aki azonos nemű, akkor született, és ott lakik mint az Olvasó.

Tegyük fel, hogy Gizi néni (vagy férje) egy állami szervnél dolgozik, ahol hozzáfér az állampolgárok pontos születési idejéhez és lakhelyéhez (3. táblázat). A fentiek miatt egy olyan kórházi adatbázisban mint a 4. táblázat akár a betegek 63%-ához hozzárendelheti a pontos identitásukat, hiszen minden kórházi rekordhoz hozzá tudja rendelni a neki megfelelő állampolgári adatokat ha az irányítószám, születési dátum és nem (mint attribútumok) implicit vagy explicit módon megjelennek mindkét adatbázisban. Ebben az esetben a név, irányítószám és nem együttese egyedi azonosítója az emberek 63%-ának Gizi néni számára.

Plauzibilitás és sikervalószínűségek

Jogosan felmerülhet a kérdés: ha Zsuzsa néni jó eséllyel újra tudja azonosítani az 1. táblázat 4. rekordját, de Terike néni nem, akkor az személyes adat-e a GDPR szerint? Hasonlóan ha Gizi néni minden embert 63%-os valószínűséggel azonosít, de egyiket sem teljes bizonyossággal, akkor a 4. táblázat bármely rekordja személyes adatnak minősül vagy sem? Hasonló bizonytalanság fellép Zsuzsa néni esetében, hiszen ritkán, de fiatal felnőttek is szenvedhetnek Alzheimer kórban. Terike néni hihetőbb támadónak tűnik mint a többiek, hiszen neki „csak” a kórházi adatokhoz kell hozzáférnie és nincs szüksége a 3. táblázatra, hogy a szomszédja adatát lokalizálja az 1. táblázatban. Ugyanakkor Zsuzsa és Gizi néni K. Ferencen kívül számos más személyt is újra azonosíthatnak, hiszen hozzáférnek a demográfiai adatokhoz. A GDPR nem definiál explicit felső korlátot arra, hogy mennyire kell egy támadónak plauzibilisnek lennie, és arra sem, hogy ilyen támadásoknak milyen minimális sikervalószínűségűeknek kell lenniük ahhoz, hogy egy (vagy több) rekord azonosítható legyen (azaz személyesnek minősüljön). Viszont megköveteli, hogy a sikervalószínűségek ésszerűen alacsony értékek legyenek az adatbázisban szereplő minden személyre a lehető legtöbb plauzibilis támadót figyelembe véve (Recital 26).

A plauzibilitás és sikervalószínűségek becslésénél figyelembe kell venni, hogy a potenciális támadók nem feltétlenül ismerik a (kvázi) azonosítók összes elemét (pl. csak az irányítószámot, de a születési dátumot nem), valamint ezek megtanulása túl költséges lehet számukra. Például ha a való életben létezik egy Terike néni (vagyis plauzibilis, hogy ismeri a szomszédja néhány adatát és hozzáfér a 2. táblázathoz), akkor K. Ferenc rekordja a 2. táblázatban személyes adatnak minősülhet. Ha Zsuzsa és Gizi néni létezése hihető (vagyis plauzibilis, hogy hozzáférnek a 3. és 4. táblázathoz és ez számukra nem okoz túl nagy költséget), akkor K. Ferenc rekordja az 1. és 4. táblázatban is személyes adatnak minősülhet.

Egy adat személyes jellege tehát attól függ, hogy milyen potenciális támadók férhetnek hozzá az adathoz és azok képesek-e meghatározni legalább egy rekord tulajdonosát mint természetes személyt. Ennek megítéléséhez szükséges minden plauzibilis támadás feltérképezése és azok sikervalószínűségeinek becslése.

Megjegyzések:

  • A fenti adatok nem azért minősülnek személyesnek, mert érzékeny információt tartalmaznak (pl. betegség), hanem azért, mert egy plauzibilis támadó képes megmondani, hogy melyik rekord melyik természetes személyhez tartozik, függetlenül az adat jellegétől. Más szavakkal, ha a fenti táblázatok nem tartalmaznák a betegséget mint attribútumot, attól még személyes adatnak minősülhetnek és vonatkozhatnak rá a GDPR kötelezettségei.
  • Általánosan igaz, hogy a belső alkalmazottak (a fenti esetben nővérek) gyakran a legvalószínűbb támadók, hiszen részükről kevés technikai felkészültséget igényel az adatlopás (eleve hozzáférésük van az adatbázisokhoz) függetlenül attól, hogy milyen biztonsági megoldásokkal (tűzfal, jelszó, antivírus szoftver, hálózati szegregálás, stb.) védik a kórházi és állami rendszereket külső „hacker” támadásoktól (miközben ezen védelmek sem nyújtanak garanciát külső támadásokkal szemben).
  • A gyakorlatban szükséges lehet az egyes támadások kockázatának elemzése, amit a GDPR is megkövetel az Adatvédelmi hatásvizsgálat (Data Protection Impact Assessment) részeként. Egy ilyen elemzés a plauzibilitás és sikervalószínűségek becslésén túl szükségessé teheti a támadásban érintett személyek/rekordok számának (scale) valamint a személyeknek okozott potenciális materiális/erkölcsi/fizikai károk (impact) becslését is. Például Gizi és Zsuzsa néni kevésbé plauzibilisek mint Terike néni, de lényegesen több személyt újra azonosíthatnak, és így az általuk okozott potenciális kár is lényegesen nagyobb lehet (például ha továbbadják az újra-azonosított adatokat).

Személyes adatok mérése

Hogyan állapíthatjuk meg, hogy egy adatbázis személyes adatokat tartalmaz és így a GDPR hatásköre alá esik? Néhány esetben ez könnyű, például amikor egy rekord valamely plauzibilis támadó által könnyen megismerhető egyedi azonosítót tartalmaz (pl. TAJ szám vagy bankszámlaszám). Akkor sem túl nehéz, ha létezik olyan publikusan elérhető másik adatbázis (3. táblázat), amely tartalmazza az azonosítók értékeit néhány rekordra; vagyis Zsuzsa és Gizi néni plauzibilis.

Általános esetben viszont meg kell becsülni minden plauzibilis támadó sikervalószínűségét, ami általában lehetetlen (ez persze nem ment fel a GDPR kötelezettsége alól, amely előír egy ilyen „best-effort" jellegű elemzést az adat felhasználásától függően). Honnan lehetne tudni, hogy a támadók akik hozzáférhetnek a kórházi adatokhoz (pl. alkalmazott, biztosító, bank, stb.) mit tudhatnak egy betegről, ami a beteg egyedi azonosítója lehet a populációban?

Vegyük Zsuzsa néni esetét K. Ferenccel, de most Zsuzsa néni csak a 3. és 5. táblázatokhoz fér hozzá. Zsuzsa néni látja a 3. táblázatban, hogy a XI. kerületben három K. Ferenc nevű ember él. Mivel Zsuzsa néni lelkes Facebook/Instagram felhasználó, ezért talál egy K. Ferenc nevű felhasználót, aki a megosztott képei alapján a XI. kerületben lakik, a 20-as éveiben jár, és krónikus bőrkiütésben szenved (a pontos betegségét ez alapján még nem ismeri). Így az 5. táblázat 4. rekordja valószínűleg a 3. táblázat 2. rekordjához tartozik, mivel az 5. táblázatban a másik két betegségnek nem tünete a bőrkiütés. Vagyis ebben az esetben az 5. táblázat 4. rekordja személyes adatnak minősülhet, amelynek egyedi azonosítója a neve, az irányítószáma, a születési éve, és a betegségének egy tünete (bőrkiütés).

Rekord Nem Irányítószám Születési dátum Betegség
1. Kovács Attila 1123 1943-*-02 Meningitis
2. Kovács Attila 1123 1943-*-02 Appendicitis
3. Kovács Ferenc 1114 19*-*-* Influenza
4. Kovács Ferenc 1114 19*-*-* Crohn-betegség
5. Kovács Ferenc 1114 19*-*-* Lábfejtörés
6. Nagy Tibor 1313 1981-*-* Meningitis

5. táblázat: Kórházi adatok

Látható, hogy nagyon nehéz feltételezéséket tenni egy támadó háttértudására és így meghatározni a plauzibilitását. Napjainkban egyre több adatot osztanak meg az emberek magukról és egymásról, akarva vagy akaratlan; így nem lehet tudni, hogy ki rendelkezik elég tudással ahhoz, hogy megtalálja az illető rekordját egy adatbázisban.

Adatok egyedisége az adatbázisban és a populációban

A fenti nehézségek ellenére a GDPR előírhatja az adatok azonosíthatóságának „best-effort" elemzését, aminek megítélése sajnos elég szubjektív, hiszen mindig kimaradhat egy Terike/Zsuzsa/Gizi néni a felsorolásból, akinek létezése csak később lesz nyilvánvaló. Vagyis az adat azonosíthatósága (és személyes jellege) idővel változhat. Ennek a rendelet tudatában van, és ezért ezekben az esetekben újabb analízist ír elő.

Az azonosíthatóság eldöntéséhez szükséges tudnunk, hogy egy rekord attribútum-értékei mennyire egyediek a populációban (és nem az adatbázisban), ahonnan a rekord számazik. Visszautalva az első példára, ha több Kovács Ferenc nevű ember él a XI. kerületben, akkor az 1. táblázat 4. rekordja nem személyes adat Terike néni (és valószínűleg senki más) számára. Annak eldöntése, hogy egy rekord egyedi-e az adott populációban viszont általában nehéz, hiszen ritkán ismerjük a populáció minden tagját. Ugyan léteznek statisztikai modellek és eszközök rekordok egyediségének becslésére egy populációban, ezen modellek többsége legjobb esetben is csak az átlagos, de nem a legrosszabb esetekre adnak valamilyen mérőszámot rekordok egyediségére.

A személyes adatok egy egyszerűbb és objektívebb indikátora a gyakorlatban a rekordok egyedisége az adatbázisban (és nem a populációban). Egy rekord egyedi, ha attribútumok egy részhalmazának értékei (amit egy plauzibilis támadó ismerhet, és így azonosíthatja a rekord tulajdonosát) egyediek rá nézve az adatbázisban, vagyis nincs más rekord aminek ilyen attribútum-értékei lennének. A fenti példában, ha K. Ferenc egyedi a nemét, irányítószámát, és születési dátumát nézve a 2. táblázatban, akkor Terike néni könnyen lokalizálhatja vidéki szomszédjának rekordját. Ha viszont k rekord rendelkezik ilyen attribútum értékekkel, akkor Terike néni nem tudja meghatározni, hogy melyik rekord tartozik a szomszédjához, feltéve, hogy nincs más információja szomszédja betegségének tüneteiről (pontosabban ha tippel, akkor az esélye, hogy eltalálja a szomszédja rekordját 1/k). Ezt illusztrálja az 6. táblázat, ahol k = 2.

Rekord Nem Irányítószám Születési dátum Betegség
1. Férfi 1123 1943-*-02 Meningitis
2. Férfi 1123 1943-*-02 Appendicitis
3. Férfi 8423 1971-01-* Bronchitis
4. Férfi 8423 1971-01-* Appendicitis
5. 1313 1981-*-* Appendicitis
6. 1313 1981-*-* Meningitis

6. táblázat: Kórházi adatok, k = 2

Természetesen, ha egy rekord egyedi az adatbázisban, az nem jelenti azt, hogy egyedi a populációban is (ld. a budapesti Kovács Ferenc esetét az 1. táblázatban). Azaz, egyedi rekordok az adatbázisban nem feltétlen minősülnek személyes adatnak, de nem túl biztató ilyen rekordok jelenléte; főleg, ha a populáción belüli egyediségét nem lehet cáfolni vagy az adatbázis tartalmazza a populáció nagy részét (ami nem ritka manapság). Ezért a gyakorlatban legtöbbször csak az adatbázison belüli egyediséget használják az adat személyességének mérésére; ha egy adatbázisban vannak olyan rekordok, amelyek egyediek valamely plauzibilis támadó számára (Terike néni aki ismeri a lakhelyet, nevet és születési dátumot), akkor jó eséllyel tartalmaz személyes adatot az adatbázis.

Komplex, sok attribútumú személyes adatok

Napjaink legtöbb adathalmaza lényegesen több attribútumot tartalmaz mint a fenti kórházi adatbázis. Például tartalmazhatja egy személy által meglátogatott helyeket, megvásárolt termékeket, megnézett filmeket, stb. Az összes attribútum száma ilyenkor megegyezik az összes lehetséges hellyel, megvásárolható termékkel, vagy létező filmmel, melyek száma akár több ezer is lehet, értékük pedig 1 ha a kérdéses személy meglátogatta/megvásárolta/megtekintette az adott helyet/árut/filmet, máskülönben 0. Egy ilyen adatbázist illusztrál a 7. táblázat, ahol az attribútumok Budapest főbb helyeinek (POI) felel meg.

Rekord Móricz Zsigmond körtér Allee Mom Park ... Széll Kálmán tér
1. 0 1 1 ... 0
2. 1 1 1 ... 0
3. 0 0 0 ... 1
4. 0 0 1 ... 1
... ... ... ... ... ...

7. táblázat: Komplex adatbázis

Az ilyen adathalmazok szinte mindig személyes adatnak minősülnek, mivel (1) a rekordok általában egyediek az attribútumok nagy száma miatt (2) a sok attribútum közül elég csak néhanyat ismerni ahhoz, hogy a illető rekordját lokalizálni tudjuk, (3) az ilyen nagy adathalmazok gyakran a populáció nagy részét lefedik. Például tegyük fel, hogy bárki megismerhet K darab, egy bizonyos személy által meglátogatott helyet az illető Facebook/Instagram profilját elemezve. Tegyük fel továbbá, hogy egy távközlési szolgáltató szeretné megosztani egy másik céggel a minden egyes előfizetője által meglátogatott helyek (cella tornyok) listáját úgy, hogy más attribútumot (név, telefonszám, stb.) nem oszt meg az előfizetőkről. Személyes adat-e az előfizetőnkénti meglátogatott helyek listája? Nagy valószínűséggel igen, hiszen kevesebb mint 5-10 torony (POI) ismerete egyedivé tesz egy rekordot. Ezt a jelenséget a következőkben illusztráljuk egy hasonló példán.

Esettanulmány: Tömegközlekedési adatok

Példaként nézzünk egy komplexebb adathalmazt, ami egy 1.5 millió lakosú város közlekedési (metró- és busz-) hálózatának használatát tartalmazza. Adott két adatbázis, amelynek minden egyes sora megfelel egy elektronikus jegynek/bérletnek (smart kártya), és tartalmazza azon állomások listáját, ahol a jegyet/bérletet érvényesítették/leolvasták (az elektronikus jegyek többnyire időalapúak, egyetlen jegy az érvényességi idején belül több állomáson is leolvasásra kerülhet). A továbbiakban tegyük fel, hogy egy utas csakis egy jegyet/bérletet használt a megfigyelt időtartamban (1 hét), vagyis minden sor megfelel egy utas által meglátogatott állomások egy részhalmazának (tehát egy állomás csak egyszer szerepelhet egy rekordban).

A metró adatbázisban összesen 66 állomás (attribútum) és 846 648 utas (rekord) található. A busz adatbázisban 861 állomás (attribútum) és 771 195 utas (rekord). Az adatbázisok főbb jellemzőit a 8. táblázat mutatja.

Metró Busz
Utasok száma 846,648 771,195
Állomások száma 66 861
Legtöbb állomás utasonként 27 54
Átlagos állomások száma utasonként 1.93 2.64
Állomások számának szórása utasonként 1.67 2.51

8. táblázat: Metró- és buszállomások látogatottsága

Két főbb támadást képzelhetünk el:

  1. A támadó ismeri egy tetszőleges utas K tetszőleges állomását, és lokalizálni szeretné az utas rekordját.
  2. A támadó ismeri egy tetszőleges utas K legtöbbször látogatott állomását (vagyis az utas TOP K állomását), és lokalizálni szeretné az utas rekordját.

A cél mindkét esetben az utas többi állomásának kiolvasása a megtalált rekordból . Mindkét támadás plauzibilis ha K nem túl nagy, hiszen szinte bármely utas nyilvános közösségi profiljából (Facebook/Instagram/Twitter stb.) könnyen meghatározhatók az általuk meglátogatott helyek, és így az azokhoz legközelebb elhelyezkedő állomások listája (pl. lakóhely, munkahely, konditerem, szórakozóhely). A sikervalószínűség mindkét esetben K értékétől függ, amit az alábbiakban a rekordok adatbázisbeli egyediségével becslünk.

TOP K állomások egyedisége

Először minden utas TOP K állomását meghatározzuk, majd megnézzük, hogy hány utasnak egyedi a TOP K állomása az adatbázisban. Az alábbi táblázat mutatja, hogy az adatbázis rekordjainak hány százaléka egyedi a TOP K állomásukat tekintve azon rekordok közül, amelyek tartalmaznak legalább K állomást. Zárójelben feltüntettük, hogy egy ilyen támadó számára hány rekord egyedi az adatbázisban.

Top-K Metró Busz
Top-2 0.03% (84 egyedi rekord) 5.56% (25 673 egyedi rekord)
Top-3 21.4% (43 315 egyedi rekord) 41.4% (119 783 egyedi rekord)
Top-4 82.1% (120 368 egyedi rekord) 79.4% (192 163 egyedi rekord)
Top-5 97.4% (129 608 egyedi rekord) 96.3% (216 135 egyedi rekord)

Például ha egy utas rekordja legalább 3 metróállomást tartalmaz, akkor ez a rekord 21.4%-os eséllyel egyedi az adatbázisban. Ugyanez az érték már 41.4% a busz-adatbázisban. Ha az összes rekordot nézzük és a támadó legfeljebb a TOP 3 állomást képes azonosítani minden rekordból, akkor számára 43 315 rekord lesz egyedi a metró-adatbázisban, ami az összes rekord kb. 5%-a. A gyakorlatban a TOP-3 állomás könnyen meghatározható egy személyről, de sokan jóval több információt megosztanak magukról közösségi portálokon (pl. képek formájában), ezért náluk akár K > 5 támadó is lehet plauzibilis több mint 95%-os sikervalószínűséggel, feltéve ha az adatbázis elég nagy és nagyjából lefedi az egész populációt.

Tetszőleges K állomás egyedisége

Milyen valószínűséggel lesz egy utas rekordja egyedi az adatbázisban egy olyan támadó számára, aki ismerheti az utas bármely K állomását (feltéve, hogy a rekord legalább K állomást tartalmaz)?

A fenti valószínűség számításához szükséges a rekordokban előforduló összes K állomás egyediségének vizsgálatára (vagyis hány más rekordban fordulnak elő), ami túl sokáig tartana. Ezért inkább véletlen mintavételezéssel becsüljük K állomás egyediségét. A részleteket mellőzve, erre itt egy egyszerű módszert mutatunk.

Első lépésként véletlenszerűen kiválasztunk egy rekordot (minden olyan rekordot ugyanolyan eséllyel, ami legalább K állomást tartalmaz), majd annak K tetszőleges állomását szintén véletlenszerűen (minden K állomást a rekordból ugyanolyan eséllyel). Végül megnézzük, hogy hány másik utas rekordja tartalmazza ezt a K állomást. A kísérlet sikeres, ha nincs más utas akinek rekordjában szerepel ez a K állomás (vagyis az első lépésben kiválasztott rekord egyedi a második lépésben kiválasztott állomásait tekintve). Ezt a kísérletet megismételjük elég sokszor (pl. 30000 ismétlés már elég pontos becslést ad), és kiszámoljuk a sikeres kísérletek százalékos arányát, amelyet az alábbi táblázat mutat. Zárójelben feltüntettük, hogy ez hány rekordot érint, vagyis hány rekord tartalmaz legalább K állomást.

K Metró Busz
2 12.7% (327 873 rekordra) 23.8% (425 602 rekordra)
3 20.2% (205 111 rekordra) 35.7% (273 759 rekordra)
4 32.4% (125 995 rekordra) 48.6% (198 875 rekordra)
5 52.7% (74 402 rekordra) 52.7% (142 150 rekordra)
6 74.1% (42 014 rekordra) 62.2% (100 779 rekordra)
7 87.7% (22 787 rekordra) 83.8% (70 370 rekordra)

Például ha egy utas rekordja legalább 3 metróállomást tartalmaz (ez 205 111 rekordra igaz, ami az összes rekord 24.2%-a), akkor ez a rekord 20.2%-os eséllyel lesz egyedi a metró adatbázisban.

Látható, hogy a busz adatbázis jóval több egyedi rekordot (és így potenciálisan több személyes adatot) tartalmaz mint a metró adatbázis. Ennek egyik fő oka, hogy több buszállomás létezik (861) mint metróállomás (66), és nyilván egy utas nagyobb eséllyel lesz egyedi ha több különböző állomást látogathat meg. Ahogy ezt a következőkben is megerősítjük, az utasok egymástól valóban elég eltérő metró- és buszállomásokat látogatnak meg.

Egyediség egyéb indikátorai

Az egyediség egy másik és gyorsabban számolható (de kevésbé pontos) indikátora lehet a sok egyedi rekordot tartalmazó adatbázisok két globális tulajdonsága: az adatritkaság (sparseness) és az állomások gyakoriságának heavy tailed eloszlása.

Egy adathalmaz ritka, ha minden utas csak néhány állomást látogatott meg. Ez a mi esetünkben valóban igaz, hiszen az átlagos állomás-szám rekordonként kevesebb mint 3 mindkét adathalmazra, aminek a szórása szintén kisebb mint 3 (8. táblázat).

A heavy-tailed tulajdonság nagyjából azt jelenti, hogy a legtöbb állomás gyakorisága alacsony az adathalmazban. Precízebben fogalmazva, ha ábrázoljuk az állomások elfordulási számának (gyakoriságának) eloszlását az adatbázisban, akkor ezen eloszlás sűrűségfüggvényének a farka „vastagabb", mint egy exponenciális eloszlás sűrűségfüggvényének farka. Ilyen ismertebb eloszlások pl. a power law és a log-normál. A következő ábrák illusztrálják a metró és busz adathalmazok heavy-tailed tulajdonságát. Ábrázoltuk az állomások gyakoriságának a komplemens kumulatív eloszlásfüggvényét (CCDF), valamint az erre legjobban illeszkedő exponenciális és heavy-tailed modellt. Az ábrák jól mutatják, hogy az exponenciális modell lényegesen rosszabbul illeszkedik mint a legjobb heavy-tailed modellek, amelyek a mi esetünkben a pozitív log-normál és Weibull eloszlások voltak. Azaz, a rekordok többsége nagy valószínűséggel egyedi! Az illeszkedést a powerlaw python csomaggal számoltuk. Érdemes megjegyezni, hogy a vizsgált heavy-tailed eloszlásoknak több paraméterük van mint az exponenciális eloszlásnak, ezért overfitting miatt a heavy-tailed eloszlások lehet, hogy csak az adatbázist modellezik pontosabban de nem a populációt (habár ennek esélye kicsi, mivel az adatbázisok jelen esetben elég nagyok).

Metró Busz
alt text alt text

Konklúzió

Láthattuk, hogy az adatok azonosíthatóságának és így személyes jellegének megítélése attól függ, hogy ki férhet hozzá az adathoz, és milyen előzetes (háttér)tudással rendelkezik az adattulajdonosokról. Másrészt, a támadó plauzibilitását (az egyénekről alkotott háttértudását) nehéz igazolni. Ennek oka, hogy napjainkban rengeteg adat érhető el az emberekről, amit részben ők maguk részben más cégek vagy személyek osztanak meg akarva vagy akaratlanul. Az azonosíthatóság sikervalószínűségét sem mindig könnyű számolni, főleg ha az adat komplex (sok attribútumot tartalmaz).

Példaként megmutattuk, hogy egy Budapest nagyságú városban a tömegközelekedést használó emberek által meglátogatott állomások listája egyedi, és kevesebb mint 5 állomás ismerete elég ahhoz, hogy egy ilyen adatbázisban bárki azonosítson egy utast, és kiolvassa az összes általa érintett állomást. Így ez az adatbázis nagy valószínűséggel rengeteg személyes adatot tartalmaz. Ez azt is jelenti, hogy ha a rendszert üzemeltető cég meg szeretné osztani ezt az adatbázist egy harmadik féllel adatelemzés céljából (pl. hogy lássák hova kell új állomást építeni), ahhoz vagy az utasok beleegyezését kell kérniük, vagy anonimizálni kell az adatbázist úgy, hogy már nem azonosítható benne senki és így nem vonatkoznak rá a GDPR kötelezettségei. Ez a kérdés könnyen aktuálissá válhat Budapesten is a közelgő elektronikus jegyrendszer bevezetésével.

Posted on Leave a comment

A pizzás ügy margójára

Kedves Diákok!

Talán hozzátok is elért a veszprémi pizzéria weboldalát tároló szerver feltöréséről, az arról ellopott adatokról való hír. Erről több olvasható például itt a népszaván.

Nagyon fontos elmondanunk, hogy a támadó -még ha a jó szándék vezérelte is- borzasztóan etikátlanul, törvénytelenül és veszélyesen járt el, és nagyon szeretnénk, ha az adatbiztonsággal foglalkozó hallgatóink soha nem követnének el hasonló hibákat.

Internetes weboldalak biztonsági tesztelésére csakis felkérés alapján, megfelelő megállapodás szerint kerülhet sor- Egy ilyen megállapodás rögzítheti az alkalmazható eszközöket, az ellenőrizhető célpontok körét, az ellenőrzés időbeli korlátozását, és számos más dolgot. Ilyen megállapodás hiányában már a feltörési kísérletek is jogszabályokba ütköznek, de egy sikeres feltörés alapesetben is 3 évig terjedő szabadságvesztéssel járhat!

Az elkövető ráadásul adatokat lopott, ráadásul ezeket közre is adta. Újabb két dolog, ami miatt súlyosan megütheti a bokáját, és akkor még nem beszéltünk a webszolgáltatónak és a cégeknek okozott kárról!

Fontos megjegyezni: Ha igaz a hacker állítása, hogy a szerver katasztrofális biztonsági állapotban van, az szintén elfogadhatatlan, és veszélyezteti emberek személyes adatait, amivel a cég az új adatvédelmi rendelkezések bevezetésével komoly büntetést is kaphatna, és egyetértünk abban is, hogy az ilyen cégeket jó lenne kényszeríteni arra, hogy biztonságukat megfelelően valósítsák meg.

Ugyanakkor nem lehet önbíráskodó módon, törvénytelenül, kérés nélkül ilyen cselekedeteket elkövetni. Még akkor sem, ha valaki nem lop el adatot, és nem publikálja azokat.

Ha a diákjaink valamikor adatbiztonsági sérülékenység jeleit, nyomait látják, vagy esetleg bizonyítékot is szereznek erről (remélhetően véletlenül), úgy a helyes eljárás a szolgáltató, kiszolgáló tulajdonos stb. haladéktalan és teljes körű tájékoztatása. Ha ez nem tehető meg közvetlenül, akkor javasolt a megfelelő, kapcsolódó CERT, kormányzat esetén pl. a GovCERT, a Kormányzati Eseménykezelő Központ tájékoztatása, akik segíteni tudnak a komnmuniákcióban, és a problémák megfelelő kezelésében, jogszerűen, úgy, hogy az mindannyiunk javára váljon.
Kérjük a diákokat, hogy ne próbálják meg utánozni a támadót, nem éri meg a 2 perc hírnév!

Posted on Leave a comment

Update on the Fancy Bear Android malware (poprd30.apk)

About the APK:

The APK file, that was investigated by Crowd Strike and us is actually corrupt, unzipping yields two warnings and a CRC Error.

$ unzip 6f7523d3019fa190499f327211e01fcb.apk
Archive: 6f7523d3019fa190499f327211e01fcb.apk
warning [6f7523d3019fa190499f327211e01fcb.apk]: 1 extra byte at beginning or within zipfile
(attempting to process anyway)
file #1: bad zipfile offset (local header sig): 1
(attempting to re-compensate)
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
inflating: AndroidManifest.xml
inflating: classes.dex
extracting: res/drawable-hdpi/dmk.png
extracting: res/drawable-hdpi/ic_launcher.png
extracting: res/drawable-mdpi/fon_1.jpg
extracting: res/drawable-mdpi/fon_2.png
extracting: res/drawable-mdpi/fon_3.png
extracting: res/drawable-mdpi/ic_action_search.png
extracting: res/drawable-mdpi/ic_launcher.png
extracting: res/drawable-mdpi/panel_2.gif
extracting: res/drawable-mdpi/panel_4.png
extracting: res/drawable-mdpi/panel_5.png
extracting: res/drawable-mdpi/panel_6.png
extracting: res/drawable-mdpi/panel_7.png
extracting: res/drawable-mdpi/warnings.png bad CRC 73cded37 (should be 902e9cdb)
file #19: bad zipfile offset (local header sig): 660433
(attempting to re-compensate)
extracting: res/drawable-xhdpi/ic_launcher.png
extracting: res/drawable-xxhdpi/ic_launcher.png
inflating: res/layout/activity_reg_form.xml
inflating: res/layout/byleten.xml
inflating: res/layout/dan_dmk.xml
inflating: res/layout/dan_meteo.xml
inflating: res/layout/dan_vr_2.xml
inflating: res/layout/meteo_podg_form.xml
inflating: res/layout/o_avtope_form.xml
inflating: res/layout/pomow_form.xml
inflating: res/layout/promt.xml
extracting: resources.arsc

In this form, it is not possible to install the APK, trying so results in the phone yielding the following error message:
$ adb install 6f7523d3019fa190499f327211e01fcb.apk
Failed to install 6f7523d3019fa190499f327211e01fcb.apk: Failure [INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION: Failed to parse /data/app/vmdl135131206.tmp/base.apk: AndroidManifest.xml]

From the error messages we suspected, that an extra byte somehow ended up in the APK file.
The repair process consisted of finding and removing an extra byte from the file “warnings.png”. By changing only this byte and getting a valid APK file, this might be the original file. After repair, we got the following file.
$ sha256sum REPAIRED.apk
5b6ea28333399a73475027328812fb42259c12bb24b6650e5def94f4104f385e REPAIRED.apk

$ unzip -vt REPAIRED.apk
Archive: REPAIRED.apk
testing: META-INF/MANIFEST.MF OK
testing: META-INF/CERT.SF OK
testing: META-INF/CERT.RSA OK
testing: AndroidManifest.xml OK
testing: classes.dex OK
testing: res/drawable-hdpi/dmk.png OK
testing: res/drawable-hdpi/ic_launcher.png OK
testing: res/drawable-mdpi/fon_1.jpg OK
testing: res/drawable-mdpi/fon_2.png OK
testing: res/drawable-mdpi/fon_3.png OK
testing: res/drawable-mdpi/ic_action_search.png OK
testing: res/drawable-mdpi/ic_launcher.png OK
testing: res/drawable-mdpi/panel_2.gif OK
testing: res/drawable-mdpi/panel_4.png OK
testing: res/drawable-mdpi/panel_5.png OK
testing: res/drawable-mdpi/panel_6.png OK
testing: res/drawable-mdpi/panel_7.png OK
testing: res/drawable-mdpi/warnings.png OK
testing: res/drawable-xhdpi/ic_launcher.png OK
testing: res/drawable-xxhdpi/ic_launcher.png OK
testing: res/layout/activity_reg_form.xml OK
testing: res/layout/byleten.xml OK
testing: res/layout/dan_dmk.xml OK
testing: res/layout/dan_meteo.xml OK
testing: res/layout/dan_vr_2.xml OK
testing: res/layout/meteo_podg_form.xml OK
testing: res/layout/o_avtope_form.xml OK
testing: res/layout/pomow_form.xml OK
testing: res/layout/promt.xml OK
testing: resources.arsc OK
No errors detected in compressed data of REPAIRED.apk.

$ jarsigner -verbose -verify REPAIRED.apk

s 2215 Thu Feb 28 18:33:46 CET 2008 META-INF/MANIFEST.MF
2268 Thu Feb 28 18:33:46 CET 2008 META-INF/CERT.SF
1714 Thu Feb 28 18:33:46 CET 2008 META-INF/CERT.RSA
sm 6108 Thu Feb 28 18:33:46 CET 2008 AndroidManifest.xml
sm 543000 Thu Feb 28 18:33:46 CET 2008 classes.dex
sm 7047 Thu Feb 28 18:33:46 CET 2008 res/drawable-hdpi/dmk.png
sm 1703 Thu Feb 28 18:33:46 CET 2008 res/drawable-hdpi/ic_launcher.png
sm 68364 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/fon_1.jpg
sm 153893 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/fon_2.png
sm 182654 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/fon_3.png
sm 311 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/ic_action_search.png
sm 1853 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/ic_launcher.png
sm 2241 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_2.gif
sm 4420 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_4.png
sm 450 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_5.png
sm 1448 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_6.png
sm 551 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_7.png
sm 25089 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/warnings.png
sm 2545 Thu Feb 28 18:33:46 CET 2008 res/drawable-xhdpi/ic_launcher.png
sm 4845 Thu Feb 28 18:33:46 CET 2008 res/drawable-xxhdpi/ic_launcher.png
sm 4356 Thu Feb 28 18:33:46 CET 2008 res/layout/activity_reg_form.xml
sm 20332 Thu Feb 28 18:33:46 CET 2008 res/layout/byleten.xml
sm 10584 Thu Feb 28 18:33:46 CET 2008 res/layout/dan_dmk.xml
sm 20852 Thu Feb 28 18:33:46 CET 2008 res/layout/dan_meteo.xml
sm 10208 Thu Feb 28 18:33:46 CET 2008 res/layout/dan_vr_2.xml
sm 2772 Thu Feb 28 18:33:46 CET 2008 res/layout/meteo_podg_form.xml
sm 2076 Thu Feb 28 18:33:46 CET 2008 res/layout/o_avtope_form.xml
sm 2944 Thu Feb 28 18:33:46 CET 2008 res/layout/pomow_form.xml
sm 952 Thu Feb 28 18:33:46 CET 2008 res/layout/promt.xml
sm 13296 Thu Feb 28 18:33:46 CET 2008 resources.arsc

s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

  • Signed by “EMAILADDRESS=android@android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US”
    Digest algorithm: SHA1
    Signature algorithm: SHA1withRSA, 2048-bit key

jar verified.

Warning:
This jar contains entries whose certificate chain is not validated.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate’s expiration date (2035-07-17) or after any future revocation date.

Re-run with the -verbose and -certs options for more details.

 

About the RC4/encryption key:

By decompiling and manually “refactoring” the encryption algorithm, we discovered a “textbook” RC4 implementation as the encryption routine, which uses the hard-coded key as a first-part to the encryption key, with the second-part coming as a parameter from the function call:

Analyzing the XAgent linux sample, which also contained this RC4 key, we did not found an RC4 implementation, but a simple XOR based encryption routine:

We found one function call, which used the encryption key from the APK as input, but surprisingly, it was not used as key parameter, but input parameter.

For checking HTTP GET and POST messages a different XOR based check routine can be found, and a Base64-like encoding. After decoding, the XOR based routine checks the http result’s body. It xors the 4-11 bytes with the first 4 bytes as a key. It then should be equal to a hardcoded value (7 bytes) which the sample uses to check whether the recv succeeded or not.

These XAgent linux samples are very similar to a Windows version that has been found in november, 2013 (5f6b2a0d1d966fc4f1ed292b46240767f4acb06c13512b0061b434ae2a692fa1).

Recommended yara for the linux versions:
rule sofacy_xagent {
meta:
author = "AKG"
description = "Sofacy - XAgent"
strings:
$service = "ksysdefd"
$x1 = "AgentKernel"
$x2 = "Cryptor"
$x3 = "AgentModule"
$x4 = "ChannelController"
$x5 = "RemoteKeylogger"
$a1 = "UNCORRECT DISPLAY NAME"
$a2 = "Keylogger started"
$a3 = "Keylog thread exit"
$a4 = "Keylogger yet started"
condition:
$service or (2 of ($x)) or (2 of ($a))
}

Posted on Leave a comment

Technical details on the Fancy Bear Android malware (poprd30.apk)

Background

Recently, Crowdstrike has published details about a malicious Android APK file, named poprd30.apk or Попр-Д30.apk. It seems that the malware was created by the Fancy Bear group for tracking Ukrainian field artillery units (more info on this can be found here: https://www.crowdstrike.com/wp-content/brochures/FancyBearTracksUkrainianArtillery.pdf). The corresponding APK is identified by the MD5 hash 6f7523d3019fa190499f327211e01fcb on a related blog site https://www.crowdstrike.com/blog/danger-close-fancy-bear-tracking-ukrainian-field-artillery-units/. However, not much technical details have been given by CrowdStrike on the attack. During discussions on the topic, Jeffrey Carr initiated discussions with us and has sent some questions on if the case is real and how exactly the attack works, in particular, how the malware could have been used in military conflicts.

We carried out only a short investigation on the topic. Our goal was to uncover more technical details about the attack and to confirm the existence of the backdoor in the particular APK file.

Highlights

  • We can confirm that the APK file known by the MD5 hash 6f7523d3019fa190499f327211e01fcb contains a backdoor that tries to communicate with a remote server.
  • The server IP in the sample is http://69.90.132[.]215/
  • The malicious APK does not use GPS to get exact location of the infected phone, it does not even ask for GPS-level position information.
  • We note, however, that some location information can be collected by the malicious APK, mainly related to the actual base station used by the phone and the WiFi status.
  • The implant in the malicious APK has similarities to the X-Agent implants of the Fancy Bear / APT28 / Sofacy group described in former reports, but this is not necessarily  an evidence on the relationship as such similarities can be faked.
  • We uncovered two interesting items: the malware authors put the German word “nichts” as a string in the code, as well, they made a typo “phone standart.”

Details

In February 2015, Trend Micro posted details about an iOS espionage app possibly related to the Pawn Storm  / Sofacy / APT28 / Fancy Bear group. The technical details can be found at http://blog.trendmicro.com/trendlabs-security-intelligence/pawn-storm-update-ios-espionage-app-found/. Figure 5 of the Trend Micro document shows possible URL GET parameters used by the malicious code:

In the poprd30.apk code very similar items can be found related to the malicious communications:

By looking into BuildConfig it seems that one recompiled this APK modified Androdi Debug Key.

As one can see, strings in the APK file are very similar to those in the X-Agent implant, and have the same common goal: make the HTTP request similar to normal HTTP GET requests with common parameters. However, this similarity alone is not enough to state that the authors are the same, because it is very easy to copy this scheme.

Also, observe the initial value for the SERVER_ANSWER variable. It is “nichts,” which means “nothing” in German. We don’t know why a german word was used here. Note that this value is not used in the code, it stands only as a default value. That means, if no value is received from the server, then the corresponding function will return this value instead of the information received from the server. In the RegG.java file, which has the similar SERVER_ANSWER value it is set to ‘{ “no_jobs”, “or”, “error” };’ for default value. Setting a default value generally helps developers to find out if the data transmission was successful in the parts of the code not close to the transmission itself. One can simply check if the answer is still the default value, and if it is, it can be sure that the transmission was not successfull without complicated routines. However, in this APK we found no reference for checking if the SERVER_ANSWER has not been changed, and we don’t have clear idea why these two default values were used in the code.

Commands

Communication routines are spread across multiple classes: DataConstructor, DataExtractor, Reg, RegG, RegP, RegPBin. The main handling of the commands is in MainService. It is not entirely clear why there are multiple copies of some data and routines.

The malware sends basic info about the phone to the attacker as shown below:

byte[] arrayOfByte = Base64.encode((“<pre><font size=4 color=green><br>CMD 101 success</font>” + “<font size=4 color=blue><br>GoogleAccounts: ” + str1 + “<br>Device ID: ” + str2 + “<br>Model: ” + Build.MODEL + “<br>Manufacturer: ” + Build.MANUFACTURER + “<br>Phone standart: ” + str4 + “<br>Country: ” + str5 + “<br>MCC & MNC: ” + str6 + “<br>Base station: ” + str3 + “<br>Android version: ” + str7 + “<br>Android SDK: ” + m + “</font></pre>”).getBytes(), 0);

The malware can receive the following commands:

  • Commands 103 105 108: stop itself
  • Command 100 : Send SMS History /commands are self-explanatory/
  • Command 101: Collect “all” information about the phone and send
  • Command 102: GetCallDetails (Call history)
  • Command 104: FetchContacts
  • Command 106: GetAppList
  • Command 107: GetWifiStatus (is any WiFi network available, what identifier, what MAC address, speed, etc.)
  • Command 109: Browser history and bookmarks
  • Command 110: Mobile data usage
  • Command 111: Folders and files from sdcard directory
  • Command 112: File download (SDcard) for command
  • Command 101 – Gets GSM network LAC, CID info or base station info (coordinates) if CDMA, andorid version, google accounts, device id, etc.

Command 101 has a typo “phone standart” which should be “standard” both in English and German.

 

For command 101, it is important to note that it can provide location related information. In case of GSM , the base station related information can provide some (not so accurate) location information. Similarly, in case of CDMA, base station information is related to location, but it is not accurate either. In addition to the base station, WiFi information can also help an adversary to find out the approximate location of the phone, but it is nowhere close to accurate detection of the real location of the phone.

We have not seen any GPS related commands in the code, not even the original “D30 guidance” functionality. Most likely, the APK does not use GPS data. To be even more precise, the application Manifest information does not contain any requests related to GPS level locality permissions; it asks for  ACCESS_COARSE_LOCATION only, which relates to the base station/WiFi based location information.

 

Encryption – RC4

The malware uses communications encrypted by RC4, encoded by Base64 (or very similar – we did not check it carefully), and CRC for error checking. These are very common, but the most important thing is the RC4 implementation and the key in use, which can be proved to be similar to the older X-Agent implants.

The corresponding RC4 key is also visible in the java byte code format:

In hex, the encryption key is 3B C6 73 0F 8B 07 85 c0 74 02 FF CC DE C7 04 FE 72 F1 5F 5E C3 56 B8 D8 78 75 50 E8 B1 D1 FA 59 5D 55 EC 83 10 A1 33 35

Note: Rc4 keys can be arbitrary length, and implementation is very easy, hence it is used many times.On the other hand, RC4 is not secure enough for real crypto operations.

Conclusions

In our investigations, we tried to check if the APK indicated in the CrowdStrike report had backdooor connectivity. We can confirm, that this APK file has malicious functionality and can be used to collect intelligence from the users of the applet. Some additional technical details were discusssed. We (and probably CrowdStrike, too) had no access to the original, unmodified APK file.

UPDATE1

Some linux X-Agent versions used exactly the same RC4 key, see this screenshot:

RC4 key in linux xagent

 

Posted on Leave a comment

!SpamAndHex at the 24th DEFCON CTF Finals

Yes, we did it again. We played against the best teams in the world at the 24th DEFCON CTF Finals in Las Vegas. However, it was not as easy as it seems to be.

This year was fairly different from any other years before. For the first time in human history, teams had to play against the DARPA Cyber Grand Challenge (CGC from now on) winner machine Mayhem from ForAllSecure. Before we go into the details of the DEFCON CTF, let’s check what happened in the finals of the CGC machines.

One day before the 24th DEFCON CTF Finals took place, 7 selected machines fought against each other to win the CGC and play with human teams. The competition was launched in the morning on August 4, but only the last couple of hours were open to the public. The very first thing that caught our eyes is the huge effort that DARPA invested into the event.

Competitor machines stood on a stage in an air-gapped setup. Their tasks were three-fold:

  1.  find vulnerabilities in CGC binaries
  2. generate a Proof of Vulnerability (PoV a.k.a exploit)
  3. patch the vulnerability with a maximum of 5% performance lost. This was a strict and essential condition of the game.

The gaming hours were divided into 96 rounds under which 82 challenges were selected for the machines. Long story short, Mayhem turned to be the winner and ForAllSecure won 2 million USDs. Congratulations!

 


Next day, the DEFCON CTF finals started with a few hours of delay due to some initial issues that Legitimate Business Syndicate (the DEFCON CTF organizer team) had to solve. The game was designed to operate with 5-minute rounds so as to accumulate the points for each team after each round. So 14 human teams and a machine, Mayhem. Similarly to previous years, the challenges were released gradually, however, the teams could not attack each other directly. They created patches and PoVs for vulnerable CGC services, and submitted them on a central site. This year, the tooling and the strategy of a team played crucial roles in the competition. Simply, you could not do anything without understanding the CGC platform. The most important thing of all was, however, the patching strategy. After patching a service it was stopped for the next round, so it was not available. As I mentioned above, performance played a key role in the competition: the more vulnerabilities you patch at once the more points you will have. One more important thing: a PoV could only slow down other teams, but you did not get points for them directly. If a team did not play this strategy, he could not perform well. Unfortunately, we put much more emphasis on PoVs than on a good patching strategy. At the beginning of day 3, we were the 11th team out of 15, then the scoreboard was hidden away for the last 4 hours. For the final results we have to wait a couple of weeks.

On one hand, we see that a better strategy could have brought us better results. On the other hand, however, we are really happy to get into the Finals for the second time in a row. Similarly to last year, we could not have realized our goal of participating in the DEFCON CTF Finals without the generous support of our sponsors. Huge thanks to them once again! We hope that next year we can play once again with the best teams in the world.

Here are some photos about us:

IMG_20160805_111823

 

!SpamAndHex at DEFCON24 T-shirt front:

front_alt_sample_on_tshirt_smaller

!SpamAndHex at DEFCON24 T-shirt back:

back_alt_sample_small

 

 

And finally the team:

sah_defcon2

 

Posted on Leave a comment

Oops!… We Did It Again

Yeah yeah yeah yeah yeah
Yeah yeah yeah yeah yeah yeah

We think we did it again
We made you believe it’s more than just luck

One year ago, we were proud to announce that the CTF team of the CrySyS Lab qualified for the DEFCON CTF Finals, which is among the most prestigious hacker competitions in the world. Now, we announce with the same pride that WE DID IT AGAIN: our !SpamAndHex team qualified for the 2016 DEFCON CTF Finals and it will travel to Las Vegas within two weeks to play against 14 other teams and a program (the winner of the DARPA Cyber Grand Challenge) between August 4 and 7. Congratulations to the team and looking forward to this extraordinary experience!

By the same token, we would like to express our immense gratitude to our sponsors who made it possible for the team to travel to the competition. They are: Tresorit, BalaBit, Dimension Data, ESET/Sicontact, SEARCH-LAB, MRG-Effitas, Microsec, Hunity Defense, Sophos, Symmetria, TMSI, and BME’s Faculty of Electrical Engineering and Informatics. Below is our team’s T-shirt design showing the sponsor logos. It is heartwarming to witness that our industry partners and our university appreciate our efforts and support the team when we need help.

Sponsors in 2016

You may ask how it is possible that students from a not-so-well-known university of a small country repeatedly achieve first class results at an international level and the 5th position in the world ranking of all hacker teams last year. We assure you that this is not pure luck! Rather, we believe it has something to do with our talent management program in the CrySyS Lab. If you are interested in what is that, then you can read our paper, which has just been accepted for presentation at the Usenix Workshop on Advances in Security Education (colocated with the 25th Usenix Security Symposium in Austin, TX, on August 9, 2016).

If you like what we do and want to help our work on growing talented IT security professionals, please, contact us (by writing to buttyan@crysys.hu).

Posted on Leave a comment

Hacking cars in the style of Stuxnet

Stuxnet is well-known in the IT security community. Its fame stems from the facts that it targeted a very specific industrial facility, it aimed at physical destruction, and it apparently accomplished its mission successfully. In addition to all these characteristics, IT security experts also appreciate its technical sophistication and the zero-day exploits that it used. Yet, we believe that the most important impact of Stuxnet in the long run is that it provides a blueprint for carrying out similar attacks in other embedded computing environments.

To demonstrate this, we started experimenting with attacking cars in the same style as Stuxnet attacked uranium centrifuges. Our experiments show that it is relatively easy to perform dangerous modifications to the settings of different car equipment (e.g., the airbag or the ABS in the car) by simply infecting the mechanic’s PC or laptop that runs the diagnostic software used to manage those equipment in the car, and replacing the DLL responsible for communications between the diagnostic software and the car with a malicious DLL that implements man-in-the-middle type attacks (e.g., replay or modification of commands). Indeed, PCs and laptops in mechanics’ workshops are not well maintained, often connected to the Internet, and used for various purposes, not only for diagnostics on cars. So, while remote attacks via the Internet or wireless interfaces seems to be more exciting than attacking cars via the mechanic’s PC or laptop, the latter can in fact be much easier to carry out and more effective in practice. Note the similarity to Stuxnet, which infected PCs that run the software used to manage the PLCs that controlled the uranium centrifuges, and replaced the DLL that was responsible for the communications between the management software and the PLCs.

More specifically, earlier this year, we carried out some research on an Audi TT at the Department of Automobiles and Vehicle Manufacturing of the Budapest University of Technology and Economics. We partially reverse engineered a widely used third-party car diagnostic software, and managed to identify and replace the DLL that it uses to communicate with a special diagnostic cable that attaches to the car’s OBD connector. Our replacement DLL implements man-in-the-middle attacks: we can log all communications between the diagnostic software and the car, as well as replay and modify messages. For this, we also had to partially reverse engineer the protocol used for communications, including figuring out how to decrypt encrypted messages and compute checksums. Finally, as a proof-of-concept, we managed to replay a message that switches off the airbag of the car without the diagnostic software noticing the misdeed.

We presented this work at the Hacktivity 2015 conference in October. The presentation and the recording of the talk is available on the web site of Hactivity (https://hacktivity.com/en/archives/hacktivity-20151/). The slides are also available on Levente’s publication page (http://www.hit.bme.hu/~buttyan/publications.html#SzijjBSz15hacktivity). The direct link to the recorded talk is: https://www.youtube.com/watch?v=5UCsKQjB6ZE.  The work also generated some media attention:

The most accurate description (after our own slides and this blog post, of course) was published in Hungarian on the HWSW portal: http://www.hwsw.hu/hirek/54692/crysys-auto-jarmu-biztonsag-man-in-the-middle.html

The Register article, which was published first:
http://www.theregister.co.uk/2015/10/23/hackers_pop_mechanics_laptops_to_silently_disable_car_airbags/

Others just copied from the above the Register article, and most of them do not describe our work accurately enough:
http://www.heise.de/security/meldung/Audi-TT-Airbag-heimlich-ueber-Diagnose-Software-deaktiviert-2858815.html
http://wccftech.com/cars-safety-bags-unsafe-hackers-find-disable/
http://news.softpedia.com/news/audi-cars-hacked-but-only-airbag-system-affected-495257.shtml
http://www.techworm.net/2015/10/hackers-find-a-way-to-disable-your-cars-airbag-system.html
http://www.scmagazine.com/researchers-control-features-in-vw-group-vehicles-through-a-zero-day-in-software-that-in-widely-used-mechanic-software/article/449161/
http://www.mirror.co.uk/news/technology-science/technology/car-airbags-disabled-hackers-cyber-6690661
http://news.sky.com/story/1575011/hackers-could-disable-car-airbags-report
http://www.cnnindonesia.com/teknologi/20151023171304-185-86938/hacker-mampu-meretas-airbag-mobil-vw/
http://www.techcult.ru/auto/2707-hakery-i-airbag

Some frequently asked questions:

Can you reveal the name of the diagnostic software which you carried out the experiments with?

No, we do not reveal the name of the software. It is sufficient to know that it’s a pretty widely used diagnostic software that is compatible with cars in the VW group. Note, however, that this has nothing to do with VW itself, it’s not their fault, this is a 3rd party software. In addition, we also looked into two other similar diagnostic software from other vendors, and they seem to have the same problem. Essentially, they all use the FTDI DLL to communicate with the diagnostic cable, so the generic idea of our attack (replacing that DLL with a fake one) would work. Details may be different though, as those software may apply different protections against reversing (e.g., better encryption of messages between the application and the cable which would make understanding the protocol harder). We have not yet checked in details those other two software. Also important to point out, that it is not the specific software, which makes our work interesting, but the main message is that embedded devices are typically managed from PCs and they can be infected by using those PCs as stepping stones. This is what we mean by a Stuxnet-style attack in the title of our talk.

Would the attack work for anything other than Audi TTs?

Yes, it works with other cars in the VW group too without any modification. And as said before, it could work with other car brands that use vulnerable diagnostic applications from other vendors.

How challenging is this attack to a reasonably skilled hacker?

It is not something special, so for a reasonably skilled attacker it is completely doable. Important to note that the attacker does not really need to hack embedded ECUs, but the attack essentially requires reversing and attacking an application running on a PC.

Can you do other things than switching the airbag off?

Anything that can be switched on or off from the diagnostic application could have been switched on or off. Moreover, we can hide this from the operator, because our Man-in-the-middle fake DDL can falsify parameters read out from the car. E.g., after switching off the airbag, we can consistently report to the application that it is still switched on.

Is there any limitation of the attack?

One limitation of our attack is that we can only set parameters when the car is connected to the infected PC. In contrast to this, remote attacks that have been in the media recently can affect the car’s behavior in real-time. However, they are much more difficult to carry out, because the attacker needs to find and exploit some vulnerability in one of the ECU’s of the car, instead of infecting a potentially badly managed PC in a repair shop. Yet, our attack may be extensible to be more dangerous: e.g., it may be possible to update the software/firmware of some ECUs via the OBD2 port, in which case we could insert a hidden functionality that is triggered by some condition later on. This is still not completely interactive, but more than a static switch off of a component. However, we did not performed any experiment of this kind, because we didn’t want to potentially brick our university’s car.

Is this attack something really new?

Actually not. Prior work (e.g., Checkoway et al. Comprehensive Experimental Analyses of Automotive Attack Surfaces, Usenix Security 2011) already mentioned the possibility of infecting cars by first infecting diagnostic equipment. Our work was a proof of concept where we tried to study how easy such an attack would be.

Is this really an attack? I mean that if you are connected to the OBD port, you can do whatever you want with the car.

Sure. But let us emphasize again the importance of the generic model of the attack: attack a PC that manages an embedded device, and then attack the embedded device itself. This could be a nightmare in the future. Imagine that you manage all your smart devices in your home/office/factory from your PC. Once dozens of embedded devices are successfully infected, the malware can even disappear deliberately from the PC, so all those embedded devices remain infected and you may never detect that. Whether we call this an attack or not does not really matter. This is certainly an important problem and challenge that we have to address in the future.

 

Acknowledgements

This was joint work with Dr. Zsolt Szalay from the Department of Automobiles and Vehicle Manufacturing. We are thankful to him for letting us experiment with the department’s Audi TT. Indirectly, we are also thankful to Audi for supporting research at the Budapest University of Technology and Economics.