Converso, a relatively new privacy-focused messaging service, has withdrawn its application from both the Google and Apple app stores amid growing concerns over a significant security flaw.
Crnković, an independent blogger renowned for his deep interest in encryption protocols, uncovered the flaw while analyzing the Android version of the Converso app.
His analysis unearthed references to both AES (Advanced Encryption Standard) and RSA (Rivest-Shamir-Adleman) encryption algorithms, the mechanisms that form the backbone of Converso's promised secure communications. He also noticed an incorporated software development kit (SDK) from Seald, a well-regarded encryption and public key authentication provider.
The disturbing aspect of Crnković's findings, however, was an unsecured Google Cloud-hosted database the app communicated with. This database, alarmingly accessible to the public, held an array of sensitive information. Encrypted message contents, private encryption keys, message metadata, and even users' phone numbers were among the sensitive information left exposed.
Converso has taken swift measures to mitigate the fallout from these revelations. In addition to pulling its app from the Google and Apple stores, the company has scrubbed its website of any assertions that it offers end-to-end encryption.
“The vulnerability with Firebase rules have been patched and you are welcome to test it out,” the company responded to Crnković. “The other vulnerability of preset decryption keys has been implemented on our side, we are only waiting to get new credentials so that existing users will be reauthenticated. However, all existing messages sent with the old decryption keys are protected by firebase rules so they still cannot be read by outside parties.”
This discovery raises questions about the legitimacy of Converso's end-to-end encryption claims and the robustness of its overall security framework.
Properly implemented end-to-end encryption ensures that the sender and recipient can see the content of a message; in this scenario, the service provider itself shouldn’t be able to decrypt it. Yet, the presence of private encryption keys in the exposed database could allow any person with access to these keys to potentially decrypt the encrypted messages, violating user privacy.
tags
Vlad's love for technology and writing created rich soil for his interest in cybersecurity to sprout into a full-on passion. Before becoming a Security Analyst, he covered tech and security topics.
View all postsNovember 14, 2024
September 06, 2024