Наистина ли има толкова голямо значение кой е хакерът или

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

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

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

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

Въз основа на разбора на Червения екип на и наличните анонси ние разнищваме пробива в инфраструктурата на 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 принадлежности и вътрешно създадени приложения.  Знаем, че това е елементарно за казване и не толкоз елементарно да осъществяване, по тази причина първо се концентрирайте върху най-критичните и мощни идентификационни данни и тайните на своята организация. Чак по-късно разширете най-хубавите практики за ръководство на тайните, с цел да намалите риска измеримо с течение на времето.

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

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