- EA kimlik doğrulama ve gateway API’sindeki açığa çıkmış Swagger dokümanları ile persona güncelleme yetki doğrulamasındaki başarısızlık birleşince, diğer kullanıcıların hesap verileri ve hatta giriş akışları etkilenebiliyordu
- Kritik nokta,
/identity/pids/{pidId}/personas/{personaId}için yapılan PUT isteğine sıradan EA Desktop OAuth istemcisinindp.client.defaultkapsamıyla erişilebilmesi ve gövdedeki pidId ile yoldaki personaId için sahiplik kontrolünün yetersiz olmasıydı - Saldırganlar persona kullanıcı adı değiştirme,
BANNEDdurumuna alma, persona taşıma, gizli hesapların persona ID’lerini bulma ve Xbox persona tabanlı giriş atlatmayı birleştirerek hesapların web girişine kadar ulaşabiliyordu - Etki alanı; kullanıcı adı ve bazı oyun verilerinin ele geçirilmesi, çevrimiçi oyun erişiminin engellenmesi, oyun banlarının atlatılması ve Xbox üzerinden EA hesabına girişe kadar uzanıyordu; ciddiyet seviyesi CVSS 10.0 olarak değerlendirildi
- Açık 16 Haziran 2024’te EA’ye bildirildi; EA 25 Haziran’da bunu kritik olarak sınıflandırdı ve 8 Temmuz ile 8 Ekim arasında persona sahiplik kontrolü ve dokümanların kaldırılması dahil yamaları dağıttı
EA kimlik doğrulama ortamında başlayan API dokümanı sızıntısı
- Başlangıç noktası, EA Desktop’ta bulunan geliştirme ortamı integration testiydi
- Production kimlik doğrulama API’si
accounts.ea.com - integration kimlik doğrulama host’u
accounts.int.ea.com
- Production kimlik doğrulama API’si
- integration ortamında yetkili bir access token alınabildi ve bu token ile erişilebilen API’leri görmek için açığa çıkmış dokümanlar aranmaya başlandı
- Kimlik doğrulama uç noktaları reverse proxy arkasındaydı;
/connectyolu ile normal/yolunun 404 yanıt biçimi farklıydı veserverbaşlığıistio-envoyidi /connect/api-docs, diğer/connectyollarından farklı olarak boş bir 404 döndürdüğü için ayrı bir servis yönlendirmesi olabileceği düşünüldü ve/connect/api-docs/index.jsonüzerinde Swagger 1.1 dokümanı bulundu- Swagger dokümanı
/api-docs/connectadresini işaret ediyordu; bu dokümanswagger-codegen-cliile OpenAPI 3.0 tanımına dönüştürülüp yerel Swagger UI’da incelendi
Gateway’de ortaya çıkan dahili API listesi
- EA Desktop, “Service Aggregation Layer” adlı bir GraphQL API kullanıyor ancak integration ortamındaki SAL güvenlik duvarının arkasında bulunuyordu
- Eski bir sürüm gibi görünen
gateway.ea.comgateway API’si,proxy/{service}/{route}biçiminde uç noktalar kullanıyordu gateway.int.ea.com/proxy/api-docs/index.json, 80’den fazla servis dokümanı listesi döndürüyorduaddresses,agerequirements,billing,commercegibi çeşitli servisler dahildi
- Her API dokümanı indirildi, güncel OpenAPI tanımına dönüştürüldü ve erişilebilen işlevler incelendi
- Bazı uç noktalar EA oyun ekiplerine ait “projects” verilerini döndürüyordu; bunlar
basic.domaindatayetki kapsamı gerektiriyordu ve production’da bu kapsama sahip istemciler de bulundu- Örnek veriler arasında iptal edilmiş bir Star Wars oyunu ve Apex Legends’ın
Titanfall3ile ilişkili grup adıyla görünen girdileri vardı
- Örnek veriler arasında iptal edilmiş bir Star Wars oyunu ve Apex Legends’ın
- integration ortamında özel oyun entitlement’ları verme yöntemi de dokümante edilmişti, ancak indirme ve oynama için gereken integration servisleri güvenlik duvarı arkasında olduğundan pratik değeri düşüktü
- Xbox Live Server Token döndüren bir uç nokta da vardı, ancak sandbox ID
RETAILolmadığı için daha derine inilmedi
Production hesap bilgileri ve persona yapısı
- Dokümanlardaki her uç nokta gerekli kimlik doğrulama kapsamını gösteriyordu; inceleme, production OAuth istemcisiyle erişilebilen uç noktalara odaklandı
/identity/pids/me, hesabın genel bilgilerini döndürüyordu- Maskelemiş e-posta değeri, e-posta durumu, doğum tarihinin bir kısmı, ülke, dil, hesap durumu, sözleşme sürümü, oluşturulma/değiştirilme/son doğrulama zamanları ve 2FA etkinliği gibi bilgiler dahildi
/identity/pids/me/personas, hesaba bağlı persona listesini döndürüyordu- Varsayılan EA hesabı
cem_ea_idnamespace’ini kullanıyordu - Steam, Xbox gibi bağlı harici hesaplar da ayrı persona olarak görünüyordu
- Varsayılan EA hesabı
- Oyunlar genelde istatistik, envanter gibi verileri persona altında saklayabildiği için platform bazlı veriler ayrışabiliyordu
- Bundan sonra
cem_ea_idnamespace’indeki persona “Origin” persona olarak anıldı
Temel açık: persona güncellemede yetki doğrulamasının başarısız olması
/identity/pids/{pidId}/personas/{personaId}uç noktası GET, PUT ve DELETE istekleri alıyordu- PUT isteği
dp.client.defaultvedp.server.defaultkapsamlarını kabul ediyordu; sıradan EA Desktop kimlik doğrulama istemcisi dedp.client.defaultkapsamına sahipti - İstek gövdesi
displayName,namespaceName,status,statusReasonCode,lastAuthenticated,nickName,pidIdgibi alanları alabiliyordu - Kendi Origin persona’sı için
displayNamedeğiştiren PUT isteği başarılı oldu ve EA hesap sitesindeki kullanıcı adı değişti- Bu istek, kullanıcı adı değiştirme cooldown süresini ve kullanıcı adı değişikliği için e-posta doğrulamasını atlatıyordu
namespaceNamedeğişikliği etkisizdistatusiçinACTIVE,DISABLED,PENDING,DELETED,BANNEDdeğerleri mümkündü; kendi Origin persona durumunuBANNEDyapınca EA Desktop kullanılmaya devam etti ama oyun girişleri engellendi- Daha büyük sorun ise istek gövdesindeki pidId değerinin başka bir hesap ID’siyle değiştirilebilmesiydi
- Kendi Steam persona’sını bir arkadaşın EA hesabına taşıyan istek başarılı oldu
- Sonrasında bunu tekrar kendi hesabına döndürmek de mümkündü
Giriş doğrulaması ve XSS denemesi
- Kendi Steam persona’sı arkadaşın hesabına taşındıktan sonra Steam ile EA web sitesine giriş denenince, yeni konum/güvenilmeyen cihaz temelli e-posta doğrulaması çıktı
- Gösterilen bazı e-postalar kendisine ait değildi; yani arkadaş hesabına giriş akışına kadar ulaşılmıştı, ancak konum tabanlı 2FA adımında durduruldu
- Persona kullanıcı adını
BattleDash <script>alert(1)</script>biçiminde değiştiren istek de başarılı oldu - Hesap bağlantı sayfasında alert çalıştı ve XSS mümkün oldu
- Kullanıcı EA hesabında oturum açmış durumdayken bu bağlantı sayfasına yönlendirilirse, tarayıcıda kod çalıştırıp oturumu ele geçirmek mümkün olabiliyordu
Başka hesapların persona’larını doğrudan manipüle etme
- Yoldaki
personaIdiçin de sahiplik kontrolünün yetersiz olup olmadığını görmek amacıyla, sahip olunmayan bir persona ID üzerinde kullanıcı adı değiştirme denendi - Yeni bir test hesabının persona ID’si alındıktan sonra, mağdur hesabın kimlik doğrulaması olmadan o hesabın kullanıcı adını değiştiren istek başarılı oldu
- Aynı yöntemle
statusdeğeriBANNEDyapılabildi ve ilgili hesap artık oyunlara giriş yapamaz hale geldi /identity/personas,displayNameile persona arıyor ve persona ID, hesap ID’si, oluşturulma tarihi ile son giriş zamanını döndürüyordu- Ancak hesabını gizleyen kullanıcılar sonuçlarda görünmüyordu
/identity/namespaces/{namespace}/personas, belirli bir namespace içinde arama yapıyor; yalnızca kullanıcı adı ve persona ID döndürüyor ama gizli hesapları da listeliyordu- Gerekli persona ID’yi elde etmek için yalnızca bu uç nokta bile yeterliydi
Persona taşımanın kısıtları ve kısmi hesap ele geçirme
- Başka bir kullanıcının Origin persona’sını kendi hesabına taşımaya çalışınca
TOO_MANY_PERSONAS_FOR_NAMESPACEhatası alındı- Bunun nedeni kendi hesabında zaten bir Origin persona bulunmasıydı
- Konsol üzerinden oluşturulan hesaplarda yalnızca o platformun persona’sı bulunabileceği ve Origin persona olmayabileceği düşünülerek namespace çakışması konsol hesabıyla aşıldı
- Test hesabının Origin persona’sını konsol hesabına taşıdıktan sonra, mağdur hesabın Origin persona’sını kendi hesabına taşıma yöntemi işe yaradı
- Bu durumda giriş yapıldığında mağdurun kullanıcı adı, platformlar arası olmayan oyun istatistikleri ve bazı diğer hesap ayrıntıları görülebiliyordu
- Mağdur hesabıyla giriş yapıldığında, yeni hesap açılmış gibi kullanıcı adı seçtiren “Finish setting up my account” akışı çıkıyordu
- Battlefield 2042 gibi modern çapraz platform oyunlarının entitlement, arkadaş listesi ve kayıt verileri persona’da değil doğrudan EA hesabında tutulduğu için taşınmıyordu
- Buna rağmen saldırgan; kullanıcı banı, oyun banı atlatma, kullanıcı adı ele geçirme ve hesap verisini rehin alma gibi eylemler gerçekleştirebiliyordu
Xbox persona ile giriş atlatma
- Bu aşamadaki mümkün işlemler; kendi linked account persona’sını istenen bir EA hesabına taşımak, istenen bir persona’yı kendi hesabına taşımak, persona’yı banlamak ve kullanıcı adını değiştirmekti
- Kendi persona’sını başka bir kullanıcının hesabına taşıyarak o hesaba giriş denenince e-posta doğrulaması çıkıyordu
- Konsolda EA oyunu oynarken hiç 2FA istemi görülmemiş olmasından yola çıkılarak Xbox/PSN token tabanlı giriş incelendi
- Nexus Connect API dokümanlarında Xbox/PSN token iletme yöntemi vardı ve EA sitesindeki PSN giriş akışından PSN client ID alınarak PSN token ile giriş denendi
- PSN token ile giriş,
ps3namespace’inde bir persona oluşturuyor ve 2FA olmadan hesap girişine izin veriyordu, ancakdp.client.defaultkapsamına sahip istemcilerps3namespace’iyle çalışamıyordu /connect/tokeninfoisteğineX-Include-Namespacebaşlığı eklenince, her OAuth istemcisi için manipüle edilebilen persona namespace listesi olduğu görüldü- Örneğin
JUNO_PC_CLIENT,cem_ea_id,steam,epic,xboxnamespace’lerini içeriyordu
- Örneğin
- Xbox namespace’i izinliydi ancak elle geçerli bir Microsoft XSTS token üretilemediği için test gerçek Xbox üzerinde yapıldı
- Yeni bir Microsoft hesabı oluşturulup onun Xbox persona’sı test EA hesabına bağlandı; ardından bu Xbox persona mağdur hesaba taşındı
- EA web sitesinde Xbox hesabıyla giriş yapınca yeni konum e-posta doğrulaması çıktı; ancak Xbox’a Battlefield 2042 kurulup oyuna giriş yapıldığında mağdur hesaba erişildi
- Sonrasında aynı Xbox hesabıyla EA web sitesine tekrar giriş yapıldığında, e-posta doğrulaması olmadan mağdur hesabın web oturumu da açılabildi
Etki alanı ve ciddiyet
- Saldırganın kullanabileceği iki ana yol vardı
- Başkasının persona verisini hesap dışına taşıyarak kullanıcı adı ve oyun verilerini ele geçirmek
- Kendi Xbox persona’sını mağdur hesaba taşıyıp Xbox’ta EA oyununa giriş yaptıktan sonra, ağ güvenilir kabul edilince Xbox hesabıyla EA web sitesine giriş yapmak
- Ek etkiler de büyüktü
- Başkasının persona’sını banlayarak çoğu çevrimiçi oyuna erişimini engellemek mümkündü
- Başkasının kullanıcı adı değiştirilip ardından o adın alınması mümkündü
- Oyun banları, hesap genelindeki oyun entitlement’larının devre dışı bırakılması şeklinde uygulandığı için persona yeni hesaba taşınarak ban atlatılabiliyordu
- Bu akış, kullanıcı etkileşimi gerekmeksizin çoğunlukla tek bir API uç noktası üzerinden mümkün oluyordu
- Ciddiyet,
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hmetriğine göre CVSS 10.0 olarak değerlendirildi
Düzeltme takvimi ve sonraki değerlendirmeler
- Açık 16 Haziran 2024’te EA’ye bildirildi
- EA, 25 Haziran 2024’te teyit gönderdi ve kritik önem seviyesi verdi
- Yama takvimi şöyleydi
- 8 Temmuz 2024: Patch 1 dağıtıldı, persona ownership check
- 18 Temmuz 2024: Patch 2 dağıtıldı, ayrıntılar bilinmiyor
- 6 Eylül 2024: Patch 3 dağıtıldı, ayrıntılar bilinmiyor
- 10 Eylül 2024: Patch 4 dağıtıldı, dokümanlar kaldırıldı
- 8 Ekim 2024: Patch 5 dağıtıldı, ayrıntılar bilinmiyor
- EA’nin ilk tahmini, düzeltmenin yıl sonuna kadar sürebileceği yönündeydi; açığa çıkmış dokümanlar ve tek bir güvensiz uç noktanın merkezde olduğu bir olayda daha hızlı geçici yama tercih edilmeliydi değerlendirmesi yapıldı
- EA’nin hâlâ bir bug bounty programı bulunmuyor ve somut bir bildirim ödülü olmaması, bazı kişilerin açıkları gizli tutmayı tercih etmesine yol açabileceği endişesini doğuruyor
- İlk testlerde kullanılan arkadaş hesabı izinli bir hesaptı
1 yorum
Hacker News yorumları
EA, birçok oyunda ortak sistemler kullanmayı seviyor. Madden’ı kurcalarken
blazeadında ortak bir arka uç olduğunu ve genel amaçlı web/TCP uç noktaları bulunduğunu keşfettim.Bu uç noktayı çağıran bir araç yaptım; XML yüklemek gerekiyordu ve sonradan anladım ki her çağrıda EA sunucusu ölüyormuş.
Her istekte yeni bir sunucu ayırdığı için Madden sunucularını tek tek çökertiyordum; sonunda EA, insanların kurcalamasını engellemek için bir API yaptı.
Hatırladığım kadarıyla her 5 bin ila 10 bin oyuncu için yaklaşık bir Blaze instance’ı gerekiyordu.
Şu anda özel bir format kullanıyorlar ve kimsenin arayüzün nasıl çalıştığını çözemeyeceğini varsayan bir güvenlik yaklaşımına, yani belirsizliğe dayalı güvenliğe epey yaslanmış görünüyorlardı.
Bir gün o yazıya geri dönmek istiyorum; en azından oldukça ilginç şeyler var.
Böyle bilinen servislerin API’lerini tersine mühendislikle incelerken bir ipucu: GitHub code search kullanın. Benzersiz bir uç nokta adını aratınca, kendi küçük API istemcisini hackleyip yazmış benzer insanlara sıkça rastlanıyor ve bu, hiç beklemediğim şekillerde araştırmama yardımcı oluyor.
namespacenamedeğeri döndürülüyor. 2FA token bilgisi JUNO’dan alınan/tokeninfo/uç noktasında hash’lenmeli.Sonradan entegrasyon denenince C++ API altyapısı çoğu zaman PSN kullanıcı ID’sini döndürüyordu.
Normal bir insanın elbette yapacağı gibi, ertesi gün teslim Xbox sipariş ettim, Battlefield 2042 kurdum ve kritik anı bekledim; içeri girebildim.
Hacker’lar gerçekten harika <3
Bir noktadan diğerine nasıl ilerlediklerinin ayrıntılı akışı ilginçti. Muhtemelen blog yazısındaki kadar temiz ve doğrusal olmamıştır.
Böyle bir saldırının gerçekte ne kadar zaman ve emek istediğini göstermek için muhtemelen dağ gibi not vardır; onları görmek de ilginç olurdu.
Tüm bunlardaki en tuhaf şey, EA’nın yıllardır mevcut Xbox hesabı bağlantısını kaldırıp yeni bir hesapla yeniden bağlamanın teknik olarak imkânsız olduğunu iddia etmesiydi. https://www.reddit.com/r/XboxGamePass/comments/12gsy4i/ea_xb... gibi yazılara ve EA forumlarındaki sayısız gönderiye bakabilirsiniz.
Ben de bu duvara çarptım; EA destekle saatlerce konuştum ama çok eski Xbox hesabımı bağlayamadılar. Bu yüzden Xbox’ta hiçbir EA oyununa giriş yapamıyor, platformda çoğunu oynayamaz hale geliyordum.
Oysa burada bunun gayet mümkün olduğu ortaya çıkıyor.
Garip şekilde benim hesabım çok uzun sürdü; 1-2 yıl boyunca destek ekibine birkaç kez e-posta attım ama her seferinde hesapları mümkün olduğunca hızlı yükselttiklerini, ancak işin çok büyük olduğu için yıllar süreceğini söylediler.
Sonra bir forumda hesabı kısa süreliğine kapatıp tekrar açarsanız 25 MB’a çıkarabileceğinize dair bir hile gördüm; ama bu vaat edilen 250 MB değildi.
Eski hesaplar 2-4 MB, yeni hesaplar 25 MB, 250 MB’a kadar yıllar sürecek dağıtım derken Microsoft’un boş depolama alanı bulmakta inanılmaz zorlandığı izlenimi oluşmuştu. Ama birkaç ay sonra Gmail ile rekabet etmeleri gerekince herkese 2 GB vermeye karar verdiler ve benim hesabım dahil tüm Hotmail hesaplarına tek seferde dağıtıldı. Uzaylılar kesin hard disk dolu bir UFO getirmiş olmalı.
[1] O hileyle ilgili eski bir forum yazısı örneği; yeni çıkan GMail’i öven bir yanıt da var: https://bimmersport.co.nz/topic/5232-hotmail-upgrade-2mb-to-...
Bağlantı değişikliği faturalandırma sisteminde tutulan verileri geçersiz kılabilir, Microsoft Xbox birimine giden aylık raporları bozabilir ya da dahili yönetici sayfasının yüklenirken çökmesine neden olabilir.
EA’yı savunmaya çalışmıyorum ama karmaşık mikroservis sistemleriyle çok uğraşınca, bir yerdeki veri yapısını değiştirmenin her zaman basit olmadığını görüyorsunuz.
Tüm hesapları banlayıp DB yedeği olmamasını ummak da eğlenceli olabilirdi
Para ödeyen bir müşteri olarak bu şirketlerden daha iyi bir tutum beklerim; bir programları yoksa, hacker’ların bulduklarını istismar etmesini şahsen kınamam
400 milyon kaydı tek bir makinede tutan kimse yoktur; sonuçta tek yapacağın hizmeti bütün öğleden sonra kapalı bırakmak ve federal hapiste 15 yıl geçirmek olur
Milyonlarca insana zarar verip iş yaptıkları şirkete ders vermenin “eğlenceli olacağı” düşüncesinin ilk tepki, en azından şu anda en yüksek puanlı yorum olması yüzünden
Yazıda şöyle bir bölüm var:
I had found a way to obtain a privileged access token within the environment (a story for another day, but a certain game's executable had hardcoded credentials!), but I wasn't sure what I could do with it.Bunu biraz daha açıklayabilir misin? Çalıştırılabilir binary’den böyle kimlik bilgilerinin kolayca okunamaması gerektiğini düşünürdüm; ayrıca bir oyun çalıştırılabilir dosyasının uzak sunucuya kendini doğrulaması gerekiyorsa geliştiricinin başka ne yapması gerektiğini de pek bilmiyorum
İstemci-sunucu mimarisinde istemciye asla güvenilemez. Çalıştırılabilir dosyanın sunucuya kendini doğrulamasına gerek olmamalı. Çalıştırılabilir dosya, kullanıcının sağladığı bilgilerle kullanıcı ya da hesap olarak doğrulanmalı
Telemetri gibi durumlarda bu tür endpoint’ler genellikle kimlik doğrulaması olmayan ya da zayıf kimlik doğrulamalı verileri kabul eder ve kötüye kullanımı önlemek için birden fazla doğrulama katmanı uygular. Çoğu zaman yalnızca yazma/ekleme amaçlıdırlar
Çalıştırılabilir dosyayı şifreleyen ve CPU kalıbındaki güvenli bir alanın özel anahtarla şifre çözmeyi yaptığı bir sisteme ihtiyacın olurdu; yine de birinin çipi delid edip anahtarı alması muhtemelen an meselesi olur
Şifreleyip şifreleme anahtarını HSM’e koysan bile, rastgele bir istemci makinede bu muhtemelen mümkün değildir; ayrıca bir noktada oyunun o string’in şifresini çözüp belleğe koyması gerekir. O bellek de okunabilir
Oyun geliştiricisinin yapması gereken şey, backend’de bir hesap sistemi bulundurup oyuncunun oyun içinde kendi kimlik bilgilerini girmesini sağlamaktır. Böylece oyun, backend sunucusuna kendini bu oyuncu olarak tanıtabilir
Bu sayede backend’deki eylemleri belirli bir oyuncuya atfedebilir ve güvenlik kararları almak için iyi bir temel oluşturabilirsin
IDA gibi araçlar var; string gibi görünen her şeyin arasında çıplak gözle kimlik bilgisi aramıyorsun
Sorun, binary’ye hardcode edilmiş kimlik bilgileri olmasından ziyade, bu kimlik bilgilerinin ayrıcalıklı yetkilere sahip olması
Böyle bir şirkette mühendis olarak, özel API’lerin, tuhaf bug’ların ve kirli iç işlerin herkese açık bir ihlal raporunda ortaya dökülmesi nasıl hissettirir diye bazen merak ediyorum
Gerçi böyle bir durumda tek bir kişinin zafiyetten sorumlu olması pek olası değil. Muhtemelen istismar edilen farklı parçaların sahibi 5-6 ekipti; exploit’in en başta var olmasının nedeni de buydu. Herkesin yalnızca kendi küçük parçasını anladığı devasa ve karmaşık bir sistem sonuçta
EA ölçeğinde bir şirkette bu olay neredeyse kesinlikle şirket içi siyasette kullanılacaktır; şirketin geneline zarar verse bile insanlar bunu, küçülen bir şirket üzerinde daha fazla kontrol elde etmek için kullanacaktır
Herkes değiştirilebilir bir kaynakken, neden işe duygusal yatırım yapılsın ki
O zamanki ekibin adı Nucleus’tu; bu yüzden yazıdaki yanıtlardan birinde
refTypedeğeriNUCLEUSidi. Bu ekip yetkilendirme, hesaplar ve ödemeler için backend API’leri geliştirip yönetiyorduYaz stajıydı; bir yıl sonra o ekipten teklif alıp çalışmaya başladım. O sırada ekibin adı EADP olarak değişmişti ve yavaş yavaş Origin ile birleşiyordu. DP’nin Data Platform olup olmadığını belli belirsiz hatırlıyorum; endpoint’lerden birinin
dp.ile başlaması da bu yüzdenO zamanlar GraphQL veritabanı yoktu; her şey Enterprise Java, OCI, Spring, Hibernate vb. idi ve ayrılmadan önce daha yeni Groovy/SpringBoot’tan da biraz vardı. Bulutta değil, veri merkezi sunucularında çalışıyordu
Yine de keyifli işler yaptım; büyük bir olay patladıktan 2-3 yıl sonra ayrıldım ama iyi mühendislerden backend geliştirme konusunda çok şey öğrendim
Şu an ekibin nasıl olduğunu, mühendislerin kimler olduğunu ya da neler yaşandığını hiç bilmiyorum ama böyle şeyleri görmek üzücü. O dönemde güvenlik konusunda çok bilinçliydik; giriş sayfasına yönelik brute force denemelerini tespit edip ele alan sistemler üzerinde de çalışmıştık
Hâlâ aktif mi, çalışıyor mu bilmiyorum ama ihlal olasılığını ve saldırı yüzeyini azaltmaya yönelik güvenlik kontrolleri/incelemeleri sprint çalışmalarının parçasıydı
Bu yazıyı keyifle okuduysanız HackerOne’ın Hacktivity gibi bug bounty platformlarında daha fazlasını görebilirsiniz: https://hackerone.com/hacktivity
Birkaç haftada ya da birkaç ayda bir güncelleniyor
Bug bounty programı kurmaya yönelik en iyi uygulamalar rehberi bir yerlerde var mı?
Web sitesinin bir yerinde, koordine edilmiş güvenlik açığı açıklama sürecine uyulması şartıyla teknik güvenlik kontrolleri yapılabileceğini yayımlayıp, hangi kapsamdaki hangi hatalar için hangi ödüllerin verileceğini yazmak yeterli. Elbette bu tek cümleden biraz daha ayrıntılı hale getirmek gerekir
Yaşın çok küçük ya da çok büyük olması halinde ödeme yapılmayacağı ya da yanlış ülkede doğup yaptırım kapsamına giriliyorsa uygun olunmayacağı gibi istisnaları da sonradan kırgınlık yaşanmaması için önceden yazmak iyi olur
Belirli sorularınız varsa yanıtlayabilir ya da iyi referanslar bulmaya çalışabilirim
Yazının şu kısmına bakınca:
It's also disappointing that EA has yet to start a bug bounty program. Without any real incentive to report vulnerabilities, I know people who have instead chosen to keep them to themselves. I would love to see EA follow the rest of the industry's lead here.Yani yazar bunu bildirdi ve hiçbir şey alamadı mı?
Bildirmenin hukuki riski var; teknik olarak şirketin sonuna kadar dava açabilecek olması da yardımcı olmuyor. EU/UK için söylüyorum