[Из песочницы] Безопасность средств безопасности: СКУД15.02.2016 17:03

Дисклеймер

Материалы, приведенные ниже, несут исключительно научно-исследовательский характер. Данное исследование проводилось автором исключительно в научно-исследовательских целях, его результаты не являются и не могут признаваться руководством к совершению каких-либо противоправных действий. При проведении исследования автор действовал в рамках законодательства Российской Федерации. Использование результатов исследования допускается исключительно в научно-ознакомительных целях. Использование результатов исследования для достижения противоправного или любого иного от научной деятельности результата может повлечь за собой уголовную, административную и (или) гражданско-правовую ответственность. Автор не несет ответственность за инциденты в сфере информационной безопасности, имеющие отношение к тематике исследования.

Вступление

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

Как я к этому пришел

Проводя тестирование на проникновения в разных компаниях, я часто встречал открытый 3050/tcp порт базы данных Firebird (далее FB) с логином и паролем по умолчанию: «SYSDBA; masterkey». Изучая данные хосты, я выяснил, что это могут быть совершенно разные решения и программы, использующие FB: от бухгалтерского ПО и CRM-систем до систем видеонаблюдения и контроля доступа, и даже ДБО. Через данный порт доступна вся БД соответствующего ПО, и, редактируя ее, можно влиять на логику работы приложения.

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

Т.к. алгоритм шифрования пароля «зашит» в самом ПО, то смысл шифрования теряется, т.к. используются обратимые алгоритмы шифрования, которые легко узнать, имея образец ПО на руках. А хеширование усложняет процесс, но ненамного.

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

Для исследования мне показались интересны системы СКУД и видеонаблюдения, системы ДБО, бухгалтерское и финансовое ПО. Но в данной статье пойдет речь только о СКУД. Используя подобные уязвимости для систем СКУД, любой участник локальной сети может открывать\закрывать любые двери, нарушать пропускной режим. В общем, все то, что может администратор СКУД и даже больше!

Методология исследования

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

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

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

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

Всего в исследовании участвовало 25 СКУД решений:

Дополнительно в качестве подтверждения уязвимости приведены скриншоты успешного подключения к БД (по пунктам для каждого СКУД).

Уязвимость не всегда опасна

Стоит также отметить, что не во всех случаях такая уязвимость представляет большой риск. Если подобные уязвимые системы используются, например, на подземной парковке жилого дома\комплекса, где сидит 1–2 охранника на КПП, то риска здесь почти никакого нет, т.к. для того, чтобы воспользоваться данной уязвимостью, нужно иметь доступ в локальную сеть, где находится компьютер с сервером СКУД. В случае с парковкой, просто некому воспользоваться таким недостатком, кроме как самим охранникам, которые и без этого имеют санкционированный доступ к системе. Другое дело, когда речь идет о большом офисе или организации, где есть непривилегированные пользователи и помещения куда ходить им нельзя: заводы, госорганы, средние и крупные компании и т.д.
Для того, чтобы оценить распространённость данной уязвимости, просканировать интернет на FB будет мало, т.к. здравомыслящий человек не будет вывешивать СКУД в интернет, а нормальная компания-производитель СКУДа напомнит клиенту об опасности такого размещения. Поэтому судить о распространённости можно только по добровольным раскрытиям информации, например, по отзывам на продукты. Конечно, стоит отметить, что этой информации нельзя доверять на 100%, т.к. не понятно, используется ли то решение сейчас и в каком виде.

Также, по отзывам и благодарностям нельзя утверждать, что вообще это решение используется в компании-источнике отзыва, или о масштабе его применения в компании. Оно может быть применено всегона одну дверь или на маленький удаленный офис большой корпорации. В конце концов, сами организации могли изменить настройки ФБ сервера, чтобы он был доступен только для localhost или иначе решить эту проблему, и такие примеры у меня есть.

Кто, возможно, имеет уязвимые системы на примерах:

— Зимние Олимпийские Игры-2014
— ГАЗПРОМ, SYNTERRA, InfoTeCS и другие крупные и известные компании…
— Банки
— Заводы
— Космодром
— Аэропорты
— Склады
— ГУВД и другие государственные структуры…
— Провайдеры
— Религиозные общины

Например:

