UN Open Source Week 2025 probíhá tento týden v sídle Organizace spojených národů v New Yorku. Středeční a čtvrteční jednání bude možné sledovat na UN Web TV.
Byla vydána nová verze 2.50.0 distribuovaného systému správy verzí Git. Přispělo 98 vývojářů, z toho 35 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Infrastrukturu pro chatovací aplikaci Telegram provozuje člověk s vazbami na ruské zpravodajské služby. Upozorňují na to investigativní novináři z redakce iStories. „Vedneev dodává služby ruskému státu včetně jeho jaderného institutu nebo zpravodajské službě FSB,“ říká v podcastu Antivirus novinář Jan Cibulka. Uživatelům, kteří si chtějí své informace chránit, doporučuje Telegram vůbec nepoužívat, a raději zvolit jednu z alternativ, WhatsApp nebo Signal.
The Trump Organization spustila ve Spojených státech mobilní síť Trump Mobile s neomezeným tarifem The 47 Plan za 47,45 dolarů měsíčně a představila vlastní značku telefonů The T1 Phone s Androidem za 499 dolarů.
Vývojáři KiCadu se na svém blogu rozepsali o problémech KiCadu v desktopových prostředích nad Waylandem. KiCad běží, ale s významnými omezeními a problémy, které podstatně zhoršují uživatelský komfort a vývojáři je nedokážou vyřešit na úrovni KiCadu. Pro profesionální používání doporučují desktopová prostředí nad X11.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Byla vydána (𝕏) nová verze 2025.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Dánské ministerstvo pro digitální záležitosti má v plánu přejít na Linux a LibreOffice [It's FOSS News].
V úterý Google vydal Android 16. Zdrojové kódy jsou k dispozici na AOSP (Android Open Source Project). Chybí (zatím?) ale zdrojové kódy specifické pro telefony Pixel od Googlu. Projekty jako CalyxOS a GrapheneOS řeší, jak tyto telefony nadále podporovat. Nejistá je podpora budoucích Pixelů. Souvisí to s hrozícím rozdělením Googlu (Google, Chrome, Android)?
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.101 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.101 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
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:443Zde mi na localhostu lítají nešifrovaná data
tcpdump tcp dst port 556 -vvvnezachytí ani jeden paket, napadá někoho proč? (otázka číslo 1 :)
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.
nc -l -p 1212 | nc seznam.cz 80 | nc -b -l -p 1212zde 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...
Tiskni
Sdílej:
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é.
Aha, no, pak mi ale unika, proc to delasTo 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.
nc -l -p 1212 | nc seznam.cz 80 | nc -b -l -p 1212Asi 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.
-b allow UDP broadcastsPotreboval bych spis neco jako
mkfifo fifo ; nc -l -p 1212 < fifo | nc www.seznam.cz 80 > fifocili , 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.
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).
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.
1112 stream tcp nowait root /usr/sbin/tcpd /bin/netcat 127.0.0.1 1113problé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
#!/bin/sh read data echo $datakdybych uměl načíst komplet stdin tak by nebyl problém si na to napsat wrapper...
#!/bin/sh while read line do echo $line > /tmp/qqq done
1112 stream tcp nowait root /usr/sbin/tcpd "/bin/netcat 127.0.0.1 1113 | sed --unbuffered 's/JOHNY/'XXXX'/g'"
/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 procesuJe to jenom takova idea, nezkousel jsem to. Nevim, jestli ty presmerovani STDIN a STDOUT pomoci
<&0
a >&1
jsou spravne a budou fungovat.
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 :(
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] inetdTakze 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 | catspusti po pripojeni na port 1112 nasledovny:
18898 ? Ss 0:00 /usr/sbin/inetd 18903 ? Ss 0:00 \_ netcat 127.0.0.1 80 | catzase 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 \_ catA 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 fileZ 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.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.
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 :(
/root/filter
s obsahem:
#!/bin/bash cat | nc 127.0.0.1 1113 | cata 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 \_ catPokud 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.
1112 stream tcp nowait root /usr/sbin/tcpd /root/filtera restartuj inetd
/etc/init.d/inetd
(pripadne openbsd-inetd
na debianu nebo jiny inetd)
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.