Inguma 101

Hello again!

Previously we covered Inguma a little, or rather the Krash part of Inguma, but it has some nice full features and once you are familiar with the command and parameter syntax, you really get a good idea of just what it is capable of.  FYI you can view the Inguma wiki in its entirety here.

Some people might call this plagiarism but hey, I wrote the wiki so I can do this! Anyways, below is a beginner friendly tutorial for Inguma. For those of you that do not know what Inguma is, it is a platform-independent penetration toolkit written in Python. It is also the project I work on in conjunction with another developer. So for the sake of using my blog as an advertising platform and introducing some people to a program they might not otherwise have found, let’s start.

After obtaining the required dependencies as noted on this page, you are set to run Inguma. Please be advised that Inguma must be run as root or with superuser privileges (*nix based systems) in order to utilize it’s full capabilities. For the curious, this is necessary as certain functions require raw sockets and other goodies which are often restricted by user and/or group rights. As the PyQT GUI is currently less than stable, this usage overview will be handled through the CLI. Be aware that all instructions are relative to your OS outside of the inguma environment, when working from the inguma> prompt you should be able to follow these examples verbatim without error. This tutorial also assumes you are smart enough to make it this far so if finding out whether or not a port is NAT’ed means nothing to you then prepare for a serious learning curve with the program’s more robust functions.

Starting Inguma
Unless you have created a symlink for Inguma, we will assume that it will be executed as a python script from the working directory.

user@host:~/inguma$ sudo ./inguma.py
Inguma Version 0.0.6
Copyright (c) 2006, 2007 Joxean Koret

inguma>

As with any application, referring to the program’s help manual always eases learning. When working with Inguma, the help option can be accessed from almost any prompt. As we move through the tutorial you will see that our prompts may change depending on which module we are using.

Using Inguma
Inguma’s module layout can be thought of as sequential with regard to execution. It is for this reason that we will first work with the discover modules. Before continuing it must be stressed that various modules should only be exercised on systems you have permission to target. Auditing systems that you are not authorized to work on most likely breaks quite a few laws and could land you in an unfortunate predicament. With that out of the way, let’s continue our tutorial.

While the importance of the discover modules is not to be diminished, it is safe to assume that you most likely have a target as well as some prerequisite information about that target. With that in mind, we will move to the gather modules. The gather modules serve to collect information about your target so that you can better evaluate its security. One of the most basic and useful gather modules is portscan. Let’s run a portscan on the machine we wish to check.

inguma> target = “uberserver.com”
inguma> show options
inguma> scanType = “S”
Options

Target: uberserver.com
Port: 0
Covert level: 0
Timeout: 1
Wait time: 0.1
Wizard mode: False

Note the use of the show options command. This is helpful in case you somehow manage to forget
what the hell it was you were doing or to verify your target parameters. We also set scanType = “S”.
This sets our portscan as a SYN scan as opposed to ACK, XMAS, TCP, etc. This option is
planned to be fully available in the 0.0.7 release.

inguma> portscan
Portscan results

Port 80/www is opened at uberserver.com
Port 7777 is opened at uberserver.com
Port 8080/webcache is opened at uberserver.com
Port 21/ftp is opened at uberserver.com
Port 9090 is opened at uberserver.com

Now that we know what ports are open on our target, we may want to refer to a discover module, isnated.
Isnated does what the name implies, finds out whether or not the specified port is NATed.

inguma> port = 80
inguma> isnated
Port 80 is NOT NATed
inguma>

We have now established that port 80 is not nated, the next thing we want to do is to gather information
about the service running on port 80. For this we will utilize the gather module, identify.

inguma> port = 80
inguma> identify
Port 80 : Apache/2.2.4 (Ubuntu) DAV/2 SVN/1.4.4 mod_perl/2.0.2 Perl/v5.8.8

This is currently where the tutorial ends. It does not delve into the program’s exploitative capabilities and payloads. This is done under the assumption that if you have made it this far, you know what to do next. In the event that you find yourself stuck, you can always refer to the source code or the help command. As noted above, whenever your Inguma prompt changes, i.e. inguma> to SNIFFER>, there will be a help command displaying any/all available options.

