Need help identifying hashes

[poot36]

I have two hashes that hashid can not identify and am wondering if someone can help me with them.
They are "$1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJw" and "$1$xDz96xgqD$piln.bBT7i3c8qUNMsRB//" without the quotes.

[radar_macgyver]

https://en.wikipedia.org/wiki/Crypt_(C)

The leading $1$ indicates it's md5.

[poot36]

That does appear to be true but if you look at the length of each hash they do not match the standard md5 length and the first hash has the 3rd $ one position over from a standard md5 hash.

[Nominal Animal]

It looks like a home-cooked PHP salted MD5 hash output to me.

$1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJw has a 8-character or 48-bit salt eyPcxmTg, and a 21-character or 126-bit hash ZbDfrT4wU2TEyFPOw9XJw.

$1$xDz96xgqD$piln.bBT7i3c8qUNMsRB// has a 9-character or 54-bit salt xDz96xgqD, and a 22-character or 132-bit hash piln.bBT7i3c8qUNMsRB//.

If we assume /.0-9A-Za-z is used, then for the first, the 48-bit salt would be AB E6 E8 F7 27 EC and the 128-bit hash 96 73 EB DD F1 BC 80 47 D0 F9 16 DA F0 B8 D5 F0, corresponding to openssl passwd -1 output of $1$q+bo9yfs$lnPr3fG8gEfQ+Rba8LjV8A==.  For the second, the 56-bit salt would be F4 FF CB 23 DB 36 3C and the 136-bit hash D6 EC 73 06 73 5F 26 E1 68 2B 68 19 63 87 4D 00 (where the final zero is irrelevant, a consequence of the encoding method, and thus the hash being a normal 128-bit one), corresponding to openssl passwd -1 output of $1$9P/LI9s2PA==$1uxzBnNfJuFoK2gZY4dNAA==.

I'd need to know which application is involved, or where the hash was encountered, to delve any deeper.

[Shonky]

That does appear to be true but if you look at the length of each hash they do not match the standard md5 length and the first hash has the 3rd $ one position over from a standard md5 hash.

Note md5crypt != md5

[bitwelder]

An inquiry to chatgpt returned that the first one, with 8 chars salt and 21 chars hash could be a 'Cisco type 5 password hashing'

[poot36]

@Nominal Animal They came from a Linux based ARM NVIDIA development board.  The Linux version is 3.10.40.

@Shonky I did screw up the md5 thing, I meant to say md5crypt but was not thinking correctly as I was distracted when typing up the message.

Is it possible to decode these non standards hashes with hashcat or will that not work?

[radar_macgyver]

The 9-char salt isn't really an issue, is it? The salt length is arbitrary AFAIK so that alone shouldn't be an issue. I can't explain the longer hash length though.

[Nominal Animal]

@Nominal Animal They came from a Linux based ARM NVIDIA development board.  The Linux version is 3.10.40.

Where on that board? /etc/shadow?

The Linux kernel does not use passwords or hashes, it is all done by (privileged) userspace applications or services like PAM; specifically pam_unix.so[/URL] (C source) on typical workstations.

We need to know which program uses the file you discovered the information in, to find out the hash algorithm and encoding.  To me, this looks like a home-grown password checking one might do from e.g. PHP, where the resulting password entry (containing salt and hash) is somehow modified, and likely uses a different encoding (64-character set; perhaps in a different order) than the standard tools do.

Is it possible to decode these non standards hashes with hashcat or will that not work?

Perhaps.  If the source to the program that uses these hashes is available, we might be able to transform the hashes to a form that hashcat can work with to find the password that results in the same hash; especially because hashcat uses certain algorithmic approaches to find plaintexts corresponding to specific MD5 hashes.

The details we need to know are 1) the hash algorithm, 2) the number of iterations (typically 1000), and 3) the encoding method (between binary and readable text) for the hash and the salt.  For a 128-bit hash with result prefix $1$, MD5 is the most likely one.


