Category Archives: Vulnerabilities

airplane taking off

Mayday: The Call for Cybersecurity Reform in Aviation

If the first big cybersecurity breach of 2018 has taught us anything, it’s that even multinational tech companies need help navigating the realm of cybersecurity. Intel knew about Spectre and Meltdown since June of 2017 and eight months of inactivity is not sufficient post-breach protocol.

If the tech industry is struggling to grasp cybersecurity’s severity, what does this mean for other industries? As tech and financial institutions recognize the importance of cybersecurity, other industries need to address the digital elephant in the room.

If we think about the most vulnerable industries to cyber-attack, the answer may both figuratively and literally fly over our heads. The aviation industry is one of those most influential industries in the global economy and one of the most susceptible right now to cyber-attack. As the number of digital components in the cockpit has increased, so too has the attack surface of all aircraft and air traffic control systems.

In the United States alone, the civil aviation industry accounts for over five percent of the US economy generating $1.6 trillion in economic activity per year. While a cyber-attack impacting the economy is frightening enough, the most alarming notion is that hackers have the ability to make airplanes vanish from radar systems or even crash. Even smaller scale cyber attacks can have a significant impact. A simple Denial-of-Service for airport services or flight delays can have massive cost implications and impact goods, people and information. With dollars and lives at risk, it’s important to understand where and why certain threat vectors in the aviation industry exist.

Mind the ‘air’ gap.

Traditionally, component parts and systems in aviation have been made up of air gapped technologies making them near to impossible to breach. As society has evolved and shifted to a more connected digital environment, we’ve seen a similar paradigm shift in aviation. Even critical components such as engines, hydraulics and flight management systems are now being monitored using IoT approaches to services. While this has made flying easier for pilots and cozier for passengers, it has also made systems exponentially more vulnerable to cyber-attack – specifically after switching from fly-by-wire to fly-by-wireless systems.

With fly-by-wireless technology, aircraft are controlled with fewer, more centralized units by

using higher throughput multicore, multiprocessor computers and commercial off-the-shelf components. While this increases efficiency, it also means that the aircraft, cockpit, cabin crew and passengers are using many of the same communications constituents. Wi-Fi, passenger information, avionics and more are all controlled by a centralized system making a single cyber-attack easier and all the more catastrophic. Not only that, but since aircraft parts are manufactured by different sources, malware could infiltrate these systems as early their journey through the supply chain.

As aviation security measures struggle to keep up with aviation technology, a number of threat vectors have surfaced. The most common in the industry include: air traffic control, aircraft IP networks, aircraft communications addressing and reporting systems (ACARS), aircraft interfaces, reservations, document control, electronic flight bags (EFB) and baggage handling. Since all airline and airport operations differ slightly, determining to what level these vectors exist and how to protect them requires a Threat & Risk Assessment (TRA) and Risk Registry (RR). With a TRA conducted and RR in place, organizations can prepare cybersecurity methodology for both pre- and post- breach conditions.

Keep airways breach-free.

You can summarize an effective cybersecurity policy in two words: be proactive. Setting up pre-breach methodology is equally as important as having post-breach methodology in place. The greatest victory is the battle not fought and there is too much at stake for the aviation industry to wage war with cyber criminals.

The harsh reality is that airlines need to prioritize as it is too expensive to protect all assets from all threats. While a TRA and RR provide the framework for an airline’s individual security needs, the mercurial nature of cyber threats requires ongoing monitoring and maintenance of the methodology in place. Pre-breach methodology should follow international standards and consider the full breach picture by understanding the risk of data exposure, breach prevention and incident response.

In an ideal world, incident response wouldn’t be a part of breach methodology, but hackers are a cunning bunch. Defenses are sometimes broken and airlines need to be prepared. Post-breach methodology is about timely mitigation and since it takes businesses an average of 100 to 200 days to detect intrusion, timeliness seems to be a widespread issue.

The key to prevention and detection is ensuring technical controls are in place and that policies and procedures governing security practices are well communicated to protect and secure assets. The ability to detect and perform an incident response that follows a breach aids greatly in tightening security practices by identifying methods that will prevent further compromise in the future.

