По Неофициални Статистически Данни Повече От 80% От Дяла На Използваните Браузери Се Пада На Microsoft Internet Explorer
Total Page：16
File Type：pdf, Size：1020Kb
Ангелина Тагарева, ф.н. 43153, 3 курс, специалност информатика Радостин Цанев, ф.н. 43089, 3 курс, специалност информатика Анализ на излезлите експлойти за Internet Еxplorer Курсов проект по Мрежова Сигурност – Сигурен Код Ангелина Тагарева, ф.н. 43153 Радостин Цанев, ф.н. 43089 По неофициални статистически данни повече от 80% от дяла на използваните браузери се пада на Microsoft Internet Explorer. Като най-често използван интернет браузер, сигурността очевидно не е била основна задача при имплементирането му. Свидетелство за това са многобройните уязвимости и експлойти, излези за този продукт. Интересното в случая е, че уязвимостите в MS IE са пъти повече от конкурентни open source решения, въпреки че кодът на браузера е затворен. Преди за започнем същинското изложение на излезлите експлйти за Microsoft Internet Explorer, ще направим няколко уточнения. Първо е важно да отбележим каква е разликата между уязвимост и експлойт. Уязвимост представлява проблем в сигурността на даден софтуер. Експлойтът е програмен код, който се възплозва от тази уязвимост. Тези две понятия вървят ръка за ръка, затова в нашето изложение ще посочваме първо за каква уязвимост се отнасят дадените експлойти и чак след това ще пристъпваме към самото им разглеждане. В политиката за сигурността на IE е застъпена идеята за различни зони на сигурност. Те биват четири вида: Internet Zone, Local Zone, Trusted Sites и Restricted Sites. Според официалния сайт на Microsoft, "Сигурността, залегната в Internet Explorer 6 е добре балансирана. При първата инсталлация на браузера, той поставя всички уеб сайтове в Internet Zone със средно ниво на сигурност. По този начин може да браузвате сигурно и ще бъдете предупраждавани преди свалянето на потенциално опасно съдържание". Ще видим случаи, в които това въобще не е валидно. Формално експлойтите за MS IE могат да бъдат разделени на няколко части, според тяхната опасност и предназначение. Ние ще ги разделим по следния начин: 1. Експлойти, които позволяват изпълнението на чужд код на клиентската машина - това са експлойтите с най-висока спепен на риск, по разбираеми причини. Намират се в най-горната част от йерархията на експлойтите, понеже често се възплозват от други експлойти и уязвимости, с чиято помощ изпълняват зловредния код. Ако клиентският IE е податлив на такъв вид атаки, то клиентската машина се намира изцяло в ръцете на "лошия човек", който иска да получи контрол над нея. 2. Експлойти, които заблуждават клиента и създават в него лъжливо чувство за сигурност. Това са на пръв поглед не дотам опасни проблеми със сигурността, но всичко зависи от това за кого се прадставя злонамереният човек, който иска да ви заблуди. В повечето случаи този тип експлойти се използват за незаконно присвояване на номера на кредитни карти и всякакъв друг вид ценна информация. Нивото на опасност от този вид атака е повече от високо. 3. Cross-Zone Scripting експлойти или по-точно начини, по които може да присвоим права за изпъление на даден програмен фрагмент в контекста на Local Zone. Сами по себе си този тип екслпойти не са толкова опасни. Съчетани с други екслпойти, изпълнението на които изисква повишаването на правата на приложението, те се превръщат в сериозна заплаха за сигурността. -1- Ангелина Тагарева, ф.н. 43153, 3 курс, специалност информатика Радостин Цанев, ф.н. 43089, 3 курс, специалност информатика 4. Cross-Site Scripting(XSS) експлойти, с чиято помощ може да се постигне кражба на кукита, сесийни ключове и друг вид чувствителна информация. 5. DoS експлойти, с чиято помощ може да се блокира изпълниението на IE, както и да се застраши стабилността на системата. 6. Има и експлойти, които не попадат в горните категории и които ще разгледаме самостоятелно. Експлойти, които позволяват изпълнението на чужд код Сега ще покажем как в средата на 2002 година е било възможно да се изпълнява код на клиентския компютър, без дори необходомостта Active Scripting да бъде включено. Преблемът идва от динамично добавяните HTML фрагменти във всяка една част от документа. Чрез използването на innerHTML, outerHTML или insertAdjacentHTML може да се постигне следния резултат: <span id="oSpan"></span> <script language="jscript" defer> oSpan.innerHTML='object classid="clsid:11111111-1111-1111-1111-111111111111" codebase="c:/winnt/system32/calc.exe"></object>'; </script> За да може да се прилага този експлойт върху IE, в който са изключени Active Scripting и ActiveX, ще използваме Data Binding. То позволява на програмистите напълно да разделят презентацията от логиката. Източниците на данни (DSO) за Data Binding могат да бъдат най-различни, като например CVS, HTML или XML. С помощта на data-binding HTML елементи, като например div или span могат да бъдат свързани към DSO без нуждата от нито един ред скрипт. Ще използваме още, че когато атрибутът dataformatas има стойност 'html', тогава Data Binding използва вътрешно innerHTML за предоставане на данните на елемента. В следващия пример ще използваме XML като източник на данни и span за консуматор на тези данни. <span datasrc="#oExec" datafld="exploit" dataformatas="html"></span> <xml id="oExec"> <security> <exploit> <![CDATA[ object id="oFile" classid="clsid:11111111-1111-1111-1111- 111111111111" codebase="c:/winnt/system32/calc.exe"></object> ]]> </exploit> </security> </xml> Друг един експлойт се възползва от факта, че IE може да бъде накаран да се отвори и да зареди страница, без значение от зоната за сигурност, в която се намираме. За да се възползва от тази уязвимост, атакуващият трябва да използва форма'та за аудио/видео streaming на Microsoft WMV/WMA. WMV/WMA има възможността да включва в себе си скриптове, които контролират различни аспекти на клипа. Именно тези скриптове правят възможно player-ът да отвори даден URL в определен период от време. -2- Ангелина Тагарева, ф.н. 43153, 3 курс, специалност информатика Радостин Цанев, ф.н. 43089, 3 курс, специалност информатика Това означава, че дори клипът да е пуснат в "Restricted Zone", лесно може да отвори URL в "Internet Zone" или всяка друга зона, която пожелае. Един добър пример за експлойт е когато атакуващият знае за съществуването на даден файл на клиентската машина, който иска да изпълни. За да се възползва от тази уязвимост, атакуващият има нужда от три файла. Първият е HTML, който потребителят трябва да разгледа и който зарежда клип (вторият файл). Сега остава само клипът да задери някой друг HTML, който съдържа в себе си object с codebase = "malicious.exe" и компютърът на жертвата вече е в ръцете на атакуващия. Ето един начин, по който може да се пусне за изпълнение клип, чието място на твърдия диск знаем: <body> Hello <xml:namespace prefix="t"/> <t:video style="display:none;behavior:url(#default#time);" t:src="file://C:/Documents/Мovies/gmlaunch.wmv"/> </body> Един друг проблем със сигурността на MS IE е, че той не оценява правилно "application/hta" MIME типът, който се използва от DATA атрибута на елемента OBJECT. IE ще изпълни HTML приложение (HTA), което е посочено в DATA атрибутът на елемента OBJECT, ако Content-Type, върнат от сървъра, е "application/hta". Атакуващият може да използва тази дупка в сигурността, за да изпълни произволен код с привилегиите на потребителя, използващ IE. Dynamic HTML Object Model (DOM) на IE дефинира елемента OBJECT като начин да се вграждат ActiveX контроли и други обекти в HTML документи. Атрибутът DATA е URI, който предоставя данните за обекта, например <OBJECT DATA="somefile.html">. HTML приложенията (HTA) са HTML документи, които се изпълняват като доверени приложения, които не са обект на ограниченията в сигурността на IE. HTA могат да изпълняват скриптове, Java или ActiveX контроли. В документацията на Microsoft пише следното: "Внимание, HTA могат да подложат машината на клиента под въздействието на злонамерени скриптове. HTA, също като .exe файловете, имат права за четене и запис на файлове и работа с регистрите. Само с няколко кратки команди, може да се създадат много мощни изпълними файлове. Изпълнението на HTA не се препоръчва на места, където произхода на файла е съмнителен". Вместо да приема Content-Type хедъра, предоставен от сървъра (както се препоръчва в RFC 2616), IE използва доста сложна схема за определяне на MIME типа на даден файл, който е посочен в URI. В много случаи IE сваля и обработва(парсва) файла като част от процеса за определяне на типа му. Тази проверка не може да различи HTML от HTA файлове, понеже и двата типа са текстови файлове, които съдържат HTML код. Като резултат, IE приема Content-Type, предоставен от сървъра. Когато се достъпва даден HTA файл директно, IE пита потребителя дали да свали или да изпълни файла. Проблемът идва от това, че когато HTA файл се задава от DATA атрибут на елемента OBJECT и уеб сървъра върне хедър с Content-Type равен на "application/hta", IE изпълнява HTA файла директно, без намеса на потребителя. HTML-ът който се използва за обръщение към HTA файла, може да бъде създаден по всеки един от следните начини: 1. Статичен HTML; 2. HTML, създаден от скрипт; 3. HTML, създаден чрез Data Binding. -3- Ангелина Тагарева, ф.н. 43153, 3 курс, специалност информатика Радостин Цанев, ф.н. 43089, 3 курс, специалност информатика Microsoft Internet Explorer Codebase Double Backslash Local Zone Тази уязвимост позволява на HTML документи да добият непозволен достъп до локални ресурси, като се използват ресурси като стойности на CODEBASE поле. При определени условия това може да бъде използвано, за да се изпълнят файлове на клиентската машина. В частност, като се сложат две обратни наклонени черти в началото на пътя на ресурса, става възможно неговото