-
Notifications
You must be signed in to change notification settings - Fork 2
/
security_analysis.html
executable file
·613 lines (593 loc) · 47.2 KB
/
security_analysis.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml"
xmlns:fb="http://ogp.me/ns/fb#">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>Security Analysis | Watch Dogs | Security Analysis of Android Applications</title>
<meta name="description" content="Team Watch Dogs | Security Analysis of Android Applications">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="author" content="Team Watch Dogs | CS416[2020]">
<link rel="image_src" href="https://i.redd.it/p8vw8ggae1751.jpg">
<link rel="shortcut icon" type="image/x-icon" href="assets/img/favicon.png">
<link rel="stylesheet" href="assets/css/bootstrap.min.css">
<link rel="stylesheet" href="assets/font-awesome/css/font-awesome.min.css">
<link rel="stylesheet" href="assets/css/highlight.min.css">
<link rel="stylesheet" href="assets/css/style.css?v5">
</head>
<body class="body-bg" style="position: relative;" data-spy="scroll" data-target="#side_menu" data-offset=92>
<div class="preloader">
<pre class="canvas"></pre>
<div class="loading">
<span>L</span><span>O</span><span>A</span><span>D</span><span>I</span><span>N</span><span>G</span><span> </span>
</div>
</div>
<nav class="navbar navbar-expand-sm bg-dark navbar-dark sticky-top">
<a class="navbar-brand" href="./">Team Watch Dogs</a>
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#collapsibleNavbar">
<span class="navbar-toggler-icon"></span>
</button>
<div class="collapse navbar-collapse justify-content-end" id="collapsibleNavbar">
<ul class="navbar-nav">
<li class="nav-item"><a class="nav-link" href="./index.html">Home</a></li>
<li class="nav-item"><a class="nav-link" href="./android_application_fundamentals.html">Android Fundamentals</a></li>
<li class="nav-item"><a class="nav-link" href="./reverse_engineering.html">Reverse Engineering</a></li>
<li class="nav-item active dropdown">
<a class="nav-link dropdown-toggle" href="./security_analysis.html">
Security Analysis
</a>
<div class="dropdown-menu" aria-labelledby="navbarDropdown">
<a class="dropdown-item" href="./security_analysis.html#static-analysis">Static Analysis</a>
<a class="dropdown-item" href="./security_analysis.html#dynamic-analysis">Dynamic Analysis</a>
<a class="dropdown-item" href="./security_analysis.html#data-storage-analysis">Data Storage Analysis</a>
<a class="dropdown-item" href="./security_analysis.html#cryptography">Cryptography</a>
</div>
</li>
<li class="nav-item dropdown">
<a class="nav-link dropdown-toggle" href="./other_topics.html">
Other Topics
</a>
<div class="dropdown-menu" aria-labelledby="navbarDropdown">
<a class="dropdown-item" href="./other_topics.html#rooting-android-device">Rooting Android Device</a>
<a class="dropdown-item" href="./other_topics.html#android-malware">Android Malware</a>
<a class="dropdown-item" href="./other_topics.html#useful-tools">Useful Tools</a>
</div>
</li>
</ul>
</div>
</nav>
<main>
<div class="container-fluid pb-3">
<div class="row">
<div class="col-sm-4">
<div class="side-menu sticky_menu">
<div class="page-title">
Security Analysis
</div>
<div id="side">
<div id="side_menu">
<div class="side-menu-content">
<ul class="side_nav">
<li><a class="nav-link active" href="#intro">Introduction</a></li>
</ul>
</div>
<div class="side-menu-header">
<h4 class="text-left">Static Analysis</h4>
</div>
<div class="side-menu-content">
<ul class="side_nav">
<li><a class="nav-link" href="#static-intro">Introduction</a></li>
<li><a class="nav-link" href="#manual-code-rev">Manual Code Review</a></li>
<li><a class="nav-link" href="#auto">Automated Source Code Analysis</a></li>
<li><a class="nav-link" href="#mobsf">Static Analysis using MOBSF</a></li>
</ul>
</div>
<div class="side-menu-header">
<h4 class="text-left">Dynamic Analysis</h4>
</div>
<div class="side-menu-content">
<ul class="side_nav">
<li><a class="nav-link" href="#dynamic-intro">Introduction</a></li>
<li><a class="nav-link" href="#da-tools">Tools</a></li>
<li><a class="nav-link" href="#mem-dump">Direct Memory Analysis</a></li>
<li><a class="nav-link" href="#debugging">Debugging</a></li>
</ul>
</div>
<div class="side-menu-header">
<h4 class="text-left">Data Storage Analysis</h4>
</div>
<div class="side-menu-content">
<ul class="side_nav">
<li><a class="nav-link" href="#data-storage-intro">Introduction</a></li>
<li><a class="nav-link" href="#storage-techniques">Data Storage Techniques</a></li>
<li><a class="nav-link" href="#testing-local-storage">Testing Local Storage</a></li>
</ul>
</div>
<div class="side-menu-header">
<h4 class="text-left">Cryptography</h4>
</div>
<div class="side-menu-content">
<ul class="side_nav">
<li><a class="nav-link" href="#crypto-intro">Introduction</a></li>
<li><a class="nav-link" href="#insec-algo">Identifying Insecure Crypto-Algorithms</a></li>
<li><a class="nav-link" href="#comm-config-issues">Common Configuration Issues</a></li>
</ul>
</div>
</div>
</div>
</div>
</div>
<div class="col-sm-8">
<div class="side-content">
<section class="section" id="intro">
<div class="title-img d-flex align-items-center justify-content-center">
<img src="assets/img/security_analysis/security.png" alt="Security Analysis" class="img-fluid">
</div>
<br>
<p>
Let’s start by defining some testing methods:
</p>
<p>
<b>Black-box testing</b> is conducted without the tester having any information about the app being tested. This process is sometimes called "zero-knowledge testing". The main purpose of this test is allowing the tester to behave like a real attacker in the sense of exploring possible uses for publicly available and discoverable information.
<br>
<b>White-box testing</b> (sometimes called "full knowledge testing") is the total opposite of black-box testing in the sense that the tester has full knowledge of the app. The knowledge may encompass source code, documentation, and diagrams. This approach allows much faster testing than black-box testing due to its transparency and with the additional knowledge gained a tester can build much more sophisticated and granular test cases.
<br>
<b>Gray-box testing</b> is all testing that falls in between the two aforementioned testing types: some information is provided to the tester (usually credentials only), and other information is intended to be discovered. This type of testing is an interesting compromise in the number of test cases, the cost, the speed, and the scope of testing. Gray-box testing is the most common kind of testing in the security industry.
</p>
</section>
<section class="section" id="static-analysis">
<h2 class="content-title">Static Analysis</h2>
<section class="section" id="static-intro">
<p>
During static analysis, the mobile app's source code is reviewed to ensure appropriate implementation of security controls. In most cases, a hybrid automatic/manual approach is used. Automatic scans catch the low-hanging fruit, and the human tester can explore the code base with specific usage contexts in mind.
</p>
</section>
<section class="section" id="manual-code-rev">
<h3 class="content-title">Manual Code Review</h3>
<p>
A tester performs manual code review by manually analyzing the mobile application's source code for security vulnerabilities. Methods range from a basic keyword search via the 'grep' command to a line-by-line examination of the source code. IDEs (Integrated Development Environments) often provide basic code review functions and can be extended with various tools.
</p>
<p>
A common approach to manual code analysis entails identifying key security vulnerability indicators by searching for certain APIs and keywords, such as database-related method calls like "executeStatement" or "executeQuery". Code containing these strings is a good starting point for manual analysis.
</p>
<p>
In contrast to automatic code analysis, manual code review is very good for identifying vulnerabilities in the business logic, standards violations, and design flaws, especially when the code is technically secure but logically flawed. Such scenarios are unlikely to be detected by any automatic code analysis tool.
</p>
<p>
A manual code review requires an expert code reviewer who is proficient in both the language and the frameworks used for the mobile application. Full code review can be a slow, tedious, time-consuming process for the reviewer, especially given large code bases with many dependencies.
</p>
</section>
<section class="section" id="auto">
<h3 class="content-title">Automated Source Code Analysis</h3>
<p>
Automated analysis tools can be used to speed up the review process of Static Application Security Testing (SAST). They check the source code for compliance with a predefined set of rules or industry best practices, then typically display a list of findings or warnings and flags for all detected violations. Some static analysis tools run against the compiled app only, some must be fed the original source code, and some run as live-analysis plugins in the Integrated Development Environment (IDE).
</p>
<p>
Although some static code analysis tools incorporate a lot of information about the rules and semantics required to analyze mobile apps, they may produce many false positives, particularly if they are not configured for the target environment. A security professional must therefore always review the results.
</p>
</section>
<section class="section" id="mobsf">
<h3 class="content-title">Static Analysis using MOBSF</h3>
<p>
Installing MobSF : <a href="https://mobsf.github.io/docs/#/installation" target="_blank">https://mobsf.github.io/docs/#/installation</a>
</p>
Static Analysis Architecture of MobSF:
<div class="d-flex align-items-center justify-content-center">
<img src="assets/img/security_analysis/mobsf-static.png" alt="MobSF Static Analysis" class="img-fluid">
</div>
<br>
Static Analysis using MobSF:
<div class="embed-responsive embed-responsive-16by9">
<video class="embed-responsive-item" src="assets/video/security_analysis/static_analysis.m4v" type="video/m4v" controls autoplay muted loop>
<source src="assets/video/security_analysis/static_analysis.m4v" type="video/m4v">
Your browser does not support the video tag :(
</video>
</div>
<br>
Android Source Tree-view using MobSF
<div class="embed-responsive embed-responsive-16by9">
<video class="embed-responsive-item" src="assets/video/security_analysis/src_code.mp4" type="video/mp4" controls autoplay muted loop>
<source src="assets/video/security_analysis/src_code.mp4" type="video/mp4">
Your browser does not support the video tag :(
</video>
</div>
</section>
</section>
<section class="section" id="dynamic-analysis">
<h2 class="content-title">Dynamic Analysis</h2>
<section class="section" id="dynamic-intro">
<p>
Why dynamic analysis in the first place? Suppose you are an attacker and the target app -
</p>
<ul>
<li>
Cannot be decompiled
</li>
<li>
Is heavily obfuscated
</li>
<li>
Generates values dynamically and cannot be retrieved from decompiled code
</li>
<li>
Signed and encrypted traffic, etc
</li>
</ul>
So instead of breaking the defence, the approach of dynamic analysis is to work from the inside i.e. to exploit the application’s own ability to perform tasks to our advantage and crack into it.
</section>
<section class="section" id="da-tools">
<h3 class="content-title">Tools</h3>
<p>
For the purpose of this tutorial, we use a platform called <b>AppUse</b> (developed by <a href="https://appsec-labs.com/" target="_blank">AppSec Labs</a>), which brings together many useful tools and custom scripts for mobile application security testing under one GUI. AppUse eliminates the need of painstakingly installing numerous security tools by packaging them into a virtual machine, and thus it will require a VM player to run. Following are the links to download AppUse and VMware Player -
</p>
<ol>
<li>
<a href="https://appsec-labs.com/appuse-pro/" target="_blank">AppUse</a>
</li>
<li>
<a href="https://www.vmware.com/products/workstation-player/workstation-player-evaluation.html" target="_blank">VMware Player</a>
</li>
</ol>
AppUse lets us perform dynamic analysis of both Android and iOS applications. It also lets us perform reverse engineering and code analysis too! So it is all-encompassing and powerful weapon for mobile application security testing.
</section>
<section class="section" id="mem-dump">
<h3 class="content-title">Direct Memory Analysis</h3>
<p>
Memory dump of an application is analysed when it is running. This can potentially reveal -
</p>
<ul>
<li>
Pieces of code
</li>
<li>
Sensitive data viz. app data, passwords, encryption keys, network traffic, calculations
</li>
<li>
Interaction with OS - files, processes
</li>
</ul>
<p>
Since android is a linux based OS, we could use a generic linux memory dump analyzer but it would reveal raw and low level data. To analyze the memory dump at a higher level we exploit the Java objects used in Android. We use a tool called Eclipse MAT that dumps app data and displays it in the form of comprehensible Java objects. Additional feature of Eclipse MAT is that it allows SQL query of the memory dump!
Following is an example of exposing the password entered by a user into an app by analysing the memory dump -
</P>
<ol>
<li>
AppUse dashboard -
<div class="d-flex align-items-center justify-content-center">
<img src="assets/img/security_analysis/dyn_analysis-1.png" alt="Dynamic Analysis" class="img-fluid">
</div>
<br>
</li>
<li>
AppUse tools collection -
<div class="d-flex align-items-center justify-content-center">
<img src="assets/img/security_analysis/dyn_analysis-2.png" alt="Dynamic Analysis" class="img-fluid">
</div>
<br>
</li>
<li>
Android emulator - For the purpose of this tutorial we used a custom built vulnerable app called <b>HackMePal</b> by AppSec Labs
<div class="d-flex align-items-center justify-content-center">
<img src="assets/img/security_analysis/dyn_analysis-3.png" alt="Dynamic Analysis" class="img-fluid">
</div>
<br>
</li>
<li>
Dumping the memory of mobile app into .hprof file
<div class="d-flex align-items-center justify-content-center">
<img src="assets/img/security_analysis/dyn_analysis-4.png" alt="Dynamic Analysis" class="img-fluid">
</div>
<br>
</li>
<li>
Converting the .hprof file into Eclipse MAT compatible .hprof version
<pre><code class="console text-light bg-dark">hprof-conv comm.appsec.hackmepal.hprof mat.hprof</code></pre>
</li>
<li>
Opening into .hprof file in Eclipse MAT
<div class="d-flex align-items-center justify-content-center">
<img src="assets/img/security_analysis/dyn_analysis-5.png" alt="Dynamic Analysis" class="img-fluid">
</div>
<br>
</li>
<li>
Open the dominator tree reorder and navigate through the packages and Java classes to find the desired variable
<div class="d-flex align-items-center justify-content-center">
<img src="assets/img/security_analysis/dyn_analysis-6.png" alt="Dynamic Analysis" class="img-fluid">
</div>
<br>
<div class="d-flex align-items-center justify-content-center">
<img src="assets/img/security_analysis/dyn_analysis-7.png" alt="Dynamic Analysis" class="img-fluid">
</div>
</li>
</ol>
</section>
<section class="section" id="debugging">
<h3 class="content-title">Debugging</h3>
<p>
This includes -
</p>
<ol>
<li>
Setting breakpoints
</li>
<li>
Bypassing restrictions
</li>
<li>
Jump to specific code sections
</li>
<li>
Expose secrets from memory
</li>
</ol>
<p>
If the source code was available, debugging is no big deal. But that’s not the case most of the time source code is unavailable. Also, decompiling an app using dex2jar and rebuilding the project with its dependencies is tricky and difficult. Alternatively, we use remote debug smali code, which is byte level assembly level code.
Following are the key steps in debugging -
</p>
<ol>
<li>
Decode apk in debug mode <br>
<pre><code class="console text-light bg-dark">apktool d -d app.apk out</code></pre>
</li>
<li>
Make it debuggable in the <code> AndroidManifest.xml </code> application tag <br>
<pre><code class="console text-light bg-dark"><application .. android:debuggable="true"/> </code></pre>
</li>
<li>
Build new apk in debug mode <br>
<pre><code class="console text-light bg-dark">apktool b -d out</code></pre>
</li>
<li>
Sign, install, and run new apk
<pre><code class="console text-light bg-dark">signapk input.apk </code></pre>
</li>
<li>
Create Netbeans project with the smali code
</li>
<li>
Attach debugger
</li>
<li>
Set breakpoint
</li>
</ol>
<p>
Debugging lets you play with code and run the functions in it on custom parameters. For example, if the the application is poorly designed then one could easily intercept the traffic generated by the app by setting up a Burp proxy and could modify the request appropriately.
</p>
<p>
There is another useful tool in AppUse suite called ReFrameworker which is used to change app behaviour without patching any code. Interested folks can explore it further. On a higher level, it works in the following way -
</P>
<ol>
<li>The android runtime is compiled with many hooks planted inside the code</li>
<li>These hooks look for a file named <code>Reframeworker.xml</code> located inside <code> /data/system </code> </li>
<li>Each time the app is run and when a hooked runtime is called, it loads the ReFrameworker configuration along with the contained rules</li>
</ol>
</section>
</section>
<section class="section" id="data-storage-analysis">
<h2 class="content-title">Data Storage Analysis</h2>
<section class="section" id="data-storage-intro">
<p>
Android provides a number of methods for <a href="https://developer.android.com/guide/topics/data/data-storage.html" target="_blank">data storage</a> depending on the needs of the user, developer, and application. For example, some apps use data storage to keep track of user settings or user-provided data. Data can be stored persistently for this use case in several ways.
</p>
</section>
<section class="section" id="storage-techniques">
<h3 class="content-title">Data Storage Techniques</h3>
The following list of persistent storage techniques are widely used on the Android platform:
<ul class="spaced-ul">
<li>
<b>Shared Preferences</b>
<br>
The <a href="https://developer.android.com/training/data-storage/shared-preferences" target="_blank">SharedPreferences</a> API is commonly used to permanently save small collections of key-value pairs. Data stored in a SharedPreferences object is written to a plain-text XML file. The SharedPreferences object can be declared world-readable (accessible to all apps) or private. Misuse of the SharedPreferences API can often lead to exposure of sensitive data.
</li>
<li>
<b>SQLite Databases</b>
<br>
SQLite is an SQL database engine that stores data in .db files. The Android SDK has <a href="https://developer.android.com/training/data-storage/sqlite" target="_blank">built-in support</a> for SQLite databases. The main package used to manage the databases is android.database.sqlite. SQLite databases can be stored in encrypted form as well as in plain text form
</li>
<li>
<b>Firebase Databases</b>
<br>
Firebase is a development platform with more than 15 products, and one of them is Firebase Real-time Database. It can be leveraged by application developers to store and sync data with a NoSQL cloud-hosted database. The data is stored as JSON and is synchronized in real-time to every connected client and also remains available even when the application goes offline.
</li>
<li>
<b>Internal Storage</b>
<br>
We can save files to the device's <a href="https://developer.android.com/guide/topics/data/data-storage.html#filesInternal" target="_blank">internal storage</a>. Files saved to internal storage are containerized by default and cannot be accessed by other apps on the device. When the user uninstalls your app, these files are removed.
</li>
<li>
<b>External Storage</b>
<br>
Every Android-compatible device supports <a href="https://developer.android.com/guide/topics/data/data-storage.html#filesExternal" target="_blank">shared external storage</a>. This storage may be removable (such as an SD card) or internal (non-removable). Files saved to external storage are world-readable. The user can modify them when USB mass storage is enabled.
</li>
<li>
<b>Keystore</b>
<br>
The <a href="https://www.androidauthority.com/use-android-keystore-store-passwords-sensitive-information-623779/" target="_blank">Android KeyStore</a> supports relatively secure credential storage. As of Android 4.3 (API level 18), it provides public APIs for storing and using app-private keys. An app can use a public key to create a new private/public key pair for encrypting application secrets, and it can decrypt the secrets with the private key.
<br>
You can protect keys stored in the Android KeyStore with user authentication in a confirmed credential flow. The user's lock screen credentials (pattern, PIN, password, or fingerprint) are used for authentication.
</li>
</ul>
</section>
<section class="section" id="testing-local-storage">
<h3 class="content-title">Testing Local Storage for Sensitive Data</h3>
<ul>
<li>
Analyze data storage in the source code.(Using Static Analysis)
</li>
<li>
Be sure to trigger all possible functionality in the application (e.g. by clicking everywhere possible) in order to ensure data generation.
</li>
<li>
Check all application generated and modified files and ensure that the storage method is sufficiently secure.
<ul>
<li>
This includes SharedPreferences, SQL databases, Internal Storage, External Storage, etc.
</li>
<li>
ADB CLI can be used to extract generated files
</li>
</ul>
</li>
<li>
Check Resources files to check if any sensitive information is stored in it
</li>
</ul>
<p>
In general sensitive data stored locally on the device should always be at least encrypted, and any keys used for encryption methods should be securely stored within the Android Keystore. These files should also be stored within the application sandbox. If achievable for the application, sensitive data should be stored off device or, even better, not stored at all.
</p>
<p>
More information of Storing application Data: <a href="https://developer.android.com/topic/security/data" target="_blank">https://developer.android.com/topic/security/data</a>
</p>
</section>
</section>
<section class="section" id="cryptography">
<h2 class="content-title">Cryptography</h2>
<section class="section" id="crypto-intro">
<p>
Cryptography plays an especially important role in securing the user's data - even more so in a mobile environment, where attackers having physical access to the user's device is a likely scenario. This chapter provides an outline of cryptographic concepts and best practices relevant to mobile apps. These best practices are valid independent of the mobile operating system.
</p>
</section>
<section class="section" id="insec-algo">
<h3 class="content-title">Identifying Insecure (or Deprecated) Cryptographic Algorithms</h3>
<p>
When assessing a mobile app, you should make sure that it does not use cryptographic algorithms and protocols that have significant known weaknesses or are otherwise insufficient for modern security requirements
</p>
<ul>
<li>
Inspect the app's source code to identify instances of cryptographic algorithms that are known to be weak, such as: <i>DES, 3DES RC2 RC4 BLOWFISH MD4 MD5 SHA1</i>.
</li>
<li>
Cryptographic algorithms are up to date and in-line with industry standards.
</li>
<li>
Key lengths are in-line with industry standards and provide protection for sufficient amounts of time. A comparison of different key lengths and protection they provide taking into account Moore's law is available online. Key lengths are in-line with industry standards and provide protection for sufficient amounts of time. A comparison of different key lengths and protection they provide taking into account Moore's law is available online.
</li>
<li>
Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a keypair used for a signature to do encryption.
</li>
<li>
Cryptographic parameters are well defined within reasonable range.
</li>
</ul>
</section>
<section class="section" id="comm-config-issues">
<h3 class="content-title">Common Configuration Issues (MSTG-CRYPTO-1, MSTG-CRYPTO-2 and MSTG-CRYPTO-3)</h3>
<ul class="spaced-ul">
<li>
<b>Insufficient Key Length</b>
<br>
Even the most secure encryption algorithm becomes vulnerable to brute-force attacks when that algorithm uses an insufficient key size. Ensure that the key length fulfills accepted industry standards.
</li>
<li>
<b>Symmetric Encryption with Hard-Coded Cryptographic Keys</b>
<br>
Hardcoded encryption key means that a key is:
<ul style="list-style-type: square">
<li>
a part of application resources
</li>
<li>
value which can be derived from known values
</li>
<li>
hardcoded in code
</li>
</ul>
<b> Recommendation to Secure Symmetric Encryption</b>
<br>
<ul style="list-style-type: square">
<li>
Ensure that no keys or passwords are stored within the source code. This means you should check native code, JavaScript/Dart code, Java/Kotlin code on Android and Objective-C/Swift in iOS. Note that hard-coded keys are problematic even if the source code is obfuscated since obfuscation is easily bypassed by dynamic instrumentation
</li>
<li>
If the app is using two-way SSL (both server and client certificates are validated), make sure that:
<ul style="list-style-type: square">
<li>
The password to the client certificate isn't stored locally or is locked in the device Keychain.
</li>
<li>
The client certificate isn't shared among all installations.
</li>
</ul>
</li>
<li>
If the app relies on an additional encrypted container stored in app data, check how the encryption key is used. If a key-wrapping scheme is used, ensure that the master secret is initialized for each user or the container is re-encrypted with a new key. If you can use the master secret or previous password to decrypt the container, check how password changes are handled.
</li>
<li>
Secret keys must be stored in secure device storage whenever symmetric cryptography is used in mobile apps. For more information on the platform-specific APIs.
</li>
</ul>
</li>
<li>
<b>Weak Key Generation Functions</b>
<br>
Cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password as an input key has the following problems:
<ul style="list-style-type: square">
<li>
If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
</li>
<li>
A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
</li>
</ul>
Ensure that passwords aren't directly passed into an encryption function. Instead, the user-supplied password should be passed into a KDF to create a cryptographic key.
<br>
Choose an appropriate iteration count when using password derivation functions.
</li>
<li>
<b>Weak Random Number Generators</b>
</li>
<li>
<b>Custom Implementations of Cryptography</b>
<br>
Carefully inspect all the cryptographic methods used within the source code, especially those that are directly applied to sensitive data. All cryptographic operations should use standard cryptographic APIs for Android and iOS (we'll write about those in more detail in the platform-specific chapters). Any cryptographic operations that don't invoke standard routines from known providers should be closely inspected.
</li>
<li>
<b>Inadequate AES Configuration</b>
<br>
Advanced Encryption Standard (AES) is the widely accepted standard for symmetric encryption in mobile apps. It's an iterative block cipher that is based on a series of linked mathematical operations. AES performs a variable number of rounds on the input, each of which involve substitution and permutation of the bytes in the input block. Each round uses a 128-bit round key which is derived from the original AES key.
</li>
<li>
<b>Predictable Initialization Vector</b>
<br>
CBC, OFB, CFB, PCBC mode require an initialization vector (IV) as an initial input to the cipher. The IV doesn't have to be kept secret, but it shouldn't be predictable. Make sure that IVs are generated using a cryptographically secure random number generator.
</li>
<li>
<b>Protecting Keys in Memory</b>
<br>
When memory dumping is part of your threat model, then keys can be accessed the moment they are actively used. Memory dumping either requires root-access (e.g. a rooted device or jailbroken device) or it requires a patched application with Frida (so you can use tools like Fridump). Therefore it is best to consider the following, if keys are still needed at the device:
<ul style="list-style-type: square">
<li>
Make sure that all cryptographic actions and the keys itself remain in the Trusted Execution Environment (e.g. use Android Keystore) or Secure Enclave (e.g. use the Keychain and when you sign, use ECDHE).
</li>
<li>
If keys are necessary which are outside of the TEE / SE, make sure you obfuscate/encrypt them and only de-obfuscate them during use. Always zero out keys before the memory is released, whether using native code or not. This means: overwrite the memory structure (e.g. nullify the array) and know that most of the Immutable types in Android (such as BigInteger and String) stay in the heap.
</li>
</ul>
</li>
<li>
<b>Protecting keys in Transport</b>
<br>
When keys need to be transported from one device to another, or from the app to a backend, make sure that proper key protection is in place, by means of an transport keypair or another mechanism. Often, keys are shared with obfuscation methods which can be easily reversed. Instead, make sure asymmetric cryptography or wrapping keys are used.
</li>
</ul>
</section>
</section>
</div>
</div>
</div>
</div>
</main>
<footer>
<div class="text-center bg-dark text-light p-3 h6" style="margin-bottom:0; font-family: monospace">
<div>Developed by Team Watch Dogs [CS416 2021 | IIT Bombay]</div>
</div>
</footer>
<script src="./assets/js/vendor/jquery-3.5.1.min.js"></script>
<script src="./assets/js/bootstrap.min.js"></script>
<script src="./assets/js/highlight.min.js"></script>
<script src="./assets/js/main.js?v4"></script>
</body>
</html>