Category: EDITORIAL

EDITORIAL | April 8, 2021

Trivial Vulnerabilities, Serious Risks

By Tiago Assumpcao & Robert Connolly

Introduction

The digital transformation brought about by the social distancing and isolation caused by the global COVID-19 pandemic was both extremely rapid and unexpected. From shortening the distance to our loved ones to reengineering entire business models, we’re adopting and scaling new solutions that are as fast-evolving as they are complex. The full impact of the decisions and technological shifts we’ve made in such short a time will take us years to fully comprehend.

Unfortunately, there’s a darker side to this rapid innovation and growth which is often performed to strict deadlines and without sufficient planning or oversight – over the past year, cyberattacks have increased drastically worldwide [1]. Ransomware attacks rose 40% to 199.7 million cases globally in Q3 alone [2], and 2020 became the “worst year on record” for data breaches by the end of Q2 [1].

In 2020, the U.S. government suffered a series of attacks targeting several institutions, including security agencies, the Congress, and the judiciary, combining in what was arguably the “worst-ever US government cyberattack,” and also affecting major tech companies.

The attacks were reported in detail [3], bringing attention to the mass media [4]. A recent article by Kari Paul and Lois Beckett in The Guardian stated[5]:

“Key federal agencies, from the Department of Homeland Security to the agency that oversees America’s nuclear weapons arsenal, were reportedly targeted, as were powerful tech and security companies including Microsoft. Investigators are still trying to determine what information the hackers may have stolen, and what they could do with it.”

In November of last year, the Brazilian judicial system faced its own personal chapter of this story. The Superior Court of Justice, the second-highest of Brazil’s courts, had over 1,000 servers taken over and backups destroyed in a ransomware attack [6]. As a result of the ensuing chaos, their infrastructure was down for about a week.

Adding insult to injury, shortly afterward, Brazil’s Superior Electoral Court also suffered a cyberattack that threatened and delayed recent elections [7].

In this post, we will briefly revisit key shifts in cyberattack and defense mechanisms that followed the technological evolution of the past several decades. Even after a series of innovations and enhancements in the field, we will illustrate how simple security issues still pose major threats today, and certainly will tomorrow.

We will conclude by presenting a cautionary case study [25] of the trivial vulnerability that could have devastated the Brazilian Judicial System.

The Ever-changing ROI of Cyberattacks

Different forms of intrusion technology have come into and out of vogue with attackers over the decades since security threats have been in the public consciousness.

In the 1980s, default logins and guest accounts gave attackers carte blanche access to systems across the globe. In the 1990s and early 2000s, plentiful pre-authentication buffer overflows could be found everywhere.

Infrastructure was designed flatly then, with little compartmentalization in mind, leaving computers — clients and servers — vastly exposed to the Internet. With no ASLR [8] or DEP/NX [9] insight, exploiting Internet-shattering vulnerabilities was a matter of a few hours or days of work — access was rarely hard to obtain for those who wanted it.

In the 2000s, things started to change. The rise of the security industry, Bill Gates’ famous 2002 memo, [10] and the growing full-disclosure movement leading the charge in the appropriate regulation of vulnerabilities, brought with them a full stack of security practices covering everything from software design and development to deployment and testing.

By 2010, security assessments, red-teaming exercises, and advanced protection mechanisms were common standards among developed industries. Nevertheless, zero-day exploits were still widely used for both targeted and mass attacks.

Between 2010 and 2015, non-native web applications and virtualized solutions multiplied. Over the following years, as increasing computing power permitted, hardware was built with robust chain-of-trust [11], virtualization [12], and access control capabilities. Software adopted strongly typed languages, with verification and validation [13] a part of code generation and runtime procedures. Network technologies were designed to support a variety of solutions for segregation and orchestration, with fine-grained controls.

From 2015 onwards, applications were increasingly deployed in decentralized infrastructures, along with ubiquitous web applications and services, and the Cloud started to take shape. Distributed multifactor authentication and authorization models were created to support users and components of these platforms.

These technological and cultural shifts conveyed changes to the mechanics of zero-day-based cyberattacks.

Today at IOActive, we frequently find complex, critical security issues in our clients’ products and systems. However, turning many of those bugs into reliable exploits can take massive amounts of effort. Most of the time, a start-to-end compromise would depend on entire chains of vulnerabilities to support a single attack.

In parallel to the past two decades of security advancements, cyberattacks adapted and evolved alongside them in what many observers compare to a “cyber-arms race,” with scopes on the private and government sectors.

While the major players in cyber warfare have virtually unlimited resources, for the majority of mid-tier cyber-attackers the price of such over-engineering simply doesn’t pay for itself. With better windows of opportunity elsewhere, attackers are instead increasingly relying on phishing, data breaches, asset exposures, and other relatively low-tech intrusion methods.

Simple Issues, Serious Threats: Today and Tomorrow

Technologies and Practices Today

While complex software vulnerabilities remain a threat today, increasingly devastating attacks are being leveraged from simple security issues. The reasons for this can vary, but it often results from recently adopted technologies and practices:

  • Cloud services [14] becoming sine qua non make it hard to track assets, content and controls [15] in the overly agile DevOps lifecycle
  • Third-party chains-of-trust become weaker as they grow (we’ve recently seen a code-dependency-critical attack based on typosquatting) [16]
  • Weak MFA mechanisms based on telephony, SMS, and instant messengers leveraging identity theft and authentication bypasses
  • Collaborative development via public repositories often leak API keys and other secrets by mistake
  • Interconnected platforms create an ever-growing supply-chain complex that must be validated across multiple vendors

New Technologies and Practices Tomorrow

Tomorrow should bring interesting new shades to this watercolor landscape:

What they didn’t tell you about AI (Thanks @mbsuiche)

Old Technologies and Practices Today and Tomorrow

There is another factor contributing to the method, from which simple security issues continue to present major threats today and will so tomorrow. It echoes silently from a past where security scrutiny wasn’t praxis.

Large governmental, medical, financial, and industrial control systems all have one thing in common: they’re a large stack of interconnected components. Many of these are either legacy components or making use of ancient technologies that lack minimal security controls.

A series of problems face overstretched development teams who often need to be overly agile and develop “full stack” applications: poor SDLC, regression bugs, lack of unit tests, and short deadlines all contribute to code with simple and easily exploitable bugs that make it into production environments. Although tracking and sanitizing such systems can be challenging to industries and governments, a minor mistake can cause real disasters.

Case Study [view the file here]

The Brazilian National Justice Council (CNJ) maintains a Judicial Data Processing System capable of facilitating the procedural activities of magistrates, judges, lawyers, and other participants in the Brazilian legal system with a single platform, making it ubiquitous as a result.

The CNJ Processo Judicial Eletrônico (CNJ PJe) system processes judicial data, with the objective of fulfilling the needs of the organs of the Brazilian Judiciary Power: Superior, Military, Labor, and Electoral courts; the courts of both the Federal Union and the individual states themselves; and the specialized justice systems that handle ordinary law and employment tribunals on both the federal and state level.

The CNJ PJeOffice software allows access to a user’s workspace through digital certificates, where individuals are provided with specific permissions, access controls, and scope of access in accordance with their roles. The primary purpose of this application is to guarantee legal authenticity and integrity to documents and processes through digital signatures.

Read the IOActive case study of the CNJ PJe vulnerabilities that fully details the scenario that represented big risks for the Brazilian Judicial System users.

Conclusion

While Information Security has strongly evolved over the past several decades, creating solid engineering, processual, and cultural solutions, new directions in the way we depend upon and use technology will come with issues that are not necessarily new or complex.

Despite their simplicity, attacks arising from these issues can have a devastating impact.

How people work and socialize, the way businesses are structured and operated, even ordinary daily activities are changing, and there’s no going back. The post-COVID-19 world is yet to be known.

Apart from the undeniable scars and changes that year 2020 imposed on our lives, one certainty is assured: information security has never been so critical.

References

[1] https://www.govtech.com/blogs/lohrmann-on-cybersecurity/2020-the-year-the-covid-19-crisis-brought-a-cyber-pandemic.html

[2] https://www.business-standard.com/article/technology/ransomware-attacks-surge-40-to-199-7-million-globally-in-q3-report-120110200919_1.html

[3] https://en.wikipedia.org/wiki/2020_United_States_federal_government_data_breach

[4] https://apnews.com/article/coronavirus-pandemic-courts-russia-375942a439bee4f4b25f393224d3d778

[5] https://www.theguardian.com/technology/2020/dec/18/orion-hack-solarwinds-explainer-us-government

[6] https://www.theregister.com/2020/11/06/brazil_court_ransomware/

