STE WILLIAMS

What’s This?

Lessons learned from a global consultancy’s 10-year transition from on-premises to 99% cloud-based infrastructure.

Let me share with you the story of a large, multinational technology consultancy’s migration from on-premises to 99% cloud-delivery infrastructure and applications. The transition began a decade ago with an email upgrade. The firm found it difficult to expand their physical server room so it moved to a cloud-based e-mail application. It took some work to find the right vendor and the right solution but, in the end, the company saved money, and soon added cloud-based CRM as well.

Because the consultancy was also growing crazy fast, officials needed to quickly add capacity. Soon they looked to the cloud for every new upgrade and app rollout. Their first true cloud environment was nailed up via an IPsec VPN to an early cloud player in the infrastructure-as-a-service (IaaS) business. They put a virtual Active Directory server up in the cloud to manage authentication, authorization, and accounting (AAA), and things just took off.  As this grew, they found they could deploy databases, web servers, applications—whatever the consultancy needed. The capacity was there with many of the security tools they were familiar with already.

One of the consultancy’s biggest security concerns was uptime, which they solved by finding a strong cloud vendor. Disaster recovery (DR) and business continuity are always big challenges, especially for a globally-dispersed and fast-growing organization like they had become. The trick was to make sure their cloud providers could match their requirements. This meant taking a lot of time to review contracts and service level agreements (SLAs) at the outset, and then holding the providers’ feet to the fire when promises did not match reality.

SLAs and Access
Management understood that a bad cloud provider could negatively impact uptime if the providers’ expectations are different from their own. For example, most organizations know how good or bad their own DR capability is, but for a cloud provider, it can be a mystery. Also, some interesting problems can creep through the cracks in ways you don’t expect. Having short outages of just several minutes randomly throughout the workday can be worse than one big long outage. This is especially true for non-real-time services like email, where you might not notice when messages aren’t getting delivered. However, some cloud provider SLAs are written to cover longer outages rather than the short ones, so it’s important to read carefully. This is especially true with platform-as-service (PaaS) cloud providers who are serving a single application and the vendor is more a niche (and therefore smaller and possibly weaker) player.

For the consultancy, managing access to their cloud was also a challenge, especially since they employed a mix of consultants and developers. Many people needed a wide range of access capabilities, and many needed full access to their own boxes. For this they turned to role-based access control to ensure people got what they needed on only the systems they needed and nothing else. Luckily, powerful security tools are available to do this. As needed, the consultancy can require multi-factor authentication (MFA) at the beginning of a session and then turn that around into single sign-on to ease access throughout the user workflow. This was especially helpful for those with elevated access as they could strongly authenticate them right off the bat.

Detection Monitoring
As for detective and monitoring security tools, most large IaaS vendors provide virtual networking capability, which the consultancy tapped for packet capture and analysis. PaaS vendors are used differently, but most provided detailed audit logs on user logins and actions which they needed for audit purposes. Some large IaaS vendors also provided additional monitoring alarms to help with pesky things like developers accidently dropping authentication credentials into public code repositories.

One major challenge for the consultancy was dealing with different cloud environments. Some cloud vendors who have multiple offerings can have different knobs and gauges for their varying services. The consultancy’s security operations team would learn how to lock down and monitor something in one service area, only to find that things worked much differently in another.

Then there are the frequent upgrades within the service, which can change the look of a console or add new features. Even within the same cloud provider, it can be like managing security for different applications and environments. This can lead to complexity and security blind spots. It gets even more difficult when there is a mixture of different cloud vendors. To this day, there are likely additional security capabilities that the consultancy hasn’t taken advantage of yet because they haven’t had the time to learn them. To help with this, it’s best to ensure that someone on the enterprise security team attends cloud provider training sessions and conferences.

Compliance: The Last Big Challenge
Commonly, most cloud providers certify their platform up to a certain level and then from there, you need to deal with additional risk and compliance requirements. Cloud providers don’t cover it all. That boundary and the accompanying responsibility is sometimes misunderstood by newcomers or executives. All things being equal, a non-technical person will just assume because XYZ Cloud has passed a particular audit, they think they’re done with security and they can rest. That’s almost never the case.

Overall, the consultancy’s journey to the cloud has been a game-changer. The lessons they learned made them a better and more valuable organization for their customers. And their security program has grown stronger.

Get the latest application threat intelligence from F5 Labs.

 

Raymond Pompon is a Principal Threat Researcher Evangelist with F5 labs. With over 20 years of experience in Internet security, he has worked closely with Federal law enforcement in cyber-crime investigations. He has recently written IT Security Risk Control Management: An … View Full Bio

Article source: https://www.darkreading.com/partner-perspectives/f5/journey-to-the-cloud-overcoming-security-risks/a/d-id/1331131?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

The German Interior ministry has confirmed that it has identified a serious attack against its servers, amidst reports that the culprits were the Russian APT28 – aka Fancy Bear – hacking group.

