Comment by catlifeonmars 4 days 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’m thinking of pivoting into cybersecurity. I suspect that’s where the all money will be in the next couple of years.
At least until the pivot by Claude et al from AI for work to AI for cybersec analysis.
Same problem, 1 level deeper. It’s cat and mouse until the next breakthrough.
Indeed - most of my StackOverflow credit is for explaining TLS config options.
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...
I don’t use stars to select dependencies FWIW. I look for age, CVEs and what other reputable projects depend on a repo. Also try to look for other signals, like if claims in the readme don’t match the implementation, or if there’s poor hygiene in the CI workflows. (And yes, I have gotten burned by an otherwise well meaning project with a supply chain vuln). As the saying goes “a little copying is better than a little dependency” (see: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s).
The thing you want has a kind of academic jargon name (coeffects algebra with graded/indexed monads for discharge) but is very intuitive, and it can do useful and complete attestation without compromising anyone credentials (in the limit case because everyone chooses what proxy to run).
Sorry but you lost me. How are coeffects different from effects? I think I’m missing some steps between monads and credentials. Maybe fill in the blanks?
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.
it's incredible that people pointed out very specifically what's wrong and you fell back to weaponized incompetence to shift the intellectual and mental burden of reviewing the code to outsiders instead of thinking for yourself. this is the problem with relying on LLM,s instead of thinking for yourself you just ask LLMs, and now other real people "idk just fix it for me make it work". do you really not see the problem with this?
No, you’re in the process of vibe coding stuff you don’t understand and you will most likely never understand until you take the time to open a book.
>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
I'm not going to review it in full, sorry. Reviewing is so much more effort compared to producing something with AI. But don't let me deter you, keep on learning and keep on building.
I wish I had the possibilities to learn and build on such a large scale when I started out. AI is a blessing and a curse I guess.
My own early projects were most definitely crap, and I made the exact same mistakes in the past. Honestly my first attempts were surely worse. But my projects were also tiny and incomplete, so I never published them.
However: What little parts I did publish as open-source or PRs were meticulously reviewed before ever hitting send, and I knew these inside and out and they were as good as I could make it.
Vibe-coded software is complete but never as good as you could make it, so the effort in reviewing it is mostly wasted.
I guess what I'm trying to say is I'm a bit tired of seeing student-level projects on HN / Github cosplaying as production ready software built by an experienced engineer. It used to be possible to distinguish these from the README or other cues, but nowadays they all look professional and are unintentionally polluting the software space when I'm actually looking for something.
Please understand that this is not specifically directed at you, it's pent up frustration from reading HN projects over the last months. Old guy yelling at clouds.
The README is really annoying.
You used to be able to tell so easily what was a good well looked after repo by viewing the effort and detail that had gone into the README.
Now it's too easy to slop up a README.
it is incredible that people pointed out very specifically what's wrong and you fell back to weaponized incompetence to shift the intellectual and mental burden of reviewing the code to outsiders instead of thinking for yourself. this is the problem with relying on LLM,s instead of thinking for yourself you just ask LLMs, and now other real people "idk just fix it for me make it work". do you really not see the problem with this?
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.
If you're able to manipulate DNS, can't you just issue your own certificate for the domain? Even if it would be revoked moments later, mitmproxy doesnt check it even when ssl_insecure=false:
https://github.com/mitmproxy/mitmproxy/issues/2235
EDIT: Maybe I incorrectly assumed you meant authoritative DNS.
You got it, authoritative not necessary. It just needs to be your router, your ISPs resolver, or the one at your public library/coffee shop/hotel etc. I’d throw BGP route poisoning in there too, but then you have much bigger problems lol.
Like you pointed out in your original post, this would be expensive to run as a targeted attack, but it has good unit economics if you scale it up, wait, and then harvest.
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)