Integrate InfoSec into the Hospitality Industry

The hospitality industry has a single focus on ensuring their guests have the optimal experience relative to their facility. This is the same with the medical and other fields; society wants people to specialize in their fields, versus generalizing in too many. If you are having heart surgery, you want the surgeon to be a specialist and not a general practitioner.

The hospitality industry is no different. As part of the operating process, the hotels and other facilities collect a mass amount of data from the clients. Each client has to pay for their room and other services, which is generally done with a credit card. This is valuable to the attackers, as the data may be sold. In recent history though, the industry has not done a fantastic job in protecting their client's data. A particularly glaring issue occurred with the Wyndham Hotels with the 2008 and 2009 compromises. The hotel in late 2015 settled with the Federal Trade Commission regarding charges the hotel did not do enough in order to protect the data. This arose from three breaches the hotel experienced with their client's data being exfiltrated. The process to resolve the issue was not inexpensive, as evidenced by the attorney fees and the fines.

Until this point, the hospitality industry has not given InfoSec a significant amount of attention. In comparison, other industries have declared this at a greater level of pertinence. For example, the DoD contractors, municipalities, financial services, medical, banking, and others have increased the focus and spending on this. The commonality with these is the entity computer system had been compromised, data exfiltrated, and fines from the FCC in specific cases.

This lack of focus may be a function of the entities working on their goal of achieving the best service for their clients. InfoSec, while vital, had not been significantly considered integral to their mission. Although not entirely within the distinct area involving their operations, InfoSec is still a supporting facet of their business.

Over the last few years, this has begun to change. The businesses are beginning to recognize each hospitality entity is the steward and responsible for their client's confidential and sensitive information. This data is sought by the attackers from the globe. The data being stored leads the reasons for attacks to occur. If the attack is successful, the hotel's client information (name, physical or mailing addresses, email addresses, credit card numbers, etc.) is removed by unauthorized parties.

This focus is expected to increase as this hospitality industry continues to increase their offerings geographically. The increase is relevant to InfoSec as the entities will be managing more data from many more regions and countries. Without this in place, the liability when there is a breach will only increase, especially with the GDPR coming online in the near future.

Mobile Device Attacks

Mobile devices have infiltrated society in many forms. People use their smartphones, tablets, laptops, and other devices in the coffee shops, malls, grocery stores, and too many other locations to note. These also have been adopted by children as they learn the many uses of technology.

These IoT devices have substantially improved the user experience (UX) and significantly increased the number of units in use along with productivity. As you walk through public areas, most people have these devices and actively using them.

One area within this realm which has not been exceptionally addressed in InfoSec. These devices hold a mass amount of data, mundane and confidential. The data also would have various levels of confidentiality involved. The person's physical address, in the grand overview, would not be as marketable as the social security number, parent's last names. This data is being targeted by the attackers.

This was recently researched by Check Point. Their research indicated 100% of the respondents, businesses located throughout the world, badly experienced malware on their mobile assets The sample consisted of 850 businesses on four continents. The focal point of the attacks were both the Android and iPhone devices.

The attacks were not isolated within each business, but there were many instances of each business. The study also noted 89% of the businesses had the opportunity to manage man-in-the-middle attacks (MitM). On a secondary level, 75% of the organizations also experienced their devices becoming compromised, as defined with the device being rooted or jailbroken.

The results indicate the mobile devices are clear targets. With the devices themselves, the Android systems were less secure than the iOS and Windows.

With these focussed attacks, it would appear defending against would be nearly impossible. With sufficient and regular training with the staff, this may be remediated to a manageable level. When the staff understands what not to do, what to not click on, what to watch for, etc., there are fewer instances of issues.

What is new again: Part II

An aspect of human nature not explored sufficiently is the lack of memory permanence. There is the distinct length of time people remember major system compromises. After this point, the issues leading up to the compromise, implications for the company, effects for the clients and associates are forgotten. This is not a new phenomenon and has been verified by several retail business breaches. After the breach notification, the sales revenue decreases for a bit, however later rebounds as if nothing ever happened.

There is, unfortunately, the same effect with malware. A programmer with a great idea for new malware creates this, the malware is presented in the wild, the malware works for a bit of time, is red-flagged, and its use is no longer needed. In the environment, we are seeing the old malware getting a new life and being re-introduced, perhaps with a nuance to adjust its signature to avoid notice from the AV providers. A recent example has been macros in Word and Excel. These were a significant issue over a decade ago. These were forgotten as viable issues for a rather significant amount of time until these were re-introduced. These were effective once again for a brief period of time until the new application is noticed, and the cycle begins again. Another incident has occurred with this. Recently, a vulnerability dating back 19 years re-appeared. This affects the RSA implementation with at least eight vendors. This vulnerability has been termed ROBOT, an acronym for Return of Bleichenbacher's Oracle Attack.

When exploited, this allows the others to decrypt and encrypt the RSA function applying the private key which had been configured previously on the TLS servers where the vulnerability was located. This issue was first noted by Daniel Bleichenbacher, a Swiss cryptographer. The vulnerability and subsequent attack are specifically applicable to RSA based PKCS #1 v1.5 encryption as utilized in SSLv2.

This will certainly not be the last attack that will be recycled. This will continue as long as our memories remain short.

Critical Infrastructure (CI) Targeted Again and Again and Again

Critical infrastructure (CI) is one of the underlying backbones of our civilization. This aspect supports virtually all we are actively involved in. If you like to use electricity for your electronics (e.g. computers, laptops, tablets, television, radio, etc.), fresh water, sewage leaving your home, etc., then a certain new malware sample should grab your attention.

Malware directed at the energy industry is not new. There have been dams attacked in the US. nuclear power plants across the globe, and other CI industries. The equipment implemented in the industries also has been targeted for their respective vulnerabilities.

The latest malware is an example of the latter. This targets the Triconex Safety Instrumented System (SIS) manufactured by Schneider Electric and has been named Triton or Tricis. This equipment is part of the industrial control system (ICS) for the utilities. This is designed to work in an autonomous fashion to monitor systems within the utility and shut a system down if there is a safety issue. This malware was coded to when implemented against the vulnerability to read and write programs and functions, along with querying the SIS controller. The attacker, with the deployed malware, is able to modify the SIS logic to shut down, indicating an unsafe reading, when the system may be operating fine without an issue.

There naturally would be financial issues to the utility, however, there may also be damage tot he equipment and facility if this were to be reversed and the equipment was to allow for unsafe conditions to continue unchecked.

The IC and ICS systems will continue to be targeted as time passes. With an attack here, the result of the compromise would rather significant detriment.

Let's automate (security) and not procrastinate

With each dawn, there are new stories relating there has been yet another compromise and a mountain of data had been exfiltrated via an "advanced hack" that allegedly no one could have defended against. Notwithstanding many of these are oversights, there is a form of assistance from within the organization that is more of an organic method of assistance. This may not be the panacea that too many are seeking, however it certainly would be an assistance.

