largely accessible encrypted passwords

Question

Suppose your university has a centralized ldap server used to authenticate all students, teachers and staff for all services provided by the university (email, exams, taxes...) Suppose that in the computer lab it is possible for every authenticated user to issue an ldapsearch and get all the data of all people in the university: students, teachers, technicians... Suppose the data contains also the fields: sambaLMPassword and sambaNTPassword with the encrypted password of each person.

Now suppose you are a little worried (you are a teacher and think that maybe the students could crack the system and stole passwords) so you speak with the technical staff of the university and they say something along the following lines:

• we know this since a long time, but the password hashes are needed by some old service we need to keep;
• anyway the passwords are encrypted and it is illegal to brute force them;
• and our students are not so smart to understand that they can obtain and decrypt them;
• however, please, keep this secret.

Would you be reassured by the answers? What would you do next?

Answer 1

Educational institutions are often required to obtain and maintain compliance and certification in numerous cybersecurity standards. Maintaining a weak cipher suite or broken encryption may put them out of compliance, which could be uncovered on their next audit.

When I see "NT password" I get very worried-- Windows passwords can be cracked in about 13.6 seconds. A sambaNTPassword is just an MD4 hash, which is a hashing algorithm that is horribly broken and has been for well over a decade.

That being said, these systems should be under occasional audit and will eventually get caught and addressed if possible (or a waiver and other mitigations will need to be put in place, e.g. a second factor of authentication that protects administrator accounts). So if you choose not to do anything, it doesn't mean they won't fix it...eventually.

If they are purposefully concealing this vulnerability during compliance audits, this is not technically illegal, but they can lose their various certifications if they get caught, and open themselves up for civil liability if they get hacked.

As for this comment

and our students are not so smart to understand that they can obtain and decrypt them

^ Is a ridiculous statement from someone who is forgetting that the younger generation bypasses their elders by several orders of magnitude when it comes to things like this. This guy found vulnerabilities in the XBox at age five!!!! (He now works for Microsoft security)

however, please, keep this secret.

I would not agree to that, but be polite about it. You should be clear that you are not willing to lie to cover someone else's mistakes.

What would you do next?

Personally, I would treat this as a "teachable moment" (remember that you are still a student) and express that you would like to learn more. See if you can arrange a meeting with one of the university's cybersecurity compliance officers-- these are the folks that sign the forms that swear and affirm that they are maintaining compliance, and who regularly work with auditors. Once you bring it to his or her attention, you can safely say you did everything you could do, and it will be their job to take it from there.

Answer 2

I would do the same as you and create a new stackexchange account and not use my normal one. ;-)

I think it is important to find out, if the people you spoke to are unwilling to change this. (It sounds to me like this). Then I would check if there is an IT manager/boss, who I could speak to, maybe on a more abstract level.

You could also suggest to hire a security firm to run a small pen test. May suggest this to the IT manager, without pointing to this problem and then let the security firm find this issue in the pen test... (No need to shoot the messenger)

This is a difficult situation and it completely depends on who are the people you can talk to and what agenda they have.

Answer 3

IIRC the attributes sambaLMPassword and sambaNTPassword, although hashed, are actually just like clear-text credentials (shared secrets) because they are used for challenge-response authentication in SMB protocol (NTLM etc.).

There is not much your IT guys can do about the mere existence of these attributes except shutting down all the services relying on those Samba domain controller.

What they can do is limiting the visibility of these attributes to LDAP clients by granting read access only to the Samba domain controllers. E.g. for OpenLDAP this can be easily done with ACLs.