On Wednesday local news site DPA International reported that the German government discovered a serious intrusion into its servers in December 2017. The attack is thought to have seen data exfiltrated for up to a year before its discovery.

Johannes Dimroth, a spokesman for the ministry, confirmed that “government information technology and networks,” had been affected by an intrusion. “The incident is being treated as a high priority and with substantial resources,” he said.

Fancy Bear has been active for at least a decade. Its activities have often non-Russian government targets. The group was fingered for the Democratic National Committee hack ahead of the 2017 US Presidential election, attacks during the 2017 French election, brazen rummaging in Finnish security forces’ servers and even attacks on the sports doping authorities.

In December 2016 Germany’s Federal Office for the Protection of the Constitution took the unusual step of issuing a public warning about hacking ahead of national elections in September 2017. That warning named Russia as the likely culprit.

Russia has always denied that it has anything to do with Fancy Bear, but the types of malware used, the software and coding styles, and its choice of targets suggest that Putin and his pals might have Fancy Bear dancing to their tune.

This latest attack on Germany will not serve to warm relations between these two historical enemies. With Russia looking to take an increasingly muscular role in European affairs, hopefully such conflicts will not leave the online realm. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/01/german_government_confirms_hackers_blitzkrieged_its_servers_to_steal_data/

Vid The Spectre design flaws in modern CPUs can be exploited to punch holes through the walls of Intel’s SGX secure environments, researchers claim.

SGX – short for Software Guard eXtensions – is a mechanism that normal applications can use to ring-fence sections of memory that not even the operating system nor a hypervisor can access, let alone other programs.

These areas are called enclaves, and are typically used to run things like anti-piracy code without anyone spying on the decryption keys, or to run sensitive computational code on an untrusted remote machine. Attestation is used to ensure software on one box is talking to code running unaltered in an enclave on another box.

The speculative execution flaws revealed in January, however, jeopardize SGX’s security boundaries, as demonstrated in the video below. As is to be expected, exploiting the chip-level vulnerabilities requires local access: a miscreant must be able to log in, or malware must be running in order to leverage the design blunder to attack an SGX enclave.

The researchers – professors Yinqian Zhang, Zhiqiang Lin, and Ten Lai, plus students Guoxing Chen, Sanchuan Chen, and Yuan Xiao – hail from Ohio State University in the USA. They’ve dubbed their enclave-sniffing technique SgxPectre, and noted on GitHub: “Similar to their non-SGX counterparts, SgxPectre attacks exploit the race condition between the injected, speculatively executed memory references and the latency of the branch resolution.”

In a formal paper, placed online this week, the team explained how a malicious program can influence a CPU core’s branch predictor so that, when the processor is executing SGX enclave code, the contents of the secure environment’s private memory and CPU registers can be observed via slight changes to the state of the cache.

Youtube Video

Enclave code built using the Intel SGX SDK, Rust-SGX, Graphene-SGX, or similar runtime libraries, are vulnerable, we’re told. These development kits include code patterns that can be exploited via SgxPectre to work out what lies within an enclave’s secret memory.

The steps the researchers took to snoop on forbidden SGX data were as follows:

• Poison the branch target buffer to inject target addresses.
• Prepare the CPU so it’s more likely to speculatively execute the secret-leaking instructions in the enclave code’s SDK.
• Run the enclave code.
• Examine the monitoring array using a “flush-reload” cache side-channel attack to drip-feed out the contents of the enclave.

Woo-yay, Meltdown CPU fixes are here. Now, Spectre flaws will haunt tech industry for years

READ MORE

There is a fix: Intel’s microcode update that introduced indirect branch restricted speculation (IBRS), which flushes the branch prediction history at the enclave boundary.

However, an evil sysadmin at, for example, a cloud provider could revert the patch, and “there is no means for the enclave code to reliably detect if IBRS is enabled.” This means enclave code running on a remote cloud machine can be snooped on by BOFHs, when the whole point of SGX is to securely run code on a faraway box.

The other microcode mitigations, Single Thread Indirect Branch Predictors (STIBP), and Indirect Branch Predictor Barrier (IBPB), have the same problem, that they mitigate speculative execution, but the enclave can’t detect whether or not they’re present. Thus, these defenses can be removed from a remote machine, defeating the purpose of the technology.

The Reptoline software-only mitigations don’t protect SGX against SgxPectre, the researchers said. Intel is aware of their work, we’re told. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/01/us_researchers_apply_spectrestyle_tricks_to_break_intels_sgx/

Customers of HTTPS certificate reseller Trustico are reeling after being told their website security certs – as many as 23,000 – will be rendered useless within the next 24 hours.

This is allegedly due to a security blunder in which the private keys for said certificates ended up in an email sent by Trustico. Those keys are supposed to be secret, and only held by the cert owners, and certainly not to be disclosed in messages. In the wrong hands, they can be used by malicious websites to masquerade as legit operations.

Unless the affected certificates are replaced in time, visitors to websites using Trustico-sold HTTPS certs will be turned away by their browsers, due to the digital certificates being revoked.

The whole situation is a mess, and possibly the result of a turf war. Here’s what we’ve managed to ascertain.

What is Trustico?

Trustico, based in Croydon, UK, touted SSL/TLS certificates, which are used by websites to encrypt and secure their connections. It resold certs from the Symantec brand umbrella: Symantec, GeoTrust, Thawte, and RapidSSL. This umbrella is now owned and operated by DigiCert.

If you wanted to buy, say, a RapidSSL-issued certificate, you could do so via Trustico. The HTTPS cert ultimately leads back, along a chain of trust, to DigiCert, a root certificate authority trusted by web browsers and other software. In turn, the website presenting the Trustico-sold cert is trusted, its traffic secured using encryption, and the reassuring green padlock is displayed in visitors’ browsers.

Why are the certificates being revoked?

According to DigiCert’s chief product officer Jeremy Rowley earlier today, Trustico told DigiCert in early February that its resold certificates had been “compromised,” and that the certs needed to be mass revoked as a result.

DigiCert staff, we’re told, asked Trustico for more information on this security mishap. The reseller replied it had a copy of the private keys, which is usually grounds for revocation, and thus insisted that DigiCert revoke the certificates.

When pressed for evidence, Trustico on Wednesday simply emailed DigiCert 23,000 certificates’ private keys as proof it held this information, it is claimed. This forced DigiCert’s hand: under the rulebook of standards set by the elders of the certificate security and browser worlds, the Trustico-sold certificates had to be revoked as a precaution within 24 hours. Specifically, the ones with their private keys in the email will be canceled.

“Trustico has not provided any information about how these certificates were compromised or how they acquired the private keys,” explained Rowley.

“As is standard practice for a Certificate Authority, DigiCert never had possession of these private keys. Currently, we are only revoking the certificates if we received the private keys. There are additional certificates the reseller requested to have revoked, but DigiCert has decided to disregard that request until we receive proof of compromise or more information about the cause of this incident.”

On Twitter, Rowley continued: “I’ll likely be posting the private keys later once people have a fair chance to replace their certificates … The allegation of compromise, keys compromised, and request for revocation all came from Trustico.”

Before you raise an eyebrow too high, by posting the private keys, Rowley plans to disclose self-signed certificates, produced using the private keys, to prove the secret information was sent to DigiCert without revealing the actual information in public. Some have already popped online as proof DigiCert received the secret keys from Trustico.

Alarm bells

To warn netizens to the upcoming mass revocation, DigiCert’s RapidSSL business sent out email alerts to Trustico customers urging them to get new HTTPS certificates or watch their sites go dark. Here’s a copy of the memo, passed to El Reg:

Red alert … Click to enlarge

DigiCert also put out a blog post, giving its side of the story:

Trustico requested revocation of their Symantec, GeoTrust, Thawte and RapidSSL certificates, claiming the certificates were compromised. When we asked for proof of the “compromise,” Trustico did not provide details on why they were requesting the immediate revocation. Trustico’s CEO indicated that Trustico held the private keys for those certificates, and then emailed us approximately 20,000 certificate private keys.

When he sent us those keys, his action gave us no choice but to act in accordance with the CA/Browser Forum Baseline Requirements, which mandate that we revoke a compromised certificate within 24 hours. As a CA, we had no choice but to follow the Baseline Requirements.

Following our standard revocation process, we gave notice via email to each certificate holder whose private keys had been exposed to us by Trustico, so they could have time to get a replacement certificate.

Now, over to Trustico.

Upset and denials

We asked the Brit biz for comment, and had yet to hear back at time of writing. However, posting on Mozilla’s security policy newsgroup, Trustico product manager Zane Lucas was clearly upset that DigiCert sent out the above alert.

“We didn’t authorise DigiCert to contact our customers and we didn’t approve the content of their email,” wrote Lucas.

“At no time had any private keys been compromised, nor had we ever informed to you that any private keys had been compromised. During our many discussions over the past week we put it to you that we believe Symantec to have operated our account in a manner whereby it had been compromised. Your usage of the word compromise has been twisted by you to your benefit and is absolutely defamatory.”

To put this in context: Trustico was fed up with using Symantec certs, and on February 13, it formally abandoned the umbrella of brands – ahead of Google Chrome and Mozilla Firefox officially distrusting the certificates due to past security fumbles by Symantec. Trustico said it had complained privately to Symantec of long-running concerns over the security safeguards on Symantec-branded of certificates, hence Lucas’ reference to its Symantec account.

Although Lucas stressed the private keys for Trustico’s resold certificates were not compromised, it did, according to DigiCert, email a copy of 23,000 of them to the root authority seemingly to trigger their revocation. At that point, DigiCert considered the certificates at risk, and started the countdown clock to cancel them.

Trustico and DigiCert have clearly majorly fallen out, with the pair going their separate ways this month amid the behind-the-scenes drama. It even appears Trustico tried to stop DigiCert from using its online portal to send out today’s emailed warning.

In future, Trustico will flog Comodo HTTPS certificates rather than peddle Symantec-branded certs. Cynics have suggested the Brit reseller ordered the revocation of its Symantec-umbrella certs so it could drive its customers onto Comodo certificates, and thus avoid the looming Google Chrome HTTPS certificate apocalypse without losing many, if any, punters. In effect, website owners have been caught up in a turf war between Trustico and DigiCert.

How did Trustico get the private keys to certificates it resold? We don’t know for sure – but it did, and still does, offer an online private key generator for certificates. Just saying.

In an email sent to customers a few hours ago, and seen by The Register, Trustico said it will provide free certificates to replace the soon-to-be-nuked SSL/TLS certs:

Recently we wrote to you to let you know that we are no longer offering Symantec, GeoTrust, RapidSSL and Thawte branded SSL Certificates. Unfortunately, Google Chrome has decided to distrust these SSL Certificates. It’s important to us that you SSL Certificate continues to function as normal, and not be compromised by the distrust of the Symantec brands. It is now required that you replace any existing distrusted SSL Certificate with one that is trusted by all web browsers.

Rest assured, there hasn’t been any type of compromise of our systems. However, Symantec brands will cease to function correctly due to Google Chrome’s decision to distrust them.

Recently DigiCert acquired the Symantec SSL Certificate division and subsequently an e-mail was sent by DigiCert to some of our SSL Certificate customers advising of the revocation of their distrusted SSL Certificate. We didn’t authorise this e-mail to be sent and had specifically disabled it within the DigiCert system. We understand that the e-mail sent about your distrusted SSL Certificates may be confusing. It’s important that you take the opportunity to replace your SSL Certificate as soon as possible.

We’re providing free replacement of affected SSL Certificates. To enable a free replacement, you’ll receive an e-mail report today if you have affected SSL Certificates. Your report will contain a unique coupon code for each affected SSL Certificate. When you replace your distrusted SSL Certificates using your unique coupon codes you’ll receive extra validity free of charge. If you have any questions please feel free to reply to this e-mail.

Meanwhile, DigiCert said it, too, will offer free replacement certs to folks using Symantec-branded HTTPS certificates, which will be ignored by web browsers later this year. And, of course, don’t forget you can grab free HTTPS certificates from Let’s Encrypt that all major browsers trust.

Today has been marred with confusion. Trustico’s customer support lines have been jammed with complaints and queries, following DigiCert’s email alerts. Reg readers told us they felt left in the dark. Perhaps it’ll all be clearer in a few hours, when the dust has settled – and the certs have been nuked. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/01/trustico_digicert_symantec_spat/

RedDrop can steal data, record audio, and rack up SMS charges for victims, says Wandera.

RedDrop, a new family of malicious software found lurking in dozens of seemingly benign Android applications, is the latest indication of the increasingly dangerous capabilities that threat actors have begun integrating into modern mobile malware.

Security vendor Wandera recently discovered RedDrop hidden in 53 working Android applications, such as image editors, calculators, language learning apps, space exploration apps, and other educational, recreational, and practical tools. Each application functions as the user would expect, while executing malicious actions in the background.

Once an infected app is installed on an Android device, it downloads at least seven more Android Application Packages (APKs), each with its own malicious functionality and from a different command and control server. The APKs are stored in the system’s memory, giving attackers a way to execute them without having to embed the functionality in the original malware sample, Wandera said.

Data the malware is capable of stealing includes all locally saved files, including photos, contacts, and images; live recordings of the device’s surroundings; device and subscriber identifiers; application data; and SIM data.

When users interact with a RedDrop-infected app, it also secretly sends a cost-incurring SMS message to a premium service and then instantly deletes the message to avoid detection by the user. All data stolen from infected systems is uploaded to remote file storage systems controlled by the attackers for potential use in future extortion schemes or to launch further attacks, according to Wandera.

RedDrop apps are being distributed from a network of over 4,000 domains, all registered to a single group that looks like it might be operating out of China. Eldar Tuvey, Wandera’s co-founder and CEO, says that several infection vectors are being used to distribute the RedDrop family of malware.

The one with the broadest reach is through Chinese search giant Baidu.com, but users could also visit Sky-mobi, which happens to run one of the largest Android app stores in the world, he says. “We also believe advertising networks are being exploited by criminals in order to entice users towards the downloads.”

As with most Android malware tools — and indeed most mobile malware — RedDrop poses a threat mainly to users who voluntarily download apps from third-party sources and websites, something that security researchers have long warned against. People who download their apps only from Google’s official Play store or from properly vetted enterprise app stores are safe from the threat for the moment. Also for the moment, RedDrop appears to be primarily aiming at Android users in China, though many of the infected apps also target European and American users.

But underestimating mobile threats like RedDrop for such reasons might be a mistake. “Our data shows that around 20.6% of Android users have their configurations set to allow third-party installations,” Tuvey says. Despite warnings, many users are still willing to take the risks that come with installations through unofficial app stores, he says.

