THC-SSL-DoS aracılığı ile bir sunucunun SSL çözümlemesinde harcadığı kaynaklar sömürülebiliyor.
Bu saldırı temel olark; SSL-Renegotiation mimarisindeki hatadan kaynaklanıyor. Hata tek bir TCP bağlantısı ile binlerce bağlantının (Üçlü el Sıkışma kuralı...) tetiklenmesi ile gerçekleştiriliyor.
----
g_opt.stat.total_renegotiations++;
p->count_renegotiations++;
if (p->count_renegotiations % 50 == 0)
{
p->state = STATE_SSL_DUMMYWRITE;
} else {
p->state = STATE_SSL_HANDSHAKING;
}
return 0;
----p->count_renegotiations++;
if (p->count_renegotiations % 50 == 0)
{
p->state = STATE_SSL_DUMMYWRITE;
} else {
p->state = STATE_SSL_HANDSHAKING;
}
return 0;
DDoS Flood ve SSL-Tüketme saldırısı karşılaştırıldığında;
Flood'da gerçekleştiren bağlantının bir tane olmaması en büyük ayrımdır. Saldırıdan amaç çok sayıda DSL bağlantısı ile Sunucunun bant genişliğinin tüketilmesidir.
SSL-DoS tarafında ise Karşıdaki sunucunu bant genişliği değil, İşlem gücü kendine karşı kullanılacağından, çok sayıda makinaya ve çok yüksek başarımlı saldırı sistemi olmadan da zarar verilebilmesidir. Burada saldırganın hedefi çok sayıda SSL El sıkışmasıdır...
----
static int
ssl_connect_io(struct _peer *p)
{
int ret;
ret = SSL_connect(p->ssl);
if (ret == 1)
{
g_opt.stat.total_ssl_connect++;
----ssl_connect_io(struct _peer *p)
{
int ret;
ret = SSL_connect(p->ssl);
if (ret == 1)
{
g_opt.stat.total_ssl_connect++;
Örneğin standart bir notebook'un %10-25 işlem gücü ile saniye 300 bağlantı tetiklemesi yapılabilir.
Aynı makinada birden fazla host olması saldırı tesir kesit/hızını arttırır.
Saldırının asıl tehlikeli tarafı ise bağlantının uçtan uca olması ve talep dönüşlerinin Sunucudan olması nedeniyle IDS/IPS sistemlerinin başarısının azalması...
Bu saldırıya gerçek bir çözüm olmasa da;
SSL-Renegotiation özelliği kapatılabilir (!)
|
____ Innovation Science Labs ____
|