1Password, dahili Okta hesabında “şüpheli etkinlik” tespit etti

• 1Password, çalışan uygulamalarına erişimi yöneten dahili Okta instance'ında 29 Eylül'de şüpheli etkinlik tespit etti; kullanıcı verilerinin veya hassas sistemlerin ihlal edildiğine dair bir bulguya rastlamadı
• Bu erişim, Okta'nın müşteri destek yönetim sisteminin ihlaliyle bağlantılıydı; saldırgan, müşterilerin yüklediği HAR dosyalarından kimlik doğrulama çerezleri ve oturum token'ları elde edebilmişti
• 1Password'ün dahili Notion raporunda, saldırganın bir IT çalışanının Okta destek ekibiyle çalışırken oluşturduğu HAR dosyasını ele geçirdiği ve dosyanın Okta trafiği ile oturum çerezlerini içerdiği belirtiliyor
• Saldırgan, 1Password'ün Okta tenant'ında yönetici kullanıcı raporu talep etti ve Google üretim ortamı kimlik doğrulaması için kullanılan IDP'yi güncelleyip etkinleştirdi; ancak daha sonraki yeniden kullanım girişimi IDP kaldırıldığı için başarısız oldu
• Okta ihlali, bir tedarikçi sızmasının müşteri şirketlere yönelik saldırılara dönüştüğü bir ikincil saldırı örneği oldu; 1Password, hedef alındığı bilinen ikinci Okta müşterisi haline geldi

---

1Password dahili Okta erişimini tespit etti

• 1Password, milyonlarca kullanıcının ve 100 binden fazla şirketin kullandığı bir parola yöneticisidir
• Şirket, çalışan uygulamalarını yönetmek için kullandığı Okta instance'ında 29 Eylül'de şüpheli etkinlik tespit etti
• CTO Pedro Canahuati, söz konusu etkinliği hemen sonlandırıp araştırdıklarını; kullanıcı verilerinin ya da çalışanlara ve kullanıcılara yönelik hassas sistemlerin ihlal edildiğine dair bir bulgu bulamadıklarını açıkladı
• Ardından 1Password, bilinmeyen bir saldırganın hesaba nasıl eriştiğini Okta ile birlikte araştırdı

Okta destek sistemi ihlali ve HAR dosyası riski

• 1Password olayı, Okta'nın açıkladığı müşteri destek yönetim sistemi ihlalinden kaynaklandığı doğrulandı
• Okta, bir tehdit aktörünün müşteri destek vaka yönetim sistemine yetkisiz erişim sağladığını ve bazı Okta müşterilerinin yüklediği dosyaları gördüğünü açıkladı
• Ele geçirilen dosyalar arasında, Okta destek personelinin sorun giderme sırasında müşterinin tarayıcı etkinliğini yeniden oluşturmak için kullandığı HAR dosyaları da vardı
• HAR dosyaları, kimlik doğrulama çerezleri ve oturum token'ları gibi hassas bilgileri saklayabildiğinden, saldırganların meşru kullanıcı gibi davranması için kötüye kullanılabilir

BeyondTrust'ın ardından bilinen ikinci hedef

• Güvenlik şirketi BeyondTrust, saldırganın geçerli bir kimlik doğrulama çereziyle kendi Okta hesabına erişmeye çalışmasının ardından sızmayı tespit etti
• BeyondTrust'ta saldırgan “birkaç sınırlı işlem” gerçekleştirebildi; ancak erişim politikası kontrolleri etkinliği durdurdu ve hesap erişimini engelledi
• 1Password, Okta ihlalinden sonra ikincil saldırı hedefi olduğu bilinen ikinci Okta müşterisi oldu

Dahili Notion raporundaki olay akışı

