INSIGHTS, RESEARCH | April 17, 2024

Accessory Authentication – part 3/3

This is Part 3 of a 3-Part series. You can find Part 1 here and Part 2 here.

Introduction

In this post, we continue our deep dive comparison of the security processors used on a consumer product and an unlicensed clone. Our focus here will be identifying and characterizing memory arrays.

Given a suitably deprocessed sample, memories can often be recognized as such under low magnification because of their smooth, regular appearance with distinct row/address decode logic on the perimeter, as compared to analog circuitry (which contains many large elements, such as capacitors and inductors) or autorouted digital logic (fine-grained, irregular structure).

Identifying memories and classifying them as to type, allows the analyst to determine which ones may contain data relevant to system security and assess the difficulty and complexity of extracting their content.

OEM Component

Initial low-magnification imaging of the OEM secure element identified 13 structures with a uniform, regular appearance consistent with memory.

Higher magnification imaging resulted in three of these structures being reclassified as non-memory (two as logic and one as analog), leaving 10 actual memories.

Figure 1. Logic circuitry initially labeled as memory due to its regular structure
Figure 2. Large capacitor in analog block

Of the remaining 10 memories, five distinct bit cell structures were identified:

  • Single-port (6T) SRAM
  • Dual-port (8T) SRAM
  • Mask ROM
  • 3T antifuse
  • Floating gate NOR flash

Single-port SRAM

13 instances of this IP were found in various sized arrays, with capacities ranging from 20 bits x 8 rows to 130 bits x 128 rows.

Some of these memories include extra columns, which appear to be intended as spares for remapping bad columns. This is a common practice in the semiconductor industry to improve yield: memories typically cover a significant fraction of the die surface and thus are responsible for a large fraction of manufacturing defects. If the device can remain operable despite a defect in a memory array, the overall yield of usable chips will be higher.

Figure 3. Substrate overview of a single-port SRAM array
Figure 4. Substrate closeup view of single-port SRAM bit cells

Dual-port SRAM

Six instances of this IP were found, each containing 320 bit cells (40 bytes).

Figure 5. Dual-port SRAM cells containing eight transistors

Mask ROM

Two instances of this IP were found, with capacities of 256 Kbits and 320 Kbits respectively. No data was visible in a substrate view of the array.

Figure 6. Substrate view of mask ROM showing no data visible

A cross section (Figure 7) showed irregular metal 1 patterns as well as contacts that did not go to any wires on metal 1, strongly suggesting this was a metal 1 programmed ROM. A plan view of metal 1 (Figure 8) confirms this. The metal 1 pattern also shows that the transistors are connected in series strings of 8 bits (with each transistor in the string either shorted by metal or not, in order to encode a logic 0 or 1 value), completing the classification of this memory as a metal 1 programmed NAND ROM.

Figure 7. Cross section of metal 1 programmed NAND ROM showing irregular metal patterns and via with unconnected top
Figure 8. Top-right corner of one ROM showing data bits and partial address decode logic

IOActive successfully extracted the contents of both ROMs and determined that they were encrypted. Further reverse engineering would be necessary to locate the decryption circuitry in order to make use of the dumps.

Antifuse

Five instances of this IP were found, four with a capacity of 4 rows x 32 bits (128 bits) and one with a capacity of 32 rows x 64 bits (2048 bits).

The bit cells consist of three transistors (two in series and one separate) and likely function by gate dielectric breakdown: during programming, high voltage applied between a MOSFET gate and the channel causes the dielectric to rupture, creating a short circuit between the drain and gate terminals.

Antifuse memory is one-time programmable and is expensive due to the very low density (significantly larger bit cell compared to flash or ROM); however, it offers some additional security because the ruptured dielectric is too thin to see in a top-down view of the array, rendering it difficult to extract the contents of the bit cells. It is also commonly used for small memories when the complexity and re-programmability of flash memory is unnecessary, such as for storing trim values for analog blocks or remapping data for repairing manufacturing defects in SRAM arrays.

Figure 9. Antifuse array
Figure 10. Cross section of antifuse bit cells

Flash

A single instance of this IP was found, with a capacity of 1520 Kbits.

This memory uses floating-gate bit cells connected in a NOR topology, as is common for embedded flash memories on microcontrollers.

Figure 11. Substrate plan view of bit cells
Figure 12. Cross section of NOR Flash memory

Clone Component

Floorplan Overview

Figure 13. Substrate view of clone secure element after removal of metal and polysilicon

The secure element from the clone device contains three obvious memories, located at the top right, bottom left, and bottom right corners.

Lower-left Memory

The lower-left memory consists of a bit cell array with addressing logic at the top, left, and right sides. Looking closely, it appears to be part of a larger rectangular block that contains a large region of analog circuitry above the memory, as well as a small amount of digital logic.