A central issue is the lack of qualified, skilled employees in the market. This has been noted repeatedly. The fix for this is not in the short-term frame. This involves training, change of mindset, and other paradigm shifts to take a full effect. One avenue, overlooked by too many is utilizing automation to assist with the task. To fully review logs, gather material, and perform the simple tasks takes the staff time to complete. This may take hours that could be used for much greater and impactful duties. By automating these tasks, the time the staff was spending pulling reports, analyzing for trends, and other activities would be freed up. The scripts don't need to be extremely over-complicated, but written to simply do the task.

To further extend the usefulness of this, simple machine learning could be applied. To ensure this is indeed adding value, this could be supervised until the app would be completing its tasks to the acceptance of management. This again would not need to necessarily delve into the minutiae initially. This step may be taken at some point later on when the comfort level is present. This is merely one manner to assist with the time crunch felt in the industry.

Message for the DoD: Security, It's Not just for Operations

Data comes in all forms and sizes. The composition of this also varies greatly dependent on the data owner. One actionable items regardless of the data composition is security. The data requires some form of security to be applied to it to keep unauthorized parties to access it. This difficult lesson has been learned by many organizations over the years with data compromises of differing magnitudes and costs to them. One of the latest involved the Department of Defense (DoD). The DoD happened to leave 1.8B social media and forum posts written by users from across the planet on a server. Normally, this would not be a notable occurrence. These posts however were placed on three Amazon S3 servers. These databases were owned by the US Central Command (CENTCOM) and the US Pacific Command (PACOM).
The issue is the data was not secured or protected. These could have been access by virtually anyone. When the servers were acquired by the DoD, the persons in charge for the Amazon S3 servers did not configure them correctly. This issue is not new, as this oversight has occurred several times to high level organizations within the last 12 months. The researcher who did find this lack of security did act responsibly and contacted the DoD. The Amazon services and databases were appropriately secured soon thereafter.
When working with the public's data, there is a certain level of responsibility and accountability. With the resources available at the DoD, this should not have happened. Regardless this oversight was corrected. The lessons to pull from this episode are many, which may be applied to other's workplaces. The person's with the appropriate level of knowledge and skills on topic should be doing the work. Simply pulling someone without the requisite level of skill is not a good idea. Once implemented, test the work done to ensure it actually works. Without this, the hope is the work was done correctly.

Connected Vehicles: Android presents another issue

A new or newer car is a significant investment for most. As a rule of thumb most people don’t have the ability to write a check for one of these vehicles. One of the selling points to entice the new buyers has been the connected features of the vehicles. Although this aspect is well-known, this feature uses a smartphone application to connect the smartphone to the vehicle. This application turns the smartphone into a remote control for the vehicle. The owner is also able to interact with the internet through the head unit (HU) of the vehicle. With all of this connectivity there are several functions, including, the user is able to start the car in January from their office, lock/unlock the vehicle doors from virtually anywhere, access music, and a number of other functions which are  benefit to the user. This appears to be a great function. There are however issues to be resolved.

Issue
The security on this topic has tended to be overlooked with this area. The smart phone and vehicle applications have tended to be under-researched and studied. This is and continues to be evidenced by this connection and attack points historically being an issue and compromised in relatively many of the manufacturers. Kaspersky Labs elected to test seven of these applications native to the Android platform engineered to interact with the vehicles. These are Android applications, however are coed by the car manufacturers and third party dev op teams.

The sample consisted of seven applications. The target points for this experiment were reverse engineering of the application, if the GUI was adequately secured, if there was an integrity check with the application, and if encryption was applied to the user name and password. The research indicated the application code was not obfuscated, the username and password were not encrypted, there was no application integrity checks, and other insecure features. These applications did not incorporate even the basic security features. The applications and manufacturers were not noted as the researchers did not want these to be targeted by the attackers. This experiment also indicated the systems were open to credential theft.

Analysis
The applications basically controlled access to the vehicle and its functions, acting as a gate. Unfortunately the gate was not locked and the handle easily lifted. A deviant and attacker would be able to gain access to the vehicle’s interior using these insecure features. From here, the attacker would be able to steal the vehicle. As noted this is a rather blatant issue that has been problematic for years with many different manufacturers.

Closing
The vehicle has a great amount of respect for the vehicle. The owner and user do not want the vehicle to be vandalized and stolen. When the owner purchased the vehicle they bargained for, the person was not expecting the connectivity and application to be insecure and open to a form of vandalism. The level of insecurity allows for the vehicle to be attacked from many points. This could have been remediated with better planning or coding.



Resources
Greenberg, A. (2017, February 16). Android phone hacks could unlock millions of cars. Retrieved from https://www.wired.com/2017/02/hacked-android-phones-unlock-millions-cars/

Kuzin, M., & Chebyshev, V. (2017, February 16). Mobile apps and stealing a connected car. Retrieved from https://securelist.com/analysis/publications/77576/mobile-apps-and-stealing-a-connected-car

Zorz, Z. (2017, February 17). Insecure car-controllering android apps are a boon for car thieves. Retrieved from https://www.helpnetsecurity.com/2017/02/17/insecure-car-controlling-android-aps/

Bosch Dongle Issue

Earlier this year, a vulnerability was discovered with the Bosch Drivelog. This was noted by the Argus Cyber Security Research. The hardware with this consists of a dongle connected to the OBDII port, which is only supposed to gather data regarding the vehicle’s operations (current status, fuel consumption, error messages, and other messages for the driver). As the data is collected, it is communicated to the user’s mobile application via the Bluetooth. This would be available on the Android and iOS platforms. The researchers, in this case, focused on the Android. This affects the dongle firmware with version 4.8.0 through 4.9.2 and the Drivelog app versions through and including 1.1.

Works via…
In theory, the sole purpose of this would be to provide the user with the vehicle’s information. The equipment, however, can be exploited and malicious code streamed to the vehicle’s CANBus. Argus Research analyzed the communication between the dongle, connections to the vehicle, and the mobile app. There were two rather significant vulnerabilities found with this. With the first, within the communication channel there was a data leak. This led to an issue with the authentication between the dongle and mobile app. With the second, there was a lapse of security with certain portions of the dongle. In this case, there issue was specifically with the message filter.

The CANBus should only receive diagnostic messages with a valid service ID. The vulnerability allowed the attacker to send messages specific to the OEM to the CANBus, affecting the vehicle. The message format and function may be surmised by simply monitoring the CANBus traffic. The attack may be done when the attacker gains root on the user’s phone. Once this is in place, the attacker is able to bypass the filter and send the malicious messages. The attack can also be done without rooting the user’s smart phone. The vulnerability is with the authentication process with the dongle and the mobile app. The PIN has eight digits with 100M possible PINs with SHA 256. A laptop is able to run 100M SHA 256 computations and encryption in 30 minutes with the proper software. The process can be shortened further with parallel processing.

When exploited…
This exploit, when achieved, has serious implications for the driver and passengers. One of the more significant effects would be, while the vehicle is moving, to stop the engine. There would be more available attacks with this.

On the bright side, the attack is not scalable. With this the attacker has to be proximate to the dongle.

