SCADA та мобільники
Зміст статті
Іван Юшкевич, Олександр Большев
Це дослідження – спроба відповісти на деякі з цих питань. Наша мета – не тільки знайти помилки безпеки в мобільних додатках для АСУ ТП, а й спробувати екстраполювати ризики компрометації цих програм на ризики компрометації всієї інфраструктури АСУ ТП. Цей підхід відрізняється від звичного погляду на оцінку безпеки мобільних додатків: вразливості з традиційно низьким рівнем небезпеки можуть наражати АСУ ТП на величезний ризик, а вразливості, які зазвичай вважаються критичними загрозами, навпаки, бувають небезпечні для АСУ ТП з дуже низькою ймовірністю.
Xakep #240. Ghidra
До кожної з трьох груп ми висунули різні вимоги безпеки. Очевидно, що ризик використання програми з уразливістю в захищеному периметрі менший, ніж ризик застосування вразливого клієнта SCADA через Internet. Ми оцінили захищеність рішень з точки зору OWASP Top 10 Mobile Risks, додавши перевірки на DoS та захищеність інтерфейсу паролем. Ще один парадоксальний результат полягає в тому, що в додатках віддаленого доступу було знайдено більше вразливостей та слабкостей, ніж у сумі за двома іншими групами. Це неприпустимо для програм, що працюють через незахищені канали зв'язку.
Загалом ми знайшли 50 вразливостей, серед яких: незахищені або недостатньо захищені методи передачі та зберігання даних (включаючи некоректне використання SSL або “саморобні” криптоалгоритми), віддалена атака на відмову у доступі на клієнт та сервер, SQL-ін'єкції, використання недовірених вхідних даних як параметри налаштування техпроцесу та ін. Експлуатація цих проблем безпеки потенційно дозволяє реалізувати ряд небезпечних атак якна додаток, і на оператора. В останньому випадку реально створити хибне уявлення про поточний стан техпроцесу, що може призвести до прийняття невірних рішень з тяжкими наслідками для підприємства.
Якщо порівнювати результати, отримані в ході цієї роботи, з висновками інших наших останніх досліджень безпеки додатків для мобільного банкінгу, то можна сказати, що ситуація досить важка. Якість коду в таких рішеннях дуже низька, зустрічаються воістину курйозні помилки та вразливості. Більшість із них — логічні та архітектурні, і експлуатувати їх досить просто. Такий стан справ не допустимий для сфери АСУ ТП. Навіть на ранніх стадіях розвитку мобільного банкінгу таких помилок не було. Можливо, це пов'язано з тим, що область АСУ ТП дуже специфічна, і розробники мобільних рішень просто не усвідомлюють те, що відбувається.
1. Головне про АСУ ТП
Перш ніж перейти до опису мобільних додатків для АСУ ТП та пов'язаних з ними загроз, необхідно зробити короткий вступ до сучасних інфраструктур АСУ ТП. Це загальний термін, що поєднує програмні та апаратні комплекси, що використовуються в автоматизації промисловості, включаючи розподілені системи управління (DCS), системи диспетчерського контролю та збору даних (SCADA), програмовані контролери (PLC), людино-машинні інтерфейси (HMI), системи управління виробництвом (MES) тощо. Сьогодні кожна фабрика, завод, бізнес-центр і навіть житлові будинки контролюються АСУ ТП у тому чи іншому вигляді. Згідно з загальним визначенням, АСУ ТП здійснює збір даних з віддалених станцій, обробляє їх та використовує автоматизовані алгоритми або керовану оператором програму-диспетчер для створення команд, які потім відправляються на віддалені пристрої (або «польові»пристрої»). Перші інфраструктури АСУ ТП з'явилися торік у 1970–1980 роках. Для таких систем характерні рідкісні оновлення та уповільнений технологічний прогрес. Проте в останнє десятиліття сучасні технології, включаючи XML, .Net, JSON тощо, стали використовуватися в АСУ ТП дедалі частіше. Звичайно, мобільні програми теж не залишилися осторонь.
Сучасні інфраструктури АСУ ТП мають складну архітектуру, що складається з таких загальновідомих елементів, як сервери, ПК, мережеві комутатори, технології програмного забезпечення (.Net, DCOM, XML і т. д.), і складніших компонентів: програмованих контролерів, передавачів, силових приводів, аналогових контрольних сигналів тощо. буд. На рис. 1 наведено схему сучасної інфраструктури АСУ ТП. Зверніть увагу на три її основні рівні.
1. Нижній рівень, де розташовані польові пристрої. Як вже згадувалося вище, вони підходять для «брудної» роботи: наприклад, вони можуть контролювати температуру і тиск в реакторі, керувати такими операціями, як відкриття та закриття клапанів, включення та вимкнення насосів тощо. На цьому рівні може використовуватися безліч пристроїв. Це можуть бути низькорівневі програмовані логічні контролери (PLC, за визначенням з Вікіпедії1: спеціалізований пристрій, який використовується для автоматизації технологічних процесів). Крім того, на цьому рівні можуть перебувати передавачі та приводи, керовані віддаленим термінальним пристроєм (RTU, електронний пристрій під керуванням мікропроцесора, який переводить фізичні об'єкти в сигнали, зрозумілі розподіленій системі керування або SCADA-системі, шляхом передачі телеметричних даних на провідну систему та повідомлень від провідної диспетчерськоїсистеми до контрольованих объектов2). Цей рівень є царством низькорівневих промислових протоколів, таких як Modbus, Modbus TCP, HART, Wireless HART, Profibus DP або PA, Foundation Fieldbus H1. Інженери нижнього рівня АСУ ТП, електрики, техніки та інші спеціалісти працюють на цьому рівні АСУ ТП.
2. Середній рівень, де можна зустріти високорівневі PLC, розподілені системи управління (DCS, система управління технологічним процесом, що відрізняється побудовою розподіленої системи вводу-виводу та децентралізацією обробки даних3), системи диспетчерського контролю та збору даних (Supervisory Control and Data Acquisition (SCADA) ), програмний пакет, призначений для розробки або забезпечення роботи в реальному часі систем збору, обробки, відображення та архівування інформації про об'єкт моніторингу або управління4) та людино-машинні інтерфейси (Human-Machine Interface (HMI)), а також такі сервери, як OPC (Open Platform Communications, раніше OLE for Process Control – OLE керувати процесами). Тут здійснюється вся інтелектуальна діяльність. На основі даних з нижчих рівнів оператори та автоматизовані системи приймають рішення та відправляють команди на польові пристрої. Тут відбувається весь процес автоматизації виробництва. Оператори, інженери-технологи, інженери АСУ ТП, програмісти PLC та ПЗ працюють із системами на цьому рівні.
3. Верхній рівень здійснює інтеграцію бізнесу та промислових процесів. Цей шар забезпечує прив'язку до корпоративної мережі та систем планування ресурсів підприємства (ERP). На цьому рівні розташовані різні системи управління активами виробництва (PAS) та системи управління виробничими процесами (MES, що надають потрібну інформацію в потрібний час і показуютьособам, які приймають рішення на виробництві, як умови роботи цеху можуть бути оптимізовані для підвищення продуктивності5). Тут з АСУ ТП працюють управлінці та інженерно-технічний персонал найвищого рівня.
2. Типи мобільних додатків АСУ ТП та пов'язані з ними ризики
Як ви тепер знаєте, інфраструктури АСУ ТП є величезними. Мобільні програми для АСУ ТП також відрізняються різноманітністю. Оскільки класифікації цих рішень (поки що) не існує, ми розробили власну, засновану на додатку до промислового процесу та його розташування в архітектурі АСУ ТП. Ми виділили три типи мобільних рішень для АСУ ТП:
1. Пульт керування : безпосередньо конфігурація/моніторинг/контроль виробничого процесу та/або його компонентів. Ролі в інфраструктурі АСУ ТП:
Пульт керування
Відсутність стороні сервера перевірки даних з погляду промислового процесу. Через те, що серверний додаток повністю довіряє даними, які прийшли від оператора, і коректність технологічного процесу повністю залежить від дій та команд, які він надсилає, якісь недоліки валідації даних можуть призвести до серйозних наслідків. При цьому в мобільному додатку легше помилитися в розряді чи випадково задати негативне значення параметра. Неправильна інтерпретація значень також може призвести до відмови в обслуговуванні серверного і клієнтського додатка.
Клієнт для OPC/MES або система архівації
Приховування сигналів тривоги. Використовуючи можливість перехоплення трафіку, зловмисник здатний змінювати відповідь від сервера таким чином, що замість інформації про подію на підприємстві оператор отримає повідомленняпро те, що все гаразд, або що ще гірше, протилежні відомості. У свою чергу, несвоєчасне або помилкове інформування може призвести до призупинення технологічного процесу, поки оператор розбирається, де неполадка: в обладнанні або все ж таки в додатку. Відмова в обслуговуванні клієнта та сервера системи може призвести до затримок в інформуванні.
Віддалене керування SCADA
Оскільки програми цього типу позиціонуються виробниками ПЗ саме як інструмент віддаленого управління SCADA-серверами, можливий перехоплення та зміна керуючих команд, витік критичної інформації, перехоплення та модифікація трафіку з метою компрометації технологічного процесу.
3. Методика тестування
Аналіз: під час аналізу кожного додатка ми зробили низку загальних перевірок. Отримані результати допомогли нам оцінити захищеність таких рішень. Кожна тестова перевірка давала корисні дані або безпосередньо демонструвала вразливості, на підставі яких будувався подальший аналіз (наприклад, додаткові перевірки чи тестування конкретних векторів атаки). Після завершення всіх тестів ми розпочали індивідуальне вивчення кожної програми з точки зору безпеки.
Наш контрольний список:
Після завершення всіх цих перевірок ми розпочали аналіз окремих додатків. Він включав розуміння логіки програми, потоків управління і т.д.
Фазинг : у деяких випадках, якщо програма використовувала двійковий протокол, складний для зворотного проектування або розуміння, ми шукали вразливості за допомогою мутаційного фазінгу. На рис. 3 зображена фазингова архітектура, яку ми використовували. Додаток підключається до сервера (PLC, SCADA, MES, OPC тощо) через прозорий проксі-сервер (transparent socketproxy). Дані, що проходять через нього, періодично мутують. Наприклад, дані, що передаються від клієнта до сервера, мутують із ймовірністю 5% або 25%. Так, мутаційні фазингові перевірки вбудовуються в нормальний потік даних, і це дозволяє нам перевірити, як випадкові ділянки протоколу аналізуються обома сторонами.
Оскільки ми маємо справу з мобільним середовищем, автоматизований фазинг клієнтських додатків не може. Є ще одна проблема: деякі з досліджуваних програм мають вбудовані компоненти інтерфейсу. Через це буває неможливо використовувати автоматизовані інструменти тестування UI, щоб емулювати натискання на кнопки управління в додатку для надсилання/приймання даних із сервера. Для вирішення цієї проблеми ми розробили спеціальний інструмент AndroidNUITst (Android Native UI TeSTer). Він складається з двох компонентів: Java-додаток, який використовує adb та бібліотеку Android UIAutomator, щоб емулювати натискання на екран та захоплювати знімки екрана; та Erlang-служба, яка застосовує тестовий сценарій для запуску тих чи інших функцій додатків та виявлення збоїв.
У таблиці нижче наведено всі протестовані мобільні програми.