Always love your content guys ❤ your channel motivated me to start learning exploitation
@camelotenglishtuition6394
6 ай бұрын
What is your learning path if you don't mind me asking
@camelotenglishtuition6394
6 ай бұрын
Great fucking video guys!
@oliverford5367
6 ай бұрын
So essentially with data corruption, you don't need to change any return pointers to point to your code or other code? You just need to find where say execve is already being executed, and change the arguments passed to it?
@dayzerosec
6 ай бұрын
Attacking the data going into `execve` would be a data-oriented attack yeah, of course having an `execve` sink isn't always possible so there are other routes perhaps abusing a file write for example to modify that or another applications configuration. Or sometimes you only need increase privileges to gain useful access, like in Linux kernel exploitation it used to be common to ROP or otherwise get arbitrary function calls to do `commit_creds(prepare_kernel_cred(0))` whereas exploits today will use read/write primitives to find and change that memory manually without highjacking the control-flow of the program. ~zi
@oliverford5367
6 ай бұрын
@@dayzerosec Right. In your experience, how effective is fuzzing compared to analyzing source code manually for finding bugs? Is it generally more effective to let a fuzzer run through the code or look through it yourself?
@dayzerosec
6 ай бұрын
@@oliverford5367 Effectiveness probably depends on metrics. By pure bug count, fuzzing is an easy win but sometimes does very little especially if fuzzing is already used in the development process. HUmans are better at finding deeper, more complex and higher-quality bugs than fuzzers tend to be. So I see human and computer and working together, let the fuzzer catch the stupid stuff, and human focus on the better bugs. There is also a feedback loop between the two. I'll let fuzzing provide insight into where i might want to look manually. Maybe a lot of warnings or even crashes come out of one area prompting more manual examination, or maybe a lack of coverage could be an indicator. On the other side as I do manual review I can feed information back into the fuzzer to improve coverage, provide newer/better seed corpus, improve mutations, etc. Personally I think its important to do both, and while you didn't ask about this exactly, I think anyone learning exploit dev should learn to do manual auditing before fuzzing but I go into that in my ctf2real-world blog posts on the Dayzerosec blog. ~zi
@CristianNazare
6 ай бұрын
4:22 - 5:00 so why is a security update something scary? How is another layer of security not "NOT SCARY"? You want unprotected data to be managed by unprotected software on unprotected hardware or what?
@dayzerosec
6 ай бұрын
So, this video is coming from the offensive side of security, developing exploits for memory-corruption bugs, the exact type of thing these mitigations are there to prevent. Whats bad for that skill is good for security. I'm all for the adoption of the technologies and later in the video we talk about adopting safer languages also, something I've spent my entire career in favor of. This video is about the future of doing that specific type of exploit development. It is scary when something threatens the value of a skill that takes a significant time to learn by basically eliminating the types of bugs it relies on. Especially so for people who are considering investing the time to learn it, its scary to think that it'll be irrelevant before you are even up-to-speed in it, or just that something I've spent a lot of time on will become unnecessary. But, would it be a good thing for that to happen? Absolutely. The funny thing about being on the offensive side of the industry is that several skills and techniques I've learned in years past have become irrelevant and that's okay (though I don't expect exploit dev to be dead just yet). I have essentially made a career out of trying to put myself out of a job by encouraging practices that make my work unnecessary. ~zi
@CristianNazare
6 ай бұрын
@@dayzerosec I know what you mean and how you feel. because as a full stack web dev I am also under the looming threat of AI taking my job. But i have to adapt, and use AI to make my job easier and faster, for my own good. The same as your career is based on finding flaws to keep us safe, and not to exploit flaws and get upset when the exploits get patched "as a whole". Exactly like how AI can build a working skeleton of a website/game/app, devs purpose has become mainly for coming up with the logic or flow of specific tasks instead of building HTML, making queries, etc. What I'm trying to say is: think of it as an (unwanted) upgrade to your career, you've been promoted to harder-to-find exploits and bugs :D
@nikoshalk
6 ай бұрын
Very insightful podcast! Thank you for sharing your views on the future of exploig dev!
@gcm4312
6 ай бұрын
34:06 maybe - in the near future - fine-tuned LLMs can massively help with this translation of unsafe languages to memory-safe languages.
@diazpame10
6 ай бұрын
please update "how to start exploit dev "
@vz7742
6 ай бұрын
No
@dayzerosec
6 ай бұрын
I want to update it but its hard. The main thing I'd want to change is really around how content is taught to have a greater focus on thinking about your exploitation primitives. Most content tends to present full exploitation strategies as here is how you exploit a stack-based overflow, a write-what-here, etc. There just isn't much content out there that really focuses on that at the beginner level so its hard to really suggest anything. I still stand by most of the recommendations though, I'd perhaps restructure it around incorporating more pwn college, but pwn college is hard to include because it changes in meaningful ways every year/course. Updating that content is something I plan to do though ~zi
Пікірлер: 15