If you missed the other articles please read:
- Tools of the Trade (Part 1)
- Tools of the Trade (Part 2)
- Tools of the Trade (Part 3)
- Tools of the Trade revisited (Part 1)
- Tools of the Trade revisited (Part 2)
In the second part of this article series we looked at how an IDS could possibly detect certain security tools and we also covered how Snort would view Nmap stimulus. We shall now end the series by seeing how Snort views a tool called Cain & Abel.
Over the course of the past two articles, and furthered in this one, is how computer security tools can leave residue. Specifically, residue that an IDS can detect. In part two we saw how easily Nmap shows up when performing various types of scans. Having this type of knowledge is crucial for your system administrators out there today. The same also applies to those lucky enough to only do network security, without the added burden and complexity of sys admin work.
Pretty much all of us who work in the computer network field today realize that not all attacks will come from the remote attacker. What of the trusted insider? That person who actually works at your company but for one reason or another now has a grudge to settle. These type of attackers have a huge advantage over the remote attacker as they are already inside the hardened network. Once inside the network you typically find a very soft interior which is quite inviting to someone with malicious intent. On that note we will take a look at a tool called Cain & Abel.
Figure 1
This piece of software is quite well known, and is also very capable as well. What we shall do with it now is see if Snort can see Cain & Abel doing a MAC sweep of the network. This would be typical of an attacker to do as it would give them some key information ie: what other machines are on the network and the MAC/IP address. Much like any attack, a good deal of time is usually spent on reconnaissance. On that note let’s begin the practical portion of this article.
Let’s get busy
Hopefully you will have surfed to the link I provided above and downloaded a copy of Cain & Abel as we will now use it. You will see in the screenshot below that I have the button next to the “folder” or save button pressed in.
Figure 2
This button, once pressed in, will start up the packet sniffer. Once you have done that, move your mouse into the white portion of the window ie: two centimeters below the button you just pressed, to start up the packet sniffer. Once there right click and a dialog box will come up. Simply press the “Scan MAC Addresses” option. Now that you have done that a lot of activity is going on in the background. This is a good time to point out that you should also have Snort running in the background prior to running the MAC discovery on Cain & Abel. No big deal if you didn’t have it running, simply get Snort configured and rerun the MAC discovery. What you will see from Snort is as seen below.
==========================================================
Snort received 280 packets
Analyzed: 280(100.000%)
Dropped: 0(0.000%)
==========================================================
Breakdown by protocol:
TCP: 0 (0.000%)
UDP: 0 (0.000%)
ICMP: 0 (0.000%)
ARP: 256 (91.429%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 24 (8.571%)
DISCARD: 0 (0.000%)
===========================================================
Action Stats:
ALERTS: 0
LOGGED: 0
PASSED: 0
===========================================================
Final Flow Statistics
,—-[ FLOWCACHE STATS ]———-
Memcap: 10485760 Overhead Bytes 16400 used(%0.156403)/blocks (16400/1) Overhead
blocks: 1 Could Hold: (0)
IPV4 count: 0 frees: 0 low_time: 0, high_time: 0, diff: 0h:00:00s
finds: 0 reversed: 0(%0.000000)
find_sucess: 0 find_fail: 0 percent_success: (%0.000000) new_flows: 0
pcap_loop: read error: PacketReceivePacket failed
Run time for packet processing was 47.0 seconds
C:\Snort\etc>
Well, we can see from the above noted Snort output that Snort did not pick up on the MAC discovery/scan that Cain & Abel did. Not surprising really as there is no rule for this in Snort. You can verify this by surfing through the Snort rules directory, and particularly the Scan ruleset. I was hoping someone by now would have been asking me just what the heck does the output of Cain & Abel look like when it does its MAC discovery/scan. Fear not for I was also logging the output with tcpdump.exe. Please see below for a traffic snippet.
10:28:46.890625 arp who-has 192.168.1.1 tell 192.168.1.107
0x0000: 0001 0800 0604 0001 000c 29b0 1654 c0a8 ……….)..T..
0x0010: 016b 0000 0000 0000 c0a8 0101 .k……….
10:28:46.890625 arp reply 192.168.1.1 is-at 00:0f:66:46:17:8a
0x0000: 0001 0800 0604 0002 000f 6646 178a c0a8 ……….fF….
0x0010: 0101 000c 29b0 1654 c0a8 016b 0000 0000 ….)..T…k….
0x0020: 0000 0000 0000 0000 0000 ead1 0cfb …………..
10:28:46.906250 arp who-has 192.168.1.2 tell 192.168.1.107
0x0000: 0001 0800 0604 0001 000c 29b0 1654 c0a8 ……….)..T..
0x0010: 016b 0000 0000 0000 c0a8 0102 .k……….
10:28:46.921875 arp who-has 192.168.1.3 tell 192.168.1.107
0x0000: 0001 0800 0604 0001 000c 29b0 1654 c0a8 ……….)..T..
0x0010: 016b 0000 0000 0000 c0a8 0103 .k……….
10:28:46.937500 arp who-has 192.168.1.4 tell 192.168.1.107
0x0000: 0001 0800 0604 0001 000c 29b0 1654 c0a8 ……….)..T..
0x0010: 016b 0000 0000 0000 c0a8 0104 .k……….
10:28:46.953125 arp who-has 192.168.1.5 tell 192.168.1.107
0x0000: 0001 0800 0604 0001 000c 29b0 1654 c0a8 ……….)..T..
0x0010: 016b 0000 0000 0000 c0a8 0105 .k……….
Now a shiny red apple goes to the one who can tell me if Cain & Abel was successful in getting some MAC resolution in the above snippet. Well, seeing as this article is not really interactive here is the answer. The first two ARP packets seen above show that the MAC discovery/scan was successful. We see that the “arp who-has” for 192.168.1.1 go out and then the “arp reply” come back with both the IP address and MAC address for 192.168.1.1 This ARP scan worked out quite well. Further to that, we saw that Snort did not pick up on it, and lastly we also saw at a packet level how all this activity looked.
Wrapup
Cain & Abel is an extremely robust tool with a lot of functionality built into it. It would be well worth your while to spend some quality time with it in order to explore all of its features. It can do a lot of damage on an internal network which is not properly secured. The whole intent of this series has been to show you that some of the tools of the trade leave residue behind and others not. That is very helpful to us as both system administrators and security analysts. Every little piece of intelligence that we can extract will only help us better protect our networks.
It is also vitally important to not only understand at a theoretical level what some of these tools do. You must also learn how to use them yourself. Once you have done so you will have a far better understanding in how to protect yourself from them. It is also helpful to write up some signatures for your IDS should there not already be some written for that tool. That type of signature knowledge will only come from studying the packet level output of these very same tools. I have said it before and I will say it again, don’t become overly reliant on a tools output. Always try to get as raw an output as possible. In our case that would be tcpdump.exe On that note I will end the article and as always hope it was of some use to you. I also value the feedback provided to me, by you the reader of these articles. Please don’t be shy, drop me a line! Till next time.
If you missed the other articles please read:
