History lessons 3: Confusing the guards and what it means for future hardware chip design

David Rogers continues his blog series — commissioned by on-chip monitoring experts UltraSoC (now part of Siemens) examining security through the ages and highlighting lessons for emerging and future technologies.

The city walls of York
Source: David Rogers

Previously, I talked about how expensive defences can be subverted by a determined and clever adversary. This time I continue the theme of access, but consider the problem of confusion.

In considering the story in the last blog, I was thinking about whether the carpenter’s entry into Conwy Castle should be classed as (what is known in the technology world as a) ‘confused deputy attack’ (it isn’t). This type of attack often happens in web applications in cross-site request forgery (CSRF) attacks in order to confuse the browser, as the agent of the attacker, into getting a website to do something it shouldn’t.

Keeping enemies out

Another example from history can better explain the concept of a confused deputy attack. Firstly, a bit of background. There are many stories in the UK of historic laws and bylaws that stem from medieval times that give an insight into how towns controlled access from people who they would consider to be “enemies”. Some of these are true and others are mere rumour. For example:

  • “Welsh people were allowed to enter the towns by day but kept out at night and forbidden to either trade or carry weapons”
  • “In the city of York, it is legal to murder a Scotsman within the ancient city walls, but only if he is carrying a bow and arrow”
  • “In Carlisle, any Scot found wandering around may be whipped or jailed”
  • “Welshmen are prohibited from entering Chester before the sun rises – and have to leave again before the sun goes down”
  • “It is still technically okay to shoot a Welshman on a Sunday inside the city walls – as long as it’s after midnight and with a crossbow”

As a note – the law commission looked into some of these stories and clarifies that:
“It is illegal to shoot a Welsh or Scottish (or any other) person regardless of the day, location or choice of weaponry. The idea that it may once have been allowed in Chester appears to arise from a reputed City Ordinance of 1403, passed in response to the Glynd?r Rising, and imposing a curfew on Welshmen in the city. However, it is not even clear that this Ordinance ever existed. Sources for the other cities are unclear.”

In York however (a northern English city which was walled to keep the Scots out), we do know that at the Bootham Bar, an entrance to the city, a door knocker was installed in 1501. Scotsmen who wanted to enter the city had to knock first and ask for permission from the Lord Mayor.

Bootham Bar Roman gateway
YORK, YORKSHIRE, UK: JULY 22, 2008: Bootham bar Roman gateway in York city wall .

The confused deputy

We have to assume that the Lord Mayor himself was not there all the time to give permission in person and delegated the authority for checking whether someone could come in to the guards. The guards still had to come to him for sign-off though.

This is where we can explain the concept of the confused deputy more clearly. Imagine that there is a Scottish attacker who wants to get into York to cause some damage. He’s knocked on the Bootham Bar gate door knocker and convinced the guards he’s authorized because he tells them he’s there to do work (he succeeds in confusing them – they become the confused deputy, conferring trust on the Scotsman where there should be none). However, our attacker still has to gain authority – through the Lord Mayor himself.

The guards carry the message to the Lord Mayor that the Scotsman is legitimate and should be allowed to enter. The Lord Mayor assumes trust and authorizes our Scotsman to enter the city to do work.

The attacker didn’t need to convince the Lord Mayor at all, all he had to do was convince the guards and use them to gain the authority he wanted. The Lord Mayor trusted his guards, but wouldn’t trust the attacker – however he’ll never see him. This is how some website and technology attacks work, by escalating the privilege level of access via an unwitting, trusted agent. To avoid this, additional measures need to be in place for the Lord Mayor to independently validate that the Scotsman is not actually an attacker, before providing further authority to him.

One concern about chip-level attacks is that the vast majority of the communications inside the chip are not integrity checked or validated in any way. An attacker can abuse existing authorities to gain trust in other parts of the system. Changing this is going to be a long-term task for the industry as attacks become more sophisticated. In the meantime, we need to put in measures to be on guard and look for unusual activity going on, rather than automatically assuming everything within the ‘city’ is trusted; perhaps the technological equivalent of using a bow and arrow after sundown.

Sources:


For more on how historical security measures and failures can help instruct the future of security design for hardware in connected devices, check out the webinar (co-hosted by UltraSoC CSO Aileen Ryan and Copper Horse founder and CEO David Rogers) accompanying this series of blog posts.

Previous blog post in the series << 2/5 Who has access?

