STE WILLIAMS

New Apple iPhone 5s to feature “Touch ID” fingerprint authentication

After months of speculation, Apple has unveiled the latest iteration of its iPhones, with the usual fanfare and drama from Apple, and obsessive queuing from fans.

Catching most headlines have been the usual details of improved camera and battery life, and the availability of an “affordable” model, the 5c, a plastic affair in a wide range of colours. The main metal model will offer only gold, silver or grey.

Of most interest from a security viewpoint is a fingerprint-based authentication system in the top-of-the-line 5s, referred to as “Touch ID”.

The authentication system, based on a new material for the home button and a metal sensor ring around it, has been the subject of numerous rumours and leaked photos and specs already.

Speculation about Apple’s interest in fingerprints goes back at least as far as 2009, resurfaces each time a new version of the iPhone is launched, and has grown steadily ever since Apple’s pricey acquisiton of fingerprint tech firm AuthenTec last summer.

Today’s confirmation at the iPhone 5s/5c launch ceremony makes it all official at last.

According to Apple’s promotional material, the sensor:

uses advanced capacative touch to take, in essence, a high-resolution image of your fingerprint from the sub-epidermal layers of your skin. It then intelligently analyses this information with a remarkable degree of detail and precision.

As well as unlocking the phone, the sensor will be able to approve purchases at the Apple store.

Fingerprint authentication has been a common sight in laptops for some time, with major vendors including Dell, Lenovo and Toshiba pushing their own built-in variations, usually available as an option alongside more traditional login methods.

There are also a range of other implementations available, including many smartphone apps and external readers supported by the Windows Biometric Framework and some leading password managers.

Fingerprints thus probably rank a little above facial recognition as the most widely-deployed biometric authentication technique at the moment.

In the past, however, they have proven rather unreliable, plagued with security worries, although suspected flaws are not always proven. Nevertheless, many fingerprint scanners seem to be open to spoofing.

Fingerprints are not secret: we leave copies of them wherever we go, even if we’re trying hard not to, as cop show afficionados will be well aware.

Once someone devious has got hold of a copy, purely visual sensors can be fooled by photographs, while more sophisticated techniques which measure textures, temperatures and even pulses are still open to cheating using flesh-like materials, or even gelatin snacks.

Just how hard it will be to defeat Apple’s recognition system remains to be seen, but as crypto guru Bruce Schneier has pointed out, there’s a big danger in using fingerprints to access online services: the temptation to store the fingerprint info in a central database.

Unlike passwords, of course, if your fingerprint data is lifted from a hacked database, you can’t simply change it, short of getting mediaeval on your hands with acid, sandpaper or some other hardened-gangster technique.

So, as expected, Apple has opted to keep all information local to the iPhone – indeed, it is apparently kept in a “secure enclave” on the new A7 chip and can only be accessed by the print sensor itself.

Expect this storage area and the connections to it to become the subject of frenzied investigations by hackers of all persuasions.

Of course, Apple is not alone in looking into fingerprints, with arch-rivals Samsung also rumoured to be making moves in that direction. (Samsung was a major customer of AuthenTec before it was acquired.)

In the long term, how similar their approaches are may be a significant issue for all of us, whatever our smartphone affiliation and whether or not we worry much about privacy, and not just thanks to the inevitable legal rumpus.

There are two basic approaches to security: either the way things work is kept proprietary and secret, as far as possible, or it’s made open for general consumption, and more importantly for verification.

A cross-vertical group, the FIDO Alliance, was set up earlier this year to develop open specifications for biometric authentication standards, with members including Google, PayPal, hardware makers like Lenovo and LG, and a raft of biometrics and authentication specialists. Beleaguered phonemaker BlackBerry is the latest big-name inductee.

The alliance’s aim, to create a universal approach to implementing biometrics in combination with existing passwords and two-factor dongles, is a noble goal.

Sadly, given Apple’s history of playing well with others, it’s pretty likely that, as with their connector cables and DRM systems, their fingerprint setup will remain aloof from any attempts to build a truly universal consensus.