“In order to protect themselves from these types of threats, individuals and organizations with vulnerable devices should disable downloads from third-party app stores, unless absolutely necessary for business functionality,” Tuvey says.

Criminals have also begun ramping up threat activity targeted at mobile devices. In a report earlier this week, Trend Micro noted a sharp increase in the volume of mobile ransomware, banking Trojans, and other malware over the past year. Many of the threats are directed at Android devices, though Apple’s iOS is not immune either, according to Trend Micro.  

Ominously, threat actors have become increasingly better at uploading malware-laden apps to Google’s Play store, according to the Trend Micro report. As a result, users downloading their apps from there cannot be absolutely certain about their security either. Unsurprisingly, given the rapidly evolving threat landscape, four out of 10 enterprises see mobile devices posing a significant risk to their security.

“Android has an above-average amount of known security vulnerabilities, and hackers know this,” says Paul Bischoff, privacy advocate at Comparitech. Organizations that provide Android devices for work should consider setting up a guest account on each device, he says. “Guest accounts in Android cannot install apps from third-party sources due to a lower level of privileges. The main admin account should be password-protected.”

If employees are allowed to use their own Android devices, clear guidelines need to be laid out about what work-related activities are allowed on their phones and what security measures need to be in place, Bischoff says. Security administrators need to instruct employees not to change the “allow apps from unknown sources” setting on any personal phones used for work.

Organizations should also update their Android devices to Android Oreo, the latest version of the operating system, Tuvey says. Oreo includes controls that make it easier for users to detect and block apps with invasive permissions. Unfortunately, almost half of all installed Android devices are running versions of the operating system that predate the previous Marshmallow version and can be easily bypassed by RedDrop, Bischoff says.

Related content:

• Threats from Mobile Ransomware Banking Malware Are Growing
• The Mobile Threat: 4 out of 10 Businesses Report ‘Significant’ Risk
• Can Android for Work Redefine Enterprise Mobile Security?
• Key New Security Features in Android Oreo

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/mobile/new-android-malware-family-highlights-evolving-mobile-threat-capabilities/d/d-id/1331159?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Hybrid cloud environments are particularly vulnerable to zero-day exploits, according to a new study.

Securing cloud-based and legacy systems is a balancing act, and businesses have a tough time staying upright. As the race to the cloud picks up speed, many are struggling to fully protect their hybrid environments from zero-day attacks.

Researchers at Enterprise Strategy Group (ESG) polled 450 IT and security pros in North America and Western Europe on hybrid cloud environments and containers. The results demonstrate concern around zero-day attacks and increased container adoption.

“The thesis for the study was the multidimensionality of hybrid clouds is shifting cybersecurity priorities,” explains Doug Cahill, senior analyst covering cybersecurity for ESG and leader of this research, which was commissioned by Capsule8.

Hybrid infrastructures have become the major architecture in enterprise environments, a shift that has come with “major headaches and concerns,” says Bogdan “Bob” Botezatu, senior e-threat analyst at Bitdefender.

“The move to hybrid happened because increasingly more organizations want to enjoy the benefit of public cloud – scalability, pay-as-you-go rates and flexibility – but also maintain control over the key infrastructure,” he explains. The hybrid approach is a necessary step toward public cloud adoption, especially for companies hesitant about cloud security.

Complexity in the Cloud

“Hybrid clouds are comprised of disparate environments,” Cahill says, adding that more than 80% of organizations using infrastructure-as-a-service (IaaS) consume services from multiple providers. “This tells us more workloads are moving to public cloud platforms,” he adds.

More than half (56%) of respondents have already deployed containerized production applications; 80% report they will have containers in production within the next 12- to 24 months.

The adoption of new technology is a gradual, phased process and many companies are in the middle of migrating old applications to the cloud. Three-quarters (73%) or organizations use, or will use, containers for both new applications and preexisting legacy applications, Cahill says.

Despite their growing reliance on containers, many businesses will continue to at least partially rely on legacy systems for years to come, he continues. Security becomes a challenge when multiple users are accessing multiple environments from multiple different locations.

The biggest hybrid cloud security challenge is maintaining strong, consistent security across the enterprise data center and multiple cloud environments, says Cahill. Businesses want consistency; they want to be able to centralize policy and security controls across both.

Security teams also struggle to maintain the pace of cloud, an increasingly difficult challenge as cloud continues to accelerate. It used to be that cloud adoption was slowed by security, Cahill points out. Now, containers are driven by the app development team. Security has to keep up.

“One of the things we know about cloud computing in general, and about DevOps, is it’s all about moving fast,” he points out. “They need to keep pace with the rapid rate of change.”

Compliance is a major concern for companies using hybrid cloud, adds Botezatu, who says Bitdefender polled CISOs about their biggest fears related to hybrid cloud in late 2016.

“Lack of visibility into what is happening in the big hybrid datacenter, the increased attack surface, security of backups and snapshots and security of data (either at rest or in transit) were the top five answers,” he says.

More Complexity = Larger Attack Surface

