Блог предназначен для публикации научных статей и материалов
|
Забруднення домену - Аміт КлеінЗабруднення домену
Абстрактний Ця коротка рецензія описує атака, яка використовує властиві недолік стороні клієнта модель довіри в контексті кібер-навпочіпки і область угон, або в цілому, в контексті отримання тимчасового власника домену (або основних частин це, наприклад, псування на головній сторінці). Простіше кажучи, ідея вивчити, щоб змусити довгострокових кешування сторінок шкідливим для того, щоб вони як і раніше в силі навіть тоді, коли область повертається до свого законному власникові. Різні напрямки атак обговорюються, а також можливі способи захисту. У той час як попередні роботи натякнув на можливість такого нападу, варто обговорити цю атаку в глибину і спростувати поширену помилку, що кібер-на корточках, домен викрадення й інших подібних атак не мають тривалий ефект. Аудиторія Так як частину матеріалу, вважається певною новизною, але не занадто технічним або занадто неясними, аудиторія складається з: - Експерти з безпеки Введення і довідкова інформація Інтерес до цієї рецензії є сценарій, в якому домену (наприклад, який буде служити нам протягом цієї рецензії є "vuln.site") тимчасово під контролем зловмисника. Таким чином, атакуючий може служити (або викликати порцію) точка входу на веб-сайт (позначається як "домашньої сторінки") з хост (або декілька хостів) в даній області (наприклад, www.vuln.site, з домашньої сторінки визначається як http://www.vuln.site/). До сьогоднішнього дня, було припущення, що, як тільки атака закінчується, тобто після домену (назад) в управління його законному власникові, або коли пошкоджені сторінці буде відновлений у своєму первісному вигляді, атака закінчилася, і практично не довго умови ефекти залишаються. Ця рецензія показує, що складні зловмисник може завдати тривалий збиток, який набирає чинності після довгого область / сторінки буде відновлена. Цей напрямок натякнув в [1], [2] і [3], але поки ця рецензія, не був повністю обговорювалося. Передумовою для цієї атаки таким чином, що зловмисник може повністю контролювати зміст "домашньої сторінки" (або будь-який інший популярної сторінки) на хост в домені. Це може бути досягнуто за допомогою наступних атак: Cyber-на корточках: зловмисник реєструє домен, який пізніше буде переведений на іншу сторону (або, що партія пред'явлення претензій на домен, або шляхом продажу домену). Домен угону: зловмисник заволодіє домен вже зареєстрований на іншій стороні, використовуючи атаки, такі як соціальна інженерія, злом серверів DNS або DNS-кешу. Псування: зловмисник зламує сервер, на якому сайт в домені, і замінює вміст головної сторінки з його / її власну версію. Отруєння веб-кеша: зловмисник може розмістити отруєння версії головної сторінки www.vuln.site в різних веб-серверів кеш (див. [1] і [3]). Атака план Напад досить проста: зловмисник, після отримання контролю над областю, привертає більше клієнтів, щоб перейти до шкідливої сторінки (http://www.vuln.site/). Ця сторінка буде обслуговувати зловмисник таким чином, що вона буде зберігатися в кеші для якомога довше клієнтами (браузери, можливо, також проксі-сервери, через які клієнти веб-серфінгу, можливо, і будь зворотний проксі-сервер використовується на сайті, будь прямий проксі, що зловмисник має доступ, і, звичайно, будь кеш-сервер зловмисника отрут в цілях реалізації атаки). Кешування управляється за допомогою або явні заголовки HTTP, HTML або мета-тег віртуальних HTTP заголовків. У будь-якому випадку, в тому числі такі заголовки б зробити дані Кешована протягом тривалого часу: Cache-Control: громадськість Щоб проілюструвати, що може бути зроблено, розглянемо просту HTML сторінку, яка завантажує Java-коду з сервера атакуючого: <html> Поки домен/сервер залишається в руках зловмисника, сценарій змісту, http://www.evil.site/attack.js, може бути бездіяльним (нічого не робити), або навіть тонше, наприклад, перенаправити жертву на інший сайт, наприклад, справжнім Один належав тій же організації, що є (або буде) власника vuln.site. Після vuln.site передається його законному власникові, зловмисник може перемикати http://www.evil.site/attack.js для виконання шкідливих дій, про що буде сказано нижче. Численні опції Як тільки хакер має кешовані сторінки в vuln.site області в браузері жертви (або проксі-сервер), який, імовірно, буде першої сторінки завантажуються жертву, зловмисник може встановити кілька атак: - Інформація/крадіжки облікових даних Зловмисник може записати куки, що жертва має в області vuln.site (точніше, ті, доступні для області, в якій проживає шкідливі сторінки). Таким чином, кожен раз, коли жертва завантажує в кеш сторінки, скрипт атакуючого буде збирати печиво, відправити їх в www.evil.site, і перенаправити жертву http://www.vuln.site/?random_string_here. Це буде гарантувати, що жертва відразу ж отримаєте головній сторінці, як передбачалося бути винесено, від www.vuln.site сервера. Крім того, це можливість для зловмисника, щоб зберегти невеликий / невидиме вікно, в той час як перенаправлення головного вікна http://www.vuln.site/?random_string_here. Потім, зловмисник може збирати печиво і зчитувати дані сторінки (від www.vuln.site тільки) протягом сесії жертви. - Оточення печиво і фіксація сесії атаки Сценарій може встановити постійні куки, які закінчуються в далекому майбутньому. Це дозволяє деяким формам атак через кукі, а також напади фіксації сесії [4]. Цікава ідея полягає у встановленні постійних печиво з випадковим ім'ям (встановлюється на стороні браузера) - це буде дуже важко видалити це печиво (якщо браузер отримує вказівку видалити всі куки). Якщо сервер намагається прочитати або розібрати всі тимчасові файли, такі печива отрута може вступити в гру. Слід зазначити, що такого роду атаки (установка печиво) можна навіть у слабких атак, таких як хрест скриптінг і маніпуляції заголовок відповіді за допомогою CRLF ін'єкції. - Man-In-The-Middle Зловмисник може завантажити оригінальний контент від реальних веб-сайт (www.vuln.site) всередині кадру, зміни HTML сторінки, перш ніж вона надається, і, таким чином реалізувати людина-в-середині атаки (шкідливий код Javascript та шкідливу сторінку кеш служить людина-в-середині в даному випадку). Зверніть увагу, що за допомогою об'єкта XMLHttpRequest, зловмисник може заволодіти сировини HTML даних, перш ніж воно відображається в браузері - це робить деякі захисні механізми марні. Атака довголіття Атака "живе" в різних сховищах кеша. Таким чином, кожна спроба кеш оператор перепровірити отруєння кеша (шляхом відправки запиту умовний) може поставити під загрозу нападу (для даного сховища кеша). Деякі проксі-серверів кеш може перевірити ще свіжі записи кеша час від часу. Крім того, документація Microsoft за замовчуванням параметрів кеша в Microsoft Internet Explorer («Перевірка оновлень збережених сторінок" встановлений на "Автоматично") є несумісним щодо того, кешовані ресурси перевіряються (за допомогою умовного запиту, використовуючи If-Modified-Since і / або If-None-Match). Згідно [5], не така перевірка відбувається на свіжі записи кеша, навіть якщо довгий час минув. Згідно [6], перевірка може відбутися для HTML ресурси, якщо більше доби пройшло з моменту їх останньої завантаженої / підтверджено. Експерименти автор схильний погодитися з [5], тобто MSIE зазвичай не перевіряють кешованих ресурсів (принаймні, не тоді, коли закінчується заголовка здійснюється з дати встановлений в далекому майбутньому), і використовувати його безпосередньо з кешу, хоча випадкові перевірки запитів не спостерігалося (рідко). Крім того, браузер, користувач може викликати активне кеш переатестації, наприклад, натисненням кнопки Refresh. Нарешті, браузер, користувач може налаштувати браузер на повторну перевірку кешованих сторінок на кожній сесії браузера або на кожному використанні (див. [6]). Тому, в інтересах зловмисника не включати ETag заголовок відповіді з отруєними сторінки, і встановити дату останньої зміни в дату в далекому майбутньому (як у прикладі вище). Це призведе до того браузера, щоб відправити переатестації запити тільки з "If-Modified-Since" (не "If-None-Match"), а якщо фактичний ресурс має дату модифікації раніше, ніж той, що надаються браузером (який є нормальний сценарій), веб-сервер буде відповідати "304" статус відповіді («немодифікованих»), таким чином, доручивши браузер для подальшого зберегти отруєння сторінку. Однак, якщо зловмисник воліє стелс-ності, то відповідь слід скопіювати Last-Modified і / або ETag значення справжні сторінки, якщо такої сторінки не існує. Звичайно, браузер, користувач може просто стерти всі кеш безпосередньо (сучасні браузери дозволяють це в один клік), або побічно (Microsoft Internet Explorer має можливість стерти кеш при виході з браузера - ця опція під назвою "Empty Temporary Internet Files Папка при закритті браузера "включена за замовчуванням для Windows/2003. див. [7]). У такому випадку атаки на цей браузер буде скасовано з моменту кеш був видалений. Попередня атака оборона
* Якщо можливо, використовуйте тільки SSL (HTTPS тільки) доступ до веб-сайту. SSL зриває ці атаки, в якій зловмисник не має доступу (пряме чи непряме) на дійсний сертифікат SSL для хоста / домену. Таким чином, DNS угон та отруєння кеша покриті, в той час як класичні псування раніше є проблемою, і, можливо, кібер-на корточках теж (якщо зловмисник виданий дійсний сертифікат). * Тільки у випадку, якщо проксі-сервер і / або клієнти іноді намагаються перевірити отруєння сторінку, це було б гарною ідеєю, щоб ніколи не відповість статусу HTTP 304, тобто сила статусу HTTP 200, на кожній сторінці точкою входу в домен. Також має сенс стежити за значеннями останньої модифікації і ETag за умови (через If-Modified-Since і If-None-Match відповідно), і якщо вони не збігаються зі значеннями, історично передбачені для цього ресурсу, це може свідчити про напад в ході . Для деяких популярних веб-серверів, є готові об'єкти, щоб змусити сервер ігнорувати If-Modified-Since заголовка запиту HTTP. Цитата з [2] (при щедрою дозволу його автора, Митя Kolsek): Інтернет-послуги Інформація [Пам'ятайте завжди переглянути вихідний код перед використанням!] Apache 1.3 HeaderModify на mod_header_modify модуля можна завантажити з Apache 2.0 RequestHeader встановлена If-Modified-Since Рекомендується лікувати If-None-Match HTTP заголовка запиту в тому ж порядку. Після атаки оборона - активний підхід
Припущення в цьому розділі є те, що законним власником домену відомо, що такий напад відбувається або до області буде відновлено, або незабаром після цього. Крім того, власник сайту може зв'язатися з усіма (або переважна більшість) клієнтів, наприклад, по електронній пошті. Власник сайту необхідно відправити по електронній пошті клієнтам, наставляючи їх, щоб натиснути на посилання. Це посилання буде на сторінці недоторканим атакуючого (поки на тому ж хості), який буде обновити URL, що зловмисник використовував (див. вище). Власник сайту може використовувати XmlHttpRequest (через Javascript), щоб змусити освіжає як самого браузера і проксі-кеш сервера. Це можна зробити за допомогою коду (у http://www.vuln.site/new_page.html), такі як цей (за умови, Microsoft Internet Explorer, протестований з MSIE 6.0 SP2): <html>
Перший заголовок, If-None-Match (з випадковою рядком) гарантує, що браузер не завантажувати дані з власного кешу, а, скоріше, насправді намагатися витягти дані. Два кеша заголовки (Pragma і Cache-Control) буде недійсною будь-яку кешовану запис в кеш-сервера (принаймні ті, досліджені в [1]). Інший варіант, поступається вище, є використання заголовків HTTP Refresh. У цьому випадку відповідь сервера для http://www.vuln.site/new_page.html повинна включати наступні відповіді HTTP заголовок: Refresh: 0; URL = http://www.vuln.site/ У заголовку Оновити змушує браузер, щоб оновити свій кеш з сервера. Сервер (www.vuln.site) повинні бути налаштовані на повернення законним копію http://www.vuln.site/ безумовно (тобто, щоб ніколи не повернутися HTTP 304 код відповіді на цей ресурс). Microsoft Internet Explorer, наприклад, навіть видає "Pragma: No-кеша" HTTP заголовка запиту, разом із заявою (перевірено з MSIE 6.0 SP2). Це може видалити кешовані записи з кешу деяких серверах. Крім того, лист може закликати користувачеві вручну стерти кеш браузера. Після атаки оборона - пасивний підхід Припущення в цьому розділі є те, що законним власником домену відомо, що такий напад відбувається або до області буде відновлено, або незабаром після цього. Тим не менш, власник сайту не може зв'язатися з клієнтами безпосередньо, а повинні чекати їх для перегляду на сайті. У цьому випадку гарна ідея, щоб закрити будь-які зовнішні веб-сайт, що шкідливий кешовані завантаженні сторінки даних / сценарій (в наведеному вище прикладі, www.evil.site). Це спрощує аналіз проблеми. Однак, це не завжди практично, і навіть так, деякі форми атаки можуть бути самодостатніми і не вимагає зовнішніх сайтів. Зараз є дві проблеми, які повинні бути оброблені: Зауважимо, однак, що якщо шкідливий сторінка не завантажується цільова сторінка (http://www.vuln.site/?random_string_here) безпосередньо, а, скоріше, використовує XmlHttpRequest дістати інформацію на сторінці, то ці методи марні ( в тому числі трюк Refresh), так як браузер (принаймні в Microsoft Internet Explorer), в цьому випадку ігнорує заголовок Refresh і забезпечує сторінку в XmlHttpResponse об'єкт як є. Звичайно, якщо шкідливі сторінки читає Javascript-код (або дані, які можуть вплинути на код потоку) з зовнішнього сайту, такі як http://www.evil.site/attack.js, і цього сайту не може бути зупинений, то це в кішки-мишки між законним власником сайту і зловмисник - у відповідь на згадану вище техніку, зловмисник може змінити сторінку, на якій в кеші перенаправлення сторінок, і так далі. Зловмисник може насправді доручити сторінки, щоб не завантажувати будь-яку сторінку з реального сайту. Саме тому важливо проаналізувати атаки і забезпечити, щоб будь-які сайти / ресурси, які він читає дані з спочатку закрили (це може бути непрактичним в разі, якщо зловмисник проходить через біль від спілкування з blog-site/forum / ... наприклад, за допомогою ток-спини і коментарі). Після атаки оборона - загальний метод
Якщо напад відбувається залучити (або містити виключно) отруєної сторінок, які не є точками входу, тобто, сторінки, які доступні через потік, який включає в себе справжні сторінки з веб-сайту, то потік може бути легко модифікований, щоб обійти використання точні адреси отруєних сторінок. Наприклад, якщо сайт має http://www.vuln.site/ відразу перенаправлення браузера на http://www.vuln.site/app/index.html, і якщо тільки остання сторінка отруєний, то власник ділянки необхідно просто змінити переадресацію, скажімо, http://www.vuln.site/app/index.html?foo=random_string_here. Крім того, власник може змінити / кв папку в щось подібне / app_random_string_here, і перенаправити на http://www.vuln.site/app_random_string_here / index.html тих пір, поки ці зміни не можуть бути передбачені зловмисник (і, отже використання випадкова рядок), цей захист метод повинен бути простим у реалізації. Після атаки оборона - турбота про Cookies Після того, як шкідливі сторінки будуть видалені з кешу браузера, куки, які були встановлені шкідливі сторінки (якщо такі печива були встановлені) повинні бути вилучені. Будь куки, встановлені шкідливі сторінки в ідеалі повинні бути негайно вилучені (це може бути зроблено на рівні HTTP або на рівні Javascript, з будь-якої сторінки на тому ж каталозі з шкідливою сторінки). Якщо список не відомий, то принаймні набір печива в використовуваної області повинні бути перевірені ретельно яку сторінку, перш ніж використовувати, і бажано бути скинуті у відомій безпечної конфігурації. Іншим варіантом є запропонує користувачеві видалити всі куки (це може бути частиною електронної пошти мови, див. вище). Думки про Типові рішення Це може бути гарною ідеєю, щоб ввести одне або декілька з наступних способів на сервер-кеш браузера світі: Резюме По суті, рецензія показує, що порчу, область захоплення, отруєння кеша і кібер-на корточках, всі вони мають довгостроковий ефект, який може простягатися далеко за веб-сайт буде відновлений. Ця концепція може бути позначена як "домен забруднення». Основною причиною є той факт, що домен стороні клієнта модель безпеки використовує підхід «все або нічого» - якщо ресурс надходить з цільового домену, це сліпо і повністю довіряв (як належать до домену, і мають можливість доступу і встановити інші ресурси домену) - назавжди, і без простий механізм відкликання. Складні зловмисник може використовувати цей пролом для установки різних атак (таких як Cross Site Scripting, фіксація сесії, повноваження злам, і т.д.) щодо користувачів сайту чиї браузер / проксі-сервера впливає. Захист від цієї техніки не є тривіальним, і може залежати від складності атаки, а також про те, постраждалих клієнтів можуть бути передані з, і чи є вони кооперативних достатньо. Посилання [1] "Розділяй і володарюй - HTTP Response Splitting, веб-атак отруєння кеша та інші теми", Amit Klein, 4 березня 2004 http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf [2] "ASPR # 2004-10-13-1: отруєння кеша документів HTTPS в Internet Explorer", Митя Kolsek (Acros Security), 13 жовтня 2004 http://www.acrossecurity.com/aspr/ASPR-2004- 10-13-1-PUB.txt [3] "HTTP запиту Контрабанда», Хаїм Linhart, Amit Klein, Ронен Heled, Стів Оррін, 6 червня 2005 http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf [4] "Фіксація сесії вразливостей у веб-додатках», Митя Kolsek (Acros Security), 18 грудня 2002 http://www.acrossecurity.com/papers/session_fixation.pdf [5] «Скрипаль PowerToy - Частина 2: HTTP Performance" (підрозділ "Умовні заявки і Кеш WinInet"), Ерік Лоуренс (Microsoft Corporation), червень [6] "Як налаштуваннях інтернет провідника кеша впливає на перегляд веб-сторінок» (підрозділ «Опис Cache Settings"), Microsoft у статті бази знань 263070 http://support.microsoft.com/default.aspx?scid=kb; електронної н-нам, 263070 # XSLTH3125121122120121120120 [7] "Конфігурація посиленої безпеки для Internet Explorer" (підрозділ "Advanced Settings"), Microsoft MSDN Про автора Amit Klein є відомий веб-додатків, дослідник безпеки. Г-н Кляйн написав багато наукових робіт за різними технологіями веб-додатків - від HTTP до XML, SOAP і веб-сервісів - і охоплює багато тем -. HTTP запиту контрабанди, небезпечно індексації, сліпий XPath ін'єкції, HTTP Response Splitting, забезпечення NET веб-додатків, хрест скриптінг, печиво отруєння і багато іншого. Його роботи були опубліковані в журналі доктора Добі, SC Magazine, журнал ISSA і ІТ-аудиту журналу, були представлені на SANS і CERT конференцій, а також використовуються і посилається в багатьох академічних навчальних програм. Г-н Кляйн є WASC (Web Application Security Consortium) офіцера. поточної копії цього документа можна знайти тут: http://www.webappsec.org/articles/ Інформація за статтею безпеки веб-додатків консорціуму правила можна знайти тут: http://www.webappsec.org/projects/articles/guidelines.shtml копії ліцензії для даного документа можна знайти тут: http://www.webappsec.org/projects/articles/license.shtml
Перекладено з http://www.webappsec.org/projects/articles/020606.shtml |
|
© 2012 Все права под надежной защитой.
|
НАШ БЛОГ
|
|