Posted on Leave a comment

Using Buildroot to create custom Linux system images

This blog post, written by Szilárd Dömötör, is the second post in a series of blog posts on transforming the Raspberry Pi into a security enhanced IoT platform. The first post explained how to build and install the default OP-TEE implementation for the Raspberry Pi 3. This one describes how you can build your own custom Linux system (with OP-TEE) using the Buildroot environment. Continue reading Using Buildroot to create custom Linux system images

Posted on Leave a comment

OP-TEE default build and installation on the Raspberry Pi

This blog post, written by Márton Juhász, is the first in a series of blog posts on transforming the Raspberry Pi into a security enhanced IoT platform.

This blog post explains how to build and install the default OP-TEE implementation for the Raspberry Pi 3. The easiest way is to follow the steps described in the corresponding git repo of OP-TEE. However, for the sake of completeness (and because some steps may actually be a bit confusing in the original description), we provide a comprehensive description here. Continue reading OP-TEE default build and installation on the Raspberry Pi

Posted on Leave a comment

Enhancing the Security of the Internet of Things

The Internet has grown beyond a network of laptops, PCs, and large servers: it also connects millions of small embedded devices. This new trend is called the Internet of Things, or IoT in short, and it enables many new and exciting applications. At the same time, IoT also comes with a number of risks related to information security. The lack of security, however, cannot be tolerated in certain applications of IoT, including connected vehicles and smart factories. In those applications, security failures may lead to substantial physical damage or monetary loss. Therefore, one of the biggest challenges today, which hinders the application of IoT technologies in certain application areas, is the lack of security guarantees. Continue reading Enhancing the Security of the Internet of Things

Posted on Leave a comment

Interdependent privacy in effect: the collateral damage of third-party apps on Facebook

by Iraklis Symeonidis, COSIC, KU Leuven
and Gergely Biczók, CrySyS Lab, BME

Recent technological advancements have enabled the collection of large amounts of personal data at an ever-increasing rate. Data analytics companies such as Cambridge Analytica (CA) and Palantir can collect rich information about individuals’ everyday lives and habits from big data-silos, enabling profiling and micro-targeting of individuals such as in the case of political elections or predictive policing. As it has been reported at several major news outlets already in 2015, approximately 50 million Facebook (FB) profiles have been harvested by Aleksandr Kogan’s app, “thisisyourdigitallife”, through his company Global Science Research (GSR) in collaboration with CA. This data has been used to draw a detailed psychological profile for every person affected, which in turn enabled CA to target them with personalized political ads potentially affecting the outcome of the 2016 US presidential elections. Whether CA used similar techniques at the time of the Brexit vote, elections in Kenya and an undisclosed Eastern European country (and several other countries) is under investigation. Both Kogan and CA deny allegations and say they have complied regulations and acted in good faith.

This blog post does not take sides in this debate, rather, it provides technical insight into the data collection mechanism, namely collateral information collection, that has enabled harvesting the FB profiles of the friends of app users. In this context, the term collateral damage refers to the privacy loss these friends suffer. In a larger nexus, this issue is part of interdependent privacy when your privacy depends unavoidably on the actions of others (in this case, your friends). Continue reading Interdependent privacy in effect: the collateral damage of third-party apps on Facebook

Posted on Leave a comment

Territorial Dispute – NSA’s perspective on APT landscape

Boldizsár Bencsáth (Boldi) will have a presentation at Kaspersky Security Analyst Summit on 09/03/2018 Friday. The presentation is based on a technical paper which describes findings about modules and information in April 2017 Shadow Brokers leak. The particular information categorizes external APT attackers and calls them SIG1 to SIG45. For more, please check the paper. Please do not forget The corresponding external sample hash list text file.

Posted on Leave a comment

Együttműködési megállapodás a Microsec Zrt-vel

Örömmel jelentjük be, hogy a CrySyS labor együttműködési megállapodást kötött a PKI alkalmazásában és fejlesztésében úttörő szerepet betöltő Microsec Zrt-vel.

A két szervezet az elmúlt években is aktív kapcsolatot ápolt, mely keretében a Microsec anyagi és tárgyi eszközökkel támogatta laborunk kutatómunkáját, valamint a laborból indult etikus hackercsapat, a !SpamAndHex külföldi versenyeken való részvételét. Jelen megállapodással a Microsec célja a PKI-val kapcsolatos kutatás-fejlesztési és innovációs tevékenységek kiemelt támogatása, az egyetemi kapcsolatok erősítése, a kutatásokhoz első kézből információk szolgáltatása a gyakorlati problémákkal kapcsolatban. A labor számára az előnyt a tehetséggondozási programunk anyagi támogatása, valamint érdekes, az ipari gyakorlathoz kapcsolódó kutatási feladatok megfogalmazása, és a stabil ipari kapcsolat jelentik.

A PKI kutatások területén a jövőben a labor a Microsec kihelyezett kutató laboratóriumaként működik, és közös publikációk megjelentetésére törekszik.

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