Tuesday, December 29, 2009

So, you wanna network online,too?


Dhanjani, Rios and Hardin can be ordered from many sites but I get mine free through my company's Safari online account. I get 60 free tokens per month that I can use for downloading into PDF formats. 1 entire book like Pro Spring 2.5 cost 30 tokens but you can spend like 10 tokens for a chapter. Of course, you don't have to spend a single token while reading online.

A good service which I am appreciable for.

Anyway, back to the book and the chapter "Intelligence gathering on your attack targets.". I previously listed ways to gain valuable information on hacking targets using little work and no dumpster diving. The previous post was geared towards attacks computer systems but not human targets.

What is a little more interesting is attacking specific people. This is one of the key issues behind Facebook' recent privacy issues. Never mind a user setting a "privacy filter" on their profile, they show it to friends. Is it easy to become a friend?

For my example I select a particular target which was a former CIO of mine in the past. (I never act upon this information, merely as a proof of concept.) It was pretty easy.

1) First of all, Wake County Real estate listings will give you the person's home address, a picture of the place (for god's sake) and what the dude payed for it among other things.

2) Second, Linked - In: The professional's information database. Oh man, this site is a treasure trove of information.

Linked in..... with the bad recession and job losses many people are looking for ways to network with others to find that next job. Hackers can also use it to build a dossier of an attack target. I went to Linked in and created a fake account. You have to have an account to be able to get more information on a target.

I searched and found my former CIO. What do I see? I see his complete work history, education history and other nuggets of valuable personal information. Combine that with the fact that most people choose passwords based upon their personal information, it wouldn't be hard to plug this into a brute force password cracker.

What else on Linked in? Well, this guy listed his personal website on his profile. I visited this site and, my-oh-my, it's a family photo website. Now, I have pictures of his wife, kids, grandparents and friends. I also get the names of his family so I can match the picture with the name.

With those two sites, I now have almost a complete history of this guy with pictures! The fun a real hacker could have with this information.

Saturday, December 26, 2009

So, you wanna social network?

Hey everyone, Merry Christmas! I'm off from grad school for the semester and need to study for my Master's comp exams in March but I'm doing some research in a few different areas and thought I would post a few thoughts.

I've been reading the book Hacking the Next Generation by Dhanjani, Rios and Hardin and that got me to thinking.... The authors explain in the chapter "Intelligence gathering" that in order to execute a successful attack against a target, the attacker must gain as much intelligence about the target as possible.

What are some of the ways the authors suggest to gather intelligence? The Internet of course. I used my former company as an example target. What if I was a disgruntled former employee bent on vengeance against either the company as a whole or just the former CIO? Both are ripe for the plucking.

1) Gathering information on company technical infrastructure - an attacker needs to know as much about the target's computer systems and infrastructure. One way to do this is to use a search engine and look for keywords such as the company's domain address. The reason I chose this was that, as a programmer, I am always searching forums and other source of information on problems that I may be having. So, I search for my former company's email address on Google.

I see some very interesting information. I come across some postings from software developers on the SpringSource developer forums. I know they are from my former company since the posters are using the company's email address in their profiles. From these postings I gather the team is using Spring framework for their MVC layer. If I wanted to attack some of the systems, I can find vulnerabilities in the Spring framework that I can utilize. I also see that one of the developers posted a URL of one of the development servers where others can test his theories. I can also use this URL as the attack target since it is accessible to the outside world. And since this was a development server, it is possible the perimeter defenses aren't as formidable as those on the production servers.

2) Using Google hacking as an intelligence source - Google is a well known vehicle for intelligence gathering. JohnnyIHackStuff has a great Google hacking database on his site. I first try a few searches using "filetype:doc companyname" as a start. Hello! in the first 10 hits I find the online resume of a former developer. The "Skills" and "Projects" section of this resume gives me some very critical information.

First of all, I see Websphere server experience. I now know that this company is using IBM's Websphere as a webserver. I make a note of this. In the experience section, I also see that this developer worked on a Single Sign On application for this company. If I can find a user id and password for the SSO application, it is possible that I can get access to many of the company's critical web applications. I also find it interesting the SSO is a homegrown SSO type of application. Very good news for me since commercial brand SSO's traditionally have had security holes. What kind of holes does a homegrown SSO have? Lot's, I'm sure.

The developer mentioned that he/she built a JAAS authentication model that users of the SSO use. The developer also put in that he/she built an developer SSO hack so developers can bypass SSO on developer machines. I wonder if the hack made it into production? Probably so. I also wonder if this developer (whom so nicely put contact information in the resume for me) is as disgruntled as I am? It may be worth a few beers to talk with this developer about his experience at the former company. Maybe $1000 would interest him for some details about his SSO experience?

That's it for now. It literally took me 15 minutes to get this amount of information.

Next up will be a post on intelligence gathering targeting the former CIO of this former company.

Saturday, November 21, 2009

Packet fragmentation vs the Intrusion Detection System

How well does Snort IDS handle packet fragments when the fragments could contain a potentially malicious software attack? Let's read on.... I found a really great article written in 2007 on how an author setup a lab environment to test this theory. Here is the URL: http://www.windowsecurity.com/articles/Packet-fragmentation-versus-Intrusion-Detection-System-IDS-Part1.html


Before we get into the article let's explore some background information on packet fragmentation. Let's find out what exactly is packet fragmentation and how packets are fragmented.


What is packet fragmentation?

If IP packets are coming into your network and one or more packets are larger than the network's defined Maximum Transmission Unit (MTU), the packet(s) must be broken up into smaller pieces in order to allow the packets to traverse the network. These smaller packets are called fragments. For more information on the protocols involved with packet fragmentation and reassembly, you can visit the RFC's at http://tools.ietf.org/html/


What is the MTU?


I just mentioned the MTU. What is an MTU? The MTU is defined as the largest datagram that can be sent over the network. The network admin has some default sizes to work with. For example, on Ethernet networks the default MTU is 1,500 bytes.


What fields are involved in packet fragmentation?

Answer: look to the IP header. Every IP packet has an IP header that stores information about the packet. Some of the fields on the IP header are the IP version (ipv4, ipv6), the identification field, source and destination IP addresses and total length. Three fields involved in packet fragmentation are (1) identification (2) fragbits or flags and (3) fragment offset.