Even if a two-culture system prevails, widespread deployment in mass-market handhelds may well be a gamechanger for the adoption of biometric authentication. Touch ID and its inevitable followers could be a major part of all our futures.


Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/5V4x4PFGG8E/

Rudest man in Linuxdom rants about randomness – “We actually know what we are doing. You don’t.”

Linus Torvalds is a very clever man – he invented Linux, after all – but he seems to struggle with simple human decency.

(He recently expressed the wish that the designers of some hardware he doesn’t like might “die in some incredibly painful accident“, and invited you to puncture the brake lines on their car as a way to make it so.)

So it’s hardly surprising that when he heard a cryptographic suggestion he thought was silly, he let rip like this:

Where do I start a petition to raise the IQ and kernel knowledge of people? Guys, go read drivers/char/random.c. Then, learn about cryptography. Finally, come back here and admit to the world that you were wrong. Short answer: we actually know what we are doing. You don’t. Long answer: we use RDRAND as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if RDRAND were to be back-doored by the NSA, our use of RDRAND actually improves the quality of the random numbers you get from /dev/random. Really short answer: you’re ignorant.

That’s right – yet more “NSA cracked my crypto” conspiracy, and this time, the rudest man in Linuxdom is in the thick of it!

Interestingly, there are some useful lessons to be learned here – and they’re more about how to deal will technical issues well than they are about surveillance or digital snooping.

So, at the risk of receiving a Royal Rant from Torvalds himself (me for writing this, and you for reading it), let me explain.

Linux has a special file called /dev/random that doesn’t exist as a real file.

If you open it in a program, and read from it, you get a stream of pseudorandom numbers, generated right inside in the kernel, and – it is hoped – of very high quality.

That means no bias (the next bit is always zero with a probability of 50%), no predictability (even if you have a detailed history of recent outputs), and no repeatability (you can’t trick the system into giving the same sequence twice).

The way this works, very loosely speaking, is that the kernel continually sucks in pseudorandom data from various hard-to-predict sources – how much did the mouse move last time? how quickly did you type? how much time elapsed between two hardware events? – and stirs it all together into a bucket of digital slurry.

Along the way, the pseudorandom inputs are each shovelled through a non-cryptographic hash function to hasten the slurrification.

An estimate is kept – expressed in bits – of the amount of randomness that has been mixed in so far.

When you need random numbers, some of the slurry is fed into a cryptographic hash function in order to extract a pseudorandom bitstream from it.

The amount of randomness extracted is never allowed to exceed the amount currently swilling around in the sludge-bucket: if necessary, your reads from /dev/random are slowed down until the bucket fills up again.

This stops an attacker diluting the sludginess of /dev/random simply by reading wastefully from it until the metaphorical water runs clear.

The question, in the light of recent implications that the NSA has tainted the cryptographic sanctity of everything it could get its tentacles into or onto, is whether it is acceptable for the Linux kernel to use random numbers generated by the CPU itself as part of its official pseudorandom stream.

After all, modern Intel CPUs have an instruction called RDRAND which is supposed to use thermal noise, generally considered an unpredictable byproduct of the fabric of physics itself, to generate high quality random numbers very swiftly.

Sounds like just the ticket, but what if Intel tainted RDRAND, by order of the NSA?

Linus’s school of thought, which is entirely understandable, is that mixing a tainted data stream with a pseudorandom one can’t reduce randomness: even if you stir your bucket of sludge in a really careful and ordered fashion, you still end up with sludge.

(I’m not sure I agree with Linus that mixing in a known-tainted RDRAND stream would nevertheless invariably improve randomness, but on the surface, it shouldn’t reduce it.)

Of course, you can counter that claim – and some concerned digerati have done just that – by postulating an actively hostile RDRAND instruction.

This RDRAND migh monitor the state of the rest of the CPU in order to produce “random” data that is specially matched to the existing contents of the sludge-bucket so as to cancel out some of its randomness.