This is consistent with the memory being some sort of flash (likely the primary code and data storage for the processor). The large analog block is probably the high voltage generation for the program/erase circuitry, while the small digital block likely controls timing of program/erase operations.  

The array appears to be structured as 32 bits (plus 2 dummy or ECC columns) x 64 blocks wide, by 2 bits * 202 rows (likely 192 + 2 dummy features + 8 spare). This gives an estimated usable array capacity of 786432 bits (98304 bytes, 96kB).

Figure 14. Overview of bottom left (flash) memory
Figure 15. SEM substrate image of flash memory

A cross section was taken, which did not show floating gates (as compared to the OEM component). This suggests that this component is likely using a SONOS bit cell or similar charge-trapping technology.

Lower-right Memory

The lower-right memory consists of two identical blocks side-by-side, mirrored left-to-right. Each block consists of 128 columns x 64 cells x 3 blocks high, for a total capacity of 49152 bits (6144 bits, 6 kB).

Figure 16. Lower-right memory

At higher magnification, we can see that the individual bit cells consist of eight transistors, indicative of dual-port SRAM—perhaps some sort of cache or register file.

Figure 17. Dual-port SRAM on clone secure element (substrate)
Figure 18. Dual-port SRAM on clone secure element (metal 1)

Upper-right Memory

The upper – right memory consists of a 2 x 2 grid of identical tiles, each 128 columns x 160 rows (total capacity 81920 bits/10240 bytes/10 kB).

Figure 19. Upper-right SRAM array

Upon closer inspection, the bit cell consists of six transistors arranged in a classic single-port SRAM structure.

Figure 20. SEM substrate image of 6T SRAM cells
Figure 21. SEM metal 1 image of 6T SRAM cells

Concluding Remarks

The OEM component contains two more memory types (mask ROM and antifuse) than the clone component. It has double the flash memory and nearly triple the persistent storage (combined mask ROM and flash) capacity of the clone, but slightly less SRAM.

Overall, the memory technology of the clone component is significantly simpler and lower cost.

Overall Conclusions

OEMs secure their accessory markets for the following reasons:

  • To ensure an optimal user experience for their customers
  • To maintain the integrity of their platform
  • To secure their customers’ personal data
  • To secure revenue from accessory sales

OEMs routinely use security chips to protect their platforms and accessories; cost is an issue for OEMs when securing their platforms, which potentially can lead to their security being compromised.

Third-party solution providers, on the other hand:

  • Invest in their own labs and expertise to extract the IP necessary to make compatible solutions
  • Employ varied attack vectors with barriers of entry ranging from non-invasive toolsets at a cost of $1,000 up, to an invasive, transistor-level Silicon Lab at a cost of several million dollars
  • Often also incorporate a security chip to secure their own solutions, and to in turn lock out their competitors
  • Aim to hack the platform and have the third-party accessory market to themselves for as long as possible
EDITORIAL | September 15, 2020

Security Makes Cents: Perspectives on Security from a Finance Leader

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 | August 1, 2019

Eight Steps to Improving Your Supply Chain Security Program

In this second, of a two-part blog series on the supply chain, I’ll discuss how to improve your supply chain security.

Supply chain attacks aren’t anything new, but we’re hearing more about them lately, as threat actors continue to find new ways to breach networks. In fact, the most well-known supply chain attack dates back to 2013 when Target was breached through its HVAC supplier, exposing the credit card data of 110 million customers. In the last two years, NotPetya, Trisis and the more recent Wipro compromise have served as not-so-gentle reminders that supply chain attacks are damaging, costly and present many risks to both businesses and their suppliers.

The fact is: the more secure an organization itself is, the more attractive that organization’s supply chain becomes in the mind of the attacker. An attacker wants to find the easiest pathway to get into the network so oftentimes, it’s the supplier who has an exploitable vulnerability that can get them full access into the original target’s network.

The more secure an organization itself is, the more attractive that organization’s supply chain becomes in the mind of the attacker.

Most threat actors organizations face today are very smart. They know they don’t actually need to leverage a sophisticated, complex supply chain hack to wreak havoc on a network, steal data or intellectual property, or cause catastrophic damage. All they really need to do is look for unpatched servers and systems or send out a simple phishing email. Just look at the recent Wipro breach where dozens of employees’ emails were compromised through a phishing scam that gave the threat actors access to over 100 Wipro computer systems to mount attacks on a dozen Wipro customers.

Phishing and the use of stolen credentials are repeat offenders that keep coming up over and over again. In fact, the 2019 Verizon Data Breach Investigations Report cited that 32 percent of the breaches involved phishing scams and 29 percent involved the use of stolen credentials.

