Açık bir Kibana, native.org'un alım-satım yığınını açığa çıkardı

Eşgüdümlü açıklama, iyi niyetle ve herhangi bir ödül ya da ödeme söz konusu olmadan bildirildi. native.org sorunu giderdi ve bu yazının yayımlanmasını onayladı. Etkilenen ana makinenin adresi açıklanmıyor.

Özet

• 207açığa çıkan dizin deseni
• 21kurtarılan canlı API anahtarı
• 8.700+her 15 dakikada günlük kaydı

native.org’un bir Kibana örneği, şirketin alım-satım altyapısını staging ve UAT genelinde, toplam 207 dizin deseniyle indeksliyordu ve arkasındaki API ağ geçidi (API gateway), canlı API anahtarlarını düz metin olarak günlüğe yazıyordu.

native.org bir DeFi likidite platformudur. Zincir üstü (on-chain) RFQ sistemi, özel piyasa yapıcılardan teklif alır ve bunları çeşitli zincirlerdeki yatırımcılara sunar; ortaya çıkan akış ise merkezi borsalarda hedge edilir. Açığa çıkan örnek bir UAT ortamının parçasıydı. native.org, sızan anahtarların hiçbirinin üretimde (production) kullanılmadığını doğruladı, örneğe kimlik doğrulama ekledi ve anahtarları döndürdü.

Açık Kibana örnekleri yaygındır. Burada daha fazla dikkati hak eden iki şey var: açık bir gözlemlenebilirlik (observability) yığınının neyi ele verdiği ve anahtar sızıntısının ardındaki hatanın ne kadar sıradan olduğu.

Önemli noktalar

• Örnek hiçbir kimlik doğrulama gerektirmiyordu. Kibana arayüzü yükleniyor, her dizin sorgulanabiliyor ve kaydedilmiş nesneler listelenebiliyordu, hepsi sıfır kimlik bilgisiyle.
• 207 dizin adı, tüm operasyonun bir haritasıydı: fiyatlandırma, hedge, risk, tasfiye, takas, zincir üstü izleme, merkezi borsa entegrasyonu, zincirler arası sabitlemeler (peg) ve acil durdurma kontrolleri. Tek bir belge açmadan mimariyi okuyabilirdiniz.
• API ağ geçidi, ham API anahtarlarını çıktısına yazıyordu ve bu da Elasticsearch’e akıyordu. Canlı günlük akışından 21 anahtar kurtardık. O sırada bir dizin her 15 dakikada 8.700’den fazla günlük kaydı alıyordu, dolayısıyla sistem açıkça çalışır durumdaydı.

Açık bir panonun ele verdikleri

Dizin adları, bir tehdit yüzeyi değil, operasyonel tesisat olmalıdır. Her hizmetin eksiksiz ve adlandırılmış bir listesi, bir saldırgana sistemin tam olarak nasıl kurulduğunu söyler. native.org örneğinde adlar, alım-satım yığınını baştan sona betimliyordu: sipariş akışı için quote-order-task ve order-manager, fiyatlandırma için pricer ve quote-ticker, risk için risk-manager ve liquidation-price-task, hedge için trade-hedger-task ve hedge-signer, merkezi borsa entegrasyonu için cex-monitor ve cex-position-monitor, takas için settlement, çeşitli zincirlerde yumuşak sabitleme (soft-peg) görevleri ve acil durdurma anahtarları için emergency-stop-task ile emergency-paused-task.

Bunların hiçbiri bir belge ya da kimlik bilgisi gerektirmedi. Dizin adları listesinin kendisi, başlı başına bir tasarım incelemesidir. Bir saldırı planlayan biri için bu, ön çalışmanın büyük kısmının çoktan yapılmış olması demektir.

Sızıntı mimarinin ötesine geçer. Aynı adlar stratejiyi de heceler: arbitraj, çift işlemi (pair trading), piyasa etkisi tahmini ve zincirler arası sabitleme için dizinler, firmanın nasıl para kazanmaya çalıştığını bir rakibe söyler; çoğu zaman daha değerli olan yarısı budur. Küme yalnızca alım-satım verisi de içermiyordu. Firmanın kendi güvenlik telemetrisini de barındırıyordu: ana makine, ağ ve uç nokta denetim günlükleri ve bir davetsiz misafiri yakalamak için tasarlanmış uyarılar. Bunu okuyan biri, savunucuların neyi tespit edip neyi edemeyeceğini görebilir.

Daha küçük operasyonel ayrıntılar bile adlandırma yoluyla sızar: barındırma bölgesi, bulut sağlayıcısı, yeni bir dile yarı yarıya yeniden yazılmış bileşenler ve kullanımdaki iç protokoller. Bunlardan herhangi biri tek başına önemsizdir. Birlikte ise, saldırgana aksi halde kendisinin yapması gereken keşfi elden teslim ederler.

Adların kendisi gayet iyi. Herhangi bir ekibin kullanacağı türden açık ve makul bir adlandırma. Yanlış giden şey, içinde yaşadıkları panonun herkese açık olmasıydı.

Günlüklerdeki anahtarlar

