Анатомия на пробива в ИТ системите на Uber: защо случката засяга всички

Наистина ли има толкова голямо значение кой е хакерът или как е влязъл в системата?
(снимка: CC0 Public Domain)

В дните след 15 септември бе оповестен пробив в ИТ системите на Uber. Тогава се изписа много за това как един 18-годишен нападател е успял да проникне в ИТ инфраструктурата на фирмата – гигант в бизнеса със споделени пътувания – и е смогнал да получи достъп до чувствителни потребителски данни. Човешкият елемент в тази история получава голямо внимание. Мнозина се фокусират върху слабостите на многофакторната автентификация (MFA). Говори се и за други проблеми, свързани с опазването на идентичността.

Актуализацията на сигурността на Uber от 19 септември отговори на някои въпроси, но същевременно предизвика нови такива. Фирмата посочи Lapsus$ като потенциален извършител на нападението.

Продължавайки да следим историята, не можем да не се запитаме: „Наистина ли има толкова голямо значение кой е нападателят или как е влязъл вътре?“ Ако сте възприели концепцията за неизбежния пробив, то това, което прави атаката забележителна (ако не броим популярността на организацията-жертва), е случилото се след нея.

Въз основа на анализа на Червения екип на CyberArk и наличните анонси ние разнищваме пробива в инфраструктурата на Uber с фокус върху вградените идентификационни данни – истинската „точка на възпламеняване“ при тази атака. Според наличните публикации, въпросните данни са били използвани за получаване на административен достъп до Системата за управление на привилегирован достъп (PAM) на организацията ( предоставено от друг доставчик). Това е отключило достъп с по-висока степен на риск. Също така показваме как множеството защити, изградени на пластове, могат да работят заедно, за да помогнат за забавяне или блокиране на подобни атаки.

„Голяма част от анализа на кибератаката на Uber се фокусира върху социалното инженерство и множеството вектори на MFA атаките. Ала истинската повратна точка за атаката се случва след първоначалния достъп. Наличието на идентификационни данни, вписани в неправилно конфигуриран мрежов дял, е от решаващо значение за анализа на тази атака. Не друго, а идентификационните данни за PAM решението, вградени в PowerShell скрипт, са това, което позволява на атакуващия да добие достъп на високо ниво, да разшири привилегиите си и да започне същински „работен ден“ в ИТ средата на Uber. Проактивната защита разчита на внедряването на множество слоеве за сигурност, но най-важното, което тази атака препотвърждава, е голямата поука: презумпцията за неизбежния пробив“, казва Шай Нахари, вицепрезидент на Червения екип в CyberArk.

Анатомия на Uber атаката: какво знаем от официалните съобщения

Фаза 1: Първоначален достъп. Нападателят е проникнал в ИТ средата на Uber, добирайки се до идентификационни данни за VPN инфраструктурата на Uber.

Фаза 2: Откриване. Най-вероятно този злодеятел не е имал специални или повишени привилегии за чувствителни ресурси. Но е имал достъп до мрежов дял, подобно на други служители на Uber. Този мрежов дял е бил или отворен, или неправилно конфигуриран, за да позволи на всички да четат ACL списъка. В рамките на мрежовия дял нападателят е открил PowerShell скрипт, съдържащ вградени (т. нар. твърдо кодирани) идентификационни данни за привилегирован достъп до PAM решението на Uber.

Кратко отклонение: както ИТ екипите, така и разработчиците често автоматизират задачи, създавайки скриптове. Тези скриптове се нуждаят от някаква форма на идентификационни данни за извършване на удостоверяване (напр. ръчно архивиране или генериране на персонализирани отчети чрез изтегляне на данни от бази данни). Въпросните идентификационни данни могат да бъдат всякакви – от SSH ключове и API токени до други пароли и привилегировани токени. За да си спестят време и да автоматизират работата, разработчиците имат навика да вграждат (да вписват директно, да „кодират твърдо“) тези идентификационни данни – вътре в кода. Това прави идентификационните данни достъпни за всички, които имат достъп до кода, и трудни за управление и ротация. При пробива в Uber вградените идентификационни данни осигуряват административен достъп до Системата за управление на привилегирован достъп. Тези идентификационни данни изглежда не са били ротирани от известно време – което ги прави много по-лесни за използване.

