Çözüldü ÇakmaLobiden Şifre Girmeden İstenilen Hesaba Giriş Yapılıyor

[Hucstasy]

Merhaba sevgili MC-TR üyeleri,

Dün gece saat yaklaşık 04:30 civarında sunucumda ciddi bir güvenlik problemi yaşandı. Olayın detaylarını mümkün olduğunca açık şekilde aktarmak istiyorum.

İlgili oyuncu ilk olarak survival sunucusuna giriş yaparak “sudo”, “op” vb. yetki yükseltmeye yönelik komutları denemiştir. Ancak sunucumda aktif bulunan OP koruma sistemi nedeniyle bu girişimler başarısız olmuştur.

Yaklaşık 04:40 civarında oyuncu sürekli “/server lobi” komutunu spamlamış ve bu nedenle spam koruması tarafından sunucudan kicklenmiştir.

Asıl problem ise yaklaşık 04:43 civarında gerçekleşmiştir. Oyuncu, tahminime göre AuthMe sistemini bir şekilde manipüle ederek ya da bir açık kullanarak kurucu hesabıma (ana hesabıma) şifresiz giriş yapmayı başarmıştır. Ardından benim hesabımla survival sunucusuna giriş yapıp kendisine tüm yetkileri vermiştir.
Bunu erkenden farkedip sunucuyu direkt kapatarak saldırıyı engelledim fakat hala saldırı olabileceği konusunda endişeliyim.

Buradaki en büyük problem, hesabıma tam olarak nasıl erişim sağladığını anlayamamamdır. Şu an için elimde net bir bilgi bulunmuyor. İlk başta “/server lobi” üzerinden bir bypass yapılmış olabileceğini düşündüm; ancak sunucularımda doğrudan “/server” komutları oyunculara kapalıdır. Oyuncular yalnızca “/lobi” ve “/survival” komutlarını kullanabilmektedir ve bu komutların çalışabilmesi için de önceden giriş yapılmış olması gerekmektedir.

Bu nedenle olayın AuthMe, Bungee/Velocity geçiş sistemi veya oturum doğrulama yapısıyla ilgili olabileceğinden şüpheleniyorum.

Şimdilik ek güvenlik amacıyla survival sunucularımın tamamına da AuthMe kurarak ikinci bir doğrulama katmanı ekledim. Ancak kullanılan yöntemin tam olarak ne olduğunu bilmediğim için bunun da kesin çözüm olup olmayacağından emin değilim. Bu yüzden halen sistemimde kritik bir açık bulunup bulunmadığı konusunda endişeliyim.

Benzer bir durum yaşamış olan ya da konu hakkında bilgisi bulunan kişiler yardımcı olabilirse çok sevinirim. Özellikle:

Authme üzerinden şifresiz giriş ihtimalleri,
Çakma Lobby / Sahte oturum senaryoları
Velocity + Authme yapılandırma açıkları,
Session/Login bypass yöntemleri,
Güvenlik açısından alınması gereken ek önlemler.
hakkında fikirlerinize ihtiyacım var.

Şimdiden yardımcı olan herkese teşekkür ederim.​

 

[Fynex network]

Merhaba, anlattığın olay AuthMe’nin doğrudan “şifreyi kırması” gibi görünmekten çok, proxy–backend doğrulama zincirinde bir açık olma ihtimalini gösteriyor.

Bu tarz durumlarda ilk kontrol edilmesi gereken nokta şudur: Oyuncular backend sunuculara, yani survival/lobi gibi Paper-Spigot sunucularına proxy dışında doğrudan bağlanabiliyor mu?

Eğer survival sunucusunun portu dışarıya açıksa veya firewall sadece Velocity/Bungee proxy IP’sinden gelen bağlantılara izin verecek şekilde ayarlı değilse, saldırgan backend sunucuya doğrudan bağlanıp offline-mode mantığıyla istediği kullanıcı adıyla giriş denemesi yapabilir. Bu durumda kurucu kullanıcı adını kullanarak giriş yapmış gibi görünmesi mümkündür.

