78%
18%
98%
A Use of Hard-coded Credentials vulnerability in Juniper Networks Junos OS on Junos Fusion satellite devices allows an attacker who is local to the device to elevate their privileges and take control of the device. This issue affects: Juniper Networks Junos OS Junos Fusion Satellite Devices. 16.1 versions prior to 16.1R7-S7; 17.1 versions prior to 17.1R2-S12, 17.1R3-S2; 17.2 versions prior to 17.2R3-S4; 17.3 versions prior to 17.3R3-S8; 17.4 versions prior to 17.4R2-S10; 17.4 version 17.4R3 and later versions; 18.1 versions prior to 18.1R3-S10; 18.2 versions prior to 18.2R2-S7, 18.2R3-S3; 18.3 versions prior to 18.3R1-S7, 18.3R2-S4, 18.3R3-S2; 18.4 versions prior to 18.4R1-S6, 18.4R2-S4, 18.4R3-S1; 19.1 versions prior to 19.1R1-S5, 19.1R2-S1, 19.1R3; 19.2 versions prior to 19.2R1-S4, 19.2R2; 19.3 versions prior to 19.3R2-S5, 19.3R3; 19.4 versions prior to 19.4R1-S1, 19.4R2; 20.1 versions prior to 20.1R1-S1, 20.1R2. This issue does not affected Junos OS releases prior to 16.1R1 or all 19.2R3 and 19.4R3 release versions.
CVSS 3.1 Base Score 7.8. CVSS Attack Vector: local. CVSS Attack Complexity: low. CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
CVSS 2.0 Base Score 7.2. CVSS Attack Vector: local. CVSS Attack Complexity: low. CVSS Vector: (AV:L/AC:L/Au:N/C:C/I:C/A:C).
The following code uses a hard-coded password to connect to a database:
...This is an example of an external hard-coded password on the client-side of a connection. This code will run successfully, but anyone who has access to it will have access to the password. Once the program has shipped, there is no going back from the database user "scott" with a password of "tiger" unless the program is patched. A devious employee with access to this information can use it to break into the system. Even worse, if attackers have access to the bytecode for application, they can use the javap -c command to access the disassembled code, which will contain the values of the passwords used. The result of this operation might look something like the following for the example above:
26: ldc #17; //String tigerThe following code is an example of an internal hard-coded password in the back-end:
}
return(1);
return(0)
}return(1);return(0)Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality."
The following code examples attempt to verify a password using a hard-coded cryptographic key.
}
return(1);
return(0);
return false;return true;
}return(0);return(1);The cryptographic key is within a hard-coded string value that is compared to the password. It is likely that an attacker will be able to read the key and compromise the system.
The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in plaintext.
This Java example shows a properties file with a plaintext username / password pair.
...# Java Web App ResourceBundle properties fileThe following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in plaintext.
...<add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" />Username and password information should not be included in a configuration file or a properties file in plaintext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information and avoid CWE-260 and CWE-13.
ExploitPedia is constantly evolving. Sign up to receive a notification when we release additional functionality.
If you'd like to report a bug or have any suggestions for improvements then please do get in touch with us using this form. We will get back to you as soon as we can.