But how likely is that, given the cryptographic and non-cryptographic hash-churning that goes on inside the Linux kernel to stir in new pseudorandom input?

Can you “cancel out” randomess under those circumstances?

How much of the state of the CPU, and even the computer as a whole, would the tainted RDRAND instruction have to track in order to produce a real time active cancellation stream that could predictably tweak the overall output of /dev/random?

Well, here’s the thing.

If you take Linus’s advice, and go read drivers/char/random.c, as an interested spectator called Taylor Hornby did, you won’t find quite the clarity that the rant-master seems to suggest.

For example, the core function get_random_bytes() says that it “does not use the hw random number generator” (which would handily render this whole discussion moot), yet calls a function which does just that:

Furthermore, the hardware-generated random data that the algorithm does not use is consumed after the non-cryptographic and the cryptographic hash-churning described above.

The RDRAND data is merely XORed into the already-hashed output of the random number generator as the last step of the process.

In theory, then, a hostile RDRAND instruction wouldn’t need to keep track of much CPU state at all, since you can cancel out an XOR merely by repeating it. (X XOR X = 0; X XOR 0 = X; and so Y XOR X XOR X = Y.)

As Taylor Hornby notes, in a mock dialogue amusingly modelled on Galileo’s Dialogue Concerning the Two Chief World Systems:

Ironically, the random.c source code suggests that a tainted source of randomess is a problem – even at the stage when the bucket of sludge is still being filled, let alone after it has been drained – when it says:

So, if I were King, what would I do to sort this out?

  • I’d order my subjects to stop worrying about a tainted RDRAND, at least for now, and concentrate on all the other problems in my Kingdom, such as IE 6, browser Java, unencrypted USB keys, XP’s forthcoming funeral, and sources of randomness that really are broken.
  • I’d have some King’s Messengers fix the comments in random.c so that they matched the code, like good documentation should.
  • I’d fold in the data from RDRAND earlier in the process, along with all the other sources of entropy, so that no-one would need to answer the question, “Who asked you to leave RDRAND until an XOR right at the very end?”
  • I’d sentence Mr Torvalds to 200 hours of community service in a hospital orthopaedic ward, helping those who can’t help themselves because of serious injuries sustained in automobile accidents.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/YHdd87Al9SY/

Microsoft delivers baker’s dozen of patches on Tuesday

Supercharge your infrastructure

Another month, another Patch Tuesday from Microsoft, but this month’s bundle has come up one short from the 14 promised patches last week.

“We are committed to delivering high-quality security updates for our customers and extensively test each bulletin prior to release,” Dustin Childs, group manager at Microsoft Trustworthy Computing told El Reg in a statement. “During some additional testing after advance notification, we determined one of the updates was not quite ready.


“We have not detected any attacks against this issue, or any of the others addressed today, and we’ll continue to work on the bulletin and release it once it is ready, through our regular bulletin release process.”

Sources say the missing patch is a .NET fix that wasn’t quite up to snuff, and that it should be ready by the next patching round in October.

As for the 13 patches that are out, Microsoft rates four as critical, affecting Windows, Internet Explorer, Outlook, and SharePoint. In the latter case, the patch fixes 10 flaws in SharePoint going all the way back to the 2003 code base.

The remaining nine are all rated as important and block remote code execution, escalation of privileges, covert information gathering, and a denial of service flaw in Active Directory that can crash systems using a malicious LDAP query.

Systems administrators are (unsurprisingly) advised to patch the critical flaws first, but be warned that reboots will be required. ®

Supercharge your infrastructure

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2013/09/11/microsoft_delivers_bakers_dozen_of_patches_on_tuesday/

NIST denies it weakened its encryption standard to please the NSA

Supercharge your infrastructure

The US National Institute of Standards and Technology (NIST) has vehemently denied accusations that it deliberately weakened encryption standards to help the NSA’s monitoring activities.

“We want to assure the IT cybersecurity community that the transparent, public process used to rigorously vet our standards is still in place,” said NIST in a statement.