Öncelikle şunları kontrol etmeni öneririm:

1. Survival, lobi ve diğer tüm backend sunucuların portlarını dış dünyaya kapat.
   Backend sunuculara sadece Velocity/Bungee proxy IP’si erişebilmeli.
2. Velocity kullanıyorsan player-info-forwarding-mode = "modern" yapılandırmasını kontrol et.
   Ayrıca Velocity tarafındaki forwarding secret ile backend Paper tarafındaki secret birebir aynı olmalı.
3. Paper/Purpur tarafında Velocity support aktif mi kontrol et.
   Backend sunucular proxy’den gelen oyuncu bilgisini doğrulamalı. Secret yanlışsa veya hiç kullanılmıyorsa ciddi güvenlik açığı oluşabilir.
4. AuthMe sadece lobide değil, gerekiyorsa tüm backendlerde doğru proxy desteğiyle çalışmalı.
   AuthMe’nin Bungee/Velocity proxy kurulum rehberindeki gibi hem proxy tarafı hem backend tarafı birlikte yapılandırılmalı.
5. AuthMe session ayarlarını sıkılaştır.
   Özellikle otomatik session ile tekrar giriş, IP değişiminde oturum kabulü, premium/auto-login gibi ayarlar dikkatle incelenmeli.
6. Kurucu hesabının ismini herkesin bildiği bir hesap olarak kullanma.
   Ana yönetici hesabı gizli bir kullanıcı adıyla tutulmalı, görünen hesapta tam yetki olmamalı.
7. OP yerine LuckPerms üzerinden minimum yetki ver.
   *, luckperms.*, minecraft.command.op, bukkit.command.op, minecraft.command.stop, lp editor, lp user permission set * gibi kritik yetkileri sadece gizli admin grubuna ver.
8. Tüm logları kontrol et:
   Velocity logları, AuthMe logları, survival latest.log, LuckPerms logları, komut geçmişi ve giriş IP’leri incelenmeli. Oyuncunun gerçekten proxy üzerinden mi, yoksa backend porta doğrudan mı geldiği buradan anlaşılır.
9. Hemen yapılması gerekenler:
   Kurucu hesabının şifresini değiştir, AuthMe veritabanındaki admin hesaplarını kontrol et, LuckPerms yetki değişikliklerini geri al, tüm OP listesini temizle, whitelist veya maintenance mode ile sistemi geçici kapalı tut.

Benim tahminim olayın ana sebebi şunlardan biri:

• Backend sunucu portlarının dışarı açık olması,
• Velocity forwarding secret yapılandırmasının eksik veya hatalı olması,
• AuthMe’nin proxy modunda eksik kurulması,
• Session/auto-login ayarlarının fazla gevşek olması,
• Lobiden giriş doğrulandıktan sonra backend geçişlerinde doğrulama kontrolünün zayıf kalması.

Kesin çözüm için sadece survival’a AuthMe kurmak yeterli olmayabilir. Asıl önemli olan, backend sunuculara proxy harici erişimi tamamen kapatmak ve Velocity/Paper forwarding doğrulamasını doğru yapılandırmaktır.

 

[Hucstasy]

Merhaba, anlattığın olay AuthMe’nin doğrudan “şifreyi kırması” gibi görünmekten çok, proxy–backend doğrulama zincirinde bir açık olma ihtimalini gösteriyor.

Bu tarz durumlarda ilk kontrol edilmesi gereken nokta şudur: Oyuncular backend sunuculara, yani survival/lobi gibi Paper-Spigot sunucularına proxy dışında doğrudan bağlanabiliyor mu?

Eğer survival sunucusunun portu dışarıya açıksa veya firewall sadece Velocity/Bungee proxy IP’sinden gelen bağlantılara izin verecek şekilde ayarlı değilse, saldırgan backend sunucuya doğrudan bağlanıp offline-mode mantığıyla istediği kullanıcı adıyla giriş denemesi yapabilir. Bu durumda kurucu kullanıcı adını kullanarak giriş yapmış gibi görünmesi mümkündür.

