106 Unknown Malware Attacks

It may be accepted knowledge that both known and unknown malware is increasing exponentially, but a recent report put a quantifiable wrapper around the statement: About 106 unknown malware types hit an average organization every hour last year, showing a drastic increase in just 12 months.

According to Check Point's 2015 Security Report, 2014 saw 48 times more malware attacks than the 2.2 downloads per hour reported in 2013. Adobe seems to be the preferred vector: The report showed that 52% of the files infected with unknown malware were PDFs, while just 3% were Microsoft Office files.

Bots have been amplifying and accelerating the spread of malware, and are one of the contributing factors to the spike. A full 83% of organizations studied were infected with bots in 2014, up from 73% in 2013, communicating and sharing data with their command and control servers every minute on average.

About half (47%) of those bots were active for more than 4 weeks, leading to untold amounts of data exfiltration. No wonder that 81% of the organizations analyzed suffered a data loss incident, up from 41% in 2013.

The report also took a look at insider threats and bring-your-own-device (BYOD), and current and past employee actions have a lot to do with malware success. The rise of BYOD has provided easier access to more organizational assets than any other intrusion point.

In 2014, 42% of businesses suffered mobile security incidents costing more than $250,000 to remediate. Almost three-quarters (72%) of IT providers agreed that their top mobile security challenge is securing corporate information, and 67% said their second biggest challenge is managing personal devices storing both corporate and personal data.

Related to this, the Check Point report looked at four main categories of risky 'shadow IT' applications: remote admin tools (RATs), file storage and sharing, peer-2-peer (P2P) file sharing and anonymizers. Research revealed that risk is nearly ubiquitous: 96% of organizations studied used at least one high-risk application in 2014, a 10% increase from the previous year. On average, 12.7 high-risk application events happen every hour.

`Today's cyber-criminals are sophisticated and ruthless: They prey on the weaknesses in a network, approaching any security layer as an open invitation to try to hack it,` said Amnon Bar-Lev, president of Check Point. `In order to protect themselves against attacks, security professionals and organizations alike must understand the nature of the latest exploits and how their networks are potentially impacted. Only by arming themselves with a combination of knowledge and strong security solutions can they truly protect themselves against these evolving threats. By making that security a critical asset to your business, you can turn security into an enabler. And in doing so, you're able to unlock innovation and foster an environment for high performance and productivity.`


Read original article

Your GitHub account is hacked

GitHub has revoked an unknown number of cryptographic keys used to access accounts after a developer found they contained a catastrophic weakness that came to light some seven years ago.

The keys, which allow authorized users to log into public repository accounts belonging to the likes of Spotify, Yandex, and UK government developers, were generated using a buggy pseudo random number generator originally contained in the Debian distribution of Linux. During a 20-month span from 2006 to 2008, the pool of numbers available was so small that it made cracking the secret keys trivial. Almost seven years after Debian maintainers patched the bug and implored users to revoke old keys and regenerate new ones, London-based developer Ben Cartwright-Cox said he discovered the weakness still resided in a statistically significant number of keys used to gain secure shell (SSH) access to GitHub accounts.

`If you have just/as of late gotten an email about your keys being revoked, this is because of me, and if you have, you should really go through and make sure that no one has done anything terrible to you, since you have opened yourself to people doing very mean things to you for what is most likely a very long time,` Cartwright-Cox wrote in a blog post published Monday. `It would be safe to assume that due to the low barrier of entry for this, that the users that have bad keys in their accounts should be assumed to be compromised and anything that allowed that key entry may have been hit by an attacker.`

Cartwright-Cox told Ars that he found about 94 keys on GitHub that contained the Debian-derived weakness. He said that after he reported his finding to GitHub officials in March he learned the actual number of site users was much higher. GitHub revoked the keys early last month, he said. GitHub officials didn`t respond to a request to comment.

Separately, the UK developer said he found nine GitHub SSH keys that contained woefully insufficient numbers of bits. Two of them had only 256 bits, making it possible for him to factor them and clone the private key in less than an hour. The remaining seven had only have 512 bits.

During the time the Debian bug was active, the pool of bits available when generating OpenSSH keys was so limited that there were only 32,767 possible outcomes for a given architecture, key size, and key type. Cartwright-Cox said attackers could have used the same methods he employed to find weak keys and then used several techniques to gain unauthorized access to the accounts the keys protected. The task would have been aided by obtaining the list of insecure Debian SSH keys off one or more public sites, such as this one. In an e-mail, he elaborated:


If I wanted to be more noisy I could have just done what I said in the blog post and looped though the keys, that may or may not have set off alarms at Github itself (I`d give it a 25% chance that it would).

