Дисклеймер

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

Вступление

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

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

Проводя тестирование на проникновения в разных компаниях, я часто встречал открытый 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-версии, которая не открывает порт БД?»


Здесь можно сделать тот же самый вывод, что и из прошлого вопроса.

4.«Есть ли возможность в интерфейсе Вашего ПО изменить пароль на базу данных? Если есть, то как это сделать?»


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

5.«Собираетесь ли Вы в следующих версиях Вашего продукта что-либо менять, касательно данного вопроса?»


6.«Посоветуйте пользователям Вашего продукта, что они могут предпринять сейчас для исправления данной ситуации, когда возможен несанкционированный доступ к БД СКУД?»


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

«Посоветуйте пользователям Вашего продукта, что они могут предпринять сейчас для исправления данной ситуации, когда хеш пароля от их БД СКУД общеизвестен всем?»


Для APACS 3000 и LyriX был получен один ответ на все вопросы:

Итоги опроса

В итоге, я сам стал сомневаться в том, кто виноват в ситуации, когда в локальной сети торчит СКУД с паролем по умолчанию на БД. Я понимаю и разработчиков и пользователей, но все же склоняюсь больше в сторону бОльшей ответственности разработчиков. СКУД сейчас есть в любой компании, такое ПО просто необходимо даже непрофессионалам в IT, поэтому продавать «уязвимое из коробки» решение не стоит. В ином случае, каждый такой СКУД должен внедрятся профессионалом, который «прикроет» уязвимости, описанные выше. Очевидно, что сами клиенты не сверлят дырки в стенах, а значит и СКУД им тоже внедрил кто-то со стороны, и при этом не озаботился его безопасной настройкой: «Работает и ладно!»

Дополнительное исследование

Однако, по результатам опроса у меня возникли и новые другие вопросы:

1. Действительно ли везде можно поменять стандартный пароль SYSDBA от БД, сохранив работоспособность СКУД?
2. Откуда клиентское приложение СКУД знает пароль от БД, если оно его не спрашивает, но соединяется с БД?

Разбираемся с первым вопросом:



Что я тут могу добавить:

К сожалению, некоторое исследуемое ПО присутствует у меня в виде демо-версии и порой очень сложно понять: нет этой функции вообще или она отсутствует только в демо-версии? Места, где у меня возникли сложности с ответом, я выделил серым цветом в таблице.

В итоге без потери работоспособности сменить пароль удалось у:

— APACS 3000 и LyriX
— ENT Контроль
— Сфинкс
— Castle
— Elsys BASTION
— АВАНГАРД и Стражъ

Для остальных не удалось сменить пароль, но возможно это связано с демо-версией, а может и нет.

Например, для Электра-АС и Шэлт ПРО в четвертом вопросе опроса подробно описывается механизм смены пароля SYSDBA, однако через демо-версию, скаченную с сайта сделать этого не удалось.

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

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

А вот и сам хеш пользователя APP_ADMIN:



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

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

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



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

Более тяжелая ситуация с ENT Контроль.

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



Практическая эксплуатация очень проста, достаточно telnet-подключения:

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

Вообще, использовать для работы клиентов прямое соединение с базой данных под общей для всех пользователей учеткой – мягко говоря, небезопасно. Нужно хотя бы завести учетные записи пользователей, как учетные записи пользователей БД. Это тоже не лучшая затея, т.к. сделать разграничение прав пользователей СКУД средствами базы данных не всегда удастся, обнаружатся «подводные камни». По хорошему, с БД должен общаться только сервер СКУД, а все клиенты должны работать с базой данных только через СКУД-сервер, например, посредством API. Это позволит грамотно и точно разделять права пользователей, так детально, как не позволит разделение пользователей в БД. А также не позволит провернуть такие примитивные штуки, как я только что показал. И все это касается всех разработчиков СКУД, а не только тех, у кого по умолчанию пароль стандартный.

Что не сделано

Еще я хотел сделать кучу разных интересных проверок и исследований, которые могли бы выявить еще больше тех или иных недостатков ИБ. Но, к сожалению, у меня нет столько свободного времени и ресурсов, чтобы так долго заниматься трудоемкими исследованиями бесплатно. К тому же, все описанное в этой статье может оказаться «цветочками», по сравнению с тем, что выявит Reverse Engineering, но для этого нужно законное разрешение владельца программы.

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

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

Причины таких уязвимостей

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

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

Тоже самое касается и защиты трафика СКУД от снифинга: её просто нет. Так писали код в 90-х, но на дворе уже 2015 год. Пора внедрять шифрование трафика и безопасную авторизацию, ведь системы СКУД и видеонаблюдения – критические и очень важные системы, призванные защищать компанию от злоумышленников. А сейчас любой школьник может устроить атаку на перехват трафика.

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

