Today I'm
blogging about another CVE, which I received during my research of
"middleware applications". This is Part 2, so if you haven't done so, please read Part 1: ActiveMQ (or how to get admin's password in plaintext).
INTRO:
Nowadays the number of applications which work via traditional request/response principle between the user and the application continuously decrease. More and more often enterprise developers add an extra layer into the usual packet flow on the backend. Examples of such applications are all well known to all of you: WAFs, asynchronous sandbox checkers, error handlers, JMS brokers. "Middleware" applications typically receive data,
process them (normalise, sort, store, etc) and afterwards pass them to backend.
Why research it?
In cases where front- and back-end applications do not contain any visible critical vulnerabilities, there still remains an opportunity for an attacker to launch a successful attack on target systems.
Also, AMQP brokers are gaining extreme popularity.
Why research it?
In cases where front- and back-end applications do not contain any visible critical vulnerabilities, there still remains an opportunity for an attacker to launch a successful attack on target systems.
Also, AMQP brokers are gaining extreme popularity.
What is RabbitMQ?
RabbitMQ is
software, which implements AMQP protocol, and is called a message broker.
It is written with use of Erlang language.
The principal idea is pretty simple: it
accepts and forwards messages. You can think about it as a post office: when
you send mail to the post box you're pretty sure that Mr. Postman will
eventually deliver the mail to your recipient. Using this metaphor RabbitMQ is
a post box, a post office and a postman. – Tutorials from official website
Today I'd
like to describe a fairly basic, but still important issue in RabbitMQ
Management Plugin. The reason why I'm calling the DoS vulnerability critical, is because the availability of AMQP servers is the Top-1 reason why people use them in their projects.
TL;DR
CVE-2015-8786:
user-provided query parameters lengths_age and lengths_incr had no validation
and could be used to exhaust server resources. ( Comments on patched release )
How to attack it?
RabbitMQ has web-based admin panel, Management Plugin, which can be
accessed through port 15672. Apart from ActiveMQ’s API, RabbitMQ API does not
have rich syntax, and source code analysis is fairly hard to conduct due to
programming language it's written on.
In case one
wants to analyse application which was written using some unknown language, one
should understand the basics of the language itself to understand flaws which
could be left by developer. Basic examples are: Java programmers love to
deserialize, PHP programmers love to use functions vulnerable to SQL injections,
Node.js programmers love to eval user input.
What is Erlang?
The concept
behind Erlang is that it was developed to be suited for systems with the
following characteristics:
- Distributed
- Fault-tolerant
- Highly available, non-stop applications
Neither Erlang has deserialization funs, nor RabbitMQ
implements RPC, so it seemed that the
only vector to pwn server is to DoS it. So I started googling “Erlang errors“,
and spend a while reading github issues, and found quite a lot of them in the
wild: ONE, TWO, etc.
It resulted
for discovery of the following attack:
Any user,
who has legal access to API (admin/policymaker/management/monitoring) can
launch Denial of Service attack against server, simply accessing API page with
a single GET query. This attack can also be launched against unknown list of logged-in
users (e.g. by creating an <img src="http://0.0.0.0:15672/[EXPLOIT]">
on any popular website), due to absence of CSRF token. Query parameters
"lengths_age" and “lengths_incr” are not checked for input limits,
making server to allocate exhaustive memory resources and crash.
Example of
attacks:
/api/queues/%2F/?lengths_age=6000000000000000&lengths_incr=5
/api/queues/%2F/?lengths_age=60&lengths_incr=-500000000
RESULT:
PATCH: https://github.com/rabbitmq/rabbitmq-management/commit/298d86fe8cb6865bf50cf91f274b1872cb7bd7ba
No comments:
Post a Comment