Всем привет! Уверен, что вы наслышаны о недочетах технологии Windows UAC, однако относительно недавно появились подробности любопытной уязвимости, эксплуатация которой дает возможность непривилегированному пользователю максимально повысить привилегии. В Jet CSIRT мы не оставили этот случай без внимания, ведь для любой команды мониторинга и реагирования на инциденты ИБ уязвимости класса Privilege Escalation представляют особый интерес. Под катом — описание уязвимости, способы детекта и защиты.
Детали уязвимости
Исследователь Eduardo Braun Prado из команды Zero Day Initiative обнаружил уязвимость локального повышения привилегий в компоненте Windows Certificate Dialog, которая возникает из-за некорректной обработки пользовательских привилегий. Уязвимость позволяет повысить привилегии пользователя до максимально возможных SYSTEM и обойти все защитные механизмы ОС Windows. Это происходит при эксплуатации механизма Windows UAC, когда пользователь взаимодействует с компонентом Безопасного рабочего стола (Secure Desktop), открыв диалог запуска файла от имени Администратора.
В чем суть уязвимости? Сертификат исполняемого файла содержит необязательное численное поле «Идентификатор политики» в формате Microsoft-specific object identifier (OID).
Заголовочный файл Wintrust.h определяет это поле как SPC_SP_AGENCY_INFO_OBJID. Хотя его назначение слабо документировано, скорее всего, оно анализируется при открытии окна с деталями сертификата. При представлении данного поля в корректном формате поле Issued by («Кем выдано») будет отображено в виде гиперссылки со значением, взятым из атрибута SpcSpAgencyInfo.
При клике по ссылке c полем Issued by откроется браузер Internet Explorer с правами SYSTEM. Родительским процессом для него будет выступать процесс consent.exe. Он также выполняется с максимальными привилегиями, и именно в его контексте запускается диалог UAC. Соответственно, далее появляется возможность запуска произвольного файла (cmd.exe, powershell.exe) из меню браузера с унаследованными правами SYSTEM.
В качестве PoC для демонстрации эксплуатации уязвимости (видео приведено ниже) исследователь предложил использовать утилиту HTML Help ActiveX Control, сертификат которой обладает описанными выше особенностями.
При этом существует возможность подписать любой исполняемый файл подобным образом, например, с помощью powershell командлета Set-AuthenticodeSignature. Предварительно потребуется создать самоподписанный сертификат корневого удостоверяющего центра и конечный сертификат средствами утилиты makecert из набора Windows SDK. Инструкция приведена по ссылке.
Уязвимость получила идентификатор CVE-2019-1388 и CVSS 7.8. Ей оказались подвержены все версии ОС от Windows 7 до Windows Server 2019. После установки патча поле Issued by в деталях сертификата перестает отображаться как гиперссылка.
Массовая эксплуатация этой уязвимости маловероятна ввиду трудности автоматизации. Ведь для реализации атаки на ее основе пользователю потребуется выполнить немало действий — от открытия окна с сертификатом исполняемого файла до запуска командной строки через интерфейс Internet Explorer. Поэтому наиболее вероятный сценарий атаки может быть связан с действиями внутреннего нарушителя.
Как обнаружить
Для обнаружения эксплуатации уязвимости на платформах Windows x64 мы в Jet CSIRT используем в SIEM-системе правило корреляции, отслеживающее цепочку событий (на контролируемом узле предварительно необходимо включить аудит запуска процессов посредством соответствующей групповой политики либо использовать утилиту Sysmon от Sysinternals):
- Детектирование запуска процесса constent.exe с правами SYSTEM (код события 4688).
- Детектирование запуска процесса C:\Program Files\iexplore.exe с правами SYSTEM, где в качестве родительского процесса выступает consent.exe.
- Детектирование запуска процесса C:\Program Files (x86)\iexplore.exe с правами SYSTEM, где в качестве родительского процесса выступает C:\Program Files\iexplore.exe.
- Детектирование запуска командного интерпретатора (cmd.exe, powershell.exe) с правами SYSTEM, где в качестве родительского процесса выступает C:\Program Files (x86)\iexplore.exe.
- ID процесса C:\Program Files (x86)\iexplore.exe из п.3 и ID C:\Program Files (x86)\iexplore.exe в качестве родительского процесса из предыдущего пункта совпадают.
Приведем пример описанного корреляционного правила на стороне FortiSIEM.
Используемые условия
Детализация условия запуска consent.exe
Детализация условия запуска IEx64
Детализация условия запуска IEx86
Детализация условия запуска cmd.exe, powershell.exe
Исходный код корреляционного правила FortiSIEM
<rules><DataRequest advanced="true" custId="1" type="Rule">
<Name>UAC Privilege Escalation through Secure Desktop</Name>
<Description>Повышение привилегий через UAC Secure Desktop CVE-2019-1388</Description>
<Remediation/>
<CustomerScope groupByEachCustomer="true">
<Include>1</Include>
<Exclude/>
</CustomerScope>
<PatternClause window="300">
<SubPattern id="148021654" name="Consent_Execution">
<SingleEvtConstr>eventType = "Win-Security-4688" AND procName CONTAIN "consent.exe" AND user IN ("СИСТЕМА","SYSTEM")</SingleEvtConstr>
<GroupEvtConstr>COUNT(*) >= 1</GroupEvtConstr>
<GroupByAttr>user,procName</GroupByAttr>
</SubPattern>
<Operator rank="0" type="FOLLOWED_BY"/>
<SubPattern id="148021655" name="IE_x64_Execution">
<SingleEvtConstr>eventType = "Win-Security-4688" AND procName REGEXP (".*Files\\\\Internet.*\\\\iexplore\\.exe$") AND parentProcName CONTAIN "consent.exe" OR user IN ("СИСТЕМА","SYSTEM")</SingleEvtConstr>
<GroupEvtConstr>COUNT(*) >= 1</GroupEvtConstr>
<GroupByAttr>procId,user,parentProcName,procName</GroupByAttr>
</SubPattern>
<Operator rank="0" type="FOLLOWED_BY"/>
<SubPattern id="148021664" name="IE_x86_Execution">
<SingleEvtConstr>eventId = 4688 AND procName REGEXP (".*\\(x86\\)\\\\.*\\\\iexplore\\.exe$") AND parentProcName REGEXP (".*Files\\\\Internet.*\\\\iexplore\\.exe$") AND user IN ("СИСТЕМА","SYSTEM")</SingleEvtConstr>
<GroupEvtConstr>COUNT(*) >= 1</GroupEvtConstr>
<GroupByAttr>procName,parentProcName,procId,user</GroupByAttr>
</SubPattern>
<Operator rank="0" type="FOLLOWED_BY"/>
<SubPattern id="148021656" name="Cmd_Execution">
<SingleEvtConstr>eventType = "Win-Security-4688" AND ( procName CONTAIN "cmd.exe" OR procName CONTAIN "powershell.exe" ) AND parentProcName REGEXP (".*\\(x86\\)\\\\.*\\\\iexplore\\.exe$") AND user IN ("СИСТЕМА","SYSTEM")</SingleEvtConstr>
<GroupEvtConstr>COUNT(*) >= 1</GroupEvtConstr>
<GroupByAttr>user,parentProcName,procName,parentProcId</GroupByAttr>
</SubPattern>
<GlobalConstr>IE_x86_Execution.procId = Cmd_Execution.parentProcId</GlobalConstr>
</PatternClause>
<IncidentDef eventType="UAC_Privilege_Escalation_through_Secure_Desktop" eventTypeGroup="PH_SYS_EVENT_PH_RULE_SEC" fireFreq="900" severity="7">
<ArgList>procName=Cmd_Execution.procName,parentProcName=Cmd_Execution.parentProcName,user=Cmd_Execution.user</ArgList>
</IncidentDef>
<DynWatchListDef/>
<userRoles>
<roles custId="0"></roles>
</userRoles>
<TriggerEventDisplay>
<AttrList>phRecvTime,eventType,reptDevName,reptDevIpAddr,destIpAddr,destName,user,parentProcId,parentProcName,procId,procName,rawEventMsg</AttrList>
</TriggerEventDisplay>
</DataRequest>
</rules>
Исследователь Florian Roth выложил Sigma-правило для обнаружения попытки эксплуатации данной уязвимости. Однако из-за ограничений языка с помощью правила можно выявлять только событие запуска Internet Explorer с правами SYSTEM и родительским процессом consent.exe без последующего детектирования запуска командных интерпретаторов. Отследить цепочку нужных событий при соблюдении описанных выше условий (1-5) средствами Sigma не представляется возможным, из-за чего мы вынуждены были разработать собственное правило.
Как защититься
1. Установить патч Microsoft от 12 ноября для соответствующей версии ОС.
2. Если патч для устранения данной уязвимости установить нельзя, стоит воспользоваться:
- правилами AppLocker, запрещающими запуск командных интерпретаторов cmd.exe и powershell.exe для учетных записей, входящих в группу «Пользователи» (необходимо учесть утилиты и техники, позволяющие обойти AppLocker, перечисленные в LOLBINS);
- средствами host-based IPS в составе систем класса EPP, EDR (нужно настроить правила доступа, запрещающие процессу iexplore.exe обращение к cmd.exe, powershell.exe).
balamutang
Не совсем понял: если из iexplore.exe с правами SYSTEM запустить notepad.exe, а из notepad.exe запустить cmd.exe это эти правила уже не сработают, если цепочка не подразумевает участия notepad.exe (или любого другого exe между эксплорером и консолью)?
По мне так iexplore.exe с правами SYSTEM уже достаточно громкий звоночек
Kriks87 Автор
Правило сработает, если будет выявлена следующая цепочка запуска процессов: consent.exe -> iexplore.exe (x64) -> iexplore.exe (x86) -> cmd.exe|powershell.exe.
Вы правы, запуск IE с правами SYSTEM уже сам по себе подозрителен, но для однозначного выявления факта эксплуатации описанной уязвимости необходимо обнаружить всю цепочку событий.