Abstract

What is steganography? Steganography is the practice of hiding messages in other messages. This means messages that are sent as words can be encrypted into clutters of other words, images, sound, and videos. The purpose of steganography is not to encrypt the content of a message, but rather to hide the message altogether. Many times, the sole fact that a message is encrypted is a threat to third party adversaries, and thus the strength of the steganography holds the utmost importance. In this paper we will talk about the role of steganography and explore the vulnerabilities in an encryption app called Nahoft.  

Introduction

Iran’s authoritarian regime is tending towards increased internet restriction and surveillance over its people. Slowly but surely, the Iranian government is filtering data to control the intake of information and limiting the trajectory of connection to Iran. In November of 2019, the Iranian government shutdown the internet for a whole week to silence protestors as well as limit exposing the truth to the rest of the world.  Nahoft is a free app on the Google Play store made by United for Iran, a group working on the civil liberties in Iran by creating technological tools such as apps. Nahoft helps Iranians communicate effectively with one another without interference from the government by turning messages from up to 1000 characters into random words in Farsi as well as images. Nahoft itself is not a messaging platform but acts as the tool that encrypts and decrypts messages which are sent on other platforms. One limitation of Nahoft not being a messaging platform is users need to make sure the platform they are using has end-to-end security or else adversaries will be able to get the encrypted message and there will be no confidentiality. The reasoning for this is Iran’s government shuts down their internet, making it difficult for people to communicate. However, because Nahoft does not require internet to encrypt and decrypt messages, when there is an internet shutdown, Iranians can still use Nahoft to speak encrypted sentences as long as they have Nahoft downloaded. Two users on Nahoft are allowed to send encrypted messages back and forth on a third-party messaging platform after sending each other invitations via the same messaging platforms. These invitations as well as messages are decoded on the app, and so only the intended recipient has access to the decoded message.

Background

Before exploring the app, we read the penetration test reports to get a better understanding of the short sights of the app and how they had been solved as well as a better understanding of the efficacy of the defense mechanisms in place to combat attackers. The penetration tests made it easier to point out the vulnerabilities that still exist in the app. Nahoft has gone through two rounds of penetration tests by Cure53. In the first round of penetration tests, the researchers and experts found that the steganography was extremely ineffective. Firstly, the obfuscation of the text was insufficient, meaning the non-syntactic words that didn’t form logically coherent sentences raised suspicion of encryption. Also, the encrypted message is always outputted in multiples of 256 bytes. These patterns made it clear to the experts that these messages were using steganography. Similarly, the obfuscation of the images was also increasingly insufficient. Instead of hiding the steganography, the image was noticeably different as the encrypted message was displayed in the border of the image. Making sure the steganography behind Nahoft is acceptable is important because a simple algorithm could ban Nahoft-related text and images. The power of Nahoft lies in its ability to encrypt messages that blend well with normal text messages.

Other vulnerabilities found in the examination was with the destruction code that deletes all the data from the Nahoft application. The adversary knows it is unlikely that the user has no messages and no friends on the app, and thus, they will know that a destruction code was entered and not the log-in passcode. A possible solution is leaving data that does not give any significant information to the adversary. Furthermore, the password strength of the of the both the log-in and destruction code was also weak. Common passwords such as the repetition of one number were allowed. This data could be arbitrarily set when the destruction code is set to avoid the suspicion of the adversary. When the data is deleted, either through the destruction code or through individual deletion of a friend or message, the data is instantly inaccessible; however, the “zero-filling” technique does not ensure that the data is cleared from the RAM, backups, or garbage collection as well. 

In the second round of the penetration test, the main vulnerabilities found concerned the ImportTextActivity and ImportImageActivity. Nahoft exposes this code to third-party apps because they can be shared from the third-party messaging platform. However, a malicious adversary can send an intent that will crash Nahoft. Similarly, the LogInActivity is also exposed to third-party apps and a malicious intent could be sent to causing Denial-of-Service (DoS). The log-in screen is also bypassed when sharing from a third-party platform. Thus, the passcode does not fully protect the decrypted messages, and the third-party adversary is able to enter Nahoft without entering a passcode.

Closer Analysis

Since Nahoft is open source, we had the chance to study the code on the GitHub repository and follow threads that might reveal a deeper understanding of the app. We followed the swatch file and the instances of java.util.Random in it. In Swatch.kt, the random function is used to create long data types that are placed into a byte array, these long data types will be converted into a byte array inside this class and will later be converted to characters in Persian. It is important to note that the java.util.Random library which uses a systems clock as a seed to produce a pseudo-random integer is not cryptographically secure. If the adversary knows the time the seed was generated, they can generate the same sequence of “random” integers. Instead, a better alternative is java.security.SecureRandom. Any seed passed through to a SecureRandom object must be unpredictable because it takes RandomData from the operating system.  The size of a random class also only has 48 bits compared to SecureRandom’s size of 128 bits, making it more difficult for adversaries to guess the random integer, and thus the encryption (2^48 attempts are required for the Random class and 2^128 attempts required for SecureRandom class). If java.util.Random was used in a test file and did not affect the code, than there would be no harm in using this library. However, it is used in the swatch file is in the app’s main source code.

