I Need A Chick
I Just need a chick
A smartphone app flaw has left Tesla vehicles vulnerable to being tracked, located, unlocked, and stolen.
Security experts at Norwegian app security firm Promon were able to take full control of a Tesla vehicle, including finding where the car is parked, opening the door and enabling its keyless driving functionality. A lack of security in the Tesla smartphone app opened the door to all manner of exploits, as explained in a blog post here. The cyber-attack unearthed by Promon provides additional functionality to that exposed by Keen Security Labs in a different hack in late September.
Tom Lysemose Hansen, founder and CTO at Promon, said: "Keen Security Labs' recent research exploited flaws in the CAN bus systems of Tesla vehicles, enabling them to take control of a limited number of functions of the car. Our test is the first one to use the Tesla app as an entry point, and goes a step further by showing that a compromised app can lead directly to the theft of a car."
One way for the hack to work is for cybercriminals to set up a Wi-Fi hotspot, likely close to a public Tesla charging point. When Tesla users log in and visit a page, an advert targeting car owners appears, offering an incentive such as a free meal or coffee. When clicking this link and downloading the accompanying app, hackers can gain access to the user's mobile device, allowing them to attack the Tesla app and obtain usernames and passwords.
Youtube Video
In an update, Promon outlines the many and varied security shortcomings of Tesla's app.
This attack is not Tesla specific, and can in generalised form be used against any app. However, the Tesla app did not offer any kind of resistance which would require time-consuming effort to exploit.
One thing that stood out was that the OAuth token is stored in plain text – absolutely no attempts have been made to encrypt it, or otherwise protect it. Getting access to this one piece of data alone will get you the location of the car, ability to track the car and being able to unlock the car.
Driving off with the car requires the username and password in addition, which was very easy to do since the application did not detect that it had been modified to add malware-like behaviour that would send the credentials out of the app to a server.
"If Tesla had followed best practice in security (e.g. as recommended by the Open Web Application Security Project), including applying self-protecting capabilities inside the app, it would have required much higher technical skills – and much more effort – to perform such an attack," according to Promon. The Norwegian app security firm said that it was in "close dialogue with Tesla" in order to address these app security issues.
El Reg asked Tesla to comment on the research on Thursday, a US national holiday. We're yet to hear back but we'll update this story as and when we hear more.
John Smith, principal solutions architect at app security firm Veracode, commented: "With Tesla just recently remediating a vulnerability which allowed the car to be exploited remotely, this new security flaw leaves the car vulnerable to theft and highlights the plethora of challenges that car manufacturers now face as they introduce internet-connected services into the car. Vulnerable software is one of the most significant challenges faced by the automotive industry, with findings from a recent IDC report indicating that there could be a lag of up to three years before car security systems are protected from hackers.
"There are over 200 million lines of code in today's connected car, not to mention smartphone apps linked to the car. So it is essential that car manufacturers put security at the heart of the development strategy, rather than as an afterthought." ®
Sponsored: Transforming software delivery with DevOps
Mac malware could piggy-back on your legitimate webcam sessions - yep, the ones you've initiated - to locally record you without detection, a leading security researcher warns.
Patrick Wardle, a former NSA staffer who heads up research at infosec biz Synack, outlined the vulnerability together with counter-measures he’s developed during a keynote presentation at the Virus Bulletin conference. Peeping Tim-stye malware that abuses the video capabilities of an infected computers to record an unwitting user is a threat to both Windows and Mac users. Mac malware such as Eleanor, Crisis, Mokes and others, all attempt to spy on Mac OS X users via their webcam.
Luckily, modern Macs contain a hardware-based LED indicator that can alert users when the camera is in use. And physically covering the built-in camera - a la Mark Zuckerberg - also provides a low-tech approach to locking out snoopers, with the downside that it also prevents legitimate use.
Wardle has uncovered a fresh dimension to the problem. After examining various "webcam-aware" OS X malware samples, Wardle identified a new "capability" that would permit this type of malware to stealthily monitor the system for legitimate user-initiated video sessions before surreptitious piggyback on these conversations in order to covertly record the user. There are no visible indications of this malicious activity (as the LED light is already on), the malware can record both audio and video without fear of detection.
During his presentation, titled Getting Duped: Piggybacking on Webcam Streams for Surreptitious Recordings, Wardle outlined the threat together with techniques geared towards detecting "secondary" processes that attempt to access an existing video session on OS X.
“I have not seen any malware using this technique at this time [but] this is something that would be trivial for malware to do, and there aren’t any tools to detect this capability,” Wardle explained, adding there “may be malware already (ab)using this technique that we just haven’t detected”.
Malware along the lines Wardle discussed would be able to record both sides of a conversation once it detects the webcam being used.
Waddle has a released a free Oversight tool that he says can detect and identify any process that accesses the webcam before giving users the ability to either block or allow a process. All these notifications/alerts are logged, so a system admin (say on a corporate network) could reactively also look through the logs to see what was using the webcam. ®
Sponsored: Boost business agility and insight with flash storage for analytics
We’re all familiar with the cartoon image of a character stopping a water leak by plugging a finger into the hole, only for another leak to start, needing another finger, and so on, until the character is soaked by a wave of water.
It’s a little like the current, fragmented state of mobile security – the range of threats is growing fast, outpacing current security measures. Also, the devices themselves have inherent vulnerabilities that can be exploited by resourceful attackers. So it’s no surprise that enterprises are struggling with the issue of mobile security.
Finding flaws and mRATs
The list of potential security challenges and vulnerabilities across Android and iOS devices is complex. It starts with the devices’ mobility: they are connecting to public cellular networks, corporate networks, public hotspots to home internet providers and back again. This makes them vulnerable to Man in the Middle (MitM) attacks via rogue cellular base stations, WiFi hotspots or compromised public networks, allowing attackers to track, intercept and eavesdrop on data traffic and even voice calls, using SS7 protocol exploits.
Then, the Android and iOS mobile operating systems themselves have been shown time and time again to be plagued with vulnerabilities that smart malicious hackers can exploit to their advantage. One major recent example is ‘Quadrooter’, a privilege escalation vulnerability shown to affect over 900 million Android devices. These vulnerabilities often have long patching cycles which can take months to roll out, leaving millions of devices vulnerable to remote attack.
Similarly, iOS has also recently been in the headlines after news broke that it had been compromised in the NSO hack. This affected all Apple devices, making the iOS, the phones resources and any application running on it, including security apps such as anti-virus, vulnerable to attack. It’s worth highlighting that this wasn’t discovered by Apple or any detection applications but was only discovered because the attacker was negligent in concealing it.
Mobile remote access trojans (mRATs) give an attacker the ability to remotely access the resources and functions on Android or iOS devices, and stealthily exfiltrate data without the user being aware. mRATs are often embedded in supposedly benign apps available from appstores. Compromised or falsely certified apps are another security risk, as they can allow attackers to remotely take over devices, using the device resources without the user being aware.
As a result, the mobile security industry is always playing catch-up. Zero-day attacks, where cybercriminals exploit inbuilt vulnerabilities on mobile operating systems that haven’t yet been patched or even identified, are a major ongoing problem.
Protection versus performance
Ultimately, there are three main threat vectors for mobile devices. These are: targeting and intercepting the communications to and from devices; targeting the devices’ external interfaces (Cellular, WiFI, Bluetooth, USB, NFC, Web etc.) for the purpose of device penetration and planting malicious code (virtually as well as physically); and targeting the data on the device and the resources/functions the device/underlying OS provides access to such as microphone, camera, GPS, storage, network connectivity, etc.
While there is a wealth of technologies designed to help manage the security gaps on devices – from Enterprise Mobile Management to mobile anti-malware– these protections come at a price. First, a collection of multiple security tools and processes is a big drain on processing power, complex to manage, and doesn’t really fix the underlying device and OS vulnerabilities. Second, the conventional approach to mobile security is based on locking down or denying features and functions. This causes further problems on the end user’s acceptance front. It’s critical to balance security and usability: If protecting the device forces people to change the way they use it, they will find workarounds that will also undermine security measures.
So if enterprises are to continue harnessing the benefits of mobile devices without compromising their performance and usability, then we need to rethink our approach to mobile security, from the ground up.
Secure foundations
This new approach starts with the foundations of the mobile device: the OS and firmware. As the various software layers on devices have fundamental vulnerabilities which can be exploited, these should be replaced with secure, hardened versions from which the flaws have been removed/patched and advanced security layers have been put in place to effectively manage and protect against those three threat vectors mentioned above. This means attackers cannot use their conventional techniques to target vulnerabilities – but the device is still using an OS that the user is familiar with, giving users access to the full app ecosystem, so usability is not affected or restricted.
This stronger foundation is then used to build a strong, security architecture consisting of four layers to address each of the three main mobile threat vectors. The first layer is the Encryption Layer, in charge of encrypting all data stored on the phone, as well as all traffic from and to the device, securing all communications, whether voice, data or messaging, from any network sniffing and man-in-the-middle attacks.
The second layer is the Protection Layer, securing the device’s externally available interfaces, from WiFi, cellular, USB, NFC, Bluetooth to web. These need protecting against threats using an embedded firewall to monitor and block all downloads and exploit attempts.
Next layer is the Prevention Layer, monitoring for unauthorized attempts to access operating system functions like stored data, the microphone or camera, location technology and so on. These need their own specialist protective technologies.
The final layer is the Detection and Enforcement Layer monitoring, detecting and blocking execution attempts of malicious code or misbehaving apps, in the same way that we currently monitor for device and network anomalies on corporate networks.
In conclusion, mobile security is currently too fragmented, and the range of threats growing too fast for conventional protections. Instead of plugging leaks as they appear, we need to start again, from the foundations up – and fundamentally rethink the way in which we protect and secure mobile devices.
Slowly but relentlessly, Google is pushing website owners to deploy HTTPS – or get left behind.
The latest announced push is scheduled for January 2017, when Chrome 56 is set to be released and will start showing in the address bar a warning that labels sites that transmit passwords or credit cards over HTTP as non-secure.
In due time, all HTTP pages will be labeled by Chrome as non-secure, and ultimately, the HTTP security indicator will turn red, and sport the same “Danger!” triangle with which sites with broken HTTPS are currently marked:
Google is in the perfect position to spearhead the campaign aimed at pushing the collective Internet towards the default use of HTTPS. Changes in Chrome are one way to do it.
Previously employed tactics include prioritising websites using HTTPS in Google Search rankings and adding a new section to the company’s Transparency Report that allows users to keep an eye on Google’s use of HTTPS, and HTTPS use of the top 100 non-Google sites on the Internet.
“A substantial portion of web traffic has transitioned to HTTPS so far, and HTTPS usage is consistently increasing,” noted Emily Schechter, of the Chrome Security Team.
“We recently hit a milestone with more than half of Chrome desktop page loads now served over HTTPS. In addition, since the time we released our HTTPS report in February, 12 more of the top 100 websites have changed their serving default from HTTP to HTTPS.”
Recent Comments