In case if you missed the previous articles in this series, here are the links. https://resources.infosecinstitute.com/cracking-damn-insecure-and-vulnerable-apps-diva-part-1/ https://resources.infosecinstitute.com/cracking-damn-insecure-and-vulnerable-app-diva-part-2/ https://resources.infosecinstitute.com/cracking-damn-insecure-and-vulnerable-app-diva-part-3/ https://resources.infosecinstitute.com/cracking-damn-insecure-and-vulnerable-app-diva-part-4/
Steps to solve:
Click on “12. HARDCODING ISSUES – PART 2” in your application. The goal of this challenge is to find out the vendor key and submit it to the application. Following is the decompiled code that is associated with the activity.
Hardcode2Activity.class Looking at the above code at Hardcode2Activity.class, it appears that this activity is creating an object of DivaJni class when it is loaded. Exploring other files reveal that there is a file called DivaJni.class as shown below.
DivaJni.class From above code, it is clear that a native library called “divajni” is loaded. Libraries will come with the APK file, and they are usually located within the”lib” directory. Unpacking the application using the command $ unzip diva-beta.apk will result in all the files and folders extracted as shown below. $ ls AndroidManifest.xml META-INF classes.dex diva-beta.apk lib res resources.arsc $ Lets navigate to “lib” folder and run “ls *” to list out all the files within each directory. This is shown below. $ ls * arm64-v8a: libdivajni.so armeabi: libdivajni.so armeabi-v7a: libdivajni.so mips: libdivajni.so mips64: libdivajni.so x86: libdivajni.so x86_64: libdivajni.so $ As we can see in the above excerpt, there are multiple instances of “libdivajni.so” files for various architectures. Lets pull one of them and run strings command on that to see if we can find anything interesting. This is shown below. $ strings libdivajni.so /system/bin/linker __cxa_finalize __cxa_atexit Java_jakhar_aseem_diva_DivaJni_access strncmp __aeabi_unwind_cpp_pr1 Java_jakhar_aseem_diva_DivaJni_initiateLaunchSequence strcpy __aeabi_unwind_cpp_pr0 JNI_OnLoad __aeabi_unwind_cpp_pr2 __gnu_Unwind_Find_exidx __gnu_Unwind_Restore_VFP_D __gnu_Unwind_Restore_VFP __gnu_Unwind_Restore_VFP_D_16_to_31 __gnu_Unwind_Restore_WMMXD __gnu_Unwind_Restore_WMMXC abort restore_core_regs memcpy _Unwind_GetCFA __gnu_Unwind_RaiseException __gnu_Unwind_ForcedUnwind __gnu_Unwind_Resume __gnu_Unwind_Resume_or_Rethrow _Unwind_Complete _Unwind_DeleteException _Unwind_VRS_Get _Unwind_VRS_Set __gnu_Unwind_Backtrace __cxa_begin_cleanup __cxa_type_match __gnu_unwind_execute __cxa_call_unexpected _Unwind_VRS_Pop __gnu_Unwind_Save_VFP_D __gnu_Unwind_Save_VFP __gnu_Unwind_Save_VFP_D_16_to_31 __gnu_Unwind_Save_WMMXD __gnu_Unwind_Save_WMMXC __restore_core_regs ___Unwind_RaiseException _Unwind_RaiseException ___Unwind_Resume _Unwind_Resume ___Unwind_Resume_or_Rethrow _Unwind_Resume_or_Rethrow ___Unwind_ForcedUnwind _Unwind_ForcedUnwind ___Unwind_Backtrace _Unwind_Backtrace __gnu_unwind_frame _Unwind_GetRegionStart _Unwind_GetLanguageSpecificData _Unwind_GetDataRelBase _Unwind_GetTextRelBase _edata __bss_start _end libstdc++.so libm.so libc.so libdl.so libdivajni.so olsdfgad;lh .dotdot GCC: (GNU) 4.8 gold 1.11 aeabi .shstrtab .interp .dynsym .dynstr .hash .rel.dyn .rel.plt .text .ARM.extab .ARM.exidx .rodata .fini_array .init_array .dynamic .got .data .bss .comment .note.gnu.gold-version .ARM.attributes $ Looking at the above output, we can notice various strings coming out among which two strings that are highlighted in the above output caught my attention. After trying both of them in the application, I ended up finding the right vendor key olsdfgad;lh
We can also find this hardcoded key in the source, which is available at the following link. https://github.com/payatu/diva-android/blob/master/app/src/main/jni/divajni.c Following is the hardcoded constant from the source code.
Steps to solve:
Click on “13. INPUT VALIDATION ISSUES – PART 3” in your application. The goal is to crash the application some how. Let’s first see how the application is responding when we enter some input. I have entered 4 As in the input field as shown below.
As you can see, the application has shown an error message. After entering multiple inputs as such, the application responded with the same error message as long as the input length is not greater than 20. The following figure shows that the app is throwing the same error when we enter 20 As.
Now let’s see how the application responds of we enter some large text. This time, I am entering 40 As.
As you can see in the above figure, the application has been crashed.
Lets see if we can find any information about this crash in “logcat”. Open up a new terminal and type “adb logcat”
I/DEBUG ( 54): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 54): Build fingerprint: ‘generic/sdk/generic:4.4.2/KK/938007:eng/test-keys’
I/DEBUG ( 54): Revision: ‘0’
I/DEBUG ( 54): pid: 1246, tid: 1246, name: khar.aseem.diva »> jakhar.aseem.diva «<
I/DEBUG ( 54): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 41414140
I/DEBUG ( 54): r0 00000000 r1 bef7536c r2 00000007 r3 00000000
I/DEBUG ( 54): r4 41414141 r5 b715b398 r6 00000004 r7 b2e52d10
I/DEBUG ( 54): r8 bef75388 r9 b2e52d08 sl b715b3a8 fp bef7539c
I/DEBUG ( 54): ip aafbdfe4 sp bef75388 lr aafbad5c pc 41414140 cpsr 00000030
I/DEBUG ( 54): d0 0000000080000000 d1 0000000042180000
I/DEBUG ( 54): d2 0000000000000000 d3 33d6bf9500000000
I/DEBUG ( 54): d4 0000000000000000 d5 3f80000000000000
I/DEBUG ( 54): d6 3f80000000000000 d7 0000000080000000
I/DEBUG ( 54): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 54): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 54): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 54): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 54): scr 60000010
I/DEBUG ( 54):
I/DEBUG ( 54): backtrace:
I/DEBUG ( 54): #00 pc 41414140
The buffer size allocated is 20. We can see it from the following figure.
So, it is clear that we are writing larger data than the size of the buffer. Due to insufficient bounds checking in strcpy() function, the buffer is overflown when user-supplied input is copied, and the application crashed. Any input that has the length greater than 20 bytes will cause a buffer overflow condition in this application.
