0day уязвимость в приложениях для iOS: Gmail, Google+ и FB Messenger

[@Speakus]

Ну… Компания Apple не виновата.

Нет, ну, а почему бы не сделать обработку tel как у всех? Есть еще и сторонние браезеры, кроме safari. Что-то мне сомнительно отсутствие вины Apple в данном случае…

[@xjukebox]

Здесь, скорее, оплошность разработчиков приложений, которые не обрабатывают tel ссылки.

[@Speakus]

Имхо это называется перекладывать с больной головы на здоровую. Если нужно было какому-то приложению разрешить делать звонок без подтверждения нужно было сделать флажок в Info.plist — т.о. разработчик выставив такой флажок явно бы указал, что он в курсе, что теперь схема tel будет обрабатываться без подтверждения (нестандартно).

[@Adnako]

Формально Apple, конечно же, подстраховалась, видимо в надежде, что её любимые пользователи будут клясть фейсбуки и гмэйлы.
Но зная Apple, вот такая отмазка совершенно не укладывается в их «заботу о пользователях».
Что мешало добавить метод делегата, например, -(BOOL)showDefaultTelAlert:, возвращающий по дефолту Yes, который любой разработчик при желании сможет переопределить и реализовать собственное поведение, а для ленивых будет вылетать стандартный алерт?

[@xjukebox]

Вообще верно сказано. По дефолту запилить алерты на все tel ссылки и все счастливы.

[@Goodkat]

Лучше при первом вызове показывать алёрт: «Приложение блабла желает иметь доступ к телефону. Запретить? Разрешить один раз? Разрешать всегда?», как это сделано с доступом к гео-данным, контактам, камере и т.п.
И все будут счастливы.

[@Psionic]

В принципе не исключено что злоумышленнику в своем зловредном приложении можно перехватить UIAlertView и сделать выбор за пользователя.

[@y0man]

Одной ночью я просто читал документацию о ссылках tel

Только на хабре можно встретить такой подход к отдыху.

P.S. Вот за что я люблю IT сообщество!

[@Nerten]

Это перевод, поэтому не только на хабре :)

[@y0man]

Не заметил перевод. Ну и хорошо, что не только!
Движемся в нужном направлении. =)

[@121212121]

Ага, только не очень внимательно читал. По указанной ссылке на tools.ietf.org/html/rfc3966 мы видим пример:
<a href="tel:[phone]">[phone]</a>
Найдите разницу, что называется.

[@iMaster]

На платных номерах перед соединением идёт начитка об услуге и тарификации. Случайный дозвон со снятием средств вряд-ли возможен.

[@Vilgelm]

Я не знаком с iOS, но разве эта уязвимость не будет работать с USSD? Там возможно моментально списание средств.

[@Pr0Ger]

Нет,

To prevent users from maliciously redirecting phone calls or changing the behavior of a phone or account, the Phone app supports most, but not all, of the special characters in the tel scheme. Specifically, if a URL contains the * or # characters, the Phone app does not attempt to dial the corresponding phone number.

[@PapaBubaDiop]

Боюсь спросить про

<a href="sms:[phone]">Send SMS to us </a>

Если такая же дыра, то прошу шоколадку от смс-агрегаторов.

[@xjukebox]

Максимум, что может сделать ссылка sms: — открыть приложение, отвечающее за отправку смс с номером телефона.
Даже сообщение указать нельзя.

Здесь больше информации

[@xjukebox]

Хотя нет, можно использовать ссылку вида

<a href="sms:[phone];body=Привет, как дела?">Кликни</a>

[@Kolyanu4]

в iPhone (IOS 7) не подставляет body, если нет истории переписки. Ну а по ссылке, которую Вы предоставили, написано что не должно содержать текст или другую информации (или я предложение не правильно понимаю :)).

The sms scheme is used to launch the Messages app. The format for URLs of this type is “sms:”, where is an optional parameter that specifies the target phone number of the SMS message. This parameter can contain the digits 0 through 9 and the plus (+), hyphen (-), and period (.) characters. The URL string must not include any message text or other information.

[@xjukebox]

Не должно, но текст подставляется, как Вы сказали ранее, если есть история переписки.

[@yarbabin]

twitter.com/i_bo0om/status/491783079912951809
Просто оставлю это здесь.

[@xjukebox]

Все-таки отчасти — это вина Apple. Именно компания, предоставляющая среду для разработки приложений должна следить за всеми возможными вариантами выйти за рамки безопасности.

[@Kentzo]

tel:// это далеко не самая «advanced» фича. Разработчики о ней знают.
Скорее это прекрасный пример отвратительного QA и низкоквалифицированной разработки конкретного продукта.

