Archive for the ‘Security’ Category

ARP Poisoning and Detection

Friday, November 4th, 2011

Many people don’t really know about the ARP or the Address Resolution Protocol. This protocol is a common protocol used in local area networks.

To define it, the Address Resolution Protocol (ARP) is a telecommunications protocol used for resolution of network layer addresses into link layer addresses, a critical function in multiple-access networks (from wikipedia). IPV4 and IPV6 has oftentimes this functionality implemented by default.

It is possible to hijack this protocol. This is called ARP Spoofing. This may allow an attacker to intercept data frames on a LAN, modify the traffic, or stop the traffic altogether. Generally, the aim is to associate the attacker’s MAC address with the IP address of another host.

Another term for ARP Spoofing is called ARP Poisoning. Below is a diagram that describes what ARP poisoning does to a network:

Although there are legitimate uses for ARP spoofing (like in hotels where unregistered machines redirect the host to a signup page), some malicious elements may use this protocol to initiate man in the middle attacks, or DOS (denial of service) attacks.

How to Detect ARP Poisoning

There is a way to detect ARP spoofing. For Windows, you can use Wireshark.

Here are two pictures of wireshark capturing the ARP requests. The first is a screenshot of normal network flow (ARP is filtered in):

Once the ARP spoofing sets in, this below happens:

Since we see duplicate IPs in the system, and if we know the router’s MAC address, we know that this source is the one doing the ARP poisoning.

CeGNULUG Talk & Discussion

Tuesday, July 12th, 2011

Short post.

The Cebu GNU-Linux Users Group (CeGNULUG) is having a group talk and discussion at the TechBar on July 29, 2011 at 7pm.

Topics discussed are as follows:

1. Google+
2. Meego Overview with QtQuick sample application.
3. Demystifying Backdoor Shells: The Risk

There will be an open forum afterwards.

This event is sponsored by:

DevCon :: http://devcon.ph/ :: http://devworks.devcon.ph/

and

Exist :: http://exist.com/ :: http://facebook.com/existg​lobal

The Importance of Sandboxing Plug-ins in Browsers

Tuesday, February 9th, 2010

We all have our favorite plug-ins for our browsers. Many people can’t live without their flash plug-in for their games and watching Hulu and YouTube videos. Other people use Java applets for their enterprise applications. Still, others use Quicktime for watching .mov videos on the browser.

What happens if a rogue plug-in runs in your browser? This is when sandboxing plug-ins become apparent.

Sandboxing applications have had it’s purpose and use in Java applications, especially plug-ins, where the program is placed in a restrictive environment that is not allowed to access system functions unless it is given access to.

This allows the plug-in to run in it’s own environment without harming the other browser or system processes.

How is sandboxing applied? Either through the plug-in itself (like java, and in a lesser way, flash), or through the browser.

Newer browsers such as Google Chrome separate their browser windows through threads, allowing rogue plug-ins to crash the affected window only. Other browsers implement some sort of sandboxing of their plug-ins. Which is better?

Since most people are in the fad of flash-bashing these days, let us make a sample of a rogue flash application that crashes the browser. Here is the link.

Mind you, I would say that flash has its uses; however as someone who dabbled in ActionScript one time or the other knows that the Flash runtime has a number of quirks and bugs that are really downright bad. In my opinion, this example is one of them.

Browsers who do not sandbox their plug-ins or separate their windows as separate threads would find this page crashes their browser really bad.

This includes Firefox, IE and Safari.

The only way to avoid spectacular crashes is to use a browser which implements some sort of separation between the plug-in and the browser itself.

Opera and Google Chrome passes this test admirably.

Interestingly, due to the flash plug-in running in a separate process in 64 bit systems in Linux (through nspluginwrapper), only the nspluginwrapper crashes, and does not take the whole browser in it.

To end, this is what I like to see implemented in all browsers. Running plug-ins in a separate process, as well as limiting it’s scope in relation to access to the underlying operating system.

Google, Facebook, Twitter and Privacy

Friday, December 11th, 2009

A few days ago, I received a wall post from the Facebook blog, that they have teamed up with Google Real Time Search. I did a little research on what that truly meant and found this post here on the official Google blog.

In a nutshell, this is what is happening. Google is getting posts and status updates from many networking sites and allowing them to be shown in the search results. How are they gonna do that? I got my answer within a few days.

Facebook had a change in their privacy settings. The time that you log into facebook, you will be notified of the privacy settings page and would suggest you that you change your settings to their recommended one – one that is seen by practically everyone.

Now, I am no privacy freak. Far from that. What I am concerned about is that by allowing your profile to be shown to all, a person will risk being used or taken advantage of by unscrupulous individuals in the net.

I’ve had my cellphone number been sent text messages by people I do not know about some nice deal which was clearly a scam. I’ve had a rise in spam messages when I placed my email in a post or comment in a blog.

Having said that, I strongly agree with Bruce Schneier, a well known computer security specialist, that:

For if we are observed in all matters, we are constantly under threat of correction, judgment, criticism, even plagiarism of our own uniqueness. We become children, fettered under watchful eyes, constantly fearful that — either now or in the uncertain future — patterns we leave behind will be brought back to implicate us, by whatever authority has now become focused upon our once-private and innocent acts. We lose our individuality, because everything we do is observable and recordable.

in his blog as a rebuttal to Eric Schmitt, CEO of Google, who said a dangerous statement to Maria Bartiromo during CNBC’s big Google special, that “If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.”

Think about it. You don’t hide things from people you don’t know because you did something bad. It is more likely that you hide things from people you are not likely to trust because they would like to do bad things to you.