Bir flört uygulamasını hackleme deneyimi (ve güvenlik araştırmacılarına yaklaşmanın yanlış yolu)

• Cerca adlı flört uygulamasında ciddi bir güvenlik açığı bulundu
• OTP yanıt içinde açığa çıkıyordu; yalnızca telefon numarasını bilen herkes hesaba erişebiliyordu
• Kimlik doğrulama olmadan açık bırakılan çeşitli API endpoint'leri üzerinden kişisel veriler kolayca sızdırılabiliyordu
• Kullanıcıların cinsel yönelimleri, mesaj içerikleri, kimlik belgeleri gibi hassas verileri büyük ölçekte açığa çıktı
• Servis tarafı, araştırmacının sorumlu bildirimine rağmen uygun yanıt ve kullanıcı bilgilendirmesi konusunda yetersiz kaldı

---

Güvenliği ciddiye alması gereken startup'ların önemi

• Son dönemde startup'lar pazara çıkışı hızlandırırken güvenliği ihmal ediyor
• Kişisel verilerin yoğunlaştığı bir flört uygulaması olmasına rağmen, geliştirme ve operasyon yetersizliği nedeniyle kullanıcılar riske atıldı

Açığın bulunması ve bildirim süreci

• 23 Şubat 2025'te Cerca'ya e-postayla güvenlik açığı ve ilgili sorunlar anlatıldı
• 24 Şubat'ta video görüşme üzerinden açığın ayrıntıları, çözüm yolları ve sonraki süreç görüşüldü
• Cerca ekibi, ciddiyetin farkında olduğunu, hızla aksiyon alacağını ve kullanıcıları bilgilendireceğini iletti
• Sonrasında birkaç kez ilerleme durumu soruldu, ancak 21 Nisan itibarıyla ne yanıt ne de duyuru geldi
• Bağımsız doğrulama sonucunda, ilgili açığın yamandığı görüldü

OTP açığı ve basit hack süreci

• Uygulama giriş sürecinde tek kullanımlık parola (OTP) ağ yanıtında doğrudan açığa çıkıyordu
• Saldırganlar, yalnızca telefon numarasını bilerek herhangi bir hesaba kolay ve hızlı biçimde erişebiliyordu

API endpoint'lerine erişim ve veri sızıntısı

• Yalnızca uygulama sürümü header'ı girilerek tüm API yollarına erişilebildiği doğrulandı
• /docs endpoint'i üzerinden OpenAPI dokümantasyonunun tamamı açığa çıkıyordu
• Burp Suite gibi araçlarla uygulama header'ı ve token'ların otomatik eklenmesi sayesinde API kontrol edilebiliyordu
• Bazı endpoint'ler yalnızca iş mantığını değiştirirken, kritik endpoint'ler ciddi kişisel veriler döndürüyordu
• user/{user_id} gibi yollar üzerinden kişisel veriler, telefon numaraları ve hatta hesap ele geçirme imkânı bulunuyordu

Büyük ölçekli kişisel veri ve kimlik bilgisi sızıntısı

• Kişisel veri endpoint'i üzerinden cinsiyet, şehir, doğum günü, okul e-postası, kimlik bilgileri gibi PII büyük ölçekte açığa çıktı
• Özellikle national_id_verified gibi kimlikle ilgili alanlar üzerinden pasaport ve kimlik kartı görüntüleri gibi hassas dosyalara erişilebiliyordu
• Bir saldırı script'iyle 6.117 kullanıcının tespit edildiği, bunların 207'sinin kimlik bilgisi de girmiş olduğu doğrulandı
• Bunlar arasında Yale Üniversitesi mensubu olduğunu belirten hesaplar da vardı
• Cerca'nın resmî Instagram hesabına göre bu, ilk haftadaki 10 bin kullanıcıya karşılık gelen bir ölçekti

Gerçek zarar riski ve sorunun ciddiyeti

