2 december 2024

Interfaces

Ik ben Jelte Derksen, een ethisch hacker werkzaam bij Kiwa NL. Ik ben in het vakgebied van ethisch hacken terechtgekomen nadat ik eerst studies had gevolgd die totaal niet bij mij pasten. Daarom heb ik de overstap gemaakt naar IT als SCADA-beheerder. Toen ik eenmaal de basis onder de knie had, stapte ik over naar IoT-ontwikkeling en Data Engineering voordat ik in de beveiligingswereld terechtkwam. Mijn huidige werkzaamheden bestaan voornamelijk uit het beoordelen van de beveiliging van IoT-apparaten en het uitvoeren van penetratietests. Ons team behandelt verschillende activiteiten, maar mijn specialisatie richt zich voornamelijk op hardware en firmware. Voor mij vertegenwoordigen de beperkingen en het ‘vernuft’ van embedded systemen een unieke schoonheid. Met deze eerste blog wil ik aandacht besteden aan interfaces, specifiek fysieke interfaces. Voordat we echter in detail treden, is het belangrijk om eerst de verschillende soorten interfaces te onderscheiden volgens ETSI EN-303 645: netwerkinterfaces, luchtinterfaces, logische interfaces en fysieke interfaces.

Interfaces onderscheiden

Voor lucht- en fysieke interfaces moeten we denken aan Laag 1 van het OSI-model, ook wel PHY genoemd, wat staat voor “fysiek.” Het belangrijkste verschil is dat de een draadloos is (lucht), terwijl de ander bedraad is (fysiek). (De laatste zou wat minder cafeïne kunnen gebruiken!) Een luchtinterface kan radiogolven of optisch zijn. Communicatie is draadloos en verplaatst zich door de lucht. Persoonlijk vind ik deze term niet helemaal passend, aangezien licht en radiogolven ook door een vacuüm kunnen reizen, waarin geen lucht aanwezig is. Fysieke interfaces vereisen een fysieke verbinding, vaak een metalen geleider die elektronen kan transporteren. Netwerk- en logische interfaces werken op hogere lagen van het OSI-model. Bij netwerkinterfaces denken we meteen aan Wi-Fi en de RJ45 Ethernet-aansluiting. Maar wat te denken van Zigbee en Bluetooth? Beide bevatten netwerkstacks; Bluetooth creëert zelfs een “Piconet” netwerk. Gelukkig is het voor ons niet noodzakelijk om deze interfaces strikt te onderscheiden tijdens testen, ondanks de informatiebehoefte.

Onderwerp van de zaak: Interfaces

De huidige standaarden voor het testen van IoT- en OT-apparaten houden rekening met interfaces. We richten ons op bepaling 5.6-4 van ETSI EN-303 645. Voor beoordelingen gebruiken we de bijbehorende Technical Specification, TS-103 701, die gedetailleerdere richtlijnen biedt voor de toepassing van de standaard. Uit ETSI EN-303 645: “Als een debuginterface fysiek toegankelijk is, moet deze in software worden uitgeschakeld.” Dit betekent dat als er een DEBUG-interface bestaat, zoals UART, JTAG, SWD, enz., deze in software moet worden uitgeschakeld. Als de DEBUG-functie tijdelijk nodig is, moet deze standaard uitgeschakeld zijn. Zo niet, dan moet deze permanent worden uitgeschakeld. TS-103 701 geeft echter extra richtlijnen en beveelt aan om alleen toegankelijkheid van DEBUG-interfaces die gemakkelijk te bereiken zijn.

Toegankelijkheid: Plug and pray?

Uit ETSI TS-103 701: “Gezien het beoogde beveiligingsniveau van ETSI TS 103 645/ETSI EN 303 645 wordt ‘fysiek toegankelijk’ gedefinieerd als zijnde direct bruikbaar met een standaard interfacekabel. Het gebruik van specifieke hulpmiddelen om fysiek toegang te krijgen tot de interface (zoals testsondes) valt buiten de scope van de beoordeling.” Bij Kiwa betekent dit dat een interface fysiek toegankelijk wordt geacht als Dupont-kabels gebruikt kunnen worden voor GPIO-verbindingen, evenals voor vele andere standaard interfacekabels en -hulpmiddelen. Denk bijvoorbeeld aan de JTAG-kabels die vaak gebruikt worden met tools zoals de Segger JLINK.