• 18 Ekim tarihli olup 1Password'ün dahili Notion çalışma alanında paylaşılan raporda, saldırganın şirketin IT çalışanı tarafından oluşturulan HAR dosyasını ele geçirdiği belirtiliyor
  • Söz konusu çalışan bu dosyayı kısa süre önce Okta destek ekibiyle çalışırken oluşturmuştu
  • Dosyada, 1Password çalışanının tarayıcısı ile Okta sunucuları arasındaki tüm trafik kayıtları ve oturum çerezleri yer alıyordu
• 1Password, anonim bir çalışanın metin ve ekran görüntüleriyle sağladığı belgenin doğruluğunu teyit etme talebine yanıt vermedi
• Rapora göre saldırgan, 1Password'ün Okta tenant'ına da erişti
  • Okta tenant'ı, çalışanlara, iş ortaklarına ve müşterilere atanan sistem erişim haklarını ve yetki seviyelerini yönetmek için kullanılır
  • Saldırgan grup atamalarını görüntüledi ve başka işlemler de yaptı; ancak bazı işlemler olay günlüklerine kaydedilmedi
  • Giriş sırasında Google'ın sağladığı üretim ortamı kimlik doğrulaması için kullanılan IDP'yi (identity provider) güncelledi

Saldırganın gerçekleştirdiği işlemler ve engellenen yeniden deneme

• 1Password IT ekibi, 29 Eylül'de yönetici yetkilerine sahip 1Password kullanıcılarının listesinin istendiğini ima eden beklenmedik bir e-posta alınca erişimden haberdar oldu
• Ekip üyeleri, onaylı bir çalışanın bu talebi yapmadığına karar vererek şirketin güvenlik müdahale ekibini bilgilendirdi
• Saldırganın gerçekleştirdiği işlemler şunlardı
  • IT çalışanının Okta panosuna erişmeye çalıştı ancak engellendi
  • 1Password'ün üretim Google ortamına bağlı mevcut IDP'yi güncelledi
  • Söz konusu IDP'yi etkinleştirdi
  • Yönetici kullanıcı raporu talep etti
• 2 Ekim'de saldırgan tekrar 1Password'ün Okta tenant'ına giriş yaparak daha önce etkinleştirdiği Google IDP'yi kullanmayı denedi; ancak IDP kaldırıldığı için başarısız oldu
• Her iki erişim de ABD'deki bulut barındırma sağlayıcısı LeaseWeb sunucusundan gerçekleşti ve Windows makinede Chrome sürümü kullanıldı
• Olaydan sonra 1Password, Okta tenant ayarlarını değiştirerek Okta dışı kimlik sağlayıcıları üzerinden girişleri reddedecek hale getirdi

Tedarikçi ihlalinin müşteri şirket saldırısına dönüşen yapısı

• Okta ihlali, son yıllarda büyük müşteri tabanına sahip yazılım ve hizmet sağlayıcılarını hedef alan bir dizi saldırıdan biridir
• Saldırganlar, sağlayıcıya sızdıktan sonra bu konumu kullanarak müşteri şirketleri hedef alan ikincil saldırılar gerçekleştirir
• İleride daha fazla Okta müşterisinin tespit edilmesi olasıdır

[GN⁺]

Hacker News yorumları

• SSO’yu dışarıya devretmek, yalnızca teknik olarak daha kolay olup olmadığı ya da operasyonel yetkinliğe sahip olup olmama meselesi değil. Müşteri sözleşmelerine itibarlı bir SSO sağlayıcısı kullandığınızı yazabilmeniz ve anahtar yönetimi yöntemi ile anahtar materyalinin korunmasına ilişkin dokümantasyon sorumluluğunu da o sağlayıcının üstlenmesi büyük bir etken.
  1Password’ün zaten böyle bir düzeneğe sahip olma olasılığı yüksek, bu yüzden bu durum biraz sıra dışı; ama genelde “kuruluş içinde hiç kimse anahtarlara erişemez” demek, “Bob tek istisna; SSO sunucusunu o işletiyor ve biz ona güveniyoruz” demekten çok daha kolaydır

  • “Bob’a güveniyoruz” demekten Okta’yı daha iyi yapan ne? Hiç tanımadığınız insanlara güvenmiş oluyorsunuz ve zaten birçok büyük güvenlik olayına karıştılar
  • Mesajlaşma tarafına katılıyorum, ama gerçek güvenlik açısından bakınca hizmet sağlayıcı tarafındaki Bob için ne diyeceğiz?