The complexity of hybrid cloud environments puts organizations at risk for several types of attack. Forty-two percent of businesses reported an attack on their cloud environment in the past year; 28% said a zero-day exploit had been the attack origin.

“Part of [the reason] is the elastic nature of these environments,” says Cahill of the critical zero-day threat. “Servers are so rapidly deployed and sometimes they’re put into production without going through assessments and vulnerability scanning.”

Common threats include taking advantage of known flaws in unpatched applications (27%), misuse of privileged accounts by inside employees (26%), exploits taking advantage of known flaws in unpatched operating systems (21%), misuse of privileged account via stolen credentials (19%), and misconfigured cloud services, workloads, or network security controls (20%).

“The security in many hybrid cloud environments is focused on the perimeter, while totally missing in-depth defenses,” says Ofri Ziv, vice president of research and head of GuardiCore Labs. “This leads to environments with weak network segmentation, which is heaven for attackers and worms.”

John Viega, cofounder and CEO of Capsule8, says zero-days will always be a real and unpredictable threat. “This is particularly true in production due to the impact of open source,” he adds. A zero-day that appears in production from open-source software will affect a huge number of companies.

Move to Unify Security

Part of the reason security is difficult with hybrid cloud is because the majority (70%) of companies currently use separate controls for public cloud-based resources and on-premise virtual machines and servers. Only 30% use unified controls, Cahill explains.

“It’s very siloed today,” he says. “There are different tools for different environments managed by different people … but that’s not sustainable over time. It doesn’t afford the consistency of security policies across disparate environments.”

This is poised to dramatically change within the next two years. By that time, 70% of respondents claim they will focus on unified controls for all server workload types across public cloud(s) and on-premise resources.

“One of the most important things a company can do is be disciplined about keeping applications on-premise or in a data center and not moving it until it is absolutely mature enough to be seamlessly be deployed in either environment,” adds Viega. One way to control this is to focus on containerization in the software development process.

Related Content:

• Hacking on TV: 8 Binge-Worthy and Cringe-Worthy Examples
• Nearly Half of Cybersecurity Pros Solicited Weekly by Recruiters
• Memcached Servers Being Exploited in Huge DDoS Attacks
• SAML Flaw Lets Hackers Assume Users’ Identities

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Kelly Sheridan is Associate Editor at Dark Reading. She started her career in business tech journalism at Insurance Technology and most recently reported for InformationWeek, where she covered Microsoft and business IT. Sheridan earned her BA at Villanova University. View Full Bio

Article source: https://www.darkreading.com/cloud/zero-day-attacks-major-concern-in-hybrid-cloud/d/d-id/1331160?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Data from real-world pen tests shows configuration errors and cross-site scripting are the most commonly found vulnerabilities.

Misconfiguration ranks as the most common type of vulnerability discovered in real-world penetration tests, according to a new, as-yet-unpublished study.

In client engagements last year, pen-testing-as-a-service provider Cobalt found mostly misconfiguration, followed by cross-site scripting (XSS), authentication and session, exposure of sensitive data, and access control-type vulnerabilities in applications.

Finding flaws is one thing, but fixing them is another. Redirect and forward-type flaws sit unresolved the longest of any category, 41 days, while server-side request forgery, sensitive data exposure, SQL injection, and others, including business logic, get fixed most rapidly.

Caroline Wong, vice president of security strategy for Cobalt and co-author of the Pen Test Metrics Study, says misconfiguration flaws are a sign of the times. “What that tells me is that so much of security vulnerability comes not necessarily from the code we were writing, and actually may have to do with other software and infrastructure components our software depends on in order to run,” she says.

“That says … organizations are making huge use of cloud services and relying on others to do their settings for them. Maybe it’s something they consider to be someone else’s problem, and maybe in the past they didn’t depend on third parties so they didn’t consider [those] security settings.”

Application penetration testing, unlike vulnerability assessment, is not exactly standard practice for most organizations today. Pen testing traditionally was associated with network security, but with the emergence of secure software development lifecycle (SDL) programs, more organizations are starting to opt for a white-hat hack of their apps. “I see a lot of organizations do one application pen test a year because of PCI, or HIPAA, or a customer asking them for one,” Wong says. But more organizations are starting to opt for app pen tests to “do the right thing” in their secure development practices now, she says.

The most common software security program typically includes developer training and a penetration test to get a pulse on the state of their applications’ security. Wong says organizations launching appsec for the first time go with a pen test to get them started.

“What’s the biggest bang for their buck to start their program? ‘Show me and my organization if we have real security issues, and use that information to get to the next level to justify further investment,'” she explains. “I find that pen testing is a very common first step when they first start thinking about appsec.”

While a vulnerability assessment scans for and identifies flaws, a penetration test goes deeper, manually exploiting vulnerabilities to see how an attacker could abuse them, for example.

Most organizations typically focus on vulnerability scanning. “But by and large there are pockets who do true pen testing. I think there’s a larger segment that does quasi-pen testing and not full, in-depth testing,” says Kevin Greene, a software assurance evangelist. “I’m not sure all folks understand” app pen testing, he notes.