So the breakdown of how this could have been done is the following:

Grab the bad key list. It contains the public and private parts of all the SSH keys that would have been made if the user had a version of OpenSSH that had Debian RNG bug, then get each private key on the list, and try to log into GitHub`s ssh with them. Depending on what key you succeed with it will tell you what user name it matches up with, in the example I provided since my key is loaded it tells me `Hi benjojo! You`ve successfully authenticated, but GitHub does not provide shell access.` but if I was to try with a weak key that matched up with another user it would say `Hi {user}! You`ve successfully authenticated, but GitHub does not provide shell access.` and then I know what user I can compromise with that.

Technically, attackers don`t even need the private key to see if a site accepts authentication from a user, HD Moore, chief research officer at Rapid7 and co-founder of the Metasploit hacking framework, told Ars. Just the public key and this Metasploit module will do. `This trick can also be used to see what internet-facing servers allow logins from what public keys, even if the private key is not available, which is a neat reconnaissance/opsec technique,` Moore said.

The randomness bug was introduced in late 2006, when Debian maintainers removed two lines of code in the OpenSSL code base in an attempt to fix warnings received by some users. In the process, the maintainers wiped out almost all of the entropy that OpenSSL relied on for its randomness engine. The epic mistake, which eventually migrated to the Ubuntu distribution of Linux as well, wasn`t diagnosed for 20 months, and by that time an untold number of cryptographic keys had been generated.

The bug was unusual in that installing a patch was only the beginning of the healing process. To fully recover, users had to revoke any keys made during that 20-month period and generate new ones using the updated OS. The discovery that GitHub users continued to rely on these hopelessly weak keys eight years after they came to light is testament to just how monumental the Debian debacle was and how hard it is for users to mop up after the mess it created.

Read original article

DDoS Attacks Spike

In the first quarter of 2015, there were more distributed denial of service (DDoS) attacks than anytime during 2014—and there was a 7% increase from the previous quarter.

According to research from the Verisign iDefense Security Intelligence Services, the frequency of attacks against both public sector and financial services customers increased; each grew from 15% in Q4 2014 to represent 18% of all Verisign mitigations in Q1 2015. But the most-attacked industry was the IT services/Cloud/SaaS sector, representing more than one-third of all mitigation activity.

`Since the early days of the Internet, malicious actors have used DDoS attacks as tools of protest, financial gain, retaliation and simple mischief,` the report noted. `Today's DDoS attackers choose their targets and tactics for a number of reasons, many of which may not be clearly evident to the victims or the security professionals and law enforcement organizations who assist them.`

The ready availability of an increased number of DDoS toolkits and DDoS botnets for hire may also have contributed to increased attacks against these industries in Q1—and that several high-profile events on the world stage probably also contributed to the increase.

`Verisign believes this increase in attacks may be partially attributed to an increased employment of DDoS attacks as part of political activism, or hacktivism, against financial services firms and various international governing organizations,` the report noted. `Verisign also believes that these attacks may be in reaction to various well-publicized events throughout the quarter, including the Charlie Hebdo terrorist attacks in Paris, France, and protests in Venezuela, Saudi Arabia and the United States.`

In terms of volume, over half of all attacks peaked at more than 1Gbps, 34 percent of attacks peaked between 1Gbps and 5Gbps, and nearly 10 percent of attacks peaked at more than 10Gbps.

There were a few volumetric DDoS attacks too, with sizes that peaked in the double-digits; these were User Datagram Protocol (UDP) floods. The largest of these clocked in at 54Gbps/18 million packets per second (Mpps) and was primarily a UDP-reflection attack leveraging the Network Time Protocol (NTP) and Simple Service Discovery Protocol (SSDP) functions, in combination with a lower volume of SYN flood traffic. The attack targeted a cloud customer and persisted for approximately four hours.

VeriSign also saw 8 Gbps/22 Mpps for TCP-based attacks.

`Regardless of their motivations, however, DDoS attackers are proving more adept and effective than ever at disrupting their targets, and network-dependent organizations of all industries, types and sizes should consider their risk and prepare accordingly,` the report concluded.

Read original article

Busting Beebone