Let's look at these 3 fields in more depth..... For more information, you can peruse the RFCs at this address: http://www.faqs.org/rfcs/rfc791.html

  1. IP header identification field: The identification field is a 16 bit field provided by the sender that aids in packet reassembly.

  2. Fragbits: The fragbits field is a 3 bit field that contains 3 control flags. Bit 0 is reserved and must always be 0. Bit 1 is the DF fragbit that stands for "Don't fragment". This bit can have 2 values: 0 (may fragment) or 1 (don't fragment). Bit 2 is the MF fragbit that stands for "More fragments". This bit can also have 2 values: 0 (last fragment) or 1 (more fragments to come)

  3. Fragment offset: This is a 13 bit field that indicates where in the datagram this fragment belongs. The first fragment will always have an offset = 0

IP Packet fragmentation example

Given the information from above let's take a look at a simple example of how a packet is fragmented. Say we have a 2366 byte packet coming into our Ethernet network. You may remember that Ethernet networks MTU is 1500 bytes so our packet will need to be divided into 2 fragments.

  1. Fragment 1: The first packet will be 1500 bytes in length. The first packet's DF fragbit will be set to 0 that means "may fragment" and the MF fragbit will be set to 1 which means More fragments to come. Since this is the first fragment, the fragment offset will be 0

  2. Fragment 2: The second packet's DF flag will still be set to 0 to mean "May fragment" but the MF flag will be set to 0 that means this will be the last fragment. The fragment offset of this packet will be somewhere around 910 or so. This is calculated based upon the data portion of previous packets and doesn't include the 20 or 40 bytes for the packet header lengths.
How does packet fragmentation lead to attacks?

Let's take our 2 packet example from earlier and see what an attacker may be able to with it.
What if an attacker wanted to telnet into our remote computer using TCP port 23 for whatever reason and what if that port is blocked by packet filtering firewall. The attacker would probably do a port scan and see which ports are open on our remote computer and what if he sees that the SMTP port 25 is open? Most likely he decides to craft a packet fragmentation attack where the first packet has the following: the fragment offset of 0 (since its the first packet), the DF flag = 0 (may fragment), the MF flag = 1 (more fragments) and the destination port = 25.

The second packet the attacker will force the fragment offset to be 1 - the reason is that offset 1 will be so low that instead of appending it to the first packet it will overwrite everything in the first packet except the first 8 bits. The attacker will also set the second packet's TCP destination port to port 23 - which normally would be blocked but not in this case since the attacker has set a fragmented packet. The packet filter sees that the offset of this second packet is greater than 0 so it will think that this is a fragment of another packet and won't put it through the ruleset.

When the 2 packets arrive at the target host, it will be reassembled and most of the first packet will be overwritten by the second and the combined packet will be allowed to go to port 23.

The article.

Now, we finally get to the actual article. In the article the author states that intrusion detection systems have traditionally had problems with packet reassembly and that they still have issues today. Even though IDS's have gotten a lot smarter in how it reassembles packets, the author wanted to see how well Snort IDS performs when it comes to detecting some simple packet fragmentation attacks. The article's goals are to (1) Show how well Snort can detect simple packet fragmentation attacks and (2) use Metasploit and fragrouter to fragment packets sent to a victim computer running Snort IDS.

The author sets up a lab environment to launch and measure the attacks. The author sets up 3 computers - the attack computer will have Metasploit installed. The middle computer will have fragrouter installed and the victim computer will have the packet sniffer and Snort installed.

What is fragrouter?

We have all seen and used Metasploit and a packet sniffer (Wireshark) so I won't explain those two software tools but I"ll briefly describe fragrouter. According to insecure.org, fragrouter is one of the top 100 security tools of all time. It is used mainly as a "Network Intrusion detection evasion toolkit". Packets are sent to fragrouter which transforms them into fragments and forwarded to the victim. The author started fragrouter with the F1 option which means to send the fragmented packets in order. Other options, like F2, F3, etc are meant to allow the attacker to send packets in any order they wish.

You can see all of fragrouter's options by listing with the fragrouter -help option. You can see all of the options to run fragrouter with different combinations.

Once the author has his lab environment setup, he is ready to launch the attack. In a nutshell, the author wants to launch a Metasploit MS03-026 attack that is routed through a middle computer running fragrouter. Fragrouter will break up the attack in multiple fragments and send them on to a victim computer. The victim computer is running Snort IDS and the author wishes to see how well Snort detects the attack through fragmented packets. So, Snort has to reassemble the packets, detect the attack, and list any fragmented packets it finds.

The Metasploit MS03-026 attack targets a buffer overflow vulnerability in Microsoft XP. The author then used the win32-reverse payload to actually try to get a remote shell access on the victim computer. Once the author gains shell access on the victim computer, he stops the attack and views Snort's statistics. Since the route was setup to forward all packets from the attack computer to the victim computer through the middle computer running fragrouter, the victim computer should see fragmented packets. I actually tried this exploit on my VMWare setup and attacking the XP VM. Metasploit told me that this VM was not susecpible to this vulnerability so I would imagine that it could be a service pack issue.

Fragrouter does produce output information to the console. It will list the fragments as well as the offset as it is doing the fragmentation.

What did Snort detect? Snort logged 7 items and 2 alerts. The interesting thing was that Snort detected 271 fragmented IP packets during the attack session. Without using fragrouter, the author performed the same attack with the same payload and Snort detected 0 fragmented packets.

Snort foiled our attempts at being stealthy by using packet fragmentation. It detected the exploit use as well as detecting the fragmented packets.

Conclusion: We can conclude from the experiment that indeed Snort is effective at detecting some simple packet fragmentation attacks. We have been shown how to use Metasploit to launch an attack going through a middle computer that fragments the attack into fragments and sent on to the victim computer with Snort running on it. There are certainly more scenarios at using fragrouter and Metasploit and that can be a future point of experimentation and is left up to the reader.

Friday, September 4, 2009

Stephen Northcutt of SANS Institute - "I think organizations should avoid Adobe if possible. Adobe security appears to be out of control".

Stephen Northcutt of SANS Institute - "I think organizations should avoid Adobe if possible. Adobe security appears to be out of control".
This is unfortunate news in my opinion. Bad publicity for Adobe and all of the good things and software that they provide and bad news for the developers out there creating slick applications using the Adobe Flex platform.

Northcutt is a bigwig tech guy from SANS. SANS Institute (http://www.sans.org/) is a highly respected organization and you can't take their statements lightly as say, a back page editorial on Inforworld. I believe alot of the flack comes from the slow and unresponsive update protocol that Adobe seems to be famous for. Microsoft usually releases updates monthly and I think I have read that Adobe recently announced a new updating strategy where they are planning to release updates quarterly. In my opinion, that is too infrequent.

Most of my experience in webappsec has been in the traditional browser based HTML based applications where you worry about vulnerabilities like improper input validation or not escaping output leaving yourself open to XSS. I have no idea how applications living inside of the flash player are exposed to attacks other than the reported problems with vulnerabilities within the Flash player itself. At a recent OWASP meeting, we had a guy from HP who demo'ed a slick, expensive offering from them that scans corporate software and reports leaks. I asked about if this software could flag Flex developed applications and I was told it could but I can't put a finger on why they were confident that it could. Maybe I don't remember or understood their explanation! Anyway, it involved something that was not of the traditional model.

It would seem logical that a Flex based application would take a little more skill to do a phishing style attack. The bogus site would have to be also developed in Flex, which I could see as doable. This is worth keeping on the radar especially as Flex is used in sensitive software such as online banking.

Wednesday, August 19, 2009

Hacking without going to jail.

I asked this question of the experts at the last OWASP group....if I want to get more familiar with tools such as Burp and Paros Proxy, how can I test against websites without getting myself into trouble?

The answer is here at hackers.org... this list is a list of sites that you can point your tools towards without going to prison.

Thursday, August 6, 2009

Notes from Raleigh OWASP meeting held on August 2009.

Hey all,


I'll take a break from web application security tools assessments from a beginner's perspective and talk about what I observed from the Raleigh OWASP meeting held on August 06, 2009. I say take a break but what we discussed at that meeting is relevant to the recent blog posts on this very site.

We spent most of the time comparing web application security assessment tools - one that is commercial and has a decent price tag of $30,000 per seat - and a few that are freely downloadable and open source. Hans from HP presented WebInspect (click here, Hans mentioned that you can download a free to use 15 day trial). This one is the commercial offering and I must say, $30,000 is too cheap. Once you play around with the free ones, Paros (discussed in last post) and/or Burp , you realize what WebInspect can do. Hans did a great job presenting this tool and explaining all it can offer. It is totally customizable with respect to what it submits in form fields in tests - therefore better equipped to handle wizard style forms that are often found in login types of applications. The complex vulnerability scans can take hours or days and sometimes could go to the limits of what the target server can handle. It can create thousands of postings on forums, look for sql injection and XSS problems, browse for directory listings. The reporting that WebInspect offers is very extensive. The idea is that the security experts can run the scans, create the reports with the nice graphics and send them to the executives.

The other tools demonstrated by Steve were Paros, W3AF and Burp. What I found suprising was that the professional pen testers still use the free tools in their day to day duties. Steve mentioned that Paros's crawler (and I assume he means spidering) is very fast compared with WebInspect or Burp. It is a good thing to run a quick scan to find the most common problems quickly - a better-than nothing proposal.

Steve mentioned that development is dead on Paros with the last release in 2004 and he still likes it. I didn't take notes but I thought he said that he is part of the JRuby team that is writing a new edition in JRuby.

Try Googling: Paros Proxy, Burp or WebScarab (an OWASP project) to find links to download these free tools. Or download WebInspect from the link above to get a 15 day trial and let me know how it works.

Saturday, August 1, 2009

Paros Proxy and Mapping a Web application

I mentioned in my last blog post that we will be looking at 3 common web application hacker tools but lets draw back that ambitious statement and start with one. I've already downloaded and installed Paros, so I'll start with that one. You can find this sweet tool at http://www.parosproxy.org/index.shtml. The version that I am using is version 3.2.0 released on November 2004.

For Windows installation it was easy, as I just let the Windows installer install itself but you must also download the latest Java JRE to get it to run correctly. Downloading and installing Java will be beyond the scope of this posting.
To set up Paros as an HTTP proxy you will use port 8080 for proxy connections and 8443 for SSL handling. Browse my last blog posting on HTTP proxies and how to set those up in your Internet Explorer, Firefox or Opera web browsers.

Once you have installed Paros, click on the launcher and you should see the Paros home page like this.


We will illustrate the value of a tool like Paros by practicing the first approach of a hacking session by what is called "mapping the target application." Mapping the application will give a hacker a better understanding of what the application is about and what the hacker is up against. According to the Web Applications Hacker's handbook, begin mapping by enumerating the applications' content and functionality in order to see what the application actually does. Some of the content will be easy to find and some will be hidden away and requires a little sleuthing to uncover. This is where the toolsets shine.
In the typical application, the majority of content can be discovered by manually browsing. The basic approach is to start at the home page and navigating through all the links and menu options until you have created a 'site map'. If the application already has a site map, that makes it easier - start there. As you can see, manually mapping and creating a rigorous inspection is a daunting task.
Web Spidering

Paros includes a tool called a web spider. This tool works by requesting a web page, parsing it for links and other content, then requesting those, continuously recursively until no new content is discovered.

Spiders attempt to acheive a high level of coverage by even submitting random and preset variables in parsed HTML forms. The spider can then analyze the response for even more valuable information. This allows spiders to walk through wizards and other mulit stage functionalities. Some other spiders can also parse Javascript to extract even more URLs and content.

To use Paros' Spider, you must first browse a site in a proxy session. Here is a screen shot once I've visited NFL.com:

To spider using Paros, you have to first browse the site and it will start adding the history to the left hand tree view. Notice all of the click thru URLs that it captures!

Select one of the sites in the tree view, I'll select NFL.com and choose Analyse -> Spider. Paros will bring up a dialog and start crawling...


You can tell Paros where to spider by directing the spider. The next steps that you can take is to manually and auto spider. See what the tool discovers and you don't. Then you can see if you can figure out why you couldn't discover some of the content that Paros does. Use Paros to discover valuable hidden content. Examine any error messages that are generated to see if you can figure out the technology behind the application. Hackers use this information to launch more sophisticated attacks.
That's it for this blog posting. The next posting will continue with Paros spidering and examine more advanced features and usefulness of application spidering. Now create those site maps and examine what you discover and what Paros discovers.





Friday, July 3, 2009

Hacking tools - HTTP Proxies

Finally, we get to the good stuff! This post is another in the series of how to use freely available tools to hack web applications. (White hat style!)

The most useful tool in your hacking or pen testing arsenal will be the HTTP proxy server. A proxy server is a server that mediates requests between your browser and the destination web server. When attacking web applications, the proxy server will allow you to intercept and modify all requests and responses. HTTPS? Even through https.

The intercepting proxy lies at the heart of your tool suite. To use it, you must configure your browser to use the proxy server to listen to a port on your machine. The proxy tool is configured to listen to that port and receive all incoming and outgoing requests. The coolest thing is that the proxy can 'stall' each message for review and modification by the user, along with other useful functions.

Configuring your browser to use a proxy server....

First, establish the port that your listening proxy will use for communications. This is usually 8080. Depending on which browser you use, the next steps will detail how you do this:

  • Internet Explorer - go to Tools -> Internet options -> Connections -> Lan settings. UNCHECK: "Automatically detect settings" and "Use Automatic configuration Script" boxes. CHECK: "Use a Proxy Server for your LAN" box. In the "Address" field, type in localhost. In the Port field: enter the port number (usually 8080 as mentioned above). Click the advanced button. Make sure the applications you are targeting are not listed in the "Do not use proxy server for addresses beginning with...." box. Click OK and you are done with configuration of the browser.
  • Firefox - go to Tools-> Options -> Connection settings. Check the "Manual proxy configuration" option. In the HTTP proxy field, enter localhost. Also, enter 8080 in the port field. Check "Use this proxy server for all protocols." box. Make sure the applications you are targeting are not listed in the "No proxy for..." box. Click OK and you are done with configuration of the browser.

In addition to the core functionality that proxy servers provide as listed above, the proxy tool suites contain a wealth of other features to assist you in attacks.

  1. Configurable interception rules - In a typical application, many of the request and responses are of little interest. This funtion allows you to configure the proxy to show only messages that are of interest to you. You can configure such things as the target host, URL, method, resource type, and many more.
  2. Web application spiders - This funtion will allow you to specify a target host and then the spider will recursively request links, then follow those links until all of the site's content has been discovered. Spiders are useful to map the target application. We will get into more of application mapping in a future post.
  3. Application scanners - To be a great hacker, you must use automation to launch successful attacks. Scanners can be used to scan target hosts checking for common vulnerabilities by sending a set of attack strings and analyzing the responses to identify signatures.
  4. Manual requests - sometimes it can be useful to send a single request and examine the response. Especially if you probing a specific vulnerability and want to issue the same request over and over again.
  5. Many other features!

That's it for this post. My next post will examine the 3 top common tool suites that contain the features listed in this post. We will look at Paros, Burp and WebScarab.

Wednesday, July 1, 2009

A quick post about web application encoding schemes

Before we get into tools discussions, lets talk a little bit about character encoding schemes. You may remember from my last post that as far as input into a web application goes, assume that all input is malicious and a developer must solidify the defenses to reject known bad content. So, you, as a developer craft together a pretty good regex expression that you pass all of your input through. As long as it's human readable character data, you should be OK, right? Wrong. Attackers can manipulate a character encoding scheme used by an application to cause behavior that the developers did not intend.

Let's look at the common character encodings:

URL Encoding

According to the Web Hacker's Handbook, URLs are permitted to contain only the printable characters in the US-ASCII character set. Therefore, a encoding scheme for URLs was created in order to safely transmit any problematic characters within the extended ASCII character set. For example, the ? and & characters in a URL has a special meanings related to request parameters. If you wanted to inject these characters as data you will need to pass the encoding equivalent.

Here are some common characters in URL encoding:

%3d - =
%20 - space
%0a - new line

Unicode Encoding

This character encoding scheme is designed to support the writing systems all around the world. It can support unusual characters in web applications. 16 bit Unicode encoding and UTF-8 are common unicode encodings.

For example, in UTF-8 , each representation of a characters is a hexidecimal and preceded by a %.

%c2%a9 - copyright

When attacking web applications, unicode encoding can sometimes be used to bypass input validation mechanisms. If an input filter blocks certain expressions, but the component that immediately is invoked after bypassing the filters understand unicode, then it could be possible to launch an attack.

HTML Encoding

This scheme is used to display problematic characters in HTML pages. Some characters have special meanings that are used to define the structure of the document rather than content.

For example, to use these characters as part of the document content, you must HTML encode them:

" - "
' - '
& - &

On top of this, any character can be HTML encoding using its ASCII code in decimal form:

" - "
' - '

HTML encoding is used mainly in checking for XSS vulerabilities in web applications. If an application does not HTML encode its responses, then the application could be vulnerable to XSS attacks.

Base64 Encoding.

This encoding is used primarily for transferring binary information represented as printable ASCII characters.

Sunday, June 28, 2009

Where do you start when hacking a web application?

Many of the web applications out there today explain that they are secure. According to the Web Hacker's Handbook, many sites tout their SSL as their claim to be secure. Of course, SSL is good - it prevents eavesdropping and keeps your content safe between browser and server over the Internet.

The fundamental security problem with most web applications is that the input is not under direct control of the application. Users all over the world can submit any arbitrary inputs to the application. The developers of the target application must therefore assume that each piece of input is malicious. The list of the Top 25 Most Dangerous Programming Errors compiled by the SANS institute and the MITRE organization in January 2009 describe the top 2 errors that revolve around malicious input and improper escaping of outputs.

The simple fact is that any user anywhere in the world can craft a special string to any publically accessible application that can wreak havoc for the organization. Couple that with the fact that the user doesn't have to use a web browser to interact with the application. There are numerous tools out there that are freely downloadable that can interact with web applications, even trapping the request from the client before it gets to the server and provides the attacker the ability to modify certain parameters that can totally bypass any validations.

Next post will get into the beginnings of how to use tools to completely map a target application.

Tuesday, June 16, 2009

Changing direction....

I decided that I needed to stop the Metasploit experimentation and go back to the basics of web application security. The Raleigh OWASP chapter got together this June to talk about how to use certain software that is useful in performing network penetration testing and I thought that would be a great place to start. I am going to start a blog series on using these tools and techniques to try and break your or someone else's web application defenses.

On our OWASP listserv someone mentioned a book that I looked into and as a newbie I think it is pretty awesome. It is called The Web Application Hacker's Handbook. Here is the information from Amazon:



I didn't buy it from Amazon but I was able to utilize my Safari Books online account to start reading the book. According to the book's introduction, this book is a practical guide to discovering and exploiting security flaws within web applications.

What I like about this book is the way the authors describe the process of hacking into logical steps. They start out by telling you why mapping your target application is important. Then they tell you in detailed steps how to do it. In addition, they list the tools that assist you in performing the tasks. The more experienced members of the OWASP group have told me about these same tools as listed in the book so they seem to be up to date and topical.

In more postings, I will get into how I started using this book and which tools that I have downloaded and installed. Hopefully, Metasploit will make more sense to me once I have a chance to get through this book!

In a related note, I thought it would be a good idea to spend the summer before school starts this semester studying for the CISSP certification exam. It costs around $500 to sit and the next test is for November. I would have to take the associate exam since I don't have the required professional security experience but it would be good for my career to pass it. Stay tuned.

Tuesday, April 21, 2009

My first published paper!

The good people at InfosecWriters.com have announced that they will publish my research paper on the SANS/CWE Top 25 Most Dangerous Programming Errors. Click here for more information on this list from the SANS Website.

I wrote this paper for my Spring 2009 grad school class at ECU as we do pretty much every semester especially for Dr. Lunsford's class. He always asks us to submit for publishing and this time they latched onto mine.

Here is a link to my entry: http://www.infosecwriters.com/texts.php?op=display&id=646

Thursday, April 9, 2009

Metasploit - downloading and installing Metasploit framework for a newbie.





I'm doing a small presentation on the Metasploit framework for my Advanced Network Security course at ECU and I thought I'd put my experiences down here.

Getting started, I went to the Metasploit's framework site on the support side and downloaded the user guide (PDF format). This is a pretty good user's guide, about 30 pages long, and easy to read. It tells me that since I am a Windows user, I need to download the last stable Windows version. I see that the current version is an EXE file that lists it at 3.2. I had read that version 3.2 came out in March and in Macworld, they say that two people worked really hard to move the best of the Windows exploits to the Mac. It seems that the Windows version is a little better (probably since there are so many exploits on that platform!)

First problem! Avast, my anti virus software, flags the downloading file as containing a few Trojans. I immediately stopped downloading and went to Google to see if I could find some information. I saw a bunch of hits for Avast and Metasploit. I selected and read a few and basically it sums up to :there aren't any trojans in metasploit.

I stopped Avast and redownloaded the file trepidly! I finished the download and clicked the installer file to install the framework. By that time, I had re-enabled the Avast software. During installation of Metasploit, Avast agained complained a few times about Trojans and I dismissed them (about 5 or so alerts in total).

Start Metasploit launched a DOS Window that scrolled a lot of files, for what seemed 3 minutes. Finally I got the splash screen and Metasploit Framework GUI v3.2.

More information next as I play around and see how it works. I'll also report if I ever find any Trojans. I will run Spybot and Adaware also.

I tried to list a few books from Amazon on using Metasploit but the links failed this morning when I looked at it. Deleting now....

Tuesday, April 7, 2009

New OWASP Cheetsheets.

The Open Web Application Security Project has released two cheatsheets aimed at helping development teams thwart XSS and SQL injection attacks.


XSS : http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

SQL Injection: http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet


The cheatsheets explain how proper output encoding goes a long way to mitigating these types of attacks. And SQL injection is up to about 30% of all malicious attacks on web applications so any protection against these attacks will be worth it to your project.

Friday, March 20, 2009

The best defense is information.

While researching the new version of Metasploit I came across a good blog post there that kind of sums up my term paper for school this semester - The best defense is information. Matter of fact, that is one of my best lessons or goals from my paper on the SANS / CWE Top 25 most dangerous programming errors. Keep up , with podcasts, SlashDot, blogs, etc.

This blog posting on Metasploit's site talks about the recent Adobe 0 day exploits last February. The poster says that security providers by and large depend alot on public information to keep users safe.

http://metasploit.com/blog/#blog-0

Saturday, March 14, 2009

Securing your email.

Encrypting your email.

Here is a good article on how to encrypt your emails:
http://www.wi-fiplanet.com/tutorials/article.php/3786446. Here is a link to one of my favorite podcast transcripts where they also talk about email security: http://www.grc.com/sn/sn-182.htm.

Make sure if you use Gmail, make sure to use https rather than http. I have found that if you go to www.gmail.com, it will put you in SSL for logon only. Once, you log in, you go back to plain old http.

If you go to https://www.gmail.com after you log in, you stay in https. I don't know why that's not the default. Also, I am looking forward to the day where all email systems, including Outlook, doesn't have PGP built in tranparentlly. If I sign up for an email system, the first things that should be done is to have me sign up for a certificate.

Lastly, if the contents of the email is really sensitive, encrypt the attachments with a tool such as TrueCrypt, send the email and then call your recipient and give them the key to decrypt.

Friday, February 13, 2009

Notes on first 9 CWE/Sans errors.

Note from Fred: Please forgive the formatting on this post...I copied and pasted from a Word doc to share with a friend of mine and the formatting didn't translate very well. I don't want to delete the post and too lazy to reformat everything so I'm leaving as-is.


1) CWE20- Improper input validation.
a. Summary
i. Prevalence – High
ii. Remedy Cost – Low
iii. Frequency - often
b. The number 1 killer of healthy software
c. SSL does not protect you from some injection attacks
d. Validate your input. Use an “accept known good” strategy – reject all input that doesn’t conform and assume all input is malicious
e. For example:
i. if you have a numeric identifier and you shouldn’t allow alphanumeric
ii. Entering a negative number instead positives and a bank balance is credited instead of deducted
iii. Passing in a size into a method that creates an array. If the size = 0, an array of length 0 would be created and if any items are attempted to be added to the array, an exception would occur.
f. Input can arrive via Form fields or input parameters on web service clients
g. Many common vulnerabilities can be thwarted using proper validations
h. Applicable to all computer languages
i. Likelihood of occurrence – High
j. XSS (CWE-79) or SQL Injection (CWE-89) are 2 consequences in a failed input mechanism.
k. Solution? Validation framework (Spring) combined with client side UI validation frameworks such as you get from a JS library like Dojo or GWT or Flex.
i. Apache Commons Validator (http://commons.apache.org/validator/) – which is what I think Struts used
ii. Try to check client side as much as possible to reduce server processing
iii. Ajax libraries – should look at these calls also and provide server side checks since these can open an application up to DOM based XSS attacks. A lot of times, Ajax libraries gather data and replace a DIV tag with data. If an attacker can inject some javascript in there or similar code, then XSS will be a problem.
l. Validate entries as separate entities and then validate combined. Sometimes individual entities pass but when combined it can transform into something else that doesn’t pass.
m. Code examples:
i. Check on client via regular expression, javascript, Flex properties, JSTL
ii. Check on server side via validation frameworks like Spring, PHP framework
iii. You have a form field that is SSN: make sure it has 3 digits, 2 digits and 3 digits: \d{3}-\d{2}-\d{4}
iv. Only allow alphanumeric characters with 40 characters in length.
n. Ff
o. Ff
p.
2) CWE-116 - http://cwe.mitre.org/top25/#CWE-116 – Improper encoding or escaping of output
a. Summary
i. Prevalence – high
ii. Remedy Cost – low
iii. Frequency – often
b. Likelihood of exploit – Very high
c. Root of most injection attacks. This is due to the fact that the nature of injection involves the violation of structured messages.
d. Attack: Attacker modifies commands sent to other components inserting malicious commands
e. Solution: When program generates output to other components in the form of messages such as queries or requests, it needs to separate control information from metadata.
f. Caution: be care in Web applications of this type of attacks where encoding can come into play for a variety of inputs: URIs, CSS attributes or HTML body.
g. Examples:
i. Getting a variable from the request and display on a webpage without properly escaping. String email = request.getParamter(‘email’); Email = email;
ii. Replacing characters with %7c (looking for and ; characters can help prevent chain-of-command attacks since OS’s can separate commands by these characters.)
iii. Replacing < or looking for these types of characters in inputs.
iv. Wikis can be especially vulnerable since they allow a subset of HTML characters as input for formatting. Use strict whitelists for this type of checking.
v. Input validation is not always sufficient. In the case of SQL injection, the last name O’Reilly would pass initial validation since it is a common last name. However, the “’” character would be stripped since it is a common SQL injection character but if this is done, the last name is altered and that may not be sufficient.
h. ??? – Look at Java encoding and escaping. For example, when inserting text into XML or HTML code, the HTML must be preserved so you would put in < instead of < href="http://cwe.mitre.org/top25/#CWE-89">http://cwe.mitre.org/top25/#CWE-89 – SQL Injection
a. Summary
i. Prevalence – high
ii. Remedy Cost - low
iii. Frequency – often
b. Likelihood of exploit – Very high
c. Targets data rich applications that store and retrieve data from a database.
d. This attack results in the 3 classic security characteristics:
i. Confidentiality – if an attacker can read your sensitive DB information
ii. Authentication – an attacker can use these attacks to assume the role of a user, even more devastating if user has admin privs
iii. Integrity – If attacker can modify data as well as read, then the data can be changed resulting in low integrity.
e. Solutions: ORMs such as Hibernate that build SQL based upon the HQL that you build.
f. Solution: use parameterized queries
g. Solution: use stored procs.
h. Solution: replace ‘ with “
i. Solution:reduce dynamic generations of SQL query strings. If you do make sure to scrub parameters supplied to DAO classes to reduce injection attacks. Since the DAOs execute on the server side, you don’t have to worry about CWE 602
j. Proper output encoding is best defense for SQL injection
k. Examples:
i. Take for example the following SQL: SELECT * FROM ITEMS WHERE OWNER= ? AND ITEMNAME = ?
ii. If the user enters: name’ or ‘a’=’a for itemname then the query becomes: SELECT * FROM ITEMS WHERE OWNER=’wiley’ AND ITEMNAME = ‘name’ or ‘a’=’a’
l. Java’s security traps have SQL injection at the top of the list. Researchers are using the Findbugs Eclipse plug in to scan for vulnerabilities

Think java is not SQL injection resistant?

rs = stmt.executeQuery(“select * from users where uname = ‘” + uName+ “’”);

4) CWE-79 - http://cwe.mitre.org/top25/#CWE-79 – Failure to preserve web page structure (XSS)
a. Summary
i. Prevalence – high
ii. Remedy Cost - low
iii. Frequency - often
b. Duplicating of client side validations on the server side seems to be a common remedy.
c. Most prevalent and dangerous vulnerabilities
d. Software developer discipline is very important to thwart XSS attacks
e. Attackers can inject JS and other code directly into the webpages that you generate
f. CWE116 – using proper output encoding can aid in XSS attacks. Most effective solution
g. Solution: set UTF-8 for your browser encoding so the browser doesn’t have to guess which encoding to use and allow yourself open to XSS
h. Solution/Example: (stored XSS) we have a web app that contains text areas that take free-form comments, etc. I can enter the following text: “
” and save. Once I bring up that record again, it brings the text into the web page and an alert box will pop up that says “Hello”.
i. Solution: (Reflected XSS) – attacker emails or posts a link to a site that contains malicious commands in the URL. When the user visits the link, the offending code can cause cookie or other private information to transfer to the attacker.
j. Solution: Practice the least privileges for users. If a superuser is subjected to a stored XSS attack, the dynamic content could provide very sensitive data from the superuser to the attacker.
k. Solution: scrub HTTP request parameters against white lists to detect common XSS exploits coming in from a URL. For example, if a web page accepts a user id from request parameters, if it contains standard text, that’s OK. However, if an attacker adds in source code or Javascript, the web page will not display the text, but execute the script.
l. Research: this blog: http://raibledesigns.com/rd/entry/java_web_frameworks_and_xss details research on Java frameworks to see how they do in preventing XSS attacks.
i. Solution: instead of using JSP EL (expression language) use JSTL such as c:out. Also see: note: still if a developer scrubs outkput for HTML, javascript, this can be prevented. http://www.owasp.org/index.php/J2EE_Bad_Practices:_JSP_Expressions
ii. Problems reported with Spring MVC (form:input / form:error) appears to be fixed
try { firstname = request.getParameter("firstname"); }
catch (Exception e) { e.printStackTrace(); }
userName = firstname;
...
pw.print(" Thanks for your feedback, " + userName + "! ");
This code allows an attacker to spit back code to the browser. For example:

5) CWE 78 - http://cwe.mitre.org/top25/#CWE-78 Failure to preserve OS command structure (OS Command injection)
a. Summary
i. Prevalence – Medium
ii. Remedy Cost – Medium
iii. Frequency - often
b. Allows attackers to execute unexpected, dangerous commands directly to the OS.
c. Leads to vulnerabilities in which the attacker does not direct access to the OS
d. Exacerbated if rule of least privilege is not followed
e. Proper encoding that supports OS commands can lessen damages
f. Java example: use the runtime.exec command to run OS commands:
initCmd = System.getProperty(“init_cmd”);
runtime.exec(initCmd);
6) CWE 319 - http://cwe.mitre.org/top25/#CWE-319 Cleartext transmission of sensitive information
a. Summary
i. Prevalence – Medium
ii. Remedy Cost – Medium
iii. Frequency - Sometimes
b. Susceptible to sniffers when you send sensitive information across a network
c. Solution: encrypt
d. Solution: Use SSL from beginning to end, not just the initial login page
e. More info: Security Now podcasts on cryptography
f. Tools – TrueCrypt
g. From OWASP:
i. Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. Encryption (usually SSL) must be used for all authenticated connections, especially Internet-accessible web pages, but backend connections as well. Otherwise, the application will expose an authentication or session token. In addition, encryption should be used whenever sensitive data, such as credit card or health information is transmitted. Applications that fall back or can be forced out of an encrypting mode can be abused by attackers.
ii. Common errors include the use of weak or deprecated SSL ciphers which can be broken and subject to man in the middle attacks. Most web servers, by default, allow insecure SSL ciphers such as SSLv2
h.
7) CWE 352 - http://cwe.mitre.org/data/definitions/352.html Cross - site Request Forgery
a. Summary
i. Prevalence – High
ii. Remedy Cost – High
iii. Frequency - Often
b. Attacker tricks a user into activating a request that goes to another site. It looks like the user is the one who initiated the request when in reality it was the attacker. If there is no way to authenticate a request was intentionally sent by a user, it will be possible for an attacker to trick the client into submitting a request to the web server.
c. May not seem like a big deal but the attacker can assume all authority on a particular site that the user has
d. Especially handy if the user has admin privs – Employ rule of least privilege
e. XSS worms that stampede through very large websites in minutes is CSRF combined with XSS
f. CSRF – can be done with image loads, via a URL, or XMLHttpRequest
g. Results? – data disclosures, unintentional code execution.
h. Solution: ensure your defenses are up to date to thwart XSS attacks CWE79
i. Example: Fusion News (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1703) example allows attackers to add user accounts. If an admin is logged in, a comment in an img tag calls index.php tag that creates a new account each time the admin goes to the page with the img tag
j. Solution: Do not use GET requests for any request that changes state
8) CWE 362 – Race Conditions http://cwe.mitre.org/data/definitions/362.html
a. Summary
i. Prevalence – Medium
ii. Remedy Cost – Med to High
iii. Frequency - Sometimes
b. Occurs in multi threaded applications
c. Denial of service and data corruption are normal attacks
d. Use thread safe capabilities
e. Avoid shared resources across threads
f. Solution: avoid threading for other multitasking solutions like queues.
9) CWE 209 – Error message information leak - http://cwe.mitre.org/data/definitions/209.html
a. Summary
i. Prevalence – High
ii. Remedy Cost – Low
iii. Frequency - Often
b. Using chatty error messages could disclose secrets to attackers
c. Solution: ensure error messages only contain the minimal amount of information
d. Solution: log more detailed information in log files. Be careful that log files cannot be read by attackers. Don’t log passwords in log files
e. Avoid messaging that may tip off attackers such as “password is invalid”. That could tip the attacker that the userid is valid and give them more information.
f. A SQL injection attack may not succeed but error information displayed as a result could give the attacker more information to launch a more focused attack
g. Example: Java – try catch blocks that System.out.println the actual message that goes back to the screen in an error message. Handle exceptions internally
Risky Resource Management.
10) Failure to constrain operations with the bounds of a memory buffer - http://cwe.mitre.org/top25/index.html#CWE-119
a. Summary
i. Prevalence – High
ii. Remedy Cost – Low
iii. Frequency – Often
b. Buffer overflows
c. Java is supposedly note susceptible to BO but applets and other attached technologies like Java Web start and more importantly the Java runtime environment are.
i. Java simply does not provide any way to store data into memory that has not been properly allocated.
d. Problems when software written in C/C++ are more susceptible
11) CWE-642 – External control of critical state data http://cwe.mitre.org/top25/#CWE-642
a. Summary
i. Prevalence – High
ii. Remedy Cost – Medium
iii. Frequency – Often
b. Revolves around the persisting of data not saved into a database but in other stores:
i. Cookies
ii. Hidden form fields
iii. Profiles
iv. Configuration files
v. Registry keys
vi. Input parameters on the URL
c. Apache Tomcat servers if not configured correctly can suffer from this attack.
i. Disable shutdown port
ii. Remove example applications that ship with Tomcat installation
iii. Force Tomcat to not cache content requiring authentication
d. Stateless protocol such as HTTP, if you want to persistent stateful information across pages, the data must be stored somewhere. Therefore, it exposes it to a malicious attacker.
e. Solution: do not store information on the client without encryption and integrity checking.
f. Solution: store state information only on the server side
g. Solution: use a framework that maintains state information for you
h. Potential attacks:
i. Shopping cart is affected when price modification occurs to a hidden form field
i. Solution implementation: Use Spring Web Flow / MVC coupled with Acegi Security to implement remember-me authentication
12) CWE 73 – External Control of File Name or Path http://cwe.mitre.org/top25/#CWE-73
a. Summary
i. Prevalence – High
ii. Remedy Cost – Medium
iii. Frequency – Often
b. When using outside or user supplied input to construct file names, an attacker can use combinations of “../” to make the system navigate outside of the intended directory.
c. If you let a user specify an external URL from which your application will download code, this sets up for worms and Trojans.
d. Solution: run only as lowest level privileged user.
e. Use whitelists to that limit characters such as “../”
f. Example:
g. Af
h.
13) CWE 426 – Untrusted search path http://cwe.mitre.org/top25/#CWE-426
a. Summary
i. Prevalence – Low
ii. Remedy Cost – Medium
iii. Frequency – Rarely
b. When locating critical system resources when running applications, for example properties files or code libraries, an attacker tries to modify the path to point to their versions. This could lead to malicious activities.
c. Solution: when running another program or accessing a file, use a fully qualified path name.
d. Solution: be careful to avoid system PATH variables when executing external programs or config files
e. Sanitize directory or folder paths when doing these activities
f. Example: if you run a program to access $PATH/file/program.sh and the attacker modifies PATH, then they could point to their application and run it with raised privileges.
14) CWE 94 – Failure to control generation of code (code injection) –
a. Summary
i. Prevalence – Medium
ii. Remedy Cost – High
iii. Frequency – Sometimes
b. If you have any code that dynamically generates code, an attacker can inject their own to alter the intended control flow of the software.
c. If you have an application that accepts as input actual source code, then you set yourself up for this attack.
d. Important to note that all injections differs from buffer overflows since buffer overflows require some other further issue to gain execution.
e. Example – by using encoding characters, an attacker could inject code where a programmer would only expect a string.
15) CWE 494 – Download of code without integrity check http://cwe.mitre.org/top25/#CWE-494
a. Summary
i. Prevalence – Medium
ii. Remedy Cost – Medium to High
iii. Frequency – Rarely
b. When downloading code to execute from a remote location, make sure to verify the origin and integrity of code
c. Attacker can use DNS spoofing, compromise the host server, or modify the code in transit.
d. Solution: use encrypted channels when accessing remote code, for example thru the Java URL objects.
e. If your software provides a solution to download code, make sure to digitally sign your code. I think even in Vista, you can do this to prevent the nasty Unauthorized message that makes people not trust your software.
f. Could this become more important of have higher rates of frequency for SaaS or Mobile computing?
16) CWE 404 – Improper resource release or shutdown http://cwe.mitre.org/top25/#CWE-404
a. Summary
i. Prevalence – Medium
ii. Remedy Cost – Medium
iii. Frequency – Rarely
b. Likelihood of exploit – Low to medium
c. Solution: use technologies that automatically garbage collect.
d. Solution: be sure to clean up unneeded cookie data. Is it possible to delete cookies?
e. Solution: be sure to clean up yourself by deleting unneeded records in databases, freeing unneeded resources, setting objects to null.
i. In Java, in DAO’s, make sure to use Spring JDBC to clean up for you or make sure to free DB connections from the pools. Otherwise, users can be denied access due to exhausted connections.
f. This is a common problem in general system performance but an attacker could get a resource leak to intentionally happen, then they could launch a DoS attack.
g. Apache Tomcat is vulnerable here – If you don’t configure your tomcat logging appropriately via logging.properties, then you could fill up catalina.out and degregade performance.
17) CWE 665 – Improper Initialization - http://cwe.mitre.org/top25/#CWE-665
a. Summary
i. Prevalence – Medium
ii. Remedy Cost – Low
iii. Frequency – Sometimes
b. Likelihood of exploit – medium
c. Problem: software the fails to properly initialize variables that lead to garbage or unintended values in variables when first using them.
d. Solution: use languages that must provide initializers like Java.
e. Solution: Use Eclipse IDE or similar when coding. The code assist tools contained within these modern IDEs alert programmers to conditions such as these. The compiler will not allow you to move forward until variables are properly initialized.
f. Solution: follow good programming practices about declaring and initializing variables just before first use. Don’t declare all variables at the top of the code block.
18) CWE 682 – Incorrect calculations
a. Summary
i. Prevalence – High
ii. Remedy Cost – Low
iii. Frequency – Often
b. Likelihood of exploit – high
c.
19)
20)
21) Action items:
a. Maybe talk about last 3 as a group
b. Mike to come up with examples for the last 3
c. Code snippets
d. Config files files examples
e. Cookie setting examples
f. Send me some branding stamps for OWASP. Powerpoint branding

