NoSQL - инъекции на примере нереляционной СУБД MongoDB

В современных условиях, при недостатке финансирования автотранспортных предприятий, важным является эффективное использование производственно -технической базы. Ведь это напрямую влияет на состояние подвижного состава. Проведение всего перечня операций ТО и Р, наличие современного оборудования, позволят долгие годы поддерживать исправное техническое состояние транспортных средств предприятия.

Литература

1. Напольский Г. МТехнологическое проектирование автотранспортных предприятий и станций технического обслуживания: учебник для вузов. М.: Транспорт, 1985. 231 с.

2. Юркова Т. И., Юрков C. В. Экономика предприятия / Т. И. Юркова, С. В. Юрков. ГАЦМиЗ. Красноярск, 2006. 116 с.

NOSQL — ИНЪЕКЦИИ НА ПРИМЕРЕ НЕРЕЛЯЦИОННОЙ

СУБД MONGODB Фримучков А. Н.

Фримучков Андрей Николаевич /Frimuchkov Andrey Nikolaevich - студент, факультет кибернетики, Московский технологический университет, г. Москва

Аннотация: в статье рассматриваются вопросы уязвимости нереляционных баз данных, в том числе MongoDB. В настоящее время считается, что нереляционные базы данных, в сравнении с классическими реляционными, являются более безопасными по причине отсутствия SQL и, соответственно, связанных с ним инъекций. Однако нереляционные базы данных имеют целый ряд специфических уязвимостей, как в них самих, так и в системе управления, что делает нереляционные базы данных не такими безопасными, как кажется на первый взгляд. Ключевые слова: информационная безопасность, базы данных, нереляционные СУБД.

Введение

Понятие NoSQL (Not Only SQL или No SQL) получило известность с 2009 года. Именно тогда развитие web-технологий и социальных сервисов дало толчок множеству новых подходов к хранению и обработке данных. Разработчики подобных приложений столкнулись с задачами, для которых традиционные реляционные СУБД оказались либо слишком дороги, либо недостаточно производительны. Кроме того, популяризаторами отказа от универсальных «комбайнов» (реляционные СУБД -РСУБД) в пользу специализированных решений стали молодые проекты и те, кому приходится работать в сценариях так называемых Big Data [1].

Уязвимости NoSQL

Логично будет предположить, что нереляционные СУБД безопасны, потому что в них отсутствуют SQL-запросы и, соответственно, отсутствует возможность провести SQL-инъекцию. Отчасти это так степени, но если в запросе отсутствует SQL-код, это еще не говорит, система безопасна. NoSQL закрывает лишь уязвимости типа SQL-инъекции, при этом оставляя множество других.

Обычно она состоит из трех уровней [3]:

• приложение;

• API базы данных NoSQL;

• NoSQL-СУБД.

Каждый их этих уровней потенциально уязвим. Начнем с нижнего, то есть самой СУБД. Как и любое приложение, СУБД может быть подвержена атакам переполнения буфера или иметь уязвимую схему аутентификации. Атаковать этот уровень сложно, потому что за подобными уязвимостями следят как сообщество, так и разработчики.

Следующий уровень — API. Большинство NoSQL-СУБД имеют огромное количество библиотек для организации доступа к данным. Большинство таких проектов имеют открытый код, но часть из них уже не поддерживаются, поэтому вероятность обнаружить уязвимость на этом уровне гораздо выше.

Уязвимости нижнего уровня NoSQL

Рассмотрим уязвимости (или слабые места) на основе анализа нескольких версий MongoDB [3]:

1. Уязвимое место в системе аутентификации. По-умолчанию БД устанавливается без пароля. Создатели MongoDB предполагают, что БД запускается в полностью доверенном окружении.

2. Уязвимое место в системе авторизации. Любой созданный пользователь по-умолчанию имеет доступ на чтение всей базы данных, то есть он имеет доступ ко всему, что у нас имеется.

3. Уязвимое место в системе авторизации администратора. Пользователь с доступом к базе данных Admin имеет права на чтение/запись откуда/куда угодно. А т.к. по-умолчанию нет пароля, то мы имеем доступ везде.

4. Нешифрованный текст. Все данные передаются в открытом виде, то есть они могут быть перехвачены любой MITM—атакой.

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

Инъекции в регулярных выражениях

MongoDB, как и многие другие NoSQL-СУБД, предоставляет возможность выполнять поиск при помощи регулярных выражений. Это очень удобный инструмент, однако он представляет собой серьёзную потенциальную угрозу [3].

Для осуществления поиска при помощи регулярных выражений используется оператор $regex. Запрос «верни мне всех пользователей, логин которых начинается с «user»» представлен на рисунке 1.

db.users.fmd

Рис. 1. Пример запроса с $regex Обработка самого запроса представлена на рисунке 2.

var regexpPwd= new RegExp("A" + password, "i"); var loginParam= { login: login, password: regexpPwd }

Рис. 2. Выполнение запроса с $regex

Для выполнения инъекции достаточно передать вместо пароля строку «[\s\S]*». Этот приём похож на классическое для SQL «1' or 1=1 --». Решение крайне тривиальное - нужно проверять входные данные.

JSON-инъекции

В MongoDB нет SQL-синтаксиса, однако СУБД не может обойтись без языка запросов, поэтому разработчики MongoDB решили использовать вместо SQL JSON. Поэтому можно попробовать осуществить разные атаки-инъекции (конечно, если нет фильтрации входных данных). Такие атаки обычно называют JSON-инъекциями [2]. Пример самого «небезопасного» кода можно увидеть на рисунке 3.

var loginParam= eval("({ login:+ login + password:'" + password+})");

Рис. 3. Пример небезопасной обработки JSON

Первое, что бросается в глаза это не возможность JSON-иньекции, а использование функции eval. Эта функция выполняет код, которые предан в аргументе, поэтому использовать её не рекомендуется.

Но вернёмся к JSON-иньекции, чтобы её выполнить достаточно передать в логин строку «root'})//», что и было сделано на рисунке 4.

Рис. 4. Эксплуатация уязвимости при обработке JSON Манипуляции с REST-интерфейсом

MongoDB предоставляет REST-интерфейс, который позволяет получить доступ к данным без возможности записи. Кроме того, существует проект под названием Sleepy Mongoose, который реализует полную поддержку REST. Пример такого запроса на рисунке 5.

var qry = "/rest/users/?login-' + login + "& password=" +password: var hash = qry.indexOfi["#"); if (hash >-1) {

qry = qry.substring(0, hash);

}

Рис. 5. Пример запроса через REST-интерфейс

Если мы введём имя пользователя root#, то войдём от имени root, т.к. всё что после # будет проигнорировано. Запрос, конечно же, надуманный и в реальном приложении такое встретить не получится, однако, в том или ином виде подобная уязвимость может быть встречена. Выдох один — фильтрация получаемых данных.

1. Запросы с оператором $where.

2. Команда db.eval.

3. Функции для сохранения в базе данных. Для этого используется специальная системная коллекция system.js.

4. Map/Reduce. Это - программный фреймворк, разработанный компанией Google для параллельных вычислений над большими объемами данных. Заключение

На уровне самой БД при настройках по-умолчанию реализации NoSQL (а именно — MongoDB) существенно проигрывают классических РСУБД. Однако, справедливо было бы заметить, что настройки по-умолчанию не используются на боевых серверах, поэтому, в большинстве случаев, если уязвимость есть только при настройках по-умолчанию, то в серьёзных проектах её не будет. И, всё же, это минус в копилку NoSQL.

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

Литература

1. СУБД NoSQL - сильные и слабые стороны. [Электронный ресурс]. Режим доступа: http://www.jetinfo.ru/stati/silnye-i-slabye-storony-nosql/ (дата обращения: 12.11.2016).

2. Азбука NoSQL-инъекций. [Электронный ресурс]. Режим доступа: https://habrahabr.ru/company/xakep/blog/143909/ (дата обращения: 12.11.2016).

3. Mongodb - Security Weaknesses in a typical NoSQL database. [Electronic resource]. URL: https://www.trustwave.com/Resources/SpiderLabs-Blog/Mongodb—Security-Weaknesses-in-a-typical-NoSQL-database/ (date of access: 12.11.2016).