This site doesn't display correctly in IE. I do my work in firefox and someone just pointed this fact out to me today. I HATE HTML with a passion. Anyone have any idea why this site is broken in IE and not FF? First person to comment with a fix gets a free beer the next time I meet them face to face ;)
Update: Looks like you all lose! I fixed it faster than a "Donkey on a Waffle". Turns out IE, being the lovely piece of uhhh.... poopie that it is, doesn't like width=50% for images. It adjusted the tables to the full size image even though I tagged the img as 50% width. Firefox gladly worked as intended, but IE is about as bright as a pile of donkey fecal matter.
Don't ask me why I spent effort points on this instead of working on my trip report and expenses, but... I did. The picture below is the "majority" of places I've had to travel since being a consultant (in blue), along with as many other major cities I can remember having visited. I think it's fairly extensive especially when you take into consideration that the blue ones have been relatively recent. Click on the image for a larger, easier to read shot.
Shmoocon is over. It looks like I was overly optimistic about blogging ANYTHING during my time at the event. I took less then a dozen pictures, some of which I'll post when I post my trip report. I did manage to hit a higher percentage of talks than I normally do, and the evening festivities were great. The highlight of the conference was hanging with former and current coworkers, the 0x90 and RIT crews, and generally seeing my once or twice a year buddies. I pretty damn tired at the moment and trying to recover.. I'll post more soon.
I am sitting in the breakfast area of the Wardman Park Mariott hotel in Washington DC eating an excellent eggs benedict. Today is the first day of Shmoocon, a hacker conference put on by the Shmoo Group. This is the third year of this conference, and having attended all three, I'm looking forward to seeing what this years tracks have to offer. I hope to blog and writeup my experiences for all to share!
Here is a pic of the lobby before things start picking up. Let the festivities begin!
I purchased and read "Thr3e" by Ted Dekker last weekend. The book is a psychological thriller in which a young seminary student, Kevin Parsons, is hunted by a serial killer. It all starts when Kevin is driving home from his university one evening and his cell phone rings. He is presented with a clue in the form of a riddle and is told he has 60 seconds to call the newspaper and confess his sins or his car will be blown up. He escapes the explosion of his car, but the next few days turn out to be the most difficult of his life. Being chased by a person who goes by the name of Slater makes the ensuing riddles and explosions an alluring read.
I couldn't manage to put this book down. Once I got far enough into the plot, it kept getting more and more intense. The author does a great job of keeping your interest throughout the narrative, however he could have done a little better job in wrapping up and linking in the riddles to the resolution. Overall, the twist at the end made me look like a complete clown in front of everyone else at the baggage claim in RDU airport when I actually said the words "NO WAY!" out loud. After looking up the reviews on Amazon and doing a bit of reading on the book, it turns out this is billed as "Christian fiction". I wouldn't have purchased the book had I known that in advance, however there really wasn't that big of a religious overtone that made me lose interest. One can safely ignore this misnomer if it would normally turn them off. Also of interest is the movie that was made out of this novel. It appears to have gotten horrid reviews, but we all now how accurate movie representations can be of good texts.
My advice to you? Ignore the bad movie reviews, forget the "Christian" label, and READ THIS BOOK! I believe this was one of the easiest to read, most interesting paperbacks I've read in a LOOONG time.
5 out of 5 DONKEYS!!
I've had many a client ask me what the term "fuzzing" meant. I have my pat definition on what fuzzing is and does, but I never knew where it came from.. until today!
-----------------------
There are quite a few stories on how the term fuzzing came to be.. fuzzy logic? Testing electrical lines? Not quite.
I spoke with Prof. Barton Miller a while back and just got to review what was said in our conversation for something I am writing, I figured I will share:
"In the Fall of 1989, I was on a dial-up modem to my campus computer. There was a big, midwest thunderstorm that was causing noise on the phone line (this was before error-correction modems), so it was a race to type a command before a stream of nonsense characters would interfere. I was surprised that these seemingly random characters would occasionally cause Unix utilities to crash. So, as one of my suggested projects in my graduate OS class (CS736), I assigned a project of writing a random character generator and testing as many Unix utility programs as possible. I called this random stream "fuzz", named after the noise on the phone line.
It had nothing to do with fuzzy logic nor any other field. And I'm not sure why I picked the particular word fuzz."
Gadi.
-----------------------
Thanks Gadi! I appreciate you clearing that up for me!
What makes a good penetration tester? That is the question of the day. First let's define the terms:
UPDATED 3/20
According to WikiPedia a "Penetration Test" is - a method of evaluating the security of a computer system or network by simulating an attack by a malicious user, commonly known as a hacker. The process involves an active analysis of the system for any potential vulnerabilities that may result from poor or improper system configuration, known and/or unknown hardware or software flaws, or operational weaknesseses in process or technical countermeasures. This analysis is carried out from the position of a potential attacker, and can involve active exploitation of security vulnerabilities.
First let me take this definition and refine it just a bit. We are going discuss specifically "application penetration testers" (APT). What is meant by that is that the broad scope of "network penetration test" is a bit more refined and focuses more on COTS applications and custom code. Many people consider this skill set to be what a "real" penetration test is. Anyone with a basic knowledge of computers can run nessus and create a report. It takes a certain skill and mindset to test at the application level. Some would even go so far as to say that what we really are talking about is a vulnerability researcher. So what makes a good "penetration tester" as we have defined it?
Technical skills
The exact technical skills required are largely dependent upon the applications being tested. Web application testing uses a completely different tool base and has many different attack techniques than say a windows binary product penetration test. However, the basic skills are the same. Understanding how applications are built, how code works, how to properly conduct threat modeling, abuses cases, determining areas of security analysis for a given application, and finally execution and creation of proof of concept are universal. This can all be taught. People can learn these skills. It is best to be intimately familiar with the target application if at all possible. If the tester is not already an expert in the application specific components, this process of familiarity typically takes place at the start of an engagement.
Ability to learn
Since applications and custom code are always so different, an APT consultant has to have the ability to learn quickly. Gather the resources and absorb them in a very short time. This is due to the fact that penetration test work is typically timed boxed. What is meant by that is that while the hackers have the luxury of infinite time, a paid consultant is limited to whatever the client is willing to pay. This doesn't apply to vulnerability researchers conducting work on their own time, but when someone is paying you for it I can just about promise you they won't let you test forever. You have to be able to learn FAST. It has to be in the consultant's nature to want to know, to want to learn, and to want to do it as rapidly as possible. "If I don't know it, give me 24 hours.. I will!"
The competitive drive
This is key. The drive to win. The drive to find a hole in everything you touch. Many people don't have this drive. Many people will give up at the first brick wall. Someone once told me that "Every application you touch is broken. It's up to you to find out where." This attitude that everything is broken in some way and that it is only a matter of time until it's found is the drive that a good APT consultant needs. This personality trait might best be described as stubborn or obstinance. There is nothing that is going to stop you from finding that vulnerability.
Creativity
I received a little feedback from Curq of 0x90 fame today. He pointed out another trait that indeed is something that is required of a good penetration tester. Creativity. A good penetration tester must be able to create, invent, and otherwise imagine new threats and attacks. Things aren't always going to follow the same old threat path, and invariably the attacker must figure out new techniques. That is where creativity comes in to play!
Experience
Last but not least is experience. The more an APT consultant has, the better they are going to be. It's just like anything else, the more time you have practicing the stronger your game will become. Penetration testing is no different. This isn't a requirement to becoming a strong penetration tester, however it is a good reference when looking to see how strong a tester may be.
That's about it. If a person has strong technical skills in the right areas, the ability to quickly learn, and that all important competitive drive, they can become a strong penetration tester. All that is required at that point is experience, and that just comes with time.
----Other areas of interest:
-What is the best way to teach someone to find vulnerabilities?
-What is the true value of a penetration test?
-Penetration testing is a function of time. Is there some magic amount of time that is typically enough? How do you properly scope an application penetration test?
-Is it possible to accurately quantify risks attributed to vulnerabilities discovered from a penetration test?
Comment and discuss!
Ok this is my first rant on this blog. Bear with me and if you don't agree with me I'd love to hear why.
The definition of the term "Generalization" is as follows:gen-er-al-i-za-tion Pronunciation Key - Show Spelled Pronunciation[jen-er-uh-luh-zey-shuhn] Pronunciation Key - Show IPA Pronunciation
.noun
1. the act or process of generalizing.
2. a result of this process; a general statement, idea, or principle.
3. Logic.
a. a proposition asserting something to be true either of all members of a certain class or of an indefinite part of that class.
b. the process of obtaining such propositions.
As I get older it really has begun to strike me when people speak in generalizations regarding the security of some product/process/etc. Recently I was listening to someone speak and they said something to the effect of "Foo technology is horribly insecure. It is one of the most insecure technologies in use in XYZ industry today." This comment troubled me. There is no way for this person to back up these statements nor did they present any reasonable evidence as to exactly how this technology was broken. It was said off the cuff and generally in passing. As far as I'm aware this person has very limited knowledge at all about this particular technology (although *I* could be wrong about this).
Normally this wouldn't have bothered me, but as I get older I find that the majority of times I hear these types of comments they are either not entirely true or completely unfounded and continue to spread someones opinions based on the whims and most likely limited knowledge of the person speaking.
Am I getting old and grumpy? Is it a function of me understanding more things than I have in the past and having a tendency to want to call people out on things? Or is it just general bad practice that I have finally come to realize? No matter what it is I'm going to be making a concerted effort not to speak in generalizations any time in the future when it comes to security related topics.
I'm sure I'll flub up and speak in a general sense on my very next post here on Donkey On A Waffle. When I do, don't be afraid to call me out and make me back up my FUD.
Hello?! Is this thing on? *BONK BONK* Well either nobody has taken the 10 seconds it takes to click the comment button OR I have no readership. I'm not egotistical enough to think anyone bothers to read this so I will assume that I'm speaking into a vacuum.
That being said, I posed a question in the last entry asking what the two fundamental security mechanisms are. All security mechanisms can be broken down into two fundamental building blocks. These mechanisms are cryptography and control of code execution.
That's it, plain and simple. I thought about pitching a fit and smacking babies when I heard about this fact. It couldn't be that simple. But the more you get to thinking about it, it really is. I ask anyone who does read this blog (all two of you) to give me five minutes of your time and try to come up with a security mechanism that is not based on one of these two fundamentals. The challenge is on...
I was surprised to learn this fact the other day. I had never really thought about software coding security in basic building blocks sort of way. There are only two, yes two, fundamental security mechanisms with regards to software. Can you name them?
Think least common denominator of security, choose a few mechanisms and break them down into what components they are created upon... that should put you on the right path. I'll post the answer in another day or two. The comments are open!
