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

В своїй презентації Hackers Paradise SQL Injection Attacks, Doug Seven, розповідає про SQL Injection атаки. Про те, що таке SQL ін’єкції, про просунуті атаки та про те, як їм протидіяти.

В публічних емайл розсилках (mailing lists), також відомих як дискусійні групи (discussion groups), існує ряд уразливостей, про які я вже розповідав на прикладі WASC Web Security Mailing List (які я виявив в даній дискусійній групі в 2008 році). Що можуть використовуватися для проведення різних атак на розсилку та її дописувачів.

Основними уразливостями, що характерні всім емайл розсилкам, є наступні Abuse of Functionality та Insufficient Anti-automation уразливості. І всім користувачам дискусійних груп варто враховувати ризики їх використання.

Abuse of Functionality:

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

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

Abuse of Functionality:

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

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

Insufficient Anti-automation:

В розсилках можлива автоматизована реєстрація. Що дозволить спамерам автотизовано підписуватися на розсилку та проводити дві вищезгадані атаки. І поєднуючи Insufficient Anti-automation з Abuse of Functionality уразливостями, спамери можуть автоматизовано відправляти спам чи автоматизовано збирати емайли для подальшого використання.

Продовжуючи традицію, пропоную вашій увазі цікаві секюріті статті. Цього разу статті на тему безпеки кредитних карт та Інтернет шахрайства.

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

• International credit card data theft
• Credit card hijacking
• Malware
• Targeted threat
• Vishing

Продовжуючи розпочату традицію, після попереднього відео про eксплоіт для уразливості в Adobe Flash Player, пропоную нове відео на веб секюріті тематику. Цього разу відео про ризики використання Gmail та Chrome від Google. Рекомендую подивитися всім хто цікавиться цією темою.

Google’s Gmail and Chrome Pose Privacy Risks

В відео розповідається про ризики приватності, що виникають при використанні Gmail та Chrome від Google. Це запис сюжету, що був показаний в новинах на телебаченні в США.

Зазначу, що подібні проблеми з приватністю, які пов’язанні з SSL, стосуються і будь-яких інших поштових сервісів окрім Gmail Гугла. Рекомендую подивитися дане відео для розуміння ризиків приватності при використанні електронної пошти з веб інтерфейсом і необхідності використання SSL.

Існує декілька варіантів розміщення шелів (як і будь-яких бекдорів) на сайтах. Перші два варіанти є відомими, а третій варіант - це новий, який я розробив минулого року, коли виявив RCE уразливість в CMS WebManager-Pro. Подібні уразливості можуть бути й в інших веб додактах.

Шели можуть бути розміщенні на сайті:

1. У вигляді окремих файлів.
2. Включені в існуючі скрипти.
3. Включені в Базу Даних.

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

У другому випадку це можуть бути будь-які існуючі php та інші скрипти на веб сайті, в код яких додається код шела. Тобто робиться бекдор в існуючому коді.

У третьому випадку це можуть бути записи в БД, коли веб додаток виконує код (наприклад, PHP код), що знаходиться у даному записі. Як це може бути у випадку CMS WebManager-Pro.

Перші два випадки стосуються файлів у файловій системі сервера. А третій випадок стосується записів в СУБД. І якщо для перших двох потрібно мати права на запис до файлової системи, то у третьому випадку ці права не потрібні - потрібно лише записати дані в БД. Тобто з використанням третього методу розміщення шелів (там де він придатний), можна обійти це обмеження, а також більш приховано розмістити шел .

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

Для пошуку перших двох типів шелів можна скористатися спеціалізованими програмами. Зокрема для WordPress можна скористатися Сканером експлоітів в WordPress та плагіном Belavir, про які я вже розповідав (але враховуючи ранішезгадані уразливості в Belavir, варто враховувати безпеку подібних плагінів при їх використанні). Про інші подібні додатки я ще розповім. А для третього типу шелів потрібні зовсім інші додатки, що вміють виявляти шели в базах даних.

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

Adobe Flash Player newfunction Invalid Pointer Use

В відео показаний процес атаки на користувачів Flash Player та Acrobat Reader (атака також можлива через їхні плагіни до браузерів). Дана уразливість стосується Flash Player 9.0 і 10.0, Adobe Reader 9.3.2, Adobe Acrobat 9.3.2 та будь-яких інших продуктів, що включають флеш плеєр.

Для створення експлотіа використовується Metasploit Framework. Рекомендую подивитися дане відео для розуміння векторів атак на Flash Player та інші продукти з вбудованим флеш плеєром.

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

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

• Credit card fraud
• Crimeware
• Internet fraud
• Phishing
• Advance-fee fraud

В останні роки з’явився новий вид атак на сайти - це атака на сайт через захоплення домену. Зокрема в 2009-2011 роках сталося декілька подібних атак на відомі компанії. Тому, на мій погляд, даний вид атак буде ставати все більш поширеним з кожним роком і вже варто звертати на це увагу.

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

Останні гучні інциденти:

1. Атака на марокканський сайт Google.

В травні 2009 року відбулася атака на сайт google.co.ma компанії Googlе через зміну налаштувань DNS. Як повідомлялося, перед цим (в квітні) аналогічним чином були атаковані сайти Google в Алжиру (google.dz) і Пуерто-Ріко (google.com.pr).

