Diffie-Hellman kulcscserét támogató szerverek túlterhelése

A korábban már beküldött CryptoLyzer alapjain készítettem egy eszközt D(HE)ater néven, ami kihasználja a Diffie-Hellman (DHE) kulcscsere azon sajátosságát, hogy a kulcs létrehozásához CPU intenzív műveletek elvégzésére van szükség és erre a szerverek viszonylag egyszerűen rá is kényszeríthetőek. A támadás, aminek a D(HE)at nevet adtam, TLS esetén akár 6-7 KB/s sávszélesség felhasználásával képes egy 1 CPU-n 100% terhelést elérni. Maga a támadás különböző hatékonysággal, de működik SSH és IPSec estén is, egyelőre viszont a tool csak SSH-t támogat, ahol ~80 KB/s szükséges a 100% CPU terhelés eléréséhez. Kíváncsi lennék mit gondoltok akár red, akár blue team oldalon a dologról.

A támadás maga viszonylag egyszerű. Olyan üzenetet kell küldeni a szerver felé, ami egy olyan kliens látszatát kelti, ami csak DHE kulcscserét támogat. Ennek hatására a szerver olyan, a kulcscseréhez szükséges számításokba kezd, amik kifejezetten CPU intenzívek. TLS esetén ehhez egyetlen üzenet (ClientHello) elküldése is elegendő, SSH esetén ugyanehhez legalább 3 üzenet küldésére és 2 üzenet fogadására van szükség, viszont míg TLS esetén a kulcsméret, aminek növelésével a számításiigény is nő, a szerver által meghatározott, addig SSH esetén a kulcsméretet a kliens tudja befolyásolni, a szerver beállításainak megfelelő határok között, ami praktikusan azt jelenti, hogy míg TLS esetén a legelterjedtebb a 2048 bites kulcsméret, addig SSH esetén a 8192 kulcsméret jellemzően kikényszeríthető, ezzel növelve a támadás hatékonyságát.

A múlt pénteki Hacktivityn adtam elő a témában, aminek a prezentációját itt találhatjátok, amiből csak azt a táblázatot szeretném ide citálni, ami az általam kipróbált protokollok és implementációk esetén foglalja össze a támadás hatékonyságát. A szerver egyébként egy 4 processzoros Digital Ocean instance volt, a számok ehhez mérten értendőek.

Protocol

Server Implementation

Speed

(req/s)

Bandwidth (KB/s)

Effect (+threads)

Efficiency

KB/s for

+1 thread

Efficiency

KB/s for

100% CPU

HTTPS (TLS 1.2)

Apache

~88

~27

~250

~0.10

~6.8

HTTPS (TLS 1.2)

NGINX

~88

~27

0

0

~6.8

SMTP (TLS 1.2)

Postfix

~34

~10

~250

~0.04

n/a

SSH (2.0)

OpenSSH

~52

~320

20-80

~6-25

~80

SSH (2.0)

Tectia SSH

~21

~185

~500

~0.4

~46

Ahogy látszik némely implementáció esetén a számos új thread/process létrehozása is kikényszeríthető, de személy szerint én ezt érzem a kisebb problémának. A védekezés, azon túl, hogy DHE helyett ECDHE-t hásználunk, is lehetséges, mivel jellemzően az ilyen típusú üzenet külldések nyomot hagynak a logban, amit például egy Fail2Ban már fel tud használni. Ennek részleteiről és a szükséges Fail2Ban beállításokról szó a D(HE)ater tool GitHub oldalán. Ugyanakkor, mivel a sávszélességigény és az erőforrásigény csekély néhány ezres, vagy tízezres botnet hálózat bittokában, amik lehetnek egyszerű routerek is, percenként akár egy-egy üzenet is elég lehet, ami azért komolyan nehezíti a védekezést egy publikus szolgáltatás (pl: HTTPS) esetén. Érdekelne hogy látjátok ennek a támadásnak a hatékonyságát, illetve a védekezés lehetőségeit.

Hozzászólások

vedekezes: nem hasznalunk titkositast :)))

vagy esetleg cloudflare?

btw erre nincs hardveres gyorsitas? mindig a cpu szamolja ki izombol?

A cloudflare is használ (még) DHE kulcscserét.
ktls létezik, használják is páran (lásd Netflix) de ettől még gondot okozhat ez a fajta támadás.

Ami inkább engem érdekel, hogy a csillagászati áron vásárolható és bérelhető DDOS védelmi csillogó-villogó-pittyegő dobozok ezzel mit tudnak kezdeni. Feltételezem, hogy jelenleg semmit. :))

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

Úgy lesz! A mac-et ígértem - ott ugye LibreSSL van, szerintem nem lesznek jobbak a számok.

Ktls-t is felírtam a listára.

A Cloudflare-t nyilván nem lőném lábon, de ha a Kárpátokon túlról valaki adna neki egy próbát és hallok róla, azt megosztom mindenképp.

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

A cloudflare is használ (még) DHE kulcscserét.

