19 ліпеня 2019 года банк Capital One атрымаў паведамленне, якога баіцца кожная сучасная кампанія - адбылася ўцечка дадзеных. Яна закранула больш за 106 мільёнаў чалавек. 140 нумароў сацыяльнага страхавання ЗША, 000 нумароў сацыяльнага страхавання Канады. 80 банкаўскіх рахункаў. Непрыемна, пагадзіцеся?
Нажаль, узлом адбыўся зусім не 19 ліпеня. Як высветлілася, Пэйдж Томпсан, яна ж Няўстойлівы, здзейсніла яго паміж 22 сакавіка і 23 сакавіка 2019 года. Гэта значыць амаль чатыры месяцы таму. Насамрэч, толькі з дапамогай вонкавых кансультантаў Capital One здолела пазнаць, што нешта адбылося.
Былая супрацоўніца Amazon арыштаваная, ёй пагражае штраф у памеры $250 тыс. і пяць гадоў турмы… але засталося шмат негатыву. Чаму? Таму што многія кампаніі, якія пацярпелі ад узломаў, спрабуюць адмахнуцца ад адказнасці за ўмацаванне сваёй інфраструктуры і дадаткаў на фоне росту кіберзлачыннасці.
У любым выпадку, вы можаце лёгка загугліць гэтую гісторыю. Мы не будзем удавацца ў драматызм, а пагаворым пра тэхнічнай баку справы.
Па-першае, што здарылася?
У Capital One працавала каля 700 бакетаў S3, якія Пэйдж Томпсан скапіявала і выкачала.
Па-другое, гэта яшчэ адзін выпадак няправільна настроенай палітыкі бакетаў S3?
Не, не на гэты раз. Тут яна атрымала доступ да сервера з няслушна настроеным файрвалам і адтуль правяла ўсю аперацыю.
Пачакайце, як гэта магчыма?
Ну, давайце пачнем з уваходу на сервер, хоць у нас мала падрабязнасцяў. Нам толькі сказалі, што гэта адбылося праз "няправільна настроены файрвол". Такім чынам, нешта настолькі простае, як няправільныя налады груп бяспекі ці канфігурацыя файрвала вэб-прыкладанні (Imperva), ці сеткавага файрвала (iptables, ufw, shorewall і т. д.). Capital One толькі прызнала сваю віну і сказала, што закрыла дзірку.
Стоўн сказаў, што Capital One першапачаткова не заўважыў уразлівасць файрвола, але хутка адрэагаваў, як толькі даведаўся пра яе. Безумоўна, гэтаму дапамог той факт, што хакер, як мяркуецца, пакінула ў адкрытым доступе ключавую ідэнтыфікуючую інфармацыю, сказаў Стоўн.
Калі вас цікавіць, чаму мы не паглыбляемся ў гэтую частку, зразумейце, што з-за абмежаванай інфармацыі мы можам толькі спекуляваць. Гэта бессэнсоўна, улічваючы, што ўзлом залежаў ад пралома, пакінутай Capital One. І калі яны не раскажуць нам больш, мы проста будзем пералічваць усе магчымыя спосабы, як Capital One пакінула свой сервер адкрытым у камбінацыі з усімі магчымымі спосабамі, якімі нехта можа выкарыстоўваць адзін з гэтых розных варыянтаў. Гэтыя праломы і метады могуць вар'іравацца ад дзіка дурных промахаў да неверагодна складаных патэрнаў. Улічваючы дыяпазон магчымасцяў, гэта ператворыцца ў доўгую сагу без рэальнага зняволення. Таму засяродзімся на аналізе той часткі, дзе ў нас ёсць факты.
Так што першая выснова: ведайце, што дазваляюць вашыя файрвалы
Усталюйце палітыку ці правільны працэс для гарантыі, што адкрыта ТОЛЬКІ тое, што павінна быць адкрыта. Калі вы выкарыстоўваеце рэсурсы AWS, такія як Security Groups або Network ACL, відавочна, чэкліст для праверкі можа быць доўгім… але як многія рэсурсы ствараюцца аўтаматычна (г.зн. CloudFormation), таксама можна аўтаматызаваць іх аўдыт. Будзь то самаробны скрыпт, які праглядае новыя аб'екты на прадмет праломаў, ці нешта накшталт аўдыту бяспекі падчас CI/CD… ёсць шмат простых варыянтаў, каб пазбегнуць гэтага.
"Пацешная" частка гісторыі заключаецца ў тым, што калі б Capital One закрыла дзірку з самага пачатку ... нічога б не здарылася. І таму, шчыра кажучы, заўсёды шакіруе бачыць, як сапраўды нешта даволі простае становіцца адзіным чыннікам узлому кампаніі. Асабліва такі вялікі, як Capital One.
Такім чынам, хакер усярэдзіне - што здарылася далей?
Ну, пасля пранікнення ў інстанс EC2… шмат што можа пайсці не так. Вы ходзіце практычна па лязе нажа, калі дазваляеце камусьці зайсці так далёка. Але як яна патрапіла ў бакеты S3? Каб зразумець гэта, давайце абмяркуем ролі IAM (IAM Roles).
Такім чынам, адзін са спосабаў атрымаць доступ да сэрвісаў AWS – быць Карыстальнікам (User). Добра, гэта даволі відавочна. Але што рабіць, калі вы жадаеце падаць іншым сэрвісам AWS, напрыклад, сваім серверам прыкладанняў, доступ да сваіх бакетаў S3? Для гэтага і існуюць ролі IAM. Яны складаюцца з двух кампанентаў:
- Trust Policy – якія службы ці якія людзі могуць выкарыстоўваць гэтую ролю?
- Permissions Policy – што дазваляе гэтая роля?
Напрыклад, вы жадаеце стварыць ролю IAM, якая дазволіць інстансам EC2 атрымаць доступ да бакету S3: па-першае, для ролі ўсталёўваецца Trust Policy, што EC2 (уся служба) ці пэўныя інстансы могуць "узяць на сябе" ролю. Прыняцце ролі азначае, што яны могуць выкарыстоўваць дазволы ролі для выканання дзеянняў. Па-другое, Permissions Policy дазваляе службе/чалавеку/рэсурсу, які "ўзяў на сябе ролю", рабіць нешта на S3, няхай гэта будзе доступ да аднаго канкрэтнага бакету… ці да больш за 700, як у выпадку Capital One.
Як толькі вы знаходзіцеся ў інстансе EC2 з роляй IAM, вы можаце атрымаць уліковыя дадзеныя некалькімі спосабамі:
- Можаце запытаць метададзеныя інстансы па адрасе
http://169.254.169.254/latest/meta-dataСярод іншага, па гэтым адрасе можна знайсці ролю IAM з любым ключам доступу. Вядома, толькі ў тым выпадку, калі вы знаходзіцеся ў інстансе.
- Выкарыстоўваць AWS CLI…
Калі ўсталяваны інтэрфейс каманднага радка AWS, то ён загружаецца з уліковымі дадзенымі з роляў IAM, калі яны прысутнічаюць. Застаецца толькі працаваць ПРАЗ інстанс. Вядома, калі б іх палітыка Trust Policy была адкрытай, Пэйдж магла б зрабіць усё напрамую.
Такім чынам, сутнасць роляў IAM заключаюцца ў тым, што яны дазваляюць адным рэсурсам дзейнічаць АД ВАШАГА ІМЯ НА ІНШЫХ РЭСУРСАХ.
Цяпер, калі вы разумееце ролі IAM, мы можам пагаварыць аб тым, што зрабіла Пэйдж Томпсан:
- Яна атрымала доступ да сервера (інстанс EC2) праз пралом у файрволе.
Няхай гэта будзе групы бяспекі / ACL або іх уласныя файрвалы вэб-прыкладанняў, верагодна, дзірку аказалася даволі лёгка закрыць, як паказана ў афіцыйных запісах.
- Апынуўшыся на серверы, яна змагла дзейнічаць "як быццам" сама была серверам
- Паколькі роля IAM сервера дазволіла доступ S3 да гэтых 700+ бакетам, яна змагла атрымаць да іх доступ.
З гэтага моманту ёй заставалася толькі запусціць каманду. List Buckets, а затым каманду Sync з AWS CLI…
. Прадухіленне такой шкоды - вось чаму кампаніі так шмат інвестуюць у абарону хмарнай інфраструктуры, DevOps і экспертаў па бяспецы. І наколькі каштоўным і эканамічна эфектыўным з'яўляецца пераход у воблака? Настолькі, што нават перад тварам усё новых і новых праблем кібербяспекі !
Мараль гэтай гісторыі: правярайце сваю бяспеку; рэгулярна праводзіце аўдыт; паважайце прынцып найменшых прывілеяў для палітык бяспекі.
( можаце паглядзець поўную юрыдычную справаздачу).
Крыніца: habr.com