“NIST would not deliberately weaken a cryptographic standard. We will continue in our mission to work with the cryptographic community to create the strongest possible encryption standards for the U.S. government and industry at large.”

According to a memo released by NSA whistleblower Edward Snowden, the intelligence agency’s budget included efforts to “influence policies, standards and specifications for commercial public key technologies”. In particular, NIST Special Publication 800-90 was referenced, a 2006 encryption standard adopted by NIST which uses four deterministic random bit generators.

One of these generators, Dual_EC_DRBG, is based on finding the discrete logarithms of elliptic curves and attracted attention almost immediately, not least because it was considerably slower than the other three methods and was specifically championed by the NSA.

A year after its publication, two Microsoft researchers – Dan Shumow and Niels Ferguson – gave a presentation at the CRYPTO 2007 conference which suggested that Dual_EC_DRBG was crackable. They were careful not to accuse the NSA of deliberately inserting a backdoor into the system, but noted that it was potentially unsafe.

In Tuesday’s statement, NIST said that working with the NSA was standard operating procedure; indeed it was required by law to consult with the NSA on security matters. To reassure users, NIST has reopened the standard to public comment so that it can be checked, but cryptography expert Bruce Schneier, who has examined some of Snowden’s material on the matter, warned that this won’t be good enough.

“NIST took a big credibility hit unfortunately,” he said in a podcast. “There are good people there doing good work but we don’t know which of their standards are tainted, we don’t know how much collaboration there is with the NSA.

“And unfortunately because trust is lost when they get up and say the NSA doesn’t affect our standards we don’t believe them. We need a way to get back trust.”

Schneier likened the situation to betraying a spouse, saying that in that kind of situation the only way to get trust back is by full disclosure. “You can’t say ‘here’s most of the things I did and you may find out some more in a few months’ – those sort of strategies never work.” ®

Supercharge your infrastructure

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2013/09/11/nist_denies_that_the_nsa_weakened_its_encryption_standard/

ThreatSim To Offer Free Campaign Subscriptions To New Customers This October in Recognition, Support Of National Cybersecurity Awareness Month

HERNDON, VA, Sep 04, 2013 (Marketwired via COMTEX) — ThreatSim, a leading innovator of simulated phishing defense training and awareness solutions, today announced it will offer new customers an entire month of free phishing training this October in support and recognition of National Cybersecurity Awareness Month.

Celebrated every October, National Cybersecurity Awareness Month was created as a collaborative effort between government and industry to ensure every American has the resources they need to stay safer and more secure online. Since its inception a decade ago under leadership from the U.S. Department of Homeland Security and the National Cyber Security Alliance, NCSAM has grown exponentially, reaching consumers, small and medium-size businesses, corporations, educational institutions, and young people across the nation.

“We share in the mission and vision of National Cybersecurity Awareness Month and are pleased to extend a free month subscription in October to any new customers looking to accelerate awareness and get their organization’s employees trained so the network and other mission-critical assets stay protected,” said ThreatSim Co-Founder and CEO Jeff LoSapio.

New customers participating in the ThreatSim free month subscription will be able to send simulated phishing e-mails to their employees using ThreatSim-designed templates or their own. Any employee falling for the phish is presented automatically with ThreatSim’s SpearTraining(TM) messages equipped with tips on how to tell phishing messages from authentic e-mail messages.

ThreatSim customers, including a top five U.S. bank, a top three U.S. utility and one of the largest government defense contractors, have achieved up to an 80% reduction in the rate of employees who click on phishing e-mail messages. Available in 11 languages and country themes, ThreatSim simulations are extremely realistic, coupled with effective training content that equips employees on how to identify and avoid phishing attacks. ThreatSim is a secure hosted service that requires no installation or configuration.

About ThreatSim

ThreatSim is a leading innovator of simulated phishing defense training and awareness solutions. Headquartered in Herndon, Va., outside Washington, D.C., ThreatSim delivers highly-scalable, feature-rich, SaaS-based phishing and advanced threat training campaigns that measurably lower organizational risk exposure. ThreatSim customers include large commercial enterprises, SMBs, government organizations and academic institutions. Request a demo, visit www.threatsim.com and follow @ThreatSim.