Tuesday, February 3, 2009

Mysterious testing tools revolving around Sans Top 25 error list

I missed this blurb on the SANS website earlier but while I was re-reading it caught my eye.

According to http://www.sans.org/top25errors/#s2 , "one of the leading software testing vendors is announcing that its software will be able to test for and report on the presence of a large fraction of the Top 25 Errors."

Mike Fratto from Information Week says here: http://www.informationweek.com/blog/main/archives/2009/01/cwesans_top_25.html that even if such tools exist, a programmer will not run them due to the complexity of running such tools.

I for one applaud any extra testing tools, as I mentioned in my first post. All they need to do to make it easier is to develop an Eclipse plug in that a developer could right click on and say "Run". Or build it into CodePro.

Friday, January 30, 2009

Top 25 Programming list Thoughts and Notes.

Welcome everyone from East Carolina and OWASP - NC! I am putting together something for a joint meeting between OWASP and ISSA in Raleigh that revolves around the recent SANS Top 25 Programming errors that came out in early January 2009 : http://www.sans.org/top25errors/.

SANS worked with the MITRE organization whose Common Weakness Enumeration (CWE) details over 700 additional programming and architecture errors and recommendations on how to avoid and mitigate them.

The main goal of the Top 25 list is to "Stop vulnerabilities at the source by educating programmers on how to eliminate all-too-common mistakes before software is even shipped. The list will be a tool for education and awareness that will help programmers to prevent the kinds of vulnerabilities that plague the software industry. Software consumers could use the same list to help them to ask for more secure software. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software."

