LinuxPlanet Blogs

Last month the Wi-Fi Alliance started steps to put an end to WEP and TKIP. By January 2011 the Wi-Fi Alliance plans to disallow TKIP on access points, and disallowed its use on all WiFi devices by 2012. WEP unfortunately survives a bit longer, with the standard being banned on access points from 2013 and banned from all WiFi devices a year later. WPA2-Mixed mode which allows TKIP, will also go in 2014, leaving only WPA2-AES.

With that good news last month, bad news comes this month for the security of Wi-Fi standards.

AirTight Networks have uncovered a vulnerability that they call “Hole196″ (  The 196 referring to the last line of Page 196 in the IEEE 802.11-2007 specification ), this is a vulnerability in the WPA2 security protocol that exposes WPA2-secured Wi-Fi networks to malicious insiders. With WPA2 being vastly adopted as the most robust option for many environments due to its resilience to brute force dictionary attacks, this vulnerability will effect both corporate and public networks significantly.

By exploiting the vulnerability, an insider can bypass WPA2 private key encryption and authentication to sniff and decrypt data from other authorized users as well as scan their devices for vulnerabilities, and potentially allow attackers to compromise users devices. AirTight researcher, Md. Sohail Ahmad, will be demonstrating this vulnerability at the Black Hat Arsenal (July 29th) and at DEFCON18 (July 31st) in a presentation entitled “WPA Too?!”.
The “WPA Too” presentation will demo the vulnerability and explain how it can be exploited by a malicious user to attack and compromise a legitimate user.

For the people not lucky enough to attend either security conference, AirTight will present a public Webinar on August 4 at 19:00 GMT to detail its findings.

Once the details of the vulnerability are disclosed it will be time to determine what steps and countermeasures can be used to protect wireless network infrastructure. But for now all that can really be done is to break out the VPN tunnels whenever using Wi-Fi. This can at least protect against your data being intercepted but there is still the potential for the attacker to disrupt the targets network traffic.

---

References:

Credit where credit is due, these are the sites I read when looking into this vulnerability.

Goodbye, WEP & TKIP
WPA2 Hole196 Vulnerability
WPA2 finds itself in a “hole”! Vulnerable to insider attacks!
Black Hat ® Technical Security Conference: USA 2010 // Black Hat Arsenal
WPA2 Exposed with ‘Hole 196′ Vulnerability
Wi-Fi WPA & WPA2 Encryption Cracking Guide
Wi-Fi Alliance to dump WEP and TKIP … not soon enough
Researcher Hints 802.1X WPA2 Flaw

For those of you who haven't heard about Tabnabbing, its yet another form of phishing which seems to be simpler and more effective than the usual phishing attacks you would have heard of. An important thing about this attack is that it can't be detected easily, even a smart browser and a cautious web surfer can get easily fooled, leading to information theft.

What's Tabnabbing and How it works?

Suppose you are working with multiple tabs. One of your friend tweets about a cool pic, you visit the website, view the image and without closing the tab move to another. In the meantime, the script running on the page detects that the page is not in focus and change its content to either your bank login page or gmail, yahoo etc. along with the favicon too. So, the next time you visit the page, because of the favicon and the changed content you thing its your regular bank website which has logged you out due to an expired session and you try to login, giving away the credentials.

This is Tabnabbing.

If you haven't noticed, the URL still won't change but the webpage caught you by surprise, fooling you ultimately. A good thing is that even in this case, the usual method of "Alway Watch the URL" will work, but the user is pretty convinced with the favicon itself.

An initial demo of Tabnabbing was shown by Aza Raskin, its discoverer, where he uses Javascript to turn the webpage into a Gmail login page. Yes, turning script off(by using No-Script addon) will not let this happen but in a proof-of-concept by researcher Aviv Raff, it seems that this can be done without using scripts too. His forged webpage reloads every 20 seconds and will turn into the phishing page(a gmail image) only when you move to another tab using a mouse and if you move with keyboard it will take 10 reloads.

Fix for Tabnabbing

As Aza Raskin suggests, Firefox Account Manager is a good way to defend a user against such attacks. This attack has worked successfully on many major browsers, though the favicon haven't worked on Safari or Chrome. Although I even read a blog about IE8 being able to detect Tabnabbing, don't know how but I will still suggest you to please check the URL before signing in or use something like the Firefox Account Manager.

I'm at Southeast LinuxFest right now, listening to Daniel Chen's Linux audio talk. A bit over an hour ago, I finished my presentation on the Linux security myth. It's meant to be accessible to normal users or to geeks needing to explain to normal users. I was asked afterward why I didn't talk about buffer overflows. That's easy: normal users can't do anything about them.

Slide 31 shows what happens when a .desktop is not executable and is in a home directory. Notably, that Fedora and openSUSE make it easy to run anyway, while Ubuntu policy says those buttons aren't OK (thanks James Tatum for the link pointer). I can understand that reasoning, but I don't expect normal people to know how to mark it as trusted or geeks to know that that's a euphemism for "set the executable bit."

Google announced the beta release of its new secure search engine this Friday. This search engine provides you with ssl encryption to protect your searches from interception, making it the first search engine to provide such a feature. All you have to do is use https instead of http to access this service.

One of the reasons why this service is not being provided by other search giants is because it consumes a lot of processing power to encrypt and decrypt the data and most importantly search queries are not really considered private or something worth protecting from interception. People who need such a protection could just use Tor to stay anonymous and protect their search privacy.

Althought I still don't see many people having any need to encrypt their searches but it still might be essential to a few and having an option is always good. Your browser might take sometime to connect to the https server but you probably won't even notice it. This option is not available for image or map searches.

Secure SSL was earlier an option for Gmail too which was made default in January this year "But it's not going to be the default option, at this point. There's a lot of work to be done before we get there.", said Muarli Viswanathan, a Google Search Product manager.

Who will use Secure Google Search?

In case you are wondering who will be the ones using this feature, then let me list a few of them coming to my mind:

• Chinese or people of other countries/organization who face high data survelliance will be benefited by this feature. Due to encryption, their searched queries won't be visible.
• Its a well known fact that although all the information being searched is available to all, but looking at one's search queries, you can easily guess what one's upto. So, business officials, government agencies or even terrorists will be benefited from it.

Protecting one's online privacy has been one of the most popular point of concern for Internet users these days. If you don't want a website to keep track of you or if want to remain anonymous for a website, you are advised to disable cookies or use private browsing mode in your browser. But a forthcoming paper by an Electronic Frontier Foundation technologist suggests that Cookies are not be the only way to identify users, a combination of various information about the system and software collected from the browser are enough to uniquely identify a user.

Modern web browsers provide a user with a lot of features but they have also been designed to send tons of information to websites - screen size, colour schemes, detailed browser version, fonts installed, the order in which they are installed, font size, OS information and a whole bunch of similar info.

According to Peter Eckersley, the researcher behind the paper, a collection of such innocent looking information can be used to uniquely identify users. He calls this technique Browser fingerprinting.

Think of it this way, it is similar to finding out a person if you know his date of birth, gender, type of clothes he usually wear, height, weight etc. The individual bits of information may seem useless but their combination can become personally identifiable. 

Of the 470,161 browsers sample data, collected through informed users visiting EFF's Panopticlick, 94.2% of browsers were unique in the sample i.e. about 1 in 450,000.

Websites already use this technique

Although this point is being raised now, this technique is already being used by a lot of websites - mainly bank or credit card companies. They call it CDI - Clientless Device Identification. They use it to identify who is a legitimate user and who's not.

According to a Gartner report, Februrary 2010, this technique gives 15-25 percent lift in fraud detection rates than Flash cookies, which were used earlier to identify users.

Even though this technique is used in a good way to catch frauds but there should be ways of configuring your browser to prevent the flow of such data. Peter will be presented at Privacy symposium in Berlin in July.

I am a very serious gmail user.  I think it's a good service.  I have already written on this blog that I am a serious fan of the mutt email client.  Please understand that I don't feel that any other gui mail client competes for the speed with which I can process my email.  So I don't want this to be a email client vs. email client war, I've already said my peace on that and if you don't like that please find another blog.

I do think it's important to check and see what the critical differences are in the two methods I use to access the service.  Clear declaration, that I use imap with mutt so I am not caching or storing the email local (i.e. POP3) which might make a difference in this argument.

After using the web interface with the google labs on for keyboard shortcuts, and giving myself a solid two week time frame during which to become proficient with using the keyboard with the web interface.  I have to say that is can be quite efficient on it's own and very usefull, so the below comparison has everything to do with web+keyboard vs. mutt and the efficiency with processing/managing emails.

Gmail web Pros:
Search speed: very fast and process all headers and body.
Open Access: any OS, any PC commands and interface available

Gmail web Cons:
No gpg support: not for key verification, not for encryption.
Conversation presentation: does invite confusion about where messages are

Mutt pros:
More refined searches: the limit statements are crazy specific
GPG support: completely, inline.
Closed Access: w/ssh access offers only encrypted channel

Mutt cons:
Software requirement: somewhere there must be software installed
Complete searches: if you do a search of body content takes a long time

I have to confess, that with multiple accounts, I have a serious need for some features on some accounts and needs for other features with others.  I actually have one account that I use both interfaces with often.

Find you comfort level, be realistic about access and real needs, if you would like to have high security and choose mutt, it might be very uncomfortable to use a mobile phone for access with a crampped keyboard.

Be practical, pragmatic and safe.

--
CafeNinja

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

Rainbow tables are a way to break md5 hashes. Rainbow tables reduce the difficulty of brute force cracking a single password by creating a large pre-generated data set of hashes for nearly every possible password.

The main benefit of Rainbow Tables is that while the actual creation of the rainbow tables takes much more time than cracking a single hash, after they are generated you can use the tables over and over again. Additionally, once you have generated the Rainbow Tables, RainbowCrack is faster than brute force attacks and needs less memory than full dictionary attacks.

Rainbow tables can break any 6 length password in less than a second. It might not be able to break long and complex passwords.

So if a hacker get access to your database, he can easily extract your users password. And most users have a habit of keeping save password for all their internet activities. Its time to move to some secure hashing mechanism like "phpass password hashing method" also used in Drupal 7. You can use phpass to protect your Drupal 6 site. But after installing you won't be able to uninstall it easily. Since the md5 hash will be lost after this.

If you are end user and don't know what to do, try out some site to test whether your password is still strong against Rainbow attack, some of these sites are Md5crack and PassCracking.

The increased hacking attempts these days convinced me that password alone won't save my system from the attackers out there. For those of you who think that your system is safe because of some complex password, then think twice, because there is always a chance that a brute force attack from some dedicated server(s) might break it. A good password is a decent start, but its definitely not the end. In this tutorial, I will tell you some ways to make your ssh login more secure by making simple changes to the sshd_config file.

Open sshd_config file

[root]# vim /etc/ssh/sshd_config

Banning the Root Login

Lets start by blocking root user login via ssh.

PermitRootLogin no

Always block access to root user. Since every linux operating system has a root account, an attacker can always make a bruteforce attempt for root login.

Disable User logins with Null passwords

PermitEmptyPasswords no

With this options user can't login to accounts will null passwords. People generally set this option to 'yes' to enable scp and automatic backup. But I strongly recommend to turn it off. If you are looking for a secure automatic backup and scp, you better start playing with some keys . No kidding, with use of ssh keys you can make secure automation of various tasks(which use ssh) possible. This howto should give you a start, ssh login without password.

Changing the Port on which SSH Daemon listens

Port 8383    # or any of your favourite ports

SSH defaults to port 22. But you can change the port on which the ssh deamon will listen for incoming requests. This is an additional security measure.

Generating a new server after some fixed time.

KeyRegenerationInterval 1h

This option signifies how long the server waits before automatically regenerating its key. This is a security measure to prevent decrypting captured sessions.

Check User File/Dir permissions before Login

StrictModes yes

This will check user permissions in home directory and rhosts file before login. This option must be set to yes because sometime user might leave their directory writable for everyone.

I am sure this will help a lot of you.

