Mică lecție de documentare

Intră tot poporu’ pe net de dimineață și în loc de google.ro vede o pagină neagră cu mesajul unui albanez algerian. “Pfuaaai ! Știre !!!” – Urlă jurnalistu’ din ei. Și se apucă voios de scris începând cu magicele “Google a fost spart !”.

Da’ ia hai să ne documentăm noi puțin înainte de-a mânca răhățel. Întâi și întâi ar trebui să cunoaștem metodele prin care un astfel de mesaj ar putea să apară pe o pagină de net. Primul care vă vine în minte este într-adevăr deface-ul. Adică spart serverul pe care e găzduită pagina și înlocuită pagina respectivă cu un mesaj.

Dar în cazul ăsta vorbim despre Google. De câte ori am văzut noi Google spart și mai ales de către un algerian albanez (doar știm o grămadă de bancuri cu albanezi… ). Hai să mergem mai departe de deface. Cum mai putem înlocui un mesaj care apare pe domeniu.ro ? Păi dacă am reuși să avem acces la serverele dns am putea înlocui răspunsul la cererea de dns pentru domeniu.ro și am redirecta utilizatorii către un alt IP din cu totul altă parte.

Serverul companiei rămâne neatins dar utilizatorii (care folosesc nume de domenii nu adrese IP) sunt redirectați pe un alt server pe care atacatorul are acces. Asta se cheamă DNS Hijacking. Și cam asta s-a întâmplat azi.

Partea foarte frumoasă este că asta se întâmplă de obicei pe serverele dns ale companiilor. Însă aici se pare că s-a întâmplat direct pe tld (adică pe .ro) și ceva a mers prost direct la rotld. (Acum da, pot să fiu 90% sigur c-a fost buba pe la rotld).

La interogare cu nslookup apare următorul IP- 95.128.3.172. Despre care aflăm în urma unui whois că este de prin Olanda și nu are absolut nicio legătură cu Google.

În mod normal ar fi trebuit să apară fie IP-uri de google (173.194.35.x) fie cache-uri locale de pe la noi (46.108.1.x – adnet telecom) unde poți să vezi în reverse că e cache google.

Dar deja nu mai e atât de funny și o știre despre cum a fost spart Google se transformă într-o știre în cât de incompetenți sunt românii. Și asta doare…

Na c-o pățesc și eu. Da’ măcar eu am scuza că nu câștig o pâine din asta. Răspunsurile primite de la 8.8.4.4 sunt în continuare primite cu 95.128.3.172 în timp ce de la 8.8.8.8 răspunsurile sunt ok. Pentru google.ro. Ce s-a întâmplat exact nu pot să spun însă ce e clar este că nu e nici un deface.

Update: Să mai comentăm nițel ce se speculează. Umblă vorba cum că cele 2 DNS-uri publice de la google ar fi fost cele afectate. Nu zic că e 100% imposibil spun doar că este improbabil. Și sunt 2 motive principale care susțin lucrul ăsta :

1. Nu returnează tot timpul adresa IP a serverului din Olanda ci doar din când în când (deci este servită de undeva din altă parte).

2. Dacă într-adevăr ar fi fost sparte cele 2 DNS-uri, DNS-uri care sunt folosite nu numai la noi în țară ci cam peste tot, nu văd de ce un hacker n-ar redirecta și cererile pentru alte domenii, nu numai pentru domeniile .ro.

Update2 : Cum putea fi investigat mai în amănunt ce s-a întâmplat ? Păi, ce încercam eu să fac acum de exemplu era să interoghez nameserverele pentru .ro (e o listă de vreo 5 servere) pentru domeniile afectate. Și să văd dacă nu cumva unul din ele îmi servește niște servere authoritative aiurea. Din câte văd la ora asta nu mai este cazul însă este posibil să fi stat altfel lucrurile dimineață. La ora asta problema pare să se fi rezolvat cam peste tot (8.8.4.4 încă îmi servește IP greșit pentru paypal.ro dar este posibil să fie de prin cache-uri). Restul funcționează ok. Chiar aștept explicațiile oficiale pentru că e interesant ce s-a întâmplat.

Leave a Reply

