SCADA и мобилни телефони
Съдържанието на статията
Иван Юшкевич, Александър Болшев
Това изследване е опит да се отговори на някои от тези въпроси. Нашата цел е не само да открием грешки в сигурността в мобилните ICS приложения, но и да се опитаме да екстраполираме рисковете от компрометиране на тези приложения към рисковете от компрометиране на цялата ICS инфраструктура. Този подход се различава от обичайния възглед за оценка на сигурността на мобилните приложения: уязвимостите с традиционно ниско ниво на сериозност могат да изложат ICS на огромен риск, докато уязвимостите, които обикновено се считат за критични заплахи, напротив, са опасни за ICS с много ниска вероятност.
Xakep #240. Гидра
За всяка от трите групи представихме различни изисквания за сигурност. Очевидно рискът от използване на приложение с уязвимости в защитен периметър е по-малък от риска от използване на уязвим клиент на SCADA през Интернет. Ние оценихме сигурността на решенията по отношение на OWASP Top 10 Mobile Risks, като добавихме DoS проверки и защита с парола на интерфейса. Друг парадоксален резултат е, че в приложенията за отдалечен достъп са открити повече уязвимости и слабости, отколкото сумата от другите две групи. Това е неприемливо за приложения, работещи през незащитени комуникационни канали.
Общо открихме 50 уязвимости, включително: несигурни или недостатъчно сигурни методи за предаване и съхранение на данни (включително неправилно използване на SSL или „самоизработени“ криптографски алгоритми), атаки за отказ на достъп на отдалечен клиент и сървър, SQL инжекции, използване на ненадеждни входни данни като настройки на процеси и т.н. Използването на тези проблеми със сигурността потенциално позволява изпълнението на редица опасни атаки, като напр.на приложение и на оператор. В последния случай е реалистично да се създаде погрешна представа за текущото състояние на процеса, което може да доведе до грешни решения със сериозни последици за предприятието.
Ако сравним резултатите, получени в хода на тази работа, с констатациите от други наши скорошни проучвания за сигурността на приложенията за мобилно банкиране, тогава можем да кажем, че ситуацията е доста трудна. Качеството на кода в такива решения е много ниско, има наистина любопитни грешки и уязвимости. Повечето от тях са логични и архитектурни и използването им е доста просто. Това състояние е неприемливо за областта на АСУТП. Дори в ранните етапи от развитието на мобилното банкиране не е имало подобни грешки. Може би това се дължи на факта, че областта на индустриалните системи за управление е много специфична и разработчиците на мобилни решения просто не осъзнават какво се случва.
1. Основното при системите за контрол на процеси
Преди да преминете към описание на мобилните ICS приложения и свързаните с тях заплахи, е необходимо да направим кратко въведение в съвременните ICS инфраструктури. Това е общ термин, който обединява софтуерни и хардуерни системи, използвани в индустриалната автоматизация, включително разпределени системи за управление (DCS), системи за контрол и събиране на данни (SCADA), програмируеми контролери (PLC), интерфейси човек-машина (HMI), системи за контрол на производството (MES) и др. Днес всяка фабрика, завод, бизнес център и дори жилищни сгради се управляват от SCADA под една или друга форма. По обща дефиниция системата за контрол на процеси събира данни от отдалечени станции, обработва ги и използва автоматизирани алгоритми или управлявана от оператор програма за диспечер, за да генерира команди, които след това се изпращат до отдалечени устройства (или „полеви станции“).устройства“). Първите APCS инфраструктури се появяват през 1970–1980 г. Такива системи се характеризират с редки актуализации и бавен технологичен прогрес. Въпреки това през последното десетилетие съвременните технологии, включително XML, .Net, JSON и др., се използват все повече в индустриалните системи за управление. Разбира се, не са пропуснати и мобилните приложения.
Съвременните ICS инфраструктури имат сложна архитектура, състояща се от добре познати елементи като сървъри, персонални компютри, мрежови комутатори, софтуерни технологии (.Net, DCOM, XML и др.) и по-сложни компоненти: програмируеми контролери, предаватели, изпълнителни механизми, аналогови управляващи сигнали и др. На фиг. 1 е показана схема на съвременна АСУТП инфраструктура. Обърнете внимание на трите му основни нива.
1. Долното ниво е мястото, където са разположени полевите устройства. Както бе споменато по-горе, те са подходящи за "мръсна" работа: например могат да контролират температурата и налягането в реактора, да контролират операции като отваряне и затваряне на клапани, включване и изключване на помпи и т.н. Много устройства могат да се използват на това ниво. Това могат да бъдат програмируеми логически контролери на ниско ниво (PLC, както е дефинирано от Wikipedia1: специализирано устройство, използвано за автоматизация на процеси). В допълнение, предаватели и задвижващи механизми, управлявани от отдалечено терминално устройство (RTU, управлявано от микропроцесор електронно устройство, което преобразува физически обекти в сигнали, разбираеми за разпределена система за управление или SCADA система, чрез предаване на телеметрични данни към хост системата и съобщения от главната контролна зала, могат да бъдат разположени на това ниво.системи към контролирани обекти2). Този слой е царството на индустриални протоколи от ниско ниво като Modbus, Modbus TCP, HART, Wireless HART, Profibus DP или PA, Foundation Fieldbus H1. Инженери от по-ниско ниво на ICS, електротехници, техници и други специалисти работят на това ниво на ICS.
2. Средното ниво, където можете да срещнете PLC от високо ниво, разпределени системи за управление (DCS, система за управление на процеси, характеризираща се с изграждането на разпределена входно-изходна система и децентрализирана обработка на данни3), системи за надзорен контрол и събиране на данни (SCADA), софтуерен пакет, предназначен да разработи или осигури работа в реално време на системи за събиране, обработка, показване и архивиране на информация за обект за наблюдение или контрол4) и интерфейси човек-машина (Human-Machine Interface (HMI)), както и сървъри като OPC (Open Platform Communications, бивш OLE за контрол на процеси). Това е мястото, където се извършва цялата интелектуална дейност. На базата на данни от по-ниски нива операторите и автоматизираните системи вземат решения и изпращат команди към полеви устройства. Тук се осъществява целият процес на автоматизация на производството. Оператори, инженери по процеси, инженери по контрол на процеси, програмисти на PLC и софтуер работят със системи на това ниво.
3. Най-високото ниво интегрира бизнес и индустриални процеси. Този слой осигурява свързаност към корпоративната мрежа и системите за планиране на ресурсите на предприятието (ERP). На това ниво са разположени различни системи за управление на производствени активи (PAS) и системи за управление на производствени процеси (MES), които предоставят точната информация в точното време и показватлица, вземащи решения в производството, как условията в цеха могат да бъдат оптимизирани за увеличаване на производителността5). Тук мениджърите и инженерно-техническият персонал от най-високо ниво работят с автоматизирани системи за управление на процесите.
2. Видове мобилни ICS приложения и свързаните с тях рискове
Както вече знаете, ICS инфраструктурите са огромни. Разнообразни са и мобилните приложения за автоматизирани системи за управление на процеси. Тъй като (все още) няма класификация на тези решения, ние разработихме наши собствени, базирани на връзката на приложението с индустриалния процес и местоположението му в ICS архитектурата. Идентифицирахме три вида мобилни решения за промишлени системи за управление:
1. Контролен панел : директно конфигуриране/мониторинг/контрол на производствения процес и/или неговите компоненти. Роли в инфраструктурата на APCS:
Дистанционно
Няма валидиране на данни от страната на сървъра от гледна точка на индустриалния процес. Поради факта, че сървърното приложение напълно се доверява на данните, които идват от оператора, а коректността на технологичния процес зависи изцяло от действията и командите, които изпраща, всякакви пропуски при валидирането на данните могат да доведат до сериозни последствия. В същото време в мобилно приложение е по-лесно да направите грешка в цифрата на числото или случайно да зададете отрицателна стойност за параметър. Неправилното тълкуване на стойности също може да доведе до отказ на услуга както за сървъра, така и за клиентските приложения.
Клиент за OPC/MES или система за архивиране
Скриване на аларми. Използвайки възможността за прихващане на трафик, нападателят може да промени отговора от сървъра по такъв начин, че вместо информация за инцидента в предприятието, операторът ще получи съобщениече всичко е наред или, още по-лошо, обратната информация. От своя страна ненавременната или невярна информация може да доведе до спиране на технологичния процес, докато операторът разбере къде е проблемът: в оборудването или в приложението. Отказът от обслужване на клиента и сървъра на системата може да доведе до забавяне на информирането.
SCADA дистанционно управление
Тъй като приложенията от този тип се позиционират от производителите на софтуер именно като инструмент за дистанционно управление на SCADA сървъри, е възможно прихващане и промяна на команди за управление, изтичане на критична информация, прихващане и модифициране на трафик с цел компрометиране на технологичния процес.
3. Методика на тестване
Анализ: По време на анализа на всяко приложение направихме редица общи проверки. Получените резултати ни помогнаха да оценим сигурността на подобни решения. Всеки тестов случай дава полезни данни или директно демонстрира уязвимости, на които се основава допълнителен анализ (например допълнителни проверки или тестване на специфични вектори на атака). След като завършихме всички тестове, започнахме индивидуално проучване на всяко приложение по отношение на сигурността.
Нашият контролен списък:
След като приключихме всички тези проверки, пристъпихме към анализ на отделните заявления. Включва разбиране на логиката на приложението, контролните потоци и т.н.
Фъзинг : В някои случаи, ако приложение използва бинарен протокол, който е труден за обратно проектиране или разбиране, ние търсихме уязвимости, използвайки мутационен фъзинг. На фиг. 3 показва fuzzing архитектурата, която използвахме. Приложението се свързва със сървъра (PLC, SCADA, MES, OPC и др.) чрез прозрачен прокси сървър (прозрачен сокетпрокси). Данните, преминаващи през него, периодично мутират. Например данните, предавани от клиент към сървър, се променят с вероятност от 5% или 25%. Това е начинът, по който мутационните размити проверки са вградени в нормалния поток от данни и това ни позволява да проверим как произволни части от протокола се анализират от двете страни.
Тъй като имаме работа с мобилна среда, автоматизираното размиване на клиентски приложения е трудно. Има още един проблем: някои от изследваните приложения имат вградени интерфейсни компоненти. Поради това може да не е възможно да се използват автоматизирани инструменти за тестване на потребителския интерфейс за емулиране на натискане на бутони за управление в приложение за изпращане/получаване на данни от сървър. За да разрешим този проблем, разработихме специален инструмент - AndroidNUITst (Android Native UI TeSTer). Състои се от два компонента: Java приложение, което използва adb и библиотеката Android UIAutomator за емулиране на докосвания на екрана и заснемане на екранни снимки; и услуга Erlang, която използва тестов скрипт за изпълнение на различни функции на приложението и откриване на грешки.
Таблицата по-долу изброява всички тествани мобилни приложения.