The first one looks at first glance like it could be a straightforward /etc/shadow password entry, because
    openssl passwd -1 -salt eyPcxmTg password
yields similar entries, for example
    $1$eyPcxmTg$XKWhmekZYWOHM5G5Ds6v81   1234
    $1$eyPcxmTg$JxqddwETEUR0W.qKUWUN60   nvidia
    $1$eyPcxmTg$mTx649hh3BkkNRuntSdH31   nvidia-arm
But, when you compare to the hash of the unknown password using the same salt,
    $1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJw
you see the hash is one character short.  This is critical, because 6-bit encoding here uses groups of four characters to encode 24 bits, with a possible trailing 8-bit group represented using XX==, and 16-bit group using XXX=.  Even if the padding character = was omitted, hashes encoded to 4n+1 characters just do not happen using normal methods.

Similarly,
    openssl passwd -1 -salt xDz96xgqD  1234
yields
    $1$xDz96xgq$J0ZlMdHTZ.E.QF1J.vLVp.
with the final character in the salt dropped and thus unused.  Indeed, the salt length is not arbitrary for the $1$ hash method using PAM/openssl.  Even the md5crypt utility limits the salt to 8 characters.

[poot36]

@Nominal Animal The hashes came from /etc/shadow file.  I do have a dump of the entire firmware from the system so I can take a look at any other relevant sections that may tell us how they were encoded.
The entire string from the shadow file for each hash is as follows: "csdev:$1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJw:16148:0:99999:7:::" and "gve6776696577:$1$xDz96xgqD$piln.bBT7i3c8qUNMsRB//:16176:0:99999:7:::" without the quotes.

[Nominal Animal]

I hope you are aware that you can also simply change the two strings in the firmware, for example to
    csdev:$1$eyPcxmTg$sytqkZd2hmk2JWSeTZi1H/:16148:0:99999:7:::
    gve6776696577:$1$xDz96xgq$FsovEQ3MZuqYRcWru6oU01:16176:0:99999:7:::
to change the passwords to be the same as the usernames are.

The regular expression format for pam-unix.so passwords beginning with "$1$" is
    \$1\$[^$]{1,8}\$[./0-9A-Za-z]{22}
which means the csdev cannot have worked (allowed access with any password) with standard pam-unix.so, because it has invalid hash length (21 characters instead of 22); and any login attempts should yield user "csv" has corrupted passwd entry system log messages (typically into /var/log/auth.log in Debian derivatives).

Similarly, the gve6776696577 cannot have worked (allowed access with any password) using standard pam-unix.so, because pam_unix/pam_unix_passwd.c:MD5Name(crypt_md5) will only use the first 8 characters from the salt, and as it passes the entire password hash construction (starting with $1$), the result will never match because the salt parts will differ.  Thus, any login attempts should yield user "gve6776696577" has corrupted passwd entry system log messages (typically into /var/log/auth.log in Debian derivatives).

Assuming the system used PAM, you can find the PAM login configuration in the firmware image in /etc/pam.d/login file.  It typically contains a @include common-auth, so that the actual config is in /etc/pam.d/common-auth, with the first non-comment line being
    auth    [success=1 default=ignore]      pam_unix.so nullok
which means pam_unix.so is the primary authenticator.  Its sources are at Github at linux-pam/modules/pam_unix/, so if you're investigating a security failure, it is quite possible an attacker not only added those two accounts but also replaced the pam_unix.so binary as well.

If you examine /etc/issue, /etc/lsb-release, and /etc/os-release files in the firmware image, you can tell what base Linux distribution this uses.  This would be important to investigate any further.

The full /etc/shadow lines show that the csdev account was created in 2014-03-19, and the gve6776696577 one in 2014-04-16 (assuming UTC time; might also be one day before or later depending on time zone), if not faked/synthesized by modifying /etc/shadow directly instead via e.g. the passwd command.

Why do you need to crack these hashes?  Do you suspect nefarious access?  Or are you investigating why these accounts cannot be logged in? Or for some other reason?