Article source: http://www.darkreading.com/applications/threatsim-to-offer-free-campaign-subscri/240161155

How The Massive Tor Botnet ‘Failed’

The decision by the operators of the so-called Medvade botnet to use the Tor network for masking their command-and-control (CC) infrastructure actually backfired.

The botnet, which had been in operation since at least 2009, began moving its infrastructure en masse to Tor in mid-August, just after the start of the Edward Snowden leaks about the NSA’s widespread spying operations and unrest in Syria. Millions of new Tor clients sparked speculation of a post-NSA anonymity bump or Syrian civil war fallout. But last week, The Tor Project confirmed that the major uptick in Tor traffic was due to a botnet.

[Turns out the massive jump in millions of new Tor clients during the past month wasn’t about the NSA, Syria, or Tor-based Pirate Bay bundles — it was pure cybercrime. See Botnet Behind Mysterious Spike In Tor Traffic .]

It was a big botnet even before going to Tor — Damballa Security says there were anywhere from 1.4 to 5 million infected machines in the botnet, which it initially dubbed “LazyAlienBikers.” The botnet is made up of infected machines in North America, Asia, and Africa, and encompasses mobile and nonmobile devices, according to the researchers, who saw infections hit more than 80 percent of enterprises it monitors.

Still unclear is just how Medvade or LazyAlienBikers initially infects machines. “One thing we are trying to identify is the infection vector,” says Manos Antonakakis, chief scientist with Damballa.

Mark Gilbert, Antonakakis’ colleague at Damballa, says the gang behind the botnet made a fatal error when it moved to Tor from SSH over Port 443. The uptick in Tor adoption only attracted unwanted attention when the group was looking for a way to hide its CC traffic.

“In the security arms race, sometimes the bad guys screw up too. But you can be sure they’ve taken the lessons learned from this progression, and will continue to find new ways to remain more elusive going forward,” says security researcher Gilbert in a post today.

“As the bot-herder, you can hide your control infrastructure at the expense of making your presence on an endpoint more obvious, and go with Tor (or freenet/i2p), which shifts attention from destination to source and may not work out in your favor,” he said. “In this case, we watched a massive botnet go virtually undetected for months by the security community at large until the owner decided to switch over to Tor.”

Yanathan Klijnsma, a cybercrime security specialist with Fox-IT, which also has been tracking the botnet, concurs that the move to Tor had the reverse effect on the botnet. “It is smart as in it will be harder to detect what type of malware it is in a network analyst point of view. But these guys have been running this botnet supposedly since 2009 … they haven’t got caught up till now, but the switch to ‘anonymity’ did get noticed,” he says. “Tor traffic is easily detected on the network, so it becomes quite obvious that something is acting up inside the network. And the Tor metrics page was a good indicator.”

The Tor Project late last week began updating the Tor browser and beta Tor Browser Bundles to help ease the traffic increase on the Tor network due to the botnet. Tor’s operators have urged relay operators to upgrade: “Relay operators are strongly encouraged to upgrade to the latest versions, since it mostly has server-side improvements in it, but users will hopefully benefit from upgrading too. Please try it out and let us know,” The Tor Project’s Erinn Clark said a blog post.

Damballa, meantime, has been tracking 27 regular- and 69 dynamic-DNS domain names of the botnet, and recently tracked an infection at a Fortune 500 global manufacturing and technology customer site (PDF), where it detected the botnet exfiltrating megabytes per day of data from some endpoints.

The security firm is still researching the botnet operation to determine its mission, but Trend Micro says it appears to be conducting online ad fraud. The malware also comes with a backdoor and uses SSH to communicate with its hosts, so data-stealing is also a possible element of the attack, according to researchers at Trend Micro.

