2021-05-20, 16:00–16:30, Main stream
dRuby is a "distributed object system" built into Ruby that is generally known
to be insecure, but which has never been properly audited... until now. In this
talk, we will discuss how dRuby works, where its insecurities lie, and how it
is much more insecure than previously understood to be — which is a feat,
considering that dRuby already provides code execution as a service.
This talk will focus on a discussion of the dRuby API, its
internals, and its underlying wire protocol, covering the security issues
inherent in each along the way. As part of the this, we will also demonstrate
several novel exploitation techniques that can be used against both dRuby
servers and clients, the latter of which have not been known to be vulnerable
until now. Following this, we will discuss some of our work to harden dRuby
against each of the issues we identified. We will then close our talk by
covering our work to exploit the exploits used to compromise dRuby-based
services for some very ironic honeypotting.
dRuby is a "distributed object system" for Ruby (think CORBA or Java's RMI).
Included in the Ruby standard library and implemented in vanilla Ruby without
native extensions, it provides a simple-to-use interface to interact with Ruby
objects from other Ruby processes, locally or over a network. While dRuby makes
it fairly easy to expose objects and their interfaces to other processes,
including those running on separate systems, it leaves a lot to be desired in
terms of its security. While its own API documentation warns coyly of its
insecurity with a simple-to-understand example exploit written in Ruby, the
actual implementation and protocol of dRuby are not documented at all, nor are
the actual risks dRuby exposes. While dRuby is well known to be a readily
exploitable service enabling remote code execution, the underlying protocol
exposes a number of additional risks that enable not only alternate methods of
compromising dRuby services, but also the means to compromise dRuby clients.
In this talk, we will open with the background of how we found dRuby being used
by a popular remote debugging dependency. We will then shift to an overview and
technical discussion of dRuby and its protocol as defined by its
implementation, starting with some basic examples of how to use dRuby.
Following this, we will walk through an analysis of the network protocol guided
by the traffic generated from our examples, and discuss how the
data is processed, including a high-level discussion of the dual client-server
peer-to-peer model used in dRuby. As part of this, we will also discuss the
implementation of dRuby's remote method call scheme, data serialization, and
proxy objects, including the default object reference scheme and ID mapper.
Throughout our discussion of dRuby's API, internals, and wire protocol, we will
bring attention to and discuss relevant risks and vulnerabilities — and how
they make dRuby fundamentally unsafe — and demonstrate several novel
proof-of-concept exploits targeting dRuby services and clients. We will also
discuss some of the existing advice and documentation for "securing" dRuby and
how it fails to guard against dRuby's inherent issues.
Following this, we will briefly discuss our efforts to harden dRuby;
the kinds of protocol, logic, and API changes needed to negate its issues;
and additional considerations that should be taken into account not to expose
further security issues.
Lastly, we will swing back to offense — or rather at offense — and close our talk
with a discussion on the insecurity of existing dRuby exploits, and show how you
can penalize your pentesters for using off-the-shelf exploits. As part of this,
we will demonstrate an emulated implementation of the dRuby wire protocol that
can be used to securely exploit dRuby services, clients, and exploits.
Addison Amiri got his start in security in the mid-2000’s when he read about how easy it was to break WEP. From there, he’s meandered the world of security, through academia and industry, eventually entering the world of professional security consulting. Along the way, he’s had the opportunity to be simultaneously amazed at how well computers work and terrified that our lives now rely on them. These days he’s traveling the world and making the most of the cyberpunk dystopia.
Jeff is a security consultant by day, and sometimes by night. A Technical
Director at NCC Group, he specializes in application security, and regularly
assesses mobile device firmware applications, embedded platforms, web
applications, and "privileged" code of all kinds. He has spoken publicly at
conferences such as DEF CON, ToorCon, RECON, and CCC, covering a wide range of
topics including Android and Java bytecode instrumentation, scriptable
debugging, and, more recently, eBPF and unikernel security. A connoisseur of
exotic candies and snacks, he enjoys starting arguments about text editors and
window managers that he doesn't actually use. Jeff holds an MS in Computer
Science from NYU Poly (Tandon).