December 3, 2012

Update: Twitter has fixed the issue for users of short codes. Users that use a “long code” should enable the PIN code in their account.

Twitter users with SMS enabled are vulnerable to an attack that allows anyone to post to their account. The attacker only needs knowledge of the mobile number associated with a target’s Twitter account. Messages can then be sent to Twitter with the source number spoofed.

Like email, the originating address of a SMS cannot be trusted. Many SMS gateways allow the originating address of a message to be set to an arbitrary identifier, including someone else’s number.

Facebook and Venmo were also vulnerable to the same spoofing attack, but the issues were resolved after disclosing to their respective security teams.

Scope

Users

Users of Twitter that have a mobile number associated with their account and have not set a PIN code are vulnerable. All of the Twitter SMS commands can be used by an attacker, including the ability to post tweets and modify profile info.

Service Providers

All services that trust the originating address of SMS messages implicitly and are not using a short code are vulnerable.

Mitigation

Users

Until Twitter removes the ability to post via non-short code numbers, users should enable PIN codes (if available in their region) or disable the mobile text messaging feature.

Twitter has a PIN code feature that requires every message to be prepended with a four-digit alphanumeric code. This feature mitigates the issue, but is not available to users inside the United States.

Service Providers

The cleanest solution for providers is to use only an SMS short code to receive incoming messages. In most cases, messages to short codes do not leave the carrier network and can only be sent by subscribers. This removes the ease of spoofing via SMS gateways.

An alternative, less user-friendly but more secure solution is to require a challenge-response for every message. After receiving an SMS, the service would reply with a short alphanumeric string that needs to be repeated back before the message is processed.

Disclosure Timelines

Twitter

The issue I filed was initially inspected by a member of their security team, but was then routed to the normal support team who did not believe that SMS spoofing was possible. I then reached out directly to someone on the security team who said that it was an “old issue” but that they did not want me to publish until they got “a fix in place”. I received no further communication from Twitter.

17 Aug 2012 I notified Twitter about the vulnerability via their web form. 20 Aug 2012 Twitter Security routed my report to their mobile support team. 6 Sep 2012 Twitter asked me not to publish until they have fixed the issue. 15 Oct 2012 I requested an update on the issue, and receive no response. 28 Nov 2012 I notified Twitter that I would publicly disclose this issue. 4 Dec 2012 I received confirmation that the issue has been resolved.

Facebook

Initially Facebook did not respond to my report on their security vulnerability page. I then emailed a friend who works at Facebook, who facilitated my contact with their security team.

19 Aug 2012 I notified Facebook about the vulnerability via their web form. 6 Sep 2012 I received a response after getting a friend on the engineering team to bump the issue internally. 28 Nov 2012 I received confirmation that the issue had been resolved.

Disclosure: I will receive a bounty from Facebook for finding and reporting this issue to them. The Facebook bounty program requires responsible disclosure and time to resolve internally in “good faith” before publishing.

Venmo

I initially disclosed this issue to Venmo support, as they do not have a security contact published. When I did not receive a response, I notified the Braintree security team (Braintree recently acquired Venmo), who responded very promptly.