3

I'm currently doing security research on the dangers of using default or well known 'secrets' for applications.

To test how big of an issue this actually is, I decided to download local copies of the 'large' stack-exchange websites and wrote some scripts that went through the data to extract strings which match a specific pattern.

This yielded around 15k possible unique secrets so far (it's still running, as of writing, I don't have the strongest computer, I also did this for some few thousand files on GitHub, leading to even more results). Which leaves me with the following question:

How ethical is it to publish such a list on the internet, alongside a tool which lets you test (locally) if your application is prone to such an attack, using said wordlist?

I've seen lots of wordlists published online, there's even entire dedicated GitHub repositories to this. If I were to publish the wordlist, it wouldn't have any personal information attached to it, but I'm still not entirely sure how ethical it would be.

4

Lists of known-compromised secrets are very valuable to people who are trying to make systems more secure, especially for things like passwords or password-equivalent credentials. Consider Troy Hunt's excellent "Pwned Passwords" page, which is built using a massive corpus of compromised passwords (and you can download it, if you want to, and also download software to set up a password-check service that doesn't send any info at all to a third party).

In addition to helping users test their own secrets, systems like this are valuable for those who want to establish secure authentication systems, because such systems should reject credentials known to have been used elsewhere (and especially if they are known to have been exposed publicly). The latest NIST guidelines actually specifically suggest checking candidate secrets against ones known to be compromised, so having such lists of compromised secrets is essential to following the guidelines!

1

Great question. This is definitely a grey area. If the secrets don't have user names associated or other PII, you are probably ok.

Typically, you should notify the sites (or specific accounts/users) of the data leakage. Then, depending on which ethical disclosure system you use, they get a certain amount of time (six weeks is common) to remediate. After that amount of time it would probably be acceptable to release the secrets without any usernames/PII.

That said, there are so many things like this available (like rockyou.txt) because of the theft of accounts in huge hacks (yahoo, linkedin, ashley madison) that resulted in these creds floating around the "dark web" for so long they are almost considered public at some point. Also, if you hardcode a secret or password into github and it gets scraped... that's probably on the DEV, although I'd like to believe as Sec Pro's we'd try to notify them. That said I understand the struggle with the logistics of that.

So as I said this is a grey area. Most important thing: don't release something that can result in a malicious actor directly breeching someone's accounts. One of the major current attacks are lateral--using hacked accounts from one site to try and access a more important site (breaching linkedin and then using that to try and see if they have same creds on Bank of America, for example).

Here is more on the US ethical disclosure site on a subgroup of the DHS called US-Cert. https://ics-cert.us-cert.gov/ICS-CERT-Vulnerability-Disclosure-Policy

4
  • Well they're not password-passwords, they're 'secret keys' (things like "CHANGE ME") sourced from multiple sources which are used for signing web-server sessions, so no other data would be published besides the secrets themselves, furthermore it seems pretty hard to inform anyone about a data breach as it's already public data, just more organized – Paradoxis Jan 14 '19 at 19:59
  • 2
    Got it. I was a little confused why you were using the term "secret." If it doesn't identify the user in anyway I don't think releasing them is harmful. Hackers scrape github all the time to see if code devs hardcode passwords they can then use to breech the companies. I understand your struggle for "how to notify github" because it's not really on github" and other similar situations. I'll update the answer above – bashCypher Jan 14 '19 at 20:03
  • 2
    agreee with bashCypher: this isn't the same as publishing a password dump, this is just aggregating and reposting already-public data. You should consider doing a blog post or talk on any interesting findings. I just saw one recently at OpenDNS about secrets scraped from pastebin, and it was awesome. – Angelo Schilling Jan 14 '19 at 20:05
  • 1
    @AngeloSchilling I'm in the process of writing one, but I'm still aggregating statistics like how many devices on Shodan I managed to find which are vulnerable to this attack. – Paradoxis Jan 14 '19 at 20:10
0

Have you verified any secrets? Because you're talking about a script pulling information that potentially is mostly noise (test data - question specific data)

If there is no link to a specific site - solution - person there should be no issue as this is public data. But in your own question you've also provided a source linking the data allowing it to be narrowed down - its still public. It was fine until you mentioned your data source.

1
  • Thanks for the answer, I haven't been able to verify any of the secrets as I chose not to scrape any data besides the secret keys themselves. I did however test my tool against a local application, and setting the key to "CHANGE ME" resulted in an instant match. Besides that, pointing out that it's found on GitHub and StackOverflow is kind of required as the research is based around recklessly publishing the keys publicly on websites which host code (which people almost instantly presume to be those websites). – Paradoxis Jan 14 '19 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.