That’s all I have for now, but far from all this program has to offer. Check it out, take it for a spin, find some bugs and give feedback if you are so inclined! We love to hear back from users, both good and bad comments as it helps us to build a better application.

Stay classy.

Dissecting the Web With Burp Proxy

First off, this is a long post so go get coffee.

For those of you that aren’t familiar with it, or programs like it, Burp is a local proxy similar to Paros which acts as a middleman intercepting HTTP/S requests and allows the user to inspect and manipulate the traffic traveling from the client to the server and from the server to the client.

Today we will be going over exactly what the title implies, testing web applications. The tools today will be: Apache 2, Tomcat 6, Burp Suite v1.1 and Firefox. Since we are going to be looking at raw HTTP traffic, this post has officially been renamed “raw-ass web app skillz.” Don’t worry, the material still remains the same.

Fulfilling the prerequisites can be a bit tricky, so for those of you on Ubuntu/Debian systems, let’s get you caught up.

You will need a working Apache 2 install so:
sudo apt-get install apache2

For a quick and easy Tomcat install, click here.

Burp which can of course be downloaded here

And firefox which you should already have.

We will be using our Tomcat install to run an insecure web application developed as part of the Insecure Web App Project developed by OWASP. And last but not least, the web application we are going to be using can be located here.

So, let’s go over our checklist real quick:
Firefox
Burp
Apache2
Tomcat6
OWASP Web Application

Since it looks like you have everything we should probably keep moving.

**I would like to take a minute to say that since you have Apache and Tomcat running, for this exercise it is NOT necessary to forward your webserver or otherwise expose your Apache/Tomcat service(s). These tests will be done on the loopback IP and since we are working with an already insecure web application, you do NOT want it exposed to the internet**

Now we are actually going to start the overview (I’m serious).

The first thing we need to do is tell Firefox that we are using a proxy, the proxy on localhost to be more specific. This will allow us to funnel our traffic through Burp. To do this we need to start Burp from its working directory and set our proxy settings in Burp as well as Firefox.

user@host:~/burpsuite_v1.1$ java -jar burpsuite_v1.1.jar

When the Burp window appears, you should be on the intercept tab, you will notice that intercept is on. This means that Burp will be grabbing our requests and holding them until we forward them. You may also drop them or hold them until you are finished inspecting them. Burp will also keep a history of all traffic for later analysis. In the options tab, check the box that says “proxy running on port,” and change the port to 7070. By default your Tomcat install uses port 8080 so if you do not change this, you will receive an error telling you that it could not use port 8080.

Once you have your proxy settings done on Burp, we need to fix them in Firefox. To do this, open up Firefox and then navigate to, edit > preferences > advanced > settings. Set it up so that your proxy settings look the same as those pictured below. Be advised that you need to remove the line in the field, “No Proxy for,” as it will not push traffic trough Burp on localhost. Once your settings match those in the picture below, click “OK” to save your changes.

With our proxy configured on both the browser and Burp, it’s time to navigate to our web application. If you haven’t checked it, read the documentation contained within the OWASP web application we downloaded for this exercise. In case you are lazy (there are a lot of you out there, admit it) I took the liberty of quoting the document.

1. Copy insecure.war file to tomcat’s webapp directory
2. Start Tomcat then use sqltest.jsp to test Tomcat’s database connection.
sqltest.jsp
You should see a list of users and passwords that you can use to login into the application.
Note the application’s database tables are reset to the initial values each time the application is started.
3. Login to the application
Login

Be advised that if you click those links in the Firefox that is configured for our local proxy, they will not load unless you forward the traffic with Burp. We will get to that later but for right now, just copy insecure.war to Tomcat’s webapp directory. If you followed the tutorial that directory is going to be ‘/usr/local/tomcat/webapps.’ Again, for the lazy please run (where insecure is the directory you untar’ed the web app):

sudo cp ~/insecure/insecure.war /usr/local/tomcat/webapps

Let’s start examining our web application in Burp. The first thing you should do is go to your Burp window and turn off intercept. This way we can load the page right away. If you don’t want to turn it off, make sure you click “Forward” until the page loads. Once you are at the application page, go back to Burp and turn intercept mode on. In the proxied Firefox browser navigate to http://127.0.0.1:8080/insecure. If things are working per the tutorial, your browser should look similar to the picture below.

