Whisper is an anonymous messaging app with over 10 million users. The author found 5 major security vulnerabilities in Whisper's Android app, including the ability to obtain a user's unique ID through insecure network requests and stored data. Whisper denied the issues but silently patched them. This violated ethics codes around taking responsibility for errors, disclosing risks to users, and fully understanding their own software and systems.

1.
Ben Reichert
June 1st, 2015
“Here your secrets are safe”
A case study of Whisper.sh
Whisper is an anonymous messaging application used by over ten million people daily.
They use it to post secrets about themselves in an ‘anonymous’ environment. Other people can
then interact with those secrets by commenting on them, as well as directly messaging the
original poster. Whispers are shared as general content, or with relation to user location. This
paper will discuss the flaws in the Android application and response from Whisper. Whisper
violated the ACM Code of Ethics on multiple accounts in relation to application security, public
relations, and privacy concerns.
When the Whisper application is installed and then opened on an Android device there is
a seamless transition right into the Whisper ecosystem. The user is not prompted for a username
or password, but instead is automatically assigned a username and given a unique user identifier.
The Whisper application for Android features 3 major screens. The first is general whispers
global to all users. The second is a location­specific view for whispers near the user. The third is
the private messaging view where users can send private messages to each other.
There were 5 major vulnerabilities found in the Whisper Android application. At the time
of finding these vulnerabilities I was employed by Xipiter, a Portland­based information security
firm. First, we need to discuss the architecture of Whisper’s web services to understand the
nature of these vulnerabilities. As previously mentioned, the user is assigned a unique 38
character uid (ex: 050f036278f1ae9651664cf6e7151a3e3ada0d). This uid is the sole
authentication for the Whisper application. It is used as both the username and password.

2. 2
Further, the Whisper web API does not use any additional authentication such as tokens,
sessions, or cookies. An example request to their service would look like this:
https://prod.whisper.sh/messaging/conversations/tt_auth?uid=050f036278f1ae9651664cf6e7151
a3e3ada0d. Whisper uses a service called TigerText.me (a previous venture of Whisper
co­founder Andrew Brooks) to handle user­to­user private messages. As we can see, if an
attacker was to obtain a uid of an individual, they would have just as much control over the
account as the rightful owner.
The first vulnerability found in the Whisper application involves forcing the application
to leak the uid in a third­party network request. The https request is forced to use http instead,
and then the uid is logged as it travels on the network. The third party service is Mixpanel and is
presumably used for matching and suggestions. SSL/TLS encrypted http connections use port
443, and unencrypted http connections use port 80 server­side. If an attacker can drop all traffic
to port 443, then the Mixpanel code decides that it cannot communicate over SSL and resorts to
plain­text http instead. This would not be much of a problem, except that Whisper is passing the
uid as a url parameter to Mixpanel. This attack can be referred to as a SSL downgrade attack as it
restricts secure network communication and forces the application to use insecure methods of
communication. The request can be seen as follows:
http://decide.mixpanel.com/decide?version=1&lib=android&token=c39eea2c9ad72a79d1688ca8
2c50cb94&distinct_id=050f036278f1ae9651664cf637161a3e3ada0d where the distinct_id is in
fact the user’s uid.
The second and third vulnerability involved insecure network communications due to
incorrect application code. When a Whisper user shared any content to other applications a

3. 3
service was used to provide a shortened url. Of course, in this url the uid is passed in as a
parameter. It is unclear why this is needed in the first place. What makes this worse is that the
original source code of the application was written to use plain­text http only. Therefore we have
one more way to obtain a user’s uid. The third vulnerability was very similar in nature to the
second, only in a separate part of the application.
The fourth vulnerability was discovered when the application was uninstalled and then
reinstalled. Due to the architecture of Android, all configuration and user data is deleted when
the application is uninstalled. When the application was reinstalled, I noticed that I was brought
back to the original user account created. The only way this could occur was to store data in a
global space, such as sd card storage. Once data is written to the sd card, any other application
can access it without restrictions. Google’s Android documentation explicitly states that under no
circumstances should sensitive data be stored on external storage (Android Storage Options,
2015). When looking on the phone sd card in the /sdcard/whisper directory there was a file called
‘wuid’ with the contents being the user’s uid in plain­text.
The fifth and final vulnerability is different from the rest, and easily the most complicated
to exploit. Whisper states that once a message is sent, it is never stored on any server and cannot
be retrieved again (Bort, 2015). This is a false statement and the following vulnerability will
prove that this is not the case. I mentioned earlier that Whisper uses TigerText for private
messaging between users. This vulnerability exists due to the API interactions between Whisper
and TigerText. This vulnerability was demonstrated with roughly 200 lines of proof­of­concept
Python code, using over eight different api methods across Whisper and TigerText services.
Since this is by far the most technical exploit, I will abstract away the gritty details. When two

