If you follow my Tweets you probably are already aware that my talk on ESAPI was accepted and is scheduled to happen at AppSecUS 2010 in California this September. I am super excited about it!
I will be streamlining my Presentation from FROC 2010 and trying to cram a lot of information into a 45 minute presentation, and so I wanted to reach out to the community, especially to those who are thinking about coming to AppSecUS to see exactly what you guys would like me to spend my time on.
It seemed like a good deal of the questions after the presentation at FROC and the presentation(s) I had the pleasure of helping give at UberConf with Ken Sipe had to do with the following areas:
* Configuration
* Using specific components
* Cross Language Compatibility
* Encoding and Validation
So my initial plan is to reformat the presentation to address these concerns primarily and leave room for elaboration and code demos real-time.
I would love to hear what you all think and if you would like to see other areas covered as well.
I am also still in the planning phases of an ESAPI Bootcamp Training session that will either be a Webcast and/or hard-core weekend training event located in Denver, so I will keep you all posted on that.
I know I promised in my last posting that I would be throwing up some recipes and sample ideas from the book (which I have started and am working on) - however with work, life, and conference season in full swing, I have decided to put this off until this fall, when I will have more time to focus on it and more input from the community (and hopefully - a NSA reviewed GA release of ESAPI 2.0)
Hope to see everyone in California in a little over a month, and looking forward to reading your input and ideas!
Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
7.31.2010
ESAPI at AppSecUS
Labels:
Conferences,
ESAPI,
security
1.13.2010
Cracking Passwords with Teh Google
Have you ever googled yourself? You may have to sift through several pages of results about people with the same name that aren't you, but you would be surprised how easy it is to find a wealth of information about yourself by combinging information retrieved by your social networking profiles being indexed.
Have you ever tried your hand at cracking a password? Chances are if you have, you have downloaded a word list and may have eventually cracked a password (unless you happen to have a cluster of PS3's laying around to do all the processing for you)
Password cracking is a lost art that often requires a lot of patience. There are two primary methods of cracking passwords: online and offline. When you attempt to crack a password online, it is often via a 'brute-force' style attack and has to be throttled carefully to avoid immediate detection (although, any competent system admin will be able to spot an online BF from a mile away after 10 shots of tequila) Offline, is often much more difficult to accomplish, simply because in order to crack a password offline, you either need to obtain a password list, or at bare minimum the hash of the password that you are trying to crack.
All that aside, one of the most difficult and time consuming parts of cracking passwords is starting with the right wordlist. There are tons of really horrible wordlists spread all across the internet, and even a handful of good ones. I am fairly partial to the Common Passwords Dictionary and the extremely large dic-0294 when I am flying blind.
However, with the wealth of knowledge available on the internet about everyone you know from sites like facebook, myspace, linkedin, hi5, twitter, and the list goes on and on, there really is no need to fly blind anymore when cracking passwords.
Now before I go much further, let me warn you that this is a tedious process right now as I am not aware of any tools in the tubes that do this for you (although, such a tool probably would not be to difficult to build) Also I would like to note that as a security professional, the information that I am providing is as much a warning to people about how easy it is to get their password, as it is a informative post about something that has been sorely neglected in security presentations (that I have been privy too).
To keep this relatively brief while still getting the point across, the example I am providing below is purely fictional, and any similarity to actual people is completely unintentional.
Step 1: Recon
If you personally know your target, this step is pretty much already done - however, if you don't know the target, the first step is to find out some very basic information about them. This is all public domain information that is easy to gain through the use of search or social engineering. For the purpose of this example we will say that I am trying to crack the password of a coworker named Don Johnson.
Now I know very little about Don other than the company he works for (obviously) and the department that he is in. We will say that he is the director of Human Resources. Our fictitious company name will be Acme Inc.
So seeing as how I know about him only in his job, LinkedIn seems the obvious starting point for me. Now, LinkedIn is one of those funny psychological experiments that proves that people really don't care about their privacy, no matter what they say. Their profile may say that they are only interested in reconnecting with previous coworkers, but if a recruiter requests to be in their network, they will almost always click - if nothing else, for curiosity sake.
Google Search #1: site:linkedin.com "Don Johnson" +Acme +Denver
9 times out of 10, the Don Johnson we were looking for will be in the top 5 results returned from google. Once I have found his profile, it is quick and easy to get a free gmail account, create a fake recruiter profile on linkedin, and start adding a bunch of people, with Don among those being added. The reason for adding several people is that Don may be a little paranoid and if a recruiter with no network requests to be in his network, he may think twice about allowing him - however, if Don sees that this recruiter is acting like most every other recruiter on linkedin, and obsessively adding 10-20 people a day, well he will probably think nothing of it and allow the request. Once he is in your network you can view his full profile which will often include such information as all of his prior employers, education, blogs, etc. Generally, I will take a scrape of the entire profile (a scrape can be as simple as using File -> Save Page As in your browser) and use the information and picture from that profile to identify him on other networks.
Let us say that in the recon of my target I discovered a linkedin, facebook, myspace, and pandora account all linked to Don. I have scrapes of his profile pages from each network, along with an archive of comments and wall postings on friends profiles from the last 60 days.
Step 2: Assimilation of Information
This is where things really start to get interesting. You have a wealth of information now about your target. You know who he is dating, the names of all his pets (real and virtual), a list of his favorite musicians, movies, and books (invaluable), a collection of nicknames, his birtday, and much much more.
I specifically call out the fact that music, movies, and books are invaluable information to know about a target. Often, people will use a term or character name from their favorite stories as all or part of their password. So that being said, you can take Don's favorite songs look up the lyrics and start your wordlist. Next, look up a character list from his favorite books and movies, then lookup memorable quotes from those characters (imdb.com) and (wikipedia) are your friends here. Keep doing this with all the information you have until you have a comprehensive word list built specifically around the social profile of your target.
This is it, this is all you need to do. I have a relatively high (60-70%) success rate when building a custom word list using this method and if I were to take the time to build some tool that used the full power of the internet to build related information, I could almost guarantee a 90%+ success rate at using this method.
So the next time you are updating your profile on myspace or facebook, think about the password that you are using to login to that site and see if you can connect the dots between your password and any of the information on your profile. I would say that for most people, they will be able to make the connection fairly quickly and most of the time.
I purposefully described this process in a fairly abstract manner, as it is a very effective means of social engineering without having any direct contact with the target, and really, there are enough bad guys in the world already.
We rely on technology to keep our personal information secure and safe, yet the true dangers still lie in the information that we publicly disclose without a second thought. This is no different from the days of dumpster diving, only google is a much cleaner and organized dumpster.
Have you ever tried your hand at cracking a password? Chances are if you have, you have downloaded a word list and may have eventually cracked a password (unless you happen to have a cluster of PS3's laying around to do all the processing for you)
Password cracking is a lost art that often requires a lot of patience. There are two primary methods of cracking passwords: online and offline. When you attempt to crack a password online, it is often via a 'brute-force' style attack and has to be throttled carefully to avoid immediate detection (although, any competent system admin will be able to spot an online BF from a mile away after 10 shots of tequila) Offline, is often much more difficult to accomplish, simply because in order to crack a password offline, you either need to obtain a password list, or at bare minimum the hash of the password that you are trying to crack.
All that aside, one of the most difficult and time consuming parts of cracking passwords is starting with the right wordlist. There are tons of really horrible wordlists spread all across the internet, and even a handful of good ones. I am fairly partial to the Common Passwords Dictionary and the extremely large dic-0294 when I am flying blind.
However, with the wealth of knowledge available on the internet about everyone you know from sites like facebook, myspace, linkedin, hi5, twitter, and the list goes on and on, there really is no need to fly blind anymore when cracking passwords.
Now before I go much further, let me warn you that this is a tedious process right now as I am not aware of any tools in the tubes that do this for you (although, such a tool probably would not be to difficult to build) Also I would like to note that as a security professional, the information that I am providing is as much a warning to people about how easy it is to get their password, as it is a informative post about something that has been sorely neglected in security presentations (that I have been privy too).
To keep this relatively brief while still getting the point across, the example I am providing below is purely fictional, and any similarity to actual people is completely unintentional.
Step 1: Recon
If you personally know your target, this step is pretty much already done - however, if you don't know the target, the first step is to find out some very basic information about them. This is all public domain information that is easy to gain through the use of search or social engineering. For the purpose of this example we will say that I am trying to crack the password of a coworker named Don Johnson.
Now I know very little about Don other than the company he works for (obviously) and the department that he is in. We will say that he is the director of Human Resources. Our fictitious company name will be Acme Inc.
So seeing as how I know about him only in his job, LinkedIn seems the obvious starting point for me. Now, LinkedIn is one of those funny psychological experiments that proves that people really don't care about their privacy, no matter what they say. Their profile may say that they are only interested in reconnecting with previous coworkers, but if a recruiter requests to be in their network, they will almost always click - if nothing else, for curiosity sake.
Google Search #1: site:linkedin.com "Don Johnson" +Acme +Denver
9 times out of 10, the Don Johnson we were looking for will be in the top 5 results returned from google. Once I have found his profile, it is quick and easy to get a free gmail account, create a fake recruiter profile on linkedin, and start adding a bunch of people, with Don among those being added. The reason for adding several people is that Don may be a little paranoid and if a recruiter with no network requests to be in his network, he may think twice about allowing him - however, if Don sees that this recruiter is acting like most every other recruiter on linkedin, and obsessively adding 10-20 people a day, well he will probably think nothing of it and allow the request. Once he is in your network you can view his full profile which will often include such information as all of his prior employers, education, blogs, etc. Generally, I will take a scrape of the entire profile (a scrape can be as simple as using File -> Save Page As in your browser) and use the information and picture from that profile to identify him on other networks.
Let us say that in the recon of my target I discovered a linkedin, facebook, myspace, and pandora account all linked to Don. I have scrapes of his profile pages from each network, along with an archive of comments and wall postings on friends profiles from the last 60 days.
Step 2: Assimilation of Information
This is where things really start to get interesting. You have a wealth of information now about your target. You know who he is dating, the names of all his pets (real and virtual), a list of his favorite musicians, movies, and books (invaluable), a collection of nicknames, his birtday, and much much more.
I specifically call out the fact that music, movies, and books are invaluable information to know about a target. Often, people will use a term or character name from their favorite stories as all or part of their password. So that being said, you can take Don's favorite songs look up the lyrics and start your wordlist. Next, look up a character list from his favorite books and movies, then lookup memorable quotes from those characters (imdb.com) and (wikipedia) are your friends here. Keep doing this with all the information you have until you have a comprehensive word list built specifically around the social profile of your target.
This is it, this is all you need to do. I have a relatively high (60-70%) success rate when building a custom word list using this method and if I were to take the time to build some tool that used the full power of the internet to build related information, I could almost guarantee a 90%+ success rate at using this method.
So the next time you are updating your profile on myspace or facebook, think about the password that you are using to login to that site and see if you can connect the dots between your password and any of the information on your profile. I would say that for most people, they will be able to make the connection fairly quickly and most of the time.
I purposefully described this process in a fairly abstract manner, as it is a very effective means of social engineering without having any direct contact with the target, and really, there are enough bad guys in the world already.
We rely on technology to keep our personal information secure and safe, yet the true dangers still lie in the information that we publicly disclose without a second thought. This is no different from the days of dumpster diving, only google is a much cleaner and organized dumpster.
Labels:
cracking,
Google,
password stealing,
security
12.28.2009
09 - The year of Toolz
I found myself using tools a lot more in my day to day job this year than I am used to. It is amazing how far some of the software breaking software tools have really come in the last few years. So that being said, I am going to focus on some of the tools that I have found myself using regularly.
Wireshark
Tried and true, Wireshark has been there for me, through thick and thin, since I got into this game long ago. I have used Wireshark for everything from dissecting RIP packets to troubleshooting TLS/SSL connection issues with SOAP Web Services. This tool is an absolute MUST HAVE for anyone in the security field. Be they hacker, hobbyist, or analyst - Wireshark will be one of your best friends.
Cain and Abel
It's interesting - I actually have a Windows XP VM that exists for no other purpose than to run Cain & Abel. This tool is invaluable when you need to capture network packets and have them analyzed and organized in real-time. It is great for sniffing out cleartext credentials (Telnet, FTP, SMTP), and one of the absolute best features is the ability to capture and essentially *bug* VOIP calls.
Metasploit
I remember when I first heard about MSF. I thought to myself, great, a new tool for Skiddies to annoy me with. At first glance it is nothing more than a glorified over-powered version of BO95. However, when you really dig deep under the covers, MSF is more like an IDE (that's Integrated Development Environment for you non-developer types) built specifically for hackers! It is a self-contained runtime where you can discover vulnerabilities and test exploits and shellcode all in a single environment. Really, this is an ingenius tool that's power far exceeds what most people are using it for.
JBroFuzzer
This has become one of the most used tools in my toolkit - I use JBroFuzzer against any new development in any of the applications that I maintain to test Regex patterns, request parameters, cookie values, and more than anything else, RESTful web services. It is amazing how many ways there are to break webservices and with some custom payloads and JBroFuzz you can create some very powerful scans that can be run against your app to dig out even the most obscure bugs that most ordinary testers would never think of.
JMeter
The quickest way to DoS your own application is by firing up a JMeter test. This is an extremely powerful tool from the Apache team that is written in Java. Load Testing, automated crawl tests, whitebox testing, and much, much more are possible with this extremely easy to use and powerful tool.
BurpSuite
The great thing about BS is it is an entire suite of tools that work together and allow you to run a quick (and surprisingly accurate) audit of an entire application. The interface is simple to use and most importantly, it is extendable. It is Java based so it is platform agnostic and works with any browser. One of the cooler features is the ability to suspend and save state then restore and continue later. Great stealth scanning feature.
There are other tools that I find myself using, but I use these almost every day, and absolutely use each extensively when doing an audit. Take this list for what it's worth, but if you haven't tried a couple of these, do yourself a favor and give them a shot.
Wireshark
Tried and true, Wireshark has been there for me, through thick and thin, since I got into this game long ago. I have used Wireshark for everything from dissecting RIP packets to troubleshooting TLS/SSL connection issues with SOAP Web Services. This tool is an absolute MUST HAVE for anyone in the security field. Be they hacker, hobbyist, or analyst - Wireshark will be one of your best friends.
Cain and Abel
It's interesting - I actually have a Windows XP VM that exists for no other purpose than to run Cain & Abel. This tool is invaluable when you need to capture network packets and have them analyzed and organized in real-time. It is great for sniffing out cleartext credentials (Telnet, FTP, SMTP), and one of the absolute best features is the ability to capture and essentially *bug* VOIP calls.
Metasploit
I remember when I first heard about MSF. I thought to myself, great, a new tool for Skiddies to annoy me with. At first glance it is nothing more than a glorified over-powered version of BO95. However, when you really dig deep under the covers, MSF is more like an IDE (that's Integrated Development Environment for you non-developer types) built specifically for hackers! It is a self-contained runtime where you can discover vulnerabilities and test exploits and shellcode all in a single environment. Really, this is an ingenius tool that's power far exceeds what most people are using it for.
JBroFuzzer
This has become one of the most used tools in my toolkit - I use JBroFuzzer against any new development in any of the applications that I maintain to test Regex patterns, request parameters, cookie values, and more than anything else, RESTful web services. It is amazing how many ways there are to break webservices and with some custom payloads and JBroFuzz you can create some very powerful scans that can be run against your app to dig out even the most obscure bugs that most ordinary testers would never think of.
JMeter
The quickest way to DoS your own application is by firing up a JMeter test. This is an extremely powerful tool from the Apache team that is written in Java. Load Testing, automated crawl tests, whitebox testing, and much, much more are possible with this extremely easy to use and powerful tool.
BurpSuite
The great thing about BS is it is an entire suite of tools that work together and allow you to run a quick (and surprisingly accurate) audit of an entire application. The interface is simple to use and most importantly, it is extendable. It is Java based so it is platform agnostic and works with any browser. One of the cooler features is the ability to suspend and save state then restore and continue later. Great stealth scanning feature.
There are other tools that I find myself using, but I use these almost every day, and absolutely use each extensively when doing an audit. Take this list for what it's worth, but if you haven't tried a couple of these, do yourself a favor and give them a shot.
5.30.2009
SQL Injection... Still? Really?
When it comes to development blunders there is one thing that really just rubs me the wrong way, no matter what language I see it in. SQL Injection is that one thing. I can understand XSS bugs, DOS vulnerabilities, buffer and stack overflows, information disclosure bugs, and just about any other type of application vulnerability that you can think of, but really there is just no excuse for the most basic SQL injection bugs to exist anymore.
If you do a google search for SQL Injection, you will see 'Results 1 - 10 of about 2,990,000 for sql injection'
Yes, you did read that correctly.. That really does say 2,990,000 results for SQL Injection. Seeing that should raise a big red flag in your minds eye, a big red flag that says, "Why, oh why is this still an issue?"
Code Injection as a generalized vulnerability is the act of embedding executable code into an application thereby forcing that application to perform an action specified by the user. This is a pretty broad description and really describes anything from a BOF (that's buffer overflow for you non-l33t types) to XSS (Cross Site Scripting) to my favorite SQL Injection.
Let me digress for a second.
The vast majority of websites on the internet are run by one guy in his spare time. Not every site has a Development Team full of Architects, Designers, Security Analysts, QA Analysts, and Database Administrators. That one guy acts as all of those people, and more often than not, doesn't look very good with any of those hats on. That one guy also relies on the 'frameworks' he downloads off of the interwebz to take care of all that tedious difficult stuff for him. Keep that in mind as we move forward along the tracks of my train of thought.
SQL Injection differs from most other types of code injection in that it has the ability to change the persistent state of an application or a site. There are some other forms of code injection that can do the same thing either by themselves or by accessing the persistent storage used by the application in the injected code, but every Skiddie in the world knows about ' or 1=1. Thus, if your app has this:
$badSQL = "Select * from users where username='$_GET['username']' and password='$_GET['password']'"
You end up with:
select * from users where username='Administrator' and password='' or 1=1
Go ahead now and type that into your MySQL Client and see what that returns... Whoops.. If you don't have a MySQL client, well, you'll just have to take my word for it that bad things follow.
I could spend all day (or night in this case) discussing all the different types of SQL Injection attacks, and all the proper ways to combat them; fortunately I don't have to because 2,990,000 pages have already gone down that path according to the mighty Google. That is beyond the scope of this article. What I want to talk about is why this is still happening. Why do we still see hundreds of new sites and apps each year falling victim to something that is so widely known, so easy to take care of in almost any language?
The answer is simple, and is the answer to most questions about things dealing with Application Security. The answer, my friends, is pure and simple HUMAN LAZINESS.
To put it in the simplest possible way, developers, and I use the term loosely, are either too lazy to care about fixing this simple issue, or too lazy to learn that it is an issue.
Option 1: Too lazy to care
This covers a pretty broad scope of excuses and general B.S. that these self proclaimed developers will use. Everything from "I didn't think that my app would get enough exposure to attract hackers." to "There's nothing worth stealing in my application anyways."
For the too lazy to care breed, let me just tell you this. Skiddies love your small website that you built for your bowling league photo album. You know why they love it? They may be skiddies, but even they know that they can completely take over your site and you will never be any the wiser because you are the guy that would never, never, ever expect to have your site pwnt.
Option 2: Too lazy to learn
I think this covers the vast majority of the people who are guilty of belonging to this caste of developer, specifically in the web space. This is the guy that got a PHP for Dummies book for christmas from his wife's brother's dog's former owner, read the first two chapters, and starts up a project on SourceForge for the newest latest greatest web app in the world. You sir, have commited the 8th Deadly Sin - "Thou shalt not distribute code that sucks"
So there it is. This is why SQL Injection has been and is still on the OWASP Top Ten List since 2004 when it was incepted.
In conclusion, I challenge you, blog-o-sphere, developers, humans - to write your next batch of code with input filtering and proper validation, or using parameterized queries (which I believe are available in almost every major interpreted or server-side language there is by now).
I challenge you to get this off of the OWASP Top Ten List for 2010.
I challenge you to overcome the laziness and put time and effort into learning your craft, or walk away and leave it to the people that do. There are plenty of ways you can get your information onto the tubez without ever having to write a single line of code.
While you're at it, I challenge you to share this post with your friends who may or may not fall into one of these categories, your friends who will read this and nod their head in agreement, and your friends who simply like to slashdot and facebook share every single page they come acrossed.
Until our next blog-o-spheric confrontation - may the schwartz be with you, farewell, and thanks for all the fish!
If you do a google search for SQL Injection, you will see 'Results 1 - 10 of about 2,990,000 for sql injection'
Yes, you did read that correctly.. That really does say 2,990,000 results for SQL Injection. Seeing that should raise a big red flag in your minds eye, a big red flag that says, "Why, oh why is this still an issue?"
Code Injection as a generalized vulnerability is the act of embedding executable code into an application thereby forcing that application to perform an action specified by the user. This is a pretty broad description and really describes anything from a BOF (that's buffer overflow for you non-l33t types) to XSS (Cross Site Scripting) to my favorite SQL Injection.
Let me digress for a second.
The vast majority of websites on the internet are run by one guy in his spare time. Not every site has a Development Team full of Architects, Designers, Security Analysts, QA Analysts, and Database Administrators. That one guy acts as all of those people, and more often than not, doesn't look very good with any of those hats on. That one guy also relies on the 'frameworks' he downloads off of the interwebz to take care of all that tedious difficult stuff for him. Keep that in mind as we move forward along the tracks of my train of thought.
SQL Injection differs from most other types of code injection in that it has the ability to change the persistent state of an application or a site. There are some other forms of code injection that can do the same thing either by themselves or by accessing the persistent storage used by the application in the injected code, but every Skiddie in the world knows about ' or 1=1. Thus, if your app has this:
$badSQL = "Select * from users where username='$_GET['username']' and password='$_GET['password']'"
You end up with:
select * from users where username='Administrator' and password='' or 1=1
Go ahead now and type that into your MySQL Client and see what that returns... Whoops.. If you don't have a MySQL client, well, you'll just have to take my word for it that bad things follow.
I could spend all day (or night in this case) discussing all the different types of SQL Injection attacks, and all the proper ways to combat them; fortunately I don't have to because 2,990,000 pages have already gone down that path according to the mighty Google. That is beyond the scope of this article. What I want to talk about is why this is still happening. Why do we still see hundreds of new sites and apps each year falling victim to something that is so widely known, so easy to take care of in almost any language?
The answer is simple, and is the answer to most questions about things dealing with Application Security. The answer, my friends, is pure and simple HUMAN LAZINESS.
To put it in the simplest possible way, developers, and I use the term loosely, are either too lazy to care about fixing this simple issue, or too lazy to learn that it is an issue.
Option 1: Too lazy to care
This covers a pretty broad scope of excuses and general B.S. that these self proclaimed developers will use. Everything from "I didn't think that my app would get enough exposure to attract hackers." to "There's nothing worth stealing in my application anyways."
For the too lazy to care breed, let me just tell you this. Skiddies love your small website that you built for your bowling league photo album. You know why they love it? They may be skiddies, but even they know that they can completely take over your site and you will never be any the wiser because you are the guy that would never, never, ever expect to have your site pwnt.
Option 2: Too lazy to learn
I think this covers the vast majority of the people who are guilty of belonging to this caste of developer, specifically in the web space. This is the guy that got a PHP for Dummies book for christmas from his wife's brother's dog's former owner, read the first two chapters, and starts up a project on SourceForge for the newest latest greatest web app in the world. You sir, have commited the 8th Deadly Sin - "Thou shalt not distribute code that sucks"
So there it is. This is why SQL Injection has been and is still on the OWASP Top Ten List since 2004 when it was incepted.
In conclusion, I challenge you, blog-o-sphere, developers, humans - to write your next batch of code with input filtering and proper validation, or using parameterized queries (which I believe are available in almost every major interpreted or server-side language there is by now).
I challenge you to get this off of the OWASP Top Ten List for 2010.
I challenge you to overcome the laziness and put time and effort into learning your craft, or walk away and leave it to the people that do. There are plenty of ways you can get your information onto the tubez without ever having to write a single line of code.
While you're at it, I challenge you to share this post with your friends who may or may not fall into one of these categories, your friends who will read this and nod their head in agreement, and your friends who simply like to slashdot and facebook share every single page they come acrossed.
Until our next blog-o-spheric confrontation - may the schwartz be with you, farewell, and thanks for all the fish!
Labels:
development,
security,
sql injection
Subscribe to:
Posts (Atom)