Airlines need to realize that this can’t be done alone. Whether it’s through the public or private sector, airlines need to partner with experts that understand the ever-changing cybersecurity landscape. The best security partner helps you implement procedures to handle this swiftly and independently and can also be called to assist in emergency situations.

A commercial plane wouldn’t take off without landing gear nor would it fly without a channel connected to air traffic control. Whether it’s physical or digital, a preflight checklist is required to ensure safety of both the flight crew and passengers. Cybersecurity isn’t a risk the aviation sector can afford to take.


Connecting the Dots for SMBs & Cybersecurity

Does your company’s private network speed ever feel like a VPN? Did someone (other than your IT director) reset your password? Have you been reading emails from the Nigerian Prince? If you’ve answered yes, it’s possible your company has fallen victim to a cyber attack.

If you’re a multinational tech giant, you’re probably fine (probably). But if you’re a SMB, cyber attacks can destroy priceless data and ravage your bottom line.

Let’s take a look at some stats: it takes most businesses somewhere between 100 and 200 days to detect an attack and to make matters worse, most SMBs find out from a third party. That means stolen data (that’s likely long gone forever) and damaged customer relationships. In addition, SMBs only have a 40 percent probability of staying in business after a security breach which are odds Han Solo wouldn’t even take.

These days, whether you sell Apple phones or apple pies your company has an attack surface. An attack surface can be anything from the Internet, to technology, to an employee and no matter how big your company may be, you need to be prepared.

You have been compromised. Now what?

In the event that your network has been attacked, react urgently but do not panic. Instead, have a plan in place. Ideally you have developed your plan before the attack, but often that is not the case.

In 2016, more than 375 million new unique malware variants were discovered globally. Cyber criminals are continuously finding new ways to breach security systems, so make sure your plan is malleable. After a cyber attack, here is the recommended plan of action:

  1. Identify the target systems and determine the data that was compromised, hopefully you had a backup of your data to be able to restore. Now perform a full system backup at the bit level to capture all files and current system state. If possible, disconnect from your network but leave the power on to preserve the system state.
  2. Take your cloned systems disks and use them for forensics in a protected environment or hand them over to your cyber security partner for analysis.
  3. Have your operating system rebuilt from scratch. At this point, you have no idea whether or not a back door has been installed. Assume that it has.

In a cyber attack, there is both a technical and human component to its path of destruction. While you work to get the technical side under control, contact your legal team and make them aware of the situation.

Start dusting off that PR handbook.

Public relations is something often neglected by SMBs. It’s important to notify your PR team as soon as possible after an attack. If you don’t have one, get one. Whether that means hiring one full time or on contract is entirely up to you.

In any business, do not try to downplay the situation. Equifax learned this the hard way when they chalked up their massive breach to “Criminals exploited a U.S. website application vulnerability to gain access to certain files.” In a blizzard of negative publicity, the story snowballed with the breach ultimately costing them close to $70 million in fourth quarter profits. Given time, the company’s hit to brand credibility will indicate its true losses.

Another PR mistake is deflecting liability. Many company executives have taken a stroll down ‘Blame Game Lane’, which almost always leaves them on the wrong side of the tracks. In 2016, Wells Fargo was fined $185 million for creating two million fake customer accounts and their CEO immediately took to blaming his 5,300 employees. By not admitting fault, one of the largest banks in the world put its internal and external reputation in serious jeopardy.

“The greatest victory is the one that requires no battle.” – Sun Tzu, The Art of War

While larger companies typically survive, it’s no wonder SMBs go out of business so fast. Cyber attacks cost time and money, both of which SMBs can’t afford to lose. Many still fail to evaluate their cyber security risks, however, boardrooms are smartening up. It’s even been a topic in NAFTA discussions. Develop a security protocol and be proactive in testing and quantifying your risks. Businesses of all sizes should test their systems and perform ‘war games’ to prepare for an attempted breach.

Put simply, two words can save your business from a cyber attack: be proactive. The most common means of cyber incursion is social engineering – using people to voluntarily but unknowingly allow a cyber attack to occur such as providing physical access or handing over system passwords. Train your employees, learn to recognize the signs of a breach and avoid opening emails from unknown sources.

Cybersecurity is unfamiliar territory for most companies these days, but one worth exploring. As you continue to evaluate your company’s security controls, just know we can help you connect the dots.

Written by: DarkKnight


Securing your device from Malware

Android and iOS devices both attempt to secure their OS from Malware and other vulnerabilities. They implement a myriad of security features in each new release, but that is just not good enough. Users still need to be vigilant and keep an eye on things.
You may not be able to adhere to everything but here is a list of things you can do to secure your device.


1. Don’t download apps from 3rd party sites

Avoid installing Android Package Files ( .apk’s) directly to your device. “Sideloading”, as it is called, installs apps not from Google Play but from 3rd party sites. The app may look exactly the same as it does from Google but may be repackaged to include malware. The signs of compromises are difficult for many users to identify, so don’t take the chance.


2. Don’t grant administrator access or extra permissions

Many apps ask for permissions to your device that they really don’t need. Before installing an app find out what permissions are required and if you don’t feel comfortable don’t install it. Is that app absolutely necessary? If you are seeing lots of adware then its probably too late but you still have the option of uninstalling the app.


3. Install a security application

Free security apps like Lookout do a decent job of scanning your device for malware, viruses and spyware. The security app will find the apps that are causing you problems and incorporates a malicious website blocker. If possible implement a security app but make sure you do your due diligence on the security app. Check the reviews to see what others are saying about the app.


4. Keep up-to-date on OS and app updates

This is a simple step but it keeps your operating system and apps up-to-date. These updates are often patches for security leaks and known or new found vulnerabilities. You can close the door on thieves but the door needs to be locked as well.


5. Disable cookies and Javascript

This is a tough one. Many apps use cookies and javascript to run. The issue here is that the majority of the apps that use cookies and javascript also incorporate analytic engines. Analytic engines will process your personal data and send it back to a corporate server. This data is even compiled offline and then sent when you are back online. Google’s policy is to retain your data for 25 months at a minimum and longer if possible…


6. Don’t jailbreak or root your device

Many users do not know what is done to the Operating System during either a jailbreak or the rooting of a device. Once completed it becomes easier to compromise a device as many users do not have the technical savvy to be able to harden a device in this state. Your dervice becomes more open to drive-by hackings especially if your using public Wi-Fi and no, you will not get a notification that your device has been compromised.


Some of these may be tough to swallow but compare that to your personal data or your banking information being freely available to the highest bidder. Keep in mind many criminal organizations are targeting individual mobile devices as they are not securely configured. Mobile has become the low hanging fruit for identity and data thieves, don’t make it easy.


Embedded Malware in Mobile Applications

Embedded Malware in Mobile Applications Blog

Project Overview


Mobile is ripe for attack, as many people only associate cyber threats with their PCs and neglect even basic security precautions on their mobile devices. Under the Public Safety Canada Cyber Security Cooperation Program (CSCP) TwelveDot created a standardized methodology to qualitatively identify malware and vulnerabilities in mobile applications.

Given the risk of exposure to both consumers and businesses we needed to ensure that Canadians are protected from embedded malware while using mobile applications. This included the development of a standard method for mobile application developers to ensure their apps are tested and validated to minimum security levels for usage not only in Canada but globally. This methodology provides users with an easy to use grading system to determine if they are accepting of the risk of using the application.

GCAM and why a standardized method is important…

TwelveDot successfully developed a methodology to test mobile application security. This is a formalized methodology known as General Code Assessment Methodology (GCAM) which can identify, categorize and report on malware and application weaknesses for resolution by the vendor/developer.

There is a need to move towards a mobile application security standard. There are no current standards for mobile application security. Most mobile applications do not even pass basic security tests. Some organizations have mobile application security tests such as dynamic and static code analysis but these only validate the code and does not encompass mobile application behaviour nor the interaction between mobile applications, their users, cloud services and 3rd parties.