About the author

David Rogers is Founder and CEO at Copper Horse.

History lessons 2: Who has access?

David Rogers continues his blog series — commissioned by on-chip monitoring experts UltraSoC (now part of Siemens) — examining security through the ages and highlighting lessons for emerging and future technologies.

Conway Castle, North Wales.
Image (edited) source: Adrian J Evans
CC-BY-SA-4.0

Conwy Castle is an imposing castle. Built towards the end of the 13th of century in North Wales, as part of Edward I’s Iron Ring around the country, its curtain walls are interspersed with eight round towers, complete with arrow slits and ramparts. Its two barbicans guarded entrances to the castle. It still stands today, within the further walls of the town of Conwy itself with a further 21 towers. What is amazing is that it was built within only five years. It was designed by the best castle designer of the day, Master James of St George, and was state-of-the-art when it came to defensive security. It withstood one siege – when the Welsh besieged King Edward in the castle in 1295. It was on Good Friday in 1401 however, that the most interesting events happened at the castle during Owain Glyndwr’s uprising against the English.

Nearly all of the garrison of the castle were at church in the town attending Mass. There were two guards left behind on the gate. A carpenter from the castle approached the guards saying that he needed to perform some work with two of his assistants. They were admitted and then immediately stabbed both guards. They then quickly let in the rest of their men, locking the gates behind them. When the garrison arrived back from church they were unable to gain access to the castle.

Unfortunately, the cleverness of this takeover was undermined by the fact that there were few stores in the castle and the Welsh were not prepared for it. It also upset the King of England, Henry IV, who immediately besieged the castle. Within three months, with no edible stores, the Welsh were starved out.

Why is this story particularly interesting in a technology context? This kind of strategy has many parallels with the way in which hackers often use guile and skill to attack seemingly impenetrable defences. The attack was planned to happen when the castle would be least defended and a way of gaining access via an authorized method had been found. The guards authenticated that the carpenter was real and he was clearly authorized to be there. The defenders were not correctly using their layers of defence within the castle and showed complacency and over-familiarity.

The story also gives a lesson for attackers looking to compromise and remain in a system. When defences have been subverted, one thing that more advanced attackers do in the technology world is what’s called ‘living off the land’. In this case the attackers were not able to sustain their takeover of the castle because they lacked those resources to hold out for a long time. Indeed, they’d misperceived the real situation. In the technology world, it is good practice to minimize in advance the things that an attacker can use once they’re “in the castle” or onto a system, such as software libraries not used for the core operation of a system. In the case of the story above, it was bad luck for the attackers that the garrison had so few usable supplies and food.

Containing access

We know that Conwy has two barbicans. The purpose of a barbican is to provide additional defence in front of an access point or gate. It functions as a mechanism for control over hostile entrants. Barbicans are typically narrow and often contain traps such as murder holes to throw things down on the enemy, as well as adjacent spaces on the same level and a floor above from which defenders can attack the enemy from the side or from height, whilst safely behind their own defences. The defenders have the advantage because low resources are needed to defend whilst the attacker is narrowly channelled into a place of the defender’s choosing.

Layout of Conwy castle showing the East and West Barbicans
Source: CADW

In technology terms, we see very little of this kind of defensive mechanism. Where there are inputs to a system, typically via an Application Programming Interface (API), inputs are often blindly accepted, in some cases from anyone who accesses the interface. Good practice dictates that input is validated – ie that a number is indeed a number and within the expected range. However, there is clearly an opportunity to go further than that. Where an interface or system is under attack there is an opportunity to defend against that. Examples of attacks go from fuzzing (throwing structured and unstructured data at an interface in the hope of breaching it in some way), repeated brute-force attempts at getting in, or denial of service (DoS) attacks hoping to overload and consume system resources. Abstractly, a system, once it identifies such kinds of attack, could provide some kind of pre-interface – ie a barbican before the data hits a real interface. This gives the opportunity to do something about an attack as it happens – for example, it could choose to drop the data that is sent during a DoS attack rather than consume system resources responding to it. More sophisticated versions could waste an attacker’s time and resources through other clever means. This is a form of ‘active defence’, without actually ever touching an attacker’s system. It is all performed locally on the system that is under attack.

However, all of this depends on whether the system is always on guard. History shows that in the Conwy castle case, the garrison were complacent – even though the Welsh had started to rebel the year before. The ‘trusted’ carpenter should have been let in on his own without anyone else and there should have been additional guards within the main castle such that the attackers were confined to the barbican itself, to be dealt with.

