Blog
Son zamanlarda, AWS Müşteri Olay Müdahale Ekibi (CIRT) ve otomatik güvenlik izleme sistemleri, Amazon Simple Storage Service (Amazon S3) depolama alanlarıyla ilişkili olağandışı şifreleme etkinliklerinde bir artış tespit etti.
Amazon, bu eylemlerin AWS hizmetlerindeki bir güvenlik açığından kaynaklanmadığını vurguluyor. Aksine, bu eylemlerin, yetkisiz bir kullanıcının geçerli kimlik bilgilerini, beklenmedik bir şekilde kullanması gerektiğini ifade ediyor. Bu eylemler, ortak sorumluluk modelinin müşteri alanında gerçekleşse de, AWS müşterilerin bu tür etkinlikleri önlemek veya etkisini azaltmak için kullanabileceği adımları önermektedir.
Müşterilerle birlikte çalışan Amazon güvenlik ekipleri, “SSE-C” (müşteri tarafından sağlanan anahtarlarla sunucu tarafı şifreleme) adı verilen bir şifreleme yöntemi kullanan S3 üzerindeki veri şifreleme olaylarında bir artış tespit etti. Bu, birçok müşteri tarafından kullanılan bir özellik olmakla birlikte, SSE-C kullanan çok sayıda S3 CopyObject işleminin nesneleri üzerine yazarak, müşteri verilerini yeni bir şifreleme anahtarıyla yeniden şifreleme etkisi oluşturduğu bir model fark etti. Yapılan analizler, bunun geçerli müşteri kimlik bilgilerini ele geçiren tehdit aktörleri tarafından yapıldığını ve bu bilgilerin nesneleri yeniden şifrelemek için kullanıldığını ortaya koydu.
Amazon güvenlik ekipleri, aktif savunma araçlarını kullanarak, bu tür yetkisiz etkinlikleri birçok durumda önlemeye yardımcı olacak otomatik önlemleri devreye aldı. Bu önlemler, müşterilerin kendilerini korumak için herhangi bir adım atmasına gerek kalmadan, girişimlerin yüksek bir yüzdesinin başarısız olmasını sağladı. Ancak, tehdit aktörleri geçerli kimlik bilgilerini kullandığı için AWS'nin geçerli kullanımı kötü amaçlı kullanımdan güvenilir bir şekilde ayırt etmesi zordur. Bu nedenle, müşterilerin riskleri azaltmak için en iyi uygulamaları takip etmeleri gerekiyor.
Yetkisiz SSE-C kullanımına karşı korunmak için müşterilerin şu dört güvenlik uygulamasını uygulamaları gerekiyor:
Yukarıdaki teknik SSE-C şifrelemesini kullanıyor olsa da, bu ve birçok güvenlik olayının temel nedeni kimlik bilgilerinin ele geçirilmesidir. Ele geçirilen kimlik bilgileri riskini azaltmanın en etkili yolu, uzun vadeli kimlik bilgilerini hiç oluşturmamaktır. Var olmayan kimlik bilgileri ifşa edilemez veya çalınamaz. Bununla birlikte AWS, kimlik bilgilerini kaynak kodunda veya yapılandırma dosyalarında saklama gereksinimini ortadan kaldıran bir yetenek seti sunar.
IAM rolleri, Amazon Elastic Compute Cloud (Amazon EC2) örneklerinden, Amazon Elastic Container Service (Amazon ECS) veya Amazon Elastic Kubernetes Service (Amazon EKS) kapsayıcılarından ya da Lambda işlevlerinden kısa vadeli kimlik bilgileri kullanarak imzalı API isteklerini güvenli bir şekilde yapmalarına olanak tanır. Ayrıca, AWS Bulutu dışındaki sistemler bile IAM Roles Anywhere özelliğini kullanarak uzun vadeli AWS kimlik bilgileri olmadan kimlik doğrulamalı çağrılar yapabilir. Bunun yanı sıra, AWS IAM Identity Center, geliştirici iş istasyonlarının, Multi-Factor Authentication (MFA) ile korunan daha uzun vadeli kullanıcı kimliklerine dayanan kısa vadeli kimlik bilgileri edinmesini sağlar.
Tüm bu teknolojiler, AWS Security Token Service (AWS STS) üzerine inşa edilmiştir ve kodda veya yapılandırma dosyalarında uzun vadeli AWS güvenlik kimlik bilgileri dağıtılmadan veya gömülmeden AWS kaynaklarına erişimi kontrol edebilen geçici güvenlik kimlik bilgileri sağlar.
Veri koruma mekanizmaları olmadan, veri kurtarma süreleri daha uzun olabilir. Veri koruma uygulaması olarak, verilerin üzerine yazılmasını önlemenizi ve kritik verilerin ikinci bir kopyasını saklamanızı öneririz.
S3 Versiyonlama özelliğini etkinleştirerek bir kovadaki bir nesnenin birden fazla versiyonunu saklayabilir ve kazara silinen veya üzerine yazılan nesneleri geri yükleyebilirsiniz. Ancak, versiyonlama özelliğinin, özellikle bir kovadaki nesnelerin sık sık üzerine yazıldığı uygulamalarda depolama maliyetlerini artırabileceğini unutmayın. Bu durumda, eski versiyonları yönetmek ve depolama maliyetlerini kontrol altında tutmak için S3 Yaşam Döngüsü politikalarını uygulamayı düşünebilirsiniz.
Buna ek olarak, kritik verilerin bir yedeğini farklı bir depolama alanına ve mümkünse farklı bir AWS hesabına veya AWS Bölgesine yedek alın. Bunu yapmak için S3 replikasyonunu kullanarak nesneleri depolama alanları arasında otomatik olarak kopyalayabilirsiniz. Bu depolama alanları aynı AWS hesabında veya farklı AWS hesaplarında ve aynı veya farklı AWS Bölgelerinde bulunabilir. S3 replikasyonu ayrıca, RPO (Recovery Point Objective) ve RTO (Recovery Time Objective) gereksinimleri olan müşteriler için bir SLA sunar. Alternatif olarak, S3 depolama alanlarının periyodik yedeklemesini otomatikleştiren yönetilen bir hizmet olan AWS Backup for S3'ü kullanabilirsiniz.
İzleme yapılmadığında, S3 depolama alanları üzerindeki yetkisiz işlemler fark edilmeyebilir. Verilerinize erişimi izlemek için AWS CloudTrail veya S3 sunucu erişim logları gibi araçları kullanabilirsiniz.
AWS CloudTrail'i, AWS hizmetlerinde (Amazon S3 dahil) gerçekleşen olayları loglamak için kullanabilirsiniz. Ayrıca, logları tek bir hesapta birleştirerek güvenlik ekiplerinizin erişim sağlaması ve izleme yapması için kullanılabilir hale getirebilirsiniz. Bunun yanı sıra, belirli S3 metrikleri veya loglarına dayalı CloudWatch alarmları oluşturabilirsiniz. Bu alarmlar, olağandışı etkinlikler hakkında hızlıca bilgi edinmenize yardımcı olur.
Ayrıca, Amazon EventBridge ve AWS Lambda'yı kullanarak otomatik düzeltici önlemler alacak bir otomasyon da kurabilirsiniz.
Eğer uygulamalarınız şifreleme yöntemi olarak SSE-C kullanmıyorsa, bir S3 depolama alanına uygulanan kaynak politikasıyla veya AWS Organizations'daki bir organizasyona uygulanan bir kaynak kontrol politikası (RCP) ile SSE-C kullanımını engelleyebilirsiniz.
S3 depolama alanına yönelik kaynak politikaları genellikle "bucket policies" olarak adlandırılır ve müşterilerin S3'teki bireysel epolama alanları için izinleri belirtmesine olanak tanır. Bir bucket politikası, S3 PutBucketPolicy API işlemi, AWS Komut Satırı Arayüzü (CLI) veya AWS Yönetim Konsolu kullanılarak uygulanabilir. Bucket politikalarının nasıl çalıştığı hakkında daha fazla bilgi için S3 belgelerine bakabilirsiniz. Aşağıdaki örnek, <your-bucket-name> adlı bir bucket için SSE-C isteklerini engelleyen bir bucket politikasını göstermektedir:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictSSECObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<your-bucket-name>/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
]
}
RCP'ler (Kaynak Kontrol Politikaları), müşterilerin AWS Organizations'daki bir organizasyon genelinde kaynaklara uygulanacak maksimum izinleri belirlemelerine olanak tanır. Bir RCP, AWS Organizations UpdatePolicy API işlemi, AWS Komut Satırı Arayüzü (CLI) veya AWS Yönetim Konsolu kullanılarak uygulanabilir. RCP'lerin nasıl çalıştığı hakkında daha fazla bilgi için AWS Organizations belgelerine göz atabilirsiniz. Aşağıdaki örnek, organizasyondaki depolama alanları için SSE-C isteklerini engelleyen bir RCP'yi göstermektedir.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictSSECObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
]
}
AWS, şifreleme olaylarının genellikle uzun vadeli kimlik bilgilerinin kötü niyetli kişiler tarafından ele geçirilmesinden kaynaklandığını belirtiyor. Bu durumun önlenmesi için kısa vadeli kimlik bilgileri (IAM Rolleri, STS (Security Token Service, IAM Identity Center) yetki kısıtlamaları ve otomatik izleme sistemleri gibi çeşitli yöntemlerle çalışmak, güvenlik risklerini önemli ölçüde azaltır. Ayrıca, özellikle SSE-C (müşteri tarafından sağlanan anahtarlarla sunucu tarafı şifreleme) kullanımını kısıtlamak veya engellemek için uygulanabilir politikalar ve teknik çözümler ayrıntılı bir şekilde yukarıda açıklanmış.
Yazının içeriğinde geçen istem dışı şifreleme olaylarına karşı alınacak dört temel güvenlik uygulamasına bizde katkı sağlayalım :
Sonuç olarak, AWS'nin sunduğu teknolojiler ve politikalar müşterilere güçlü bir güvenlik altyapısı sunarken, ek önlemlerle bu yapı daha da sağlamlaştırılabilir. Müşterilerin, güvenlik uygulamalarını düzenli olarak güncelleyerek ve uygulayarak olası tehditlere karşı hazırlıklı olmaları büyük önem taşır.
Kaynak:
Veriler, ilk defa bu ay sosyal medyada ve hacker formlarında yer alan yeni bir hacker grubu olan "Belsen Group" tarafından sızdırıldı. Grup, kendilerini tanıtmak için bir Tor Web sitesi oluşturdu. Oluşturulan site üzerinden FortiGate cihazlarına ait verileri diğer tehdit aktörleri tarafından kullanılmak üzere ücretsiz olarak yayınladı.
Grup, siber suç forumlarının birinde FortiGate cihazlarına ait verileri kendilerini tanımak amacıyla ücretsiz yayınladıklarını belirten bir post paylaştı.
"Bu yılın başında bizim için olumlu bir başlangıç olarak ve grubumuzun adını
hafızanızda sağlamlaştırmak adına ilk resmi operasyonumuzu duyurmaktan
gurur duyuyoruz:
15.000'den fazla hedefe ait hassas veriler yayınlanacak dünya çapında (hem devlet
hem de özel sektör) saldırıya uğrayan ve verileri çıkarılan kişiler"
Sızdırılan FortiGate verileri, ülkeye göre sınıflandırılmış klasörleri içeren 1,6 GB'lık büyük bir arşivden oluşuyor. Zira, arşivin içinde bulunan dosyaların genelinin text dosyası olaması 1,6 GB'lık bir büyüklüğün aslında ne kadar fazla veri barındırdığın ürkütücü bir delilidir. Ülkelere ait bu klasörlerin içinde ise, o ülkeye ait FortiGate cihazlarının IP adreslerine göre alt klasörler bulunuyor. Belsen Group, tehdit aktörleri için oldukça kolaylaştırcı bir çalışma yapmış gözüküyor.
Siber güvenlik uzmanı Kevin Beaumont'a göre, her IP adresine ilişkin klasörde “configuration.conf” (Fortigate yapılandırma dökümanı) ve “vpn-passwords.txt” dosyası bulunuyor. Bazı şifrelerin ise düz metin halinde olduğunu, yapılandırmalar için ayrıca özel anahtarlar (private keys) ve güvenlik duvarı (firewall) kuralları gibi hassas bilgileri de içeriyor.
Beaumont, "Kurban kuruluşundaki bir cihazda olay müdahalesi yaptım ve istismar gerçekten de cihazdaki yapılara dayalı olarak CVE-2022-40684 aracılığıyla gerçekleştirilmiş. Ayrıca dökümde görülen kullanıcı adlarının ve şifrenin eşleştiğini de doğrulayabildim. Verilerin Ekim 2022'de 0day güvenlik açığı olarak toplandığı görülüyor. Bazı nedenlerden dolayı, config'in veri dökümü 2 yıldan biraz daha uzun bir süre sonra bugün yayınlandı." diye açıklıyor.
2022'de Fortinet, tehdit aktörlerinin hedeflenen FortiGate cihazlarından yapılandırma dosyalarını indirmek ve ardından "fortigate-tech-support" adı verilen kötü amaçlı bir super_admin hesabı eklemek için CVE-2022-40684 olarak izlenen zero-day açığının kullandığı konusunda uyardı.
Beaumont, FortiGate yöneticilerinin sızıntının kendilerini etkileyip etkilemediğini bilmesi için sızıntıdaki IP adreslerinin bir listesini yayınlamayı planladığını belirtti.
Alman haber sitesi Heise, veri sızıntısını analiz etti. Analize göre sızıntıdaki bahsi geçen verilerin 2022'de toplandığını ve tüm cihazların FortiOS donanım yazılımı 7.0.0-7.0.6 veya 7.2.0-7.2.2'yi kullandığını söyledi.
“Tüm cihazlar FortiOS 7.0.0-7.0.6 veya 7.2.0-7.2.2 ile donatılmıştı, çoğu da 7.2.0 sürümüne sahipti. Bilgisi sızdırılan cihazların arsında 3 Ekim 2022 tarihinde yayınlanan 7.2.2 sürümünden daha yeni bir FortiOS sürümüne sahip cihaz bulamadık."
DrDisk Lab siber güvenlik uzmanları paylışan verilerin sahte mi yoksa gerçek bir sızıntı mı olduğu hakkkında yapılan analizler sonucunda verinin doğruluğunu belirlemiştir.
Sızıntıdaki verilerin ücretsiz bir şekilde yayınlanmış olmasıyla birlikte, verilere artık erşimin çok daha kolay olduğunu görebiliyoruz. Her ne kadar bu verilerin 2022 0day açığıyla toplanmış olması ve bahsi geçen zaafiyetin Fortinet tarafından yayınlanan yeni FortiOS sürümü ile giderilmesi siber güvenlik noktasında sorunların çözüldüğü anlamına gelmiyor. Zira kullanıcılar söz konusu güncellemenin yapılıp yapılmadığını takip etmemiş ve sistemlerini henüz güncelleme yapmamışlar ise, yazının konu aldığı muhtemel kurbanlardan birisi olmalarının an meselesi olduğunu söylemek, pek de abartılı bir ifade olmaz.
Yukarıda paylaştığımız ve DrDisk Lab Siber güvenlik uzmanlarının çalışmaları neticesinde elde edilen bilgiler, veri sızıntısında yer alan IP adreslerinde bulunan cihazlarda 2 yıl önce yapılan güncelleme ile bertaraf edilen zafiyetin bu güncellemeyi henüz almamış cihazlarda devam ettiğini gözler önüne sermektedir. Firewall cihazlarınız, sadece elektrik faturasına katkı sağlasın istemiyorsanız, onları güncel tutmak zorunda olduğunuz gerçeğini atlamamalısınız. 2 sene önceki VPN erişim bilgilerini ve Firewall kurallarını kullanmaya devam eden sistemlerin, sızdırılan bu verileri kullanacak olası tehdit aktörlerinin saldırılarına karşı savunmasız olduğunu belirtmek isteriz. Bu durum söz konusu cihazlardan sorumlu olan IT yöneticileri için önem arz etmektedir.
Kaynakça:
BleepingComputer. (2025). Hackers leak configs and VPN credentials for 15,000 FortiGate devices. -Lawrence Abrams Erişim adresi:
Fortinet. (2022). CVE-2022–40684 Güvenlik Duyurusu.
Heise. (2025). FortiGate Veri Sızıntısı Analizi.
2022 zero day was used to raid Fortigate firewall configs. Somebody just released them. - Kevin Beaumont Erişim Adresi:
HDD hata yönetimi, sabit disklerin uzun süre güvenilir bir şekilde çalışmasını sağlamak için kullanılan yöntemler bütünüdür. Bu yöntemler, disk üzerindeki hataları tespit edip düzeltmeyi veya yönetmeyi hedefler. HDD hata yönetimi kapsamında sıkça karşılaşılan iki önemli liste, P-List (Primary Defect List) ve G-List (Growth Defect List), diskteki hatalı sektörlerin yönetilmesinde kritik rol oynar
HDD Hata Yönetimi Teknikleri
P-List (Primary Defect List)
G-List (Growth Defect List)
P-List ve G-List Karşılaştırması
P-List, G-List ve Yedek Sektörlerin Önemi
Öneriler
P-List ve G-List yönetimi, HDD’nin güvenilirliğini ve kullanım ömrünü artırır. Kullanıcıların SMART raporlarını, yedek sektörlerin kullanımını ve G-List büyüklüğünü belli periyotlarla takip etmeleri veri bütünlüğü ve güvenliği açısından önemlidir. G-List büyümeye devam ederse veya yedek sektörler tükenmeye yaklaşırsa, diski değiştirmek veya kapsamlı bir yedekleme stratejisi uygulamak gerekecektir.