Информационная безопасность
0,0
рейтинг
2 сентября 2014 в 12:11

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

image

Интро


Нормальные люди проводят ночи смотря фильмы, читая статьи, общаясь в социальных сетях или (да, я знаю — это странно) засыпая на кровати.
Я же провожу свои ночи читая документации и тестируя самые разнообразные приложения и сервисы.
Одной ночью я просто читал документацию о ссылках tel, так как я был в восторге от старых технологий, которые использовались до сих пор, их недостатков и того, что люди никогда не читали RFC, что и приводит их к RTFM PWNAGE (как я привык это называть).

Нужно пробовать


Как только я закончил читать документацию по tel — я посмотрел на свой iPhone и сказал: Круто, нужно пробовать! Я накодил маленькую HTML страницу и загрузил ее в Safari, вот код:
image
Как только я кликнул по ссылке — тут-же появилось диалоговое окно, которое спрашивало действительно ли я хочу позвонить по телефону 0000.

Apple


На данном этапе была только моя заинтересованность в ссылках tel, я не искал уязвимость. Но тут меня озарило: Apple очень сильно любит менять что-либо и делать вещи лучше, так может быть у Apple есть своя документация по TEL? И я был прав

Строка, в которую я влюбился


Документация Apple по ссылке tel очень короткая и легка к прочтению. Читая первый параграф, кое-что привлекло мое внимание:

Когда пользователь тапает по ссылке tel на странице, iOS показывает алерт, который спрашивает действительно ли пользователь хочет набрать номер телефона и инициализирует набор, если пользователь жмет по «Согласен». Когда пользователь открывает URL со ссылкой tel через установленное приложение, iOS не показывает алерт и инициализирует звонок без последующего подтверждения пользователем.

Оригинал
When a user taps a telephone link in a webpage, iOS displays an alert asking if the user really wants to dial the phone number and initiates dialing if the user accepts. When a user opens a URL with the tel scheme in a native app, iOS does not display an alert and initiates dialing without further prompting the user.



Поэтому если я кликну по ссылке в Safari — я получу окошко, которое будет спрашивать у меня действительно ли я хочу позвонить, но если я кликну по ссылке в webView установленного приложения — вызов начнется без моего подтверждения.

Читают ли люди документации?


Нет. И это печально

После прочитанного меня терзали сомнения относительно таких «больших игроков» как Facebook, Twitter, Google, LinkedIn и так далее. Я думал, что такие «гиганты» могли бы позаботиться о подобной мелкой «дыре», но, как оказалось, я был не прав.

Тестируем на приложении Facebook Messenger


Я отправил ссылку на страницу через Facebook Messenger, кликнул по ней, чтобы попасть через webView на созданную ранее страницу (социальные приложения не хотят, чтобы вы покидали приложение и именно поэтому такие приложения используют webView), а потом кликнул по ссылке «click me»:

Клик по ссылке инициирует звонок. Погодите-ка… это не очень хорошо.

Делаем ссылку самокликающейся


Множество людей считают, что такие вещи, как ссылки могут быть нажаты только пользователем. Как бы да не так! Используя хитрый, но простой до ужаса javascript скрипт, я сделал ссылку «самокликающейся».
image

Смотрите что происходит
image