So, right now you should have that pictured page loaded and Burp in interept mode. In case you got lost finding it, it is under the Proxy > Intercept, tabs.

Now, let’s try and log into our web application with anything we choose. This request will need to be forwarded manually through Burp proxy. After you enter a username and password of your choice (make sure it is invalid), click login.

Per usual, this request will need to be forwarded through burp and even though it is not in our immediate window, we can view the contents of it in our history tab. In the screen shot below we can see the raw information on our request under the raw request tab. How appropriate especially since this entry was officially named “raw-ass web app skillz.”

As seen in the shot above, we can examine some detailed information about the request/reply using out history tab. This is pretty normal to be honest and could most likely be viewed via TCP reassembly in Wireshark even though it is not as straight forward.

Now, let’s examine real authenticated requests. If you followed the instructions and clicked sqltest.jsp, you most likely saw a table listing valid login information. For the lazy, see below.

USERID LOGIN PASS NAME EMAIL ADMIN
1 admin secret Administrator admin@mail.com 1
2 asmith andy Andy Smith andy@mail.com 0
3 bmoody beth Beth Moody beth@mail.com 0
4 cjones chris Chris Jones chris@mail.com 0

Let’s use the 2nd login info, because that is my name. Log into your application with the userid ‘asmith’ and the password ‘andy.’ When you are logged in, you will see something interesting. Well, not necessarily all that interesting, but a different page at least. This is the page for our Asmith. Why is this important? We are going to examine that request, which unlike our first, was a valid authentication. From there we will see what we can make happen with parameter tampering, actually, you will be doing that without me.

Now, I will spare you the details but the GET requests are relatively the same. The only major differences are those based upon submitted login credentials. The first point of interest is the response. Why is this interesting? Well, that is actually where this tutorial ends.

I believe that best way to educate someone is determined by their desire to learn. If you paid attention to this post you should have learned a lot such as setting up and installing Tomcat, adding a web application and working with local proxies. On that note, figure out why you should care about the response and request information. Dissect the application further and be sure to check the supplied information on the OWASP web application for additional practice tests like parameter tampering and SQL flaws.

In the mean time, don’t learn to hack, hack to learn!

P.S. If you are interested in more program features which are WAY beyond the scope of this post, be sure to stop over at the Burp page and read up on this awesome program’s features and capabilities.

P.P.S If you have read this far I am assuming you are probably at least relatively interested in the subject matter covered. If you want to learn more about auditing web applications with Burp leave a comment and if the response is solid, I’ll do a part 2 using the same setup and application(s).

P.P.P.S Good lord. This is the last edit I am going to make to this post but in the event that anyone is really fascinated by this, make sure to check out the OWASP Testing Guide.

Forgive me!

I’ve been busy lately!

I plan on working up something cool soon.  Maybe dissecting the web with Paros Proxy, some cool TCP reassembly with Wireshark, Inguma module usage or tactical target reconnaissance.  In the mean time, play with this.

Share the knowledge and use it responsibly!

HTTPSuper Solution?

A lot of security professionals know there is no solution to insecurity.  There are remedies and precautions one can take, but as long as networks and servers and databases and all that other fun stuff that help to serve up YouTube videos to make the work week go by faster are around, there will always be infiltration.

Now, I don’t care to distinguish between the ‘hats’ hackers wear, because in the end, exploitation and infiltration are just that.  Kind of an, ‘it is what it is,’ situation.

One of the biggest concerns I have is the amount of blind faith people put into  security safeguards, particularly SSL and HTTPS. For those of you that don’t know, a quick Google will tell you that SSL stands for  Secure Socket Layer.  HTTPS is  HTTP over SSL and the basic concept is that SSL encrypts data between the client and server, thus making it impossible for anyone to ninja your communications in transit.  At least that’s the theory.  Imagine 2 people standing at opposite ends of the room  shouting a conversation  across the  place and no one other than those 2 people know what the conversation is about.  Pretty awesome eh?  As with most technological solutions, this is easier said than done.

Now, when people tell you “Never submit your credit card information unless you see HTTPS in the URL,”  it’s like saying “don’t take candy from strangers.”  I’m not saying this isn’t good advice to follow, but  you should never put it past your friends, or people that act like friends, to poison you, at least I don’t.  As of yet, hackers have yet to find a way to physically poison someone over the internet (give them time) but HTTPS does not mean that the connection is to be trusted.

