Colasoft Blog

Google announced last week that users can visit https://www.google.com to establish a secure connection for their searches, which Google says “helps protect your search terms and your search results pages from being intercepted by a third party on your network”.

In response to the worries that search terms are eavesdropped by third party on public Internet accesses, especially at public like WIFI hotspots at airport, Google offers a connection over HTTPS to protect your search terms been sniffed. The purpose of this article is to figure out how does the encrypted search connection work and see if it really protects you. As packets never lie, we will go down to the packet level to check the original traffic out. Let Capsa network analyzer to prove that. First let’s check out how the normal search goes.

Normal Google Search

First run Capsa Network Analyzer and start a capture, then visit http://www.google.com, enter the keyword Capsa, and click the Google Search button. Until now, we can clearly see a HTTP packet captured with the keyword “Capsa”. If in a public network, the hacker can easily get the GET request and figure out your search terms with little tricks.

And another important way to get your search terms is to get the packet of your clicking on a link in the search results, which contains the keywords too. In this case we will click the second link in the results. When we go back to the packets, we can see there are two DNS packets, a DNS query and a response, then three-way-handshake with www.colasoft.com. The fourth packet is a HTTP GET packet.

If you are interested in this GET packet, you will find a Referer string in it, which is pretty the same as the string in figure below.

Encrypted Google Search

After the normal search, we flush the DNS, start a new capture, and reopen the browser. This time we visit https://www.google.com, enter the same keyword “Capsa”, and click the Google Search button. The page loaded and we go back to the analyzer and find there are DNS packets and HTTPS packets, without any HTTP packets (figure E). As all transmissions are protected by SSL, we cannot find any search keyword in these packets, unless you have that power to decode them.

Then we click the same link over the returned search results, and we find there are two DNS packets too and three-way-handshake and then a HTTP GET packet to load the Colasoft page. We can check this packet and find there is not a Referer string (figure F) in it. As google’s explanation, they’ve stopped transferring this value to the clicked page to prevent keywords being tracked.

Google also pointed out that the encryption search only protects you from keywords tracking but the website you visit later could also be spotted because of you DNS queries. And that’s something they cannot do about. But that’s not the topic of this article. We can sure that the new HTTPS Google search does what it alleged (you can learn more Google SSL search from http://www.google.com/support/websearch/bin/answer.py?answer=173733&hl=en). Furthermore, the society is talking about the network security more and more these days. We should always pay attention to our communications on the Internet, emails, social media communications and passwords, and so on.

In a typical MAC flooding attack, a switch is flooded with packets, each containing different source MAC addresses. The switch records these addresses to its CAM table. When the table is full, the switch cannot look up the right destination port, but to broadcast out on all ports. A malicious user could then use a packet sniffer running in promiscuous mode to capture sensitive data from other computers, which would not be accessible were the switch operating normally.

How to detect if there’s a MAC flooding attack in the network? In this article, I will demonstrate to you with Colasoft Capsa Analyzer.

For detecting MAC flooding attack. Let’s start capture, we start the analysis from the SUMMARY TAB. All these statistics seem right. Except one when we come to the Physical address count. There are more than a hundred thousand MAC addresses discovered in this network. How could this small network have so many machines? Possibly, it is a mac flooding attack.

We need to check the addresses in the NOD EXPLORE. Open the physical explorer, and look this number; there are more than 1800 MAC addresses in local segment. It’s abnormal; there is no way that so many machines exist in this network. And apparently, these addresses are not real. We are sure that there are worm activities, or attacks in the network.

Let’s see how these nodes are communicating. Open the MATRIX TAB. And we choose Top 1000 physical node matrix type. We see this matrix, what a mess! There are so many nodes communicating, and according to the colors of the line, red means one way transmitting.

And we can go to the PHYSICAL CONVERSATION TAB to read that it’s true. Almost all nodes only send one packet out. Most packets are 64 bytes.
We know that all machines in our network are connected with a switch. This looks like a MAC flooding attack.

Still, to confirm our prediction, we need to see the original data of the packets they send out. Open the PACKET TAB. We see the delta time between packets is very small, which gives a great pressure to the switch. Almost all packets are 64 bytes. And let’s look at the original data in the packets. Almost all packets are randomly generated by padding same digits in the packets.

According to all these behaviors, and decoded information from packets, we are pretty sure that there is MAC flooding in this network. But it’s hard to find the attacker’s address directly because all addresses are forged. However, we can cut some machines off the network to eliminate the innocent machines until we find the target one.
Watch the video tutorial of detecting MAC flooding attack is avaliable at Here!

We are so excited to announce a new version of our flagship product – Colasoft Capsa Network Analyzer. The latest released Capsa 6.9 R2 is now fully compatible with the current Windows 7 32bit and 64bit Edition, satisfying the users’ growing need for Win 7 compatibility.

Please check the following for new features and latest improvement of Capsa 6.9 R2. We hope you enjoy the new version! Any suggestions will be highly appreciated.

New Features:

• Support Windows 7 32bit and 64bit Edition.
• Packet Player: Support replay multiple packet files simultaneously.
• Globally added two new options: alias(or hostname) and address can be displayed simultaneously.
• There is a new option in the global Option settings users can enable to prevent hibernation when capturing.
• New protocol ISL and FCoE can be recognized now.
• Decoders for ISL, FCoE protocols.
• Support Windows Server 2008 and X64 Edition.

Improvements:

• An online help section activated in Start Page below Quick Link.
• The Loopback won’t be shown in the NIC test wizard.

Bug Fixed:

• A wrong value has been displayed in the decode area for IP Fragment Offset.
• Users login as other windows ID will have to reactivate Capsa every time they login.

Download a Free Trial Now