When Europol helped coordinate the April takedown of the Beebone botnet, information security expert Raj Samani - who assisted with the takedown - says everyone involved in the operation estimated that the polymorphic botnet was composed of about 12,000 infected systems, and that the majority were based in the United States

But actually, what we realized was the number of infected hosts were way higher. In fact, we`re seeing in our sinkhole somewhere between 30,000 to 40,000 unique infections per day. So, it`s way bigger than we initially thought, but the remediation is the painful part now,` says Samani, who is the Europe, Middle East and Africa chief technology officer for Intel Security - formerly known as McAfee. To date, there`s been about a 10 percent reduction in the number of infected hosts, from 37,000 to 33,000. But based on updated attack telemetry, researchers also found that the majority of infected botnet nodes are located in Iran, followed by Peru, neither of which is typically a hotbed of cybercrime or botnet infections.

The Beebone botnet - a.k.a. AAEH - is a polymorphic downloader, used by attackers to infect a PC and then install additional malware. The botnet is now being sinkholed, meaning that all related sites that were registered by attackers have been suspended, domain names seized, and data redirected to sites controlled by security experts. Related lists of infected IP addresses have also been distributed to Internet Service Providers and national Computer Emergency Response Teams, to warn victims and urge them to disinfect their PC.

In an interview recorded at Infosecurity Europe - where Samani is delivering a keynote devoted to critical-infrastructure security concerns - he also details:
•What happens after law enforcement agencies launch a botnet takedown;
•The need to reach and educate new markets with malware-related information;
•How to battle online attacks that cross borders.

Samani is Intel Security`s vice president and EMEA chief technical officer. He`s also a cybersecurity adviser to Europol`s European Cybercrime Center - EC3 - and the chief innovation officer for the Cloud Security Alliance. He has previously worked at the U.K. chapter of the Information Systems Security Association, consultancies CapGemini and Deloitte, and technology vendor Qualys.

Read original article

Blue Coat Fixes

Blue Coat has released a software update to address a total of four vulnerabilities affecting the web-based administration console (WebUI) of the company's SSL Visibility Appliance.

The Blue Coat SSL Visibility Appliance is an encrypted traffic management platform that provides organizations complete visibility into encrypted traffic. The WebUI, which allows customers to configure and manage the product, is accessible to authorized administrators through an HTTPS connection to the dedicated management port.

Vulnerabilities in the WebUI were discovered by Tim MalcomVetter from FishNet Security, who recently identified several security bugs in HP Network Automation.

The first vulnerability is a cross-site request forgery (CVE-2015-2852) that can be exploited by a remote attacker to gain access to the WebUI and perform various actions on behalf of an administrator. For the attack to work, the malicious actor must trick an administrator into visiting a specially crafted website

The SSL Visibility Appliance's WebUI is also vulnerable to clickjacking attacks due to improper validation of the request origin (CVE-2015-2854). Because the product doesn't enforce the same origin policy in X-Frame Options response headers, an attacker can gain access to the administration console by tricking the admin into visiting a malicious website. If the targeted user is not authenticated, the attacker can trick them into authenticating by using hidden iframes, Blue Coat said in its advisory.

The WebUI is also vulnerable to cookie theft (CVE-2015-2855) and session fixation (CVE-2015-2853).

An attacker capable of sniffing network traffic can steal or manipulate an administrator's cookie because these cookies don't have HttpOnly and Secure flags set. The stolen cookie can then be used to impersonate the administrator.

The session fixation bug allows an attacker to hijack a user's session by obtaining a valid session ID. Session IDs, which are set prior to authentication, can be obtained by an attacker because they are not invalidated or changed after authentication.

`A remote attacker's access is limited by the capabilities granted to the administrator. The attacker can only perform operations in the WebUI that the administrator could perform. The WebUI can be used to read and modify information such as configuration, audit logs, authorized users, and the health and status of the appliance. It can also can be used to reboot the appliance,` Blue Coat wrote in its advisory.

The vulnerabilities affect Blue Coat SSL Visibility Appliance SV800, SV1800, SV2800 and SV3800 running versions 3.6.x through 3.8.3 of SSL Visibility. Blue Coat has addressed the bugs with the release of SSL Visibility 3.8.4. The company has noted that fixes are not being provided for versions 3.8.2f and 3.7.4.

According to Blue Coat, potential attacks can also be prevented by limiting access to the SSL Visibility management port to trusted clients, allowing only known IP addresses to access the management port, assigning distinct roles to different types of administrators, and using ProxySG and WebPulse to block access to malicious websites from clients.

