Protokoll lehallgatás SSL-n keresztül

Sziasztok, következő a szitu:

Adott egy program, amely egy szerverrel kommunikál a 443-as porton (azaz SSL), viszont nem webszerver. Nyilván egy wireshark mit sem tud kezdeni a csomagok tartalmával, hiszen a szerver privát kulcsa nélkül nem tudom visszafejteni az adatokat. Szeretném kideríteni, hogy HOGYAN kommunikál a kliens a szerverrel.

Az ötletem az volt, hogy csinálok egy SSL szervert (openssl s_server ...), átirányítom a cél IP-t az általam létrehozott szerverre, és látom, hogy a kliens milyen adatot küld. Ezután egy klienssel (openssl s_client ...) csatlakozok az eredeti szerverhez, elküldöm azt, amit a lokális szerveren kaptam a programtól, és megkapom rá a választ. Eddig meg is vagyok.

Ámde ezt szeretném automatizálni (azaz ne kelljen csomagonként ezt eljátszanom), vagy még jobb egy olyan környezetet kialakítani, amelyet wireshark-al tudok monitorozni. Alapvetően azt szeretném elérni, hogy egy teljesen transzparens réteget húzzak a program és az eredeti szerver közé.

Az ncat és openssl -l próbálok bűvészkedni, de nem jutok egyről a kettőre. Főleg az a gondom, hogy az ncat -nek egyszerre nem tudom használni az SSL támogatását és a szkript végrehajtást / session output-t.

Röviden mit szeretnék elérni: Egy meglévő SSL-es szerver-kliens közé tenni egy általam létrehozott SSL-es kliens-t és szervert, amelyek megfelelő irányban továbbítják az adatokat. Ekkor már az általam létrehozott szerver privát kulcsával (jól gondolom?) belenézhetek a csomagokba.

Tudtok valamit javasolni? Köszi.

Update: openssl s_client és openssl s_server illetve a megfelelő IP forward beállítások mellett szépen tudok kommunikálni a szerverrel és a klienssel is plaintext-ben (legalább az account jelszavát titkosítva küldik...). Ebből az következik, hogy se kliens-oldali, se szerver-oldali azonosítás nincs. Most a socat tool-al próbálkozok, ígéretesnek tűnik, mert tud shell-scriptet futtatni SSL mellett ami így első ránézésre elég lesz nekem. Ha van fejlemény, megírom.

Megoldás:
A megoldás csak olyan esetben működik, amikor nincs kliens oldali és szerver oldali azonosítás! A lenti megoldáshoz feltételezzük, hogy a valós szerver (REALS) címe 1.2.3.4 és mint mondtam, a szolgáltatás a 443-as porton üzemel. A valós kliens (REALC) tehát ehhez kapcsolódik. A megoldás módszere az, hogy létrehozunk egy SSL klienst (VIRTUALC) és szervert (VIRTUALS), és biztosítjuk, hogy kétirányú kommunikáció történjen REALC <-> VIRTUALS, VIRTUALS <-> VIRTUALC és VIRTUALC <-> REALS között. Másrészt el kell térítenünk a valós forgalmat, hogy rajtunk menjen keresztül. Na nézzük:

1. REALS certificate-jének beszerzése
$ openssl s_client -host 1.2.3.4 -port 443, majd a kapott certificate-t elmentjük a reals.crt fájlba.

2. VIRTUALS certificate készítése

$ openssl genrsa -out server.key 1024
$ openssl req -new -key server.key -x509 -days 3653 -out server.crt
$ cat server.key server.crt > server.pem; rm server.key


3. Forgalomirányítás

$ sudo iptables -t nat -A OUTPUT -p tcp --destination 1.2.3.4 -j DNAT --to-destination 127.0.0.1:4000
$ sudo iptables -t nat -A OUTPUT -p tcp --destination 10.10.10.10 -j DNAT --to-destination 1.2.3.4:443

A második irányítást nemsoká látjuk, hogy miért is kell.

4. VIRTUALC és VIRTUALS beizzítása

$ socat -v SSL:10.10.10.10:443,cafile=reals.crt SYSTEM:"openssl s_server -accept 4000 -cert server.pem -no_dhe -no_ecdhe" 2> txrx.log

A socat-nek nem jó az SSL-LISTEN módja a jobb oldalra, mert valami miatt több egymás utáni kapcsolatot nem volt képes kezelni még a fork,reusaddr kombóval sem. Másrészt a bal oldalra nem írhatjuk a valós szerver címét (1.2.3.4), hiszen a forgalomirányítás miatt egy körkörös láncot kapnánk. Ezért kellett bevezetni egy új címet, és azt irányítani a valós címre.

Ez a megoldás ha jól gondolom (javítsatok ki, ha nem) használható MITM támadásra is, amennyiben a forgalomirányítást meg lehet csinálni az adott hálózatban, és mint mondtam, nincs kliens oldali és szerver oldali azonosítás (amely sajnos nagyban igaz).

Huhh, sokat tanultam ma is. :) Használjátok egészséggel, saját felelősségre.