Connect with us

Security

Deserialization issues also affect Ruby, not just Java, PHP, and .NET

Published

on

The Ruby programming language is impacted by a similar “deserialization issue” that has affected and wreaked havoc in the Java ecosystem in 2016; an issue that later also proved to be a problem for .NET and PHP applications as well.

The issue at the heart of this problem is how Ruby handles the process of serialization –and its counterpart, deserialization.

Serialization is the process of converting a data object into a binary format so it can be sent over a network, stored inside a database, or saved on disk. As you might imagine, deserialization is the opposite process, of reversing a binary blob back into its data object structure that can then be fed back into the programming language for further processing at a later date.

Almost all programming languages support serialization and deserialization operations. Some might use different names for these processes, but the concept is found in almost all. For example, in some Ruby documentation files, some developers refer to serialization and deserialization operations under the terms of marshaling and unmarshalling data.

Serializing and deserializing data is a common operation in many web or desktop applications, mainly because it’s an incredibly easy and fast way of moving data between apps or different programming mediums.

But security researchers have sounded the alarm about the improper usage of these two operations. It’s now been known for years that this process could be targeted to trick applications into running malicious commands, especially when user-supplied data is fed directly into a serializer without being sanitized first, and then deserialized into a chain of automated operations with no security safeguards.

The Java Apocalypse

This became painfully obvious in 2015 when two security researchers –Chris Frohoff and Gabriel Lawrence– discovered a dangerous flaw in the way data was deserialized via the Apache Commons Collection, a very popular Java library.

Researchers from Foxglove Security expanded on Frohoff and Lawrence’s original work, showing how an attacker could exploit the Apache Commons Collection library flaw to take over WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS Java servers.

The proof-of-concept code released from these experiments was later used to confirm that over 70 other Java applications were also vulnerable to deserialization flaws. A ShiftLeft report also revealed numerous serialization/deserialization issues across many SaaS vendor SDKs.

These discoveries and the revelation that deserialization attacks could work in practice and weren’t just a theoretical attack rocked the Java ecosystem in 2016, and the issue became known as the Java Apocalypse.

Organizations such as Apache, Cisco, Red Hat, Cisco, VMWare, IBM, Intel, Adobe, HP, Jenkins, and SolarWinds, all issued security advisories and patches to fix affected products.

For the sake of security, Google allowed over 50 of its Java engineers to participate in a project named Operation Rosehub, where Google staffers submitted patches to Java libraries to prevent deserialization attacks.

Over 2,600 were patched in Operation Rosehub, but the message was heard loud and clear at Oracle’s offices, and the company announced this spring plans to drop serialization/deserialization support from the main body of the Java language.

.NET and PHP also affected

However, the issue didn’t stop with Java. In 2017, HPE security researchers also discovered that many .NET libraries for supporting serialization and deserialization operations were also vulnerable to similar attacks, which allowed hackers to take over apps and servers.

PHP followed suit a few months after that, and earlier this summer, a PHP deserialization issue was also found in WordPress, a content management system that’s being used to run more than 30 percent of the Internet’s sites.

And now, Ruby, too.

But, this week, security researchers from elttam, an Australian IT security firm, have also discovered that Ruby-based apps are also vulnerable to serialization/deserialization attacks.

Researchers published proof-of-concept code showing how to exploit serialization/deserialization operations supported by the built-in features of the Ruby programming language itself.

“Versions 2.0 to 2.5 are affected,” elttam researchers said.

“There is a lot of opportunity for future work including having the technique cover Ruby versions 1.8 and 1.9 as well as covering instances where the Ruby process is invoked with the command line argument –disable-all,” the elttam team added. “Alternate Ruby implementations such as JRuby and Rubinius could also be investigated.”

While the Java and .NET deserialization issues were limited to third-party libraries, having deserialization issues impact Ruby itself greatly increases a hacker’s attack surface.

With this week’s revelations, there is now proof-of-concept code available online for assembling serialization/deserialization attacks against four of the most popular programming ecosystems around —Java, .NET, PHP, and Ruby.

As the HPE researchers pointed out in their research paper about .NET’s serialization woes, the problem is not that simple to solve.

The serialization/deserialization issues –regardless of the programming language– are a combination of vulnerable code but also bad coding practices on behalf of developers, who fail to recognize that serialized data is not necessarily secure by default and should be trusted when deserialized.

Fixing this would require having sanitizing user input before serializing it and then limiting a deserialized data’s access to certain functions to prevent malicious code from having its way with a server.

Related coverage:

Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Security

GigaOm Radar for Disaster Recovery as a Service (DRaaS)

Published

on

Very few organizations see disaster recovery (DR) for their IT systems as a business differentiator, so they often prefer to outsource the process and consume it as a service (DRaaS) that’s billed monthly. There are many DRaaS providers with varying backgrounds, whose services are often shaped by that background. Products that started as customer-managed DR applications tend to have the most mature orchestration and automation, but vendors may face challenges transforming their application into a consumable service. Backup as a Service (BaaS) providers typically have great consumption models and off-site data protection, but they might be lacking in rich orchestration for failover. Other DRaaS providers come from IaaS backgrounds, with well-developed, on-demand resource deployment for recovery and often a broader platform with automation capabilities.