Read original article

Japan Pension Hacked

The personal data of more than one million Japanese citizens have been obtained by hackers, Japan Pension Service (JPS), an organization which manages Japan's universal public pension system, said on Monday

Toichiro Mizushima, president of Japan Pension System, told in a news conference that the Japan Pension Service staff computers were accessed by an external email virus, which led to the leak of almost 1.25 million cases of personal data.

During the conference, he apologized for the leak. He said that the combinations of names, identification numbers, birth dates and addresses of the Japanese citizens had been compromised. `The organization is setting up a team to investigate the cause and prevent a recurrence,` Mizushima said. According to a news report broadcasted on NHK public television, Abe said, `These are the people`s vital pensions.
I have instructed Health and Welfare Minister (Yasuhisa) Shiozaki to consider the pension recipients and do everything possible,` Shiozaki also apologized in the conference for failing to prevent the personal data from the hackers. He had instructed the Japan Pension Service to set top priority on protecting the public`s pensions -

Read original article

Hola VPN DDoS attacks

Hola is a VPN provider that purports to offer its users freedom from censorship, a way to access geoblocked content, and anonymous browsing. The service claims that more than 47 million people are part of its peer-to-peer network. But according to a group of researchers (calling themselves Adios), it`s dangerously insecure: the client software has flaws that allow for remote code execution and features of the client enabled tracking. On top of that, critically, Hola sells access to its peer-to-peer network with little oversight, enabling it to be used maliciously. The nature and scale of problems with Hola has researchers now saying users should bid adieu to the software.

Since the initial reports, Hola has made some changes. One method of remote code execution was removed—though the Adios team says that others remain—and the tracking flaw has also been fixed. But the deeper problems remain, and they`re fundamental to the way that Hola is built.

The company doesn`t hide the fact that the Hola network is peer-to-peer. Users of the service form a large network, and Hola traffic is routed through this network, using the connections of other Hola users. This is great for Hola; it means that the company doesn`t need to operate points of presence in different countries in order to make traffic appear to originate in these countries. But this is very risky for end users.

The example that Adios researchers give is a straightforward one: if you use Hola and someone else uses Hola to distribute child pornography, there`s a chance that they`ll do so using your Internet connection. This in turn could have the police kicking your door down.

This kind of risk isn`t unique to Hola. The Tor network has the same kind of problem: its exit nodes appear to be the traffic source (since that`s where traffic changes from being encrypted Tor traffic into regular, trackable Internet traffic), and that can cause liability issues for the operators of exit nodes. This is why the Electronic Frontier Foundation recommends against running an exit node from your home connection.

The difference is Tor exit node operators know what they`re doing and choose to take that risk. Hola users, for the most part, don`t know the risk exists, and they certainly aren`t electing to choose it. Hola does offer a way to prevent your connection being used in this way, however: switch from its free service to its paid one.

Moreover, the company is selling access to its network through an offshoot called `Luminati.` The Luminati business is selling bandwidth through an `almost unlimited number of real IP`s.` This kind of business isn`t unique; there are people who sell access to peer-to-peer networks with a large number of IP addresses. They tend to be criminals, selling access to botnets of compromised machines. Access to this kind of network is attractive to, for example, spammers (who want their junk e-mails to originate from as many IP addresses as possible) and those engaging in distributed denial of service attacks (lots of IP addresses means lots of distribution).

It is this paid access that was recently used to attack the 8chan image board. Hola`s founder claims that Luminati `screens` users and that the 8chan attacker slipped through. The Adios team found that in practice there were no meaningful restrictions, with a sales representative telling them `Luminati has no idea what you are doing on our platform.` Anyone willing to pay the price, ranging from $1.45 to $20 per GB, seems to have access to a massive botnet.

While the remote code execution problem, like the tracking problem, could in principle be fixed, problems due to Hola`s peer-to-peer nature appear to be intractable. Sending traffic through Hola users` connections is an integral feature of its peer-to-peer network. The Hola network assumes that there are enough users acting as exit nodes; if they were to all go away, the company would have to completely change how its network is built.

As such, the group of researchers is advising that all Hola users remove the software. For those who want to bypass geographic restrictions—a common use for Hola—there are any number of conventional, non-peer-to-peer VPN services out there. For those looking for anonymity online and bypassing of national censorship, the Tor network remains the gold standard.

Read original article