A security auditor for our servers has demanded the following within two weeks:
- A list of current usernames and plain-text passwords for all user accounts on all servers
- A list of all password changes for the past six months, again in plain-text
- A list of "every file added to the server from remote devices" in the past six months
- The public and private keys of any SSH keys
- An email sent to him every time a user changes their password, containing the plain text password
We're running Red Hat Linux 5/6 and CentOS 5 boxes with LDAP authentication.
As far as I'm aware, everything on that list is either impossible or incredibly difficult to get, but if I don't provide this information we face losing access to our payments platform and losing income during a transition period as we move to a new service. Any suggestions for how I can solve or fake this information?
The only way I can think to get all the plain text passwords, is to get everyone to reset their password and make a note of what they set it to. That doesn't solve the problem of the past six months of password changes, because I can't retroactively log that sort of stuff, the same goes for logging all the remote files.
Getting all of the public and private SSH keys is possible (though annoying), since we have just a few users and computers. Unless I've missed an easier way to do this?
I have explained to him many times that the things he's asking for are impossible. In response to my concerns, he responded with the following email:
I have over 10 years experience in security auditing and a full understanding of the redhat security methods, so I suggest you check your facts about what is and isn't possible. You say no company could possibly have this information but I have performed hundreds of audits where this information has been readily available. All [generic credit card processing provider] clients are required to conform with our new security policies and this audit is intended to ensure those policies have been implemented* correctly.
*The "new security policies" were introduced two weeks before our audit, and the six months historical logging was not required before the policy changes.
In short, I need;
- A way to "fake" six months worth of password changes and make it look valid
- A way to "fake" six months of inbound file transfers
- An easy way to collect all the SSH public and private keys being used
If we fail the security audit we lose access to our card processing platform (a critical part of our system) and it would take a good two weeks to move somewhere else. How screwed am I?
Update 1 (Sat 23rd)
Thanks for all your responses, It gives me great relief to know this isn't standard practice.
I'm currently planning out my email response to him explaining the situation. As many of you pointed out, we have to comply with PCI which explicitly states we shouldn't have any way to access plain-text passwords. I'll post the email when I've finished writing it. Unfortunately I don't think he's just testing us; these things are in the company's official security policy now. I have, however, set the wheels in motion to move away from them and onto PayPal for the time being.
Update 2 (Sat 23rd)
This is the email I've drafted out, any suggestions for stuff to add/remove/change?
Hi [name],
Unfortunately there is no way for us to provide you with some of the information requested, mainly plain-text passwords, password history, SSH keys and remote file logs. Not only are these things technically impossible, but also being able to provide this information would be both a against PCI Standards, and a breach of the data protection act.
To quote the PCI requirements,8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography.
I can provide you with a list of usernames and hashed passwords used on our system, copies of the SSH public keys and authorized hosts file (This will give you enough information to determine the number of unique users can connect to our servers, and the encryption methods used), information about our password security requirements and our LDAP server but this information may not be taken off site. I strongly suggest you review your audit requirements as there is currently no way for us to pass this audit while remaining in compliance of PCI and the Data Protection act.
Regards,
[me]
I will be CC'ing in the company's CTO and our account manager, and I'm hoping the CTO can confirm this information is not available. I will also be contacting the PCI Security Standards Council to explain what he's requiring from us.
Update 3 (26th)
Here are some emails we exchanged;
RE: my first email;
As explained, this information should be easily available on any well maintained system to any competent administrator. Your failure to be able to provide this information leads me to believe you are aware of security flaws in your system and are not prepared to reveal them. Our requests line up with the PCI guidelines and both can be met. Strong cryptography only means the passwords must be encrypted while the user is inputting them but then they should be moved to a recoverable format for later use.
I see no data protection issues for these requests, data protection only applies to consumers not businesses so there should be no issues with this information.
Just, what, I, can't, even...
"Strong cryptography only means the passwords must be encrypted while the user is inputting them but then they should be moved to a recoverable format for later use."
I'm going to frame that and put it on my wall.
I got fed up being diplomatic and directed him to this thread to show him the response I got:
Providing this information DIRECTLY contradicts several requirements of the PCI guidelines. The section I quoted even says
storage(Implying to where we store the data on the disk). I started a discussion on ServerFault.com (An on-line community for sys-admin professionals) which has created a huge response, all suggesting this information cannot be provided. Feel free to read through yourselfhttps://serverfault.com/questions/293217/
We have finished moving over our system to a new platform and will be cancelling our account with you within the next day or so but I want you to realize how ridiculous these requests are, and no company correctly implementing the PCI guidelines will, or should, be able to provide this information. I strongly suggest you re-think your security requirements as none of your customers should be able to conform to this.
(I'd actually forgotten I'd called him an idiot in the title, but as mentioned we'd already moved away from their platform so no real loss.)
And in his response, he states that apparently none of you know what you're talking about:
I read in detail through those responses and your original post, the responders all need to get their facts right. I have been in this industry longer than anyone on that site, getting a list of user account passwords is incredibly basic, it should be one of the first things you do when learning how to secure your system and is essential to the operation of any secure server. If you genuinely lack the skills to do something this simple I'm going to assume you do not have PCI installed on your servers as being able to recover this information is a basic requirement of the software. When dealing with something such as security you should not be asking these questions on a public forum if you have no basic knowledge of how it works.
I would also like to suggest that any attempt to reveal me, or [company name] will be considered libel and appropriate legal action will be taken
Key idiotic points if you missed them:
- He's been a security auditor longer than anyone else on here has (He's either guessing, or stalking you)
- Being able to get a list of passwords on a UNIX system is 'basic'
- PCI is now software
- People shouldn't use forums when they're not sure of security
- Posing factual information (to which I have email proof) online is libel
Excellent.
PCI SSC have responded and are investigating him and the company. Our software has now moved onto PayPal so we know it's safe. I'm going to wait for PCI to get back to me first but I'm getting a little worried that they might have been using these security practices internally. If so, I think it is a major concern for us as all our card processing ran through them. If they were doing this internally I think the only responsible thing to do would be to inform our customers.
I'm hoping when PCI realize how bad it is they will investigate the entire company and system but I'm not sure.
So now we've moved away from their platform, and assuming it will be at least a few days before PCI get back to me, any inventive suggestions for how to troll him a bit? =)
Once I've got clearance from my legal guy (I highly doubt any of this is actually libel but I wanted to double check) I'll publish the company name, his name and email, and if you wish you can contact him and explain why you don't understand the basics of Linux security like how to get a list of all the LDAP users passwords.
Little update:
My "legal guy" has suggested revealing the company would probably cause more problems than needed. I can say though, this is not a major provider, they have less 100 clients using this service. We originally started using them when the site was tiny and running on a little VPS, and we didn't want to go through all the effort of getting PCI (We used to redirect to their frontend, like PayPal Standard). But when we moved to directly processing cards (including getting PCI, and common sense), the devs decided to keep using the same company just a different API. The company is based in the Birmingham, UK area so I'd highly doubt anyone here will be affected.
First, DON'T capitulate. He is not only an idiot but DANGEROUSLY wrong. In fact, releasing this information would violate the PCI standard (which is what I'm assuming the audit is for since it's a payment processor) along with every other standard out there and just plain common sense. It would also expose your company to all sorts of liabilities.
The next thing I would do is send an email to your boss saying he needs to get corporate counsel involved to determine the legal exposure the company would be facing by proceeding with this action.
This last bit is up to you, but I would contact VISA with this information and get his PCI auditor status pulled.
As someone who has been through the audit procedure with Price Waterhouse Coopers for a classified government contract, I can assure you, this is totally out of the question and this guy is insane.
When PwC wanted to check our password strength they:
If I had even hinted that I could show them what the users passwords were over the last 6 months, they would have shut us out of the contract immediately.
If it were possible to provide these requirements, you would instantly fail every single audit worth having.
Update: Your response email looks good. Far more professional than anything I would have written.
Honestly, it sounds like this guy (the auditor) is setting you up. If you give him the information he's asking for, you've just proven to him that you can be socially engineered to give up critical internal information. Fail.
I've just spotted you're in the UK, which means that what he's asking you to do is to break the law (the Data Protection Act in fact). I'm in the UK too, work for a large heavily-audited company and know the law and common practices around this area. I'm also a very nasty piece of work who will happily curb-stamp this guy for you if you like just for the fun of it, let me know if you'd like help ok.
You are being socially engineered. Either its to 'test you' or its a hacker posing as a auditor to get some very useful data.
I am seriously concerned about OPs lack of ethical problem solving skills and the server fault community ignoring this blatant breach of ethical conduct.
Let me be clear on two points:
It is not your job to falsify records. It is your job to make sure that any necessary records are available, accurate, and secure.
The community here at Server Fault must treat these kinds of questions as the stackoverflow site treats "homework" questions. You can not address these issues with only a technical response or ignore the violation of ethical responsibility.
Seeing so many high-rep users replies here in this thread and no mention of the ethical implications of the question saddens me.
I would encourage everyone to read the SAGE System Administrators' Code of Ethics.
BTW, your security auditor is an idiot, but that does not mean you need to feel pressure to be unethical in your work.
Edit: Your updates are priceless. Keep your head down, your powder dry, and don't take (or give) any wooden nickels.
You can't give him what you want, and attempts to "fake" it are likely to come back to bite you in the arse (possibly in legal ways). You either need to appeal up the chain of command (it's possible this auditor's gone rogue, although security audits are notoriously idiotic -- ask me about the auditor that wanted to be able to access an AS/400 via SMB), or get the hell out from underneath these onorous requirements.
They're not even good security -- a list of all plaintext passwords is an incredibly dangerous thing to ever produce, regardless of the methods used to safeguard them, and I'll bet this bloke will want them e-mailed in plain-text. (I'm sure you know this already, I just have to vent a little).
For shits and giggles, ask him directly how to execute his requirements -- admit you don't know how, and would like to leverage his experience. Once you're out and gone, a response to his "I have over 10 years experience in security auditing" would be "no, you have 5 minutes of experience repeated hundreds of times".
No auditor should fail you if they find a historical problem that you've now fixed. In fact, that's evidence of good behaviour. With that in mind, I suggest two things:
a) Do not lie or make stuff up. b) Read your policies.
The key statement for me is this one:
I bet that there's a statement in those policies saying passwords cannot be written down and cannot be passed to anyone other than the user. If there is, then apply those policies to his requests. I suggest handling it like this:
Show him a list of usernames, but do not allow them to be taken away. Explain that giving plain text passwords is a) impossible as it's one-way, and b) against policy, which he is auditing you against, so therefore you won't obey.
Explain that this was not historically available. Give him a list of recent password change times to show that this is now being done. Explain, as above, that passwords will not be provided.
Explain what is and is not being logged. Provide what you can. Do not provide anything confidential, and explain by policy why not. Ask if your logging needs to be improved.
Look at your key management policy. It should state that private keys are not allowed out of their container and have strict conditions of access. Apply that policy, and do not allow access. Public keys are happily public and can be shared.
Just say no. If you have a local secure log server, allow him to see that this is being logged in situ.
Basically, and I'm sorry to say this, but you have to play hardball with this guy. Follow your policy exactly, do not deviate. Do not lie. And if he fails you for anything that is not in policy, complain to his seniors at the company who sent him. Collect a paper trail of all this to prove that you have been reasonable. If you break your policy you are at his mercy. If you follow them to the letter, he will end up being sacked.
Yes, the auditor is an idiot. However, as you know, sometimes idiots are placed in positions of power. This is one of those cases.
The information he requested has zero bearing on the current security of the system. Explain to the auditor that you're using LDAP for authentication and that the passwords are stored using a one-way hash. Short of doing a brute-force script against the password hashes (which could take weeks (or years), you will not be able to provide the passwords.
Likewise the remote files - I'd like to hear, perchance, how he thinks you ought to be able differentiate between files created directly on the server and a file that is SCPed to the server.
As @womble said, don't fake anything. That will do no good. Either ditch this audit and fine another broker, or find a way to convince this "professional" that his cheese has slid off of his cracker.
Have your "security auditor" point to any text from any of these documents that have his requirements and watch as he struggles to come up with an excuse and eventually excuses himself to never be heard from again.