• C’deki bellek güvenliği açıklarının en çok konuşulan konu olması ilginç; ancak gerçek etkisi büyük olan şey çoğu zaman sözde en iyi tasarımları izlerken aşırı karmaşıklıktan doğan içgörü çöküşü oluyor

  • Güvensiz C’yi eleştirirken yeniden Bizansvari bir canavar yaratan kişiler çoğu kez aynı tarafta yer alıyor. Basit bir düzeneği bir Rube Goldberg makinesine çevirerek istihdamı korumaya yarayan normalleşmiş teşvikler işliyor gibi görünüyor
  • Organizasyonel hatalar o kurumu büyük ölçüde etkileyebilir; ancak bellek güvenliği hataları genellikle otomatik yöntemlerle istismar edilebilir ve o yazılımı kullanan tüm kuruluşları etkiler. Heartbleed’in bu kadar çok tartışılmasının nedeni de etkisinin büyük olmasıydı
  • Sonuçta mesele karmaşıklık. Bir şeyler gözden kaçıyor; bir şeyi güncellediğinizde bunun diğer mantık katmanlarında doğuracağı zincirleme etkileri kaçırıyorsunuz. Karmaşıklık güvenlik açığı doğurur, ancak katmanlı güvenlik savunmaları ve karşı önlemler riski azaltabilir.
    Temel nedenin, insanların devasa karmaşıklığı kavrayamamasındaki sınır olduğunu düşünüyorum
  • Ölçülebilen şey optimize edilir. Yazılım açıkları hakkında sayısal ve kolayca toplanabilen veriler var; ancak verilerin kuruluşlardan nasıl çalındığına, hatta bazen ne zaman çalındığına dair bilgi eksik.
    İkincisi insanlarla ilgili olduğu için karmaşık olma olasılığı yüksek; bu yüzden kurtuluşu teknolojide aramak daha kolay
  • “İçgörü çöküşü”nün ne olduğunu merak ediyorum. Kulağa çok ilginç bir kavram gibi geliyor

