[ I post this *not* because I'm tired of telling so many people the same
thing, but rather figure it's interesting info. Considering if one person
asks about it, there's probably 10 people who don't ask ]
I've recieved a large number of requests, especially in the last 4 days,
asking various topics, such as what programming languages I recommend,
what books I think are good to start with, and in general how to go about
establishing oneself in the security community and acquiring the knowledge
to be in that position. Since I have a little different take than the
normal suggestions, I'm going to spew them for all to see. Note that a
lot of this is various parts I've emailed of to individuals.
------------------------------------------------------------------------
Where to start
------------------------------------------------------------------------
This is where I'm going to offer a very different opinion. If you are
just starting, I suggest you *NOT* look at Technotronic, Bugtraq,
Packetstorm, Rootshell (is this still active?), etc.
Yes, *DON'T* start there (although they're good sites and that doesn't
mean you can't visit them. :)
The reasoning is simple: if your idea of knowing 'security' is knowing the
latest exploits, you're going to find yourself not knowing much. Granted
it's nice to know what's broken and what's not, but it's not going to give
you a solid foundation of knowledge to build on. Great, you know RDS is
the latest rage. You know how to download and run the script. You know
how to patch it (maybe). 3 months from now, the patches are widely
distributed, the issue becomes old--now what good is the knowledge you
have? Let alone how much of the issue did you understand?
Was your knowledge of the issue, or the exploit?
This is my biggest point to stress, and one that people seem to overlook.
So many people figure if they know the latest exploits, they know
security. NO! NO! NO! All that happens is that you know 'exploits',
*not* 'security'!
Example: You know about phf, showcode.asp, Count.cgi, and test-cgi. But
do you know in general what makes a CGI vulnerable? Do you know how to go
about coding a secure CGI? Would you be able to start guessing at
vulnerabilties in other CGIs based on that? Or are phf, showcode.asp,
Count.cgi, and test-cgi exclusively all you know about?
So I suggest that you *DON'T* start with exploits. Ignore they exist
(well, you know what I mean). What you need to do is start by becoming a
user.
------------------------------------------------------------------------
Becoming a user
------------------------------------------------------------------------
What I mean by this is that you need casual, general exposure. For
instance, if you're going to perform web hacks, do you even know how to
use the web? Great, you can open up Netscape or IE....you can type names,
know that .html is a webpage. You need to keep along this route...become
a power-user. Identify .asp and .cgi as dynamic. What's .php? What's
this redirect thing? Cookies? SSL? All these things that a normal user
encounters.
NO EXPLOITS! Just normal use. You can't be elite++ and ignore the basic
(boring) stuff. No free rides.
Ok, so you know this stuff inside and out. You have exposure. Before you
hack unix, you need to at least know how to login, logout, use the command
shell, run your normal set of applications (mail, ftp, web, etc). You
need to know the basics. Then you move onto becoming an admin.
------------------------------------------------------------------------
Becoming an admin
------------------------------------------------------------------------
Now you move beyond user realm, into more sophistication. Focus more on,
say, the webserver itself. What type of server is it? What's the
difference? How do you go about configuring it? Knowing the correct
answers to a lot of this means knowing how it works, and what it does. Do
you understand HTTP? The difference between HTTP 1.0 and 1.1? What's
this WebDAV stuff? Knowing how HTTP 1.1 virtual hosting works helps you
setup your webserver. Go deeper.
How about OSes. How can you hack NT if you never configured it? You
expect to crack an admin password without knowing how to run rdisk, manage
user names and passwords, etc? You expect to use RDS (commandline)
exploits when all you've used is the GUI? Again, you need to elevate from
admin to 'power-admin'. Fine, you can do add users in the GUI. Are there
other ways? What about the command line? And hell, what are all these
.exe's in your system32 directory anyways? What do they do? Do you know
why usernetctl needs to be suid? Do you even need usernetctl? Go deeper.
Become intimate. This is key. Don't know enough to get by....know as
much as you can find out. Become a guru. But note....
------------------------------------------------------------------------
You can't know everything
------------------------------------------------------------------------
Alas, it's a sad fact of life. Don't think you can...if you think you do,
you're fooling yourself, and you're probably spread thin. What you need
to do is pick an area where your interests are most heavy, and learn more.
Become a user. Become an admin. Become a guru. Become the de-facto #1
guy/gal on anything to do with that topic. Don't just learn how to use
the web, how to write a CGI. Know HTTP. Know what web servers are
supposed to do. Know where to look. Realize when they don't do what
should be done.
By knowing your subject intimately, you'll then automatically know how to
exploit it.
It's that simple. If you know all the ins and outs, well, security is
included in those ins and outs. And not just the latest exploit
either...all past, and future exploits. You may even find stuff (while
becoming a guru) that's unknown. Wow, you. Finding exploits. Yes. But
you have to understand what your looking at and how it works before hand.
So put down that copy of whisker, and go learn what CGI actually is, how
that affects HTTP, how webservers implement it, etc. Then you'll
understand what it does.
------------------------------------------------------------------------
Programing languages
------------------------------------------------------------------------
Couple of things I was recently asked. First one being what programming
languages do I recommend:
I guess it depends on a few things--mostly how much time you want to sink
into it, how useful you want it to be, how fast of a turn-around you want,
and the complexity level of which you want to be involved. Choices are,
in no particular order:
Visual Basic.
- Pretty easy to learn, many books on thhe subject, many free code
repositories on the net. You should also be able to get the hang of it
pretty fast as well. However, there's some glass-ceiling issues with the
language, you don't have as much power as, say, c++. You also need to get
a copy of VB (warez or legit...but it's not free in general), and you're
limited to Windows. And coding exploits and patches is going to be rough.
C++
- Probably the most powerful of languagees. Exist on practically all
platforms, tons of books and stuff on the net about it. Freeware
compilers for all platforms, so you can get the tools to get you started
dirt cheap (free). A little more complex than VB, may take some more time
to initially get the hang of. Basic stuff is easy, but more complex
object-oriented stuff definately requires a little concentration. This is
your all-around average choice.
Assembly
- Ultimate in complexity, will probably be overly-hard to learn as a first
language. However, you learn this first, everything else is cake. ;)
Some books, support for it is diminishing, but knowledge of asm is crucial
for things like buffer overflows and exploits. Pretty much freeware for
all platforms, but it's *tough* to get the hang of.
Perl
- Not a bad language. It's easy like VB,, so pickup on it is relatively
quick. Does have glass ceilings like VB, however. But it runs on most
platforms (unix and win), so that's a bonus. Lots of books on it (the
O'Reilly 'Camel' books kick ass), and it's free. You can code some
exploits with it...general stuff, but it's meant more for manipulating
text stuff, not binary.
So I guess it's all in what you want to do. Safest bet is C/C++.
-------------------------------------------------------------------------
Recommended books
------------------------------------------------------------------------
Another question is what books do I recommend:
I personally keep the following on hand for reference:
Applied Cryptography (Bruce Scheiner)
Linux Application Development (Mike Johnson and Erik Troan)
Windows Assembly Language and Systems Programming (Barry Kauler)
Perl Cookbook (Tom Christiansen and Nathan Torkington) (O'Reilly)
Linux Programmer's Reference (Richard Petersen) (Osborne)
All the O'Reilly 'Pocket Reference' books, which include vi, emacs,
python, perl, pl/sql, NT, javascript, sendmail, tcl/tk, perl/tk
I typically always dip into the above on a regular basis.
As a general rule of thumb, most O'Reilly books rock. Find one on an
interesting topic and go to town. :)
(
geocities.com/eljehad1)