Mobile Comm and IoT Flashcards
Android rooting tools
TunesGo, KingoRoot, OneClickRoot, MTK Droid, SuperOneClick
Untethered Jailbreaking
Kernal will remain patched (jailbroken) after reboot with or without system connection
Semi-tethered Jailbreaking
Reboot does not retain jailbreak but the but the software has been added to the device and can still be used when needed
Tethered Jailbreaking
reboot removes jailbreak and the phone may get stuck in a loop on start up requiring a system connection to repair
Userland exploit
OS level jailbreak does not provide Admin level access untethered. They will be patched
iboot exploit
can be semi-tethered will be patched provides admin.
Boot Rom Jailbreak
Allows access to filesystem. can be untethered not patchable. hardware not software
Android Trojans
Obad, FakeDefender, TRAMP.A, ZitMo
BlueSmacking
Bluetooth DOS attack against the device
Bluejacking
Sending unsolisited messages to and from mobile devices
Bluebugging
Accessing a bluetooth enabled device and using its features. Bloover is software for this
Bluesnarfing
theft of data from a device due to an open connection (staying in discover mode)
Blueprinting
footprinting for bluetooth: Collecting device information over bluetooth
IoT OWASP top 10
I1 Insecure Web Interface I2 Insufficient Authentication/Authorization I3 Insecure Network Services I4 Lack of Transport Encryption I5 Privacy Concerns I6 Insecure Cloud Interface I7 Insecure Mobile Interface I8 Insufficient Security Configurability I9 Insecure Software/Firmware I10 Poor Physical Security
Hvac Attack
Attack to shut down an air conditioner
Sybil Attack
DOS in IoT network Mutiple forged identities make it seem as if network is congested
Rolling Code
Sniffs out the code used by your key fob
IoT Vulnerability Scanners
RIoT, beSTORM, IoTSploit, IoT Inspector
3 phases of IoT Hacking
- Information Gathering
- Vulnerability Scanning
- Launching Attacks
BBProxy
Used for Blackjacking a blackberry
This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system.
M1: Improper Platform Usage
occurs when development teams assume that users or malware will not have access to a mobile device’s filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores. Usage of poor encryption libraries is to be avoided. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data.lost phone or malware
Rooted/ jailbroken phone
M2: Insecure Data Storage/ storage vulnerabilities
Mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication but not elsewhere. This inconsistency leads to the risk of exposing data and session IDs to interception. The use of transport security does not mean the app has implemented it correctly. To detect basic flaws, observe the phone’s network traffic. More subtle flaws require inspecting the design of the application and the applications configuration.
When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device’s carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it’s traveling across the wire. The following threat agents exist:
An adversary that shares your local network (compromised or monitored Wi-Fi); Carrier or network devices (routers, cell towers, proxy’s, etc); or Malware on your mobile device.
M3: Insecure Communication
Poor or missing authentication schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app. Weaker authentication for mobile apps is fairly prevalent due to a mobile device’s input form factor. The form factor highly encourages short passwords that are often purely based on 4-digit PINs. Authentication requirements for mobile apps can be quite different from traditional web authentication schemes due to availability requirements.
M4: Insecure Authentication
In order to exploit this weakness, an adversary must successfully return encrypted code or sensitive data to its original unencrypted form due to weak encryption algorithms or flaws within the encryption process
M5: Insufficient Cryptography
related to insecure authentication, as they both deal with user identities and credentials. However, this checks for the authenticated user’s permissions. Authorization usually follows directly after authentication. A mobile app with insecure authorization means that malicious users can gain a level of access that allows them to execute commands that they shouldn’t have permission to. IDOR, Navigating to vulnerable or hidden endpoints that were not intended to be accessible but allow hackers to execute privileged commands
M6: Insecure Authorization