last day (15 days later) » 

11:21 AM
1
Q: ssh - why can I login with partial passwords?

marcLet's say I have a machine with a user password of 12 alphanumerical characters. When I log myself in via ssh using password authentication, I noticed a couple of days ago, that I can either only input 8 of the password characters or the whole password followed with whatever I'd like. The common ...

 
@Lambert: thanks to point it out, but still didn't managed to sort the issue.
 
@Murphy: It's Arago (based on Yocto). Have no clue on the algorithm used, bat could check ssh log files. Will post them in a bit.
 
@marc I don't think the SSH logs will be helpful. Check the first few characters of the users /etc/shadow hash entry. If it doesn't have something like $...$.......$, it's using DES. Otherwise, post the number between the first two $s, which will be the encryption method..
 
@muru: There is no /etc/shadow file in this distribution.
 
11:21 AM
@marc What does /etc/pam.d/sshd contain (if anything)?
 
```# PAM configuration for the Secure Shell service

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth required pam_env.so # [1]

# Standard Un*x authentication.
auth include common-auth

# Disallow non-root logins when /etc/nologin exists.
account required pam_nologin.so

# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account required pam_access.so
 
11:33 AM
OK, /etc/pam.d/sshd just refers to /etc/pam.d/common-auth for the actual authentication mechanisms.
It also refers to /etc/pam.d/common-accountt which looks like a typo. But it could be something worse than that: together with the lack of /etc/shadow and the apparent use of the ancient crypt()-style password hashes (as indicated by the acceptance of just the first 8 characters of the password), it makes me suspicious that this system might be hacked.
All these might be changes made by the intruder, in an attempt to make the system not log SSH logins and logouts, and to make it easier to capture users' password hashes in a form that is relatively easy to crack.
Please check the contents of /etc/pam.d/common-auth and /etc/pam.d/common-accountt (with either one or two t's at the end.)
 
11:49 AM
There's also the possibility that the system is using the old-style password storage in /etc/passwd. Do the second columns in that file contain "x" or some other string?
 
In other words, the first line in /etc/passwd is usually the root user: something like root:<something>:0:0:.... The question is: is the <something> part after the first colon character just a single x or is it a long string of characters?
If it is a long string of characters, does it begin with a $<a few characters>$? If it does, what are the characters between the dollar signs?
 
the passwd file:
root:26IAXra1Dapk7:0:0:root:/:/bin/sh
daemon:*:1:1:daemon:/usr/sbin:/bin/sh
bin:*:2:2:bin:/bin:/bin/sh
sys:*:3:3:sys:/dev:/bin/sh
sync:*:4:65534:sync:/bin:/bin/sync
games:*:5:60:games:/usr/games:/bin/sh
man:*:6:12:man:/var/cache/man:/bin/sh
lp:*:7:7:lp:/var/spool/lpd:/bin/sh
mail:*:8:8:mail:/var/mail:/bin/sh
news:*:9:9:news:/var/spool/news:/bin/sh
uucp:*:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:*:13:13:proxy:/bin:/bin/sh
www-data:*:33:33:www-data:/var/www:/bin/sh
backup:*:34:34:backup:/var/backups:/bin/sh
This system isn't intentionally hacked, as it is shipped this way by the hardware company.
 
12:05 PM
Yup, that is traditional password hash scheme. Please change your root and ftp passwords right now; they are crackable from those strings you posted.
 
Those arent the original passwords. I changed them before posting them here
 
Good.
 
The root password is also a 12 alphanumrical password, but also behaves the same way as already described.
 
But that explains why just the first 8 characters of the password is enough: the traditional password hash scheme only stores (and compares) the first 8 characters of the password.
 
Holy cow! That makes sense
But how can I change that! Is there an easy way at least?
 
12:10 PM
As I've got a Yocto project here I'm currently looking up the details how to set the password encryption method. It has to be enabled in BusyBox IIRC; I thought I had a readme somewhere regarding this...
 
Depending on the versions of PAM libraries used, maybe. In /etc/pam.d/common-auth and /etc/pam.d/common-passowd files, there is hopefully a line referring to pam_unix.so. Adding options to that line in /etc/pam.d/common-passwd controls the hashing method used when setting new passwords. The pam_unix.so library should be smart enough to auto-detect the password hashing method of the stored password hashes.
If the PAM manpages are installed, man pam_unix might be useful.
 
@marc As a first step, did you already try using passwd? What are the resulting passwords?
 
If the pam_unix.so library is relatively up-to-date, it should recognize the sha512 option, which should provide plenty of password security. If not, the option sha256 or even md5 would improve the encryption strength and allow passwords longer than 8 characters.
And the shadow option to pam_unix.so would enable the use of /etc/shadow.
 
@Murphy I already used passwd, and it doesnt changes anything regarding the limitation of 8 characters.
 
Although if the system is delivered from the vendor in this configuration, it suggests there might be some software installed that is not using PAM and might not be capable of using /etc/shadow and/or more advanced password algorithms.
 
12:25 PM
But you can try using some other algorithm; passwd has a switch for that.
passwd -a SHA-512
should result in an appropriately encrypted pwd, starting with "$6$...". Next step would be to force using /etc/shadow.
If SHA512 isn't supported, try "SHA-256" -> "$5$...".
Do you have the possibility to rebuild BusyBox?
 
According to tiebing.blogspot.fi/2013/11/… the passwd -a option values for BusyBox passwd command would be "des", "md5", "sha256" and "sha512". Of course, that is for some unnamed version of BusyBox as it existed in 2013...
 
@telcoM You're right, nice catch. They differ from the algorithm names on full-featured distris :-(
@marc You may have to apply some trial&error to get it right.
So, the command should be (I just tested!)
passwd -a sha512
 
12:41 PM
Not using /etc/shadow and using the traditional password hash scheme is so last millennium... perhaps some stern words to the vendor about security might be called for?
 
I'd just call it crap.
I just checked the BusyBox config; it's all under "Login/Password Management Utilities".
There the support for shadow passwords has to be enabled, the usage of internal crypt functions disabled (so libc is used), and the default encryption algorithm set to "sha512".
 
@Murphy: I would agree on this one, calling it crap, and having to deal with this in the year 2018.
 
Before spending too much effort with BusyBox, it might be useful to check if the PAM library used on Yocto supports the better options.
 
This may indeed be the better option. I'll leave at this point; good luck!
 
The library is probably at /lib/security/pam_unix.so. Something like strings /lib/security/pam_unix.so | grep shadow should result in some output if the library includes /etc/shadow support; replace shadow with sha512 to see if it includes the SHA-512 algorithm.
It's not a perfect test, but if the library won't support any better options, making BusyBox use better password encryption would just enable you to lock yourself out of the system. The sshd and any non-busybox "payload" services on the system are probably using the PAM library to handle passwords. If the library won't understand the improved configuration, it would have to be replaced too...
 

last day (15 days later) »