The castles of yore often included  other mechanisms for access control including the use of a portcullis (or sometimes several of them) which could be dropped very quickly if needed to block access or to trap attackers at entry points. Similarly, entrances were often guarded by drawbridges which could be closed, or turning bridges which could easily be destroyed by defenders. Castle buildings often had entrances on the 1st floor and above – well above head-height. This meant that wooden stairs could be destroyed and burnt in a hurry if necessary, causing an attacker further trouble if the castle was under attack. All of these were primarily designed for defending against sieges. As we’ve seen in this blog however, sometimes costly defences can be undermined by guile, intelligence, defender complacency and choosing the right timing.


For more on how historical security measures and failures can help instruct the future of security design for hardware in connected devices, check out the webinar (co-hosted by UltraSoC CSO Aileen Ryan and Copper Horse founder and CEO David Rogers) accompanying this series of blog posts.

Previous blog post in the series << 1/5 Doing nothing in a hostile environment is never going to work out well

Next blog post in the series >> 3/5 Confusing the guards and what it means for future hardware chip design

About the author

David Rogers is Founder and CEO at Copper Horse.

Automotive threat modelling: off-the-shelf solutions

Copper Horse’s automotive cybersecurity posts, including Automotive threat modelling: off-the-shelf solutions, can now be found on the Secure-CAV microsite.

Secure-CAV is an ambitious collaborative project that aims to improve the safety and security of tomorrow’s connected and autonomous vehicles through a combination of cybersecurity monitoring, hardware solutions, machine learning and functional demonstrators.

About the author

James Tyrrell is a Threat Modelling Analyst at Copper Horse.

Copper Horse and Arm launch white paper on IoT security by design

“If you’re looking to deploy IoT, you need to do it right from the start and you need to think about what happens with that product throughout its lifetime, until you sunset it,” David Rogers MBE – founder of Copper Horse and author of the UK’s Code of Practice for Consumer IoT Security – told listeners at yesterday’s launch webinar (available to watch on-demand). “That means working with suppliers and partners who you can trust will take the right approach to security and platforms.”

Arm commissioned Copper Horse to offer an impartial guide to IoT security by design, and the 19 page white paper guides readers on how to appropriately and securely manage solutions at scale.

“If you’re deploying IoT in any kind of environment – for example, consumer, automotive, agricultural, industrial or medical, you need to consider security from the beginning,” David reiterates. “Regulation is coming so it can’t be ignored.”

Topics covered in the briefing include: the threat landscape; future regulation; software updates and device management; public key infrastructure (PKI); end-of-life and decommissioning; and a reminder on identifying and eliminating bad practices.

Full details can be found at – https://learn.arm.com/securingiotbydesign.html.

Copper Horse CEO David Rogers Receives MBE from the Queen at Windsor Castle

Mr. David Rogers is made an MBE (Member of the Order of the British Empire) by Queen Elizabeth II at Windsor Castle. This picture is not for use after 25 December 2019, without Buckingham Palace approval. PA Photo. Picture date: Friday October 25, 2019. See PA story ROYAL Investitures. Photo credit should read: Jonathan Brady/PA Wire

David Rogers, Copper Horse’s CEO was made a Member of the Order of the British Empire (MBE) for services to Cyber Security by Her Majesty the Queen on Friday the 25th of October 2019. The investiture took place at Windsor Castle.

After the ceremony, David said “It was a delight and honour to meet Her Majesty the Queen. I have accepted this award on behalf of everyone involved with securing connected products in the ‘Internet of Things’ and working to protecting people from online harms. This includes the security research and hacking community, government departments and academia. There is some truly great work going on and there are some fantastic, passionate individuals working on this all across the world.”

More details on David’s work can be found here. Copper Horse provides IoT security consultancy and engineering expertise worldwide from its home in Windsor, UK.

ETSI publishes European Standard on Consumer IoT Security


David Rogers writes about the launch of the specification: ‘Cyber Security for Consumer Internet of Things’ from ETSI’s TC Cyber group.

Today the European Telecommunications Standards Institute (ETSI) announced the publication of their ETSI Technical Specification, TS 103 645 (pdf).

This work builds on the UK Code of Practice for IoT Security and has had input from experts around the world. It is great that this work has been elevated up to European level and published as a standard. This means a much wider technical audience and crucially, official endorsement at European level by companies and governments.