Öncelikle şunları kontrol etmeni öneririm:

1. Survival, lobi ve diğer tüm backend sunucuların portlarını dış dünyaya kapat.
   Backend sunuculara sadece Velocity/Bungee proxy IP’si erişebilmeli.
2. Velocity kullanıyorsan player-info-forwarding-mode = "modern" yapılandırmasını kontrol et.
   Ayrıca Velocity tarafındaki forwarding secret ile backend Paper tarafındaki secret birebir aynı olmalı.
3. Paper/Purpur tarafında Velocity support aktif mi kontrol et.
   Backend sunucular proxy’den gelen oyuncu bilgisini doğrulamalı. Secret yanlışsa veya hiç kullanılmıyorsa ciddi güvenlik açığı oluşabilir.
4. AuthMe sadece lobide değil, gerekiyorsa tüm backendlerde doğru proxy desteğiyle çalışmalı.
   AuthMe’nin Bungee/Velocity proxy kurulum rehberindeki gibi hem proxy tarafı hem backend tarafı birlikte yapılandırılmalı.
5. AuthMe session ayarlarını sıkılaştır.
   Özellikle otomatik session ile tekrar giriş, IP değişiminde oturum kabulü, premium/auto-login gibi ayarlar dikkatle incelenmeli.
6. Kurucu hesabının ismini herkesin bildiği bir hesap olarak kullanma.
   Ana yönetici hesabı gizli bir kullanıcı adıyla tutulmalı, görünen hesapta tam yetki olmamalı.
7. OP yerine LuckPerms üzerinden minimum yetki ver.
   *, luckperms.*, minecraft.command.op, bukkit.command.op, minecraft.command.stop, lp editor, lp user permission set * gibi kritik yetkileri sadece gizli admin grubuna ver.
8. Tüm logları kontrol et:
   Velocity logları, AuthMe logları, survival latest.log, LuckPerms logları, komut geçmişi ve giriş IP’leri incelenmeli. Oyuncunun gerçekten proxy üzerinden mi, yoksa backend porta doğrudan mı geldiği buradan anlaşılır.
9. Hemen yapılması gerekenler:
   Kurucu hesabının şifresini değiştir, AuthMe veritabanındaki admin hesaplarını kontrol et, LuckPerms yetki değişikliklerini geri al, tüm OP listesini temizle, whitelist veya maintenance mode ile sistemi geçici kapalı tut.

Benim tahminim olayın ana sebebi şunlardan biri:

• Backend sunucu portlarının dışarı açık olması,
• Velocity forwarding secret yapılandırmasının eksik veya hatalı olması,
• AuthMe’nin proxy modunda eksik kurulması,
• Session/auto-login ayarlarının fazla gevşek olması,
• Lobiden giriş doğrulandıktan sonra backend geçişlerinde doğrulama kontrolünün zayıf kalması.

Kesin çözüm için sadece survival’a AuthMe kurmak yeterli olmayabilir. Asıl önemli olan, backend sunuculara proxy harici erişimi tamamen kapatmak ve Velocity/Paper forwarding doğrulamasını doğru yapılandırmaktır.

Merhaba, detaylı açıklaman için teşekkür ederim. Söylediğin şeylerin büyük kısmını kontrol ettim.

Şu an backend portları dışarı açık değil, oyuncu direkt survival veya lobiye bağlanmıyor. Giriş sırası şu şekilde ilerliyor:

Proxy → çakma lobi → AuthMe doğrulaması → gerçek lobi → survival

Yani oyuncu önce auth sunucusunda giriş yapıp doğrulandıktan sonra diğer sunuculara aktarılıyor. Ayrıca Velocity forwarding ayarları ve secret yapılandırması da kontrol edildi, şu an doğru görünüyor.

IP tarafında dikkatimi çeken şey oyuncunun IP’sinin sabit olması fakat her girişte source portunun değişmesi oldu. Ancak bunun tek başına exploit göstergesi olmadığını biliyorum çünkü NAT bağlantılarında normal davranış olabiliyor.