So, if encryption is the ‘magic bullet’ of security and it will stop any attacker in his or her tracks, why am I even writing this post?  (Don’t you love my clever use of rhetoric to guide the reader into following the post the way it was written?)  Well, if you haven’t caught on yet, SSL is not all it is cracked up to be.  Beyond merely encrypting information, SSL certificates give you the ability to validate the website or rather approve the site you are visiting.  We may or may not talk about that more, we’ll see how this goes. =P

There are certain attacks known as man in the middle attacks which are pretty obvious from the name alone.  A MITM attack is when a third party is able to adulterate an active or stateful connection and either hijack that connection or read the data being transmitted. Now, MITM attacks range from incredibly simple (ARP poisoning) to pretty complicated (SSH session hijacking and other forms of credential theft).

These attacks aren’t really why SSL/HTTPS has some flaws nor are they what this post is about. The biggest problem with SSL and HTTPS is that even though they encrypt your data in transit and allow you to validate the site you are visiting, they guarantee nothing as far as what the individual on the receiving end will do with your data. This is usually pretty obvious to most hackers but it isn’t necessarily something that occurs to the average PC user.  It may seem that if you can trust the connection, why can’t you trust the destination?  Let’s look at this a bit more in depth.

Now, when you connect to a website that uses HTTPS, you most likely are prompted to accept a security certificate like the one seen below

Now, first of all let’s look at the most glaring detail of this certificate, the .MIL extension.  That’s military and probably best left alone so don’t be an idiot and screw with it at a later date in time.  You will also notice that it says, “the signer(s) are not registered.”  This may seem like common sense as this blog caters to people with an  existing base of security knowledge but all too often things like this go unnoticed by the normal user.  In reality people cannot bear to have to actually see security measures, so rather than making sure their information is going to be transmitted to a trusted individual and/or site, they click whatever they need to click so that they can order some really cute pencils as fast as humanly possible.

With that security certificate we can assume that a government issued security certificate can be trusted (relatively speaking).  The real problem arises with the fact that pretty much anyone can add SSL capability to their website and issue their OWN certificates pretty inexpensively.  The initial idea behind SSL certificates was that they would be issued by a trusted third party.  To clarify, someone other than the server and client would issue the certificate as kind of an…impartial but trusted party.  The problem with third party certification is that it costs money and since we know most people click away whatever gets in the way of them and their eBay auctions, it doesn’t need to be legit!

Let’s do a quick and somewhat inaccurate example of how this technology can exploit the ignorance of the general public.

**Disclaimer** DO NOT actually set something like this up.  If you do, I am in no way responsible.

I can create a web page that advertises microwaves for $5.00.  Who wouldn’t want a $5.00 microwave?  Anyways, I can also enable SSL on my server and create my own certificates.  This is also a rude assumption to make as it preys on their…stupidity for lack fo a better word (that is the nature of the beast), but I am going to assume that anyone who thinks a $5.00 microwave is a good investment won’t be reading the security certificate (I can’t help myself).  To this user it appears as though I am providing a legitimate service and doing so in a way that will encrypt their data so that they get their microwave, I will get my $5.00 and life will be excellent.  The reality of the matter is that I don’t care if 90% of my site’s visitors don’t buy because of my willy-nilly certificate.  Eventually someone will be dumb enough to buy a microwave and since the best tactics are to hit and run, once I have just one credit card number, I can take off and set up a new site, selling something totally different, financed and built with the person’s credit card who was silly enough to give me their information.

In closing, think like a criminal, don’t be one.  Share the information and for the love of all things sacred, check your SSL certificates.

Slow-mo!

I should really think of some good content for this blog.  I could always just grab a new and exciting article from one of my many bookmarks, but there’s already a lot of blogs that do that.   It’s not that I’m lazy, it’s my journalistic integrity!

Token Fuzzing With Krash

Krash is a pretty slick and straightforward block-based fuzzing app.  Krash comes with the Inguma Package and is also written by the Inguma Project’s head dev, Joxean Koret. While there are a lot of good tools out there for fuzzing like SPIKE or Paros Proxy, Krash is a pretty quick setup and accepts parameters of raw packets and then tokenizes them. Every token the fuzzer is able to generate will be fuzzed. This approach is similar to block based fuzzing but a bit more “automagic.”

