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

Раніше я зробив антологію атак через редиректори (відкриті та закриті) в своїх статтях Редиректори: прихована загроза та Атаки через закриті редиректори. А в даній статті я зроблю антологію атак через капчі.

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

Атаки через капчі.

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

• Обіх капч.
• Redirector атаки.
• Cross-Site Scripting атаки.
• SQL Injection атаки.
• CSRF атаки.
• Витоки інформації.
• Denial of Service атаки.

Обіх капч.

В капчах бувають численні Insufficient Anti-automation уразливості, що дозволяють обходити капчі для відправки автоматизованих запитів. Про що я детально розповів в своєму проекті Month of Bugs in Captchas.

Redirector атаки.

В капчі Google є Redirector уразливість, що дозволяє перенаправляти відвідувачів на довільні сайти.

Cross-Site Scripting атаки.

В капчі для Nucleus та в плагінах Peter’s Random Anti-Spam Image, Math Comment Spam Protection, Captcha!, Cryptographp, WP-ContactForm та CapCC для WordPress є Cross-Site Scripting уразливості (reflected та persistent), що можуть використовуватися для XSS атак.

SQL Injection атаки.

В капчі для Nucleus та в плагіні CapCC для WordPress є SQL Injection уразливості, що можуть використовуватися для атак на сайти.

CSRF атаки.

В плагінах Captcha! та CapCC для WordPress є Cross-Site Request Forgery уразливості, що можуть використовуватися для CSRF-атак. В тому числі для експлуатації Insufficient Anti-automation (в обох капчах) та SQL Injection (в другій капчі) уразливостей.

Витоки інформації.

В капчі для Nucleus є Full path disclosure та SQL DB Structure Extraction уразливості, а в плагіні CapCC для WordPress є Full path disclosure уразливість. Які призводять до витоку інформації на сайті.

Denial of Service атаки.

Через капчі можуть бути проведені DoS атаки (через SQL Injection та Denial of Service уразливості в них). Про що я детально написав в своїй статті DoS атаки через капчі.

Висновки.

Замість захисту веб сайтів від автоматизованих запитів, капчі часто становлять загрозу безпеці веб сайтів та їх відвідувачів. Тому розробникам капч та власниках веб сайтів, що їх використовують, потрібно завжди перевірявіти безпеку своїх капч.

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

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

W-Agora

В W-Agora на деяких сторінках в мета-тегах виводиться версія системи (w-agora version 4.1.5).

Mantis

В Mantis (MantisBT) версію системи можна дізнатися в файлі http://site/doc/ChangeLog.

Coppermine Photo Gallery:

В CPG на кожній сторінці веб додатку виводиться його версія (Coppermine Photo Gallery v1.2.2b).

coWiki

В coWiki є декілька витоків інформації:

• На кожній сторінці в коментарі виводиться версія системи (coWiki 0.3.4).
• На кожній сторінці в мета-тезі виводиться версія системи (coWiki 0.3.4).
• На кожній сторінці виводиться версія системи (coWiki 0.3.4).

eNvolution

В eNvolution версію системи можна дізнатися в файлах /config/install_log.txt, /instalacja.txt, /instalar.txt, /install.txt, /installa.txt, /installdeu.txt, /installer.txt та /where_to_get_support.txt.

В своїй статті Хакінг веб сайтів, секюріті дослідження, оприлюднення та законодавство в частині “Оприлюднення уразливостей” я описав різні варіанти оприлюднення уразливостей. Так звані політики оприлюднення.

Політики оприлюднення уразливостей.

Існують наступні варіанти оприлюднення: responsible disclosure (відповідальне оприлюднення), full disclosure (повне оприлюднення) та advanced responsible disclosure (просунуте відповідальне оприлюднення). Є також цікава версія full disclosure (яку я використовую і з кожним роком я використовую її все більше) - responsible full disclosure. Це суміш перших двох типів оприлюднення.

В своїй діяльності я найчастіше використовую просунуте відповідальне оприлюднення уразливостей. Більш детально про різні політики оприлюднення ви можете прочитати у вищезгаданій статті, а зараз я детально розповім про просунуте відповідальне оприлюднення. Що я використовую при проведенні соціального секюріті аудиту, який є однією з задач мого веб проекту.

Політика просунутого відповідального оприлюднення.