Remediation
The issue is difficult to remediate due to the user’s phone being in the loop. The 3rd party has no interest in the phone or control. In theory, the phone could be rife with malware and viruses, and there is little the 3rd party could do to resolve this. To increase the complexity the attackers don’t necessarily need to use the phone as the vulnerable point in the attack. To remediate this however, Bosch did implement TFA, which would remove a portion of the risk.

Resources
Argus. (2017, April 14). Argus cyber security unearths security vulnerabilities in bosch’s drivelog connector dongle. Retrieved from http://telematicsnews.info/2017/04/14/argus-cyber-security-unearths-security-vulnerabilities-in-boschs-drivelog-connector-dongle/

Bosch PSIRT. (2017, April 13). Bosch drivelog connector. Retrieved from https://psirt.bosch.com/Advsory/Bosch-2017-0201.html

Cimpanu, C. (2017, April 24). Flaws in car dongle will let hackers stop your car’s engine. Retrieved from https://www.bleepingcomputer.com/news/security/flaws-in-car-dongle-will-let-hackers-stop-your-cars-engine/

King, J. (2017, April 14). Bosch patches security vulnerability in drivelog OBD-II dongle. Retrieved from http://www.leftlanenews.com/bosch-patches-drivelog-obdii-dongle-after-vulnerability-found-95511.html

Kovacs, E. (2017, April 14). Flaws in bosch car dongle allow hackers to stop engine. Retrieved from http://www.securityweek.com/flaws-bosch-car-dongle-allow-hackers-stop-engine

Kovelman, A. (2017). A remote attack on the bosch drivelog connector dongle. Retrieved from https://argus-sec.com/remote-attack-bosch-drivelog-connector-dongle/

Mimoso, M. (2017, April 19). Patched flaw in bosch diagnostic dongle allowed researchers to shut off engine. Retrieved from https://threatpost.com/patched-flaw-in-bosch-diagnostic-dongle-allowed-researchers-to-shut-off-engine/125061/

Paganini, P. (2017, April 16). Flaws in the bosch drivelog connector dongle could allow hackers to halt the engine. Retrieved from http://securityaffairs.co/wordpress/58039/hacking/flaws-bosch-drivelog.html

Tech Time. (2017, April 20). Argus cyber took over a car critical systems via Bluetooth. Retrieved from http://news.techtime.co.il/2017/04/20/argus-cyber/

MedSec v. SJM: Insecure Pacemakers

            People throughout the globe have health issues with various parts of their bodies and in differing degrees. These may be acute or chronic, or life threatening. An issue that is present involves cardiac problems. For persons with cardiac issues, a defibrillator/pacemaker is vital and works best with the patient. There are a number of manufacturers of this product, with each having several models. As the patients require these to live, in case there were to be an issue, if an attacker were to compromise a unit, the patients could be placed in mortal peril. The unit being compromised may also allow for unauthorized access of protected health information (PHI) (White, 2015). This could provide for a HIPAA violation (Kohgadai, 2016). This issue could be a very costly learning opportunity for the manufacturer. Medical records are prime targets for the attackers. When there happens to be a compromise of this type, merely the fines are massive. This does not however factor in the costs for forensic work to review the incident.

            With these devices, there has been any issue with this being a known issue, yet net addressed by the manufacturer. The data indicates the manufacturer are unprepared in the area. A survey completed in 2017 from the Ponemon Institute on behalf of Synopsys indicated only 17% of the manufacturers have worked towards appropriate cyber security controls (Dellinger, 2017). This lack of focus is due to many issues, including but not limited to the lack of adequately trained staff, senior management not appreciating the short- and long-term financial and operational risks, issues with testing and other significant issues.

History

            Medical connected devices have been present and in use for decades. Consumers have presented the need for assistance with bodily functions. Although these were designed with the best intentions and functionality in mind, there were still issues with the equipment. From 1990-2000, the FDA issued recalls on 114,645 devices (Burns, Johnson, & Honeyman, 2016). As security has become more of an issue, there have been more presentations and security-oriented developments. On August 4, 2011 Jerome Radcliffe presented at Black Hat a compromise for an insulin pump. As a diabetic, he was acutely aware of. Radcliffe was able to reverse engineer the communication protocols. With this protocol in hand, he was able to access the pump and control it (Burns, Johnson, & Honeyman, 2016). On October 17, 2012, Barnaby Jack presented a video at the Ruxcon Breakpoint Security Conference showing the method to direct a pacemaker to deliver a shock using the serial and model number.

            A recent example of the effect from a lack of security was with Johnson & Johnson. In 3Q2016, Johnson & Johnson informed 14k doctors and diabetic patients of three vulnerabilities in their Animus insulin pumps. These and many more examples abound as security is not applied to these.

            In 2013, Barnaby Jack was supposed to present a compromise on a pacemaker at a hacker conference in Las Vegas. He passed on the evening prior.

Normal Process

            As with piece of equipment there is a standard process for the device to work. Millions of people depend on the devices across the globe (Wadhwa, 2012). As this is the case, the tolerances and parameters have to be narrowly construed. Most pacemakers have their data retrieved and settings configured via a wand or other device being placed proximate to the pacemaker. This may be relatively close or within a few feet of the device. The apparatus retrieves the data and makes adjustments to the sensors, thresholds, and rates (Lyle, 2015).

            This remote access is significantly beneficial. The patient can’t have a USB through their chest wall and skin. This also allows for simple adjustments. This is a simple way to collect data used by doctors and medical to aid the patients (Knapton, 2014). If there were need to be adjustments to the equipment, this may be done over-the-air (OTA) (Wadhwa, 2012).

Worst Case Scenario

            Anytime there is a death or disability, this is not the optimal situation and a shame. Many people have pacemakers and defibrillators through society. These persons work as mechanics, teachers, professors, CEOs, CFOs, diplomats, dignitaries, Presidential Cabinet members, and nation leaders.

            In a case shown in a recent dramatized television program, a political figure has the pacemaker/defibrillator implanted. The person is arriving for a meeting. Another group would prefer the person with the implanted device not to be using oxygen anymore. If it were to be possible to compromise the pacemaker, by extension it would be possible to assist the person with their transition. Although this is a simple case and application, this scenario could upgraded to a Secretary of State.

Regulation

“I have no problem with science…I just wish that it would give the law time to catch up.”

~Law & Order-Seed; 2/15/95, S5 E15

            It is difficult at best to couple InfoSec with the law. The wheels of justice and law move incredibly slow. Most legislators have minimal ideas of what is going on with InfoSec other than the sound bites and headlines. There also has tended to be a rather firm process in place to enact legislation, which is exceptionally unfriendly to change.

            In comparison, the InfoSec community moves rather quickly. This seems to change daily. There, procedurally with the process in place, is no way for the legal system to keep pace. This is unfortunately the reality.

            The FTC has attempted to start the legal process. There were generic proposals in 2013 (Armstrong, Kleidermacher, Klonoff, & Slepian, 2016). When a business engineers an IoT device, this should implement a suitable level of security. Per this endeavor, the data collected should be minimal, the data retained should be minimal, and other measures. This is weak, but a start.

