Avastades 25K AWS S3 kopasid

AWS S3 ämbrite lubadega seotud probleemid on sama vanad kui teenus ise. Arvan, et Skyhigh viis läbi kaks selle teema kõige tuntumat uurimist, viidates sellele, et 7% kõigist S3-ämbritest on avatud, ja Rapid7, et isegi 17% on avatud. Täna oleme 2018. aastal ja otsustasin kontrollida, milline on probleemi praegune seis. Lisaks tahan tutvustada oma uurimistöö tehnikaid - kui mul mõni nutikas puudu oleks, palun andke sellest kommentaarides teada.

Alustame mõne teooriaga

Kõigile AWS S3 koppidele pääseb juurde järgmiste URL-ide abil:

https: // [kopa_nimi] .s3.amazonaws.com /
https: // [aws_endpoint] .amazonaws.com / [kopa_nimi] /

või kasutades AWS CLI:

$ aws s3 ls - piirkond [piirkonna_nimi] s3: // [kopa_nimi]

Mitte sageli ei osuta inimesed piirkonna parameetri kasutamise vajadusele. Mõned ämbrid ei tööta piirkonda täpsustamata. Ma ei näe mustrit, kui see töötab ja kui see pole nii hea tava, tuleb see parameeter alati lisada :)

Niisiis, kehtiva ämbri leidmine võrdub üldiselt s3.amazonaws.com või [aws_endpoint] .amazonaws.com alamdomeeni leidmisega. Allpool tutvun 4 meetodiga, millest võib selle ülesande täitmisel abi olla.

Pruutjõud

Iga kopa nimi peab olema unikaalne ja sisaldama vaid mõne erandiga 3–63 tähtnumbrilist märki (võib sisaldada „-” või „.”, Kuid seda ei saa alustada ega lõpetada). Nagu öeldud, oleme relvastatud piisavalt teadmistega, et leida kõik S3 ämbrid, kuid olgem ausad - see toimiks pigem lühinimede puhul. Sellele vaatamata kipuvad inimesed nimetamisel kasutama mõnda mustrit, nt. [ettevõtte_nimi] -dev või [ettevõtte_nimi]. varundamine. Kui olete otsinud konkreetse ettevõtte ämbri, saate hõlpsalt automatiseerida selliste tuntud mustrite kontrollimise protsessi, kasutades selliseid tööriistu nagu LazyS3 või aws-s3-bruteforce. Ütleme nii, et meil on ettevõte nimega Rzepsky. Lihtne käsk: $ ruby ​​lazys3.rb rzepsky näitab rzepsky-dev ämbri:

Aga mis siis, kui soovite koristada võimalikult palju koppe, ilma et oleks alustatud konkreetset nime? Jätkake selle postituse lugemist;)

Tagasitee masin

Kas olete kunagi Waybacki masinast kuulnud? Tsiteerides Vikipeediat:

Teekonnaautomaat on Interneti-arhiivi loodud veebimaailma ja muu Internetis sisalduva teabe digitaalne arhiiv.

Mõned selle digitaalarhiivi ressursid on salvestatud Amazoni taristule. Sellegipoolest, kui Wayback Machine on S3-koppis indekseerinud vaid ühe foto, saame selle teabe hankida ja kontrollida, kas see kopp sisaldab avalikke ressursse. Isegi siis, kui indekseeritud foto on juba eemaldatud (või sellele juurdepääsu keelatakse), on teil siiski kopa nimi, mis annab lootuse leida seest huvitavaid faile. Wayback Machine'i API-liidese küsimiseks võite kasutada Metasploiti moodulit nimega enum_wayback:

Nagu mäletate selle postituse algusest, võite viidata kopa sisule ka piirkonna spetsifikatsiooniga URL-i abil. Veelgi paremate tulemuste saamiseks saame kontrollida kõigi võimalike Amazon S3 lõpp-punkti alamdomeene lihtsa bash-vooderdise abil:

$ lugedes -r regioon; Kas msfconsole -x "kasuta \ abi- / skannerit / http / enum_wayback; määra DOMAIN $ piirkond; \
määra OUTFILE $ region.txt; jooksma; exit "; tehtud 

Väga sageli annab Wayback Machine teile tagasi tuhandeid pilte, mis on paigutatud ühte ämbrisse. Seega peate tegema ainult mõned toimingud, et tõmmata välja ainult kehtivad ja kordumatud koppnimed. Programmid nagu cut ja awk on siin suurepärased sõbrad.

Wayback Machine andis mulle 23498 potentsiaalset ämbrit 398,7 MB txt-failide kujul. Nendest ämbritest 4863 olid avalikult avatud.

Kolmandate osapoolte päringud

Veel üks tehnika, mida tahaksin tutvustada, on kolmandate osapoolte (nt Google, Bing, VirusTotal jne) päringud. On palju tööriistu, mis saavad automatiseerida huvitavate andmete kogumist välistest teenustest. Üks neist on Sublist3r:

Jällegi peaksime otsima iga piirkonna alamdomeenidest ja tõmbama seejärel välja ainult unikaalsed ämbrinimed. Kiire bash ühevooderdisega:

$ lugedes -r regioon; teha python3 sublist3r.py -d $ region \
> $ piirkond.txt; tehtud 

annab tulemuseks 756, millest… oli koguda vaid 1 kopp. Õlu administraatoritele!

Otsimine sertifikaatide läbipaistvusloogidest

Viimane tehnika, mida ma teile tutvustada tahaksin, on koppnimede otsimine, jälgides sertifikaatide läbipaistvusloke. Kui te pole sertifikaatide läbipaistvusega kursis, soovitan teil seda esitlust vaadata. Põhimõtteliselt on iga väljaantud TLS-sertifikaat logitud ja kõik need logid on avalikult juurdepääsetavad. Selle idee peamine eesmärk on kontrollida, kas mõnda sertifikaati pole ekslikult või pahatahtlikult kasutatud. Avalike logide idee paljastab siiski kõik domeenid, sealhulgas… jah, ka S3-ämbrid. Hea uudis on see, et teie otsimiseks on juba saadaval tööriist - ämbervoog. Veel parem uudis on see, et see tööriist kontrollib ka leitud ämbri õigusi. Laskem siis pildistada:

$ python3 bucket-stream.py - lõimed 100 - log

Pärast 571134 võimaluste kontrollimist andis kopp-skanner mulle tagasi 398 kehtivat ämbrit. Neist 377 olid avatud.

Ämbri sisu kontrollimine

Hea küll, me leidsime tuhandeid ämbernimesid ja mis edasi? Noh, näiteks saate kontrollida, kas mõni nendest ämbritest lubab avalikku või iga autentitud AWS-i kasutajat (mis on põhimõtteliselt sama mis avalik). Sel eesmärgil saate kasutada minu skripti BucketScanner - see loetleb lihtsalt kõik juurdepääsetavad failid ja kontrollib ka KIRJUTAMISE õigusi. Selle uurimistöö jaoks muutsin aga bucket_reader meetodit järgmisel viisil:

def bucket_reader (kopa_nimi):
    piirkond = saada_regioon (kopa_nimi)
    kui piirkond == 'puudub':
        üle andma
    muu:
        kopp = saada_bucket (kopa_nimi)
        tulemused = ""
        proovige:
            jaoks s3_object kaustas bucket.objects.all ():
                kui s3_object.key:
                    print "{0} on kogutav" .vorming (kopa_nimi)
                    results = "{0} \ n" .vorming (kopa_nimi)
                    append_output (tulemused)
                    vaheaeg

Kuigi see pole oma töö kõige elegantsem viis - kui ämbrisse sai koguda vaid ühe faili, siis minu muudetud skanner teatab selle ämbri kogutavaks.

Riskid

Avalikult juurdepääsetavate failide hulgast leiate tõesti huvitavaid. Kuid tundlike andmete lekkimine pole ainus risk.

Mõned ämbrid on avalikult kirjutatavad. Kindlasti võib ründaja kasutada sellist ämbrit pahavara levitamise punktina. Veelgi hirmutav on see, kui kasutate sellist ämbrit legitiimse tarkvara levitamiseks oma töötajate seas - kujutage vaid ette sellist stsenaariumi: juhendate kõiki uustulnukaid ettevõtte ämbrist tarkvara installima ja ründaja kirjutab selle tarkvara juba üle nakatunud paigaldaja. Selle stsenaariumi teine ​​variatsioon oleks S3 teadlaste trollimine - nt. laadides üles nakatunud faili ahvatleva nimega, näiteks “Palgaaruanne - 2017.pdf” (muidugi laadivad kõik vastutavad teadlased alati ebausaldusväärsed failid liivakastide keskkonda, eks?)

Teine oht avalikult kirjutatavate ämbrite kasutamisel on see, et võite kaotada kõik oma andmed. Isegi kui teil pole koppiobjektide kustutamise õigusi, kuid lihtsalt WRITE-loaga, saate faili üle kirjutada. Kui aga kirjutate mõne faili tühja failiga üle, tähendab see, et see fail pole enam kellelegi kättesaadav. Vaatame seda näidet:

Ainus mehhanism, mis säästab teie andmeid sellises stsenaariumis, on versioonide lubamine. See mehhanism võib siiski olla kallis (see kahekordistab teie ämbris kasutatud ruumi suurust) ja paljud inimesed ei otsusta seda kasutada.

Olen kuulnud ka argumenti:

Jah, see on lihtsalt ämber testimise jaoks.

Noh, kui teie "test" kopp saab ebaseadusliku sisu salvestusruumi, siis ... vabandust, kutt, kuid see on teie kontole kinnitatud teie krediitkaart.

Kas mõni helgem tulevik on?

S3 ämbrite lubade probleem on endiselt olemas ja ma ei oota lähitulevikus märkimisväärset muutust. IMHO inimesed annavad avalikkusele juurdepääsu, kuna see töötab alati - te ei pea muretsema lubade määramise pärast, kui S3-teenus teeb koostööd teiste teenustega. Teine põhjus võib olla lihtne viga lubade konfigureerimisel (nt tähemärgi „*” sisestamine koppipoliitikasse valesse kohta) või et eelnevalt määratletud rühmade mitte mõistmine (nt rühma AWS abil saab ikkagi seada mis tahes autentitud AWS-i konto) CLI).

Teine probleem on, kuidas sellistest probleemidest teatada? Kätte pole kinnitatud ühtegi e-posti, nii et te ei saa kunagi kindel olla, kellega peaksite ühendust võtma. Ämbrite nimed võivad näidata, et nad kuuluvad firmasse X, kuid pidage meeles, et igaüks võib seda vabalt nimetada. Nii et olge kärud!

Kokkuvõte

24652 skannitud ämbri jaoks suutsin ma faile 5241 ämbrist (21%) ja suvalisi faile 1365 ämbrisse (6%) üles laadida. Tulemuste põhjal võin kahtlemata öelda, et probleem on endiselt olemas. Ehkki mõned ämbrid on tahtlikult avatud (nt kuvatakse mõned pildid, ettevõtete brošüürid jne), ei tohiks kumbki neist olla avalikult kirjutatav. Olen üsna kindel, et on ka muid ägedaid meetodeid veelgi ämbrite leidmiseks, nii et ainus mõistlik vastumeede näib olevat… oma ämbrile õigete õiguste seadmine

Siit leiate ka minu seitsmeastmelise juhendi oma AWS-i kuningriigi kindlustamiseks.