Reddit reviews The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities (Volume 1 of 2)
We found 18 Reddit comments about The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities (Volume 1 of 2). Here are the top ones, ranked by their Reddit score.
If you're talking about memory corruption, you're looking for Smashing The Stack in 2010. However, most experts in application security and modern exploitation techniques recommend a more practical research-driven approach to learning about memory corruption mitigation techniques, so keep that in mind while reading this paper. As always, The Bible is relevant.
If you're talking about embedded device reverse engineering, you'll probably get the best answer from the /r/ReverseEngineering subreddit.
If you're talking about kernel bugs and kernel module bugs, I wish you luck. Bugs and vulnerabilities in these types of systems, usually require very obscure knowledge in very specific systems. Not for beginners or the faint of heart.
If you're talking about web bugs, you're looking for the OWASP Top 10. The web is mostly a giant joke, and widely uninteresting (this is an unpopular opinion on this subreddit).
http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426
Done and Done.
> Supponiamo che uno (anzi, più di uno visto che siamo tutti componenti di un LUG) voglia iniziare a smanettare un po' in quest'ambito, che cosa consigli?
di farlo :)
> Mettere su un webserver e iniziare a tentare di bucarlo con gli exploit conosciuti può essere una buona idea oppure è meglio prima procedere con altro?
Tutto fa brodo (mi', ventesimo proverbio, mi sto biscardizzando :). Però per prima cosa devono essere chiare le problematiche agli strati più bassi: boot da media esterno, forensics "malevola" (accesso al fs, reset delle password, estrazione delle password, trojanizzazione dell'OS, ..), MITM e i suoi derivati, poi nmap e network/service discovery come se piovesse, analisi di tutti i servizi esposti, poi "finalmente" potete dedicarvi anche alla parte (web) applicativa.. :)
Ci sono moltissimi "playground" per divertirsi ed imparare, sia come vm da scaricare che contest, crackme & co. online, alcuni al volissimo:
(copio & incollo dal sorgente che usiamo per generare la documentazione che distribuiamo a corsi & co, spero mantenga la formattazione - non è aggiornatissimo):
Esercizi
Elenco di applicazioni vulnerabili che possono essere utilizzate per imparare/approfondire le vulnerabilità nelle applicazioni web:
Elenco di applicazioni vulnerabili da altri siti:
Libri consigliati
Metodologie e check-list
Cheat sheets
> Da esperto di sicurezza, hai qualche consiglio su qualche "giochino" da far vedere in conferenze e relazioni per sensibilizzare le persone sull'argomento? Attualmente noto che fa molta presa questo iter (che è più sensazionalistico che altro):
> creo una rete wifi aperta senza dir loro nulla e aprendo wireshark
> durante la conferenza loro ovviamente la utilizzano senza pensarci troppo
> a fine conferenza mostro loro quante cose avrei potuto prelevare se solo avessi voluto
Ehm.. sarà anche sensazionalistico, ma lo faccio spesso anche io, con anche la parte di MITM sui certificati in automatico. Anche phishing/malware via mail, magari con split screen (cosa fa l'utente, cosa si vede sul "back-end"), con uno dei vari tool che ci sono metasploit, beef o con banali 10 righe di (linguaggio di scripting web a tua scelta).
Network security books are almost all scams that monetize the escapist fantasies of the fan base. Security is mostly assumption management. Don't assume a third party rehash is going to make you understand the underlying code any better.
That said, The Art of Software Security Assessment is pretty good. It's one of the books openbsd recommends for developers. It's quite healthy to know how anything talked about in the past 15 or so articles of phrack works, too.
Don't read anything that makes you think there is less for you to know after reading it. It's poison. And until you put the concepts into action, you don't know shit.
Web dev having trouble finding work? Buy this book and this book, read them and contact [email protected].
> They're wrong. The problem is that writing and testing cryptographic software is really, really hard.
Except that HeartBleed was an implementation bug, not a cryptographic one. It could have been caught if the OpenSSL maintainers a) paid for a security audit b) learned how to perform security audits themselves and did so on a regular basis. Instead of depending on security firms to audit OSS code, I feel this is an opportunity for the OSS community to unsilo the knowledge built up by professional security researchers and code auditors.
If you are interested in helping audit OSS C/C++ code, read The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities.
Reverse engineer Microsoft patches.
edit: serious answer:
I do this kind of work for a living. I started out in 1995 when I was 13 years old learning from mudge's excellent article on how to write buffer overflows and I progressed from there.
If you're analyzing software for which you have access to source code, you can't beat The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities.
Chris Wysopal's Art of Software Security Testing is also good.
If you're attacking software for which you have no source code, learn about fuzzing and reverse engineering. An excellent intro to reverse engineering is Reversing: Secrets of Reverse Engineering.
Those will get you started, but it helps to have people around you who are successfully discovering and exploiting software vulnerabilities. This is also the kind of field where you absolutely have to stay on top of the latest developments in software security. Things move at a mind-boggling pace. Read security blogs, talk to people in the industry, read books, etc...
"Source code fuzzers". Wow. Unless you're fuzzing a compiler/interpreter, it doesn't make any sense at all. Really, you should start by finding in Google about the subject.
In any case, I recommend you to read the book "The art of software security assessment" [1] and a Bug Hunter's Diary[2].
[1] http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426
[2] http://www.amazon.com/Bug-Hunters-Diary-Software-Security/dp/1593273851
Also a classic is "The Art of Software Security Assessment"
http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426
Training or not, the only way to get good at it is to do it. When it comes to discovering and exploiting vulnerabilities in commodity software, I'd say there are four aspects: 1) knowing what constitutes a software vulnerability; 2) facility with vulnerability discovery; 3) facility with software exploitation; and 4) dealing with issues of scale.
As for 1), I'd suggest reading books on the subject (e.g., The Art of Software Security Assessment) and following conference presentations to learn about emerging trends. For 2) and 3), Capture The Flag challenges (e.g. /r/SecurityCTF) provide a font of both small targets to practice on as well as write-ups from people who have completed them. Also, follow blogs and conference presentations to learn about exploit techniques. This will help you only somewhat with 4), which is where having reverse engineering skills are especially helpful. 4) is a matter of experience -- trying to apply what you've learned from practice on smaller targets (like CTFs) to larger, real-world software, failing, and keeping at it until you start to succeed.
The mother of all auditing books, better than Jon Erickson's jack of all trades - master of none approach imo.
The shellcoders handbook makes for an excellent accompaniment, too.
Based on reading some of your comments it looks like what you are really asking about is "how do I learn security engineering?"
The answer is by reading resources that explicitly teach the concept, because it is a specific discipline that blends software engineering, systems engineering, and computer security theory. It is probably most properly classified as a sub-discipline of systems engineering, so reading about systems engineering in general can be useful as well.
The following do not teach you "how to hack" they teach "how to look at this system/application from a security point of view" which seems to be what you are looking for.
Resources:
Both of those books can be bought through Amazon or there are PDFs online. I have the first two and am now buying the last one after reading a bit of the PDF I found.
Be warned, the last two books are very large. The second one would probably cover two semesters worth of material. The last one is nearly 1200 pages across two volumes.
The MIT videos are great.
Regardless of the above, Security+ or equivalent would give you a base level of knowledge from which you could get more out of the above materials. You can get Sec+ study guides online cheap/free, either in book or articles or video lecture form. Cybrary has great free cybersec lecture courses including Sec+.
For those looking to write and/or evaluate the security of software, there's also TAOSSA.
A little prophecy here - neither WebInspect nor Fortify will actually solve any of your problems, they'll just point you at them. Having bug reports doesn't mean the issues get solved (correctly), and to get the ones which actually matter you'll have to wade through lots of false positives, even with the better tools.
In order to determine what counts and what doesn't and how you fix it if it does, you actually need security competence. Which is something the developers who are often facing hundreds or thousands of bug reports from these tools often do not have, since they were never trained and/or had no time to further look into.
When it comes to pen testing and app sec assessments, it really depends on what you're looking at. If it's web apps mostly, well, I am sure you already know OWASP. I kinda liked the Web Application Hacker's Handbook.
When it comes to other stuff, this is a great book http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426
I am, btw, a CSSLP, and I think the cert is kinda fluffy.
Senior Security Engineer
Hi, I'm Kevin Hock and I work on the DataDog security team.
We are looking for some talented security engineers to join our security team here in NYC.
How Do I Apply
Send me an email with your resume and GitHub at [email protected]
What you will do
Who you should be
Bonus points
Sample interview questions
Hat tip to Levi at SquareSpace, also on this thread, he is an awesome person to work with. David Wong, a crypto king of NCC, on this very Q4 thread, is also a great person to work with in Chicago.
If you're looking to break stuff more than build stuff hat tip to Chris Rohlf's Yahoo! team.Random other places you can apply in nyc: MongoDB, Jane Street, 2 sigma, greenhouse.
I personally applied because I love Python but I like the company a lot so far.
I'm in a similar situation and some resources that I'm finding really eye opening are Trailofbits CTF Guide and the book [The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities] (http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426).
I also find other people exploits and presentations inspiring in a sense :)
Your recommendation for AV is wrong: antivirus software generally makes your computer more vulnerable.
Where am I getting this from?
James Findley has a nice post over at Hacker News which, in my non-expert opinion, sums up the state of AV well:
> In the days of windows 95/8, the desktop landscape was very different to how it is now - OSes and browsers were horribly insecure, and readily compromised with little effort. Attacks were plentiful, and infections common. AV really did add useful additional security.
>
> These days that's less the case - an up to date windows 10 or OSX desktop is reasonably secure by default - it can still be infected, but generally not without some action taken by the user (of course there are still 0-days, but they are generally treated seriously and patched at least moderately quickly. Unauthenticated RCEs are now a rarity, thankfully).
>
> The AV industry hasn't really caught up with the idea that the OS/apps they are messing with are now in general fairly well written and audited pieces of code, and haven't really got institutional awareness that they are making things worse, much of the time.
http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426