TSM - Situația e fără speranță, dar nu serioasă: Obținerea unui S3 Bucket Negligence Award

S3 Bucket Negligence Award, un termen inventat de Corey Quinn , autorul picantelor newsletter și podcast "Last Week in AWS", se referă la politicile security-as-an-afterthought ce au dus la tot felul de rezultate spectaculoase.

Dacă nu sunteți interesați să citiți complet acest modest articol, important de reținut este următorul S3 Bucket policy, pentru reușite și popularitate:

{  
  "Version":"2012-10-17",  
  "Statement":[  
    {  
      "Sid":"FreeForAll",  
      "Effect":"Allow",  
      "Principal": {"AWS": ["\*"]},  
      "Action":["s3:\*"],  
      "Resource":
       ["arn:aws:s3:::mybucket/\*"]  
    }  
  ]  
}

Un scurt ocol prin istorie - AWS, S3, IAM

AWS (Amazon Web Services) este o filială a prea-bine cunoscutei Amazon care oferă platforme de on-demand cloud computing.

AWS a fost lansat în martie 2006, în urma cu 13 ani, fiind principalul actor pe piața furnizorilor de platforme cloud, cu un venit raportat pe 2018 de $25.6 miliarde.

Primul serviciu din cadrul AWS a fost S3 (Simple Storage Service), lansat pe 13 martie 2006 (anunțat în aceeași zi), în timp ce IAM (Identity & Access Management) a fost dat spre folosire generală pe 25 februarie 2011, aproape cinci ani mai târziu!.

Ca atare, identity & access management la nivel de S3 este o "struțocămilă" formată din S3 Bucket policies și ACL-uri (Access Control Lists), configurate individual pentru fiecare S3 Bucket .(Evangheliști ai infrastructure-as-code ar menționa aici posibilitatea automatizării).

Se urmează acest ghid simplu pentru a dezlănțui infernul pentru datele utilizatorilor voștri

1. Cum a fost precizat și în introducere, scurtătura este în a seta s3:(acțiunea) pentru (principals / conturile și utilizatorii afectați) pe my_bucket; (resursa) în configurația de bucket policy. Merită încercat!
2. Sigur, e posibil ca unii plicticoși din echipa de SecOps să fi setat o notificare prin AWS SNS și AWS Configure pentru a nu permite asemenea politici în S3. Nu vă fie teamă, există alternativă: se pot seta ca fiind publice obiectele din S3: login în consola AWS, mers la panoul de control pentru S3, și selectând bucket-ul și obiectul tință, se face click dreapta și Make public.

Voilà!

1. Oh, nu! Nu aveți acces de scriere la acel S3 Bucket cu date senzitive. Sau poate aveți, dar este configurată opțiunea de MFA Delete. Nu vă panicați. Se prea poate ca unul din serverele de Jenkins ale organizației să aibă permisiunile necesare. Escaladarea de privilegii, mereu la îndemână! Rapid creați un Freestyle Job și scrieți următorul shell script care să fie executat:

{  
  "Version":"2012-10-17",  
  "Statement":[  
    {  
      "Sid":"FreeForAll",  
      "Effect":"Allow",  
      "Principal": {"AWS": ["\*"]},  
      "Action":["s3:\*"],  
      "Resource":
       ["arn:aws:s3:::mybucket/\*"]  
    }  
  ]  
}

1. Sau se pot lasă secrete (chei AWS, chei SSH, credențialele unui satelit, etc.) înăuntrul unui S3 Bucket. Este o metodă relativ pasivă, dar cu siguranță suficient de distractivă.

În concluzie?

Dacă aveți nevoie de a reține toate acestea, recomand flaws.cloud, un sandbox cu exerciții cu diverse vulnerabilițăți de S3 și IAM.

Nu vă temeți niciodată! Având în vedere creșterea zilnică a feature-urilor în AWS, și ca atare a complexității și suprafeței vulnerabile, există mereu posibilitatea de a împiedica buna funcționare a politicilor și a verificărilor create de echipele de [SecOps](https://blyx.com/2018/07/18/my-arsenal-of-aws-security-tools/ ).