0xad

The author seems to be deriving wrong conclusion, I think.

Yes, LinkedIn (like any other social media) is primarily a dumpster. But, and this is a BIG but, you yourself don’t need to produce trash. You can produce HIGH quality content.

No one is stopping you.

So what is the real issue here? I think that it is this: the real grievance of the OP is that his original, high quality, content might loose to the slop. And this hurts, so instead of playing the game anyway, he goes on his own site and complains. Basically playing out the party meme.

Binvisio from cortesi and cantordust from domas being already mentioned, I’m surprised I haven’t seen this yet: https://lcamtuf.coredump.cx/newtcp/

Yes, but (always but!) we also need to take into account what we're aiming at, which is an impact on stock performance. So the company needs to be (1) listed on a stock exchange and (2) have a significant publicly disclosed incident. And it turns out that such cases aren't as common as one might think. :)

As a side note, one can learn a lot from Verizon's DBIR. People familiar with it might even recognize my inspiration.

If you don't see the difference between proprietatory format like docx and you argue that just because I add double-asterisk with a word in-between then suddenly it's not plain-text file (since it's markdown markup at this point) then yeah, this conversation is over.

I think it does.

By transforming file Foo.docx into file Bar.b64 you get a plain-text file (Bar.b64) but Foo.docx still isn't plain-text. That's actually how email attachments work (transforming any file into b64 plain-text file), so I think your counter-argument is pointless.

No.

Open up a word document (.docx) in hex editor (head -80 foo.docx | xxd) and you'll see it's not a plain file on a binary level. Now do the same with any python, php, html, and js files and you'll see that they're plain files.

That's the difference that Derek is talking about.

Here's one: If you want your operations to be as easy as they can be (LAMP), go with PHP.

By original do you mean Hovav's? Then no, it's 2008.

But I'd argue that Borrowed Code Chunks exploitation technique paper by stealth from 2005 is the original. But maybe I'm just too old.

You can use grammarinator or any other of myriad grammar fuzzers BUT I'd start with radamsa and its string-related flags. Radamsa is _awesome_, you run it on an input and you get mutated output. Works both for binary files and text fles (such as grammars).

OP here. I'm planning to do so, however it will require more work (better description of the problem, wider description of viable solutions, additional case studies). Most probably it will land on Medium and Dev.to.

Yes you will, but only because GitHub already recognised this class of problems and came up with their own solution [1]. Bear in mind that it works only for vendors that integrated, so while it's true for AWS it might not be for your FOO API.

I giggled at meme.

[1] https://developer.github.com/partnerships/secret-scanning/

Hey, OP here. I agree that a blog post would be more readable. In this particular case I just didn't expect that it will catch fire. If I would then I would spend more time on the form. I won't make that mistake again (i.e. in the future I will use a blog post as main driver of such twitter thread).

Cool! Thanks for explanation.

Greetings fellow Hackers! OP here. I see that my experiment got some traction which means more awareness should be spread about this class of bugs.

For starters I recommend reading "How Bad Can It Git" [1] and "Detecting and Mitigating Secret-Key Leaks inSource Code Repositories" [2] papers.

After that you can read "How I made $10K in bug bounties from GitHub secret leaks" [3] and some notable reports on HackerOne Hacktivity [4] [5] and [6]. This last one is interesting - leaking secrets is not only about code repository! Actually it's about entire toolset used for software development, hence secret scanning could (should?) be performed for other places such as CICD logs or even Slack messages [7].

Anyhow, back to code repositories. GitHub and GitLab both recognized secrets as a problem, so they came up with solutions. If you use GitHub you can easily integrate GitGuardian [8] into your workflow ($$$) but even if you don't GitHub provides you with Secret Scanning feature [9] (both are mentioned within the Twitter and HN threads). If you use GitLab you have a Secret Detection feature [10] at your disposal BUT in order to use it you need to setup Auto DevOps (that's why in my experiment GitLab didn't alert me - I just pushed commits to my public repo but didn't setup anything).

Apart from built-in solutions provided by GitHub and GitLab, one can use tooling of their own choice. For this I'd recommend two types of solutions: proactive and reactive. For proactive security, as mentioned in the Twitter thread, you can use Talisman [11] as pre-commit hook. For reactive security you can use GitLeaks [12] (used by GitLab) or similar tools - there are many of them but one stands out, namely truffleHog [13] which can sniff each and every commit across all branches (also used by GitLab).

What if you already commited a secret into the public repository? Start with revoking and continue with this tutorial [14]

gl, hf.

[1] https://www.ndss-symposium.org/ndss-paper/how-bad-can-it-git... [2] https://people.eecs.berkeley.edu/~rohanpadhye/files/key_leak... [3] https://tillsongalloway.com/finding-sensitive-information-on... [4] https://hackerone.com/reports/716292 [5] https://hackerone.com/reports/396467 [6] https://hackerone.com/reports/496937 [7] https://github.com/PaperMtn/slack-watchman [8] https://www.gitguardian.com/ [9] https://developer.github.com/partnerships/secret-scanning/ [10] https://docs.gitlab.com/ee/user/application_security/sast/#s... [11] https://github.com/thoughtworks/talisman [12] https://github.com/zricethezav/gitleaks [13] https://github.com/dxa4481/truffleHog [14] https://docs.github.com/en/free-pro-team@latest/github/authe...

Awesome, thanks for the background information!

You mean adversaries? No. For token generation I used https://canarytokens.org/ so the only information I got was abou triggering the token, but not the context in which it was triggered.

BTW. GitHub (apart from GitGuardian) also has Secret Scanning feature [1] that basically allows the provider to act on the leaked secret. Amazon is integrated and it should invalidate and inform the owner but this also went to Thinkst, not me, so I don't know if it was actually invalidated and alerted.

[1] https://developer.github.com/partnerships/secret-scanning/

Thanks!

What AFL needs is _instrumentation_ and of course the easiest way is to get that at compilation step, however you are not constrained by anything to get that part via other means. Check https://github.com/ivanfratric/winafl that uses DynamoRIO.

So, to answer your question -- it wouldn't be easy but it can be done.

Great article. Kudos.

On a side node, my old project https://github.com/dyjakan/interpreter-bugs along with short presentation I did on WarCon 2017 https://github.com/dyjakan/conference-talks/blob/master/2017... (references might be interesting for others).

And of course also caused problems there. Check Project Zero advisories (iirc found by jhorn).