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

Про переваги атак на сайти з використанням інших сайтів я вже коротко писав в статті Використання сайтів для атак на інші сайти. А також розробив програму DAVOSET для проведення таких атак. Зараз більш детально розповів про переваги використанням інших сайтів для проведення DoS і DDoS атак та для розсилки спаму.

При проведенні DoS атак через інші сайти є наступні переваги:

• Використання ресурсів інших серверів для атаки.
• Приховання джерела атаки (за рахунок приховання власного IP).
• Обхід обмежень на IP при атаці на сайт (за рахунок використання інших серверів).
• Підставлення сайтів, що використовувалися для проведення атаки.
• Використання трафіку інших серверів.
• Можна заDoSити як цільовий сайт, так і сайт-посередник, так і обидва сайти.

При проведенні DDoS атак через інші сайти є наступні переваги:

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

При розсилці спаму через інші сайти є наступні переваги:

• Використання ресурсів інших серверів.
• Приховання джерела розсилки спаму (за рахунок приховання власного IP).
• Підставлення сайтів, що використовувалися для розсилки спаму.
• Використання трафіку інших серверів.

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

Продовжуючи розпочату традицію, після попереднього відео про експлоіт для LNK уразливості в Microsoft Windows, пропоную новий відео секюріті мануал. Цього разу відео про обхід аутентифікації в Mikrotik Hotspot. Рекомендую подивитися всім хто цікавиться цією темою.

How to bypass Mikrotik Hotspot Login Page

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

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

При використанні функції crypt, зокрема для створення хешів паролів, можуть виникнути секюріті проблеми. Якщо в статті Неякісне використання MD5 у веб додатках я розповів про обрізання рядків, що використовуються для секюріті потреб, самими розробниками, то в даному разі мова йде про обрізання рядків (зокрема паролів) самим алгоритмом. Що потрібно враховувати всім веб розробникам, які використовують crypt.

Функція crypt (при використанні стандартного DES алгоритму, що є по замовчуванню) урізає паролі до 8 символів. При створенні хеша функцією crypt враховуюється лише перші 8 символів паролю. Це задокументований функціонал crypt.

Але при цьому дана особливість не є достатньо відомою. І існує велика кількість додатків, зокрема на Perl та PHP, які використовують crypt (з DES). Я сам використовую Perl з січня 2001 року, але лише в 2010 році дізнався про цю особливість crypt. В літературі, яку я читав, ні слова про обмеження crypt не було сказано, і в основному лише рекомендувалося її використовувати для хешування паролів (тобто як надійний метод хешування). В своєму Посібнику з безпеки, написаному в 2005, я також порадив використовувати crypt, не зазначивши про дану особливість (але в цьому році я додав інформацію про обмеження crypt).

В Інтернеті можна знайти чимало статтей, де рекомендується використовувати функцію crypt, але при цьому рідко коли згадується про її обмеження. А в тих довідниках де про це згадується, це робиться без достатнього акцентування, тому читачі можуть на це просто не звернути уваги. Зокрема в perldoc лише в одному реченні згадується про цю особливість (чого недостатньо), зате в керівництві по PHP на це звертається більше уваги (і радиться використовувати інші алгоритми замість DES, чого цілком достатньо для привернення уваги розробників).

Тому хеш пароля довжиною більше 8 символів буде таким самим, що і хеш пароля в 8 символів (при ідентичних перших 8 символах). Що зпрощує підбір паролів і може бути використаним для атаки на Perl та PHP додатки, які використовують crypt для перевірки хешів (зокрема, хешів паролів), або при брутфорсі викрадених хешів. А також на папки на серверах з Apache, що захищені htpasswd.

Пароль в 8 символів може бути в деяких випадках достатнім, а в інших випадках - недостатнім, до того ж нападник може проводити атаку тривалий час і підібрати навіть 8 символьний пароль. А якщо використовується пароль (навіть достатньо довгий), в якому перші 8 символів легко вгадуємі і лише наступні символи не є легко вгадуємими (наприклад, “password_randomchars”), то він буде легко підібраний, тому що при створенні хеша враховуються лише перші 8 символів (”password”).

Дана ситуація має місце в Perl та PHP. В інших мовах програмування, що підтримують стандартний DES алгоритм, ситуація подібна. А також в Apache htpasswd.exe, якщо він використовує DES, при використанні на сайті htpasswd-функціонала Apache (зокрема в версії для Linux та Unix систем, бо на Windows використовується MD5 алгоритм, але є спеціальна версія htpasswd.exe, що використовує DES алгоритм). Тому при використанні даних інструментів, потрібно замість DES використоувати інший алгоритм.

Продовжуючи традицію, пропоную вашій увазі цікаві секюріті статті. Щоб ви поповнювали свої знання з веб безпеки.

Добірка цікавого чтива на тему безпеки, в тому числі web security (статті з Вікіпедії):

• NOP slide
• Null character
• OSVDB
• Off-by-one error
• Operation: Bot Roast

В своїй презентації Client Side Attacks, Mauricio Velazco розповідає про атаки на клієнтів. Презентація зроблена на іспанській мові, але є деякі слайди з текстом на англійській мові.

