Information Security News
A change in some early versions of Google's Chrome browser is attracting the attention of security researchers who say it can make it harder for end users to know when they're visiting a malicious site trying to push malware or phish login credentials.
The change, which is said to affect a small fraction of people running version 36 of Chrome, aka Canary, causes the browser's address bar (Google calls it the Omnibox) to no longer display the URL currently open. Instead, the domain name and any subdomains of the open page are shown immediately to the left of the Omnibox in what's dubbed the Origin Chip. Google developers haven't given a definitive explanation for the experimental change, although Jake Archibald, a developer advocate for Google Chrome, recently gave his personal thoughts here. Presumably, it's designed to keep up with various features already available in Internet Explorer, Firefox, and Safari that highlight the precise domain a browser is visiting. The features are designed to thwart attacks that rely on long, confusing addresses that can sometimes conceal the true domain that's open.
Researchers at PhishMe, a company that helps prevent organizations from falling victim to phishing and malware attacks, have been testing the trial interface and have found behavior they say could make it easier for attackers to fool end users. By loading up an address with long strings of characters, the researchers were able to completely suppress both the domain name and other address parameters in both the Omnibox and Origin Chip. For instance, when the PhishMe researchers entered the URL "hxxp://this.is.a.test.for.longurl.to.test.the.canary.property.in.the.new.chrome.browser.and.see.if.it.works.DOMAINNAME.com/CheckingNowWithSampleURLInHere/eb31ac/?login_id=48ea2b9a-4f1b-4bbb-b573-89524db025e9" (minus the quotes), the Chrome interface looked like this:
The last couple of days, a lot of readers sent us links to articles proclaiming yet another new flaw in DNS. "Critical Vulnerability in BIND Software Puts DNS Protocol Security At Risk"  claimed one article, going forward to state: "The students have found a way to compel DNS servers to connect with a specific server controlled by the attacker that could respond with a false IP address. â
So how bad is this really?
First of all, here is a the "TL;DR;" version of the vulnerability:
A domain usually uses several authoritative DNS servers. A recursive DNS server resolving a domain will pick a "random" authoritative DNS server for this particular domain. The real question is: How random? Actually as it turns out, it isn't random at all, and this is a features. BIND attempts to use the fastest name server, and has a special algorithm ( Smoothed Round Trip Time or SSRT algorithm) to figure out which server to use.
The vulnerability found here allows an attacker to influence the SSRT values in order to direct the name server to use a specific authoritative name server for a domain.
So the result is that the attacker can determine which authoritative name server is being used. BUT it has to be among the set of valid authoritative name servers. The attacker can not redirect the queries to an arbitrary name server of the attackers choosing.
So how does this make DNS spoofing easier?
The attacker has to guess three variables in order to spoof a DNS response:
By pinning the name server IP, the attacker will only gain a marginal advantage. The issue may be more of a problem if one of the servers is compromised. But in this case, DNS spoofing isn't really your #1 priority.
Without DNSSEC, DNS spoofing is certainly possible, and this attacks makes it a bit more likely. But this attack is hardly a game changer and only provides a minor advantage to the attacker.
What should you do?
Relax... finish your coffee... read up on DNSSEC and apply BIND patches as they become available (because it is always good to patch.)
Also the original presentation/paper is available as well and a lot better then some of the news reports covering it.
How hard is it to implement DNSSEC? It isn't trivial, but more recent versions of BIND make it a lot easier by automating some of the re-signing tasks. It is easiest if your registrar supports it and you host your zones with them. For example the registrar I host a couple of my domains with automates the entire process for about $5/year.
We also had another recent article covering some new DNS spoofing techniques:
Posted by InfoSec News on May 07http://arstechnica.com/information-technology/2014/05/why-he-hacked-university-of-maryland-contractor-turned-hacker-tells-all/
Posted by InfoSec News on May 07http://www.wantchinatimes.com/news-subclass-cnt.aspx?id=20140506000060&cid=1103&utm_content=buffer44f85
Posted by InfoSec News on May 07http://www.networkworld.com/news/2014/050614-fireeye-buying-npulse-281356.html
Posted by InfoSec News on May 07http://www.canada.com/news/Colombian+authorities+arrest+purported+hacker+allegedly+trying/9812951/story.html
Posted by InfoSec News on May 07http://www.theregister.co.uk/2014/05/06/mandia_infosec_interview/