Despite the previous efforts I've still got some issues with the BBS user, �thats used to ssh to TLP. Somehow they're able to exploit the account to �insert a crontab. I've subsequently taken write perms off the users home �directory, and innoculated the user crontab and then locked it by removing �write permissions....

Have to say I don't quite know what the result is, but the injection is,

# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
#0 0 */3 * * /dev/shm/.lwp/.rsync/a/upd>/dev/null 2>&1
#5 8 * * 0 /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#@reboot /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#0 0 */3 * * /dev/shm/.lwp/.rsync/c/aptitude>/dev/null 2>&1

Its rsyncing to something? and it also tries to install something? I haven't �looked at these in a terminal removing the /dev/null at this point, I s'pose �I should look at the files its calling. The result is a rogue ./cron task, �and a load average that shoots through the roof, on the octo core its out �past 18 so it uses everything it can.

Spec


--- SuperBBS v1.17-3 (Eval)
* Origin: (21:3/101)

Hello Spectre!

On 31 Dec 2019, Spectre said the following...

Despite the previous efforts I've still got some issues with the BBS
user, thats used to ssh to TLP. Somehow they're able to exploit the account to insert a crontab. I've subsequently taken write perms off

Try adding the BBS user to a line in /etc/cron.deny, that should take care of any attempts of adding to the user's crontab (unless they got root on the machine of course). Also don't forget to clear the BBS user's crontab completely so that it is clean after locking it down.

I'm not sure if this prevents any /etc/cron.d/ cron jobs (for that user) from running, though... I think anything that you (as root) add to the user's crontab, and any /etc/cron.d/ jobs for that user, will work as usual, it is just the "crontab -e" (editing/adding etc.) for that user which will be "locked".

#0 0 */3 * * /dev/shm/.lwp/.rsync/a/upd>/dev/null 2>&1
#5 8 * * 0 /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#@reboot /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#0 0 */3 * * /dev/shm/.lwp/.rsync/c/aptitude>/dev/null 2>&1

Given the CPU usage, I'd say some of those are perhaps crypto mining
software. The dot directories to hide everything and the names probably just
an attempt to masquerade all of it in case you would notice the files.

What puzzles me is that /dev/shm is usually a RAM disk (tmpfs file system), so should get cleared on every boot, yet they add the @reboot line which would then be useless as nothing is left after a reboot...

Found some thread mentioning these filenames:

https://ubuntuforums.org/showthread.php?t=2395684

You might want to check the .ssh directory of the BBS user (e.g. ~bbs/.ssh/)
to see if they have added SSH keys to it -- that way they could SSH to the machine and perhaps execute commands that way, e.g. spawn a shell... These could be remnants from the first time they got in, and would explain why the escape handling (traps) didn't have any effect...

Best regards
Zip

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

On 31 Dec 2019, Spectre said the following...

Despite the previous efforts I've still got some issues with the BBS
user, thats used to ssh to TLP. Somehow they're able to exploit the account to insert a crontab. I've subsequently taken write perms off
the users home directory, and innoculated the user crontab and then
locked it by removing write permissions....

What's likely going on is that the user has managed to get
access to a shell on your system. Do you have something
installed that lets them run an editor or pager or something
along those lines? Those are common vectors for getting to
a shell.

It is likely that once they get access to the shell, they
leverage that to install a crontab file, possibly via the
`crontab` command. Setting permissions on the tab file
and changing the permissions of the home directory are
unlikely to help much here.

Have to say I don't quite know what the result is, but the injection is,

# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) #0 0 */3 * * /dev/shm/.lwp/.rsync/a/upd>/dev/null 2>&1
#5 8 * * 0 /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#@reboot /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#0 0 */3 * * /dev/shm/.lwp/.rsync/c/aptitude>/dev/null 2>&1

Its rsyncing to something? and it also tries to install something? I haven't looked at these in a terminal removing the /dev/null at this point, I s'pose I should look at the files its calling. The result is a rogue ./cron task, and a load average that shoots through the roof, on
the octo core its out past 18 so it uses everything it can.

It might be, but more to the point, it's running three separate
programs, which are in odd directories (/dev/shm/.lwp/.rsync and
the subdirectories underneath that). I'd imagine these are
probably shell scripts; I'd take a look at them to see what they
do.

At this point, it seems likely that you've had a root compromise.

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: ACiD Underworld // acidunderworld.com:31337 (21:1/188)

Try adding the BBS user to a line in /etc/cron.deny, that should take care of any attempts of adding to the user's crontab (unless they got root
on the machine of course). Also don't forget to clear the BBS user's crontab completely so that it is clean after locking it down.

All done, I've gone for a cron.allow, to ban system wide user cron access. If �any other user is compromised then it would at least cover all the user �accounts. I've just commented the existing addition in an attempt to figure �out just what it is, bit its looking like the crontab is just a launch �vehicle.

I'm not sure if this prevents any /etc/cron.d/ cron jobs (for that user) from running, though... I think anything that you (as root) add to
the user's crontab, and any /etc/cron.d/ jobs for that user, will
work as usual, it is just the "crontab -e" (editing/adding
etc.) for that user which will be "locked".

That would be correct, and at this point that seems to be the only attack �vector, a thorough study of the rest of the crontab files doesn't show �anything being tampered with or any superfluous ones in existance.

software. The dot directories to hide everything and the names probably just an attempt to masquerade all of it in case you would notice
the files.

You can't miss it... forget looking for an extra file for a moment, the �impact
on the system generally is to large to hide. However if you crawl �through those directories, none of them exist any longer even without a �reboot to clear the tmpfs volume. So whatever it is, seems to launch and �clean up after
itself.

You might want to check the .ssh directory of the BBS user (e.g. ~bbs/.ssh/) to see if they have added SSH keys to it -- that way they could SSH to the machine and perhaps execute commands that way, e.g.

No keys there.. in fact its another empty directory.. I should check the �system ones though just in case.

I am reasonably sure the root account is still secure.. even if they made off �with the password file, the current password isn't something you'd find in a �dictionary even though its only 7 characters its a mash of operators and �alpha numerics. They'd be more likely to crack the password for the other �user account. But this doesn't seem to be the case either.

I would expect should they have a system password, and they're that clever �inside the system, that the fileserver would still be subject to the same �attack, its no longer visible from outside, but once inside on the BBS �system, you could still endeavour to use it.

Spec


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: Scrawled in haste at The Lower Planes (21:3/101)

What's likely going on is that the user has managed to get access
to a shell on your system. Do you have something installed
that lets them run an editor or pager or something along those
lines? Those are common vectors for getting to a shell.

Not that I'm aware of... I can't figure is where/how exactly they're �achieving
that shell. Theres the regular editors.. vim, I use joe more often �than not so
its there too, theres not much else, more/less... its a pretty �basic setup aside from the VM stuff. Before there was a problem I used to �have on the older system the BBS running as the BBS user, but that looked �like a problem in itself, so I took that back off it, and any remnants of �that mess would be long gone.

It is likely that once they get access to the shell, they leverage
that to install a crontab file, possibly via the `crontab` command. Setting permissions on the tab file and changing the permissions
of the home directory are unlikely to help much here.

Well they've either been able to use "crontab -e" or are manually editing �/var/spool/cron/crontabs/bbs roots crontab is clean, and the system crontabs �seem clean too. Well the fewer places there are to write to, the harder its �going to be to try and "install" something. I'll have to have a look at / �dev/shm and see what can be done with that too.

programs, which are in odd directories (/dev/shm/.lwp/.rsync and the subdirectories underneath that). I'd imagine these are probably
shell scripts; I'd take a look at them to see what they do.

Those locations are empty or don't exist...

At this point, it seems likely that you've had a root compromise.

That would make sense, but I'm not seeing any evidence of that, just �userspace
compromise. I s'pose if I was going to try and be clever, I'd be �looking for logins from bbs and capturing the sessions... have to admit I �don't really know how to do that off hand, but it'd give me something to look �at post intrusion.

I know if I close the bbs account the problem will go away... so I'm not sure �the root compromise is really in... otherwise you'd hide yourself another �account somewhere surely? No evidence can be found for that either... Shrug. �I have to accept doing it this way is a security issue.. so trying to �ameliorate the ability of the account to write anywhere ought to help lock it �down, so if access is still there, there's nothing to be done with it. The �only other suggestion I've had is to place the bbs account on seperate system �that does only that function, be it a VM or seperate hardware. But that �seems to add a lot of extra latency to the BBS system.

Spec


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: Scrawled in haste at The Lower Planes (21:3/101)