Ideally, in addition to an SDL check, organizations should run regular vulnerability assessments and pen tests to get “wider coverage” of the attack surface, he says.

Cobalt’s study also includes new data from a survey of security, management, operations, developers, and DevOps specialists. Turns out most aren’t pen testing all of their apps: just 24% say they pen test 67% to 100% of their apps, while 35% test one to 33% of their apps, and 31% say they test anywhere from 34% to 66% of their apps.

While the best practice is to pen test critical apps once every quarter, most (32%) of the respondents in the survey say they only do so annually; 16%, semiannually; 12%, quarterly; 12%, not at all yet; and 7%, more than five times a year.

More than 30% say they pen test their apps when they add a new feature or patch. Some 26% pen test their apps on an ad hoc basis, 25% at the time of a new release, and 22% when a customer requests it.

Some 46% say they would pen test more apps, but it’s too expensive. That’s a common deterrent, as well the expertise required for pen testing. “It requires a really skilled individual” with the expertise to know what to probe and attack, according to Greene.

And once the results come in from a pen test, they require action. “I have met organizations for whom the reason they don’t do more pen tests is because they are still trying to figure out how to fix the results from their first pen test,” Wong says.

“The biggest challenge of pen testing apps is finding the right people,” which can be costly, she notes.

Related Content:

• 7 Ways to Maximize Your Security Dollars
• Zero-Day Attacks Major Concern in Hybrid Cloud
• Why Cryptocurrencies Are Dangerous for Enterprises

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/the-state-of-application-penetration-testing/d/d-id/1331161?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Earlier this week, we wrote about a big-news item out of the US that claimed “the Feds can now (probably) unlock every iPhone model in existence”.

Indeed, the company that inspired the journalist who made that dramatic claim – to be fair, the company itself didn’t make it – also mentions being able to into a wide range of Android vendors’ devices, too, from Alcatel, through Google itself, to ZTE.

If the claim is true, is that an excuse for us to go back to the bad old days of simply not bothering with mobile security?

We went on Facebook Live to talk through the issues involved…

(Can’t see the video directly above this line, or getting an error such as “no longer available”? Watch on Facebook instead.)

Note. With most browsers, you don’t need a Facebook account to watch the video, and if you do have an account you don’t need to be logged in. If you can’t hear the sound, try clicking on the speaker icon in the bottom right corner of the video player to unmute.

Follow @NakedSecurity
Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/xiOjEo-aX-g/

Logon security company Duo recently found a rather worrying flaw in its own authentication gateway.

A bit of digging revealed that the flaw was reflected in many other so-called single-sign on (SSO) applications, thanks to a problem in handling the underlying “authentication language” that has become a standard for products in this space.

Duo disclosed the problem responsibly late last year, and after giving vendors – including itself – time to fix the bug, has now gone public with an excellent and educational explanation of what went wrong.

In the vocabulary of SSO, network authentication uses dedicated authentication servers, known as IdPs (Identity Providers), to validate requests from client software (users) for access to servers on the network, known as SPs (service providers).

This means that you don’t need to program an authentication module, or maintain a separate password database, or run yet another two-factor authentication service, for every server.

In the jargon, you use an SSO IdP server to handle usernames and passwords for all the other SPs on the network.

Of course, if you want various clients and SPs from different vendors to work cleanly together with an IdP from yet another vendor, you need a uniform data language and vocabulary for them to communicate.

One such language is SAML, short for Security Assertion Markup Language.

SAML is a dialect of XML, which is a sort-of tidied-up form of HTML, the language used to create web pages.

Now, if you have written software or scripts that generate web pages in HTML format, you’ll know that it’s gloriously simple to do – you just stick the right tags at each end of each sentence in bold, each web link, each paragraph, each item in a bulleted list, and so on.

Easy!

But if you have ever had to write software to go the other way – to read in HTML or XML and make sense of it – then you will know where this article is going.

Hard!

Generating HTML and then reliably reading it back in are as far apart in difficulty as being able to utter enough badly-pronounced words in a foreign language to find your way to the train station, and being able to chat fluently with a native speaker.

What the bug looks like

Duo did us all a favour by producing a stripped-out representation of the parts that matter in an SAML authentication response; we’ve followed their synthetic example here.

An SAML response typically contains an XML-formatted assertion that identifies the authenticated user, something like this:

Assertion ID="ABC1245"
    [email protected]/NameID/Subject
/Assertion

There should also be a digital signature for the assertion (here identified by the string ABC1245), without which an imposter could simply copy a SAML response, and casually alter the NameID to refer to a different account:

Signature
   SignedInfoReference URI="#ABC1245"//SignedInfo
   SignatureValuedigital sig of assertion ABC1245/SignatureValue
/Signature

The problem that Duo found was how various programming libraries – including python-saml, used by Duo, ruby-saml and saml2-js – dealt with XML comments inside SAML data structures, and how these comments affected the digital signature process.

