Monthly Archives: April 2015

A Javascript-based DDoS Attack as seen by Safe Browsing

To protect users from malicious content, Safe Browsing’s infrastructure analyzes web pages with web browsers running in virtual machines. This allows us to determine if a page contains malicious content, such as Javascript meant to exploit user machines. While machine learning algorithms select which web pages to inspect, we analyze millions of web pages every day and achieve good coverage of the web in general. In the middle of March, several sources reported a large Distributed Denial-of-Service attack against the censorship monitoring organization GreatFire. Researchers have extensively analyzed this DoS attack and found it novel because it was conducted by a network operator that intercepted benign web content to inject malicious Javascript. In this particular case, Javascript and HTML resources hosted on baidu.com were replaced with Javascript that would repeatedly request resources from the attacked domains. While Safe Browsing does not observe traffic at the network level, it affords good visibility at the HTTP protocol level. As such our infrastructure picked up this attack, too. Using Safe Browsing data, we can provide a more complete timeline of the attack and shed light on what injections occurred when. For this blog post, we analyzed data from March 1st to April 15th 2015. Safe Browsing first noticed injected content against baidu.com domains on March 3rd, 2015. The last time we observed injections during our measurement period was on April 7th, 2015. This is visible in the graph below, which plots the number of injections over time as a percentage of all injections observed: We noticed that the attack was carried out in multiple phases. The first phase appeared to be a testing stage and was conducted from March 3rd to March 6th. The initial test target was 114.113.156.119:56789 and the number of requests was artificially limited. From March 4rd to March 6th, the request limitations were removed. The next phase was conducted between March 10th and 13th and targeted the following IP address at first: 203.90.242.126. Passive DNS places hosts under the sinajs.cn domain at this IP address. On March 13th, the attack was extended to include d1gztyvw1gvkdq.cloudfront.net. At first, requests were made over HTTP and then upgraded to to use HTTPS. On March 14th, the attack started for real and targeted d3rkfw22xppori.cloudfront.net both via HTTP as well as HTTPS. Attacks against this specific host were carried out until March 17th. On March 18th, the number of hosts under attack was increased to include the following: d117ucqx7my6vj.cloudfront.net, d14qqseh1jha6e.cloudfront.net, d18yee9du95yb4.cloudfront.net, d19r410x06nzy6.cloudfront.net, d1blw6ybvy6vm2.cloudfront.net. This is also the first time we find truncated injections in which the Javascript is cut-off and non functional. At some point during this phase of the attack, the cloudfront hosts started serving 302 redirects to greatfire.org as well as other domains. Substitution of Javascript ceased completely on March 20th but injections into HTML pages continued. Whereas Javascript replacement breaks the functionality of the original content, injection into HTML does not. Here HTML is modified to include both a reference to the original content as well as the attack Javascript as shown below: [… regular attack Javascript …] In this technique, the web browser fetches the same HTML page twice but due to the presence of the query parameter t, no injection happens on the second request. The attacked domains also changed and now consisted of: dyzem5oho3umy.cloudfront.net, d25wg9b8djob8m.cloudfront.net and d28d0hakfq6b4n.cloudfront.net. About 10 hours after this new phase started, we see 302 redirects to a different domain served from the targeted servers. The attack against the cloudfront hosts stops on March 25th. Instead, resources hosted on github.com were now under attack. The first new target was github.com/greatfire/wiki/wiki/nyt/ and was quickly followed by github.com/greatfire/ as well as github.com/greatfire/wiki/wiki/dw/. On March 26th, a packed and obfuscated attack Javascript replaced the plain version and started targeting the following resources: github.com/greatfire/ and github.com/cn-nytimes/. Here we also observed some truncated injections. The attack against github seems to have stopped on April 7th, 2015 and marks the last time we saw injections during our measurement period. From the beginning of March until the attacks stopped in April, we saw 19 unique Javascript replacement payloads as represented by their MD5 sum in the pie chart below. For the HTML injections, the payloads were unique due to the injected URL so we are not showing their respective MD5 sums. However, the injected Javascript was very similar to the payloads referenced above. Our systems saw injected content on the following eight baidu.com domains and corresponding IP addresses: cbjs.baidu.com (123.125.65.120) eclick.baidu.com (123.125.115.164) hm.baidu.com (61.135.185.140) pos.baidu.com (115.239.210.141) cpro.baidu.com (115.239.211.17) bdimg.share.baidu.com (211.90.25.48) pan.baidu.com (180.149.132.99) wapbaike.baidu.com (123.125.114.15) The sizes of the injected Javascript payloads ranged from 995 to 1325 bytes. We hope this report helps to round out the overall facts known about this attack. It also demonstrates that collectively there is a lot of visibility into what happens on the web. At the HTTP level seen by Safe Browsing, we cannot confidently attribute this attack to anyone. However, it makes it clear that hiding such attacks from detailed analysis after the fact is difficult. Had the entire web already moved to encrypted traffic via TLS, such an injection attack would not have been possible. This provides further motivation for transitioning the web to encrypted and integrity-protected communication. Unfortunately, defending against such an attack is not easy for website operators. In this case, the attack Javascript requests web resources sequentially and slowing down responses might have helped with reducing the overall attack traffic. Another hope is that the external visibility of this attack will serve as a deterrent in the future. Source: http://googleonlinesecurity.blogspot.ca/2015/04/a-javascript-based-ddos-attack-as-seen.html