Another library that we followed was Libsodiumjni. Libsodiumjni is a library that has multiple functionality purposes. It can convert an array of characters to a byte array, encrypt a string with a given key, get the public key, and generate random bytes with a seed and seed size. It is used in Encryption.kt (Nahoft/app/src/main/java/org/nahoft/codex) and this library gives the class access to the private and public keys. This class will encrypt the data. The conversion of the random data type to Persian characters occurs in Alphanumeric.kt where the bytes are converted to integers, then digits, and finally symbols. The internet permission in the Android.manifest.xml file asks the user if they want the app to use the internet to which for the purposes of Nahoft they can reply not allow. What this does is make it clear to the app that the user doesn’t want to use internet as opposed to the indiscretion created if this pop-up did not appear. If the internet permission is absent from the xml file, it is possible that the app uses the internet without denial of permission to upload information from the app to another server, causing data leakage. This file is located in both the main source code for the app and Codex.

Testing Application

Because Nahoft is an android application, in the testing process, we used a Pixel 4a Android emulator. To start exploring the app, first we can set the login password as well as the destruction code by going to Settings. The destruction code is a default wipeout of all the user’s friends as well as imported messages. This function is put in the app in the case that an adversary gains access to the phone device. The adversary will find no critical information that will put others (people in the friends list) in harm’s way. The passwords entered have some level of complication as sequential passcodes are not allowed. The passwords also must be exactly six numbers. Once done using the app, users should log-out using the log-out icon, prompting them to enter the log-in passcode the next time they click on the app. To use the destruction code, the user should enter it in the log-in instead of the actual log-in password and all the data will be cleared. Next to the settings, there is a Help icon which will teach users how to use the app by explaining the purpose of all the icons. To the left of the Help icon exists the Friends icon where the users will invite their friends by clicking the plus button on the bottom right corner. After entering the name of a friend, the user should invite them and copy the share text. This copied text should be sent to their friend on a third-party messaging platform. The friend will import the invitation and then the user can send encrypted messages back and forth with that friend. To send messages to a friend in the Friends list, the user should go to the Create icon where they will choose the friend they want to communicate with via drop-down list. They then will enter the message they would like to send. The user has the option of sending the message as another text messages or as an image. The new message or image will be copied and sent to a friend. The friend can import the image or message by clicking on the Read icon and pasting the data into textbox through the share function on the messaging platform (which will display Nahoft as one of the apps) or by using the Clipboard. The user can also manually type the entire message into the textbox to decrypt it. The user also has the option of saving an image if they don’t currently have internet. That way, when they do, the message is ready to send. All the saved messages will go in the Messages section of the Read icon. To delete the saved messages, the user should open the intended message and click the trash can icon. To delete a friend, the user should click on the intended friend, click the button that says “Edit” and a “Delete Friend” option will arise.

Summary of Test Application

         After exploring the app, there were a few vulnerabilities that stuck out. Firstly, after both penetration tests, Nahoft still did not recognize patterns of a weak password. For example, the password “147258” was allowed when it is vertically sequential. Similarly, the passcode for both the destruction code and the log-in could only be numbers with a length of six. This would make it easier for an adversary to guess the passcode since the number of combinations are not significant. To fix this problem, the passcode could include characters, making the use of special characters mandatory. The length of the passcode can also be increased to make it a stronger passcode. Furthermore, there can be a default number of times the user is allowed to answer the wrong passcode until they have to wait a certain amount of time or until the destruction code is activated. Another vulnerability in the app relating to the log-in status is that only when the user clicks the log-out icon does it ask the user for the passcode upon the next visit to the app. However, if the user closes the app but does not log-out, the app will still be opened the next time the user opens Nahoft. The Iranian government or any other adversary would be able to open Nahoft without entering a passcode and would be able to see the critical information sent between friends. To fix this vulnerability, there can be a time interval by which the app closes by itself if the user is not active. Nahoft could also automatically log-out every time it is closed. These vulnerabilities are critical as they give adversaries direct access to the encryption and decryption keys. The main purpose of pointing out these vulnerabilities as well as the one’s mentioned in the penetration tests is make Nahoft a safer space to communicate for Iranians.