A new security podcast is available announcing the new release of Back|Track 3 on PaulDotCom The podcast entitled PaulDotCom Security Weekly Episode 112 -June 19, 2006 is available here
This episode features members of the Back|Track development team.
To get the latest version of Back|Track follow the link here.
Thursday, June 19, 2008
Monday, May 26, 2008
Multipart PortScanning Tutorial Part 7
Multipart PortScanning Tutorial Part 7
In this edition we will be looking at the results of some Xmas Tree scans.
Disclaimer: This information is for educational purposes only and not to commit a crime!
If you do something that causes you to hose your box don't come kicking and screaming on the forums!
All IP Address' MAC Address' etc. have been munged!
[b]
OK so first things first If you are not up to speed here are the other tutorials I have done on nmap.[/B]
[url="http://forums.remote-exploit.org/showthread.php?t=11001"]Part1[/url]
[URL="http://forums.remote-exploit.org/showthread.php?t=11003"]Part2[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11010"]Part3[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11025"]Part4[/URL]
[url="http://forums.remote-exploit.org/showthread.php?t=11216"]Part5[/url]
[url="http://forums.remote-exploit.org/showthread.php?t=14195]Part6[/url]
OK so let's look at what a Xmas Tree scan is.
[quote]Xmas scan (-sX)
Sets the FIN, PSH, and URG flags, lighting the packet up like a Christmas tree.
[b]From the nmap online documentation. [/b] [/quote]
So what does this mean?
Well for starters we know about the three-way handshake with TCP/IP. So what we are doing is sending packets out that have the "FIN", "PSH" and "URG" flags set.
So let's look at these flags. The first one "FIN" tells the target that we are finished with our connection. And normally it would send back and "ACK" Packet.
The second is the "PSH" or push packet. TCP designates data being sent to an application by using the "PSH" flag. To ensure that data sent from a node has been received TCP uses an "ACK" flag that specifies which "PSH" packets have been received. "ACK"s are sent in response to "PSH" data grams in two different scenarios:
1. When data has been received by a node.
2. When the "ACK" delay has been reached.
The third flag is the "URG" flag. The "URG" flag is used to tell a node that information needing immediate attention is present within a packet.
A "URG" also tells a receiving node that the sender requests all buffered data to be passed to the application. Normally TCP holds data in a memory buffer until enough is collected then it is passed to the application needing said data. With the "URG" flag TCP sends the data immediately. Ok so now might be a good idea to take a break!
Now that we know what the packets mean let's take a look at why this can be important to the pen-tester.
First when we do a Xmas tree scan and the target sends us a "RST" or reset packet then we know that a target port is closed. But if the target port is open then there will be silence. This is the same thing when doing a "FIN" scan. All of this takes place due to RFC 793 Transmission Control Protocol.
During a Xmas tree scan nmap categorizes the response as either closed or open|filtered. The open|filtered result is combined because firewalls often drop these packets. Because it's impossible to determine if a missing response was due to an open port or a filtered network connection, there's no way to tell the difference between an open or filtered port. Different implementations of the TCP/IP stack will handle these scans in different ways. Windows for example will reply with a "RST" regardless of the status of the port. If an open|filtered port is picked up then the node is not windows based. Special attention must be given when the results show all ports as closed as this may not be true.
Ok so now if you are still with me let's take a look at some scans.
First in the default mode with a look at the flags.
[code]
#nmap -sX -v -v 192.168.1.5 [/code]
-sX xmas tree scan
-v verbosity
[b] And our results. [/b]
[code]
Starting Nmap 4.62 ( http://nmap.org ) at 2008-05-01 13:30 EDT
Initiating ARP Ping Scan at 13:30
Scanning 192.168.1.5 [1 port]
Completed ARP Ping Scan at 13:30, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:30
Completed Parallel DNS resolution of 1 host. at 13:30, 0.05s elapsed
Initiating XMAS Scan at 13:30
Scanning 192.168.1.5 [1715 ports]
Increasing send delay for 192.168.1.5 from 0 to 5 due to 21 out of 70 dropped probes since last increase.
Completed XMAS Scan at 13:30, 16.56s elapsed (1715 total ports)
Host 192.168.1.5 appears to be up ... good.
All 1715 scanned ports on 192.168.1.5 are closed
MAC Address: 00:12:34:56:AA:FF (Cisco-Linksys)
Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 17.024 seconds
Raw packets sent: 1821 (72.842KB) | Rcvd: 1718 (79.024KB)
[/code]
As you can see we really didn't learn much about our target. The only thing that we learned is that the ports all appear to be closed.
But this is not really the case. I know that there are open ports because the target is actually a print server.
[b]This time lets look more in depth at our target.[/b]
[code]
#nmap -sV -v -v -F -sX -O 192.168.1.5
[/code]
-sV service version
-O Operating system
-F Only scan ports listed on services.
[b] Now the relevant results[/b]
[code] Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: storage-misc|printer
Running: Hotway embedded, IBM embedded, Packard Bell embedded
OS details: Hotway HDC-U2LA NAS device, IBM 6400 Printer (software version 7.0.9.6), Packard Bell NetStore 3500
OS Fingerprint:
Purposely removed [/code]
This time we can see that nmap returned us a print server. The device type is still incorrect. This can mean the difference between accessing the network and being shut out.
This print server like most usually have TCP ports 515, 631 open. There is usually one or two more like http or telnet open as well.
So we see that even though the two scans are not 100% accurate we did gain some valuable information about our target. Again a lot of devices will not respond to this type of scanning but there are some that will. Using the Xmas tree scan we can also help mask our intentions from a IDS. But remember most system administrators worth their weight in salt will ensure that there IDS's pick up this type of scan. There are ways around this as well.
Try playing with this type of scan and see what kind of results you get.
Drop a line if this has helped or hindered you.
In this edition we will be looking at the results of some Xmas Tree scans.
Disclaimer: This information is for educational purposes only and not to commit a crime!
If you do something that causes you to hose your box don't come kicking and screaming on the forums!
All IP Address' MAC Address' etc. have been munged!
[b]
OK so first things first If you are not up to speed here are the other tutorials I have done on nmap.[/B]
[url="http://forums.remote-exploit.org/showthread.php?t=11001"]Part1[/url]
[URL="http://forums.remote-exploit.org/showthread.php?t=11003"]Part2[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11010"]Part3[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11025"]Part4[/URL]
[url="http://forums.remote-exploit.org/showthread.php?t=11216"]Part5[/url]
[url="http://forums.remote-exploit.org/showthread.php?t=14195]Part6[/url]
OK so let's look at what a Xmas Tree scan is.
[quote]Xmas scan (-sX)
Sets the FIN, PSH, and URG flags, lighting the packet up like a Christmas tree.
[b]From the nmap online documentation. [/b] [/quote]
So what does this mean?
Well for starters we know about the three-way handshake with TCP/IP. So what we are doing is sending packets out that have the "FIN", "PSH" and "URG" flags set.
So let's look at these flags. The first one "FIN" tells the target that we are finished with our connection. And normally it would send back and "ACK" Packet.
The second is the "PSH" or push packet. TCP designates data being sent to an application by using the "PSH" flag. To ensure that data sent from a node has been received TCP uses an "ACK" flag that specifies which "PSH" packets have been received. "ACK"s are sent in response to "PSH" data grams in two different scenarios:
1. When data has been received by a node.
2. When the "ACK" delay has been reached.
The third flag is the "URG" flag. The "URG" flag is used to tell a node that information needing immediate attention is present within a packet.
A "URG" also tells a receiving node that the sender requests all buffered data to be passed to the application. Normally TCP holds data in a memory buffer until enough is collected then it is passed to the application needing said data. With the "URG" flag TCP sends the data immediately. Ok so now might be a good idea to take a break!
Now that we know what the packets mean let's take a look at why this can be important to the pen-tester.
First when we do a Xmas tree scan and the target sends us a "RST" or reset packet then we know that a target port is closed. But if the target port is open then there will be silence. This is the same thing when doing a "FIN" scan. All of this takes place due to RFC 793 Transmission Control Protocol.
During a Xmas tree scan nmap categorizes the response as either closed or open|filtered. The open|filtered result is combined because firewalls often drop these packets. Because it's impossible to determine if a missing response was due to an open port or a filtered network connection, there's no way to tell the difference between an open or filtered port. Different implementations of the TCP/IP stack will handle these scans in different ways. Windows for example will reply with a "RST" regardless of the status of the port. If an open|filtered port is picked up then the node is not windows based. Special attention must be given when the results show all ports as closed as this may not be true.
Ok so now if you are still with me let's take a look at some scans.
First in the default mode with a look at the flags.
[code]
#nmap -sX -v -v 192.168.1.5 [/code]
-sX xmas tree scan
-v verbosity
[b] And our results. [/b]
[code]
Starting Nmap 4.62 ( http://nmap.org ) at 2008-05-01 13:30 EDT
Initiating ARP Ping Scan at 13:30
Scanning 192.168.1.5 [1 port]
Completed ARP Ping Scan at 13:30, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:30
Completed Parallel DNS resolution of 1 host. at 13:30, 0.05s elapsed
Initiating XMAS Scan at 13:30
Scanning 192.168.1.5 [1715 ports]
Increasing send delay for 192.168.1.5 from 0 to 5 due to 21 out of 70 dropped probes since last increase.
Completed XMAS Scan at 13:30, 16.56s elapsed (1715 total ports)
Host 192.168.1.5 appears to be up ... good.
All 1715 scanned ports on 192.168.1.5 are closed
MAC Address: 00:12:34:56:AA:FF (Cisco-Linksys)
Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 17.024 seconds
Raw packets sent: 1821 (72.842KB) | Rcvd: 1718 (79.024KB)
[/code]
As you can see we really didn't learn much about our target. The only thing that we learned is that the ports all appear to be closed.
But this is not really the case. I know that there are open ports because the target is actually a print server.
[b]This time lets look more in depth at our target.[/b]
[code]
#nmap -sV -v -v -F -sX -O 192.168.1.5
[/code]
-sV service version
-O Operating system
-F Only scan ports listed on services.
[b] Now the relevant results[/b]
[code] Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: storage-misc|printer
Running: Hotway embedded, IBM embedded, Packard Bell embedded
OS details: Hotway HDC-U2LA NAS device, IBM 6400 Printer (software version 7.0.9.6), Packard Bell NetStore 3500
OS Fingerprint:
Purposely removed [/code]
This time we can see that nmap returned us a print server. The device type is still incorrect. This can mean the difference between accessing the network and being shut out.
This print server like most usually have TCP ports 515, 631 open. There is usually one or two more like http or telnet open as well.
So we see that even though the two scans are not 100% accurate we did gain some valuable information about our target. Again a lot of devices will not respond to this type of scanning but there are some that will. Using the Xmas tree scan we can also help mask our intentions from a IDS. But remember most system administrators worth their weight in salt will ensure that there IDS's pick up this type of scan. There are ways around this as well.
Try playing with this type of scan and see what kind of results you get.
Drop a line if this has helped or hindered you.
Sunday, May 25, 2008
Multipart PortScanning Tutorial Part 6
Because there has been some interest I will try to do a couple more tutorials on [URL="http://nmap.org/"]nmap[/URL]. I am using the latest version available.
[B]In this edition we will be looking at the results of some "ACK" Scans[/B].
Disclaimer: This information is for educational purposes only and not to commit a crime! If you do something that causes you to hose your box don't cry to me. All IP Address' MAC Address' etc. have been munged!
[B]
OK so first things first If you are not up to speed here are the other tutorials I have done on nmap.[/B]
[url="http://forums.remote-exploit.org/showthread.php?t=11001"]Part1[/url]
[URL="http://forums.remote-exploit.org/showthread.php?t=11003"]Part2[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11010"]Part3[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11025"]Part4[/URL]
[url="http://forums.remote-exploit.org/showthread.php?t=11216"]Part5[/url]
[B]Next lets talk a minute about what a "ACK" scan is.[/B]
[quote]-sA (TCP ACK scan)
This scan is different than the others discussed so far in that it never determines open (or even open|filtered) ports. It is used to map out firewall rulesets, determining whether they are stateful or not and which ports are filtered.
The ACK scan probe packet has only the ACK flag set (unless you use --scanflags). When scanning unfiltered systems, open and closed ports will both return a RST packet. Nmap then labels them as unfiltered, meaning that they are reachable by the ACK packet, but whether they are open or closed is undetermined. Ports that don't respond, or send certain ICMP error messages back (type 3, code 1, 2, 3, 9, 10, or 13), are labeled filtered.
[URL="http://nmap.org/docs.html"]From the nmap online documentation[/URL]. [/quote]
So what does this mean to us. First when dealing with TCP/IP we all know how the connections work, so when a connection is finished one would normally see an ACK or Acknowledgment. Meaning that the connection was made and a transfer of some sort took place. So when we scan for hosts by sending out ACK packets what we are doing is telling the target machine that we have "received the transmission". But since this is our first real communication with said target. It will not no how to respond. This is turn will generate RST or reset packets. Now if we look above we see that nmap will label them as unfiltered, and in turn they are reachable. This second part is really the only part we care about. By sending out ACK packets we can then determine if a host is alive and possibly not set of IDS alarms. Now there is a caveat to this. If there are a lot of ACK packets hitting a target then an IDS will most likely see this and of course set off the alarm.
There are several ways we can mitigate this with nmap. Which I will show more of in a later tutorial.
[b]So our first default scan should look something like this.[/b]
[code]#nmap -v -v -sA 192.168.1.5 [/code]
Now I included the -v -v for verbosity level two just to get all of the information out of this basic scan that we can.
[b]Now lets look at the results. [/b]
[code]
Starting Nmap 4.62 ( http://nmap.org ) at 2008-05-00 12:26 EDT
Initiating ARP Ping Scan at 12:26
Scanning 192.168.1.5 [1 port]
Completed ARP Ping Scan at 12:26, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:26
Completed Parallel DNS resolution of 1 host. at 12:26, 0.05s elapsed
Initiating ACK Scan at 12:26
Scanning 192.168.1.5 [1715 ports]
Increasing send delay for 192.168.1.5 from 0 to 5 due to 40 out of 133 dropped probes since last increase.
Completed ACK Scan at 12:26, 15.39s elapsed (1715 total ports)
Host 192.168.1.5 appears to be up ... good.
All 1715 scanned ports on 192.168.1.5 are unfiltered
MAC Address: 00:12:34:45:AA:FF (Cisco-Linksys)
Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 15.828 seconds
Raw packets sent: 1836 (73.442KB) | Rcvd: 1716 (78.932KB)[/code]
Now the only thing that we learned is that the target is there, which we should already have known before we started scanning it. Blindly scanning a target is how we set off alarms!
Ok now lets look at it again only this time we will be trying to find out some info on the OS and what services are running.
But remember we do not want to trip the alarm so we are going to be a little sneaky with our throttling. Note this may or may not hide us, That is not the real point here.
[code]
#nmap -sV -v -v -F -T Paranoid -sA -O -PN 192.168.1.5
[/code]
This time we have several flags set.
-sV for service versions.
-v -v again verbosity level 2
-F to only scan the ports listed on the service version scan. No sense scanning all possible ports as this could trigger alarms.
-T Paranoid again to help mask what we are doing.
-sA is for the ACK scan itself.
-O for OS detection
-PN so that we do not ping the target before scanning. Again to mask what we are doing from the target itself.
[b]And of course the output[/b]
[code]
Starting Nmap 4.62 ( http://nmap.org ) at 2008-05-00 13:04 EDT
Initiating ARP Ping Scan at 13:04
Scanning 192.168.1.5 [1 port]
Completed ARP Ping Scan at 13:04, 0.01s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:04
Completed Parallel DNS resolution of 1 host. at 13:04, 0.05s elapsed
Initiating ACK Scan at 13:04
Scanning 192.168.1.5 [1276 ports]
Increasing send delay for 192.168.1.5 from 0 to 5 due to 45 out of 150 dropped probes since last increase.
Completed ACK Scan at 13:04, 11.45s elapsed (1276 total ports)
Initiating Service scan at 13:04
Initiating OS detection (try #1) against 192.168.1.5
SCRIPT ENGINE: Initiating script scanning.
Host 192.168.1.5 appears to be up ... good.
All 1276 scanned ports on 192.168.1.5 are unfiltered
MAC Address: 00:12:34:45:AA:FF(Cisco-Linksys)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: storage-misc|printer
Running: Hotway embedded, IBM embedded, Packard Bell embedded
OS details: Hotway HDC-U2LA NAS device, IBM 6400 Printer (software version 7.0.9.6), Packard Bell NetStore 3500
OS Fingerprint:
Purposely Removed
Network Distance: 1 hop
Read data files from: /usr/local/share/nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.866 seconds
Raw packets sent: 1343 (55.504KB) | Rcvd: 1283 (59.160KB) [/code]
So this time we picked up a bit more detail. I will say that what was reported by the scan's OS details is incorrect but they device type is. Also note that the mac address is listed as Cisco-Linksys. This along with the device type is the most relevant info we have gained. In order for us to actually penetrate the target we need more information. Which I will leave up to you to learn about.
So again we have covered using an ACK scan with nmap. There are more options, reasons, and ways of using this type of scan. I have showed you only the basics.
When I get the chance I will be showing more options for IDS spoofing and evasion techniques. I have purposely left this info out of this tutorial!
If this has helped or hindered you say something. :)
[B]In this edition we will be looking at the results of some "ACK" Scans[/B].
Disclaimer: This information is for educational purposes only and not to commit a crime! If you do something that causes you to hose your box don't cry to me. All IP Address' MAC Address' etc. have been munged!
[B]
OK so first things first If you are not up to speed here are the other tutorials I have done on nmap.[/B]
[url="http://forums.remote-exploit.org/showthread.php?t=11001"]Part1[/url]
[URL="http://forums.remote-exploit.org/showthread.php?t=11003"]Part2[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11010"]Part3[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11025"]Part4[/URL]
[url="http://forums.remote-exploit.org/showthread.php?t=11216"]Part5[/url]
[B]Next lets talk a minute about what a "ACK" scan is.[/B]
[quote]-sA (TCP ACK scan)
This scan is different than the others discussed so far in that it never determines open (or even open|filtered) ports. It is used to map out firewall rulesets, determining whether they are stateful or not and which ports are filtered.
The ACK scan probe packet has only the ACK flag set (unless you use --scanflags). When scanning unfiltered systems, open and closed ports will both return a RST packet. Nmap then labels them as unfiltered, meaning that they are reachable by the ACK packet, but whether they are open or closed is undetermined. Ports that don't respond, or send certain ICMP error messages back (type 3, code 1, 2, 3, 9, 10, or 13), are labeled filtered.
[URL="http://nmap.org/docs.html"]From the nmap online documentation[/URL]. [/quote]
So what does this mean to us. First when dealing with TCP/IP we all know how the connections work, so when a connection is finished one would normally see an ACK or Acknowledgment. Meaning that the connection was made and a transfer of some sort took place. So when we scan for hosts by sending out ACK packets what we are doing is telling the target machine that we have "received the transmission". But since this is our first real communication with said target. It will not no how to respond. This is turn will generate RST or reset packets. Now if we look above we see that nmap will label them as unfiltered, and in turn they are reachable. This second part is really the only part we care about. By sending out ACK packets we can then determine if a host is alive and possibly not set of IDS alarms. Now there is a caveat to this. If there are a lot of ACK packets hitting a target then an IDS will most likely see this and of course set off the alarm.
There are several ways we can mitigate this with nmap. Which I will show more of in a later tutorial.
[b]So our first default scan should look something like this.[/b]
[code]#nmap -v -v -sA 192.168.1.5 [/code]
Now I included the -v -v for verbosity level two just to get all of the information out of this basic scan that we can.
[b]Now lets look at the results. [/b]
[code]
Starting Nmap 4.62 ( http://nmap.org ) at 2008-05-00 12:26 EDT
Initiating ARP Ping Scan at 12:26
Scanning 192.168.1.5 [1 port]
Completed ARP Ping Scan at 12:26, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:26
Completed Parallel DNS resolution of 1 host. at 12:26, 0.05s elapsed
Initiating ACK Scan at 12:26
Scanning 192.168.1.5 [1715 ports]
Increasing send delay for 192.168.1.5 from 0 to 5 due to 40 out of 133 dropped probes since last increase.
Completed ACK Scan at 12:26, 15.39s elapsed (1715 total ports)
Host 192.168.1.5 appears to be up ... good.
All 1715 scanned ports on 192.168.1.5 are unfiltered
MAC Address: 00:12:34:45:AA:FF (Cisco-Linksys)
Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 15.828 seconds
Raw packets sent: 1836 (73.442KB) | Rcvd: 1716 (78.932KB)[/code]
Now the only thing that we learned is that the target is there, which we should already have known before we started scanning it. Blindly scanning a target is how we set off alarms!
Ok now lets look at it again only this time we will be trying to find out some info on the OS and what services are running.
But remember we do not want to trip the alarm so we are going to be a little sneaky with our throttling. Note this may or may not hide us, That is not the real point here.
[code]
#nmap -sV -v -v -F -T Paranoid -sA -O -PN 192.168.1.5
[/code]
This time we have several flags set.
-sV for service versions.
-v -v again verbosity level 2
-F to only scan the ports listed on the service version scan. No sense scanning all possible ports as this could trigger alarms.
-T Paranoid again to help mask what we are doing.
-sA is for the ACK scan itself.
-O for OS detection
-PN so that we do not ping the target before scanning. Again to mask what we are doing from the target itself.
[b]And of course the output[/b]
[code]
Starting Nmap 4.62 ( http://nmap.org ) at 2008-05-00 13:04 EDT
Initiating ARP Ping Scan at 13:04
Scanning 192.168.1.5 [1 port]
Completed ARP Ping Scan at 13:04, 0.01s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:04
Completed Parallel DNS resolution of 1 host. at 13:04, 0.05s elapsed
Initiating ACK Scan at 13:04
Scanning 192.168.1.5 [1276 ports]
Increasing send delay for 192.168.1.5 from 0 to 5 due to 45 out of 150 dropped probes since last increase.
Completed ACK Scan at 13:04, 11.45s elapsed (1276 total ports)
Initiating Service scan at 13:04
Initiating OS detection (try #1) against 192.168.1.5
SCRIPT ENGINE: Initiating script scanning.
Host 192.168.1.5 appears to be up ... good.
All 1276 scanned ports on 192.168.1.5 are unfiltered
MAC Address: 00:12:34:45:AA:FF(Cisco-Linksys)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: storage-misc|printer
Running: Hotway embedded, IBM embedded, Packard Bell embedded
OS details: Hotway HDC-U2LA NAS device, IBM 6400 Printer (software version 7.0.9.6), Packard Bell NetStore 3500
OS Fingerprint:
Purposely Removed
Network Distance: 1 hop
Read data files from: /usr/local/share/nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.866 seconds
Raw packets sent: 1343 (55.504KB) | Rcvd: 1283 (59.160KB) [/code]
So this time we picked up a bit more detail. I will say that what was reported by the scan's OS details is incorrect but they device type is. Also note that the mac address is listed as Cisco-Linksys. This along with the device type is the most relevant info we have gained. In order for us to actually penetrate the target we need more information. Which I will leave up to you to learn about.
So again we have covered using an ACK scan with nmap. There are more options, reasons, and ways of using this type of scan. I have showed you only the basics.
When I get the chance I will be showing more options for IDS spoofing and evasion techniques. I have purposely left this info out of this tutorial!
If this has helped or hindered you say something. :)
Sunday, April 6, 2008
How to Setup a Trixbox image using Vmware player
How to Setup a Trixbox image using Vmware player.
This guide will show you how to setup a target PBX machine in your own pentesting lab.
This will allow you to use several tools that are available in BT in order to learn about VOIP.
So this guide will assume a few things.
1. You have at least two computers on some sort of network
2. One of them is capable of running BT
3. The other is running windows xp.
Now if you need help with any of that then see
google
Now in order to get our machine setup we need to download a few things.
1. the player
2. the trixbox image
You need to download the Vmware image titled: trixbox CE 2.6.0.7
There are md5sums for it as well.
Ok now setup the vmware player as per the documentation
Next you will need to unzip the trixbox image.
Once this is done you will need to start the player. Once it opens chose from the commands "open" and navigate to the folder where your recently unzipped folder.
Then find the file that is labeled "trixbox-ce-2.6.0.2" This is the needed image.
Now select open and the OS should start too boot inside of the player. It takes a few minutes to get to the log on prompt.
If there are any errors that prevent you from getting a root log in prompt then you will need to work those out first.
You can post in this thread but I can only offer limited help for this. Best go to the trixbox website.
Now that our OS is booted we can leave it alone.
If you have the desire you can log onto it using
logon:root
password: trixbox
But there is really nothing to see there.
You will do all configuration from the web gui interface.
You should also see on the player the IP address to access this web interface.
If not find the IP of your machine and this will be it.
Ok so on another machine open a browser and navigate to the IP address.
Then once you have the page the next few steps are real easy.
Upper right hand corner find the user mode and switch to maint.
you will need to supply the user and password
User: maint
Password: password
Now it will reload the page. Next find on the left side toward the top "Asterix" and then in the drop down "FreePBX"
Click on it and it reloads. This is the page where we can add our extensions. This is basically the user and there associated phone number.
Just like when you call some business or whatever and the prompt asks for an extension.
Choose in the middle the drop down box that should say "SIP" device.
Then you will need to fill out the following.
The extension number
You should give a name but it is not necessary.
Then down the list you will see "secret" this is the password field put something in there or leave it blank.
Next go to the very bottom and hit the submit button and back up to the top of the page is an orange button for adding the new extension to the database and turning it on.
At this point you are done. If you want to mess with the other features by all means go for it. For our testing purposes we are finished with the web interface.
You can the just navigate to another website or close the browser.
Now in order for us to make use of the SipVicious tools you will need to navigate to the SipVicious directory and add a word list.
The default is "dictionary.txt" At this point you can either add some words or whatever but you need to ensure that your secrets from above are in there.
Save the file and exit.
So to see the video that shows how to set up our trixbox please follow this link it will take you to blip.tv
For more info on using the SipVicious tools see my other tutorial here.
Hope you enjoy it and please leave some feed back!
This guide will show you how to setup a target PBX machine in your own pentesting lab.
This will allow you to use several tools that are available in BT in order to learn about VOIP.
So this guide will assume a few things.
1. You have at least two computers on some sort of network
2. One of them is capable of running BT
3. The other is running windows xp.
Now if you need help with any of that then see
Now in order to get our machine setup we need to download a few things.
1. the player
2. the trixbox image
You need to download the Vmware image titled: trixbox CE 2.6.0.7
There are md5sums for it as well.
Ok now setup the vmware player as per the documentation
Next you will need to unzip the trixbox image.
Once this is done you will need to start the player. Once it opens chose from the commands "open" and navigate to the folder where your recently unzipped folder.
Then find the file that is labeled "trixbox-ce-2.6.0.2" This is the needed image.
Now select open and the OS should start too boot inside of the player. It takes a few minutes to get to the log on prompt.
If there are any errors that prevent you from getting a root log in prompt then you will need to work those out first.
You can post in this thread but I can only offer limited help for this. Best go to the trixbox website.
Now that our OS is booted we can leave it alone.
If you have the desire you can log onto it using
logon:root
password: trixbox
But there is really nothing to see there.
You will do all configuration from the web gui interface.
You should also see on the player the IP address to access this web interface.
If not find the IP of your machine and this will be it.
Ok so on another machine open a browser and navigate to the IP address.
Then once you have the page the next few steps are real easy.
Upper right hand corner find the user mode and switch to maint.
you will need to supply the user and password
User: maint
Password: password
Now it will reload the page. Next find on the left side toward the top "Asterix" and then in the drop down "FreePBX"
Click on it and it reloads. This is the page where we can add our extensions. This is basically the user and there associated phone number.
Just like when you call some business or whatever and the prompt asks for an extension.
Choose in the middle the drop down box that should say "SIP" device.
Then you will need to fill out the following.
The extension number
You should give a name but it is not necessary.
Then down the list you will see "secret" this is the password field put something in there or leave it blank.
Next go to the very bottom and hit the submit button and back up to the top of the page is an orange button for adding the new extension to the database and turning it on.
At this point you are done. If you want to mess with the other features by all means go for it. For our testing purposes we are finished with the web interface.
You can the just navigate to another website or close the browser.
Now in order for us to make use of the SipVicious tools you will need to navigate to the SipVicious directory and add a word list.
The default is "dictionary.txt" At this point you can either add some words or whatever but you need to ensure that your secrets from above are in there.
Save the file and exit.
So to see the video that shows how to set up our trixbox please follow this link it will take you to blip.tv
For more info on using the SipVicious tools see my other tutorial here.
Hope you enjoy it and please leave some feed back!
There is also a thread over at remote-exploits forums for using the SipVicious tool set.
Join the conversation.
I should have the other video and thread (on setting up a target machine in your own private network) up later today.
Join the conversation.
I should have the other video and thread (on setting up a target machine in your own private network) up later today.
Friday, April 4, 2008
Abusing VOIP Networks with SipVicious
Tuesday, April 1, 2008
SipVicious Hacking
I did a small video on using the SipVicious tools under Back|Track
I will post more info later at the remote exploits forums.
I will also post a small video on setting up our target machine.
There are two formats for the video a .html and a .swf
The files have been pulled temporarily will repost them later on tonight.
I will post more info later at the remote exploits forums.
I will also post a small video on setting up our target machine.
There are two formats for the video a .html and a .swf
The files have been pulled temporarily will repost them later on tonight.
Subscribe to:
Posts (Atom)