SmarterMail .NET deserialization (CVE-2019-7214)

SmarterMail is a Windows mail server. Its versions 16.x before build 6985 expose an admin channel over .NET Remoting on port 17001 that deserializes client-sent objects without validating their type. This is CVE-2019-7214: an unauthenticated attacker can send a malicious serialized object (an ObjectDataProvider/TypeConfuseDelegate family gadget) that, upon being rebuilt, runs commands on the server.

Insecure deserialization is a classic pattern: the receiver trusts the byte stream and rebuilds an arbitrary object; with the right gadget, that reconstruction triggers a Process.Start call or equivalent. Here the channel doesn't even ask for authentication, so the RCE is direct.

There's a public exploit (Exploit-DB 49216) that automates sending the object and ships a PowerShell reverse shell payload:

searchsploit -m windows/remote/49216.py
# edit HOST, PORT=17001, LHOST, LPORT in the header
python3 49216.py

The object is deserialized in the SmarterMail service's context, which runs as a highly privileged account (often SYSTEM), so the shell usually lands as nt authority\system already, with no need to escalate.

How it's identified. Port 17001 flagged as MS .NET Remoting by nmap, together with SmarterMail hints (web console on 9998 with /interface/root, or an anonymous FTP with the ImapRetrieval/Spool layout), points to the product and its vulnerable version.

How to detect it. The network signature is .NET Remoting traffic to port 17001 from a source that is not a known administration client, carrying a serialized object with recognizable gadgets (ObjectDataProvider, TypeConfuseDelegate, System.Diagnostics.Process strings) that an IDS with payload inspection can flag. On the host, the definitive pattern is process lineage: the SmarterMail service (often as SYSTEM) spawning powershell.exe/cmd.exe as a child (Event ID 4688 / Sysmon 1), something a mail server never does. A connection to 17001 followed by an anomalous child process is the chain.

Defence. Update SmarterMail to build 6985 or later, don't expose port 17001 to untrusted networks, and run the service under a lower-privilege account. The root cause, deserialization of untrusted data, is avoided by validating types or using safe data formats. Related to Node.js deserialization and pickle deserialization.