Using the GCAM methodology, we were able to identify mobile applications that indicate signs of bad coding practice and poor application design. These factors were used to derive a calculation that can be used to determine an application grade. This grade clearly indicates to a user the potential risk of security and privacy exposure.


For the data captures, a Man-In-The-Middle (MITM) proxy was used to intercept and decrypt secure network sessions and we used Wire Shark to capture all the network session traffic. The network traffic shows, from a security perspective, how someone with intent could use fingerprinting techniques to target a device/user.

Application Selection

The applications were selected from both the Apple and Google Play app stores. We did not focus on other app stores due to lack of source control over the posted apps. We wanted to focus on applications that users and business would use everyday. Applications can be broken down into two major categories, free and paid applications. We have selected applications from both major categories.


The applications are then further broken down as shown in the categories below.

App Store Categories:







Food & Drink


Health & Fitness





News & Video



Social Networking






There is a general trend, from the analysis of the tested mobile applications, for someone with intent to use advanced techniques to target a device or user. Security and privacy is not a primary concern when designing/coding mobile applications, and many developers do not have the necessary skills for these considerations at design time. Larger more established organizations with more resources (time and money) such as Google and Facebook, generally have better coded and designed applications, where as the smaller less process mature organizations demonstrate less skill in developing secure mobile applications. However, the larger organizations also attempt to exploit user data by creating malware and using vulnerabilities built-in to their applications. This can be demonstrated by the fact that analytic engines collect user data and behaviours without user knowledge. These include API’s and SDKs from Google, Yahoo, and Amazon. These engines are included in the majority of applications given that they are free and easy to integrate for developers.


Figure 1 iOS Embedded Malware


Figure 2 Android Embedded Malware


Our tests show that the SDKs and API’s that developers implement are not just Apple or Google APIs but 3rd party APIs that may not be securely tested or validated but just added in. Over 40% of the applications we tested contained embedded 3rd party SDK/API’s.

3rd party libraries in the SDK’s have known vulnerabilities but the majority of mobile applications have not been tested against these known vulnerabilities. Many developers don’t even now the risk of using these 3rd party APIs nor do they evaluation the source code for origin.

The vast majority of library flaws remain undiscovered and typical Java applications are likely to include at least one vulnerable library.

3rd party libraries in the SDK’s have known vulnerabilities as can be seen in the CVE database but the majority of mobile applications have not been tested against the known vulnerabilities. Nor do the developers of these libraries report the vulnerabilities to the developers.

Sample SDK Vulnerability

  • A vulnerability in the OpenSSL ssl3_get_key_exchange function could allow a remote attacker to downgrade the security of certain TLS connections. An OpenSSL client accepts the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. This could allow a remote attacker using man-in-the-middle techniques to facilitate brute-force decryption of TLS/SSL traffic between vulnerable clients and servers. This vulnerability is also known as the FREAK attack.


Analytic engines are the largest threat vector in mobile environments.

These engines collect a variety of data from account names to country codes to browser versions. Data is even collected when the user is offline and saved to persistent storage on the device and forwarded on to the server during the next session. The data is retained for months if not years and the user is never advised of the storage length or uses of the data being collected. In many instances the companies that offer these services will typically sell this data to marketing companies looking to directly target advertising to these users.


An example of a popular analytic engine can be seen below in Figure 2. It shows the network traffic timestamp of the Crashlytics engine at work. Crashlytics is a popular analytic engine and it was prevalent in the applications we tested.


Figure 2 Network traffic timestamp of crashlytics data being transferred

Data found in application directories with compiled data to be sent to crashlytic analytic server.


Figure 3 – Crashlytics directory created by app on device

Looking at the directory structure pictured above (Figure 3), one can see that the data is grouped according to its processing status. The engine will process data it deems valid to send back to the server. Sendable data, data being processed, data that is prepared to send and invalid data. This data is also processed offline and can be sent back once a network connection has been established.

Fake apps mimic the actual applications they are supposed to replace. They are easily found on third party app download sites, websites and official app stores including Google Play. While outside the scope of our security testing users need to be aware these apps are prevalent and pose significant exposure risk when used.

Fake apps are available in every app category from Business to Games, Finance and Weather. These apps are not harmless copycats, they are intended to be malicious and include embedded malware.