An unsophisticated cyberattack often yields a better outcome for an attacker — saving them time, money and resources while making attribution more difficult, so it’s in their best interest to take the easier path to their goal. We’ve seen many successful breaches where attackers penetrated systems through hardcoded credentials or just poorly patched systems.

That’s why, if you’re not protecting your own network against basic threat actors, doing your due diligence to properly patch, and holding your suppliers accountable for securing their own networks, you have no hope in protecting against nation-states or more capable threat actors. This is where third-party testing comes in handy to trust and verify your suppliers.

Here are a few key steps you can take today to build a supply chain security program:

  1. Know your suppliers and look upstream as well as downstream. Start with your tier-one suppliers and then identify tier twos and others. Take a full inventory of who you do business with so you can identify any weak links.
  2. Conduct a risk assessment. Once you’ve identified all your partners, you need to properly assess each one’s cybersecurity posture so you know the risks they may pose to your organization. You must consider where each device or component was built and who exactly built it. Is there a possible backdoor or counterfeit part? Or is it just the more likely software quality issues that can result in a breach?
  3. Utilize third-party testing. Hire a third-party firm to test your system, and that of your suppliers, to provide actionable results on what you need to fix first.
  4. Regularly scan and patch all vulnerable systems.
  5. Use strong passwords. Teach your employees about the importance of using strong passwords and not recycling them across accounts.
  6. Ensure your staff has set up multi-factor authentication everywhere possible.
  7. Conduct regular security awareness training to teach employees how to identify phishing scams, update software and become more security-conscious.
  8. Harden the security of the devices connected to your networks.

Make sure you’re not worrying about low-likelihood events like supply chain attacks if you’re not doing the basics of foundational security at your own organization. It’s really quite simple: you need to crawl before you walk, and walk before you run.

EDITORIAL | July 17, 2019

Supply Chain Risks Go Beyond Cyber: Focus on Operational Resilience

In this first, of a two-part blog series on supply chain, I’ll discuss the security and operational risk in today’s supply chain.

In the past 20 years, we’ve seen the globalization of the supply chain and a significant movement to disperse supply chains outside national borders. With this globalization comes many supply chain risks — risks that go beyond just cyber attacks and demonstrate a need for stronger operational resilience.

Most organizations want to take advantage of tariff treaties and overall cost savings by outsourcing the manufacturing and production of their goods, resulting in greater operational efficiencies. However, much of this supply chain globalization has actually made our supply chain longer, much more complex and less resilient. Nowadays, a product may have to go through multiple countries before it’s complete, offering more opportunities for things to go wrong from a supply chain risk perspective.

In the last two years alone, the global supply chain has experienced major disruptions from natural disasters, weather-related events and factory fires that have put organizations out of business. One of the most notable supply chain disruptions occurred in the 2000s when the production of hard disk drives produced in Thailand was gravely impacted by significant flooding in the country. The flooding impacted the whole logistics chain including the hardware manufacturers, component suppliers, the transportation of the devices, as well as the manufacturing plants and facilities involved in the hard drive development.

Puerto Rico is home to more than 40 drug manufacturing companies so when Hurricane Maria’s tragic landfall in 2017 caused power outages, loss of life and utter devastation, it also disrupted the island’s biggest export: pharmaceutical and medical devices. Even a year after the hurricane, there were still supply chain disruptions involving a major manufacturing plant supplying IV saline bags to U.S. hospitals.

Another, more direct supply chain risk involves the delivery of sub-standard or altered components — this is when the supplier is seeking enhanced profit by delivering low-cost goods. There are many examples of this over the years including the 2010 Vision Tech scandal where the company was charged with selling 59,000 counterfeit microchips to U.S. Navy.  Driven by profit-seeking behavior, in 2018, the owner of PRB Logics Corporation was arrested and charged with selling counterfeit computer parts. They were repainted and remarked with counterfeit logos and PRB took it a step further to defraud the purchaser of the equipment by falsifying test results when the buyer wanted verification that the components were delivered as specified.

While it’s difficult to predict when disasters, hurricanes or flooding may occur, or to know for certain if a device has been tampered with, there are several steps organizations can take to improve their supply chain management and overall operational resiliency, including:

  1. Don’t just select one risk to manage. Take a holistic view of your entire supply chain and try to identify the weakest links.
  2. Consider all potential disruptions and ways you can build and design your supply chain to keep it operational in the face of any foreseeable and unforeseeable challenges. If the suppliers with whom you deal directly are required to have a supply chain program and they expect the same of their suppliers, this will create a far more resilient supply chain of higher integrity.
  3. Don’t use substandard or modified/altered components and parts to save money. This can result in major issues with supply chain integrity and data integrity down the road.
  4. Trust and verify. Know what’s in your firmware and ensure there are no counterfeit hardware components. You need to verify what you cannot trust, including components from a third-party. You need to trust what you cannot verify. Even if you trust a vendor, there’s always the possibility of a compromise further up the supply chain.
  5. Understand high-order effects within your supply chain. A first-order effect directly impacts that device, whereas a second-order effect is simply the consequence of the first effect of an event.
