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

Нещодавно, 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 (деталі)

14.09.2006

Сьогодні встановив плагін Subscribe to Comments для WordPress і знайшов в ньому декілька уразливостей.

Це Cross-Site Scripting уразливості в Subscribe To Comments 2.0.4 WordPress plugin (в wp-subscription-manager.php та subscribe-to-comments.php).

Про дані уразливості я напишу додаткову інформацію після того як повідомлю розробників плагінів і розробників движка WordPress.

До речі, я вже раніше писав про уразливість в одному Wordpress плагіні - уразливість в Wordpress WP-DB Backup Plugin.

16.09.2006

Уразливість в плагіні Subscribe To Comments 2.0.4 (в wp-subscription-manager.php та subscribe-to-comments.php).

XSS:

Уразливість в параметрах ref та email в скриптах wp-subscription-manager.php та subscribe-to-comments.php.

http://host/blog_path/wp-subscription-manager.php?ref=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
http://host/blog_path/wp-admin/edit.php?page=subscribe-to-comments.php&ref=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
http://host/blog_path/wp-subscription-manager.php?email=%3Cscript%3Ealert(document.cookie)%3C/script%3E
http://host/blog_path/wp-admin/edit.php?page=subscribe-to-comments.php&email=%3Cscript%3Ealert(document.cookie)%3C/script%3E

В мене на сайті ці уразливості вже виправлені . Це я зробив одразу як знайшов їх.

P.S.

До речі, як щойно повідомив мені розробник плагіна, він найближчим часом випустить нову версію плагіна Subscribe To Comments 2.0.8, з виправленням даних уразливостей.

Зі своєї сторони я планую випустити Subscribe To Comments 2.0.5 MustLive Edition. Де будуть виправлені дані уразливості, а також опишу методику виправлення уразливостей (необхідний php код). Це все планується в рамках нової версії мого Security Pack.

Щойно встановив плагін Subscribe to Comments - для підписки на коментарі.

Раніше відвідувачі сайту могли лише підписатися на коментарі за допомогою загальної Стрічки коментарів (RSS), а також на персональні стрічки до кожного повідомлення (наприклад, Стрічка коментарів повідомлення “Добірка уразливостей”). І все. Тепер же, відвідувачі можуть підписуватися на коментарі до потрібних їм повідомлень, під час відправки коментарю (для цього є відповідний чекбокс). Цією роботою і займається плагін Subscribe to Comments.

Так що удачних підписок

До речі, з цим плагіном пов’язані деякі курйози (я знайшов в ньому ряд уразливостей). З приводу чого я висловлюсь в наступному повідомленні.

Чимала частина власників сайтів, яким я повідомляю про уразливості на їх веб сайтах, та взагалі велика частина усіх власників сайтів, в наш час мало обізнані стосовно такої проблеми як Cross Site Scripting. І навіть якщо чули про наявність даної загрози і зокрема про наявність XSS на власному сайті (по інформації від мене), дані власники сайтів не переймаються цією проблемою - або не виправляють уразливості зовсім, або виправляють неякісно, або відповідають, що мовляв це не серйозна проблема і вони не бачать ніяких ризиків пов’язаних з даними уразливостями (і що адмінів навряд чи похакають, а стосовно юзерів їх сайтів їм байдуже).

Причому подібне відношення до уразливостей (і зокрема до XSS) існує давно - нагадаю, що Cross Site Scripting уразливості як окремий напрямок веб безпеки існує вже багато років (з 2000 року). І кількість похаканих сайтів щоденно зростає, але їх власники так і не почали замислюватися над проблемами безпеки своїх веб сайтів. В результаті своєї дослідницької діяльності стосовно уразливостей, я регулярно стикаюся з подібним відношенням власників до своїх сайтів, до їх безпеки і до XSS уразливостей.

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

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

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

P.S.

Вже в 2010 році я створив програму DDoS attacks via other sites execution tool (DAVOSET) для використання сайтів зомбі. DAVOSET - це інструмент для використання Abuse of Functionality та XML External Entities уразливостей на одних сайтах, для проведення DoS і DDoS атак на інші сайти.