Applicable to Other Equipment

            This issue is not limited to pacemakers. This also is completely applicable to most other connected medical device. The manufacturers need to understand not only the intended processes with the equipment, but also the hazards and potential harm with a lack of security being applied. The manufacturers need to define these risks with the system and put controls in place (Wu & Eagles, 2016). This risk analysis should complete a risk analysis based on the applicable standards.

            As a secondary point, to mitigate these issues the manufacture needs to review the controls related to the technical side of the product. This team effort of review and implementation would produce a document. This would involve applying the appropriate form and level of governance (Williams & Woodward, 2015). To have the optimal situation, this step would need to be proactive.

            There are several real-world examples of this. In 2016, Johnson & Johnson informed their clients of vulnerabilities. A model of their insulin pumps exhibited a vulnerability which would allow access to the insulin pump. In theory, an unauthorized party could direct the insulin pump to input a fatal dose of insulin. The vulnerable model was the Animas One Touch Ping. The distinct vulnerability was partially due to the equipment being connected (Harper, 2017).

            In 2015, there was an issue with the Hospira Sybiq infusion pump. The vulnerability here also allowed an unauthorized access. This however was through the hospital’s network (Harper, 2017). Lastly, in 2013, Barnaby Jack was to give a presentation on the methodology to compromise a pacemaker at a security conference in Las Vegas. The attack could take place up to 50 feet away. He passed on the night before the presentation (Harper, 2017).

St. Jude Medical (SJM) Lawsuit

            As a rule of thumb, a lawsuit is the last stage of the confrontation. Once this is filed, the situation becomes rather expansive in terms of finances, and funding. Most entities would have worked with SJM (Dark Reading, 2016). In the past, however, SJM brushed off attempts to fix the issues and patch management. MedSec elected to work with Muddy Waters in disclosing the issues (Dark Reading, 2016). MedSec stated the pacemaker and defibrillator could be compromised and manipulated (Pierson & Finkle, 2016) via the equipment vulnerabilities (Osborne, 2016). MedSec also stated that SJM should recall its pacemakers as these were vulnerable to attack (Tucker, 2016). These vulnerabilities were relative to the pacemaker and defibrillator were detailed in the report. (Nichols, 2010). These were rather significant (News-checker, 2016).This would allow the pacemaker to malfunction (Tucker, 2016).

            SJM sued Muddy Waters Consulting LLC, Muddy Waters Capital LLC, MedSec Holdings, Ltd., MedSec LLC, and the three persons who were principals in the businesses (Business Wire, 2016; Dark Reading, 2016; Tucker, 2016). The matter was filed in the USDC for the District of Minnesota as the St. Jude Medical v. Muddy Waters, MedSec Holdings, et al. with case number 16-cv-0302 (Pierson & Finkle, 2016). The full filing may be viewed at https://regmedia.co.uk/2016/09/08/medsec_lawsuit.pdf.

            The claimed cause of action was the defendants defamed SJD with false information (Dark Reading, 2016) and intended to be malicious (Pierson & Finkle, 2016). SJM stated these were false warnings (Osborne, 2016). In particular, the cause of action were the false statements, false advertising, conspiracy, and manipulation of the public market (Business Wire, 2016; Tucker, 2016). In short, SJM sued MedSec, et al. to correct the alleged false information that had been provided to the media (Osborne, 2016).

            As a result of the disclosures and/or the lawsuit, the SJM shares decreased significantly (Dark Reading, 2016). The stock share price was lowered an estimated 10% during the day and rebounded so the net effect was only an estimated decrease of 3% (Pierson & Finkle, 2016). SJM claimed the attackers only did this to provide a profit to the firm (Kan, 2016).

            SJM had a rather distinct focus on the MedSec and Muddy Waters groups. SJM claimed the research and investment firms were false (Nichols, 2016), had applied flawed testing methods, used outdated software, and simply did not understand the medical device technology (Osborne, 2016; Kan, 2016).   SJM stated MedSec’s claims were made-up (Nichols, 2016). SJM went as far as to retain the University of Michigan to attempt to replicate the study. The UM research team arrived as a different result. The research team at UM stated MedSec’s research was flawed and UM could find no evidence to support the claims (Tucker, 2016; Newmarker, 2016).

            MedSec’s defense was rather simple. The disclosure was correct (Dark Reading, 2016) and the University of Michigan research team was wrong. Arising from this set of issues was a class action lawsuit against SJM (Daniels, 2016). The cause of action for the class action lawsuit was a failure to adequately secure the equipment with the remote tracking function (Daniels, 2016).

Insecurity

            No product is 100% perfect. A dedicated set of engineers collaborating with the InfoSec staff have the opportunity to create a product that has the appropriate safety and security features built in. There are other instances however when this is not the case and the security is not appropriately applied. This is especially an issue when the device is attached to a person via being implanted (Wadhwa, 2012) and a connected device, as the results from an attack may be deadly (Knapton, 2014).

            These connected devices have been known to be insecure by the industry and manufacturers. The manufacturers have not overall been working diligently to secure these. A few distinct manufacturers also have declared their devices are perfectly safe to the public. The primary attack point has been the wireless communication. This acts to regulate the devices assisting the human heart to function properly (Knapton, 2014). This is an area of vulnerability to be exploited. The manufacturers simply have not been prepared (Wadhwa, 2012) and security not integrated (Zorz, 2016).

            The lack of security has even gathered the attention of the U.S. Department of Homeland Security (DHS). In 2014 the DHS began to investigate more than 20 medical devices (Knapton, 2014). In 2013, the DHS Industrial Control Systems Cyber Emergency Response Team (OCS-CERT) noted approximately 300 devices manufactured by 40 companies (Knapton, 2014). The examples for the  vulnerabilities abound. Each manufacturer and product line has the potential for vulnerabilities. These have exhibited insecure architecture, hard-coded passwords that were not able to be changed, and other insecure protocols. As for the passwords, this would allow an unauthorized third party to access the machine (Knapton, 2014).

MedSec

               In pacemakers alone, there has been noted more than 8,000 vulnerabilities in the program code (Vaas, 2017). This sample was from four manufacturers. This number does not represent a majority of the manufacturers present in the market.

               This also applies to the MedSec issues. The vulnerabilities were blatantly present, yet not acted on by SJM. The security was so poor that the FDA threatened legal action against SJM if these vulnerabilities were not addressed. This was significant to the extent the FDA and DHS both issued a notice or warning letter of these insecurities (Uchill, 2017). SJM, on the same day as the notice, noted these were “extremely low cyber-security risks” (Vaas, 2017). MedSec did push the patches for this set of issues (Carlson, 2017).

               There were a number of vulnerabilities with the pacemaker product. These included:

·        A lack of strong authentication (Daniels, 2016).

·        Commands may be issued from a distance.

·        SJM included a code which could be used for the purpose of over-riding. This was a fixed 3byte code.

·        The communications channel between the endpoints (pacemaker and the Merlin@home base unit) was weak (Vaas, 2017; Brenner, 2017; Daniels, 2016).

·        A 3-byte back door was left open.

·        Poor level of encryption.

·        The anti-debugging tools were weak.

In Closing…

               Medical devices are pertinent to our lives and will continue to grow in usage and visibility. These should not be treated as just another piece of equipment, but as a device that has to be secured. Without this security, adequately and appropriately in place, the potential for compromises will be there, waiting to be implemented.

References and Resources

Ahmadi, M. (2017). FDA and medical industry fear ware of medical-device hacks. Retrieved from http://www.informationsecuritybuzz.com/expert-comments/fda-medical-industry-fear-wave-medical-device-hacks/

Armstrong, D.G., Kleidermacher, D.N., Klonoff, D.C., & Slepian, M.J. (2015). Cybersecurity regulation of wisdom devices for performance and assurance in the age of “medjacking”. Journal of Diabetes Science and Technology, 10(2), 435-438. doi:10.1177/1932296815602100

BBC. (2016). Medical device cyber-safety rules issued by US watchdog. Retrieved from http://www.bbc.com/news/technology-38458864

Bethell, M. (2016, October 19). Cyber hackers threatens security of lifesaving medical devices. Retrieved from http://www.dailytech.com/Cyber+Hack+Threaten+Security+of+Lifesaving+Medical+Devices+/article37716.htm

Brenner, B. (2017, January 23). St. Jude case highlights ongoing divide over ‘responsible bugs disclosure’. Retrieved from https://nakedsecurity.sophos.com/2017/01/23/st-jude-case-highlights-ongoing-divide-over-responsible-bugs-disclosure

Burns, A.J., Johnson, M.E., & Honeyman, P. (2016). A brief chronology of medical device security. Communications of the ACM, 59(10), 66-72. doi:10.1145/2890488. Retrieved from http://cacm.acm.org/magazine/2016/10/207766-a-brief-chronology-of-medical-device-security/fulltext

Business Wire. (2016, September 7). St. jude medical brings legal action against muddy waters and medsec. Retrieved from http://www.nasdaq.com/press-release/st-jude-medical-brings-legal-action-against-muddy-waters-and-medsec-20160907/00282

Business Wire. (2017, January 9). St. jude medical announces cybersecurity updates. Retrieved from http://www.businesswire.com/news/home/20170109005921/en/st.-jude-medical-announces-cybersecurity-updates

Carlson, J. (2017, January 10). FDA says st. jude heart devices vulnerable to hacking. Retrieved from http://www.startribune.com/fda-says-st-jude-heart-devices-vulnerable-to-hacking/410153595/ 

Castellucci, M. (2016, October 18). St. jude medical steps up cybersecurity measures after questions about device safety. Retrieved from http://www.modernhealthcare.com/article/20161018/NEWS/161019901

CBS News. (2017, January 10). U.S. warns of security flaw that could allow hackers control of heart devices. Retrieved from http://www.cbsnews.com/news/cybersecurity-flaw-that-could-allow-hackers-control-of-heart-devices-united-states-warns/

Center for Devices and Radiological Health. (2002, January 11). General principles of software validation; Final guidance for industry and FDA staff. Retrieved from http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM085281.html

Centerwatch. (2016, Septembe 12). St. jude medical sues muddy waters and medsec. Retrieved from https://www.centerwatch.com/news-online/2016/09/21/st-jude-medical-sues-muddy-waters-medsec/

Cherry, S. (2013, April 30). Hacking pacemakers. Retrieved from http://spectrum.ieee.org/podcast/biomedical/devices/hacking-pacemakers

Claburn, T. (2008, March 12). Three medical schools demonstrate the wireless dangers that can disturb an implantable cardioverter defibrillator like the medtronic maximo DR. Retrieved from http://www.informationweek.com/pacemakers-vulnerable-to-hacking/d/d-id/1065618

Cloud Security Alliance. (2016, October 6). HIPAA violations examples and cases-Eight cautionary tales. Retrieved from https://blog.cloudsecurityalliance.org/2016/10/06/hipaa-vioations-examples-cases-eight-cautionary-tales/

Cluley, G. (2016, December 1). Under attack: How hackers could remotely target your pacemaker. Retrieved from https://www.tripwire.com/state-of-security/featured/under-atack-how-hackers-could-remotely-target-your-pacemaker/#

Cluley, G. (2017, January 10). Security scare over hackable heart implants. Retrieved from http://www.welivesecurity.com/2017/01/10/security-scare-hackable-heart-implants/

Daniels, M. (2016, August 29). St. jude heart devices have security weaknesses, suit says. Retrieved form http://www.law360.com/articles/833622/st-jude-heart-devices-have-security-weakness-suit-says

Dark Reading Staff. (2016, September 7). Medical device vulnerability-Disclosure flap intensifies. Retrieved from http://www.darkreading.com/vulnerabilities-threats/st-jude-sues-muddy-waters-medec/d/d-id/1326837

Data Breach Today. (2016, January 18). FDA issues more medical device security guidance. Retrieved from http://www.databreachtoday.com/fda-issues-more-medical-device-security-guidance-a-8805

Dellinger, A.J. (2017, May 30). Medical device makers expect attacks within the next year, but aren’t prepared. Retrieved from http://newsweek.com/medical-device-safety-can-they-be-hacked-companies-manufacturers-concerned-617507

Densford, F. (2017, January 9). St. jude releases FDA-cleared merlin@home cybersecurity update. Retrieved from http://www.massdevice.com/st-jude-releases-fda-cleared-merlinhome-cybersecurity-update/

FDA. (2016). Cybersecurity. Retrieved from http://www.fda.gov/MedicalDevices/DigitalHealth/UCM373213.htm

Finkle, J. (2017, January 9). St. jude heart devices get cyber security updates after probe into hack vulnerability. Retrieved from http://www.huffingtonpost.com/entry/st-jude-heart-devices-get-cyber-security-updates-after-probe-into-hack-vulnerability_us_5873d482e4b099cdb0fea482

Halperin, D., Heydt-Benjamin, T.S., Ransford, B., Clark, S.S., Defend, B., Morgan, W., Fu, K., Kohno, T., & Maisel, W. (2008). Pacemakers and implantable cardiac defibrillators: Software radio attacks and zero-power defenses. 2008 IEEE Symposium on Security and Privacy, 1-14. Retrieved from http://www.secure-medicin.org/public/publications/icd-study.pdf

Harper, C. (2017, April 10). FDA, industry fear wave of medical-device hacks. Retrieved from http://thehill.com/policy/healthcare/328120-fda-industry-fear-wave-of-medical-device-hacks

Hatmaker, T. (2016, December 28). FDA issues new security guidelines so that your pacemaker won’t get hacked. Retrieved from https://techcrunch.com/2016/12/28/fda-issues-new-security-guidance-so-that-your-pacemaker-wont-get-hacked/

Help Net Security. (2016, October 19). Securing medical devices: Cybersecurity spending to triple by 2021. Retrieved from https://www.helpnetsecurity.com/2016/10/19/securing-medical-devices/

HIMSS. (2013). Medical device security. Retrieved from http://www.himss.org/medical-device-security

Ismail, N. (2017, April 3). IoT to improve the programming of implantable devices. Retrieved from http://www.information-age.com/iot-impreve-programming-implantable-devices-123465487/

Ismail, N. (2017, April 11). Medical devices at severe risk of hack attacks. Retrieved from http://www.information-age.com/medical-devices-severe-risk-hack-attacks-123465684

