> • Open Mobile Alliance (OMA) designed a protocol for Device Management (DM), to remote implement UPDATE, MANAGE, CONTROL and BACKUP. Car Vendors can use this protocol to remote control version update and retrieve data. • Automotive Grade Linux (AGL) is sub-org under The Linux Foundation which engage in cross industry requirements for internet of car. Recently, AGL try to defined OMA DM 2.0 to become car communication standard. • Tesla convince that their protocol is too rough and their last line in security protection is Black Box, open source will make their products in risk.
> • OMA DM is a device management protocol for server to control the client device. • OMA DM include following major phases: – Generic device information maintain (DevInfoMO, DmAccMO, DCMO) – Firmware maintain (FUMO) – Software maintain (SCOMO) • OMA DM now has two version release: – OMA DM I (complete) • base on SyncML (Synchronization Markup Language) data format, OMA also give a project as syncml rtk which plays as communication protocol of SyncML – OMA DM II (uncomplete) • base on JSON data format, it simply use HTTP as communicate protocol • only main protocol update to version II, not FUMO, SCOMO, or any else
> • OMA DM 1.3 Communication Flow Syn yncM cML
> • OMA DM 2.0 Communication Flow JS JSON
> • How to Registration? How to identify response with Async Report?
> • First Time Package1 session establish: Match Server’s Factory Device Serial > > > Unregister Auth Bootstrap Number Device • Else: Some else RFC2617 Headers (e.g. Authorization)
> • That means registration key is store on microcontroller DB as un-encrypted state and can be inferred • You can register a fake client just like which we infer door number that mentioned in Section 1 IoT part
> • TLS/SSL is recommended in OMADM 2.0 • RFC2617 Basic Authentication Schema MUST be supported (newest: RFC 7617 (2015)) HTTP HTTPS/SSL HTTP < < Basic and Digest Access HTTPS/TLS PlainText Authentication • RFC 2617 security options are optional . If Server doesn’t set QOP, Client will work as RFC 2069. • Basic Authentication Schema is easy attack by MITM. Attacker can easily set OFF on QOP to let Client use RFC 2069. • Moreover, there’s no mechanism to let Client check Server identification. • RFC 2617 block user to use STRONG hash algorithm to store sensitive data like PSW, they defined as recoverable value.
We all know where recommends are going ¯\_( ツ )_/¯
> • HTTP Publ Public ic
> • OMA DM Modules and Functions – Command Dealer – Parser & Database maintainer – Package Handeler • OMA DM Data structures
> • Table Name?
> • Table Name?
> • Database type storage in OMA DM – Pros • Insert / Update / Parse can easily use database schema mechanism to check DDF invalid – Cons • Need more designing on table name also reach the consensus between Server & Client • XML type storage in OMA DM – Pros • easily fit the document designing – Cons • Insert a new MO tree will be hard to check if is valid DDF
> • Actually Usage of Value?
> • Cross Protocol Version: DataBuffer stream boundary different in SML & HTTP (1 st command result following with 1 st – data /1 st command result code with 2 nd command result code) – Command method not backward compatible (Ver2 not support REPLACE command) • OMA DM NodeName & SQL Syntax conflict: – urn:oma:mo:fumo:1.0/<x>/update • A lot of Extension in OMA DM tree: (there can not be multiple tables in same name) – urn:oma:mo:oma-dm-devinfo:1.2/<x>/Ext – urn:oma:mo:oma-dm-dmacc:1.2/<x>/Push/GCM/Ext – urn:oma:mo:fumo:1.0/<x>/Ext • Result Code inconsistency: – Sometime diff MO module use same result code, sometime not. • Same MO module, different DDF
> • Request Launching in different way – Server use method commands – Client use Generic Alerts (the one they usually used is to respond the results of async commands like EXEC) • Alert Type – urn:oma:at:dm:2.0:BootstrapComplete – urn:oma:at:dm:2.0:ClientInitiatedMgmt – urn:oma:at:dm:2.0:ServerInitiatedMgmt – urn:oma:at:scomo:1.1:UpdateUserRequest – org.openmobilealliance.dm.firmwareupdate:update – org.openmobilealliance.dm.firmwareupdate:downloadandupdate
> • Ellipsis: Usually use on MIID, this regards as only one node/value come up as result. • Real Name: The actually node name. • urn:oma:mo:moid:1.0// – Cannot resolve, there’s two MO instances. • urn:oma:mo:moid:1.0/left/Data/1/Value – identifies one nodes; the moroot1/Data/1/Value
> • x-name: the DM Client MUST resolve only one node that satisfies all corresponding nv fields for this x-name component; if multiple nodes are resolved, an error code MUST be returned • Wildcard: the DM Client MUST address all nodes at the specified location • urn:oma:mo:moid:1.0/(x)/Data/*/Value?nv=(x)/ID:GPS – identifies two nodes; the moroot1/Data/1/Value and moroot1/Data/2/Value node
> • In fact, Client and Server should share same MO trees (even though Server will manage lots of Clients, but server should sync every Client) • This over-freedom parser should only implement on Server backend control panel, or better not exist • Server and Client should send what they exactly needed rather than making parser more complicated • It is strongly suggest that not to allow # ; = > < this kind of SQL symbol as valid characters in every node in URI
> • Too complicate for Developer to implement property – With dynamic-changing table schema in SCOMO – Apply to self-defined table schema with different Vendors’ clients • SQLinjection with PlainText HTTP body (especially URI) • Sometime Vendors’ clients simply send sub -tree in it’s own style . (e.g. strings in integers, arrays in different JSON objects)
& > • There’s no token designed (relative key in OMADM1.0, but not in OMADM2.0) and authenticate mechanism (registration) in this protocol. • MITM still problem here . (RFC2617 doesn’t work to prevent this link attack.) • There’s no checksum confirmed mechanism for FUMO, (firmware update module) client cannot even check if it is runnable or not before it exec the binary. • There’s checksum confirmed mechanism for SCOMO (software update module) , however, download source URL still can be a trap. (Server not even going to auth or check Remote Repository Server status and give a valid token let client to confirm source)
> > & Fake Request Hacking Payload Server Client Un-encrypted DB Response e.g. DevID (API key) Hacker
> > & Fake Request Request Update Benign Server Benign Client Response Fake Command Hacker
> Hacker Hack Benign Server Compromised Switch Request Update Request Update Malicious Payload Malicious Payload DownloadURL DownloadURL Benign Client Malicious Server
> Update Request TargetURL Response Benign Server Auth Sync???? Download Request Benign Client Malware / File Name Command injection e.g. Unsnenitize file name donwload Hack Compromised Hacker Remote Repository e.g. Ruby,Net::FTP command injection
> Request Update Hack Hacker Fake Command Compromised Server Server Control Panel Client e.g. Node.js ft. misconfigure debugger handshake Allow command injection 1. Return shell with malicious update 2. finding ECU ID from Brutal Force OMA DM component db information with GET cmd ECU 3. Sending Canbus modified malicious component application
• • •
> Physical Remote SD Update server GPS WiFi Infotainment 3G/4G Remote Repository USB Bluetooth RDS Android Apps OBD2 MyCar server
> • In IoT, OT, and Vehicle communication, plaintext and default AC/PW still make serious problems • Latest Cross-Industry features (AI manufacture, AI medication, AI car) still not take Information Security as a serious problem, then come out with lots of vulnerabilities application • In past, low revenues device (PC, IoT) can be find out exploit value by black industry. Apparently, vehicle with its high value deserve to own its targeting attack, and it’s worthy • Vehicle security can be a research draft of aircraft , it’s really sensitive to country security • OMA DM 2.0 is a protocol that need to harden. Should take serious concern on security issues on its document
> • Supply chain attack make vendors pay attention on every third-party libraries (& Remote Repository Server) • Make sure to use BL/WL mechanism and Hash check • Cipher and CA always enhance your communication, use them • Physical attack cannot avoid, but take care every addon on your car and make sure to change your AC/PW • Every remote access to CAN bus components (OBDII, MyCar, ECU update) should apply auth confirm & encrypted communication. Vendors’ Web should apply vulnerabilities scanning to fix bugs, avoid brutal force and information leak. • Mini computer is the major component in all attack vectors, Application Whitelist can ease the lost after compromised by hacking
> • http://www.openmobilealliance.org/ • http://illmatics.com/Remote%20Car%20Hacking.pdf • https://ioactive.com/pdfs/IOActive_Adventures_in_Automotive_Networks_and_Control_Units.pdf • https://www.sans.org/reading-room/whitepapers/threats/hacking-bus-basic-manipulation-modern- automobile-through-bus-reverse-engineering-37825 • http://www.aut.upt.ro/~pal-stefan.murvay/papers/dos-attacks-controller-area-networks-fault- injections-from-software-layer.pdf • https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20presentations/DEFCON-27-Jmaxxz- Your-Car-is-My-Car-Code-6e0e599/ • https://www.shs.edu.tw/works/essay/2012/11/2012111421572430.pdf • https://hackaday.com/2019/06/10/takatas-deadly-airbags-an-engineering-omnishambles • https://blog.avast.com/hacker-breaches-gps-service-of-27000-cars • https://www.zdnet.com/article/dhs-warns-about-can-bus-vulnerabilities-in-small-aircraft • https://www.outilsobdfacile.com/vehicle-list-compatible-obd2 • https://github.com/gmacario/easy-build • https://www.st.com/resource/en/user_manual/dm00039084-discovery-kit-with-stm32f407vg-mcu- stmicroelectronics.pdf • https://www.elmelectronics.com/wp-content/uploads/2017/01/ELM327DS.pdf
>
Recommend
More recommend
