19 iyul 2019-cu ildə Capital One hər bir müasir şirkətin qorxduğu mesajı aldı - məlumat pozuntusu baş verdi. Bu, 106 milyondan çox insana təsir etdi. 140 ABŞ sosial təminat nömrəsi, bir milyon Kanada sosial təminat nömrəsi. 000 bank hesabı. Xoşagəlməz, razılaşmırsınız?
Təəssüf ki, hack iyulun 19-da baş vermədi. Göründüyü kimi, Peyc Tompson, a.k.a. Dözülməz, 22 mart - 23 mart 2019-cu il tarixləri arasında törədib. Yəni təxminən dörd ay əvvəl. Əslində, yalnız kənar məsləhətçilərin köməyi ilə Capital One nəyinsə baş verdiyini aşkar edə bildi.
Keçmiş Amazon işçisi həbs edildi və onu 250 dollar cərimə və beş il həbs gözləyir... amma hələ də çoxlu neqativlər qalıb. Niyə? Çünki haker hücumlarından əziyyət çəkən bir çox şirkət kibercinayətkarlığın artması fonunda öz infrastrukturunu və tətbiqlərini gücləndirmək məsuliyyətindən yayınmağa çalışır.
Hər halda, bu hekayəni google-da asanlıqla tapa bilərsiniz. Drama girməyəcəyik, amma danışacağıq texniki məsələnin tərəfi.
Əvvəla, nə oldu?
Capital One-da təxminən 700 S3 vedrəsi işləyirdi, Peyc Tompson onları köçürdü və sildi.
İkincisi, bu yanlış konfiqurasiya edilmiş S3 vedrə siyasətinin başqa bir halıdır?
Xeyr, bu dəfə deyil. Burada o, səhv konfiqurasiya edilmiş firewall ilə serverə giriş əldə etdi və bütün əməliyyatı oradan həyata keçirdi.
Gözləyin, bu necə mümkündür?
Yaxşı, bir çox detalımız olmasa da, serverə daxil olaraq başlayaq. Bizə yalnız bunun "yanlış konfiqurasiya edilmiş təhlükəsizlik duvarı" vasitəsilə baş verdiyini söylədilər. Beləliklə, səhv təhlükəsizlik qrupu parametrləri və ya veb tətbiqi təhlükəsizlik duvarının (Imperva) konfiqurasiyası və ya şəbəkə təhlükəsizlik duvarı (iptables, ufw, shorewall və s.) Capital One yalnız günahını etiraf etdi və deşiyi bağladığını söylədi.
Stone bildirib ki, Capital One əvvəlcə firewall zəifliyini hiss etməyib, lakin bundan xəbər tutan kimi tez hərəkətə keçib. Stoun dediyinə görə, buna şübhəsiz ki, hakerin əsas identifikasiya məlumatlarını ictimai sahəyə qoyması kömək etdi.
Niyə bu hissəyə daha dərindən getmədiyimizlə maraqlanırsınızsa, lütfən başa salın ki, məhdud məlumatlara görə yalnız fərziyyə edə bilərik. Hackin Capital One-ın buraxdığı çuxurdan asılı olduğunu nəzərə alsaq, bu heç bir məna kəsb etmir. Və onlar bizə daha çox məlumat verməsələr, biz sadəcə Capital One-ın öz serverini açıq qoymasının bütün mümkün yollarını sadalayacağıq və kiminsə bu müxtəlif variantlardan birini istifadə edə biləcəyi bütün mümkün yollarla birlikdə sadalayacağıq. Bu qüsurlar və texnikalar vəhşicəsinə axmaq nəzarətdən tutmuş inanılmaz dərəcədə mürəkkəb nümunələrə qədər dəyişə bilər. İmkanların genişliyini nəzərə alsaq, bu, heç bir real nəticəsi olmayan uzun bir dastana çevriləcək. Ona görə də gəlin faktların olduğu hissəni təhlil etməyə diqqət edək.
Beləliklə, ilk çıxış yolu budur: firewalllarınızın nəyə icazə verdiyini bilin.
YALNIZ açılmalı olanların açılmasını təmin etmək üçün siyasət və ya düzgün proses qurun. Əgər siz Təhlükəsizlik Qrupları və ya Şəbəkə ACL kimi AWS resurslarından istifadə edirsinizsə, yoxlanılacaq yoxlama siyahısı açıq-aydın uzun ola bilər... lakin bir çox resurs avtomatik olaraq yaradıldığı kimi (məsələn, CloudFormation), onların auditini avtomatlaşdırmaq da mümkündür. İstər yeni obyektləri qüsurlara görə skan edən evdə hazırlanmış skript olsun, istərsə də CI/CD prosesində təhlükəsizlik auditi kimi bir şey olsun... bunun qarşısını almaq üçün bir çox asan seçim var.
Hekayənin "gülməli" tərəfi ondan ibarətdir ki, əgər Capital One əvvəlcə dəliyi bağlasaydı... heç nə olmazdı. Və beləliklə, açığını desəm, bir şeyin həqiqətən necə olduğunu görmək həmişə şok olur olduqca sadə bir şirkətin sındırılmasının yeganə səbəbi olur. Xüsusilə Capital One qədər böyük olanı.
Beləliklə, içəridə haker - sonra nə oldu?
Yaxşı, EC2 instansiyasına daxil olduqdan sonra... çox şey səhv gedə bilər. Əgər kiminsə o qədər uzağa getməsinə icazə versəniz, praktiki olaraq bıçaq kənarında gəzirsiniz. Bəs S3 vedrələrinə necə daxil oldu? Bunu başa düşmək üçün gəlin IAM Rollarını müzakirə edək.
Beləliklə, AWS xidmətlərinə daxil olmağın bir yolu İstifadəçi olmaqdır. Tamam, bu olduqca aydındır. Bəs siz tətbiq serverləriniz kimi digər AWS xidmətlərinə S3 vedrələrinizə giriş imkanı vermək istəyirsinizsə nə etməli? IAM rolları bunun üçündür. Onlar iki komponentdən ibarətdir:
- Güvən Siyasəti - bu roldan hansı xidmətlər və ya insanlar istifadə edə bilər?
- İcazələr Siyasəti - bu rol nəyə imkan verir?
Məsələn, siz EC2 instansiyalarının S3 qutusuna daxil olmasına imkan verəcək IAM rolu yaratmaq istəyirsiniz: Birincisi, rolun EC2 (bütün xidmət) və ya xüsusi instansiyaların rolu “ələ keçirə biləcəyi” Güvən Siyasəti olmalıdır. Rolu qəbul etmək o deməkdir ki, onlar hərəkətləri yerinə yetirmək üçün rolun icazələrindən istifadə edə bilərlər. İkincisi, İcazələr Siyasəti “rolu öz üzərinə götürmüş” xidmətə/şəxsə/resursa S3-də hər hansı bir işi görməyə imkan verir, istər bir xüsusi vedrə daxil olsun... istərsə də Capital One-da olduğu kimi 700-dən çox.
IAM rolu ilə EC2 instansiyasında olduqdan sonra etimadnamələri bir neçə yolla əldə edə bilərsiniz:
- Nümunə metadatasını buradan tələb edə bilərsiniz
http://169.254.169.254/latest/meta-dataDigər şeylər arasında, bu ünvanda hər hansı bir giriş düyməsi ilə IAM rolunu tapa bilərsiniz. Əlbəttə ki, yalnız bir vəziyyətdə olsanız.
- AWS CLI istifadə edin...
AWS CLI quraşdırılıbsa, o, əgər varsa, IAM rollarından etimadnamələri ilə yüklənir. Qalır ki, misal vasitəsilə işləmək. Əlbəttə ki, onların Güvən Siyasəti açıq olsaydı, Peyc hər şeyi birbaşa edə bilərdi.
Beləliklə, IAM rollarının mahiyyəti ondan ibarətdir ki, onlar bəzi resurslara DİGƏR RESURSLARDA SİZİN Adınızdan hərəkət etməyə imkan verir.
İndi IAM-ın rollarını başa düşdüyünüz üçün Paige Thompsonun etdikləri barədə danışa bilərik:
- O, firewalldakı bir dəlik vasitəsilə serverə (EC2 nümunəsi) giriş əldə etdi
İstər təhlükəsizlik qrupları/ACL-lər, istərsə də öz veb tətbiqi firewallları olsun, rəsmi qeydlərdə qeyd edildiyi kimi, çuxurun bağlanması çox asan idi.
- Bir dəfə serverdə o, serverin özü kimi “sanki” davrana bildi
- IAM server rolu S3-ə bu 700+ vedrələrə giriş imkanı verdiyi üçün o, onlara daxil ola bildi
O andan etibarən onun etməli olduğu yeganə şey əmri yerinə yetirmək idi List Bucketsvə sonra əmr Sync AWS CLI-dan...
. Belə zərərin qarşısının alınması şirkətlərin bulud infrastrukturunun qorunmasına, DevOps-a və təhlükəsizlik mütəxəssislərinə bu qədər investisiya qoymasının səbəbidir. Və buluda keçmək nə qədər dəyərli və sərfəli olur? O qədər ki, getdikcə daha çox kibertəhlükəsizlik problemləri qarşısında belə !
Hekayənin əxlaqı: təhlükəsizliyinizi yoxlayın; Müntəzəm yoxlamalar aparmaq; Təhlükəsizlik siyasətləri üçün ən az imtiyaz prinsipinə hörmət edin.
( Tam hüquqi hesabata baxa bilərsiniz).
Mənbə: www.habr.com