Daha doğrudan olan sorun, API ağ geçidi günlüklerindeydi. Ağ geçidinin anahtar arama işlevi, her başarılı aramada anahtar nesnesinin tamamını günlüğe yazıyordu ve bu günlük satırları her şey gibi Elasticsearch’e düşüyordu. Ağ geçidi dizinini açıp o işleve göre filtrelemek, şuna benzer bir kayıt akışı döndürüyordu:

[refreshApiKey] auth.GetByApiKey success, apiKey:
{"id": 9, "api_key": "faa79a…362f1f", "name": "[redacted]", "rate_limit": 20}

Bu yolla 21 farklı anahtar kurtardık. Bu, var olan en yaygın günlükleme hatalarından biridir: hata ayıklama sırasında tüm isteği ya da kimlik doğrulama nesnesini günlüğe yazmak, sonra da bunun başka birinin okuyabileceği bir depoya gittiğini unutmak. Kimlik bilgisi ile günlüklerinizi sakladığınız yer aynı şey hâline gelir.

Etkisi, orantılı biçimde

Bu bir UAT ortamıydı ve native.org anahtarların üretimde kullanılmadığını doğruladı. Bu önemlidir ve bunu canlı bir alım-satım masasında kıl payı atlatılmış bir olay gibi süslemeyeceğiz. Öyle değildi.

Yine de ciddiydi. Kimlik doğrulaması olmayan, internete açık ve çalışır durumdaki bir örnek, gerçek kimlik bilgilerini düz metin olarak günlüğe yazıyor ve para yöneten bir platformun tüm tasarımını açığa çıkarıyordu. Anahtarlar UAT anahtarlarıydı, ama dizin birkaç dakikada bir binlerce günlük satırı alıyordu, dolayısıyla trafik gerçekti ve açığa çıkardığı mimari, üretim sisteminin çalıştırdığı mimarinin ta kendisidir. “Sadece UAT” ile “herkese açık internette, canlı anahtarları günlüğe yazıyor” arasındaki boşluk, hikâyenin tamamıdır.

Kavram kanıtı (PoC)

Örnek, HTTP bağlantı noktasında kimlik doğrulamasız isteklere yanıt veriyordu. Bunu doğrulamak üç adım aldı ve hiçbiri curl ya da bir tarayıcıdan daha egzotik bir araç gerektirmedi:

• GET /api/status, kimlik bilgisi olmadan Kibana sürümünü ve düğüm adını döndürdü.
• GET /api/saved_objects/_find?type=index-pattern&per_page=500, 207 dizin deseninin tamamını döndürdü.
• Ağ geçidi dizinini Discover’da açıp anahtar arama işlevine göre filtrelemek, günlüğe yazılmış anahtarları gösterdi.

Ana makinenin 443 bağlantı noktasındaki bir TLS sertifikası (CN=*.native.org, Cloudflare Origin CA tarafından verilmiş), örneğin native.org’a ait olduğunu doğruladı.

Açıklama zaman çizelgesi

• 2 Haziran 2026Açığa çıkan örneği tehdit istihbaratı araştırması sırasında bulduk ve etkilenen uç nokta, dizin listesi, günlüğe yazılan anahtarların düzenlenmiş bir örneği ve giderme adımlarıyla birlikte native.org'a bildirdik.
• 18 Haziran 2026native.org açığa çıkmayı doğruladı. Örneğe kimlik doğrulama eklediler, etkilenen anahtarları döndürdüler, örnek ve anahtarların hiçbir üretim anahtarı içermeyen bir UAT ortamına ait olduğunu doğruladılar ve yayım için istedikleri düzenlemeleri belirttiler.
• 19 Haziran 2026native.org'un katkısıyla, istedikleri düzenlemeleri uygulayarak yayımlandı.

native.org hızlı yanıt verdi, sorunu giderdi ve yazı üzerinde bizimle çalıştı. Bunu, karşılığında bir şey için değil, açığa çıkma ciddi olduğu ve bilmeleri gerektiği için bildirdik. Eşgüdümlü açıklama tam olarak böyle işlemelidir.

Aynı yığını çalıştıran ekipler için

• Kibana ve Elasticsearch’ü kimlik doğrulamanın arkasına alın. xpack.security.enabled özelliğini etkinleştirin ve HTTP bağlantı noktasını herkese açık internetin dışında tutun. Kimlik doğrulaması olmayan bir ELK yığını, web arayüzü dünyaya açık bir veritabanıdır.
• Günlük deponuzu, ona erişebilen herkesin okuyabileceği bir şey olarak görün. Bir kimlik bilgisi bir günlük satırına düşebiliyorsa, okunacağını varsayın.
• Kimlik doğrulama ya da istek nesnelerinin tamamını günlüğe yazmayın. Bir tanımlayıcı yazın, sırrı asla. Anahtar arama yolu, tam da bunun yanlış gittiği yerdir.
• Dizin ve hizmet adlarınızın sisteminizi betimlediğini unutmayın. İçinde yaşadıkları yeri özel tutun.
• Eski ortamlarınızı envantere alın. Buradaki adlar uat-v1, uat-v2, staging ve shadow gibi etiketler taşıyordu; zamanla birikmiş test kurulumu katmanları. Sonunda herkese açık hâle gelen, genellikle unutulanıdır.

Teşekkür

Hızlı ve profesyonel yanıtı için ve bu rapora neyin girip neyin giremeyeceği üzerinde bizimle çalıştığı için native.org ekibine teşekkür ederiz.