1. 1-й Государственный испытательный космодром (г. Мирный)
2. AZIA Group Technology
3. BIOMAN
4. Dr.Oetker
5. DSSL» (Trassir) — Приволжье
6. EAST LINE
7. ENKA («Энка Ишаат Ве Санайи Аноним Ширкети»)
8. Expert Security Systems
9. RB Service Home Network
10. SPAR
11. SYNTERRA
12. XCOM
13. Zoneco
14. «СпорткарЦентр»
15. Абсолют СБ
16. АО «Императорский фарфоровый завод»
17. АСБ-Комплект
18. Аэропортовый комплекс Домодедово
19. Аэропорты в городах Мурманск, Пермь
20. Банк ВИЗАВИ
21. Банк Москвы
22. Банк Развитие-Столица
23. Банк Снежинский
24. Банк: Промышленно-Торговый банк
25. Безопасность Он-Лайн
26. Бизнес центр Ducat Place ll
27. В центральном офисе и одном из супермаркетов сети «Атак»
28. Газпром
29. ГАЗПРОМБАНК
30. Группа СЕБ МУЛИНЕКС
31. ГУВД по СПб и ЛО
32. Дата-Пермь
33. ЗАО «Аэрофест» в аэропорту Шереметьево-2
34. ЗАО «Белорусская сеть телекоммуникаций» (БеСТ Life)
35. ЗАО «Керама-Марацци»
36. Зимних Олимпийских Игр-2014
37. ИСБ
38. КАМАЗИНСТРУМЕНТСПЕЦМАШ (Г. НАБЕРЕЖНЫЕ ЧЕЛНЫ)
39. Компания Fujitsu
40. Комплексные Системы Безопасности
41. Конт
42. Куб-Системы проект
43. Морская ледостойкая стационарная платформа «Приразломная»
44. МосКабельМет
45. Московский Областной Научно-Исследовательской Клинический Институт им. М.Ф. Владимирского (МОНИКИ)
46. Московский театр «Ленком»
47. НПК «Биос»
48. ОАО «Вертолетная сервисная компания» (100% дочерняя структура ОАО «ОПК «Оборонпром»)
49. ОАО «КИРОВСКИЙ ЗАВОД».
50. ООО «Газпром бурение»
51. ООО «Газпромнефть-ЮГ»
52. ООО «Данон Индустрия»
53. ООО «Рамэнка»
54. ООО «СВЯЗЬСПЕЦПРОЕКТ»
55. ООО «Сименс Бизнес Сервисез» в г. Воронеже
56. ООО «ФОЛЬКСВАГЕН Груп Рус»
57. ООО НПО «Городские системы»
58. ОСМП (центральном офисе «Объединенных систем моментальных платежей»)
59. Открытое акционерное общество «Белорусский металлургический завод»
60. Паркинги жилых комплексов компании «ЮИТ ДОМ» и СГ «Эталон»
61. Предприятия ХК ОАО «ФосАгро»
62. Профавтоматика
63. Растр
64. Религиозная община «Приход в честь Всех Святых в г. Минске Минской Епархии Белорусской Православной Церкви»
65. Росморпорт
66. Рубеж-92
67. САНТЕХПРОМ
68. Сателлит Урал
69. Сатро-Палладин
70. САТУРН
71. Сиддхи Секьюрити
72. Складские логистические комплексы ОАО «Интертерминал» (Санкт-Петербург)
73. Совершенные системы
74. Сонопресс
75. Специалист Безопасности
76. Тел
77. Теплосеть Санкт-Петербурга
78. ТеплоЭлектроЦентраль №25
79. ТНК КарелияНефтеПродукт
80. Триада СТ-В
81. Трэйд Телеком
82. Уфанет
83. финансово-Расчетного Центра АО «АвтоВАЗ»
84. ЦБ РФ по Томской области
85. Цербер
86. Элси
87. Элтра
88. Энерго-Альянс
…

И многие другие объекты.

Пример эксплуатации

А теперь давайте разберём, насколько сложно воспользоваться данной уязвимостью. Я считаю, что для этого не нужно владеть какими-то особыми знаниями, все делается общедоступными инструментами и за пару минут.

Найти сервер FireBird

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

nmap -sS -p3050 --open 192.168.0.0/24

В ответ через некоторое время nmap выведет все открытые порты 3050/tcp, которые нашел в сети 192.168.0.0/24:

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

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

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

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

Разобраться в структуре БД используемого СКУД

Для того что бы сделать что-то со СКУДом через FB-сервер, нужно разобраться в формате БД. Сколько СКУДов, столько и разных форматов хранения данных в базе данных.

Начнем с простого.

Доступ в официальный интерфейс администрирования СКУД

Чтобы подключиться к серверу СКУД, нам понадобится клиентская программа для конкретной версии. Возможно, некоторые СКУД через официальный клиент поддерживают только локальное подключение, я не знаю, не проверял. Чтобы подключиться нам понадобится: ip, логин, пароль. IP мы уже нашли с помощью сканера портов, а вот логин и пароль от интерфейса СКУД нам не известны, но их можно узнать в БД СКУД. Для примера разберем на примере СКУД ENT Контроль, мой любимый СКУД.

В таблице «FB_UZP» хранятся данные для авторизации пользователей управления СКУД:

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

1. Сбрутить хеши и узнать пароли, привет, cmd5.ru:

2. Заменить хеш существующего пользователя на известный нам, например «c4ca4238a0b923820dcc509a6f75849b» обозначает пароль »1».