Originally posted here:
A Javascript-based DDoS Attack as seen by Safe Browsing

DDoS threat recognized by all members of the C-suite

The increasing number and size of DDoS attacks and their costly and devastating effects on brand perception have not passed unnoticed by North American businesses, most of which have heightened their …

Read More:
DDoS threat recognized by all members of the C-suite

Banks Lose Up to $100K/Hour to Shorter, More Intense DDoS Attacks

Distributed denial of service attacks have morphed from a nuisance to something more sinister. In a DDoS attack, heavy volumes of traffic are hurled at a website to halt normal activity or inflict damage, typically freezing up the site for several hours. Such exploits achieved notoriety in the fall of 2012 when large banks were hit by a cyberterrorist group. But the Operation Ababil attacks were simply meant to stop banks’ websites from functioning. They caused a great deal of consternation among bank customers and the press, but little serious harm. Since then, the attacks have become more nuanced and targeted, several recent reports show. “DDoS is a growing problem, the types of attack are getting more sophisticated, and the market is attracting new entrants,” said Rik Turner, a senior analyst at Ovum, a research and consulting firm. For example, “we’re seeing lots of small attacks with intervals that allow the attackers to determine how efficiently the victims’ mitigation infrastructure is and how quickly it is kicking in,” he said. This goes for banks as much as for nonbanking entities. Verisign’s report on DDoS attacks carried out in the fourth quarter of 2014 found that the number of attacks against the financial industry doubled to account for 15% of all offensives. DDoS activity historically increases during the holiday season each year. “Cybercriminals typically target financial institutions during the fourth quarter because it’s a peak revenue and customer interaction season,” said Ramakant Pandrangi, vice president of technology at Verisign. “As hackers have become more aware of this, we anticipate the financial industry will continue to see an increase in the number of DDoS activity during the holiday season year over year.” In a related trend, bank victims are getting hit repeatedly. “If you have an organization that’s getting hit multiple times, often that’s an indicator of a very targeted attack,” said Margee Abrams, director of security services at Neustar, an information services company. According to a report Neustar commissioned and released this week, in the financial services industry, 43% of bank targets were hit more than six times during 2014. Neustar worked with a survey sampling company that gathered responses from 510 IT directors in the financial services, retail and IT services, with strong representation in financial services. (The respondents are not Neustar customers.) The average bandwidth consumed by a DDoS attack increased to 7.39 gigabits per second, according to Verisign’s analysis of DDoS attacks in the fourth quarter of 2014. This is a 245% increase from the last quarter of 2013 and it’s larger than the incoming bandwidth most small and medium-sized businesses, such as community banks, can provision. At the same time, DDoS attacks are shorter, as banks have gotten relatively adept at handling them. Most (88%) detect attacks in less than two hours (versus 77% for companies in general), according to Neustar’s research. And 72% of banks respond to attacks in that timeframe. Some recent DDoS attacks on banks have been politically motivated. Last year, a hacker group called the European Cyber Army claimed responsibility for DDoS attacks against websites run by Bank of America, JPMorgan Chase, and Fidelity Bank. Little is known about the group, but it has aligned itself with Anonymous on some attacks and seems interested in undermining U.S. institutions, including the court system as well as large banks. But while attacks from nation-states and hacktivists tend to grab headlines, it’s the stealthy, unannounced DDoS attacks, such as those against Web applications, that are more likely to gum up the works for bank websites for short periods and are in fact more numerous, Turner noted. They’re meant to test the strength of defenses or to distract the target from another type of attack. For example, a DDoS attack may be used as smokescreen for online banking fraud or some other type of financially motivated fraud. In Neustar’s study, 30% of U.S. financial services industry respondents said they suffered malware or virus installation and theft as a result of a DDoS attack. “What I hear from our clients is that DDoS is sometimes used as a method to divert security staff so that financial fraud can get through,” said Avivah Litan, vice president at Gartner. “But these occurrences seem to be infrequent.” Her colleague Lawrence Orans, a research vice president for network security at Gartner, sounded skeptical about the frequency of DDoS-as-decoy schemes. “I think there is some fear-mongering associated with linking DDoS attacks with bank fraud,” he said. However, “the FBI has issued warnings about this in the past, so there is some validity to the issue of attackers using DDoS attacks as a smokescreen to distract a bank’s security team while the attacker executes fraudulent transactions.” According to Verisign’s iDefense team, DDoS cybercriminals are also stepping up their attacks on point-of-sale systems and ATMs. “We believe this trend will continue throughout 2015 for financial institutions,” Pandrangi said. “Additionally, using an outdated operating system invites malware developers and other cyber-criminals to exploit an organization’s networks. What’s worse is that thousands of ATMs owned by the financial sector in the U.S. are running on the outdated Windows XP operating system, making it vulnerable to becoming compromised.” Six-Figure Price Tag DDoS attacks are unwelcome at any cost. Neustar’s study puts a price tag on the harm banks suffer during such attacks: $100,000 an hour for most banks that were able to quantify it. More than a third of the financial services firms surveyed reported costs of more than that. “Those losses represent what companies stand to lose during peak hours of transactions on their websites,” said Abrams. “That doesn’t even begin to cover the losses in terms of expenses going out. For example, many attacks require six to ten professionals to mitigate the attack once it’s under way. That’s a lot of salaries going out that also represent losses for the company.” Survey respondents also complained about the damage to their brand and customer trust during and after DDoS attacks. “That gets more difficult to quantify in terms of losses to an overall brand, but it’s a significant concern,” Abrams said. To some, the $100,000 figure seems high. “Banks have other channels for their customers — mainly branch, ATM and phone — so I don’t see that much revenue being lost,” said Litan. Other recent studies have also attempted to quantify the cost of a DDoS attack. A study commissioned by Incapsula surveyed IT managers from 270 North American organizations and found that the average cost of an attack was $40,000 an hour: 15% of respondents put the cost at under $5,000 an hour; 15% said it was more than $100,000. There’s no question banks have had to spend millions in aggregate to mitigate DDoS risks. “They created more headroom by buying more bandwidth and by scaling the capacity of their web infrastructure — for example, by buying more powerful web servers,” said Orans. “And they continue to spend millions on DDoS mitigation services. That’s where the real pain has been — the attackers forced the banks to spend a lot of money on DDoS mitigation.” Source: http://www.americanbanker.com/news/bank-technology/banks-lose-up-to-100khour-to-shorter-more-intense-ddos-attacks-1073966-1.html?zkPrintable=1&nopagination=1

