Hackers turn to DNS reflection for their DDoS attacks
Get a powerful Linux Dual-Core dedicated server for less than $2.67 a day!Tweet Share on Twitter.
June 3, 2013
A new report this morning suggests that hackers are increasingly turning to DNS reflection techniques in an effort to increase the volume of DDoS (distributed denial of service) attacks on the internet infrastructure.
Overall, those techniques have been known about for a few years but they were seldom used in anger, until the debilitating DDoS attacks in March that peaked at 300 Gbps against anti-spam firm Spamhaus and cloud-based DDoS mitigation company Cloud Flare.
DNS reflection attacks involve things like sending a request for a large DNS zone file to a DNS server, with the details of the request forged so that they appear to come from the IP addresses of the intended victim. And there are a few more ways to do that.
Open public-facing DNS servers then respond to the request with a large file. The attackers' requests are only a fraction of the size of the responses, meaning the attacker can effectively increase his attack by a factor of 100 from the sheer volume of bandwidth they control.
And the same sort of technique has been used as well to run a series of other attacks since, according to Matthew Prince, Cloud Flare's CEO. Traffic of 50 to 60 Gbps in each attack is becoming typical, and that's something that was unheard of, until March.
The numerous attacks on German-based Spamhaus illustrated the open DNS server issues. Mitigation actions since that attack mean that there are less open resources to exploit. But not every security expert agrees on that notion.
Nevertheless, exploiting open systems to run serious attacks of that nature remains relatively straightforward, according to Prince-- "All you need is just ten lines of code or so and a lot of patience,” he said.
As well as the recent high volume attacks, Cloud Flare is also seeing a certain growth in smaller but more sophisticated attacks, often targeting online multiplayer games and similar targets.
In one example, attackers are targeting login credential servers by blitzing them with fake usernames and passwords. The technique is designed to stop hacker rivals being able to log back after being denied access by so-called booter servers.
And with rivals unable to log back into the session, hackers can win by default, and that's the whole issue.
Initial "caveman with a club" SYN flood attacks designed to swamp an internet connection are being followed up by more sophisticated app layer attacks against credential servers, Prince explained. He added that, in many ways, DDoS attacks are getting run for much the same reasons that IRC flamewars used to take place in the old days.
Prolexic, another DDoS mitigation security company, separately announced that it had successfully blocked a massive DNS reflection DDoS attack that peaked at 167 Gbps against an unnamed "real-time financial exchange platform" on May 27.
“This was a massive attack that made up in brute force what it lacked in sophistication,” said Scott Hammack, Prolexic's CEO. “Because of the proactive DDoS defense strategies Prolexic had put in place with this specific client, no malicious traffic reached its website and downtime was avoided for the most part. The company wasn’t really aware it was under attack.”
The DDoS mitigation for this attack was distributed across Prolexic’s four cloud-based scrubbing centres in Hong Kong, London, and two in the United States.
Prolexic’s London-based scrubbing center mitigated the majority of the malicious traffic, which peaked at 90 Gbps back in mid-March.
More background information on DNS reflection DDoS attacks can be found in a whitepaper by Prolexic. We will continue to monitor these developments as they happen, and we'll report them to you once available.
In other internet security news
Google has decided that it's more than kosher to tell everybody about newly-discovered security holes in various software used in such things as PCs, laptops, tablets and smartphones a full seven days after it learns about them, even if that's not enough time for makers of vulnerable software to provide a good solution to the security issue.
Google used its Online Security Blog to deliver this writing-- “We recently discovered that attackers are actively targeting a previously unknown and unpatched security vulnerability in software belonging to another company.”
Ed. note: Google didn't name that 'other company' but whom other is it than Yahoo... Read on-- “We always report these cases to the affected vendor immediately, and we work closely with them to drive the issue to resolution.”
But that following up seems that it's not happening fast enough and Google seriously thinks that it's totally appropriate, as the post goes on to say “we believe that more urgent action -- within 7 days -- is appropriate for critical security vulnerabilities under active exploitation by hackers and attackers all over the globe.”
Seven days is therefore the time limit that Google will allow it to elapse before it “will support researchers making details available so that users can take steps to rapidly protect themselves.”
The logic behind Google's unilateral 'hurry-up guys' is that “each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more computers will be compromised.” And Google is 100 percent right when you think of it.
But Google hasn't explained yet what it considers “critical security vulnerabilities”. The Online Security Blog directs readers to this document at the Chromium Projects that details different levels of security-related severity.
The guidelines on offer there pertain only to web browsers. Just what represents a “critical security vulnerability” in a word processor or Android app isn't explained, at least not yet.
So there are some that wonder if Google has just proclaimed itself judge, jury and executioner all at the same time when it comes to software security bugs, inasmuch as it will decide what is a critical issue, and has set the time line in which software makers and vendors must address these issues or face public shaming (by Google).
And let's face it-- there's massive potential for this to blow up in Google's face. Imagine if Google publicises a security flaw that has been imperfectly mitigated, but the outing of the issue sparks even wider attempts at exploitation.
So there are some that will be keeping a close eye on this. A more nuanced response seems sorely needed and seven days seems a reasonable time to wait for the update, in our view. The internet community will be a better place, thanks to initiatives made by Google and others in the quest for better online surfing.
In other internet security news
Kaspersky Internet Security firm CEO and founder Eugene Kaspersky suggests that Huawei's telecom equipment could contain some doors, but they are probably not back doors, but somewhere in-between. However, there is nothing really wrong with Huawei, he said.
The Russian internet security company is nonetheless taking proactive steps to ensure that his company doesn't experience the same 'cold shower' reception Huawei has found in U.S. markets as well as in India recently.
Kaspersky comes to Australia almost every year and behaves a bit like a Richard Branson but Russian-style, putting on a stunt of some sort for the press, revealing extra-curricular adventures and offering some tidbits that hint at his history of association with Russia's various security programs.
For example, Kaspersky adopted the term “SCADA-Geddon” to describe a likely outcome of online warfare related to the Stuxnet Virus, but also not quite ever appearing entirely serious, nevertheless.
So the question is-- how much weight to place then, on Kaspersky's claims of grey areas in Huawei products? “We are not going to detect Huawei software as malicious,” he said. “And it's not just Huawei that has this grey area in their products. There was a very famous story about Sony rootkits as well, and a similar one with China's ZTE” he pointed out, before adding that he feels Huawei's troubles in the U.S. and India can be attributed to the detection of some suspicious behavior in its equipment and the knowledge of those issues being politicised.
Whatever it is, Kaspersky didn't want to talk politics, but did say that his company is aware of the fact it can be hurt from this, since Kaspersky sells security software in about fifty countries, including the U.S. and India.
“In the U.S., Australia and Western Europe, we are facing similar issues of trust,” he said, and he outlined plans to address those problems before they intensify or grow out of control.
“We are about to have a second backup and compiling systems in the U.S.,” he said. “Americans will have access to the source code and we will be very open to disclose the source code in case of specific requests.”
“We need to prove that we are from the other side of the world, but you can trust us, and we will do our best to confirm it and to prove it. If we have any questions like Huawei equipment about our technology, we will explain it to you, we will prove there is nothing wrong in our products and technologies.”
Kaspersky sounded very serious on that and delivered with all the weight of a CEO with his eye on growth. But as it seems to be the case with Kaspersky, also with an eye on the next move of the adversary.
In other internet security news
It's been revealed recently that the Stuxnet worm may have actually helped Iran's controversial nuclear program to move forward.
Critical internet-facing industrial systems controlling crucial equipment used by nuclear power plants, airports, factories and other sensitive systems are still subjected to sustained attacks within a few hours of appearing online, according to new research by Trend Micro.
The security vulnerabilities of SCADA (supervisory control and data acquisition) industrial control systems are numerous, and have been a major focus of interest in information security circles for the last three years or so thanks to Stuxnet, Duqu, and other similar noteworthy virus attacks.
A security expert has challenged a theory on how the infamous Stuxnet worm, best known for tampering with Iranian lab equipment, somehow escaped into the internet. New York Times reporter David Sanger wrote what's become the definitive account of how Stuxnet was jointly developed by a U.S. / Israeli team. The sophisticated malware virus was deployed to sabotage high-speed centrifuges at Iran's nuclear fuel processing plant by infecting and commandeering the site's control systems.
According to Sanger's sources, an Iranian technician's laptop was plugged into a Stuxnet-sabotaged centrifuge device and was almost immediately infected by the malfunctioning equipment.
The news that the Stuxnet worm may have helped Iran is according to a report published by the Royal United Services Institute, an influential defence think tank operating in Britain.
Stuxnet infected many systems at Iran's uranium enrichment facility at Natanz in 2009 and 2010, hobbling high-speed centrifuges after infecting computers connected to various SCADA industrial control systems at the plant.
The sophisticated attacks, seen as an alternative to a military strike against the facility, is credited with putting Iran's nuclear programme back by between eighteen months up to two years.
The malware worked by infiltrating the SCADA systems used to run the high-speed gas centrifuges. It then randomly and surreptitiously accelerated them and then slowed them down to induce seemingly random but frequent failures.
But a journal article published by the Royal United Services Institute claims that Iranian authorities redoubled their efforts after Stuxnet was discovered, so that production of fissile material went up - rather than down - a year after the SCADA-busting worm was discovered.
The malware acted as a wake-up call that prompted the Iranians to throw more resources at their ill-designed nuclear project, bonded personnel together and prompted security audits that uncovered critical security vulnerabilities that might otherwise have gone unnoticed, the Daily Telegraph also reported.
In 2012, the White House leaked its role in developing Stuxnet as part of a wider U.S.-Israeli effort, codenamed Operation Olympic Games, that began under the presidency of George W. Bush. Public revelation of this suspected role thwarted the slim possibility of a diplomatic resolution to Iran's nuclear ambitions, while acting to put the country closer towards a war footing with Israel.
The Washington-based Institute for Science and International Security claimed in February 2011 that Stuxnet likely destroyed about 1,000 IR-1 centrifuges, out of 9,000 deployed at Natanz.
Yet Ivanka Barzashka, an academic at King's College in London, who penned the RUSI article, says that the initial impact of the worm has been overestimated by those left somewhat awestruck by the effect of the world's first cyber-weapon.
"While Stuxnet may have had the potential to seriously damage Iranian centrifuges, evidence of the worm’s impact is circumstantial and inconclusive," wrote Barzashka in the RUSI journal.
"Related data shows that the 2009 version of Stuxnet was neither very effective nor well-timed and, in hindsight, may have been of net benefit to Iran," she added.
Barzashka's analysis is primarily based on publicly available data from the International Atomic Energy Agency. Tehran decommissioned and replaced about 1,000 high-speed IR-1 centrifuges at its fuel enrichment plant at Natanz over just a few months starting late in 2009.
However, since August 2010, the number of operational machines at Natanz has been steadily growing, as Barzashka claimed in her study-- "Iran began enrichment to 20 percent in one IR-1 cascade at the Pilot Fuel Enrichment Plant at Natanz in February 2010, ostensibly to manufacture its own fuel for the Tehran Research Reactor, which is used to produce medical isotopes. This development shows that Iran was able to successfully install and operate new machines in early 2010, between the first and second Stuxnet attack waves. If Stuxnet was the cause of the drop in machine numbers at block A26, it had no effect on Iran's ability to operate and install new IR-1 centrifuges several months later."
The Natanz fuel enrichment plant began operation in February 2007, but prior to Stuxnet, it could only produce enrichment levels of about 3.5 percent, which is suitable only as low-grade reactor fuel.
Barzashka explained that IAEA physical inventory data on the number of centrifuges installed at the Iranian facility are potentially misleading because machines have constantly been installed and upgraded over time.
Specific calculations reveal that performance at the FEP – measured as separative capacity – has increased every year since the beginning of operations in 2007," she writes. "Data for the 2010 reporting period – from November 22, 2009 to November 21, 2010 – are no exception.
In fact, uranium-enrichment capacity actually grew during the time that Stuxnet was said to have been destroying Iranian centrifuges.
Barzashka concluded-- "Iran produced more enriched uranium, more efficiently. The entire plant's separative capacity per day increased by about 40 percent, despite the fluctuations in centrifuge numbers. In January 2010, Iran was running 1,148 centrifuges fewer than it had operating seven months earlier, in May 2009," she said.
"In August 2010, IAEA inspectors counted the same number of machines as in August 2008, giving rise to the probable source of the claim that Stuxnet set back Iran's enrichment programme by two years," she added.
However, both of these raw numbers are misleading, according to the defence analyst. Barzashka says that while Stuxnet might have temporarily slowed Iran, at least in 2009, its operations emerged in fact stronger from the aftermath of the worm.
Its technicians improved centrifuge performance before achieving higher concentrations and greater volumes of enriching uranium than before.
Worse, the Iranians are far more wary about - and in fact better prepared to defend against - future cyber-attacks against their nuclear facilities by possible successors to Stuxnet.
"As a result, Iran's uranium-enrichment capacity increased and, consequently, so did its nuclear weapons potential," Barzashka wrote. "The malware - if it did in fact infiltrate Natanz - has made the Iranians more cautious about protecting their nuclear facilities.
"The malware didn't set back Iran's enrichment program, though perhaps it might have temporarily slowed down Iran's rate of expansion. Most importantly, Stuxnet or no Stuxnet, Iran's uranium enrichment capacity increased and, consequently, so did its nuclear weapons potential," she concludes.
Former Foreign Secretary Malcolm Rifkind criticized Barzashka's report before stressing that bilateral diplomatic talks between the U.S. and Iran remain the best method to address Iran's nuclear ambitions.
"Part of the objective of many people in the international community has been to stop, or if you can’t stop, to slow down the Iranian nuclear program," said Rifkind, chairman of Parliament's Intelligence and Security Committee in the U.K.
"In so far as Stuxnet may have done that, and I emphasise may have done that, it was a plus," he added. "What is undoubted is that Stuxnet significantly slowed down the enrichment process," he added.
Get a powerful Linux Dual-Core dedicated server for less than $2.67 a day!Tweet Share on Twitter.
You can link to the Internet Security web site as much as you like.