Researchers at Trend Micro spotted Medvade downloading a Tor module in August and early September, which provides stealthy cover for CC servers, and makes taking down a Tor-based service nearly impossible, experts say. But the bad guys behind the botnet weren’t so stealthy when it came to hiding themselves: “They operate from Kharkov, Ukraine and Israel and have been active since at least 2010. One of the main actors is known as ‘Scorpion.’ Another actor uses the nickname ‘Dekadent.’ Together, they are part of a well organized and probably well financed cybercrime gang” associated with adware scams and search result-hijacking, notes Feike Hacquebord, senior threat researcher with Trend Micro in a blog post.

Meanwhile, The Tor Project today also addressed questions raised by researchers about whether the NSA or U.K.’s spy agency have been able to crack Tor’s encryption. “It’s not clear what the NSA or GCHQ can or cannot do. It’s not clear if they are ‘cracking’ the various crypto used in Tor, or merely tracking Tor exit relays, Tor relays as a whole, or run their own private Tor network,” The Tor Project’s Phobos said in a blog post. “What we do know is that if someone can watch the entire Internet all at once, they can watch traffic enter Tor and exit Tor. This likely de-anonymizes the Tor user.”

More than likely, though, is that the spy agencies have “Tor flow detector scripts that let them pick Tor flows out of a set of flows they’re looking at,” Phobos says. “It’s unlikely to have anything to do with deanonymizing Tor users, except insofar as they might have traffic flows from both sides of the circuit in their database. However, without concrete details, we can only speculate as well. We’d rather spend our time developing Tor and conducting research to make a better Tor.”

Have a comment on this story? Please click “Add Your Comment” below. If you’d like to contact Dark Reading’s editors directly, send us a message.

Article source: http://www.darkreading.com/attacks-breaches/how-the-massive-tor-botnet-failed/240161160

Kaspersky Reports: APT Attacks Against South Korean Think-Tanks

Woburn, MA – September 11–Today Kaspersky Lab’s security research team published a report that analyzes an active cyber-espionage campaign primarily targeting South Korean think-tanks.

This campaign, named Kimsuky, is limited and highly targeted. According to technical analysis, attackers were interested in targeting 11 organizations based in South Korea and two entities in China including the Sejong Institute, Korea Institute For Defense Analyses (KIDA), South Korea’s Ministry of Unification, Hyundai Merchant Marine and The supporters of Korean Unification.

The earliest signs of this threat actor’s activity date back to the 3rd of April 2013, and the first Kimsuky Trojan samples appeared on the 5th of May 2013. This unsophisticated spy program includes several basic coding errors and handles communications to and from infected machines via a Bulgarian web based free e-mail server (mail.bg).

Although the initial delivery mechanism remains unknown, Kaspersky researchers believe the Kimsuky malware is most likely delivered via spear-phishing e-mails and has the ability to perform the following espionage functions: keystroke logging, directory listing collection, remote control access and HWP document theft (related to the South Korean word processing application from the Hancom Office bundle, extensively used by the local government). The attackers are using a modified version of the TeamViewer remote access application to serve as a backdoor to hijack any files from the infected machines.

The Kimsuky malware contains a dedicated malicious program designed for stealing HWP files, which suggests that these documents are one of main objectives of the group.

Clues found by Kaspersky Lab’s experts make it possible to surmise the North Korean origin of the attackers. First of all, profiles of the targets speak for themselves – South Korean universities conducting research on international affairs and producing defense policies for government, a national shipping company, and support groups for Korean unification.

Secondly – a compilation path string containing Korean words (for example, some of them could be translated as English commands “attack” and “completion”).

Third – two email addresses to which bots send reports on status and transmit infected system information via attachments – [email protected] and [email protected] – are registered with the following “kim” names: “kimsukyang” and “Kim asdfa”. Even though this registration data does not provide hard data about the attackers, the source IP-addresses of the attackers fit the profile: there are 10 originating IP-addresses, and all of them lie in ranges of the Jilin Province Network and Liaoning Province Network in China. The ISPs providing Internet access in these provinces are also believed to maintain lines into parts of North Korea.

Another interesting “geo-political” feature of Kimsuky malware is that it only disables security tools from AhnLab, a South Korean anti-malware company.

