Need help identifying hashes - Page 1
Forum section: electronics / general

author: poot36
author_rank: Frequent Contributor
timestamp: July 25, 2024, 03:56:58 am
content: 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.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: July 25, 2024, 04:03:55 am
content: https://en.wikipedia.org/wiki/Crypt_(C)The leading $1$ indicates it's md5.

author: poot36
author_rank: Frequent Contributor
timestamp: July 25, 2024, 04:55:40 am
content: 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 25, 2024, 06:23:29 am
content: It looks like a home-cooked PHP salted MD5 hash output to me.$1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJwhas a 8-character or 48-bit salteyPcxmTg, and a 21-character or 126-bit hashZbDfrT4wU2TEyFPOw9XJw.$1$xDz96xgqD$piln.bBT7i3c8qUNMsRB//has a 9-character or 54-bit saltxDz96xgqD, and a 22-character or 132-bit hashpiln.bBT7i3c8qUNMsRB//.If we assume/.0-9A-Za-zis used, then for the first, the 48-bit salt would beAB E6 E8 F7 27 ECand the 128-bit hash96 73 EB DD F1 BC 80 47 D0 F9 16 DA F0 B8 D5 F0, corresponding toopenssl passwd -1output of$1$q+bo9yfs$lnPr3fG8gEfQ+Rba8LjV8A==. For the second, the 56-bit salt would beF4 FF CB 23 DB 36 3Cand the 136-bit hashD6 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 toopenssl passwd -1output of$1$9P/LI9s2PA==$1uxzBnNfJuFoK2gZY4dNAA==.I'd need to know which application is involved, or where the hash was encountered, to delve any deeper.

author: Shonky
author_rank: Frequent Contributor
timestamp: July 25, 2024, 07:10:38 am
content: Quote from: poot36 on July 25, 2024, 04:55:40 amNote md5crypt != md5

author: bitwelder
author_rank: Super Contributor
timestamp: July 25, 2024, 12:39:40 pm
content: 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'

author: poot36
author_rank: Frequent Contributor
timestamp: July 26, 2024, 01:36:15 am
content: @Nominal AnimalThey came from a Linux based ARM NVIDIA development board. The Linux version is 3.10.40.@ShonkyI 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?

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: July 26, 2024, 02:39:53 am
content: 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 26, 2024, 08:39:47 am
content: Quote from: poot36 on July 26, 2024, 01:36:15 amWhere on that board?/etc/shadow?The Linux kernel does not use passwords or hashes, it is all done by (privileged) userspace applications or services likePAM; specificallypam_unix.so (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.Quote from: poot36 on July 26, 2024, 01:36:15 amPerhaps. If the source to the program that uses these hashes is available, we might be able to transform the hashes to a form thathashcatcan work with to find the password that results in the same hash; especially becausehashcatuses 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 onelooksat first glance like it could be a straightforward/etc/shadowpassword entry, becauseopenssl passwd -1 -salt eyPcxmTgpasswordyields similar entries, for example$1$eyPcxmTg$XKWhmekZYWOHM5G5Ds6v811234$1$eyPcxmTg$JxqddwETEUR0W.qKUWUN60nvidia$1$eyPcxmTg$mTx649hh3BkkNRuntSdH31nvidia-armBut, when you compare to the hash of the unknown password using the same salt,$1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJwyou 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 usingXX==, and 16-bit group usingXXX=. 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 xDz96xgqD1234yields$1$xDz96xgq$J0ZlMdHTZ.E.QF1J.vLVp.with the final character in the salt dropped and thus unused. Indeed, the salt length isnotarbitrary for the$1$hash method using PAM/openssl. Even themd5cryptutility limits the salt to 8 characters.

author: poot36
author_rank: Frequent Contributor
timestamp: July 27, 2024, 02:59:24 am
content: @Nominal AnimalThe 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 27, 2024, 05:15:55 am
content: I hope you are aware that you can also simply change the two strings in the firmware, for example tocsdev:$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 forpam-unix.sopasswords beginning with "$1$" is\$1\$[^$]{1,8}\$[./0-9A-Za-z]{22}which means thecsdevcannot have worked (allowed access withanypassword) with standardpam-unix.so, because it has invalid hash length (21 characters instead of 22); and any login attempts should yielduser "csv" has corrupted passwd entrysystem log messages (typically into/var/log/auth.login Debian derivatives).Similarly, thegve6776696577cannot have worked (allowed access withanypassword) using standardpam-unix.so, becausepam_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 yielduser "gve6776696577" has corrupted passwd entrysystem log messages (typically into/var/log/auth.login Debian derivatives).Assuming the system used PAM, you can find the PAM login configuration in the firmware image in/etc/pam.d/loginfile. 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 beingauth [success=1 default=ignore] pam_unix.so nullokwhich meanspam_unix.sois the primary authenticator. Its sources are at Github atlinux-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 thepam_unix.sobinary as well.If you examine/etc/issue,/etc/lsb-release, and/etc/os-releasefiles in the firmware image, you can tell what base Linux distribution this uses. This would be important to investigate any further.The full/etc/shadowlines show that thecsdevaccount was created in 2014-03-19, and thegve6776696577one 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/shadowdirectly instead via e.g. thepasswdcommand.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?

author: poot36
author_rank: Frequent Contributor
timestamp: July 28, 2024, 01:20:24 am
content: 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.

author: poot36
author_rank: Frequent Contributor
timestamp: July 28, 2024, 07:34:02 pm
content: 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 nullokaccount required pam_unix.sopassword required pam_unix.so nullokThere 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=BuildrootVERSION=2020.02.3ID=buildrootVERSION_ID=2020.02.3PRETTY_NAME="Buildroot 2020.02.3"

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 29, 2024, 04:14:59 am
content: Yup, clearly uses PAM and pam-unix.so. The systems integration ("putting together the distro") was done usingbuildroot.I would suggest you modify one of the firmwares'/etc/shadow, replacing the password hashes.You can generate new password hashes for testing viaopenssl passwd -1 -noverifypasswordbut for actual use, I recommend usingopenssl passwd -1which 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 viapasswdorchpasswd); and if so, it should be replaced by doing it viapasswdorchpasswdinstead, 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 takesquitea 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 (runningsed -e '/^csdev:/ s/PATTERN/REPLACEMENT/' -e '/^gve6776696577:/ s/PATTERN/REPLACEMENT/' /etc/shadowas 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.

author: poot36
author_rank: Frequent Contributor
timestamp: August 01, 2024, 02:41:41 am
content: 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.