RESEARCH | March 9, 2018

Robots Want Bitcoins too!

Ransomware attacks have boomed during the last few years, becoming a preferred method for cybercriminals to get monetary profit by encrypting victim information and requiring a ransom to get the information back. The primary ransomware target has always been information. When a victim has no backup of that information, he panics, forced to pay for its return.
(more…)

EDITORIAL | January 31, 2018

Security Theater and the Watch Effect in Third-party Assessments

Before the facts were in, nearly every journalist and salesperson in infosec was thinking about how to squeeze lemonade from the Equifax breach. Let’s be honest – it was and is a big breach. There are lessons to be learned, but people seemed to have the answers before the facts were available.

It takes time to dissect these situations and early speculation is often wrong. Efforts at attribution and methods take months to understand. So, it’s important to not buy into the hysteria and, instead, seek to gain a clear vision of the actual lessons to be learned. Time and again, these supposed “watershed moments” and “wake-up calls” generate a lot of buzz, but often little long-term effective action to improve operational resilience against cyber threats.


At IOActive we guard against making on-the-spot assumptions. We consider and analyze the actual threats, ever mindful of the “Watch Effect.” The Watch Effect can be simply explained:  you wear a watch long enough, you can’t even feel it.
I won’t go into what third-party assessments Equifax may or may not have had because that’s largely speculation. The company has probably been assessed many times, by many groups with extensive experience in the prevention of cyber threats and the implementation of active defense. And they still experienced a deep impact cyber incursion.

The industry-wide point here is: Everyone is asking everyone else for proof that they’re secure.

The assumption and Watch Effect come in at the point where company executives think their responses to high-level security questions actually mean something.

Well, sure, they do mean something. In the case of questionnaires, you are asking a company to perform a massive amount of tedious work, and, if they respond with those questions filled in, and they don’t make gross errors or say “no” where they should have said “yes”, that probably counts for something.

But the question is how much do we really know about a company’s security by looking at their responses to a security questionnaire?

The answer is, “not much.”

As a company that has been security testing for 20 years now, IOActive has successfully breached even the most advanced cyber defenses across countless companies during penetration tests that were certified backwards and forwards by every group you can imagine. So, the question to ask is, “Do questionnaires help at all? And if so, how much?”
 
Here’s a way to think about that.

At IOActive we conduct full, top-down security reviews of companies that include business risk, crown-jewel defense, and every layer that these pieces touch. Because we know how attackers get in, we measure and test how effective the company is at detecting and responding to cyber events – and use this comprehensive approach to help companies understand how to improve their ability to prevent, detect, and ever so critically, RESPOND to intrusions. Part of that approach includes a series of interviews with everyone from the C-suite to the people watching logs. What we find is frightening.

We are often days or weeks into an assessment before we discover a thread to pull that uncovers a major risk, whether that thread comes from a technical assessment or a person-to-person interview or both.

That’s days—or weeks—of being onsite with full access to the company as an insider.

Here’s where the Watch Effect comes in. Many of the companies have no idea what we’re uncovering or how bad it is because of the Watch Effect. They’re giving us mostly standard answers about their day-to-day, the controls they have in place, etc. It’s not until we pull the thread and start probing technically – as an attacker – that they realize they’re wearing a broken watch.

Then they look down at a set of catastrophic vulnerabilities on their wrist and say, “Oh. That’s a problem.”

So, back to the questionnaire…

If it takes days or weeks for an elite security firm to uncover these vulnerabilities onsite with full cooperation during an INTERNAL assessment, how do you expect to uncover those issues with a form?

You can’t. And you should stop pretending you can. Questionnaires depend far too much upon the capability and knowledge of the person or team filling it out, and often are completed with impartial knowledge. How would one know if a firewall rule were updated improperly to “any/any” in the last week if it is not tested and verified?

To be clear, the problem isn’t that third party assessments only give 2/10 in security assessment value. The problem is that executives THINK it’s giving them 6/10, or 9/10.

It’s that disconnect that’s causing the harm.

Eventually, companies will figure this out. In the meantime, the breaches won’t stop.

Until then, we as technical practitioners can do our best to convince our clients and prospects to understand the value these types of cursory, external glances at a company provide. Very little. So, let’s prioritize appropriately.

EDITORIAL | January 24, 2018

Cryptocurrency and the Interconnected Home

There are many tiny elements to cryptocurrency that are not getting the awareness time they deserve. To start, the very thing that attracts people to cryptocurrency is also the very thing that is seemingly overlooked as a challenge. Cryptocurrencies are not backed by governments or institutions. The transactions allow the trader or investor to operate with anonymity. We have seen a massive increase in the last year of cyber bad guys hiding behind these inconspicuous transactions – ransomware demanding payment in bitcoin; bitcoin ATMs being used by various dealers to effectively clean money.

