Month: August 2014

Researchers take advantage of cloud service providers’ free trials and lousy anti-automation controls to use cloud instances like bots.

LAS VEGAS — Black Hat USA — Thrifty attackers, are you tired of investing your dollars in a botnet that’s constantly being disrupted by new anti-virus signatures and bot downtime? A “cloudbot” might be just what you seek. As shown at Black Hat last week by Rob Ragan and Oscar Salazar, senior security associates at Bishop Fox, cloudbots are entirely free and very resilient, and they offer all the uptime of a cloud service with no need for malware. Good news for bot masters working on the cheap.

Bad news for cloud service providers that use poor anti-automation measures. As Salazar and Ragan showed in their Black Hat session, “Cloudbots: Harvesting CryptoCoins Like a Botnet Farmer,” confirming registrations with email alone is not enough to prove a registrant is a unique human. Without adding captchas, SMS verification, or other anti-automation measures, online services could find themselves powering activities like cryptocurrency mining and denial-of-service attacks.

The researchers specifically went after free cloud services — or those with free trials — that host infrastructure or development platforms.

“We were able to gather thousands of those [services’] accounts and control them just as a botnet herder would control a traditional botnet by spreading malware,” Ragan says in an interview with DarkReading. “We were basically able to register a bunch of free trials and have control over these accounts… and build a system — a framework, if you will — for targeting online services.”

How it’s done
As Salazar explains, they begin by using Google App Engine’s inbound mail handler, which transfers mail into a POST request that Google posts to a user’s web server. Using that, they were able to receive email as though it were a POST request coming from anybody’s browser and then “scrape the content” from the email.

“We look through the body of the email and look for URLs — [cloud service] activation links, essentially,” Salazar says. “And from the service itself, we request the activation link. Instead of having to go click on it ourselves, it gets automaticaly requested for us by our application.”

Then they headed to FreeDNS.afraid.org and created a wide variety of subdomains, for free, using domains donated by generous souls. Using FreeDNS, they were able to register MX records, which are used to point servers to mail.

After that, they use yet another cloud service that converts email into an adjacent object and pastes it back to the server.

“So, using that full setup, you go to a website you want to sign up for [and] type in an email address containing a random local part” and a domain registered from FreeDNS, says Salazar. “As soon as we click ‘activation’ on the submit link, an email is sent. But we’re not receiving the email; our application is receiving the email and is clicking the registration link for us. At that point, we don’t need to do anything at all.”

For the purpose of their proof-of-concept, Ragan and Salazar used this process to create 1,000 accounts at roughly 150 services — small companies, startups, and some third-party resellers of bigger cloud providers — and gathered more than a terabyte of free storage. They could have made it much bigger. According to the researchers, the script can be run as often as they like, so the size of the “cloud botnet” is limited merely by the amount of effort one wants to put into registering new instances.

“Gather enough of them,” says Ragan, “and it’s a supercomputer for free.”

Benefits for the attacker
A cloud botnet is undoubtedly economical.

“All that we really required to build this was a low-end laptop, a browser, and an Internet connection,” says Ragan. And, of course, the “bots” themselves were free.

Plus, they’re simply higher quality than your average bot. They’re powerful, energy-efficient, resilient, and nearly always available.

“All these [cloud] providers have low-latency, high-bandwidth, high-availability Internet connections,” says Ragan. “Their whole business model is that [they’re] online and available 99.999% of the time. And that’s a lot different than a botnet that works off personal home computers that may go offline at the end of the night or might have a slow DSL connection.”

“A lot [of cloud services] let you shut down the instance while you didn’t need it,” says Salazar. “So essentially it would be like a sleeper bot. It wouldn’t be using system resources when you didn’t need them, and [that would] make it a lot less likely to be identified.”

They made other efforts to avoid detection, as well. They could create accounts on one cloud service provider and use it to launch attacks on another, avoiding the need even for Tor exit nodes or VPN endpoints.

“Also, we didn’t have a central point of command and control,” says Ragan. “We leveraged a Python framework called Fabric, which is designed for system administrators to manage a datacenter or internal service management, and all that’s required is SSH access into like a Linux machine, for example — which is what we were getting from these free cloud service providers. SSH access into a Linux [virtual machine].

“And at that point, we could manage that all with our private keys, and we could launch our scripts and commands from any one of those cloud service providers we had access to. We could move around and be coming from new locations every time we launched a new command.”

Also, though they expect that they did stretch the limits of some terms of service, creating this sort of botnet is not entirely illegal, because no machines are being infected with malware.

Since the botnet does not require malware, it needn’t go through the process of updating code every time an anti-virus provider writes a new signature. Some bots will, however, die when a free trial expires, but those changes are predictable, and the bots can be easily replaced by simply registering more accounts.

However, if attackers did want to use malware in the next stage of an attack, they could simply use their cloudbots’ development environments to do all their coding in the browser, without ever storing it on their own hard drives.

What cloud providers should do
Salazar and Ragan think that bad guys may already have had the same ideas they did. Before they even had a chance to try out their registration script on some sites, they found that some services’ free trials were “temporarily disabled” entirely, and that one of them specifically said that it had been disabled because of suspected abuse by criminal hackers.

“If you have a company and you have to shut down registration,” says Ragan, “that’s money lost.”

Two-thirds of the services the researchers looked at used only email confirmation to fight automation.

“We realized that this was really an antiquated approach,” says Ragan. “That ‘one person equals one email address.’ That’s simply not the case anymore.”

The solution could be introducing more anti-automation technologies like captchas or verification by mobile devices. However, online businesses also don’t want to make it really onerous for legitimate users to complete their registration — because that could lose money, too.

