Про двери и дыры

Растущий рынок zero-day’ев подталкивает программистов оставлять (и продавать) уязвимости в продуктах своей компании, так считает Брюс Шнайер.

Инцидент с чатом

Эта печальная история произошла примерно год назад. Дабы сэкономить время, была скачена nulled-версия одного популярного чата. Естественно там должны были оказаться “закладки”, так что прошерстив код руками я встретил порядка шести (!) явно добавленных руками дыр. По непонятной причине все они повышали права пользователя чата, но не были полноценными RCE, что было бы логичней.

Чат был установлен и даже проработал порядка недели, пока какой-то злобный уебан не получил права админа и не переименовал юзеров по своему усмотрению. Стало понятно, что найти все закладки даже при таком объеме кода физически вне моих сил! В итоге, от живого общения с читателем пришлось отказаться, хотя сейчас я понимаю, что надо было просто по-diff‘ать nulled с demo-версией.

Но что делать если дыру оставили при разработке?

PHP-бекдоры

Мистер Кробер, в своей статье про обфускацию шеллов, использует в качестве козыря особенность php, позволяющую вызывать функцию по имени:

Подобные трюки позволяют вызывать опасные функции типа eval, исключая поиск регулярками. Встречаются бекдоры и на уровне js, перехватывающие и отправляющие пароль на гейт автора. Слегка модифицированный шаблонизатор может иногда убирать экранирование. Дыра может быть и на уровне генератора случайных чисел, позволяя доброжелателю предсказать сгенерированные для пользователей пароли. Найти подобные уязвимости статик анализом не представляется возможным.

PHP-Антивирусы

Во времена истории с чатом, я расковырял базы достойных внимания защитных решений. Их оказалось не так много, большинство серверов банально сканирует диски ClamAv. К моему удивлению, за наличие некоторых скриптов можно моментально лишиться хостинга. В случае с автоматикой это происходит сразу после ежедневного (раз в день) сканирования по крону. Небольшие хостеры страдают от любопытства админов, которые не брезгают шариться по файлам юзеров руками, так что откажитесь от их использования.

Желая влезть в антивирусную тему, наш соотечественник выпустил php-сканер по имени AIBOLIT. На мой субъективный, подобные решения могут продвигаться только с откатами директорам фирм, ибо это очередной антивирус Бабушкина.

Однако он показывает развитие мертворождённой идеи сигнатурного сканера, сначала были набиты знакомые автору “эвристики”:

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

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

Как легко догадаться, такие скан-строки дают невероятно много ложных срабатываний, поэтому следующим шагом будет (вы не поверите) WHITELIST’инг! Белый список представляет из себя набор sha1-хешей, взятых от (???) имени файла:

Компилируемые бекдоры

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

Если у нашего приложения отключены DYNAMICBASE и Stack-Cookie, мы можем собрать банальное переполнение стека. Копируем строчку не проверяя размер буфера и вот мы уже перезаписали адрес возврата, можем даже оставить нужные для шеллкода rop-гаджеты.

Высокоуровневые бекдоры

Куда страшнее архитектурные уязвимости, когда ошибка заложена на стадии проектирования!

Примером могут служить хеши паролей из SAM-файла: какой бы длины не был пользовательский пароль (так работала Xp) он будет разбит на куски по 7 символов, которые будут хешированны отдельно. Таким образом любая контора с большой вычислительной мощностью ломает хеши как орешки, а для пользовательской машины (того времени) это недоступно. Наверняка это один из тех бекдоров, которые были добавлены по просьбе местных силовиков, по-своему понимающих слово “сертификация”.

Ещё одним забавным примером является документированная (!) функция action-script 1.0, по непонятной причине добавленная в (тогда ещё) Macromedia Flash. Она позволяла запускать произвольные приложения в системе, при просмотре через плеер. Что вкупе с записью любых данных в область flash-cookie привело к нехилому риску.

С учётом того сколько было найдено критических дыр во Flash’e, рискну предположить что проблема в доставшейся Adobe кодовой базе.

Ещё один важный урок на сегодня: Наличие одной дыры такого уровня говорит нам о том, что тот же криворукий дебил разраб оставил ещё сотню!

Это была первая найденная мной дыра, и сказать что я a#уел – ничего не сказать, позднее про неё писали в 29A (secret zone), так что внимательно читайте документацию =).

В сухом остатке, черные ходы и разного рода “закладки” обещают доставить всем нам массу неприятностей, хотя бы потому что никто давно не пишет native-код, используя “доверенные” фреймворки, что позволяет добавить дыру сразу в тысячи чужих приложений.

Добавить комментарий