Pumpplatformu Güvenlik Olayı Analizi

Son günlerde, Pump platformunda ciddi bir güvenlik olayı meydana geldi ve bu durum çok sayıda kullanıcının fonlarının zarar görmesine neden oldu. Bu makalede, bu olayın nedenleri ve sonuçları derinlemesine incelenecektir.

Saldırı Süreci

Saldırgan, olağanüstü bir hacker değil, muhtemelen Pump platformunun eski bir çalışanıdır. Pump'ın belirli bir DEX'te token ticaret çiftleri oluşturmak için kullandığı yetkili cüzdanın kontrolüne sahiptir, buna "mağdur hesap" diyoruz. Pump'ta henüz belirli bir DEX standartlarına ulaşmamış tüm Bonding Curve LP havuzlarına ise "hazırlık hesap" diyoruz.

Saldırgan öncelikle bir borç verme platformundan bir miktar anında kredi aldı ve bu krediyi, listeleme standartlarına ulaşmayan tüm token havuzlarını doldurmak için kullandı. Normalde, havuz listeleme standartlarına ulaştığında, "hazırlık hesabı"ndaki SOL, "mağdur hesabına" aktarılmalıdır. Ancak saldırgan bu noktada aktarılan SOL'u çekti ve bu yüzden zamanında listelenmesi gereken ve kilitlenmesi gereken token'lar listeye alınamadı.

Mağdur Analizi

Analizlere göre, mağdurlar esas olarak saldırı gerçekleşmeden önce Pump platformunda henüz havuzda doldurulmamış tokenleri satın alan kullanıcılardır. Onların SOL'leri yukarıda belirtilen saldırı yöntemiyle alındı. Bu, erken dönemde kayıpların 80 milyon dolara kadar çıkabileceği tahmininin nedenini de açıklıyor (son veriler, gerçek kaybın yaklaşık 2 milyon dolar olduğunu gösteriyor).

Dikkate değer olan, belirli bir DEX'te listelenmiş olan tokenlerin LP'lerinin kilitlenmiş olması nedeniyle bu saldırıdan etkilenmemesi gerektiğidir.

Saldırganın Kimliğini Tahmin Etme

Saldırganın "mağdur hesabı"nın özel anahtarına sahip olması, platformun yetki yönetiminde önemli bir ihmal olduğunu şüphesiz ortaya koyuyor. Token havuzunu doldurmanın, saldırganın daha önceki görevlerinden biri olduğunu tahmin edebiliriz.

Diğer platformların uygulamalarına benzer şekilde, Pump muhtemelen soğuk başlatma gerçekleştirmek için bu çalışanın proje fonlarını yeni çıkarılan token havuzunu doldurmakla görevlendirdi (muhtemelen çoğunlukla kendi çıkardığı test tokenları), böylece bu tokenlar borsa listesine alınabilsin ve heyecan yaratabilsin. Ancak bu, sonunda iç tehditlerin bir kırılma noktası haline geldi.

Deneyimler ve Öğretiler

1. Benzer projeler için sadece yüzeysel taklit yeterli değildir. Kullanıcıları işlem yapmaya çekmek için başlangıç itici gücü sağlamak gerekmektedir.

2. Proje tarafı, yetki yönetimi ve güvenlik önlemlerine büyük önem vermelidir. Yetkilerin makul bir şekilde dağıtılması, düzenli denetim yapılması ve iç risklerin önlenmesi son derece önemlidir.

3. Kullanıcılar, özellikle tam olarak doldurulmamış veya ana borsa üzerinde listelenmemiş token işlemleriyle ilgili olarak yeni platformlara katılırken dikkatli olmalıdır.

4. Proje tarafı, tek nokta arıza riskini azaltmak için çoklu imza, yetki seviyeleri gibi kapsamlı bir risk yönetim mekanizması kurmalıdır.

5. Güvenlik denetimleri ve penetrasyon testleri düzenli olarak yapılmalı, potansiyel açıklar zamanında tespit edilmeli ve düzeltilmelidir.

6. Çalışan eğitimi ve etik eğitimi güçlendirilmeli, sağlıklı bir kurumsal kültür oluşturulmalı ve iç tehdit riskleri azaltılmalıdır.

Bu olay, hızlı gelişen kripto para sektöründe güvenliğin her zaman birinci öncelik olduğunu bir kez daha hatırlatıyor. Hem proje sahipleri hem de kullanıcılar, her zaman tetikte olmalı ve gerekli güvenlik önlemlerini almalıdır.