Because there are few regulations governing crypto trading, we cannot see if cryptocurrency is being used to fund criminal or terrorist activity. There is an ancient funds transfer capability, designed to avoid banks and ledgers called Hawala. Hawala is believed to be the method by which terrorists are able to move money, anonymously, across borders with no governmental controls. Sound like what’s happening with cryptocurrency? There’s an old saying in law enforcement – follow the money. Good luck with that one.

Many people don’t realize that cryptocurrencies depend on multiple miners. This allows the processing to be spread out and decentralized. Miners validate the integrity of the transactions and as a result, the miners receive a “block reward” for their efforts. But, these rewards are cut in half every 210,000 blocks. A bitcoin block reward when it first started in 2009 was 50 BTC, today it’s 12.5. There are about 1.5 million bitcoins left to mine before the reward halves again.

This limit on total bitcoins leads to an interesting issue – as the reward decreases, miners will switch their attention from bitcoin to other cryptocurrencies. This will reduce the number of miners, therefore making the network more centralized. This centralization creates greater opportunity for cyber bad guys to “hack” the network and wreak havoc, or for the remaining miners to monopolize the mining.

At some point, and we are already seeing the early stages of this, governments and banks will demand to implement more control. They will start to produce their own cryptocurrency. Would you trust these cryptos? What if your bank offered loans in Bitcoin, Ripple or Monero? Would you accept and use this type of loan?

Because it’s a limited resource, what happens when we reach the 21 million bitcoin limit? Unless we change the protocols, this event is estimated to happen by 2140.  My first response  – I don’t think bitcoins will be at the top of my concerns list in 2140.

The Interconnected Home

So what does crypto-mining malware or mineware have to do with your home? It’s easy enough to notice if your laptop is being overused – the device slows down, the battery runs down quickly. How can you tell if your fridge or toaster are compromised? With your smart home now interconnected, what happens if the cyber bad guys operate there? All a cyber bad guy needs is electricity, internet and CPU time. Soon your fridge will charge your toaster a bitcoin for bread and butter. How do we protect our unmonitored devices from this mineware? Who is responsible for ensuring the right level of security on your home devices to prevent this?

Smart home vulnerabilities present a real and present danger. We have already seen baby monitors, robots, and home security products, to name a few, all compromised. Most by IOActive researchers. There can be many risks that these compromises introduce to the home, not just around cryptocurrency. Think about how the interconnected home operates. Any device that’s SMART now has the three key ingredients to provide the cyber bad guy with everything he needs – internet access, power and processing.

Firstly, I can introduce my mineware via a compromised mobile phone and start to exploit the processing power of your home devices to mine bitcoin. How would you detect this? When could you detect this? At the end of the month when you get an electricity bill. Instead of 50 pounds a month, its now 150 pounds. But how do you diagnose the issue? You complain to the power company. They show you the usage. It’s correct. Your home IS consuming that power.

They say that crypto mining is now using as much power as a small country. That’s got a serious impact on the power infrastructure as well as the environment. Ahhhh you say, I have a smart meter, it can give me a real time read out of my usage. Yes, it’s a computer. And, if I’m a cyber bad guy, I can make that computer tell me the latest football scores if I want. The key for a corporation when a cyber bad guy is attacking is to reduce dwell time. Detect and stop the bad guy from playing in your network. There are enterprise tools that can perform these tasks, but do you have these same tools at home? How would you Detect and React to a cyber bad guy attacking your smart home?

IOActive has proven these attack vectors over and over. We know this is possible and we know this is almost impossible to detect. Remember, a cyber bad guy makes several assessments when deciding on an attack – the risk of detection, the reward for the effort, and the penalty for capture. The risk of detection is low, like very low. The reward, well you could be mining blocks for months without stopping, that’s tens of thousands of dollars. And the penalty… what’s the penalty for someone hacking your toaster… The impact is measurable to the homeowner. This is real, and who’s to say not happening already. Ask your fridge!!

What’s the Answer –  Avoid Using Smart Home Devices Altogether?

No, we don’t believe the best defense is to avoid adopting this new technology. The smart and interconnected home can offer its users fantastic opportunities. We believe that the responsibility rests with the manufacturer to ensure that devices are designed and built in a safe and secure way. And, yes, everything is designed; few things are designed well.IOActive researchers spend 99% of their time trying to identify vulnerabilities in these devices for the safety of everyone, not just corporations. The power is in the hands of the consumer. As soon as the consumer starts to purchase products based not only on their power efficiency, but their security rating as well, then we will see a shift into a more secure home.

