An internal penetration test is often a simulation of a malicious insider or an attack within the LAN, from the perspective of a compromised workstation. In the past, a sure-shot way of getting network credentials was to abuse the presence of LLMNR and NBT-NS name resolution protocols in the LAN. Any internal host can respond to an unsolicited name lookup requested by any other host in the LAN. This way an attacker gets hold of the unsuspecting domain users NetNTLMv1/v2 hash and then subjects it to relay attacks or offline cracking.
This tried and tested tactic is slowly fading away. This can be attributed to organisations having fixed this after a penetration test or larger adoption of using operating systems other than windows.
In a recent engagement, I was in one such network with very few windows workstations. I observed that there was no LLMNR/NBT-NS. I performed a network sweep on ports TCP 515, 631, 9100 to look up for network printers. This revealed a printer that was recent in patch levels and used domain authentication.
I tried the defaults and a few other weak credentials. It was locked out of local authentication, but for some reason, the options panel allowed looking up for other underlying settings in the printer. Why would that be exposed? Because it can be allowed for anonymous access, so users do not lock themselves out during an initial configuration.
Figure 1: Anonymous access setting being enabled as default.
From here it was as easy as searching the printer for “password” which gives you the links to the settings page that you can force browse as it is allowed for “anonymous”.
- Identify settings such as LDAP/SMTP
- Change the server address to your internal attacker host in the LAN
- Set up a netcat on your attacker host “nc -lvvp 389”
- And hit “Submit and Test”, you will get clear text passwords on your attacker host
Figure 2: Figure describing the steps for recovering domain credentials.
Often times, printer accounts function as domain users with access to other services mapped to a regular user. Giving us the much needed limited user account or sometimes local administrative account on specific servers.
While we have seen this attack work in many organisations, I decided to contact the vendor explaining that they should re-enforce authentication any time any change is performed on the settings function that can contain domain credentials. But this was not addressed by the vendor as a fix will affect the field service as they do not know credentials for repairs. I assume this tactic is already used by the field service man, who knew this a feature now for some quick creds?
Co-ordinated disclosure timelines
- Oct 5, 2018 - Contacted Lexmark security advisory with the observation.
- Oct 5, 2018 - Lexmark security team acknowledges the receipt of vulnerability (CVE assigned – CVE-2018-17944)
- Oct 30, 2018 - first follow up
- Jan 14, 2019 - Second follow up
- Jan 28, 2019 - Lexmark includes disclosure suggesting changes to documentation to perform hardening. (CVE-2018-17944) confirmed http://support.lexmark.com/index?page=content&id=TE909&locale=EN&userlocale=EN_AU
- Feb 02, 2019 – Lexmark clarifies the following setting would help ensure settings page are only configured for authenticated users.
Navigate to “Settings” > “Security” > “Manage permissions” > "Administrative Menus" list by clicking on the "+" the item listed as "Security Menu" controls access to the LDAP settings. Remove that permission from the "Public" (unauthenticated)