In this post, we will give a crash course in using Krash for fuzzing stateless protocols (cheesy pun, I couldn’t resist). The tools you will need are of course Inguma and all required packages (for good measure) and Wireshark. Really any tcpdump will do but I am partial to Wireshark so that is today’s tool of choice. We’ll only be using Wireshark for grabbing some raw packets to pass to Krash so there’s no need to be an expert on protocol analysis.

Let’s get started!

Assuming you have downloaded the Inguma package you need to navigate to the working directory where the Krash script resides.

user@host:~$ cd /inguma/krash

If you navigate to the ‘audits’ directory within Krash, you will see folders containing supplied raw packets which can be used to fuzz just about anything you see fit. If you take a moment to read the documentation, you will notice that Krash does not currently support cookies or stateless protocols so for today we will just be fuzzing a web server, particularly HTTP traffic. We will also be using Wireshark to get a raw HTTP packet. Since this is just example, let’s take whatever we find first.

First thing we need to do is open wireshark. Since we have picked our target (thanks to Vayde for donating his server as a test subject), let’s load the home page and grab the GET request for fuzzing.

In wireshark, start your packet capture on your listening interface.

After you have done that, start the packet capture and pull up the webpage in any browser you’d like. Now, if you aren’t familiar with Wireshark, you need to pick out the HTTP traffic, right click on the packet stream and select “follow TCP stream” from the menu.

Since we will be fuzzing the GET request, copy and paste that out of your window. It should look something like this:

GET / HTTP/1.1
User-Agent: Opera/9.50 (X11; Linux i686; U; en)
Host: CENSOREDHOST.com
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en-US,en;q=0.9
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Connection: Keep-Alive

With this securely fastened to your clipboard, open up a text processing tool of your choice and paste it into a blank document. Save the file as anything you’d like, for this example, let’s just call it ‘test_packet.http.’ Please note that to keep things simple and organized, this sould be placed in ~/inguma/krash/audits/webserver, since we are fuzzing an Apache server. Don’t expect to find much fuzzing Apache though since it is widely deployed and heavily audited.Let’s head back to the command line to commence fuzzing at once!

user@host:~$ ./krash.py audits/test_packet.http CENSOREDHOST.com 80 0


While most of that command is pretty easy to understand, the last 2 parameters specify the port number and verbosity respectively.

If/when you manage to find something of interest, Krash will halt and notify you of the last packet that might have caused the error in the event that you wish to recreate it.

Covers today’s brief entry on fuzzing.  If you like Krash, make sure to check out SPIKE and Paros Proxy as both can be excellent fuzzing tools.

Take care and share the knowledge!

Insight on the Security Mindset

I recently came across an interesting editorial written by Bruce Schneier in which he talks about the “twisted mind of the security professional,” and he is pretty dead on.

After providing a nice anectdote, Schneier talks about just what it is that motivates security professionals and it pretty much boils down to a proclivity for circumventing security measures.

Security requires a particular mindset. Security professionals — at least the good ones — see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.

And how right he is. I remember when I was around 6, possibly younger, I found myself mashing keys mindlessly on our old Commodore 64. Eventually when the computer returned “syntax error,” I was thrilled. Now, I had no idea what this actually meant but if I had to pick a moment of discovery, that would be it. This machine, which was hooked up to my television set, was talking back to me. My biggest curiosity no longer became getting a kung-fu fighting game to load, but rather what else I could make this computer say.  Beyond this, I wondered how I could take over the world with a Commodore 64 which was no simple task.  Some years later the internet became pretty popular, this was well before everyone had a PC in their house and America Online was THE internet service provider.  Sometimes I would call my friends to make plans only to dial the wrong number and be answered with a barrage of modem chatter, this too fascinated me.  The next thing I would do is to call that same wrong number with my computer and see what would happen.  This usually resulted in a login prompt which then lead me to ask, “how can I get past this stupid thing?”  Since any real exploitation was well beyond my mental capacity at the time I did what any curious kid would do, kept calling.