Kan, M. (2016, August 29). Medical device security disclosure ignites an ethics firestorm. Retrieved from http://www.computerworld.com/article/3113385/security/medical-device-security-ignites-an-ethics-firestorm.html

Khandelwal, S. (2017, June 5). Over 8,600 vulnerabilities found in pacemakers. Retrieved from http://thehackernews.com/2017/06/pacemaker-vulnerability.html

Knapton, S. (2014, November 6). Terrorists could hack pacemakers like in homeland, say security experts. Retrieved from http://www.telegraph.co.uk/news/science/science-news/11212777/Terrorists-could-hack-pacemakers-like-in-homeland-say-security-experts.html

Kohgadai, A. (2016, October 6). HIPAA violations examples and case-Eight cautionary tales. Retrieved from https://blog.cloudsecurityalliance.org/2016/10/06/hipaa-violations-examples-cases-eight-cautionary-tales/

Jones, D., & Rushing, S. (2016). HIPAA compliance-not just an issue for healthcare providers. Retrieved form http://www.jdsupra.com/legalnews/hipaa-compliance-not-just-an-issue-for-31185/

Lemos, R. (2017, May 18). Embedded windows medical ‘devices’ infected by wannacry ransomware. Retrieved from http://www.eweek.com/security/embedded-windows-medical-devices-infected-by-wannacry-ransomware

Lyle, D.P. (2015, January 14). Hacking pacemakers for murder no longer the perfect crime. Retrieved from https://writersforensicsblog.wordpress.com/2015/01/14/hacking-pacemaker-for-murder-no-longer-the-perfect-crime/

Marin, E., Singelee, D., Garcia, F.D., Chothia, T., Willems, R., & Preneel, B. (2016). On the (in)security of the latest generations implantable cardiac defibrillators and how to secure them. ACSAC. doi:http://dx.doi.org/10.1145/2991079.2991094

McGee, M.K. (2016). FDA issues more medical device security guidance. Retrieved from http://www.databreachtoday.com/fda-issues-more-medical-device-security-guidance-a-8805

Moon, M. (2016, December 28). FDA issues final guidance on medical devices’ cybersecurity. Retrieved from https://www.engadget.com/2016/12/28/fda-medical-devices-cyber-security-final-guidance/

Muddy Waters Capital LLC. (2016, August 25). Muddy waters research. Retrieved from http://d.muddywatersresearch.com/wp-content/uploads/2016/08/MW_STJP_08252016_2.pdf

Newmarker, C. (2016, September 7). St. jude sues over cybersecurity accusations. Retrieved from http://www.qmed.com/mpmn/medtechpulse/st-jude-sues-over-cybersecurity-accusations

Nichols, S. (2016, September 7). St. jude sues short-selling MedSec over pacemaker hack report. Retrieved from http://www.theregister.co.uk/2016/09/07/st_jude_sues_over_hacking-claim/

Osborne, C. (2016, September, 8). MedSec sued over st. jude pacemaker vulnerability report. Retrieved from http://www.zdnet.com/article/medsec-sued-over-st-jude-pacemaker-vulnerability-report

Pierson, R., & Finkle, J. (2016, September 7). St. jude sues short-seller over heart device allegations. Retrieved from http://whtc.com/news/articles/2016/sep/07/st-jude-sues-muddy-waters-medsec-over-heart-device-allegations/

Regmedia. (2016, September 8). St. Jude Medical, Inc. vs. Muddy Waters Consulting, et al. Retrieved from https://regmedia.co.uk/2016/09/08/medsec_lawsuit.pdf

Sayer, P. (2016, December 1). Implantable medical devices can be hacked to harm patients. Retrieved from http://www.computerworld.com/article/3146215/security/implantable-medical-devices-can-be-hacked-to-harm-patients.html

Snell, E. (n.d.). How ransomware affects hospital data security. Retrieved from http://healthitsecurity.com/features/how-ransomware-affects-hospital-data-security/

Slabodkin, G. (2017, February 22). Ransomware emerging as medical devices cybersecurity threat. Retrieved from https://www.information-management.com/news/

Sorrel, C. (2008, March 12). Scientists demonstrate deadly wifi pacemaker hack. Retrieved from https://www.wired.com/2008/03/scientists-demo/

Spring, T. (2016, October 24). St. jude faces new claim heart implants are hackable. Retrieved from https://threatpost.com/st-jude-faces-new-claim-heart-implants-are-hackable/121504/

Stanford, J. (2017, June 12). Hacking a heart pacemaker isn’t science fiction. See what experts are doing to prevent it. Retrieved from http://www.azcentral.com/story/news/local/phoenix/2017/06/12/hacking-pacemaker-isn’t-science-fiction-movie-plotlline-but-reality/378176001

Storm, D. (2015, September 8). Researchers hack a pacemaker, kill a man (nequin). Retrieved from http://www.computerworld.com/article/2981527/cybercrime-hacking/researchers-hack-a-pacemaker-kill-a-man-nequin.html

St. Jude Medical. (2016, September 7). St. jude medical brings legal action against muddy waters and medsec. Retrieved from http://media.sjm.com/newsroom/news-releases/news-releases-details/2016/St-Jude-Medical-Brings-Legal-Action-Against-Muddy-Waters-and-MedSec/default.aspx

Sullivan, C. (2016, October 6). How to mitigate data breaches in health IT. Retrieved from http://www.information-management.com/news/security/how-to-mitigate-data-breaches-in-health-it-100299441.html

Sun, L.H., & Dennis, B. (2013, June 13). FDA, facing cybersecurity threats, tightens medical-device standards. The Washington Post.

Thompson, J. (2016, October 27). It is shocking! Even heart devices can be hacked. Retrieved from http://www.newseveryday.com/articles/50840/20161027/it-is-shocking-even-heart-devices-can-be-hacked.htm

Tucker, A. (2016, September 7). St. jude medical filed a lawsuit against MedSec and muddy waters. Retrieved from http://www.legalreader.com/st-jude-medical-files-lawsuit-against-medsec-and-muddy-waters/

Uchill, J. (2017, April 13). FDA threatens action against medical device-maker over poor cybersecurity. Retrieved from http://thehill.com/policy/cybersecurity/328752-fda-threatens-st-jude-medical-device-over-poor-cybersecurity

U.S. Department of Health and Human Services. (2002, January 11). General principles of software validation; Final guidance for industry and FDA staff. Retrieved from http://www.fda.gov/MedialDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm085281.html

Vaas, L. (2017, January 12). Pacemakers patched against potentially life threatening hacks. Retrieved from https://nakedsecurity.sophos.com/017/01/12/pacemakers-patched-against-potentially-lifethreatening-hacks/

Vaas, L. (2016, May 30). Security of medical devices ‘is a life or death issue’, warns researcher. Retrieved from https://naked security.sophos.com/2017/05/30/security-of-medical-devices-is-a-life-or-death-issue-warns-researcher/

Wadhwa, T. (2012, December 6). Yes, you can hack a pacemaker (and other medical devices too). Retrieved from http://www.forbes.com/sites/singularity/2012/12/06/yes-you-can-hack-a-pacemaker-and-other-medical-devices-too/#52bd766613e0

