Category: McAfee Labs

Apr 17 2018

Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern

This post was researched and written with the assistance of Tim Hux, Abhishek Karnik, Asheer Malhotra, and Steve Povolny

McAfee Advanced Threat Research team analysts have studied Adobe Flash Player for years because it is a popular target for attacks. As always, we advise customers to remain current with McAfee’s latest DAT versions. In this post we want to provide some insight into the history of Flash exploitation and possible future trends.

Morphisec published an analysis of a new set of Flash flaws, CVE-2018-4878, that have been exploited in the wild. Hardik Shah of McAfee Labs posted a technical analysis of CVE-2018-4878’s mechanisms on March 2:

“The number of Flash Player exploits has recently declined, due to Adobe’s introduction of various measures to strengthen Flash’s security. Occasionally, however, an exploit still arises. On January 31, Kr-Cert reported a zero-day vulnerability, identified as CVE-2018-4878, being exploited in the field. (Adobe has released an update to fix this flaw.)”

Details about McAfee protections covering CVE-2018-4878 appear at the end of this article.

This post will examine the history of Flash’s issues since the first Common Vulnerabilities and Exposures (CVE) list for Flash was published in 2006. By examining some of the data, both users and owners of sites that employ Flash can better understand Flash flaws and why Flash will continue to interest attackers, even though Adobe will discontinue development of Flash in 2020.

We examined historical Flash data regarding vulnerabilities. We also accounted for the current distribution and uses of Flash. Through this analysis, we believe that despite Adobe announcing Flash’s end of life, a number of sites will continue to use and depend upon Flash for at least the immediate future, even as sites convert to alternative technologies. (See the list of example sites, below.) Flash continues to offer attackers an exploitable collection of flaws for the immediate future.

The following chart uses CVE data. Although not every exploitable and exploited condition receives a CVE entry, most flaws that are discovered through security research or reported against major software vendors’ products eventually gains a CVE number that is posted to the CVE database kept by Mitre. Therefore, CVE offers a convenient repository of vulnerability data to aid research.

Searching the entire database for every instance of “Flash Player” or “Adobe Flash Player” returned 1,050 CVE entries from the years 2006-2017.

There was a steady increase in reported vulnerabilities between 2006 and 2014. Then we saw a big jump in 2015 and 2016. Of the 1,050 issues, about 79% (830) gave attackers some sort of code execution capability, though not every one of those 830 flaws allowed remote code execution. Still, an attacker gains a significant advantage from running any code. The McAfee Labs analysis shows that CVE-2018-4878 was another example of remote code execution, which usually leads to full compromise. This point suggests that Flash vulnerabilities will remain a significant target.

The data source CVE Details offers the following distribution of Flash CVE vulnerabilities:

Source: CVE Details.

In 2015 through 2017, 81% of flaws resulted in code execution of one form or another.

CVE Details also assigns Flash issues with Common Vulnerability Scoring System scores. Many issues from 2015–2017 earned scores above 9, which is considered severe.

  • 2015: 294 vulnerabilities ≥ 9
  • 2016: 224 vulnerabilities ≥ 9
  • 2017: 60 vulnerabilities ≥ 9

These severe scores further highlight why attackers remain interested in exploiting Flash weaknesses; they offer significant “attacker value” for the effort required to exploit them.  Looking at the historical distribution of issues, we see a spike in 2015. Then the spike drops off. It was in the latter part of 2014 that Adobe adopted a change in their software security strategy.

“’Finding and fixing bugs isn’t the way to go, it’s … making it harder and more expensive for [attackers] to achieve an outcome,” said Adobe’s Chief Security Officer, Brad Arkin, at a conference in October 2014. He urged organizations to stop patching every vulnerability and instead increase the cost of exploitation to frustrate attackers. “The bad guys aren’t stupid,” he added. “They are going to apply their resources in the [most] cost efficient way possible, and so they seek to minimize the cost of developing an exploit.”

Adobe’s shift in software security strategy has been to make exploiting issues prohibitively expensive so that attackers will find easier, less resource-intensive, and perhaps more reliable methods. Rather than chase every flaw, Adobe’s approach focuses on building defensive techniques that protect vulnerabilities, just as standard secure development life cycle techniques attempt to prevent new vulnerabilities from being released.

Little in software development happens immediately, especially on a large scale. There is typically a lag—usually one to two years—between a strategy shift and results. In any event, the first issues to be eliminated are often the easiest to fix. As the program’s effectiveness improves, resources are available to address harder problems.

Brad Arkin spoke about a strategy shift in the fall of 2014. We expected that shift to take time, and that is what we see in the data: In 2016, the number of newly discovered issues began to decline. However, the steep increase in vulnerabilities in 2015 and 2016 requires some additional examination.

When security researchers focus on a code base, they generally start by finding the easiest-to-discover issues. As these are found and fixed, researchers probe deeper, shifting to techniques that increase in difficulty. Due to this ever-increasing difficulty, we often see a decrease in discoveries; it takes more time and effort to uncover tricky issues.

Coupling the increasing difficulty of finding problems against the increase in effectiveness of a software security program, we find a distribution like what we have seen with Flash CVE reporting from 2015 through 2017. Until 2015, attackers exploited relatively easy-to-find cross-site scripting errors, but these largely disappeared after 2014. Suddenly, in 2015, there is a huge jump in the discovery of difficult-to-uncover memory issues and code execution opportunities. The leap in the CVE numbers reflects more technically challenging issues surfacing just as Adobe’s software strategy was making its shift.

The new strategy had not had time to be fully effective by 2015. Plus, Flash, like all complex software, carries a large amount of legacy code. Just when researchers were digging deeper and harder into the code base, Adobe’s software security change required not just chasing vulnerability fixes, but also generating protective code and designs—all of which take time to implement. This typical situation explains the influx of critical new issues in 2015, and their subsequent continuous reductions.

Still, no single or collection of security techniques is perfect. In 2017, Flash marked 70 new issues. So far in 2018, three have been discovered. The most recent, CVE-2018-4878, is technically challenging and appears to be within protections that Adobe has placed within byte arrays to prevent these memory structures from being misused. “[CVE-2018-4878] bypassed the byte array mitigation feature that was introduced to prevent ‘length corruption’ attacks in Flash,” wrote McAfee’s Hardik Shah in “How Hackers Bypassed an Adobe Flash Protection Mechanism.”

It is just as possible to unwittingly add an exploitation opportunity when implementing software protections as when writing any other code. Of the 73 vulnerabilities discovered in 2017 and 2018, there is no method, without tracking code changes, to know when each of the flaws was introduced. It is likely that some of them arose in code carried forward from earlier versions, that is, from legacy code. Software implementers have a compelling argument to reuse as much code as possible in each new version. It is cheaper because it saves time.

In a product with a history as long as Flash’s (more than 10 years), some of its code was written for a different threat landscape, not for today’s attackers and their more sophisticated tools and techniques. It is reasonable to suspect that a significant portion of the last two years’ worth of newly discovered issues are in code that has been carried into the latest versions. Those flaws contrast with the most recent vulnerability, CVE-2018-4878, which bypasses and abuses protections that were likely put into place after Adobe’s shift in strategy. The code that CVE-2018-4878 abuses was intended to make exploitation of byte arrays “more expensive.”

To measure the popularity of Flash, we turned to Q-Success’ W3Techs web survey data. The following table shows the use of four client-side languages, with Flash declining steadily since 2011. JavaScript, on the other hand, today is nearly ubiquitous, at 95%. The two leading languages are graphed in the chart that follows the table.

Historical Yearly Trends in the Usage of Client-Side Programming Languages for Websites

Usage (in % of sites) of Client-Side Programming Languages for Websites

Chart data as of March 8, 2018. Source for table and chart: © 2009-2018 Q-Success DI Gelbmann GmbH

