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

Well, I certainly didn't intend to make anyone feel down.  I've been working at this for more than ten years; there just aren't any security jobs (zero) within an hour of where I live.  I wanted to know where I stood.

Oneeyedcarmen, I do wish you the best in your endeavours.

I don't trust them, but my dog keeps digging up the mason jars I buried.  What can you do?

I don't think we'll be able to get away from it anytime soon, but there are some things that can be done to make it safer. 

On some of the sites I use, the site sends an email with a unique URL to the address that I registered with.  After clicking the link, I still have to enter some personal information.  This isn't perfect--someone could have already compromised my email--but it's better than letting me reset the password entirely in-band.

Sites also need to log IP addresses when a reset is requested and monitor post-reset activity.  If your banking password is reset, the bank should not allow your account to transfer all of your money to another account or allow a transaction that is 10x normal without actually calling you to make sure everything is okay.

One thing I do to protect myself is to use information that is not true, but that I can remember.  You can't get the answers to my questions by going to my MySpace page.

Thanks guys.  I appreciate the assessment.  I wanted to make sure I wouldn't be wasting my time. 

I realized after reading ChrisG's response that I really needed a website that I can send potential employers to so I set up a site on Google with my resume, publications, and a personal statement.  I hope it helps.

Regards.

I'm planning to start applying for some security jobs soon and I'm hoping for a little advice.  I have never had a full-time security job, but I have had security responsibilities and would (ideally) like to land an intermediate-level position. 

Is this possible, or do I need to put in some time in an entry-level position first?

My justification for wanting to do this is that I think my technical skills are much more in line with an intermediate-level position.

I have 6 years of full-time experience in networking, programming, and IT management.  My responsibilities have included managing an IDS and performing product security testing.

I'm Security+ certified and plan to pickup the C|EH soon.  I've taken Foundstone's Ultimate Hacking: Expert course.

I've published several articles (in print) on buffer overflows and other security topics and have also contributed to several Wikipedia articles.  I can write exploits and shellcode and can use advanced techniques to bypass StackGuard, PointGuard, no-exec, ProPolice, etc.  I can also find and exploit other vulnerabilities such as as SQL injection and XSS.  About eight years ago, I reported several vulnerabilities on Bugtraq.  I spoke at Defcon around the same time. 

I know TCP/IP really well and have spent hundreds of hours analzying traffic with tcpdump, Ethereal, Wireshark, and Snort.  I've created a lot of custom traffic (for product security testing) using Hping2, Packit, Nmap, fragroute, and my own protocol fuzzers .  One of my work projects required me to analyze and qualify signatures for Snort and the Cisco IDS.  I documented dozens of the signatures in the Snort project.

I've been using Unix for 14 years and can comfortably manage BSD, Linux, and HP-UX.  I have some Windows server experience (and a lot of desktop), but no Active Directory.  I have experience with Cisco routers and switches, HP switches, and Foundry layer-4 devices.  I'm comfortable with Unix firewalls but have no hands-on experience with commercial firewalls.

My knowledge comes mostly from personal projects and reading--I've read more than a thousand articles and conference/journal papers on security (and hacking) over the last ten years.

So, what should I aim for?

If you think I'm getting ahead of myself, say so.  If I should go for an intermediate-level job, how do I get past HR?

There are two things that I think you need to impress on your employers.

1) Someone can eventually find a way in.  An attacker only needs one misconfiguration or unpatched vulnerability to get access to some system.  Even if you have good security practices and are patched up-to-date, a new exploit could be released tomorrow that leaves you vulnerable to every script kiddie who decides to take a poke at you.

2) Once an attacker gets in, he usually wants to keep his access and move to other systems within the network.  The primary means of expanding his access are cracking passwords, or otherwise stealing credentials from the first machine, and sniffing the network to get other credentials.  Many people don't believe that it's possible to sniff switched networks, but many also think the Earth is flat.  Tools such as Cain and Abel, and Dsniff have made sniffing on switched networks relatively easy.

Good security isn't only about keeping the bad guys out, it's also about containing the damage once they get in.  If an attacker gets into one machine and can then sniff FTP, telnet, POP, LM/NTLM, you're wide open.  If he gets in but has limited network access (due to firewalls, VLANs), is unable to crack the passwords on the system, and can't sniff any useful traffic, he has a much more difficult task ahead of him.  That's not to say that he can't still own the whole network, but it raises the bar significantly in terms of skill and time.  Increased time is increased risk for the attacker; the longer he is logged in and putzing around on your systems, the more likely he is to get caught (especially if you have good logging and some IDS in place.)

Cheers.