The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Mimosa DoS / Code Execution / File Disclosure[+] 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
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum