Harvest uygulamasındaki açık yönlendirme Microsoft hesabı OAuth token’larının çalınmasına yol açabiliyordu

 (eval.blog)
1 puan yazan GN⁺ 2023-10-23 | 1 yorum | WhatsApp'ta paylaş
  • Harvest’in Outlook Calendar OAuth bağlantı akışında callback URL’i, state değerindeki hedefe yeniden yönlenerek açık yönlendirme oluşturuyordu; örtük yetkilendirme akışıyla birleştiğinde token’lar harici URL’lere sızabiliyordu
  • Sorun Microsoft’ta değil, Harvest entegrasyonu tarafındaydı; kayıtlı OAuth redirect_uri, kullanıcıyı saldırganın belirlediği domaine gönderen bir yönlendirme ara noktası haline geliyordu
  • state, URI ile kodlanmış JSON’du; subdomain içine example.com/ gibi sonunda eğik çizgi bulunan harici bir domain konduğunda example.com/.harvestapp.com/... biçiminde yönlendirme yapıyordu
  • PoC, Microsoft OAuth authorize URL’inde client_id=0dcef4db-36d8-4aed-9cc5-ab43e1814884, response_type=id_token, response_mode=fragment, scope=openid kullanarak #id_token=... fragment’ının yönlendirme hedefine eklendiği akışı gösteriyordu
  • Güvenlik açığı 23 Ağustos 2020’de bildirildikten sonra yamanın 1 Ağustos 2023’te yapıldığı doğrulandı; 22 Ekim 2023’te Harvest gecikmenin human error olduğunu söyleyerek özür diledi

OAuth callback’inde token’ın sızdığı akış

  • Harvest, kullanıcıların Outlook Calendar’ı OAuth ile bağlayabildiği bir zaman takip yazılımıdır
  • Yetkilendirme başarılı olduğunda kullanıcı https://outlook-integration.harvestapp.com/auth/outlook-calendar/… adresine yönlendirilir
  • Bu callback, kullanıcıyı tekrar state içinde sağlanan URL’ye taşır ve bu süreçte açık yönlendirme oluşur
  • İlk tespit edilen callback URL’inin state değeri URI ile kodlanmış JSON’dur
    • Decode edildiğinde {"return_to":"/","subdomain":"hackerone295"} biçimindedir
    • subdomain değeri, hackerone295.harvestapp.com gibi bir Harvest uygulama alanını tahmin etmek için kullanılır
  • subdomain içine example.com/ gibi sonunda eğik çizgi bulunan bir değer koyulursa callback URL’i harici bir domaine yönlenecek hale gelir
  • Bu callback URL’i OAuth uygulamasına kayıtlı redirect_uri olduğundan, açık yönlendirme ile örtük yetkilendirme akışı birleştirildiğinde token yönlendirme hedefine sızabilir
  • PoC authorize URL’i şu değerleri kullanır
  • Kullanıcı nihayetinde şu biçimde bir adrese yönlendirilir
  • Bu, Microsoft tarafında bir güvenlik açığı değildir

Bildirimden yamaya geçen süre

  • Harvest ekibi, açığın açıklanması ve yama sürecinde çok az yanıt verdi; açığı triage ile kabul ettikten sonra da düzeltme uzun zaman aldı
  • Güvenlik açığı 23 Ağustos 2020’de bildirildi ve Harvest ilk kez 16 Ekim 2020’de iletişime geçti
  • 27 Kasım 2020’de rapor triaged durumuna alındı
  • 28 Nisan 2022’de şirket düzeltme üzerinde çalıştığını ve tahmini süreyi 2 hafta olarak verdiğini söyledi, ancak gerçek düzeltme için yaklaşık 1 yıl daha gerekti
  • 1 Ağustos 2023’te güvenlik açığının yamalandığı doğrulandı
  • 21 Ekim 2023’te rapor, herkese açık bir yazıyla yayımlandı
  • Aynı gün itibarıyla rapor hâlâ triage durumundaydı; bug bounty politikasında ödülden bahsedilmesine rağmen bounty veya HackerOne puanı verilmedi
  • 22 Ekim 2023’te yazı dikkat çektikten sonra Harvest gecikmeyi human error olarak açıklayıp özür diledi

İlgili okumalar