Advanced responsible disclosure (просунуте відповідальне оприлюднення) - це моя версія оприлюднення, яка поєднує всі переваги responsible disclosure і full disclosure. Я створив її 18.07.2006, коли відкрив мій веб сайт. Концепція advanced responsible disclosure полягає в наступному:

1) Спочатку я роблю анонс на моєму веб сайті про уразливість на веб сайті (веб додатку) без деталей.
2) Потім я посилаю листа з деталями власнику веб сайта (розробнику веб додатка) і даю йому деякий час для виправлення.
3) Після закінчення часу, я оприлюднюю всі деталі уразливості в записі на моєму сайті (під анонсом).
4) Я завжди даю достатньо часу для виправлення, але якщо для розробника часу недостатньо і він просить про додатковий час, тоді я дам йому додатковий час, щоб дозволити йому виправити уразливість перед оприлюдненням.
5) Анонс та час для виправлення (перед оприлюдненням деталей) є стимулами для власників веб сайтів (розробників веб додатків) для виправлення дірок. Це головна причина, чому я створив даний тип оприлюднення.

Історія створення даної політики оприлюднення.

Після того як я почав працювати в сфері веб безпеки в 2005 і почав інформувати власників веб сайтів про дірки на їхніх сайтах, я виявив, що responsible disclosure не працює. В зв’язку з ігноруванням (чи не подякують і не виправлять, чи подякують, але не виправлять, бо їм байдуже) власниками веб сайтів. Вони не слідкують за безпекою їхніх сайтів і якщо ви скажете їм про дірки використовуючи відповідальне оприлюднення, вони продовжать робити те саме. На початку 2006 я бачив ту саму ситуацію і я вирішив, що потрібен інший метод оприлюднення (який буде використовувати сайт для розміщення публічних оприлюднень, щоб зробити стимули для власників сайтів виправляти дірки).

І після того як я відкрив мій сайт 18.07.2006, я почав використовувати цей новий метод оприлюднення уразливостей на веб сайтах та веб додатках. Ось так народився advanced responsible disclosure. І я назвав дану роботу по знаходженню уразливостей на веб сайтах та інформуванню їхніх адмінів як соціальний секюріті аудит.

Наскільки відповідальне оприлюднення працює.

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

Так що є сенс в advanced responsible disclosure і я рекомендую використовувати його при оприлюдненні дірок на веб сайтах та у веб додатках. І у випадку коли адмін веб сайту (розробник веб додатку) дуже ламерить, тоді responsible full disclosure може бути використаний, про який я розповідав раніше (або у випадку, якщо уразливість дуже маленька). Стандартний full disclosure краще використовувати тільки в рідких і тяжких випадках.

Продовжуючи розпочату традицію, після попереднього відео про підбір паролів до FTP, пропоную новий відео секюріті мануал. Цього разу відео про захоплення Linux-сервера через SQL Injection. Рекомендую подивитися всім хто цікавиться цією темою.

Rooting a linux box via MySQL Injection

В даному відео ролику демонструється використання SQL Injection уразливості на сайті, що використовує MySQL, для захоплення сервера на Linux. Раніше я вже наводив відео про захоплення сервера на Windows XP через SQL Injection, а в даному випадку атакується Linux-сервер.

Для цього на сервер через SQL ін’єкцію заливається аплоадер, через який заливається шел і експлоіт (для підняття прав на сервері до root). Після чого додається новий акаунт адміністратора в систему та через PuTTY під’єднується до сервера. Рекомендую подивитися дане відео для розуміння SQL Injection атак.

Капчі повинні захищати веб сайти від автоматизованих запитів. Але як я показав в своєму проекті Month of Bugs in Captchas, вони з цим погано справляються, через численні Insufficient Anti-automation уразливості, що дозволяють обходити капчі. Окрім цього, капчі можуть призвести до DoS атак на сайти.

DoS атаки через капчі можуть відбуватися через SQL Injection уразливості (що також дозволяють проводити DoS атаки) та Denial of Service уразливості. Капчі, як і будь-які веб додатки, можуть мати різні уразливості, зокрема SQL Injection та Denial of Service, що можуть призвести до DoS атак. І раніше я вже писав про подібні уразливості в капчі для Nucleus, CapCC для WordPress та CaptchaSecurityImages.

SQL Injection уразливості в капчах.

