Stunnel / netcat - odchyt/modifikace paketů

16.3.2008 22:25 | Přečteno: 2311× | Linux - readonly debian pro routery | poslední úprava: 16.3.2008 22:26

Dělám pokusy s úpravou síťové komunikace abych dokázal jisté mé tvrzení - aneb že lze za předpokladu podvržení falešného certifikátu upravit data tak, aby "napadený" nic nepoznal. Snažím se upravit paket který "letí" skrz nějaký router. Moje současné nastavení předpokládá příchozí data v SSL na port 443, tato data si ukradnu pomocí iptables a pošlu je na port 555 kde jede stunnel...

z portu 555, vyhodím ssl a pošlu na 556
stunnel -d 555 -r 556

naslouchám na 556 a posílám na cílovej server
stunnel -c -d 556 -r X.X.X.X:443

Zde mi na localhostu lítají nešifrovaná data
Dále bych rád data nějak zobrazil. Ačkoliv tcpdump funguje super tak v tomto případě nějak selhává, nenapadá mě vubec proč.

tcpdump tcp dst port 556 -vvv

nezachytí ani jeden paket, napadá někoho proč? (otázka číslo 1 :)
připustím li, že data se podaří zachytit tak je třeba je upravit a poslat dál, k tomuto účelu jsem dělal pokusy s netcatem, "zbastlil" jsem si tento příkaz

nc -l -p 556 | nc 127.0.0.1 557 | nc -b -l -p 556
na 557 v tomto případě byl druhý konec stunnelu.

Tento příkaz bych očekával že vezme data z portu 556 (nešifrované http), přepošle je netcatu který udělá request na druhý stunnel a odpověď vrátí zpět na 556.
Bohužel takto se mi zde nepovedlo komunikaci rozjet :( (any idea? otázka číslo 2)
Pokud tento příkaz testuji bez stunnelů, tedy jenom jako "jednoduchou proxy" tak to funguje.

nc -l -p 1212 | nc seznam.cz 80 | nc -b -l -p 1212

zde mi při požadavku na ipadresarouteru:80 hodí opravdu stránku seznamu. Zdá se že nudejchá víc spojení (to je také otázka č3 k řešení...)

No, a to jsou veškeré mé dosavadní poznatky. úpravu komunikace bych pak rád dělal začleněním sedu do toho netcatu...
dík za jakékoliv nápady, podněty :)

ps: jde skutečně jen o důkaz že to takto jde, tak nemusíte mít strach, nejdu vyloupit banku :D

       

Komentáře

[Stevko]

A na správnom interface púšťaš tcpdump (to je len taký prvý nápad, prečo by nemusel zachytiť). Na lo ho možno treba pustiť.

[Johny z Podoli]

dík, lo jede :))) sem já blbec naslouchal na eth, na to sem si mohl přijít sám :)) bože.

[Michal Kubeček]

Ono je chování tcpdump trochu záludné (i když naštěstí zdokumentované): neuvedete-li interface, poslouchá na prvním, který najde kromě lokální smyčky. A vy tady potřebujete právě tu lokální smyčku. Nejjistější je navyknout si specifikovat interface pokaždé.

[Abraxis]

A o co se vlastne snazis? Pokud ti jde o to protunelovat cely inetovy provoz pres jeden TCP (UDP) port, tak muzu vrele doporucit OpenVPN (zrovna pres nej jedu a je to fakt bomba - za pul hodinky rozchozene - server CentOS 5.0, klienti MacOS a WinXP).

[Johny z Podoli]

snažím se vzít jedno https spojení, vyhodit ssl, upravit nějak data, zase zabalit do ssl a poslat na server. A to všechno chci udělat tak, aby to krom falešného ssl certifikátu bylo zcela transparentní :)

[Let_Me_Be]

Hmm, a proc se o to snazis? Pokud spravne chapu, tak utocis na neco co neni vubec zajimave a pokud se nepletu tak to obvykle ssl ani neresi.

[Johny z Podoli]

nerozumim. Snažim se někomu ukázat že to tak lze, nic víc nic méně. Mám https, z něj si udělám http, pak jej chci [nějak] pozměnit a zase přehodím do https, nerozumím čemu nerozumíš.

[Vašek Lorenc]

