На 19 юли 2019 г. Capital One получи съобщението, от което се страхува всяка съвременна компания – извършено е нарушение на данните. То засегна повече от 106 милиона души. 140 000 номера за социално осигуряване в САЩ, един милион номера за социално осигуряване в Канада. 80 000 банкови сметки. Неприятно, не сте ли съгласни?
За съжаление, хакът не се случи на 19 юли. Както се оказва, Пейдж Томпсън, a.k.a. Непостоянен, го е извършил в периода 22 март – 23 март 2019г. Това е преди почти четири месеца. Всъщност само с помощта на външни консултанти Capital One успя да открие, че нещо се е случило.
Бивш служител на Amazon беше арестуван и е изправен пред глоба от $250 XNUMX и пет години затвор... но все още има много негативизъм. Защо? Тъй като много компании, които са пострадали от хакове, се опитват да отменят отговорността за укрепване на своята инфраструктура и приложения на фона на нарастването на киберпрестъпността.
Както и да е, лесно можете да потърсите в Google тази история. Няма да навлизаме в драма, но ще поговорим за технически страна на въпроса.
Първо, какво се случи?
Capital One имаше около 700 работещи кофи S3, които Пейдж Томпсън копира и изцеди.
Второ, това поредният случай ли е на неправилно конфигурирана политика за кофа S3?
Не, не и този път. Тук тя получи достъп до сървър с неправилно конфигурирана защитна стена и извърши цялата операция оттам.
Чакай, как е възможно това?
Е, нека започнем с влизане в сървъра, въпреки че нямаме много подробности. Беше ни казано само, че това се е случило чрез „неправилно конфигурирана защитна стена“. И така, нещо толкова просто като неправилни настройки на групата за сигурност или конфигурация на защитната стена на уеб приложението (Imperva) или защитната стена на мрежата (iptables, ufw, shorewall и т.н.). Capital One само призна вината си и каза, че е затворил дупката.
Стоун каза, че Capital One първоначално не е забелязал уязвимостта на защитната стена, но е действал бързо, след като е разбрал за нея. Това със сигурност е било подпомогнато от факта, че хакерът е оставил ключова идентифицираща информация в публичното пространство, каза Стоун.
Ако се чудите защо не навлизаме по-задълбочено в тази част, моля, разберете, че поради ограничената информация можем само да спекулираме. Това няма смисъл, като се има предвид, че хакът зависи от дупка, оставена от Capital One. И освен ако не ни кажат повече, ние просто ще изброим всички възможни начини, по които Capital One е оставил сървъра си отворен в комбинация с всички възможни начини, по които някой може да използва една от тези различни опции. Тези недостатъци и техники могат да варират от изключително глупави пропуски до невероятно сложни модели. Предвид набора от възможности, това ще се превърне в дълга сага без истинско заключение. Затова нека се съсредоточим върху анализа на частта, в която имаме факти.
Така че първият извод е: знайте какво позволяват вашите защитни стени.
Създайте политика или подходящ процес, за да гарантирате, че се отваря САМО това, което трябва да се отвори. Ако използвате ресурси на AWS, като групи за сигурност или мрежови ACL, очевидно контролният списък за одит може да бъде дълъг... но точно както много ресурси се създават автоматично (т.е. CloudFormation), също е възможно да автоматизирате техния одит. Независимо дали става въпрос за домашен скрипт, който сканира нови обекти за недостатъци, или нещо като одит на сигурността в CI/CD процес... има много лесни опции за избягване на това.
„Смешната“ част от историята е, че ако Capital One беше запушил дупката на първо място... нищо нямаше да се случи. И така, честно казано, винаги е шокиращо да видиш как нещо наистина доста просто става единствената причина една компания да бъде хакната. Особено такъв голям като 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