Anyone that knows me relatively well can tell you that this is expected behavior from me.  Eventually my random dialings came to an end when an unnamed company called my Mother’s house and asked what the heck was happening from her phone number.  Thankfully nothing went terribly wrong after she explained that I was simply a somewhat mischevious, albeit curious, 13 year old.

Even now, some 10 years later, I still find myself wondering how I can take over the world but in a much different sense.  My intentions with the knowledge I have gained are in no way malicious.  I accept that it is not my destiny to take over the world, whether it be through the internet or other means (maybe in another life).  However, the desire to learn more and continuing to question the secure protocols that make our world run is something that I will forever be fascinated with.

SmartWater is a liquid with a unique identifier linked to a particular owner. “The idea is for me to paint this stuff on my valuables as proof of ownership,” I wrote when I first learned about the idea. “I think a better idea would be for me to paint it on your valuables, and then call the police.”

Really, we can’t help it.

Heh, right again Mr. Schneier.

Now, if you tell people that your hobbies include breaking into computer networks (when given permission), planning how you would shoplift, get into the safe at your credit union or simply get a can of Coke out of the vending machine without paying for it, they tend to get a little nervous, even if you make it clear you have no intention of actually executing any of the above.

My mind often wanders into weird areas of curiosity and mostly when I am doing things that are relatively normal to other people.  One of my favorite hobbies is when my girlfriend asks me to go shopping with her (she really likes to shop), I look for all the security cameras.  I then ask myself how many of them are dummy cameras and then I look for the motion detectors and see if there any areas of the room that are untouched by them. Next on my list is where are the ‘employee only’ areas and how are they accessed.  Truthfully, I have absolutely no intention of either stealing or breaking into the store at a later date in time, but I just can’t stop myself from wondering or from developing the perfect plan that will never be executed.  In fact, I find myself playing these scenarios out in my head and beyond that, how security could be improved.

The secure mindset is interesting in the sense that it isn’t so much about creation as it is with disassembly. I often have a hard time explaining that to people. From time to time others in the open source community ask me for help with a PHP form or something similar or maybe a friend asks me to fix their computer. It’s odd telling them that you aren’t sure how to solve their problem, but once they get it solved and they need someone to break it, you’re just the guy to get in touch with.

This kind of thinking is not natural for most people. It’s not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don’t have to exploit the vulnerabilities you find, but if you don’t see the world that way, you’ll never notice most security problems.

Despite what people may think up to this point, I am really not a criminal (seriously), but I believe my greatest tool as a security practicioner, beyond any software or somputer, is having a somewhat criminal mind. I’d also like to say that it is that criminal mind that made my parents very nervous for quite some time.

The lack of a security mindset explains a lot of bad security out there: voting machines, electronic payment cards, medical devices, ID cards, internet protocols. The designers are so busy making these systems work that they don’t stop to notice how they might fail or be made to fail, and then how those failures might be exploited. Teaching designers a security mindset will go a long way toward making future technological systems more secure.

That part’s obvious, but I think the security mindset is beneficial in many more ways. If people can learn how to think outside their narrow focus and see a bigger picture, whether in technology or politics or their everyday lives, they’ll be more sophisticated consumers, more skeptical citizens, less gullible people.

On a final note, being as involved with the security community as I am, a lot of beginners often ask me, “how can I become a great hacker” or “can you teach me how to hack?”

I’ve often speculated about how much of this is innate, and how much is teachable. In general, I think it’s a particular way of looking at the world, and that it’s far easier to teach someone domain expertise — cryptography or software security or safecracking or document forgery — than it is to teach someone a security mindset.

This is often the hardest part to get people to understand. You do not simply just learn to hack. You learn to discover everything there is to know about these technologies. It’s not like you reach a point where you can access any private system at the drop of a hat or there is a well known exploit floating around for NASA databases. I like the quote, “don’t learn to hack, hack to learn,” it sums up the philosophy behind hacking pretty nicely.

Now, by no means do I encourage anyone to break into private systems and destroy data or rob a retail store (or any store for that matter) but in order to be an effective security professional, one who is one step ahead of the criminals, you cannot distance yourself from the criminal mindset.

In short, never stop learning, security is a continuing process not a state of being and lastly, be proud of what you have learned, even it makes other people nervous.

If you are interested in reading Bruce Schneier’s Wired editorial in its entirety, it can be found here.