Новый вид фишинг атаки на Apple

Новый вид фишинг атаки на Apple

Kevin Mitnick

В недавнем сообщении в своем блоге Феликс Краузе раскрыл метод фишинга паролей пользователей Apple на iOS, который был бы совершенно неотличим от реального запроса пароля iOS. Это заставило нас подумать о последствиях - как еще можно было бы использовать эту тактику в экосистеме Apple и какой ущерб могла бы привести этот фишинговый обман?

Новый вид фишинг атаки на Apple

iOS фишинг

В случае с от Krause iOS-фишинг мошенничеством, используя простой код, любое приложение может легко имитировать стандартный запрос пароля iOS, и большинство пользователей не думают, что здесь что то не так.

Изображение предоставлено сайтом krausefx.com

Однако я не вижу большого риска от этого фишинга. Приложения iOS можно загружать только через App Store, и, хотя я бы никогда не сказал, что невозможно получить фишинговое приложение из App Store, это, конечно, непросто сделать. Мало того, что хакеру нужно протолкать вредоносный код через обзор, им также нужно будет создать приложение -наживку, которую достаточно будет загрузить, что становится все труднее даже для легальных разработчиков в переполненном iOS App Store. Я рассматриваю это как возможное, но очень маловероятно.

Конечно, есть много других случаев, когда процесс скрининга в App Store не может начат какое-либо действие, и это может быть столь же убедительным, и не больше.

Например, рассмотрим macOS вместо iOS. В отличие от iOS, пользователи Mac могут загружать приложения из любого места и часто это делают. Таким образом, пользователи Mac в конечном итоге заражаются вредоносными ПО, вирусно-рекламным ПО и неэтичными и нежелательными программными обеспечениями. Таким образом, нет стадии рассмотрения, к которому должен хакеру приходится обращаться.

Предположим, вы используете свой Mac, и вдруг приложение Mail открывается и запрашивает пароль из-за сбоя в вашей учетной записи iCloud. Это может выглядеть примерно так, как показано ниже. Ваши действия?


Вы введете свой пароль учетной записи iCloud? В конце, он будет ссылаться на надежный и правильный адрес учетной записи iCloud. Если вы ввели свой пароль извините, то в этом случае, вы уже отмечены как зараженный.

Ладно, может быть, это не самый убедительный запрос пароля, если вы эксперт по Mac и знаете, как должны выглядеть такие запросы . (Теперь я слышу критические замечания.) Однако есть несколько важных вещей, которые нужно взять на заметку.

Во-первых, это обмануло многих. Конечно, возможно, не поклонников Mac, но большинство людей не являются и не обязаны быть экспертами и знать как выглядит каждое диалоговое окно MacOS.

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

Хуже того, было бы легко воспроизвести настоящий диалог аутентификации macOS, пиксель за пикселем, без особых усилий в приложении, составленном в Xcode.

Фактически аналогичное событие произошло в начале этого года, когда Handbrake был взломан для установки вредоносного ПО Proton. Вредоносная копия Handbrake в конечном итоге запросила пароль для входа в систему таким образом, что даже эксперты «купились» на это, например, разработчик уважаемой и общеизвестной компании Panic, Inc.


Мы привыкли к подобным запросам пароля и стала частью нашей повседневной жизни, поэтому, когда мы видим это, мы просто вводим пароль, не задумываясь ни о чем. В конце концов, у Macs не может быть вредоносных программ, верно? К счастью для пользователей Mac, достоверных и фактических случаев такого рода вредоносных программ встречалось мало, но это только в пользу хакеров, поскольку мы привыкли к этим запросам и не относимся к ним с подозрением, которое стоит того, чтобы относились с подозрение к подобным запросам.

Итак, что мы можем сделать с подобными вещами? К сожалению, Apple не может решить эту проблему. Приложение всегда сможет отображать идеальную симуляцию до пикселя, любого официального macOS или iOS.страницы запроса пароля.

Хуже того, даже веб-разработчик мог бы сделать то же самое, объединив скриншоты из целевой системы и веб-формы. Код может обнаружить систему и отобразить соответствующее «окно» для MacOS, iOS, Windows или Android. Подсунуть что-то подобное в качестве наложенного поверх взломанного легитимного сайта, и можно обмануть народ.

Хотя Apple может постоянно направлять пользователя в известное, удобное место для ввода паролей, это не всегда разумно. Рассмотрим, например, ужасный пользовательский опыт. Apple навязала пользователям Mac новый пользовательский процесс загрузки ядра в MacOS High Sierra. Хотя это не то же самое, что и запрос пароля, это хороший пример того, как принудительное заставлять пользователя переходу к определенному местоположению по соображениям безопасности может пойти в другом ужасном направлении, что приводит к плохому опыту для пользователя, который на самом деле не может быть значительно безопасным способом.

Вместо того, чтобы искать исправления для чего-то, что не может быть исправлено, нам нужно сосредоточиться на изменении нашего собственного поведения. Каждый запрос пароля всегда следует рассматривать с подозрением, независимо от источника. Если Mail всплывает, и появляется окно с запросом пароля, это не значит, что на самом деле Mail запрашивает ваш пароль.

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

К сожалению, это не всегда возможно, так как в случае установщика, запрашивающего пароль или приложение, запрашивающее пароль для установки вспомогательного инструмента. В случае Handbrake не было нормой запрашивать пароль, поэтому просмотр запроса пароля в этом контексте не является опасным. Хотя я должен признать, что, возможно, я попал под фальшивый запрос пароля Handbrake, если бы я был более осторожен, я бы проверил сайт разработчика или документацию разработчика, чтобы убедиться, что это нормально для Handbrake.

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

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

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