Як в 2009 році повідомив представник Mozilla в своїй статті cross-site xmlhttprequest with CORS, починаючи з версії Firefox 3.5 в браузері Firefox додана підтримка міжсайтових XHR запитів. Яка реалізована через специфікацію Cross-Origin Resource Sharing (CORS). Міжсайтові XHR запити також підтримуються в інших браузерах, зокрема в Safari, Chrome та IE8.

Якщо раніше XHR запити могли бути лише в рамкам одного домену, то в нових браузерах, що підтримують Cross-Site XMLHttpRequest, запити можуть бути проведені між різними доменами. Що створює можливості для нових міжсайтових атак.

Тому враховучи, що в Firefox 3.5, Safari 4, Chrome 2 та Internet Explorer 8 є підтримка Cross-Site XMLHttpRequest, то це може бути використано для міжсайтових XSS атак з викорисанням XHR. Так що при відповідних умовах в нових браузерах може проводитися новий вид атак - міжсайтові XHR атаки (cross-site XHR attacks).

При наступних умовах можливі міжсайтові XHR атаки:

1. При наявності HTTP Response Splitting уразливості на сайті для виведення потрібних заголовків сервера.
2. При наявності уразливостей, що дозволять завантажити на сайт серверні скрипти для виведення потрібних заголовків сервера.
3. При наявності на сайті XSS дірки, а на сервері нападника є скрипт, який дозволяє звертатися через XHR (таким чином комунікація відбувається через XHR).
4. При наявності проксі (що контролюється нападником), який для будь-якого сайта виводить необхідні заголовки сервера, щоб дозволити міжсайтовий XHR.
5. При наявності вірусів на комп’ютері користувача (це можуть бути й плагіни/доповнення до браузера), що для будь-якого сайта виводять необхідні заголовки, щоб дозволити міжсайтовий XHR.

Продовжуючи розпочату традицію, після попереднього відео про IIS WebDAV уразливість в дії, пропоную новий відео секюріті мануал. Цього разу відео про eксплоіт для LNK уразливості в Microsoft Windows. Рекомендую подивитися всім хто цікавиться цією темою.

Microsoft LNK Exploit – MS10-046

Раніше я вже писав про виконання коду через ярлики в Microsoft Windows. Дана уразливість була виявлена в різних версіях ОС Windows від Microsoft (патч для якої вийшов на початку серпня). І в даному відео ролику демонструється використання даної уразливості в ярликах для атаки на IE.

В відео показаний процес атаки на користувачів Internet Explorer через спеціально створений сайт (зі спеціальним ярликом). Рекомендую подивитися дане відео для розуміння векторів атак на браузер Internet Explorer.

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

IIS WebDAV Vulnerability in Action

Раніше я вже писав про обхід аутентифікації WebDAV в Microsoft IIS, що була виявлена в веб сервері Microsoft в 2009 році. І в даному відео ролику демонструється використання даної уразливості в IIS.

В відео показані різні варіанти атаки через WebDAV. Рекомендую подивитися дане відео для розуміння векторів атак з використанням уразливості в аутентифікації WebDAV в IIS.

Продовжуючи традицію, пропоную вашій увазі цікаві секюріті статті. Щоб ви поповнювали свої знання з веб безпеки.

Добірка цікавого чтива на тему безпеки, в тому числі web security (статті з Вікіпедії):

• Intrusion detection system evasion techniques
• Laptop theft
• Login spoofing
• Memory safety
• Mixed threat attack

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

Зловживання захисними механізмами.

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

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

Це інша версія зворотньої DDoS атаки (reverse DDoS attack) про яку я писав в 2008. Якщо в тому випадку атака вібдувалася на браузери користувачів сайта, то в даному випадку атака відбувається на захисні механізми сайта (від імені відвідувачів сайта).

Можливі наступні атаки:

• Атаки для блокування аккаунтів при некоректних логінах.
• Атаки на вбудовані захисні механізми (вбудовані IPS) з блокуванням.
• Атаки на WAF з включеним блокуванням.
• Атаки для блокування ботів пошукових систем.

Атаки на вбудовані IPS та WAF є більш небезпечними ніж атаки на логін форми, тому що вони призводять до блокування доступу до всього сайта і можуть бути використані не тільки для блокування користувачів та адмінів сайтів, але також і ботів пошукових систем.

Атаки для блокування аккаунтів при некоректних логінах.

Існують такі веб додатки (наприклад, форуми та інші движки), що використовують автоматичне блокування як захист від Brute Force атак на логін форми. Якщо логіни відомі (а я багато разів присав про численні Information Leakages у веб додатках, що призводять до витоку логінів), то можна заблокувати всі дані акаунти.

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

Атаки на вбудовані захисні механізми (вбудовані IPS) з блокуванням.

Існують сайти з вбудованими захисними механізмами з блокуванням і вони можуть бути атакованими з використанням даного методу. В 2009 я знайшов такий сайт як www.4post.com.ua, де серед інших уразливостей була Abuse of Functionality дірка (в захисному функціоналі, що блокував доступ при одному спеціальному запиті до сайта), що дозволяла проводити блокування користувачів та адмінів сайта.

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

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

Атаки на WAF з включеним блокуванням.

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

З декількома простими CSRF атаками (повинно бути стільки атак, скільки треба для перевищення порогу WAF) на користувачів сайта, можливо заблокувати повний доступ до сайта для користувачів та адмінів сайта. Нижчезгадане блокування ботів пошукових систем також можливе на таких сайтах.

Атаки для блокування ботів пошукових систем.

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