Message-ID: <f6ed9a591385b42daefd6c28e0c74b09@iancaling.com>
Date: Fri, 12 May 2017 14:41:54 -0700
From: Ian Ling via Fulldisclosure <fulldisclosure@...lists.org>
To: Fulldisclosure <fulldisclosure@...lists.org>
Subject: [FD] Mimosa Wireless Radios - RCE, DoS,
 and Local File Disclosure Vulnerabilities

[+] 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 AP’s (<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 device’s 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 vendor’s 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 client’s MQTT 
broker. This command can be re-sent endlessly to act as a DoS attack on 
the client.

--Unauthenticated local file disclosure: In the device’s 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 device’s 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 device’s web interface. This vulnerability can 
also be used to view the plaintext pre-shared key (PSK) for encrypted 
connections, or to view the device’s serial number (which leads to DoS).

--Authenticated remote command execution #1: In the device’s 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 
device’s 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 – Vendor notified of some of the above vulnerabilities
2017/04/05 – Vendor acknowledgement
2017/04/07 – Vendor notified of web interface RCE #1
2017/04/07 – Vendor acknowledges web interface RCE #1
2017/04/11 – Vendor releases patch for all vulnerabilities that were 
known at the time
2017/04/11 – Web interface RCE vulnerability #2 discovered and reported 
to vendor
2017/04/12 – Vendor acknowledges vulnerability
2017/05/12 – Public disclosure

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists