It is badly cliched, but it doesn't make my skin crawl quite like "paradigm breaking".

A while back, I read something about creativity that talked about "thinking around corners."  I like the phrase and it's not cliched (yet).

Know your subject.  Read other papers, articles, etc. so that you know what other people are doing and so that you know the benefits and drawbacks of their approaches as well as your own. 

Have someone who is not an expert, but who should be able to understand your papers, read them and give you feedback as to whether the papers are understandable.  If your reader doesn't understand one of your papers, take him seriously.  Your explanation probably left something out.

Test and re-test any code, commands, or configurations that you include in your paper.  You don't want to publish a paper with code that doesn't compile or commands that don't work.

Include links or references for background/further reading at the end.  Some people may want to read more background in order to understand your paper or to move on to related or more advanced topics.  Even a couple of links or references can be helpful.  Choose other papers or books that you've read and think are appropriate.  Dont' just slap in some random references you aren't actually familiar with. 

Buy a copy of The Elements of Style by Strunk & White.  It's a standard guide to grammar and style that many writers use (for good reason).  It's also very short and easy to read in short spurts.  Theirs is sage advice; follow it.

Don't use passive voice (most of the time).  This rule isn't absolute.  Sometimes you'll use passive voice in a sentence because it sounds right, but if you use it too much your writing will sound weak.

That's all I can think of right now.  Good luck.

-Unicityd

The cryptography behind 128-bit AES is unbreakable so far, but that doesn't mean that every implementation is unbreakable in practice.  Most flaws occur because of the way the cryptography is handled, i.e. keys stored in the clear or generated from a non-random source like the time of day.

That said, if the signal can't go past your meter, then (TEMPEST aside) you're not an less safe than with a traditional wired home network even if the cryptography turns out to be badly implemented (I have no idea if it is or not). 

If you're looking for a book, try these:

The Shellcoder's Handbook
http://www.amazon.com/Shellcoders-Handbook-Discovering-Exploiting-Security/dp/0764544683
Exploiting Software
http://www.amazon.com/Exploiting-Software-Break-Addison-Wesley-Security/dp/0201786958

I posted a list of papers and tutorials on buffer overflows a while back.  I don't know if the links are still current, but you should be able to find the papers through Google if not.

http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,2897.msg13502/#msg13502

The first two papers will give you enough to start writing stack-based buffer overflows.  The others cover more advanced topics and can be read roughly in the order that I listed them (the better your background in programming and operating systems, the more you can jump around). 

I was fortunate to come across a copy of The Cuckoo's Egg at a used bookstore a few years ago.  I thought it was very good; perhaps it even deserves a re-read.

Hi all,

I'm hoping to stimulate a little discussion here.  I see pretty frequent suggestions on this site for various penetration testing and hacking books, but not for many other security books.  I'm guessing that the members here read other security books too, so I ask:

What is your favorite non-hacking security book?

My favorite security book is Network Security: Private Communication in a Public World by Charlie Kaufman et. al.  The book focuses on network security protocols and has very lucid explanations of the cryptography involved, how the protocols work and what their shortcomings are.  It doesn't have a lot of practical advice for system admins, but it really helped me to understand Kerberos, IPSec, SSL, etc.

For web application security, I second BillV's recommendation of the Web Application Hacker's Handbook.  I'm in the process of reading it myself--though i've been a little sidtracked lately--and it is very good.

Unicityd

AES is the U.S. Standard and is the safe choice.  The runners up for the standard were Twofish and Serpent and both are considered to be very strong.  Twofish is the successor to Blowfish and is probably a better choice than that algorithm. 

RC6 was evaluated as a candidate for the U.S. standard but was not selected as a finalist.  I don't know if that was due to flaws in the systems or because of other concerns such as performance, code size, etc.

Triple-DES is still a good choice, but it's slow.  Triple DES uses 168-bit keys, but carries only 112-bit security (because you can do a time-memory tradeoff when triple encryption is used.) DES was the old U.S. standard.  Regular DES uses only 56-bit keys and is not recommended for new products.

Key size is important, but algorithm strength is equally important.  Try to find a copy of Applied Cryptography by Bruce Schneier.  The book is out of date so it won't talk about AES or Twofish, but it will give you a little insight into the types of concerns that go into selecting a cipher.  At a minimum, read the chapters on DES, block ciphers (there are two) and the chapter on key size.  As an alternative, you can find the Handbook of Applied Cryptography online for free in pdf form.  It's by Alfred Menezes et al.

Wikipedia is probably a good place to get some background on the algorithms.

