• general insecurity

    From Spectre@21:3/101 to Nobody on Tue Dec 31 11:32:00 2019
    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)
  • From Zip@21:1/202 to Spectre on Tue Dec 31 12:10:50 2019
    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)
  • From tenser@21:1/188 to Spectre on Tue Dec 31 11:02:53 2019
    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)
  • From Spectre@21:3/101 to Zip on Wed Jan 1 07:43:00 2020
    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)
  • From Spectre@21:3/101 to tenser on Wed Jan 1 08:08:00 2020
    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)