Here are some notes:

1. Programming errors in this list relate mostly to security

2. Could also be renamed to Top 25 Web Programming errors since many of the items on the list are not applicable to non web programmers. However at least all but 2 of the 25 relates to any software if not all of them.
  • Web applications are starting to dominate mainstream computing.

  • Web applications are accessible from anywhere in the world whereas desktop applications mostly require physical presence to interact.

3. How does this list compare, duplicate, enhance other similar type lists?


4. Old software proverb: “The first 90 % of the work takes 10% of the time and the other 10% takes 90% of the time”.

  • Security sadly is not at the forefront of development cycle and therefore is relegated to the last 10% of the time. Therefore, a lot of the times, security is not gotten around to implement.

  • Succeeding in software is more of getting EVERYTHING right and less of not doing a few things wrong. One bug especially those found by the customer can fail a project.

  • You can help your project success along the way by simply recognizing what errors you can make and that is where lists like these can help your project success rate.

5. Can these 25 items be reduced to 12?

  • Improper Input Validation ... path , user input, download without integrity check
  • Untrusted Source ... similar data validation, but checks on more "human" level, untrusted seach path
  • Failure to Fullfil Constrains ... buffer overflow

  • Improper Initialization or Relase of Resource .... unitialized data,

  • Failure to Preserve Proper Structure ... encoding or escaping of textual data, SQL, html, control generation of code

  • Client-Side Enforcement of Server Side Security

  • Revealing Potentially Misused Infromation .... os calls in text file, cleartext transmission of sensitive data - hard coded passwords, error message information leak

  • Giving Privilegies to Access Potentially Misused Information (& their executing)... data critical to keep valid state of program, external file names,

  • Race Condition

  • Incorrect Calculation

  • Insufficent Random Values

  • Use of Weak Cryptographic Algorightms

6. Or maybe the list can be boiled down into 3 categories?:

  • Insecure Interaction Between Components (9 errors)

  • Risky Resource Management (9 errors)

  • Porous Defenses (7 errors)

7. A good idea for a hands on project would be to build a website that demonstrates a use and example for each error in the list for reference.

8. What is a “Race condition”? – a race condition is merely a synch issue where properly timed inputs and program execution can lead to unexpected state of the program.

9. Can a tool like Codepro be modified to check against this list? It would be much better to have a best practice of “I ran my code against this tool and it came back clean” rather than nothing at all.

10.Amazing thing is that people are noticing and reacting to this list where these issues have been around and noted for awhile.

11.Will some kind of regulations or government action result in this list? Think Sarbanes Oxley.

12.A lot of the items on the list are programming “errors” per se. They could be considered exploitable loopholes. The fact is that software will work fine in a world without hackers

13.Website with 25 errors categorized: http://naveedslote.blogspot.com/2009/01/top-25-most-dangerous-programming_13.html

More to come later - Fred