Безпека засобів безпеки: СКУД

Дисклеймер

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

Вступ

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


Як я до цього прийшов

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

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

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

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

Для дослідження мені здалися цікавими системи СКУД і відеоспостереження, системи ДБО, бухгалтерське і фінансове. Але в даній статті піде мова тільки про СКУД. Використовуючи подібні уразливості для систем СКУД, будь-який учасник локальної мережі може відкривати\закривати будь-які двері, порушувати пропускний режим. Загалом, все те, що може адміністратор СКУД і навіть більше!

Методологія дослідження

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

Кожен екземпляр встановлювався на віртуальну машину і аналізувався на відкриті порти. Якщо серед іншого з'являвся 3050\tcp порт, то я пробував залогуватися на нього під дефолтних логіном і паролем. Якщо залогуватися під стандартними обліковими даними не виходило, тобто при установці FB-сервера змінило пароль, то я намагався зрозуміти на який саме. Пробував встановлювати ПО декілька разів і дивився: змінювався хеш пароля від FB-сервера чи ні. Якщо він не змінювався, тобто при декількох установках залишався одним і тим же, я будував припущення, що даний пароль є універсальним для всіх установок цього для будь-якого, хто використовує це рішення. Це не краще, ніж використання загальновідомих облікових даних за замовчуванням. Будь-хто, хто встановить собі дане рішення, дізнається хеш від всіх інших клієнтів, що не є правильний і безпечний варіант.

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

Результати дослідження

Всього в дослідженні брало участь 25 СКУД рішень:









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

APACS 3000



ENT Контроль



KODOS

LyriX



Сфінкс



Castle



Elsys BASTION



Tempo Reale

АВАНГАРД



КРОНВЕРК Реверс

Стражъ



Електра-АС



Вразливість не завжди небезпечна

Варто також зазначити, що не у всіх випадках така вразливість представляє великий ризик. Якщо такі вразливі системи використовуються, наприклад, на підземній парковці житлового будинку\комплексу, де сидить 1-2 охоронці на КПП, то ризику тут майже ніякого немає, т. к. для того, щоб скористатися даною вразливістю, потрібно мати доступ в локальну мережу, де знаходиться комп'ютер з сервером СКУД. У випадку з паркуванням, просто нікому скористатися таким недоліком, окрім як самим охоронцям, які й без цього мають санкціонований доступ до системи. Інша справа, коли мова йде про великому офісі або організації, де є непривілейовані користувачі і приміщення куди ходити їм не можна: заводи, держоргани, середні і великі компанії і т. д.

Поширеність уразливості
Для того, щоб оцінити поширеність даної уразливості, просканувати інтернет на FB буде мало, т. к. розсудлива людина не буде вивішувати СКУД в інтернет, а нормальна компанія-виробник СКУДа нагадає клієнту про небезпеку такого розміщення. Тому судити про поширеність можна тільки за добровільним розкриття інформації, наприклад, за відгуками на продукти. Звичайно, варто зазначити, що цієї інформації не можна довіряти на 100%, оскільки не зрозуміло, чи то рішення зараз і в якому вигляді.

Також, за відгуками і подяками не можна стверджувати, що взагалі це рішення використовується в компанії-джерелі відкликання, або про масштаб його застосування в компанії. Воно може бути застосоване всегона одну двері або на маленький віддалений офіс великої корпорації. Зрештою, самі організації могли змінити налаштування ФБ сервера, щоб він був доступний тільки для localhost або інакше вирішити цю проблему, і такі приклади у мене є.

Хто, можливо, має вразливі системи на прикладах:

— Зимові Олімпійські Ігри-2014
— ГАЗПРОМ, SYNTERRA, InfoTeCS та інші великі й відомі компанії…
— Банки
— Заводи
— Космодром
— Аеропорти
— Склади
— ГУВС і інші державні структури…
— Провайдери
— Релігійні громади

Наприклад:

1. 1-й Державний випробувальний космодром (р. Мирний)
2. AZIA Technology Group
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» вразливістю або недоліком безпеки і чому?»