Існує капча для Nucleus. В даній капчі для Nucleus є Full path disclosure, SQL DB Structure Extraction, SQL Injection, Cross-Site Scripting та Insufficient Anti-automation уразливості. Зокрема через SQL Injection можна провести DoS атаку.

DoS (через SQL Injection):

В проекті MoBiC я розповідав як провести Insufficient Anti-automation атаку через дану SQL ін’єкцію. Для проведення DoS атаки замість раніше наведеного потрібно використати наступний код (чим більший benchmark, тим довше триває атака):

<input type="hidden" name="code" value="1" />
<input type="hidden" name="myid" value="-1 and benchmark(10000000,md5(now()))" />

CapCC - це капча плагін для WordPress. В плагіні CapCC є Insufficient Anti-automation, Cross-Site Request Forgery і SQL Injection уразливості. Зокрема через SQL Injection можна провести DoS атаку.

DoS (через SQL Injection):

Для атаки потрібно відправити POST запит, як показано в моєму експлоіті (чим більший benchmark, тим довше триває атака):

CapCC SQL Injection.html

Всі капчі, що мають SQL Injection уразливості, можуть бути атаковані. Відповідно до класифікації SQL Injection, уразливість в капчі для Nucleus - це Reflected SQL Injection, а уразливість в CapCC - це Persistent SQL Injection.

Denial of Service уразливості в капчах.

CaptchaSecurityImages - це скрипт капчі, що використовується на багатьох веб сайтах та движках. В CaptchaSecurityImages є Insufficient Anti-automation та Denial of Service уразливості. Зокрема через Denial of Service можна провести DoS атаку.

DoS:

http://site/CaptchaSecurityImages.php?width=1000&height=9000

Якщо вказати великі значення width і height, то можна створити велике навантаження на сервер.

Всі капчі, що дозволяють через передані параметри вказувати розміри зображення, можуть бути атаковані. Відповідно до класифікації DoS уразливостей - це DoS перенавантаження.

В своїй презентації Advanced Web Hacking, Shreeraj Shah розповів про просунутий веб хакінг. Про сучасні загрози в Інтернеті для компаній та їхніх клієнтів.

This is English version of my SQL DB Structure Extraction vulnerabilities article.

There is such variety of Information Leakage vulnerabilities as SQL DB Structure Extraction. This vulnerability lie in that there is information leakage in web application about structure of the database. This information leakage can be of use at SQL Injection attack.

Such vulnerability I found first time already in 2006 (at one site) and gave it this name. Such vulnerabilities I found at many web sites, particularly at bizua.com.ua, zoom.cnews.ru and job.ukr.net. And also in many web applications, particularly in WordPress (many times), W-Agora, Nucleus, Athree CMS (twice) and Abton.

Example of information leakage which occurs at using of one from SQL DB Structure Extraction vulnerabilities in WordPress:

SELECT * FROM wp_posts WHERE 1=1 AND (post_status = "publish" OR post_author = 1 AND post_status != 'draft' AND post_status != 'static') AND post_status != "attachment" AND post_status <> ‘trash’ GROUP BY wp_posts.ID ORDER BY post_date DESC LIMIT -30, 15

In this case important information it is name of table (wp_posts), particularly its prefix (wp), which is using in other tables of WP at vulnerable site.

What is the difference between SQL DB Structure Extraction and SQL Error? Because in both cases there is a message about error at request to database.

There are different messages about error in SQL query (SQL Error):

1. Only a message is showing about error at request to DB without any details. Sometimes at that there can be a message about a script, in which error occurs, including there can be mentioned full path to it at the server, which is Full path disclosure vulnerability. And in other cases there can be no details, only mentioning about error at request to DB.

2. A message is showing about error at request to DB and part of SQL query, in which there is error. In this case, usually, there is no leaked information about structure of DB. But in such cases it’s possible the conduction of XSS attacks via errors at requests to DB.

3. A message is showing about error at request to DB with detailed information about current SQL query (or several queries). When information about structure of DB is leaked - about tables and their fields in DBMS. And this variant is SQL DB Structure Extraction.

So SQL DB Structure Extraction vulnerability - it’s such variant of SQL Error, when error at request to database occurs and at the page (at notification about error at request to DB, or even without such notification) the information about structure of DB is showing.

Існує такий різновид Information Leakage уразливостей як SQL DB Structure Extraction. Дана уразливість полягає в тому, що у веб додатку має місце витік інформації про структуру бази даних. Даний витік інформації може стати в нагоді при SQL Injection атаці.

