First some background: on Friday August the 17th a researcher by the name of pod2g released details of an exploit that affects Apple iPhone. Namely, it is possible for a user to specify the Originating Address (phone number) that gets displayed by an iPhone when it receives a new SMS, allowing an attacker to spoof the sender of a message. He followed this up with a tool that allows a user to send modem (AT) commands from a jail-broken iPhone. How this spoofing actually works is through the use of a specific Information Element parameter in the upper layer UDH (UserDataHeader) of the SMS, called the Reply-Address field. The issue that pod2g identified is that an iPhone will display the Reply-Address as the sending address within the iPhone SMS client, and not show the real Originating Address.

However in some online discussions of this exploit there has been a range of debate on who is responsible, and the possible implications. Contrary to some comments, such as this article from Dark Reading here, this is not a network issue, this is a handset issue, and specifically an issue within the SMS client used by the iPhone handset. The GSM network is based on the 3GPP specifications, and in this case 3GPP 23.040, which clearly outlines the danger of using this parameter:

3GPP 23.040-530, Reply Address Element:

Despite the fact that MMI aspects of the ME are out of the scope of the present document, it must be mentioned that this mechanism might open the door to potential abuse. It is desirable that the user is made aware in some way that the reply address of the incoming message is different from the originator’s one, and that the user is presented with the original TP-OA address to identify the sender of the SM.

However for most devices the Reply-Address doesn't matter. Why? - we've tested this parameter on a range of Android, Windows Mobile, Blackberry and Symbian devices, and so far the vast majority simply ignore the Reply-Address or not display it - or if they do - like the BlackBerry version shown, they display both addresses, as the specification outlines. If this was indeed a network issue, then all devices, receiving the same message must be similarly affected, and they're not. Any device, be it the iPhone or some other device, that displays the Reply-Address is opening itself up to malicious use, as the Specification clearly outlines.

Screenshot of Blackberry displaying both Originating Number and Reply Address (Callback Number).

The next question is, what is the impact of this? For this question, we agree with many of the comments made by others, i.e. it only affects iPhone devices, unless other devices which also don't heed the warnings of the spec are identified, and opens them up to an increased chance of phishing attacks. Apple are aware of this issue, however if this reported statement by Engadget is correct, then they're going about mitigating the problems it presents in an unusual way, by using iMessage. Obviously iMessage is only supported on iPhones, and so does nothing to address SMS sent from non-iPhones with this parameter.

Incidentally the use of the Reply-Address is exceptionally rare in mobile networks now. It is not used due to the fact that it's not supported by many devices and the original scenario that it was addressing never really materialised - it is one of the many extended SMS function fields that didn't get much traction (see the original Change Request adding this here, 3GPP spec fans). This makes the identification and blocking of messages that contain this parameter by mobile operators easier to perform. Mobile Operators already perform this task in blocking other types of message which are spoofed at the signalling level or sent via less than reputable companies who provide access to these fields to bulk SMS senders. The question is though, should operators have to filter this parameter? If you care to read the Change Request, it clearly states that the reasoning for this Reply-Address is that:

3GPP 23.040-520, CR047 (3GPP TSG-T2#16 T2-020230):

it is desirable to set a return address different of the one used to send the SMS

This negates the argument made by online commentators, that the operator should be inspecting the Reply-Address, if they did what would they compare it against - if designed to be different from the sending address, how should it be validated? This is why the authors of the Change Request added in the proviso that it could be maliciously abused and both addresses should be displayed. So operators could filter and look for this parameter, but in this particular case, filtering of the Reply-Address parameter would be a secondary fix.

We work with operators every day to help them identify and remedy the threat posed by mobile malware, spam, and other security issues, but they shouldn't be blamed for this one.