3. Создать нового пользователя со своим паролем\хешем.

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

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

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

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

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

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

select ID from fb_usr where LNAME=’Фамилия’

Выполнить его можно нажав вот эту кнопку:

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

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

select * from fb_evn where USR=(select ID from fb_usr where LNAME=’Фамилия’)

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

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

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

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

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

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

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

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

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

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

Реакция разработчиков

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

В целом, большинство разработчиков не сочли ситуацию выше своей проблемой, многие проигнорировали мои вопросы, хотя знали, что я пишу статью об их продукте. Некоторые воспринимали мой звонок в компанию как игру, пытались «выкрутиться» и лгали, объясняя, что FireBird у них используется только в бесплатной версии ПО, а в платной у них все хорошо и что им даже не интересно, что я там у них нашел. В итоге, конечно, все оказывалось совсем не так. Подобные «скользкие» разговоры проходили с людьми, которые продают продукт, но я хорошо понимаю, о чем говорю и поэтому уболтать меня не удавалось. Представляю, как тяжело обычному клиенту компании вывести таких продавцов на «чистую воду».

С технарями все гораздо проще. Техподдержка в основном сразу понимала, о чем речь, и просила все заворачивать на почту, правда, большинство таких «заворотов» заканчивалось игнорированием писем. Но бывали и такие случаи, когда тех.поддержка упорно не могла осознать, что, помимо пароля от СКУД, есть пароль от FireBird, и на него можно зайти не через интерфейс ПО.

Бывало, что компания после первого телефонного контакта не отвечала на письмо, а когда я снова позвонил в компанию, чтобы понять, что случилось — слышал в ответ: «Ааа… Да-да-да. Наши программисты сказали, что нам это не интересно. Что можно не отвечать на такие письма.».

Что это такое? Желание программистов пресечь распространение такой информации к своему начальству? Или полное безразличие к качеству своей работы, все равно «никто не понимает, как это работает»?

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

Результаты опроса компаний:

1. «Является ли открытый на внешнем интерфейсе сетевой карты порт 3050/tср с логином и паролем «SYSDBA; masterkey» уязвимостью или недостатком безопасности и почему?»

Для Шэлт ПРО первый вопрос был другим:

«Является ли открытый на внешнем интерфейсе сетевой карты порт FireBird с одинаковым для всех клиентов паролем — уязвимостью или недостатком безопасности и почему?»

Из данных ответов можно сделать следующие выводы и предположения:

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

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

— Разработчики перекладывают на Вас ответственность по контролю защищенности их продукта.

Мое мнение: Это частично правильно, т.к. если Вы захотите настроить СКУД небезопасно — Вы это сделаете и разработчик тут будет не причем. Однако, на мой взгляд, разработчики недостаточно информируют клиентов о том, что пароль от БД можно сменить и о том, что это НУЖНО сделать сразу после установки. Ведь с одной стороны клиент может сам небезопасно настроить СКУД, а с другой он и вовсе не знает что СКУД «из коробки» уже уязвим. Почему пользователей при установке не просят задать пароль от БД, а просто добавляют в техническую документацию строчку о том, что нужно (можно) сменить пароль — я не знаю.

— Часть ПО, очевидно, использует порт FireBird не для связи между сервером СКУД и сервером БД, а для связи между клиентом СКУД и сервером БД. (Иначе как объяснить что порт нужен для удаленных клиентов).

Мое мнение: Зачем тогда спрашивать пароль от пользователя СКУД, если клиентское ПО все равно управляет СКУДом через «SYSDBA; masterkey»? Получается что это «ширма» для отвода глаз, обман.Я проверил, так это или не так, и сильно удивился полученным результатам. Об этом чуть ниже.

Перейдем ко второму вопросу:

2.«Для чего используется в Вашем продукте порт 3050/tcp на внешнем интерфейсе сетевой карты? Можно ли его оставить только на localhost?»

Из данных ответов можно сделать следующие выводы и предположения:

— У многих порт используется для подключения нескольких клиентов с разных рабочих мест.
Мой комментарий: Опять видим, что связь клиентов с БД осуществляется не через промежуточный сервер СКУД, а напрямую через порт FireBird. Что обозначает, что каждый клиент должен знать пароль от FireBird сервера, а пароль и логин пользователя СКУД спрашивается для вида. Любой клиент, может взять сохраненный пароль в клиенте СКУД от БД FireBird и подключится напрямую к базе данных, минуя графическое разделение доступа интерфейса программы.
Предвижу один аргумент: Пароль от FireBird сохранен у клиента всегда, ведь его не вводит пользователь при логине и без него клиент не авторизуется, особенно если пароль по умолчанию сменили.

Третий вопрос:
3.«Почему Вы решили использовать в своем продукте «серверную«версию FireBird, вместо Embedded-версии, которая не открывает порт БД?»