One way to receive up-to-date reports about vulnerability issues is subscribing to vulnerability RSS feeds: they update on demand, they don’t rely on your mail subsystem and they don’t fill up your mailbox. The only drawback is that you could miss alerts if you don’t sync your feeds for a long time, but if you’re a IT security manager, you don’t have a life, so how could it happen anyways?

Here’s the top feeds you should be subscribed to (CVE tags are reported in brackets):

1. NIST Vulnerability Database.
2. US Cert Technical Security Alerts [CERT].
3. SecurityFocus Vulnerabilities [SF-INCIDENTS].
4. Open Source Vulnerability Database [OSVDB].
5. IBM Internet Security Systems Threats [ISS].
6. Vupen Security Advisories [VUPEN].
7. Secunia Latest Security Advisories (Unofficial) [SECUNIA].
8. eEye Security Advisories [EEYE].

The above list is also available as OPML file you can import into your feed reader.

Furthermore, you should subscribe to Operating Systems product-centric vulnerability feeds to ensure you receive timely information regarding updated packages and suggested workarounds for your infrastructure. Here’s a comprehensive list, sorted alphabetically:

1. Apple Security Announce (Mac OS X, iPhone, etc) [APPLE].
2. Checkpoint’s SmartDefense Service [CHECKPOINT].
3. Cisco’s Product & Service Security Advisories [CISCO].
4. Debian Security Advisories [DEBIAN].
5. Fedora Security Updates [FEDORA].
6. FreeBSD Security Advisories [FREEBSD].
7. Gentoo Linux Security Advisories (GLSA) [GENTOO].
8. Mandriva Security Advisories [MANDRIVA].
9. Microsoft’s Security Notification Service Comprehensive Edition [MS].
10. NetBSD Security Advisories [NETBSD].
11. OpenPKG Security Advisories [OPENPKG].
12. OpenBSD Errata [OPENBSD].
13. Red Hat Security Advisories [REDHAT].
14. Slackware Linux Security Advisories [SLACKWARE].
15. Solaris SunSolve Alerts [SUNALERT].
16. SUSE Linux Enterprise Security Advisories (also contains OpenSUSE advisories) [SUSE].
17. Ubuntu Security Notices [UBUNTU].

OS security advisory feeds are available as OPML file as well.

Have I missed anything? Please report if you find some advisory feed I accidentally missed. Also, if you’re into an Operating System security team and you don’t offer a security announcement feed, please consider making it available.

Related posts:

1. Windows back-to-the-future bug
2. Security through obscurity
3. Process management roundup/1

As many of you have noticed I'm posting in my social networking streams using base64 decode statements.  I just wanted to explain that I will be doing this even for the mundane.  I have had the ephifany that "some is good, more must be better" is maybe not the way I intended for my social live to be.

I should explain that I expected that these would be mostly walled gardens with each social networking service offering it's unique and special approach to the broadcast communication issue.  As more of these services have started integrating, using back door API's and making it a giant collective, that while my single voice is not important, it adds to a logarithm of what is the collective whole. 

I am not foolish, I don't think that my posting the command to decrypt what I post keeps my messages "secure", and that is not my intention for them.  What I do hope to succeed in is that my messages aren't being grokked for the commercial, financial and statistical benifit of corporate entities for whom I hold no allegiance, holding or care.  It's mine, and I made it for public consumption.  As I see venture capitalist investing millions of dollars in companies who scrub what is the internet collective for profit and gain, I am saddened.  I would understand if doing this created a benefit for the consumer or the internet as a whole. 

My goal is to allow me, my family and my friends to continue using the tools as they were originally designed without offering my portion of mind-share away.  I feel that, especially in the case of the base64 posts, I achieve the goals of:

1. communicating with family and friends with miniumum tech overhead.
2. make it easy for someone to ignore me on a broadcast stream.
3. upset the machines on the far side of the services I use from gaining profit over my ideas and opinions.

I would be lying if I didn't see the added benifit of this preparing myself and family for secure communications in the case we feel corporations or the state care far too much about what we say or limiting our freedoms.  This is just an advance warning that it only escalates from the base64 posts.  It is my humble opinion that what used to be called "paranoid" measures, by todays standards, can at best be referred to as moderate privacy.

--
CafeNinja

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.