Above, the correct data string for the field NameID is obviously [email protected], being the full text immediately between the start tag NameID; and the end tag /NamedID.

But if you were to write this instead…

Assertion ID="ABC1245"
    [email protected]!-- comment --.test/NameID/Subject
/Assertion

…what’s the correct value for NameID, given that the text !-- comment -- is supposed to be ignored?

Duo found that buggy SAML libraries would read the NameID string in various ways, sometimes as [email protected] (treating the comment as a terminator for the data field), and sometimes as [email protected] (simply treating the comment as it it were not there at all).

Either interpretation has technical validity, and it doesn’t really matter which approach you choose as long as you are consistent.

Duo found that wasn’t the case: buggy SAML libraries would use the interpretation [email protected] when validating the signature, but the second interpretation when matching the username.

In other words, by injecting a comment followed by some extra text into the NameID field of a signed SAML response, a crook could alter the username in the authentication message without invalidating its digital signature.

As a result, the altered response would pass muster, thus potentially tricking servers on the network into trusting an unauthorised user.

What to do?

• If you use an SSO system in your business: check with your vendor if it is SAML-based. If so, ask if it is affected and whether there is a patch available.
• If you are a vendor with any product that speaks SAML: check with your programmers which SAML libraries you use, and whether they need patching.

Finally, at the risk of sounding impractically pompous, re-evaluate everywhere that you’ve used an XML-based approach to data when you didn’t need to.

As a wise man once said, “There is no limit to how much worse you can make a computer security problem by using XML in the process of solving it.”

Follow @NakedSecurity
Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/GJrTOLcnlWM/

Various single-sign-on systems can be hoodwinked to allow miscreants to log in as strangers without their password, all thanks to bungled programming.

Specifically, the vulnerable authentication suites mishandle information submitted in the XML-like Security Assertion Markup Language (SAML). These weaknesses can be potentially exploited by hackers to log into systems, masquerade as other users, and access their accounts.

Single-sign-on systems (SSOs), for those who don’t know, are typically used by enterprises, and large websites, to allow users and customers to log into lots of different services using one username and password pair – plus any two-factor authentication methods, of course. It means folks can sign into apps on phones, webpages on their desktop PCs, and so on, using one set of credentials.

According to the US Homeland Security-backed CERT, the Duo Network Gateway, OneLogin’s python-saml and ruby-saml, Clever’s saml2-js, the OmniAuth-SAML, and the Shibboleth openSAML C++ SSO toolkits are vulnerable to authentication bypass attacks. Vendors of similar technology are potentially affected, too.

The security shortcomings were first discovered by Duo in its own product, and follow up work revealed that other makers of SSO software were also affected. This is therefore a new class of bug, lying within the processing of SAML data.

Duo worked closely with US-CERT and the aforementioned developers since December to patch the bugs, and went public with its findings on Tuesday now that all the fixes are, we’re told, available.

Cryptographic

According to CERT: “A remote attacker can modify SAML content for a SAML service provider without invalidating the cryptographic signature, which may allow attackers to bypass primary authentication for the affected SAML service provider.”

That sounds as though any unauthenticated scumbag can gain control of any account. However, Duo’s Kelby Ludwig noted that to practically exploit this class of security hole, an attacker has to be logged in. Thus, the flaws allows a rogue user or customer to impersonate another person on the system, which still isn’t very nice.

“This vulnerability can allow an attacker with authenticated access to trick SAML systems into authenticating as a different user without knowledge of the victim user’s password,” explained Ludwig.

Ludwig’s advisory has the full technical details, but to briefly summarize: when signing in, the system that performs the identity check produces a SAML response, which is sent to the system providing the service. This response contains, among other things, the account ID of the user logging in, and a digital signature of the data. That signature is supposed to ensure the information is tamper-proof: a tweaked response will not match its signature, and thus will be discarded.

It is, however, possible to log into an identity system, and carefully alter the valid SAML response so that it has a stranger’s account ID instead of your own, all while keeping the signature valid. This modified access key is then presented to the service provider, and it appears to be legitimately generated by the identity checking system, due to the valid signature. Thus, you can log in as the stranger using this forged SAML response.

The trick is to exploit the fact that XML comments are skipped when generating the signature, but are not fully skipped when extracting the user account ID string. Oops.

Coordinated

Steve Manzuik, director of security research at Duo Security, told El Reg that the advisory is in “no way an attempt to criticize competitors’ products. In fact, the coordinated disclosure alongside our own customer notification is intended to do the exact opposite.”

“This vulnerability was identified during an internal review to vet possible software dependencies,” he explained. “It was after we identified that issue, that we felt other SAML libraries could be affected by the same or similar issues. That hypothesis turned out to be correct. We found a vulnerability that affects multiple SAML libraries. These libraries can be used by organizations to enable, for example, Single-Sign-On between websites in their organization.”

So: check your SSO library or provider for any security updates, and apply them when you can, ideally before miscreants start to exploit this class of bug. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/28/sso_sys_flaw/