Безопасность средств безопасности: СКУД (часть 1)
 Дисклеймер: материалы, приведенные ниже, несут исключительно научно-исследовательский характер. Данное исследование проводилось автором исключительно в научно-исследовательских целях, его результаты не являются и не могут признаваться руководством к совершению каких-либо противоправных действий. При проведении исследования автор действовал в рамках законодательства Российской Федерации. Использование результатов исследования допускается исключительно в научно-ознакомительных целях. Использование результатов исследования для достижения противоправного или любого иного от научной деятельности результата может повлечь за собой уголовную, административную и (или) гражданско-правовую ответственность. Автор не несет ответственность за инциденты в сфере информационной безопасности, имеющие отношение к тематике исследования.
ВСТУПЛЕНИЕ
Все привыкли выделять деньги на обеспечение безопасности компании, внедрять готовые решения и считать, что эти готовые решения полностью закрыли те или иные риски. Рынок предлагает комплекс различных решений от разных компаний-производителей, поэтому у покупателя есть широкий выбор аппаратных средств безопасности и ПО для управления ими. Вот именно об информационной безопасности такого ПО и пойдёт речь. Сегодня поговорим о системах контроля и управления доступом (СКУД).
КАК Я К ЭТОМУ ПРИШЕЛ
Проводя тестирование на проникновения в разных компаниях, я часто встречал открытый 3050/tcp порт базы данных Firebird (далее FB) с логином и паролем по умолчанию: «SYSDBA;masterkey». Изучая данные хосты, я выяснил, что это могут быть совершенно разные решения и программы, использующие FB: от бухгалтерского ПО и CRM-систем до систем видеонаблюдения и контроля доступа, и даже ДБО. Через данный порт доступна вся БД соответствующего ПО, и, редактируя ее, можно влиять на логику работы приложения.
В БД обычно хранятся логины и пароли для доступа к функционалу через графический интерфейс самой программы, значит, прочитав их, можно воспользоваться полным функционалом самого приложения через красивый графический интерфейс, изначально не зная ни одного логина и пароля к данной системе. Иногда пароли могут храниться в зашифрованном или хешированном виде.
Т.к. алгоритм шифрования пароля «зашит» в самом ПО, то смысл шифрования теряется, т.к. используются обратимые алгоритмы шифрования, которые легко узнать, имея образец ПО на руках. А хеширование усложняет процесс, но ненамного.
Вот мне и стало интересно, а много ли ПО имеет такой недостаток, если не сказать «уязвимость»? И вообще, является ли это уязвимостью ПО? Может быть, это просчет пользователей не настроивших данное ПО корректно? Ясно одно: такая ситуация очень распространена и несет в себе угрозы для бизнеса.
Для исследования мне показались интересны системы СКУД и видеонаблюдения, системы ДБО, бухгалтерское и финансовое ПО. Но в данной статье пойдет речь только о СКУД. Используя подобные уязвимости для систем СКУД, любой участник локальной сети может открывать\закрывать любые двери, нарушать пропускной режим. В общем, все то, что может администратор СКУД и даже больше!
МЕТОДОЛОГИЯ ИССЛЕДОВАНИЯ
Сам процесс исследования очень прост. Я скачал с официальных сайтов производителей демо-версии или обычные версии ПО, в зависимости от того, что было доступно на сайте. Если сайт не предоставлял возможности легко скачать ПО, то я связывался с производителем ПО через email и просил предоставить демо или триал версию ПО для тестирования или сравнительного анализа. Собрав дистрибутивы самых распространенных систем СКУД на рынке РФ\СНГ, я приступил к тестированию.
Каждый экземпляр ПО устанавливался на виртуальную машину и анализировался на открывшиеся порты. Если среди прочего появлялся 3050\tcp порт, то я пробовал залогиниться на него под дефолтным логином и паролем. Если залогиниться под стандартными учетными данными не получалось, т.е. ПО при установке FB-сервера сменило пароль, то я пытался понять на какой именно. Пробовал устанавливать ПО несколько раз и смотрел: изменялся ли хеш пароля от FB-сервера или нет. Если он не менялся, т.е. при нескольких установках оставался одним и тем же, я строил предположение, что данный пароль является универсальным для всех установок данного ПО для любого, кто использует это решение. Это не лучше, чем использование общеизвестных учетных данных по умолчанию. Любой, кто установит себе данное решение, узнает хеш от всех остальных клиентов, что не есть правильный и безопасный вариант.
После того, как данные действия были выполнены, я откатывал виртуальную машину назад в первоначальное состояние и переходил к следующему образцу ПО. Если ПО не устанавливалось на WindowsXP, то же самое пробовалось на Windows 7. Ну и конечно, если я замечал подобную ситуацию для других баз данных — я ее тоже отмечал, хотя изначально рассчитывал искать только FB. Все проверки проводились для ситуации, когда СКУД находится в локальной сети и установлен по умолчанию. Уязвимым я считал тот СКУД, к БД которого удалось подключиться и увидеть внутренности базы данных.
РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЯ
Всего в исследовании участвовало 25 СКУД решений.
Дополнительно в качестве подтверждения уязвимости приведены скриншоты успешного подключения к БД (по пунктам для каждого СКУД).
|