In the meantime, consider the entry point for most cyber bad guys. Generally, this is your desktop, laptop or mobile device. Therefore, ensure you have suitable security products running on these devices, make sure they are patched to the correct levels, be conscious of the websites you are visiting. If you control the available entry points, you will go a long way to protecting your home.
RESEARCH | January 11, 2018

SCADA and Mobile Security in the IoT Era

Two years ago, we assessed 20 mobile applications that worked with ICS software and hardware. At that time, mobile technologies were widespread, but Internet of Things (IoT) mania was only starting. Our research concluded the combination of SCADA systems and mobile applications had the potential to be a very dangerous and vulnerable cocktail. In the introduction of our paper, we stated “convenience often wins over security. Nowadays, you can monitor (or even control!) your ICS from a brand-new Android [device].”


Today, no one is surprised at the appearance of an IIoT. The idea of putting your logging, monitoring, and even supervisory/control functions in the cloud does not sound as crazy as it did several years ago. If you look at mobile application offerings today, many more ICS- related applications are available than two years ago. Previously, we predicted that the “rapidly growing mobile development environment” would redeem the past sins of SCADA systems.
The purpose of our research is to understand how the landscape has evolved and assess the security posture of SCADA systems and mobile applications in this new IIoT era.

SCADA and Mobile Applications
ICS infrastructures are heterogeneous by nature. They include several layers, each of which is dedicated to specific tasks. Figure 1 illustrates a typical ICS structure.

Figure 1: Modern ICS infrastructure including mobile apps

Mobile applications reside in several ICS segments and can be grouped into two general families: Local (control room) and Remote.


Local Applications

Local applications are installed on devices that connect directly to ICS devices in the field or process layers (over Wi-Fi, Bluetooth, or serial).

Remote Applications
Remote applications allow engineers to connect to ICS servers using remote channels, like the Internet, VPN-over-Internet, and private cell networks. Typically, they only allow monitoring of the industrial process; however, several applications allow the user to control/supervise the process. Applications of this type include remote SCADA clients, MES clients, and remote alert applications. 

In comparison to local applications belonging to the control room group, which usually operate in an isolated environment, remote applications are often installed on smartphones that use Internet connections or even on personal devices in organizations that have a BYOD policy. In other words, remote applications are more exposed and face different threats.

Typical Threats And     Attacks

In this section, we discuss the typical threats to this heterogeneous landscape of applications and how attacks could be conducted. We also map the threats to the application types.
 
Threat Types
There are three main possible ICS threat types:
  • Unauthorized physical access to the device or “virtual” access to device data
  • Communication channel compromise (MiTM)
  • Application compromise

Table 1 summarizes the threat types.

Table 1: SCADA mobile client threat list
 
Attack Types
Based on the threats listed above, attacks targeting mobile SCADA applications can be sorted into two groups.
 
Directly/indirectly influencing an industrial process or industrial network infrastructure
This type of attack could be carried out by sending data that would be carried over to the field segment devices. Various methods could be used to achieve this, including bypassing ACL/ permissions checks, accessing credentials with the required privileges, or bypassing data validation.
 
Compromising a SCADA operator to unwillingly perform a harmful action on the system
The core idea is for the attacker to create environmental circumstances where a SCADA system operator could make incorrect decisions and trigger alarms or otherwise bring the system into a halt state.
 
Testing Approach
Similar to the research we conducted two years ago, our analysis and testing approach was based on the OWASP Mobile Top 10 2016. Each application was tested using the following steps:
  • Perform analysis and fill out the test checklist
  • Perform client and backend fuzzing
  • If needed, perform deep analysis with reverse engineering
We did not alter the fuzzing approach since the last iteration of this research. It was discussed in depth in our previous whitepaper, so its description is omitted for brevity.
We improved our test checklist for this assessment. It includes:
  • Application purpose, type, category, and basic information 
  • Permissions
  • Password protection
  • Application intents, exported providers, broadcast services, etc.
  • Native code
  • Code obfuscation
  • Presence of web-based components
  • Methods of authentication used to communicate with the backend
  • Correctness of operations with sessions, cookies, and tokens 
  • SSL/TLS connection configuration
  • XML parser configuration
  • Backend APIs
  • Sensitive data handling
  • HMI project data handling
  • Secure storage
  • Other issues
Reviewed Vendors
We analyzed 34 vendors in our research, randomly selecting  SCADA application samples from the Google Play Store. We did, however, favor applications for which we were granted access to the backend hardware or software, so that a wider attack surface could be tested.
 
Additionally, we excluded applications whose most recent update was before June 2015, since they were likely the subject of our previous work. We only retested them if there had been an update during the subsequent two years.
 
Findings
We identified 147 security issues in the applications and their backends. We classified each issue according to the OWASP Top Ten Mobile risks and added one additional category for backend software bugs.
 
