На 19 јули 2019 година, Capital One ја доби пораката од која се плаши секоја модерна компанија - се случи прекршување на податоците. Погоди повеќе од 106 милиони луѓе. 140 американски броеви за социјално осигурување, еден милион канадски броеви за социјално осигурување. 000 банкарски сметки. Непријатно, не се согласувате?
За жал, хакирањето не се случи на 19 јули. Како што се испоставува, Пејџ Томпсон, a.k.a. Непостојана, го извршил во периодот од 22 март до 23 март 2019 година. Тоа е пред речиси четири месеци. Всушност, само со помош на надворешни консултанти Capital One успеа да открие дека нешто се случило.
Поранешен вработен во Амазон е уапсен и се соочува со парична казна од 250 долари и пет години затвор... но има уште многу негативност. Зошто? Бидејќи многу компании кои страдаат од хакери се обидуваат да ја отфрлат одговорноста за зајакнување на нивната инфраструктура и апликации во услови на пораст на компјутерскиот криминал.
Како и да е, можете лесно да ја прогуглате оваа приказна. Нема да навлегуваме во драма, туку зборуваме за тоа технички страна на работата.
Како прво, што се случи?
Capital One имаше околу 700 S3 кофи кои работеа, кои Пејџ Томпсон ги копираше и ги исфрли.
Второ, дали е ова уште еден случај на погрешно конфигурирана политика на корпата S3?
Не, овој пат не. Овде таа доби пристап до сервер со неправилно конфигуриран заштитен ѕид и ја изврши целата операција од таму.
Чекај, како е тоа можно?
Па, да почнеме со најавување на серверот, иако немаме многу детали. Ни беше кажано само дека тоа се случило преку „погрешно конфигуриран заштитен ѕид“. Значи, нешто едноставно како неточни поставки за безбедносни групи или конфигурација на заштитен ѕид на веб апликацијата (Imperva) или мрежниот заштитен ѕид (iptables, ufw, shorewall, итн.). Capital One само ја призна вината и рече дека ја затворил дупката.
Стоун рече дека Capital One првично не ја забележал ранливоста на заштитниот ѕид, но дејствувал брзо откако станал свесен за тоа. На ова секако помогна и фактот што хакерот наводно оставил клучни информации за идентификација во јавен домен, рече Стоун.
Ако се прашувате зошто не навлегуваме подлабоко во овој дел, ве молиме разберете дека поради ограничените информации можеме само да шпекулираме. Ова нема смисла со оглед на тоа дека хакирањето зависеше од дупката што ја остави Capital One. И освен ако не ни кажат повеќе, ние само ќе ги наведеме сите можни начини на кои Capital One го оставил отворен својот сервер во комбинација со сите можни начини на кои некој би можел да користи една од овие различни опции. Овие недостатоци и техники може да варираат од глупави превиди до неверојатно сложени модели. Со оглед на опсегот на можности, ова ќе стане долга сага без вистински заклучок. Затоа, да се фокусираме на анализа на делот каде што имаме факти.
Значи, првиот фаворит е: знајте што дозволуваат вашите заштитни ѕидови.
Воспоставете политика или соодветен процес за да се осигурате дека е отворено САМО она што треба да се отвори. Ако користите AWS ресурси како што се безбедносни групи или мрежни ACL, очигледно списокот за проверка за ревизија може да биде долг... но исто како што многу ресурси се креираат автоматски (т.е. CloudFormation), исто така е можно да се автоматизира нивната ревизија. Без разлика дали се работи за домашна скрипта која скенира нови објекти за пропусти, или нешто како безбедносна ревизија во процес на CI/CD... има многу лесни опции за да се избегне ова.
„Смешниот“ дел од приказната е дека доколку Капитал Оне ја затнеше дупката од прва... ништо немаше да се случи. И така, искрено, секогаш е шокантно да се види како нешто навистина прилично едноставно станува единствена причина за хакирање на една компанија. Посебно една голема како Capital One.
Значи, хакер внатре - што се случи следно?
Па, по упадот во примерок EC2... многу може да тргне наопаку. Практично одите на работ од ножот ако дозволите некој да оди толку далеку. Но, како влезе во корпите на S3? За да го разбереме ова, ајде да разговараме за улогите на IAM.
Значи, еден начин за пристап до услугите AWS е да се биде Корисник. Добро, ова е прилично очигледно. Но, што ако сакате да им дадете на другите услуги AWS, како што се вашите сервери за апликации, пристап до вашите корпи S3? За тоа служат улогите на IAM. Тие се состојат од две компоненти:
- Политика на доверба - кои услуги или луѓе можат да ја користат оваа улога?
- Политика за дозволи - што дозволува оваа улога?
На пример, сакате да креирате улога на IAM што ќе им овозможи на примероците на EC2 да пристапат до корпата S3: Прво, улогата е поставена да има Политика на доверба што EC2 (целата услуга) или одредени примероци можат да ја „преземат“ улогата. Прифаќањето на улога значи дека тие можат да ги користат дозволите на улогата за да вршат дејства. Второ, Политиката за дозволи дозволува услугата/лицето/ресурсот што „ја презеде улогата“ да направи што било на S3, без разлика дали станува збор за пристап до една специфична кофа... или над 700, како во случајот со Capital One.
Откако ќе бидете во примерок EC2 со улогата на IAM, можете да добиете акредитиви на неколку начини:
- Може да побарате метаподатоци за пример на
http://169.254.169.254/latest/meta-dataМеѓу другото, можете да ја најдете улогата на IAM со кој било од копчињата за пристап на оваа адреса. Се разбира, само ако сте во некој пример.
- Користете AWS CLI...
Ако AWS CLI е инсталиран, тој е вчитан со ингеренциите од улогите на IAM, доколку е присутен. Останува само да се работи ПРЕКУ инстанцата. Се разбира, ако нивната Политика за доверба беше отворена, Пејџ можеше да стори сè директно.
Значи, суштината на улогите на IAM е дека тие дозволуваат некои ресурси да дејствуваат ВО ВАШЕ ИМЕ на ДРУГИ РЕСУРСИ.
Сега кога ги разбирате улогите на IAM, можеме да зборуваме за тоа што направи Пејџ Томпсон:
- Таа доби пристап до серверот (пример EC2) преку дупка во заштитниот ѕид
Без разлика дали станува збор за безбедносни групи/ACL или за нивните сопствени заштитени ѕидови на веб-апликации, дупката веројатно беше прилично лесно да се приклучи, како што е наведено во официјалните записи.
- Откако беше на серверот, таа можеше да се однесува „како“ да е самата сервер
- Бидејќи улогата на серверот IAM му дозволи на S3 пристап до овие 700+ корпи, тој можеше да пристапи до нив
Од тој момент, сè што требаше да направи е да ја изврши командата List Bucketsа потоа командата Sync од AWS CLI...
. Спречувањето на таквата штета е причината зошто компаниите инвестираат толку многу во заштита на инфраструктурата во облак, DevOps и безбедносни експерти. И колку вредно и исплатливо е преместувањето во облакот? Толку многу што дури и наспроти се повеќе и повеќе предизвици за сајбер безбедноста !
Морал на приказната: проверете ја вашата безбедност; Спроведување на редовни ревизии; Почитувајте го принципот на најмала привилегија за безбедносните политики.
( Можете да го погледнете целосниот правен извештај).
Извор: www.habr.com