From W3Techs data, we can see that Flash use has declined steadily, to only 5% of surveyed web sites. Doesn’t that suggest that Flash exploitation would also decline or even stop? Unfortunately, it does not.

The following W3Techs chart shows that although the number of sites using Flash is fairly low, enough high-traffic sites employ it to keep Flash popular.

High-Traffic Sites That Still Use Adobe Flash

Source: PublicWWW.

If popular websites continue to use Flash, then Flash Player will remain in use on users’ machines for some time. Adobe has promised to continue supporting Flash Player until the end of 2020. Unfortunately, this means merely that software updates, features, and patches will no longer be added; it does not effectively change Flash’s overall use. Only the end of websites requiring Flash will remove its vulnerabilities from the security picture.

A highly targeted attack may need to compromise only a single computer to access an organization’s digital infrastructure and gain access to strategic targets. That single computer could be running an unpatched or dated version of Flash.

As the use of Flash has declined, client-side JavaScript has become the de facto browser programming language. Yet JavaScript’s takeover does not fully solve the problem because it can deliver a Flash payload. Although some of the Flash vulnerabilities we have analyzed can be exploited remotely, many cannot. An attacker often requires some interaction by the victim to run a Flash exploit. JavaScript has become an increasingly common delivery mechanism for this purpose.

DIY: Exploits in a Kit

Perhaps more important to attackers is the easy availability of Flash exploits ready to use in numerous exploit “kits.” Kits package all the necessary code to exercise a set of known vulnerabilities. Access to readily available exploits in a kit means far less attacker effort. Kits also “lower the technical bar.” Attackers need not understand how an exploit works; they can simply leverage the packages without knowing the technical details.

Old Flash exploits are still available, along with new ones such as CVE-2018-4878, according to Tim Hux of the McAfee Advanced Threat Research team. “The Bizarro Sundown (aka GreenFlash) and ThreadKit exploit kits added the exploit to their lists last month,” he said. “The Rig and Magnitude exploit kits added this flaw to their arsenals this month.”

Adding a new exploit does not mean the old ones are no longer available. Exploit kits are additive. The Rig kit, which appeared in 2014, contains the following Flash exploits:

CVE-2013-0634           CVE-2015-3113

CVE-2014-0497           CVE-2015-5119

CVE-2014-0515           CVE-2015-5122

CVE-2014-0569           CVE-2015-7645

CVE-2015-0311           CVE-2016-1019

CVE-2015-0359           CVE-2016-4117

CVE-2015-3090

Old exploits do not die, they just get used less often as software is upgraded to fix earlier versions. If an attacker finds a vulnerable version of Flash in use, kits will have exploits to employ.

Conclusion

It is difficult, and perhaps impossible, to prove that software is error free. (Alan Turing’s famous proof mathematically shows that automated processes cannot be proved correct through automation.) As famed computer scientist Edsger Dijkstra noted, “Testing shows the presence, not the absence of bugs.” (“Software Engineering Techniques,” NATO Science Committee, page 16.) In other words, even software that has passed a battery of security tests before release may still contain exploitable conditions.

From our analysis of the relationship between Flash CVEs and Flash’s ongoing use, especially on high-traffic sites, McAfee’s Advanced Threat Research team believes that Flash vulnerabilities will continue to offer attackers a means toward malicious ends. However, Adobe’s shift in security strategy is an excellent step in reducing the number of newly discovered issues, which should maintain their decline.

McAfee protections for CVE-2018-4878

McAfee’s malware engine can parse Flash for malicious content. Customers who have turned on automatic updates or who update regularly have been protected against seven new variants of CVE-2018-4878 since February 6.

McAfee Host Intrusion Prevention signatures 8001, 1149, 6011, and 6010 detect CVE-2018-4878 exploits.

  • 8001 and 1149: On by default, but log only, not block. Customers can select block.
    • 8001: Suspicious exploit behavior, log only, available in HIPS, not in ENS
    • 1149: CMD tool access by a Windows mail client or Internet Explorer, log only, available in HIPS, not in ENS
  • 6011 and 6010: Off by default. Enabling them may result in an increase of false positives.
    • 6011: Generic application invocation protection, not present in ENS
    • 6010: Generic application hooking protection, not present in ENS

Recent campaigns exploiting Flash Player Issues

CVE-2018-4878: Currently being exploited in a massive spam mail campaign.

CVE-2017-11292: Black Oasis Advanced Persistent Threat

CVE-2016-4117: Hidden Cobra APT/CryptXXX Ransomware/Erebus APT

CVE-2016-1019: Cerber and Locky ransomware/Hidden Cobra APT

CVE-2015-3133: CryptoWall Ransomware

CVE-2015-0311: TeslaCrypt and FessLeak Ransomware

CVE-2014-8439: Cerber Ransomware

CVE-2015-7645: Cerber and Alpha Crypt Ransomware

McAfee does not control or audit third-party benchmark data or the websites referenced in this document. You should visit the referenced website and confirm whether referenced data is accurate.
McAfee and the McAfee logo are trademarks or registered trademarks of McAfee, LLC or its subsidiaries in the US and other countries. Other marks and brands may be claimed as the property of others. Copyright © 2018 McAfee, LLC

The post Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern appeared first on McAfee Blogs.

Apr 16 2018

Cloud Clustering Vulnerable to Attacks

The authors thank John Fokker and Marcelo CaroVargas for their contributions and insights.

In our upcoming talk at the Cloud Security Alliance Summit at the RSA Conference, we will focus our attention on the insecurity of cloud deployments. We are interested in whether attackers can use compromised cloud infrastructure as viable backup resources as well as for cryptocurrency mining and other illegitimate uses. The use of containers has increased rapidly, especially when it comes to managing the deployment of applications. Our latest market survey found that 83% of organizations worldwide are actively testing or using containers in production. Applications need authentication for load balancing, managing the network between containers, auto-scaling, etc. One solution (called a cluster manager) for the automated installation and orchestration of containers is Kubernetes.

Some key components in the Kubernetes architecture appear below:

High-level Kubernetes architecture.

  • Kubernetes master server: The managing machine oversees one or more nodes
  • Node: A client that runs tasks as delegated by the user and Kubernetes master server
  • Pod: An application (or part of an application) that runs on a node. The smallest unit that can be scheduled to be deployed. Not intended to live long.

For our article, we need to highlight the etcd storage on the master server. This database stores the configuration data of the cluster and represents the overall state of the cluster at a given time. Kubernetes saves these secrets in Base64 strings; before Version 2.1 there was no authentication in etcd.

With that knowledge, security researcher Giovanni Collazo from Puerto Rico started to query the Shodan database for etcd databases connected to the Internet. He discovered many and by executing a query, some of these databases started to reveal a lot of credentials. Beyond leaking credentials from databases and other accounts, what other scenarios are possible?

Leaking Credentials

There are several ways that we can acquire credentials for cloud services without hacking into panels or services. By “creatively” searching public sites and repositories, we can find plenty of them. For example, when we searched on GitHub, we found more than 380,000 results for certain credentials. Let’s assume that half of them are useful: We would have 190,000 potentially valid credentials. As Collazo did for etcd, one can also use the Shodan search engine to query for other databases. By creating the right query for Django databases, for example, we were able to identify more cloud credentials. Amazon’s security team proactively scans GitHub for AWS credentials and informs their customers if they find credentials.

Regarding Kubernetes: Leaked credentials, complete configurations of the DNS, load balancers, and service accounts offer several possible scenarios. These include exfiltrating data, rerouting traffic, or even creating malicious containers in different nodes (if the service accounts have enough privileges to execute changes in the master server).

Creating malicious containers.

One of the biggest risks concerning leaked credentials is the abuse of your cloud resources for cryptomining. The adversaries can order multiple servers under your account to start cryptomining, enriching their bank accounts while you pay for the computing power “you” ordered.

Open Buckets

We have heard a lot about incidents in which companies have not secured their Amazon S3 buckets. A number of tools can scan for “open” buckets and download the content. Attackers would be most interested in write-enabled rights on a bucket. For our Cloud Security Alliance keynote address at RSA, we created a list of Fortune 1000 companies and looked for readable buckets. We discovered quite a few. That is no surprise, but if you combine the read-only buckets information with the ease of harvesting credentials, the story changes. With open and writable buckets, the adversaries have plenty of opportunities: storing and injecting malware, exfiltrating and manipulating data, etc.

McAfee cloud researchers offer an audit tool that, among other things, verifies the rights of buckets. As we write this post, more than 1,200 writable buckets belonging to a multitude of companies, are accessible to the public. One of the largest ad networks in the world had a publicly writable bucket. If adversaries could access that network, they could easily inject malicious code into advertisements. (As part of our responsible disclosure process, we reported the issue, which was fixed within hours.) You can read an extensive post on McAfee cloud research and how the analysts exposed possible man-in-the-middle attacks leveraging writable buckets.

Clustering the Techniques

To combat ransomware, many organizations use the cloud to back up and protect their data. In our talk we will approach the cloud as an attack vector for spreading ransomware. With the leaked credentials we discovered from various sources, the open and writable buckets created a groundwork for storing and spreading our ransomware. With attackers having a multitude of credentials and storage places such as buckets, databases, and containers, defenders would have difficulty keeping up. We all need to pay attention to where we store our credentials and how well we monitor and secure our cloud environments.

The post Cloud Clustering Vulnerable to Attacks appeared first on McAfee Blogs.

Apr 11 2018

Parasitic Coin Mining Creates Wealth, Destroys Systems

The increasing popularity of cryptocurrencies has inspired some people to pursue coin mining, essentially making money online. (Mining is the processing of transactions in the digital currency system, in which new transactions are recorded in a digital ledger called the blockchain. Miners help to update the ledger to verify and collect new transactions to be added to the blockchain. In return, miners earn Bitcoins, for example.) Mining is resource intensive and legal if it is done with the proper permissions.

McAfee Labs has recently seen a huge increase in a malware variant, commonly known as CoinMiner or CoinMiner-FOZU!, which takes control of a victim’s computer to mine new coins by infecting user executables, injecting Coinhive JavaScript into HTML files, and blocking the domains of security products to stop signature updates.

CoinMiner-FOZU!, which we analyzed, has led all major coin-miner malware in prevalence in 2018. (March figures are incomplete.) Source: McAfee Labs.

The following graphs show statistics and geographic data for recent CoinMiner-FOZU! detections:

W32/CoinMiner employs—without a user’s consent—machine resources to mine coins for virtual currencies. Its parasitic nature makes it rare as well as destructive: The malware does not put a unique marker on each file it infects. Thus subsequent infections by the same malware will reinfect the victim’s files.

Analysis

After launching, CoinMiner copies itself into two hardcoded locations:

  • %Windows%\360\360Safe\deepscan\ZhuDongFangYu.exe
  • %filesystemroot%:\RECYCLER\S-5-4-62-7581032776-5377505530-562822366-6588\ZhuDongFangYu.exe

These two files are hidden and read only:

The binary executes from the first location and starts the parasitic infection process. The malware prepends itself to user-executable files but, unlike traditional file infectors, it does not allow the original file to run. It targets files with extensions .exe, .com, .scr, and .pif. This malware does not check for multiple infections. If the threat is deleted and later reinfects the system, the same files will again be targeted.

To prevent victims from restoring clean copies of their files, the malware deletes both ISO (disk image) and GHO (Norton Ghost) files:

 

Once CoinMiner finishes infecting other executable files, it injects a Coinhive script into HTML files. The Coinhive service provides cryptocurrency mining software, which using JavaScript code can be embedded in websites and use the site visitor’s processing power to mine the cryptocurrency:

CoinMiner disables the user account control feature, which notifies the user when applications make changes to the system. Through registry updates, it also disables folder options and registry tools, and deletes safe mode.