Applications can be downloaded directly from the developer’s site. They can also be downloaded from 3rd party sites. There are thousands of sites that offer application files available for download.

Herein lies the problem. The 3rd party sites are not secure. They do not ensure the apps are secure or free from malware/vulnerabilities. Moreover some of the sites are purpose built venues for malware/vulnerabilities to be introduced to users. These sites actually repackage the application with embedded malware/vulnerabilities. The files are then unwittingly downloaded by users and installed. The user’s device is now compromised.

Cloud Services are used by a majority of the mobile applications tested. Approximately 80% of the apps tested use cloud services. The main players in this are Amazon and Google.

Sample test results from the DropBox application in iOS show both Amazon and Google Cloud services in use. Google cloud services uses Google cloud endpoints, so it can determine user location, locate nearby stores, and then provide the user relevant offers and recommendations. These usage patterns build on the users’ already growing user profile created for each and every user of these services. Many users are not aware of the metadata being collected on them at this point and once they do it is too late to remove your fingerprint.

What can you do to ensure your apps are safe?

Users and businesses need to assess risks, determine threats and mitigate threats. These threats include, threats to data, threats to availability and system integrity.

  • Always research the publisher/developer of the app. For iOS apps a user can look at the details tab of the mobile app in the Apple App Store and look at the information about the app and search the publisher/developer.
  • Read application reviews. Check around to see what others are saying (,,
  • Always check application permissions (a simple calculator app should not need access to personal information) For iOS open the Settings app and scroll down to the list of apps at the very bottom. Tap an app and you’ll see the permissions it wants. You can enable or disable individual permissions for specific apps from here. For Android apps select Menu>Settings>Applications>Manage Applications. Then choose an app and scroll to the bottom and it shows you the list of permissions.
  • Avoid installing Android Package files ( APK’s ) directly to your device. If you use the Google Play site to install apps then you should be ok. However if you download .apk files from developer sites or third party sites and install the .apk , then you are putting yourself at higher risk. Sideloading is the process of loading an .apk file directly to your device. Not all manufacturers support Google Play on their devices. Also regional restrictions imposed by Google Play may prevent you from loading an app. In order to install an .apk file you will need to enable unknown sources which allows the installation of apps from sources other than Google Play. But be forewarned do not allow apps extra permissions for the majority of these will most likely contain malware.
  • Install an antivirus app on your phone. Lookout is a quality mobile security app that is available for both iOS and Android.
  • Disable cookies and don’t allow javascripts to run to prevent analytic engines from sending your personal data. In doing, so you reduce your risk from malware, however some apps may not run properly with cookies and more specifically javascript disabled. Many apps nowadays use javascript for plugins. You will have to decide what is more important the app or the security of your data?


There is also a comprehensive list of steps developers need to address to ensure mobile application security but that is for another day…another blog.

Full report on Embedded Malware in Mobile Applications available please contact us.


Why paying for vulns is a bad model

There seems to be a new trend in the industry that has vendors paying for vulns. Many big vendors currently offer money for unpublished vulnerabilities. This can range from few hundred US dollars to $100K bounty for the security researcher. While, I believe it is good to deal with vulnerabilities and disclosure you have ask does the vendor actually fix these or do they just use it as cheap means to bug fix?

I would argue the later given the fact that the vendor community fought so adamantly to stop and destroy any initiative related to vulnerability disclosure policies or procedures including the recently released ISO/IEC 29147 Vulnerability disclosure standard. For such a small standard the same vendors who have try to destroy this standard are now offer $$$ for your vulns, why ROI!

Think about what would the cost be to large operating system vendor to fix a bug that impacts 100K users globally? This include engineering and testing time, marketing, and PR now then calculate the avg. salary of these staff members for a bug that takes about 1000 hours to fix. This can now be purchased for $5K. Now that is a great ROI. Remember, none (not one) of these programs indicates that it will fix the vuln only that they are willing to provide money to the finder and give them credit for finding it.

This starts a very dangerous trend in our industry that those with $$$ can control the means to protect the innocent users and businesses who are violated by using the shoddy code to begin with. It does not address the fundamental issue of creating secure code and secure testing practices which are costly to embed in to a company culture. This should be the focus of every company the produces software.

If you are a finder who has discovered a vuln here is what I recommend:

Find the vulnerability disclosure policy for the company. If they don’t have one that says a lot but reach out the security or administrative contact listed on many web sites.
Use a secure transport method to disclose the details of what you have discovered.
Keep detailed records of the event and all communication to the vendor
If you do not get a response try the regional CERT they typically have the contacts and can help with coordinating the events.
Worse case, if you feel that the vendor is not willing to work with you and the issue is critical to customers of the product or service perform a public disclosure. While I don’t condone this behavior I know how vendors behave when it comes to vulnerability disclosure so I understand the rational.

One interesting development would be the launch of companies that front the vendor for vulnerability disclosure. They are fully funded by the big vendors and have had a hand in creating the policies used for collecting vulns. Again, no mention that ANY of these will be addressed by the vendor. Do your research and make an informed decision if this is best path forward.


SMBs and HeartBleed


Just so we are clear Heartbleed was not an exercise in patching and telling users to change their passwords but should be used to educate organizations to the “risk” of blatantly using other people’s stuff and not validating it yourself. This little gem of a security exploit called Heartbleed has been sitting quietly for years… or has it?

If you had to use the vulnerable SSL libraries then how do you do know with 75% probability that no one exploited this hole to take a little info here and there. If you can say that with a high level of confidence great……but you are in the minority on this one. Asked differently how many SMBs have the talent to understand this kind of risk in their bullpens? Getting nervous…… you should be.

Why do I believe this — the forgotten art of the intrusion analyst. These are people who can analyse network captures, review system logs, audit binary checksums, etc…to determine sessions that lead to compromise. Not many of these artisans exist today and not many organizations believe in their benefits as we can see by the 100s of millions of alerts that are generated in CA every day by SIEMs and IPS/IDS that go unreviewed and unanalyzed. Yes, one can argue about the lack of intelligence and I get that one but if the IPS/IDS were tuned properly to reduce the alerts to a minimum allowing the intrusion analyst to only focus on the ones that seem really suspicious these events can be alerted and mitigated much quicker.

Use a managed service provider… they are only providing a compliance check box for your company. They will not protect you — sorry providers that is the reality. With 100’s of customers and many targeted attacks they will only see the bigger attacks not the skilled and targeted attacks. So lots of bad here what is the good and how does a small company stand a chance.

SMBs need to start demanding more of their providers and vendors when it comes to security. Specific to internet security use these as a guide to gauge a service provider’s ability to help you.

1. What site security certifications does the provider/vendor have i.e. 27001. If a security operations center does not have this how do they expect they are going to protect you. Sorry SAS-70s aren’t worth the paper they are written on.
2. What is their track record on vulnerability disclosure? Do they have a vulnerability disclosure policy that is publicly posted?
3. Does your SLA state actions when a active attack is being conducted against your site and what actions they are able to perform. Make sure you understand the implications of these changes.
4. Did you ever conduct a RA against the data that resides on the provider site? What is the risk of exposure to this data and your reputation?
5. Review your operational policies and procedures for alignment to security risks and threats to your organization. These are changing with each new system and technology being deployed so too should your risk profiles. These will necessitate policy changes at least once annually.
6. Find a good security partner who understands the “context” of your business and is able to help determine specific risks and threats to your operation for security.
7. Does the provider demonstrate how security vulnerabilities are identified and eliminated during design, development and testing of the product. Are they using a guide such as ISO 27034 to determine the security checks that are required for the lifecycle of the software/service. If so they can easily provide you the application security control (ASC) list to you.
8. Make sure you revoke your current SSL certificate and have it reissued. If you don’t you are still open to the vulnerability. Many companies do not seem to realize this given the number of revoke requests for certs since HeartBleed was announced. BTW this number is only about 30% currently so many sites are vulnerable to attack.

Finally, security is not easy and it is not a product solution. It is compromised of good process, procedure and it requires discipline….LOTs of discipline.