Відповіді на перше питанняENT Контроль
В нашому програмному комплексі використовується порт 3050/tcp, який
необхідний для роботи баз даних Firebird. За замовчуванням логіном і паролем для
бази даних встановлено стандартний «SYSDBA і masterkey». Даний ПІДХІД
зумовлений відкритістю нашого апаратно-програмного комплексу до інтеграції
з іншими системами і можливістю роботи з нашим обладнанням сторонніх
програмістів. Дане рішення не є вразливість системи безпеки,
так як у користувача системи є Документована можливість зміни
пароля підключення до БД.
АВАНГАРД і Стражъ
Не є. Це зроблено свідомо для можливості підключення віддалених клієнтів. Це буде уразливістю в тому випадку, якщо клієнти буде підключатися без жодних засобів захисту типу VPN. Але, слава Богу, ті, у кого є необхідність в таких підключеннях, прекрасно розуміють, як треба підключати віддалених «товстих клієнтів»так, щоб не створити собі проблеми. Пароль і логін за замовчуванням клієнт можна змінювати, якщо він розуміє про що мова.
КРОНВЕРК Реверс
Думаю, немає. Зрозуміло, завжди можна поміняти і логін та пароль адміністратора.
Крім того, зовсім необов'язково відкривати 3050/tcp зовні.
На початку 2000 був скандал зі зломом БД паролів Interbase, вразливість давно вирішено.
Зараз визнано, що використання Firebird є безпечним при дотриманні елементарних заходів безпеки.
Електра-АС
Є, але це в цілому залежить від експлуатуючих СКУД людей. В
документації рекомендується міняти стандартних пароль до БД на секретний.
APACS 3000 і LyriX
Дали спільну відповідь (Наведено нижче)
Elsys BASTION
ВІДМОВИЛИСЯ ВІД КОМЕНТАРІВ
KODOS
ПРОІГНОРУВАЛИ ПИТАННЯ
Сфінкс
ПРОІГНОРУВАЛИ ПИТАННЯ
Castle
ПРОІГНОРУВАЛИ ПИТАННЯ
Tempo Reale
ПРОІГНОРУВАЛИ ПИТАННЯ

Для Шэлт ПРО перше питання був іншим:

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

Відповідь Шэлт ПРОШэлт ПРО
В більшості випадків так, якщо мережа під СКУД не відособлена фізично або логічно і є можливість підключення до сервера бази даних Firebird, а так само якщо є можливість установки з зовнішніх носіїв або скачування їх з мережі (глобальної/локальної). У найпростішому випадку це може привести до втрати даних, якщо немає резервної копії бази, а так само до не санкціонованою доступу на підприємство або спотворення даних. Наприклад, по обліку робочого часу. Варіантів дуже багато і всі вони залежать від цілей зловмисників.

З даних відповідей можна зробити наступні висновки і припущення:

— Багато розробники передбачають, що мережа СКУД повинна бути фізично ізольованою мережею, а тому вона і не потребує захисту її компонентів.

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

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

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

— Частина, очевидно, використовує порт FireBird не для зв'язку між сервером СКУД і сервером БД, а для зв'язку між клієнтом СКУД і сервером БД. (Інакше як пояснити, що порт потрібен для віддалених клієнтів).

Моя думка: Навіщо тоді питати пароль від користувача СКУД, якщо клієнтський ЗА все одно керує СКУДом через «SYSDBA;masterkey»? Виходить що це «ширма» для відводу очей, обман.Я перевірив, так це або не так, і сильно здивувався отриманими результатами. Про це трохи нижче.

Перейдемо до другого питання:

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

Відповіді на друге питанняENT Контроль
Порт 3050/tcp використовується для роботи мережевої SQL бази даних Firebird.
Особливістю мережевих баз даних передбачає одночасну роботу
декількох користувачів з різних АРМ з даними, що зберігаються в базі на
віддаленому сервері або АРМ. Для цього і використовується порт 3050.
АВАНГАРД і Стражъ
Для будь-яких конфігурацій можна, для яких не можна. Наше — це розподілена система з підтримкою одночасної роботи декількох клієнтів одночасно.

