110
this post was submitted on 06 Feb 2024
110 points (94.4% liked)
Programming
17270 readers
39 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You have to find a problem before you can fix it. All good programmers are hackers.
You don't need to be a hacker to find those problems. You need to be a good detective. All good programmers are detectives.
I don't think either is actually true. I know many programmers who can fix a problem once the bug is identified but wouldn't be able to find it themselves nor would they be able to determine if a bug is exploitable without significant coaching.
Exploit finding is a specific skill set that requires thinking about multiple levels of abstraction simultaneously (or intentionally methodically). I have found that most programmers simply don't do this.
I think the definition of "good" comes into play here, because the vast majority of programmers need to dependably discover solutions to problems that other people find. Ingenuity and multilevel abstract thinking are not critically important and many of these engineers who reliably fix problems without hand holding are good engineers in my book.
I suppose that it could be argued that finding the source of a bug from a bug report requires detective skills, but even this is mostly guided inspection with modern tooling.
Yeah take for instance ransomware. That is easy since a lot of your targets might distrust regular user input but be much less cautious about stuff that should presumably be only accessible internally but isn't actually even properly locked behind a VPN gate so a simple credential stuffing would do and from then onwards it is actually easier than a physical kidnapping since you don't need to worry about using physical force to ensure your victim submits, doesn't escape or recognize you. But then you need to actually be smart to make sure you don't de-anonymize yourself in the process, don't render your operation just some temporary disturbance by ensuring your victim doesn't just restore their backups if your goal is a denial of service until you get paid and not expecting ransom for not releasing breach data.
Or take carding. Not technically super difficult, especially with the whole illusion of security that many non-technical users have (ie the infamous padlock when I can literally set up a phishing site with letsencrypt that'd log all the form data in minutes), but then good luck cashing out on that with all the KYC on virtually every crypto exchange out there and all that granted 3DS doesn't stop you.
Programmers have the source code right in front of them, hackers usually don't. It's quite amazing what they can do taking shots in the dark.
depends. Desktop code, sure, reverse engineering from assembly takes some time but some good dissasemblers might be able to produce some C skeleton to start from. Though you might get lucky just exploiting the supply chain of bloated open source with a hellton of vulnerabilities deps/infra like glibc, apache or sudo.
But web code? Sure, minifiers exist but not every website uses them and even if their do, thanks to all the new stuff since ES5 you can for example spend way less time doing something like finding a Math.random() based, ergo cryptographically utterly broken PRNG.
Or for example you can easily rule out whether the website uses header-to-cookie based CSRF protection by just checking the console on any authenticated write-like request. The rest could be automated with things like zaproxy or selenium/curl-impersonate/puppeteer scripts.
"Hacking" also has plenty of specialties like programming. When I think of hacking my first thought is remote, non-http services. Webservers are fair game for hacking but they're also meant for public consumption so I'd guess monitoring is a bit more severe (not that companies don't skimp on intrusion detection).