White, J. (2015, October 5). Why medical device security should be top priority. Retrieved from http://www.healthcarebusinesstech.com/medical-device-security/

Williams, P.A., & Woodward, A.J. (2015). Cybersecurity vulnerabilities in medical devices: A complex environment and multi-faceted problem. Medical Devices: Evidence and Research, 8, 305-316. doi:10.2147:MDER.S50048

Wolf, D., Chernuch, M.S., Diamond, J. (writers), & Scardino, D. (producer). (1995). Law & order-Seed. (S5 E15). Law & Order. Atlanta, GA: TNT.

Wu, F., & Eagles, S. (2016). Cybersecurity for medical device manufacturers: Ensuing safety and functionality. Biomedical Instrumentation & Technology, 50(1), 23-34.

Zorz, Z. (2016, December 1). Insecure pacemakers can be easily hacked. Retrieved from https://www.helpnetsecurity.com/2016/12/01/insecure-pacemakers-easily-hacked/

Zorz, Z. (2017, January 12). FDA urges patients to implement patch to secure their cardiac implants. FDA urges patients to implement patch to secure their cardiac implants. Retrieved from https://www.helpnetsecurity.com/2017/01/12/secure-cardiac-implants/

Insecure Hardware is a Global Issue

            Insecure hardware is a massive issue for many parties. The insecure affects not only the individual or business as they use computers in the home and office, but also the internet as a whole. This is an issue for the equipment and the engineers responsible for the development of the equipment. For the equipment owner, they could now have as one of their assets compromised piece of equipment. This would be connected to the network and possibly other systems in the business or home. The equipment may be used for the normal, intended purpose (e.g. payroll, accounts receivable, and other vital functions). This may also be used for nefarious purposes at the same time, unbeknownst to the owner.

            This may sound prima facie a bit far-fetched, evoking the thought for the consumer of “This would not happen to me.” What would anyone want with an IP camera or route from a grandma in Nebraska? The focus would be potential unauthorized usage by the persons or people who code bots to leverage the capabilities of these to attack other systems. These attacks have been with the purpose of securing more IoT devices to build the bot army, which would then be directed at their target. In the last year there have been too many examples of this. There have been massive DDoS attacks on Krebs on Security and Deutsche Telekom, as two well-known examples. These and many more represent the significant DDoS attacks by Mirai and Persirai malware, among others.

            The insecure equipment has turned into a potential malware tool for their targets when executed. The consumers as a whole and the IT industry would hope this would be a minor idea, not generally in use, and not affecting many units. Unfortunately, this is not the case. This continues to be an issue as more of these insecure assets are compromised and used as part of the bot army.

            This issue is global in nature and effect. The scope is by far not limited to the US. The products, regardless of where they are made, and manufactured and sent across the globe, insecure and all. The remediation for this is relatively simple, but taxing in its application. The equipment needs to have more security features in place. Also any default passwords should be required to be changed. These small steps would remove much of the security issues with this.

Bug bounty programs: Slots difficult to fill

            The need for bug bounty programs began years ago as a void formed. The manufacturers were producing their goods and services, as to be expected. An issue experienced was the manufacturers had the “first to market” mentality in place. There was and continues to be in certain markets, a hurry to design, engineer, and manufacture the product. The product needs to be the first in the marketplace for the consumer to purchase the unit. In theory, the manufacturer would be the market leader, and sell the maximum number of units and gain the market share. If the manufacturer were to wait, they would not be maximizing the sales volume and would be trying to catch up with their peers. This sales process methodology is unfortunately still prevalent. As of late this has been noted with routers, IP cameras, and other like equipment.

With these and other products security architecture was applied in various levels. This ranged from very little, with too many of the IoT products, to a moderate level of security applied. A contributing factor to this has been the lack of information security talent. This is a function of the limited number of programs focused on this, newer programs not coming online at a quick enough pace, and a time lag once these are in place of at least three years prior to graduates entering the workforce.

One area growing in importance is vehicle security. The number of vehicles with embedded systems continues to grow. The autonomous vehicles are actively being tested on the roads used by other people presently. These vehicles are expected to be in full production within five years. These systems are being developed with the focus of having them operational in a timely manner with security being a secondary focus.

With the growing need for information security (InfoSec) professionals, there is an issue. In this specialty, there is a limited number of people that have the knowledge and expertise to attack the embedded systems in a vehicle. Most firms in this specialty do not allow their personnel to contribute to these bug bounty programs (Gray, 2017). This appears to be starting to relax, but is still a parameter to overcome.

With a bug bounty program, the sponsoring firm is able to add to their baseline of security. With vehicles, there are ample areas to research. The connected and autonomous vehicles in use today tend to be more computers on wheels than anything. From an administrative side, a bug bounty program is easier with a vehicle that has been sold for years. This allows for more vehicles and modules to be tested, as there are more vehicles on the lots and junkyards. With the new vehicles an issue could be, dependent on the circumstances, the cost. The new vehicles cost upwards of $30k new. The internal client may not want to part with two or three vehicles due to this constraint on their budget. With the junkyard vehicles, these may not have all the original equipment due to an accident or other force, however many of the modules would be intact and perfectly testable.

There is much to do with InfoSec and vehicles. This subfield of InfoSec is growing by leaps and bounds. More of the manufacturers are producing more connected vehicles, applications, and hardware. The bug bounty programs are a welcome addition to the InfoSec environment for those manufacturers that without an internal testing program. This has and will continue to provide knowledge re: the vulnerabilities that may not normally be found.

Reference

Gray, P. (2017, July 2). Biz soap box: Bugcrowd founder and CEO casey ellis on the future of crowd sourced security. Retrieved from https://risky.biz/

BlueBorne: Uh oh.

            Bluetooth has been in use in the public for well over a decade. Previous attacks focused on the insecurity of the Bluetooth protocol. The new attack, BlueBorne, is unique in its approach for this time junction.

            This attack is rather substantial in its potential reach for targets. This may affect anywhere from 5.3B (Khandelwal, 2017; Moscaritolo, 2017) to 8.2B devices worldwide (Zorz, 2017) with iOS, Android, Windows, and Linux OS devices with Bluetooth enabled. This is due to its agnostic focus on the Bluetooth process itself, in comparison to the various platforms.

            The user does not have to be a victim of malware for the attack to be successful. The user does not have to download a file or link, click anything, or do anything to be a victim. The only prerequisite is for the Bluetooth to be enabled and on (Zorz, 2017; Khandelwal, 2017; Rascal23, 2017) and proximate to the attacker (Khandelwal, 2017). This distance would need to be less than 32 feet (Goodin, 2017). The device does not have to be paired with any other device (Moscaritolo, 2017), inclusive of the attacker’s device. This enables the attack to be silent as it affects the device. This design does not “wake up” the targeted device (Biggs, 2017) and the user does not suspect the device is compromised. The speed of the attack also is innovative. For the device to be compromised in its entirety takes only up to 10 seconds for the process, inclusive of the choices the malware has to complete (Goodin, 2017).

            This attack gives the attacker a choice of avenues to pursue in compromising the device. The attacker may take complete control of the device, continue on the course of spreading the malware further, or in the alternative establish a man-in-the-middle attack (MitM) (Khandelwal, 2017). As an off-shoot of this, the attacker could in theory create a botnet network from these. This further infection of other devices proximate to the infected on likewise could be accomplished in seconds (Rascal23, 2017).

            This also is a valid attack against air-gapped machines that were previously thought to be secure. As with this target, all that has to happen is the Bluetooth is on and the attacker is proximate.

            The reports form the researchers who detected the attack (Armis Labs) are available at http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf and https://www.armis.com/blueborne/.