КРОНВЕРК Реверс
Тільки на локалхост можна за змістом використання — мережеве ЗА припускає звернення
декількох клієнтських місць до єдиної БД.
Електра-АС
Ви використовували дуже стару версію. У сучасній версії програмний
комплекс працює по локальній мережі на різних комп'ютерах. Тому
сервер БД повинен бути доступний з інших комп'ютерів.
Шэлт ПРО
Звичайно, систему можливо налаштувати на роботу тільки на локальному комп'ютері. Для цього достатньо заблокувати даний порт стандартним Брандмауером Windows для підключення зовні.
APACS 3000 і LyriX
Дали спільну відповідь (Наведено нижче)
Elsys BASTION
ВІДМОВИЛИСЯ ВІД КОМЕНТАРІВ
KODOS
ПРОІГНОРУВАЛИ ПИТАННЯ
Сфінкс
ПРОІГНОРУВАЛИ ПИТАННЯ
Castle
ПРОІГНОРУВАЛИ ПИТАННЯ
Tempo Reale
ПРОІГНОРУВАЛИ ПИТАННЯ

З даних відповідей можна зробити наступні висновки і припущення:

— У багатьох порт використовується для підключення декількох клієнтів з різних робочих місць.
Мій коментар: Знову бачимо, що зв'язок клієнтів з БД здійснюється не через проміжний сервер СКУД, а безпосередньо через порт FireBird. Що означає, що кожен клієнт повинен знати пароль від сервера FireBird, а пароль і логін користувача СКУД питається для виду. Будь-який клієнт, може взяти збережений пароль клієнта СКУД від БД FireBird і підключається безпосередньо до бази даних, минаючи графічне поділ доступу інтерфейсу програми.
Передбачаю один аргумент: Пароль від FireBird збережений у клієнта завжди, адже його не вводить користувач при логін і без нього клієнт не авторизується, особливо якщо пароль за замовчуванням змінили.


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

Відповіді на третє питанняENT Контроль
Дане питання не було поставлено
АВАНГАРД і Стражъ
См. вище.

КРОНВЕРК Реверс
Тому що див. 2. Firebird Embedded використовується в нашому продукті під назвою «РЕВЕРС СТАРТ 8000»,
недолік її використання — додаток, загрузившее Вбудований сервер, володіє БД монопольно — ні про яке
колективному доступі до БД не може бути й мови. Для однокористувальницької системи використання Embedded-версії
цілком виправдано. Крім того, Embedded-версію іноді зручно використовувати для зберігання локальних даних.
Електра-АС
Тому що має розподілену структуру. Зокрема з БД можуть
працювати користувачі з різних комп'ютерів локальної мережі.
Шэлт ПРО
Серверна версія Firebird використовується так як наша система мережева клієнтів та робота з базою даних відбувається в будь-якому випадку, навіть якщо сервер системи не запущено або база даних з сервера Firebird розташовується на окремому сервері, включаючи UNIX.
Так приміром відбувається робота модуля побудови звітів.
APACS 3000 і LyriX
Дали спільну відповідь (Наведено нижче)
Elsys BASTION
ВІДМОВИЛИСЯ ВІД КОМЕНТАРІВ
KODOS
ПРОІГНОРУВАЛИ ПИТАННЯ
Сфінкс
ПРОІГНОРУВАЛИ ПИТАННЯ
Castle
ПРОІГНОРУВАЛИ ПИТАННЯ
Tempo Reale
ПРОІГНОРУВАЛИ ПИТАННЯ

Тут можна зробити той самий висновок, що і з минулого питання.

4.«Чи є можливість у інтерфейсі Вашого ПО змінити пароль на базу даних? Якщо є, то як це зробити?»

Відповіді на четверте питанняENT Контроль
Дане питання не було поставлено. Додам від себе: Так, змінити пароль можна в інтерфейсі сервера. Дуже зручно.
АВАНГАРД і Стражъ
См. вище. В налаштуваннях сервера є відповідна кнопка.