4. 4
users initiate a private chat, Whisper creates a TigerText “group”. Both users are then added to
the group with the illusion of one­to­one chat. The architecture of TigerText allows as many
users to join a chat as wanted. Further, if we could add an attacker account to the group we could
see the private messages as they were sent. An incorrect TigerText server configuration set a
‘replay_history’ boolean to True, when it defaults to False. This allows any member that is added
to a group to retrieve past messages for the entire conversation. Therefore, a malicious user can
be added to a group and retrieve past messages given a user’s uid.
Something to note about these vulnerabilities in regards to uid generation: once a uid is
generated it cannot be reset. This means that once a Whisper account uid is leaked that account
can be considered permanently compromised. This is due to the fact that Whisper has no way to
reset a password, and therefore must throw away the entire account once compromised. While
we just detailed the specific technical details, let us now pivot towards ethics in regards to
remediation, public relations and privacy concerns.
When these vulnerabilities were discovered in the Android application, Whisper was
contacted and notified of the existence of such bugs. Their response was complete denial. Three
days later an updated version of the Android application hit the Google Play store with the
changelog of “bug fixes”. I reversed­engineered the application and discovered that they fixed
every bug mentioned in the initial bug report. This brings us to the first ACM Code of Ethics
violation: ​6.08. Take responsibility for detecting, correcting, and reporting errors in software
and associated documents on which they work ​(ACM, 2015)​. ​Whisper did not claim
responsibility for the vulnerabilities that their service included and silently patched their
software. With this, also releasing the patched Android application without notifying the user

5. 5
base that there was severe vulnerabilities placed them at risk. This is a violation of the following
ACM Code: ​1.04. Disclose to appropriate persons or authorities any actual or potential danger
to the user, the public, or the environment, that they reasonably believe to be associated with
software or related documents ​(​ACM, 2015)​.
The second ACM Code of Ethics violation is in regards to public statements. After a long
process of back­and­forth communication between Xipiter and Whisper, Business Insider picked
up the story and wrote an article. When asked about prior message retrieval, “​Whisper's
co­founder Michael Heyward and its CTO Chad DePue talked to Business Insider and told us it
is simply not possible to do such things with its app” (Bort, 2015). Xipiter published a video of
the prior message retrieval exploit showing two phones messaging each other with an attacker
listening in on every conversation (Vimeo, 2015). Whisper’s public response to this was thus
“Heyward claims the video and other claims are "ridiculous," "bizarre" and "doctored."” The
ACM Code of Ethics ​1.06. Be fair and avoid deception in all statements, particularly public
ones, concerning software or related documents, methods and tools ​summarizes this situation
well (ACM, 2015). As previously written and demonstrated there are obvious security holes in
Whisper’s application. Also, they denied all bugs in their software, yet invited Xipiter to join
their bug bounty program.
I would like to stress that these vulnerabilities were found by myself over a weekend.
After those few short days of analysis, I seemed to know more about Whisper’s api calls and
system than they did. Imagine what a determined individual or team could do if they spent more
time looking at an application like Whisper. This brings us to the ACM Code of Ethics violation:
3.07. Strive to fully understand the specifications for software on which they work ​(ACM, 2015).

6. 6
There is a difference between requirements documentation and how software works in the real
world. In this instance, Whisper was shown that they did not understand the capabilities and
repercussions of their software.
During analysis of the network traffic the application sent, I noticed that there was a lot
of data being sent to third party services. Data such as when the app was opened, what the user
tapped, and viewed content were all logged and then periodically send to a remote server. One
specific instance was data being sent to MobileAppTracking.com. The problem with this data
was that neither Xipiter nor Whisper could decode the sent data. When I went looking through
the Java source code of the application (obtained through reverse engineering) I noticed the code
for generating this data. The send data could include, but is not limited to, email address,
facebook account, gender, location, etc. An ‘anonymous’ application should not be collecting
identifiable information; that defeats the whole purpose of anonymity. Whisper’s privacy policy
is quick to point out that they do not collect personally identifying information (Whisper, 2015).
Everything I’ve stated so far is in support that there was obvious negligence on Whisper’s
behalf. What if they never intended to create a system so vulnerable to account takeover? Their
intention for the single uid is to create a streamlined process so the user is not hassled by login
credentials. An engineer could have simply forgot to include the s in https in the second and third
vulnerability; which is an easy oversight. An engineer could have left the replay_history set to
True for debugging and simply forgot to turn it off. Someone working with the mixpanel api may
not have known that it would be susceptible to SSL downgrade attacks. To keep with the
streamlined process, an engineer could have chosen to write the uid to the sd card so the user
never loses their account. With all of these cases, the intention may have been well, but the

7. 7
implementation was askew. When a security firm states a list of problems with their service of
course they are going to try to patch everything they can without publicly showing application
flaws.
If the first thing an ‘anonymous’ application asks for is the Identity permission, there is
probably something wrong with calling it ‘anonymous’. Other researchers will not be able to
verify the vulnerabilities stated above as Whisper has fixed them. Ultimately it is up to the
individual to stack the evidence presented above, as well as the previous news articles about
Whisper privacy concerns to make a decision whether or not to use Whisper.

8. 8
References:
Android Storage Options. (n.d.). Retrieved June 2, 2015, from
http://developer.android.com/guide/topics/data/data­storage.html
ACM Software Engineering Code of Ethics. (n.d.). Retrieved June 2, 2015, from
https://www.acm.org/about/se­code
Bort, J. (2015, March 23). Inside the 'bizarre' public fight anonymous app Whisper is having with
a security startup. Retrieved June 2, 2015, from
http://www.businessinsider.com/whisper­app­fights­with­security­startup­xipiter­201
5­3
Whisper Privacy Policy. (n.d.). Retrieved June 2, 2015, from https://whisper.sh/privacy
Vimeo ­ Whisper private message "exploit" (NO AUDIO). (n.d.). Retrieved June 2, 2015, from
https://vimeo.com/122701126