Kedden az IT café is megírta, hogy az E-Siber.com oldalon megjelent egy bejegyzés, ami azt állította, adatokat lop a Dropbox, és minden adatunkhoz hozzáfér. Az eredeti cikk szerzője alaposan dokumentálta a folyamat első lépéseit, de a kritikus pontokon már nem volt ennyire alapos. Kérdéseinket feltettük a Dropbox sajtóosztályának, illetve mi magunk is nyomozásba kezdtünk.
A riadalmat az okozta, hogy M. Mekin Pesen észrevette, minden esetben, ha új fájlt hoz létre (akár a megosztott mappákon kívül), a Dropbox akcióba lendül, és először az új fájllal foglalkozik, aztán a szerverrel kommunikál. Rengeteg hasznos hozzászólás érkezett a tegnap megjelent hírünkhöz, több olyan közbeékelődéses módszerre kaptunk javaslatot, amivel olvasóink szerint kideríthető, hogy pontosan milyen adatokat forgalmaz az alkalmazás. A BurpSuite MiTM megoldását próbáltuk ki, de a kétirányú authentikáció miatt ez nem volt járható út. Kénytelenek voltunk tehát a generált forgalomra hagyatkozni ezen a téren.
Mit csinál a fájlokkal a Dropbox?
Amikor létrehozunk egy új dokumentumot, a Dropbox asztali kliense információt kér a fájlról és lekérdezi (egészen pontosan a shell32.dll fér hozzá a fájlhoz, nem is a Dropbox) az adott tartalom teljes elérési útját. Erre azért van szüksége, hogy ellenőrizhesse, szükség van-e a szinkronizálásra, vagy nincs. A lekérések során nem olvassa a fájl tartalmát (ezt egyébként a Dropbox az IT cafénak küldött rövidke válaszában is megerősíti, ebben azt írják: a poszt téves, a Dropbox kizárólag az engedélyezett mappákból szinkronizál). A folyamatot bárki ellenőrizheti, mi a Rotihab API Monitorát használtuk. A fentiekből egyértelműen kiderült, hogy a Stat és a GetLongPathName függvények meghívásán túl nem történik más.
A másik kritikus pont az adatküldés volt, amit a Dropbox SSL kapcsolaton keresztül intéz, ezt pedig nem sikerült megkerülnünk, sem visszafejtenünk. Mivel a rendszer többrétegű védelmet és ún. certificate pinning eljárást is használ, a BurpSuite nem jelentett segítséget, az előtelepített tanúsítványok ellenére nem fogadta el azokat, nem volt hajlandó kommunikálni. Így maradt az a megoldás, hogy az adatforgalom mennyiségét figyeljük. Létrehoztunk több dokumentumot is, kisebbeket, nagyobbakat egyaránt. A tapasztalatok alapján a közelében sem járt a továbbított adatmennyiség a valós fájlméretnek. Tény és való, hogy minden egyes új dokumentum létrehozását követően beszélgetésbe elegyedett a szerverrel a kliens, ami akkor sokkal ritkábban történt meg, ha nem nyúltunk a tesztkörnyezethez, azonban azt is elvethetjük, hogy a fájljainkat titokban ellopná.
Végezetül szeretnénk köszönetet mondani a kapcsolódó fórumban tapasztalható aktív és hasznos hozzászólásokért emvynek és sztanozsnak, illetve hálával tartozunk még Stefano Fratepietro úrnak (DEFT) a szakmai iránymutatásért.
