SSL-DoS-Tool: Plesk CP angreifbar

[VisualBeo]

Hallo Freunde der gepflegten Weboberflächenadministration.

Wie heise.de gestern berichtete, hat eine dieser bösen Hackergruppen ein Tool veröffentlicht, um Server per SSL-Verbindungen in die Knie zu zwingen. Das Tool erzwingt haufenweise die Neuaushandlung der Schlüssel und erzeugt damit eine hohe Rechenlast auf dem Server.

Ich hab versucht, damit meinen vServer (Plesk 10 auf Ubuntu 10) anzugreifen. Ergebnis:

Apache2 hat Renegotiation per default disabled, https-Webseiten sind also nicht angreifbar:

>thc-ssl-dos.exe -l 1000 <IP> 443 --accept --skip-delay

Handshakes 0 [0.00 h/s], 1 Conn, 0 Err
ERROR: Target has disabled renegotiation

Jedoch ist das Plesk ControlPanel (lighttpd) auf Port 8443 gut angreifbar, der CP-Deamon (sw-cp-serverd) erzeugt eine hohe Last (über 77%CPU und 9.2%MEM).

>thc-ssl-dos.exe -l 1000 <IP> 8443 --accept --skip-delay

Handshakes 0 [0.00 h/s], 1 Conn, 0 Err
Handshakes 28 [28.57 h/s], 28 Conn, 0 Err
Handshakes 57 [28.97 h/s], 56 Conn, 0 Err
Handshakes 84 [26.55 h/s], 79 Conn, 0 Err
Handshakes 119 [34.79 h/s], 101 Conn, 0 Err
Handshakes 151 [32.39 h/s], 122 Conn, 0 Err
(...)

Grundsätzlich funktioniert es also. Jedoch bleibt der Server noch halbwegs stabil. Das CP reagiert zwar sehr lahm bis gar nicht, der Apache2 oder andere Dienste scheinen davon aber unbeeindruckt zu sein.

Habt ihr ein bisschen rumprobiert und evtl. erfolgreiche Angriffe starten können, z.B. der verteiltem DOS?

Grüße, Chris

 

[its]

Leider gab es diese Form von Angriff schon länger, nur jetzt hat THC es in eine Enduser-Freundliche Variante verpackt. Es war mir möglich, mit nur zwei DSL Leitungen einen meiner Test-Plesk Server lahm zu legen.

Sobald ich eine praktikable Lösung für das Problem habe, werde ich darüber schreiben.

Ob THC generell böse ist, lässt sich drüber streiten.

Doch der Trend entwickelt sich leider immer weiter dahingehend, dass man Sicherheitslücken-Scanner, DDoS-Programme, etc Enduser freundlich gestalten muss, damit die Masse darauf Aufmerksam wird und auch die Hersteller etwas dagegen unternehmen.

 

[VisualBeo]

Das mit der "bösen Hackergruppe" war eher augenzwinkernd gemeint.

Was du sagst, stimmt aber. Facebook hat seine Session-Hijacking-Lücke damals auch erst geschlossen, als es für den Angriff sogar ein eigenes Browser-AddOn (firesheep) gab *gg*.

 

[its]

Ich glaube mit dem deaktivieren von der

renegotiation

ist schon vielen geholfen.

Die Frage ist jetzt nur, wenn schon zwei DSL Leitungen ausreichen um sehr hohe Last zu erzeugen, wir man sich effektiv davor schützt?

Ohne große Kosten für "SSL acceleration" auszugeben?

 

[wstuermer]

An dieser Stelle sei dann mal auf den rechtlichen Aspekt dieses "Tools" verwiesen. Der kam in dem heise-Artikel ja etwas zu kurz.

 

[d4f]

Ich will darauf hinweisen dass der Angriff ohne Renegotiation _PROBLEMLOS_ weiter funktioniert, nur etwas mehr Client-Bandbreite wird benoetigt da er fuer jede Schluesselaushandlung eine neue Verbindung oeffnen muss.

Zu glauben Apache in der Defaulteinstellung sei sicher (vor dieser Methode) ist ein Trugschluss, mit etwas Know-How kriegt man ihn ganz schnell in die Knie.
Die DDoS-Technik gilt fuer _ALLE_ SSL-Verbindungen, und ist somit nicht nur auf HTTP-Server begrenzt.