I often feel dizzy when I walk into Ace Hardware in South Miami Beach and walk along the aisle with a screwdriver. You will see nearly 50 kinds of screwdrivers with different specifications displayed neatly and orderly on the shelves. There is a slight but very important difference between each specification screwdriver and the adjacent screwdriver. I'm not a qualified repairman, and I can't accurately tell the ideal use of every screwdriver, but I'm sure that similar situations can also be applied to our safety tool software. Especially when you are conducting a security audit of Web types or other highly customized applications, you will find that each audit task needs a special "screwdriver" to solve the problem. You know, being able to piece together some security gadgets such as SQL API function hooks in time has saved the work team of Immunity more than once. Of course, these tools are not only suitable for security audit tasks. Once you can intercept SQL API with hook function, you can easily write a tool to detect suspicious abnormal SQL queries in real time, and provide a repair plan to the client company in time to resist the attack of stubborn hackers.
As we all know, it is a very difficult thing to make each of your safety researchers truly become a member of the team. No matter what kind of problems are faced with, many security researchers are enthusiastic to start from scratch and try to completely rewrite the tool library they need. For example, Immunity found a security hole in the SSL daemon, and what is likely to happen next is that you suddenly find that one of your security researchers is actually trying to write an SSL client from scratch. And their usual explanation for this is "all SSL libraries I can find are ugly."
You need to try your best to avoid this situation. In fact, the existing SSL library is not ugly-it is just not designed according to the special preference style of security researchers. What we really need to do is to deeply analyze a large number of existing codes, quickly find problems, and modify them according to our own needs. This is the key to establish an available SSL library in time and use it to develop a vulnerability exploitation program that is still in the fresh-keeping period. To do this, you need to make your security researchers work like a real team. A security researcher who has mastered Python has a powerful weapon, perhaps just like those who have mastered Ruby. However, the real difference of Python is that when Python enthusiasts Qi Xin work together, they will be as powerful as a super-individual running at high speed. Just like the army of ants in your kitchen, when there are enough to form a big squid, it is much more difficult to kill them than to kill a squid. This is the fact that this book tries to tell you.
You may have found some tools for what you want to do. You may ask, "I already have a Visual Studio with a debugger. Why should I write a debugger for my own use?" Or "Does WinDbg have no plug-in interface?" The answer is yes. WinDbg does provide plug-in interfaces, and you can slowly piece together something useful through those APIs. Until one day, you will probably say, "Heck, if only I could connect with 5000 users of WinDbg, so that we can exchange our debugging results." If you choose Python from the beginning, you can build an XML-RPC client and server by writing about 100 lines of code, and then the whole team can work synchronously, so that everyone can enjoy the achievements and information of others in time.
Hacking is by no means the same as reverse engineering-your goal is not to recover the source code of the entire application. Your goal is to know more about software systems than the system developers themselves. Once you can do this, no matter what form the target appears, you will eventually successfully penetrate it and get a hot opportunity to use it. This also means that you need to become an expert in visualization, remote synchronization, graph theory, linear equation solving, static analysis technology and many other aspects. So Immunity decided to standardize all these on Python platform, so that once we write a graph theory algorithm, it will be common in all our tools.
In chapter 6, Justin shows you how to steal the user name and password entered in the Firefox browser with a hook. This is exactly what malware authors do-as can be seen from some previous reports, malware authors usually use some more advanced languages to write such programs. However, you can also use Python to write a sample program in 15 minutes to show your developers that their security assumptions about their products are not valid. Some software companies now spend a lot of money to protect the internal data of software because they claim security problems. In fact, what they do is often just to realize some copyright protection and digital rights management mechanisms.
This is what this book is trying to teach you: the ability to quickly create security tools. You should be able to use this ability to bring success to yourself or the whole team. This is the future of security tools: rapid implementation, rapid modification and rapid interconnection. I think, in the end, the only question you have left may be: "Are you finished?"
Dave Aitel, founder and chief technology officer of Immunine
February 2009, Miami Beach, Florida, USA.
thank you
I want to take this opportunity to thank my family for their understanding and support in the process of writing this book. Thanks to my four lovely children: Emily, Carter, Cohen and Brady, who gave my father a reason to finish this book. I am very glad to have you. I also want to say thank you for your encouragement in this process. You have all experienced the rigor and hardship of writing books. It's really beneficial to have you people who feel the same way about the publication of technical works-I love you. I also want to tell my dad that your sense of humor helped me through those days when I couldn't keep writing-I love you, dad, and don't stop making people around you laugh.
Thanks to the help of many excellent security researchers along the way, this book has gradually grown up: Jared Dermot, Pedro Amigny, Cody Pierce, Thomas Heller (the legendary invincible Python Man) and Charlie Miller-I owe you a big thank you. As for the exemption group, there is no doubt that you have been generously supporting me in writing this book. Thanks to your help, I not only grew up as a Python kid, but also became a real developer and security technology researcher. Nico and Dami spent extra time helping me solve this problem, and they are very grateful. Dave Aitel, my technical editor, has been pushing the progress of this book to ensure its logic and readability. Thank you very much here. For the other Dave, Dave Fallon, thank you very much for reviewing this book for me. I was deeply impressed by the mistakes that made me laugh and cry, the heroic act of saving my laptop at the CanSecWest conference, and your magical network knowledge as a wizard.
Finally, the last person to thank is the Nostarch publishing team. Taylor and I went through the whole publishing process of this book (believe me, Taylor will be the most patient guy you have ever met), and Bill gave me an encouraging voice, as well as a lovely coffee cup and Perl cheat sheet. Megan saved me a lot of trouble at the end of the book creation, and other team members working behind the scenes published this book-thank you! . I appreciate everything you have done for me. Now this thank-you speech is almost as long as Grammy's acceptance speech. Finally, I want to thank all my friends who have helped me again, but I may forget to mention-you know what you mean to this book.
Justin Seitz