This article series will be based upon a network system breach. What we shall cover is the actual hack itself, from the reconnaissance stage, through to enumeration, network service exploitation, and ending with post-exploitation strategies. All of these steps will then be viewed at the packet level, and then explained. Being able to view, and understand an attack at the packet level is critically important for both system administrators (sys admin) and network security personnel. The output of firewalls, Intrusion Detection Systems (IDS) and other security devices will always in turn lead you to look at the actual network traffic. If you don’t understand what you are looking at, at the packet level, then all of the network security technology you have is utterly useless. This will then be followed by how to write a Snort signature based off of the attack traffic.
Tools used for this simulated network attack:
* Nmap
* IPEye
* Tcpdump
* Metasploit Framework
* Netcat
* SolarWinds TFTP Server
* Tftp client
* FU Rootkit
Setting the stage
There is no shortage of hostile scanning on the Internet today, not to mention worm activity, and other forms of malware, such as viruses. All of this amounts to a lot of white noise for the well protected computer network. What we shall look at is a person deliberately targeting a computer network. For the purposes of this article we shall assume that the hacker has already decided upon his victim and done earlier research such as finding out the IP address or addresses of the victim network. He may have also tried to find out other such nuggets of information, such as email addresses associated with that network. This type of information is critical in case the hacker were to find there was no way into the network after having scanned, profiled, and enumerated it. The email addresses that he may have harvested would be useful in setting up a client side attack by which he would try and lure a user to a malicious website via a link in an email. More on that type of attack in a later article series.
On with the show
We shall now view the actions of the potential hacker as he goes about the business of scanning, profiling, and enumerating the victim network. The first tool that the hacker uses is Nmap. Though Nmap has quite a few IDS signatures for it, it is still quite a useful tool, and is heavily used.
Figure 1
We can see via the syntax used by the hacker in the screenshot that he deliberately picks port 21 and 80, as he has several exploits he can use via the the Metasploit Framework. Not only that but those are two system services and protocols that he understands fairly well. Shown as well is that he is using a SYN scan which is also the most common port scan type. This is due to the fact if a service which uses TCP is listening on a port which is scanned with a SYN packet, then it will send back a SYN/ACK packet. That SYN/ACK packet indicates that a service is indeed listening there, and awaiting connections. The same cannot be said for UDP based services such as DNS (DNS also uses TCP though it mostly uses UDP for the bulk of its transactions).
Listed below the syntax is the output that Nmap gleans from the packets it sent, but to be more accurate, from the packets it receives as a result of the SYN scan it just did. We can see that there are seemingly both FTP and HTTP services offered. We are not really interested in the MAC address so we will ignore that. Though tools such as Nmap are not often wrong it is always good to verify your information at the packet level to ensure its accuracy. Not only that, but it is also in looking at the return packets, from the victim network, that we shall gather the host, service, and architectural information from.
Let us consult the packets
There are several programs out there today which will take packets off the wire and pull out information such as the operating system type, architectural info ie: x86 or SPARC and so on, for you. That really isn’t all that much fun, nor more importantly are we learning anything by letting a program do the work for us. On that note let’s take a look at the Nmap packet trace, and pull out some information about the victim network.
10:52:59.062500 IP (tos 0x0, ttl 43, id 8853, offset 0, flags [none], proto: ICMP (1), length: 28) 192.168.111.17 > 192.168.111.23: ICMP echo request seq 38214, length 8
0x0000: 4500 001c 2295 0000 2b01 0dd3 c0a8 6f11 E..."...+.....o.
0x0010: c0a8 6f17 0800 315a 315f 9546 ..o...1Z1_.F
10:52:59.078125 IP (tos 0x0, ttl 128, id 396, offset 0, flags [none], proto: ICMP (1), length: 28) 192.168.111.23 > 192.168.111.17: ICMP echo reply seq 38214, length 8
0x0000: 4500 001c 018c 0000 8001 d9db c0a8 6f17 E.............o.
0x0010: c0a8 6f11 0000 395a 315f 9546 0000 0000 ..o...9Z1_.F....
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
Shown in the two packets above is the opening salvo from Nmap. What it does is send an ICMP echo request to the victim network. You will note that it is not aimed at a specific port, seeing as ICMP does not use ports, but rather is handled by the ICMP error message handler which is built into the TCP/IP protocol stack. This ICMP packet is also stamped with a unique number, 38214 in this case, in order to help the TCP/IP stack keep track of the returning traffic, and associate it with an earlier ICMP packet it sent. The packet directly above us is the response from the victim network, in the form of an ICMP echo reply. Also note it bears the sequence number of 38214. So the hacker knows that there is indeed a computer, or computer network behind that IP address.
This opening ICMP packet sequence is why Nmap has an IDS signature for it. This ICMP host discovery option can be disabled in Nmap if so desired. What kind of information can be gleaned via the resulting ICMP echo reply packet from the victim network? In reality not a ton of information is there to help us profile the network. Though we can take a preliminary stab at what the operating system family is. The time to live field and value next to it is highlighted in the packet above. A value of 128 points to the likelihood that this computer is probably a Microsoft Windows one. While this ttl value is not a definitive answer as to what the operating system is, it will hopefully be corroborated by the ensuing packets that we will look at.
Wrap up
So far in this part we have seen a malicious hacker scan a network for two specific ports using Nmap. He so far has ascertained that a computer or computer network resides at that IP address. In part two we shall go on to finish the study of our packet trace, and pull out the remaining pieces of profiling information. See you then.
Tools used for this simulated network attack:
* Nmap
* IPEye
* Tcpdump
* Metasploit Framework
* Netcat
* SolarWinds TFTP Server
* Tftp client
* FU Rootkit
Setting the stage
There is no shortage of hostile scanning on the Internet today, not to mention worm activity, and other forms of malware, such as viruses. All of this amounts to a lot of white noise for the well protected computer network. What we shall look at is a person deliberately targeting a computer network. For the purposes of this article we shall assume that the hacker has already decided upon his victim and done earlier research such as finding out the IP address or addresses of the victim network. He may have also tried to find out other such nuggets of information, such as email addresses associated with that network. This type of information is critical in case the hacker were to find there was no way into the network after having scanned, profiled, and enumerated it. The email addresses that he may have harvested would be useful in setting up a client side attack by which he would try and lure a user to a malicious website via a link in an email. More on that type of attack in a later article series.
On with the show
We shall now view the actions of the potential hacker as he goes about the business of scanning, profiling, and enumerating the victim network. The first tool that the hacker uses is Nmap. Though Nmap has quite a few IDS signatures for it, it is still quite a useful tool, and is heavily used.
Figure 1
We can see via the syntax used by the hacker in the screenshot that he deliberately picks port 21 and 80, as he has several exploits he can use via the the Metasploit Framework. Not only that but those are two system services and protocols that he understands fairly well. Shown as well is that he is using a SYN scan which is also the most common port scan type. This is due to the fact if a service which uses TCP is listening on a port which is scanned with a SYN packet, then it will send back a SYN/ACK packet. That SYN/ACK packet indicates that a service is indeed listening there, and awaiting connections. The same cannot be said for UDP based services such as DNS (DNS also uses TCP though it mostly uses UDP for the bulk of its transactions).
Listed below the syntax is the output that Nmap gleans from the packets it sent, but to be more accurate, from the packets it receives as a result of the SYN scan it just did. We can see that there are seemingly both FTP and HTTP services offered. We are not really interested in the MAC address so we will ignore that. Though tools such as Nmap are not often wrong it is always good to verify your information at the packet level to ensure its accuracy. Not only that, but it is also in looking at the return packets, from the victim network, that we shall gather the host, service, and architectural information from.
Let us consult the packets
There are several programs out there today which will take packets off the wire and pull out information such as the operating system type, architectural info ie: x86 or SPARC and so on, for you. That really isn’t all that much fun, nor more importantly are we learning anything by letting a program do the work for us. On that note let’s take a look at the Nmap packet trace, and pull out some information about the victim network.
10:52:59.062500 IP (tos 0x0, ttl 43, id 8853, offset 0, flags [none], proto: ICMP (1), length: 28) 192.168.111.17 > 192.168.111.23: ICMP echo request seq 38214, length 8
0x0000: 4500 001c 2295 0000 2b01 0dd3 c0a8 6f11 E..."...+.....o.
0x0010: c0a8 6f17 0800 315a 315f 9546 ..o...1Z1_.F
10:52:59.078125 IP (tos 0x0, ttl 128, id 396, offset 0, flags [none], proto: ICMP (1), length: 28) 192.168.111.23 > 192.168.111.17: ICMP echo reply seq 38214, length 8
0x0000: 4500 001c 018c 0000 8001 d9db c0a8 6f17 E.............o.
0x0010: c0a8 6f11 0000 395a 315f 9546 0000 0000 ..o...9Z1_.F....
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
Shown in the two packets above is the opening salvo from Nmap. What it does is send an ICMP echo request to the victim network. You will note that it is not aimed at a specific port, seeing as ICMP does not use ports, but rather is handled by the ICMP error message handler which is built into the TCP/IP protocol stack. This ICMP packet is also stamped with a unique number, 38214 in this case, in order to help the TCP/IP stack keep track of the returning traffic, and associate it with an earlier ICMP packet it sent. The packet directly above us is the response from the victim network, in the form of an ICMP echo reply. Also note it bears the sequence number of 38214. So the hacker knows that there is indeed a computer, or computer network behind that IP address.
This opening ICMP packet sequence is why Nmap has an IDS signature for it. This ICMP host discovery option can be disabled in Nmap if so desired. What kind of information can be gleaned via the resulting ICMP echo reply packet from the victim network? In reality not a ton of information is there to help us profile the network. Though we can take a preliminary stab at what the operating system family is. The time to live field and value next to it is highlighted in the packet above. A value of 128 points to the likelihood that this computer is probably a Microsoft Windows one. While this ttl value is not a definitive answer as to what the operating system is, it will hopefully be corroborated by the ensuing packets that we will look at.
Wrap up
So far in this part we have seen a malicious hacker scan a network for two specific ports using Nmap. He so far has ascertained that a computer or computer network resides at that IP address. In part two we shall go on to finish the study of our packet trace, and pull out the remaining pieces of profiling information. See you then.
Now we left off in part one having looked at the opening packet sequence sent by Nmap. The sequence sent began with an ICMP echo reply to ascertain whether or not a computer or network was assigned to the IP address. Furthermore, we were able to take a guess that the victim computer network was likely a Microsoft Windows based one, based on the ttl in the ICMP echo reply packet it sent back to the attacker. What we shall now do is carry on looking at the remaining packets in the Nmap scan, and pull out the remaining information which will allow us to profile the victim network.
Moving on
10:52:59.078125 IP (tos 0x0, ttl 49, id 9808, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.111.17.37668 > 192.168.111.23.80: ., cksum 0xfd46 (correct), ack 85042526 win 2048
0x0000: 4500 0028 2650 0000 3106 0407 c0a8 6f11 E..(&P..1.....o.
0x0010: c0a8 6f17 9324 0050 67d1 a55e 0511 a55e ..o..$.Pg..^...^
0x0020: 5010 0800 fd46 0000 P....F..
10:52:59.078125 IP (tos 0x0, ttl 128, id 397, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.111.23.80 > 192.168.111.17.37668: R, cksum 0x6813 (correct), 85042526:85042526(0)win 0
0x0000: 4500 0028 018d 0000 8006 d9c9 c0a8 6f17 E..(..........o.
0x0010: c0a8 6f11 0050 9324 0511 a55e 0511 a55e ..o..P.$...^...^
0x0020: 5004 0000 6813 0000 0000 0000 0000 P...h.........
The above two packets came right after the ICMP based ones we looked at in part one. Nmap sent an ACK packet to the victim network IP of 192.168.111.23 on port 80. In terms of profiling information we do not have a whole lot here. We saw that the ACK packet received from the hacker elicited an RST packet back, as this ACK was unexpected. In essence it did not belong to a previously established connection. We still have a ttl of 128, which corresponds to the ttl we saw earlier.
10:52:59.296875 IP (tos 0x0, ttl 58, id 45125, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.111.17.37644 > 192.168.111.23.21: S, cksum 0x37ce (correct), 2010644897:2010644897(0) win 3072
0x0000: 4500 0028 b045 0000 3a06 7111 c0a8 6f11 E..(.E..:.q...o.
0x0010: c0a8 6f17 930c 0015 77d8 01a1 0000 0000 ..o.....w.......
0x0020: 5002 0c00 37ce 0000 P...7...
10:52:59.296875 IP (tos 0x0, ttl 128, id 398, offset 0, flags [DF], proto: TCP (6), length: 44) 192.168.111.23.21 > 192.168.111.17.37644: S, cksum 0x4f58 (correct), 1685290308:1685290308(0) ack 2010644898 win 64240 <mss 1460>
0x0000: 4500 002c 018e 4000 8006 99c4 c0a8 6f17 E..,..@.......o.
0x0010: c0a8 6f11 0015 930c 6473 7d44 77d8 01a2 ..o.....ds}Dw...
0x0020: 6012 faf0 4f58 0000 0204 05b4 0000 `...OX........
10:52:59.296875 IP (tos 0x0, ttl 128, id 110, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.111.17.37644 > 192.168.111.23.21: R, cksum 0xca50 (correct), 2010644898:2010644898(0) win 0
0x0000: 4500 0028 006e 0000 8006 dae8 c0a8 6f11 E..(.n........o.
0x0010: c0a8 6f17 930c 0015 77d8 01a2 77d8 01a2 ..o.....w...w...
0x0020: 5004 0000 ca50 0000 P....P..
Following the ACK and RST packet exchange we now see the actual SYN packet sent from the hacker to the victim network, as evidenced in the packet with the S highlighted. This then elicits a SYN/ACK packet back from the victim network on its port 21. This exchange is then finalized by the RST packet sent back from the hacker’s computer to the victim network. These three packets now hold a much richer harvest in terms of profiling information.
We have the same ttl of 128 from the victim computer, but we also have the window size of 64240. Though this value is not on the list I hyperlinked to earlier, it is indeed a window size I have seen many times before from a Win32 (32 bit variants of Microsoft Windows such as Win NT, 2K, XP and 2K3). Another defining feature of a Microsoft Windows computer is that of predictably incrementing IP ID numbers. In this case we only have an IP ID value, in this case 398 in the middle packet above. We would need at least one more before being able to say with more confidence that this computer is indeed an MS Windows one. On that note let’s take a look at the remaining packets from the Nmap scan.
10:52:59.312500 IP (tos 0x0, ttl 59, id 54025, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.111.17.37644 > 192.168.111.23.80: S, cksum 0x3393 (correct), 2010644897:2010644897(0) win 4096
0x0000: 4500 0028 d309 0000 3b06 4d4d c0a8 6f11 E..(....;.MM..o.
0x0010: c0a8 6f17 930c 0050 77d8 01a1 0000 0000 ..o....Pw.......
0x0020: 5002 1000 3393 0000 P...3...
10:52:59.312500 IP (tos 0x0, ttl 128, id 399, offset 0, flags [DF], proto: TCP (6), length: 44) 192.168.111.23.80 > 192.168.111.17.37644: S, cksum 0x7913 (correct), 1685345101:1685345101(0) ack 2010644898 win 64240 <mss 1460>
0x0000: 4500 002c 018f 4000 8006 99c3 c0a8 6f17 E..,..@.......o.
0x0010: c0a8 6f11 0050 930c 6474 534d 77d8 01a2 ..o..P..dtSMw...
0x0020: 6012 faf0 7913 0000 0204 05b4 0000 `...y.........
10:52:59.312500 IP (tos 0x0, ttl 128, id 111, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.111.17.37644 > 192.168.111.23.80: R, cksum 0xca15 (correct), 2010644898:2010644898(0) win 0
0x0000: 4500 0028 006f 0000 8006 dae7 c0a8 6f11 E..(.o........o.
0x0010: c0a8 6f17 930c 0050 77d8 01a2 77d8 01a2 ..o....Pw...w...
0x0020: 5004 0000 ca15 0000 P.......
The first piece of information that the hacker looks at is to see if the IP ID number increments to 399. This IP ID indeed is 399 as seen in the middle packet. With this information the hacker is quite confident that he is dealing with either NT, 2K , XP, or 2K3. Also seen in this packet sequence is that port 80 on the victim network seemingly has a service, as evidenced by the SYN/ACK, The SYN/ACK packet is ascertained by verifying the flag field in the TCP header, in this case the underline hex value of 12 or decimal 18. This value is reached by the SYN flag value of 2 being added to the ACK flag value of 16.
On to enumeration
With the hacker now knowing that both port 21 and 80 are open for business, he moves on to the enumeration stage. What he needs to know now is what type of webserver is listening for connections. It would be pointless for him to use an Apache exploit on an IIS web server. With that in mind he opens up a cmd.exe session and fires up netcat.
C:\>nc.exe 192.168.111.23 80
GET slslslls
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Mon, 06 Aug 2007 15:11:48 GMT
Content-Type: text/html
Content-Length: 87
<html><head><title>Error</title></head><body>The parameter is incorrect. </body>
</html>
C:\>
We can see in the above noted netcat or nc.exe syntax that he types in the victim’s IP address as well as port number 80. Once he hits enter he types in the HTTP verb of GET followed by some gibberish. This causes the victim network webserver to send back its system information as it does not understand the request. In essence it enumerates itself :-). So the hacker now knows that he is looking at Microsoft IIS 5.0. Excellent news indeed, as he has a variety of exploits for this version of IIS. All nicely bundled within the Metasploit framework.
Wrap up
With the hacker having scanned the victim network using Nmap a crucial series of packets were then received by the hacker. Buried within those packets, as we saw, was enough information for the hacker to take a very educated stab at the operating system, architecture, and with netcat, also the server type.
* We had an incrementing IP ID number which point to MS Windows.
* We had a ttl of 128 which again points to MS Windows.
* The ttl of 128 also points to an Intel x86 architecture vice say SPARC.
* Via netcat we then saw that the webserver was MS IIS 5.0.
All in all, not a bad haul of information. This allowed the hacker to profile the host, architecture, and service offered. With this information in hand the hacker was now ready to launch an attack on the victim networks webserver. In part three we will see just that. See you then.
Moving on
10:52:59.078125 IP (tos 0x0, ttl 49, id 9808, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.111.17.37668 > 192.168.111.23.80: ., cksum 0xfd46 (correct), ack 85042526 win 2048
0x0000: 4500 0028 2650 0000 3106 0407 c0a8 6f11 E..(&P..1.....o.
0x0010: c0a8 6f17 9324 0050 67d1 a55e 0511 a55e ..o..$.Pg..^...^
0x0020: 5010 0800 fd46 0000 P....F..
10:52:59.078125 IP (tos 0x0, ttl 128, id 397, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.111.23.80 > 192.168.111.17.37668: R, cksum 0x6813 (correct), 85042526:85042526(0)win 0
0x0000: 4500 0028 018d 0000 8006 d9c9 c0a8 6f17 E..(..........o.
0x0010: c0a8 6f11 0050 9324 0511 a55e 0511 a55e ..o..P.$...^...^
0x0020: 5004 0000 6813 0000 0000 0000 0000 P...h.........
The above two packets came right after the ICMP based ones we looked at in part one. Nmap sent an ACK packet to the victim network IP of 192.168.111.23 on port 80. In terms of profiling information we do not have a whole lot here. We saw that the ACK packet received from the hacker elicited an RST packet back, as this ACK was unexpected. In essence it did not belong to a previously established connection. We still have a ttl of 128, which corresponds to the ttl we saw earlier.
10:52:59.296875 IP (tos 0x0, ttl 58, id 45125, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.111.17.37644 > 192.168.111.23.21: S, cksum 0x37ce (correct), 2010644897:2010644897(0) win 3072
0x0000: 4500 0028 b045 0000 3a06 7111 c0a8 6f11 E..(.E..:.q...o.
0x0010: c0a8 6f17 930c 0015 77d8 01a1 0000 0000 ..o.....w.......
0x0020: 5002 0c00 37ce 0000 P...7...
10:52:59.296875 IP (tos 0x0, ttl 128, id 398, offset 0, flags [DF], proto: TCP (6), length: 44) 192.168.111.23.21 > 192.168.111.17.37644: S, cksum 0x4f58 (correct), 1685290308:1685290308(0) ack 2010644898 win 64240 <mss 1460>
0x0000: 4500 002c 018e 4000 8006 99c4 c0a8 6f17 E..,..@.......o.
0x0010: c0a8 6f11 0015 930c 6473 7d44 77d8 01a2 ..o.....ds}Dw...
0x0020: 6012 faf0 4f58 0000 0204 05b4 0000 `...OX........
10:52:59.296875 IP (tos 0x0, ttl 128, id 110, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.111.17.37644 > 192.168.111.23.21: R, cksum 0xca50 (correct), 2010644898:2010644898(0) win 0
0x0000: 4500 0028 006e 0000 8006 dae8 c0a8 6f11 E..(.n........o.
0x0010: c0a8 6f17 930c 0015 77d8 01a2 77d8 01a2 ..o.....w...w...
0x0020: 5004 0000 ca50 0000 P....P..
Following the ACK and RST packet exchange we now see the actual SYN packet sent from the hacker to the victim network, as evidenced in the packet with the S highlighted. This then elicits a SYN/ACK packet back from the victim network on its port 21. This exchange is then finalized by the RST packet sent back from the hacker’s computer to the victim network. These three packets now hold a much richer harvest in terms of profiling information.
We have the same ttl of 128 from the victim computer, but we also have the window size of 64240. Though this value is not on the list I hyperlinked to earlier, it is indeed a window size I have seen many times before from a Win32 (32 bit variants of Microsoft Windows such as Win NT, 2K, XP and 2K3). Another defining feature of a Microsoft Windows computer is that of predictably incrementing IP ID numbers. In this case we only have an IP ID value, in this case 398 in the middle packet above. We would need at least one more before being able to say with more confidence that this computer is indeed an MS Windows one. On that note let’s take a look at the remaining packets from the Nmap scan.
10:52:59.312500 IP (tos 0x0, ttl 59, id 54025, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.111.17.37644 > 192.168.111.23.80: S, cksum 0x3393 (correct), 2010644897:2010644897(0) win 4096
0x0000: 4500 0028 d309 0000 3b06 4d4d c0a8 6f11 E..(....;.MM..o.
0x0010: c0a8 6f17 930c 0050 77d8 01a1 0000 0000 ..o....Pw.......
0x0020: 5002 1000 3393 0000 P...3...
10:52:59.312500 IP (tos 0x0, ttl 128, id 399, offset 0, flags [DF], proto: TCP (6), length: 44) 192.168.111.23.80 > 192.168.111.17.37644: S, cksum 0x7913 (correct), 1685345101:1685345101(0) ack 2010644898 win 64240 <mss 1460>
0x0000: 4500 002c 018f 4000 8006 99c3 c0a8 6f17 E..,..@.......o.
0x0010: c0a8 6f11 0050 930c 6474 534d 77d8 01a2 ..o..P..dtSMw...
0x0020: 6012 faf0 7913 0000 0204 05b4 0000 `...y.........
10:52:59.312500 IP (tos 0x0, ttl 128, id 111, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.111.17.37644 > 192.168.111.23.80: R, cksum 0xca15 (correct), 2010644898:2010644898(0) win 0
0x0000: 4500 0028 006f 0000 8006 dae7 c0a8 6f11 E..(.o........o.
0x0010: c0a8 6f17 930c 0050 77d8 01a2 77d8 01a2 ..o....Pw...w...
0x0020: 5004 0000 ca15 0000 P.......
The first piece of information that the hacker looks at is to see if the IP ID number increments to 399. This IP ID indeed is 399 as seen in the middle packet. With this information the hacker is quite confident that he is dealing with either NT, 2K , XP, or 2K3. Also seen in this packet sequence is that port 80 on the victim network seemingly has a service, as evidenced by the SYN/ACK, The SYN/ACK packet is ascertained by verifying the flag field in the TCP header, in this case the underline hex value of 12 or decimal 18. This value is reached by the SYN flag value of 2 being added to the ACK flag value of 16.
On to enumeration
With the hacker now knowing that both port 21 and 80 are open for business, he moves on to the enumeration stage. What he needs to know now is what type of webserver is listening for connections. It would be pointless for him to use an Apache exploit on an IIS web server. With that in mind he opens up a cmd.exe session and fires up netcat.
C:\>nc.exe 192.168.111.23 80
GET slslslls
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Mon, 06 Aug 2007 15:11:48 GMT
Content-Type: text/html
Content-Length: 87
<html><head><title>Error</title></head><body>The parameter is incorrect. </body>
</html>
C:\>
We can see in the above noted netcat or nc.exe syntax that he types in the victim’s IP address as well as port number 80. Once he hits enter he types in the HTTP verb of GET followed by some gibberish. This causes the victim network webserver to send back its system information as it does not understand the request. In essence it enumerates itself :-). So the hacker now knows that he is looking at Microsoft IIS 5.0. Excellent news indeed, as he has a variety of exploits for this version of IIS. All nicely bundled within the Metasploit framework.
Wrap up
With the hacker having scanned the victim network using Nmap a crucial series of packets were then received by the hacker. Buried within those packets, as we saw, was enough information for the hacker to take a very educated stab at the operating system, architecture, and with netcat, also the server type.
* We had an incrementing IP ID number which point to MS Windows.
* We had a ttl of 128 which again points to MS Windows.
* The ttl of 128 also points to an Intel x86 architecture vice say SPARC.
* Via netcat we then saw that the webserver was MS IIS 5.0.
All in all, not a bad haul of information. This allowed the hacker to profile the host, architecture, and service offered. With this information in hand the hacker was now ready to launch an attack on the victim networks webserver. In part three we will see just that. See you then.
In part two of this article series we left off having gathered all of the necessary information required for an attack on our victim network. On that note let’s carry on with the actual hack itself. This will be followed by the transferring over of some programs required in order to further the post-exploitation strategies of the hacker. It would be rather pointless to simply hack a computer and then withdraw. Normally the goal of any malicious hacker is to not only gain a presence on a computer network, but also to maintain it. That normally means trying to hide their ongoing presence. Time for the fun stuff Now I will be using the Metasploit Framework in order to facilitate the actual hack itself. This framework is really a thing of beauty in that it offers you a large variety of exploits, and just as importantly many different options for your choice of payload. You may not always want to have a reverse shell, or inject VNC. The payload will often depend on the target at hand, the network architecture, and your ultimate goal. In our case, we will go with the reverse shell. This is always beneficial, and especially so in case your target is behind a router and not directly accessible. For example you hit a webserver, but it is one of several which are load balanced. No guarantee that you will be able to connect to it with a forward shell, hence you’re wanting the computer to shovel a shell back to you. Lastly, I will not cover the actual usage of the Metasploit Framework for this is something that I have covered several times in other articles. We shall concentrate on what things look like at the packet level. Now instead of taking the approach of covering each step of the hack with screenshots and code snippets we will take a different tack. What we shall do is recreate the hack with the help of Snort. We shall take the binary log of the hack I did, and then parse it through Snort to see what it saw. Ideally, it will have seen everything I did. In reality what we are going to do is packet forensics. The goal will be to see how accurately we can come to reassembling exactly what has happened. On that note, I shall take the binary packet log which recorded everything I did and parse it through Snort with its default ruleset in place. Snort output The syntax used to invoke snort is as follows: C:\snort\bin\snort.exe –r c:\article_binary –dv –c snort.conf –A full This in turn caused Snort to parse the binary packet called article_binary which resulted in the below output. I have truncated the output of Snort to the germane parts for brevity. ============================================================== Snort processed 1345 packets. ============================================================== Breakdown by protocol: TCP: 524 (38.959%) UDP: 810 (60.223%) ICMP: 11 (0.818%) ARP: 0 (0.000%) EAPOL: 0 (0.000%) IPv6: 0 (0.000%) ETHLOOP: 0 (0.000%) IPX: 0 (0.000%) FRAG: 0 (0.000%) OTHER: 0 (0.000%) DISCARD: 0 (0.000%) ============================================================== Action Stats: ALERTS: 63 LOGGED: 63 PASSED: 0 The part that is of interest to us is the fact that 63 alerts were triggered by the hacking activity. We will now take a look at the alert.ids file which will give us more detailed information as to what happened. Now if you remember the first thing the hacker did was use Nmap to scan the network. That also happens to be the first alert triggered by Snort. [**] [1:469:3] ICMP PING NMAP [**] [Classification: Attempted Information Leak] [Priority: 2] 08/09-15:37:07.296875 192.168.111.17 -> 192.168.111.23 ICMP TTL:54 TOS:0x0 ID:3562 IpLen:20 DgmLen:28 Type:8 Code:0 ID:30208 Seq:54825 ECHO [Xref => http://www.whitehats.com/info/IDS162] Following this the hacker used netcat to enumerate the webserver in an effort to find out what type it was. This enumeration attempt did not trigger any Snort alerts. I would be curious to know why, so let’s take a look at the packet log. Well after seeing the normal TCP/IP three way handshake, the following packet was seen. 15:04:51.546875 IP (tos 0x0, ttl 128, id 9588, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.111.17.1347 > 192.168.111.23.80: P, cksum 0x5b06 (correct), 3389462932:3389462943(11) ack 2975555611 win 64240 0x0000: 4500 0033 2574 4000 8006 75d7 c0a8 6f11 E..3%t@...u...o. 0x0010: c0a8 6f17 0543 0050 ca07 1994 b15b 601b ..o..C.P.....[`. 0x0020: 5018 faf0 5b06 0000 4745 5420 736c 736c P...[...GET.slsl 0x0030: 736c 0a sl. There is nothing remarkable in this packet beyond the fact that there is a GET request with some garbage after it as evidenced by the slslsl. So in reality there was nothing for Snort to trigger on. It would be rather difficult to build an effective IDS signature to trigger on this type of enumeration attempt. That is likely why there are no such signatures. The next packet after this is where the victim networks webserver enumerates itself. After the enumeration was done the hacker immediately sent exploit code to the webserver. This exploit code then resulted in quite a few Snort signatures being triggered. Specifically for the exploit shown below I saw this Snort signature. [**] [1:1248:13] WEB-FRONTPAGE rad fp30reg.dll access [**] [Classification: access to a potentially vulnerable web application] [Priority: 2]08/09-15:39:23.000000 192.168.111.17:1454 -> 192.168.111.23:80 TCP TTL:128 TOS:0x0 ID:15851 IpLen:20 DgmLen:1500 DF ***A**** Seq: 0x7779253A Ack: 0xAA1FBC5B Win: 0xFAF0 TcpLen: 20 [Xref => http://www.microsoft.com/technet/security/bulletin/MS01-035.mspx][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0341][Xref => http://www.s ecurityfocus.com/bid/2906][Xref => http://www.whitehats.com/info/IDS555] Following this series of alerts Snort next fired off on a series of TFTP alerts. Once the hacker gained access to the webserver he then began to use the built-in TFTP client to transfer over four files: nc.exe ipeye.exe fu.exe msdirectx.exe After these files had been transferred over the hacker used netcat to send a shell back to his computer. From there he disconnected his other shell which resulted from the initial attack and did all remaining work in the netcat shell. Interestingly enough, none of the follow activity performed by the hacker via the reverse shell was logged by Snort. This in spite of the fact that the hacker used the rootkit he had transferred over via TFTP to hide the process information for netcat. Not good at all, one would ideally have wanted the usage of the fu.exe rootkit to have fired an IDS signature. Wrap up In part three of this series we saw the hack that was pulled off by the hacker as it was seen by Snort. We were able to recreate pretty much everything that was done with the exception of the usage of the rootkit. While an IDS is quite a useful piece of technology, and should be a part of your networks defenses, it isn’t perfect. It will only alert you to traffic that it has signatures for. With this in mind we shall learn how to build Snort signatures in the last part of this article series. Furthermore, we shall also see how to test these signatures to verify their effectiveness. See you then. |
0 comments:
Post a Comment