Taken from:
Banks Lose Up to $100K/Hour to Shorter, More Intense DDoS Attacks

Mexican news site suffers DDoS Attack after publishing article on State Massacre

After publishing the article — titled “It Was The Feds” — news portal Aristegui Noticias reported suffering distributed denial of service (DDoS) attacks, which brought the site down for more than seven hours. Press freedom group Article 19 immediately called on authorities to guarantee the free flow of information. Additionally, the group called on the Mexican government to act in defense of journalists, “especially when they are providing vital information to the public as is in the case of Laura Castellanos.” Castellanos, the investigative reporter behind the article, has been the victim of intimidation, break-ins, and security threats over her decades-long career. In 2010, Article 19 included Castellanos in their journalist protection program. Mexico’s human rights commission called on the government to conduct a thorough investigation to “get to the truth” of the Apatzingán incident. “We want to let society know what happened that day,” human rights commission ombudsman Luis Raúl González Pérez said Tuesday. Source: https://news.vice.com/article/mexicos-government-is-brushing-off-report-of-another-state-massacre-of-unarmed-civilians    

More here:
Mexican news site suffers DDoS Attack after publishing article on State Massacre

Banking botnets persist despite takedowns

In order to provide organizations insight into the most insidious and pervasive banking botnets currently being used to target financial institutions and their clients, Dell SecureWorks released at RS…