• “BT ekip üyesinin tüm sistem kimlik bilgilerini değiştirdik ve MFA’yı yalnızca Yubikey kullanılacak şekilde değiştirdik” kısmına bakınca, bunun tüm çalışanlara Yubikey tabanlı iki aşamalı kimlik doğrulama kullandırmak için bir vesile olmasını umuyorum. FIDO2’nin altı gerçekten zayıf
  İnsanların hâlâ neden Okta’yı seçtiğini merak ediyorum. Kişisel olarak kimlik sağlayıcı olarak GSuite kullanmak bana çok daha rahat geliyor. Okta epey ciddi bir ihlal yaşadı; açıkçası ondan önce de güvenlik uygulamaları hakkında iyi şeyler duymamıştım

  • Yubikey ya da başka tarayıcı tabanlı MFA bu saldırıyı engelleyemezdi. Çünkü saldırgan, MFA tamamlandıktan sonraki geçerli yönetici oturum token’ını elde etmişti
    Donanım tabanlı MFA’yı zorunlu kılmak iyi bir uygulama ve gelecekte spear phishing gibi saldırıları engelleyebilir, ama bu olayın kendisiyle ilgisi yok
    İnsanların Okta’yı seçmesi daha çok “IBM satın aldığı için kimse kovulmaz” sözüne yakın. Kendi Keycloak sistemini işletirken ihlal yaşanırsa sorumluluk bende olur; Okta olursa sorun benim sorunum olmaktan çıkar — bu dış kaynak kullanımı yapısı da etkili
  • Çalınan şey oturum çereziydi; iki aşamalı kimlik doğrulamanın bu sorunla ilgisi yok
    Google Workspace’i ciddi bir kullanım için gerçekten kullanıp kullanmadığını merak ediyorum. En az özelliğe sahip kimlik sağlayıcılardan biri; Okta ise en çok özelliği olanlar arasında. İkisinin de iki tekerleği var diye bisikletle motosikleti karşılaştırmak gibi
    Bir teknoloji forumunda Google Workspace’in kimlik sağlayıcı olarak önerildiğini göreceğimi hiç düşünmezdim
  • Çoğu insan Okta’yı seçmez. Yönetici seviyesinde biri Okta’yı seçer, geri kalanlar da sonuçlarına katlanır
    Yubikey kullanırsanız tüm parola sorunlarının müşteri desteğini dış kaynak şirketi değil, kurum içi BT departmanı üstlenir
    MFA’da teknik sorunlar ve sosyal sorunlar var; anahtar, token, telefon, SMS gibi uygulamaların teknik güvenlik boyutu neredeyse önemsiz kalıyor. Müşteri desteği, kayıp parolalar, çamaşır makinesine giren anahtarlar, e-posta alamama gibi sosyal sorunlar ezici biçimde daha büyük
    Herkes güvenlikteki devasa ve aptal müşteri desteği rolünü dış kaynak kullanımıyla devretmek istiyor; ama bunu yaptıktan sonra herkes maliyetleri düşürmeye teşvik ediliyor. Sonuç da Okta oluyor
  • GSuite’i kimlik sağlayıcı olarak kullanmak çok sınırlı. “Kimlik sağlayıcıyım” kutucuğunu işaretliyor, ama “bağlanabilir” olmanın ötesine geçtiğiniz anda işler zorlaşıyor ya da imkânsızlaşıyor
    Örneğin tüm çalışanları GSuite’te olan bir organizasyonda AWS organizasyon erişimi sağlamak için önerilen yöntem AWS SSO[1]. Bağlantıyı kurunca giriş yapılabiliyor, ama açıklar var
    GSuite kullanıcı gruplarına göre AWS SSO’da kullanıcıları otomatik provision etme ya da kaldırma özelliği yok. SSO’nun SCIM desteğiyle kendi kodunuzu yazabilirsiniz, ama bakımını yapmanız gerekir
    SSO oturumu oluştururken MFA kontrolünü zorunlu kılmanın ne GSuite tarafında ne de AWS SSO tarafında bir yolu var. GSuite, SAML uygulaması kimlik doğrulamasından önce MFA kontrolü isteyemiyor; AWS SSO da kendi dahili Directory’sini kullanırken olduğunun aksine, kimlik sağlayıcı kullanıldığında MFA kontrolünü zorunlu kılamıyor
    Okta ve benzeri ürünler bu işleri yapıyor; kullanılan endpoint’e göre MFA kontrolü de koyabildikleri söyleniyor. Bunu kendim denemedim, pazarlama materyalleri ve satış anlatımlarına dayanıyorum
    Özetle Okta, kimlik sağlayıcı ile kullanılan uygulama arasında çok daha fazla otomasyon ve güvenlik yapıştırıcısı sağlıyor
    [1] Burada AWS SSO, AWS ürünü olan “AWS IAM Identity Center (Successor to AWS Single Sign-On)” anlamına geliyor
  • Okta’nın diğer çözümlerden daha iyi ya da daha kötü olduğuna dair kanıt var mı? Güvenliği ölçmek çok zor
    Şu anda görünen kanıtlar, Okta’nın geçen yıl bir ihlal yaşadığı, bu kez de ihlal yaşadığı ve bu ihlalin müşteri destek departmanında ya da sistemlerinde gerçekleştiği kadar. İhlal açıklaması gecikmiş olabilir; ama çok sayıda asılsız bildirim olduğu için yakın zamana kadar kanıt bulamamış da olabilirler. İlk bildiren müşteriye hakkını teslim etmemiş, bildirimden sonra müşteriyle düzgün iletişim kurmamış da olabilirler
    Bilmediğimiz şeyler çok daha fazla. Saldırganın ne kadar yetenekli olduğunu, her kimlik sağlayıcının kaç kez ihlal edildiğini, kaçını tespit ettiğini, tespit edip üstünü kapatıp kapatmadığını, her hizmette ne kadar çok ve ne kadar ciddi güvenlik hatası olduğunu ve bunların bulunmasının ne kadar kolay olduğunu, ihlal tespit kabiliyetlerinin nasıl olduğunu, çalışan eğitimlerinin ne kadar iyi olduğunu, çalışanların ne kadarının gerçekten güvenliği önemsediğini bilmiyoruz
    Sırf Okta ihlali bildirdi diye ürünün daha kötü olduğu sonucuna varılamaz. Diğer ürünlerin ne kadar iyi olduğunu bilmiyoruz; Okta’nın bazı ya da tüm rakiplerinden daha iyi olma ihtimali de var, elbette daha kötü de olabilir