Table 4 presents the distribution of findings across categories. The “Number of Issues” column reports the number of issues belonging to each category, while the “% of Apps” column reports how many applications have at least one vulnerability belonging to each category.
Table 4. Vulnerabilities statistics

In our white paperwe provide an in-depth analysis of each category, along with examples of the most significant vulnerabilities we identified. Please download the white paper for a deeper analysis of each of the OWASP category findings.

Remediation And Best Practices
In addition to the well-known recommendations covering the OWASP Top 10 and OWASP Mobile Top 10 2016 risks, there are several actions that could be taken by developers of mobile SCADA clients to further protect their applications and systems.

In the following list, we gathered the most important items to consider when developing a mobile SCADA application:

  • Always keep in mind that your application is a gateway to your ICS systems. This should influence all of your design decisions, including how you handle the inputs you will accept from the application and, more generally, anything that you will accept and send to your ICS system.
  • Avoid all situations that could leave the SCADA operators in the dark or provide them with misleading information, from silent application crashes to full subverting of HMI projects.
  • Follow best practices. Consider covering the OWASP Top 10, OWASP Mobile Top 10 2016, and the 24 Deadly Sins of Software Security.
  • Do not forget to implement unit and functional tests for your application and the backend servers, to cover at a minimum the basic security features, such as authentication and authorization requirements.
  • Enforce password/PIN validation to protect against threats U1-3. In addition, avoid storing any credentials on the device using unsafe mechanisms (such as in cleartext) and leverage robust and safe storing mechanisms already provided by the Android platform.
  • Do not store any sensitive data on SD cards or similar partitions without ACLs at all costs Such storage mediums cannot protect your sensitive data.
  • Provide secrecy and integrity for all HMI project data. This can be achieved by using authenticated encryption and storing the encryption credentials in the secure Android storage, or by deriving the key securely, via a key derivation function (KDF), from the application password.
  • Encrypt all communication using strong protocols, such as TLS 1.2 with elliptic curves key exchange and signatures and AEAD encryption schemes. Follow best practices, and keep updating your application as best practices evolve. Attacks always get better, and so should your application.
  • Catch and handle exceptions carefully. If an error cannot be recovered, ensure the application notifies the user and quits gracefully. When logging exceptions, ensure no sensitive information is leaked to log files.
  • If you are using Web Components in the application, think about preventing client-side injections (e.g., encrypt all communications, validate user input, etc.).
  • Limit the permissions your application requires to the strict minimum.
  • Implement obfuscation and anti-tampering protections in your application.

Conclusions
Two years have passed since our previous research, and things have continued to evolve. Unfortunately, they have not evolved with robust security in mind, and the landscape is less secure than ever before. In 2015 we found a total of 50 issues in the 20 applications we analyzed and in 2017 we found a staggering 147 issues in the 34 applications we selected. This represents an average increase of 1.6 vulnerabilities per application. 

We therefore conclude that the growth of IoT in the era of “everything is connected” has not led to improved security for mobile SCADA applications. According to our results, more than 20% of the discovered issues allow attackers to directly misinform operators and/or directly/ indirectly influence the industrial process.

In 2015, we wrote:

SCADA and ICS come to the mobile world recently, but bring old approaches and weaknesses. Hopefully, due to the rapidly developing nature of mobile software, all these problems will soon be gone.

We now concede that we were too optimistic and acknowledge that our previous statement was wrong.

Over the past few years, the number of incidents in SCADA systems has increased and the systems become more interesting for attackers every year. Furthermore, widespread implementation of the IoT/IIoT connects more and more mobile devices to ICS networks.

Thus, the industry should start to pay attention to the security posture of its SCADA mobile applications, before it is too late.

For the complete analysis, please download our white paper here.

Acknowledgments

Many thanks to Dmitriy Evdokimov, Gabriel Gonzalez, Pau Oliva, Alfredo Pironti, Ruben Santamarta, and Tao Sauvage for their help during our work on this research.
 
About Us
Alexander Bolshev
Alexander Bolshev is a Security Consultant for IOActive. He holds a Ph.D. in computer security and works as an assistant professor at Saint-Petersburg State Electrotechnical University. His research interests lie in distributed systems, as well as mobile, hardware, and industrial protocol security. He is the author of several white papers on topics of heuristic intrusion detection methods, Server Side Request Forgery attacks, OLAP systems, and ICS security. He is a frequent presenter at security conferences around the world, including Black Hat USA/EU/UK, ZeroNights, t2.fi, CONFIdence, and S4.
 
Ivan Yushkevich
Ivan is the information security auditor at Embedi (http://embedi.com). His main area of interest is source code analysis for applications ranging from simple websites to enterprise software. He has vast experience in banking systems and web application penetration testing.
 
IOActive
IOActive is a comprehensive, high-end information security services firm with a long and established pedigree in delivering elite security services to its customers. Our world-renowned consulting and research teams deliver a portfolio of specialist security services ranging from penetration testing and application code assessment through to semiconductor reverse engineering. Global 500 companies across every industry continue to trust IOActive with their most critical and sensitive security issues. Founded in 1998, IOActive is headquartered in Seattle, USA, with global operations through the Americas, EMEA and Asia Pac regions. Visit for more information. Read the IOActive Labs Research Blog. Follow IOActive on Twitter.
 
Embedi
Embedi expertise is backed up by extensive experience in security of embedded devices, with special emphasis on attack and exploit prevention. Years of research are the genesis of the software solutions created. Embedi developed a wide range of security products for various types of embedded/smart devices used in different fields of life and industry such as: wearables, smart home, retail environments, automotive, smart buildings, ICS, smart cities, and others. Embedi is headquartered in Berkeley, USA. Visit for more information and follow Embedi on Twitter.
EDITORIAL | November 14, 2017

Treat the Cause, not the Symptoms!

With the publication of the National Audit Office report on WannaCry fresh off the press, I think it’s important that we revisit what it actually means. There are worrying statements within the various reports around preventative measures that could have been taken. In particular, where the health service talks about treating the cause, not the symptom, you would expect that ethos to cross functions, from the primary caregivers to the primary security services. 

I read that the NHS Digital team carried out an onsite cyber assessment of 88 out of 236 Trusts. None passed. Not one. Think about this. These trusts are businesses whose core function is the health and well-being of its customers, the patients. If this were a bank, and someone did an onsite assessment and said: “well the bank left all the doors open and didn’t lock the vault”, would you put your hard-earned money in there for safe keeping? I don’t think so. More importantly, if the bank said after a theft of all the money, “well the thieves used masks; we didn’t recognize them; they were very sophisticated”, would you be happy? No. Now imagine what could have been found if someone had carried out an in-depth assessment, thinking like the adversary. 


The report acknowledges the existence of a cyber-attack plan. However, the plan hadn’t been communicated. So, no one knew who was doing what because the plan hadn’t been practiced and perfected. The only communication channel the plan provided for, email, was shut down. This meant that primary caregivers ended up communicating with personal devices using WhatsApp, potentially exposing Patient Medical Records on personal mobile phones through a social messaging tool. 

The report also states the NHS Digital agency had no power to force the Trusts to “take remedial action even if it [NHS Digital] has concerns about the vulnerability of an organization”. At IOActive, we constantly talk to our customers about what to do in the case of a found vulnerability. Simply ticking a box without follow up is a pointless exercise. “My KPI is to perform a security assessment of 50% of the Trusts” – box ticked. That’s like saying “I will perform triage on 50% of my patients, but won’t treat them”. Really?! 

An efficacy assessment of your security practices is not an audit report. It is not a box-ticking exercise. It is a critical function designed specifically to enable you to identify vulnerabilities within your organization’s security posture and empower you to facilitate appropriate controls to manage risk at a business level. Cyber Security and Information Security are not IT issues; they are a business issue. As such, the business should absolutely be focused on having skilled experts providing actionable intelligence, enabling them to make business decisions based on risk, impact and likelihood. It’s not brain surgery, or maybe it is.

It’s generally accepted that, if the bank had taken basic IT security steps, this problem would have been avoided. Treat the cause not the symptom. We are hearing a lot of evidence that this was an orchestrated attack from a nation-state. However, I’m pretty sure, with the basic failures of the NHS Digital to protect the environment, it wouldn’t have taken a nation-state to launch this destructive attack. 

Amyas Morse, Head of NAO said: “It was a relatively unsophisticated attack and could have been prevented by the NHS following basic IT security best practices. There are more sophisticated cyber-threats out there than WannaCry, so the Department and the NHS need to get their act together to ensure the NHS is better protected against future attacks.” I can absolutely guarantee there are more sophisticated attacks out there. 

Eighty-one NHS organizations were impacted. Nineteen-thousand five hundred medical appointments canceled. Six hundred GP surgeries unable to support patients. Five hospitals diverted ambulances elsewhere. Imagine the human factor. You’re waiting for a lifesaving operation – canceled. You’ve been in a car crash – ambulance diverted 40 miles away. All because Windows 7 wasn’t patched. Is that acceptable for an organization trusted with the care and well-being of you and your loved ones? Imagine the damage had this attack been more sophisticated.

Cybersecurity Assessments are not audit activities. They are mission critical assessments for the longevity of your business. The NHS got lucky. There are not many alternatives for health care. It’s not like you can pop down the street and choose the hospital next door. And that means they can’t be complacent about their duty of care. People’s lives are at stake. Treat the cause not the symptoms.