Connect with us


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



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 *


Managing Vulnerabilities in a Cloud Native World



This free 1-hour webinar from GigaOm Research brings together experts in Cloud Native Vulnerability Management, featuring analyst Iben Rodriguez and special guest from Palo Alto Networks, John Morello. The discussion will focus on optimizing cloud security posture and integration with enterprise tool sets.

We will review platforms delivering Security Posture Management and Workload Protection for Microservice based and Hybrid Cloud Workloads.

Registrants will learn how new customers can benefit from Prisma Cloud to better secure their complex multi-cloud environments. Existing customers will learn about new features they can take advantage of and how to optimize their limited resources.

Register now to join GigaOm and Palo Alto Networks for this free expert webinar.

The post Managing Vulnerabilities in a Cloud Native World appeared first on Gigaom.

Continue Reading


Security Tools Help Bring Dev and Security Teams Together



Software development teams are increasingly focused on identifying and mitigating any issues as quickly and completely as possible. This relates not only to software quality but also software security. Different organizations are at different levels when it comes to having their development teams and security teams working in concert, but the simple fact remains that there are far more developers out there than security engineers.

Those factors are leading organizations to consider security tooling and automation to proactively discover and resolve any software security issues throughout the development process. In the recent report, “GigaOm Radar for Developer Security Tools,” Shea Stewart examines a roundup of security tools aimed at software development teams.

Stewart identified three critical criteria to bear in mind when evaluating developer security tools. These include:

  • Vendors providing tools to improve application security can and should also enhance an organization’s overall security posture.
  • The prevailing “shift-left” mindset doesn’t necessarily mean the responsibility for reducing risk should shift to development, but instead focusing on security earlier in the process and continuing to do so throughout the development process will reduce risk and the need for extensive rework.
  • Security throughout the entire software development lifecycle (SDLC) is critical for any organization focused on reducing risk.

Figure 1. How Cybersecurity Applies Across Each Stage of the Software Development Lifecycle *Note: This report focuses only on the Developer Security Tooling area

Individual vendors have made varying levels of progress and innovation toward enhancing developer security. Following several acquisitions, Red Hat, Palo Alto Networks, and Rapid7 have all added tooling for developer security to their platforms. Stewart sees a couple of the smaller vendors like JFrog and Sonatype as continuing to innovate to remain ahead of the market.

Vendors delving into this category and moving deeper into “DevSecOps” all seem to be taking different approaches to their enhanced security tooling. While they are involving security in every aspect of the development process, some tend to be moving more quickly to match the pace of the SDLC. Others are trying to shore up existing platforms by adding functionality through acquisition. Both infrastructure and software developers are now sharing toolsets and processes, so these development security tools must account for the requirements of both groups.

While none of the 12 vendors evaluated in this report can provide comprehensive security throughout the entire SDLC, they all have their particular strengths and areas of focus. It is therefore incumbent upon the organization to fully and accurately assess its SDLC, involve the development and security teams, and match the unique requirements with the functionality provided by these tools. Even if it involves using more than one at different points throughout the process, focus on striking a balance between stringent security and simplifying the development process.

Read more: Key Criteria for Evaluating Developer Security Tools, and the Gigaom Radar for Developer Security Tool Companies.

The post Security Tools Help Bring Dev and Security Teams Together appeared first on Gigaom.

Continue Reading


Key Criteria for Evaluating User and Entity Behavior Analytics (UEBA)



Cybersecurity is a multidisciplinary practice that not only grows in complexity annually but evolves nearly as quickly. A survey of the security landscape today would reveal concerns ranging from the classic compromised servers to the relatively new DevSecOps practices aimed at securing the rapid deployment of new code and infrastructure. However, some things remain constant no matter how much change is introduced. While technology evolves and complexity varies, there is almost always a human component in
risks presented to an organization.

User Behavior Analysis (UBA) was designed to analyze the actions of users in an organization and attempt to identify normal and abnormal behaviors. From this analysis, malicious or risky behaviors can be detected. UBA solutions identify events that are not detectable using other methods because, unlike classic security tools (an IDS or SIEM for example), UBA does not simply pattern match or apply rule sets to data to identify security events. Instead, it looks for any and all deviations from baseline user activity.

As technology advanced and evolved, and the scope of what is connected to the network grew, the need to analyze entities other than users emerged. In response, entity analysis has been added to UBA to create UEBA or User and Entity Behavior Analysis. The strategy remains the same, but the scope of analysis has expanded to include entities involving things like daemons, processes, infrastructure, and so on.

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 Key Criteria for Evaluating User and Entity Behavior Analytics (UEBA) appeared first on Gigaom.

Continue Reading