Does this look like Malware?

[LIsLinuxIsSogood]

[NeddySeagoon]

LIsLinuxIsSogood,

Using your link, I did

[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

[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...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[LIsLinuxIsSogood]

[Ant P.]

You were running Firefox as root?

[LIsLinuxIsSogood]

[NeddySeagoon]

LIsLinuxIsSogood,

[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

[LIsLinuxIsSogood]

So why this:

[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

[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

[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.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

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

[LIsLinuxIsSogood]

[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:

[Hu]

[NeddySeagoon]

LIsLinuxIsSogood,

Somebody had root to leave a root owned file behind.