Various Mimosa products suffer from denial of service, information leakage, code execution, and file disclosure vulnerabilities.
8fefeb6dcd43f7f2bc9969105e2384a2[+] Credits: Ian Ling
[+] Website: iancaling.com
[+] Source: http://blog.iancaling.com/post/160596244178
Vendor:
=================
http://mimosa.co
Products:
======================
Access Points (e.g. A5) <2.2.3
Client Radios (e.g. C5) <=2.2.3
Backhaul Radios (e.g. B5) <=2.2.3
Vulnerability Types:
===================
Remote Command Execution (RCE), Denial of Service (DoS), Local File
Disclosure, and Information Leakage
Vulnerability Details:
=====================
Mimosa Client (e.g. C5) and Backhaul (e.g. B5) models (<2.2.4) are
vulnerable to multiple vulnerabilities, including local file disclosure,
remote command execution (RCE), information leakage, and
denial-of-service (DoS) vulnerabilities.
All vulnerabilities below affect versions <2.2.3, except for the last
one (authenticated RCE #2), which also affects version =2.2.3.
Mimosa APas (<2.2.3) are also vulnerable to the MQTT information leakage
vulnerability explained below.
--Information leakage in the web interface (leads to DoS): There is a
page in the web interface that will show you the deviceas serial number,
regardless of whether or not you have logged in. There is another page
(also accessible without authenticating) that allows you to remotely
factory reset the device simply by entering the serial number.
--Information leakage in the MQTT broker (leads to DoS): These devices
run Mosquitto, a lightweight message broker, to send information between
devices. By using the vendoras hard-coded credentials to connect to the
broker on any device (whether it be an AP, Client, or Backhaul model),
an attacker can view all the messages being sent between the devices. If
an attacker connects to an AP, the AP will leak information about any
clients connected to it, including the serial numbers, which can be used
to remotely factory reset the clients.
--Unauthenticated remote command execution (RCE) in the MQTT broker
(leads to DoS): By connecting to the MQTT broker on the wireless AP and
a wireless client, an attacker can gather enough information to craft a
command that reboots the client remotely when sent to the clientas MQTT
broker. This command can be re-sent endlessly to act as a DoS attack on
the client.
--Unauthenticated local file disclosure: In the deviceas web interface,
there is a page that allows an attacker to use an unsanitized GET
parameter to download files from the device as the root user. The
attacker can download any file from the deviceas filesystem, including
block device images. This can be used to view unsalted, MD5-hashed
administrator passwords, which can then be cracked, giving the attacker
full admin access to the deviceas web interface. This vulnerability can
also be used to view the plaintext pre-shared key (PSK) for encrypted
connections, or to view the deviceas serial number (which leads to DoS).
--Authenticated remote command execution #1: In the deviceas web
interface, after logging in, there is a page that allows you to ping
other hosts from the device and view the results. The user is allowed to
specify which host to ping, but this variable is not sanitized
server-side, which allows an attacker to pass a specially crafted string
to execute shell commands as the root user.
--Authenticated remote command execution #2: On the backend of the
deviceas web interface, there are more tests the user can run than just
the ping test mentioned above. These other tests are not all shown on
the webpage; some are only accessible by crafting a POST request with a
program like cURL. There is one test accessible via cURL that does not
properly sanitize user input, allowing an attacker to execute shell
commands as the root user.
Disclosure Timeline:
===================================
2017/04/05 a Vendor notified of some of the above vulnerabilities
2017/04/05 a Vendor acknowledgement
2017/04/07 a Vendor notified of web interface RCE #1
2017/04/07 a Vendor acknowledges web interface RCE #1
2017/04/11 a Vendor releases patch for all vulnerabilities that were
known at the time
2017/04/11 a Web interface RCE vulnerability #2 discovered and reported
to vendor
2017/04/12 a Vendor acknowledges vulnerability
2017/05/12 a Public disclosure