P300 vulnerabilities

[eugene_herrera]

Hi, 

I have a client with some P300 devices, they work correctly, but the problem is that they are presenting some vulnerabilities in each one of them. For example:

Description

The remote host supports the use of RC4 in one or more cipher suites. The RC4 cipher is flawed in its generation of a pseudo-random stream of bytes so that a wide variety of small biases are introduced into the stream, decreasing its randomness. If plaintext is repeatedly encrypted (e.g., HTTP cookies), and an attacker is able to obtain many (i.e., tens of millions) ciphertexts, the attacker may be able to derive the plaintext.

The remote host supports the use of SSL ciphers that offer medium strength encryption. Nessus regards medium strength as any encryption that uses key lengths at least 64 bits and less than 112 bits, or else that uses the 3DES encryption suite. Note that it is considerably easier to circumvent medium strength encryption if the attacker is on the same physical network.

According to its self-reported version in its banner, Dropbear SSH running on the remote host is prior to 2016.74. It is, therefore, affected by the following vulnerabilities :   - A format string flaw exists due to improper handling of     string format specifiers (e.g., %s and %x) in usernames     and host arguments. An unauthenticated, remote attacker     can exploit this to execute arbitrary code with root     privileges. (CVE-2016-7406)   - A flaw exists in dropbearconvert due to improper     handling of specially crafted OpenSSH key files. An     unauthenticated, remote attacker can exploit this to     execute arbitrary code. (CVE-2016-7407)   - A flaw exists in dbclient when handling the -m or -c     arguments in scripts. An unauthenticated, remote attacker     can exploit this, via a specially crafted script, to     execute arbitrary code. (CVE-2016-7408)   - A flaw exists in dbclient or dropbear server if they are     compiled with the DEBUG_TRACE option and then run using     the -v switch. A local attacker can exploit this to     disclose process memory. (CVE-2016-7409)

The remote host supports the use of SSL ciphers that offer medium strength encryption. Nessus regards medium strength as any encryption that uses key lengths at least 64 bits and less than 112 bits, or else that uses the 3DES encryption suite. Note that it is considerably easier to circumvent medium strength encryption if the attacker is on the same physical network.

The remote SSH server is configured to allow key exchange algorithms which are considered weak. This is based on the IETF draft document Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-20. Section 4 lists guidance on key exchange algorithms that SHOULD NOT and MUST NOT be enabled. This includes:   diffie-hellman-group-exchange-sha1   diffie-hellman-group1-sha1   gss-gex-sha1-*   gss-group1-sha1-*   gss-group14-sha1-*   rsa1024-sha1 Note that this plugin only checks for the options of the SSH server, and it does not check for vulnerable software versions.

[Squozen]

It’s end-of-life, so you follow the same steps you do for any end-of-life product with a security vulnerability. 
If possible, patch it. 
If no patches are available, replace it. 
If replacement is not possible, minimise the attack surface by disabling services or firewalling them. 

[eugene_herrera]

Thank you for the information.

Initially I had the devices with the release, 100.1.0.9.52 and I updated to the software 100.1.0.9.108, after this update it does not allow me to disable the following parameters: HTTP, TELNET as well as SNMP.

[Squozen]

Then it looks like you’ll need step 2 or 3 of my post. 👍🏼

Can you SSH into it and disable telnet/http that way?

If you're using Chrome for the web interface, try Firefox.

[aadityakhanna]

which Post