Заметка: вы так-же можете делать редирект на стороне сервера, перекидывая пользователя по tel ссылке используя header(«Location: tel://0000»)

Можно ли считать это проблемой безопасности?


Я могу заставить вас набрать любой номер телефона единственным кликом по ссылке в любом приложении, в котором не отрегулирован процесс обработки tel ссылок. Поэтому да, это проблема безопасности.

Только представьте — я зарегистрировал платный номер телефона и отправил вам ссылку в Facebook Messenger или Twitter. Вы нажали и позвонили мне, я поднял трубку, чтобы снять с вашего счета немного денег.

Это не правильно! Кто же виноват?


Ну… Компания Apple не виновата. Люди вообще не читают документацию. Первый параграф по ссылке tel все до мельчайших подробностей расписывает — что, когда и как происходит, а также четко формулирует, что как бы то ни было установленные приложения могут быть настроены показывать свои собственные алерты.

Кто же не RTFM?


Facebook Messenger
image


Gmail
image


Google+
image


А теперь для всех…

Будьте осторожны


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

Примечание автора: Кстати, все тоже самое отлично проделывается и с iFrame.
Перевод: Neculaesei Andrei
Alex Novak @xjukebox
карма
24,5
рейтинг 0,0
Информационная безопасность
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (44)

  • +32
    Ну… Компания Apple не виновата.
    Нет, ну, а почему бы не сделать обработку tel как у всех? Есть еще и сторонние браезеры, кроме safari. Что-то мне сомнительно отсутствие вины Apple в данном случае…
    • –28
      Здесь, скорее, оплошность разработчиков приложений, которые не обрабатывают tel ссылки.
      • +16
        Имхо это называется перекладывать с больной головы на здоровую. Если нужно было какому-то приложению разрешить делать звонок без подтверждения нужно было сделать флажок в Info.plist — т.о. разработчик выставив такой флажок явно бы указал, что он в курсе, что теперь схема tel будет обрабатываться без подтверждения (нестандартно).
      • +6
        Формально Apple, конечно же, подстраховалась, видимо в надежде, что её любимые пользователи будут клясть фейсбуки и гмэйлы.
        Но зная Apple, вот такая отмазка совершенно не укладывается в их «заботу о пользователях».
        Что мешало добавить метод делегата, например, -(BOOL)showDefaultTelAlert:, возвращающий по дефолту Yes, который любой разработчик при желании сможет переопределить и реализовать собственное поведение, а для ленивых будет вылетать стандартный алерт?
        • +1
          Вообще верно сказано. По дефолту запилить алерты на все tel ссылки и все счастливы.
          • +5
            Лучше при первом вызове показывать алёрт: «Приложение блабла желает иметь доступ к телефону. Запретить? Разрешить один раз? Разрешать всегда?», как это сделано с доступом к гео-данным, контактам, камере и т.п.
            И все будут счастливы.
          • 0
            В принципе не исключено что злоумышленнику в своем зловредном приложении можно перехватить UIAlertView и сделать выбор за пользователя.
  • +10
    Одной ночью я просто читал документацию о ссылках tel

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

    P.S. Вот за что я люблю IT сообщество!
    • +13
      Это перевод, поэтому не только на хабре :)
      • +1
        Не заметил перевод. Ну и хорошо, что не только!
        Движемся в нужном направлении. =)
    • +1
      Ага, только не очень внимательно читал. По указанной ссылке на tools.ietf.org/html/rfc3966 мы видим пример:
      <a href="tel:+1-212-555-0101">+1-212-555-0101</a>
      Найдите разницу, что называется.

  • 0
    На платных номерах перед соединением идёт начитка об услуге и тарификации. Случайный дозвон со снятием средств вряд-ли возможен.
    • 0
      Я не знаком с iOS, но разве эта уязвимость не будет работать с USSD? Там возможно моментально списание средств.
      • 0
        Нет,
        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.
  • +4
    Боюсь спросить про
    <a href="sms:+3581234567">Send SMS to us </a>
    


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

      Здесь больше информации
      • +2
        Хотя нет, можно использовать ссылку вида
        <a href="sms:+380930000000;body=Привет, как дела?">Кликни</a>
        • 0
          в 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.
          • +1
            Не должно, но текст подставляется, как Вы сказали ранее, если есть история переписки.
    • +1
      twitter.com/i_bo0om/status/491783079912951809
      Просто оставлю это здесь.
  • +18
    То есть вы предполагаете, что любой разработчик, который хочет использовать webView, должен сам догадаться прочитать документацию на какие-то трижды ненужные ему ссылки, которые описаны в совершенно другой части документации? Или просто штудировать developer.apple.com/*?

    UPD Только заметил, что перевод. Все претензии к автору оригинала.

    P.S. И почему ярлычок перевод не сделать на всю ширину страницы, чтобы заметно было?
    • +1
      Все-таки отчасти — это вина Apple. Именно компания, предоставляющая среду для разработки приложений должна следить за всеми возможными вариантами выйти за рамки безопасности.
    • +1
      tel:// это далеко не самая «advanced» фича. Разработчики о ней знают.
      Скорее это прекрасный пример отвратительного QA и низкоквалифицированной разработки конкретного продукта.
  • +1
    IOS 7.1.2
    Fb Messanger.
    автоклик не срабатывает. ручной — таки звонит без предупреждения

    <script> document.location='tel://000'; </script>
    говорит «страница пытается открыть сторoнний апп. разрешить?»

    header('Location: tel://000') — звонит без вопросов…

    • +1
      Еще можно использовать iFrame.
  • +9
    Автор, у вас классный перевод, раз в комментариях многие даже не заметили, что это не собственное исследование. Да и сам я тоже только дочитав до комментариев увидел, что статья переводная.
    А по делу. Не подскажете, USSD отправляется таким образом? Я к сожалению без устройства, сам поглядеть не могу, но интересно.
    • +2
      Спасибо!

      Что касается USSD — еще в далеком 2012 году была уязвимость. Сейчас, к сожалению, все залатали.
      • +7
        К чьему сожалению? ;) Может к счастью )))). И без USSD, подобным можно создать кучу проблем.
        Кстати, а что на других платформах, кто-нибудь проверял?
        • 0
          Извините, «по Фрейду» ошибочка вышла. :)

          Что касается других платформ — на андроиде не работает, симбиан тоже. Остальные еще предстоит тестировать.
  • 0
    На android что-то похожее было. Вроде можно было вайпнуть телефон такой ссылкой. Кстати, надо попробовать сервис-коды, хотя бы тот же *#06#.
    • 0
      Была уязвимость в фирменной оболочке Samsung еще на 2.x версиях, лечилось установкой альтернативного лаунчера.
    • +1
      Вот этот пост вы, видимо, имели ввиду.
  • +3
    На минуточку, это не только у iOS такое поведение, но и у всея OSX — только что попоробовал: например VK Messager (при включенной настройке «открывать внешние ссылки в программе») при клике очень даже пытается позвонить через любой устанновленный VoIP (например Skype, Zoipper). Правда скайп звонить отказывается — но это лишь потому, что разработчики плевать хотели на пользователей — как обработчик tel:// скайп зарегистрировался, а вот обрабатывать не хочет
  • –1
    Возможно я что-то не понимаю, а зеродей то в чем состоит?
    Телефон превращается в кирпич? Он рутуется? На него ставится троян? Пользователь не может прервать звонок?
    • 0
      Скажите, а у вас какое-то свое определение 0day уязвимостей?

      Вот вам кусочек википедии:
      0day (англ. zero day) — термин, обозначающий вредоносные программы, против которых еще не разработаны защитные механизмы или уязвимости, которые не устранены.
      • +1
        Яж написал «возможно я что-то не понимаю»…

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

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

        • 0
          Понимаете-ли, тут трактовать по разному можно.
          Заражением можно считать возможность выполнения сторонним софтом (давайте считать html страницу — софтом) каких-либо операций (вызова необходимого номера телефона) на устройстве.
          • 0
            То есть, в общем случае, посещение произвольной html страницы, с возможностью её не посещать, является заражением?
  • +1
    Если использовать вызов из нативного кода, то звонить будет без предупреждения и диалога:

    [[UIApplication sharedApplication] openURL:[NSURL URLWithString:
    @"tel:1-555-555-5555"]];
    

    А если, как в вашем примере из html:
    <a href=”tel:1-555-555-5555″>1-555-555-5555</a>
    

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


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

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

    Другие примеры вызовов приложений (sms, maps, youtube) можно посмотреть, например, тут
    • 0
      Да не, в его примере ошибка, там еще два слеша присутствуют.
      • 0
        Работает и со слешами и без слешей.
  • +1
    Для набора телефона с предварительным диалоговым окном, есть адрес telprompt://
    Для набора без диалогового окна tel://
    Как спроектировано так и работает, никаких уязвимостей.
    • 0
      «Это не баг — это фича»
    • +1
      если что-то работает как спроектировано, то уязвимость еще может быть следствием плохого проектирования ;)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.