← Back to context

Comment by catlifeonmars

15 hours ago

This tool looks like it unconditionally disables tls verification for upstream requests.

It shells out to mitmproxy with "--set", "ssl_insecure=true"

This took all of 5 minutes to find reading through main.py on my phone.

https://github.com/jmuncor/sherlock/blob/fb76605fabbda351828...

Edit: In case it’s not clear, you should not use this.

I think the main problem is when OP wrote:

> I built this

Instead of

> I prompted this

I am OK with people publishing new ideas to the web as long as they are 100% honest and admit they just had an idea and asked an AI to build it for themselves. That way I can understand they may not have considered all the things that needs to be considered and I can skip it (and then prompt it myself if I want to, adding all the things I consider necesary)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Don't use it if you plan to auto accept terminal commands, without a sandbox, while on a public wifi in a cafe, next to a hacker who decides to bet on you running a very niche configuration.

  • All you need is to manipulate DNS, inject a record with a long TTL and the rest is not required.

    It scales very well and I guarantee this is not the only instance of misconfigured host verification. In other words, this is not as niche as you might think.

Just fixed it and implemented a simple http relay, eliminating the mitmproxy and the ssl_insecure=true. The new implementation uses TLS verification, doing last tests and merging it... After the merge can you check it out and tell me if I earned your star? :D

  • I’m not sure you fully understand the implications of the misconfiguration of mitmproxy there. Effectively you provided an easily accessible front door for remote code execution on a user’s machine.

    No offense, but I wouldn’t trust anything else you published.

    I think it’s great that you are learning and it is difficult to put yourself out there and publish code, but what you originally wrote had serious implications and could have caused real harm to users.

    • Ohh my, no offense taken... The next time I will be a lot more careful with the stuff that I put out there. Learning and getting the hang of it, would love if you either comment on the code or here any other things you think could be improved. I am in the process of getting better and appreciate all the blunt and transparent feedback. No one grows out of praise.

      5 replies →

  • >tell me if I earned your star

    Since you asked: Not in a million years, no.

    A bug of this type is either an honest typo or a sign that the author(s) don't take security seriously. Even if it were a typo, any serious author would've put a large FIXME right there when adding that line disabling verification. I know I would. In any case a huge red flag for a mitm tool.

    Seeing that it's vibe coded leads me believe it's due to AI slop, not a simple typo from debugging.

    • I love the real feedback tbh, I am still learning, and want to learn as much as possible. Would love if you can review it and tell me bluntly either in the repo or here the things that should be improved. I would love to learn more from you and get better :D

      7 replies →

  • You don't understand what you're doing, and never will. Throw away all computing devices you've got.

And it's already surpassed my most starred project when it was on GitHub, all the more validating to have moved it to forgejo. If vibecoded stuff with unbelievable security vulns can get so much praise the whole star system doesn't work as a quality filter. Similarly a well crafted README used to help reflect quality, no longer...