Bu yüzden olayın doğrudan “backend’e direkt bağlanma” yerine daha çok session/kimlik doğrulama zinciriyle ilgili olabileceğini düşünmeye başladım. Özellikle AuthMe session restore, auto-login veya premium doğrulama tarafında yanlış güven oluşuyor olabilir.

Şu an test amaçlı:

• session/auto-login ayarlarını sıkılaştırıyorum,
• premium auto auth özelliklerini kontrol ediyorum,
• backend doğrulamalarını tekrar gözden geçiriyorum,
• admin yetkilerini minimuma indiriyorum.

Çünkü burada asıl problem OP yetkisi değil, başka oyuncuların hesaplarına erişim ihtimali. Eğer gerçekten session reuse veya auth zinciriyle ilgili bir durum varsa, normal oyuncular için de ciddi risk oluşturabilir.

AuthMe logları ve giriş kayıtlarını incelemeye devam ediyorum. Özellikle “Session restored” veya “Automatically logged in” tarzı kayıtlar var mı ona bakacağım.

 

[Fynex network]

Bu durumda backend port bypass ihtimali zayıflamış görünüyor. Proxy → çakma lobi → AuthMe → gerçek lobi → survival zinciri doğruysa ve Velocity forwarding secret tarafı da sağlamsa, odak noktası artık AuthMe session, auto-login, premium auth ve sunucular arası geçişte login state kontrolü olmalı.

Özellikle şu noktaları kontrol etmeni öneririm:

1. AuthMe session restore kayıtları
   Loglarda saldırı saatine yakın şu tarz kayıtlar var mı bakılmalı:

• Session restored
• Automatically logged in
• Auto-login successful
• Premium user automatically logged in
• Logged in by session
• FastLogin/Floodgate/SkinsRestorer kaynaklı otomatik doğrulama kayıtları

Eğer kurucu hesabı için şifre girilmeden “session restored” veya “auto login” tarzı bir kayıt varsa, olay büyük ihtimalle session güveni veya premium auto-login tarafındadır.

1. Session ayarlarını geçici olarak kapat
   Teşhis için AuthMe session sistemini tamamen kapatıp tekrar deneme yapılmalı. Yani oyuncu her girişte mutlaka şifre girmek zorunda kalmalı.

Kontrol edilmesi gereken ayarlar:

• sessions enabled
• timeout
• sessionExpireOnIpChange
• sessionCheckOnIp
• autoLogin
• premiumAutoLogin
• forceLoginAfterRegister
• unsafe passwords / weak password kontrolü

Geçici olarak en güvenli test yaklaşımı:

• Session restore kapalı
• Auto login kapalı
• Premium auto auth kapalı
• IP değişince session geçersiz
• Her sunucu geçişinde login state kontrolü aktif

1. Premium auto-login / FastLogin benzeri sistem varsa ayrıca incelenmeli
   Eğer FastLogin, JPremium, nLogin, LibreLogin, AuthMeBridge, Floodgate/Geyser gibi ek kimlik doğrulama veya premium doğrulama eklentileri varsa sorun AuthMe’den değil, bu eklentilerden biriyle AuthMe arasındaki güven zincirinden kaynaklanıyor olabilir.

Bu tarz sistemlerde bazen oyuncu “premium doğrulandı” varsayımıyla şifresiz geçirilir. Eğer UUID/name eşleşmesi, premium check, cache veya session yanlış çalışırsa başka bir kullanıcı adıyla otomatik doğrulanmış gibi görünme riski doğabilir.

1. Auth sunucusundan çıkmadan önce doğrulama zorunlu olmalı
   Oyuncu AuthMe ile giriş yapmadan:

• /lobi
• /survival
• /server
• NPC tıklama
• menü komutları
• item menüleri
• plugin mesajları
• portal geçişleri

kesinlikle çalışmamalı.

Sadece /login, /register ve gerekiyorsa /captcha benzeri temel komutlar açık kalmalı.