Все это говорит о устаревших подходах к программированию.

Разработчикам часто довольно сложно критично смотреть на свой продукт с точки зрения безопасности. Я это знаю по аналогии с тестированием на проникновение в сети компаний. Администраторы, настроившие сеть, имеют немного “замыленный” взгляд на неё, и посмотреть на нее со стороны трезвым и критическим взглядом бывает сложно, к тому же, их учат одним вещам и подходам, а злоумышленник использует совсем другие знания, подходы и методы мышления, абсолютно бесполезные для повседневной работы администратора или разработчика. Поэтому, в грамотно выстроенном процессе разработки присутствует этап обязательного тестирования и существуют специальные сотрудники-тестировщики, которые производят тестирование ПО в соответствии с заранее написанными тестами, в том числе и тестами безопасности. Или же можно отдать тестирование на аутсорсинг компаниям, которые специализируются на этом.

Еще одна причина в возникновении неловких ситуаций – легкомысленность покупателя и сетевых администраторов. Грамотный администратор не будет действовать по принципу «установил и забыл» или на слово верить всему, что говорят продавцы. Необходимо самостоятельно убедиться в безопасности всех настроек и понять, как работает ПО, просканировать порты, почитать в интернете, какие стандартные пароли используются в таких базах данных и все проверить. Запустить Wireshark и посмотреть на трафик приложения – дело 5 минут и не требует особых познаний в области IT. Эти 5 минут, возможно, сэкономят вам время и ресурсы в будущем. Да и разработчик будет рад улучшить свой продукт, если вы выявите что-то подозрительное.

Мнения экспертов

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

Представители бизнеса

АЛЕКСЕЙ КУЧИН, Руководитель IT Московского офиса ОАО «Акрон» (www.acron.ru)
О компании:
Группа «Акрон» входит в число крупнейших мировых производителей минеральных удобрений. «Акрон» — крупная международная компания с большим числом офисов, филиалов, заводов и складов по всей России и всему миру. Свыше 15 000 сотрудников в 6 странах мира.

Комментарий:

Тема статьи наводит на противоречивые выводы.

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

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

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

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

ВИТАЛИЙ ТЕРЕНТЬЕВ, директор департамента специальных проектов HeadHunter (hh.ru):
О компании:
HeadHunter — российская компания интернет-рекрутмента, развивающая бизнес в России, на Украине, в Белоруссии, Казахстане, Литве, Латвии и Эстонии.

Комментарий:

1. Очень не высокий порог для использования уязвимости, в IT компаниях много людей для которых это легко решаемая задача, иногда просто из баловства. Как результат, это долгое время нарушений связанных например с контролем рабочего времени сотрудников.

2. Сложность в обнаружении нарушения, вызванная свойством самой уязвимости.

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

ПАРХОМОВ ВЛАДИСЛАВ, Член Правления ИХ «Финам» (finam.ru):
О компании:
Холдинг «ФИНАМ» — российский брокер. «ФИНАМ» работает на биржах, ведёт доверительное управление денежными средствами, инвестирование на валютном рынке Forex. Представительства компании в 90 городах по всему миру.
Комментарий:

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

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

Дмитрий Буданов, Генеральный директор Elite Security (elite-security.ru):
О компании:
«Элит Секьюрити» входит в число немногих крупных частных охранных компаний, работающих на территории России, стран Европы и СНГ. Более 25 представительств с общей численностью сотрудников, превышающей 5000 человек.
Комментарий:

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

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

Что касается самих производителей, то уязвимыми в статье считаются СКУД, которые не нашли массовое распространение у нас в стране. Ведущие же решения: Bolid, Gate, Parsec, Perco, Quest занимают подавляющую часть рынка СБ и, если бы эта статья затрагивала их, полезность ее была бы выше.

Разработчики других СКУД систем

Семён Пивоваров, Руководитель отдела поддержки клиентов и тестирования продукции Parsec ( parsec.ru ):
Комментарий:

«1) Почему Ваше решение оказалось без данных уязвимостей? Что Вы предпринимаете для защиты своего ПО?

Так как наша система сделана в формате 3-х звенной архитектуры, то доступ к СУБД должен иметь лишь сервер приложений, остальные модули с БД напрямую никак не контактируют.

В результате мы не требуем возможности сетевого доступа к БД и по-умолчанию при установке экземпляра MS SQL Server из нашего дистрибутива не активируем сетевые протоколы TCP/IP и Named pipes. Доступ сервера приложений к базе осуществляется под специально создаваемой на этапе установки для этих целей SQL-учётной записью, у которой есть доступ лишь к базам Parsec.

