ACME.inc: The Ethical Calls a Pen Tester Makes Mid-Engagement
Heads up: ACME.inc is a fictional company, and this is a simulated scenario I wrote for an ethics course. The engagement, the employees, and the findings are invented. The vulnerability at the center of it, CVE-2024-6387, is real, as are the ethical considerations and responsibilities of penetration testing work.
Day three of a two-week penetration test, and you've just found a flaw that could hand an attacker root on the client's server. Do you keep testing, or do you pick up the phone?
Here's the setup. I've been hired by ACME.inc, a manufacturer of fine technological widgets, to perform an external and internal penetration test. The goal is to identify vulnerabilities, report my findings along with steps to mitigate the risk, and improve the company's overall security posture. During testing I discover several critical vulnerabilities that a threat actor could exploit to reach sensitive customer data. I also find employees using weak passwords and not following security protocols.
An exercise in "ethical hacking" puts a lot of ethical considerations in front of the operator. After all, the ability to break security and abuse systems is a great responsibility, and one an ethical hacker shouldn't take lightly. The very name of the trade, ethical hacking, implies the practitioner uses their skills for the good of society, as opposed to the counterparts who hack for unethical purposes.
Stop when you find something critical
One of the findings is CVE-2024-6387, a flaw in the company's OpenSSH server. It's known as regreSSHion, and Qualys disclosed it in July 2024. In short: a race condition in sshd that can let an unauthenticated remote attacker run code as root on glibc-based Linux systems, affecting OpenSSH versions from 8.5p1 up to (but not including) 9.8p1. It's rated 8.1 (High) on CVSS rather than Critical, because it's hard to pull off. Qualys's lab exploit took around 10,000 attempts, or roughly six to eight hours on average against a 32-bit test system. Hard isn't impossible, though, and a root shell on a server holding customer data isn't something you sit on.
So I stop immediately and inform the system administrator and the CISO, then suggest a mitigation strategy. The real fix is upgrading to OpenSSH 9.8p1 or a patched build from the distro. If they can't patch right away, Qualys's stopgap is setting LoginGraceTime to 0, which closes the hole but makes the server easier to knock over with a denial of service.
It would be unethical to continue the test once a vulnerability that severe turns up where sensitive customer or corporate data is concerned. If a real attacker got in while my test was still running, it would be a very bad look. Furthermore, I would not want to deliver a report after a two-week engagement saying that on day three I discovered a potentially massive security risk and failed to disclose it right away. (This is why a lot of rules of engagement spell out exactly this case ahead of time: stop and notify on a critical finding.)
Stay in scope
Setting aside a litany of liability concerns, accessing sensitive customer data can be an ethically dubious position all by itself. Generally, accessing specific data is unnecessary. Diving into the accounting folders to view personally identifying information has no relevance when showing access to the top-level folders, or to the root/admin account, demonstrates control just fine.
It's important to stay within scope and only break what has to be broken to prove the point. Going beyond scope, or doing it to massage your ego by showing off, is not only unethical but highly unprofessional.
Don't name and shame (with one exception)
I don't think it's necessary or ethical for a penetration tester to single out employees for simple mistakes. Employees with bad passwords, or who fall for social engineering, shouldn't be punished, so I don't disclose the names or accounts of anyone who made a mistake. Everyone makes mistakes or skips protocols. If users aren't making good decisions, it's up to the company to enforce password policy, and that can be done electronically. There's no need to beat Cheryl in logistics over the head for using "Fall2024" as her password.
The better way to handle mistakes is to assume the people who got caught represent a much larger percentage of employees who are also getting it wrong. That points toward security education and training for the entire workforce.
That said, there's a difference between simple mistakes and willful negligence, malfeasance, and mischief. Employees caught intentionally circumventing security measures, or acting maliciously, aren't acting ethically and should be exposed.
Talk about ethics before the engagement, not during it
Communication is key to resolving ethical dilemmas before they come up. Before the engagement, I sat down with ACME.inc's CISO and system administrator and laid out my positions: I'll disclose critical vulnerabilities as soon as I find them, I won't identify individual employees who make simple mistakes, and I will absolutely disclose malicious behavior and the people responsible. ACME.inc's management asked to limit the scope of the test so personally identifiable information couldn't be exposed to my team.
With everyone's stance understood and agreed on up front, the odds of running afoul of anyone's professional or personal ethics dropped a lot. Failing to listen, communicate, and address concerns before an engagement can do more harm than good.
The report
The report of findings had three parts: a high-level, non-technical summary, a technical summary with key screenshots and explanations in descending order of severity, and a mitigation strategy report.
During the engagement, several employees fell for our email phishing campaign, which we followed up with successful social engineering attempts by phone. There was also a lack of administrative password policy enforcement, which led to a big chunk of the workforce using weak passwords. Again, rather than single out individuals, I recommended training for the entire workforce on spotting and resisting phishing, plus policy changes for how employees handle phone calls from unknown people asking for names and email addresses.
Takeaway
Ethical decision-making in this job is an almost constant reality. There are ethical considerations before, during, and after an engagement, and a professional has to know their boundaries, both personal and professional, and be ready to communicate and act on them. It's also our duty to give competent service while respecting the client's own ethical concerns.
It takes a special person to study how to break the rules and still stay in control. There's a fine line between the white-hat and the black-hat hacker, and a personal code of ethics is what draws it. After all, the only thing separating an ethical hacker from a hacker is the "ethical" part.