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

Одним з навайжливіших SEO показників сайта є його ранжування в результатах пошуку. І через дірки на сайті можна впилавати на ранжування сайта в результатах пошуку в пошукових системах.

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

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

Також через дірки на сайті можна вплинути на його ранжування (зокрема в Гуглі). Це стало можливо з недавніх пір, коли швидкодія сайта - стала фактором ранжування для Google. Поки що це стосується лише користувачів з США, але з часом Гугл перенесе даний фактор ранжування і на інші країни.

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

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

Injecting Malicious Code via phpBB

В даному відео ролику демонструється Code Execution атака на phpBB. Коли при доступі до адмінки, що можна зробити через різні дірки в движку, можна виконувати довільний код (довільні системні команди) через phpBB за допомогою спеціального методу, розробленого автором даного відео.

Для цього в адмінці виконується спеціальний SQL запит, що дозволяє в движку виконувати довільні системні команди. Після чого автор виконує декілька команд, в тому числі додає новий акаунт адміністратора в систему. Рекомендую подивитися дане відео для розуміння Code Execution атак.

Пропоную ознайомитися з мою статтею про тестування систем пошуку вірусів на веб сайтах, що я провів на цьому тижні.

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

Тестування систем пошуку вірусів на веб сайтах

Мною були дослідженні наступні системи:

1. Web Virus Detection System.
2. Google.
3. Yahoo.
4. Yandex.
5. Norton Safe Web.
6. McAfee SiteAdvisor.
7. StopBadware.

З результатами тестування можете ознайомитися в даній статті.

This is English version of my Anthology of attacks via captchas article.

Earlier I made anthology of attacks via redirectors (opened and closed) in my articles Redirectors: the phantom menace and Attacks via closed redirectors. And in this article I’ll make anthology of attacks via captchas.

CAPTCHA - it’s security web applications, which designed to protect web sites against automated requests. But captchas not only badly handle with protection against automated requests, but they also create possibilities for other attacks at the sites and their visitors. There are many different attacks via captchas, which I’ll tell about in this article.

Attacks via captchas.

Besides direct captcha bypass, there also can be made many other attacks via them. Here is a list of all attacks via captchas which I know:

• Captcha bypass.
• Redirector attacks.
• Cross-Site Scripting attacks.
• SQL Injection attacks.
• CSRF attacks.
• Information leakages.
• Denial of Service attacks.

Captcha bypass.

Multiple Insufficient Anti-automation vulnerabilities occur in captchas, which allow to bypass captchas for sending of automated requests. Which I told about in details in my project Month of Bugs in Captchas.

Redirector attacks.

In Google’s captcha there is Redirector vulnerability, which allow to redirect visitors to arbitrary sites.

Cross-Site Scripting attacks.

In captcha for Nucleus and in plugins Peter’s Random Anti-Spam Image, Math Comment Spam Protection, Captcha!, Cryptographp, WP-ContactForm and CapCC for WordPress there are Cross-Site Scripting vulnerabilities (reflected and persistent), which can be used for XSS attacks.

SQL Injection attacks.

In captcha for Nucleus and in plugin CapCC for WordPress there are SQL Injection vulnerabilities, which can be used for attacks on the sites.

CSRF attacks.

In plugins Captcha! and CapCC for WordPress there are Cross-Site Request Forgery vulnerabilities, which can be used for CSRF-attacks. Including for exploitation of Insufficient Anti-automation (in both captchas) and SQL Injection (in second captcha) vulnerabilities.

Information leakages.

In captcha for Nucleus there are Full path disclosure and SQL DB Structure Extraction vulnerabilities, and in plugin CapCC for WordPress there is Full path disclosure vulnerability. Which lead to leakage of information at the site.

Denial of Service attacks.

There can be conducted DoS attacks via captchas (via SQL Injection and Denial of Service vulnerabilities in them). Which I wrote about in details in my article DoS attacks via captchas.

Conclusions.

Instead of protecting of web sites against automated requests, captchas often pose a threat to security of web sites and their visitors. So developers of captchas and owners of web site which use them need always to check security of their captchas.

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

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 розповів про просунутий веб хакінг. Про сучасні загрози в Інтернеті для компаній та їхніх клієнтів.