Friday, March 30. 2012
EU Votes To Lower Mobile Roaming Charges
Wednesday, March 28. 2012
Anatomy of a leak: how iPhones spill the ID of networks they access
Via ars technica
-----
An Ars story from earlier this month reported that iPhones expose the unique identifiers of recently accessed wireless routers, which generated no shortage of reader outrage. What possible justification does Apple have for building this leakage capability into its entire line of wireless products when smartphones, laptops, and tablets from competitors don't? And how is it that Google, Wigle.net, and others get away with publishing the MAC addresses of millions of wireless access devices and their precise geographic location?
Some readers wanted more technical detail about the exposure, which applies to three access points the devices have most recently connected to. Some went as far as to challenge the validity of security researcher Mark Wuergler's findings. "Until I see the code running or at least a youtube I don't believe this guy has the goods," one Ars commenter wrote.
According to penetration tester Robert Graham, the findings are legit.
In the service of our readers, and to demonstrate to skeptics that the privacy leak is real, Ars approached Graham and asked him to review the article for accuracy and independently confirm or debunk Wuergler's findings.
"I can confirm all the technical details of this 'hack,'" Graham, who is CEO of Errata Security, told Ars via e-mail. "Apple products do indeed send out three packets that will reveal your home router MAC address. I confirmed this with my latest iPad 3."
He provided the image at the top of this post as proof. It shows a screen from Wireshark, a popular packet-sniffing program, as his iPad connected to a public hotspot at a Starbucks in Atlanta. Milliseconds after it connected to an SSID named "attwifi" (as shown in the section labeled #1), the iPad broadcasted the MAC address of his Linksys home router (shown in the section labeled #2). In section #3, the iPad sent the MAC address of this router a second time, and curiously, the identifier was routed to this access point even though it's not available on the local network. As is clear in section #4, the iPad also exposed the local IP address the iPad used when accessing Graham's home router. All of this information is relatively simple to view by anyone within radio range.
The image is consistent with one provided by Wuergler below. Just as Wuergler first claimed, it shows an iPhone disclosing the last three access points it has connected to.
Graham used Wireshark to monitor the same Starbucks hotspot when he connected with his Windows 7 laptop and Android-based Kindle Fire. Neither device exposed any previously connected MAC addresses. He also reviewed hundreds of other non-Apple devices as they connected to the network, and none of them exposed previously accessed addresses, either.
As the data makes clear, the MAC addresses were exposed in ARP (address resolution protocol) packets immediately after Graham's iPad associated with the access point but prior to it receiving an IP address from the router's DHCP server. Both Graham and Wuergler speculate that Apple engineers intentionally built this behavior into their products as a way of speeding up the process of reconnecting to access points, particularly those in corporate environments. Rather than waiting for a DHCP server to issue an IP address, the exposure of the MAC addresses allows the devices to use the same address it was assigned last time.
"This whole thing is related to DHCP and autoconfiguration (for speed and less traffic on the wire)," Wuergler told Ars. "The Apple devices want to determine if they are on a network that they have previously connected to and they send unicast ARPs out on the network in order to do this."
Indeed, strikingly similar behavior was described in RFC 4436, a 2006 technical memo co-written by developers from Apple, Microsoft, and Sun Microsystems. It discusses a method for detecting network attachment in IPv4-based systems.
"In this case, the host may determine whether it has re-attached to the logical link where this address is valid for use, by sending a unicast ARP Request packet to a router previously known for that link (or, in the case of a link with more than one router, by sending one or more unicast ARP Request packets to one or more of those routers)," the document states at one point. "The ARP Request MUST use the host MAC address as the source, and the test node MAC address as the destination," it says elsewhere.
Of course, only Apple engineers can say for sure if the MAC disclosure is intentional, and representatives with the company have declined to discuss the issue with Ars. What's more, if RFC 4436 is the reason for the behavior, it's unclear why there's no evidence of Windows and Android devices doing the same thing. If detecting previously connected networks is such a good idea, wouldn't Microsoft and Google want to design their devices to do it, too?
In contrast to the findings of Graham and Wuergler were those of Ars writer Peter Bright, who observed different behavior when his iPod touch connected to a wireless network. While the Apple device did expose a MAC address, the unique identifier belonged to the Ethernet interface of his router rather than the MAC address of the router's WiFi interface, which is the identifier cataloged by Google, Skyhook, and similar databases.
Bright speculated that many corporate networks likely behave the same way. And for Apple devices that connect to access points with such configurations, exposure of the MAC address may pose less of a threat. Still, while it's unclear what percentage of wireless routers assign a different MAC address to wired and wireless interfaces, Graham and Wuergler's tests show that at least some wireless routers by default make no such distinction.
Wuergler also debunked a few other misconceptions that some people had about the wireless behavior of Apple devices. Specifically, he said claims that iPhones don't broadcast the SSID they are looking for from Errata Security's Graham are incorrect. Some Ars readers had invoked the 2010 blog post from Graham to cast doubt on Wuergler's findings
"The truth is Apple products do probe for known SSIDs (and no, there is no limit as to how many)," Wuergler wrote in a post published on Friday to the Daily Dave mailing list. He included the following screenshot to document his claim.
Connecting the dots
What all of this means is that there's good reason to believe that iPhones and other Apple products—at least when compared to devices running Windows or Android—are unique in leaking MAC addresses that can uniquely identify the locations of networks you've connected to recently. When combined with other data often exposed by virtually all wireless devices—specifically the names of wireless networks you've connected to in the past—an attacker in close proximity of you can harvest this information and use it in targeted attacks.
Over the past year or so, Google and Skyhook have taken steps to make it harder for snoops to abuse the GPS information stored in their databases. Google Location Services, for instance, now requires the submission of two MAC addresses in close proximity of each other before it will divulge where they are located. In many cases, this requirement can be satisfied simply by providing one of the other MAC addresses returned by the Apple device. If it's within a few blocks of the first one, Google will readily provide the data. It's also feasible for attackers to use war dialing techniques to map the MAC addresses of wireless devices in a given neighborhood or city.
Since Apple engineers are remaining mum, we can only guess why iDevices behave the way they do. What isn't in dispute is that, unlike hundreds of competing devices that Wuergler and Graham have examined, the Apple products leak connection details many users would prefer to keep private.
A video demonstrating the iPhone's vulnerability to fake access point attacks is here.
Updated to better describe video.Image courtesy of Robert Graham, Errata Security
Tuesday, March 27. 2012
TI Demos OMAP5 WiFi Display Mirroring on Development Platform
Via AnandTech
-----
On our last day at MWC 2012, TI pulled me aside for a private demonstration of WiFi Display functionality they had only just recently finalized working on their OMAP 5 development platform. The demo showed WiFi Display mirroring working between the development device’s 720p display and an adjacent notebook which was being used as the WiFi Display sink.
TI emphasized that what’s different about their WiFi Display implementation is that it works using the display framebuffer natively and not a memory copy which would introduce delay and take up space. In addition, the encoder being used is the IVA-HD accelerator doing the WiFi Display specification’s mandatory H.264 baseline Level 3.1 encode, not a software encoder running on the application processor. The demo was running mirroring the development tablet’s 720p display, but TI says they could easily do 1080p as well, but would require a 1080p framebuffer to snoop on the host device. Latency between the development platform and display sink was just 15ms - essentially one frame at 60 Hz.
The demonstration worked live over the air at TI’s MWC booth and also used a WiLink 8 series WLAN combo chip. There was some stuttering, however this is understandable given the fact that this demo was using TCP (live implementations will use UDP) and of course just how crowded 2.4 and 5 GHz spectrum is at these conferences. In addition, TI collaborated with Screenovate for their application development and WiFi Display optimization secret sauce, which I’m guessing has to do with adaptive bitrate or possibly more.
Enabling higher than 480p software encoded WiFi Display is just one more obvious piece of the puzzle which will eventually enable smartphones and tablets to obviate standalone streaming devices.
-----
Personal Comment:
Kind of obvious and interesting step forward as it is more and more requested by mobile devices users to be able to beam or 'to TV' mobile device's screens... which should lead to transform any (mobile) device in a full-duplex video broadcasting enabled device (user interaction included!) ... and one may then succeed in getting rid of some cables in the same sitting?!
Wednesday, March 21. 2012
World’s First Flying File-Sharing Drones in Action
Via TorrentFreak
-----
A few days ago The Pirate Bay announced that in future parts of its site could be hosted on GPS controlled drones. To many this may have sounded like a joke, but in fact these pirate drones already exist. Project “Electronic Countermeasures” has built a swarm of five fully operational drones which prove that an “aerial Napster” or an “airborne Pirate Bay” is not as futuristic as it sounds.
In an ever-continuing effort to thwart censorship, The Pirate Bay plans to turn flying drones into mobile hosting locations.
“Everyone knows WHAT TPB is. Now they’re going to have to think about WHERE TPB is,” The Pirate Bay team told TorrentFreak last Sunday, announcing their drone project.
Liam Young, co-founder of Tomorrow’s Thoughts Today, was amazed to read the announcement, not so much because of the technology, because his group has already built a swarm of file-sharing drones.
“I thought hold on, we are already doing that,” Young told TorrentFreak.
Their starting point for project “Electronic Countermeasures” was to create something akin to an ‘aerial Napster’ or ‘airborne Pirate Bay’, but it became much more than that.
“Part nomadic infrastructure and part robotic swarm, we have rebuilt and programmed the drones to broadcast their own local Wi-Fi network as a form of aerial Napster. They swarm into formation, broadcasting their pirate network, and then disperse, escaping detection, only to reform elsewhere,” says the group describing their creation.
File-Sharing Drone in Action (photo by Claus Langer)
In short the system allows the public to share data with the help of flying drones. Much like the Pirate Box, but one that flies autonomously over the city.
“The public can upload files, photos and share data with one another as the drones float above the significant public spaces of the city. The swarm becomes a pirate broadcast network, a mobile infrastructure that passers-by can interact with,” the creators explain.
One major difference compared to more traditional file-sharing hubs is that it requires a hefty investment. Each of the drones costs 1500 euros to build. Not a big surprise, considering the hardware that’s needed to keep these pirate hubs in the air.
“Each one is powered by 2x 2200mAh LiPo batteries. The lift is provided by 4x Roxxy Brushless Motors that run off a GPS flight control board. Also on deck are altitude sensors and gyros that keep the flight stable. They all talk to a master control system through XBee wireless modules,” Young told TorrentFreak.
“These all sit on a 10mm x 10mm aluminum frame and are wrapped in a vacuum formed aerodynamic cowling. The network is broadcast using various different hardware setups ranging from Linux gumstick modules, wireless routers and USB sticks for file storage.”
For Young and his crew this is just the beginning. With proper financial support they hope to build more drones and increase the range they can cover.
“We are planning on scaling up the system by increasing broadcast range and building more drones for the flock. We are also building in other systems like autonomous battery change bases. We are looking for funding and backers to assist us in scaling up the system,” he told us.
Those who see the drones in action (video below) will notice that they’re not just practical. The creative and artistic background of the group shines through, with the choreography performed by the drones perhaps even more stunning than the sharing component.
“When the audience interacts with the drones they glow with vibrant colors, they break formation, they are called over and their flight pattern becomes more dramatic and expressive,” the group explains.
Besides the artistic value, the drones can also have other use cases than being a “pirate hub.” For example, they can serve as peer-to-peer communications support for protesters and activists in regions where Internet access is censored.
Either way, whether it’s Hollywood or a dictator, there will always be groups that have a reason to shoot the machines down. But let’s be honest, who would dare to destroy such a beautiful piece of art?
Electronic Countermeasures @ GLOW Festival NL 2011 from liam young on Vimeo.
Quicksearch
Popular Entries
- The great Ars Android interface shootout (130709)
- Norton cyber crime study offers striking revenue loss statistics (101068)
- MeCam $49 flying camera concept follows you around, streams video to your phone (99715)
- Norton cyber crime study offers striking revenue loss statistics (57297)
- The PC inside your phone: A guide to the system-on-a-chip (57018)
