Hello, I have a very weird problem on a CentOS 5.2 system. A few months ago, encrypted passwords in the shadow file were MD5'ed - allowing for long passwords, rather than only 8 characters max. Today, passwords are 3DES'ed only. No way to find how the system reverted to DES-encrypting. But what's more bothersome is we cannot get the system to go the MD5 way again, despite all our best efforts. Authconfig says this :
pam_unix is always enabled shadow passwords are enabled password hashing algorithm is md5
So... where to look ? Tia, -- FdL
Frédérique Da Luene wrote:
pam_unix is always enabled shadow passwords are enabled password hashing algorithm is md5
Check /etc/sysconfig/authconfig for
USEMD5=yes
If that is there and you still get 3DES passwords, then, ummm, check that your /usr/bin/passwd is the one which is shipped with CentOS.
Ralph
Hello, I have a very weird problem on a CentOS 5.2 system. A few months ago, encrypted passwords in the shadow file were MD5'ed - allowing for long passwords, rather than only 8 characters max. Today, passwords are 3DES'ed only. No way to find how the system reverted to DES-encrypting. But what's more bothersome is we cannot get the system to go the MD5 way again, despite all our best efforts. Authconfig says this :
pam_unix is always enabled shadow passwords are enabled password hashing algorithm is md5
So... where to look ?
Have you checked /etc/libuser.conf for crypt_style? pwck and grpck can verify integrity of the data in /etc/passwd /etc/group /etc/shadow /etc/gshadow.
Hi Barry
--- En date de : Jeu 2.4.09, Barry Brimer lists@brimer.org a écrit :
De: Barry Brimer lists@brimer.org Have you checked /etc/libuser.conf for crypt_style? pwck and grpck can verify integrity of the data in /etc/passwd /etc/group /etc/shadow /etc/gshadow.
I have just checked, and libuser.conf has :
crypt_style = md5 modules = files shadow create_modules = files shadow
pwck and grpck both tell us everything is ok. This is really strange... -- FdL
Frédérique Da Luene wrote:
De: Barry Brimer lists@brimer.org Have you checked /etc/libuser.conf for crypt_style? pwck and grpck can verify integrity of the data in /etc/passwd /etc/group /etc/shadow /etc/gshadow.
I have just checked, and libuser.conf has :
crypt_style = md5 modules = files shadow create_modules = files shadow
pwck and grpck both tell us everything is ok. This is really strange...
Existing entries don't (and can't) change when you change crypt_style so everything should still be OK. What happens when you add a new user with the system tools?
Hi,
--- En date de : Jeu 2.4.09, Les Mikesell lesmikesell@gmail.com a écrit :
De: Les Mikesell lesmikesell@gmail.com Objet: Re: [CentOS] Shadow passwords NOT md5'ed ? À: "CentOS mailing list" centos@centos.org Date: Jeudi 2 Avril 2009, 16h42 Frédérique Da Luene wrote:
De: Barry Brimer lists@brimer.org Have you checked /etc/libuser.conf for
crypt_style? pwck
and grpck can verify integrity of the data in
/etc/passwd /etc/group
/etc/shadow /etc/gshadow.
I have just checked, and libuser.conf has :
crypt_style = md5 modules = files shadow create_modules = files shadow
pwck and grpck both tell us everything is ok. This is really strange...
Existing entries don't (and can't) change when you change crypt_style so everything should still be OK. What happens when you add a new user with the system tools?
Useradd newuser : ok passwd newuser : ok
The password is not MD5, only 3DES.
Ralph Angenendt wrote:
Frédérique Da Luene wrote:
Useradd newuser : ok passwd newuser : ok
The password is not MD5, only 3DES.
Again: Have you looked if passwd on your machine is the one from CentOS?
I would suggesting copying the binary to a known clean machine to check the md5sum to verify. If you might have been hacked, you can't check the md5 on that box.
Michael A. Peters wrote:
Ralph Angenendt wrote:
Frédérique Da Luene wrote:
Useradd newuser : ok passwd newuser : ok
The password is not MD5, only 3DES.
Again: Have you looked if passwd on your machine is the one from CentOS?
I would suggesting copying the binary to a known clean machine to check the md5sum to verify. If you might have been hacked, you can't check the md5 on that box.
Yupp. The last times I had to handle/help in such situations, the binaries were clearly way off for the machines - often a comparing ls -l is enough, but not all the time.
Ralph
I have may missed this in all the traffic, but has anyone checked the PAM entry? This is what actually counts; the other files are used by administrative tools to configure PAM
% grep ^password /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password required pam_deny.so
The "md5" word there is what tells the password command to use md5 encryption
On Sun, Apr 05, 2009, Ralph Angenendt wrote:
Michael A. Peters wrote:
Ralph Angenendt wrote:
Frédérique Da Luene wrote:
Useradd newuser : ok passwd newuser : ok
The password is not MD5, only 3DES.
Again: Have you looked if passwd on your machine is the one from CentOS?
I would suggesting copying the binary to a known clean machine to check the md5sum to verify. If you might have been hacked, you can't check the md5 on that box.
Yupp. The last times I had to handle/help in such situations, the binaries were clearly way off for the machines - often a comparing ls -l is enough, but not all the time.
This will tell if the program is different and works on any RPM based system regardless of their package contents.
rpm -V `rpm -qf /bin/login`
Or of you're not lazy as I am.
rpm -qf /bin/login # gets the name of the package rpm -V util-linux # the name of the package returned.
Bill Campbell wrote:
On Sun, Apr 05, 2009, Ralph Angenendt wrote:
Michael A. Peters wrote:
Ralph Angenendt wrote:
Frédérique Da Luene wrote:
Useradd newuser : ok passwd newuser : ok
The password is not MD5, only 3DES.
Again: Have you looked if passwd on your machine is the one from CentOS?
I would suggesting copying the binary to a known clean machine to check the md5sum to verify. If you might have been hacked, you can't check the md5 on that box.
Yupp. The last times I had to handle/help in such situations, the binaries were clearly way off for the machines - often a comparing ls -l is enough, but not all the time.
This will tell if the program is different and works on any RPM based system regardless of their package contents.
rpm -V `rpm -qf /bin/login`
This assumes that rpm and the library it uses have not been compromised. I personally suspect the machine has been compromised.
On Sun, Apr 05, 2009, Michael A. Peters wrote:
Bill Campbell wrote:
On Sun, Apr 05, 2009, Ralph Angenendt wrote:
Michael A. Peters wrote:
Ralph Angenendt wrote:
Frédérique Da Luene wrote:
Useradd newuser : ok passwd newuser : ok
The password is not MD5, only 3DES.
Again: Have you looked if passwd on your machine is the one from CentOS?
I would suggesting copying the binary to a known clean machine to check the md5sum to verify. If you might have been hacked, you can't check the md5 on that box.
Yupp. The last times I had to handle/help in such situations, the binaries were clearly way off for the machines - often a comparing ls -l is enough, but not all the time.
This will tell if the program is different and works on any RPM based system regardless of their package contents.
rpm -V `rpm -qf /bin/login`
This assumes that rpm and the library it uses have not been compromised. I personally suspect the machine has been compromised.
So far I have not seen either rpm or its database changed on any of the Linux cracks I have analyzed, and I have a fairly large sample set. That isn't to say that it can't happen.
We also use a system I have developed, similar to tripwire and aide, that maintains a database of all critical files on the system, and will detect any changed files at least in /bin, /sbin, /usr/bin, /usr/sbin, and /etc directories, and any setuid files on any file systems not mounted suid. This runs at least daily, and sends e-mail notification of any changes to our security alias using direct SMTP, bypassing the system's e-mail system in case that is either down or compromised.
I disable prelink as (a) I think it is a dubious optimization, and (b) it can make changes that make tracking system integrity more difficult.
Given a good database and quick detection of intrusion, I have found it possible to clean systems quickly and with a reasonable degree of confidence presuming that the system has been monitored properly from installation. I certainly wouldn't try this on a system that has been unmonitored from birth.
FWIW, the vast majority of cracks of Linux systems I have seen were made first through weak user passwords. While it's possible to have good passwords required in private or business systems, I have found it practically impossible in and ISP environment where the customers don't care about security and can't be forced to use good passwords. Most often these cracks have been made via webmin or its child, usermin.
We restrict access to webmin to the local LAN, and perhaps a few external IPs, and usually disable usermin entirely. We also give most users a /bin/false shell unless they have a real need for shell access (although I did see a case where somebody had replaced /bin/false with /bin/bash on a system we inherited so had not been monitored consistently).
Bill
-
Barry Brimer -
Bill Campbell -
Frédérique Da Luene -
Les Mikesell -
Michael A. Peters -
Ralph Angenendt -
Stephen Harris