1. Gerçek lobi ve survival tarafında da “login state” kontrolü yapılmalı
   Sadece çakma lobide AuthMe olması bazı ağlarda yeterli olmayabilir. Oyuncu bir şekilde geçiş zincirinde doğrulanmış gibi işaretlenirse backend sunucu onu güvenilir kabul edebilir.

Bu yüzden en azından kritik sunucularda şu kontroller yapılmalı:

• AuthMeBridge / AuthMeBungee doğru çalışıyor mu?
• Oyuncu login olmadan başka sunucuya aktarılabiliyor mu?
• Auth sunucudan gerçek lobiye geçiş sadece başarılı login eventinden sonra mı yapılıyor?
• Plugin menüleri login öncesinde komut çalıştırabiliyor mu?
• NPC, GUI veya özel /lobi komutu AuthMe login durumunu kontrol ediyor mu?

1. Admin hesabı için özel güvenlik uygulanmalı
   Buradaki risk OP yetkisinden bağımsız. Eğer hesap ele geçirilebiliyorsa normal oyuncular da etkilenebilir. Ama admin hesaplarında ekstra önlem şart.

Öneriler:

• Kurucu hesabının AuthMe şifresini değiştir
• Kurucu hesabını normal oyuncuların bildiği isimle kullanma
• Yetkili hesaplar için 2FA eklentisi kullan
• Yetkili hesaplarda session/auto-login tamamen kapalı olsun
• Admin yetkilerini tek hesaba yığma
• OP kullanma, LuckPerms ile minimum yetki ver
• Konsoldan verilebilecek komutları oyuncu hesaplarından tamamen kaldır

1. Loglarda özellikle şu zinciri ara
   Saldırı saatindeki kayıtları şu sırayla kontrol et:

• Oyuncu hangi IP ile bağlandı?
• Hangi kullanıcı adıyla bağlandı?
• Kurucu hesabı için login komutu girilmiş mi?
• Şifre doğrulama başarılı kaydı var mı?
• Yoksa session/auto-login ile mi geçirilmiş?
• Kurucu hesabı auth sunucusundan mı gerçek lobiye geçti?
• Survival’a geçişi hangi plugin tetikledi?
• Yetki verme komutu hangi sunucuda çalıştı?
• LuckPerms logunda hangi komut, hangi hesap, hangi saat görünüyor?

Eğer kurucu hesabı için /login komutu görünmüyor ama hesaba giriş başarılı görünüyorsa, bu doğrudan session/auto-login/premium-auth tarafına işaret eder.

1. Source port değişimi tek başına kanıt değil
   Aynı IP’den farklı source portlarla bağlantı kurulması normaldir. NAT, modem, işletim sistemi ve bağlantı yenilemeleri nedeniyle her TCP bağlantısında farklı port görülebilir. Bu tek başına exploit belirtisi değildir.

Benim bu yeni bilgilere göre en güçlü ihtimal sıralamam şu olur:

1. AuthMe session restore / auto-login yanlış güven oluşturdu.
2. Premium auto-login veya FastLogin benzeri bir eklenti kullanıcıyı şifresiz doğruladı.
3. Auth sunucudan gerçek lobi/survival geçişinde login state kontrolü eksik kaldı.
4. Özel /lobi, /survival, menü, NPC veya plugin-message geçişleri AuthMe doğrulamasını bypass etti.
5. Kurucu hesabının şifresi daha önce biliniyordu veya zayıftı; fakat loglarda /login kaydı yoksa bu ihtimal düşer.

Bence şu an yapılacak en mantıklı test:

• Session restore kapat
• Premium auto-login kapat
• FastLogin/JPremium/nLogin/LibreLogin vb. varsa geçici kapat
• Sadece manuel /login şifre ile girişe izin ver
• Auth olmadan hiçbir komut, menü, NPC, portal ve sunucu geçişi çalışıyor mu test et
• Kurucu hesabı için 2FA ve ayrı gizli admin hesabı kullan

