What are Phishing kits?
Phishing kits are usually downloadable from dark sites and underground IRC forums in the form of an archive – tar, zip, etc. and contain all of the files necessary to build a phishing site. The kit users are not technically adept but the kit authors usually are and they drive much of the phishing sites used today.
Nearly 400 different phishing kits were discovered by computer scientists at UC Santa Barbara - http://www.scmagazineus.com/backdoor-scams-emerge-on-phishing-kits/article/113240/
Out of almost 400 kits, 129 had backdoors that phished the phishers.
RockPhish.
MrBrain – although use is diminishing due to MrBrain’s stealing of the stealer’s data which led to distrust in the underground community.
Google Kit - http://securitylabs.websense.com/content/Blogs/3512.aspx
Stolen cards are used for....
Used to purchase nonsensical domains and webhosting services. The hosting service providers that have longer take down times are usually preferred. Over the past few years, the main stream hosting services like Yahoo are declining in use due to the fast takedown times. Other hosting services like by.ru and 100webspace.net
Top webhosters by phishers:
http://toolbar.netcraft.com/stats/hosters
Phishiest countries:
http://toolbar.netcraft.com/stats/countries
Monday, January 4, 2010
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.
Labels:
East Carolina Univerity,
Hack,
Hacking,
linkedin
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.
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.
Labels:
East Carolina Univerity,
Hack,
Hacking,
Information Security,
InfoSec,
IT Security,
SSO
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
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.
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
- IP header identification field: The identification field is a 16 bit field provided by the sender that aids in packet reassembly.
- 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)
- 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.
- 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
- 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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)