Взлом систем контроля доступом СКУД.

Довольно часто мы ведемся на красивые маркетинговые фразы многих продуктов, такие как «Ваш компьютер защищен» или «Ваша система в безопасности». Мы довольно расслабляемся и думаем, что нам ничего не грозит. Но, оказывается, security-решения сами нуждаются в защите. Считаешь, та легкость, с которой злоумышленники в кино открывают любые двери — всего лишь красивая режиссерская выдумка? Ну что ж, давай выясним!

А для этого мы сегодня «пригласили на серьезный разговор» системы контроля и управления доступом (СКУД), которые как раз и отвечают за открытие дверей только нужным людям.

Преамбула

При изучении безопасности различных объектов и ПО часто обнаруживаются уязвимости, возникающие просто от халатности или невнимательности. Например, когда на сервере не патчится / не отключается служба, про которую давно известно, что она «дырявая». Или когда после установке CMS-ки не удаляется инсталляционный скрипт. Дефолтные конфиги, дефолтные права тоже частенько приводят ко взлому систем. Ну и конечно же, встроенные учетки с логинами и паролями «по умолчанию». Все это при анализе защищеннoсти очередной системы периодически попадается и мне.

Во время одного такого исследования, например, сканер сети обнаружил открытый 3050/tcp, на котором обычно висит СУБД FireBird; а когда я попробовал подключиться к нему и войти под дефолтной учеткой SYSDBA:masterkey, никто мне не воспрепятствовал сделать это. Как потом оказалось, на сервере вертелась база системы контроля и управления доступом (в моей практике также встрeчались случаи, когда «огненная птичка» использовалась разным бухгалтерским ПО или ДБО системами).

[ad name=»Responbl»]

Имея доступ к такой базе, ты имеешь доступ к учеткам (логинам, паролям) всех пользователей, включая администраторов системы. Подсмотрев их, можно так же легко подключиться к системе через красивый GUI официального клиента. Почему легко? Потому что зачастую пароли хранятся в открытом виде. Если они хранятся в зашифрованном виде — то ничто не мешает узнать алгоритм шифрования, имея на руках экземпляр ПО, и расшифровать их. Использование хешей также не проблема, их можно сбрутить, или же подменить хеш к базе на нужный.

И тогда мне стало интересно: а много ли СКУДов подвержены такой уязвимости?

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

Подход к исследованию

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

Каждая СКУД устанавливалась на виртуальную машину и анализировалась на предмет открытых портов. Если среди прочих появлялся 3050/tcp порт, то я пробовал зайти на сервис, слушающий его, под дефолтным логином и паролем. Если залогиниться под стандартной учеткой не получалось, то есть программа при установке Firebird-сервера сменила пароль, то я пытался понять, на какой именно.

Пробовал устанавливать ПО несколько раз и смотрел, изменялся ли хеш пароля от FB-сервера или нет. Если он не менялся, то есть при нескольких установках оставался одним и тем же, я предполагал, что пароль является универсальным для всех установок конкретного ПО. Это не лучше, чем использование общеизвестных учетных данных по умолчанию. Любой, кто установит себе такое решение, легко может узнать хеш от всех остальных клиентов, что не есть правильный и безопасный вариант.

[ad name=»Responbl»]

После этого я откатывал виртуальную машину назад в первоначальное состояние и переходил к следующему образцу. Если программа не устанавливалась на Windows XP, те же действия повторялись в Windows 7. Все проверки проводились для ситуации, когда СКУД находится в локальной сети и установлена с параметрами по умолчанию. Уязвимым я считал ту СКУД, к СУБД которой удалось подключиться и увидеть внутренности базы.

Результаты исследования

После завершения всех манипуляций я получил следующие результаты:

1. Двенадцать из двадцати пяти СКУД-решений имели такой недостаток. Это APACS 3000, ENT Контроль, KODOS, LyriX, Сфинкс, Castle, Elsys BASTION, Tempo Reale, АВАНГАРД, КРОНВЕРК Реверс, Стражъ, Электра-АС.
2. В остальных протестированных СКУД такой особенности, к счастью, не было выявлено. Это Шэлт ПРО, БИТ, Gate, Golden Gate 2002, ParsecNET, Perco, QUEST II, RusGuard, Smartec-Timex, Biosmart, ITV-Интеллект, Болид-ОРИОН ПРО, Сторк.

Эксплуатация

Около половины (12 из 25) рассмотренных систем оказались подвержены данной уязвимости, а это означает, что шанс встретить в реальной жизни СКУД-сервер с открытым 3050-м портом достаточно велик. Поэтому давай посмотрим, что можно сделать, если вдруг ты обнаружил в своей локальной сети такую машину.