Пароль этой учётной записи также не является статическим, а генерируется для каждой новой установки случайным образом. Права администратора нужны нам только при развёртывании приложения и его обновлении, для обычной работы системы этого не требуется.
При первичной установке системы в случае установки нашего экземпляра SQL Server (есть возможность поставить базы на существующий инстанс) мы требуем от пользователя задать пароль системного администратора SQL Server (sa) поскольку автоматическое задание какого-то стандартного пароля – это дыра в системе безопасности, а перекладывать на плечи пользователей смену пароля мы посчитали излишним и совсем ненужным шагом.

Вторая причина такого решения – если в системе действуют политики паролей, то наш стандартный пароль может не пройти требования политики и установка ПО не пройдёт.

Конечно, есть и минусы в таком подходе – если пользователи забыли пароль SA и нет аккаунта Windows с админскими правами, а с базу нужно администрировать, то поможет только нелинейная процедура сброса пароля администратора SQL, которую Microsoft предлагает для подобных случаев, либо переустановка SQL Server.

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

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

2) Что Вы думаете об уязвимых продуктах конкурентов? В чем причины такой ситуации на Ваш взгляд?

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

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

3) Что касается хранения паролей пользователей системы в базе – конечно нельзя их хранить в открытом виде.
Мы воспользовались при разработке системы безопасности паттерном ProviderBase, который появился в .NET Framework 2.0. Реализовав его мы автоматически получили современный и наиболее защищённый механизм хранения паролей в виде «солёного» хэша.

Голубкин Егор, Руководитель группы программных разработок ООО «Прософт-Биометрикс» ( bio-smart.ru ):
Комментарий:

1) Почему Ваше решение оказалось без данных уязвимостей? Что Вы предпринимаете для защиты своего ПО?

При проектировании и разработке Biosmart-Studio v5 мы учитывали требования к защищенности нашего продукта, поэтому таких ошибок не допускали. Наша система имеет клиент-серверную архитектуру, БД мы используем PostgreSQL, доступ к серверу БД открыт только для локальных коннектов. Клиентское ПО доступ к БД не имеет. Если есть необходимость открыть доступ к БД, например для внешнего сервера интеграции, мы создаем отдельного пользователя с ограниченными правами доступа, и указываем список ip адресов, с которых разрешен коннект.

2) Что Вы думаете об уязвимых продуктах конкурентов? В чем причины такой ситуации на Ваш взгляд?

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

Проблем может быть несколько:

1) Архитектурные просчеты при проектировании, в результате которых клиентское ПО имеет непосредственный доступ к БД. В такой реализации очень сложно безопасно работать с БД.

2) Некоторые решения разрабатывается довольно длительное время и имеет старую кодовую базу, используют устаревшие программные решения, развиваются медленно, так как сложно и трудоемко поддерживать legacy код. Тяжело поддерживать современный уровень программного продукта при использовании старых решений.

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

Игорь Фаломкин, Руководителем департамента разработки «ITV | AxxonSoft» (axxonsoft.com):
Комментарий:

«Обеспечение информационной безопасности на конкретном предприятии обязанность службы, эксплуатирующей систему безопасности/контроля доступа. Задача разработчиков оборудования и ПО — дать возможность настроить систему таким образом, чтобы несанкционированный доступ к информации был невозможен. Это касается и используемых СУБД. После установки программного обеспечения администратор системы должен изменить пароли по умолчанию для пользователей, создаваемых СУБД автоматически. Таким образом, из перечисленного списка уязвимым можно считать только то программное обеспечение, которое не допускает работы с измененными паролями используемых пользователей СУБД.

Дмитрий Савельев, Директор департамента обучения и развития дилерской сети «PERCo» (perco.ru):
Комментарий:

Наше мнение по озвученной Вами проблеме полностью совпадает с приведенным в статье ответом наших коллег из компании Apollo.

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

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

Наша компания всерьез озаботилась этим вопросом несколько лет назад. Именно тогда на базе ведущих технических ВУЗов страны и ближнего зарубежья мы создали практические лаборатории для изучения сетевых систем безопасности PERCo. Сейчас получить подобную квалификацию можно в следующих ВУЗах:

МГТУ им. Баумана, Москва,
Университет телекоммуникаций им.Бонч-Бруевича, Санкт-Петербург,
Воронежский Институт МВД,
Университет Государственной Пожарной Службы, Санкт-Петербург,
Уральский Федеральный Университет, Екатеринбург,
Новосибирский ГТУ,
Казахский Национальный Универсистет,
Suleyman Demirel University, Алмата,
и еще нескольких федеральных институтов.
Мы рассчитываем, что в ближайшие годы ситуация, описанная вами в статье, серьезно изменится и стандартные root:root будут уже большой редкостью.

Представители ИБ-компаний и независимые ИБ-эксперты

Качалин Алексей, эксперт по ИБ:
Комментарий:

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

