BackTrack5 Install

I recently came into a mode of downtime for a few days and decided to finally install backtrack5 on a Lenovo X201 laptop. I burned the disk early on this semester but between my own students and my deliveribles at DSU, it sat on my desk at home collecting dust until this last weekend.

Out of the gate I hit the dreaded black screen. It took about an hour to find the right combination of grub tweaks to get it to boot and launch X. From there I will have to say that an i5 and 8GB of RAM is sheer overkill for this distribution. I did like the number of tools loaded into the live disk and the ease of use of the Ubuntu based apt installer made it easy to get the extra tools I wanted in my load. This left some testing of the tools to see if they performed any better than the windows versions.

For the most part I was pleasantly surprised at how well everything worked. I did find that the wlan0 adapter was not talking well with ssidsniff even when calling the adapter explicitly in the argument tags. Small issue really and I fully admit that in the short amount of time I did not try Kismet. I was able to quickly pull off an (on my own network of course) arp poisoning MITM attack using SSLStrip which I had seen demonstrated from the BlackHat tutorials and a few YouTube links prior. I was really impressed at how many tools were available to the user for security concerns. Nessus, OpenVAS, and  Snort were full installs with some of my more favorite tools such as Nikto and Ettercap.

I have to say that I'm sad I did not pick up this distribution earlier. BT5 is great and it would have saved me all those hours configuring my previous Ubuntu installs with tools had I just moved to this instead. I will also say that it is likely that the Lenovo hardware on this is what caused most of my issues. I will play around with it a little more this week before my summer courses get crazy and perhaps get it going in a VirtualBox environment although having real adapters in place of bridged mode NICs is always nicer.

Paros Web Proxy

As this semester wraps up at both universities I found myself rapidly trying to grade papers as well as complete my own projects. One of the projects I needed to complete was a network and web security course at DSU. I used nikto in a previous post to discuss the use of the software in vulnerability assessment.

I have used proxy software in the past, but never in the capacity of vulnerability assessment. Now the project was to break a PHP script and gain remote access. This actually turned out to be more simplistic than I anticipated, but what was surprising was how useful the paros proxy software was in accomplishing that particular goal.

The software is designed to allow you to see all the GET and POST messages, content, delivery of regular web traffic between your host and the remote server. It has two nifty features though; cookie storage and spider crawl. I used the spider functionality to grab the listing of html the did a directory grep for *.php to find my script call. This saved hours of time looking though the site and really let me get to the heart of the assignment.

Paros should be added to any suite of network vulnerability tools for use in pen testing. I highly recommend it.

Nikto2

I have been working on a project for my information security class. It requires me to test and gather information on a server before attempting to penetrate it. I have managed to build a good list of information on the server, but I have not managed to penetrate it yet. Of course I'm trying to do this without the use of scripts or applications designed for this server's vulnerabilities, so I'm doing it the hard way, but honestly, did anyone expect anything less of me?

So I'm working though trying to find all the tools I can use to discover all the possible vulnerabilities and I remember nikto. For those who are not familiar with Nikto, it is a web server vulnerability tool, a very vertically aligned form of metasploit (which I wish had student licenses). Nikto 2 has come along way since the last time I looked at it and seems to be very stable. The thing I like most about Nikto is the mutation capability, being able to change what I need to accomplish my goal. This goes beyond just adding parameter tags, to being able to actively get content loaded on the server. It also has a export to metasploit function which enables this to be added to a pen tester's suite of tools. Nice.

Within a few minutes and a good nmap scan I was able to determine a mostly complete range of vulnerabilities on the project server. Of course the hard part is actually utilizing these vulnerabilities and exploiting them, but then again, that what I'm being graded on. Nikto 2 is working flawlessly on my ubuntu server, my Solaris VM, and my OSX laptop (10.7 Lion).

Slowloris and RDP

I was reading up on one of the latest worms to be released this week. It uses RDP to initiate a session and then attempts a dictionary attack against windows based hosts. It would seem that this is one of the first attempts to utilize what is really thought of as a utility to initiate a penetration. If one were to be cleaver enough, RDP as a utility and terminal services could become a more prominent attack vector.

