Az van, hogy nem tudom hol találtam a linket erre a Core Security figyelmeztetőre, minden esetre a H-Security azt írja, hogy a lent részletezett bugot már javította a Microsoft, erre utaló bejegyzést ugyanakkor sem a disclosure timeline, sem a BID nem mond semmit a javítás kiadásáról. Minden esetre szerintem egy nagyon érdekes próblémáról van szó, és nagy valószínűséggel a BlackHat-en is valami nagyon hasonlót fognak bemutatni.

Nos, eddig abban a hitben éltem, hogy az újonnan bejelentett Internet Explorer hiba részleteiről csak február 2-án szerezhetünk tudomást, amikor is a hiba felfedezője, Jorge Luis Alvarez Medina elő fogja adni a történetet a BlackHaten. Egyedül azért álltam neki ennek a posztnak, mert tisztázni akartam azt a sok marhaságot, amit a hazai hírportálok eddig leközöltek, aztán látom, hogy a Core Security teljes leírással és PoC-al szolgál az érdeklődőknek. Lássuk tehát, hogyan is lehet lenyúlni az egyszeri IE felhasználó fájljait:

1. Először is ki kell találni a célpont felhasználónevét: ez nem nehéz, ha nyitva van a 445-ös port, ahol a Windows általában a fájlmegosztást intézi, egyébként találgatni kell. Ez a történet gyenge pontja, valamint a nyelv is bezavarhat de ezzel most nem foglalkozunk (a Windowst korlátos számú nyelven adták ki, tehát a probléma áthidalható).
2. A felhasználónév alapján tudjuk, hogy milyen útvonalon lehet hozzáférni az Internet Explorer által tárolt adatokhoz, pl. a böngészési előzményekhez vagy a sütikhez.
3. Ez után a támadó elindít egy HTTP-átirányítás-láncot, ami teleszórja mindenféle címekkel a böngészési előzményeket. A trükk az, hogy ezeket egy majdnem sima szöveges állományban tárolja az IE, amibe simán berakhatunk némi HTML kódot is. 
4. A átirányítás sorozat utolsó állomása először is csinál egy <frame>-et, amibe betölt egy <object> taget tartalmazó fájlt. A böngésző mindenféle felesleges figyelmeztetéseket dobálna a felhasználónak, ha egy <object> tag-en keresztül szeretnénk hozzáférni egy fájlhoz, de amennyiben mindezt egy keretben tesszük, a figyelmeztetések eltűnnek.
5. Az <object> tag egy útközben generált, text/html MIME típusú távoli fájlra hivatkozik, ami egy 302-es HTTP átirányítással (igen, ez is feldolgozódik) a file:// protokollazonosítót használva egyszerűen átdobja a felhasználót a saját history fájljára (aminek a helyét a felhasználónévből tudjuk), amit ugyebár már előzőleg teleszórtunk HTML kóddal. 
6. Ez a kód az Internet Zónában renderelődik, aminek elvileg nincs joga hozzáférni a helyi gép erőforrásaihoz. A trükk az, hogyha a nem gépnévvel, hanem IP címmel hivatkozunk a helyi hosztra UNC formátumban (\\127.0.0.1), az IE úgy tekinti, hogy az Internet Zónában keresünk valamit, a zónán belüli olvasás pedig megengedett, így bármit kiolvashatunk, az áldozat gépéről, aminek tudjuk az elérési útját. Természetesen a kiolvasó szkriptnek a helyi hoszton kell futnia, hogy hozzáférjen a lokális fájlokhoz, erre ment ki a játék a harmadik lépésben.  

Röviden ennyi a történet, bővebb információkért nézzétek meg az eredeti leírást és tanulmányozzátok a PoC-t. A fenti furcsaságok oka egyébként nagy valószínűséggel az, hogy az IE motorját használja a Windows Explorer is. Az illetéktelen fájlolvasáshoz egy sor, önmagában ártalmatlan bug és feature láncolata vezetett, látszik tehát, hogy tervezési hibáról van szó. 

Megoldásként IE8-ra vagy alternatív böngészőre váltás, az Internet és Intranet zónák biztonsági szintjének Magasra állítása, az IE védett módú futtatása vagy a file:// protokollkezelő letiltása képzelhető el.