Bir flört uygulamasını hackleme deneyimi ve güvenlik araştırmacılarına yönelik yanlış yaklaşım

 (alexschapiro.com)
2 puan yazan GN⁺ 2025-05-13 | 1 yorum | WhatsApp'ta paylaş
  • Cerca Dating App'te telefon numarası tabanlı giriş ile açıkta duran API bir araya gelerek, OTP yanıtının doğrulama kodunu içermesi ve bunun kişisel verilerin görüntülenmesine kadar uzanabilen tehlikeli bir duruma yol açıyordu
  • api.cercadating.com, uygulama sürümü başlığı eklendiğinde /docs içindeki openapi.json üzerinden uç noktaları açığa çıkarıyordu; bazı istekler ise zorla eşleştirme gibi iş mantığını bile manipüle edebiliyordu
  • user/{user_id}, geçerli bir kullanıcı kimliğiyle ad, konum, doğum tarihi, okul, telefon numarası, e-posta, profil durumu gibi PII döndürüyordu; bu da OTP açığıyla birleştiğinde hesap ele geçirmeye yol açabiliyordu
  • Hesaba erişim sağlandıktan sonra, belge göndermiş kullanıcılar için pasaport veya kimlik bilgilerine, selfie URL'lerine ve özel mesajlara kadar erişilebiliyordu; doğrulama betiğiyle 6.117 kullanıcı, kimlik bilgisi girmiş 207 kullanıcı ve Yale öğrencisi olarak işaretlenmiş 19 kullanıcı bulundu
  • Açık 23 Şubat 2025'te Cerca'ya bildirildi ve 24 Şubat'ta telefon görüşmesi yapıldı; ancak 21 Nisan'daki açıklama tarihine kadar ne takip eden bir yanıt geldi ne de kullanıcılara bildirim yapıldı, yalnızca yamanın uygulanıp uygulanmadığı bağımsız olarak doğrulandı

Bildirimden sonra kesilen yanıt süreci

  • Cerca Dating App'te özel mesajların, pasaport bilgilerinin, cinsel tercihlerin ve diğer kişisel verilerin açığa çıkmasına yol açabilecek bir flört uygulaması güvenlik açığı vardı
  • Açık keşfedildikten sonra 23 Şubat 2025'te Cerca ekibine e-postayla bildirim yapıldı; ertesi gün yapılan görüntülü görüşmede açık, azaltma yöntemleri ve sonraki adımlar ele alındı
  • Cerca ekibi sorunun ciddiyetini kabul etti, sorumlu açıklamadan dolayı teşekkür etti ve açığın giderileceğini, etkilenen kullanıcılara bildirim yapılacağını söyledi
  • Sonrasında 5 Mart ve 13 Mart'ta düzeltme ve kullanıcı bildirimi planına dair güncelleme istendi, ancak 21 Nisan 2025'teki açıklama anına kadar yanıt gelmedi
  • Açığın kamuya açıklanmasından önce yamalandığı bağımsız olarak doğrulandı ve açıklama buna dayanarak yapıldı

OTP girişinden başlayan hesap erişimi

  • Uygulama yalnızca telefon numarasına kod gönderen OTP tabanlı giriş kullanıyordu
  • Ağ isteklerini incelemek için iPhone uygulamasında Charles Proxy kullanılarak uygulama trafiği yakalandı
  • OTP'yi tetikleyen yanıtın içinde tek kullanımlık parola doğrudan yer alıyordu
  • Bu yapıda, yalnızca kullanıcının telefon numarasını bilmek ilgili hesaba erişmek için yeterliydi
  • Hesap sahibinin telefon numarasını bulmak için ayrı bir yol gerektiğinden API uç noktalarının araştırılmasına geçildi

