Sunday, March 27, 2011

Course Review: SANS SEC542

Well it is that time again for another course review.  This time it is SANS SEC542: Web App Penetration Testing and Ethical Hacking.

I personally found this course super interesting.  I took it OnDemand via SANS (personally, the only way to do courses) and I greatly benefited from the insight provided by Kevin Johnson as well as extra time to do my own research into the tools and techniques mentioned in class.  The following is going to be a summary of the core concepts that I learned from this course.  If you have a chance to take it, I suggest you do.  The insight and lab environment provided by SANS proves to be an effective learning tool.

Day 1: Attackers view of the web
The real purpose of this day is the ensure that everyone taking the class has a similar baseline of knowledge.  This knowledge, of course, is what the rest of the course will build on.  What I particularly liked about this part of the course was not so much the overview of TCP and the different types of authentication (basic/digest...) but how all of this was summed up into how the attacker views the different mechanisms that are used in security today. 

The course goes into depth about the authentication techniques used today.  For example, in Today's web, session state is everything.  The course goes over the different ways that session state is persisted in a stateless protocol as HTTP is. 

The course also talks about the different types of "testing", and which types will accomplish what.  On a related note, I was recently asked a question about the difference between penetration testing and a security assessment.  At the time, I kind of flubed the answer, but after reviewing my notes I would have to take the following stance.  A penetration test is simply a matter of seeing "how far can you get".  You can only truly know the risk of a vulnerability if you have fully explored how far you can take it.  A security assessment, on the other hand, is more of a "try-and-find" type approach.  The goal is not to find out how far a certain vulnerability can go, but rather, to figure out where the holes are and plug them.

The most important part of day 1, in my opinion, was the discussion of the attack methodology used.  Since learning this methodology, I have learned that there are others than can be followed such as OSSTMM.  Really, the methodology here is quite simple.
1) Recon : Research the target
2) Mapping: understand the target and it's surroundings
3) Discovery: look for vulnerabilities
4) Exploitation: launch attacks!!!


Day 2: Recon and Mapping

Recon as defined by the course simply means to research the target.  In the day and age of things like Stackoverflow, recon has gotten more complex.  Kevin tells the story of one assessment that he was doing where he actually used google and message boards to determine vulnerabilities in code.  Coders like to post samples (especially when they have problems) on message boards looking for help.  Kevin repeatedly says that the only advantage a company has over a hacker is the fact that they have access to the code.  This really changed my mind on posting code samples on the internet.  Most of the techniques and tools involved in Recon are general stuff.  Just remember that you can use anything public facing to get an idea of what the company is using.  Take for example, job postings.

Once you have your targets to hit, you can begin the mapping phase.  Mapping generally goes in the following order:
1) Port Scan
2) OS Fingerprint & Version Scan
3) SSL analysis
4) Virtual hosting $ load balancer analysis
5) Software configuration Analysis
6) Spidering
7) Detailed Analysis.

Basically, you are trying to find out as much information about the target as possible.  All this information could be things you could use during the next phases.  For example, in (3) you could determine that the server allows for the NULL SSL key.  Which basically means data is sent in the clear.  You might be able to use this information during later phases.  Another interesting aspect of mapping is (5).  There are automated tools that you can use to help determine the configuration of applications running on the server.  There are many tools that one can use in this space.  They include
1) Nmap
2) P0F
3) HttpPrint
4) Nikto
5)WebScarab

One important step of mapping is to try and chart out the application itself.  What pages link to others, etc.

Day 3: Server-Side Vuln Discovery
Basically this step involves probing the server to try and determine weakness in the application.  The easiest way to accomplish this is by use of automated scanners.  One should never rely on automated scanners to do all the work, however. Most of the day talks about manual ways to do discovery.  Very very very interesting stuff.
1) w3af

Day 4: Client-Side Discovery
This day primarily focuses on the client side technologies used in modern day websites, and how one might be able to exploit them.  One example I can remember clearly was talking about an AJAX shopping cart.  General shopping carts have the following 4 steps.
1) Add an item
2) Subtotal
3) Charge credit card
4) Checkout.

Well what would happen if you ran all of these calls out of order?  Would it work?  You'd be surprised to know that not too long ago some major AJAX shopping carts had vulnerabilities like this. 
This day goes into depth about AJAX, Web services, XPATH Injection and more. 

Day 5: Exploitation
This day was by far the "fun" day out of the course.  Here they talk about bypassing authentication.  They talk about using your SQL Injection for bad.  They talk about making zombies of browsers on the internal networks, and then using them to continue your attack.  Really really neat stuff.  I'm not going to into detail here.

Overall this was a great course.  I think it has provided a solid foundation for me to build my skills on.  I recommend this course for all developers who want to know how attacks are really done.  Those people who say, so what ... sql injection... the database doesn't have anything useful on it, be warned... you are so wrong.

Tuesday, March 15, 2011

Adventures in LINQ - Part 1

