19. július 2019-én a Capital One megkapta azt az üzenetet, amelytől minden modern vállalat tart – adatszivárgás történt. Több mint 106 millió embert érintett. 140 000 amerikai társadalombiztosítási szám, egymillió kanadai társadalombiztosítási szám. 80 bankszámla. Kellemetlen, nem értesz egyet?
Sajnos július 19-én nem történt feltörés. Mint kiderült, Paige Thompson, a.k.a. Akadozó, 22. március 23. és március 2019. között követte el. Azaz majdnem négy hónapja. Valójában csak külső tanácsadók segítségével tudta a Capital One felfedezni, hogy valami történt.
Az Amazon egy korábbi alkalmazottját letartóztatták, és 250 XNUMX dolláros pénzbírsággal és öt év börtönnel sújtják... de még mindig sok negatívum maradt. Miért? Mert sok olyan vállalat, amelyik megszenvedte a feltöréseket, megpróbálja levenni a felelősséget infrastruktúrája és alkalmazásai megerősítéséért a növekvő kiberbűnözés közepette.
Amúgy ezt a történetet nyugodtan rákeresheted a google-ba. Nem megyünk bele a drámába, hanem beszéljünk róla műszaki oldala a dolognak.
Először is, mi történt?
A Capital One-ban körülbelül 700 S3-as vödör futott, amelyeket Paige Thompson lemásolt és kiszívott.
Másodszor, ez egy másik eset a rosszul konfigurált S3-gyűjtő-házirendről?
Nem, nem most. Itt hozzáfért egy rosszul beállított tűzfalú szerverhez, és onnan hajtotta végre a teljes műveletet.
Várj, ez hogyan lehetséges?
Nos, kezdjük azzal, hogy bejelentkezünk a szerverre, bár sok részlettel nem rendelkezünk. Csak azt mondták nekünk, hogy ez egy „rosszul konfigurált tűzfalon” keresztül történt. Tehát valami olyan egyszerű dolog, mint a biztonsági csoport helytelen beállításai vagy a webalkalmazás tűzfalának (Imperva) vagy hálózati tűzfalának (iptables, ufw, shorewall stb.) konfigurálása. A Capital One csak elismerte bűnösségét, és azt mondta, hogy bezárta a lyukat.
Stone szerint a Capital One kezdetben nem vette észre a tűzfal sebezhetőségét, de gyorsan cselekedett, amint tudomást szerzett róla. Ebben minden bizonnyal segített az a tény, hogy a hacker állítólag kulcsfontosságú azonosító információkat hagyott nyilvánosságra, mondta Stone.
Ha kíváncsi arra, hogy miért nem megyünk bele mélyebben ebbe a részbe, kérjük, vegye figyelembe, hogy a korlátozott információ miatt csak találgathatunk. Ennek nincs értelme, mivel a feltörés a Capital One által hagyott lyukon múlott. És hacsak nem árulnak el többet, csak felsoroljuk az összes lehetséges módot, amellyel a Capital One nyitva hagyta a szerverét, valamint az összes lehetséges módot, amellyel valaki használhatja e különböző lehetőségek valamelyikét. Ezek a hibák és technikák a vadul ostoba mulasztásoktól a hihetetlenül összetett mintákig terjedhetnek. Tekintettel a lehetőségek tárházára, ez egy hosszú saga lesz, valódi következtetés nélkül. Ezért koncentráljunk annak a résznek az elemzésére, ahol tényekkel rendelkezünk.
Az első lépés tehát a következő: tudja, mit tesz lehetővé a tűzfala.
Hozzon létre egy szabályzatot vagy megfelelő folyamatot annak biztosítására, hogy CSAK azt nyissa meg, amit ki kell nyitni. Ha olyan AWS-erőforrásokat használ, mint a biztonsági csoportok vagy a hálózati ACL-ek, nyilvánvalóan hosszú lehet az ellenőrző lista, amelyre az ellenőrzésre kerül sor... de ahogy sok erőforrás automatikusan létrejön (azaz a CloudFormation), lehetőség van a megfigyelésük automatizálására is. Legyen szó házi készítésű szkriptről, amely új objektumokat vizsgál meg hibákat keresve, vagy valami, például egy CI/CD-folyamat biztonsági auditját... számos egyszerű lehetőség van ennek elkerülésére.
A történet "vicces" része az, hogy ha a Capital One betömte volna a lyukat, akkor semmi sem történt volna. És hát, őszintén szólva, mindig megdöbbentő látni, hogy valami tényleg elég egyszerű ez az egyetlen oka annak, hogy egy vállalatot feltörjenek. Főleg egy akkora, mint a Capital One.
Szóval, hacker belül – mi történt ezután?
Nos, miután betört egy EC2 példányba... sok minden elromolhat. Gyakorlatilag késélen jársz, ha valakit idáig engedsz. De hogyan került az S3 vödrökbe? Ennek megértéséhez beszéljük meg az IAM szerepköröket.
Tehát az AWS-szolgáltatások elérésének egyik módja a felhasználó. Oké, ez elég nyilvánvaló. De mi van akkor, ha más AWS-szolgáltatásokhoz, például az alkalmazásszerverekhez szeretne hozzáférést biztosítani az S3-tárolókhoz? Erre valók az IAM-szerepek. Két összetevőből állnak:
- Bizalmi politika – mely szolgáltatások vagy emberek használhatják ezt a szerepet?
- Engedélyezési szabályzat – mit tesz lehetővé ez a szerepkör?
Például szeretne létrehozni egy IAM-szerepkört, amely lehetővé teszi az EC2-példányok számára, hogy hozzáférjenek egy S3-csoporthoz: Először is, a szerepkör olyan megbízhatósági házirenddel van beállítva, amellyel az EC2 (a teljes szolgáltatás) vagy bizonyos példányok „átvehetik” a szerepet. Egy szerep elfogadása azt jelenti, hogy használhatják a szerepkör engedélyeit műveletek végrehajtására. Másodszor, az engedélyek házirendje lehetővé teszi a „szerepet elvállaló” szolgáltatásnak/személynek/erőforrásnak, hogy bármit megtegyen az S3-on, legyen szó egy adott gyűjtőkör eléréséről... vagy 700 felett, mint a Capital One esetében.
Miután egy EC2-példányban van IAM szerepkörrel, többféle módon szerezhet hitelesítő adatokat:
- Példány metaadatokat kérhet a címen
http://169.254.169.254/latest/meta-dataTöbbek között ezen a címen bármelyik hozzáférési kulccsal megtalálhatja az IAM szerepkört. Természetesen csak akkor, ha egy adott esetben.
- AWS CLI használata...
Ha az AWS parancssori felület telepítve van, akkor a rendszer betölti az IAM-szerepkörökből származó hitelesítő adatokat, ha vannak. Csak a példányon keresztül kell dolgozni. Természetesen, ha a bizalmi szabályzatuk nyitott, Paige mindent közvetlenül megtehet.
Tehát az IAM-szerepek lényege, hogy lehetővé teszik bizonyos erőforrások számára, hogy AZ ÖN NEVÉBEN cselekedjenek MÁS ERŐFORRÁSOKRA.
Most, hogy megértette az IAM szerepét, beszélhetünk arról, amit Paige Thompson tett:
- A tűzfalon lévő lyukon keresztül jutott hozzá a szerverhez (EC2 példány).
Legyen szó biztonsági csoportokról/ACL-ekről vagy saját webalkalmazás-tűzfalukról, a lyukat valószínűleg meglehetősen könnyű betömni, amint az a hivatalos nyilvántartásokban szerepel.
- Miután felkerült a szerverre, képes volt úgy viselkedni, mintha ő maga lenne a szerver
- Mivel az IAM-szerver szerepkör lehetővé tette az S3 számára a hozzáférést ehhez a 700+ gyűjtőhöz, hozzáférhetett hozzájuk
Ettől a pillanattól kezdve már csak a parancsot kellett végrehajtania List Bucketsmajd a parancsot Sync az AWS CLI-ből...
. Az ilyen károk megelőzése az oka annak, hogy a vállalatok olyan sokat fektetnek a felhőalapú infrastruktúra védelmébe, a DevOps-ba és a biztonsági szakértőkbe. És mennyire értékes és költséghatékony a felhőbe költözés? Olyannyira, hogy még az egyre több kiberbiztonsági kihívás ellenére is !
A történet morálja: ellenőrizze biztonságát; Rendszeres ellenőrzéseket végezzen; Tartsa tiszteletben a biztonsági politikák legkisebb kiváltsága elvét.
( Megtekintheti a teljes jogi jelentést).
Forrás: will.com