• Cinsel yönelim, konuşma içerikleri, kimlik belgeleri gibi son derece hassas bilgiler sızdığı için takip, kimlik hırsızlığı ve şantaj gibi ağır zarar riskleri oluştu
• Cerca, "şifreleme dahil sektör standartlarına uyuyoruz" diye bilgilendirme yaptı, ancak bu ifade fiilî işletim durumu ile örtüşmüyordu
• Kullanıcılar bunu doğrudan doğrulayamadığı için, uygulama sağlayıcısının proaktif ve sorumlu güvenlik yönetimi şart
• Fiilen, belirsiz sayıda kişinin zaten büyük miktarda kişisel veriyi ele geçirmiş olma ihtimali de mevcut

Sonuç ve sorumlu güvenlik kültürünün gerekliliği

• Herkesin kolayca hackleyebileceği kadar zayıf güvenliğe sahip bir uygulamanın işletilmesi ciddi bir toplumsal sorun
• Kullanıcı verilerini korumak en yüksek öncelik yapılmazsa zarar gerçek zamanlı olarak ortaya çıkabilir
• Güvenlik araştırmacısının bildirimine aktif yanıt ve kullanıcı bilgilendirmesi açısından yetersiz kalan Cerca örneği ibret verici
• Daha güvenli bir internet ortamı kurmak için tüm geliştiricilerin güvenlik yapısını oluşturmayı en yüksek öncelik haline getirmesi gerekiyor

[GN⁺]

Hacker News görüşleri

• Bu uygulamanın üniversite öğrencileri tarafından epey başlangıç seviyesinde yapılmış bir ürün olduğunu hesaba katsam bile, güvenlik ve iletişim konusunda ellerinden gelenin en iyisini yapmaları gerektiğini düşünüyorum. Yine de büyük bir VC tarafından fonlanan yetişkin şirketlerin de aynı sorunlara çarpıp benzer şekilde davrandığını görünce, öğrencilere aşırı sert davranmak da gerekmiyor gibi geliyor. Makale bağlantısını paylaşıyorum

  • Buna kesinlikle katılmıyorum. "Bilmiyorduk" bir mazeret olamaz. Bilmeden devam etmiş olmaları aslında daha büyük sorun. Bu, ehliyetsiz ve yetersiz bir sürücünün kaza yapıp birini yaralamasına benziyor
  • Ben de Cerca hakkında bilgi bulmaya çalışırken kaynak bağlantısına tıkladım; Nisan 2025 tarihli bir yazı ve yaklaşık iki ay önce yapılmış uygulamayı övüyor. Bu, LLM halüsinasyonuyla üretilmiş bir çöp gibi duruyor. OP’nin dediğine göre Şubat’ta Cerca ekibiyle iletişime geçmiş; yani ya açık daha lansman olur olmaz bulundu ya da ortada tuhaf bir durum var. Yine de ortada "iki aylık bir açık" + "iki aylık, öğrenciler tarafından yapılmış bir hizmet" durumu var
  • Uygulama "Cerca Applications, LLC" adı altında çıkıyorsa, bunun öğrencilerin yaptığı bir uygulama olduğunu ve o yüzden biraz daha anlayışlı olmamız gerektiğini insanların nasıl bileceğini anlamıyorum
  • Bence bu öğrenciler başka bir şey okumalı
  • Bu, onları savunmak gibi geliyor. Üniversite öğrencileri yaptı diye otomatik olarak hoş görmek doğru değil. The Facebook da başlangıçta üniversite öğrencileri tarafından başlatılmıştı. Meta’nın uzun süredir devam eden mahremiyet ihlalleri ve veri güvenliğini umursamama geçmişi zaten ortada. O yüzden bu tür davranışlar mazur görülemez; çözüm ancak kurucuların yaşı veya deneyiminden bağımsız olarak düzgün düzenleme ve para cezalarıyla gelir diye düşünüyorum
  • Pasaport ve cinsel yönelim gibi hassas verilerle uğraşıyorsanız, en azından verileri sızdırdığınız söylendiğinde cevap vermeniz gerekir. Bu tam bir felaket ve burada güvenlik eksikliği kesinlikle kabul edilemez seviyede
  • Uygulama güvenliği hakkında hiçbir şey bilmiyorsanız, bence hiç uygulama yapmamalısınız. Biraz duygusal konuşacağım ama arkadaşlarımın flört uygulamaları kullandığını görünce bilgilerinin açığa çıkması düşüncesi korkunç geliyor. Bunu yapanlar utanmalı. Güvenlik araştırmacısının iletişim girişimine bile cevap vermemişler; bundan da utanmaları gerekir. Bana böyle davranılsaydı çok daha sert bir ifşa yazısı yazardım. Lütfen uygulama yapmayı bıraksınlar