Before you invest in a DRaaS solution, you should attempt to be clear on what you see as its value. If your motivation is simply not to operate a recovery site, you probably want a service that uses technology similar to what you’re using at the protected site. If the objective is to spend less effort on DR protection, you will be less concerned about similarity and more with simplicity. And if you want to enable regular and granular testing of application recovery with on-demand resources, advanced failover automation and sandboxing will be vital features.

Be clear as well on the scale of disaster you are protecting against. On-premises recovery will protect against shared component failure in your data center. A DRaaS location in the same city will allow a lower RPO and provide lower latency after failover, but might be affected by the same disaster as your on-premises data center. A more distant DR location would be immune to your local disaster, but what about the rest of your business? It doesn’t help to have operational IT in another city if your only factory is under six feet of water.

DR services are designed to protect enterprise application architectures that are centered on VMs with persistent data and configuration. A lift-and-shift cloud adoption strategy leads to enterprise applications in the cloud, requiring cloud-to-cloud DR that is very similar to DRaaS from on-premises. Keep in mind, however, that cloud-native applications have different DR requirements.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

The post GigaOm Radar for Disaster Recovery as a Service (DRaaS) appeared first on Gigaom.

Continue Reading

Security

GigaOm Radar for DDoS Protection

Published

on

With ransomware getting all the news coverage when it comes to internet threats, it is easy to lose sight of distributed denial of service (DDoS) attacks even as these attacks become more frequent and aggressive. In fact, the two threats have recently been combined in a DDoS ransom attack, in which a company is hit with a DDoS and then a ransom demanded in exchange for not launching a larger DDoS. Clearly, a solid mechanism for thwarting such attacks is needed, and that is exactly what a good DDoS protection product will include. This will allow users, both staff and customers, to access their applications with no indication that a DDoS attack is underway. To achieve this, the DDoS protection product needs to know about your applications and, most importantly, have the capability to absorb the massive bandwidth generated by botnet attacks.

All the DDoS protection vendors we evaluated have a cloud-service element in their products. The scale-out nature of cloud platforms is the right response to the scale-out nature of DDoS attacks using botnets, thousands of compromised computers, and/or embedded devices. A DDoS protection network that is larger, faster, and more distributed will defend better against larger DDoS attacks.

Two public cloud platforms we review have their own DDoS protection, both providing it for applications running on their public cloud and offering only cloud-based protection. We also look at two content delivery networks (CDNs) that offer only cloud-based protection but also have a large network of locations for distributed protection. Many of the other vendors offer both on-premises and cloud-based services that are integrated to provide unified protection against the various attack vectors that target the network and application layers.

Some of the vendors have been protecting applications since the early days of the commercial internet. These vendors tend to have products with strong on-premises protection and integration with a web application firewall or application delivery capabilities. These companies may not have developed their cloud-based protections as fully as the born-in-the-cloud DDoS vendors.

In the end, you need a DDoS protection platform equal to the DDoS threat that faces your business, keeping in mind that such threats are on the rise.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

Continue Reading

Security

GigaOm Radar for Security Information and Event Management (SIEM) Solutions

Published

on

The security information and event management (SIEM) solution space is mature and competitive. Most vendors have had well over a decade to refine their products, and the differentiation among basic SIEM functions is fairly small.

In response, SIEM vendors are developing advanced platforms that ingest more data, provide greater context, and deploy machine learning and automation capabilities to augment security analysts’ efforts. These solutions deliver value by giving security analysts deeper and broader visibility into complex infrastructures, increasing efficiency and decreasing the time to detection and time to respond.

Vendors offer SIEM solutions in a variety of forms, such as on-premises appliances, software installed in the customers’ on-premises or cloud environments, and cloud hosted SIEM-as-a-Service. Many vendors have developed multi-tenant SIEM solutions for large enterprises or for managed security service providers. Customers often find SIEM solutions challenging to deploy, maintain, or even operate, leading to a growing demand for managed SIEM services, whether provided by the SIEM vendor or third-party partners.

SIEM solutions continue to vie for space with other security solutions, such as endpoint detection and response (EDR), security orchestration automation and response (SOAR), and security analytics solutions. All SIEM vendors support integrations with other security solutions. Many vendors also offer tightly integrated solution stacks, allowing customers to choose the solutions they need most, whether just a SIEM, a SIEM and a SOAR, or some other combination. Other vendors are incorporating limited EDR- or SOAR-like capabilities into their SIEM solutions for customers who want the extra features but are not ready to invest in multiple solutions.

With so many options, choosing a SIEM solution is challenging. You will have to consider several key factors, starting with your existing IT infrastructure. Is an on-premises SIEM the right choice for you, or do you want a cloud-based or hybrid solution? Which systems and devices will be sending data to your SIEM, and how much data will it need to collect, correlate, analyze, and store? You should also consider the relative importance of basic capabilities and advanced features, bearing in mind that the basic capabilities may be considerably easier to deploy, maintain, and operate. Will your IT and security teams be able to deploy, maintain, and operate the solution on their own, or should you look for managed services to handle those tasks?

This GigaOm Radar report details the key SIEM solutions on the market, identifies key criteria and evaluation metrics for selecting a SIEM, and identifies vendors and products that excel. It will give you an overview of the key SIEM offering and help decision-makers evaluate existing solutions and decide where to invest.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

Continue Reading

Trending