Affected Devices

            There are millions of unpatched mobile phones, computers, and internet of things (IoT) devices. As these are not patched, the attacker would have the capability to exploit the vulnerability to control the devices (US-CERT, 2017). This is specifically addressed with VU#240311.

            The affected devices are:

a)      Samsung Smart Watch, TVs, and Refrigerators,

b)     Samsung Galaxy Phones and Tablets,

c)      Google Pixel Smartphone,

d)     All Windows Computers Beginning with Vista,

e)      All iPhone, iPod, and iPod touch devices with iOS 9.3.5 and previous versions, and

f)      Pumpkin Car Audio System (Zorz, 2017).

Of these attacks, the strongest attack involves the Android and Linux OS devices. With these, the Bluetooth implementation are vulnerable to memory corruption exploit anyway. The attack allows the malware to run with high system privilege. This gives the exploit access to the sensitive system resources (Goodin, 2017).   

            The Linux devices don’t utilize address space layout randomization (ASLR) or a like security feature to mitigate the BlueBorne’s potential buffer overflow vulnerability. The Android does use the ASLR, however the attack is able to bypass the security feature with another vulnerability being exploited that leaks memory location where key processes are operating (Goodin, 2017). In addition, the malware does attack the hosts L2CAP (logical link and adaption layer protocol) at the stack data layer. The L2CAP supports the connection multiplexing, segmentation, and re-assembly of packets for upper layer protocols.

US-CERT

            BlueBorne has eight vulnerabilities associated with it through the various OSs (KB, 2017; Zorz, 2017; Biggs, 2017; Goodin, 2017; Khandelwal, 2017).

a)      CVE-2017-1000251 (CWE-120)

a.      Buffer copy without checking the size of the input (“Classic Buffer Overflow”)

b.      Linux Kernel version 3.3-rc1 is affected. This was coded to exploit a vulnerable implementation of L2CAP EFS in BlueZ. The I2cap_parse_conf_rsp was not coded to check the rsp argument length prior to unpacking. This allows the attack to overflow the 64 byte bugger on the kernel stack with an unlimited amount of data.

b)     CVE-2017-0785 (CWE-125)

a.      Out of bounds read

b.      There is a vulnerable implementation of SDP. The attacker could exert control over the device. This would take the form of controlling the continuation state within SDP, request packets and cause the SDP server to return an out of bounds read from the response buffer.

c)      CVE-2017-0785 (CWE-125)

a.      Out of bounds read

b.      This affects all versions of Android prior to September 9, 2017. The vulnerability contains a vulnerable implementation of SDP within the Android Bluetooth software stack. An attacker may be able to control the continuation state within the SDP request packets and cause the SDP server to return an out of bounds read from the response buffer. This is much like CVE-2017-1000250, however this is directed at a different stack.

d)     CVE-2017-0781 (CWE-122)

a.      This CVE is a heap based buffer overflow which affects all Android versions prior to September 9, 2017.  With this, an incorrect buffer size is passed to a memcpy call within the BVEP implementation for Android. This may allow the attacker to send crafted packets to the device that would overflow the heap.

e)      CVE-2017-0782 (CWE-191)

a.      Integer Underflow (Wrap or Wraparound)

b.      This CVE focusses on the BNCP implementation for Android. Here the rem_len does not check the size and is applicable to all versions prior to September 9, 2017. This allows for an integer underflow and further unsafe processing of attacker controlled packets.

f)      CVE-2017-14315 (CWE-122)

a.      This affects Apple’s Bluetooth Low-Energy Audio Protocol (LEAP) implementation in iOS version 9.3.5 and lower, Apple TV tv OS version 7.2.2 and lower. This does not property validate the CID for incoming Bluetooth LEAP audio data. This may result in a heap overflow due to this vulnerability not properly validating the packet sizes prior to calling memcpy.

g)     CVE-2017-0783 and CVE-2017-8628 (CWE-300)

a.      With this vulnerability there are security level requirements that  are not correct in the PAN profile in the Bluetooth implementation. This may allow an attacker to secure permission to perform a man-in-the-middle (MitM) attack.

With these vulnerabilities, four are critical and should be addressed first.

Solutions

            The affected devices should download and apply the patches to resolve the issue immediately. As noted, the patches are readily available for Windows, iOS, Linux kernel, and Android (KB, 2017). Google pushed its patches with their September Android update. This was for Marshmallow and Nougat (KB, 2017). Microsoft pushed its patches on September 12. Apple mitigated the vulnerability with its iOS 10. Linux should provide their mitigation soon.

There may be an issue with the Android devices in case when the Android partners have do not immediately pass the patch onto their clients. Until this occurs, the Bluetooth should be turned off until this is implemented (KB, 2017; Zorz, 2017).

References

Biggs, J. (2017, September 13). New Bluetooth vulnerability can hack a phone in 10 seconds. Retrieved from https://techcrunch.com/2017/09/12/new-bluetooth-vulnerability-can-hack-a-phone-in-ten-seconds/?ncid=rss

Goodin, D. (2017, September 12). Billions of devices imperiled by new clickless Bluetooth attack. Retrieved from https://arstechnica.com/information-technology/2017/09/bluetooth-bugs-open-billions-of-devices-to-attacks-no-clicking-required/

KB. (2017, September 12). Vulnerability note VU#240311: Multiple Bluetooth implementation vulnerabilities affect many devices. Retrieved from http://www.kb.cert.org/vulns/id/240311

Khandelwal, S. (2017, September 12). Blueborne: Critical Bluetooth attack puts billions of devices at risk of hacking. Retrieved from http://thehackernews.com/2017/09/blueborne-bluetooth-hacking.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+TheHackerNews+...

Moscaritolo, A. (2017, September 13). BlueBorne Bluetooth attack puts 5 billion devices at risk. Retrieved from https://www.pcmag.com/news/356174/blueborne-bluetooth-attack-puts-5-billion-devices-at-risk

Rascal23. (2017, September 13). Linux gets blasted by blueborne too. Retrieved from http://fullcirclemagazine.org/2017/09/13/linux-gets-blasted-by-blueborne-too/

US-CERT. (2017, September 12). Blue Borne Bluetooth vulnerabilities. Retrieved from https://www.us-cert.gov/ncas/current-activity/2017/09/12/BlueBorne-Bluetooth-Vulnerabilities

Zorz, Z. (2017, September 13). Billions of Bluetooth-enabled devices vulnerable to new airborne attacks. Retrieved from https://www.helpnetsecurity.com/2017/09/13/blueborne/