Bu testten sonra sorun tekrarlanmıyorsa açık büyük ihtimalle AuthMe şifresinin kırılması değil, oturum/auto-login zincirindeki yanlış güven mekanizmasıdır.

 

[Hucstasy]

Bu durumda backend port bypass ihtimali zayıflamış görünüyor. Proxy → çakma lobi → AuthMe → gerçek lobi → survival zinciri doğruysa ve Velocity forwarding secret tarafı da sağlamsa, odak noktası artık AuthMe session, auto-login, premium auth ve sunucular arası geçişte login state kontrolü olmalı.

Özellikle şu noktaları kontrol etmeni öneririm:

1. AuthMe session restore kayıtları
   Loglarda saldırı saatine yakın şu tarz kayıtlar var mı bakılmalı:

• Session restored
• Automatically logged in
• Auto-login successful
• Premium user automatically logged in
• Logged in by session
• FastLogin/Floodgate/SkinsRestorer kaynaklı otomatik doğrulama kayıtları

Eğer kurucu hesabı için şifre girilmeden “session restored” veya “auto login” tarzı bir kayıt varsa, olay büyük ihtimalle session güveni veya premium auto-login tarafındadır.

1. Session ayarlarını geçici olarak kapat
   Teşhis için AuthMe session sistemini tamamen kapatıp tekrar deneme yapılmalı. Yani oyuncu her girişte mutlaka şifre girmek zorunda kalmalı.

Kontrol edilmesi gereken ayarlar:

• sessions enabled
• timeout
• sessionExpireOnIpChange
• sessionCheckOnIp
• autoLogin
• premiumAutoLogin
• forceLoginAfterRegister
• unsafe passwords / weak password kontrolü

Geçici olarak en güvenli test yaklaşımı:

• Session restore kapalı
• Auto login kapalı
• Premium auto auth kapalı
• IP değişince session geçersiz
• Her sunucu geçişinde login state kontrolü aktif

1. Premium auto-login / FastLogin benzeri sistem varsa ayrıca incelenmeli
   Eğer FastLogin, JPremium, nLogin, LibreLogin, AuthMeBridge, Floodgate/Geyser gibi ek kimlik doğrulama veya premium doğrulama eklentileri varsa sorun AuthMe’den değil, bu eklentilerden biriyle AuthMe arasındaki güven zincirinden kaynaklanıyor olabilir.

Bu tarz sistemlerde bazen oyuncu “premium doğrulandı” varsayımıyla şifresiz geçirilir. Eğer UUID/name eşleşmesi, premium check, cache veya session yanlış çalışırsa başka bir kullanıcı adıyla otomatik doğrulanmış gibi görünme riski doğabilir.

1. Auth sunucusundan çıkmadan önce doğrulama zorunlu olmalı
   Oyuncu AuthMe ile giriş yapmadan:

• /lobi
• /survival
• /server
• NPC tıklama
• menü komutları
• item menüleri
• plugin mesajları
• portal geçişleri

kesinlikle çalışmamalı.

Sadece /login, /register ve gerekiyorsa /captcha benzeri temel komutlar açık kalmalı.

1. Gerçek lobi ve survival tarafında da “login state” kontrolü yapılmalı
   Sadece çakma lobide AuthMe olması bazı ağlarda yeterli olmayabilir. Oyuncu bir şekilde geçiş zincirinde doğrulanmış gibi işaretlenirse backend sunucu onu güvenilir kabul edebilir.

Bu yüzden en azından kritik sunucularda şu kontroller yapılmalı:

• AuthMeBridge / AuthMeBungee doğru çalışıyor mu?
• Oyuncu login olmadan başka sunucuya aktarılabiliyor mu?
• Auth sunucudan gerçek lobiye geçiş sadece başarılı login eventinden sonra mı yapılıyor?
• Plugin menüleri login öncesinde komut çalıştırabiliyor mu?
• NPC, GUI veya özel /lobi komutu AuthMe login durumunu kontrol ediyor mu?

