|
17 | 17 | { |
18 | 18 | "key": "open_source_intelligence", |
19 | 19 | "title": "Open Source Intelligence", |
| 20 | + "caption": "", |
20 | 21 | "description": "Gathering information using search engines to find publicly available information about the device", |
21 | 22 | "tools": "Google Dorking components/device, FCC Database (fccid.io or fcc.io), Patents (patents.google.com, worldwide.espacenet.com/patent, appft.uspto.gov), Chinese OSINT (baidu.com, qichacha.com, right.com.cn, codechina.csdn.net, pudn.com, search.gitee.com), Finding datasheets for components", |
22 | 23 | "vrt_category": "sensitive_data_exposure" |
23 | 24 | }, |
24 | 25 | { |
25 | 26 | "key": "network_scanning", |
26 | 27 | "title": "Network Scanning", |
| 28 | + "caption": "", |
27 | 29 | "description": "Scan the network for devices to find the one being tested, identify wireless protocols in use", |
28 | 30 | "tools": "NMAP, Wireshark, tcpdump" |
29 | 31 | }, |
30 | 32 | { |
31 | 33 | "key": "rf_scanning", |
32 | 34 | "title": "Radio Frequency Scanning", |
| 35 | + "caption": "", |
33 | 36 | "description": "Identify any radio communications, frequencies, modulation the device might be using, identify wireless protocols in use", |
34 | 37 | "tools": "HackRF, LimeSDR, BladeRF, Universal Radio Hacker (URH), other various rf sniffers", |
35 | 38 | "type": "checklist", |
36 | 39 | "items": [ |
37 | 40 | { |
38 | 41 | "key": "bluetooth_ble", |
39 | 42 | "title": "Bluetooth and BLE", |
| 43 | + "caption": "", |
40 | 44 | "description": "Try to sniff the communication, check if it's encrypted, can it be decrypted, are replay attacks possible, check if sensitive information being transmitted in plaintext", |
41 | 45 | "tools": "Flipper, Ubertooth, Nordic nRF, Wireshark (might need to install an additional plugin and/or connect external hardware), btmon (linux), Bluetooth Virtual Sniffer (Windows)" |
42 | 46 | }, |
43 | 47 | { |
44 | 48 | "key": "zigbee_lora", |
45 | 49 | "title": "ZigBee and LoRa", |
| 50 | + "caption": "", |
46 | 51 | "description": "For ZigBee and LoRa devices, try to sniff the communication, capture the encryption key exchange (during active recon see if it's hardcoded on the device), check if the communication can be decrypted, and determine if replay attacks are possible. For LoRa, also check for LoRaWAN-specific vulnerabilities, such as weak join procedures, unencrypted payloads, and improper key management.", |
47 | 52 | "tools": "Nordic nRF, Wireshark (might need to install an additional plugin and/or connect external hardware), ZT-CHK, TI SmartRF Protocol Packet Sniffer (SPPS) software, Semtech LoRaWAN sniffer, TTN Packet Forwarder, SDR tools supporting LoRa (HackRF, LimeSDR, BladeRF), Universal Radio Hacker (URH)" |
48 | 53 | }, |
49 | 54 | { |
50 | 55 | "key": "near_field_communication", |
51 | 56 | "title": "NFC Testing", |
| 57 | + "caption": "", |
52 | 58 | "description": "For card readers like access control locks and credit cards, can also be used in mobile testing. Try to read the information on the card, is it encrypted, can it be decrypted, can you forge a request, does the reader allow you to write to it so it will accept forged messages", |
53 | 59 | "tools": "flipper (base model is limited, additional hardware can be installed), Proxmark" |
54 | 60 | } |
|
65 | 71 | { |
66 | 72 | "key": "opening_device", |
67 | 73 | "title": "Opening up the Device Under Test", |
| 74 | + "caption": "", |
68 | 75 | "description": "Open up the device to identify the various components and find data sheets online for the various components, map out PCB, find open ports (UART, JTAG)", |
69 | 76 | "tools": "screwdrivers, anti-tamper bits, prying tools, soldering iron, desoldering workstation, Multimeter, XRAY, probes, oscilloscope, magnifying glass, logic analyzer", |
70 | 77 | "type": "checklist", |
|
73 | 80 | { |
74 | 81 | "key": "visual_component_identification", |
75 | 82 | "title": "Visual Component Identification", |
| 83 | + "caption": "", |
76 | 84 | "description": "Using a magnifying glass identify the various components on the PCB in the device, determine what they do and how they connect together, look up datasheets for important components online and read through them", |
77 | 85 | "tools": "magnifying glass, Search Engines" |
78 | 86 | }, |
79 | 87 | { |
80 | 88 | "key": "measure_voltage_resistance_continuity", |
81 | 89 | "title": "Measuring Voltage, Resistance, and Continuity", |
| 90 | + "caption": "", |
82 | 91 | "description": "Using a multimeter identify GND, Vcc, N/C, Pull-Up resistors to help map out the board, verify the different pins identified in the datasheets, and enumerate debug ports", |
83 | 92 | "tools": "multimeter" |
84 | 93 | }, |
85 | 94 | { |
86 | 95 | "key": "id_debug_ports", |
87 | 96 | "title": "ID Debug Ports", |
| 97 | + "caption": "", |
88 | 98 | "description": "Determine which debug protocols are being used, UART, JTAG, SPI, I2C, SWD, and/or NAND/MMC and find out which pins can be used to access those ports. In some cases you may need to desolder the ports and solder header pins to them to access them", |
89 | 99 | "tools": "multimeter, logic analyzer, oscilloscope, soldering iron" |
90 | 100 | } |
|
102 | 112 | { |
103 | 113 | "key": "dump_download_firmware", |
104 | 114 | "title": "Dump or Download Firmware for Analysis", |
| 115 | + "caption": "", |
105 | 116 | "description": "Using the identified debug ports try to dump the firmware from the device for reverse engineering. Desoldering the SPI flash and using a tool to dump the firmware from it directly. Try downloading the firmware from the vendor site, however it might be encrypted.", |
106 | 117 | "tools": "desoldering station, jtagulator, minicom, PuTTy, Bus Pirate, Raspberry Pi Pico" |
107 | 118 | }, |
108 | 119 | { |
109 | 120 | "key":"firmware_analysis", |
110 | 121 | "title":"Firmware Analysis", |
| 122 | + "caption": "", |
111 | 123 | "description":"Reverse engineering the dumped firmware. Identify encryption if used and try to decrypt it. Use emulation software to help analyze it. Analyze and search the firmware for hardcoded passwords/keys and other sensitive information.", |
112 | 124 | "tools":"binwalk, QEMU, Ghidra, grep, strings, hexdump, readelf" |
113 | 125 | } |
|
122 | 134 | { |
123 | 135 | "key":"replay_attacks", |
124 | 136 | "title":"Replay Attacks", |
| 137 | + "caption": "", |
125 | 138 | "description":"Using the sniffed traffic, determine if replay attacks are possible. Check if the device accepts modified requests and if you can make changes to the configuration. Verify if the device uses unencrypted communication.", |
126 | 139 | "tools":"Wireshark, hackRF, python" |
127 | 140 | }, |
128 | 141 | { |
129 | 142 | "key":"shared_resources", |
130 | 143 | "title":"Improper Isolation of Shared Resources", |
| 144 | + "caption": "", |
131 | 145 | "description":"A SOC may use pin multiplexing allowing an untrusted agent to access assets/info intended to trusted agents only", |
132 | 146 | "CWE":"CWE-1189" |
133 | 147 | }, |
134 | 148 | { |
135 | 149 | "key":"bac_on_chip_debugger", |
136 | 150 | "title":"Broken Access Control for On-Chip Debugger", |
| 151 | + "caption": "", |
137 | 152 | "description":"Unauthenticated access to the on chip debugger through the JTAG, allowing root access or access to sensitive information. Or not implementing proper access control during different boot stages.", |
138 | 153 | "CWE": ["CWE-1191", "CWE-1244"], |
139 | 154 | "tools":"jtagulator, SOIC-8 clip" |
140 | 155 | }, |
141 | 156 | { |
142 | 157 | "key":"improper_lock_bit_protection", |
143 | 158 | "title":"Improper Lock Bit Protection", |
| 159 | + "caption": "", |
144 | 160 | "description":"Assess the integrated circuit trusted lock bit to see if it's missing or can be modified by software later giving access to protected registers, address regions, systems and features that should be protected.", |
145 | 161 | "CWE": ["CWE-1231", "CWE-1233"] |
146 | 162 | }, |
147 | 163 | { |
148 | 164 | "key":"cryptographic_implementation", |
149 | 165 | "title":"Cryptographic Implementation", |
| 166 | + "caption": "", |
150 | 167 | "description":"Assess if the cryptographic algorithm in use is non-standard or a disallowed/non-compliant version.", |
151 | 168 | "CWE":"CWE-1240" |
152 | 169 | }, |
153 | 170 | { |
154 | 171 | "key": "fault_injection_and_side_channel_attacks", |
155 | 172 | "title": "Fault Injection and Side Channel Attacks", |
| 173 | + "caption": "", |
156 | 174 | "description": "Test for fault injection and side channel attacks that can bypass security measures to dump firmware, access sensitive information, perform code execution, skip authentication, or escalate privileges.", |
157 | 175 | "CWE": ["CWE-1256", "CWE-1300"], |
158 | 176 | "tools": "chipwhisperer, oscilloscope, pcb workstation with nano probes" |
159 | 177 | }, |
160 | 178 | { |
161 | 179 | "key":"memory_overlap", |
162 | 180 | "title":"Improper Handling of Memory Overlap", |
| 181 | + "caption": "", |
163 | 182 | "description":"Assess if isolated memory regions and access control policies allow software with low privileges to make changes to overlapping memory also used by software running with higher privileges.", |
164 | 183 | "CWE":"CWE-1260" |
165 | 184 | }, |
166 | 185 | { |
167 | 186 | "key":"clearing_memory_during_state_transition", |
168 | 187 | "title":"Sensitive Information Uncleared Before State Transition", |
| 188 | + "caption": "", |
169 | 189 | "description":"Assess if sensitive information only needed for one state is cleared after transitioning to the next state, such as during boot or waking up from sleep mode.", |
170 | 190 | "CWE":"CWE-1272" |
171 | 191 | }, |
172 | 192 | { |
173 | 193 | "key":"volatile_memory_boot_code", |
174 | 194 | "title":"Improper Access Control for Volatile Memory for Boot Code", |
| 195 | + "caption": "", |
175 | 196 | "description":"Assess if the secure boot process can be bypassed to execute untrusted malicious boot code", |
176 | 197 | "CWE":"CWE-1274" |
177 | 198 | }, |
178 | 199 | { |
179 | 200 | "key":"firmware_not_updating", |
180 | 201 | "title":"Firmware Not Getting Updates", |
| 202 | + "caption": "", |
181 | 203 | "description":"Verify if the firmware can receive regular updates as vulnerabilities are discovered in the future.", |
182 | 204 | "CWE":"CWE-1277" |
183 | 205 | }, |
184 | 206 | { |
185 | 207 | "key":"root_shell", |
186 | 208 | "title":"Root Shell Access", |
| 209 | + "caption": "", |
187 | 210 | "description":"Try to gain root shell access on the device using an enabled communication protocol, i.e. telnet or ssh, or using an open debug port to interrupt the boot process.", |
188 | 211 | "tools":"SOIC-8 clip, Burp, Caido, GNU Screen" |
189 | 212 | } |
|
196 | 219 | "type": "large_upload" |
197 | 220 | }, |
198 | 221 | { |
199 | | - "key": "executive_summary", |
| 222 | + "key": "executive_summary", |
200 | 223 | "title": "Executive summary", |
201 | 224 | "description": "The executive summary should be written with a high-level view of both risk and business impact. It should be concise and clear, therefore it is important to use plain English. This ensures that non-technical readers can gain insight into security concerns outlined in your report.", |
202 | 225 | "type": "executive_summary" |
|
0 commit comments