1 yorum

 
GN⁺ 2023-10-23
Hacker News yorumları

  • Bir bug bounty programı sorumlusu olarak içeride neler olduğunu açıklayayım. Zaten @0xcrypto’dan özür diledim ve içeride de açıkladım ama burada da toparlamanın doğru olacağını düşünüyorum
    En başından beri bu sorunu tamamen yeniden üretemedik ve bir şeyi gözden kaçırırız diye kapatamadık. Son olarak “bir çözüm bulacağım” diye yanıt verdikten hemen sonra ise yeniden üretilemediği kanaatine yaklaşmıştık; benzer bir OAuth ile ilgili bildirim de gelince içeride karışıklık oldu ve bunun zaten işlenip iletildiğini sandık
    Bildirim ayarları yüzünden sonraki mesajları kaçırdım ve konu Triage durumunda süresiz şekilde kaldı, güncelleme de yapılmadı. Bu bir bahane değil; ben de uzun süre bug bounty avcısı olarak çalıştım, bir şirketten güncelleme beklemenin ne kadar sinir bozucu olduğunu çok iyi biliyorum. Müşteri güvenliği en büyük önceliğimiz ve güvenlik sayfasında yazanlar da doğru

    • Hata olabilir ama 3 yıl boyunca HackerOne’a defalarca ulaşıldığı halde HackerOne’ın Harvest ile iletişime geçememesi hâlâ açıklanmış değil
      Üstelik artık yeniden üretilemeyen bir bildirimin nasıl ele alınacağı da belirsiz. Bunu HackerOne’da daha fazla tartışmak istedim ama özür mesajından sonra yine yanıtsızlık olmuş gibi görünüyor
    • Sonuçta bu açığın anlatıldığı şekilde gerçekten çalıştığına inanıp inanmadığınızı ve öyleyse neden yeniden üretilemediğini merak ediyorum
    • Açıklamayı doğrudan duymak güzel. Yeniden üretilememiş olsa bile, kaynak koda bakarak open redirect mümkün mü diye kolayca kontrol edilemez miydi diye düşünüyorum
    • En azından bunu ciddiye aldığınızı yazmanız bile sevindirici. Herkes hata yapabilir ama hata olduğunda sorumluluk alınmazsa işin büyüdüğünü düşünüyorum
    • Harvest’i memnuniyetle kullanıyorum ama artık iOS’taki yeni mobil uygulamayı da düzeltmeniz iyi olur. Küçük sorunlar o kadar çoğaldı ki destek ekibine bildirmeyi bile bıraktım
      Uygulamanın durumu sık sık sunucu durumuyla uyuşmuyor; sunucudaki değişiklikler ancak zorla yenilemeden sonra görünüyor ya da istemcideki değişiklikler kaydettikten sonra geri dönüyor. Zaman takibi kullanıcı deneyimi de rahatsız edici; butonlar ancak kaydırınca görünüyor ya da başlat/durdur/yeniden başlat/sil butonlarının yeri öğenin durumuna göre sürekli değişiyor. Eski uygulama güzel değildi ama sorunsuz çalışıyordu

  • Oldukça endişe verici. Harvest kullandığımda destek gerçekten harikaydı; yanıtlar hızlıydı, müşterilerin ürünü nasıl kullandığını çok ayrıntılı anlıyorlardı ve mevcut özellikleri yaratıcı biçimde nasıl kullanabileceğimi de detaylı anlatıyorlardı
    Uygulanmamış özellikler için verilen yanıt ise “backlog’a ekleriz ama garanti veremeyiz” oluyordu. Mühendislik ekibinin 30 kişi olduğu yazıyor [1] ama bu kaynağın nereye gittiğini pek bilmiyorum. Çünkü başka özelliklerin de hızla çıktığını görmedim
    “Harvest kullanıcısı” olarak spam almaya başlayınca müşteri listesini satmış olabileceklerinden şüphelendim ama şirket yöneticileri hemen devreye girip bunu güçlü şekilde reddetti ve derhal inceleme başlattı; yani bunu çok ciddiye aldılar. Bu iyiydi
    Ama sonuçta bunun da bir mühendislik sorunu gibi göründüğünü söyleyebilirim. Aktif müşterileri oldukça kolay tahmin etmenin bir yolunu buldum; bu da “backlog”a girdikten sonra aylardır düzeltilmedi. Düzeltme çok küçük görünüyordu. Ayrıca MFA yalnızca Google ile girişte sunuluyor [2]. Yine de uygulamanın kendisi yaptığı işi gerçekten çok iyi yapıyor
    1: https://www.getharvest.com/about/meet-the-team
    2: https://support.getharvest.com/hc/en-us/articles/36005266713...

    • İyi değerlendirmeniz için teşekkürler. Destek ekibinin harika olduğu konusunda kesinlikle katılıyorum. Küçük bir ekip ama her konuyu çok ciddiye alıyorlar ve az önce bahsettiğim incelemeye de bizzat dahil oldular
      Bu başlıktaki bildirimi yapan kişiyle iletişimin bozulması tamamen benim hatamdı ve üstteki yanıtta açıkladığım gibi bunun bir daha yaşanmamasını sağlayacağım
    • Beğeniyor musun nefret mi ediyorsun, anlamadım. İroni mi yapıyorsun?
    • Destek kalitesi gerçekten iyiydi. Talepler her zaman çok yetkin kişiler tarafından ele alınıyordu ve çoğu zaman birkaç dakika içinde yanıt alıyordum
      Özellik isteklerimin bazıları gerçekten ürüne de girdi. Bunun benim etkimin sonucu olup olmadığını bilmiyorum ama en azından iyi bir zaman takip aracı konusunda benzer düşündüğümüzü hissettim

  • Başlık Microsoft’a karşı epey haksız görünüyor. Son dönemdeki kimlik doğrulama olayları nedeniyle Microsoft’un gündemde olmasından yararlanılmak istenmiş gibi; başlığı görür görmez “yine mi MS ihlali?” diye düşündüm
    Gerçekte olan şey Harvest’in token’ı ve Harvest kodundaki enjeksiyon açığı yüzünden yalnızca Harvest uygulaması erişim yetkileri yanlış şekilde açığa çıkmış. Arkasında başka hangi kimlik sağlayıcısı olursa olsun aynı şekilde savunmasız olurdu

    • Blog yazısının yazarı benim. Endişeyi anlıyorum ve başlıktan Microsoft adını çıkarmayı düşündüm ama uygun bir ifade bulamadım
      Çünkü bu açık yalnızca Microsoft hesap bağlantısı için kullanılan OAuth uygulamasını etkiliyor. İlk başlık “Microsoft OAuth token leak via open redirect in Harvest App” idi, sonra bunu “Microsoft Account's OAuth tokens leaking via open redirect in Harvest App” olarak değiştirdim. Hâlâ değiştirmeye açığım, önerilere açığım
    • Ben de aynı şeyi düşündüm. Hatta yazının OAuth’un nasıl çalıştığını gerçekten bildiği hâlde buna MS token’ı demesine şaşırdım diyebilirim

  • RFC 6749, yetkilendirme sunucusunun bu tür saldırıları nasıl önlemesi gerektiğini ayrıntılı olarak ele alır
    Yetkilendirme sunucusu, açık istemciler için yönlendirme URI’sinin kaydını zorunlu tutmalı; gizli istemciler için de bunu istemesi tavsiye edilir. İstekte bir yönlendirme URI’si verilirse, yetkilendirme sunucusu bunu kayıtlı değerle karşılaştırıp doğrulamalıdır
    O halde Harvest uygulaması kötü amaçlı bir redirect_uri kaydetmemiş olmalı; peki bu nasıl mümkün oldu diye merak ediyorum. Microsoft OAuth sunucusu, OAuth istemcisinin kayıtlı yönlendirme URI’siyle karşılaştırırken redirect_uri içindeki URL parametrelerini görmezden mi geliyor?

    • Görünüşe göre bunun üstüne ikinci bir yönlendirme bindirilmiş ve bu da state parametresine konmuş. Muhtemelen amaç, istenen herhangi bir yere yönlendirebilmekti
      Amaçlanan akış şu: Harvest yetkilendirme URL’sine git → redirect_uri=registered_uri ve state=some_encoded_final_uri ile Microsoft yetkilendirme URL’sine yönlendiril → kullanıcı kimlik bilgilerini girsin → kayıtlı URI’ye yönlendirilsin → state okunup içindeki URI’ye yeniden yönlendirilsin
      Bu saldırı da hâlâ izin verilen URI’ye yönlendiriyor, ancak o uç nokta state değerini okuyup yanıtı/token’ı olduğu gibi iletiyor. Hata üç parçalı: state’in kötüye kullanılması, madem kötüye kullanılacak en azından state’in şifrelenip doğrulanmaması ve örtük yetkinin açık bırakılması. Gerekliyse sınırlı amaçlı ayrı bir kayıt oluşturulmalıydı
    • Harvest’in redirect_uri değeri Microsoft’a kayıtlı. Microsoft OAuth sunucusu Harvest’e yönlendirdikten sonra, Harvest state içindeki verilere göre kendi yönlendirmesini uygulamış

  • Örtük yetki, bu yazıda da görüldüğü gibi, tam da bu nedenlerle epey korkunç
    Bu arada yakında gelecek OAuth 2.1 spesifikasyonunda kaldırılması planlanıyor: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm...

    • Zaten yaklaşık 6 yıl önce kullanım dışı bırakılacaktı, değil mi? CORS bu kullanım alanının yerini aldığı için yeni spesifikasyonda tutulmasının bir nedeni yok

  • Açığın düzeltilmesi 3 yıl mı sürmüş? Ağustos 2020’den Ağustos 2023’e; Harvest ekibinin büyüklüğünü bilmiyorum ama yine de kabul edilemez görünüyor

    • Birçok şirkette sık görüldüğü gibi düşük öncelikli bir iş olarak backlog’a atılmış, birkaç Jira temizliği ve organizasyonel yeniden yapılanmadan geçmiş, sonra da en sonunda tekrar bulunup düzeltilmiş gibi duruyor
    • Harvest güvenlik ekibindenim. Diğer yorumlarda da yanıtladığım gibi, temelde yeniden üretilemedi ve açık bir düzeltme de yapılmadı. Ancak kapatılması gereken issue, benim insan hatam nedeniyle Triage durumunda kalmış

  • Keşke bir OAuth uzmanı bu sorunu biraz daha ayrıntılı açıklasa. Blog yazısını birkaç kez okudum ama gerçek açığı hâlâ anlayamadım
    Çok sınırlı OAuth bilgimle anladığım kadarıyla Harvest uygulaması Microsoft’tan kullanıcıyı doğrulamasını istiyor, Microsoft kullanıcıyı doğruladıktan sonra başarılı olursa callback URL’sine yönlendirip yanıt gövdesinde erişim token’ını iletiyor, öyle değil mi?
    Bu durumda blog yazarı, dönüş URL’sini gerçek dönüş URL’si yerine example.com’a gidecek şekilde ayarlayan elle hazırlanmış bir URL üretmiş olmuyor mu?

    • Evet. Blog yazarı gerçekten böyle elle hazırlanmış bir URL oluşturmuş. Ancak saldırı URL’sindeki callback URL’si harvestapp alan adında ve saldırganın kontrol ettiği kısım, OAuth sunucusunun gözünde büyük ölçüde opak olan state içinde
      Bu URL sayesinde birine login.microsoftonline.com bağlantısı gönderip “Harvest’e giriş yap” diyen bir giriş istemi gösterebilir ve ardından saldırgan gerçekten Harvest hesabıyla ilgili yetkileri elde edebilir
      Normalde bu mümkün değildir. Saldırgan, example.coma yönlenen yeni bir uygulama kaydedebilir ama bu durumda Harvest’le ilgili yetkiler içeren bir erişim token’ı alamayacağı için işe yaramaz
      Microsoft tarafındaki OAuth uygulamasında geçerli yönlendirme izin listesi vardır; bu yüzden login.microsoftonline.com/authorize?client_id=$harvestAppID&redirect_uri=attacker.com gibi denemeler Microsoft tarafında hata verir. Saldırının mümkün olmasının nedeni, geçerli bir outlook-integration.harvestapp.com URL’sinin erişim token’ını aldıktan sonra saldırganın sitesine yeniden yönlendirme yaparken erişim token’ını da aktarmasıdır
    • Açık outlook-integration.harvestapp.com tarafındaydı. OAuth2 callback başarıyla tamamlandıktan sonra yapılacak işlemleri belirten bir JSON nesnesi state olarak kullanılıyordu
      subdomain özelliği, tarayıcıyı harvestapp.com alt alanına #id-token ile birlikte yönlendirmek için kullanılıyordu. Sorun, subdomain değerinin aşağıdaki URL’ye doğrudan enjekte edilmesiydi
      https://${subdomain}.harvestapp.com/...#id-token=...
      JSON yükündeki subdomain alanı sonuna eğik çizgi eklenmiş attacker-controlled.com/ gibi bir değerle ayarlanırsa URL https://attacker-controlled.com/.harvestapp.com/...#id-token=.. olur ve tarayıcı başka bir alan adına giderken token sızar
    • Microsoft, dönüş URL’sinin Harvest’in belirlediği izin listesinde olup olmadığını denetler. Harvest muhtemelen yazılımın birden fazla örneğini desteklemek için bunun üstüne kendi yönlendirme mekanizmasını ekledi ama yönlendirme girdisini düzgün biçimde temizlemedi
      Dolayısıyla bu OAuth’nun kendisinden kaynaklanan örtük bir sorun değil, zayıf bir uygulama
    • Tam olarak bilmiyorum ama sorunun Harvest’in tüm URL’leri callback URL’si olarak kabul etmesi olduğunu düşünüyorum. Microsoft’a yalnızca belirli URL’lerin callback olarak kabul edilmesi gerektiği söylenmeliydi
      İş akışı kurulurken güvenilir callback URL’lerinin gerçek bir listesini oluşturmak yerine, callback URL izin listesinde joker karakter kullanmış olabilirler. Tamamen yanlış da olabilir

  • Neden 3 yıl beklediklerini anlamıyorum. Yayın öncesi erteleme süresi için 90 gün yeterli.

    • Çok büyük değişiklikler gerekiyorsa ve oldukça büyük bir ekip zamanının çoğunu bu soruna ayırıyorsa, 90 günden daha uzun sürebilir. Ya da çözüm hazır olabilir ama müşteri bildirimleri nedeniyle belirli ve nispeten kısa bir takvime uymak gerekebilir.
      Yine de böyle ek ertelemelere araştırmacının ya da avukatının/temsilcisinin izin vermesi gerekir. Bu, normalden büyük meselelerde şirketin iyi niyetle talep edebileceği bir şeydir.

  • HackerOne şirketlerin böyle bir şeyi 3 yıl boyunca bekletmesine izin veriyorsa, rolünü düzgün yapmıyor gibi görünüyor.

    • HackerOne, bug bounty programı yürüten şirketlere bağımlıdır. Ne ölçüde devreye girdiği, sunduğu hizmete — örneğin triyaj yapıp yapmadığına — büyük ölçüde bağlıdır.
      En temel seviyede sadece bir güvenlik açığı ifşa platformu ve araştırmacının hukuk ekibi tarafından dava edilmemesini amaçlayan standart yasal metinler sağlar.
      Çoğu durumda şirketler ifşa taleplerini reddeder. Araştırmacı izin almadan açıklarsa hem HackerOne hem de şirketle yaptığı anlaşmayı ihlal eder ve hukuki sorumlulukla karşı karşıya kalır. Bu durumda şirketin açıklamaya onay verdiği anlaşılıyor; müdahale çok yavaş olsa da bunu teslim etmek gerekir.
      Benim de dört haneli ödül seviyesindeki hataların bir yıldan uzun süre düzeltilmediği birkaç deneyimim oldu ama bunu HackerOne'ın suçu olarak görmedim.
    • Şirket tarafında HackerOne meseleleriyle uğraştım; bir HackerOne katılımcısı HackerOne'ın kendi kurallarını sürekli ihlal ediyordu. İfşa takvimini bozdu, hatayla ilgili sosyal medyada yalan paylaşımlar yaptı, hatta çalışanları tehdit etti.
      HackerOne umursamadı. Bu kişinin kendi kurallarını ihlal ettiğini defalarca bildirmemize rağmen ellerinden bir şey gelmediğini söylediler.
      Çalışır durumdaki bir şirketi asgari operasyon kadrosuna kadar küçültüp, yetkisiz destek görevlilerinin soruları yanıtladığı bir yapı kalmış gibiydi. Oldukça eski bir olay, şimdi değişmiş olabilir ama o zamanki izlenim buydu.
    • Üç taraf — HackerOne, şirket ve hatayı bulan araştırmacı — arasında tüm kozlar şirketin elinde.
      HackerOne'ın haddini aştığını ve şirkete ne yapmasına “izin verileceğini” belirlediğini hissederlerse, şirketler basitçe HackerOne'dan ayrılıp kendi iç çözümlerini kurar.
    • Belki de şirket incelemesi gerekebilir; böylece işleri yıllarca sürüncemede bırakan ve ödeme yapmayan berbat şirketlerden kaçınılabilir.

  • Bu konunun neden Microsoft'a iletilmediğini anlamıyorum. Microsoft, sorun düzeltilene kadar bu OAuth uygulamasının erişim yetkisini iptal edebilirdi.
    Yine de Microsoft'a OAuth ile bağlı buna benzer kötü uygulamadan binlerce tane vardır diye düşünüyorum.

    • Bunun mümkün olduğunu bilmiyordum. Açıkçası benim aklıma hiç gelmezdi.