1. Admin hesabı için özel güvenlik uygulanmalı
   Buradaki risk OP yetkisinden bağımsız. Eğer hesap ele geçirilebiliyorsa normal oyuncular da etkilenebilir. Ama admin hesaplarında ekstra önlem şart.

Öneriler:

• Kurucu hesabının AuthMe şifresini değiştir
• Kurucu hesabını normal oyuncuların bildiği isimle kullanma
• Yetkili hesaplar için 2FA eklentisi kullan
• Yetkili hesaplarda session/auto-login tamamen kapalı olsun
• Admin yetkilerini tek hesaba yığma
• OP kullanma, LuckPerms ile minimum yetki ver
• Konsoldan verilebilecek komutları oyuncu hesaplarından tamamen kaldır

1. Loglarda özellikle şu zinciri ara
   Saldırı saatindeki kayıtları şu sırayla kontrol et:

• Oyuncu hangi IP ile bağlandı?
• Hangi kullanıcı adıyla bağlandı?
• Kurucu hesabı için login komutu girilmiş mi?
• Şifre doğrulama başarılı kaydı var mı?
• Yoksa session/auto-login ile mi geçirilmiş?
• Kurucu hesabı auth sunucusundan mı gerçek lobiye geçti?
• Survival’a geçişi hangi plugin tetikledi?
• Yetki verme komutu hangi sunucuda çalıştı?
• LuckPerms logunda hangi komut, hangi hesap, hangi saat görünüyor?

Eğer kurucu hesabı için /login komutu görünmüyor ama hesaba giriş başarılı görünüyorsa, bu doğrudan session/auto-login/premium-auth tarafına işaret eder.

1. Source port değişimi tek başına kanıt değil
   Aynı IP’den farklı source portlarla bağlantı kurulması normaldir. NAT, modem, işletim sistemi ve bağlantı yenilemeleri nedeniyle her TCP bağlantısında farklı port görülebilir. Bu tek başına exploit belirtisi değildir.

Benim bu yeni bilgilere göre en güçlü ihtimal sıralamam şu olur:

1. AuthMe session restore / auto-login yanlış güven oluşturdu.
2. Premium auto-login veya FastLogin benzeri bir eklenti kullanıcıyı şifresiz doğruladı.
3. Auth sunucudan gerçek lobi/survival geçişinde login state kontrolü eksik kaldı.
4. Özel /lobi, /survival, menü, NPC veya plugin-message geçişleri AuthMe doğrulamasını bypass etti.
5. Kurucu hesabının şifresi daha önce biliniyordu veya zayıftı; fakat loglarda /login kaydı yoksa bu ihtimal düşer.

Bence şu an yapılacak en mantıklı test:

• Session restore kapat
• Premium auto-login kapat
• FastLogin/JPremium/nLogin/LibreLogin vb. varsa geçici kapat
• Sadece manuel /login şifre ile girişe izin ver
• Auth olmadan hiçbir komut, menü, NPC, portal ve sunucu geçişi çalışıyor mu test et
• Kurucu hesabı için 2FA ve ayrı gizli admin hesabı kullan

Bu testten sonra sorun tekrarlanmıyorsa açık büyük ihtimalle AuthMe şifresinin kırılması değil, oturum/auto-login zincirindeki yanlış güven mekanizmasıdır.

authme pluginini değiştirerek keyleri ve portları gözden geçirerek şimdilik bir güvenlik sağladım ne kadar güvenli bilmiyorum ama şimdilik çözüldü

 

[BayLite]

Velocity kur limboauth kullan

 

[ByVoxar]

Merhaba sevgili MC-TR üyeleri,

Dün gece saat yaklaşık 04:30 civarında sunucumda ciddi bir güvenlik problemi yaşandı. Olayın detaylarını mümkün olduğunca açık şekilde aktarmak istiyorum.

İlgili oyuncu ilk olarak survival sunucusuna giriş yaparak “sudo”, “op” vb. yetki yükseltmeye yönelik komutları denemiştir. Ancak sunucumda aktif bulunan OP koruma sistemi nedeniyle bu girişimler başarısız olmuştur.