Battle story: Probing zou binnen de scope moeten vallen

Hoewel ETSI testsondes buiten de scope beschouwt, moet U niet denken dat "verborgen" interfaces op testpads enige beveiliging bieden. Testsondes zijn goedkoop, en als U een collega hebt met vaste handen, werken zelfs stijve draden. We testten eens een apparaat met een prachtig PCB, zonder enige markeringen op het silk screen, met een NRF52832-chip. Met behulp van het gemakkelijk beschikbare datasheet, pinout-diagrammen en het volgen van de PCB-sporen, vonden we twee kleine gouden pads die “interessant” leken. Met de JTAGulator identificeerden we de SWDIO en SWCLK van de chip en kregen we toegang. Security through obscurity is als het koekjesblik voor kinderen verstoppen—met genoeg tijd en toewijding zullen ze het vinden, met alle gevolgen van dien. Mijn geld staat op het toegewijde kind dat dol is op zijn "Lunettes."

Documentatie: Een goedbedoeld kwaad

Een veelvoorkomend probleem met cybersecuritystandaarden is het correct invullen van de documentatie. Ontbrekende informatie of het verkeerd interpreteren van vragen komt vaak voor. Voor de bepalingen in sectie 5.6 over het minimaliseren van aanvalsvlakken is alleen IXIT 15-Intf nodig. De IXIT staat voor de "Implementation eXtra Information for Testing."

De beoordelingsprocedure bestaat uit drie stappen:
1. Zorg ervoor dat alle documentatie compleet is en dat er twee samples klaar zijn.
2. Controleer of de documentatie voldoet aan de norm.
3. Bevestig dat de documentatie overeenkomt met de “echte” situatie.

Hoe beter de kwaliteit van de verstrekte informatie, hoe soepeler het testproces zal verlopen. Het doel van documentatie is om het apparaat onder test (Device Under Testing, DUT) te kunnen beoordelen. Testers moeten het DUT volledig begrijpen. Voor deze bepaling worden interfaces vaak vergeten of over het hoofd gezien.

Enkele "fictieve" excuses die worden gegeven:

  • “Het is geen DEBUG-interface omdat het met een wachtwoord is beveiligd.”
  • “Het is geen DEBUG-interface omdat het alleen gegevens verzendt.”
  • “Het heeft een eigen connector.”
  • “u moet enkele pinnen overbruggen.”
  • “We zijn het vergeten.”

De laatste is mijn favoriet, omdat een kleine vergissing gewoon menselijk is. Bovendien is de meeste DEBUG-informatie die mogelijk wordt uitgespuwd, intrinsiek "beveiligingsrelevant." Het is beter om meer informatie te verstrekken en iets uitvoeriger te zijn dan te riskeren dat we het gevreesde FAIL/INCONCLUSIVE-resultaat in het rapport krijgen.

Toepassing: Wat kan ik halen uit deze lap tekst?
Oké, we hebben de definitie van de interfaces behandeld en de bepaling doorgenomen. Maar wat moet u hieruit halen?

Houd bij het werken met een apparaat de volgende punten uit deze bepaling in gedachten:
1. Heeft het apparaat in productie een DEBUG-interface nodig?
2. Als dat zo is, kunt u het tijdelijk beschikbaar maken en standaard uitschakelen?
3. Als het alleen gegevens uitzendt, zijn het dan beveiligingsgevoelige gegevens?
4. Heeft u de volledige documentatie ingevuld?

Conclusie: De puntjes verbinden

Alle interfaces die DEBUG-functionaliteit bieden, kunnen - en waarschijnlijk zullen - worden misbruikt door degenen die ernaar zoeken, en niet iedereen heeft ethisch correcte bedoelingen. Daarom neemt ETSI EN-303 645 interfaces serieus. DEBUG-interfaces moeten in software worden uitgeschakeld, hetzij permanent of standaard als ze tijdelijk vereist zijn. Het ontwerpen van veilige apparaten is een kunst, en ik hoop dat u deze kunstvorm omarmt.