• Bir geliştirici olarak küçük bir şirkette çalışırken kişisel sorumluluğum konusunda bazen endişeleniyorum. Birçok şirket PCI veya HIPAA gibi düzenlemelere tabi olmayan alanlarda faaliyet gösteriyor. Küçük organizasyonlarda güvenlik, tüm şirketin değil mühendisliğin sorunu gibi görülüyor. Ürün ekibi özelliklere, PM takvime, QA hatalara odaklanıyor; güvenlik konusunda ses çıkaran çok az kişi oluyor. Mühendisler de sadece kendilerine verilen işi yapmakla yetinsin beklentisi var. Mühendis güvenliği de sahiplenirse güzel, ama yaparsa PM vb. kişilerden tepki de görebiliyor. Ve hep şu laflar duyuluyor: "Bu ne kadar sürer?", "Bunun gerçekten olma ihtimali ne kadar?", "Önce MVP’yi hızlıca çıkaralım, sonra düzeltiriz" vb. Böyle olunca ben de çalışan olarak şirketin istediğini yapmış oluyorum. Ama şirket hacklenme veya sızıntı nedeniyle dava edildiğinde, sırf "daha iyi bilmesi gereken" mühendis ben olduğum için sorumluluk bana kalır mı diye sık sık düşünüyorum

  • Pratikte siz mühendis olduğunuz için değil, sertifikalara imza atıp güvenliği garanti eden kişi olmadığınız için, güvenli olmadığı ortaya çıksa bile sorumlu tutulmazsınız
  • Şirket bir LLC ya da Corp ise, "corporate veil" sizi korur. Kayıtlara geçmiş bir suç işlemediyseniz sorumluluğunuz olmaz. Yine de her ölçekte şirkette güvenlik standardı eksikliği büyük bir sorun. Yeni özellik çıkarmak güvenlikten hep daha önemli görülüyor
  • Küçük bir organizasyonda mühendis olarak, bu riskleri ekibe anlatmak ve güvenlik için geliştirme zamanı ayrılması konusunda güçlü şekilde ısrar etmek bizim sorumluluğumuz diye düşünüyorum. Kolay değil ama bunu ihmal etmek şirketin kendisini riske atabilir
  • Ben olsam kendimi koruyacak kadar hukuk öğrenir, yasa dışı taleplere yazılı olarak itiraz eder ve bunları görmezden gelmem yönünde verilen onayı da mutlaka yazılı alırdım. Ama küçük bir startup’ta bu bile zor olabilir. Yasal olmadığını hissedersem direkt istifa ederim
  • "Emirleri uyguluyordum" savunmasından hoşlanmıyorum ama böyle durumlarda mutlaka yazılı kayıt bırakmak iyi olur: güvenlikte sorun olduğunu e-postayla bildirmek ve yöneticinin "takılma, boş ver" dediğine dair kanıtı saklamak. Benim bildiğim kadarıyla giriş seviyesi çalışanların veri sızıntısı yüzünden hukuken sorumlu tutulduğu bir vaka görmedim. Genelde kimse sorumlu olmuyor, şirket sembolik bir ceza ödeyip geçiyor
  • Şirket yöneticisi değilseniz kişisel sorumluluğunuz olacağını sanmıyorum
  • Benim deneyimimde böyle bir şey olmadı