OpenAPI belgeleriyle ortaya çıkan uç noktalar

  • api.cercadating.com üzerinde dizin fuzzing aracı kullanılarak yollar listelendi
  • Uygulamaya ait başlıklar olmadan sitenin hiçbir bölümüne erişilemiyordu
  • Gobuster ile ilgili başlık eklenerek istek gönderildiğinde /docs uç noktası bulundu ve burada openapi.json sunuldu
  • Burp Suite'in match-and-replace özelliği kullanılarak uygulama sürümü başlığı ile Charles Proxy'den çıkarılan bearer token'ın her zaman eklenmesi sağlandı
  • Korunmayan bazı uç noktalar iş mantığını etkiliyordu ve iki kişiyi zorla eşleştiren istekler bile gönderilebiliyordu

Kullanıcı profilleri ve kişisel veri sızıntısı

  • user/{user_id} uç noktası, geçerli bir kullanıcı kimliği verildiğinde çeşitli kişisel verileri döndürüyordu
  • Yanıt şu bilgileri içeriyordu
    • Ad, cinsiyet, ilgilenilen cinsiyet, şehir, enlem-boylam
    • Okul e-postası ve doğrulama durumu, sektör, meslek, doğum tarihi, boy
    • Okul kimliği ve okul adı, profilin tamamlanma durumu
    • Vatandaşlık kimliği doğrulama durumu, mobil ve e-posta doğrulama durumu
    • Premium durumu, hesabın aktif-askıda-onboarding durumu
    • Telefon numarası, e-posta, kullanıcı kimliği, kalan arama sayısı
    • Profil görselleri, eşleşme tercihleri, kullanıcı prompt'ları, karşılıklı iletişim bilgileri, oluşturulma-değiştirilme zamanları, yaş vb.
  • Python betiğiyle geçerli kullanıcı kimlikleri bulunarak kullanıcı verileri toplu şekilde enumerate edilebiliyordu
  • Dönen telefon numaraları OTP açığıyla birleşince hesapların tamamına erişim için kullanılabiliyordu
  • OTP girişi olmadan da kullanıcıların kişisel verileri açığa çıkmış durumdaydı

Kimlik belgeleri ve özel mesajlara kadar uzanan erişim

  • national_id_verified alanı, sistemde pasaport veya kimlik bilgisi tutulduğunu gösteriyordu
  • Kimlik belgesiyle ilgili yanıtlar şu bilgileri içeriyordu
    • verification_type: PASSPORT
    • document_number
    • front_side_url
    • back_side_url
    • selfie_url
    • durum, kimlik, kullanıcı kimliği
  • Bu bilgiler yalnızca giriş yapmış kullanıcıya sunuluyordu, ancak OTP açığı nedeniyle istenen herhangi bir kullanıcı olarak oturum açmak mümkündü
  • Belge göndermiş kullanıcılar için herkesin kimlik bilgilerini görebilecek bir yapı olduğu, ancak bunun fiilen yapılmadığı belirtildi
  • Potansiyel flört eşleşmeleriyle yapılan özel mesajlar da görülebiliyor, belge gönderilmişse pasaport bilgilerine de erişilebiliyordu

Doğrulanan sızıntının boyutu

  • Hızlı bir betikle bilgi alınabilen kullanıcı sayısı, Yale öğrencisi olarak kayıtlı kullanıcı sayısı ve kimlik bilgisi girmiş kullanıcı sayısı hesaplandı
  • Betik, geçerli kullanıcı kimliklerini sayarken art arda 1.000 kez geçerli kimlik bulamazsa duracak şekilde çalışıyordu
  • Bu yöntem daha fazla kullanıcı olasılığını dışlamıyor
  • Cerca, ilk haftasında kullanıcı sayısının 10 bin olduğunu belirtmişti
  • Doğrulanan sayılar şunlardı
    • 6.117 kullanıcı
    • Kimlik bilgisi girmiş 207 kullanıcı
    • Yale öğrencisi olarak işaretlenmiş 19 kullanıcı