• Eskiden 1Password’ü liste fiyatından satın alırdık; yazılım tamamen çevrimdışı çalışır ve şifrelenmiş kasayı yerelde ya da Dropbox’ta saklardı. İnternette çalınacak bir şey olmadığı için hacker’lar konusunda endişelenmeye de gerek yoktu
  Sonra biri hesap makinesini eline aldı ve kârlılığı artırmanın yolunun herkesin verisini buluta taşımak ve abonelik ücreti almak olduğuna karar verdi. Şimdi de verilerin sızıp sızmadığını dert ediyoruz

  • Doğrudan yönetebilecek kadar yetkin olmayan insanlar için kullanım kolaylığının ciddi biçimde arttığı da doğru
    Ayrıca şu an bildiğimiz kadarıyla kasayı Dropbox’ta tutmaktan ne kadar farklı? Dropbox da hacklenebilir ve oradaki verilerin şifrelenmediği herkesçe bilinir. Henüz gerçekten bir 1Password kasasının ihlal edildiği bir örnek bilmiyoruz, değil mi?

• https://blog.1password.com/okta-incident/
  Orijinal olay raporu: https://blog.1password.com/files/okta-incident/okta-incident...

  • İlginç kısım şu. Bir BT ekip üyesi Okta destek ekibiyle çalışırken, talep üzerine Chrome geliştirici araçlarında bir HAR dosyası oluşturup Okta destek portalına yüklemiş; bu dosyada tarayıcı ile Okta sunucusu arasındaki tüm trafik kayıtları ve oturum çerezleri gibi hassas bilgiler yer alıyormuş
    Daha sonra kimliği bilinmeyen bir aktör, o HAR dosyasının oluşturulmasında kullanılan aynı Okta oturumuyla Okta yönetici portalına erişmiş
    Bankaların hep söylediği gibi, destek görevlisine parolanızı vermemelisiniz

• Bu sefer sorumluluk açıkça Okta’da. Sorunu gidermek için düz metin HAR ile kodlanmış oturumlar istiyorlar ve son kullanıcıların bunları düzgünce temizlemesini bekliyorlar.
  Yükleme sırasında HAR verilerini temizleyip sisteme giren, düşük ücretli ve yetersiz sayıdaki destek teknisyenlerinin gördüğünde yalnızca ilgili ve güvenli kısımlar kalacak şekilde yapmak mümkün değil mi?
  HAR yapılandırılmış veri olduğu için programla temizlenmesi çok kolay. Roket bilimi değil.