Фаза 3: Разширяване на привилегиите, достъп до PAM системата. Използвайки вградените идентификационни данни от администраторско ниво за Системата за управление на привилегирован достъп, нападателят е успял да разшири допълнително правата си.

Фаза 4: Достъп до тайните в PAM системата, достигане до критични фирмени системи. Според последната информация от Uber, в крайна сметка атакуващият е добил „разширени права за редица инструменти“. Когато е налице достъп до тайните от Системата за управление на привилегирован достъп, потенциалът за щети е значителен. Съобщава се, че нападателят е компрометирал достъпа до SSO и конзолите, както и до конзолата за управление на облака, където Uber съхранява чувствителни клиентски и финансови данни.

Фаза 5: Извличане на данни. Макар че Uber все още разследва инцидента, компанията потвърди, че нападателят е „изтеглил вътрешни Slack съобщения, а също така е получил достъп до или е изтеглил информация от вътрешен инструмент, който финансовият екип използва за управление на някои фактури“.

Съвети за справяне с вградените идентификационни данни като част от стратегиите за задълбочена защита

От наша гледна точка проактивната защита изисква „отбрана в дълбочина“ – комбинация от допълващи се слоеве за сигурност – следвайки стратегия за „нулево доверие“, която разчита на силни контроли с възможно най-малко привилегии. Може би най-важното в този случай е да нямате вградени идентификационни данни – на първо място.

За да намалите кибер-риска в своята собствена организация, препоръчваме да се съсредоточите върху елиминирането на тази практика и да направите инвентаризация на съществуващата среда. Целта е да намерите и премахнете вградени идентификационни данни, които биха могли да са вписани в код, PaaS конфигурации, DevOps инструменти и вътрешно разработени приложения.  Знаем, че това е лесно за казване и не толкова лесно да изпълнение, затова първо се съсредоточете върху най-критичните и мощни идентификационни данни и тайните на своята организация. Чак след това разширете най-добрите практики за управление на тайните, за да намалите риска измеримо с течение на времето.

След като сте направили план за справяне с „твърдо кодираните“ идентификационни данни, помислете за няколко допълнителни стъпки, за да подсилите защитите си:

• Кражбата на идентификационни данни остава водещ източник на риск. И, както се видя наскоро, нападателите стават все по-добри в заобикалянето на MFA. Те използват различни вектори и техники – в описаната история има множество компромиси с MFA. Вашите служители са Вашите пазители — обучавайте ги редовно да забелязват и докладват фишинг, за да избегнете компрометиране. Очаквайте бдителност, но не и съвършенство, тъй като атаките продължават да еволюират.

• Систематично прилагайте принципа на най-малко привилегии, започвайки от крайната точка. Целта е да се гарантира, че служителите и външните изпълнители имат възможно най-ниското ниво на права и разрешения, за да могат да вършат работата си. Конфигурирайте решенията за управление на привилегирован достъп с най-малко привилегии. Администраторите трябва да имат достъп само до такива привилегировани акаунти, които са абсолютно необходими за тяхната работа. Достъпът посредством профили трябва да бъде изолиран и стриктно удостоверяван.

• Описаната атака подчертава проблема с „нулевата тайна“, с който специалистите по сигурността отдавна се борят: какво се случва, ако някой получи достъп до абсолютните удостоверителни данни – онези, които защитават всички други удостоверителни данни? Ето защо са от критично значение силните проактивни и реактивни контроли за „отбрана в дълбочина“. Дори ако MFA не сработи, трябва да има допълнителни механизми за идентифициране и блокиране на заплахите, преди зложелателите да достигнат тази точка.

• Намалете до минимум постоянния привилегирован достъп. Премахването на постоянния достъп до чувствителна инфраструктура и уеб- или облачни конзоли може да помогне на организациите да ограничат „страничното движение“, пристъпвайки от компромис към мощно решение за сигурност. Особено в комбинация със силни средства за удостоверяване, времево-ограниченото повишаване на привилегиите може значително да намали достъпа на всяка компрометирана идентичност, ограничавайки радиуса на поразителната сила на нападателя.

Случилото се с Uber не е пробив, за който може да се обвини едно лице или един доставчик, нито е пробив, който едно технологично решение би могло да предотврати. Ето защо защитата в дълбочина е толкова важна: тя затруднява нападателите да работят, да се движат и в крайна сметка да постигат целите си.