Eski bir Roblox hack olayını hatırlatıyor: üretim dışı bir staging sitesinde kullanıcılar kayıt olabiliyordu ve üzerinde "Buradaki hiçbir şey kalıcı değildir" yazan bir banner vardı. Üretim hesabına yeni bir yönetici hesabı eklendiğinde, birisi staging sitesinde aynı kullanıcı adıyla kayıt olup çerezler ve token'ları kullanarak üretim hesabını ele geçirmiş ve siteyi riske atmıştı. Bu tür sorunların nadir olmadığını hayal etmek zor değil: kullanıcı adı veya kullanıcı kimliğine dayalı kriptografik token'lar üretilirken üretim/staging için farklı sırlar yoksa, staging sitesi üretim yetkilerini karıştıran harici servislerle iletişim kuruyorsa vb.
Büyük şirketlerde geliştirme/üretim sınırları, insanların düşündüğünden çok daha geçirgendir. Sıradan bir günü düşünün: PC'ye giriş yaparsınız, e-postayı kontrol edersiniz, ardından aynı kimlik bilgileriyle Azure portalına giriş yaparsınız (hepsi aynı tenant tarafından desteklenir). Hesap GitHub ve bulut hesaplarına bağlıdır.
Teams ya da OneDrive'da çalışabilmek için, anlaşılması zor izinlere sahip grup ve ekipler her yere oluşturulur ve bunlar şirket dizininde neredeyse ayırt edilemeyen güvenlik grupları olarak kalır.
Bazen hâlâ ihtiyaç duyduğunuz şeyi kullanıp kullanmadığınızı soran otomatik e-postalar alırsınız, ama mesajlar muğlaktır ve gerçekten büyük bir şirkette soracak kimse yoktur (yardım masası yanıt vermek için iki gün sürer ve Twitter'da John Savill'e de ulaşamazsınız, bu yüzden sadece onaylayıp devam edersiniz).
Sonunda yapı yıpranır ve saldırgan zayıf bir noktada şanslı olup tenant'lar arasında istediğini elde edebilir.
Zeki bir CISO'nun bir keresinde dediği gibi, hacker'lar içeri sızmaz, giriş yapar.
Siber güvenlik sektöründe buna yaygın olarak "whoopsie" deniyor.
Araştırmacı ve güvenlik uzmanı Kevin Beaumont, Mastodon'da OAuth uygulamasına 'full_access_as_app' rolü atanabilen bir hesabın yönetici ayrıcalıklarına sahip olması gerektiğine dikkat çekti. "Birileri"nin üretim ortamında oldukça büyük bir yapılandırma hatası yaptığını söyledi.
Sistemin ayrıntılarını bilmiyorum, ama sorunun bu olmayacağını düşünürdüm ve bir uzmanın bunun sorun olduğunu söylemesine şaşırdım. Böyle bir hatayı yapmanın mümkün olmaması gerekirdi. Tasarımcılar ve yöneticiler bunu imkânsız hale getirmeli ve bunun sorumluluğunu taşımalı.
Gösterişli güvenlik sertifikalarına rağmen, Amazon'da 36 dolarlık bir kitaptaki iyi düşünülmüş en iyi uygulamaların tamamen göz ardı edildiği görülüyor.
Bu gönderide eksik olan şey şu: yazarlar "üretim"i nasıl tanımlıyor ve "üretim dışı" bir hesabın üretim domaini üzerinde nasıl yönetim yetkisine sahip olabildiği.
Bu kalıp, MS ekosistemi genelinde istisna değil kural, ancak Microsoft'un kendisinin bunu yapıyor olması özellikle utanç verici.
Bir şirkette tüm üretim sunucularının ve veritabanlarının parolaları, baş mimar parolaları hatırlamak istemediği için kod deposundaki bir metin dosyasında saklanıyordu. Bunun ne kadar aptalca olduğunu CTO'ya söylediğimde, "Çalışanlarımıza güveniyoruz" ve "Güvenlik denetiminden geçtik" yanıtlarını aldım.
Yeni bir iş yerine gittiğimde, birisinin "daha kolay olduğu için" çok fazla yetki vermesinden hoşlanmıyorum. Bunu yapmamak gerekir. Bu sadece şirketi riske atmakla kalmaz, aynı zamanda istemediğiniz bir sorumluluğu da üzerinize yükler. Yanlışlıkla önemli bir şeyi bozabilirsiniz ve hacklenirseniz, yetkiniz olduğu için bunu benim yaptığımdan şüphelenilebilir.
Bunun neden bir "hata" sayıldığını merak ediyorum. Bu, Microsoft'ta yönetici olarak çalışan bir casusun eylemi de olabilir.
1 yorum
Hacker News görüşleri