Search the Community
Showing results for tags 'encrypted'.
Found 4 results
The mobile encryption app NQ Vault has been in the news for bad reasons. Mobile encryption apps are commonly used to prevent access to sensitive data on the phone (such as images, videos, documents and so on). These encryption apps usually offer a vault with your desired password. You can push any secret files to this vault and they would be secure, as the data present in vault is encrypted and would decrypt only when the correct password is entered. The NQ Vault app is one such mobile encryption app which boasted that it “encrypts” and secures your confidential files. All this has now become a joke and we will see why! NQ Vault allows you to pick a private passcode and “encrypts” pictures, texts, and any other data from the eyes of anyone who happens to look through your phone or device. For instance, an attacker who has access to the device should not be able to view the original files unless he knows the passcode. The idea is that even if an attacker pulls these files from the device, since they are encrypted, they would mean nothing but junk. But in case of NQ Vault, it turned out that if an attacker pulls these encrypted files, he could easily get the original files in a matter of seconds. It’s not about weak encryption The point is that NQ Vault doesn’t use any encryption algorithm to secure the user’s data. It just uses XOR substitution. So we are not talking about using a weak algorithm or a weak key. We are talking about having “no algorithm”. As discovered by blogger NinjaDoge24, NQ Vault just XORs the user’s file with a key and calls it “encrypted”. Breaking it step by step I tried to verify this practically, and here is how easy it turned out to be: Download and install the NQ Vault mobile app from Google Play Store on any Android device. Set your desired passcode (say 000). Select any secret file (for example apple.png). Here is the HEX representation of the apple.png file: Note: HEX is a positional numeral system base of 16. It uses sixteen distinct symbols, most often the symbols 0–9 to represent values zero to nine, and to represent values ten to fifteen. You can use HEX Viewer tool to view an image’s hex representation. 3. Now send the image to the NQ Vault using the app. This would mean the file apple.png is encrypted and should have been stored somewhere on the device. This is the message shown by NQ Vault: 4. These so called “encrypted” files are stored on the SD card at the location /mnt/sdcard/SystemAndroid/Data. How do I know this? Well just by looking at SQLite files in this case. Also at the above mentioned location, there is a text file saved by the app which says: 5. But these encrypted files are hidden from the user. So initially a simple ‘ls’ on the folder does not reveal anything. But ‘ls’ with –a attribute would reveal all the hidden files, as shown in the following screenshot. 6. The next thing is to pull out this encrypted file to the local machine. I used the adb pull command for this purpose. As seen below, the file is stored with a .bin extension. 7. Now see the HEX representation of this encrypted file: 8. Now just XOR abc.png & the encrypted file:\ 9. What this suggests is, based on the passcode selected by the user, it generates a “key” (30 in this case) and just XORs the user’s file with this key! Upon investigation, it turned out that this key value is always between 00 and ff, which means 255 possible values. As explained by NinjaDoge24, here are some of the passcodes and their corresponding key values: Thus, an attacker who has access to the encrypted files just need to brute force XOR with 255 possible values to get the original files back! It’s not over! The story is not over yet. It is also discovered that the app performs this worthless encryption only for the first 128 bits of the user’s file, and stores the rest in plain format. So it’s all out there in the raw for the attacker to see. For example, in the above example, notice that only the first 128 bits are XOR-ed, and rest of the bits remain the same. The below screenshot gives a clear idea: Notice that only the initial bits are transformed, while the rest of the file remains the same. Here is a simple script written by NinjaDoge24 that automates this whole process. Lessons learned Everyone makes mistakes, including reputed organizations such as Facebook, Google etc., and we all understand that. But this is just asking to be punished. All those millions of users who believed the claims of this software and unknowingly rated it at 4.6 will now feel cheated. The fact that CNET, PC Magazine and many other site reviews rated it highly points out another problem – it’s hard to trust the claims of an app just by looking at what it does. It is definitely not possible for review sites to perform a security audit of an app before they rate it. Companies need to realize the importance of the trust that users have in their brand and also need to remember that once lost, it’s very hard to gain it back. Source
cryptmount is a utility for GNU/Linux operating systems which allows an ordinary user to mount an encrypted filing system without requiring superuser privileges. It is aimed at recent Linux systems using the 2.6 kernel series. There are currently two main approaches to using encrypted filesystems within the linux kernel: the cryptoloop device driver; the device-mapper system, using the dm-crypt target. The (older) cryptoloop system has grown in parallel with the loopback device-driver of 2.4 kernel series, but has now been superseded by the device-mapper capabilities of the 2.6 kernel series. The newer devmapper system offers a cleaner organization of encryption and device-access, and superior performance has been noted. Alternative user-space tools which allow individual files to be encrypted are also widely available, but allow some information about file sizes & organization to be exposed. With the older cryptoloop system, it was possible to describe all the details of an encrypted filesystem within /etc/fstab so that it could be configured completely by 'mount'. This meant that it was particularly easy to give any user permission to mount those encrypted filesystems simply by providing the 'user' option within /etc/fstab. With the newer device-mapper infrastructure, there are more stages involved in mounting an encrypted filing system, and neither does 'mount' currently allow this nor does the syntax of /etc/fstab lend itself to describing all the necessary filesystem parameters. This is especially so if the filesystem is stored in an ordinary file, which would require separate configuration of a loopback device and a devmapper target before the filesystem could be accessed. cryptmount was written to make it as easy for ordinary users to access encrypted filesystems on-demand using the newer devmapper mechansism as it was to use the older, now deprecated, cryptoloop methods. This offers the following advantages: access to improved functionality in the kernel transparent support for filesystems stored on either raw disk partitions or loopback files separate encryption of filesystem access keys, allowing access passwords to be changed without re-encrypting the entire filesystem storing multiple encrypted filesystems within a single disk partition, using a designated subset of blocks for each rarely used filesystems do not need to be mounted at system startup un-mounting of each filesystem is locked so that this can only be performed by the user that mounted it, or the superuser encrypted filesystems compatible with cryptsetup encrypted access-keys can be chosen to be compatible with openssl, or managed via libgcrypt, or (for 2.0 release-series) built-in SHA1/Blowfish ciphers support for encrypted swap partitions (superuser only) support for setting up encrypted filesystems or crypto-swap at system boot-up Link: cryptmount.sourceforge.net
The sanctity of Apple iMessage end-to-end encryption has been challenged by white hats who in 2013 reverse engineered the protocol behind it, revealing that Apple controls the key infrastructure and could, in turn, be compelled to turn over messages via government order. CEO Tim Cook denied those charges last September in an interview, but nonetheless, confidence in the security of messages sent over iMessage hasn’t been 100 percent since. Researcher Moxie Marlinspike’s Open WhisperSystems today released version 2.0 of the free Signal app for Apple iOS, which now adds end-to-end encrypted messaging to the encrypted voice calling introduced last July with Signal 1.0. The private messaging support for iPhone is free and open source—and not the last step for Marlinspike, who is also responsible for RedPhone, an app that encrypts calls on the Android platform, and TextSecure for Android, a private text and chat app that is at the heart of today’s Signal 2.0 release for the iPhone. “We’re going to unify TextSecure and RedPhone into Signal on Android, release a desktop version of Signal, and keep working to push the envelope of secure protocols and private communication,” Marlinspike said of his planned product road map. For now, the availability of Signal 2.0 for iOS brings a measure of privacy and secure communication that’s been in question since the QuarksLab report of 2013. “It’s technically possible that someone in control of Apple’s servers could intercept your communication,” Marlinspike said, adding that Signal 2.0 now allows iPhone users to communicate privately with users on the Android platform. The protocol behind Signal 2.0 also supports forward secrecy, which essentially generates a new encryption key for each message, meaning that if a key were cracked in the future, not all messages would be in danger. Signal 2.0, Marlinspike also said, allows users to verify each other’s respective encryption keys, meaning that it would be an easy detect if an attacker was sitting in a man-in-the-middle position intercepting traffic between endpoints. For now, both ends of a conversation require Signal to be installed in order to assure secure communication, Marlinspike said. The simplicity of Signal should remove any impediment for privacy conscious users. The app uses the phone’s existing phone number and address book and does not require a separate log-in or authentication mechanism to manage. Users are able to send encrypted group messages (text, video, photos) and make encrypted phone calls worldwide without extra charges, Marlinspike said. “We cannot hear your conversations or see your messages, and no one else can either. No exceptions. You can even tap and hold on a contact’s name to see advanced identity verification options,” says Signal 2.0’s product description. “Everything in Signal is always end-to-end encrypted and painstakingly engineered in order to keep your communication safe.” The source code is available on Github for inspection, as well, Marlinspike said. Source