• Araştırmacının hukuki riskini azaltmak için, bence ek bir hesap açmak veya bir arkadaşın rızasıyla profil oluşturup erişim elde etmek yeterli olurdu. Verileri gerçekten çekmeye gerek yok; örneğin benim id’m 12345 ve arkadaşımın id’si 12357 ise, aradaki id’lerle başka hesapların profillerine erişilebildiğini göstermek mümkün. Başkalarının da dediği gibi, binlerce kişinin kişisel verisine erişmeye gerek yok; açığı kanıtlayıp açıklamak için daha sınırlı bir gösterim yeterli

  • Bu, bilgi güvenliği araştırmacılarının bildiği standart ve açık yaklaşım. Hassas bilgileri çekip kanıtlamak isteyebilirsiniz ama bu gereksizdir ve hatta ikiyüzlüce olur

• Bu yazının kendisi de epey kafa karıştırıcı geliyor. OTP’yi alan API’nin o kadar basit olduğu, OTP’nin doğrudan sunucu yanıtında döndüğü ve böylece sadece telefon numarasını bilen herkesin hesaba erişebildiği söyleniyor. API otp/telefonnumarası gibi görünüyor ve OTP yanıtın içinde geliyormuş; yani telefon numarasını tahmin edebilirseniz kodu da alıyorsunuz gibi. Sonra bir script ile kullanıcı ID’lerini sıralayıp arka arkaya 1.000 boş ID gelince duran bir yöntemle toplam 6.117 kullanıcı, 207 kimlik bilgisi ve 19 Yale öğrencisi tespit edildiği anlatılıyor. Ama bu kadarını, rıza olmadan başkalarının kişisel verilerine erişecek kadar ileri götürmek, geçmişte weev’in AT&T’yi hackleyip hapse girmesine benziyor. Ölçek küçük olsa bile bu tür araştırma hukuken riskli ve yazarın, güvenlik araştırmacılarını korumayan yasal ortamı yeterince ciddiye almadığından endişe ediyorum

  • API’nin otp/numara ile son OTP’yi doğrudan geri döndürdüğü kısmından söz ediliyor. Yani telefon numarasını tahmin eden kişi OTP’yi de hemen alabiliyor
  • Auernheimer davasındaki ilk iddianameyi okursanız, orada (bu olaydan farklı olarak) suç kastını kanıtlayan yeterli delil vardı. Ayrıca kişisel bilgileri gerçekten dışarıya açıkladıkları da iddia edilmişti; bu olay o kadar ileri gitmiş değil

• Ben de benzer bir şey yaşadım; başka bir flört uygulamasında bir açığı bildirmeye çalıştım ama kimseye ulaşamayınca kurucunun profilini "lütfen benimle iletişime geçin" diye değiştirdim, onlar da yedekten geri yükledi. Yıllar sonra Instagram reklamlarında aynı uygulamayı görünce tekrar denedim ve aynı açığın hâlâ durduğunu gördüm. Sadece API endpoint’lerini bilen biri admin yetkisine, tüm mesajlara ve eşleşmelere erişebiliyor. Tekrar iletişime geçmeli miyim diye düşünüyorum

  • Ulaşıp sorumlu bir geliştirici olduğunuzu belirtmenin ve sadece sorunu açıklayıp bırakmanın iyi olabileceği öneriliyor