From its second location on an infected system—the hidden autorun.inf at the file system root—the malware ensures that it starts after rebooting:

To avoid detection by security products, CoinMiner puts security software domains in the hosts file and redirects them to 127.0.0.1, the loopback address on the victim’s system. If users have not created a local website, they will see an error page in their browsers. By doing this, the malware ensures that no victim can receive an update from the security vendor.

When the victim runs the script-injected HTML files, the Coinhive script executes, downloading coinhive.min.js (hash: 4d6af0dba75bedf4d8822a776a331b2b1591477c6df18698ad5b8628e0880382) from coinhive.com. This script takes over 100% of the CPU for mining using the function setThrottle(0). The mining stops when the victim closes the infected HTML file:

The simple hosts-file injection, hiding in the recycle bin, and maximizing CPU usage suggest that this malware has been written by a novice author. McAfee advises all users to keep their antimalware products up to date.

McAfee Detections

  • W32/CoinMiner
  • CoinMiner-FOZU![Partial hash]
  • TXT/CoinMiner.m
  • HTML/CoinMiner.m
  • JS/Miner.c

Hashes (SHA-256)

  • 80568db643de5f429e9ad5e2005529bc01c4d7da06751e343c05fa51f537560d
  • bb987f37666b6e8ebf43e443fc4bacd5f0ab795194f20c01fcd10cb582da1c57
  • 4d6af0dba75bedf4d8822a776a331b2b1591477c6df18698ad5b8628e0880382

The post Parasitic Coin Mining Creates Wealth, Destroys Systems appeared first on McAfee Blogs.

Mar 27 2018

Today’s Connected Cars Vulnerable to Hacking, Malware

The McAfee Advanced Threat Research team recently published an article about threats to automobiles on the French site JournalAuto.com. Connected cars are growing rapidly in number and represent the next big step in personal transportation. Auto sales are expected to triple between 2017 and 2022, to US$155.9 billion from $52.5 billion, according to PwC France. Realizing this increase is a huge challenge for car companies as well as for IT security firms.

Through multiple added functions, from Wi-Fi and external connections to driving assistance and autonomous operations, connected cars will very soon need strong security to avoid any intrusions that could endanger drivers, passengers, and others.

Security Risks

Modern cars are exposed to security risks just as are other connected devices. Let’s look at current and future threats in the automotive security field.

The following diagram shows the main risks: 

 

Personal Data and Tracking

Connected cars record a lot of information about their drivers. This information can come from an external device connected to the car, such as a phone, and can include contact details, SMS and calls history, and even musical tastes. A car can also record shifting patterns and other driver’s habits that could be used to create a picture of a driver’s competence. This kind of oversight could aid insurance companies when offering coverage, for example.

With personal data now considered the new gold, all of this information represents a valuable target for cybercriminals as well as companies and governments.

  • Cybercriminals can use this stolen information for financial compensation and identity theft
  • Companies can use this information for marketing or insurance contracts
  • Governments can use this information for spying on and tracking people

Faked Car Data

Digital information can be modified and faked. By altering data such as pollution tests or performance, companies can take advantage of the results to increase sales. Similarly, drivers could modify car statistics such as distance traveled to fool insurance companies or future buyers.

Car Theft and Key Fob Hacking

Key fob hacking is a technique to allow an intruder to enter a car without breaking in. This technique is widely known by attackers and can be done easily with cheap hardware. The attack consists of intercepting the signal from a wireless key to either block the signal to lock the car or replay the signal to gain access.

One variant of the attack uses a jammer to block the signal. The jammer interferes with the electromagnetic waves used to communicate with the vehicle, blocking the signal and preventing the car from locking, leaving access free to the attacker. Some jammers have a range of more than 500 meters.

Key fob jammer.

