Cloud-Device Communication
1.1. Authentication
1.2. Device identification
1.3. Firmware upgrade flow
1.4. Communication channel security
1.5. What kind of data is sent to the cloud
1.6. Communication protocols used
Local Network
2.1. Services with weak credentials (no password, simple password, easily brute-forceable password)
2.2. Misconfigured services
2.3. Unpatched services with known vulnerabilities
2.4. Hidden backdoors/accounts
2.5. Proprietary services
Initial Device Configuration
3.1. Impersonation attack
3.2. Information leak
Companion (smartphone) App – Cloud Communication
4.1. Device access control
4.2. Account management
4.3. Strong/indeterministic device and user identifiers
Companion (smartphone) App
5.1. Privacy (what data is sent to the cloud)
5.2. Hardcoded secrets
Other
6.1. Hardware access/security
6.2. Earlier vulnerabilities, patching speed
6.3. Active maintenance of firmware
How the device is set up:
- impersonation attack
- replay attack
- man in the middle
- information leak (unprotected wireless network)
Communication protocols
Communication between the device and mobile app. Could be one of the following:
- encrypted protocol: can be vulnerable to man in the middle attack if poorly implemented
- plain text: vulnerable to multiple types of attacks.
- proprietary: reverse engineering the mobile app will determine if it is vulnerable or not.
Communication between the device and vendor cloud. In many cases, a cloud platform is required to enable features such as remote access, storage, etc.
- encrypted protocols, such as HTTPS (most secure approach, if the device implements certificate pinning), HTTP with encrypted payload (can be vulnerable to some attacks), MQTT with TLS etc.
- plaintext protocols (HTTP)
- proprietary protocol: reverse engineering will determine if it is vulnerable or not
Communication between the device and mobile app over the internet: P2P, relay through the cloud, or direct connection through port forwarding.
LAN security:
- popular services with weak credentials such as telnet/ssh/ftp (no password; simple password; random password for each device; unique bruteforceable password)
- poorly configured services such as http/https servers (proper authentication/authorization; hidden functionalities; unauthenticated information disclosure; unauthenticated/authenticated exploits)
- unpatched applications with known vulnerabilities.
- applications where the standard is not respected, such as rtsp (no password; simple default password; password chosen by user; exploits)
- hidden backdoors/accounts
- other protocols (information disclosure; exploits)
Cloud security:
- proper authentication/authorization schemes
- proper password reset functionality
- strong/random device and user identifiers
Other:
- privacy related: what information is transmitted to the cloud by device/app; privacy policy
- earlier exploits; patching speed
- ease of upgrading firmware
- force the user to change any default passwords, and password complexity reinforcement.
Reverse engineering the application to obtain:
- secrets disclosure: API keys, server passwords, default credentials, etc.
- required permissions
- certificate pinning
- obfuscation
- detailed logs
Hardware security
- UART debugging