See the article here:
Banking botnets persist despite takedowns

The rise and rise of bad bots – little DDoS

Many will be familiar with the term bot, short for web-robot. Bots are essential for effective operation of the web: web-crawlers are a type of bot, automatically trawling sites looking for updates and making sure search engines know about new content. To this end, web site owners need to allow access to bots, but they can (and should) lay down rules. The standard here is to have a file associated with any web server called robots.txt that the owners of good bots should read and adhere too. However, not all bots are good; bad bots can just ignore the rules! Most will also have heard of botnets, arrays of compromised users devices and/or servers that have illicit background tasks running to send spam or generate high volumes of traffic that can bring web servers to their knees through DDoS (distributed denial of service) attacks. A Quocirca research report, Online Domain Maturity, published in 2014 and sponsored by Neustar (a provider of DDoS mitigation and web site protection/performance services), shows that the majority of organisations say they have either permanent or emergency DDoS protection in place, especially if they rely on websites to interact with consumers. However, Neustar’s own March 2015, EMEA DDoS Attacks and Protection Report, shows that in many cases organisations are still relying on intrusion prevention systems (IPS) or firewalls rather than custom DDoS protection. The report, which is based on interviews with 250 IT managers, shows that 7-10% of organisations believe they are being attacked at least once a week. Other research suggests the situation may actually be much worse than this, but IT managers are simply not aware of it. Corero (another DDoS protection vendor) shows in its Q4 2014 DDoS Trends and Analysis report, which uses actual data regarding observed attacks, that 73% last less than 5 minutes. Corero says these are specifically designed to be short lived and go unnoticed. This is a fine tuning of the so-called distraction attack. Arbor (yet another DDoS protection vendor) finds distraction to be the motivation for about 19-20% of attacks in its 2014 Worldwide Infrastructure Security Report. However, as with Neustar, this is based on what IT managers know, not what they do not know. The low level, sub-saturation, DDoS attacks, reported by Corero are designed to go unnoticed but disrupt IPS and firewalls for just long enough to perpetrate a more insidious targeted attack before anything has been noticed. Typically it takes an IT security team many minutes to observe and respond to a DDoS attack, especially if they are relying on an IPS. That might sound fast, but in network time it is eons; attackers can easily insert their actual attack during the short minutes of the distraction. So there is plenty of reason to put DDoS protection in place (other vendors include Akamai/Prolexic, Radware and DOSarrest ). However, that is not the end of the bot story. Cyber-criminals are increasingly using bots to perpetrate another whole series of attacks. This story starts with another, sometimes, legitimate and positive activity of bots – web scraping; the subject of a follow on blog – The rise and rise of bad bots – part 2 – beyond web scraping. Source: http://www.computerweekly.com/blogs/quocirca-insights/2015/04/the-rise-and-rise-of-bad-bots.html