The discussions during the specification development were very rational and it also meant that some of the supporting text were promoted into provisions within the specification, making the overall work stronger. For example, wording that could be considered ambiguous from a technical standpoint has been clarified and considered at length by me and others. This means that whilst we still see this as a high level specification, we’ve also tried to further pin down what we’re trying to say, all whilst trying to ensure that we avoid unintended consequences and companies deliberately trying to avoid putting security into their products via loopholes.

These efforts will continue. During the specification process, there were some really good proposals brought forward on some deep technical aspects about IoT security and privacy that we see as being potential spin-off work items in ETSI – I’m keeping track of what those topics were. There are also things that some of us would like to bring into the Code of Practice for future revisions, such as consideration by manufacturers of issues such as coercive or controlling behaviour which can be compounded by IoT in the home. All these things are for the future, but the great thing is the enthusiasm is there from some brilliant minds both in government and industry, so watch this space!

The IoT Security Mapping site has also been updated to reflect how the ETSI specification maps to the UK Code of Practice in order to help implementers understand how it all fits together, including against other recommendations and specifications from around the world.

What are your devices saying about you?

 

In our recent blog, Ryan Ng wrote about new Smart Home connected devices being developed and sold in 2018. There are many new and innovative ways to improve our lives using technology appearing in stores and on crowd funding platforms such as Kickstarter every day. The majority of these devices interact with mobile apps, whether they are sending notifications or allow the user to control functionality, these devices often require a hub to connect the devices to the wider internet. Smart speakers and thermostats are now being used as hubs to connect other smart home appliances. Many of these devices, such as a PIR or door open/close sensors, are running on coin cell batteries which are expected to last multiple years and for this they need to use a low powered radio network to communicate with their hub. The Bluetooth and Zigbee radio protocols are widely used in this area with well-defined standards and optimisation of power usage  to maximise battery life.

 

We thought it would be interesting to buy some tools and see what data we could capture.

 

Bluetooth and Bluetooth Low Energy (which is a subset of Bluetooth 4.0) are maintained by the Bluetooth Special Interest Group and runs on 2.4 GHz. Bluetooth Low Energy was designed to provide much reduced comms and power drain whilst offering a similar range of communication.

 

We purchased an Ubertooth One from Greatscottgadgets.

 

 

 

 

The Ubertooth One is “an open source 2.4 GHz wireless development platform suitable for Bluetooth experimentation”. The device allows us to promiscuously sniff packets of Bluetooth data using a tool such as Wireshark, but something we found much more interesting is the open source project BlueHydra available on GitHub. BlueHydra is a Bluetooth discovery service built on top of BlueZ, the official Linux Bluetooth stack. Using these tools allows us to track Bluetooth devices as they pass by with BlueHydra showing us how often the devices are in our vicinity, how close and in many cases who the manufacturer of the device is. Devices can be detected even when Bluetooth is not in discoverable mode!

 

 

 

 

Functionality can be further extended with simple python scripts such as ble_finder.py written by Troy Brown and Garrett Gee which allows you to create a list Bluetooth devices to be monitored and will alert you when a device is detected in close proximity to the Ubertooth One.

 

We also purchased a Zigbee packet analyser a few years ago for a project before Zigbee became so popular in Smart Home systems. Based on IEEE 802.15.4, Zigbee is a low powered radio standard developed and maintained by the Zigbee Alliance with most devices running at 2.4 GHz, with some other regional frequencies available (784 MHz in China, 868 MHz in Europe and 915 MHz in the USA and Australia).

 

 

 

 

The device was manufactured by Freescale although they merged with NXP  in 2015. The analyser we’re using is a NXP USB-KW24D512 using this device, the Kinetis Protocol Analyser Adapter software provided by NXP and Wireshark, we’ve captured data packets being communicated between Amazon Echo Plus and Phillips Hue smart light bulbs and also Samsung Smart Things communicating with sensors. Although this data is encrypted, it does allow us to scan for Zigbee based Smart Home devices around us and as all devices are allocated their own Device Network ID, so we can see how many devices someone has in their home.

 

 

 

In Zigbee, the protocol is designed to not leak information beyond the initial pairing process. This prevents arbitrary traffic analysis. In Bluetooth, however, when a device communicates with another device e.g. a fitbit with a phone, the traffic can be observed, which gives at the very least metadata about user habits such as what time they get up in a morning. This is not good for user privacy.