Tuti biztos? Én határozottan úgy emlékszem, hogy az Opera 12 koporsójába az verte be nálam az utolsó szöget, amikor a cloudflare mögötti nem kevés site-tal már nem tudott kommunikálni, mert csak ECDHE-t volt hajlandó beszélni, míg az Opera 12-be az már pont nem került be, csak a DHE. Egy rövid pillanatig elgondolkodtam azon, hogy csinálok egy MitM újracsomagolást a squidemben, de aztán inkább elengedtem a dolgot.

elovalasztas2021.hu:

 Testing server preferences 

 Has server cipher order?     yes (OK) -- only for < TLS 1.3
 Negotiated protocol          TLSv1.3
 Negotiated cipher            TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Cipher order
    TLSv1:     ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA 
    TLSv1.1:   ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA 
    TLSv1.2:   ECDHE-ECDSA-CHACHA20-POLY1305-OLD ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-GCM-SHA384
               ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA384 

A GitHub repoban vannak Fail2Ban kiegészítések, meg konfigurációk. Meg aztán ugye az ECDHE mindennél is jobb. A gyorsítókártya jó kérdés, a számítás itt javarészt hatványozást jelent, ennek függvényében már lehet, hogy tudja itt valaki a választ. Amúgy a Cloudflare kapcsán bőven el tudom képzeni, hogy van erre megoldásuk. Egy próbát mindenképp megér, ha van valakinek ott egy instance-a.

Van gyorsítókártya DHE,ECDHE-re. Intel Quick Assist Technology (QAT) az (egyik) varázsszó. Létezik külön PCI-E kártya is ,de vannak olyan Xeon-hoz való chipsetek amiben benne van a QAT.

Sok nagy ADC és tűzfal cuccban van ilyen eszköz (pl F5.)

https://www.intel.com/content/www/us/en/architecture-and-technology/int…

https://www.intel.com/content/dam/www/public/us/en/documents/product-br…

Egyébként 2.5-ös haproxy-ban már lesz néhány új fetcher ami használható rate limitelésre log olvasás meg fail2ban nélkül is SSL hibáknál.

https://github.com/haproxy/haproxy/commit/3d2093af9bec2b73ed285b967f434…

https://github.com/haproxy/haproxy/commit/7c6898ee4907e66c000a77ec32eff…

Ilyen sima tls rate limit-et simán össze lehet rakni haproxy-val. Én szofisztikáltabbra gondoltam, pl csak a DHE-t támogató klienseket rate limitelni. Léteznek erre fectherek pl a ssl_fc_cipherlist_str visszadja a az összes támogatott alogritmust, utána már csak egy stick-table meg egy acl kell hogy rate limitelje a csak DHE-t nyomató klienseket pl.

DH Support for Key Sizes: 768/1024/1536/2048/3072/4096.

Amit csodálok az az, hogy DH, van DHE helyett, de erről részletesebbet nem találok így hirtelen a dokumentumokban. Ugyanakkor az is érdekes, hogy a legnagyobb érték 4096 bit, miközben mind az SSH, mind a TLS 1.3 lehetővé teszi a 8192 bites kulcsokat, amit a DHEater ki is kényszerít.

egy olyan kliens látszatát kelti, ami csak DHE kulcscserét támogat

Laikusként kérdezem: mennyi ilyen kliens van, mennyire megvalósítható nem támogatni a DHE kulcscserét szerver oldalon?

Psszt, elárulom az IP-címemet: 192.168.0.14

Igazából olyan kliens, ami csak és kizárólag DHE-t támogat nem hiszem, hogy lenne. Szerver oldalon szimplán konfiguráció kérdése kikapcsolni a DHE kulcscserét TLS, SSH és OpenVPN esetén legalábbis, csak nem szokás, mivel ezen keresztül lehet backward compatibilityt megvalósítani úgy, hogy a kulcscsere algoritmus forward secret, ha ez nem szempont, akkor ott az RSA kulcscsere.

Azt még érdemes hozzátenni, hogy a Qualys statsiztikáiból az látszik (Forward Secrecy szekció), hogy a "Used with most browsers" aránya csaknem 70%, ami pont azt jelenti, hogy a DHE engedélyezett.

Used with most browsers – most browsers negotiate a FS suite. This will typically happen with a server that supports ECDHE suites, but falls back to DHE for clients that do not support Elliptic Curve cryptography.

Úgy nézem, ez 2.5-től elérhető. A legtöbb LTS rendszer még csak 2.4.* openvpn-t hoz a saját repo-jából. De javítsatok ki, ha tévedek! (nyilván ha nagyon akarom, akkor konténer, meg leforgatom forrásból, stb.)
Játszós szerveren azért kipróbálom, köszi!

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

Szerintem jól gondolod, de ez a lap elég elavult, szóval inkább itt bogarássz: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-…

és azt javaslom, hogy használj inkább --tls-crypt -et. ;)

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

igen. Én eddig tls-auth-ot használtam, pont ilyen célokra.

Viszont a tls-crypt-et most próbáltam ki 2.4.7-es openvpn-ben. Működik szépen. A kérdésre a válasz: igen, egyszerre kell server+client oldalon bekapcsolni.