Continued here:
The rise and rise of bad bots – little DDoS

Week in review: APT wars, 18-year-old bug endangers Windows users, and main sources of data breaches

Here's an overview of some of last week's most interesting news and articles: Simda botnet taken down in global operation The Simda botnet, believed to have infected more than 770,000 computers …

Read the original:
Week in review: APT wars, 18-year-old bug endangers Windows users, and main sources of data breaches

Namecheap DNS Under DDoS Attack

Namecheap DNS hosting is under a DDoS attack, as a result millions of websites are offline. The company issued a statement : We regret to let you know that we are experiencing a DDoS attack against our default DNS system v2. If your domain name(s) is using DNS system v2, it may not be resolving properly at the moment. Unfortunately, there is no current ETA for the issue, but we are doing our best to mitigate the attack and minimize its affect on the service. We will keep you updated on the progress. An update was later posted : Update @ 7:45 AM EDT | 11:45 AM GMT The attack is still ongoing, unfortunately. We are doing our best to mitigate the attack as soon as possible. Your patience and understanding are highly appreciated Source: https://www.shieldjournal.com/namecheap-dns-under-ddos-attack/  

Read this article:
Namecheap DNS Under DDoS Attack

How startup GitHub survived a massive five-day DDoS attack

The collaborative coding site scrambled to withstand the opening salvo from what researchers dubbed China’s Great Cannon. But CEO Chris Wanstrath says that was just the beginning. To survive, startups must surmount challenges like product development, funding negotiations and cash flow. GitHub CEO Chris Wanstrath can add a very different challenge to his list: a sustained five-day network attack that some say marked the beginning of a new, more aggressive chapter in China’s relations with the outside computing world. GitHub’s business, founded in 2008, is all about letting programmers work together. It offers a place where individual coders can contribute to each other’s software projects, and where companies like Google, Facebook and Twitter can share work through the collaborative open-source movement. But on March 26, two organizations with GitHub accounts came under attack. Attacks on GitHub are common, though it can be nearly impossible to figure out their origins, Wanstrath said during an interview here at the company’s Merge conference. Even teenagers flexing their online muscles can launch an attack by buying access to a collection of machines. But this recent GitHub attack one was the worst in the company’s history. The company’s seven-person response team worked around the clock in a cat-and-mouse game to keep GitHub running even as the attackers shifted from one type of attack to another. Those two targeted GitHub sites were GreatFire.org, a nonprofit organization that tries to help people bypass Chinese censorship, and the Chinese New York Times, according to an analysis of the attack by network security software firm Netresec. But it hurt all of GitHub’s operations. That’s because it was a distributed denial-of-service (DDOS) attack, where countless computers around the world overwhelmed GitHub’s servers to the point where they couldn’t provide the online service they’re supposed to provide. Researchers dubbed the attack the Great Cannon. The Great Firewall of China has been around for years, letting the government block access to sites it doesn’t want its Chinese residents seeing, but the Great Cannon serves an offensive rather than defense purpose, the researchers at the University of Toronto, University of California and Princeton University wrote. When people visited innocent Web pages, the attacker’s servers would replace website code with malicious code that would direct their browsers to ceaselessly reload the GitHub pages. “The Cannon manipulates the traffic of bystander’ systems outside China, silently programming their browsers to create a massive DDOS attack,” the researchers said. The Chinese system could work similarly to one run by the US National Security Agency and its British counterpart, Government Communications Headquarters, according to documents leaked by former NSA contractor Edward Snowden. These programs, called Quantum and Foxacid, appeared to target the anonymous communication technology called Tor and employees at Belgian telecommunications company Belgacom, according to security expert Bruce Schneier and Der Spiegel, a German news publication. Wanstrath sat down with CNET’s Stephen Shankland to discuss the GitHub attack. The following is an edited transcript of their conversation. What was your first inkling that you were under attack? Wanstrath: A traffic spike. We started to get an unusual amount of traffic. It was coming from all over the world — were we on Oprah? Then we realized people’s phones or computers were getting hijacked to load GitHub. We saw the man-on-the-side attack. But that was just was the first attack of a series. Wanstrath: Yes. It was a mix of new stuff and boring stuff. The nature of the first attack was novel. After that we saw other attacks that were traditional, like SYN floods. In five days, we saw 18 or 20 attacks. How often are you attacked ordinarily? Wanstrath: Once a month, if not more. We’ve got monitoring. We have a good incident response program set up. When there’s an attack profile, you get paged. The main event of a DDOS is overwhelming the network with traffic. When you get a million requests and they’re exactly the same in one second, that’s a DDOS. We have automated systems, then an ops team on the network around the clock. So was somebody trying to send a message? Wanstrath: Of course. I just don’t know who the message was for. I’m not even sure the message is to us. You don’t need to be a state government to run this sort of attack. Sometimes it’s teenagers fighting over message boards. If it was from China, is there an easier way to target GreatFire and the New York Times than launching a five-day attack? Wanstrath: Sure. That’s why it’s confusing to conclude it came from China. In China, the New York Times is blocked, the Wall Street Journal is blocked. China blocks [lots] of websites. And after five days they chose to disengage? Did you vanquish the enemy? Wanstrath: It was an ongoing battle. We successfully mitigated some of their attacks. Even though we were winning, we were fighting the whole time. There was a lot of press about it, which may have contributed to the disengagement. What’s frustrating is there was no ransom note — no request for anything. Just an attack. What did it do to your business? Wanstrath: The outages are frustrating. We never went totally down, but people had errors. It interrupted people’s workflows. At GitHub, people were up all weekend. So is this a badge of honor? A sign that you’ve arrived? Wanstrath: It’s hard to feel that way when there are real people trying to do real work with GitHub. If this is what arriving is like, this isn’t what we signed up for. We’ve been attacked for awhile. We have defenses. But GitHub two or three years ago would not have successfully mitigated this attack. You can imagine a smaller company just falling over. What did you learn? Have you changed any technology or policies? Wanstrath: We learned a lot on a technical level. The DDOS is such a cat-and-mouse game. We can’t share broadly with the technology community to say here’s how to protect yourselves, though. It’s like bacteria. If the attackers know what we do, then they’ll stop doing that attack. Now, they don’t know what we know. Did you talk to the US government about the attack? Wanstrath: We can’t say it really has a China component because we can’t prove anything. We can’t really ask for help for anyone. I’m not sure what would have happened if this had lasted a month. Source: http://www.cnet.com/au/news/how-startup-github-survived-a-massive-five-day-network-attack-q-a/

Original post:
How startup GitHub survived a massive five-day DDoS attack

Borg routers open to repeat remote DoS attack

Patches cooked for five versions of Cisco’s IOS Remote attackers can send some Cisco routers into a continuous denial of service funk by rebooting network processor chips with a crafted attack. The high-severity hole (CVE-2015-0695) affects the IOS XR software in Cisco ASR 9000 Series Aggregation Services routers running Typhoon-based cards, the second-generation of line cards. The Borg says exploitation could cause “a lockup and eventual reload of a network processor chip and a line card that is processing traffic, leading to a denial of service condition”. “The vulnerability is due to improper processing of packets that are routed via the bridge-group virtual interface when any of the following features are configured: Unicast Reverse Path Forwarding, policy-based routing, quality of service, or access control lists,” Cisco says in an advisory. “An attacker could exploit this vulnerability by sending IPv4 packets through an affected device that is configured to route them via the BVI interface.” Users should apply the patches for five versions as there are no workarounds for the flaw. Software newer than version 4.3.0 are unaffected. The Borg does not know of any in-the-wild attacks using the vulnerabilities and has offered some techniques for admins to identity exposure. Source: http://www.theregister.co.uk/2015/04/16/borg_routers_open_to_repeat_remote_dos_attack/ http://whitepapers.theregister.co.uk/paper/view/3715/cyber-risk-report-2015.pdf

Read More:
Borg routers open to repeat remote DoS attack