[7] https://www.tse.jus.br/imprensa/noticias-tse/2020/Novembro/tentativas-de-ataques-de-hackers-ao-sistema-do-tse-nao-afetaram-resultados-das-eleicoes-afirma-barroso

[8] https://en.wikipedia.org/wiki/Address_space_layout_randomization

[9] https://en.wikipedia.org/wiki/Executable_space_protection

[10] https://www.wired.com/2002/01/bill-gates-trustworthy-computing/

[11] https://en.wikipedia.org/wiki/Trusted_Execution_Technology

[12] https://en.wikipedia.org/wiki/Hypervisor

[13] https://en.wikipedia.org/wiki/Software_verification_and_validation

[14] https://cloudsecurityalliance.org/blog/2020/02/18/cloud-security-challenges-in-2020/

[15] https://ioactive.com/guest-blog-docker-hub-scanner-matias-sequeira/

[16] https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

[17] https://act-on.ioactive.com/acton/attachment/34793/f-87b45f5f-f181-44fc-82a8-8e53c501dc4e/0/-/-/-/-/LoRaWAN%20Networks%20Susceptible%20to%20Hacking.pdf

[18] https://act-on.ioactive.com/acton/fs/blocks/showLandingPage/a/34793/p/p-003e/t/form/fm/0/r//s/?ao_gatedpage=p-003e&ao_gatedasset=f-2c315f60-e9a2-4042-8201-347d9766b936

[19] https://ioactive.com/wp-content/uploads/2018/05/IOActive_HackingCitiesPaper_cyber-security_CesarCerrudo-1.pdf

[20] https://ioactive.com/wp-content/uploads/2018/05/Hacking-Robots-Before-Skynet-Paper_Final.pdf

[21] https://ioactive.com/wp-content/uploads/2018/05/IOActive_Compromising_Industrial_Facilities_from_40_Miles_Away.pdf

[22] https://ioactive.com/pdfs/IOActive_SATCOM_Security_WhitePaper.pdf

[23] https://ioactive.com/wp-content/uploads/2018/08/us-18-Santamarta-Last-Call-For-Satcom-Security-wp.pdf

[24] https://www.belfercenter.org/publication/AttackingAI

[25] https://act-on.ioactive.com/acton/attachment/34793/f-e426e414-e895-4fb0-971f-4fa432e5ad9b/1/-/-/-/-/IOA-casestudy-CNJ-PJe.pdf

EDITORIAL | September 17, 2020

Cybersecurity Vigilance for a Historic Election

By Matt Rahman

November 3rd is Election Day in the United States. Every election is important, but this election is particularly crucial. It is one of the most important elections in our lifetime—the 2020 election will determine the course of the United States for the next 10 years or more. With so much on the line, every vote counts—but the security and integrity of, and voter confidence in, the election itself are also at risk.

The Senate Intelligence Committee determined that Russia influenced and interfered with the 2016 election, and US intelligence agencies report that Russia and other nations are spreading misinformation and actively trying to hack the 2020 election as well. The COVID-19 pandemic combined with social and political unrest across the country provides cyber adversaries with a larger attack surface for manipulation and exploitation. Heightened cybersecurity awareness and effective cybersecurity are more crucial than ever to ensure our votes are counted.

Heightened cybersecurity awareness and effective cybersecurity are more crucial than ever to ensure our votes are counted.

As the clock winds down to Election Day — and early voting and mail-in voting begin across the country — we need to consider whether we can trust the technology and processes we rely on for voting. Is the supply chain intact? Can we ensure the integrity of voter registration databases? Are media outlets and social media having an adverse influence on the election? Most importantly, can voters trust the process and have confidence that their votes will be properly counted? Clearly, we need around-the-clock vigilance between now and November 3rd to secure our vote.

Covert and Overt Actions that can Influence the Vote

Political campaigns are all about influence and swaying opinion—but those activities should be limited to the candidates and American interests. Foreign nations should not manipulate or interfere with our democratic election process, yet they do. There are foreign influences that are plainly visible, and then there are clandestine methods that are not visible. Spies who operate without being detected may impact the election. They can also steal intellectual property, manipulate technology, and recruit potential agents and mules to deliver exploits and payloads.

Social media is a double-edged sword when it comes to information. It can be a great way to do research, engage in rational discussion, and learn about the candidates and current issues. The problem is that it is also an extremely efficient way to spread misinformation, and many people can’t tell the difference. Deepfake videos and fake propaganda released on social media platforms are part of disinformation campaigns and political agitation that drive a wedge between people and prevent productive dialogue.

The COVID-19 pandemic is driving a spike in demand for mail-in ballots so people can avoid gathering at polling sites and exposing themselves to potential risk from the virus. However, the United States Postal Service is struggling, and there have been a number of cuts and changes that seem specifically intended to make it more difficult to vote by mail. Once ballots get to a post office, both the mail-in ballots and post office sorting machines are ripe for insider threats, human manipulation, and fraud if not managed and monitored appropriately.

Protect the Vote by Managing Cybersecurity and Supply Chain Risk

What can we do to defend the election process and our votes against all of these threats? The challenges of election security span the breadth and depth of the attack surface. Every county in the United States is a potential target and the scope of attacks can range from cyber attacks against voter registration and voting systems to theft of information and everything in between.

Okay, but how difficult is the challenge of election security? Let’s consider it; there are thousands of networks and applications to protect. Every network has thousands of devices, including PCs, laptops, printers, servers, smartphones, tablets, IoT devices, etc. Each of these devices runs several layers of software, and each of these software applications has thousands to millions of lines of code. Software code is complex and, as with any product made by humans, often has errors which includes security problems. In several million lines of code contained in thousands of layers of software, there are thousands of possible cybersecurity problems that need to be identified and fixed. Because of these cybersecurity problems, networks should be protected to prevent exploitation by bad actors.

Because we live in a global economy, technology is built with different small parts made in different parts of the world by people working at different companies. Securing the supply chain is also an important challenge, as backdoors and security problems can be planted in technology and exploited later by state actors.

On top of these cybersecurity problems, we have the human element. Individuals need to be properly trained in secure technology use and how not to be fooled by phishing or other targeted cyber attacks.

The best way to secure our votes and protect the integrity of the election is to engage the security community early and often to get a hacker’s point of view and the best skills working together.

Engage the security community early and often to get a hacker’s point of view and the best skills working together.

We need to properly train all personnel in cybersecurity to make them resilient against cyber attacks. We should make sure technology comes from trusted parties that perform due diligence and security audits on their providers in order to properly secure the supply chain. We also need to audit hardware and software to identify potential cybersecurity problems in order to fix them and/or take preventive actions to avoid their exploitation. Also, we need to conduct continuous or frequent vulnerability scans and penetration tests to gain valuable insight into the overall security posture of the election process and identify weaknesses so they can be addressed proactively.

As the attack surface constantly expands and the threat landscape continually shifts and evolves, ongoing testing and validation of applications and security controls should be a requirement.

The 2020 election is crucial for the future of the United States. It will require around-the-clock vigilance between now and November 3rd to guard against attacks on the election and secure our vote.

Matt Rahman is COO at IOActive, the world leader in research-fueled security services.

EDITORIAL | September 15, 2020

Security Makes Cents: Perspectives on Security from a Finance Leader

By Joshua Beauregard

Recently, it feels like the Internet is filled with stories of cyber-breaches and security breakdowns. As the world is more interconnected than ever, these stories are becoming all too familiar. In fact, there is a malicious web-based hacking event every 39 seconds, and 43% of them target small businesses.

While a breach can occur in any area of a business, a corporate finance department is often uniquely positioned, with touch-points extending further outside the company than other groups. With touch-points up and down the supply chain, the number of potential attack vectors increases, and with cross-functional access, the impact of successful attacks grows exponentially.

Fortunately, there are several small steps any department can take to beef up its policies and awareness to help prevent it from becoming the subject of the next news article. Many organizations overlook the value of programmatic, policy, and procedural controls to manage cybersecurity risks as they purchase the latest, expensive cybersecurity widget. Forward-looking organizations make cybersecurity an integral part of their overall operational resiliency with CISA’s CRR or SEI’s CERT-RMM.

Here are some specific examples where small changes can improve a finance department’s security posture.

Create a Disbursement Process Policy – and Stick to It!

Most of us know that good internal controls are the backbone of preventing fraud within an organization. But what if those controls are circumvented at an appropriate level with the relevant authority? As the pace of business increases, so does the urgency to transact that business and the necessity of off-cycle disbursements. Threat actors know this and take advantage of it. The most popular attack is spear-phishing, often referred to as Business Email Compromise (BEC), where an email is sent by an attacker to a specific person, usually someone with enough authority to transfer money without additional oversight. In many cases, these emails will appear to come from someone high up in a company: an owner, board member, C-Suite, or VP.