A key direction viszont már nem szükséges hozzá úgy mint a tls-auth-oz kellett.

Szerkesztve: 2021. 10. 12., k – 13:46

Nem kene a DHE parameterit lejebb venni ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hogy értve? Az 1024 bites kulcs kapcsán azt a mondás, hogy nemzetbiztonsági szintű erőforrások birtokában törhető, így jellemzően 2048 bites, vagy annál nagyobb kulcsok vannak használatban. Az SSH, illetve a TLS 1.3 kapcsán ráadásul a kliens tud választani, hogy milyen méretű kulcsot szeretne. Persze mondjuk például OpenSSH esetén a /etc/ssh/moduli állományból kivehetőek a nagyobb méretű kulcsok és ezzel voltaképpen csökkenthető a hatákonyság, de a rate limiting nekem jobb megoldásnak tűnik.

aes128..aes256  hasznalatos, RSA nagy kulcsokkal csak eas kulcs cserig megy, RSA tul lassu tenyleges kapcsolathoz.
RSA -hasznal nagy kulcsot, nem a szimetrikus titkositas.

BTW ez -e a lassu resz DHE -nel?
https://en.wikipedia.org/wiki/Modular_exponentiation

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

  • TLS esetén nincs ilyen keresés, mivel ott a szerver határozza meg a DH kulcs méretét (DH param)
  • SSH esetén két lehetőség van
    1. Diffie-Hellman Key Exchange esetén maga az algoritmus (pl: diffie-hellman-group14-sha1 -> 2048 bit) határozza meg a kulcs méretét, így a szerver által ajánlott algoritmusok közül azt választja a D(HE)ater, amihez a legnagyobb kulcsméret tartozik (pl: diffie-hellman-group18-sha512 -> 8192 bit)
    2. Diffie-Hellman Group Exchange esetén maga az algoritmus (pl: diffie-hellman-group-exchange-sha256) nem határozza meg a kulcs méretét, az egy negotiation keretében dől el, az algoritmusok egyeztetése után, ahol a kliens ki tudja "erőszakolni" a szerver által támogatott kulcsméretet, ami a D(HE)ater esetében így is történik

Nyilván a konkrétumok nagyon függenek attól is, hogy milyen hardverről beszélünk, de egy 4 processzoros digital ocean instance esetén a 4-szer 100% CPU terhelés eléréséhez SSH (8192 bit) esetén 25-30 req/s kell, HTTPS esetén (4096 bit) 60-65 req/s kell, szóval leginkább azt mondanám, hogy ha 1000 req/s a cél, akkor leginkább a DHE-t kapcsolnám mindenestül. Ugyanakkor arról sem érdemes megfeledkezni, hogy a támadás védhető rate limitinggel, amihez vannak is Fail2Ban konfigok a D(HE)ater GitHub oldalán.

haproxy-t tesztelek egy 2 CPU-s VM-ben,de elég nagy req/s megy be és a haproxy nem akar igazán "túlterhelődni".

 

### Summary

    * Thread num: 8
    * Protocol: tls
    * Address: 10.2.66.88
    * IP: 10.2.66.88
    * Port: 443
^C
### Statistics

* Requests
    * Total request num: 36352
    * Total speed: 635.28 req/s
    * Average failed ratio: 0.00 %
    * Average succeeded ratio: 100.00 %
* Bandwith
    * Total upload: 52.73 KB/s
    * Total download: 0.00 KB/s

 

Ezzel a req/s-el a két szálon futó haproxy úgy 20% CPU-t eszik magonként.

Mit csinálok rosszul?

16 szálon :

### Summary

    * Thread num: 16
    * Protocol: tls
    * Address: 10.2.66.88
    * IP: 10.2.66.88
    * Port: 443
^C
### Statistics

* Requests
    * Total request num: 73984
    * Total speed: 2545.97 req/s
    * Average failed ratio: 0.00 %
    * Average succeeded ratio: 100.00 %
* Bandwith
    * Total upload: 211.32 KB/s
    * Total download: 0.00 KB/s

 

56% magonként kb

1881713 haproxy   20   0  203152  81372  13228 R  56.3   2.0   0:27.19 haproxy
1881710 haproxy   20   0  203152  81372  13228 R  54.0   2.0   0:27.98 haproxy

Mondjuk a haproxy szerint csak 163req/s megy be ilyenkor és én hiszek neki. Az már problémásabb ha erre 50% CPU pörög....

 

echo "show info" | nc -U /run/haproxy/admin.sock | grep Ssl
MaxSslConns: 0
CurrSslConns: 16
CumSslConns: 18894
SslRate: 154
SslRateLimit: 0
MaxSslRate: 163
SslFrontendKeyRate: 0
SslFrontendMaxKeyRate: 0
SslFrontendSessionReuse_pct: 100
SslBackendKeyRate: 0
SslBackendMaxKeyRate: 0
SslCacheLookups: 0
SslCacheMisses: 0

Szerkesztve: 2021. 11. 06., szo – 22:57

-