If you want to find papers on the cryptanalysis of these algorithms, look at the proceedings to IACR's Crypto and Eurocrypt conference as well as the Fast Software Encryption Conference.  Unless you have a heavy math background, and until you've read up on block ciphers, you'll probably just want to skim the papers for the results and conclusion.

I hope this helps.

Don,

Do you draw any distinctions between former hackers?  I ask because I was a teenage computer hacker and have always admitted so.  I was never arrested for anything and my juvenile mischief did not carry over into adulthood.

As to whether being a former blackhat is an advantage: I don't think it is.  It's important to understand attack methods--you have to understand what you're defending against--but this knowledge can be gained in other ways.  There are numerous books on computer hacking available and many of them are quite good.  On the practical side, one can learn about attack methods from managing an IDS or honeypot, doing penetration testing, or reversing malware. 

Jack,

Many of the protections that are being shipped can be bypassed. 

On Windows, the /GS protections aren't always used and can be bypassed (in some cases) even when they are.  DEP is not fully supported on some processors and does not have to be enabled for all programs.

OpenBSD has a lot of features to prevent buffer overflow attacks and, as a result, there aren't a lot of OpenBSD exploits.

Linux systems vary.  StackGuard (which the /GS protections are based on) can be bypassed.  Stack randomization (boot-time or run-time) can be defeated also.  ASLR is harder to bypass but it is possible.  PaX can be defeated (even aside from the security flaw reported on Bugtraq).  Non-exec stack makes exploitation harder, but the return-into-libc method was made specifically to work around this barrier.

I posted a list of papers on writing buffer overflows a couple of weeks ago.  Many of the papers in that list deal specifically with defeating the various protections: 

http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,2897.msg13502/#msg13502

The buffer overflow exploit is very much alive.

Regards.

I have not used TestKing, but from what I've read they are "braindumps".  That is, Test King pays people to take the actual test so that they can write down the actual test questions.  So, unless they've changed their methods, using TestKing is cheating.

If you want to write buffer overflow exploits, you need to learn C and assembly.

The standard introductions to buffer overflows are:

• Smashing the Stack for Fun and Profit
  http://www.phrack.com/issues.html?issue=49&id=14&mode=txt
• How to Write Buffer Overflows
  http://insecure.org/stf/mudge_buffer_overflow_tutorial.html

Once you've mastered this, you can move onto advanced techniques.  Read the papers in the list below and follow the references as they suits your interests.  Setup a Linux or FreeBSD box with no buffer overflow protection (No non-exec stack, PaX, W^X, etc, ProPolice, etc) so that you can practice.  I used FreeBSD 4.x and 5.x when I did most of this.  As you get into the material about defeating the different protection mechanisms, install ProPolice on BSD or non-exec/Stackguard on Linux.  Can you get around them?  It's good to understand PaX (which was eventually discovered to have a major flaw) and W^X, but you don't need to worry too much about defeating them in the wild.  You're more likely to encounter stack based protection such as Stackguard or Microsoft's /GS, a non-executable stack, and/or stack randomization.  It will take you months to read all of these papers and to practice using at least some of the techniques, but if you can get through them all you will have some real expertise in exploiting buffer overflows. 

Be sure to read the Bugtraq list.  Look at the exploits that are posted and try to understand what they do.  Good luck.

Metasploit can be helpful in creating exploits and shellcode, but I think you'll learn more by doing things yourself.  That said, there is nothing wrong with using it to speed things up once you master the basics of writing exploits and creating shellcode.

Good luck.

• w00w00 on Heap Overflows
  http://www.w00w00.org/files/articles/heaptut.txt
• Taking Advantage of Non-terminated Adjacent Memory Spaces
  http://www.phrack.com/issues.html?issue=56&id=15&mode=txt
• The Frame Pointer Overwrite
  http://www.phrack.com/issues.html?issue=55&id=8&mode=txt
• Bypassing Stackguard and Stackshield
  http://www.phrack.com/issues.html?issue=56&id=5&mode=txt
• Defeating Compiler-level Buffer Overflow Protection
  http://www.usenix.org/publications/login/2005-06/pdfs/alexander0506.pdf
• Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server
  http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
• Getting around non-executable stack (and fix)
  http://seclists.org/bugtraq/1997/Aug/0063.html
• Basic Integer Overflows
  http://www.phrack.com/issues.html?issue=60&id=10&mode=txt
• Exploiting Format String Vulnerabilities
  http://doc.bughunter.net/format-string/exploit-fs.html
  http://julianor.tripod.com/bc/formatstring-1.2.pdf
