Taking Back What's yours: Defeating CryCryptor ransomware, another covid-19 malware! ☜(˚▽˚)☞ (day 98)
Disclaimer:
This post is heavily based on Lukas Stefanko "Analysis of CryCryptor Android Ransomware and how I created decryptor | fake COVID-19 tracing app" all of the credit goes to him and please support his channel(You can check the video in this link)Background:
As soon I see the video, I grab my laptop and to try analyze the malware by myself and see what I came out with. In summary, I understand the encryption along with the decryption process, internal works of the malware in detail and I managed to come out with an alternative way to decrypt back the file. Nevertheless, the concept is pretty much the same from the original video.In this post, I will teach you how to analyze it and create your own tools for recovering the encrypted file.
Before we move on to the juicy stuff, the following is the background story of CrypCryptor Android:
- It's targeting user in Canada
- It disguises itself as an official COVID-19 tracing app provided by Health Canada
- It is based on open-source code on GitHub. Link: https://github.com/thelinuxchoice/crydroid but now is dead
If you just want to get the POC, just go to this Github page
Getting The Samples:
First, we need to get our hands on the sample. I used Koodous to download the malware:Reverse Engineer The Malware: Understanding the Encryption
Once I download the malware I open it in Jadx and the first thing to look is the manifest file which contains the summary of the application.First, let's take a look at the permission, here we can see that it requires internet access, access to external storage(this is where our focus should be put on), get notified when the device in boot-up and foreground_service to let the application run in background service(used if targetSdkVersion=29).
This is the broadcast receiver that responsible for receiving boot events in the device(We will take a look on this broadcast receiver later)
This is services that responsible for running background task in the device. Even though you are not an android developer the name is quite clear with the intent that the component does. Please pay attention in this configuration because it holds the key to retrieving the encrypted file.
File: "com.crydroid.ui.MainActivity"
Let's go to the MainActivity class first since this the piece of code that is trigger when it first opens the application. Bring your attention to the onCreate() function(when an activity class is triggered, it first execute the onCreate() function)
It looks like the application doing some preparation by calling e(), c(), and f() function.
e(), responsible for setting and storing the encryption key. The application put the encryption key in shared preferences.
inside the shared preferences the malware put two indexes, first is UUID and password(com.crydroid.PASSWORD) that will be used to encrypt our file and it is generated through d() function.
as you can see the d() function called different classes named b() (import from g.a.a.b) and used the a() function to generate random strings consist of uppercase, lowercase, number, and special characters.
c() function, responsible to show the SDK version of the software currently running on this hardware device.
b() function, to setup listener for button.
next, the application will ask for access to external storage using a() function
and refer to the shared preferences for the second time to retrieve the UUID value for paying the ransom using b() function.
To all of you who never do actual reverse engineering on an android malware, you might have difficulty at first following the explanation since the name of the function is confusing, this is actually quite common since malware author wants to confuse you when analyzing their source code.
But that's all right throughout the time it will come as a second nature if you practice it daily
if the two conditions from a() and b() function are fulfilled the malware will execute the encryption mechanism.
To the more astute reader out there, you might notice that inside the MainActivity class, the malware author registers a broadcast receiver at runtime(when the application resumes the execution to be more precise) that is not listed in manifest file with two intent filters ACTION_ENCRYPTED and ACTION_DECRYPTED.
this registered broadcast receiver responsible for changing the ransom text and UI in the application. If the receiver invokes with intent contain "com.crydroid.ACTION_DECRYPTED" it will change to "unlocked. Personal files decrypted"
File: "com.crydroid.services.EncryptionService"
Let's take a look at the encryption process, as you know the encryption is started if the com.crydroid.services.EncryptionService invokes by the application.
In android, The first function that will be executed by the service is onStartCommand() that will start foreground service.
in summary, there are two functions that you should focus on com.crydroid.services.EncryptionService: the c() and the b() function
c() function responsible to enumerate all the files inside your external storage to be encrypted later. However, as you can see only particular file with specific extension that will be encrypted by the app
then inside the if statement there is a function call, b(canonicalPath) and this is the part where the encryption happens.
from the source code above the encryption used AES encryption and at the end of the function it will generate three files: the first one will contain extensions .enc(the encrypted file), .enc.iv(contain the initialization vector), and enc.salt(contain the salt of the encrypted file).
The key is retrieved from index "com.crydroid.PASSWORD" in shared preference that has been set at the beginning of application execution.
Run The Malware: Let's see what we got
We have go through the source code of the malware to understand how it encrypts our file. Now! It is time to do some dynamic analysis by running the malware inside an emulator.To make it more realistic I will create some random note in the external storage
Next, I install the application into the emulator(android SDK 22) and you will have a new application named "traceshield"
Once you click the application it will ask for permission for external storage, confirm the permission and it will automatically exit the application by prompting error message.
If you open the application again it will show you a ransom message that tells your data is encrypted and you need to send an email to this address.
In order to decrypt it, you have to put the password in the application which is the master key for the encryption. Let's take a look at our file!
yeah! it is encrypted and the original text is gone, bummer!
Notice that we also got a new file called, readme.txt that contain the same instruction that we got in the application
Let's check the shared preferences file that contains the configuration of the encryption scheme inside the application internal directory.
well it pretty much what we expected, right? there are UUID and password index inside that contains the master key. We could just put the password to decrypt the file but if you want to do it in real life scenario the infected phone might not have been rooted.
So how do we get our file back without rooted phone?! captain????
No worries! let's take our step back to the manifest file again, do you still remember about the three service components that I show you earlier?
Pay attention to the android:exported tag in it what is it says? it is set to be True so this means that anyone inside the device can invoke this component without root access and the GOOD NEWS! here is that the decryption component can be invoked as well. What you see in here is a vulnerability called "Improper Export of Android Components" labeled as CWE-926
Reverse Engineer The Malware: Understanding the Decryption
Let's take a moment to understand the decryption scheme in the malware. The decryption starts when you enter the master key in the app.The corresponding source code is below:
File: "com.crydroid.ui.c"
as you can see when we enter the master key it will compare with the one that is saved in shared preferences and if it's equal it will invoke the DecryptionService class to decrypt the file.
File: "com.crydroid.services.DecryptionService"
Inside the decryption class, the process is pretty much the same with encryption, let's take a look:
onStartCommand() function that is used to invoke the service component
a() function used to delete the readme_now.txt file that contains the ransom text.
b() function used to dump all encrypted files and called b(canonicalPath) where contains the decryption function.
the decryption function is pretty straightforward, it will get the salt(.enc.salt) and the iv(.enc.iv) file along with the encrypted file(.enc) then used this along the master key to get the original content of the file.
Taking Back What's Yours!: Defeating The Ransomware
Now that we have understood the decryption process, it is time to build the program that will invoke the decryption process.You can do this normally using ADB:
Easy Peasy Lemon Squeezy!
or if you want more and want to do it with programming, we can use python to automate this process.
we will use the pure python adb library.
I create a python script that contains 3 functions:
- The first function(connect_to_devices), will search for device attach to USB cable through ADB and will return a list of devices
- The second function(check_ransomware_package), will check if the device is infected with the ransomware or not
- The third function(decrypt_file_device), will invoke the DecryptionService service class to do the decryption process.
run the python script and we got our file back, yeaayyyy!
But not many devices will have the functionality on ADB access, right?!
I think the most convenient way is to create an android app and let it install on your phone. Okay! let's do it!
I open my android studio and for a starter, I will create two functions that will detect the ransomware application using packageManager() class and invoke the DecryptionService class by using Intent. Well as you can see the logic is pretty much the same with the python script, right?
Finally, put it together again in the onCreate()(in Android this is equivalent to main() function)
Before Decryption:
After Decryption:
Installed the application and yeaaayy! it works again!
I put all the source code for android app and python in this Github page
Alternative Way!
this section is optional for the reader, this is just another vulnerability that I found in malware that able to retrieve the master keyBut in order to do this, you need to have ADB, USB cable, and Developer options turned on.
Okay! So I start noticing this vulnerability when I see the android:allowBackup config is set to be true. This means that the app allows its content to be backup and restore later, thus I try to back up the malware and see if the master key is included or not.
I used the ADB backup command to do this and then I extract the .ab file using python Zlib library and yes! we got the master key.
I enter the master key and I got the file back
Cool! So that's all for today, I hope you enjoy this post and have a Good day :)
Comments
Post a Comment