Resolving domen z NS gransy.com po pondelnim hacku

Úterý Září 22 08:32:18 CEST 2020

Diky, jsem rad, ze v tom nejsme sami, zajimalo by me kolik lidi s tim 
travy hodiny casu stejne bez vysledku...

Je mozne, ze to je nejaky problem v bindu, nicmene pred hacknutim 
gransy.com s tim problemy nebyly, resp. nic co by bylo za bezneho provozu 
problem, takze to je nejaka "konjunktura" s tim, co tam ted uplacali.

Ja nasel napr. tyto stare chyby se stejnymi priznaky:
https://bugzilla.redhat.com/show_bug.cgi?id=1281484
https://bugzilla.redhat.com/show_bug.cgi?id=807540

minimalne ten prilozen patch v gitu bindu ale je.

Ve zdrojacich bindu je jen
"malformed OPT option",             /*%< 113 DNS_R_OPTERR */

pokud koukam po
"stop on unrecognized qresult in rpz_rewrite"

Jedine co z toho vykoukam je ze to v tento funkci propadne do nejake 
defaultni case.. komentar k funkci je

"Look for response policy zone QNAME, NSIP, and NSDNAME rewriting."
co to znamena netusim, popis te chyby zadny aby clovek aspon tusil kam 
smerovat.

Adam Pribyl

On Tue, 22 Sep 2020, Jan 'yanek' Bortl wrote:

> [zkousim preposlat znovu, neb se mail neobjevil ani po hodine v archivu]
>
> Dobry vecer,
>
> cely patek, cele dnesni odpoledne a ted vecer se v tom snazim zorientovat. 
> Nefunguje ani posledni verze bind9 9.17.5 dnes rucne a defaultne 
> zkompilovana. Unbound funguje. Knot-resolver udajne taky - to jsem 
> neoveroval.
>
> Napsal jsem si na to kratky script, kde se to vetsinou projevi i bez loadu 
> (bokem bez provozu od zakazniku je to obtizne navoditelne):
>
> #!/bin/bash
>
> IP=<ip_bindu>
> DOMAIN=tiscali.cz
>
> for i in `seq 1 50`; do
>     echo -n "$i: "
>     dig neexistujici$i.$DOMAIN @$IP | grep status
> done
>
> Pokud bude psat aspon jednou SERVFAIL, tak je tam problem (pripadne zvetsit 
> cislo 50 na vic, ale je to videt uz na prvnich dotazech).
>
> Hloupe na tom je, ze neco zpusobi otraveni cache bindu a ten zacne odpovidat 
> SERVFAIL i na veci, ktere pred par vterinama jeste vedel. To se mi tedy dari 
> nasimulovat jen s netrivialnim zakaznickym provozem.
>
> Nicmene k veci: patral jsem s hodne velkym debug levelem v bindu a zjistil 
> nasledujici... pokazde zustanu u tech servfailu trcet na takoveto hlasce:
>
> 21-Sep-2020 21:16:37.608 client @0x7f685c000c88 10.136.0.2#52073 
> (imap50.tiscali.cz): query failed (malformed OPT option) for 
> imap50.tiscali.cz/IN/A at query.c:6929
>
> Tedy stejne co je videt i u vas. Ale dvakrat moudry z toho nejsem. Na 
> odpovedi ze serveru nevidim nic moc spatne. Mam z toho spis dojem, ze je tam 
> nejaka krpa v bindu jako takovem, ktera se projevuje v kombinaci s Gransy - 
> proc netusim.
>
> Jen takovy vystrel do tmy behem psani tohoto emailu: mam dojem, ze problem 
> (uz jenom) delaji domeny pouzivajici DNSSEC s obstaroznim NSEC misto NSEC3 
> (nadruhou stranu napriklad o2.cz, ctu.cz funguji, ty jsou ale jinde). U 
> tiscali.cz a vami uvedene domeny unimagnet.cz i workhouse.cz vyse uvdeny test 
> vzdy selze (na cerstve pustenem bindu). U ostatnich domenach co maji NSEC3 se 
> mi to navodit dnes uz nepovedlo. V sobotu to jeste slo videt, ze je to 
> rozbite, ale to bylo nejspis zpusobene rozbityma NS na domene gransy.com, 
> pricemz dva z nich odpovidali REFUSED. To se jim nejspis uz povedlo vyresit 
> neb to dnes uz nevidim.
>
> Jeste jsem nasel CVE-2016-2848 ktere resi rozbite OPT, mozna nejake voditko 
> dale.
>
> Nejaky napad nekoho zkuseneho? Dovolil jsem si dat do kopie Ondreje Sureho, 
> treba bude umet ukazat prstem co je spatne at uz v Bindu nebo u Gransy.
>
> Bavil jsem se v patek s Gransy a na svuj DNS frontend pouzivaji sve "caching" 
> reseni, takze muze byt problem i tam - nadruhou stranu s nahodnymi SERVFAIL 
> domenami se potkavam relativne casto napric celym internetem, kdy vetsinou 
> pomaha prave flush cache. Nicmene to nebylo doposud tak uplne vyrazne caste, 
> aby me to dostatecne trklo to nejak aktivne resit.
>
>
> Dne 21. 09. 20 v 7:57 Adam Pribyl napsal(a):
>> Zjistil jsem ze kdyz flushnu cache (rndc flush) tak to vetsinou chvili jde, 
>> nicmene prvni preklad adresy trva treba 2s.
>> Prijde mi jako kdyz se pak nacachuje nejaka chyba a ta pak prevlada.
>> 
>> Tady je nejaky timeline, kde pisi ze vcera gransy.com nejak posilovali, 
>> protoze s tim stale maji problemy, ale u nas to teda stale spis nejde nez 
>> jde:
>> 
>> https://wladass.cz/subreg-hacknut-timeline/
>> 
>> 
>> On Sun, 20 Sep 2020, Zdeněk Janiš wrote:
>> 
>>> Máme KNOT Resolver a zdá se to OK:
>>> 
>>> $ dig -t A www.unimagnet.cz @192.168.100.100
>>> 
>>> ; <<>> DiG 9.16.6-Debian <<>> -t A www.unimagnet.cz @192.168.100.100
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45631
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;www.unimagnet.cz.              IN      A
>>> 
>>> ;; ANSWER SECTION:
>>> www.unimagnet.cz. 540     IN      CNAME   ingress.wpj.cloud.
>>> ingress.wpj.cloud.      0       IN      A       81.91.91.88
>>> ingress.wpj.cloud.      0       IN      A       81.91.91.89
>>> 
>>> ;; Query time: 0 msec
>>> ;; SERVER: 192.168.100.100#53(192.168.100.100)
>>> ;; WHEN: Ne zář 20 22:47:54 CEST 2020
>>> ;; MSG SIZE  rcvd: 108
>>> 
>>> Dne 20. 09. 20 v 9:59 Adam Pribyl napsal(a):
>>>> Od te doby co v pondeli hackli subreg.cz/gransy.com nam nefunguje 
>>>> resolving domen, ktere jdou pres NS gransy.com. Zkousel jsem bind 9.8 a 
>>>> bind 9.11 (oboji debian) a proste resolving konci na servfail. Primy 
>>>> dotaz pres dig jde.
>>>> 
>>>> Napr.
>>>> 
>>>> dig www.unimagnet.cz @ns.gransy.com
>>>> 
>>>> ale prostrednictvim naseho bindu ne. Pokud zvysim trace log v bindu pise 
>>>> to napr.
>>>> 
>>>> rpz QNAME rewrite www.workhouse.cz via www.workhouse.cz stop on 
>>>> unrecognized qresult in rpz_rewrite()failed:  : malformed OPT option
>>>> 
>>>> DNS format error
>>>> 
>>>> apod. Pouzivame DNSSEC, ale vypnuti nic nezmenilo.
>>>> 
>>>> I googli DNS obcas vyhodi timeout na domenach z NS gransy.com.
>>>> 
>>>> Pozoruje nekdo neco podobneho? (Samozrejme pokud provozujete svuj 
>>>> rekurzivni resolver.)
>>>> 
>>>> Diky
>>>> 
>>>> Adam Pribyl
>>> 
>>> -- 
>>>  Zdeněk Janiš
>>> 
>> 
>> 
> -- 
> Jan 'yanek' Bortl <yanek [at] yanek. cz>
> http://yanek.cz/
> -----------------------------------------------------------------
> "Maybe one day you will learn that your way is not the only way."
>                                        Opher [StarGate: The Nox]
>
>
> _______________________________________________
> Linux mailing list
> Linux na linux.cz
> http://www.linux.cz/mailman/listinfo/linux
>