Another attack intercepts the signal sent by the key and replays it to open the door. Auto manufacturers protect against this kind of attack by implementing security algorithms that avoid simple replays with same signal. Each signal sent from the key to the car is unique, thus avoiding a replay. However, one proof of concept for this attack blocks the signal to the car and stores it. The driver’s first click on the key does not work but is recorded by the attacker. The driver’s second click is also recorded, locking the car but giving two signals to the attackers. The first signal recorded, which the car has not received, is used to unlock the door. The second signal is stored for the attacker to use later.

Entering by the (CAN) Back Door

Autos use several components to interact with their parts. Since the end of the 20th century, cars have used the dedicated controller area network (CAN) standard to allow microcontrollers and devices to talk to each other. The CAN bus communicates with a vehicle’s electronic control unit (ECU), which operates many subsystems such as antilock brakes, airbags, transmission, audio system, doors, and many other parts—including the engine. Modern cars also have an On-Board Diagnostic Version 2 (OBD-II) port. Mechanics use this port to diagnose problems. CAN traffic can be intercepted from the OBD port.

The on-board diagnostic port.

An external OBD device could be plugged into a car as a backdoor for external commands, controlling services such as the Wi-Fi connection, performance statistics, and unlocking doors. The OBD port offers a path for malicious activities if not secured.

Spam and Advertising

Adding more services to connected cars can also add more security risks. With the arrival of fully connected autos such as Teslas, which allow Internet access from a browser, it is feasible to deliver a new type of spam based on travel and geolocation. Imagine a pop-up discount as you approach a fast-food restaurant. Not only is this type of action likely to be unwanted, it could also provide a distraction to drivers. We already know spam and advertising are infection vectors for malware.

Malware and Exploits

All the ECUs in an auto contain firmware that can be hacked. Cars employ in-vehicle infotainment (IVI) systems to control audio or video among other functions. These systems are increasing in complexity.

An in-vehicle infotainment system.

MirrorLink, Bluetooth, and internal Wi-Fi are other technologies that improve the driving experience. By connecting our smartphones to our cars, we add functions such as phone calls, SMS, and music and audiobooks, for example.

Malware can target these devices. Phones, browsers, or the telecommunication networks embedded in our cars are infection vectors that can allow the installation of malware. In 2016, McAfee security researchers demonstrated a ransomware proof of concept that blocked the use of the car until the ransom was paid.

A proof-of-concept IVI ransomware attack on a vehicle.

The ransomware was installed via an over-the-air system that allowed the connection of external equipment.

Third-Party Apps  

Many modern cars allow third parties to create applications to further connected services. For example, it is possible to unlock or lock the door from your smartphone using an app. Although these apps can be very convenient, they effectively open these services to anyone and can become a new attack vector. It is easier to hack a smartphone app than a car’s ECU because the former is more affordable and offers many more resources. Car apps are also vulnerable because some third parties employ weak security practices and credentials are sometimes stored in clear text. These apps may also store personal information such as GPS data, car model, and other information. This scenario has already been demonstrated by the OnStar app that allowed a hacker to remotely open a car.

Vehicle-to-Vehicle Communications

Vehicle-to-vehicle (V2V) technology allows communications between vehicles on the road, using a wireless network. This technology can aid security on the road by reducing a car’s speed when another vehicle is too close, for example. It can also communicate with road sign devices (vehicle to infrastructure). That transmitted information improves the driving experience as well as the security. Now imagine this vector invaded by destructive malware. If the V2V system becomes a vector, a malicious actor could create malware to infect many connected cars. This sounds like a sci-fi scenario, right? Yet it is not, if we compare this possibility with recent threats such as WannaCry or NotPetya that targeted computers with destructive malware. It is not hard to predict such a nightmare scenario.

Conclusion

Connected cars are taking over the roads and will radically change how we move about. By enhancing the customer experience, the automotive and the tech industries will provide exciting new services. Nonetheless, we need to consider the potential risks, with security implemented sooner rather than later. Some of the scenarios in this post are already used in the wild; others could happen sooner than we expect.

References

The post Today’s Connected Cars Vulnerable to Hacking, Malware appeared first on McAfee Blogs.