Баги в телефоне что это
Роботы ошибаются: ищем баги в приложениях для Android
Новые ошибки в веб-сервисах, приложениях и операционных системах — все это уже так привычно и знакомо. Подобные новости мы читаем каждый день. Но что странно: если взять мобильное направление, то здесь царит тишина. И если иногда проскакивают новости об уязвимостях в самих ОС, то никакого багтрака по мобильным приложениям нет. Почему?
Почта, календарь, список контактов, менеджер паролей, сотни фотографий — все это хранится у нас на телефоне. Смартфон становится своеобразным ключиком ко всему: многие сервисы привязывают номер телефона для возможности восстановления пароля. При этом мы по какой-то необъяснимой причине на подсознательном уровне считаем, что все содержимое смартфона априори находится в безопасности. Худшее, что может произойти, в глазах обычного обывателя — это потеря или кража девайса. Однако на этом список угроз не заканчивается.
Мобильные приложения по сути своей мало чем отличаются от обычных. И глупо было бы говорить о том, что они более безопасны. Напротив, мобильные разработчики не сильно запариваются насчет безопасности, расставляя приоритеты в сторону функциональности и юзабилити. Программисты здесь еще не научены горьким опытом и пока мало задумываются о безопасности — главное, чтобы все хорошо работало и пользователи скачивали/покупали приложения. Поэтому нет ничего странного, что в огромном количестве приложений (в том числе банковских) кроются уязвимости — и выявляются они чаще всего простейшим анализом. Неудивительно, что безопасность мобильных приложений вызывает все больший интерес как среди злоумышленников, так и среди исследователей. Хороший пример: компания «Яндекс» в конце 2012 года добавила в конкурс «Охота за ошибками», помимо вебсервисов, свои приложения для iOS и Android. В нашей программе сегодня — разобраться с основными типами уязвимостей в мобильных приложениях для мобильной платформы Android. Но прежде — освоим матчасть.
Операционная система Android устроена таким образом, что каждое приложение запускается под специальной виртуальной машиной Dalvik. Ее отличительная особенность — низкое энергопотребление, что хорошо подходит для ARM-устройств. Программы для Android пишутся на Java (с использованием внешних библиотек на других языках благодаря расширению NDK), однако стандартный байт-код не используется. Вместо этого Dalvik использует свой формат — dex. Обычные class-файлы конвертируются в dex с помощью утилиты dx, входящей в Android SDK.
Топ-10 уязвимостей мобильных приложений и способы их устранения
По данным Statista в мире насчитывается около 3.5 млрд. пользователей смартфонов. Это значит, что жертвами небезопасных мобильных приложений могут стать очень многие.
Подготовленный фондом OWASP cписок 10 наиболее актуальных уязвимостей приложений – это отличный ресурс для разработчиков, стремящихся создавать защищенные продукты. Дело в том, что многие мобильные приложения по своей природе уязвимы для угроз безопасности. Вспомним, к примеру, ряд нашумевших атак, произошедших за последние годы. К ним можно отнести шпионское ПО Pegasus для WhatsApp, посредством которого злоумышленники смогли заполучить управление устройствами пользователей мессенджера. Еще одним примером явился взлом приложения Pokémon Go, который позволил пользователям с помощью реверс-инжиниринга манипулировать GPS-данными и ловить больше покемонов.
Многие другие приложения и организации, такие как Tinder и MediaTek, также стали жертвами атак. Но что же делает подобные ресурсы уязвимыми? Для мобильных приложений характерна более обширная поверхность атаки, чем для их веб-аналогов, так как они скачиваются с публичных площадок и дают возможность проинспектировать код. Плюсом к этому, такие приложения, как правило, собирают огромное количество пользовательской информации, что делает их еще более привлекательным средством для кибер-преступников.
Исследования OWASP
На основе проведенного опроса и анализа обратной связи мирового сообщества проект по обеспечению безопасности мобильных приложений (OWASP) впервые предоставил информацию о связанных с ней рисках в 2011 году. После этого аналогичные исследования проводились в 2014 и 2016 годах. Последнее из этих исследований и является наиболее актуальным на сегодня.
В списках 2014 и 2016 года полностью совпадает только один пункт, в остальном же структура категорий сильно изменилась. Например, некоторые пункты были разделены, а некоторые, наоборот, объединены в один, что упростило их рассмотрение.
Мы же с вами ознакомимся с версией списка уязвимостей 2016 года, попутно рассмотрев возможные способы их устранения.
1. Неправильное использование платформы
Данный вид уязвимостей стоит во главе списка. Независимо от того Android это или iOS, при разработке для любой из этих платформ необходимо придерживаться конкретных требований с целью обеспечения должного уровня безопасности итогового продукта. Но бывает, что при создании приложений некоторые из предписанных правил и рекомендаций непреднамеренно нарушаются или просто реализуются с ошибками.
В результате возникает угроза, вызванная неверным использованием какой-либо возможности платформы или отсутствием реализации протоколов безопасности. Здесь можно упомянуть следующие случаи:
Как предотвратить
Подобные уязвимости нужно устранять на серверной стороне. Наряду с соблюдением рекомендаций платформы по разработке, риски можно также минимизировать с помощью безопасных подходов к написанию кода и применения правильных настроек сервера. Помимо этого, уменьшить вероятность неверного использования платформы поможет:
2. Небезопасное хранилище данных
Мобильные устройства нередко теряются или крадутся, оказываясь в руках злоумышленников. Помимо этого, утечка личной информации пользователя может произойти из-за вредоносного ПО, которое позволяет атакующему задействовать уязвимости устройства. С помощью взлома или рутинга устройства можно легко обойти защиту шифрованием, поэтому разработчики ПО должны исходить из предположения, что злоумышленники могут получить доступ к файловой системе.
И поскольку практически все приложения так или иначе сохраняют информацию, очень важно реализовать ее сохранение в такой области, где она не будет доступна другому приложению или пользователю.
Как предотвратить
Производить тестирование приложения на уязвимость угрозам для выяснения, какие информационные активы обрабатываются, и как с этими данными взаимодействуют API. Это поможет:
3. Небезопасная коммуникация
Если данные передаются незашифрованными в виде чистого текста, любой, кто отслеживает данную сеть, может перехватить и прочесть их.
Мобильные приложения, как правило, обмениваются данными по модели клиент-сервер. При этом процесс передачи через сеть оператора или интернет должен быть реализован безопасно. Траффик может перехватываться прокси-серверами, базовыми станциями, а также с помощью взлома WiFi или путем установки на устройство вредоносного ПО.
Как предотвратить
Для избежания кражи данных в процессе их передачи по сети следует полагаться на утвержденные индустрией протоколы шифрования и прочие практики, включая:
4. Небезопасная аутентификация
Прежде чем предоставить доступ, приложение должно проверить подлинность пользователя. Обход аутентификации обычно реализуется через существующие уязвимости, такие как неправильная проверка сервисных запросов сервером. Мобильные приложения должны проверять и удерживать подлинность пользователя, особенно в процессе передачи конфиденциальных данных, например, финансовой информации.
Как предотвратить
Использование слабых мест механизма аутентификации позволяет злоумышленникам обходить системы проверки паролей или получать дополнительные разрешения, осуществляя кражу данных и другие действия.
Для предотвращения подобных рисков рекомендуется:
5. Недостаточная криптографическая стойкость
Существует два случая, в которых криптография системы может быть скомпрометирована для раскрытия чувствительных данных:
Как предотвратить
Недостатки системы криптографического управления доступом могут вести к утечке чувствительных данных с устройства. В связи с этим следует:
6. Небезопасная авторизация
Для разных пользователей предусматриваются разные права, в результате чего одни получают стандартный доступ, в то время как другие, например администраторы, могут иметь дополнительные разрешения и привилегии. Слабые схемы авторизации, несмотря на успешную проверку подлинности пользователя, могут не справляться с проверкой его прав на доступ к запрашиваемым ресурсам. Подобный недочет позволяет хакерам авторизовываться и выполнять атаки с целью повышения привилегий.
Как предотвратить
Как и в случае с аутентификацией, недочеты авторизации могут вести к краже данных, подрыву репутации и даже штрафам за несоблюдение требований. В качестве противодействия этим рискам стоит рассмотреть следующие варианты:
7. Качество кода клиента
Эта категория в некотором смысле является общей причиной проблем мобильного клиента, связанных с неправильной реализацией кода.
Атакующий может передавать особые входные данные в вызовы функций, провоцируя их выполнение и наблюдая за поведением приложения. В связи с этим падает производительность, повышается потребление памяти и т.п. В этом случае стоит иметь в виду, что ошибки в коде нужно исправлять локальным способом, поскольку они возникают в мобильном клиенте и отличаются от ошибок серверной стороны. Привести же они могут к:
Как предотвратить
Для устранения уязвимостей и прочих, вызванных некачественным кодом, проблем, рекомендуется:
8. Подделка кода
Иногда в магазинах встречаются поддельные версии приложений. От оригинала их отличает встроенное в исполняемый файл вредоносное содержимое, например закладка, позволяющая получать несанкционированный доступ к системе. Злоумышленники могут повторно подписывать эти поддельные приложения и размещать их в сторонних магазинах или даже напрямую доставлять жертве через фишинговые атаки.
Как предотвратить
Подделка кода программы может вести к упущенным выгодам, краже личных данных, подрыву репутации и прочим пагубным последствиям. Для предотвращения подобных проблем существуют следующие рекомендации:
9. Реверс-инжиниринг
Злоумышленники могут разобрать и декомпилировать приложение для анализа кода. Этот способ взлома особенно опасен, так как позволяет инспектировать, понять и изменить код, включив в него вредоносную функциональность или транслирование нежелательной рекламы. Разобравшись в принципе работы приложения, хакеры могут изменить его с помощью таких инструментов, как IDA Pro, Hopper и прочих. После реализации нужного им поведения, они могут повторно скомпилировать приложение и использовать в своих умыслах.
Как предотвратить
Помешать злоумышленнику выполнить реверс-инжиниринг программы может только невозможность произвести деобфускацию кода с помощью IDA Pro, Hopper и аналогичных инструментов.
10. Лишняя функциональность
Иногда разработчики могут ненамеренно оставлять закладки или дополнительную функциональность, которые не очевидны для конечного пользователя. В результате продукт выпускаются в продакшен с функцией, которая не должна быть доступной, что создает дополнительные риски для безопасности приложения.
Хакеры эксплуатируют подобные слабые места программ непосредственно из своих систем, не нуждаясь в содействии со стороны регулярных пользователей. Они изучают файлы конфигурации, двоичные файлы и прочие компоненты, раскрывая функционал бэкенд-части, который затем используют для совершения атак.
Как предотвратить
Один из наиболее эффективных способов избежания подобных типов уязвимостей – это самостоятельный анализ безопасности кода. Таким образом вы сможете:
Обобщение
Приведенный список уязвимостей мобильных приложений может послужить отправной точкой для организаций, разработчиков, специалистов по безопасности и пользователей, которые только начинают решать соответствующие проблемы. Здесь были приведены краткие определения для каждого вида уязвимости, примеры сценариев атаки, способы их предотвращения и рекомендованные стратегии по минимизации ущерба.
Но имейте в виду, что этот список представляет лишь необходимый минимум. Поэтому с целью реализации максимально эффективного и безопасного продукта советуем изучить данную тему более углубленно.
На правах оффтопа: баги и их последствия
Павел Крижепольский
О том, как одной сменой текущей даты превратить iPhone в «кирпич» (Внимание! Не пробуйте повторить это сами!), самом дорогом дефисе в истории США, черном понедельнике, делении на ноль, реальной эпидемии в придуманном мире и других знаменитых багах…
Вместо предисловия
Согласно Википедии, в программировании баг (англ. bug — первичные значения: клоп, любое насекомое, вирус) — жаргонное слово, обычно обозначающее ошибку в программе или системе, из-за которой программа выдает неожиданное поведение и, как следствие, результат.
Первое применение слова bug по отношению к технике приписывают Томасу Эдисону. По одной из легенд, еще во время работы над фонографом, он долго не мог понять, почему же собранный прототип отказывается работать. Перебрав в уме все возможные варианты и так и не найдя решения, он предположил, что во время сборки между деталями устройства мог попасть жук. И хотя на самом деле никаких насекомых в фонографе не оказалось, в будущем он продолжил использовать слово bug для обозначения досадных неисправностей.
В качестве примера можно привести одну из записей из его рабочего дневника, датированную 1878 годом:
«Так было со всеми моими изобретениями. Первый шаг — интуиция, которая приходит как вспышка, затем возникают трудности — устройство отказывается работать, и именно тогда проявляются «жучки» — как называют эти мелкие ошибки и трудности — и требуются месяцы пристального наблюдения, исследований и усилий, прежде чем дело дойдёт до коммерческого успеха или неудачи»
Любопытно, что слово debugging, которое в наши одни обозначает этап отладки программы и поиск всех возможных проблем, встречалось еще в Оксфордском словаре 1945 года выпуска. Правда, тогда речь шла не о программах, а об авиационных двигателях.
Применимо к компьютерам и программному обеспечению слова «баг» и «дебагинг» стали использовать несколько позже. Считается, что родоначальником этой традиции в 1946 году стала контр-адмирал флота США Грейс Хоппер, которая столкнулась с неполадкой в работе с вычислительной машиной Harvard Mark II. Как выяснилось впоследствии, причиной странного поведения ЭВМ оказался самый обычный мотылек, который попал между контактами одного из электромеханических реле. Трупик несчастного насекомого был бережно извлечен из недр машины и приклеен скотчем к странице рабочего дневника. Подпись ниже гласила: «Первый реальный случай обнаружения бага».
В наш с вами век реальные насекомые уже вряд ли смогут привести к сбою в работе программы. Зато вот их цифровые сородичи ежегодно доставляют людям кучу проблем. Случаев, когда одна крохотная ошибка программиста приводила к огромным неприятностям, в новейшей истории полно и случай в iPhone – еще цветочки.
Временные сложности
Сломать за 60 секунд
На днях владельцы техники Apple случайно выяснили, что если установить на iPhone или iPad дату 1 января 1970 года, а затем перезагрузить устройство, то оно превратится в «кирпич». На экране будет вечно светиться логотип Apple и больше загрузиться устройство не сможет уже никогда. Ну или как минимум – до вашего визита в сервисный центр, хотя и с этим пунктом пока не все ясно.
На данный момент установлено, что ошибка встречается на мобильных устройствах Apple с 64-битными процессорами Apple A7, A8, A8X, A9 и A9X. Версия ОС значения не имеет. Категорически не рекомендую проводить подобные эксперименты на своем аппарате – это гарантированно приведет к серьезной поломке, справиться с которой своими силами вы не сможете. Так же хочу обратить ваше внимание на всевозможные «приколы», уже второй день гуляющие по интернету. Шутники предлагают поменять время на смартфоне чтобы увидеть секретную пасхалку или суметь бесплатно скачать платные программы из AppStore. Результат – «кирпич» вместо смартфона.
Суть бага. В Unix-подобных ОС время считается не совсем привычным для нас образом. Для Unix текущее время – это число секунд, прошедшее от точки отсчета, за которую была принята полночь 1 января 1970 года. Для человека такой способ не очень удобен, а вот для компьютера — в самый раз. Что именно происходит в «голове» у iPhone, который решил, что присутствует при зарождении Unix вселенной, пока не известно, но что сказывается это на нем не лучшим образом – уже неоднократно проверенный факт.
Впрочем, попытаться самим предположить, где именно закрался «баг», нам никто не мешает.
Те, кто играл в игры времен MS-DOS наверняка сталкивались с разными багами, возникающими при переполнении счетчика. К примеру, в Civilization был очень миролюбивый правитель по имени Ганди, у которого параметр агрессии был равен 1. Если его еще немного «задобрить», предложив принять какой-то подарок или заключив союз, значение агрессии вначале падало до нуля… а затем резко взлетало до небес. Дело в том, что переменная предполагала значения от 0 до от 255 и при попытке отнять единицу от нуля вновь становилась максимальной. Программисты просто не предусмотрели проверку текущего значения переменной, что и приводило к ошибке.
Подобная ситуация встречалась и во многих других играх. К примеру, в оригинальной X-Com максимально прокачанный боец рисковал внезапно стать беспомощным младенцем, так как с очередной прибавкой к характеристикам значения счетчиков скидывались до нуля.
Можно предположить, что что-то подобное происходит и с iPhone — во время загрузки iOS для каких-то своих целей требуется взять значение времени, которое на пару секунд меньше текущего… а так как дата 1 января 1970 года и так принята системой за 0, то в результате значение 64-битной переменной становится максимальным. Ради интереса можно попробовать посчитать, какая это получается дата, но очень подозреваю, что наше Солнце к тому времени уже точно погаснет.
Уверен, что рано или поздно с этой проблемой Apple разберется. Но вот 19 января 2038 года я бы все же посоветовал всем быть поосторожнее – именно в этот момент значение Unix-времени превысит 2147483647 и перестанет помещаться в стандартную переменную (беззнаковое 32-битное целое число). И как на это отреагируют 32-битные устройства по всему миру — загадка.
Баг Тысячелетия
Суть бага. Во многих ОС год записывался только двумя последними цифрами. Так, для обозначения 1998 года использовались цифры 98, для 1999 – 99 и так далее. По этой системе 2000 год обозначался как 00, что для компьютера ничем не отличалось от 1900 года.
Несмотря на свое страшное название, на практике ни к каким особым проблемам этот баг не привел. Может быть, за это стоит благодарить оперативно сработавших программистов, которые к 2000 году смогли исправить большую часть ПО. А возможно, что это просто у страха глаза были велики. В любом случае, по-настоящему опасные баги выглядят совершенно иначе и крайне редко предупреждают о своем существовании за несколько лет до возникновения потенциальной проблемы.
Через тернии к звездам
Самый дорого дефис в истории
Маринер-1 – космический аппарат NASA, который был создан для изучения Венеры. Запуск аппарата состоялся 22 июля 1962 года, однако уже через несколько минут после старта он был уничтожен.
Первые проблемы начались уже спустя 293 секунды после запуска, именно в этот момент Маринер-1 потерял связь с Землей. Такая ситуация была изначально предусмотрена инженерами, и управление аппаратом принял на себя бортовой компьютер. Вот только компьютер тут же «запаниковал» и выдал команду на очень сильную коррекцию курса, которая в тот момент была совершенно не нужна и вывела Маринер-1 на опасную траекторию. Так как падение ракеты к тому моменту было уже практически неминуемо, специалисты NASA приняли решение ее уничтожить.
Суть бага. Во время перевода написанных от руки формул в код программы, программист пропустил символ надчеркивания (макрон). Отсутствие в коде одной единственной черточки привело к тому, что бортовой компьютер стал воспринимать незначительное отклонение от траектории движения как очень серьезное и срочно ввел значительные поправки, которые и сбили ракету с курса.
Впрочем, в некоторых версиях произошедшего вместо символа надчеркивания фигурирует дефис, а кто-то предполагает, что во время составления программы на Фортране программист просто перепутал точку с запятой.
Метод копипаста
«Ариан 5» (фр. Ariane 5) — европейская ракета-носитель семейства Ариан, предназначена для выведения полезной нагрузки на низкую опорную или геопереходную орбиту. Она до сих пор является основной ракетой-носителем ЕКА и останется таковой минимум до 2023 года. И тем не менее, ее первый запуск закончился аварией, которая стала примером одного из самых дорогих багов в истории.
Суть бага. Во время работы над ПО новой ракеты программисты использовали куски уже готового кода, ранее написанного ими для Ариан 4. В результате, иные технические характеристики новой ракеты и немного другая расчетная траектория полета привели к тому, что ее текущая скорость превысила имеющиеся в программе ограничения. В какой-то момент бортовой компьютер просто не смог перевести значение скорости из 64-битного формата в 16-битный (число оказалось больше 32,767 и просто «не влезло» в переменную), что и вызвало сбой в работе ПО.
Цена ошибки
Защита от дурака
В сентябре 1997 года авианосец США USS Yorktown в течение трех часов дрейфовал в море с неработоспособными бортовыми компьютерами и системой управления ходовой частью. К счастью для экипажа, ситуация произошла во время учебных маневров, а не боевых действий.
Суть бага. На ноль делить нельзя – это знают даже ученики начальной школы. Но компьютер – не человек, и, если попросить его поделить какое-то число на ноль, он честно попытается это сделать. Причем, этой неразрешимой задаче он станет уделять все свое время и внимание. Если, конечно, программист не предусмотрит специальную «защиту от дурака», которой в бортовых системах USS Yorktown почему-то не было. В результате, когда один из членов экипажа по ошибке ввел ноль в бортовую систему управления, она вышла из строя, на несколько часов оставив авианосец совершенно беспомощным.
Одна треть секунды
К сожалению, далеко не все «баги» в ПО оканчиваются столь удачно. Очень часто они могут привести к человеческим жертвам, что и произошло в 1991 году во время войны в Персидском заливе. Из-за ошибки в ПО зенитный ракетный комплекс Patriot отказался перехватывать запущенную ракету, что привело к человеческим жертвам.
Суть бага. Из-за особенностей округления времени, каждые 100 часов бесперебойной работы ЗРК Patriot его часы сбивались примерно на треть секунды. В итоге компьютер вовремя обнаружил запуск вражеской ракеты, но из-за бага со временем допустил критическую ошибку при просчете траектории. Решив, что ракеты уже не существует, система отменила попытку перехвата.
Цепная реакция
Компьютерный разум
Чёрный понедельник (англ. Black Monday) — понедельник 19 октября 1987 года — день, в который произошло самое большое падение индекса Доу-Джонса за всю его историю. Хотя еще утром абсолютно ничто не предвещало беды и никаких объективных причин для обвала рынка просто-напросто не было.
Суть бага. До сих пор есть несколько теорий произошедшего, но в большинстве случаев основной причиной называют примитивную логику ПО для программного трейдинга. В какой-то момент рынок начал падать, и самые осторожные «электронные помощники» трейдеров поспешили побыстрее избавиться от всех дешевеющих ценных бумаг. Это привело к тому, что вместо обычной коррекции случилась самая настоящая цепная реакция — рынок оказался перенасыщен, цены на бумаги упали еще больше и в дело включилось ПО остальных игроков. В итоге один крохотный снежок спровоцировал огромную горную лавину, которую никто совершенно не ожидал.
С точки зрения финансовых последствий, «черный понедельник» стал далеко не самым страшным событием прошлого века (хотя и затронул очень многие страны), однако многие финансисты и трейдеры до сих пор вспоминают о нем с содроганием. Это был первый случай, когда машины попросту оттеснили людей в сторону и стали играть друг с другом по своим собственным правилам. Люди же выступали в роли сторонних наблюдателей, слишком медленных и неповоротливых для того, чтобы их стоило принимать во внимание.
Эпидемия
Спустя несколько часов в мире игры разразилась страшная эпидемия, которая выкашивала целые города. Улицы были завалены трупами персонажей игроков, а выжившие в страхе шарахались от любой тени, боясь подцепить смертельную заразу. Как-то совладать с ситуацией удалось только после перезапуска игровых серверов, во время которого программисты в спешном порядке установили специальный патч, исправляющий ошибку. И думаю, что тот день многие игроки запомнили надолго.
Впрочем, сам я в World Of Warcraft никогда не играл и могу пересказать проишествие только с чужих слов. Возможно, кто-то из читателей меня поправит.
Суть бага. По задумке гейм-дизайнеров, эффект должен был действовать только в домашней локации Хаккара и никак не мог затронуть персонажей в других местах. Они не учли только один момент – зараженный игрок мог телепортироваться в другую локацию, заразив ничего не подозревающих соседей.
Вместо послесловия
У каждой медали есть две стороны, и технический прогресс исключением не является. Баги вошли в нашу жизнь также прочно, как компьютеры, интернет и мобильные телефоны. Иногда они бывают забавными, иногда – опасными, но чаще – просто неприятными.
Что самое смешное, очень многих людей тянет протестировать все найденные баги на собственной шкуре. Казалось бы, совершенно очевидно, что это так же глупо, как вставлять спицы в электрическую розетку. Но нет, количество людей, специально готовых вставить стилус в Galaxy Note не той стороной или решивших проверить, сработает ли баг с датой на их iPhone, с каждым годом становится все больше и больше.
Может быть, это тоже своего рода баг современного общества, который мы все где-то и когда-то проглядели?