It should be the policy of every finance department to individually verify all off-cycle disbursements with a separate email or message to ensure that the request is valid. But usually awareness of simple clues will tell you that the request isn’t valid. For example:

  • The sender’s email address doesn’t match the person’s actual email address.
  • There are abnormal links within the email message.
  • The language doesn’t match the person.

Remember, human intelligence and critical thinking are the best defense against spear-phishing attacks. Making sure you have a good relationship with those that can authorize payments will greatly reduce the likelihood of a successful attack.

Manage Your External Credentials

Depending on the size of your department, you may be more or less able to effectively segregate duties. In most small and medium-sized businesses, the finance department wears multiple hats: accounting, FP&A, tax, treasury, etc. In these cases, there exists an increased need for cross-training. With cross-training and role backups comes the need for passwords to be shared among multiple people.

Your passwords are not always an entry point for your systems,
but weak passwords can jeopardize the information and accounts

That in itself brings inherent dangers. How do you securely share passwords? How do passwords get updated? Many may default to using an Excel spreadsheet or Google doc to keep a list of websites and passwords. While these may be efficient, they are not secure. So what should you do?

  • Implement a password management service, such as SecretServer or LastPass. While there is an associated cost, these services allow groups to share passwords in an encrypted and secure environment often with an audit trail.
  • Use secure password generators. These services can help you input the password requirements of a website and create the strongest password possible.
  • Follow good password hygiene by updating passwords regularly, using random characters, and making them as long as possible. See NIST SP 800-63B Appendix A for additional details.
  • Make use of Multi-Factor Authentication (MFA), when possible.
  • Don’t reuse passwords. It’s just as convenient for an attacker as it is for your team.

Your passwords are not always an entry point for your systems, but weak passwords can jeopardize the information and accounts stored on third-party systems, like tax agencies or customer portals.

Social Engineering is Real

It is becoming more and more common for threat actors to gain access through means other than technical infiltration. A common way is to get an employee to voluntarily give up information through a pretext. I have personally received phone calls supposedly from our bank asking me to verify my password to them. Remember, banks or other agencies will never ask for sensitive information over the phone. If you ever have doubts as to the authenticity of a request, you can always hang up and call back using verified and published phone numbers. If the request is illegitimate, the caller will do all they can to keep you on the line.

Over 95% of attacks that succeed do so because of human error. It is human nature to want to satisfy the request on the other end of the line, but don’t be afraid to make sure you’re protected.

The Cloud is Safe, Right?

Anyone else remember the days of on-prem hosted accounting software that was clunky and had to be updated every year? Those days are long gone thanks to the proliferation of cloud-based, whole-hosted ERP solutions. And it doesn’t stop there: financial analytics suites, CRMs, and document sharing all have industry leaders that are cloud-only.

Have you asked yourself how safe that data is? Sure, you’ve got high-level password requirements in your environment, but what about your service provider? It’s safe, right?

Is it? Ask yourself how you know. What risks lurk undiscovered in your supply chain?

Technology companies are one of the top three industries to experience an information breach, mainly because they carry a vast amount of very distinct and personally-identifying data. Client names, addresses, and emails are all stored in the cloud and could be prime targets for a cybercriminal. One needs to look no further than the Cloud Hopper campaign to see the risk of using Managed Service Providers (MSPs).

When you are assessing new software, ask for third-party security reports. Almost all storage-based companies can provide you with SOC 2 reports that discuss their practices and policies surrounding IT and IS environments. Have someone who knows how to interpret the contents read those reports and comments so you can make an informed risk assessment.

If you want to feel extra secure, consider having an assessment performed.

If you want to feel extra secure, consider having an assessment performed. At IOActive, we perform security assessments of the key products and providers we utilize in our operations as part of our internal Supply Chain Integrity program. Not every organization has the skills or resources to perform such assessments, but several great third-party assessor organizations exist to help. If specific vulnerabilities are identified, most providers are happy to know about them and, depending on the severity, will work to remediate those vulnerabilities quickly before you deploy the new service.

Protect What You’ve Built

One of the most popular new products in insurance is a cyber insurance policy. Once upon a time, these policies were designed to help the few companies operating within the cyber landscape. But now, everyone operates in that arena. The insurance industry has responded and offers tailor-made solutions to protect companies from multiple angles in case of a breach, including investigation, forensics, and damages. This is a must-have policy in the new connected world of the 21st century and a core part of firm-level risk management.

This is not a big business policy, either. Remember that 43% of attacks target small businesses. Legal damages resulting from a breach at a small business pose an existential threat to that organization. Talk to your agent about adding a cyber incident policy to help mitigate some of the risks associated with a breach.

The world is changing rapidly and our workspaces are changing just as fast. As remote work becomes the new normal for many companies, our digital footprints are expanding and cybersecurity is the responsibility of everyone in the company, not just the IT or IS departments. Do your part and think about how you could be impacted or used to impact others.

Joshua Beauregard is a Certified Public Accountant and the Senior Director of Finance and Administration at IOActive, the world leader in research-fueled security services.

EDITORIAL | September 8, 2020

IOActive Labs Blog

By John Sheehy

Reclaiming Hallway Con

We have several exciting things happening with our blog content. Like many, we’ve been working to replace the value lost with the loss of face-to-face gatherings at meetings, conventions, and informal get-togethers. Many veterans of the conference circuit will tell you that by far the most valuable part of a typical conference is the hallway con, which refers to the informal discussions, networking, and often serendipitous meetings that happen outside the formal conference agenda.

IOActive is helping reclaim hallway con by making some of that valuable content available in a pandemic-friendly format on our blogs and in webinars. We recently launched our Guest Blog series with a post focused on emerging threats in intermodal transportation from Urban Jonson, an accomplished contributor to hallway con and leader of the Heavy Vehicle Cyber Security (HVCS) working group at NMFTA.

Likewise, we are making some more informal technical content available to a larger audience at a higher frequency through our new IOActive Labs blog.

IOActive Labs Blog

The IOActive Labs blog is an organizational innovation proposed by our consultants to support a more agile process for developing, reviewing, and posting technical content. It facilitates lower-latency, higher-frequency posting of technical content, which was more challenging within our prior process.

This new process allows for some interesting new types of content, such as live blogging during a CTF, and more informal content, such as documenting techniques. Furthermore, the organization of the technical content under the IOActive Labs blog will allow the part of our audience, who’s only interested in the (very interesting) bits and bytes, to easily find those posts as we include more diverse, non-technical content and voices in our main blog.

We want to break in the new IOActive Labs blog with an appropriately original and interesting first post.

Breaking in the IOActive Labs Blog with a Look at Aviation Operational Technology

Ruben Santamarta, a Principal Consultant at IOActive, has amassed a considerable body of groundbreaking, original cybersecurity research. He continues his work on emerging threats through a look into airline and airport operational technology (OT) associated with Electronic Bag Tags (EBTs). This post builds on his recent work on warcodes (malicious bar codes) discussed in his recent blog post.

This research takes an empirical look at some of the implementation flaws in a couple of examples of devices and components that support the “tags everywhere” and “sensors everywhere” trends brought about by IoT and the thirst for more sources of data to feed the big data movement. It also illustrates some of the potential supply-chain risks associated with using insecure, but not intentionally malicious, products and components in systems that perform core business operations.

You may also follow the latest posts on the IOActive Labs twitter.

More to Come

We have more exciting innovations to come as we work to recapture more of the value lost without conferences.

EDITORIAL | August 28, 2020

Principles of the IOActive Guest Blog Series

By John Sheehy

IOActive has recently begun to post a series of guest blogs. Our first post was an excellent contribution from Urban Jonson, who leads the Heavy Vehicle Cyber Security (HVCS) working group at NMFTA, focusing on emerging threats in intermodal transportation.

Our organization has embarked upon this series because we think it provides additional value to our readers. This is one more thing we’re doing to give back to the security community and help those starting out to gain a broader understanding of cybersecurity.

We have long prided ourselves on telling our clients what they need to know rather than what they want to hear. Likewise, our decades-long, original cybersecurity research program has delivered results that force the security community, industries, agencies, governments, and societies to re-evaluate their assumptions about cybersecurity risks and potential impacts.

Through this series of guest blog posts, we are going to expose readers to carefully curated concepts and perspectives presented by industry thought leaders who don’t happen to (currently) work for IOActive. We’re striving to collect a diverse, high-quality set of perspectives that help the security community think about what’s coming next and how to approach difficult problems in new ways.