2. Дефейс бангладешського сайта Google.

Як я вже писав, на початку січня сайт google.com.bd компанії Googlе піддався дефейсу, через захоплення управління над доменом.

3. Захоплення домену ChronoPay.

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

На початку 2010 року вийшла друга версія класифікації Web Application Security Consortium Threat Classification - WASC TC v2.0. Вона є продовженням WASC TC v1.0 і має значні відмінності від першої версії класифікації.

Серед нововведень другої версії класифікації виділю наступні. По-перше, в ній додані нові класи уразливостей. По-друге, з’явилися ідентифікатори класів уразливостей (що є зручним для посилання на WASC TC). По-третє, в новій версії класифікації немає категорій уразливостей, а є два різновиди: Атаки та Слабкості.

За новою версією класифікації WASC TC існують наступні класи уразливостей:

Атаки (Attacks):

Abuse of Functionality (WASC-42)
Brute Force (WASC-11)
Buffer Overflow (WASC-07)
Content Spoofing (WASC-12)
Credential/Session Prediction (WASC-18)
Cross-Site Scripting (WASC-08)
Cross-Site Request Forgery (WASC-09)
Denial of Service (WASC-10)
Fingerprinting (WASC-45)
Format String (WASC-06)
HTTP Request Splitting (WASC-24)
HTTP Response Splitting (WASC-25)
HTTP Request Smuggling (WASC-26)
HTTP Response Smuggling (WASC-27)
Integer Overflows (WASC-03)
LDAP Injection (WASC-29)
Mail Command Injection (WASC-30)
Null Byte Injection (WASC-28)
OS Commanding (WASC-31)
Path Traversal (WASC-33)
Predictable Resource Location (WASC-34)
Remote File Inclusion (WASC-05)
Routing Detour (WASC-32)
SOAP Array Abuse (WASC-35)
SSI Injection (WASC-36)
Session Fixation (WASC-37)
SQL Injection (WASC-19)
URL Redirector Abuse (WASC-38)
XPath Injection (WASC-39)
XML Attribute Blowup (WASC-41)
XML External Entities (XXE) (WASC-43)
XML Entity Expansion (WASC-44)
XML Injection (WASC-23)
XQuery Injection (WASC-46)

Слабкості (Weaknesses):

Application Misconfiguration (WASC-15)
Directory Indexing (WASC-16)
Improper Filesystem Permissions (WASC-17)
Improper Input Handling (WASC-20)
Improper Output Handling (WASC-22)
Information Leakage (WASC-13)
Insecure Indexing (WASC-48)
Insufficient Anti-automation (WASC-21)
Insufficient Authentication (WASC-01)
Insufficient Authorization (WASC-02)
Insufficient Password Recovery (WASC-49)
Insufficient Process Validation (WASC-40)
Insufficient Session Expiration (WASC-47)
Insufficient Transport Layer Protection (WASC-04)
Server Misconfiguration (WASC-14)

Існує така класифікація уразливостей як Web Application Security Consortium Threat Classification (WASC TC). У 2004 році вийшла перша версія класифікації - WASC TC v1.0. Про яку я зараз детально розповім (зазначу, що в 2010 році вийшла TC v2.0).

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

За класифікацією WASC TC існують наступні класи уразливостей:

1. Аутентифікація (Authentication)
1.1. Підбор (Brute Force)
1.2. Недостатня аутентифікація (Insufficient Authentication)
1.3. Небезпечне відновлення паролів (Weak Password Recovery Validation)
2. Авторизація (Authorization)
2.1. Передбачуване значення ідентифікатора сесії (Credential/Session Prediction)
2.2. Недостатня авторизація (Insufficient Authorization)
2.3. Відсутність таймаута сесії (Insufficient Session Expiration)
2.4. Фіксація сесії (Session Fixation)
3. Атаки на клієнтів (Client-side Attacks)
3.1. Підміна вмісту (Content Spoofing)
3.2. Міжсайтове виконання сценаріїв (Cross-Site Scripting)
3.3. Розщеплення HTTP-запиту (HTTP Response Splitting)
4. Виконання коду (Command Execution)
4.1. Переповнення буфера (Buffer Overflow)
4.2. Атака на функції форматування рядків (Format String Attack)
4.3. Впровадження операторів LDAP (LDAP Injection)
4.4. Виконання команд ОС (OS Commanding)
4.5. Впровадження операторів SQL (SQL Injection)
4.6. Впровадження серверних розширень (SSI Injection)
4.7. Впровадження операторів XPath (XPath Injection)
5. Недостатній захист інформації (Information Disclosure)
5.1. Індексування директорій (Directory Indexing)
5.2. Ідентифікація додатків (Web Server/Application Fingerprinting)
5.3. Витік інформації (Information Leakage)
5.4. Зворотний шлях у директоріях (Path Traversal)
5.5. Передбачуване розташування ресурсів (Predictable Resource Location)
6. Логічні атаки (Logical Attacks)
6.1. Зловживання функціональними можливостями (Abuse of Functionality)
6.2. Відмова в обслуговуванні (Denial of Service)
6.3. Недостатня протидія автоматизації (Insufficient Anti-automation)
6.4. Недостатня перевірка процесу (Insufficient Process Validation)