Kaspersky Lab’s products detect and neutralize these threats as Trojan.Win32.Kimsuky, and modified TeamViewer client components are detected as Trojan.Win32.Patched.ps.

Article source: http://www.darkreading.com/attacks-breaches/kaspersky-reports-apt-attacks-against-so/240161162

Google loses appeal in Wi-Fi data grab case

Google court ruling. Image courtesy of ShutterstockA US appeals court has upheld a previous decision from a district court that ruled Google violated wiretap laws when it collected personal data from unencrypted Wi-Fi networks in 2010.

The 9th US Circuit Court of Appeals ruled Google to be liable under the US Federal Wiretap Act after the company sucked up sensitive information such as user passwords and entire emails from home wireless broadband networks.

This issue goes back to 2010 when, as a part of its Street View program in the US and Europe, Google sent Wi-Fi sniffing vehicles out to gather data for their mapping tool.

“It’s a landmark decision that affirms the privacy of electronic communications for wireless networks,” said Marc Rotenberg, executive director of the Electronic Privacy Information Center in Washington, D.C., in a report by Reuters.

“Many internet users depend on wireless networks to connect devices in their homes, such as printers and laptops, and companies should not be snooping on their communications or collecting private data.”

Google’s lawyers had argued that the company’s collection of personal data should fall under an exemption to the Wiretap Act which makes it lawful to intercept radio communications if they are readily accessible to the general public and not scrambled or otherwise encrypted.

The three appeals court judges, however, held that Google’s first assertion was far too broad with the company having claimed that anything transmitted in the range of 3 kilohertz to 300 gigahertz was a radio communication and hence exempt. (Such a range of frequencies encompasses television broadcasts, Bluetooth communications, telephones and a multitude of other devices.)

Circuit Judge Jay Bybee wrote:

Under the expansive definition of ‘radio communication’ proposed by Google, the protections afforded by the Wiretap Act to many online communications would turn on whether the recipient of those communications decided to secure her wireless network.

Consider an e-mail attachment containing sensitive personal information sent from a secure Wi-Fi network to a doctor, lawyer, accountant, priest, or spouse. A company like Google that intercepts the contents of that e-mail from the encrypted home network has, quite understandably, violated the Wiretap Act.

In respect of the company’s second point about the Wi-Fi data being “readily accessible” to the general public, the judges also disagreed, saying:

Wi-Fi transmissions are not ‘readily accessible’ to the ‘general public’ because most of the general public lacks the expertise to intercept and decode payload data transmitted over a Wi-Fi network.

Even if it is commonplace for members of the general public to connect to a neighbor’s unencrypted Wi-Fi network, members of the general public do not typically mistakenly intercept, store, and decode data transmitted by other devices on the network.”

Google said it was “disappointed” with the decision and will consider its next steps.

Unsecured wireless. Image courtesy of ShutterstockThe internet search giant revealed this accidental collection of personal data back in May 2010, making a public apology at the time.

Since then the company has settled to the tune of $7 million with the District of Columbia and 37 US states over the unauthorised collection of Wi-Fi data.

Fines and investigations have followed in other countries too.

This latest ruling has far-reaching implications for anyone who grabs data over Wi-Fi without permission – whether intended or not – and may well be welcomed at a time when privacy erosion appears in the news with alarming regularity.

Also, for the millions of users who (ignorantly, in my opinion) use unencrypted Wi-Fi networks all around the world both in their homes and in cafes, coffee shops, restaurants and other locales it will, hopefully, serve as a reminder to reconsider the privacy aspect of such connections.

Image of gavel and unsecured Wi-Fi courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/visYsf6yub0/

John McAfee tweets from BEYOND THE GRAVE: Drug binge death? Not me, mate

Supercharge your infrastructure

Antivirus software wild man John McAfee has joined Queen Elizabeth II, the Queen Mother, Fidel Castro, and poet Samuel Taylor Coleridge in receiving a premature obituary.

