A történet úgy kezdődött, hogy megelégeltem a YouTube user szemszögéből számomra destruktív változásait (blur UI, 1080p minőség lekorlátozását bizonyos videókra, adblocker utálat stb.). Főleg a reklámok irritáltak, meg az a döntésük, hogy aki nem Chromeot használ, azt lassítják. Gondoltam előfizetek, de azzal az a probléma, hogy az előfizetés fiókhoz kötött. Be kell tehát lépni ahhoz, hogy reklámmentesen menjen. Azt viszont nem szerettem volna, ha követik a megtekintési előzményeim. Szerencsére ezt ki lehet kapcsolni, viszont akkor egyáltalán nem ajánl népszerű videókat sem. Privát ablakban viszont lazán dobálgat érdekes tartalmakat objektívebben.

Kicsit betelt a pohár, de szembejött velem egy profi alternatíva, a Piped. Gyakorlatilag egy nyílt forrású frontend + YouTube proxy, amit felraksz egy szerverre és egyrészt anonymizálja valamennyire a forgalmat, mert a YouTube csak annyit lát, hogy a szerver IP-ről érkeznek kérések, másrészt meg lehet szabadulni a YouTube féle sallangoktól és kap az ember egy piszok gyors felületet a lényeggel.

"Hátránya", hogy reklámmentesít is, így a YT tűzzel-vassal próbálja ellehetetleníteni. Hogy az átlag user is tudja használni, léteznek publikus instanceok, amiket önkéntesek üzemeltetnek, amiknek az IP címeit szinte naponta kitiltja a streamingóriás, hiszen azt látja, hogy sok egyidejű stream fut egy címről.

Erre a Piped csapat válasza az volt, hogy akkor használnak IPv6 címeket, hiszen ilyet viszonylag egyszerű nagyobb mennyiségben szerezni. Aztán ha a YT kitiltja az egyik IPv6-os címüket, váltanak másikra. Erre van is egy szkript, ami itt található: [link].

Nem titok, hogy saját célra én is futtatok Piped szervert, amit én és a szűk baráti kör használ. Amíg csak én használtam, nem voltak gondok, de a gyors és sallangmentes YouTube lehetősége hamar népszerű lett a baráti körben, szóval az én IP címem is letiltotta a streaming óriás. Megoldás után kellett tehát néznem.

Figyelem! Spoiler következik! Ha szeretnéd próbára tenni a networking tudásod, akkor javaslom, hogy töltsd le a feladat forrását innen, ne nyisd le a writeup spoiler részét, buildeld le a kihívást és próbáld meg megkeresni a flaget.

A Cloudflare törős cikkem kapcsán már írtam a tunnelbroker szolgáltatásról. Lényegében adnak egy /48-as IPv6 blokkot ingyen, ami egyrészt rengeteg IPv6-os címet jelent, másrészt bármikor lehet új címet kérni, ha a régi tartományt tiltanák.

Az oldalukra regisztrálva még mintakonfigot is adnak, amivel fel lehet húzni egy network interface-t és lehet használni a hozzánk rendelt címeket:

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.88.98 local 144.x.x.x ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:titkos::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

Igen ám, de ez így egy elég alap konfig. A gép címe örökre a 2001:470:titkos::2 lesz, ami nem feltétlen ideális. A maintainerek által javasolt szkript gyakorlatilag csak ezt az IP címet cseréli le időnként, viszont ez elég drasztikus, mert ha épp akkor cserélne a szkript IP-t, amikor valaki még nézné az adást, akkor az ő streamjét is megszakítjuk. Meg még mindig nem ideális, hiszen az összes user egyetlen IPv6-ról fogja nézni az adásokat...

Szerencsére találtam egy tök jó cikket, ahol egy Discord bot fejlesztő igyekezett áthidalni a YouTube ban problémát hasonló módon: [link]. Itt gyakorlatilag annyit javasol a szerző, hogy kiadva a következő két parancsot:

echo 'net.ipv6.ip_nonlocal_bind = 1' >> /etc/sysctl.conf
ip -6 route replace local YOUR_48_BLOCK dev lo

A teljes /48-as IPv6 blokk használható lesz az összes futó alkalmazás számára, szabadon bindolhatnak rá és használhatják hálózati forgalom lebonyolítására.

Ez a megoldás megtetszett, rögtön eszkábáltam is egy squid + haproxy alapú round robin (azaz egymás után felváltva váltogatva az IPv6 címeket) proxyt. Az elképzelés egyszerű volt. Squiddel meg tudtam mondani, hogy az adott proxynak mi legyen a kimenő IP címe, illetve meg tudtam mondani, hogy hanyas porton fusson. 128 ilyen portot tudtam lefoglalni és mindre egy random IPv6-ot használt. Majd haproxy-n belül definiáltam ezt a 128 portot és az végezte a rotációt, hogy egymás után legyenek használva a portok. Végül a haproxy egyetlen portot foglalt le magának, ahova beérkezett a forgalom, majd innen ment tovább a squidhez, a squid pedig küldte a tunnelbroker felé a forgalmat.

[+] A setup

Sikeresen elértem ezzel azt, hogy ha egyszerre ketten néztek valamit, akkor mindig más IP-ről indult a lejátszás. Igen ám, de elég kényelmetlen volt erre beáldozni 129 portot (128 a squidnek és 1 a haproxynak). Illetve nem volt túl optimális sem, hiszen még mindig csak egy statikusan beégetett 128 IPv6 címből álló listát tudok hasznosítani, amikor a blokkom jóval nagyobb ennél.

Először jött tehát az ötlet, hogyha a squid tud nekem bindolni tetszőleges IPv6-ra, akkor én is tudok olyan szoftvert írni, ami ugyanezt megcsinálja nekem és készít egy proxyt a megoldásból. Ahogy ezt írtam szembesültem azzal, hogy fogalmam sincsen, hogyan működnek a forward proxyk. Sima HTTP forgalom esetében tök egyszerű a megvalósítás, hiszen ki tudjuk olvasni nyersen, hogy mit és hova kell küldeni. HTTPS forgalomnál már nem ilyen egyszerű a megoldás, hiszen azt szeretnénk elérni, hogy a proxy csak továbbítsa a forgalmat, ne titkosítsa újra.

HTTP esetében tök egyértelmű, hogy mi történik:

[steve@todo src]$ curl -v -x 'http://localhost:1337' http://google.com
* Host localhost:1337 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
* Trying [::1]:1337...
* connect to ::1 port 1337 from ::1 port 41104 failed: Connection refused
* Trying 127.0.0.1:1337...
* Connected to localhost (127.0.0.1) port 1337
> GET http://google.com/ HTTP/1.1
> Host: google.com
> User-Agent: curl/8.7.1
> Accept: */*
> Proxy-Connection: Keep-Alive
>
* Request completely sent off

Viszont HTTPS esetén egy CONNECT HTTP kérés történik:

* Host localhost:1337 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
* Trying [::1]:1337...
* connect to ::1 port 1337 from ::1 port 55998 failed: Connection refused
* Trying 127.0.0.1:1337...
* Connected to localhost (127.0.0.1) port 1337
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/8.7.1
> Proxy-Connection: Keep-Alive

Ami alig tartalmaz adatot, csak annyit, hogy hova menjen a kérés és a többi forgalom mehet titkosítva a proxy és a kliens között. Tök érdekes és logikus megoldás, viszont erről a CONNECT HTTP methodról most hallottam először, ezért beletelt egy kis időbe, mire sikerült implementálni.

De a végeredmény egy elég spagetti, de működő proof of concept megoldás lett arra, hogy megoldható a teljes IPv6 tartomány rotálása és felhasználása HTTP és HTTPS forgalom továbbítására egyaránt. A kódra nem vagyok büszke, nem is a szépség volt a cél, de felraktam ide megtekintésre: [link]

Ez a megoldás tök jól működik a mai napig, használja a teljes IPv6 blokkom és alig jelent extra overheadet, viszont eléggé zavart, hogy függünk a kerneltől, interfészeket hozunk létre és ehhez túl sok jogosultságra van szükség a konténeren belül, ahol a proxy fut. Ha feltöri valaki, akkor egyszerűen szerezhet magának root jogot a gépemen.

Gondoltam én kis naív, hogy nem muszáj nekem a kernel által adott tunnel támogatást használni, meg interfaceket, hiszen mi akadályozna abban, hogy mindent szoftveresen oldjak meg? Interfészre sincs szükségem, hiszen csak egy alkalmazásból használnám a v6-os blokkot. Szóval technikailag egyetlen távoli IPv4 címmel kellene beszélgetni, amihez azt feltételeztem, hogy nincs szükség root jogokra. Hiszen TCP-n és UDP-n is meg lehet ezt tenni minden további nélkül. Adatot akarok küldeni az 1.1.1.1 felé? Semmi gond, meg lehet tenni.

Node, halvány fogalmam nem volt arról, hogy mi ez a sit tunnel, amit a tunnelbroker használ, és hogyan működik a gyakorlatban a kommunikáció. Elkezdtem keresgélni a neten, de alig találtam használható leírást arról, hogy mi ez az egész, pár RFC-n kívül, amiből egy szót sem értettem. A legtöbb találat gyakorlati példa volt arra, hogy hogyan lehet sit tunnelt használni különböző OS-eken.

Arra rájöttem, hogy a forgalomra az IP protocol 41 van használva, elkezdtem tehát githubon keresgélni az ip4:41 kulcsszóra, hiszen Goban így lehet erre a protokollra bindolni és mostanában átszoktam arra, hogy minden proof of conceptet Go-ban írok a Python helyett. Találtam is egy érdekes projektet: [link], ami messze nem az, amit én keresek, de kb ez volt az egyetlen értelmes resource az egész Githubon Go-ban, ami hasonló protokollt piszkálgat.

Sajna ezzel se voltam kisegítve, hiába próbálkoztam, sehogy nem sikerült megérteni a dolog működését. Ekkor jutott eszembe, hogy van nekem egy már működő network stackem a linux kernelben, szóval talán az lenne a legegyszerűbb, ha csinálnék egy tunnelt, majd megnézném, hogy hogyan épül fel a kapcsolat wiresharkból nézve.

Gyorsan fel is húztam egy tunnelt:

[root@todo steve]# ip tunnel add test mode sit remote 127.0.0.1 local 127.0.0.1 ttl 255
[root@todo steve]# ip link set test up
[root@todo steve]# ip addr add 2001:470:6d:d6::1336/64 dev test
[root@todo steve]# ip a show dev test
4: test@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 65516 qdisc noqueue state UNKNOWN group default qlen 1000
link/sit 127.0.0.1 peer 127.0.0.1
inet6 2001:470:6d:d6::1336/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::7f00:1/64 scope link
valid_lft forever preferred_lft forever
[root@todo steve]# ip -6 route add default dev test
[root@todo steve]#

Nem igazán érdekelt, hogy a saját gépemre mutat, ahol nincs szerver, ami fogadná a csomagokat, csak az érdekelt, hogy mit küldök, szóval ez tökéletesnek bizonyult. Aztán elkezdtem pingelni egy random IP-t:

ping 2001:470:6d:d6::1

Majd ránéztem wiresharkra, ahol a következőt láttam:

Megmondom őszintén, hogy elsőre elborzasztott a látvány, hiszen sosem raktam még össze csomagokat kézzel, fogalmam sincs, hogy mit jelentenek az egyes értékek, hogyan tudom ezeket felépíteni stb. Egyetemen sokszor riogattak minket az elméleti háttérrel, ahol hasonló datagrammokat kellett megtanulni:

De a gyakorlatban sosem kérték számon és a tanárok többsége is úgy állt hozzá, hogy egy programozónak nem kell mindent fejből tudnia, elég csak pár mező jelentését tudni a vizsgán, ezért én sem vettem soha komolyan ezeket. Kb a jelenlegi probléma során ástam bele magam először a topikba és jöttem rá, hogy mennyire fontos dolog ez.

Node a lényeg. Térjünk vissza a korábbi képre, ahol az látszik, hogy van egy keret, ami magába foglal egy Ethernet réteget. Logikus, hiszen ethernet interfacere küldtem a csomagot. Majd van egy IPv4 réteg, ez látszólag annyi érdekeset tartalmaz, hogy honnan hova megy a csomag (tőlem a tunnelbroker IPv4 felé), illetve azt mondja meg, hogy a protokoll 41, ami IPv6 tunnellingre enged következtetni. Majd ebbe van csomagolva egy szabályos IPv6 réteg, amit egy ICMPv6 réteg követ, hiszen pingeltünk a tunnelt használva.

Magyarul a következő rétegeket kellene összerakni kódból: IPv4(IPv6(ICMPv6()))

Hogy sikeres legyen a pingünk.

Pythonhoz szerencsére van egy tök jó library, a scapy, amivel pikk-pakk összedobtam a kódot, ami elküld egy pinget a tunnelbroker felé, és wiresharkból látszik, hogy az válaszol is:

from scapy.all import send
from scapy.layers.inet import IP
from scapy.layers.inet6 import IPv6, ICMPv6EchoRequest

def main():
local_ipv4_addr = "10.13.120.93" # saját interface-m forráscíme
remote_ipv4_addr = "216.66.86.114" # tunnelbroker szerver címe

local_ipv6_addr = "2001:470:titkos::2" # tetszőleges cím a kapott tartományból
remote_ipv6_addr = "2001:470:titkos::1" # a ::1 végű cím mindig a tunnelbrokeres routeré, így erre megy a ping, hiszen ez válaszol, ha jól dolgoztunk

ip4_layer = IP(src=local_ipv4_addr, dst=remote_ipv4_addr, proto=41, ttl=255, version=4)
ip6_layer = IPv6(version=6, src=local_ipv6_addr, dst=remote_ipv6_addr)

icmp6_layer = ICMPv6EchoRequest()

packet = ip4_layer / ip6_layer / icmp6_layer

send(packet, iface="wg0")

print(packet.show(dump=True))

print("6in4 packet sent")

if __name__ == "__main__":
main()

Gyakorlatilag pár sor kóddal sikerült is pinget küldeni, ráadásul még azt is sikerült megoldani, hogy VPN-en keresztül menjen a teljes forgalom a tunnel felé. Viszont ekkor szembesültem vele, hogy root nélkül már a Python kód sem működött. Arra jöttem rá, hogy root nélkül a kernel nem engedi az IP Protocol 41 használatát, mivel a protokoll segítségével elég könnyen lehet IPv6 forrás és célcímeket spoofolni, amivel meg lehetne kerülni tűzfalakat és sok kártékony tevékenységet véghez lehetne vinni IP spoofinggal. Például valaki csinálhat egy tűzfal szabályt arra, hogy csak a 2a00:1450:4001:811::200e cím érheti el a gépet SSH-n (Google egyik IPv6 címe). IP protocol 41-gyel viszonylag egyszerűen lehetne olyan csomagokat küldeni, amik látszólag erről a forráscímről jönnének, viszont mégsem a Google küldte azokat. Érthető tehát, hogy nem engedik, viszont elég kellemetlen hír ez számomra...

Node úgy döntöttem, hogy ennek ellenére megpróbálom összehozni ugyanezt Go-ban és leváltom a jelenlegi, kernelre erősen támaszkodó megoldásom. Szerencsére a Google-nek van egy egész jó könyvtára, amivel a scapy-hez hasonlóan tudunk csomagokat kézzel összerakni, gopacket a neve.

A következő kódot dobtam össze:

package main

import (
"fmt"
"log"
"net"

"github.com/google/gopacket"
"github.com/google/gopacket/layers"
)

func main() {
conn, err := net.ListenPacket("ip4:41", "0.0.0.0")
if err != nil {
log.Fatal(err)
}
defer conn.Close()

localIPv4Addr := net.ParseIP("10.13.120.93")
remoteIPv4Addr := net.ParseIP("216.66.86.114")

ip4Layer := &layers.IPv4{
SrcIP: localIPv4Addr,
DstIP: remoteIPv4Addr,
Protocol: layers.IPProtocolIPv6,
TTL: 255,
Version: 4,
Flags: 0x0,
}

localIPv6Addr := net.ParseIP("2001:470:titkos::2")
remoteIPv6Addr := net.ParseIP("2001:470:titkos::1")

ip6Layer := &layers.IPv6{
Version: 6,
SrcIP: localIPv6Addr,
DstIP: remoteIPv6Addr,
NextHeader: layers.IPProtocolICMPv6,
HopLimit: 64,
}

icmp6Layer := &layers.ICMPv6{
TypeCode: layers.ICMPv6TypeEchoRequest,
}

icmp6Layer.SetNetworkLayerForChecksum(ip6Layer)

buf := gopacket.NewSerializeBuffer()
opts := gopacket.SerializeOptions{
FixLengths: false,
ComputeChecksums: true,
}
err = gopacket.SerializeLayers(buf, opts, ip4Layer, ip6Layer, icmp6Layer)
if err != nil {
log.Fatal(err)
}

fmt.Printf("%x\n", buf.Bytes())

_, err = conn.WriteTo(buf.Bytes(), &net.IPAddr{IP: remoteIPv4Addr})
if err != nil {
log.Fatal(err)
}

fmt.Println("6in4 packet sent")
}

Ugyanaz, mint a Python, csak kicsit hosszabb megoldás. Viszont sehogy nem akart menni. A következő hibát tapasztaltam:

Fura, hogy az IPv6 csomagom verziója négyes lett, a TTL sem lett 255 az IPv4-es csomag esetében, illetve nyilván nem működött a mutatvány. Ezen a ponton elkezdtem hasonlítgatni a két csomag tartalmát hexben, majd sok idő után rájöttem, hogy a Go azzal, hogy megmondom neki, hogy IP protocol 41-ről lesz szó: net.ListenPacket("ip4:41", "0.0.0.0"), automatikusan elintézi az IPv4-es csomag összerakását és azért lett a verzió kód 4 az IPv6-os csomagban, mert azt is létrehozza nekem a nyelv, viszont én is megcsinálom ugyanezt, így duplán kerül be az IPv4-es réteg a rossz verzióval. A megoldás tehát az, hogy csak az IPv6-os csomagtól foglalkozom az összerakással, a többit a nyelvre hagyom.

Arra sehogy nem találtam megoldást, hogy mindent kézzel rakjak össze, mint a Python esetében az ethernet rétegig, úgy tűnik ez egy nyelvi limitáció. Nyers syscallokkal meg lehetne oldani, de akkor meg OS specifikus lenne a kód és nem univerzális.

Hosszas kihívások után viszont Go-ból is sikerült összerakni a pinger implementációt és kapok is vissza választ a tunnel másik oldalán lévő IPV6-os címtől! A kódot itt megtaláljátok, mert kicsit hosszú lett.

Hátránya, hogy az IPv4 csomag felett semmi kontrollom nincs, azt a Go és a linux kernel rakja nekem össze, szóval TTL-t pl nem tudok állítani. És valamiért a TTL Go-ból 64 IP protocol 41 esetén, míg a linux kernel 255-et állít be. Viszont megkérdeztem az egyetemen egy tanárt és azt mondta, hogy ez nem probléma, így maradt ez a megoldás.

Oké, már értem, hogy hogy működik a protokoll, tudok pingelni, de még mindig manuálisan rakok össze csomagokat. A végcél pedig az lenne, hogy ugyanezt HTTP(S) forgalommal is meg tudjam tenni. Kellene egy komplett userspace TCP implementáció, amiből meglehetősen kevés létezik valamiért, bármilyen programnyelven keres rá az ember.

TCP esetében rengeteg dolgot kellene implementálni, amihez bőven kevés vagyok. Azt a tippet kaptam, hogy a Google féle gvisor projekt rendelkezik egy tcpip stack-kel, amit tudnék használni:

- https://pkg.go.dev/gvisor.dev/gvisor/pkg/tcpip/
- https://pkg.go.dev/gvisor.dev/gvisor/pkg/tcpip/transport/tcp

Illetve ezt szinte out of the box be lehetne kötni transportként a HTTP kliensembe, de akárhogy próbálkoztam, ehhez egyelőre kevés vagyok. Nem sikerült rájönni, hogy hogyan tudnám ezt a TCP stacket felhasználni. Egyelőre félretettem a projektet.

Viszont idén is engem ért az a megtiszteltetés, hogy részt vehettem a HCSC (Hungarian CyberSecurity Competiton) szervezésében. mivel az Óbudai Egyetemet kérték fel idén is, hogy gyártson feladatokat. idén másodszorra járulhattam hozzá, most 11 feladattal a szervezéshez.

És ha már kibervédelmi verseny, szeretek mindig valami különlegeset is hozni. Volt már, hogy saját bug bounty felfedezésem alakítottam leegyszerűsítve feladattá, vagy egyéb különlegesebb problémát hoztam, amivel én is megküzdöttem, hogy egy kicsit talán egyedibb legyen tőle a paletta.

Idén a networking mellett döntöttem, és pont kapóra jött ez a zátonyra futott projekt. Azt nyilván nem várhattam el tőlük, hogy valaki majd ír nekem TCP stacket, de belegondoltam abba, hogy egy hekkernek sosem árt egy kis alap hálózatos tapasztalat, nekem teljesen új volt a terület, mikor beleástam magam, de nem teljesíthetetlen terep.

És így született meg a Return of Jack feladatom. Tavaly is csináltam pár kihívást Jack névvel és messze az kapta a legtöbb kritikát, ezért gondoltam, hogy tradícióvá teszem a megosztó feladatoknál a Jack trademarkot.

Készítettem egy routert, ami hallgatózik IP protokoll 41-en keresztül érkező ICMPv6 echo request és reply csomagokra, majd válaszol ezekre, ha azok megfelelő formában jönnek.

A flaget pedig elhelyezhettem volna simán az ICMPv6 réteg adat mezőjébe, viszont sokkal kreatívabbnak tűnt, hogy az ICMP csomagok tartalmaznak egy sequence numbert és egy identifier mezőt is: [link]. A flag általában egy előre meghatározott flag formátumban megadott sztring, pl: HCSC{pelda_flag}, így az ICMP identifier lehet a sztring adott indexe, a sequence number pedig lehet az adott indexen szereplő karakter.

A támadónak pedig nincs más dolga, csak kipörgetni az összes abc karaktert és pár speciális karaktert ICMP csomagok tunnellezett küldésével, egészen addig, míg helyre nem tudják állítani a flaget a bezáró } karakterig.

Az implementáció viszonylag hamar megvolt. Gyakorlatilag egy szervert kellett csinálnom, ami hallgatózik IPv4-en és IP protocol 41-es csomagokat vár. Majd gopackettel feldolgozza ezeket, elkezdi lebontani a rétegeket és ha talál megfelelő formátumban küldött ICMP kéréseket, akkor válaszol rájuk.

A feladat szövegét volt talán a legnagyobb kihívás kitalálni. Hiszen ez tipikusan egy olyan feladat, amit pontos utasítások nélkül esélye sincs a játékosnak megoldani. Végül a következő körítéssel álltam elő:

-------------------------------------------------

A sok utálat miatt, amit tavaly Jack kapott, a helyi hatóságok letartóztatták és bezárták egy elhagyatott sziget börtönébe. Sok-sok morális rágódás után végül úgy döntött, hogy végre kész élni a következményekkel és kész meglobogtatni a fehér zászlót, majd beismerni tettét. Azonban a szigeten igencsak limitált a kommunikációs hálózat. Gyakorlatilag az egész sziget egy speciális /64-es IPv6 tartományon osztozik. Először lépj vele kapcsolatba, aztán folytatjuk!

Ezeket az adatokat tudjuk:
- 2001:470:6d:d6::/64 a hálózat
- 2001:470:6d:d6::1337 egy hintet tartalmaz, de ezen kívül nem használható semmi másra
- minden más IP a tartományból használható a Jackkel való kommunikációra
- Jack nem sokat tud a hálózatokról, illetve router firmware fejlesztésekről, így csupán egyetlen hálózati réteg protokollt implementált le sikeresen. Ezen a protokollon ha kérdezel (ID: 128), ő talán válaszol (ID: 129). De a következőt mindenképp vedd figyelembe! Ez az egyetlen esélye, hogy kommunikáljon a külvilággal lebukás nélkül. Nyilván nem lesz túl bőbeszédű. Csak a jó kérdésre fog válaszolni (kivéve a hint esetében, hiszen az nem Jack műve).

Nem megy az IP elérése a "clear weben"? Semmi gond! Az első feladatod egy kis network OSINT. Who is on the other side?

Még mindig nem tiszta minden?
Itt egy pontokba szedett lépéssorozat. Nem árt, ha ezekre mind tudsz válaszolni:
1. Találd ki, hogy milyen szolgáltatásra lehetett használva a megadott IPv6 tartomány. Valószínűleg még szükséged lehet erre az infóra.
2. Milyen protokollt használ Jack? Felismered az azonosítókat? Valószínűleg ez is fog kelleni.
3. Mi történik, ha azt az IPv6 címet szólítod meg, ami a hintben szerepel? Lehet, hogy ad egy tippet, hogy hogyan tovább...
4. Profit!

Megjegyzés: A challenge megoldása során neked közvetlenül csak az alább megadott IPv4 cím felé kell adatot küldened.

Megjegyzés: A célcím (dst) csak akkor számít, amikor a hinttel beszélgetsz. Minden más esetben lehet a cél bármilyen IPv6 cím.

> Készítői kommentek:
> - VPN kapcsolat nem szükséges
> - Ez a challenge a megszokott infrastruktúrán kívül van hosztolva és egy szerveren elérhető. Az IP-t lentebb találjátok.
> - a challenge nem TCP és nem is UDP, más

Hasznos lehet az utadon:
- https://wireshark.org
- https://scapy.net/
- https://datatracker.ietf.org/ linkek

Kinda funny. You are going to capture the flag, capture data and rescue the captured Jack at the same time.

-------------------------------------------------

Meg kaptak a leírás mellé egy IP címet, ahol futott a szoftverem és várta a csomagokat.

Egyébként a verseny során egyetlen versenyző oldotta meg a feladatot, amiért tényleg le a kalappal, minden elismerésem!

Mivel a versenynek vége, a verseny szervezőinek engedélyét megszerezve publikáltam a feladataim, így akit érdekel, elérhető egy részletes angol nyelvű writeup a feladatról itt: [link], a forráskód itt: [link], és a megoldásom itt: [link].

Utólag kicsit megbántam, hogy ráeresztettem szegény versenyzőket egy ilyen egzotikus feladatra, mert sok feedback jött, hogy már a leírás hossza is elijesztette az embereket, de bízom benne, hogy volt valaki, aki profitált abból a tudásból, ami a megoldás levezetésével jár. Én rengeteget tanultam a feladat elkészítése során, és hálás vagyok az összes versenyzőnek, akik minden évben motiválnak, hogy folytassam, mert minden évben tanulok valami újat olyan területekről, amikkel nem biztos, hogy magamtól foglalkoznék.

Köszönöm, hogy elolvastad!