I remembered reading about a HTTP SYN flood utility in an IRC channel once a few months ago. Slowloris had been demonstrated at a defcon at one point (I'm not sure which one), but it made me wonder if there have been attempts to initiate half open sessions to terminal services in the past. It could be argued that since the TCP stack in slowloris actually initiates and completes a connection, many of the more common remote options could be targeted via DoS. Since most use the TCP stack and then hand off to another service, most of them could be real targets, especially ones which are not used in the main arena of remote connectivity, like TeamView or something similar.

Now I know that there are defenses against Slowloris, but it requires looking at the number of open connections and determining if that number is too many. This defense would need to be set against each type of remote connection across any number of ports for RDP, ARD, and VNC. Whitelists and constant monitoring would also have to be setup.

It also make me wonder if NetFlow can detect the number of simultaneous connections rather than leaving it to a script running on the host. I will look to see if snort has any specific signatures to determine a slowloris attack and if that sig can be tweaked to look at other services beyond HTTP. I also wonder if Metasploit has a similar vulnerability in the framework.

I guess it's time to go read more...

Summer Semester: Shift in Focus

EC2...wow, just wow. As I sit here trying desperately to wade through the massive amount of material I must read and prep in 23 days, I sit in awe of how Amazon has implemented the EC2. You are probably wondering why I have sprung this topic without any sort of prelude or previous mention, well that's a funny story actually and it all revolves around being flexible.

So I registered for a seminar course this summer, INFS 890. I must take and pass six of these courses to meet the requirements for the DSc program. What I did not realize involves two things: 1. I have completed my core and 2. It's all specialization and dissertation work from here on out. INFS 890 prepares you for dissertation by allowing you to schedule time and resources for your dissertation topic. I now have a dissertation area, professor, and direction. So when discussing the needs of the course with the instructor I came to a choice, a fork in the road if you will, between network security and cloud security. Given the resources and position of my current work projects I chose cloud security, and to quote Indiana Jones, it would seem that I have chosen wisely.

I started playing with EC2 last week after reading the apology letter from Amazon regarding the recent outage. The way that the infrastructure is set up is amazing. I started creating my own instances and modifying other AMIs to meet my curiosity. Wow...30 seconds to VM creation. So many distributions and so inexpensive. Being able to set the instances in a good arrangement then setting that arrangement as a cloud formation. Wow. I loved being able to setup Ubuntu in just minutes. I doubt I will ever need a home machine to do OS testing and learning. I have been trying to get back into SuSE and instead of buying or re-purposing a machine to do this, I can now just launch a AMI, make the changes I need, and continue on my merry way.

This does leave some serious security questions though, and if the literature at this point is any indication, EC2 security is being left in the hands of the users. The literature on this is far from sparse (YAY), meaning it's a hot topic and there is no great silver bullet answer. I have seen some excellent ideas in the articles so far and I am starting to implement them myself in my own test cloud. Of course I do have to watch the cost, but that's why I applied to the AWS in Education program, perhaps with a little luck, Amazon will allow me to play and learn at a reduced cost.

Gawker Breach and Strong Passwords

I used Lifehacker and Gizmodo, of course I was a member before the war between Nick/Adrian and 4Chan, before the dark times. What can we learn from this incident, well several things!

1. The first is that strong password security is a must. 
It's not just a good idea that some person in a classroom somewhere mandates. It should be good policy for every person connected to the internet. I downloaded the files from gnosis, the group claiming responsibility for the Gawker breach. They has access to those systems for a long time (weeks if not months). Long enough to crack good, strong passwords. I was surprised to see how many people use children names, their own names, colleges, and the word "password" as their password.

People, these are not strong. No word easily found in any dictionary is "strong"!!!

I typically use strong passwords. Even after 48 hours of brute force against my own passwords which were in the list obtained from gnosis, I went through every site which I felt had security issues, and changed passwords ahead of my 90-120 day schedule. Yes, you should change your passwords at least every 90 days. This is no laughing matter. I spent most of the weekend changing my passwords.

This is my forumla for making strong passwords: Letters + Numbers + Capitals and for grins throw in a !@#$%& character or two. Make it more than 8 characters.


This is an example of a strong password: !iWng24Cea@39

Note the use of capitals, print characters (!@#$%&*), and numbers. The password is also longer than 8 characters. 

DO NOT REUSE PASSWORDS ON MULTIPLE SITES, EACH SITE NEEDS A SPECIFIC PASSWORD.  This is what ultimately lead to the massive amount of personal information on the gawker media employees to be leaked and posted. 

2. Pay attention to emails and news regarding the sites we use on a daily or weekly basis. 
Keeping apprised of a situation is no small feat, but we do this in so many ways already. You would certainly notice if the front door to your home was open all day long. I am not saying that everyone should learn intrusion detection, but be aware of the sites and services you use, and be aware of any issues they have.

3. Site designers, make password changing/entry friendly to strong passwords.
In the process of changing the passwords to sites this weekend, I noticed a disturbing trend. Many sites do not allow the storing of what I consider strong characters, mainly the !@#$%* characters. This is a serious issue to me. I realize that storing these types of characters is more difficult in the short term, but in the long term this adds the longevity of the cracking attempt. Do not limit me on password length either. Making a limit of 12 characters is silly and outdated. If I am capable of remembering a 32 character string then let me have 32 characters.

Sticking to these tips will help you in the long run maintain some measure of safety. Remember that security is not a matter of stopping someone cold, but making it as difficult as possible to breach the measures taken. No security is full proof, but do not make it easy for anyone to breach your data.

Fall Personal Project: Update 2

And working!....The Snort home project is a success. At least the setup and configuration of the project is a success. I have not tried to mess with the rules yet, but I will get there. I'm sidetracked at the moment by a layoff, contract work, classes, and job hunting. Honestly I'm surprised I got any of it done at all.

All said and done this is pretty sweet, and I would like to thank the guys at the snort forums and on the snort mailing list for all the help. I would also like to thank the guide writer for the in depth guide. 

Here is a list of the equipment I used: 

1. Dell Zino (aka Inspirion 400)

2. 1 Router (any type with a built in switch)

3. 1 unmanaged hub or a switch which you can set as a repeater (I used a Netgear DS108)

3. 1 Cisco USB to Ethernet dongle (USB 300M)

4. Ubuntu 10.4 or higher

5. UTP patch cables

6. 1 UPS for the networking equipment.

I will go through the configuration in an upcoming post, but needless to say it does work. There are some tricks I learned outside of the guide which will help along the way.

Here some photos of the setup all completed:

I have cleared the DB several times and started traffic over and it is working like a charm. The next post will cover the guide, software installs, and getting LAMP running.

Why I use SSID

This is going to be a long one. It comes from a debate I had on irc a few days ago. I've heard this time and time again, to increase security, disable SSID broadcast. It's true, if you want to be absolute in your wifi network security, you should disable SSID broadcast. Now let me tell you why I don't.

I like things to work: Yes, in a nutshell this is my primary reason. I like it when I know my Wii can see my wifi network. I like it when my mother brings her iPod over and it works seamlessly. There is something to be said about technology doing what it was designed to do, making my life easier and improving the quality of it. I dislike having to stop what I am doing to troubleshoot a wifi connection, if the device can see the SSID, then I know the hardware is at least functioning somewhat properly. It saves time and effort, something geeks like to do.

How do I secure my wifi network? Simple steps will always work:

1. Change the default password on your router. 
 This should be the first thing you do. All it takes is determining the router type and someone can lookup the factory username and password. Once they get into your router, find your connected IP, turn off your SPI firewall, and lock you out, well, it's game over. Seriously speaking this keeps so much from happening. Usually you cannot change the default username, but make your password strong. Letters + Numbers + Capitals and for grins throw in a !@#$%& character or two. Make it more than 8 characters too.

2. Change the SSID broadcast name.
Do this as soon as you have changed the default password.

3. Set the radio encryption level to high.
It boils down to this, a wifi network still uses plain old fashioned radio waves for communication (which is why you have channels on your router). Just like regular radio waves they can be intercepted by anyone with the basic knowledge and equipment. Encryption of the radio signal is crucial! When you set the encryption of a router you are encrypting the radio transmission and reception, the information floating (waving) through the air is encrypted. This protects against interception. The current standard for high encryption is WPA2, go as high as you can. This will not stop a determined person, but it will make it extremely difficult, which is the basics of security.

4. Use MAC Filters.
Here is where I depart from the "standard". Each and every device which connects to a network uses a media access control address (MAC). Most modern routers allow a person to setup a list of MACs which will be allowed on the network. If the MAC isn't on the list, it is not allowed on. Now here is the problem with MACs, they can be spoofed, easily spoofed. Here is the counter argument. Most will not take the time to try and discover the connected MACs, they will move on to another target. Spoofing a MAC requires someone to take the time and effort to capture radio traffic, find the correct MAC, and spoof it. Remember if you have done the previous steps, this is just another road block in the way of a intruder. It is better to have it than to not have it. It should not be implemented on its own as a security plan, rather it should be implemented as a part of a security methodology.

5. Check your logs/activity.
So many people do not take the time to review their router. I do mine about once a month, but I take security very seriously. At least check it every few months. There are ways to set routers to email you when certain activity happens. Do so! Just like you check your windows and door by looking at them, do the same for your network.

Wardriving (whitehat of course)

Wednesday night, I thought I would kill two birds so to speak. I needed to pick up my lovely wife from the airport and at the same time, complete an assignment for my networking class regarding wardriving. Let me preface this by stating I know the difference between scanning for a network and connecting to it. I have done this many times in the past and I am not about to break the law now. So I fire up VIStumbler on my laptop, jump in my nifty car and drive 26.1 miles to DFW international airport. The results were more than interesting.

I found what I expected getting out of my neighborhood, lots of unsecured open wireless networks. On the drive to the highway I found plenty of businesses which would offer WiFi to their customers; McDonalds, Starbucks, Hyatt, even a KFC. Then I get some more than interesting hits; Bank of America, Wells Fargo, a local doctor's office. These were just a few of the businesses which I would think would at least encrypt their network. Leaving it open for access is one thing, it makes it easy for customers to connect, but traffic encryption should be a no quarter point of interest.

Having spent lots of time as a network and system admin, I would find it very unnerving to have an open and unsecured WiFi network for a doctor's office, bank, or any retail operation which accepts credit cards (and stores them locally). I understand that many businesses simply offer internet service to their customers, the local coffee shop for example. I have personally seen local businesses though, connect their POS system to their WiFi network. Here is where things can get tricky.

Here are some reasons why. For all those doctor's offices out there, HIPPA is no laughing matter. If the network inadvertently transmits HIPPA related patient information on an unsecured network and that transmission is intercepted...well good night Sally. This is a major issue. For businesses which accept credit cards, you must follow PCI-DSS standards for card data security set by VISA, MasterCard, Discover, and American Express (The PCI council). The fines you could receive for a breach could literally put the business down for the count.

Do not take WiFi security lightly. Set up encryption, use it, access points and wireless routers have it built in for a reason. Set up authentication when you can, again these access points come with this ability out of the box. For you data paranoid types (like me), use good encryption and authentication with a IDS setup on the inside of the network. None of this may stop a determined intruder, but it can slow them down and make them move on to a more viable target, which is what security is all about.

Securing your files in OS X

If you are like me, you are concerned about privacy and security regarding your files. In OS X you can use Apple's FileVault, which will encrypt the entire disk, or you can rely on 3rd party applications to secure individual files for you.

If you want though, there is a much easier way. Apple's Disk Utility will create 256bit AES encrypted disks for you, which of course are images, so you can read/write/and keep safe.

This is a perfect way to keep files compressed, together, organized, and encrypted. It also makes it much easier to back them up to NAS, DVD, or using any of a number of backup utilities. My only suggestion is to use a large password. A friend of mine recently posted that he uses this method to keep his quicken files encrypted. If you are running on a laptop, you would definitely want to keep any financial records, lists of passwords, email, etc, encrypted. If it gets stolen you can always replace the laptop, but you cannot always replace the damage caused by identify theft or credit score loss.

Take it from a guy with bachelor's degree in criminology, a master's degree in criminology, and a professional information security certification, you need to keep private or sensitive data encrypted.