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.
Jules (@maibinecaieri) November 28, 2012 at 09:44
Cred ca e sub rotld.ro. Eu nu am vazut deloc pagina aia.
Mai degraba dns-ul vreounui provider marisor.
1nu November 28, 2012 at 10:39
Dacă descopereau un exploit la ROTLD nu cred că se opreau doar la Google si Yahoo.
Claudiu November 28, 2012 at 10:48
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.
Tyby November 28, 2012 at 11:36
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 November 28, 2012 at 12:05
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 November 28, 2012 at 12:08
Intrebarea este de ce doar 8.8.4.4, si nu si celalalt. Nu folosesc aceleasi surse?
Meekuu November 28, 2012 at 12:11
Acum și 8.8.8.8 rezolvă cu același IP (aiurea).
Tyby November 28, 2012 at 12:26
> http://www.google.ro 8.8.8.8
Server: [8.8.8.8]
Address: 8.8.8.8
Non-authoritative answer:
Name: http://www.google.ro
Addresses: 2a00:1450:4016:801::1017
173.194.35.191
173.194.35.184
173.194.35.183
>
Licaon_Kter November 28, 2012 at 12:41
OpenDNS FTW!
Gabriel November 28, 2012 at 15:14
[email protected]:~$ 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}:
[email protected]:~$ 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 November 28, 2012 at 16:04
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…
marsbt November 28, 2012 at 17:32
Salut,
Pana la urma a fost vorba de SQL Injection la TLD. Way to go.
Meekuu November 28, 2012 at 17:45
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 November 28, 2012 at 18:29
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 November 28, 2012 at 17:48
Poți să-mi dai te rog sursa pentru SQL Injection ? De unde-ai aflat ?
alexandru maraloi November 28, 2012 at 23:58
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 November 29, 2012 at 00:26
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).
Sabotor November 29, 2012 at 11:52
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.
Adi November 29, 2012 at 13:01
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 November 29, 2012 at 13:06
Î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 ?
ViRii November 29, 2012 at 17:36
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 November 29, 2012 at 18:45
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…