• More info on format bugs
  http://julianor.tripod.com/bc/kalou-formats.txt
• Defeating Solar Designer's Non-executable Stack Patch
  http://insecure.org/sploits/non-executable.stack.problems.html
• Advanced return-into-lib(c) exploits: PaX case study
  http://freeworld.thc.org/root/docs/exploit_writing/p58-0x04.txt
• Bypassing PaX ASLR Protection
  http://www.phrack.com/issues.html?issue=59&id=9&mode=txt
• Vudo Malloc
  http://www.phrack.com/issues.html?issue=57&id=8&mode=txt
• Once upona  free()
  http://www.phrack.com/issues.html?issue=57&id=9&mode=txt
• Overwriting the .dtors section
  http://synnergy.net/downloads/papers/dtors.txt
• _atexit in Memory Bugs
  http://doc.bughunter.net/buffer-overflow/atexit.html

Learning Perl and/or Python is important for your long term skill set.  If you've got security responsibilities right now, I'd skip the programming until you're up to speed in some other areas.

First, learn TCP/IP if you haven't already.  I recommend W. Richard Stevens TCP/IP Illustrated volume I.  Some of the stuff on Ethernet is dated, but the book is wonderful.

After that, explore the areas of network security that are most applicable to your responsibilities.  I'll suggest several books to start, but supplement your book reading with experimentation and online research.  A topic that is interesting to you may only get a half a page of coverage in a book, but there are probably more in depth articles available--use Google.

For IDS, install Snort on a test machine.  Read Network Intrusion Detection by Stephen Northcutt.  The book is several years old so you'll want to supplement it with the Snort documentation. 

For penetration testing and applied security concepts, read Hacking Exposed and play with some of the tools in a test environment (don't scan/probe/attack any system without permission.)  Other posters may recommend Counter Hack Reloaded instead; I've heard good things about it, but I haven't read it yet.  Either book should be fine.  Also, install Nmap and read the Nmap documentation.  Make sure you understand the different scanning modes and OS detection.

For perimeter security, read Inside Network Perimeter Security by Stephen Northcutt.  Try to get your hands on a router that you can practice configuring (if you don't have significant experience already).

For Windows-specific information, reading Hacking Exposed Windows.  Also, Google and read "A L0phtCrack Technical Rant".  Make sure you understand the difference between LM and NTLM and how to turn off LM hashes--Google is your friend.  Experiment with the tools in a test environment.

For Unix-specific information, I'm hard-pressed to make a recommendation.  I enjoyed Practical Unix and Internet Security by Gene Spafford, but my copy is from 1996.  There is a 2003 edition, but I have not looked at it. There are other Linux-specific books available that may be more helpful to you.

I apologize that some of the books I recommend are a little old; my recent reading has tended to focus rather deeply on narrow areas rather than on general material.

Best of luck to you.

Perl and Python are available on most Unix systems and are very useful for writing tools and automating tasks.   One reason they are so popular is that they don't take a long time to learn (for the basics) and you can write simple tools with a minimal amount of code.

I did application security testing in my last job and I used Perl to write several network protocol fuzzers.  Using Perl, I was able to write the tools more quickly and with less code than I would have been able to in C/C++ or Java.

I would suggest not trying to demonstrate it.  Normally BGP Hijacking causes a denial of service attack.  The new method uses AS path prepending so that it can send captured traffic to the real destination; originally, the hijacking AS became a black hole for the captured traffic.  Unless you're really familiar with BGP and with the details of the attack, you're probably just going to cause a denial of service attack.

As I understand it, the attack allows a rogue BGP router to advertise IP addresses that it doesn't actually deliver to.  An attacker wouldn't actually send malicious traffic to your site.  Instead, he'd tell other sites he can deliver to your IPs, read or modify the traffic that is sent to him, then forward it on to your network.  Unless you checked the global BGP routing table, you probably wouldn't notice anything except some extra latency.  To demonstrate the attack, you're going to need BGP routers on two different ASes: one victim and one attacker.

Unless you're an ISP, you can't prevent this attack.  In order to prevent this, ISPs are going to have to be more aggressive about filtering what their neighbor ASes advertise to them.  The best thing you can do is to research the issue so that you and your organization understand it and then contact your ISP to see what they are doing to prevent such attacks--probably, they should be doing some filtering on the advertisements they accept.

That said, I'm not a BGP expert.  What I've said here is based on my own readings about the attack.  If there is anyone on this forum who can offer some more insight (or corrections), I'd be much obliged.

The paper about the attack is located here:

http://blog.wired.com/27bstroke6/files/ballani_et_al_ip_hijack.pdf