etc directry chmoded to 777?

bungeebones · 09-30-2013, 10:37 AM

I am running two EdUbuntu 12.04 and have them set up as LTSP servers in a small school. We were running only one until last week when, after its resources started being overtaxed, I built and installed the second. Both machines are 6 core amd with either 16 or 32 gb of ram.

I was having really weird network problems last week with the new one. Two pcs in the room would let authroized users login while the rest of the room wouldn't. And those boxes wouldn't let anyone log in even if the ethernet cable from the one letting people in was moved to another machine, as if only certain mac addresses were allowed in. I had to reinstall and got it working friday.

So Friday I had two working servers, one old and one new. They were on separate ethernet lines out and separate switches and each ran separate parts of the school. One was on a 192.168.3.X address and the other was on a 192.168.0.X address. They were turned off early friday evening. I started the old one Sunday and I was on it most of the day but not out in its network.

This morning, the old machine started to exhibit the exact same symptoms of the previous installation on the new one (i.e. a user could login on one pc in the room but not the others). The only common denominator was that this old server was now on the same ethernet cable as the earlier failed install.

I put a tester on the cable and it seemed fine. I ran a second, new line and put a laptop on it and it still acted the same. It seems to authenticate the user ok but then kicks them off and back to the login page. It acts like that is what is going on but can't tell for sure.

So I put the whole school on the same server (the new one). The affected machines were able to login without problem (so not a networking issue right?). I then started to copy student's home directory contents over to the new server manually with a sd card writer. The new server wouldn't let me do it and rejected me as sudo saying something grievous about the sudoers file. After some investigation I discovered the entire etc directory (including the sudoer file) had been chmodded to 777?

My question is in regards to out-of-the box linux security. Is there a security hole that would allow something like this to happen out of the box? I doubt if anyone got my password but there is another person with admin and sudo access.

Thanks if anyone can help me with this..

PS I have been backing up the old site with the Ubuntu backup program but never tried to restore anything with it before. Any pointers on using it would be appreciated also. Basically we just need the home folders.

Firerat · 09-30-2013, 11:04 AM

check /var/log/auth.log for sudo entries

something like

Code:

zgrep sudo /var/log/auth.log* | less

will also handle any gziped logs ( .log.2.gz etc )

bungeebones · 09-30-2013, 11:32 AM

Quote:

Originally Posted by Firerat

check /var/log/auth.log for sudo entries

something like

Code:

zgrep sudo /var/log/auth.log* | less

will also handle any gziped logs ( .log.2.gz etc )

Thanks firerat,

The earliest entry today was at 10:45 which was about three hours after I booted it.

The first post is an odd notice that it was not able to execute sendmail - no such directory or folder. I didn't attempt to mail anything but maybe someone else did.

Right after it says sudoer is chmod 777 should be 440.

I failed to mention I use webmin and at the end of that line it says PWD=usr/share/webmin

Assuming it was a hack, could they have used a webmin vulnerability to get in?

I'm not concerned about salvaging it and will reinstall but I hope I can at least prevent a repeat occurrence.

bungeebones · 09-30-2013, 12:05 PM

I mis read the file and there were earlier posts.

The first one involves a trusted student and it looks to me like he was playing around with sudo. If someone can please shed some light on this post :

sudo: pam-unix (sudo:auth) auth could not identify password for [student's name was here]

Then it had:
sudo: student's name here 3 incorrect password attempts TTY unknown PWD = home/student name; user: root COMMAND=/usr/share/profilemanager

Was sudo just reporting he failed his own login or was he trying to login as sudo?

Firerat · 09-30-2013, 02:32 PM

I don't think you have been 'hacked'
It would be a little dumb to
chmod 777 /etc -R

unless they just wanted to break it

sudo is a group account ( if it exists )

Code:

sudo: student's name here 3 incorrect password attempts TTY unknown PWD = home/student name; user: root COMMAND=/usr/share/profilemanager

they did

Code:

sudo profilemanager # or /usr/share/profilemanager

from their home dir. , and failed to enter their own password three times

have to admit, I have no idea what /usr/share/profilemanager does
it might not even exist

if you give a student sudo, then restrict it to what they need ( which should be nothing

)

anyway,

Code:

stat /etc/os-release

that will give you a date/time of the chmod 777

bungeebones · 10-01-2013, 12:11 PM

Thanks, I didn't think that student would have tried to hack in but needed to make sure.

Anyway, I reinstalled lastnight and everything seems ok except I've got to do some customisation.

Thanks for the help

Habitual · 10-01-2013, 02:58 PM

save the /etc perms for future reference (could be scripted?)

Code:

sudo getfacl /etc/* -R > facl.in

restoring them seems to be like so:

Code:

sudo setfacl --restore=facl.in

from the setfacl man page:

Code:

 --restore=file
           Restore a permission backup created by ‘getfacl -R’ or similar. All
           permissions of a complete directory subtree are restored using this
           mechanism.  If the input contains owner comments or group comments,
           and setfacl is run by root, the owner and owning group of all files
           are  restored  as  well.  This  option  cannot  be mixed with other
           options except ‘--test’.

Warning: I've never used this process, so wait for someone else to chime in.

Good Luck!

Don't mind me, my post is a little "excessive" for a single /etc/sudoers file.
Sorry about that. Unless you enjoy shell exercises of this nature, then you're as sick as I am.

Have a Great Day!

chrism01 · 10-03-2013, 07:10 PM

This is a bit of a long shot, but rpm based systems are able to reset perms/ownerships etc correctly from the rpmdb recs
http://www.cyberciti.biz/tips/reset-...ermission.html
It says there that this feature is not available to deb based systems .. HOWEVER, that's a very old page (' LAST UPDATED August 28, 2007'), so its possible it may be available now.
imho it ought to be