Is it normal for auditors to require all company passwords?

Question

My company is currently engaged in a security audit framed as a pentest. They've requested all admin passwords for every one of our services and all source code of our software. They want logins for Google Apps, credit card processors, GitHub, DigitalOcean, SSH credentials, database access, and much more. Note, we've never signed a single NDA (but have been provided a statement of work) and I'm very reluctant to provide this info to them because of this.

Is this normal for a pentest? I assumed it would mostly be black box. How should I proceed?

"UPDATE* We now have an NDA. The contract does, however, say that we can't hold them liable for anything. Still not sure if this is the right move to continue with them. In my experience, their requests aren't normal even in white box audits, and their statement of work reads in a way that doesn't make it clear if this is a white box or black box audit.

Closely related: [Our security auditor is an idiot. How do I give him the information he wants?](https://serverfault.com/questions/293217/our-security-auditor-is-an-idiot-how-do-i-give-him-the-information-he-wants) — Jeff, Oct 25 '17 at 17:50
Related: https://security.stackexchange.com/questions/147125/network-administrator-knowing-all-user-passwords — schroeder, Oct 25 '17 at 19:03
Hey, I want to audit your company: please send me all your admin passwords. Just edit your question to list them all .... — schroeder, Oct 25 '17 at 19:05
Wait, what? You've never signed an NDA with that security company? Back the heck off right now and get that NDA signed before ever moving forward. Sounds to me like it's a fake company masquerading as a real one, to see if they can get any information from you. If this is a real legitimate company, then the auditor is trying to see if you're dumb enough to provide that information. If you provide even a little bit of it, you've failed the audit. However, this is incredibly unprofessional and should never happen. — Mark Buffalo, Oct 25 '17 at 20:32
I've been a pentester for five years. We don't touch a damn thing until we've got an agreed scope, timeframe, signed contract, and NDA in place. These formalities protect **both parties** and nobody should hand over any data or touch any systems until they are properly completed. Anyone who requests this kind of information without legal agreements in place and absolute necessity of access is (at best) a massive technical and legal liability to themselves, their organisation, and yours. Stay the hell away from these cowboys. — Polynomial, Oct 26 '17 at 02:31
Our product was routinely pentested (each half year) by a reputable company, and every half year they requested credentials for something or the other. So every half year we send them a smiley, or a link to the end of the internet, or something simular. We always passed :) For us at least this was a normal part of the test, the objective being to see if our team was able to recognize social engineering. Your manager might be aware of this but not telling you for obvious reasons, as was the case with us. — Douwe, Oct 26 '17 at 11:27
**In case you've already given them credentials, treat it as if it's a real security breach**. If they're not a real company, this is what you should do; if they are, this is what they hope you'll do. — Prime, Oct 27 '17 at 13:54
If you give them passwords, they're not penetration testing anymore...they're just using passwords you gave them. — developerwjk, Oct 27 '17 at 21:07
We had pentesters from our parent company visit. We were told to cooperate fully. They wanted access to the systems and admin access. Fine. Then they grabbed the password files and flaunted them as "trophies". Their word, not ours. We failed because we were not supposed to give them the support we had been told to give them. — Tony Ennis, Oct 30 '17 at 02:12
No, but doing a dictionary crack on the encrypted passwords are to me okay. — peterh, Nov 01 '17 at 20:58
*We now have an NDA. The contract does, however, say that we can't hold them liable for anything* How could an NDA be a true NDA if they can't be hold liable for anything ? — Walfrat, Nov 02 '17 at 12:45
@Walfrat yeah, that's very worrying. OP, does that mean you guys are moving forward with this company? — , Nov 03 '17 at 19:13

Conor Mancone · Accepted Answer · 2017-10-26T12:14:07.507

438

Is this normal for a pentest?

Absolutely not. Best case scenario: they are performing "social engineering" penetration testing and want to see if you can be pressured into fulfilling a very dangerous action. Middle-case scenario, they don't know how to do their job. Worst-case scenario they are only pretending to be an auditing company and fulfilling their request will result in an expensive breach.

In the case of a code-audit the company will obviously need access to source code. However I would expect a company who provides such services to already understand the sensitivity of such a need and have lots of forms for you to sign, and to offer to work in a strictly controlled environment. A reputable security company is going to be concerned not just with protecting you (because it is their job) but also with protecting themselves from untrustworthy clients (Our source code got leaked right after we hired you: we're suing!!!!). All this to say: any reputable security company that doesn't have you sign lots of contracts before going to work is not a reputable security company.

I can't imagine any circumstances in which handing over access to any of those things would be a good idea.

Edit RE: hidden contracts

A few have suggested that the company might have simply not told the OP about any relevant contracts/agreements/NDAs. I suppose this is possible, but I want to clarify that the lack of a contract isn't the only red flag that I see.

As someone who has built e-commerce sites and business software that has required integration with many CC Processors, I see absolutely no benefit to giving someone else access to your CC Processor. At that point in time they are no longer penetration testing your systems: they are penetration testing someone else's systems that you happen to use. Indeed, giving out access credentials in such a way likely violates the terms of service that you signed when you started using your CC Processor (not to mention the other systems they are requesting access to). So unless you have permission from your CC Processor to hand your credentials to a security auditing company (hint: they would never give you permission), giving them that access is a huge liability.

Many others here have done a great job articulating the differences between white-box and black-box testing. It is certainly true that the more access you give security auditors, the more effectively they can do their jobs. However, increased access comes with increases costs: both because they charge more for a more thorough vetting, and also increased costs in terms of increased liability and increased trust you have to extend to this company and their employees. You are talking about freely giving them complete control over all of your companies systems. I can't imagine any circumstances under which I would agree to that.

edited Oct 26 '17 at 12:14

answered Oct 25 '17 at 17:41

Conor Mancone

30,380
13
92
98

69

Completely agree. At best, I'm hoping it's a clumsy way to prove a point about social engineering. But even then, I would not do business with such a company. any reputable firm will have a contract, and an NDA, and various assurances to protect both you and them before starting an engagement like this. – JesseM Oct 25 '17 at 17:54
6

Good answer. OP may also have obligations to his other service providers *not* to share his password with other parties. That being said, it *may* be acceptable to create a new user account specifically for the pen testers, with their own password that they would manage, with limited permissions, on a case by case basis. – John Wu Oct 25 '17 at 20:09
2

@jesseM One remaining possibility is that contracts and NDA's are signed and the OP doesn't know about it. We have had situations where we would be doing pen testing that was done without the knowledge or with different kinds of limited knowledge of the participants. (I.e. only the CEO, CSO and CIO would know about it. It is very tricky to do this right and there need to be very good escalation processes in the organization though, otherwise you risk a lot of trouble when people don't react correctly and things stop working.) – DRF Oct 26 '17 at 11:06
1

@DRF even in the context of the OP not knowing about contracts, these requests are unreasonable. Access to their CC Processor? I see no reason why a security auditor would need that. It is a huge liability for both parties. Even if you are trying to check that they are following best-practices in CC processing, you don't need access to their CC Processor to do that, and requesting access is a *clear* violation of best practices. They are asking for too many highly sensitive items for this to be anything other than bad. – Conor Mancone Oct 26 '17 at 11:24
1

@ConorMancone Oh they certainly are unreasonably but might be part of a "normal" social pentest. To me it seems a bad way to test it. Most people will buck if you want this much. The smart way is want just a few things that are much more believable. – DRF Oct 26 '17 at 12:51
@DRF a social engineering penetration test is certainly the most charitable explanation, but it is definitely a bad way to do it. As you say, it makes it more obvious. Moreover, I would choose less critical services: NDA or not the last thing I want is someone sending me the credentials to their CC Processor. – Conor Mancone Oct 26 '17 at 13:09
@ConorMancone, without actually knowing if there is a contract and what such a contract might specify about what is in the scope of the test, we can't say if the request is valid or not. Perhaps the entity that engaged the security company specified they should try to access those pieces of information from employees. I agree with DRF that this sounds like a club handed approach to it, but we also don't know if the OP is representing the requests accurately. Maybe these were separate requests over time that the OP finally clued into that maybe he shouldn't be providing? We just don't know. – YLearn Oct 26 '17 at 19:44
To add to your second from last sentence; it's uncommon for one person in any large turnover company to have access to all the keys to the kingdom simultaneously without oversight from other higher ups. Partly due to the security concerns, but primarily because no one really ever needs everything at once. – Dom Oct 30 '17 at 17:15
I had one security audit where they checked a variety of services whether they were securely set up. The only thing that came out of it was a misconfigured dev Google developer application which could've theoretically used against us. Anyway though, that was done by a person who came to sit in our office and a colleague of mine would log in for him. I can however *imagine* (not saying it's a good thing) a remote company doing this by asking for passwords. – David Mulder Nov 02 '17 at 14:36
2

@DavidMulder That is actually a very valuable service: for comparison, it is amusing to google "another amazon aws leak" to see all the instance of people leaking critical information because of poorly configured hosting configurations. That being said, I don't think handing over passwords is the way to fix that one. If it came down to it I think it would be better to let them remotely connect to an office computer and watch everything they do. It would be a more valuable learning experience like that anyway. – Conor Mancone Nov 02 '17 at 14:57
Frankly, if this is an attempt to demonstrate the danger of social engineering it's still really questionable, pentests and audits aren't user training. Asking an informed party for credentials isn't social engineering. – Kaithar Nov 03 '17 at 16:45

Arminius · Answer 2 · 2017-10-26T03:15:25.100

How should I proceed?

Don't proceed with them. The way they act is unprofessional. Pentests carry risks for both parties, and it doesn't seem they did anything to address them.

First, you should absolutely not hand anything over without a written contract (including an NDA). It's surprising they routinely do business like that. How do they know the exact scope? Under which terms do they get paid? Will they just clam they're "done" at some point or is there a timetable? Do you get a proper report? Who pays if they cause damage? Are they insured in case they lose your credentials to a third party? How will you know if a future breach is part of the test or an actual attack by someone else? Even if you trust them, these questions should certainly be answered before you kick off a pentest.

And it's not just you, they are putting themselves at risk. If you never clarified the scope, they might be attacking some of your systems without permission, with potential legal implications.

I assumed it would mostly be black box.

Both black and white box tests are common and each approach has its own advantages. But if the mode of testing never came up, it seems like there has never been a discussion about what should be achieved by conducting a pentest in the first place. A professional contractor would have assisted you with figuring out the right conditions and methods.

(One great first question to a potential contractor is asking them for a sample pentest report. It will give you an initial idea about how they work and what results you may expect.)

score 38 · Answer 3 · answered Oct 25 '17 at 21:11

Prior to any penetration test there should be a Scoping and Rules of Engagement document(s) that is signed by both parties. These documents should describe in detail what will be tested and what methods have been agreed upon by your company and the contractor. If you have not gone through this discussion with your contractor, discontinue the engagement and seek other professionals.

As a penetration tester, I have asked companies to provide accounts or laptops that they would provision a normal user. This allows to test from a malicious employee perspective. However, this is all agreed upon prior to the test in the Scoping and Rules of Engagement.

Just my 2cents.

score 25 · Answer 4 · answered Oct 25 '17 at 21:42

25

NEVER EVER!!

We are doing a full pentest at my work. It was explicitly stated by the pentesters that they don't even need the login/password for anything. We stated that it was great since we'd never release anything to them before hand. There are 3 main types of pentests: white box, grey box, black box.

White Box is that you give them all information and they find problems with your software, network, etc.

Grey Box is that you give them some details of what you want them to pentest. We used that since they'd have no idea which external wireless ISP we were using. We told them to do an external test first so we gave them a few IPs and they easily broke in.

Black Box is that you provide them nothing and they have to find everything on their own. After that they can do their pentest on the external IPs. For internal testing, it is different. They will be inside your network running nmap and other intense scans on every target they come across. This is the most difficult, but the best in my opinion.

answered Oct 25 '17 at 21:42

rockower

391
2
11

1

"We told them to do an external test first so we gave them a few IPs and they **easily broke in**." -- Where you work at? – Daniel Oct 28 '17 at 14:37
7

@Daniel You mean, "What's your IP", don't you? :) – BenjiWiebe Oct 30 '17 at 14:10
@BenjiWiebe I see what you did there, but I wouldn't dare going down such shady paths. I asked for the company name to stay clear from them; I have no desire to penetrate anyone as it is against my nature. – Daniel Oct 30 '17 at 23:10
@Daniel breaking in is only the first step. Exploiting the holes found is another step. Try phishing your own company. Implement policies and enforce them. I work for State Government. – rockower Nov 01 '17 at 00:35
@Daniel "I have no desire to penetrate anyone as it is against my nature." I see what you did there – Bas Nov 01 '17 at 13:03

score 20 · Answer 5 · answered Oct 25 '17 at 23:00

My company is currently engaged in a security audit framed as a pentest.

and

Note, we've never signed a single NDA or other contract with them yet, and I'm very reluctant to provide this info to them because of this.

The use of "engaged" in this context implies a definition of "enter into a contract to do something." This leaves me wondering if the conflicting statements are accidental or if you are not the entity within your company that has engaged the security company.

If the latter, there may very well be contracts/agreements of which you were not made aware. This would not be unusual, as many of the penetration tests where I have been on the receiving end conceal the specific details of the test from employees so they don't take any "abnormal" actions to protect against the test(s).

If this is the case, then do with the request what you would do normally with such a request. Tell them "no" and if they push back ("but it's required for us to perform the penetration test") then run the request (in writing) up to your supervisor providing your concerns. If your supervisor tells you (in writing) to release this information, you should then be in the clear as they may have a better understanding of the test than you do. If your superiors are unclear run it further up the chain of command and/or push for them to request guidance from the entity that engaged the security company.

However, if you are the entity who has engaged the security company then I (like the other answers here) would have serious concerns. If you feel it may still be worth pursuing (or are concerned that they will make some sort of "breach of contract" claim), then I would suggest you use a means of evaluating if this is a social engineering test. For instance, you could generate a list of fake admin accounts and passwords. Provide this to them, say you are still working on the rest, and you will send it along as it is ready. Then see how they respond.

If it is just a social engineering test, all they need is to see proof of this type of information being leaked (which you can show later are faked accounts). A responsible security company shouldn't need any more of the requested information and should stop you from providing it ("Looking at what you provided, I think this should be sufficient to let us proceed; don't worry about the rest unless it turns out we really do need it"). If they don't stop any further information, disengage immediately.

More information could only cast suspicion on any penetrations they perform from that point forward (i.e. it is easy to penetrate a system if you have admin access) and/or expose them to potential intellectual property lawsuits (i.e. leaked source code, etc).

Fake accounts and passwords are an excellent suggestion. They would be even more effective if they were accounts that led them into a honeypot, so you could monitor them for abuse. — John Deters, Oct 26 '17 at 15:55

score 8 · Answer 6 · answered Nov 02 '17 at 02:24

Coming at the question from a slightly different angle:

Are you the CEO or CTO?

No? Then do not give the auditors any passwords. Ever.

Put an information package together and forward it up the chain to your IT Manager, CTO, CEO, or whatever. To put it bluntly, it's their job to make those sorts of decisions (and to take the consequences), not yours.

If your boss says, "No, you send it." then answer, "As an employee, I'm not comfortable releasing such dangerous information to a third-party."

If you are, in fact, the CTO, then take advice from the answers above.

You might also add in writing that your *professional advice* is not to release the credentials, but that you respect that it is the CEO's decision. — o.m., Nov 04 '17 at 09:09

score 3 · Answer 7 · answered Oct 26 '17 at 12:51

Validate your assumptions.

If this is supposed to be a black box test, they should not get or require any passwords whatsoever.

If this is supposed to be a config review, or white box tests, some passwords should be handed over. The correct procedure is to change them before the test to something unique (random string), and then change them again after the test.

Check with your management and explicitly ask if proper NDAs and contracts have been signed.

Is this normal for a pentest?

The scenario as you described it is unusual, but not entirely implausible. It all depends on what exactly was agreed for the test scope and activities.

I assumed it would mostly be black box. How should I proceed?

Check with the manager responsible for signing this pentesting team. Your CISO or CSO or IT manager or whoever it may be. Voice your concerns and ask if this approach was agreed upon.

Giving Passwords / Source Code

Personally, I would not give any passwords or source code to anyone without a proper NDA signed. I would also never, ever, give them the actual passwords. In all the pentests I've been involved in, on both sides as both customer and project manager (I'm not a pentester, but I've managed pentesters) there were always user accounts created for the pentest and passwords changed. We even recommend to our customers to change them after the test is done (some don't, that's always a sad finding for the next report).

Password Strength

As for what some answers wrote about "evaluating password strength" - that's a load of hogwash. Yes, there is a "best practice" on good passwords, which some guy pulled out of thin air some decades ago and is terribly sorry for today. All the math on the subject is full of holes and unverified assumptions and a lot of password policies actually reduce the search space instead of enlarging it. The only real test for password strength has two parts: One, get the top 10,000 or so passwords from one of the 20 or so lists that float around the Internet and use that as a blacklist. Two, run the same cracking software that bad guys use (most of them are Free Software) on your password hashes. If your instance of John cracks it, so will theirs.

most of this is covered by the other answers - your password strength section is based on a faulty assumption; if the same admin password is used in multiple places, then that is not a strong password, for instance - and yes, automated password audits do exactly what you outlined, so I'm not sure where you are going with this 'counter argument' — schroeder, Oct 26 '17 at 13:05

Is it normal for auditors to require all company passwords?

7 Answers7

Giving Passwords / Source Code

Password Strength

Linked