It is amazing to see the number of bridged services that rely upon the source telephone address of an incoming call (supplied via caller-ID) or SMS message as a form of authentication. Maybe this made sense in the 90's when spoofing caller-ID was hard, and the most it would offer is accessing someone's voicemail without a PIN. But nowadays there are countless online services that allow SMS and caller-ID source spoofing (Spoofcard, Phonytext, etc). Pair this with the growing number of services offering telephony or SMS integration, and you start to have a problem.
Let's review some recent examples of this situation in action. Twitter was found to allow spoofed SMS messages to perform Twitter account actions/changes. The core problem was first identified nearly two years ago, but a recent variant allowed attackers to circumvent previously added safeguards. Twitter offers the option of using a PIN, but using a PIN impacts the ease of use and the overall user experience--so users do not jump at the opportunity to opt-in to this additional hurdle.
Google Voice has also had a fair amount of problems exposed, although some of the problems use different vulnerability vectors than the simple spoofed caller-ID/SMS. Spoofing caller-ID of a mobile phone configured for a Google Voice account allows an attacker to get into the Google Voice IVR system for that account and modify certain settings. Google has since closed these holes.
While we are talking about hacking telephone/SMS-related services, it is probably worth mentioning an XSS bug found on Skype's website. The attacker can try the usual bag of tricks to get a user to click on an XSS-ified link and gain access to the Skype session cookie. Fortunately, it seems Skype session cookies expire after thirty minutes...making the window of exploit opportunity it bit more difficult for an attacker to hit.
Overall, it is important for companies looking to add SMS/telephony bridged capabilities to their existing services to understand that caller-ID and SMS source information is not reliable for authentication purposes. Period. It is no different than asking a user for their username without the additional authentication aspect of a password; it creates an "on your honor" system which is ripe for abuse.
Until next time,