Написано от: Фарид Мустафаев, експерт по киберсигурност в ThreatLocker
Именуваните канали (named pipes) са често срещан избор за комуникация между приложения, работещи на един и същ компютър с Windows. Те са бързи, поддържат се директно от операционната система и работят добре за комуникация между услуги на Windows (Windows services), десктоп приложения, процеси в системния трей, конзолни помощни програми и фонови агенти.
Типичният дизайн може да включва привилегирована услуга на Windows, действаща като сървър на именувания канал, докато потребителското приложение се свързва като клиент. Тъй като и двата процеса се изпълняват на един и същ компютър, разработчиците често третират тази комуникация като вътрешна и следователно доверена.
На практика каналът е достъпен от среда, в която много несвързани процеси могат да се изпълняват под различни потребители, сесии и контексти на сигурност.
Именуваните канали често се третират като частни, тъй като се използват за комуникация между приложения на една и съща машина. Това предположение е небезопасно.
Една работна станция с Windows може да изпълнява процеси под LocalSystem, администратори, стандартни потребители, сервизни акаунти и отделни интерактивни или отдалечени сесии. Тя може също така да съдържа софтуер на трети страни, скриптове, диагностични инструменти и зловреден софтуер, работещ под компрометиран акаунт.
Всеки процес, който знае името на канала и има достатъчно права за достъп, може да се опита да се свърже. Windows по рождение не знае кое изпълнимо досие е възнамерявал да използва разработчикът за този канал.
Поради тази причина именуваният канал трябва да се третира като изложен на риск локален интерфейс. Преди да обработи заявка, приложението трябва да определи кой се е свързал, какво е разрешено да прави тази идентичност и дали предоставените данни са безопасни.
Идентичност, контрол на достъпа и граници на привилегиите
Рискът е най-голям, когато привилегирована услуга на Windows комуникира с по-малко привилегировано десктоп приложение.
Услуга, работеща като LocalSystem, може да бъде в състояние да променя защитени файлове и ключове в регистъра, да стартира процеси, да променя системната конфигурация, да осъществява достъп до данните на други потребители или да комуникира с драйвери на ядрото. Когато тези операции са достъпни чрез именуван канал, каналът се превръща в API към привилегирована функционалност.
Успешното свързване доказва само, че на клиента е било разрешено да отвори канала. То не доказва, че:
- клиентът е очакваното приложение;
- свързаният потребител е упълномощен;
- заявената операция е разрешена.
Поради това разрешенията за канала трябва да бъдат дефинирани изрично и ограничени до най-малкия подходящ набор от идентичности. Широките разрешения за „Everyone“, „Authenticated Users“ или всички интерактивни потребители могат да позволят на несвързани процеси да достигнат до канала.
Удостоверяването (authentication) и оторизацията (authorization) също трябва да останат разделени. На даден потребител може да бъде разрешено да прави заявки за състоянието на услугата, но не и да спира услугата, да променя защитени настройки, да стартира процеси или да осъществява достъп до произволни файлове. Чувствителните команди трябва да бъдат оторизирани поотделно.
Имитирането на самоличност (impersonation) може да помогне чрез извършване на операции в контекста на сигурността на клиента, но с него трябва да се борави внимателно. Сървърът трябва да проверява дали имитирането е било успешно, да ограничава работата, извършвана по време на имитирането, и винаги да възстановява първоначалната си идентичност.
Спечелете битката срещу кибератаките, задвижвани от изкуствен интелект:
- Вижте как прекомерните разрешения могат да превърнат инструментите с изкуствен интелект в сериозен риск за сигурността.
- Научете как практическата стратегия за „нулево доверие“ (Zero Trust) може да помогне за ограничаване на заплахите, улеснени от изкуствен интелект, преди те да се разпространят.
Недоверени сървъри, команди и данни
Клиентът трябва да проверява сървъра по същия начин, по който сървърът проверява клиента.
Предвидимото име на канал е само идентификатор. То не е тайна и не доказва кой процес е създал канала. Атакуващият може да създаде канал, използвайки очакваното име, преди легитимният сървър да е стартирал, което кара клиента да се свърже с контролиран от атакуващия процес.
Опцията за първи екземпляр на канала (first-pipe-instance) може да помогне за откриване, че името вече е заето, но тя не замества правилния контрол на достъпа или проверката на идентичността на сървъра.
Съобщенията, получени през канала, също трябва да се третират като недоверени входни данни. Дори удостоверен клиент може да изпрати:
- деформиран или извънгабаритен зловреден код;
- невалидни пътища до файлове или регистри;
- неподдържани комбинации от команди;
- стойности, предназначени да предизвикат условия за грешка.
Привилегирована услуга, която преобразува такива входни данни директно в операции с файлове, регистри, процеси или команден ред, може да се превърне в „объркан заместник“ (confused deputy): атакуващият предоставя инструкцията, докато услугата предоставя привилегиите.
Заявките трябва да използват строго рамкиране на съобщенията, ограничени размери, бели списъци с команди, валидиране на схеми, нормализиране на пътища, специфична за операцията оторизация и безопасно управление на грешки.
Наличност и отдалечено излагане
Сигурността на именуваните канали не се ограничава само до ескалация на привилегии и неоторизирани команди.
Злонамерен или неправилно функциониращ процес може многократно да се свързва, да държи връзките отворени, да изпраща непълни съобщения или да подава заявки, които консумират прекомерно количество процесорни ресурси, памет или ресурси на ядрото.
Сървърът трябва да използва лимити за връзките, таймаути, анулиране, ограничени размери на съобщенията, контролирана конкурентност и ограничаване на честотата на заявките.