These entries will be more focused on risks, emerging threats, potential business impacts, new approaches to solving problems, and other higher-level perspectives rather than our deeply technical blog entries from IOActive Labs.

Of course, in providing a platform for sharing diverse opinions, the opinions expressed in the guest blog posts are not necessarily those of IOActive.

Principles of Guest Blogging

We have lofty goals for our Guest Blog Series. To ensure we achieve the desired results we need to have some guiding principles for the series. It’s unfortunate, but necessary that we need to list some of these.

  • No Paid Placement
    We will never post a blog in exchange for compensation. We’ll post things because they provide a valuable perspective and not because they are profitable.
  • No Advertising
    IOActive will not sell advertising on our blog. We don’t want our readers to be assaulted by the worst use of browser technologies as they ponder a challenging thought.
  • No Products; No Pitches
    No posts which focus on products or sales pitches will be allowed. Everyone gets enough of these already. Literally, a subset of the community is waiting to provide these.
  • Original Content
    Content on the blog will be unique and not previously posted anywhere else. The content may be on a topic about which the author(s) have spoken or written before, but it cannot materially be a repost of prior work.
  • Contributes to the Community
    The content of the post must positively contribute to the security community and hopefully the world, even if it challenges existing assumptions, approaches, or solutions. Ideally, the post will help readers contemplate what’s coming next and how to approach difficult problems in new ways through exposure to a diverse, high-quality perspective.

Hopefully, our readers will value these diverse, broad perspectives of our guest bloggers as much as we do.

EDITORIAL | June 30, 2020

Warcodes: Attacking ICS through industrial barcode scanners

By Ruben Santamarta

Several days ago I came across an interesting entry in the curious ‘ICS Future News’ blog run by Patrick Coyle.


Before anyone becomes alarmed, the description of this blog is crystal clear about its contents:

“News about control system security incidents that you might see in the not too distant future. Any similarity to real people, places or things is purely imaginary.”

IOActive provides research-fueled security services, so when we analyze cutting-edge technologies the goal is to stay one step ahead of malicious actors in order to reduce current and future risk.

Although the casino barcode hack is made up, it turns out IOActive reported similar vulnerabilities to SICK months ago, resulting in the following advisory:



This blog post provides an introductory analysis of real attack vectors where custom barcodes could be leveraged to remotely attack ICS, including critical infrastructure.


Introduction


Barcode scanning is ubiquitous across sectors and markets. From retail companies to manufacturing, utilities to access control systems, barcodes are used every day to identify and track millions of assets at warehouses, offices, shops, supermarkets, industrial facilities, and airports.

Depending on the purpose and the nature of the items being scanned, there are several types of barcode scanners available on the market: CCD, laser, and image-based to name a few. Also, based on the characteristics of the environment, there are wireless, corded, handheld, or fixed-mount scanners.

In general terms, people are used to seeing this technology as part of their daily routine. The security community has also paid attention to these devices, mainly focusing on the fact that regular handheld barcode scanners are usually configured to act as HID keyboards. Under certain circumstances, it is possible to inject keystroke combinations that can compromise the host computer where the barcode scanner is connected. However, the barcode scanners in the industrial world have their own characteristics.

shipping automation

From the security perspective, the cyber-physical systems at manufacturing plants, airports, and retail facilities may initially look as though they are physically isolated systems. We all know that this is not entirely true, but reaching ICS networks should ideally involve several hops from other systems. In some deployments there is a direct path from the outside world to those systems: the asset being handled.

Depending on the industrial process where barcode scanners are deployed, we can envision assets that contain untrusted inputs (barcodes) from malicious actors, such as luggage at airports or parcels in logistics facilities.

In order to illustrate the issue, I will focus on the specific case I researched: smart airports.

Attack Surface of Baggage Handling Systems


Airports are really complex facilities where interoperability is a key factor. There is a plethora of systems and devices shared between different stakeholders. Passengers are also constrained in what they are allowed to carry.

luggage scanning

In 2016, ENISA published a comprehensive paper on securing smart airports. Their analysis provided a plethora of interesting details; among which was a ranking of the most critical systems for airport resilience.



Most modern baggage handling systems, including self-service bag drop, rely on fixed-mount laser scanners to identify and track luggage tickets. Devices such as the SICK CLV65X are typically deployed at the automatic baggage handling systems and baggage self-drop systems operating at multiple airports.


The Baggage Connection

More specifically, SICK CLV62x-65x barcode scanners support ‘profile programming’ barcodes. These are custom barcodes that, once scanned, directly modify settings in a device, without involving a host computer. This functionality relies in custom CODE128 barcodes that trigger certain actions in the device and can be leveraged to change configuration settings.

A simple search on YouTube results in detailed walkthroughs of some of the largest airport’s baggage handling systems, which are equipped with SICK devices.

Custom CODE128 barcodes do not implement any kind of authentication, so once they are generated they will work on any SICK device that supports them. As a result, an attacker that is able to physically present a malicious profile programming barcode to a device can either render it inoperable or change its settings to facilitate further attacks.

We successfully tested this attack against a SICK CLV650 device.

Technical Details


IOActive reverse engineered the logic used to generate profile programming barcodes (firmware versions 6.10 and 3.10) and verified that they are not bound to specific devices.

The following method in ProfileCommandBuilder.class demonstrates the lack of authentication when building profile programming barcodes.

[caption id="attachment_6882" align="alignnone" width="686"] Analyzing CLV65x_V3_10_20100323.jar and CLV62x_65x_V6.10_STD



 

Conclusion


The attack vector described in this blog post can be exploited in various ways, across multiple industries and will be analyzed in future blog posts. Also, according to IOActive’s experience, it is likely that similar issues affect other barcode manufacturers.

IOActive reported these potential issues to SICK via its PSIRT in late February 2020. SICK handled the disclosure process in a diligent manner and I would like to publicly thank SICK for its coordination and prompt response in providing its clients with proper mitigations.

EDITORIAL | May 27, 2020

File-Squatting Exploitation by Example

By Enrique Nissim

This will (hopefully) be a short story about a bug I found some time ago while auditing a .NET service from an OEM. It should be interesting as I have yet to find a description of how to exploit a similar condition.

Our service was running as SYSTEM and needed to periodically execute some other utilities as part of its workflow. Before running these auxiliary tools, it would check if the executable was properly signed by the vendor. Something like this:

public void CallAgent()
{
   string ExeFile = "C:\\Program Files\\Vendor\\Util.exe";
   if (!new Signtool().VerifyExe(ExeFile))
       return;
 
    // Execute Agent here
}

This is where it gets interesting. Of course we can’t control anything at that Program Files location, but what is that VerifyExe method doing?

internal class Signtool
    {
        private const string SignToolPath = "C:\\Windows\\Temp\\signtool.exe";
 
        private void ExtractSignTool()
        {
            byte[] signtool = QuatService.Resource1.signtool;
            using (FileStream fileStream = new FileStream("C:\\Windows\\Temp\\signtool.exe", FileMode.Create))
                fileStream.Write(signtool, 0, signtool.Length);
        }
 
        private void DeleteSignTool()
        {
            File.Delete("C:\\Windows\\Temp\\signtool.exe");
        }
 
        private bool Verify(string arg)
        {
            this.ExtractSignTool();
            Process process = new Process();
            process.StartInfo.UseShellExecute = false;
            process.StartInfo.RedirectStandardOutput = true;
            Path.GetDirectoryName(this.GetType().Assembly.Location);
            process.StartInfo.FileName = "C:\\Windows\\Temp\\signtool.exe";
            process.StartInfo.Arguments = arg;         
            process.Start();
            process.WaitForExit();
            this.DeleteSignTool();
            return process.ExitCode == 0 || process.ExitCode == 2;
        }
 
        public bool VerifyExe(string ExeFile)
        {
            return this.Verify("verify /pa \"" + ExeFile + "\"");
        }
 
    }

The code simply extracts a signature verification tool that it has embedded in C:\Windows\Temp as part of its resources, executes it to verify the target executable, and then deletes the tool as if nothing ever happened.

Did you catch the bug? The issue is in the FileMode.Create flag that gets passed as part of the FileStream call used to write the file.

What is object squatting?