Подібну уразливість вперше я знайшов ще в 2006 році (на одному сайті) і дав їй таку назву. Подібні уразливості я знаходив на багатьох веб сайтах, зокрема на bizua.com.ua, zoom.cnews.ru та job.ukr.net. А також у багатьох веб додатках, зокрема в WordPress (неодноразово), W-Agora, Nucleus, Athree CMS (двічі) та Abton.

Приклад витоку інформації, що відбувається при використанні однієї з SQL DB Structure Extraction уразливостей в WordPress:

SELECT * FROM wp_posts WHERE 1=1 AND (post_status = "publish" OR post_author = 1 AND post_status != 'draft' AND post_status != 'static') AND post_status != "attachment" AND post_status <> ‘trash’ GROUP BY wp_posts.ID ORDER BY post_date DESC LIMIT -30, 15

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

В чому полягає різниця між SQL DB Structure Extraction та SQL Error? Бо в обох випадках виводиться повідомлення про помилку в запиті до бази даних.

Повідомлення про помилку в SQL запиті (SQL Error) бувають різні:

1. Виводиться лише повідомлення про помилку при запиті до БД без жодних деталей. Іноді при цьому може бути повідомлення про скрипт, в якому відбулася помилка, в тому числі може бути вказаний повний шлях до нього на сервері, що є Full path disclosure уразливістю. А в інших випадках може не бути жодних деталей, тільки згадка про помилку при запиті до БД.

2. Виводиться повідомлення про помилку при запиті до БД та частина SQL запиту, в якому є помилка. В даному випадку, зазвичай, інформації про структуру БД не витікає взагалі. Але в подібних випадках можливе проведення XSS атаки через помилки при запитах до БД.

3. Виводиться повідомлення про помилку при запиті до БД з детальною інформацією про даний SQL запит (або декілька запитів). Коли витікає інформація про структуру БД - про таблиці та їх поля в СУБД. Ось цей варіант і є SQL DB Structure Extraction.

Тобто SQL DB Structure Extraction уразливість - це такий варіант SQL Error, коли відбувається помилка при запиті до бази даних і на сторінці (при повідомленні про помилку при запиті до БД, або навіть без даного повідомлення) виводиться інформація про структуру БД.

Продовжуючи розпочату традицію, після попереднього відео про взлом Java додатків, пропоную новий відео секюріті мануал. Цього разу відео про підбір паролів до FTP. Рекомендую подивитися всім хто цікавиться цією темою.

Brute Force FTP Escalation

В даному відео ролику демонструється Brute Force атака на FTP. Після підбору паролю до FTP сервера на Windows XP, отримується telnet доступ до системи. А потім й доступ через RealVNC з захопленням акаунту адміністратора. Рекомендую подивитися дане відео для розуміння атак через FTP.

Про можливі атаки через редиректори, в тому числі сервіси редирекції, я писав в свої статтях Редиректори: прихована загроза та Атаки через закриті редиректори. Зокрема я наголошував на можливості розповсюдження шкідливого ПЗ через редиректори.

Також я писав про уразливості на багатьох сервісах редирекції, зокрема про уразливості на tinyurl.com. І я зокрема писав про можливість розповсюдження шкідливого коду саме через сервіс TinyURL. Атаки на користувачів можуть відбуватися як через редирекцію на зловмисні сайти, так і через поширення шкідливого коду безпосередньо через уразливості на сервісах редирекції. Але на всі мої попередження власники даних сервісів не звертали уваги.

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

Це добре, що Google почав перевіряти на інфікованість і сервіси редирекції. Зокрема на tinyurl.com Гугл виявив 363 редиректори, з яких на 112 була виявлена підозріла активність за останні 90 днів. Частина сайта tinyurl.com була внесена до переліку сайтів із підозрілою активністю 7 разів протягом останніх 90 днів і за цей час tinyurl.com був посередником зараження 52 сайтів.

Що цікаво, TinyURL почали звертати увагу на використання їхнього сервісу для атаки на користувачів, і почали попереджати про можливість небезпеки при редирекції через них на деякі URL (потенційно вони можуть співробітничати з тим же Гуглом). Вони виводять сторінку “Warning - this URL may be harmful” з повідомленням про небезпеку даної адреси і пропонують користувачеві, якщо він бажає, самому перейти по лінці.

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