Websecurity - Веб безпека

Вчора до мене звернулися з проханням протестувати сайт Верховної Ради України (ВРУ) на уразливості (сайт http://portal.rada.gov.ua та зокрема http://zakon.rada.gov.ua). І як показав мій попередній секюріті аудит, результати невтішні і сайт Верховної Ради уразливий. В даному випадку я знайшов декілька Cross-Site Scripting уразливостей. Про що попередньо вже повідомив адміністрацію веб сайту, і зараз підготую детальний звіт.

Я регулярно провожу аудит безпеки різноманітних сайтів, як своїх власних, так і сайтів своїх партнерів, і тих сайтів, які мені на очі потрапляють. Ну а також іноді провожу аудит веб сайтів, веб додатків та веб систем на замовлення. Але до цього часу державний сектор вебу (gov) не залучав мою увагу (окрім випадку з сайтом Агентства Національної Безпеки США Cross-Site Scripting уразливість на www.nsa.gov, але в даному випадку це секюріті сайт, і звернув увагу саме через тематику сайту). І ось я оглянув один наш gov сайт - веб сайт Верховної Ради. Найвищого законодавчого органу держави - і тому сайт повинен бути взірцем безпеки.

Але результати невтішні - на сайті мають місце уразливості (і це був лише попередній огляд). Можна представити загальний стан серед державних gov сайтів в Україні (як мінімум, а то і по всьому світі можна екстраполювати). І цю ситуацію потрібно змінювати. Сайту Верховної Ради та іншим сайтам державних органів потрібно приділяти увагу безпеці та секюріті-аудиту. Я зі своєї сторони надам необхідні консультації, головне щоб уразливості оперативно виправляли і слідкували за безпекою.

В свої новинах я неодноразово згадував про пошукові системи і про уразливості в них. Особливо ця проблема стосується популярних пошукових систем та порталів, з численними веб проектами (як пошуковцями, так й іншими веб сервісами).

Зокрема згадував наступні випадки: Уразливість на lib.meta.ua, Уразливості на meta.ua, Cross-Site Scripting на Яндексі, Нові уразливості на Yandex, Cross-Site Scripting на Рамблері, Нова уразливість на Рамблер, Нова XSS уразливість на Рамблері, Уразливість на go.km.ru, XSS уразливість в Гуглі, XSS та CSRF уразливості в Google.

Як видно з моїх повідомлень наявність уразливостей - це поширене явище в багатьох пошуковцях і порталах. Я вже не кажу про пошукові скрипти на сайтах - там це теж поширене явище (і я регулярно пишу про це в новинах). Взагалі уразиливості в пошукових скриптах, як на сайтах, так і в веб сервісах пошуковців - це один з напрямків, де уразливості найбільш поширені.

Власникам та розробникам пошукових систем, особливо популярних пошувців і порталів, слід приділяти більше уваги безпеці власних веб систем.

До теми уразливостей в пошукових системах я ще буду регулярно звертатися. В мене вже чекає нова інформація про уразливості в пошуковцях. Як серед раніше згадуваних систем, так і нових.

Розповім вам про ще одні уразливості в Гуглі. В минулому місяці я вже писав про XSS уразливість в Гуглі, а зараж продовжу тему уразливостей на сайтах Гугла. Це відома в світі компанія та найпопулярнійший пошуковець, тому й зрозуміла увага, яку приділяють до сайтів Гугла дослідники. І тому сам Гугл повинен серйозно слідкувати за безпекою власних сайтів.

В цьому році в Google було знайдено чимало різноманітних уразливостей. Окрім вже згадуваного мною XSS в Гуглі, в своєму запису Cross Site Scripting Vulnerability in Google (датованого липнем цього року) RSnake повідомляє про нові уразливості в Гуглі (частина з яких вже виправлена). Зокрема про XSS та CSRF. А також про ще один редиректор (я вже писав про попередній редиректор в записі Фішинг за допомогою Yahoo та Google).

До редиректорів я ще поверусь окремо, в інших моїх дослідженнях, а зараз розглянемо XSS та CSRF уразливості.

XSS була знайдена в інструменті додавання RSS feed (в налаштуваннях Персональної сторінки Гугла). Зараз ця уразливість вже виправлена, але ви можете глянути на скріншот на сайті RSnake.

CSRF (Cross Site Request Forgery) була знайдена в інших персоналізованих налаштуваннях Гугла, що дозволяє довільному (зловмисному) сайту змінити дефолтну локацію пошуку по мапам.

В цьому році Гугл все частіше з’являється в новинах - з повідомленням про нові уразливості на їхніх сайтах. Інші пошуковці, до речі, теж не виключення.

Нещодавно, 02.10.2006, секюріті експерти виявили серьйозну помилку в Internet Explorer, яка дозволяє викоконувати міжсайтовий скриптінг з використанням UTF-7 символів в URL запиту.

Причому спочатку один дослідник виявив дану уразливість на Майкрософтовському сервері IIS, яка проявляє себе в IE (в якому встановлена автодетекція кодування сторінки), і дана уразливість може бути використана як універсальна уразливість проти користувачів IE та веб сайтів на IIS серверах. Але майже одразу після появи повідомлення про цей випадок, інший дослідник виявив подібну уразливість на серверах Apache при використанні IE та UTF-7 символів в URL. Що теж може бути використано як універсальна уразливість проти користувачів IE та веб сайтів на серверах Apache (при умові ввімкненої автодетекції кодування сторінки).

Суть нападу зводиться до задання неіснуючої сторінки, і при цьому веб сервери IIS і Apache виводять інформацію, що вона не існує і при наявності UTF-7 символів дозволяють провести XSS атаку.

Сам я проводив дослідження і в мене Internet Explorer ніяк не проявив в даній уразливості (ні на серверах Апач, ні на IIS). Схоже що в мене IE взагалі не підтримує дане кодування (його немає в виборі кодувань), на відміну від Mozilla (де вибір такого кодування є, але сама Mozilla не вразлива).

Як повідомляє RSnake в себе на сайті в записі UTF-7 Strikes 404 Pages In Internet Explorer, проблема подібна має місце, як він перевірив, і про подібного роду уразливості в IE він вже знав раніше. І не зважаючи на різні обмеження, даний напрямок атаки може бути віднесеним до універсальних XSS атак. Але пізніше в коментарях до запису було повідомлено, що дана уразливість зустрічається епізодично, не на всіх серверах Apache. Та й сам автор повідомлення про уразливість в Apache + IE, підтвердив, що поспішив, і в дефолтній конфігурації Апач (особливо останні версії) не вразливий до даної атаки. Але ще зашишаються IIS сервера (та й рідкі випадки на деяких версіях Apache).

• Microsoft Internet Information Services UTF-7 XSS Vulnerability [MS06-053] (деталі)
• IE UXSS (Universal XSS in IE, was Re: Microsoft Internet Information Services UTF-7 XSS Vulnerability [MS06-053]) (деталі)

Як повідомляє www.cgisecurity.com, нещодавно розгорілася дискусія з приводу XSS уразливостей на сайтах секюріти компаній (і до цього я дізнався про цю новину на сайті ha.ckers.org, на форумі якого й почалася дискусія з цього приводу).

Компанії F5 та Acunetix незалежно одна від одної знайшли XSS уразливості на сайті свого конкурента. І після того як були зроблені відповідні заяви зі сторони кожної з них, компанії почали заперечувати наявність уразливостей на їх сайтах . Осиболиво це почала робити Acunetix - мовляв ми ж секюріті компанія, які ж у нас можуть бути уразливості, ми ж сканер безпеки випускаємо і скануємо ним всі власні сайті (і з цього ж можна зробити висновок про якість їхнього сканера).

Якщо F5 не сильно відрікалася, сказала лише що це була не повноцінна XSS, а лише html ін’єкція (що заперечують ті хто бачив в роботі цю уразливість), і вони вже її пофіксили, то Acunetix взагалі заперечує що будь-які уразливості мали місце. Після цього користувачі сайта ha.ckers.org (зокрема його форума - sla.ckers.org/forum/) знайши чимало уразливостей на сайтах цих компаній, в тому числі надали скріншоти, щоб ті не росказували, що дір не було (після того як пофіксять).

Одним словом дискусія з приводу XSS на сайтах секюріти компаній розгорілася серйозна.

Головний висновок, який повинні зробиити компанії, які працюїть в області безпеки (та й взагалі всі фізичні та юридичні особи в цій обласі), це те, що у випадку, коли були знайдені і розголошені уразливості на їх сайтах, то не треба це заперечувати, треба лише підвердити, пофіксити і рухатися далі.

Я до речі також згадував про випадки уразливостей на сайтах секюріти компаній (в записі Безпека сайтів про безпеку) і планую регулярно згадувати про подібні випадки.

Сьогодні вийшла нова версія програми Perl Pas Interpreter v.1.2.7. В новій версії:

• Додана кнопка очищення поля текста програми (в онлайн інтерпретаторі).
• Додана функція delete.
• Додана функція insert.
• Покращена робота read та readln з масивами (з індексом-змінною).

Деталі на сайті інтерпретатора. Тема для обговорення програми на форумі.

Додаткова інформація про Perl Pas Interpreter в розділі Онлайн інструменти.

В цьому році активність пошуку уразливостей в веб додатках (і написання експлоітів) зросла. В порівнянні з минулим роком. Та й у другій половини цього року, порівняно з першиим півріччям, відчутно збільшилася активність в даній сфері.

Це особливо примітно на аналізі типів експлоітів від проекту milw0rm.com (на якому з’являються нові й різноманітні експоіти). Так, в другому півріччі поточного року, кількість експоітів веб типу значно зросла. А в серпні, і особливо в вересні, на сайті milw0rm з’являються в основному web apps експоіти (переважна частина) - зараз це стала сама популярна тема. І кількість експоітів зростає швидкими темпами (як і кількість самих веб додатків). Причому досліджувати там є ще багато чого (з одних лише існуючих веб додатків, окрім нових, які регулярно з’являються, та й нові версії існуючих веб додатків додають нових уразливостей), тому кількість експоітів буде тільки зростати. А виробникам веб додатків потрібно ще більше приділяти увагу безпеці своїх програмних продуктів.

Зараз активність хакерів доволі висока. Як раз в липні я розпочав роботу даного веб проекту, і просто не встигаю публікувати інформацію як про експоліти (в записах “Добірка експлоітів”), так і про уразливості в веб додатках і системах (в записах “Добірка уразливостей”).

До цього я слідкував (з 2005) за потоками інформації про нові експоліти та уразливості, і раніше активність в цьому намрямку була значно меншою. За рік ситуація кардинально змінилася - і пошук уразливостей в веб додатках (ну і написання експоітів) став поширеним явищем. Я до речі теж займаюся пошуком уразливостей в веб додатках і системах , тому також вношу свою лепту в хакерську активність.

Вчора звечора на сайті заглючило UTF кодування, із-за глюків БД, які недоречно себе проявили (MySQL переглючило, що в свою чергу призвело то дого, що WordPress сильно переглючило). В результаті інформація на сайті відображалася не коректно.

Це могло бути пов’язано з деякими роботами адміністрації хостінга на сервері (над БД). Що привело до некоректної роботи сайта. Поки ще не отримав інформації від адміністрації, що саме відбулося вчора ввечері з MySQL.

Вночі проблему вирішити не вдалося, так як переглючило БД і движок сильно. Вже після обіду, як добрався до свого сайту, вирішив проблему остаточно (хитрими хакерськими методами ) і тепер інформація відображається коректно. Даний інцидент можна віднести до особливостей роботи движка (зокрема роботи WordPress з БД).

Робота проекту продовжується у звичному режимі.

Я вже згадував раніше про сайт ha.ckers.org - безпека веб додатків. Автор сайту, RSnake, в своїй статті Why XSS is Here to Stay описує основні причини, чому Cross-Site Scripting уразливості мають і будуть мати місце. І в цьому питанні я з ним погоджуюсь.

Основні причини поширення XSS:

• Аналітичні сервіси - щоб вирішити кардинально проблему XSS, потрібно відмивитися від включення віддалених скриптів (на JavaScript), але на це не підуть компанії, які надають, наприклад, аналітичні сервісі - ті ж рахівники різного гатунку (а з минулого року цим почала займатися Google). Я вже не кажу про повну відмову від JavaScript - ніхто на це не піде (хоча це вирішить багато проблем з безпекою), бо всі до нього звикли і дуже багато сервісів на ньому базується.
• Контекстна та банерна реклама - системи контекстної та здебільшого й банерної реклами базуються саме на JavaScript коді, розміщеному на сторінках веб сайтів (прочитайте мою замітку Хакінг сайту через уразливості в коді зовнішніх систем). Дуже багато людей зайняті в цій сфері, як самих компаній, так і власників сайтів - тому ніхто від цього не захоче відмовитися. Зокрема тому, що в цій сфері обертаються гроші (які заробляють як власники рекламних систем, так і власники сайтів).
• AJAX - він базується на віддалених запитах JavaScript, тому нічого вдіяти тут не вийде, якщо ми хочемо AJAX, який є основою Web 2.0, ми повині миритися з його недоліками (і в тому числі з можливістю XSS). Інакше, ми залишимося веб самого AJAX-а, і повернемося до Веб 1.0 (та й багато компаній задіяні зараз в ajax напрямку, які не захочуть від своїх планів відмовитися).
• Akamai - це система кешування відвідуємих веб сайтів, яка вимагає наявність JavaScript в браузері користувача (з відповідними наслідками).
• Завантаження сторінок і SEO - з точки зору швидкості завантаження сторінок, яка зменшується від наявності JS-коду на сторінках сайтів, а також з точки зору релевантності сторінки для пошукових систем (SEO), та й з точки зору трафіка, то з цих причин власники сайтів намагаються розміщати віддалени скрипти (різноманітних систем), і тому даний функціонал вкрай потрібен для власників сайтів.

З наведених причин (лише деяких з усіх можливих) ви можете побачити, що кардинально змінити ситуацію (в браузерах), як мінімум заборонити віддалені запити в JavaScript, не має можливості - тому що велика кількість різноманітних компаній (як великих, так і малих) та й самих інтернет користувачів, аж ніяк не забажає відмовитися від даного функціоналу, який дарує як зручності, так і наражає на небезпеку.

Тому єдиним засобом на сьогодні для боротьби з XSS є пошук і виправлення уразливостей З приводу пошуку уразливостей (і рекомендацій щодо їх виправлення) можна звертатися до мене.

Нещодавно була знайдена чергова уразливість в MS Internet Explorer - переповнення буфера в IE (Internet Explorer COM Object Heap Overflow).

Як повідомляє дослідник цієї уразливості, вона спрацьовує на Windows 2000 Server SP4 з Internet Explorer 6.0 SP1 та Windows XP SP2 з Internet Explorer 6.0 SP1.

Як я протестував на своїй Windows XP Pro SP2 + Internet Explorer 6.0 SP1 - уразливість працює. Причому помилка в IE серйозна, окрім DoS також можливе виконання довільного коду і навіть більше, можливе завантаження з віддаленого хоста та запуск довільної програми.

На основі інформації про дану уразливість, я розробив свій невеличкий, але досить цікавий експлоіт .

Test Internet Explorer (тестувати потрібно лише в IE).

У експлоїта є деякі нюанси, що він може не кожного разу спрацювати - це особливість роботи прикладу коду наведеного автором, що експлоіт може заглючити і не спрацювати (на Windows XP SP2 з IE 6.0 SP1). Тому потрібно спробувати декілька разів, якщо у вас з першого разу не вийшло. Коли мій експлоіт вас похакає, ви про це дізнаєтесь

Можете ознайомитися з прикладом використання уразливості від автора:

• Internet Explorer COM Object Heap Overflow Download Exec Exploit (деталі)