Having a vuln pop up on a Friday does not spark joy. However, I am pretty convinced that the detection I got for “SpamAssassin Milter Plugin ‘mlfi_envrcpt()’ Remote Arbitrary Command Injection Vulnerability” (CVE-2010-1132) is a false positive.
I could not find any traces of a “SpamAssassin” milter on any of the machines that are indicated as vulnerable. I’m not sure how exactly the detection is done, but I tested the known exploit from ExploitDB and got the exact same output that is shown in the PoC as vulnerable:
nc localhost 25
220 <hostname> ESMTP Postfix (Ubuntu)
mail from: me@me.com
250 2.1.0 Ok
rcpt to: root+:"|touch /tmp/pwnd"
250 2.1.5 Ok
However, the file /tmp/pwnd is never created and there are no indications of any changes made.
How does the detection for this vulnerability work? The 99% QoD indicates that an exploit was executed which confirmed the presence of the vulnerability; if it is the same exploit linked from ExploitDB, it is probably prone to false-positives.
I’d appreciate some information on the matter. If I can provide any further information to help, please let me know.
Here is how the gb_spamassassin_milter_38578.nasl script detects the potential SMTP RCE vulnerability:
1. It identifies SMTP ports using the smtp_get_ports() function.
2. For each identified SMTP port, the script attempts to retrieve the SMTP banner to gather information about the SMTP server.
3. It extracts the domain name from the banner if available.
4. The script opens a connection to the SMTP server and simulates a simple SMTP conversation, including sending a "MAIL FROM" command and a specially crafted "RCPT TO" command with a payload intended to trigger the vulnerability. This specially crafted "RCPT TO" command injects "sleep 16" into the command.
5. It measures the time taken for the SMTP server to respond to the "RCPT TO" command and compares it to the time taken for the "MAIL FROM" command.
6. If the response time for the "RCPT TO" command is significantly longer than the "MAIL FROM" command and falls within a specific time range (between 15 and 20 seconds), the script considers this as evidence of a potentially vulnerable system.
This is proposed to work because instead of creating a file such as the PoC from VulnDB you supplied, the detection script injects a sleep 16 into the RCPT TO command and compares the response time to that of the MAIL FROM response. This is why the time differential is used as the litmus test.
thanks for your fast reply and detailed info. I checked if the payload
nc localhost 25
220 <hostname> ESMTP Postfix (Ubuntu)
mail from: me@me.com
250 2.1.0 Ok
rcpt to: root+:"|sleep 16"
250 2.1.5 Ok
would work as a “simulation” of the nasl and it didn’t seem to have any noticeable effect. The response was almost instantaneous, and definitely shorter than 15 seconds
Maybe the server had a hiccup when handling that particular request when the scan was made, so I’ll consider this as a false positive for now and keep a close eye in the following days.
Thanks again for your help, and have a nice weekend.
The VT in question is doing a “generic” check for this so even if SpamAssassin milter is not installed a system having a similar vulnerability might get reported
The actual sent command is RCPT TO: root+:"; sleep 16 ;"
A remote_vul QoD for such timing based checks might be indeed too high as networking factors could play a role. remote_analysis should better fit and the VT in question has been updated accordingly (besides some more minor updates to it)
Remote checks that perform some analysis, but may not always be completely reliable depending on environmental conditions. Narrowing down suspected false-positive or false-negative edge cases may require analysis by the user (see Chapter 11.8).