Найти FireBird

Первое, с чего следует начать, и что будет делать злоумышленник, — это искать во внутренней сети компании открытый 3050/tcp порт. Для этого можно воспользоваться легендарным сканером nmap, запустив его с такими ключами:

nmap -sS -p3050 --open 192.168.0.0/24

В результате сканирования nmap выведет список хостов из сети 192.168.0.0/24, на которых открыт tcp порт 3050 (результат сканирования представлен на рисунке 1).

Соответственно, адресация сети у каждого будет своя, но принцип поиска один и тот же.

Подключиться к Firebird

Обнаружив в сети машинy (или машины) с установленным сервером Firebird, попробуем к ним подключиться. Сделать это можно с помощью программы IBExpert. Забегая вперед, скажу, что для ее работы с «огненной птичкой» понадобится библиотека fbclient.dll (чтобы ее получить, установи Firebird-сервер на свою машину или скачай из Интернета). После установки пробуем подключиться к каждому найденному серверу. Для подключения потребуется знать логин, пароль и путь к БД на самом сервере. Логин и пароль будем использовать дефолтные (SYSDBA:masterkey), а путь к БД, скорее всего, с очень высокой долей вероятности окажется стандартным (пути к БД различных СКУД представлены на рисунке 2).

[ad name=»Responbl»]

Правда, так как в тестировании участвовали демо-версии, то не все пути на рисунке 2 будут соответствовать расположению баз в полноценных версиях. В любом случае, практически всегда есть вариант установить себе интересующую СКУД и посмотреть, какой она использует путь по умолчанию. Узнать название СКУД достаточно просто: можно спросить прямо, какая используется СКУД, можно попросить совета у безопасника: «Какая СКУД лучше?», и он сам все расскажет. Можно подсмотреть иконку или очертания интерфейса на мониторе на КПП. Иногда на считывателях карт есть значок производителя ПО. А можно просто перебрать все стандартные варианты, их немного.

Разобраться в структуре БД

Итак, мы подключились к БД напрямую и теоретически можем делать все, что хотим — даже то, что не позволяет сделать официальный интерфейс администрирования. Но чтобы взаимодействовать со СКУД через FB-сервер, нужно разобраться в формате БД, а сколько СКУД, столько и разных форматов хранения информации в базе данных. Поэтому, чтобы избежать абстрактного разговора, все дальнейшие действия мы будем рассматривать на примере СКУД ENT Контроль. В других системах будет практически все то же самое.

Прежде всего для подключения к серверу СКУД нам понадобится клиентская программа под конкретную версию. Еще нужно знать IP, логин, пароль. IP мы уже нашли с помощью сканера портов, а вот логин и пароль от интерфейса СКУД нам не известны, но их можно узнать из БД. В таблице FB_UZP хранятся данные для авторизации пользователей управления СКУД (см. рисунок 5).

Логин хранится в открытом виде, а пароль — в виде хеша (md5). Тут мы можем поступить разными способами:

1. Сбрутить хеши и узнать пароли (привет cmd5.ru).
2. Заменить хеш нужного пользователя на известный нам, например, c4ca4238a0b923820dcc509a6f75849b, что соответствует паролю 1.
3. Создать нового пользователя со своим паролем/хешем.

Выбор за тобой, только после всех этих действий не забудь сделать Commit, чтобы все изменения были сохранены.

Теперь подключаемся к серверу с помощью официального клиента.

И получаем доступ к панели администрирования СКУД как легальный админ.

Конечно, работая с БД напрямую, можно делать намного больше, чем через GUI. Зато интерфейс позволяет удобней и быстрей выполнять официально разрешенные действия.

Создание ложных событий СКУД

Давай попробуем разыграть самый безобидный сценарий — подправим себе время посещения. Для начала нужно по ФИО получить ID пользователя, поэтому делаем SQL запрос к серверу:

select * from fb_usr where LNAME='Фамилия'

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

Теперь, зная свой идентификатор (допустим, это 123), заглянем в таблицу, ведущую учет открытия-закрытия дверей: fb_evn. Здесь исполняем второй запрос, который выведет нам все события, связанные с нашей картой-пропуском:

select * from fb_evn where USR=(select ID from fb_usr where ID=123)

Вот, собственно, почти все. Заметь, каждый проход через дверь — это два события: открытие и закрытие двери при проходе. Если речь о входе в контролируемую зону, то это события 2 и 3, если о выходе — события 4 и 5.

Чтобы сымитировать выход через дверь, находим факт выхода через внешнюю дверь компании и меняем для этих двух строчек время на то, когда ты хочешь/должен «уйти» (см. рисунок 12).

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

Угрозы и риски

1. Самый банальный и безобидный риск использования данной уязвимости — правка сотрудниками логов своего рабочего времени. Я сам так делал, когда работал в одной из компаний, где стоит уязвимая СКУД. Успешно правил опоздания и уходы раньше времени, и руководство знало, но никак не могло это проконтролировать или пресечь. Доходило до того, что СКУД могла показать мое присутствие, когда я вообще не вышел в этот день на работу. Соответственно, здесь риск для работодателя — потеря человеко-часов и несоблюдение дисциплины сотрудниками.
2. Еще один вероятный вектор — это изменение профиля доступа самому себе сотрудником компании. Например, у меня на прошлом месте работы было установлено ограничение времени: если не выйти из здания до определенного часа, то останешься запертым внутри. Приходилось звонить на охрану и выслушивать ругательства. Поэтому я себе поменял профиль доступа на профиль без ограничения по времени, вернее, без ограничений вообще, и мог ходить свободно хоть в кабинет гендира. Соответственно, еще один риск — проникновение сотрудника в любое время и в любое охраняемое СКУД помещение для шпионажа, кражи или других злонамеренных действий.
3. Создание новых пропусков — злоумышленник может принести свою карту доступа и добавить ее идентификатор в БД как ID нового сотрудника или, что хуже, привязать ее к существующему сотруднику компании. При этом к новой карте можно прикрепить любое фото, чтобы не вызвать подозрений у бдительной охраны на КПП. Риск — проникновение на охраняемую территорию злоумышленника под видом легального сотрудника компании.
4. Саботаж или отказ в доступности(DoS) — имея доступ к БД, злоумышленник может сменить пароли всех операторов СКУД, чтобы отстранить их от управления и заблокировать все двери на подконтрольной территории. Это полностью парализует перемещение сотрудников между помещениями и, как следствие, остановит важные бизнес-процессы. Вернуть систему в контролируемое состояние не удастся, а отключение СКУД полностью сделает все двери открытыми. Представь, что такая атака случится, когда на территории будут гостить важные клиенты, которые окажутся запертыми вместе с персоналом.
5. Комплексная атака, видеонаблюдение. Многие СКУД поддерживают интеграцию с системами видеонаблюдения или напрямую подключают к себе видеокамеры наблюдения. Таким образом, злоумышленник параллельно несанкционированному проникновению способен отключить произвольную камеру, а система видеонаблюдения не зафиксирует действий нарушителя. Кстати, некоторые производители СКУД имеют свои системы видеонаблюдения, которые зачастую уязвимы так же, как и их СКУД. Скорее всего, получится и фальсификация картинки с камеры, ведь можно подменить одну камеру в БД на другую, «ненастоящую», которая будет транслировать в цикле кусок нужной картинки.

[ad name=»Responbl»]

Иными словами, наличие такой маленькой лазейки в системе безопасности ставит под сомнение целесообразность СКУДа и позволяет злоумышленникам оставаться незамеченным и заниматься шпионажем, пока компания уверена в своем полном контроле над ситуацией.

Elsys BASTION & ENT Контроль

Еще пару слов хотелось бы сказать про Elsys BASTION, поскольку учетная запись SYSDBA вообще никак не используется данной СКУД. Вместо этого используется специально созданный пользователь Firebird APP_ADMIN, как для соединения сервера СКУД с БД, так и для соединения клиентов с БД. В интерфейсе Elsys BASTION есть возможность сменить пароль только для APP_ADMIN. Я попробовал сменить пароль SYSDBA на действующей системе(не демо), и работоспособность системы сохранилась для всех и во всем. Я даже сделал ребут сервера СКУД, чтобы убедиться в этом. Отсюда делаем вывод, что учетка SYSDBA — просто забытая учетка. Смысл сложного пароля для APP_ADMIN теряется, когда в системе всегда присутствует учетка SYSDBA с паролем masterkey.

Что касается пароля APP_ADMIN, то при установке СКУД предлагается задать его пользователю или использовать стандартный. Если выбрать второй вариант, то для всех покупателей будет установлен одинаковый пароль — тоже не лучший вариант.

Еще один момент, который меня заинтересовал в Elsys BASTION — как клиентские приложения некоторых СКУД узнают пароль от базы данных? Ведь я его им не указывал, но они все равно устанавливают соединение с БД напрямую. Когда я разбирался с этим вопросом, мое внимание привлекли продукты ENT Контроль, Сфинкс и Castle.

Сфинкс и Castle в качестве БД используют mysql с пустым паролем сразу после установки. Через интерфейс программы пароль можно установить, но почему-то новый пароль не нужно указывать на клиенте СКУД, который каким-то образом все же соединяется с БД напрямую.

Вот как это работает:

1. Клиентское ПО сначала обращается к серверу СКУД с введенными пользователем логином и паролем.
2. Проверяется валидность пользователя и пароля, если все ок, то идем дальше.
3. Сервер предоставляет данные, необходимые для авторизации на mysql-сервере с правами root.
4. Клиент авторизуется на mysql-сервере под пользователем root.

Это не совсем страшно, но все-таки плохо. Любой пользователь, даже с минимальными правами, сможет получить root и делать все что угодно с БД СКУД даже после того, как его самого совсем удалят. Да и смена пароля от mysql тоже не поможет, ведь злоумышленник легко может закрепиться на сервере, просто добавив еще одного пользователя mysql, про которого никто не будет знать.

С ENT Контроль более тяжелая ситуация. Этот клиент тоже сначала обращается к серверу СКУД и получает пароль от Firebird в открытом виде, но делает он это ДО верификации пользователя. Достаточно подключиться на порт СКУД и вежливо попросить пароль от SYSDBA — и сервер вежливо его предоставит, кем бы ты ни был (см. рисунки 15 и 16).

Практическая эксплуатация очень проста, достаточно telnet-подключения (см. рисунок 16).

Как защититься самостоятельно

Ну а теперь зайдем с другой стороны. Тем, у кого внедрено решение с подобным недостатком, могу посоветовать сменить пароль от SYSDBA. Понадобится программа наподобие IBExpert или IBConsole. Работоспособность после такого изменения может быть потеряна, все зависит от конкретного приложения и его разработчиков.

Вот как это делается, например, через IBExpert:

1. подключаемся к серверу Firebird;
2. нажимаем Tools;
3. нажимаем User Manager;
4. выбираем SYSDBA;
5. нажимаем Edit;
6. указываем новый пароль;
7. нажимаем ОК.

Что касается СКУД с небезопасной авторизацией клиентов, то, на мой взгляд, нужно отказаться от использования данных решений или разрешить соединения к этим портам только с доверенных IP, вынеся СКУД-сервер и его клиентов в отдельный vlan.

Общие замечания

Большинство изученного ПО производит впечатление «сырого» с точки зрения безопасности, сделанного на скорую руку, порой даже без примитивных мер защиты. Так и чувствуется мысль программиста: «Только я один знаю, как это написано, а значит, никто не разберется, что к чему. Можно лениться и писать как угодно». Именно поэтому, я думаю, Reverse Engineering СКУД-решений выявит серьезные уязвимости.

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

Выводы

Подводя итоги, хочу отметить следующее:

1. Мое небольшое исследование еще раз подтвердило, что производители, которые действительно заботятся о безопасности своих клиентов, должны отдавать свое ПО на аудит в стороннюю профильную компанию для выявления уязвимостей. Поскольку продаваемая программа постоянно развивается, контроль за «неуязвимостью» должен быть частью процесса разработки. Имеет смысл и смена непосредственных технических аудиторов, что только повысит надежность результата от разных специалистов и экспертов.
2. Ясно прослеживается необходимость в каком-либо отличительном признаке, по которому покупатель мог бы опознать проверенное ПО и сделать осознанный выбор. Иными словами, нужно выделить производителей, которые тратят часть бюджета на анализ защищенности своих продуктов, среди компаний, которые просто разрабатывают продукт, и непонятно, заботятся ли они о безопасности вообще и насколько эффективно. По-хорошему, компании — даже известнейшие — сами должны быть заинтересованы в том, чтобы отдать свой продукт на аудит, а потом демонстрировать клиентам сертификат о пройденных проверках безопасности.
3. Часто в рамках проведения тестирования на проникновение аудиторы находят уязвимость в стороннем ПО очень известных и серьезных производителей. И столь же часто заказчик «пентеста» просит аудитора не сообщать об уязвимости разработчику уязвимого ПО, обосновывая это фразами вроде «опять мы им за наш счет уязвимость нашли. Сами они ничего не делают. Почему мы должны платить за их уязвимости, а они нет?». Формально заказчики правы: они оплатили работы и результатом работ сами вольны распоряжаться. Такие ситуации нередки.
4. Прикрыть уязвимость иногда можно своими силами.