Hanging out on boards, IRC, reading hacker publications will get you access to exploits of others. If you want to develop your own zero day exploits you need to become a really really great programmer. Then gain an understanding of the layers that live between the publicly accessible part of an application and the core system you want access to (usually the OS). Learn everything you can about those layers and how the creator has protected the system from unauthenticated users.
Sometimes you're dealing with completely open source apps. These are more secure but the plus side is that you have access to all uncompiled source code.
Sometimes you're dealing with all or part of the stack that is proprietary. These are sometimes less secure but you don't have access to easily readable source code so you need to use special tools to figure out what the creator has done to protect the system.
If you're trying to get into a specific system, intuition often helps you choose where to spend your energy first. You'll have a feel for what code has the least eyeballs on it or the less competent developers writing it, or less frequent updates so you look there first.
FYI there are two kinds of zero day exploits. The first is one you just discovered and no one knows about it. I think of that as true zero day. The second is one that fits the classical definition of the developer having zero dev days to fix it because they haven't been told yet, but many other folks may know about it. Discovering a true zero day security hole is very hard and getting harder because of the bounties being offered now. Often regular zero day holes are discovered by others who got hacked using it and simply back-tracked the hackers steps.
Hope that helps. I'm the developer of Wordfence, a security plugin for WordPress. Also disclosed the timthumb wordpress vulnerability last year and fixed the hole by rewriting timthumb.
Sometimes you're dealing with completely open source apps. These are more secure but the plus side is that you have access to all uncompiled source code.
Sometimes you're dealing with all or part of the stack that is proprietary. These are sometimes less secure but you don't have access to easily readable source code so you need to use special tools to figure out what the creator has done to protect the system.
If you're trying to get into a specific system, intuition often helps you choose where to spend your energy first. You'll have a feel for what code has the least eyeballs on it or the less competent developers writing it, or less frequent updates so you look there first.
FYI there are two kinds of zero day exploits. The first is one you just discovered and no one knows about it. I think of that as true zero day. The second is one that fits the classical definition of the developer having zero dev days to fix it because they haven't been told yet, but many other folks may know about it. Discovering a true zero day security hole is very hard and getting harder because of the bounties being offered now. Often regular zero day holes are discovered by others who got hacked using it and simply back-tracked the hackers steps.
Hope that helps. I'm the developer of Wordfence, a security plugin for WordPress. Also disclosed the timthumb wordpress vulnerability last year and fixed the hole by rewriting timthumb.