Yaklaşık 04:40 civarında oyuncu sürekli “/server lobi” komutunu spamlamış ve bu nedenle spam koruması tarafından sunucudan kicklenmiştir.

Asıl problem ise yaklaşık 04:43 civarında gerçekleşmiştir. Oyuncu, tahminime göre AuthMe sistemini bir şekilde manipüle ederek ya da bir açık kullanarak kurucu hesabıma (ana hesabıma) şifresiz giriş yapmayı başarmıştır. Ardından benim hesabımla survival sunucusuna giriş yapıp kendisine tüm yetkileri vermiştir.
Bunu erkenden farkedip sunucuyu direkt kapatarak saldırıyı engelledim fakat hala saldırı olabileceği konusunda endişeliyim.

Buradaki en büyük problem, hesabıma tam olarak nasıl erişim sağladığını anlayamamamdır. Şu an için elimde net bir bilgi bulunmuyor. İlk başta “/server lobi” üzerinden bir bypass yapılmış olabileceğini düşündüm; ancak sunucularımda doğrudan “/server” komutları oyunculara kapalıdır. Oyuncular yalnızca “/lobi” ve “/survival” komutlarını kullanabilmektedir ve bu komutların çalışabilmesi için de önceden giriş yapılmış olması gerekmektedir.

Bu nedenle olayın AuthMe, Bungee/Velocity geçiş sistemi veya oturum doğrulama yapısıyla ilgili olabileceğinden şüpheleniyorum.

Şimdilik ek güvenlik amacıyla survival sunucularımın tamamına da AuthMe kurarak ikinci bir doğrulama katmanı ekledim. Ancak kullanılan yöntemin tam olarak ne olduğunu bilmediğim için bunun da kesin çözüm olup olmayacağından emin değilim. Bu yüzden halen sistemimde kritik bir açık bulunup bulunmadığı konusunda endişeliyim.

Benzer bir durum yaşamış olan ya da konu hakkında bilgisi bulunan kişiler yardımcı olabilirse çok sevinirim. Özellikle:

Authme üzerinden şifresiz giriş ihtimalleri,
Çakma Lobby / Sahte oturum senaryoları
Velocity + Authme yapılandırma açıkları,
Session/Login bypass yöntemleri,
Güvenlik açısından alınması gereken ek önlemler.
hakkında fikirlerinize ihtiyacım var.

Şimdiden yardımcı olan herkese teşekkür ederim.​

merhaba auht me eklentisinin şifre kısımlarını bypass edebiliyorlar bunun yerine velocity de limbo auht gibi pluginler kurabilirsin ekstra güvenlik olarak opu olan kişiler için kod sistemi ekleyebilirsin örneğin kullacının opu var ise her girişinde veya oyunda op aldığında tahmin edilmesi zor bir kof olsun /kod şifre şeklinde yazıldığında oyuna giriş yapabilisin bu plugine bakabilirsin ama daha iyisi vardır

Değerli ziyaretçimiz, içeriği görebilmek için şimdi giriş yapın veya kayıt olun.

 

[Hucstasy]

merhaba auht me eklentisinin şifre kısımlarını bypass edebiliyorlar bunun yerine velocity de limbo auht gibi pluginler kurabilirsin ekstra güvenlik olarak opu olan kişiler için kod sistemi ekleyebilirsin örneğin kullacının opu var ise her girişinde veya oyunda op aldığında tahmin edilmesi zor bir kof olsun /kod şifre şeklinde yazıldığında oyuna giriş yapabilisin bu plugine bakabilirsin ama daha iyisi vardır

Değerli ziyaretçimiz, içeriği görebilmek için şimdi giriş yapın veya kayıt olun.

hocam bypass mevzusu çok sıkıntı opların olmasa bile vip vb oyuncuların hesaplarına giriş yapabilirler bu yüzden direkt fixlemek için dediğin gibi limboapi ve 2 aşamalı doğrulamalı auth ekledik şimdilik bir sorun yok umarım ilerde de olmaz teşekkürler plugin için işime yarar yine sağol