[poot36]

I have a few of these devices at work that need some settings changed but they were set up by a former tech that did not document the password to get into the device so I was left with trying to get in.  I do see references to pam in the firmware dump but it was a quick skim through so I did not notice if the files you listed are on the device.  I will take a look and get back to you.

[poot36]

There is no files in /var/log/ at all.  Also the folder has a lock icon on it but that did not prevent me from going into the folder.
The /etc/pam.d/login file does not have a @include common-auth string in it.
It has this instead:
auth  required pam_unix.so nullok

account   required pam_unix.so

password required pam_unix.so nullok
There is additional text after this but it does not seem relevant to this issue.
There is no /etc/pam.d/common-auth folder.
Files /etc/issue and /etc/lsb-release do not exist.
The file /etc/os-release does exist and has this strings in it:
NAME=Buildroot
VERSION=2020.02.3
ID=buildroot
VERSION_ID=2020.02.3
PRETTY_NAME="Buildroot 2020.02.3"

[Nominal Animal]

Yup, clearly uses PAM and pam-unix.so.  The systems integration ("putting together the distro") was done using buildroot.

I would suggest you modify one of the firmwares' /etc/shadow, replacing the password hashes.
You can generate new password hashes for testing via
    openssl passwd -1 -noverify password
but for actual use, I recommend using
    openssl passwd -1
which uses a standard password prompt to read and verify the password.  (When the password is supplied on the command line, other processes running as the same user account or with root privileges can see the password via /proc/PID/cmdline, whereas pipes and socket pairs are impossible (outside the kernel) to eavesdrop without causing glitches and errors.)

Personally, my nose twitches a bit: there is something fishy here, either incompetence or malice.  If this was my responsibility, I'd (have to) spin a new firmware image from scratch, to ensure there are no hidden traps, and would fully document the process, plus whatever proprietary/custom stuff is added on top, for the next guy after me to have a solid basis of starting from.  (But they also call me a paranoid perfectionist, who spends way too much time on things.)  If you also have information on how these devices are actually used, you might be able to help optimize the workflow by choosing better components and/or configuration for the system, too.  Things have a tendency of evolving a lot in four years in the open source world.

Most likely innocent explanation is that whatever post-customization/installation is done to the image involves direct editing of /etc/shadow (instead of doing it properly via passwd or chpasswd); and if so, it should be replaced by doing it via passwd or chpasswd instead, because direct editing easily leads to – as we see here! – malformed entries.  (Not doing this "right" from the get go is perfectly innocent and acceptable, because it takes quite a lot of experience in systems integration to know this kind of small details, as they stem from practical experience and not theory.)

The malicious explanation is that these entries were modified via a script (running sed -e '/^csdev:/ s/PATTERN/REPLACEMENT/' -e '/^gve6776696577:/ s/PATTERN/REPLACEMENT/' /etc/shadow as root) to deliberately make them inoperable but innocuous-looking for some reason.  The fact that there are no system logs could be a deliberate design choice in systems integration if the devices have limited storage space – these logs often take a lot of room –, but it could also be done deliberately to ensure no signs of malicious tampering would be left.  Pity that people doing this do not realize these things never hit the company or the bosses, only other people doing the same job.  It's like trying to get back at bad bosses who eat lunch outside the company by spiking the sodas in the employee cafeteria with emetics: only hurts people in the same situation trying to do the job, and not the higher-ups at all.  No boss, no matter how horrible, has ever been fired because their underling made an exit bomb.

[poot36]

Well I have some good news and some not as good news.
I have been able to get my hands on a spare unit that was not setup and dumped it's firmware and the 2 accounts that I was wondering about are also on this unit so there is no issue regarding those accounts.
The not so good news is I have found that the account that we don't know the password to starts with a $6$ so it will be harder to figure out.
Thanks for the help.
I think I may need to upgrade my GPU though as hashcat does like the $6$ hash but it states a very long time to figure it out.