5.2 Call Lure
Alice is a customer of BobBank. Mallet is an attacker attempting to obtain Alice's access credential for the BobBank site by impersonating BobBank via the phone.
Mallet places an outbound call to Alice (and a hundres of other users). The phone number appears to be from a legitimate 800-number service. The voice service introduces itself as BobBank and alerts Alice that for fraud verification purposes, they need to ask her a series of questions. The call also says "For verification purposes, please enter your account number and numeric pin." For further verification, Mallet asks Alice to state her mother's maiden name. Finally, the system asks some non-identifying information such as "Is your checkbook in your possession?", "Please state the date of your last ATM transaction?", "Please enter the amount of your last ATM transaction?". The call concludes by saying "Thank you, your account appears to be in good standing at this time. Goodbye."
Mallet also provides an 800 number at the beginning of the transaction that can be used to call back when it is convenient. That 800 number is managed by Mallet and answers asking the same transactions.
Alice and BobBank both have assets at risk. Alice's personal information has been compromised and her account may also be compromised at this point. In addition to direct losses due to fraud BobBank may suffer indirect losses due to the need to reissue account numbers, pins, and checkbooks to Alice and increased customer service calls whether or not the attack is successful: Alice may insist on doing all her future transactions at a local branch at significantly higher cost to the bank. Alice may contact customer service to ask about the attack.
For additional references, see http://www.cknow.com/news/security/PhoneSpoofingAddedtoPhish.html
X.X Unique Characteristics of Voice Browsers
Differences
- Interaction with a voice browser is often entirely transparent to the end user. He or she has no idea whether the interaction is with a voice browser or any other automated phone application.
- Voice browsers typically have no standard chrome whatsoever. The entire user experience is defined by the application markup. There is some standard context information provided to the application markup (callerid, dialed number) which can be found in 5.1.4 of the VoiceXML 2.0 specification [1].
- Voice browsers have no URL bar. All content must be navigated to via hyperlinking. Bookmarking would be an application-specific feature and is not built into the browser metaphor.
- A highly interconnected voice web is technically feasible, but does not truly exist today. Applications live in their own space and do not contain links outside of their domain.
- For latency reasons, Voice browser deployments often make use of greater presentation markup caching and more separation of dynamic data and presentation data.
- Trust is typically established via the phone number the caller dialed. That said, there is no real reason you can trust the phone number. Trust would be established by the credibility of the source of the phone number (corporate website, phonebook, toll-free directory assistance.) Outbound calls are inherently less trustworthy.
- The search engines in this space are 411 services. 411 data is typically maintained by telcos thorugh their whitepages and yellowpages which usually involves a direct relationship with the business or individual. It is more difficult to publish yourself as a spoof address.
- The phone network tends to have more centralized control with substantially greater regulatory control and legal precedent. For instance, the national do-not-call list generally works where attempts to control email spam haven't.
- The costs of answering a spoofed 800# or placing malicious outbound calls are substantially higher than the cost of publishing a spoof website or generating an email.
Similarities
- Voice browsers run in a different trust zone than the web services and databases. Billions of calls a year are handled by voice browsers operated by one company on behalf of another company. These browsers interpret many different companies' voice applications. As a result a single voice browser may be able to access content and services that the application running on that voice browser is not allowed to access. As a consequence, all the same sandboxing requirements apply.
- Protecting user data and preventing cross-session data leaks is equally critical.
- Voice browsers make heavy use of Ecmascript.
- User authentication is still the responsibility of the web site and not the browser. Cookies are employed. Authentication techniques differ due to the inability to effectively recognize random a strings of letters, digits, caps, and punctuation that is typically found in a typed password. Biometric identification/authentication (voice prints) are more easily integrated into the user experience, though they are not widely deployed.
[1] VoiceXML 2.0 Standard Session Variables /TR/voicexml20/#dml5.1.4