КРОНВЕРК Реверс
Так, звичайно. См. «Адміністратор»СКД «РЕВЕРС»або налаштування сервера обміну СКУД «РЕВЕРС 8000».
Електра-АС
Є.
28.3 Заміна пароля до сервера бази даних
При необхідності Ви можете змінити пароль до сервера бази. Для цього в
головному меню виберіть пункт Настройки – Сервер БД – Паролі. На
відкрилася закладці введіть новий пароль і підтвердження пароля.
Після заміни пароля на всіх робочих станціях і комп'ютерах підтримки
програми редактора або фізичної модуля після запуску запросять новий
пароль. Після першого правильного підключення до бази даних на даному
комп'ютері новий пароль буде записаний у файл Config.ini в зашифрованому
вигляді.
Шэлт ПРО
Дана можливість є в будь-якому з модулів (меню->налаштування->пароль до бази даних)
APACS 3000 і LyriX
Дали спільну відповідь (Наведено нижче)
Elsys BASTION
ВІДМОВИЛИСЯ ВІД КОМЕНТАРІВ
KODOS
ПРОІГНОРУВАЛИ ПИТАННЯ
Сфінкс
ПРОІГНОРУВАЛИ ПИТАННЯ
Castle
ПРОІГНОРУВАЛИ ПИТАННЯ
Tempo Reale
ПРОІГНОРУВАЛИ ПИТАННЯ

Так як не всі розробники відповіли на питання, що виникло припущення, що у деяких розробників змінити пароль, зберігаючи працездатність ПО не можна. Результати такої перевірки будуть наведені нижче.

5.«Чи збираєтеся Ви в наступних версіях Вашого продукту що-небудь міняти, стосовно даного питання?»

Відповіді на п'яте питанняENT Контроль
Так, ми не стоїмо на місці, постійно розвиваємося і збільшуємо функціональні
можливості нашого продукту. Ми прагнемо створити простий, надійний і
багатофункціональний з широким спектром можливостей продукт. Більш того, на
сьогоднішній день створено відділ служби технічної підтримки з
висококваліфікованими працівниками, які надають допомогу всім
нашими клієнтами' як по телефону, так і на місці застосування нашої системи.
Програмісти, за запитом наших клієнтів, індивідуально збільшують
функціонал нашої системи, роблячи її більш функціональною і зручною у використанні.
АВАНГАРД і Стражъ
Час покаже. Поки FireBird при правильному налаштуванні цілком задовольняє існуючим вимогам, для яких він був створений. До того ж у нього найнижча вартість володіння при максимумі можливостей. А для сучасні замовників це не останнє питання. До того ж, якщо раптом у замовника є особлива думка з цього питання — готові обговорювати і вносити для нього ІНДИВІДУАЛЬНІ зміни. Для масового продукту це ні до чого. А за 15 років існування продукту такий досвід є. Поки ніхто із замовників не скаржився. ;)

КРОНВЕРК Реверс
См. п. 1-4.
Електра-АС
Вже реалізовано в сучасних версіях. ЗА підтримує можливість
задати особливий пароль на підключення до БД.
Шэлт ПРО
З цього питання це вже зроблено починаючи з версії 1.10
APACS 3000 і LyriX
Дали спільну відповідь (Наведено нижче)
Elsys BASTION
ВІДМОВИЛИСЯ ВІД КОМЕНТАРІВ
KODOS
ПРОІГНОРУВАЛИ ПИТАННЯ
Сфінкс
ПРОІГНОРУВАЛИ ПИТАННЯ
Castle
ПРОІГНОРУВАЛИ ПИТАННЯ
Tempo Reale
ПРОІГНОРУВАЛИ ПИТАННЯ

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

Відповіді на шосте питанняENT Контроль
Всім нашим клієнтам, як реальним, так і потенційним, я раджу
звертатися безпосередньо в нашу компанію, з будь-яких виникаючих
питань, стосовно працездатності і функціональних можливостей нашій
системи. Співробітники нашої компанії нададуть висококваліфіковану
допомога B тій або іншій ситуації, і не залишать без уваги наших клієнтів. Для
зручності та побажань наших клієнтів служба технічної підтримки працює з
понеділка по п'ятницю з 8 до 20, а в суботу з 10 до 18. За допомогою можна
звернутися за безкоштовної гарячої лінії за телефоном 8 800 505 02 30 або
залишити заявку на нашому сайті.
АВАНГАРД і Стражъ
Замовити у нас на сайті IT послугу з конфигурировнию ПО і ми самі допоможемо йому вирішити цю проблему.

