Атака от тип „Донеси си собствена EDR“ (Bring Your Own EDR) злоупотребява с доверени компоненти на SentinelOne, за да превърне защитата на крайни точки в мощен щит за зловреден код. Проучването беше представено на DEF CON 34 в Лас Вегас, а SentinelOne отстрани докладваната уязвимост в Agent версия 26.1.1.
Инструментите за откриване и реагиране на крайни точки (EDR) работят с дълбока видимост и високи привилегии, тъй като трябва да инспектират процеси, файлове, памет и системно поведение.
Тези същите привилегии могат да станат опасни, когато локалните интерфейси, логиката на инсталатора и границите на доверие не са достатъчно защитени.
Изследването се фокусира върху Windows Protected Process Light (PPL). Този модел за сигурност на Windows има за цел да предотврати четенето, модифицирането, дебъгването или прекратяването на защитени услуги за сигурност от обикновени процеси.
Продуктите за антивирусна защита и EDR обикновено използват ниво на защита Antimalware-Light, като в същото време други защитени услуги включват LSASS и компоненти на Windows Defender.
Изследователи от Akamai установиха, че SentinelOne излага на риск няколко интерфейса на Component Object Model (COM), включително обекта SentinelHelper. Един метод, наречен Dump, може да бъде извикан от локален администратор за създаване на паметови дъмпове на защитени процеси.
За разлика от други изложени функции, методът съобщава за липса на строга валидация на местоположението на извикващото приложение. Това дава възможност на атакуващ с администраторски права да направи дъмпове на процеси, защитени от PPL, включително собствения агент на SentinelOne и Microsoft Defender.
Техниката не изисква уязвим драйвер, експлойт на ядрото или традиционна уязвимост за ескалация на привилегии в Windows. Вместо това тя злоупотребява с легитимен, доверен EDR процес за извършване на действия, които нормалният софтуер в потребителски режим не може да направи.
След това изследователите свързват тази възможност с по-ранни проучвания на PPL, базирани на COM. Чрез извличане на специфични за процеса COM тайни от дъмпове на паметта, те демонстрират път за картографиране и изпълнение на неподписан код в рамките на друг защитен с PPL процес.
При техните тестове атаката в крайна сметка позволява изпълнението на неподписан зловреден код в защитения контекст на Microsoft Defender след разрешаване на разрешенията за паметта, релокациите и ограниченията за зареждане на зависимости.
Проучването също така изследва поведението на инсталатора на SentinelOne. Твърди се, че легитимен инсталатор може да бъде конфигуриран с манипулирана стойност на системния регистър за внедряване на нефункционален локален агент.
Такъв агент все още може да отчита статус „защитен“, докато изключва конкурентни защити на крайни точки. Това трансформира доверения инсталатор на продукт във възможен инструмент за отслабване на защитната позиция на целта.
Друго безпокойство е свързано с връзката за управление. Изследователите на Akamai забелязаха, че URL адресът за управление на агента може да бъде идентифициран чрез достъпен интерфейс за статус.
Пренасочването на това хост име на локално ниво може да предотврати събирането на облачна телеметрия, докато агентът на крайната точка изглежда активен. Това може да забави откриването на атака от конзолата за управление.
Най-сериозното въздействие идва от обръщането на функциите за самозащита на EDR продукт. Атакуващ може да постави зловреден код в инсталационната директория на EDR, да активира отново защитата срещу подправяне и да остави SentinelOne да блокира други процеси от промяна или достъп до зловредния софтуер.
Злонамереният код може да заобиколи както защитите на Windows PPL, така и собствените механизми за защита на EDR, базирани на файлове и процеси. Констатациите показват, че защитата на крайните точки трябва да се разглежда като високорискова инфраструктура.
Уязвимостта е докладвана и коригирана в SentinelOne версия 26.1.1 или по-нова. Организациите трябва да обновят агентите на SentinelOne, за да ограничат строго правата на локалния администратор, да наблюдават за неочаквана активност на инсталатора и да разследват промени в локалния DNS или записи в хост файла, които засягат домейните за управление на EDR.
Екипите за сигурност трябва също така да преразгледат дали тяхната EDR платформа излага локални интерфейси за управление, до които администраторите имат достъп без силни контроли за оторизация.