I first read about squatting attacks in “The Art of Software Security Assessment” (which I highly recommend by the way). Essentially, squatting is an attack where you create an object before the legitimate application does. You can then manipulate the object and affect the normal behavior of the application. If an application is not careful and attempts to create a named object (such as Mutex, an Event, a Semaphore, etc.) in the global namespace, it might open an existing object instead, because another application could have already created an object with the exact same name. In this case, the Create method will succeed (https://docs.microsoft.com/en-us/windows/win32/sync/object-names):

This same method can be used for file squatting: the application acts as if it has created a file when it has actually opened an existing file.

There are two conditions necessary for this to be exploitable:

  1. The dwCreationDisposition parameter of the
    CreateFile function must be set incorrectly, leading the application to open an
    existing file instead of creating a new one. An incorrect setting is any
    setting except CREATE_NEW.
  2. The location where the file is being created must
    be writeable by potentially malicious users.

So in C/C++ code, if you see a call to CreateFile using CREATE_ALWAYS, it should raise a flag:

In .NET code, FileMode.Create maps to CREATE_ALWAYS:

Exploitation

At this point, we have a confirmed file squatting vulnerability:

  • The service is not using FileMode.CreateNew.
  • The location C:\Windows\Temp is writable by authenticated
    users.

We also have a race condition because there is a time window between when signtool.exe is extracted and when it is executed.

Therefore, we can exploit this vulnerability by leveraging Hardlinks and OpLocks:

The steps would be the following:

  1. Create
    a directory such as C:\Users\Public\Exploit.
  2. Create
    a file named dummy.txt inside the directory.
  3. Place
    payload.exe inside the directory.
  4. Create
    the Hardlink in C:\Windows\Temp\Signtool.exe to point to C:\Users\Public\Exploit\Dummy.txt.
  5. Set
    an OpLock on dummy.txt.
  6. When
    the OpLock triggers, recreate the Hardlink to point to payload.exe (we can do
    this because the file is ours and the ACL hasn’t changed).

Not so fast! If we check the behavior of the vulnerable “QuatService” with ProcMon, we see there are actually five calls to CreateFile instead of just three:

The first CreateFile is used by FileStream to write the signtool to disk. The second, third, and fourth calls are all part of the inner workings of CreateProcess. The final CreateFile is called with delete access in order to erase the file.

At a practical level, because of the short time window, the two additional CreateFile calls from CreateProcess could interfere with our goal. I found that the best settings for reliable, reproducible results were:

  • Use a second OpLock on dummy.txt after the first
    one is hit.
  • Call Sleep(1) to skip the third CreateFile
    (second one from CreateProcess).
  • Attempt to create the Hardlink to payload.exe in
    a loop. This is necessary because the Hardlink creation could fail due to the
    fact the service could still hold the handle from the third CreateFile.

Here is the code for a functional exploit for the vulnerability (tested on Windows 10 19041 and 18363):
https://github.com/IOActive/FileSquattingExample/blob/master/SquatExploit/SquatExploit/SquatExploit.c

Video demo of the exploit working:

The vulnerable service is included in the same GitHub project in case you want to play with it. If you come up with a better approach to increase the reliability of the exploit, please send me a message.

Mitigations

As already discussed, to avoid this situation there are two options:

  1. Use
    CREATE_NEW / FileMode.CreateNew and
    handle the potential error caused by an existing file.
  2. Write
    to a protected filesystem location.

What about the path redirection mitigations?

  • The Hardlink mitigation doesn’t apply here because we’re creating a link to our own file.
  • The SYSTEM %TEMP% change is not implemented yet. Even though this mitigation will definitely fix the vulnerability, it is worth noting that there will be still room for squatting other directories:
    • C:\Windows\Tasks
    • C:\windows\tracing
    • C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
    • C:\Windows\System32\spool\drivers\color
    • C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System

References

More on Object Squatting mitigations:

EDITORIAL | May 6, 2020

A Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Airworthiness Directive

By Ruben Santamarta

Several weeks ago, international regulators announced that they were ordering Boeing 787 operators to completely shut down the plane’s electrical power whenever it had been running for 51 days without interruption.1 The FAA published an airworthiness directive elaborating on the issue, and I was curious to see what kind of details were in this document.

While I eventually discovered that there wasn’t much information in the FAA directive, there was just enough to put me on track to search for the root cause of the issue. This blog post will leverage the interesting bits of information in the FAA directive to gain knowledge about some avionics concepts.

First, we need to introduce the parts of the 787’s architecture and systems that are relevant to this issue. The FAA directive explicitly uses acronyms, such as CDN or CCS, that need to be defined before moving to root cause analysis.

What is the Common Core System (CCS)?

As opposed to the federated avionics architectures, which make use of distributed avionics functions that are packaged as self-contained units, Integrated Modular Avionics (IMA)2 architectures employ a high-integrity, partitioned environment that hosts multiple avionics functions of different criticalities on a shared computing platform. Boeing engineers went one step further and developed the Common Core System (CCS) for the 787, a further enhancement based on an open IMA avionics technology.

Essentially the CCS is a hardware/software platform that provides computing, communication, and input-output (I/O) services for implementing real-time embedded systems, known as hosted functions.

Multiple hosted functions share the platform resources within a virtual system environment enforced by partitioning mechanisms that are implemented as part of the platform design, relying on a VxWorks 6533,4 OS.5

This virtual system partitioning environment guarantees that hosted functions are isolated from each other, so it supports highly critical applications but also lower levels of application integrity. Remember that international regulations define five levels of failure conditions, categorized by their effects on the aircraft, crew, and passengers:

Level A–Catastrophic

Failure may cause multiple fatalities, usually with loss of the airplane.

Level B–Hazardous

Failure has a large negative impact on safety or performance, reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers.

Level C–Major

Failure significantly reduces the safety margin or significantly increases crew workload. May result in passenger discomfort (or even minor injuries).

Level D–Minor

Failure slightly reduces the safety margin or slightly increases crew workload. Examples might include causing passenger inconvenience or a routine flight plan change.

Level E–No Effect

Failure has no impact on safety, aircraft operation, or crew workload.

Software approved to levels A, B, or C requires strong certification involving formal processes for verification and traceability

As a result, a DO-178B6 Level-A software may coexist in the same physical shared resource with a Level-E application.

Figure 1. VxWorks 653 Architecture7,A

Ideally, the applications cannot interfere with each other, regardless of faults that may occur within the hosted functions or the platform resources, which are predetermined and communicated to the platform components via loadable configuration files usually in either XML or proprietary binary formats.

Within the CCS we can find the following major components:

  • General Processing Modules (GPMs) to support functional processing needs
  • Remote Data Concentrators (RDCs) to support system analog signals, analog discrete signals, and serial digital interfaces (CAN bus8, A4299, etc.)
  • Avionics Full Duplex (A664-P7) Switched Ethernet10 network for communication between platform elements

These elements can be packaged as Line Replaceable Units (LRUs)11 or in module or card form, which can then be grouped within cabinets or integrated LRUs. As a result, the CCS is made up of:

  • Two (2) Common Computing Resource (CCR) cabinets
  • The Common Data Network (CDN)
  • 21 RDCs
Figure 2. CCS Architecture A

Common Computing Resource Cabinets

Each CCR cabinet has:

  • Two (2) Power Conditioning Modules (PCMs)
  • Eight (8) General Processing Modules (GPMs)
  • Two (2) ARINC 664-P7 network Cabinet Switches (ACSs)
  • Two (2) Fiber Optic Translator Modules (FOXs)
  • Two (2) Graphic Generators (part of the Display and Alert Crew System)
Figure 3. Boeing 787 CCR Cabinet12, A

Each GPM is an independent computing platform that hosts airplane systems’ operational software and provides the hosted applications a partitioned environment based on the ARINC 653 standard. Each GPM has the same hardware and core operating system.

The GPMs in these CCR cabinets run hosted functions such as Remote Power Distribution System (RPDS), Generator/Bus Power Control Unit (GCU/BPCU),13 Circuit Breaker Indication and Control, Landing Gear Indication and Control, Thrust Management Function, and Flight Management Function.

Common Data Network

The CDN is a high-integrity IEEE 802.3 Ethernet network utilizing IP addressing and related transport protocols (UDP). As an A664-P7 compliant network, it also implements deterministic timing and redundancy management protocols. The CDN uses both fiber optic cable and copper wire and moves system information between the various airplane systems connected to it, either directly or through ACSs, FOXs, or RDCs.

Figure 4. 787 Network Architecture A

The CDN is comprised of the network End System (ES) hosted in each connecting end node and multiple network switches.

End System

Within the context of an avionics network, as defined in the A664-P7 specification, we find that:

The main function of the End System (ES) is to provide services, which guarantee a secure and reliable data exchange to the partition software.

Essentially, the ES is assuming the role of a Network Interface Controller (NIC), capable of maintaining communication ports (queuing, sampling, or SAP) for messages written and read by multiple hosted applications. This is performed by exchanging Ethernet frames through a Virtual Link (VL), which is a conceptual communication object that defines a logical unidirectional connection from one source to one or more destination ES. The traffic flow in the VL is shaped not to exceed a configured Bandwidth Allocation Gap (BAG), which represents the minimum time interval between the first bits of two consecutive frames.

Figure 5. ES Communications in the CDN

The ES operating in the CDN (also in the switches) is physically separated from the host processor, interfacing through a PCI Bus. From a high-level perspective, it is comprised of:

  • One (1) custom ASIC
  • Two (2) COTS Ethernet PHY transceivers
  • Two (2) serial configuration memories
  • RAM
Figure 6. High-level Overview of End System Board

The ES can be configured from the host through a proprietary API. This configuration data has been previously generated using a DO-178B Level-A tool (ESBIN) and then stored in a custom file (es_config.bin).

The ES in a CDN switch implements much the same functionality except for some addressing and redundancy operations.

Remote Data Concentrators

There are 21 RDCs in the CCS.

Figure 7. Remote Data ConcentratorsA

These RDCs provide the interface between airplane systems that do not have the ability to support A664-P7 in the CDN.

The RDCs convert these signals to ARINC 664 data and vice versa, thus effectively acting as a gateway for a variety of analog devices, such as sensors or valves, ARINC 429 buses, and CAN subnets.

From an A664-P7 perspective, these RDCs map:

  • Analog signals to parameters
  • A429 to communication ports
  • CAN bus to both parameters and communication ports

As a result, the high-level architecture would be as follows.

Figure 8. High-level Overview of CCS

To better illustrate this architecture as a whole, we can oversimplify one of the hosted functions to see how all the pieces work together.

The landing gear control software is running in one of the CCRs, hosted in a GPM’s partition. This hosted function partition receives gear lever up/down data as well as gear and gear door position data from one of the 21 RDC via the CDN. Then, depending on the signals received, the landing gear control software may issue gear-sequencing commands to the proper RDC via the CDN. The RDC can then transfer the specific signal to those actuators that, for example, energize the control valves to retract and extend the landing gear or open and close the gear doors.

Root Cause Analysis

The FAA’s directive is scarce in technical details. It only contains a high-level description of the issue; however, it provides the reader with some key facts that can help with root cause analysis:

The FAA has received a report indicating that the stale-data monitoring function of CCS may be lost when continuously powered on for 51 days. This could lead to undetected or unannunciated loss of CDN message age validation, combined with a CDN switch failure. The CDN handles all the flight-critical data (including airspeed, altitude, attitude, and engine operation), and several potentially catastrophic failure scenarios can result from this situation. Potential consequences include:

  • Display of misleading primary attitude data for both pilots.
  • Display of misleading altitude on both pilots’ primary flight displays (PFDs).
  • Display of misleading airspeed data on both pilots’ PFDs, without annunciation
  • of failure, coupled with the loss of stall warning, or over-speed warning.
  • Display of misleading engine operating indications on both engines.

The potential loss of the stale-data monitoring function of the CCS when continuously powered on for 51 days, if not addressed, could result in erroneous flight-critical data being routed and displayed as valid data, which could reduce the ability of the flight crew to maintain the safe flight and landing of the airplane.

I will be carefully analyzing every single sentence.

The FAA has received a report indicating that the stale-data monitoring function of CCS may be lost when continuously powered on for 51 days.

Back in 2015, the FAA issued a similar directive14 although in that case the underlying problem was described a bit more explicitly.

We have been advised by Boeing of an issue identified during laboratory testing.

The software counter internal to the generator control units (GCUs) will overflow after 248 days of continuous power.

So basically, we can probably assume the situation is pretty much the same: Boeing identified this current issue during laboratory testing.

The 2015 FAA directive also explicitly mentioned that Boeing was working on a software patch to fix the issue; however, there is no mention of any upcoming patch in this current directive. As we will see later on, this makes sense if the vulnerability is hardware-related.

Once again, the mention of “51 days” initially points towards some kind of overflow in a counter.

This could lead to undetected or unannunciated loss of CDN message age validation, combined with a CDN switch failure.

This sentence tells us a lot of things about the nature of the issue. First, any catastrophic error in the CDN that goes undetected or ‘unannunciated’ in the 787 is highly unexpected, although it’s not entirely clear to me whether both the loss of CDN message age validation and CDN switch failure go undetected or just the first issue. Both maintenance engineers and pilots have the ability to check the status of the CCS switches and CDN LRUs through the maintenance pages in the Flight Deck. Also, any significant fault will be centralized, logged, and processed via the Central Maintenance Computing Function (CMCF).

Figure 9. CCS Status in the Flight Deck15

Also, pilots can reset both left and right CCR on the overhead panel; however, as the FAA directive states, a complete power shutdown is required, so we can assume a CCR reset doesn’t solve the problem. This means the issue is located deep in the hardware of a component that is present not only in the CCR, but also in other parts of the CDN.

Figure 10 CCR Reset Buttons16

So we have that:

  • The CDN loses the ability to perform age validation.
  • The CDN switches fail.

Let’s narrow down the list of potential suspects by analyzing how data communication integrity is enforced in the CDN.

Integrity Checking in the CDN

Bear in mind that the CCS is an asynchronous system where each partition is not only controlling when its data is produced but also decoupling this operation from the network interface. At the MAC level, the A664-P7 spec mandates that the output interfaces need to be transmitting, regardless of the PHY status, in order to prevent error propagation or re-transmission of old frames. Still, in an AFDX avionics network the order matters, so when the transmitting partition produces certain data, the receiver partition expects to collect that data in the same order.

In addition, the CCS operates following a redundancy policy having two different channels (‘A’ and ‘B’), although it is theoretically possible to configure them to operate independently.

Figure 11. Frame Processing Logic

In order to fulfill these requirements, the ES adds a Sequence Number (SN) after the AFDX payload when transmitting frames. This SN is 0 right after the ES reset and then 1-255. The redundant frames received in the ES follow the ‘first valid wins’ policy. Please note that in addition to the ordinal integrity there is a procedure to detect real redundant frames, where a configured constant (Skew Max) is used to limit the valid time window for two potentially redundant frames.

Figure 12. Regular AFDX Frame

This logic is common to all AFDX ES and I don’t think this functionality is where the actual flaw lies, as any problem would be more dependent on the amount of traffic flowing through the CDN rather than a specific time period. However, interestingly, there is something in the ES’ integrity checking and redundancy management that makes the 787 a little bit special: Boeing’s proprietary Error Detection Encoding (EDE) protocol.

EDE Protocol: A Promising Suspect

The EDE protocol is working at the VL level to add an additional layer of end-to-end integrity in the CDN.

When a VL is enabled with EDE, which is mandated by Boeing for critical and essential data, the transmitting ES encapsulates the payload with an EDE header and footer.

Figure 13. EDE Wrapped Frame

The EDE header and footer include the following fields:

  • SN: A 2-byte sequence number bound to a specific COM port. This value is incremented for each frame that is transmitted.
  • Timestamp: A 6-byte value that holds the time when the message was transmitted, using the local clock domain of the transmitting ES.
  • CRC X and CRC Y: These CRCs are calculated using the EDE Source ID (a 32-bit value only known for the ES transmitter and receiver in a VL), EDE timestamp, and payload.

The EDE timestamp is relative to the transmitting ES’ clock domain, so the CCS needs a way to centralize and keep track of all the local time references so any age validation can be performed accurately. This task is cyclically performed by the Time Management function, which maintains a table of relative offsets with the relationships between the time references for each ES present in the CDN. This is possible thanks to a request/response protocol where the Time Agent in each ES is periodically questioned by the Time Managers.

The resulting table of offsets is then broadcast to each ES through the Time Offset message so an ES can perform EDE age verification when receiving data from another ES. Obviously, the EDE Time Management packets required to calculate and propagate these offset tables are not subject to EDE age verification. 

Age verification in the CDN, in the context of the EDE protocol, relies on the consistency of these offset tables. So, what would happen if, for any reason, this fails? It is difficult to say without having access to a 787 (currently accepting donations) 😉 but I will try my best.

There are several possible scenarios:

  • The ES did not receive the offsets table.
    The message is forwarded to the EDE Redundancy Manager but a flag is set to indicate its age cannot be validated.
  • The age is greater than the maximum configured age.
    The message is directly discarded.
  • The age is less than the maximum configured age.
    This is the expected case. The message is forwarded to the EDE Redundancy Manager, eventually reaching the COM port.
  • The age is inconsistent.
    For some reason, the message seems to have an age that makes no sense. For example, let’s imagine that the timestamp set by the transmitting ES is close to its wrap-around value. After performing the required calculation, the receiving ES obtains a timestamp that has already wrapped-around, so it would look like the message had been received before it was actually sent. The message is accepted but still handled as its age is unknown.

Bearing in mind that this functionality is implemented in the ASIC and the timestamp should be derived from a counter, I think the whole issue may be around this logic. 

The key question is: How does the 51-day period fit in this scenario? Ok, let me present my theory.

A Potential Explanation

The 6-byte EDE timestamp is the key to make sure everything goes smoothly in the CDN. The most significant bit in this timestamp is set 0 by definition, so ideally we have 0x7FFFFFFFFFFF as the maximum coherent value for the EDE timestamp.

The ES receives the data from the hosted application through PCI, running at 33MHz, so it would be reasonable to implement a counter at a similar clock frequency so the ASIC can use that clock reference to timestamp ready-to-go messages. So let’s assume the counter is ideally operating at 33MHz and the timestamp is somehow derived from that counter, also taking into account different parameters, such as delays and latencies due to moving data across the different interfaces (RMII, PCI, etc.).

By calculating the frequency at which an ideal counter (starting at 0) should be operating in order to wrap-around the EDE timestamp (0x800000000000) after 51 days, we obtain ~32MHz. That’s pretty close to our assumption.

The CDN handles all the flight-critical data (including airspeed, altitude, attitude, and engine operation), and several potentially catastrophic failure scenarios can result from this situation.

We previously introduced the DO-178B certification levels where level A corresponds to a catastrophic failure, which prevents continued safe flight or landing.

Potential consequences include:

  • Display of misleading primary attitude data for both pilots.
  • Display of misleading altitude on both pilots’ primary flight displays (PFDs).
  • Display of misleading airspeed data on both pilots’ PFDs, without annunciation of failure, coupled with the loss of stall warning, or over-speed warning.
  • Display of misleading engine operating indications on both engines.

The consequences covered in the FAA document seem to be strictly related to the scenario where pilots can no longer trust their instruments, a problem that in past incidents has led to tragic consequences.

In a Boeing 787, all this data is handled by the Display Crew Alert System (DCAS). This system provides the pilots with all the audio, tactile, or visual indications that are necessary for the safe operation of the airplane, as you can see in the following image. 

Figure 14. DCAS includes Multiple Displays

The potential loss of the stale-data monitoring function of the CCS when continuously powered on for 51 days, if not addressed, could result in erroneous flight-critical data being routed and displayed as valid data, which could reduce the ability of the flight crew to maintain the safe flight and landing of the airplane.

We can read this last paragraph as a summary of what has been elaborated in this blog post.

Conclusion

Aviation security research is a complicated field, not only because of the secrecy that surrounds these technologies but also the commercial and corporate barriers that prevent access to the required equipment. Despite all these challenges, I think that any effort to promote this kind of research always pays off.

The timing is also interesting, as this flaw is coming to light almost a year after reporting our research to Boeing. Boeing acknowledged that they set up a fully functional aircraft and a laboratory to assess our claims (which involved the CDN), so I guess there is a chance that, maybe, follow-up research on their part identified this issue. In general terms, this would be a good side-effect of any security research, which is all about fostering the appropriate level of trust in the devices and organizations the people depend upon.

Do not take what I have presented here as the real root cause of the problem that Boeing detected. I may be right, but it’s just as likely that I’m wrong, and this was an exercise intended to satisfy my curiosity. Hopefully, you have learned something new and enjoyed reading about the topic. The more thoughtful people there are carefully scrutinizing critical systems, the better those systems will be in the long-term. That’s what this is all about.

For additional reading, please refer to the white paper of my original research, which was released during Black Hat 2019.

[A] IOActive White Paper: Arm IDA and Cross Check: Reversing the 787’s Core Network
[1] https://www.federalregister.gov/documents/2020/03/23/2020-06092/airworthiness-directives-the-boeing-company-airplanes
[2] https://www.aviationtoday.com/2007/02/01/integrated-modular-avionics-less-is-more/
[3] https://en.wikipedia.org/wiki/ARINC_653
[4] https://www.windriver.com/products/product-overviews/vxworks-653-product-overview-multi-core/vxworks-653-product-overview-multi-core.pdf
[5] https://www.windriver.com/customers/customer-success/aerospace-defense/boeing/ (404 link broken)
[6] https://en.wikipedia.org/wiki/DO-178B
[7] http://www.artist-embedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_WindRiver_Wilson.pdf
[8] https://en.wikipedia.org/wiki/CAN_bus
[9] https://en.wikipedia.org/wiki/ARINC_429
[10] https://pdfs.semanticscholar.org/5db4/b539ed7bdec182448ac8d7219db12a8bbc12.pdf
[11] https://en.wikipedia.org/wiki/Line-replaceable_unit
[12] https://bioage.typepad.com/.a/6a00d8341c4fbe53ef0162fbf813b6970d
[13], [14] https://s3.amazonaws.com/public-inspection.federalregister.gov/2015-10066.pdf
[15], [16] https://www.instagram.com/787guide/

EDITORIAL | April 13, 2020

Mismatch? CVSS, Vulnerability Management, and Organizational Risk

By Brook S.E. Schoenfield

I’ll never forget a meeting I attended where a security engineer demanded IT remediate each of the 30,000 vulnerabilities he had discovered. I know that he wasn’t just dumping an unvetted pile of vulnerabilities on IT; he’d done his best to weed out false-positive results, other errors, and misses before presenting the findings. These were real issues, ranked using the Common Vulnerability Scoring System (CVSS). There can be no doubt that in that huge (and overwhelming) pile were some serious threats to the organization and its digital assets.

The reaction of the IT attendees did not surprise me, nor did the security engineer’s subsequent reaction. It didn’t go well. Presented with that much work, IT refused, describing their already fully loaded plans and referring the security engineer to the CIO. In other words, “Security, take your vulnerabilities and be gone. We have other work to do.”

I’ve seen this same dynamic play out over and over again. Faced with 72,000 unqualified static analysis findings, the application team addressed none of them. Given 130,000 issues across an organization’s entire (scannable) infrastructure, the operations team’s first reaction is to do nothing.

The foregoing, real-world numbers are overwhelming. As one senior architect told me, “It took me an average of 15 minutes to figure out whether each of the five findings was a real issue. None of them was. In order to work through this set of findings, the effort will take about six person-weeks. We don’t have a resource to dedicate to this for six weeks, especially at a high false-positive rate. Much of it will be wasted effort.”

At the same time, we intuitively know that somewhere in those piles of vulnerabilities are issues that will be exploited and whose exploitation will cause serious harm: we know there’s organizational risk in the pile. But how do we find the dangerous needle in the haystack of vulnerability findings?

Knee-jerk security responses don’t help. I cannot count the number of times a security person has flatly stated, “Just patch it.” As though patching is the simplest thing in the world.

Upgrading a security patch may be simple for a single application; it’s not quite so straightforward when faced with thousands of potential issues across thousands of software components. This is especially true as potential disruption from unexpected side-effects must be considered when introducing new software (patches) into complex systems whose failure might have disastrous consequences.

As far as I’ve been able to see, few organizations cope well with tens of thousands of issues, each demanding a fix.  Plus, a continuing flow of new issues discovered each day adds to the work queue.

Ultimately, managing cybersecurity risk is a business decision just as managing any other organizational or operational risk is for an organization. When these issues are viewed from different, sometimes adversarial, technical silos, it is not surprising that a consensus understanding of organizational risk management priorities does not coalesce.

Up until recently, industry practice has been to prioritize issues based upon CVSS base score. However, research from 2014 indicates that using the CVSS base score may be no better than “choosing at random.”1 Maybe that’s why even organizations with fairly mature security and operations functions continue to be compromised through unpatched vulnerabilities.

Perhaps we’re fixing the wrong issues. Are there attributes that will help find the most likely exploits?

If we rely solely on CVSS, especially, published CVSS base scores, then yes, we will prioritize many issues that will rarely, perhaps never, be exploited by real attackers. The 2014 ground-breaking academic analysis by Allodi and Massacci2 found that CVSS base scores have been a poor predictor of exploitation. Their results have since been validated by some vendor-funded studies.3 CVSS has certainly proven useful for potential severity ratings, but using it as a predictor, or worse, as a risk calculation seems to be a mistake, despite the prevalence of the practice.

If not CVSS, then how can we identify the issues most likely to be exploited? Allodi and Massacci found that the addition of an exploit to an Exploit Kit dramatically increases the likelihood of use “in the wild,” that is, by real-world attackers. Their second strong predictor is Dark Web chatter about a vulnerability and its exploitation. When these two activities happen in tandem, one should fix the issue, and soon. This aligns well with the intuitive insights of today’s security practitioners who focused on threat intelligence and assessing their security posture through adversary emulation assessments such as red team exercises.

That should be easy, right? Unfortunately, processing Dark Web chatter proves non-trivial. Commercial products4 might not provide quite the right information, meaning that users must craft their own searches. Search capabilities in these products vary dramatically from full regular expressions to simple keyword searches. Buyer beware.

However, a recent announcement may signal the path forward. The Cyentia Institute and Kenna Security announced the release of their Exploit Prediction Scoring System (EPSS)5 and the research from which EPSS was built. Kenna Security is supplying the data from which the EPSS calculator works. EPSS employs further predictors than the two primary ones named by Allodi and Massacci; please see the EPSS research6 to learn more. EPSS may be vulnerability management’s better mousetrap.

EPSS includes the CVSS severity score. But it offers an entirely different dimension into the potential for active vulnerability misuse by real attackers. Don’t mistake CVSS for EPSS. They deliver very different facets of the vulnerability picture. Severity is our best guess as to how bad successful exploitation might be in a normalized, generalized case. CVSS lacks context, often glaringly missing. In comparison, EPSS attempts to tell us which vulnerabilities attackers will try, producing a percentage prediction of how likely exploitation will be at the time of calculation.

In the research (please see endnotes), exploitation of high-severity issues is actually much rarer than the misuse of low and medium issues. That may come as a surprise. One reason for the preference for low and medium issues might be the ease of crafting exploits. Plus, attackers hesitate using issues that require significant setup and preconditions. Instead, they routinely string together issues that in isolation aren’t all that impactful. But taken as a set of steps, the “kill chain”, several low and medium issues can lead to full compromise. A quick survey through a few of MITRE’s ATT&CK Threat Groups7 demonstrates how techniques are used to generate a kill chain.

When we rely upon CVSS severity as our priority, we fix the issues that in the most generalized case might cause the most damage, scheduling the lower severities for some later date. This is precisely the problem predictive analysis addresses: identify those issues in which attackers are interested, and prioritize those. It turns out that quite often, some low and medium severity issues are the ones to worry about.

Remove attacker leverage by patching some kill chain steps, and we raise the cost or even prevent chained attacks. But we can only do that if we know which issues, irrespective of their potential severity, attackers are considering. EPSS and predictive models, in general, may offer users a way to sift attacker-preferred issues from the chaff of overwhelming vulnerability queues.

I must warn readers that there are problems with EPSS. Today, all one can get is a single, point-in-time predictive score through a web browser interface. One-at-a-time scoring isn’t how vulnerability management must work in order to scale and provide just-in-time information. Unless a score is high enough to act upon when calculated, any score’s increase over time is the quantity to watch. Each vulnerability’s score needs to be monitored in order to identify issues that exceed the organization’s risk tolerance. Going to a website and checking tens of thousands of issues one at a time isn’t really workable.

If EPSS is going to be of use, there must be some automation for organizations to periodically check scores. The threat landscape is dynamic, so any solution must be equally dynamic. I hope that Cyentia and Kenna Security will provide a service or API through which organizations can monitor predictive score changes over time, and at scale.

EPSS is tightly coupled to the management of vulnerabilities. It would be a major error to apply EPSS, or any vulnerability misuse prediction method, to other aspects of organizational risk management. As always, every organization needs a robust and thorough understanding of its risk tolerances, dedicated skilled people to managing risk, and must adopt a rigorous and proven risk scoring mechanism, for instance, The Open Group standard: Factor Analysis of Information Risk (FAIR)8.

Importantly, EPSS will not supersede human risk analysis. EPSS and CVSS as well, are adjuncts to human analysis, not replacements. Well-resourced attackers appear to be using more so-called, zero-day vulnerabilities9, that is, vulnerabilities unknown before use and not yet fixed. To confront zero-days we must rely on our threat intelligence gathering and contextual risk analysis. Human threat modeling continues to be one of the best techniques for assessing potential danger from the unexpected appearance of a possible threat vector.

The Cyentia researchers indicated to me that Kenna Security owns the data used by EPSS. I attempted to contact someone at Kenna Security multiple times for this article, but Kenna Security has, unfortunately, not responded.

IOActive offers a full range of security consulting services, including vulnerability management, risk assessment, software security, and threat modeling.

Hopefully, this post helps your organization deal with your unmitigated vulnerability queue and better translate it into definable organizational and operational risks. Effective vulnerability management has the potential to free up resources that can be applied to other aspects of a robust cyber-risk program.

Cheers,
/brook s.e. Schoenfield
Master Security Architect
Director of Advisory Services

[1] Allodi, Luca & Massacci, Fabio. (2014). Comparing Vulnerability Severity and Exploits Using Case-Control Studies. ACM Transactions on Information and System Security. 17. 1-20. 10.1145/2630069. Thanks to Luis Servin (@lfservin) for the reference to this academic paper.

[2] http://seconomicsproject.eu/sites/default/files/seconomics/public/content-files/downloads/Comparing Vulnerabilities and Exploits using case-control studies.pdf

[3] NopSec, Inc’s 2016 and 2018 State of Vulnerability Risk Management Reports: https://www.nopsec.com/

[4] There is an open-source, public Dark Web search engine, DarkSearch.io. DarkSearch doesn’t offer full regular expressions, but it does offer several keyword and grouping enhancements.

[5] https://www.kennaresearch.com/tools/epss-calculator/

[6] Prioritization to Prediction, Cyentia Institute, and Kenna Security: https://www.kennasecurity.com/prioritization-to-prediction-report/images/Prioritization_to_Prediction.pdf

[7] https://mitre-attack.github.io/attack-navigator/enterprise/

[8] https://www.opengroup.org/forum/security-forum-0/risk-management

[9] Please see https://www.fireeye.com/blog/threat-research/2020/04/zero-day-exploitation-demonstrates-access-to-money-not-skill.html

EDITORIAL | April 2, 2020

10 Laws of Disclosure

By Cesar Cerrudo

In my 20+ years working in cyber security, I’ve reported more than 1000 vulnerabilities to a wide variety of companies, most found by our team at IOActive as well as some found by me. In reporting these vulnerabilities to many different vendors, the response (or lack thereof) I got is also very different, depending on vendor security maturity. When I think that I have seen everything related to vulnerability disclosures, I’ll have new experiences – usually bad ones – but in general, I keep seeing the same problems over and over again.

I’ve decided it would be a good idea to write about some Laws of Disclosure in order to help those companies that are not mature enough to improve their vulnerability disclosure processes.

Law 1: The vulnerability reporter is always right

It doesn’t matter if the vulnerability reporter is gross, stupid, or insults you, they have zero-day findings on your technology, so you’d better say “please” and “yes” to everything you can. It’s less complicated to deal with someone you don’t like than dealing with 0days in the wild, hurting your business.

Law 2: Have an easy-to-find and simple way to report vulnerabilities

It shouldn’t take more than a few seconds browsing your website to find how to report a vulnerability. Make it easy and simple as possible; otherwise, you’ll learn about the vulnerability on the news.

Law 3: Your rules and procedures are not important

Some vulnerability reporters don’t care about your rules and procedures for reporting, they don’t want your bounty or compensation. They don’t have to follow your rules; they just want the vulnerability reported and fixed.

Law 4: Keep vulnerability reporter up to date

Never keep the vulnerability reporter in the dark. Instantly acknowledge when you receive a vulnerability report, and then keep the finder posted about your actions and plans.

Law 5: Don’t play dirty

Never try to trick the reporter in any way to buy time or avoid public disclosure. Sooner or later the reporter will find out and 0day you. Time is never on your side, so use it wisely.

Law 6: Compensate

The vulnerability reporter is working for free for you, so always compensate them in some way, like a bounty or at least public acknowledgement and thanks.

Law 7: Forget NDAs and threats

The vulnerability reporter is not part of your company and don’t care about your lawyers. The vulnerability must always be fixed and then published, not hidden.

Law 8: Put the right people in place

Your people handing vulnerability reports should have the right knowledge and proper training. Never put lawyers or marketing people in charge of vulnerability disclosure; vulnerability finders don’t want to hear BS from them.

Law 9: Coordinate

Properly coordinate the release dates of your fix and the vulnerability advisory publication. You don’t want your customers exposed for one second.

Law 10: Always publish

Don’t sweep vulnerabilities under the carpet with silent fixes without telling your customers how and why they should update. If you do, the vulnerability reporter will make sure your customers know it, and they won’t be happy when they find out.

These Laws are based on my own experience, but if I’ve missed something, feel free to share your own experience and help contribute to a better vulnerability disclosure process. Also, if you ever need help with disclosures yourself, let me know via Twitter DM or email. I’ll be happy to help.