Není lepší použít třeba existující nástroje? Např. webmitm nebo sshmitm z balíčku dsniff?

[Johny z Podoli]

to právě není to, co hledám. Rád bych si ten postup právě udělal "na koleni" abych demonstroval step by step co se děje. nepotřebuji nic co pustím a ono to všechno pojede. Ale dík za zajímavej tip, i tak si to projdu.

[Michal Kubeček]

Prostě si chce prakticky vyzkoušet man-in-the-middle attack v případě, že není ověřován veřejný klíč protistrany.

[Johny z Podoli]

dík za jasnej a stručnej výklad :D

[Let_Me_Be]

Aha, no, pak mi ale unika, proc to delas To ze to takhle jde udelat je dost well-known. Proto se taky overuje zda klic sedi k domene a nezmenil se od posledni navstevy, kdyz nekam lezes.

Ale jo, taky delam spoustu hovadim (treba pisu do tehle diskuze, kdyz bych mel pracovat [nebo spat]).

[Michal Kubeček]

Aha, no, pak mi ale unika, proc to delas To ze to takhle jde udelat je dost well-known.

U některých lidí je velmi užitečné jim prakticky předvést, jak je to jednoduché. Sám jsem to na školeních začal předvádět a ze zkušenosti mohu říct, že je to mnohem účinnější než samotný teoretický výklad principu.

[Let_Me_Be]

Jo, to souhlas. Ja mam ted zase nejake prilis zvidave obdobi (no, snad to prejde).

[petr_p]

nc -l -p 1212 | nc seznam.cz 80 | nc -b -l -p 1212

Asi máte kouzelný netcat, protože si nedokážu představt, jak se výstup toho prostřední netcatu (HTTP odpověď) dostane zpátky do TCP spojení mezi prvním netcatem a HTTP klientem a odešle se tak klientovi.

[Johny z Podoli]

od toho tam je to -b, které řiká že broadcast

[CET]

Uch, ale to je UDP broadcast, ne? Navic taky moc nechapu, co ma broadcast spolecnyho s presmerovanim vstupu a vystupu.

-b allow UDP broadcasts

Potreboval bych spis neco jako

mkfifo fifo ; nc -l -p 1212 < fifo | nc www.seznam.cz 80 > fifo

cili , vystup z prvniho nc presmerovat na vstup druhyho nc a pak pres "fifo" predat vystup z druhyho nc na stdin prvniho nc. A kdyz tohle spustis a pak das nc localhost 1212, tak by to melo spravne komunikovat se seznamem.

[petr_p]

Asi ne, Time. Doporučuji nc -l -p 1212 -c 'nc seznam.cz 80'.

Ostatně toto je klasický problém shellu, který propojuje jen dva předdefinované deskriptory. I když doufám, že nějaký rozumný shell bude umět poskládat nepojmenované roury, jak potřebuje uživatel (něco jako nc -l -p 1212 0<!roura | nc seznam.cz 80 1>!roura, kde roura by byl identifikikátor, kterým by se odkazovalo na onu nepojmenovanou rouru).

[RoboShim]

Muzes mrknout na tenhle zapisek.

http://www.abclinuxu.cz/blog/RoboShim/2007/12/jednoducha-ha-proxy-na-linuxuhttp://www.abclinuxu.cz/blog/RoboShim/2007/12/jednoducha-ha-proxy-na-linuxu

Resil jsem tam prakticky to samy, ale pro LDAP. Prichozi LDAPS se rozsifruje, preda se rizeni skriptiku a ten nastartuje openssl dal - spojeni na localhost:390 jde nesifrovany. Nemam tam nabourani se pomoci iptables, ale to je detail, ja mam primo adresu toho serveru.

[RoboShim]

eee, URL je zdvojeny - sorry, spravne je to http://www.abclinuxu.cz/blog/RoboShim/2007/12/jednoducha-ha-proxy-na-linuxu

[CET]

Teorie je spravne, zpracovani taky spravny. Mozna bys to pro HTTP/HTTPS mohl resit trebas i pouzitim apache v proxy modu, treba i s rewritem, ale mouzes ject i na stunnelu.

Jak uz padla odpoved, tcpdump by default posloucha na eth0, ale tobe ta komunikace jede na "lo", takze tcpdump -i lo.

Problem v otazce 2 bych videl v nespravnym postupu - ten nc -b je podle me nesmysl. Jak jsem psal, chtelo by to spis mkfifo fifo ; nc -l -p 556 < fifo | nc 127.0.0.1 557 > fifo (overil jsem to ted a funguje). Zkousel jsem ted ten tvuj zapis s nc -b a nefunguje mi. Takze to nebude ono.

K otazce cislo tri: vubec nechapu, jak se ti mohla zobrazit stranka seznamu, me to vubec nejede.

Jinak bych mozna doporucoval zapojit jeste xinetd/inetd. Mohl bys to pak resit

iptables redirect -- stunnel -- xinet (bash skript) -- openssl

Iptables by udelal redirect na stunnel. Stunnel by desifroval spojeni a plaintext predal na xinet, ktery by na urcitym postu pustil bash skript (nebo perl, python, c) - vyhoda je, ze ten skript by cetl data na stdin a posilal na stdout (cili zadna sitova komunikace) a dale pak bys mohl data predavat bud nc smerovany na stunnel nebo primona na openssl s_client.

[Johny z Podoli]

OK, zkouším řešit přes inetd, toto řešení je fakt nápadité a triviální, ještě teď potřebuji vyřešit poslední problém.
na port 1112 inetd mi jde request, já jej vezmu a předám jej na 1113 (super, takto to všechno funguje)

1112            stream  tcp     nowait  root    /usr/sbin/tcpd /bin/netcat 127.0.0.1 1113

problém ale nastává v případě že chci s daty něco udělat (upravit v načtené stránce) slovo JOHNY za XXXXX, logicky by to mohlo být nějak takto.

1112            stream  tcp     nowait  root    /usr/sbin/tcpd /bin/netcat 127.0.0.1 1113 | sed 's/JOHNY/'XXXX'/g'"

bohužel takto inetd na daném portu ani nezačne naslouchat. Tedy, nějaký nápad jak do inet deamonovi vnutit něco co bude ve smyslu nefungujícího příkladu? dík, Johny

[Johny z Podoli]

