29 Aug DNSSec day in Colombia Dmitry Bestuzhev
28 Nov Google.ro and other RO domains, victims of a possible DNS hijacking attack Stefan Tanase
01 Oct The tale of one thousand and one DSL modems Fabio Assolini
10 Jul Is it the end of the DNSChanger Trojan? Dmitry Bestuzhev
06 Jul The end of DNS-Changer Marco
07 Nov Massive DNS poisoning attacks in Brazil Fabio Assolini
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
Earlier today, Softpedia reported that an Algerian hacker using the nickname MCA-CRB has managed to deface the Romanian sites of Google (google.ro) and Yahoo! (yahoo.ro).
When we found out about this incident we were pretty skeptical of these websites being hacked. A website as large as Google can be hacked, in theory, but it’s highly unlikely. We then noticed that both domains resolve to an IP address located in the Netherlands: 18.104.22.168 (server1.joomlapartner.nl) – so it rather looks like a DNS poisoning attack.
The question which remains unanswered up until now is where exactly the DNS spoofing/poisoning attack has happened.There are several possible scenarios here:
This is the description of an attack happening in Brazil since 2011 using 1 firmware vulnerability, 2 malicious scripts and 40 malicious DNS servers, which affected 6 hardware manufacturers, resulting in millions of Brazilian internet users falling victim to a sustained and silent mass attack on DSL modems.
We will show how cybercriminals exploited an under-the-radar vulnerability which affected thousands of outdated DSL modems across the country. This enabled the attack to reach network devices belonging to millions of individual and business users, spreading malware and engineering malicious redirects over the course of several months. The scenario was fuelled by the widespread neglect of ISPs, blunders from hardware manufacturers, under-educated users and official apathy.
If you think the task of cleaning up victims of the DNS Changer malware was a big challenge, imagine what it would be like to deal with 4.5 million modems compromised in this attack v all of them in sunny, beautiful Brazil.
Next Monday, 9th of July, at 06:00 (MEZ) the temporary DNS-servers setup by FBI will be shut down. But still there are still thousands of infected machines – one can wonder, what will happen to them?
Computers in the internet have their own address – the IP-address. There are two versions:
You clearly see that these addresses are not so easy to remember compared to e.g. “kaspersky.com”. Therefore the “Domain Name System” was created which translates domain-names as “kaspersky.com” to their respective IP-address to connect to the server.
The DNS-Changer malware replaces the DNS-servers on the infected system with its own. FBI Press Release
The reason they do this is because it facilitates “Click Hijacking”. This is a technique where infected users are redirected to advertisement websites from the criminals and “Advertising Replacement” where on legitimate websites the advertisements were exchanged with one from the criminals.
Luckily, the FBI caught the criminals and installed temporary DNS-Servers in order to avoid a “black-out” for the mass of infected computers.
This temporary solution will come to an end on Monday when the servers are shut down. When this happens, the infected machines will no longer able to resolve domain names in order to connect to e.g. a website.
Of course, if you know the address of the server you can still use it instead of the name e.g. 22.214.171.124 is “securelist.com” but this is not easy solution.
We would like to point out that despite the big noise around this topic, there is no need to panic. The solution is rather simple – read below for more.
First of all, it might be interesting to point out that in 2012 we detected 101.964 attempts by DNSChanger malware to infect our users.
The good news is that the infections were blocked and the number of infection attempts is going down.
For instance, this map of the past week shows that the amount of infection attempts/detections as decreasing. Of course, computers with no or old protection are still in danger of possible unspotted infections.
So, how to check if you are infected with DNSChanger?
The DNS Changer Working Group provides helpful information on their website – unfortunately, we previously mentioned that automatic websites setup for this purpose do not work 100% well. So, the manual solution of checking the DNS server IPs is better.
If you are infected, you can change your DNS entries to the free DNS-Servers from Google: 126.96.36.199 and 188.8.131.52. OpenDNS also offers two: 184.108.40.206 and 220.127.116.11, which we also recommend for additional security features.
The best solution is of course to install a security suite capable of detecting and cleaning the infection and fixing the DNS servers.
Since many DNSChanger infections are accompanied by TDSS, a rather nasty rootkit, you can also use our tool “Kaspersky TDSSKiller” in order to detect and delete the infection
In the past few days several Brazilian ISPs have fallen victim to a series of DNS cache poisoning attacks. These attacks see users being redirected to install malware before connecting to popular sites. Some incidents have also featured attacks on network devices, where routers or modems are compromised remotely.
Brazil has some big ISPs. Official statistics suggest the country has 73 million computers connected to the Internet, and the major ISPs average 3 or 4 million customers each. If a cybercriminal can change the DNS cache in just one server, the number of potential victims is huge.
Last week Brazil’s web forums were alive with desperate cries for help from users who faced malicious redirections when trying to access websites such as YouTube, Gmail and Hotmail, as well as local market leaders including Uol, Terra and Globo. In all cases, users were asked to run a malicious file as soon as the website opened.
We monitored one attack which saw a clean machine displaying this warning when opening Google:
It was not so long ago we saw Google blacklist complete sets of subdomains such as the co.cc domains. (http://www.seroundtable.com/co-cc-google-removal-13644.html) These were known to be hosting malicious websites. About the same time, I also started to investigate new ways of identifying domains connected to malicious content by analyzing the DNS information.
During my research I simply performed AXFR checks on domains that looked suspicious, but I quickly noticed that it was not only machines hosting phishing sites that have weak configurations in their nameservers. Many government sites, and nameservers handling TLD (Top Level Domains), allow AXFR. This is not a vulnerability in itself, but the information collected from the nameservers can be very valuable for attackers.
AXFR is the opcode for DNS zone transfer, this is a type of DNS requests that will allow you as en external person obtain all DNS information for a specific domain. It is used for administrators to replicate the databases containing the DNS data across a set of DNS servers. This also allows attackers to obtain all DNS data for a specific domain
Targetted attacks and hacktivism has been a very hot topic lately. This has put some pressure on governments, organisations and many large companies. We have seen that security has become a higher priority within companies, but it seems that most focus is on the new and technical vulnerabilities, which have resulted in the fact that old and trivial vulnerabilities are being forgotten.
One of my first checks was to see how many of the top level domains out there actually support AXFR. I based my research on the IANA TLD list available at http://data.iana.org/TLD/tlds-alpha-by-domain.txt. To my surprise about 30% out of all nameservers handling TLD allowed AXFR.
Since we posted about the compromised CA incident and related browser fixes, the incident has been labeled "Comodogate". Quite a bit of information has been released since then. There is even a voice that claimed responsibility for the breach, allegedly describing his attack and proving his success by disclosing a private key.
The CEO of Comodo (the Certificate Authority compromised in this incident) stirred an alphabet soup of speculation regarding attribution, or who may have performed the break-in and their motivations. At one point, he even compared the recent RSA incident as related, claiming the entire authentication layer of the internet is under attack. While the RSA-gate incident may seem to be coming from another, yet connected, part of the world, it was another attack on the trust inherent in authentication and cryptography services. There is more than a kernel of truth to the statement.
It is easy to say that authentication services are under attack across the internet. It's a lot like saying the browser is under attack in a flash of the obvious.
The voice that came forward and claimed responsibility for the attack and certificate theft posted the actual private key for one of the stolen certificates. It was data (outside of the CA and the true developers) only the thief could possess. You can verify the key yourself by following these instructions. He has done faceless interviews, he has assumed a twitter account and replied to all sorts of questions and tweets.
The author(s) is actively talking about his self. It's interesting reading the text from this voice, because its author is allegedly a source of the breakdown of the fundamental trust of authentication and trust on the internet as we know it. The voice comes across as though the reader should trust the character behind it. Can interested parties trust that this individual is *just* a 21 year old student as they claim? Why would you?
We've had a few queries from readers asking what DNS poisoning actually is.
As stated yesterday, DNS poisoning is the manipulation of an IP address for a certain DNS entry
So what does that really mean? To fully understand this, first you need to know some basics about how addresses work.
There are a few very big DNS servers which provide other, smaller, DNS servers with DNS/I.P. entries. These entries get stored in the cache of the smaller DNS servers. It's not the big servers, but the smaller ones that are being poisoned. Poisoning only lasts until the DNS server rechecks the entries with a large DNS server, so you may also hear this called DNS cache poisoning.
So, if you enter www.kaspersky.com in your browser, the DNS server is queried for the IP address assigned to this DNS name. (DNS names are mainly to make our lives easier). In this case the DNS server will respond with the IP address 18.104.22.168.
So the goal of DNS poisoning is to make the (small) DNS server say that another IP address (one of a site containing malicious content) is assigned to a certain DNS name.
How exactly can servers be poisoned? Well, DNS servers need to run an operating system and software to perform their tasks. Insecure settings and/or vulnerabilities in either of these can lead to the DNS server being poisoned, usually by malformed packets being sent to the server.
How can you protect yourself? This is a tricky question, because as a (DNS) client there is not that much you can do. For example, with modified hosts files, it's a local issue. But in this case the issue isn't local - it's up to your ISP or system administrator to make sure that everything is secure.
When DNS servers are poisoned so that users are directed to clones of legitimate sites, if the poisoning is done correctly, and the cloned sites are carefully constructed, the user won't notice anything unusual.
And I for one don't know many people who know the real IP addresses of the sites they visit...