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.

Answer 1

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.

Answer 2

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.)

Answer 3

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.

Answer 4

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.

Answer 5

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).

Answer 6

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.

Answer 7

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.