Shellshock makes Heartbleed look insignificant

Somehow there always seems to be another Internet security disaster around the corner. A few months ago everyone was in a panic about Heartbleed.

Now the bug, Shellshock (officially CVE-2014-6271), a far more serious vulnerability, is running uncontrolled over the Internet. It’s never a good time to panic, but if you’re discouraged I don’t blame you; I know I am.

In retrospect, the grave concern over Heartbleed seems misplaced. As information disclosure bugs go it was a really bad one, but it was only an information disclosure bug and a difficult one to exploit. The sky’s the limit on attacks with Shellshock and it’s so easy to exploit that it’s already being widely-exploited according to research firm Fireeye, which says they have already observed several forms of attack:

• Malware droppers
• Reverse shells and backdoors
• Data exfiltration
• DDoS

Of course it’s not just Fireeye; everyone is reporting widespread sightings of exploits. See Kaspersky, Trend Micro, HP Security Research and many others.

Speaking of HP, their TippingPoint unit states that their network IPS has been updated to recognize known attacks using Shellshock. A vigorously updated IPS, deployed not just at the perimeter but also at critical points within the network, may be the only effective systemic protection you have against Shellshock for now. HP is not the only IPS around of course. And remember that an IPS is more of a protection against known exploits than against the vulnerability generally.

This particular bug has been in the Bash shell for over two decades. The implications of this are really bad. First, it means that an extremely important and popular program either went unscrutinized or poorly-scrutinized. Surely there are many other such problems out there. Don’t be surprised if several of them have been used carefully and surreptitiously for targeted attacks for years. In fact, don’t be surprised if Shellshock has been used in the past.

All sorts of horrible scenarios are possible with Shellshock. It’s not just limited to web server attacks. Fireeye shows how different Internet services, even DHCP and SSH, can be exploited to perform the attack, as long as Bash is the shell, and it usually is. They demonstrate automated click fraud, stealing the host password file, several DDOS attacks using the server and several ways to establish a shell on the server without any malware running on it.

For more information and the original article follow the source link below. 

Source: ZD Net

Android Browser flaw a “privacy disaster” for half of Android users

Bug enables malicious sites to grab cookies, passwords from other sites.

A bug quietly reported on September 1 appears to have grave implications for Android users. Android Browser, the open source, WebKit-based browser that used to be part of the Android Open Source Platform (AOSP), has a flaw that enables malicious sites to inject JavaScript into other sites. Those malicious JavaScripts can in turn read cookies and password fields, submit forms, grab keyboard input, or do practically anything else.

Browsers are generally designed to prevent a script from one site from being able to access content from another site. They do this by enforcing what is called the Same Origin Policy (SOP): scripts can only read or modify resources (such as the elements of a webpage) that come from the same origin as the script, where the origin is determined by the combination of scheme (which is to say, protocol, typically HTTP or HTTPS), domain, and port number.

The SOP should then prevent a script loaded from http://malware.bad/ from being able to access content at https://paypal.com/.

The Android Browser bug breaks the browser’s handling of the SOP. As Rafay Baloch, the researcher who discovered the problem found, JavaScript constructed in a particular way could ignore the SOP and freely meddle with other sites’ content without restriction.

This means that potentially any site visited in the browser could be stealing sensitive data. It’s a bug that needs fixing, and fast.

As part of its attempts to gain more control over Android, Google has discontinued the AOSP Browser. Android Browser used to be the default browser on Google, but this changed in Android 4.2, when Google switched to Chrome. The core parts of Android Browser were still used to power embedded Web view controls within applications, but even this changed in Android 4.4, when it switched to a Chromium-based browser engine.

But just as Microsoft’s end-of-life for Windows XP didn’t make that operating system magically disappear from the Web, Google’s discontinuation of the open source Browser app hasn’t made it disappear from the Web either. As our monthly look at Web browser usage shows, Android Browser has a little more real-world usage than Chrome for Android, with something like 40-50 percent of Android users using the flawed browser.

The Android Browser is likely to be embedded in third-party products, too, and some Android users have even installed it on their Android 4.4 phones because for one reason or another they prefer it to Chrome.

Google’s own numbers paint an even worse picture. According to the online advertising giant, only 24.5 percent of Android users are using version 4.4. The majority of Android users are using versions that include the broken component, and many of these users are using 4.1.x or below, so they’re not even using versions of Android that use Chrome as the default browser.

Baloch initially reported the bug to Google, but the company told him that it couldn’t reproduce the problem and closed his report. Since he wrote his blog post, a Metasploit module has been developed to enable the popular security testing framework to detect the problem, and Metasploit developers have branded the problem a “privacy disaster.” Baloch says that Google has subsequently changed its response, agreeing that it can reproduce the problem and saying that it is working on a suitable fix.

Just how this fix will be made useful is unclear. While Chrome is updated through the Play Store, the AOSP Browser is generally updated only through operating system updates. Timely availability of Android updates remains a sticking point for the operating system, so even if Google develops a fix, it may well be unavailable to those who actually need it.

