4 ms·

The special feature of these "pseudo USSD" codes on Android is that you don't have to press the call button. Simply typing the digits is enough. Note I have no

The special feature of these "pseudo USSD" codes on Android is that you don't have to press the call button. Simply typing the digits is enough. Note I have no idea if this particular attack actually works.

deleted 14y ago
[deleted]
rplnt 14y ago
I don't think it's "android feautre", I've seen this on a few non-smart phones in the past. I don't know which one though as I owned few of them over the years.
- deleted 14y ago
  [deleted]
ajross 14y ago
This predates Android by years. Special "phone number" codes have been used to control firmware since the very first compute went into a phone. The reason is fairly clear: in the early devices, dialing a number was the only UI metaphor available. USSD itself is actually a standard, such as it is: http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data http://en.wikipedia.org/wiki/Unstructured_Supplementary_Serv... Now, of course, it's just a bit of legacy nonsense that gets left enabled simply because it's part of an existing workflow and serves mostly as a hidden gotcha for people doing security analysis.
- spauka 14y ago
  In this case, the USSD is not the bug. The fact that it can be triggered from HTML and cause a factory reset without user interaction is the bug. At least with older phones, after entry, it was necessary to hit dial before any effect was taken.
  - ajross 14y ago
    That's true, but sort of missing my point. Security bugs are very rarely "security bugs" in isolation. They're far more often unexpected interactions between subsystems. Here, the expectation of the browser is that it can fire a "phone number" Intent securely, because the dialer app will handle it. But the phone number intent also happens to hook to the USSD layer. It's not USSD's "fault", as the check needs to be in the browser according to the architecture. But USSD remains a booby trap because it's an unexpected legacy feature with surprising security behavior.

deleted 14y ago

[deleted]

rplnt 14y ago

I don't think it's "android feautre", I've seen this on a few non-smart phones in the past. I don't know which one though as I owned few of them over the years.

deleted 14y ago
[deleted]

ajross 14y ago

This predates Android by years. Special "phone number" codes have been used to control firmware since the very first compute went into a phone. The reason is fairly clear: in the early devices, dialing a number was the only UI metaphor available. USSD itself is actually a standard, such as it is: http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data http://en.wikipedia.org/wiki/Unstructured_Supplementary_Serv... Now, of course, it's just a bit of legacy nonsense that gets left enabled simply because it's part of an existing workflow and serves mostly as a hidden gotcha for people doing security analysis.

spauka 14y ago
In this case, the USSD is not the bug. The fact that it can be triggered from HTML and cause a factory reset without user interaction is the bug. At least with older phones, after entry, it was necessary to hit dial before any effect was taken.
- ajross 14y ago
  That's true, but sort of missing my point. Security bugs are very rarely "security bugs" in isolation. They're far more often unexpected interactions between subsystems. Here, the expectation of the browser is that it can fire a "phone number" Intent securely, because the dialer app will handle it. But the phone number intent also happens to hook to the USSD layer. It's not USSD's "fault", as the check needs to be in the browser according to the architecture. But USSD remains a booby trap because it's an unexpected legacy feature with surprising security behavior.