Portál AbcLinuxu, 30. dubna 2025 11:20
Ve středu (10.10.) mi Atalax a Jakluk napsali „Tak jak byste to viděli s The Catch?“ A že teda jo, no.
V pátek těsně před startem za mnou ve škole přišel undisclosed spolužák, že by se chtěl účastnit a že nemá tým, a jestli bych do toho nešel s ním. Koukli jsme do pravidel, zda můžeme být čtyři, a odstartovali jsme tedy ve složení dva matfyzáci (IRL) a dva FELáci (spolupracující po internetu).
Dále popisuji úlohy, které jsem buď vyřešil, nebo se na nich alespoň podílel. Tentokrát distribuce práce fungovala dobře, a to jak paralelismus, tak párové programování. U ostatních úloh tedy budete muset pohledat jinde, nebo si počkat na oficiální řešení (nebo mě uprosit v diskuzi).
Sorry, začíná to strašně beginner level.
Stránka plná blábolů, nastaví vám cookie isadmin=0. Poeditujeme, hotovo. Za dva body??
Dáno SSID a MAC sítě UPC, zadejte heslo. Tisíckrát rozmazaný problém.
Existuje Military-grade encryption a Microsoft-grade encryption. Microsoft nějaké údaje při posílání po síti šifruje AESem s pevně daným klíčem, který se samozřejmě válí na netu. V této úloze jde o dešifrování XML s takovými údaji. I pokud o tomto bugu nevíte (nebo stejně jako já - neboť Windows nerozumím, sorry - nevíte jak se to jmenuje a tedy co hledat), kousky XML byly googlitelné, a tak jistě brzy najdete popis tohoto přelomového způsobu šifrování.
Dostali jsme PCAP z DHCP serveru, který má lease nastavený na 10 sekund, takže tam je docela provoz. Spolužák si naštěstí všiml, že je tam 24 discoverů a offerů (a flagy mají náhodou 24 znaků) a všechno ostatní jsou renewy. Ta 24 se nakonec ukázala jako falešná stopa, ale zajímavé je, že se v některých discoverech posílá jiná linková a aplikační MACka (pole Client MAC v BOOTP protokolu), a kupodivu zrovna aplikační MAC tvoří ASCII znaky s vlajkou (a v ostatních je nulová NIC část MACky). Samozřejmě kdo má v tom Wiresharku tyhle romány kopírovat ručně, uživatelé blobutils si můžou aplikovat následující tshark:
> tshark -T fields -e bootp.hw.mac_addr -r /tmp/dhcp.pcap.gz | grep -v "00:00:00"|uniq | blhexbin CT18-Bb1a-YEeR-r6Sa-rJao
Křížovka. Prostě křížovka. Strašně jsem chtěl hledat solver a pak to programovat, ale nakonec jsme to dali ručně na papír. Mimochodem většina nalezených solverů neumí backreference. Asi je na čase fakt se naučit to constraint-solving programming.
Telnet server, který s vámi hraje lodičky:
Connected to challenges.thecatch.cz. Escape character is '^]'. Greeting Send your moves in form A10, B1 .. { "board": { "A": "............X..", "B": "...........XX..", "C": "............X..", "D": "...............", "E": "...X...........", "F": "...XX......X...", "G": "...X.......XX..", "H": "...............", "I": ".......X.......", "J": "......XXX..X...", "K": ".......X..XX...", "L": "...........X...", "M": "...............", "N": "...............", "O": "...............", "_": "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15" }, "myMove": "", "myMoveResult": "", "overallResult": "0 0 (N/A)", "yourMove": "", "yourMoveResult": "" }
Po tahu server řekne hit/miss. V instrukcích je, že musíte ze 100 her vyhrát 80. Ach jo, to jako fakt budeme psát solver na lodičky?!
Inu, tak jsem začal programovat. Jenom poznámka, pozornost upoutalo, že jsem použil telnetlib (ukradeno odsud), a prý to tak bylo podivně krátké. No a když mi to komunikovalo, tak jsem zlepšoval heuristiky až jsem to teda jako vyhrál.
X X X X X XXX , XXX , XX , X , X a rotace a zrcadlení X XPokud dobře koukám, tak to znamená, že po odkrytí části lodičky nemůžu nikdy říct, o jakou lodičku se jedná. (uff, alespoň jeden opruz s programováním odpadl) Na druhou stranu lodičky se nikdy nedotýkají, a proto střílení všude okolo z předchozího bodu bude často padat vedle. Rozhodl jsem se tedy podívat se na problém z druhé strany -- na desku přikládat tu největší lodičku a podle toho říkat, kde loď pravděpodobně je, a kde naopak určitě nebude - tím si ušetříme překvapivě mnoho missů. Úspěšnost se zlepšila, najednou jsem vyhrál 72 her ze 100. Blížíme se. (kdybych byl prase, tak to nechám chvíli běžet a budu doufat, že to náhodou vyhraju, ale já mám nějak blok prasit servery organizátorů, prasím jenom svůj počítač…)
Server vám pošle obrázek:
Cílem je najít všechny smějící se smajlíky, vyXORovat jejich barvy (po složkách), a výsledek poslat zpět. Na tohle máte 5 sekund, takže to nejde dělat ručně (možná bych to teda dokázal oklikat, nevím).
Smajlíků je vždy 16 v gridu 4x4, ale mají náhodou rotaci, velikost i posunutí (ale nevytékají ze svých 200x200px čtverců). Ach jo, jde se programovat. Na první pohled je vidět že přístup „převedeme to do PBM a pattern v tom grepneme“ je odsouzen k nezdaru, takže jsem si pořídil plnohodnotné OpenCV a scikit-image.
Jako první věc je potřeba rozkrájet obrázek na 200x200px čtverce. Následně v každém čtverci lokalizujeme obličej. To uděláme postupnou línií detekující nečerné pixely a pak totéž pro transponovaný obrázek (modře) pokud také neumíte používat numpy jako já:
Umíte někdo v GIMPu dělat nedementně šipky?
Teď vyvstává otázka jestli musíme obrázek normalizovat na pevnou velikost a zejména otáčet. Rotaci umím určovat polygon walking algoritmem a vím jistě že to fakt nechci dělat. Zkusíme to nějak ohackovat. Ukazuje se, že můžeme doprostřed vyříznutého obličeje strategicky položit kolečko (skimage.draw.circle
), a když je správně velké, tak nezasáhne oči, ale zasáhne horní ret v případě mračícího se obličeje. Pak už stačí jen otestovat, zda průnik obrázku s kolečkem obsahuje jiné než černé pixely.
Tím tedy máme vyřešeno smajlík/smutník a zbývá poslední detail (tedy vlastně dva), a to zjistit jakou barvou je to nakreslené. To také není tak přímočaré, smajlíci jsou antialisovaní, takže nestačí vzít náhodný pixel… Uděláme tedy np.reshape
, np.unique(return_counts=True)
a vybereme si nejčastější nenulovou hodnotu.
A ten poslední detail? Server musí poznat, že mu posíláme odpověď na obrázek, který jsme si stáhli, a k tomu nám dává PHPSESSID
. A wget
nemá parametr --keep-session-cookies
defaultní…
Wordovský dokument s makry, tedy VBS/VBA. Tomu vůbec nerozumím, ale atalax mi poradil pustit na něj olevba a vypadne zdroják, kde je funkce, která rozbaluje něco-jako-double-base64. Máme v podstatě tři možnosti:
S poslední možností už mám nějaké zkušenosti (legendární překládání všeho včetně LaTeXu do C), takže jsem prostě přepsal pole na ndarray, kulaté závorky na hranaté a tak, spustil to a ono to (samozřejmě po opravě několika chyb) vydalo hromadu bordelu (zamýšleně) a v ní byl ukrytý flag. Naštěstí jsem si před tím všiml na soutěžním Slacku debaty o tom, jak je důležité flag hledat regexpem, protože v té hromadě se ztrácel. Podle soutěžního Slacku si na tohle ztrácení naběhlo fakt hodně lidí.
Tohle byla nějaká bizarní DNSková věc, kde jste se zeptali na jméno, ono to vrátilo nějaký NS, a když jste se zeptali na něj, tak to vrátilo nějaký jiný NS a tak pořád dokola:
? dustoff.infinite.thecatch.cz. IN ANY dustoff.infinite.thecatch.cz. 0 IN NS ns.v3n06cd.infinite.thecatch.cz. ? ns.v3n06cd.infinite.thecatch.cz. IN ANY v3n06cd.infinite.thecatch.cz. 0 IN NS ns.skvd8dr.infinite.thecatch.cz. ? ns.skvd8dr.infinite.thecatch.cz. IN ANY skvd8dr.infinite.thecatch.cz. 0 IN NS ns.gml4cf4.infinite.thecatch.cz. ? ns.gml4cf4.infinite.thecatch.cz. IN ANY gml4cf4.infinite.thecatch.cz. 0 IN NS ns.li8d7jr.infinite.thecatch.cz. ...
infinite
? PRNG? Nevěřil jsem tomu, že tohle někam povede, samozřejmě jsem měl dig ve smyčce a ukončil jsem ho po 947 dotazech. Zajímavé je, že na jiné dotazy to neodpovídá:
? ns.gmm4cf4.infinite.thecatch.cz. IN ANY NXDOMAIN infinite.thecatch.cz. 0 IN SOA challenges.thecatch.cz. hostmaster.infinite.thecatch.cz. 2018091424 7200 7200 1209600 86400
mmmmmkay, takže PRNG který vám vydá další krok to asi nebude, a pokud, tak s checksumem? A je cílem ho cracknout? Nebo spíš bloudím a tady nic není…? Navíc to posílá nějaké EDNS příznaky a já tomu vůbec nerozumím a netuším, jestli je v nich něco schovaného, nebo je to normální součástí toho updatu DNS co teď probíhá.
No, po chvíli přemýšlení jsme dospěli k závěru, že bychom si mohli nachytat alespoň 1024 vzorků, to je takové hezké číslo, a pak z nich něco vyvěštit. A světe div se, po 1024 krocích z toho začaly místo li8d7jr
padat hexačísla odpovídající ASCII znakům a blilo to na nás instrukce a heslo. Jakože wtf. 1024 mi přijde moc (navíc když je v hostname infinite
), a podle mě tohle někdo naprosto legitimně nedá proto, že se řídil pravidlem nebruteforcovat servery pořadatele.
Soutěžilo 276 týmů, z nichž 24 došlo do cíle (mezi nimi pak rozhodoval čas). My jsme skončili po 9 hodinách třetí. Před námi byli jenom profesionálové (Avast (6 hodin) a nejmenovaná pentesterská firma (8 hodin)). Prvních 10 týmů (a tedy i my) postupuje do on-site kola. Vzhledem k tomu, že minimálně já nemám nejmenší tušení co dělám, fakt nevím, jak tohle skončí. srsly, jak se tohle stane někomu, kdo ještě před měsícem nevěděl, co je to ctf (upřesnění: myslel jsem si, že naprostá většina CTF je o reverzování a buffer overflow exploitech, s čímž nemám téměř zkušenosti)
Tiskni
Sdílej:
Před námi byli jenom profesionálové (Avast (6 hodin) a nejmenovaná pentesterská firma (8 hodin)).Toto jsem presne cekal a proto jsem se na to radeji vykaslal.. proc delat stejnou chybu dvakrat.
Před námi byli jenom profesionálové (Avast (6 hodin) a nejmenovaná pentesterská firma (8 hodin)).Jo, profesionálové z Avastu... mám takovej pocit, že se jim dneska povedlo zablokovat půlku internetu (webu) jako false positive phishing.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.