tady by mi možná pomohlo umět v bashi našíst komplet stdin, pomocí read načtu vždy jen jeden řádek.... :(

#!/bin/sh

read data
echo $data

kdybych uměl načíst komplet stdin tak by nebyl problém si na to napsat wrapper...

[Johny z Podoli]

tak, sice už umím načíst všechno z stdinu ale zde to nějak nechodí. dmesg|mujscript.sh a vše je ok, jakmile ale muj script dam do inetd tak na tom cyklu to timeoutuje. Přítom pokud zakomentuji cyklus a nechám tam třeba "echo ahoj" tak vše jde

#!/bin/sh
while read line
do
echo $line > /tmp/qqq
done

[petr_p]

sed --unbuffered.

[Johny z Podoli]

bohužel, ani tak ten request neprojde. Bez sedu je vše ok, se sedem to je mrtvé.

1112            stream  tcp     nowait  root    /usr/sbin/tcpd "/bin/netcat 127.0.0.1 1113 | sed --unbuffered 's/JOHNY/'XXXX'/g'"

[CET]

Kdyz uz, zkus to nacpat do nejakyho skriptu a z inetd volej primo ten skript. Mam dojem, ze inetd to nespousti pres BASH a pipe je BASHovska vec. Musel bys to spustit napr. /usr/sbin/tcpd /bin/bash -c '/bin/netcat 127.0.0.1 1113 | sed .....' , ale to si spis zpusobis bolesti hlavy. Udelej shell skript s obsahem netcat | sed a ten pak nacpi do inetd.

Ale i tak si myslim, ze to nebude ono. Pokud se nepletu, tak musis vyresit problem:

inetd ---> transform1 ----> netcat 
  ^------- transform2 <------| 

Slovne popsane: z inetd jeho stdout presmerovat do tvyho skriptu na stdin, tam neco nacist a upravit a poslat na stdin netcatu. Vystup stdout z netcatu poslat na stdin tvyho skriptu, neco provest a poslat na stdin inetd. Problem je, ze pokud bys chtel opravdu neco dokonalyho, tak ten tvuj "skript" by mel testovat zaroven vystup z inetu (klient neco posila) i z netcatu (server neco posila) a to neblokujicim zpusobem - proste kdyz neco posle klient NEBO server, tak to precist a predat dal. Mozna by slo nejak nahodit dva ruzny child skripty, kde jeden by upravovat smer inetd->netcat a druhy by upravoval netcat->inetd. Krome pojmenovanych rour (named pipes) me zatim nic nenapada. To by byl skriptik asi takhle:

#!/bin/bash

mkfifo /tmp/stdout-netcat /tmp/stdin-netcat
nc 127.0.0.1 1113 </tmp/stdin-netcat >/tmp/stdout-netcat &
p=$!
sed 'UPRAVY1' <&0 >/tmp/stdin-netcat &
ps1=$!
sed 'UPRAVY2' </tmp/stdout-netcat >&1 &
ps2=$!

# a tady neco na cekani ukonceni
# a pak zabiti tech tri procesu

Je to jenom takova idea, nezkousel jsem to. Nevim, jestli ty presmerovani STDIN a STDOUT pomoci <&0 a >&1 jsou spravne a budou fungovat.

[Johny z Podoli]

situace je v podstatě jednoduší než si uvedl, stačí mi upravit příchozí data, tedy analogie s tím, co mi nefunguje. Script který toto obslouží jsem se snažil vytvořit. Bohužel jsem nenašel způsob jak načíst stdin do toho scriptu. Snažil jsem se toho dosáhnout cyklem (někde výše v diskuzi je můj příklad) ale to také moc nechodilo.
toto funguje, tedy inetd pajpám rozumí ...

1112                stream  tcp     nowait  root    /usr/sbin/tcpd "/bin/netcat 127.0.0.1 1113 | cat"

konstrukce se sedem by měla také fungovat. V podstatě nevidím nejmenší rozdíl když "cat" nahradím sedem, tak sed dělá to samé co cat (pokud nenajde shodu podmínek tak ani nic neupravuje). Proč to tedy se sedem neprojde nechápu :(

[CET]

situace je v podstatě jednoduší než si uvedl, stačí mi upravit příchozí data, tedy analogie s tím, co mi nefunguje.

No, ten obrazek

inetd ---> transform1 ----> netcat 
  ^------- transform2 <------| 

plati, ale da se udelat da se to zapsat taky jako

(*) [stdin] inetd [stdout] --> [stdin] transform1 [stdout] ---> [stdin] netcat [stdout] ---> [stdin] transform2 [stdout] ----> (vrat se na zacatek) (*) [stdin] inetd

Takze viz niz. Osobne si myslim, ze ty si tady ale hrajes stylem "zkusim tohle. hele, ono to NEJAK funguje, tak to bude zrejme spravne". Ale takhle to fakt neni a nemel bys to takhle resit, mel bys presne vedet, proc to funguje, a ze to tak ma skutecne fungovat. Podle man tcpd:

Operation is as follows: whenever a request for service arrives, the inetd daemon is tricked into running the tcpd program instead of the desired server. tcpd logs the request and does some additional checks. When all is well, tcpd runs the appropriate server program and goes away.

Nejsem si jistej ale, jakym zpusobem tcpd spousti ten program. Mozna to spousti prave pomoci bash -c "XXX", pak zapis /bin/netcat 127.0.0.1 1113 | cat funguje a mel by fungovat i sed. Ale zrejme to tak nebude. Zkusil jsem presne ten priklad s tim catem a nefunguje mi. Osobne nechapu, jak ti to muze fungovat, pochybuju, ze mame ruzny verze tcpd. Jsi si jistej, ze po kazde zmene inetd.conf restartujes inetd? Me osobne takhle konfigurace

1112                stream  tcp     nowait  root    /usr/sbin/tcpd "/bin/netcat 127.0.0.1 80 | cat"

udala po pripojeni na ten port 1112 tehle seznam procesu:

18791 ?        Ss     0:00 /usr/sbin/inetd
18801 ?        Ss     0:00  \_ "/bin/netcat 127.0.0.1 80 | cat"

coz vypada presne na ten pripad, ze to tcpd spousti pouze presne jako prikaz, jak to napises. Cili ani uvozovky se neberou jako ohranicujici znaky, ale jako soucast prikazu. Takze, TOHLE JE SPATNE! Dale konfigurace bez uvozovek:

1112                stream  tcp     nowait  root    /usr/sbin/tcpd /bin/netcat 127.0.0.1 80 | cat

spusti po pripojeni na port 1112 nasledovny:

18898 ?        Ss     0:00 /usr/sbin/inetd
18903 ?        Ss     0:00  \_ netcat 127.0.0.1 80 | cat

zase to spousti jako jeden prikaz, nebo teda spis to vypada, ze spusti prikaz netcat a preda mu parametry (1.par="127.0.0.1", 2.par="80", 3.par="|", 4.par="cat"). Tzn. TOHLE JE TAKY SPATNE! Pro tvoji informaci, spravne by ty procesy mely vypadat takhle:

18942 ttyp7    Ss     0:00                          \_ /bin/bash
18946 ttyp7    S+     0:00                              \_ nc 127.0.0.1 80
18947 ttyp7    S+     0:00                              \_ cat

A toho jsem dosahnul tak, ze jsem spustil V BASHi(!!) prikaz nc 127.0.0.1 80 | cat. Takze takhle nejak by to melo vypadat. Zkusil jsem ted i konfiguraci

1112                stream  tcp     nowait  root    /usr/sbin/tcpd /bin/bash -c "/bin/netcat 127.0.0.1 80 | cat"

ale po pripojeni mi to hlasi bash chybu

127.0.0.1: -c: line 0: unexpected EOF while looking for matching `"'
127.0.0.1: -c: line 1: syntax error: unexpected end of file

Z toho nejsem taky moc moudrej. Mozna to bude tim, ze tcpd to zase spusti jako

command: /bin/bash
1.par: -c
2.par: "/bin/netcat
3.par: 127.0.0.1
4.par: 80
5.par: |
6.par: cat"

Cili tcpd nevyhodnocuje text v uvozovkach jako jeden retezec, ale bere uvozovky a apostrofy jenom jako obyc znak a paramatry oddeluje podle mezer.

Script který toto obslouží jsem se snažil vytvořit. Bohužel jsem nenašel způsob jak načíst stdin do toho scriptu. Snažil jsem se toho dosáhnout cyklem (někde výše v diskuzi je můj příklad) ale to také moc nechodilo.
toto funguje, tedy inetd pajpám rozumí ...

1112                stream  tcp     nowait  root    /usr/sbin/tcpd "/bin/netcat 127.0.0.1 1113 | cat"

konstrukce se sedem by měla také fungovat. V podstatě nevidím nejmenší rozdíl když "cat" nahradím sedem, tak sed dělá to samé co cat (pokud nenajde shodu podmínek tak ani nic neupravuje). Proč to tedy se sedem neprojde nechápu :(

No, jak jsem psal, me to nechodi ani s tim catem, ani kdyz to nacpu jako bash -c "...", bohuzel s tim bash -c se to chova naprosto stejne i v xinetd. Ale myslim, ze jsem na to prisel. Zkus udelat presne tenhle postup, aspon me to funguje.

• Vytvorit script /root/filter s obsahem:

  #!/bin/bash
  
  cat | nc 127.0.0.1 1113 | cat
  

  a udelej ho spustitelny chmod a+x /root/filter. Muzes ho pripadne otestovat, na prikazovej radce spust /root/filter. Muzes se podivat taky do procesu ps faxw a mel bys videt

  19360 ?        Ss     0:00  \_ /bin/bash /root/filter
  19361 ?        S      0:00      \_ cat
  19362 ?        S      0:00      \_ nc 127.0.0.1 1113
  19363 ?        S      0:00      \_ cat
  

  Pokud tam zacnes psat, mel bys videt spravnou odpoved. Ty prikazy cat muzes nahradit samozrejme sed/awk/perl. Prvni cat slouzi k uprave komunikace od klienta na server, druhy cat pak meni odpoved od serveru ke klientovi.
• do inetd.conf dej konfiguraci

  1112                stream  tcp     nowait  root    /usr/sbin/tcpd /root/filter
  

  a restartuj inetd /etc/init.d/inetd (pripadne openbsd-inetd na debianu nebo jiny inetd)

Kdyz jsi to takhle pripravil, tak zkus ten udelat nc 127.0.0.1 1112 a melo by to fungovat. U me to aspon funguje, dal jsem menit odpoved od HTTP serveru a funguje to.