Therefore, Ragan and Salazar suggest that companies might turn on those extensive anti-automation measures only when there is an anomaly. If there are usually 100 registrations per day, and suddenly 1,000 registrations arrive in 10 minutes, then there is a good chance that there is malicious activity. However, instead of shutting down the registration service entirely and closing out legitimate new customers, companies can temporarily enable further account verification measures, thereby combating malicious entities and accepting any new legitimate registrants who have the patience to complete the process.

Another option for small service providers is to use a federated identity solution — letting users register with their Facebook account, for example — and leave all the complicated identity and access management to someone else.

In the meantime, any website — not just cloud service providers — needs to have a closer look at its anti-automation tools and procedures.

“One of the things we wanted to answer is ‘Will we continue to see this as a rising trend?'” says Ragan, “and the answer is undoubtedly yes.”

Sara Peters is contributing editor to Dark Reading and editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad of other topics. She authored the 2009 CSI Computer Crime and Security Survey and founded the CSI Working Group on Web Security Research Law — a collaborative project that investigated the dichotomy between laws regulating software vulnerability disclosure and those regulating Web vulnerability disclosure.

[Source: DarkReading]

For most organizations, bring your own device (BYOD) is a fact of life or soon becoming one. People want to use the same mobile device(s) for both their work and personal lives and have some freedom of choice as to the devices they use. The more competition an organization faces in recruiting and retaining employees, the more likely a company is to allow some form of BYOD. It can also increase productivity and communication for employees, since they are likely to be always connected.

However, BYOD also brings some interesting security challenges. Most of the challenges arise from the potential of sensitive information being stored on mobile devices. ISACA has a set of guidelines that can be helpful for securing mobile devices. Organizations could require that BYOD users follow suchguidelines. In addition, BYOD users frequently connect to the cloud as a way to get their work email or share files and this poses some specific challenges.

For example, consider BYOD and the use of Dropbox or similar cloud file-sharing services for business purposes. Many organizations use Dropbox as a way to easily share files, even sensitive files, between users. The files are stored in Dropbox’s cloud and are encrypted using 256-bit AES encryption (both at rest and in transit), which is decent enough encryption for most corporate use. Generally, the files are also automatically synced with the mobile device. This may not be a concern for devices owned by the organization, but with BYOD, the employee now has a copy of a potentially sensitive file on his or her own device. If the device was then lost or stolen, it is possible that the sensitive data could be compromised, resulting in a data breach.

If this is a concern, organizations can mandate by policy that BYOD users only access the shared files on demand and not download local copies. This is fairly straightforward with Dropbox. Similar policies could be enabled for email use when the organization is using a cloud-based email service, such as Gmail. For example, the policy might only allow the use of email from a browser or app, rather than allowing local copies of messages and attachments to be stored on the device.

If local storage of potentially sensitive files and email is allowed, there are additional precautions that could be taken. Local data encryption, particularly on notebooks, is an option. Smartphones, tablets and, with additional software, even notebooks often have a remote-wipe capability that can be triggered if the device is lost. Ideally, this remote wipe should be something that not only the BYOD users but also their IT departments can trigger on the device. In addition, PINs, passwords, two-step verification or biometrics must always be used to protect access to the device. Devices that do not have such authentication should be prohibited from accessing the company network or cloud.

Of course, the security policy should also mandate that the sharing of personal work files should be kept separate. In the case of Dropbox, use a separate Dropbox for each one. Otherwise, an employee wanting to share sensitive information may inadvertently share work information with friends and family.

Since BYOD is a fact of life and is likely being used in conjunction with work in the cloud, organizations need to review and update their security policies and security awareness training to ensure that sensitive data remains secure.

Rob Clyde, CISM
CEO of Adaptive Computing
ISACA International Vice President

[Source: ISACA]

Information technology (IT) has a main role in our society and economy. It is known that most of the essential services, public and private, mass media, security forces and, of course, enterprises, depend on IT for the normal, everyday activities. But, it is not so widely known that every one of those essential services and IT assets depend more and more on industrial control systems (ICSs). ICSs are responsible for the control and management of physical security systems in data centers, as well as refrigeration towers and electric generators providing energy to the fire extinguish systems, among many other aspects.

ICSs are the bases of the main critical infrastructures and essential services in our nations and, therefore, their security and protection rests in them. This has made ICSs a target for cyberterrorism, advanced persistent threat attacks and cyberwar.

This fact, besides a lack of security requirements in their design, deployment and operation, has allowed the development of real cyberweapons whose objective is to exploit the existing vulnerabilities in these systems.

Therefore, our society and economy are vulnerable. Stuxnet, Duqu, Anonymous, Flame, Shamoo, Careto, botnets or denial of service attacks are words and concepts appearing more and more in the media, trying to explain information leaks, service outages, electrical blackouts and other incidents that affect our essential services.

In a global market with more competitiveness and complex and growing threats, this situation is unsustainable. It is necessary to employ large amounts of work, develop plans, implement measures and, of course, provide important economic resources to decrease the gap of vulnerability to the attackers, and increase the level of protection of our industrial and critical infrastructures.

This new area, called industrial cybersecurity, addresses these issues. It is the set of practices, processes and technologies designed to manage the risk of cyberspace when using, processing, storing and transmitting information in industrial infrastructures and organizations, and focuses on the people, processes and technologies involved. In this increasingly complex world, many disciplines need to team up to reduce the risks related to cyberterrorism and protect our critical assets.

Samuel Linares
Director, Industrial Cybersecurity Center (CCI)

[Source: ISACA]