Ucelom tejto nody je overenie konceptu moznosti odchytenia IP adresy ako potencialnej zranitelnosti information leakage. Po nazbierani dostatocneho mnozstva materialu budu zverejnene niektore detaily, ktore budu dostatocnym sposobom demonstrovat dany koncept. Z pochopitelnych dovodov bude zverejnena len ciastocna informacia, tak aby bolo respektovane pravo na ochranu sukromia zakotvene v ustave clenskych statov EU. Posudok, ci je resp. bude dane spravanie systemu mozne povazovat za zranitelnost necham na kompetentnych.
Please stand by...





OK, nazbieral som dostatocne mnozstvo materialu, takze mozme prikrocit k prezentacii. Ide o to, ze "zranitelnost" sa navonok vlastne ani nejavi ako "zranitelnost". Jedna sa skor o [vy|zne]uzitie spravania komunikacie protokolu HTTP pri parsovani HTML dokumentu, ktore umoznuje lubovolnej 3tej strane, ktora moze vytvarat prispevky, logovat niektore informacie, ako IP adresu, pole referer a zaznamenat cas pristupu daneho uzivatela k sledovanemu miestu. "Zranitelnost" javi znamky, ktore su typicke pre oblast web application security, kedze nenarusuje integritu serveru a sluzieb, ktore na nom bezia, ale server vyuziva len ako sprostredkovatela informacie veducej k "utoku". V kombinacii s dalsimi udajmi, ktore je mozne verejne ziskat z weboveho rozhrania Kyberie ma teda potencialny utocnik moznost ziskat udaje, kto sa kedy z akej IP adresy v akom case k sledovanemu miestu prihlasil. Na zaklade zpracovanych informacii sa mi podarilo zistit napriklad, ze ID ChreN vyuziva k pripojeniu provider Chello, zatial co ID Abbys a ID v92 pouzivaju k pripojeniu brany T-comu a v92 ako spravny paranoik filtruje pole referer. Cenzurovanu ukazku z logu je mozne vidiet na nasledujucom priklade:

01]<85.xxx.232.xxx> <03:17:11 - 03.05.09>
02]<91.xxx.184.xx> <03:47:13 - 03.05.09>
03]<78.xx.62.xxx> <03:53:48 - 03.05.09> <>
04]<78.xxx.117.xxx> <06:55:50 - 03.05.09> <>
05]<213.xxx.8.xx> <07:13:38 - 03.05.09>
06]<213.xxx.118.xx> <08:37:31 - 03.05.09>
07]<62.xxx.125.xx> <08:46:21 - 03.05.09>
08]<82.xxx.104.xx> <08:55:46 - 03.05.09> <>
09]<213.xxx.217.xxx> <09:00:57 - 03.05.09>
10]<213.xxx.217.xxx> <09:10:30 - 03.05.09>
11]<78.xx.174.xx> <09:18:50 - 03.05.09>
12]<84.xx.34.xxx> <09:35:19 - 03.05.09>
13]<78.xx.47.xx> <09:42:08 - 03.05.09>
14]<78.xx.130.xxx> <09:50:50 - 03.05.09>
15]<88.xxx.6.xx> <10:10:13 - 03.05.09>
16]<195.xx.79.xx> <10:12:03 - 03.05.09>
17]<138.xxx.7.xxx> <10:14:14 - 03.05.09> <>
18]<85.xxx.195.xxx> <10:21:00 - 03.05.09> <>
19]<195.xx.8.xx> <10:22:18 - 03.05.09> <>
20]<213.xx.146.xxx> <10:30:44 - 03.05.09> <>
21]<92.xxx.8.xx> <10:32:45 - 03.05.09>
22]<62.xxx.69.xx> <10:37:57 - 03.05.09>
23]<78.xx.62.xxx> <10:38:18 - 03.05.09>
... und so weiter :-)

Na kolko je mozne to povazovat za zranitelnost necham na vas, pravdou vsak je, ze komercne servere byvaju proti tejto moznosti osetrene, napriklad stahovanim externych objektov prostrednictvom vlastneho rozhrania, takze linky veduce von su preparsovane na nieco, co by vyzeralo asi takto

kybaria.sk/?external=http://externy.objekt

pri tom je este nutne zabezpecit, aby boli prepustene len tie dotazy, ktore zadal interny uzivatel Kyberie, aby nebolo mozne URL pouzivat ako redirektor pre vonkajsie entity. Utocnik by tak nemal mat moznost odchytit IP adresu [inu nez Kyberie].