Hacker’s Ethics – My Changing Perspective

Personal Ethics is not something that changes too dramatically over time. The foundation of our ethics is typically laid as children with small changes throughout our life. Untypical, then, was a major shift in my personal ethics as it relates to “security research”, aka hacking.

Intro

Has your spouse ever told you something a million times, but it didn’t make sense to you? My wife, for years, has been questioning my shady security research practices. Over the last few weeks, starting with John Strand’s talk at Derbycon 2017, I’ve been hearing a recurring theme. This theme has probably been there all along, but I wasn’t listening to it, or to my wife. The theme is, “Did you hack into that? Yes? Did you have permission?”

The line

Ethically (and legally for that matter), there’s a line between vulnerability hunter and unauthorized computer access. That line, and even the definitions of terms, is different to everyone. For those of us that literally seem to have vulnerabilities just fall right out in front of us, that line is a bit over towards the dark side since easy equates to it’s okay in our minds.

Like many honest, well meaning security researchers, I’ve never received any personal gain from doing security research and reporting vulnerabilities; not a dime. People like me truly feel that by finding these things before the bad guy does, the good guy will be safer. It’s that feeling of discovery, followed by helping make the good guys a little safer, that drives us.

My Ethics – Pre 08 OCT 2017

Starting in 2015, soon after leaving the NSA, I became super addicted to security research and started spending a lot of time searching for vulnerabilities and creating/testing attack vectors. In some cases, I would make contact with the potential victim myself, but with many I would report my findings through federal law enforcement.

As an example, one common scenario I exploited frequently was “discovery and verification of a password”. Password compromise is, unfortunately, still a very common attack vector in the absence of, and sometimes in spite of, multi-factor authentication. For those that come across passwords often on paste sites, malware repos, popping bad guy infrastructure, in good guy code, etc., you know this information could give a true evil person access and allow them to do some serious damage. But, the vast majority, depending on source, are stale, or otherwise unusable passwords. There’s only one way I am aware of to know if the password you discovered is valid. Seriously, do you know of another way besides trying it?

I asked a few of my contacts in federal LE, multiple times in fact, questions like, “If I obtain a password (from wherever), is it going to far to “verify” that password?” and “Is verifying a vulnerability, safely, acceptable?” The general, combined guidance, was as follows:

• Do not ever ask for money.
• Do not withhold information or details to LE when reporting.
• Do not modify, delete or add data or software of any kind.
• Do not exfil beyond what is needed to prove vuln/access (i.e. a screenshot is typically the limit).
• Do not install backdoors or future access after reporting.

With that feedback, I went to town. I began hacking into bad guy infrastructure, typically associated with malware, on a daily basis, and often multiple times per day. I became very good at it, discovered multiple vulnerabilities in well known malware infrastructure, and wrote dozens of automated exploits against bad guy infrastructure. Once I popped a bad guy server, I’d dump everything they had stolen from their victims: passwords, SSH keys, credit card numbers, bitcoins, etc. In addition to sharing this information with LE, I’d frequently provide this information to various intel channels of which I am a member.

I didn’t stop there, though. I was taking it a step further. I’d extract HVTs (high valued targets) from the password dumps, see what bad guy had access to, if anything, and then report my findings to LE. Some of the bigger HVTs that I verified access to include:

• taking over malware, running on a state representatives business website
• an FTP server in the US legislative branch
• POS systems for a nationwide furniture store
• a federal government database containing full PII (DoB, SSN, address, etc.) of over 10 million Americans
• admin control of an entire county 911 emergency services network and the endpoints
• a customer DB for a satellite based service provider
• all tracking data for a global shipping company
• an endpoint in a safe manufacturer’s production network
• all voter registration records for a particular state
• payroll, A/V systems, merchant accounts, email accounts, etc. of several large churches
• and many more

Another common thing I would do is connect to an open wifi and run a port scan at every store, restaurant and business I was at. Examples of things I found doing that include:

• access to POS systems for at least a dozen restaurants and stores
• gained admin on the network gear at no fewer than 8 business/restaurants would could have allowed me to MiTM all traffic
• enumeration of a corporate network against AD at a big box store
• took over the energy management system at a zoo
• and many more I’ve forgotten about

There are so many other categories of examples I could give, but you get the idea. I was hacking so often, I’d be breaking out of kiosk mode on a touch screen at a theme park while I was there with my family. I was an addict (still am, to be transparent).

Side question (comment below). For those that do/have done this sort of stuff, and then it makes the news, does the news always get the details 100% wrong? If I “know” they are wrong about these “breaches” that I have full perspective on, what would make me think anything else they say it true.

Kevin Johnson

After Derbycon, I spent a considerable amount of time researching the ethics of vulnerability research. On 08 OCT, 3.5 years after he gave it, I watched his talk at https://www.youtube.com/watch?v=skYeNYeVY58.

According to Kevin, even dropping a single quote into a form field is going too far. That one hit me hard, as it is something I do every time I create a new account or leverage a new service for something. I have even used this, during interviews with potential employers, as an example of security research I perform.

Kevin’s talk transformed my personal ethics as it relates to security research. He was the straw that broke the unauthorized-hacking-is-wrong back for me.

My Ethics – Post 08 OCT 2017

I’m not going to lie, I’m having serious struggles right now knowing where to draw that line. Based on the wisdom from Kevin Johnson, and others, I’ve got this far:

• With permission, anything is fair game. My struggle is if LE, for example, gave me specific targeting permission, is that fair game as well? I’m going with yes.
• Working within the restraints of a company’s bug bounty program is okay.
• Modifying/deleting/adding anything on someone else’s system is wrong.
• Verifying passwords is going too far. This is a hard one, but I am not going to do this anymore.
• Dropping a tick mark into a form to see if it barfs seems fine to me. Note: this goes against Kevin’s ethics.
• Taking a SQLi attack to the next step and trying a few things to verify a vuln seems reasonable, but I’m going to make this a default no.
• If I’m able to create an account (or multiple) on a provider’s service and then “hack” into it/them, that seems safe. The only data I would be gaining access to is my own.
• Attacking local installs of software in my VMs, within the EULA, is acceptable. Even outside the EULA, I’m going to get away with as much as possible. Most EULAs take away all customer rights and should be made unenforceable in the courts anyway, IMO.
• Port scanning: A large number of ports against one target will be off limits. But, scanning the whole Internet for a single port, or small number, seems fine.
• DoS has always been against my ethics.
• Vendor disclosure/notifications: 7 days when it is an attack vector, 30 days for actual vulnerabilities (if vendor could push a patch). I will give more time, within reason, when a vendor requests it. In either case, the lack of response will be treated as acceptance (ex. https://penconsultants.com/blog/exploits/exposing-tanium-a-hackers-paradise/).
• Attack vectors leveraging product “features” (Macros/DDE, HTML5, DLL functions, etc.) or exploiting a class of products when it affects “all” products (ex. AV sandboxes) will be released immediately to the public with no vendor notification.
• Hacking back: the standard rules above do not apply. Aggressiveness and techniques depend on the infrastructure. Examples: compromised good guy servers, bad guy on good guy service provider, all bad guy infrastructure. Regardless, I will still have a measured level of response.
• More to come

The Implications

I have had the opportunity to discover hundreds of vulnerabilities and weaknesses in the last several years, and in turn, the privilege to help hundreds of businesses mitigate gaps in their systems. Because of my overwhelming desire to see the good guys win and bad guys lose, the implications of my new self imposed limitations have me feeling somewhat helpless.

I firmly believe that this ethics change will, in the end, cause more harm than good for the industry as a whole. There are many more bad guys in the world than good guys authorized by company X.

Thanks to Kevin Johnson @secureideas, Mano @manopaul, and @HackFormers for the presentation on the ethics of security research.

What are your thoughts? Do you draw the line somewhere different?