КРОНВЕРК Реверс
Очевидні речі: Без необхідності не відкривати 3050/tcp зовні, поміняти пароль для SYSDBA.
Електра-АС
У сучасній версії є можливість змінити пароль SYSDBA та
використовувати його для підключення до БД.
APACS 3000 і LyriX
Дали спільну відповідь (Наведено нижче)
Elsys BASTION
ВІДМОВИЛИСЯ ВІД КОМЕНТАРІВ
KODOS
ПРОІГНОРУВАЛИ ПИТАННЯ
Сфінкс
ПРОІГНОРУВАЛИ ПИТАННЯ
Castle
ПРОІГНОРУВАЛИ ПИТАННЯ
Tempo Reale
ПРОІГНОРУВАЛИ ПИТАННЯ

Для Шэлт ПРО шостий питання було іншим:

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

Відповідь Шэлт ПРОШэлт ПРО
1. Рекомендуємо оновити версію
2. Якщо є можливість підключення до сервера локальної мережі, то змінити пароль підключення до бази даних.

Для APACS 3000 та LyriX був отриманий одну відповідь на всі питання:

Відповідь APACS 3000 і LyriXAPACS 3000 та LyriX
По суті можу відповісти наступне:

Можливість вказаного Вами несанкціонованого доступу до бази даних можлива в тому випадку, якщо грубо порушені елементарні правила. Це відбувається тоді, коли адміністратором системи на об'єкті залишаються паролі «за замовчуванням», які повинні змінюватися в обов'язковому порядку. Щоб влізти в базу даних потрібно знати не номер порту, а пароль і, якщо адміністратор його не змінив, це кричуща недбалість, що говорить про його адміністратора безграмотності. Закривати цей порт не можна, оскільки за нього йде робота.

Ми як компанія, що розробляє програмні комплекси для управління інтегрованими системами безпеки, розуміємо і також багато уваги приділяємо питань, пов'язаних з інформаційною безпекою. Тому на всіх семінарах ми постійно порушуємо і розбираємо питання, пов'язані з обов'язковою зміною паролів за замовчуванням на всіх рівнях, політикам оновлення паролів. Також ми настійно рекомендуємо, щоб наші системи завжди обслуговували грамотні фахівці IT і адміністратори. Тільки при повному розумінні і дотриманні всіх правил і політик безпеки можна розраховувати на належний захист всього програмного комплексу та об'єкта в цілому.

Підсумки

Зрештою, я сам почав сумніватися в тому, хто винен у ситуації, коли в локальній мережі стирчить СКУД з паролем за замовчуванням на БД. Я розумію і розробників і користувачів, але все ж більше схиляюся в бік більшої відповідальності розробників. СКУД зараз є в будь-якій компанії, таке просто необхідно навіть непрофесіоналам у 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, підмережа, відключення від «зовнішнього периметра», використання окремого комплекти мережевого обладнання та фізичних ліній зв'язку, що дає високий рівень ізоляції від загроз. Але все ж не завжди і не скрізь застосовується такий підхід. Про це замислюються у великих компаніях, які можуть дозволити це собі, виділяють ресурси, і рідше – в дрібних.

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

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


ВІТАЛІЙ ТЕРЕНТЬЄВ, Керівник IT 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. Реалізувавши його ми автоматично отримали сучасний і найбільш захищений механізм зберігання паролів у вигляді «солоного» хеша.


Володимир Богачов, Керівник IT «Прософт-Системи» ( prosoftsystems.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. Натискаємо ОК



Що стосується небезпечною авторизації в деяких розглянутих СКУДах, то тут ситуацію може виправити тільки сам розробник. А поки, можна порадити тільки ізолювати сервер СКУД з корпоративної мережі. І пам'ятати, що різні права різних користувачів СКУД не мають сенсу. Внести зміни в БД зможе і користувач з доступом тільки на читання.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.