[@xjukebox]

Еще можно использовать iFrame.

[@Starche]

Автор, у вас классный перевод, раз в комментариях многие даже не заметили, что это не собственное исследование. Да и сам я тоже только дочитав до комментариев увидел, что статья переводная.
А по делу. Не подскажете, USSD отправляется таким образом? Я к сожалению без устройства, сам поглядеть не могу, но интересно.

[@xjukebox]

Спасибо!

Что касается USSD — еще в далеком 2012 году была уязвимость. Сейчас, к сожалению, все залатали.

[@Ajex]

К чьему сожалению? ;) Может к счастью )))). И без USSD, подобным можно создать кучу проблем.
Кстати, а что на других платформах, кто-нибудь проверял?

[@xjukebox]

Извините, «по Фрейду» ошибочка вышла. :)

Что касается других платформ — на андроиде не работает, симбиан тоже. Остальные еще предстоит тестировать.

[@svosin]

На android что-то похожее было. Вроде можно было вайпнуть телефон такой ссылкой. Кстати, надо попробовать сервис-коды, хотя бы тот же *#06#.

[@Vilgelm]

Была уязвимость в фирменной оболочке Samsung еще на 2.x версиях, лечилось установкой альтернативного лаунчера.

[@alexglue]

Вот этот пост вы, видимо, имели ввиду.

[@bevice]

На минуточку, это не только у iOS такое поведение, но и у всея OSX — только что попоробовал: например VK Messager (при включенной настройке «открывать внешние ссылки в программе») при клике очень даже пытается позвонить через любой устанновленный VoIP (например Skype, Zoipper). Правда скайп звонить отказывается — но это лишь потому, что разработчики плевать хотели на пользователей — как обработчик tel:// скайп зарегистрировался, а вот обрабатывать не хочет

[@xiWera]

Возможно я что-то не понимаю, а зеродей то в чем состоит?
Телефон превращается в кирпич? Он рутуется? На него ставится троян? Пользователь не может прервать звонок?

[@xjukebox]

Скажите, а у вас какое-то свое определение 0day уязвимостей?

Вот вам кусочек википедии:

0day (англ. zero day) — термин, обозначающий вредоносные программы, против которых еще не разработаны защитные механизмы или уязвимости, которые не устранены.

[@xiWera]

Яж написал «возможно я что-то не понимаю»…

хотя на википедии, чуть дальше в этой статье написано:
«После обнаружения уязвимости в программном обеспечении начинается процесс разработки вредоносного кода, использующего обнаруженную уязвимость для заражения отдельных компьютеров или компьютерных сетей.»

А в той цитате, что привели Вы, указан термин «вредоносные программы». Гуглплюс, гмэйл, фейсбукмесенджер трудно считать вредоносными программами. Ситуация повторяет попап окна десятилетней давности. А ведь никто тогда это не считал зеродеем, хотя инет тогда зачастую был небезлимитным

[@xjukebox]

Понимаете-ли, тут трактовать по разному можно.
Заражением можно считать возможность выполнения сторонним софтом (давайте считать html страницу — софтом) каких-либо операций (вызова необходимого номера телефона) на устройстве.

[@xiWera]

То есть, в общем случае, посещение произвольной html страницы, с возможностью её не посещать, является заражением?

[@AMDev]

Если использовать вызов из нативного кода, то звонить будет без предупреждения и диалога:

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:
@"tel:[phone]"]];

А если, как в вашем примере из html:

<a href=”tel:[phone]″>1-555-555-5555</a>

То будет диалог:


Дело тут в том, что установленные приложения проходят ревью и подозрительные вызовы из нативного кода отслеживаются на этапе проверки приложения перед публикацией в applestore.
А вот пройти ревью с такими вызовами в коде это, скорее всего не просто.
Так что, я думаю это просто так задумано (WAD — work as designed)

В перечисленных вами приложениях в нативные вызовы подставляется внешний url, что, на мой взгляд, является недоработкой разработчиков приложений.

Другие примеры вызовов приложений (sms, maps, youtube) можно посмотреть, например, тут

[@121212121]

Да не, в его примере ошибка, там еще два слеша присутствуют.

[@xjukebox]

Работает и со слешами и без слешей.

[@Drag116]

Для набора телефона с предварительным диалоговым окном, есть адрес telprompt://
Для набора без диалогового окна tel://
Как спроектировано так и работает, никаких уязвимостей.

[@xjukebox]

«Это не баг — это фича»

[@Speakus]

если что-то работает как спроектировано, то уязвимость еще может быть следствием плохого проектирования ;)