Security best practice guidelines always call for changing default passwords as any password left on the factory preset is considered low hanging fruit, essentially just waiting to be abused by attackers to gain unauthorized access.
Frameworks such as Cyber Essentials, PCI DSS, and UK Gov ITHC enforce this practice as one of their test requirements during an audit. The scenario below shows why it is part of a best practice to change default passwords as it could lead to a more severe issue. 53% of data breaches occur due to default or shared credentials, according to the 2022 Verizon Data breach report.
How Default Passwords Can be Abused
Below is a typical login printer page. In most cases, the device ships with a default username and password which is publicly available. Tools such as creds can help identify credentials by simply providing the software or device name.
Figure 1: Default Credentials
Figure 2: Printer Login Page
This is an incredibly easy task and one that opens the company or individual up to an immediate attack.
Once authenticated, attackers can access the configuration page as administrator, allowing them to perform malicious tasks. Most current printers come with a feature to allow employees to scan or print to a folder, and to do this a user will need to be setup with permissions to be able to write to a folder on a print server.
Trustwave SpiderLabs has observed that oftentimes the “users” created tend to be part of a domain, sometimes even with higher privileges assigned instead of a restricted account, enabling the account to write to the folder.
In some cases, these credentials on the page itself allows them to be viewed simply by using the “inspect element” option. In other cases, the credentials are stored on the configuration file and will be encrypted. An example of one of these printers is as follows:
Figure 3: SMB Configuration on a Printer/Scanner
In this case, the printer does not have any authentication details stored on the page; however, it does have the “Scan destination” option which can be edited. All we need to do is change the “Scan destination” to the IP address of our machine and set up an SMB server with ntlmrelayx.py from Impacket, which will capture the hash and with the “socks” flag in use, it will be possible to use other tools via proxychains. Once the scan destination is set up, there would be an option to “check authentication” or “test connection” on the printer to execute the process to perform the authentication checks.
Figure 4: Hash captured from the Printer.
The screenshot above shows that it was possible to relay the captured hash to the print server. In this case, the user did not have administrative privileges on the system, however, with a domain user, it is possible to use it to scan the network to find an accessible file share with potentially sensitive information. The target range would be larger depending on the network and utilizing the “-tf” flag in ntlmrelayx, a target file with SMB signing disabled systems can be provided. During the enumeration phase, a file server was found, and the user was able to access a folder with the “web.config” file readable.
Figure 5: Relaying Hashes with Proxychains
Using the information obtained from the “web.config” file, it was then possible to connect to the MSSQL server as the credential and server details were observed. Once connected, issuing the “xp_dirtree” against the rogue SMB server and the target server in ntlmrelayx would be the MSSQL itself, allowing for the hash to be captured and relayed.
Figure 6: Browsing SMB share via MSSQL.
Once the command was issued, it was possible to obtain the hashes from the MSSQL server as shown below:
Figure 7: Hashes captured from the MSSQL Server
It was observed that the MSSQL server is running as the “SVC_TESTMSSQL” service account. In some cases, SVC accounts will have administrative privileges on a system. As shown above, the AdminStatus is “TRUE” which means we can dump hashes or obtain a shell on the system like the following:
Figure 8: Administrative Access on Server
Conclusion
Default passwords on applications/devices can lead to more severe issues when combined with known misconfiguration issues on such as SMB signing disabled. While most modern devices and applications allow for users to set passwords on first installation, it is important that the password policy set out by organizations are adhering to best practices. As for legacy devices and applications, it is best to review the default accounts on these systems and set a complex password as per security best practice guidelines.