Copper Horse CEO Appointed Visiting Professor

View from York St John University
View from York St John University

David Rogers, the Copper Horse CEO has been appointed a Visiting Professor in Cyber Security and Digital Forensics at York St John University. The full text of the university’s press release is below. David intends to work with the university on security aspects of the Internet of Things as well as to encourage social inclusion within technology and cyber security:

York St John University appoints security expert as Visiting Professor in Cyber Security and Digital Forensics

The Computer Science department is delighted to announce the appointment of David Rogers, CEO of Copper Horse Ltd, as visiting Professor in Cyber Security and Digital Forensics.

Professor Rogers is a world-leading mobile security expert and is an adviser to the Department of Culture, Media & Sport on issues of Cyber Security. David chairs the Device Security Group at the GSM Association and sits on the Executive Board of the Internet of Things Security Foundation. He also teaches Mobile Systems Security at the University of Oxford.

Justin McKeown, Head of Computer Science, said: “David has worked in the mobile industry in both security and engineering roles for more than 17 years. It’s fantastic to have someone of his professional calibre working with our students.

“Much of our research activity within the department focuses on the Internet of Things. David’s knowledge in this field is highly valuable and his input will bolster and enhance our activities in this area.”

Professor Rogers said: “I am honoured to be given the title of Visiting Professor at York St John. In the technology world we face many challenges in the future – these can only be addressed by trained individuals who will fill the national skills gap in cyber security and perform cutting edge research for the Internet of Things.

“York St John University is uniquely placed to take a leading role with their students because they put ethics and social inclusion at the heart of their work. I am proud to play a small part and to give something back to my native county, North Yorkshire.”

Computer Science is one of a series of new science subjects introduced at York St John University within the past four years. Since its introduction it has gone from strength to strength. In September this year new BSc programmes in Software Engineering and Games Development will be introduced.

Exhibiting at Mobile World Congress 2016 – Stand 7C70e

20150228_134027

We are excited to announce that Copper Horse will be exhibiting at Mobile World Congress 2016 at the Grand FIRA in Barcelona 22-25 February 2016. Come and visit us in Hall 7 at Stand 7C70e. We will have some fun challenges on our stand including the chance to try your hand at lock picking. We will also be demonstrating the intelligent door, part of the Motion Project, allowing the monitoring of very distinct data points while allowing you full control of your privacy. Here at Copper Horse, we firmly believe that you are not the product.

 

You’ll find us at a number of events on-site including running the UKTI Cyber Security in the Mobile World sessions at lunchtimes on Monday 22nd (Connected Car Security)Tuesday 23rd (Future Network Security) and Wednesday 24th (Cyber Security in IoT) on stand 7C40 as well as speaking in the main conference on Thursday 25th. Monday the 22nd evening sees the “Dark and Stormy – The Cyber Happy Hour” from 17:15 onwards which will include drinks, food and some amazing Pecha Kucha talks. Our CEO, David Rogers will be MC’ing the event. We encourage you to come along to the cyber sessions as they’re all good learning opportunities as well as good for networking with other security professionals and experts. For all the UKTI events, just turn up to the UKTI stand 7C40 and try to get there early as the seats fill up fast.

 

We will also be hosting our invitation only, annual security dinner on the Sunday at a secret location in Barcelona.

 

Copper Horse is a UK based mobile systems security consultancy and solutions provider. The company provides world-leading security expertise on mobile and connected devices. The organisation is currently focused on advising clients on Internet of Things security threats, strategies and solutions as well as developing a security-focused IoT product through the company’s “Motion Project”. The company will focus on a consumer-focused IoT security strategy in 2016 with the theme of “You are not the product”.

 

If you’re interested in working with us, here are some of the services we provide:

 

• Security threat and risk analysis, strategies and solutions
• Internet of Things solutions development (security, software, hardware)
• Mobile handset security expertise (throughout the stack from hardware to browser)
• Incident handling and responsible disclosure expertise
• Smart Home security consultancy
• Connected Car security consultancy
• Small cells security
• Bespoke security and anti-fraud solutions development (including software and hardware)
• Standards consultancy
• Specialist investigations and product/market threat and risk analysis
• Technology horizon scanning

 

We look forward to meeting you in Barcelona!

 

 

Note: This blog was edited to add more details and events on the 10/02/16.