The one thing that I am really enjoying about my current stint in c# is learning about and using LINQ.  This really seems like a powerful way to query objects.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace LinqExamples.examples
{

    class LinqExample2 : IExample
    {
        private Role Role1 = new Role(){Id = 1,Name = "Role 1"};
        private Role Role2 = new Role(){Id = 2, Name = "Role 2"};
        private Role Role3 = new Role(){Id = 3, Name = "Role 3"};
        private User User1 = new User() { Id = 1, Name = "User 1" };
        private Account Account1 = new Account() { Id = 1, Name = "Account 1" };

        List&ltuserroleaccount> UserRoleAccountsList;
        List&ltrole> NewRoles;

        public LinqExample2() 
        {
            UserRoleAccountsList = new List&ltuserroleaccount>()
                                                                    {
                                                                        new UserRoleAccount() {
                                                                            Account = Account1,
                                                                            Roles = new List&ltrole>(){ Role1, Role2}
                                                                        }

                                                                    };
            NewRoles = new List&ltrole>() { Role1, Role3 };
        }

        public void ExecuteExample()
        {
            Console.WriteLine("Linq Example #2: Only adding new roles");
            Console.WriteLine("========================================================");

            var rolesToAdd = NewRoles.Except(UserRoleAccountsList.Where(x => x.Account.Id == Account1.Id).Select(x => x.Roles).FirstOrDefault());
            foreach (var item in rolesToAdd)
            {
                Console.WriteLine("Role to add: {0}", item.Name);
            }

            var rolesIntersect = NewRoles.Intersect(UserRoleAccountsList.Where(x => x.Account.Id == Account1.Id).Select(x => x.Roles).FirstOrDefault());
            foreach (var item in rolesIntersect)
            {
                Console.WriteLine("Role intersect {0}", item.Name);
            }

            var rolesUnion = NewRoles.Union(UserRoleAccountsList.Where(x => x.Account.Id == Account1.Id).Select(x => x.Roles).FirstOrDefault());
            foreach (var item in rolesUnion)
            {
                Console.WriteLine("Role union {0}", item.Name);
            }
        }
    }

    class UserRoleAccount
    {
        public List&ltrole> Roles { get; set; }
        public Account Account { get; set; }
    }

    class User
    {
        public string Name { get; set; }
        public long Id { get; set; }
    }

    class Role
    {
        public string Name { get; set;}
        public long Id { get; set; }
    }

    class Account
    {
        public string Name { get; set; }
        public long Id { get; set; }
    }
}


[Sorry about the encoding, hopefully I'll figure out a better way to display generics soon]


As you can see from the above example, it is very easy to compare the NewRoles object to the list of roles already set in the UserRoleAccount object.

1) Except:  displays all roles that are in NewRoles but not in the current role list
2) Intersect: displays all the roles that exist in both lists
3)  Union:  Does a join on the two lists.  Does not display duplicates.

This is a far cry from the days of iterating over the lists or implementing custom comparator functions.

Saturday, March 5, 2011

Checkbox-fu with JQuery

The current project that I am is a .net MVC 3 project.  The framework comes with the JQuery library for making client side controls easier to create.  I have only used YUI (2) before, so the concept of a javascript library is not uncommon to me.

I must say that I am really liking the JQuery library.  As with all libraries, it takes a bit to learn the in's and out's of how the library works.  In this post, I am going to show you how to create buttons that will check and uncheck all of the checkboxes on the page.

First of all, the code.
$(document).ready(function()
   {
    $("#all").click(function() {
     $(".checkboxes input:checkbox").each(function(){
               $(this).attr('checked','true');
               });
    }); // end all.click
    
    $("#none").click(function() {
     $(".checkboxes input:checkbox").each(function(){
               $(this).removeAttr('checked');
               });
    });
   });

Soccer
Hockey
Football
Basketball







If you view the source of this page, you should see the html mark up that I have up above.  It is pretty simple.  I have a div with a class of checkboxes.  Inside that are 4 checkboxes that are currently unchecked.  I then have a span with 2 buttons in it (a select all, and a clear).

The Javascript code itself is pretty easy (as is most things with JQuery).  Since I want my buttons to have functionality provided by the javascript, I need to ensure that my javascript runs after the elements that they affect load.  The easiest way to do this is to wrap all the javascript code in a document.ready block.  JQuery uses the $(document).ready function to accomplish this.

JQuery works on the idea of selectors.  You can use attributes such as id and class to act as selectors.  You can also use keywords such as form to accomplish the same thing.  Be careful if you have more than one form on your page.

Back to the code.  My buttons have an id of all or none respectively.  The line inside the function uses the JQuery selector methods to select multiple html elements.  In this case, it is looking inside any divs with the .checkboxes class.  From that, it will look for any input elements of type checkbox.  The .each method allows you to perform a function on each element in the array that is returned from the JQuery selector method.

The "this" keyword is pretty self explanatory in this case.  It clearly represents the DOM object that I am functioning on.  This is because I have called it form a .each method.  See http://remysharp.com/2007/04/12/jquerys-this-demystified/ for more information on the "this" keyword in JQuery.

The last piece of the puzzle is the attr and removeAttr methods.  Basically, this adds an attribute to the DOM object, or removes it.  These are handy methods if you want to quickly disable and re-enable buttons.  In the above case, I am using it to add the checked and remove the checked attribute.

JQuery can do a lot more than this, but this small example gives a small glimps of how powerful the framework is.  You can easily accomplish several tasks with just a couple lines of code.