Users of Android 4.0 and up can avoid much of the exposure by switching to Chrome, Firefox, or Opera, none of which should use the broken code. Other third-party browsers for Android may embed the broken AOSP code, and unfortunately for end users, there’s no good way to know if this is the case or not.

Update: Google has offered the following statement:

We have reviewed this report and Android users running Chrome as their browser, or those who are on Android 4.4+ are not affected. For earlier versions of Android, we have already released patches (1, 2) to AOSP.

Source: Ars Technica

This World Map Shows Every Device Connected To The Internet

A striking map created by John Matherly at search engine Shodan shows significant disparities in internet access across the world.

The graphic maps every device that’s directly connected to the internet. We first noticed it when geopolitical expert Ian Bremmer tweeted it.

Some of the dark spots on the map could be attributed to low population density in those areas, but by looking at the map it’s clear that internet access isn’t equal across the world.

The different colors indicate the density of devices — blue indicates fewer devices and red indicates more devices at a given location.

As you can see from the map, the US and Europe have very high levels of internet connectivity, with the exception of the less-populated areas of the western US. Africa is mostly an internet blackout, and Asia has much less internet connectivity than Europe and the US despite having very dense population centers in some areas.

Matherly told Business Insider how he put the map together (at least for a tech guy):

The way it was performed is fairly straightforward:

1. Use a stateless scanner to send a Ping request to every public IPv4 address

2. Keep track of which IPs responded with a Pong

3. Find out where the IP is physically located using a GeoIP library (i.e. translates from x.x.x.x -> latitude/ longitude)

4. Draw the map

Steps 1-3 took about 5 hours and the final step took 12 hours. This is possible because nowadays we have the technology (stateless scanning) to very efficiently talk to millions of devices on the Internet at once.

Source: Business Insider

Which Smartwatch are you most looking forward to?

Samsung Gear S

Are you going to be one that jumps in on the Smartwatch craze? If so choice one of the below watches you are most looking forward to as they are all soon to release. Or if you already have a Smartwatch go ahead and put it down.

Asus Zenwatch

LG G Watch R

Apple Watch

Offline attack shows Wi-Fi routers still vulnerable

An attack can break into some common Wi-Fi routers, via a configuration feature.

A researcher has refined an attack on wireless routers with poorly implemented versions of the Wi-Fi Protected Setup that allows someone to quickly gain access to a router’s network.

The attack exploits weak randomization, or the lack of randomization, in a key used to authenticate hardware PINs on some implementations of Wi-Fi Protected Setup, allowing anyone to quickly collect enough information to guess the PIN using offline calculations. By calculating the correct PIN, rather than attempting to brute-force guess the numerical password, the new attack circumvents defenses instituted by companies.

While previous attacks require up to 11,000 guesses—a relatively small number—and approximately four hours to find the correct PIN to access the router’s WPS functionality, the new attack only requires a single guess and a series of offline calculations, according to Dominique Bongard, reverse engineer and founder of 0xcite, a Swiss security firm.

“It takes one second,” he said. “It’s nothing. Bang. Done.”

The problem affects the implementations provided by two chipset manufacturers, Broadcom and a second vendor whom Bongard asked not to be named until they have had a chance to remediate the problem. Broadcom did not provide a comment to Ars.

Because many router manufacturers use the reference software implementation as the basis for their customized router software, the problems affected the final products, Bongard said. Broadcom’s reference implementation had poor randomization, while the second vendor used a special seed, or nonce, of zero, essentially eliminating any randomness.

The Wi-Fi Alliance could not confirm whether the products impacted by the attack were certified, according to spokeswoman Carol Carrubba.

“A vendor implementation that improperly generates random numbers is more susceptible to attack, and it appears as though this is the case with at least two devices,” she said in a statement. “It is likely that the issue lies in the specific vendor implementations rather than the technology itself. As the published research does not identify specific products, we do not know whether any Wi-Fi certified devices are affected, and we are unable to confirm the findings.”

The research, originally demonstrated at the PasswordsCon Las Vegas 2014 conference in early August, builds on previous work published by Stefan Viehböck in late 2011. Viehböck found a number of design flaws in Wi-Fi Protected Setup, but most significantly, he found that the PIN needed to complete the setup of a wireless router could be broken into smaller parts and each part attacked separately. By breaking down the key, the number of attempts an attacker would have to try before finding the key shrunk from an untenable 100 million down to a paltry 11,000—a significant flaw for any access-control technology.

Viehböck was not the only researcher to notice the flaws in the technology. Independently, Craig Heffner of Tactical Network Solutions discovered the issue and created a tool, Reaver, to use brute-force guessing of all 11,000 combinations to find the PIN. Ars Technica used the tool to confirm the original issue.

Bongard’s updated attack exploits the lack of randomization in the nonce, a number used to create the pseudo-random inputs to calculate the keys.

For more information follow the source link below.

Source: Ars Technica