• Pasaport veya adres gibi hassas veriler uygulamada toplanacaksa, bunun gerçekten iki kere düşünülmesi gerekir. "Bunu öğrenciler yaptı" deyip geçiştirilecek bir mesele değil

  • Birleşik Krallık hükümeti porno sitelerine erişim için kimlik zorunluluğu getirmeye çalışıyor; bunun nereye varacağını görmeyi bekliyorum
  • Pasaport gibi kimlik bilgileri girildiyse, bunların girişten sonra dışarıya açık şekilde görünmesi için hiçbir neden olmamalı. Kimlik verisini UI’da göstermek için bir API varsa, tüm numarayı döndürmek yerine son birkaç haneyi döndürmesi yeter. Flört uygulamasıysa, kimlik doğrulamasının yapılıp yapılmadığını bir boolean veya enum (doğrulanmadı/pasaport/ehliyet) olarak dönmek bile yeterli olur. Havayolu uygulamalarındaki gibi belirli bir kimliği seçmek gereken sistemler istisna olabilir ama örneğin United uygulamasının da sadece son birkaç haneyi göstermesi gibi, iç API’lerin de bu şekilde kısıtlanmasını isterim
  • GDPR’ye bakılması için bağlantı paylaşılıyor
  • Hatta devlet tarafından işletilen güvenli ve mahrem bir kimlik doğrulama hizmetine ihtiyaç olduğunu düşünüyorum. Ya da Apple ya da Google gibi "neredeyse devlet" rolündeki şirketler üstlenmeli
  • Mümkünse üçüncü taraf kimlik doğrulama hizmeti kullanmak daha yaygın, ama böyle hizmetler gerçekten kimlik görsellerini de uygulamaya veriyor mu merak ediyorum

• OTP’nin API yanıtında olduğu gibi geri döndürülmesi akıl almaz bir durum. Sebebini anlayamıyorum

  • UI’da girilen değerle anında karşılaştırabilmek için yapılmış. Güvenliği düşünmüyorsanız kulağa makul gelebilir. Flört uygulamaları gereken kişisel veri kapsamı açısından çok geniş olduğu için, böyle bir hata korkunç
  • Böylece veritabanı maliyetini tek hamlede azaltabilirsiniz
  • OTP üretildikten sonra DB veya cache yanıtını doğrudan döndürmek, POC ya da MVP aşamasında böyle bir modele kayınca kolayca gözden kaçabilir
  • Görünüşe göre OTP, "tek kullanımlık şifre gönderim isteği yanıtı" içinde aynen sızıyor. Bunun nedeni muhtemelen framework’ün tüm DB nesnesini serialize edip HTTP üzerinden döndürmesi olabilir
  • Bir HTTP isteğinden tasarruf ediliyor ve UX hızlanıyor, bu yüzden yüzeyde iyi görünebilir. Pinterest de geçmişte API’sinde 2FA secret dâhil her şeyi ifşa etmişti. Bildirmiştim ve ödül de almıştım; yani bu tür hatalar büyük teknoloji şirketlerinde bile bazen yaşanıyor
  • Ben de anlayamıyorum. Form oluşturmayı basitleştirme uğruna yapılmış bir hata gibi geliyor

• Yale Daily News’taki ilgili başka bir makalenin bağlantısı paylaşılıyor

• Kişisel verilerin nükleer atık kadar tehlikeli kabul edilmesini sağlayacak yasalar olsa keşke. Sızıntı durumunda şirketlerin iflas etmesi, sorumluların da hukuki kriz yaşaması gerekir diye düşünüyorum. Şu an kullanıcı verisi toplamak fazla kolay ve sızıntı olduğunda sadece özür dilenip yoluna devam ediliyor

  • PII’ı nükleer madde gibi ele almak biraz fazla olur. E-posta adresi gibi, sadece doğrulama/iletişim için kullanılan veriler o kadar büyük mesele değil
  • Beyaz yakalılar için de hapis tehdidi olsa ancak o zaman gerçekten ciddiye alınır gibi geliyor

• iOS’ta Charles Proxy diye bir araç olduğunu ancak şimdi öğrendim. Eskiden pentest yaparken doğrudan uygulama ikilisinin içinde string arardım. iOS’a özel uygulama analizinde gerçekten çok yardımcı olacak gibi

  • Güzel araçtır, tavsiye ederim (ama SSL pinning varsa işe yaramaz)