Internet rumours that surfaced on Tuesday falsely claimed the self-described “eccentric millionaire” and entrepreneur had died at the Palms Casino Resort in Las Vegas as the “result of a suspected cocaine and alcohol fuelled binge”.


This, it turns out, was not the case.

McAfee himself surfaced to deny the rumours via his official Twitter account in a series of updates. “For those wondering if im dead the answer is…’The Media is killing me, but somehow im still tweeting’ #NotDeadYet,” he said in an update featuring pictures of him relaxing on a couch alongside two somewhat fearsome-looking dogs.

McAfee, who famously faked a heart attack while held in a Guatemala detention centre last December in order to avoid being deported back to Belize where he was wanted for questioning as a “person of interest” in the death of his neighbour, has been noticeably quiet of late. Guatemalan authorities, who arrested the tech mogul for entering the country illegally, eventually sent McAfee back to the US.

The antivirus pioneer has had no connection for many years with the security firm he founded, which is now owned by Intel. Back in June he played up to his wild man image by posting a tongue-in-cheek (and NSFW) video explaining how to uninstall the security software that still bears his name, by taking a handgun to a computer. The vid featured seven strippers and was seen as more of a joke by McAfee than a genuine dig at the antivirus industry, or the eponymous security software in particular. ®

Supercharge your infrastructure

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2013/09/11/rumours_john_mcafee_death_greatly_exaggerated/

Brazilian TV show accuses NSA of spying on oil firm based on leaked docs

Supercharge your infrastructure

Brazilian President Dilma Rousseff has said that if leaked NSA documents showing the US spied on her country’s state-run oil firm Petrobras are “confirmed”, then it must have done so for “economic and strategic” reasons rather than for “national security”.

The leaked “intelligence documents” appear to run counter to US claims it isn’t involved in industrial espionage.


The NSA told the Washington Post in an emailed statement late last month: “The Department of Defense does engage” in computer network exploitation,” adding: “The department does ***not*** engage in economic espionage in any domain, including cyber.”

However, Brazilian TV news programme Fantástico alleged that the NSA had monitored the internal network of Petrobras, the part-government-owned energy giant, based on leaked NSA reports it had seen.

Fantástico had obtained the documents from Glenn Greenwald, the journalist to whom NSA whistleblower Edward Snowden had revealed certain leaked documents.

The NSA internal documents feature Petrobras’s name as an example of targets of the Blackpearl programme, which extracts data from private networks.

Petrobras is named along with the Swift network for global bank transfers, the French foreign ministry and Google. Other targets include terrorist organisations, whose names were redacted, The Guardian adds.

The June 2012 documents provide few clues about the nature or extent of the alleged spying. Subjects of interest might include the upcoming multibillion-dollar auction for Campo de Libra, an oil field off the coast of São Paulo.

The US has complained vociferously for years about Chinese cyber-espionage against US defence contractors and multinationals. Energy giants are high up in the list of targets of this sort of cyber-malfeasance.

At least three US oil giants were reportedly hit by cyber-attacks aimed at stealing secrets back in 2008, in the months before the high-profile Operation Aurora attacks against Google. China was the prime suspect in the targeted malware-based attacks against against Marathon Oil, ConocoPhillips, and ExxonMobil that appeared to be targeting information about new energy discoveries.

The US government has said that its surveillance activities are about foreign policy and fighting terrorism and nothing to do with industrial or economic espionage.

The latest leak casts doubt on these assertions while providing useful fodder for China next time they are accused of breaking the unwritten rules of the Big Brother house.

Petrobas pushed out a statement (em Português) in response to the leaks, saying it follows industry best practice in securing its network. It denies voluntarily sharing information with the NSA.

This is likely to add fuel to the flames for Brazil’s President Dilma Rouseff, who threatened to cancel her October trip to the US last week over earlier reports leaked by Snowden alleging that the US agency had snooped on her phone calls and emails.

The NSA allegedly bugged the telephones and internet communications of Rousseff and her key staffers. ®

Supercharge your infrastructure

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2013/09/11/nsa_spying_petrobras_brasil/