3 ms·

As a security engineer, I'm really happy to see news like this enter the mainstream more and more on HN. These bounties are well deserved. For those of you who

by dsacco 12y ago

As a security engineer, I'm really happy to see news like this enter the mainstream more and more on HN. These bounties are well deserved. For those of you who would like to try and earn bounties like these, I recommend the same books I always do: 1. The Art of Software Security Assessment 2. Gray Hat Python 3. The Web Application Hacker's Handbook This is your ethical hacker starter kit. The first two are good for foundational knowledge and will show you how to find the bugs worth something. The third book is specialized for web applications, which is still great but not quite as lucrative. You will also want to check out CTFs, Cryptography Engineering and the Matasano Crypto Challenges. If you're looking to join a top tier security firm, Matasano is great for those who like offices and Accuvant (my employer) is great for those who like working fully remotely.

lordnacho 12y ago
Thanks for the list. I always found the security area mystifying. How do you determine when you are good enough to apply? And how do you get some work that you will actually be able to do?
- dsacco 12y ago
  Some firms are very open to taking total noobs with promising intuitions and who can code well (you need to be able to code well for this). If you can go this way, you should. Otherwise: 1. If you have found bug bounties consistently across the gamut of web application vulnerabilities, you're probably ready (you will have gaps - supplement with lots of theory). 2. If you can competently write a custom debugger and reverse engineer apps, you're ready. 3. If you would honestly call yourself an expert C/C++ programmer, you're ready. 4. If you actually completed the Matasano Crypto Challenges, you're ready. You are specifically not ready just because you got yourself a certification, especially if that certification is the CISSP. The CISSP is an HR drone criteria that has more relevance on a SaaS pricing table than it does in a real security firm. 'tptacek and 'patio11 are working on Starfighter, which will be of interest to you. Check it out.
exDM69 12y ago
These books are probably great but if you look at some of the best/worst bugs found in the past few years, there's one tool that seems to come up over and over again: afl-fuzz. I recon that the easiest way to get started with bug hunting might be to just set up afl-fuzzing on some trivial code that has lots of potential for going wrong. Stuff like JSON/HTML/HTTP parsing in C is a great candidate to find integer overflow or buffer overrun bugs in (some of the bugs in this list are exactly that). Throw some CPU time for the fuzzing, and pretty soon you should have a handful of repro cases. The nice thing about these is that the bugs could be very trivial to fix but have enormous security consequences. If someone wants a suggestion for a project to try some fuzzing against, the new h2o/libh2o web server and its HTTP parser component (picohttpparser) look very well written but not very well tested (only a handful of hand written, hard coded test cases). I'm pretty sure there's one or more potentially disastrous bugs in it. edit: almost all bugs in this list seem to be integer overflow bugs. That hints that these issues were found using a static analysis tool like ClangAnalyzer or Coverity.
- tptacek 12y ago
  Reading some of the actual reports, these look like straight code findings (see for instance the numbered step-by-step explanations). They also aren't particularly complicated bugs.
- dsacco 12y ago
  Please don't start this way. Michal Zalewski didn't write afl fuzzer so it would be used without deep technical knowledge. It's actually not for beginners at all despite how powerful it is. As a general rule to start in security work, you will want to know how to program in at least one language competently, then move on to theoretical understanding of vulnerabilities, then finding them painstakingly by hand, and finally by automation. It's perfectly fine to use afl (or other similar tools), but understand that using an automated tool without first knowing how to do things by hand and groking the theory will stunt your growth and make it hard to progress very far. Pop open a weakened VM and exploit a few buffer overflow bugs the old fashioned way before you use a fuzzer. With code review, learn the nuances of each language before you automate your audit. You shouldn't have to rely on an automated tool to find out register globals is on in PHP (as one example).

by dsacco 12y ago

lordnacho 12y ago

Thanks for the list. I always found the security area mystifying. How do you determine when you are good enough to apply? And how do you get some work that you will actually be able to do?

dsacco 12y ago
Some firms are very open to taking total noobs with promising intuitions and who can code well (you need to be able to code well for this). If you can go this way, you should. Otherwise: 1. If you have found bug bounties consistently across the gamut of web application vulnerabilities, you're probably ready (you will have gaps - supplement with lots of theory). 2. If you can competently write a custom debugger and reverse engineer apps, you're ready. 3. If you would honestly call yourself an expert C/C++ programmer, you're ready. 4. If you actually completed the Matasano Crypto Challenges, you're ready. You are specifically not ready just because you got yourself a certification, especially if that certification is the CISSP. The CISSP is an HR drone criteria that has more relevance on a SaaS pricing table than it does in a real security firm. 'tptacek and 'patio11 are working on Starfighter, which will be of interest to you. Check it out.

exDM69 12y ago

These books are probably great but if you look at some of the best/worst bugs found in the past few years, there's one tool that seems to come up over and over again: afl-fuzz. I recon that the easiest way to get started with bug hunting might be to just set up afl-fuzzing on some trivial code that has lots of potential for going wrong. Stuff like JSON/HTML/HTTP parsing in C is a great candidate to find integer overflow or buffer overrun bugs in (some of the bugs in this list are exactly that). Throw some CPU time for the fuzzing, and pretty soon you should have a handful of repro cases. The nice thing about these is that the bugs could be very trivial to fix but have enormous security consequences. If someone wants a suggestion for a project to try some fuzzing against, the new h2o/libh2o web server and its HTTP parser component (picohttpparser) look very well written but not very well tested (only a handful of hand written, hard coded test cases). I'm pretty sure there's one or more potentially disastrous bugs in it. edit: almost all bugs in this list seem to be integer overflow bugs. That hints that these issues were found using a static analysis tool like ClangAnalyzer or Coverity.

tptacek 12y ago
Reading some of the actual reports, these look like straight code findings (see for instance the numbered step-by-step explanations). They also aren't particularly complicated bugs.
dsacco 12y ago
Please don't start this way. Michal Zalewski didn't write afl fuzzer so it would be used without deep technical knowledge. It's actually not for beginners at all despite how powerful it is. As a general rule to start in security work, you will want to know how to program in at least one language competently, then move on to theoretical understanding of vulnerabilities, then finding them painstakingly by hand, and finally by automation. It's perfectly fine to use afl (or other similar tools), but understand that using an automated tool without first knowing how to do things by hand and groking the theory will stunt your growth and make it hard to progress very far. Pop open a weakened VM and exploit a few buffer overflow bugs the old fashioned way before you use a fuzzer. With code review, learn the nuances of each language before you automate your audit. You shouldn't have to rely on an automated tool to find out register globals is on in PHP (as one example).