• İnsanlar neden aşırı basit ve çok kullanıcı dostu çevrimiçi servisler yerine kendi barındırdığı, kendi eşitlediği parola yöneticilerini kullandığını sormaya devam ediyor; sebep aynı. Apartman anahtarlarını mahallenin tren istasyonundaki kasaya atmamaya benziyor.

  • Bunu yapınca daha güvende hissedebilirsiniz ama gerçekte öyle olmayabilir. Hedefli bir saldırgan Okta’yı aşabiliyorsa, zamanında güncellemeyi unuttuğunuz ya da güncellemeleri gecikmeli gelen kendi barındırdığınız parola yöneticinizi de pekâlâ aşabilir.
    Bu tür kuruluşlar çoğu zaman açıklama yapmadan haftalar, bazen aylar önce sorunu düzeltir.
    Açık kaynak kullanırken kritik bir hata bulunursa yamayı basın duyurusuyla birlikte alırsınız; büyük servisler ise o sorunu büyük ihtimalle çoktan düzeltmiş olur. Ortalama bir kullanıcı için risk-getiri dengesi hizmet olarak sunulan çözüm tarafında.
  • Bunun konuyla ilgisi yok. 1Password’deki parolalar, yalnızca kullanıcının sahip olduğu bir anahtarla şifreleniyor. Kişisel bir ev sunucusunu 1Password sunucularından daha güvenli tutabileceğiniz çok şüpheli.
  • Ben de pass komut satırı aracı + git kullanıyorum ve şimdiye kadar tek bir sorun bile yaşamadım.
    Betiklerde de kullanılabiliyor.
    Sunucu ihlali yok, web eklentisi zafiyeti yok, sunucu hatası yüzünden tüm parolaları kaybetme riski yok. Sadece düzgün çalışıyor.
  • Ne demek istediğini anlıyorum ama parola kasam kendi barındırdığım bir yazılım ve kendi barındırdığım bir kasa dosyası olsaydı, her gün veri kaybı konusunda endişelenirdim gibi geliyor.
  • Ne kullandığını merak ettim.

• “1Password, devam saldırılarının hedefi olduğu bilinen ikinci Okta müşterisi oldu” cümlesi garip. Ars, Cloudflare’ın da mağdur olduğunu bilmiyor mu?
  https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...

  • BeyondTrust’un sorunu bildirdiği, Cloudflare’ın saldırı hedefi olduğu bilinen ilk Okta müşterisi ve 1Password’ün de ikinci olduğu anlamına geliyor gibi.

• Uygulamalarda şüpheli davranışı izlemek için en iyi uygulamaları merak ediyorum. Servis genelinde istek oranı veya hata oranı gibi temel kontrolleri biliyorum ama pratikte bu ne kadar gelişmiş hale geliyor?
  Bir olay akışı verdiğinizde anormal davranışları bulan akıllı araçlar var mı, yoksa izlenecek her şeyi önceden düşünmek ve kural eklemek mi gerekiyor merak ediyorum.

  • Bu alanda deneyimi olmayan koltuk uzmanı bir sıradan kullanıcıyım, o yüzden süzgeçten geçirerek okuyun. Öncelik denetim izi olmalı. Kullanıcı hesabı veya verileri üzerinde yapılan her işlem, sistemdeki her değişiklik; zaman damgası, kullanıcı vb. bilgilerle denetim günlüklerinde yer almalı. Özellikle parola ya da hesap ayrıntısı değişiklikleri gibi şeyler.
    Böyle bir olay akışı oluşunca veri analiz araçları çalıştırılabilir. Günler, haftalar, aylar süren etkinliklerden normal bir taban çizgisi oluşturulmalı; toplu parola değişiklikleri veya e-posta değişiklikleri gibi sıradan dışı davranışlar alarm üretmeli.
    Ancak bu sadece koltuk varsayımı; denetim günlükleri ve bunların kullanımını gerçekten ele almış biri var mı merak ediyorum.
  • Yapay zeka startup fikri olarak fena değil. Security as a Service olarak tüm istekleri üçüncü taraf bir servis üzerinden proxy’leyip anormallikleri tespit ettirirsiniz. Tabii tespit edemezse o servis sorumluluk almaz muhtemelen.
  • https://www.obsidiansecurity.com/

• Yine mi tespit etmişler?
  https://news.ycombinator.com/item?id=37991863