Gizlilik vaatleri ve gerçek risk

  • Cerca'nın gizlilik politikası, “verileri şifreleme ve diğer sektör standardı önlemlerle koruduğunu” söylüyordu
  • Gerçek açık durumu ile karşılaştırıldığında bu ifade yanıltıcı olabilecek nitelikteydi
  • Açığa çıkabilecek veriler arasında cinsel tercihler, özel mesajlar ve çeşitli kişisel bilgiler yer alıyordu
  • Kötü niyetli bir kullanıcı bu bilgilere erişirse kimlik hırsızlığı, takip ve şantaj gibi sonuçlar doğabilirdi
  • Flört uygulamaları hassas veriler işlediği için, uygulamayı hızlı piyasaya sürmekten önce kullanıcı verisi güvenliği öncelik olmalı

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-13
Hacker News yorumları

  • Bu uygulama, üniversite öğrencileri tarafından yapılmış epey erken aşama bir proje gibi görünüyor. Güvenlik ve iletişim pratiklerini düzgün uygulamak için ellerinden geleni yapmaları gerektiği doğru, ama benzer sorunlarda büyük VC yatırımı almış “yetişkin şirketlerin” de berbat tepki verdiğini düşününce çok sert yüklenmek istemiyorum
    https://georgetownvoice.com/2025/04/06/georgetown-students-c...

    • Şiddetle katılmıyorum. “Ne yaptıklarını bilmiyorlardı, o yüzden çok ağır yargılamayalım” demek tuhaf. Ne yaptıklarını bilmedikleri hâlde yayına kadar götürdülerse, bu hafifletici değil, daha çok ağırlaştırıcı bir unsur bence
      Bu, bir sürücünün kazada birini öldürmesi ve sonradan ehliyetinin bile olmadığının ortaya çıkmasına benziyor
    • “Cerca” hakkında bilgi ararken aynı bağlantıyı gördüm; Nisan 2025 tarihli ve iki ay önce yapılmış bir uygulamayı öven bir yazı olduğundan LLM halüsinasyonu gibi çöp bir yazı gibi görünüyor
      Asıl yazıda Şubat ayında Cerca ekibiyle iletişime geçildiği söyleniyor; yani ya çıkış gününde bulunan bir açık ya da yapıda tuhaf bir şey var. Her hâlükârda “iki aylık bir güvenlik açığı” ve “iki aylık, öğrenciler tarafından yapılmış bir uygulama/hizmet”
    • Uygulama Cerca Applications, LLC adına yayımlanmışsa, görmezden gelinmesi gereken birkaç script kiddie olduklarını nereden bilebiliriz ki
    • Bu insanlar muhtemelen başka bölümler okumalı
    • Haklı bir yanı var ama yine de bu fazla. Gizli olması gereken OTP’yi yanıt gövdesinde döndürmemek, ister deneyimli geliştirici ister lise öğrencisi olsun, neredeyse sağduyu meselesi
      Üstelik eğlence için yapılmış bir şey değil, ticari bir ürün. Uygulama içi satın almalarda Cerca App $9.99, Cerca App 3 month $9.99, 10 Swipes $2.99, 3 Swipes $0.99, 5 swipes $1.99, 3 Searches $1.99, 10 Searches $3.99, 5 Searches $2.99 olarak listelenmiş

  • Küçük bir şirkette mühendis olarak bazen kişisel sorumluluğum konusunda endişeleniyorum. PCI veya HIPAA kapsamına girmeyen, düzenlemeye tabi olmayan alanlarda faaliyet gösteren çok fazla şirket var ve küçük yapılarda güvenlik kurumsal bir yükümlülük olmaktan çıkıp sadece mühendisliğin ilgi alanına itiliyor
    Ürün ekibi özelliklere, PM takvime, QA hata bulmaya odaklanıyor; güvenlik konusunda makul şekilde ses çıkaran kişi pek olmuyor. Mühendisten, panodaki işleri bitirmekten fazlası beklenmiyor. Takvimi etkilemeden güvenli hâle getirebiliyorsan ne âlâ, yoksa PM vb. kişilerden baskı görüyorsun
    “Bu ne kadar sürer?”, “Böyle bir şeyin gerçekten yaşanma riski ne kadar?”, “Güvenliği sonra ele alırız, önce MVP’yi müşterilere çıkaralım” gibi şeyler duyuyorsun. Çalışan olarak işverenimin söylediği işi yapıyorum; ama bir hack veya veri sızıntısı yüzünden şirket dava edilirse, “bilmesi gereken” tek kişi olduğum gerekçesiyle kişisel olarak ben mi sorumlu tutulacağım diye düşünüyorum

    • Kesin konuşmak gerekirse, gerçek anlamda mühendislik mühendisi değilsin. Güvenliği onaylayan tasarım çizimlerine imza atmayacaksın ve güvensiz olduğu kanıtlansa bile bunun sorumluluğunu üstlenmeyeceksin
    • LLC ya da şirketse, suç işlendiğini belgeleyen bir şey bırakmadığın sürece tüzel kişilik perdesi ile korunma ihtimalin yüksek
      Yine de ölçekten bağımsız olarak kurum genelinde güvenlik standartlarının eksikliği acınası. Yeni özellik çıkarmak, iyi güvenlik pratiklerini garanti altına almaktan her zaman önce geliyormuş gibi
    • Kişisel olarak, kendimi koruyacak kadar hukuku bilmek, yasa dışı şeylere yazılı olarak itiraz etmek ve “görmezden gel” talimatını da yazılı onayla almak isterdim
      Yine de bir startup’ta sadece bir iki geliştirici varsa bunun bile zor olduğunu anlıyorum. Yasal işler peşinde koşulmadığını hissedersem ben ayrılırdım
    • Küçük bir organizasyonda mühendissen, ekibin geri kalanını bu güvenlik riskleri konusunda eğitme ve bunları azaltmak için mühendislik zamanı ayrılmasını zorlama sorumluluğun olduğunu düşünüyorum
      Kolay değil, ama ciddiye alınmazsa işin kendisini batırabilecek kadar önemli bir konu
    • “Sadece emirleri yerine getiriyordum” savunmasını sevmem ama böyle bir durumda mutlaka yazılı kayıt bırakmak gerekir
      Güvenlik eksikliğine dair endişeleri dile getirdiğin e-posta kayıtları ve yöneticinin bunu önemsememeni söylediği yanıtlar gerekli. Hangi bölge olduğunu bilmiyorum ama sıradan bir çalışanın veri sızıntısından hukuken sorumlu tutulduğu bir örnek bilmiyorum. Genelde veri sızıntılarında kimse gerçek bir sonuçla karşılaşmıyor; şirket de göstermelik bir ceza ödeyip geçiyor

  • Bir araştırmacı olarak hukuki maruziyeti azaltmak için ikinci bir hesap açmak ya da bir arkadaşa profil oluşturtup erişim izni almak yeterli olurdu
    Enumeration açığını kanıtlamak için gerçekten veri kazımaya gerek yok. Benim ID’m 12345 ise ve arkadaşım kaydolup 12357 aldıysa, herhangi bir kullanıcının ID’sini bulup profiline erişilebildiğine kanıt olarak bu yeterli
    Başkalarının da söylediği gibi, açığı doğrulamak ve açıklamak için diğer kullanıcıların kişisel olarak tanımlanabilir bilgilerine bu kadar çok erişmeye gerek yok

    • Bu, çoğu güvenlik araştırmacısının görmezden geldiği standart ve bariz yöntem
      Kişisel olarak tanımlanabilir bilgilerin korunmasını isteyip bunu kanıtlamak için onları kazımak gereksiz ve ikiyüzlüce

  • Yazı epey kafa karıştırıcı. OTP tabanlı girişte tek kullanımlık parola isteğinin yanıtında OTP’nin aynen geldiği kısmı yeterince açıklanmamış, ama muhtemelen api.cercadating.com/otp/ gibi bir API olduğundan, telefon numarasını tahmin ederseniz o numaraya sahip olmasanız bile OTP kodunu alabileceğiniz anlamına geliyor gibi görünüyor.
    Ayrıca 1.000 ardışık ID içinde geçerli kullanıcı yoksa duran bir script ile 6.117 kişi, kimlik bilgisi eklemiş 207 kişi ve Yale öğrencisi olduğunu iddia eden 19 kişi bulduğunu söylüyor; yazar bunun ne kadar tehlikeli olduğunun farkında mı emin değilim. Aslında weev’in AT&T’yi ihlal ettiği yönteme benziyor ve o hapse girmişti[0].
    Daha büyük bir şirket ve daha büyük bir sızıntıydı, ama bir güvenlik açığını kullanarak binlerce kişinin verisine izinsiz eriştiğini herkesin içinde övünerek anlatmazdı diye düşünüyorum. Ahlak yargısı yapmak istemiyorum; güvenlik araştırmacılarının uyarıda bulunabileceği bir alan olması gerektiğini düşünüyorum, ancak hukuk güvenlik araştırmacıları için epey dezavantajlı.
    [0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...

    • Telefon numarası tahmininden bahsedilmiş ve OTP gönderen API çağrısının kelimenin tam anlamıyla OTP’yi döndürdüğü yazıyor.
    • Auernheimer davasının orijinal iddianamesini okursanız, savcılığın burada muhtemelen bulunmayan geniş kapsamlı kasıt kanıtlarına sahip olduğunu görürsünüz.
      O davadaki sanıklar temel kişisel tanımlanabilir bilgileri yayımlamakla da suçlanmıştı; burada böyle bir şey olmuş gibi görünmüyor.

  • Başka bir dating uygulamasında benzer bir şey yaşamıştım; oradan hiçbir zaman yanıt gelmedi. Kurucunun dikkatini çekmek için profil yazısını “benimle iletişime geç” ifadesiyle değiştirdim, o da yedeği geri yükledi.
    Birkaç yıl sonra Instagram reklamını görünce sorunun hâlâ var olup olmadığını kontrol ettim; hâlâ vardı. Uygulama-proxy-sunucu ile kolayca bulunabilen API endpointini bilen herkesin tam yönetici yetkisine sahip olup tüm mesajlara, eşleşmelere vb. erişebildiği bir yapıydı.
    Tekrar gidip bir kez daha denemeli miyim diye düşünüyorum.

    • Sorumlu bir geliştirici gibi iletişim adresinden yalnızca güvenlik açığı bildirimi yapıp geçmek yeterli olmaz mı?

  • Pasaport veya adres gibi hassas bilgiler alınmadan önce insanların iki kez düşünmeye zorlanması gerekiyor. Bu tür şeyler sadece çocukların uygulama yapması diye geçiştirilemez.

    • Pasaport veya başka kimlik bilgilerinin girildikten sonra herkese açık biçimde görünür olmasının hiçbir nedeni yok. UI’da göstermek için API ile veri çekmek gerekse bile tam pasaport/kimlik numarasını içermesi gerekmez; en azından yalnızca son birkaç haneyi gönderecek şekilde maskeleyebilirler.
      Bir dating sitesi için API’nin kimlik durumu hakkında verified/not-verified boolean değeri ya da ‘not-verified’, ‘passport’, ‘drivers-license’ gibi enum değerleri döndürmesi yeterlidir. İstemci/UI’da ayrıntılı bilgileri göstermeye gerçek bir ihtiyaç yok.
      Havayolu uygulaması gibi, sınır geçişi amaçlı kimlik belgesi seçmeniz gereken durumlar istisna olarak daha fazla bilgi gösterebilir; ama United uygulamasında olduğu gibi pasaport numarasının yalnızca son birkaç hanesini göstermek yeterli. Dahili API’nin de sadece bu kadarını göndermesini isterim.
    • Birleşik Krallık hükümeti porno sitelerine erişimde kimlik doğrulamayı zorunlu kılmak için çok uğraşıyor; bunun kendi yüzlerinde patlayacağı günü sabırsızlıkla bekliyorum.
    • Devletin işlettiği güvenli ve özel bir kimlik doğrulama hizmeti gibi bir şey olmalı.
      Ya da Apple veya Google gibi “devlete benzer” bir yer de bunu üstlenebilir.
    • GDPR’ye bakın.
      https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
    • Üçüncü taraf kimlik doğrulama hizmeti kullanmamışlar mı? Uygulamalar genelde bunu böyle çözer. Yoksa böyle bir üçüncü taraf hizmet, gerçek görsel gibi ham kimlik belgesini uygulamaya aynen aktarıyor olmasın?

  • İstek API yanıtında OTP döndürmesi hiç mantıklı değil. Bunu neden yapmış olabilirler?

    • UI’ın kullanıcının girdiği değerin doğru olup olmadığını kontrol etmesini sağlamak için yapmış olabilirler.
      Güvenliği düşünmezseniz oldukça makul ve bariz bir çözüm aslında. Dating uygulamaları zorunlu olarak çok fazla kişisel tanımlanabilir bilgi içerdiğinden, yapılması en riskli uygulama türlerinden biri; bu ise korkunç.
    • OTP’yi oluşturup kaydettikten sonra veritabanı veya cache gibi yerlerden gelen yanıtı aynen döndürmüş olabilirler.
      Hızlı bir proof of concept veya MVP’de zaman kazanmak için kayıt modelini API yanıtı olarak aynen kullanmak sık görülen bir şey, bu yüzden kolayca gözden kaçabilir.
    • Veritabanı maliyetini ortadan kaldıran basit bir numara.
    • Bir HTTP isteğini azaltıyor ve kullanıcı deneyimini de hızlandırıyor. Sevmemek için ne sebep var ki?
      Pinterest’in yeni API’si çıktığında OAuth entegrasyonu kullanan tüm uygulamalara kullanıcı bilgilerinin tamamını saçıyordu; buna iki aşamalı doğrulama gizli değeri de dahildi. Bildirip ödül aldım, ama bu tür şeyler daha iyisini bilmesi gereken büyük şirket API’lerinde bile oluyor.
    • OTP’nin “tek kullanımlık parolayı tetikleyen yanıt” içinde gönderildiği anlaşılıyor.
      Framework kaynaklı olma ihtimali var. Muhtemelen veritabanına koyulan nesne, ORM veya başka bir saklama sistemi tarafından doğrudan serileştirilip HTTP yanıtı olarak geri döndürülüyordu.

  • https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
    Bu konuyla ilgili başka bir haber.

    • “Geliştiriciler en iyi uygulamaları kullanmalı, ama bu yeterli olmayabilir. Verileri güvende tutmak çözülmemiş bir problem” demek, ha öyle mi. O zaman yapacak bir şey yok.

  • Kişisel tanımlanabilir bilgi saklamayı nükleer atık depolamak kadar riskli hâle getiren bir yasa olmasını isterdim. Sızıntı olursa şirket neredeyse kesin olarak batmalı ve sorumlular hukuki riskle karşı karşıya kalmalı.
    Teşvikleri doğru hizalamanın en iyi yolunun bu olduğunu düşünüyorum. Şu anda mümkün olduğunca çok kullanıcı bilgisi saklamanın neredeyse hiçbir dezavantajı yok. Veri sızıntısı mı? Bir özür tweet’i atıp devam ediyorsunuz.

    • Kişisel tanımlanabilir bilgileri nükleer atık gibi ele almak biraz aşırı bence. Kişisel tanımlanabilir bilgiler arasında kimlik doğrulama ve iletişim amaçlı e-posta adresi gibi nispeten zararsız veriler de var.
    • Beyaz yakalılar hapishanesi gerekebilir.
      Ancak o zaman bu sorun hak ettiği ilgiyi görebilir gibi geliyor.

  • “Hiç yanıt alamadım” deniyorsa, sessizlik sürerse 90 gün sonra açığı kamuya açıklayacağını bildirme zamanıdır

    • Bu, şirketten çok masum kullanıcılar için daha büyük bir ceza olur
    • Burada açık denebilecek bir şey bile yok. Düpedüz herkese açık durumda
    • Bunu yaparsan dava edilmenin ve hatta suç duyurusuyla karşılaşmanın yolu açılır