---
Introduction
In early 2024, a new vulnerability was identified affecting network devices that support email notifications (such as printers, scanners, and routers). CVE-2024-5143 describes a privilege escalation issue where a local administrator can reconfigure SMTP settings without re-authenticating, potentially exposing sensitive login credentials. In this post, we’ll break down how this vulnerability works, show a practical example, and discuss the risks.
What Is CVE-2024-5143?
CVE-2024-5143 allows any user with device administrative privileges to change the outgoing mail (SMTP) server configuration on a device without having to re-enter or even know the current mail server password. By redirecting outbound emails to a server they control, an attacker can capture the SMTP username and password as the device tries to send emails through the new server.
Vendor advisory and official reference:
> NIST NVD - CVE-2024-5143
> SecurityFocus - CVE-2024-5143
Real-World Example: How Attackers Steal SMTP Credentials
Imagine a company uses a multifunction printer that can scan documents to email using an internal SMTP relay. The IT staff set up the device with a company email account (scanner@example.com) and a strong password.
Normal SMTP Config
SMTP Server: smtp.internal.example.com
Port: 587 (TLS)
Username: scanner@example.com
Password: (stored securely in device config)
The device only prompts the user to enter the password if they want to *change* the username or password, not if they just change the SMTP server address.
Attacker logs into the device admin panel.
2. Changes the SMTP Server to one they own (e.g., smtp.attacker.com), keeps the same username and password.
Original credentials are auto-filled by the device for the new server address.
4. Device tries to send email via the attacker’s server, and transmits the username and password—often in cleartext or easily retrievable form—to the attacker’s SMTP server.
Simple Code Snippet: Attacker’s Fake SMTP Server (Python)
import smtpd, asyncore
class CredentialCatcher(smtpd.SMTPServer):
def process_message(self, peer, mailfrom, rcpttos, data, **kwargs):
print(f"Connection from {peer}")
print(f"MAIL FROM: {mailfrom}")
print(f"RCPT TO: {rcpttos}")
# Credentials are in AUTH commands—logged separately if using real server software
server = CredentialCatcher(('...', 25), None)
print("Fake SMTP server listening on port 25...")
asyncore.loop()
*Note*: In a real attack, the attacker would run an SMTP server with authentication logging enabled, to capture credentials sent in AUTH PLAIN or LOGIN commands.
Why Is This Dangerous?
SMTP credentials are often highly privileged and allow sending company emails, reading inbox contents, and sometimes even resetting passwords for other systems. If these are stolen, the attacker can:
Possibly leverage Single Sign-On (SSO) connections
Because the device doesn't ask for re-authentication upon changing SMTP destination host, *anyone with admin access to the device* can quietly collect these credentials—even without knowledge of the current password.
Mitigation & Recommendations
- Update device firmware: Check with your vendor for patches or mitigations related to CVE-2024-5143.
- Vendor advisory: NIST NVD - CVE-2024-5143
Restrict local admin panel access: Only trusted IT staff should have device admin privileges.
- Use strong server-side authentication: Protect SMTP servers against external connections and monitor for unusual activity.
- Require password re-entry: Devices should prompt for the current credentials anytime the SMTP server destination is changed, not just when changing the password or username.
Further Reading
- A Deep Dive on SMTP Credential Phishing via Devices
- OWASP: Insecure Default Device Configuration
Summary
CVE-2024-5143 exposes a critical weakness in how many network devices handle SMTP configuration: any admin can change where "scan to email" and notifications go, and capture the credentials *without ever knowing/entering* the original username or password. All IT admins should audit their network devices for this issue, ensure firmware is updated, and train staff on the dangers.
Timeline
Published on: 05/23/2024 17:15:31 UTC
Last modified on: 10/31/2024 15:35:44 UTC