Dünya Kupası'nı Hacklemek: Bir Kimlik Kartı Yeterli mi?

Dev Organizasyon, Dev Hatalar

Selamlar, ben Alper. Bugün size bir yazılımcının kabuslarını süsleyecek, bir güvenlik araştırmacısının ise iştahını kabartacak gerçek bir hikayeden bahsedeceğim. Konumuz 2022 FIFA Dünya Kupası ve bu devasa organizasyonun dijital kalbi olan Hayya sistemi. Güvenlik araştırmacısı Sam Curry'nin paylaştığı bu hikaye, bize modern yazılım dünyasında "basit" görünen hataların ne kadar büyük sonuçlar doğurabileceğini bir kez daha hatırlatıyor.

Dünya Kupası gibi milyonlarca insanın katıldığı, milyarlarca doların döndüğü bir etkinlikte güvenlik önlemlerinin en üst seviyede olmasını beklersiniz, değil mi? Ancak Sam Curry'nin keşfettiği şey, tüm sistemi bir iskambil kağıdı gibi yıkabilecek kadar temel bir hataydı: IDOR (Insecure Direct Object Reference), yani Türkçesiyle Güvensiz Doğrudan Nesne Referansı.

Her Şey Nasıl Başladı?

Sam Curry, Katar'daki Dünya Kupası'na gitmeye karar verdiğinde her taraftar gibi "Hayya" uygulamasını indirmek ve dijital kimliğini oluşturmak zorundaydı. Bir yazılımcı refleksiyle, uygulama arka planda neler yapıyor, sunucuyla nasıl konuşuyor diye merak edip trafiği izlemeye (intercepting) başladı. Kullandığı araç muhtemelen birçoğunuzun bildiği Burp Suite idi.

Sisteme giriş yaptığında, profil bilgilerini getiren bir API (Uygulama Programlama Arayüzü) isteği fark etti. Bu istekte kullanıcının kimliğini belirten basit bir sayısal ID (kimlik numarası) bulunuyordu. Sam, kendi ID numarasını bir başkasınınkiyle değiştirdiğinde ne olacağını merak etti. Sonuç? Beklenenden çok daha vahimdi.

IDOR Nedir ve Neden Bu Kadar Tehlikelidir?

Burada teknik bir parantez açalım. IDOR, bir uygulamanın kullanıcıdan gelen girdiyle doğrudan veritabanı nesnelerine erişim izni vermesi durumudur. Örneğin, sizin profil sayfanız /api/user/123 adresindeyse ve siz 123 yerine 124 yazdığınızda başkasının profilini görebiliyorsanız, orada bir IDOR açığı vardır. Normalde sistemin "Bu kullanıcı gerçekten 124 numaralı veriyi görmeye yetkili mi?" diye kontrol etmesi (authorization/yetkilendirme) gerekir.

Hayya sisteminde bu kontrol tamamen unutulmuştu. Sam, sadece ID numarasını değiştirerek turnuvaya kayıtlı herhangi birinin pasaport bilgilerine, ev adresine, telefon numarasına ve hatta bilet detaylarına ulaşabiliyordu. Ancak iş burada bitmedi; Sam daha derine indi.

"Super Admin" Yetkilerine Giden Yol

Sam, sadece veri okumakla kalmayıp veriyi değiştirip değiştiremeyeceğini de test etti. API uç noktalarını (endpoints) kurcalarken, sistemin yönetici paneline ait bazı gizli fonksiyonları keşfetti. Şaşırtıcı bir şekilde, sıradan bir kullanıcı token'ı (erişim anahtarı) ile bu yönetici fonksiyonlarına istek atabiliyordu. Bu durum, yazılım dünyasında Privilege Escalation (Yetki Yükseltme) olarak adlandırılır.

Bu yetkiyle Sam, turnuvadaki herhangi birinin biletini iptal edebilir, koltuk numarasını değiştirebilir veya daha da ilginci, stadyum girişlerindeki dijital ekranlarda görünen bilgileri manipüle edebilirdi. İşte "Rickroll" hikayesi burada devreye giriyor.

Stadyumda Rickroll Yapmak

Rickroll, internet dünyasında birini beklemediği bir anda Rick Astley'nin "Never Gonna Give You Up" şarkısına yönlendirmekle yapılan popüler bir şakadır. Sam Curry, bulduğu bu açık sayesinde stadyum girişlerindeki kontrol noktalarında, taraftarların kimlik kartları okutulduğunda ekranda beliren fotoğrafı ve ismi merkezi olarak değiştirebileceğini fark etti.

Düşünsenize, binlerce taraftar stadyuma girmek için sıraya giriyor ve görevlinin ekranında her bir taraftarın yerine Rick Astley beliriyor! Bu sadece komik bir şaka değil, aynı zamanda tüm giriş sistemini kilitleyebilecek, büyük bir kaosa neden olabilecek bir durumdu. Neyse ki Sam bir Ethical Hacker (Etik Hacker) olduğu için bu durumu kötüye kullanmak yerine hemen yetkililere bildirdi.

Yazılımcılar İçin Çıkarılacak Dersler

Bu olaydan biz geliştiricilerin alması gereken çok önemli dersler var:

• Asla İstemciye Güvenmeyin: Kullanıcının gönderdiği ID veya parametre ne olursa olsun, sunucu tarafında her zaman yetki kontrolü yapmalısınız.
• API Güvenliğini Hafife Almayın: Modern uygulamalar tamamen API'lar üzerine kurulu. API uç noktalarınızı korumak, ön yüzü (frontend) korumaktan çok daha kritiktir.
• Savunma Derinliği (Defense in Depth): Güvenlik sadece bir katmanda olmamalı. Hem ağ seviyesinde, hem uygulama seviyesinde, hem de veritabanı seviyesinde kontroller bulunmalıdır.
• Hata Mesajları: Hata mesajlarında sistem hakkında çok fazla ipucu vermekten kaçının.

Sonuç olarak, milyonlarca dolarlık bütçeler ve binlerce kişilik ekipler bile bazen en temel güvenlik prensiplerini gözden kaçırabiliyor. Sam Curry'nin bu keşfi, sistemin turnuva başlamadan hemen önce yamalanmasını sağladı ve olası bir dijital felaketi önledi. Bir dahaki sefere bir API yazarken kendinize şu soruyu sorun: "Kullanıcı bu ID değerini değiştirirse ne olur?"

Güvenli kodlar yazmanız dileğiyle, bir sonraki yazıda görüşmek üzere!