Брызгин Андрей, Руководитель направления аудита и консалтинга «Group-IB» (group-ib.ru):
О компании:
Group-IB — одна из ведущих международных компаний по предотвращению и расследованию киберпреступлений и мошенничеств с использованием высоких технологий; первый российский поставщик threat intelligence решений, вошедший в отчеты Gartner. Одна из 7 самых влиятельных компаний в области кибер-безопасности по версии Business Insider. Компания, рекомендованная Организацией по безопасности и сотрудничеству в Европе (ОБСЕ). Официальный партнер Еuropol, полицейской службы Евросоюза.

Комментарий:

На примере систем контроля и управления доступом статья вскрывает ряд проблем информационной безопасности, характерных для самых разных сфер деятельности, в которых на данном этапе времени активно внедряются технологии автоматизации и уждалённого управления. Недостаточная защита баз данных от доступа извне и из локальных сегментов сети, предсказуемая или встроенная в код авторизационная информация (hardcoded credentials), эти и многие «глупые» ошибки и мы видим регулярно как врамках аудиторских проектов, так и в процессе изучения документации на системы обработки информации, используемые в рамках CRM/ERP-систем, крупных порталов, интернет-банкинга и даже АСУТП/SCADA. Таким образом, поднятые в статье проблемы безусловно являются актуальными.

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

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

МИХАИЛ КОРЕШКОВ, Консультант по ИБ и СТМ:
Комментарий:

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

В данном случае (управление доступом), разработка надежного железа не снимает необходимости разрабатывать безопасное ПО. Существуют тысячи комплексов защиты, которые нуждаются в беспристрастном тесте, от систем периметральной защиты до CCTV, который должна заказывать сама организация – разработчик. Современные условия показывают динамически меняющиеся угрозы и повышение среднего уровня компьютерной и технической грамотности нарушителей, что обуславливает необходимость анализировать и применять в разработке широкий спектр вводных данных и интегрировать новые решения в системы защиты. Данный тест дает понимание о довольно широком спектре предоставляемых комплексов и необходимости добровольного экспертного тестирования систем безопасности, которые разрабатываются и выходят на рынок, аналогично получению «знака качества». Комплексные тесты систем безопасности на уязвимость должны проводиться сторонней организацией, а не разработчиками, данная статья показывает эту необходимость в полном объеме.

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

Алексей Лукацкий, Security Business Development Manager at Cisco Systems ( cisco.com ):
О компании:
Cisco — американская транснациональная компания, разрабатывающая и продающая сетевое оборудование, предназначенное в основном для крупных организаций и телекоммуникационных предприятий. Одна из крупнейших в мире компаний, специализирующихся в области высоких технологий. Изначально занималась только корпоративными маршрутизаторами.

Об авторе комментария:
Алексей Викторович Лукацкий – известный бизнес-консультант по безопасности.

Комментарий:

Да, это проблема, типичная для разработчиков софта

Почему покупателям сложно обнаружить уязвимости

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

Сложности обнаружения уязвимостей

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

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

Второй проблемой в обнаружении и тем более исправлении уязвимостей является законодательство. Наше законодательство и законодательство большинства других стран запрещает производить Reverse Engineering без согласия правообладателя ПО. (Reverse Engineering — это процесс изучения внутренностей ПО с помощью дизассемблера). Я могу придумать объяснения, зачем создан такой закон — для противодействия взлому. Но у него есть и обратная сторона — закрытость программы для изучения позволяет разработчикам предоставлять некачественные услуги и товар, притом покупатель не имеет права проверить качество и безопасность товара.

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

Выводы

1. Аудит–необходимость
Производители, которые действительно заботятся о безопасности своих клиентов, должны отдавать свое ПО на аудит в стороннюю профильную компанию для выявления уязвимостей. Учитывая, что продаваемая программа постоянно развивается, контроль за «неуязвимостью» должен быть частью процесса разработки. Имеет смысл и смена непосредственных технических аудиторов, это только повысит надежность результата от разных специалистов и экспертов.

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

3. От уязвимостей не застрахован никто
Часто в рамках проведения тестирования на проникновение аудиторы находят уязвимость в стороннем ПО от очень известных и серьезных производителей ПО. И так же часто заказчик “пентеста” просит аудитора не сообщать об уязвимости разработчику уязвимого ПО, обосновывая это тем, что: “опять мы им за наш счет уязвимость нашли. Сами они ничего не делают. Почему мы должны платить за их уязвимости, а они нет?”. Формально они правы, они оплатили работы и результатом работ сами вольны распоряжаться. Такие ситуации нередки.

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

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

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



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

Соболев Евгений
«Practical Security Lab» / «Лаборатория Практической Безопасности»
itpsl.ru / itpsl.org