24 Comments

  1. Dacă descopereau un exploit la ROTLD nu cred că se opreau doar la Google si Yahoo.

  2. Eu am puse la toata reteaua google public dns ca si ns-uri; pe IE am vazut algerienii, pe Nightly nu mi se incarca nimic.

  3. Tyby

    8.8.4.4 da in continuare 95.128.3.172, 8.8.8.8 da normal. Uitati o perioada de 4.4, pana se rezolva.

    Problema pare sa fie – totusi – in curtea Gugal. Afaik, 8.8.x.x sunt administrate de ei direct, cineva s-a “jucat” la unul dintre ele. Asteptam declaratiile (if any).

    PS: btw, erau algerieni, nu albanezi :)

    • Meekuu

      Da, dar faptul că au fost afectate și alte domenii .ro (iar 8.8.4.4 ia informațiile de mai sus din ierarhia .ro ) sugerează că problema n-a fost acolo. Ce-i drept eu n-am interogat alte ns-uri (iar ale mele par să răspundă corect). Și da, cel mai bine e să așteptam vești direct de la cei implicați.

      Am modificat cu albanezii (damn, era mai haios cu albanezi :D ).

    • Tyby

      Intrebarea este de ce doar 8.8.4.4, si nu si celalalt. Nu folosesc aceleasi surse?

    • Meekuu

      Acum și 8.8.8.8 rezolvă cu același IP (aiurea).

  4. Gabriel

    user@host:~$ dig +trace paypal.ro @8.8.4.4

    ; <> DiG 9.8.1-P1 <> +trace paypal.ro @8.8.4.4
    ;; global options: +cmd
    . 37696 IN NS j.root-servers.net.
    . 37696 IN NS g.root-servers.net.
    . 37696 IN NS k.root-servers.net.
    . 37696 IN NS f.root-servers.net.
    . 37696 IN NS a.root-servers.net.
    . 37696 IN NS b.root-servers.net.
    . 37696 IN NS d.root-servers.net.
    . 37696 IN NS e.root-servers.net.
    . 37696 IN NS l.root-servers.net.
    . 37696 IN NS h.root-servers.net.
    . 37696 IN NS m.root-servers.net.
    . 37696 IN NS c.root-servers.net.
    . 37696 IN NS i.root-servers.net.
    ;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 39 ms

    ro. 172800 IN NS primary.rotld.ro.
    ro. 172800 IN NS secondary.rotld.ro.
    ro. 172800 IN NS dns-ro.denic.de.
    ro. 172800 IN NS dns-at.rotld.ro.
    ro. 172800 IN NS ns.uu.net.
    ro. 172800 IN NS ns-ext.isc.org.
    ;; Received 388 bytes from 192.58.128.30#53(192.58.128.30) in 171 ms

    paypal.ro. 10800 IN NS dns35.register.com.
    paypal.ro. 10800 IN NS dns36.register.com.
    ;; Received 79 bytes from 193.230.31.225#53(193.230.31.225) in 3324 ms

    paypal.ro. 86400 IN A 211.20.108.4
    ;; Received 43 bytes from 216.21.234.88#53(216.21.234.88) in 136 ms

    pentru paypal.{com|es|de|at|co.uk} TLD-urile respective raspund cu ns[123].isc-sns.{com|net|info}:

    user@host:~$ dig +trace paypal.es @8.8.4.4

    ; <> DiG 9.8.1-P1 <> +trace paypal.es @8.8.4.4
    ;; global options: +cmd
    . 15176 IN NS g.root-servers.net.
    . 15176 IN NS d.root-servers.net.
    . 15176 IN NS m.root-servers.net.
    . 15176 IN NS l.root-servers.net.
    . 15176 IN NS f.root-servers.net.
    . 15176 IN NS b.root-servers.net.
    . 15176 IN NS i.root-servers.net.
    . 15176 IN NS a.root-servers.net.
    . 15176 IN NS j.root-servers.net.
    . 15176 IN NS k.root-servers.net.
    . 15176 IN NS c.root-servers.net.
    . 15176 IN NS h.root-servers.net.
    . 15176 IN NS e.root-servers.net.
    ;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 40 ms

    es. 172800 IN NS ns1.cesca.es.
    es. 172800 IN NS ns15.communitydns.net.
    es. 172800 IN NS ns3.nic.fr.
    es. 172800 IN NS ns-ext.nic.cl.
    es. 172800 IN NS f.nic.es.
    es. 172800 IN NS a.nic.es.
    es. 172800 IN NS sns-pb.isc.org.
    ;; Received 453 bytes from 192.33.4.12#53(192.33.4.12) in 285 ms

    paypal.es. 86400 IN NS ns2.isc-sns.com.
    paypal.es. 86400 IN NS ns1.isc-sns.net.
    paypal.es. 86400 IN NS ns3.isc-sns.info.
    ;; Received 115 bytes from 84.88.0.3#53(84.88.0.3) in 91 ms

    paypal.es. 300 IN A 173.0.84.191
    paypal.es. 300 IN A 173.0.84.193
    paypal.es. 300 IN A 173.0.88.191
    paypal.es. 300 IN A 173.0.88.193
    paypal.es. 300 IN A 66.211.168.132
    paypal.es. 300 IN A 66.211.168.173
    paypal.es. 300 IN NS ns3.isc-sns.info.
    paypal.es. 300 IN NS ns1.isc-sns.net.
    paypal.es. 300 IN NS ns2.isc-sns.com.
    ;; Received 315 bytes from 63.243.194.1#53(63.243.194.1) in 54 ms

    Nu e clar ca problema e[ra] la rotld?! Or am I missing something?

    • Meekuu

      Așa aș spune și eu. Probabilitatea cea mai mare e să fie direct în curtea rotld, însă nu-mi place să mănânc rahat și să se dovedească ulterior că m-am înșelat. Dacă-ar fi să bârfesc la o bere aș spune clar că unul din serverele pentru tld .ro e de vină și gata. Cum n-am posibilitatea să verific informația direct și încă n-avem un răspuns oficial de la rotld, aștept.

      Puteau fi într-adevăr și nameservele open de la google și avea sens să se propage și pe nameserverele de la ISP-ii din ro în condițiile în care ISP-ii foloseau mai sus serverele google. Dar, după cum am zis mai sus, puțin probabil având în vedere c-au fost afectate doar .ro-urile. Nu-l văd pe unu’ să facă asta și să nu belească și un .com mare ceva…

  5. Salut,

    Pana la urma a fost vorba de SQL Injection la TLD. Way to go.

    • Meekuu

      Da, dar e interesant la care din cele 6 servere care deservesc .ro-ul s-a întâmplat. Și eu sunt tare curios de ce vulnerabilitate s-au folosit.

    • Gabriel

      Tu suspectezi ca a fost efectiv compromis un server DNS? Io cred ca e mai simplu si au reusit sa obtina acces la interfata/baza de date unde poti specifica DNS-urile pentru fiecare domeniu .ro.

    • Meekuu

      Poți să-mi dai te rog sursa pentru SQL Injection ? De unde-ai aflat ?

  6. alexandru maraloi

    Te ingrozeste faptul ca tehnica asta de DNS poisoning “la drumul mare” functioneaza fara probleme. Oare ce s-ar fi intamplat daca ar fi redirectionat catre un o pagina phishing ? Cati dintre voi ar mai fi avut incredere in google…? DNS alternativ , mai ales ca sunt destule free.

    • Meekuu

      Dacă ar fi fost google de vină aș mai fi zis să n-am încredere. Dar cum n-a fost cazul eu zic că putem trăi liniștiți mai departe cu google.

      Și phishingul ar fi afectat doar utilizatorii care ignoră avertizările legate de certificate (presupun că te referi la un phishing pentru ceva instituții bancare sau conturi importante, care-s de obicei pe conexiuni ssl).

    • Mai, in legatura cu increderea, treaba sta cam asa:
      Sa n-ai niciodata incredere in nimic online si tot timpul sa fii circumspect. Daca folosesti internet banking, alege o banca ce foloseste o metoda de autentificare foarte greu de inselat – de exemplu, eu ma loghez cu un certificat si o parola, iar cand trebuie sa fac un transfer, banca imi trimite un sms cu un cod (sau ai un RSA token), asa ca chiar daca la un moment dat sunt inselat de un phising, doar cu certificatul si cu parola nu prea au ce sa faca. Pentru plati online faci un cont separat, cu card separat, pe care pui bani numai cand cumperi ceva. In felul asta eu zic ca dormi mult mai linistit si nici nu te mai ingrozeste la fel de tare fapul ca unii mai heckaresc cate ceva pe undeva.

  7. Adi

    de ce un ISP-ist sa aiba ca forwarders in dns google? imi suna foarte putin probabil..
    toata treaba pointeaza catre rotld..nici eu nu sint sigur, dar apropo de bere, eu am facut pariu pe asta..
    de ce nu sint suta la suta convins, e treaba cu dnsurile publice google..au reactionat foarte lent in relatia cu rotld…poate din cauza fusului orar…
    irlanda a dat declaratie oficiala..o astept curios si pe a noastra..

    • Meekuu

      Încurcate-s căile ISP-iștilor din RO :D. Acum sunt și eu 100% convins că problema e pe la rotld. Și nu cred că google au reacționat lent în relația cu rotld ci mai degrabă rotld au reacționat lent în relația cu oricine. Cum reacționează lent și nu dau nici o declarație încă.

      Cum paștele mă-sii să fii responsabilul de tld într-o țară și să treacă mai bine de 24 de ore fără să răspunzi și să explici ceva public ? Ce bază mai poți pune pe domeniile cumpărate la rotld ?

  8. cei de la kaspersky spun ca e vb de dns poisoning (kaspersky.ro/blog/googlero_şi_alte_domenii_din_românia_victime_ale_unui_posibil_atac_de_tip_dns_poisoning)
    dar inca nu se stie exact ce si cum sa intamplat, doar presupuneri

    • Meekuu

      Până și cei de la kaspersky s-au repliat. Nu e vorba de dns poisoning ci au spart sql-ul pe la rotld. Nașpa…

Next ArticleMică lecție de asumare a răspunderii