Обновления
- Мы опубликовали еще одну статью:
Ссылка скрыта от гостей
- Уязвимость коснулась даже первого iPhone (он же iPhone 1 / iPhone 2G) на iOS 3.1.3.
- Первый триггерный запуск этой уязвимости произошел в октябре 2010 года.
- Как вы можете заметить в новой статье, эту уязвимость можно эксплуатировать, и мы рекомендуем выпустить патч как можно скорее.
- Мы запустили bounty программу для
Ссылка скрыта от гостей
- IOCs & FAQ были обновлены.
Влияние и ключевые детали (TL;DR):
- Эта уязвимость позволяет злоумышленникам удаленно выполнять код и заражать устройство, отправляя электронные письма, занимающее значительные объемы памяти.
- Уязвимость не требует электронной почты с большим обьемом памяти - обычной почты, которая может потреблять достаточно оперативной памяти, было бы достаточно. Есть много способов достичь такой растраты ресурсов, включая RTF, multi-part и другие методы.
- Обе уязвимости были вызваны на практике
- Уязвимость может быть выполнена до того, как будет загружена вся электронная почта, поэтому ее содержимое может и не остаться в устройстве.
- Мы не исключаем, что после успешной атаки злоумышленники могут удалить оставшиеся электронные письма.
- Триггер уязвимости на iOS 13: атаки происходит самостоятельно (/zero-click) на iOS 13, когда приложение электронной посты открывается в фоновом режиме
- Триггер уязвимости в iOS 12: атака требует click по электронной почте. Атака будет инициирована перед рендерингом содержимого. Пользователь не заметит ничего аномального в самом письме
- Самостоятельные атаки на iOS 12 могут быть инициированы (так называемый zero-click), если злоумышленник контролирует почтовый сервер
- Уязвимости существуют, по крайней мере, начиная с iOS 6 - (дата выпуска: сентябрь 2012) - когда был выпущен iPhone 5
- Самые ранние триггеры, которые мы наблюдали на практике, были на iOS 11.2.2 в январе 2018 года.
-
Ссылка скрыта от гостей
Данная статья является первой частью цикла статей, со второй частью можно ознакомиться
Ссылка скрыта от гостей
На сайте можно заполнить анкету и проверить не угрожает ли вам эта уязвимость.
Многочисленные уязвимости в MobileMail / Maild
Введение
После рутинного расследования iOS Digital Forensics и Incident Response (DFIR), ZecOps обнаружили ряд подозрительных событий, которые влияют на почтовое приложение по умолчанию на iOS, начиная с января 2018 года. ZecOps проанализировали эти события и обнаружили уязвимость, влияющую на iPhone Apple и IPADS. ZecOps также обнаружили множественные триггеры для этой уязвимости на корпоративных пользователей, VIP и MSSP, в течение длительного периода времени.
Цель атаки заключается в отправке специально созданного электронного письма на почтовый ящик жертвы, позволяющая, тем самым, инициировать уязвимость в контексте iOS MobileMail на iOS 12 или maild на iOS 13. Основываясь на данных ZecOps Research и Threat Intelligence, мы с большой долей уверенности предполагаем, что эти уязвимости - в частности, удаленное переполнение кучи - широко используются в ходе целенаправленных атак со стороны продвинутого оператора(ов) угроз.
Подозреваемые цели включали:
- Частные лица из организации Fortune 500 в Северной Америке
- Руководитель от перевозчика в Японии
- VIP из Германии
- MSSP из Саудовской Аравии и Израиля
- Журналист в Европе
- Подозреваемый: руководитель швейцарского предприятия
Мы считаем, что эти атаки соответствуют как минимум одному оператору угрозы национального государства или национальному государству, которое приобрело эксплойт у исследователя Proof of Concept (POC) и использовало «как есть» или с незначительным модификации (отсюда и строки 4141..41).
Хотя ZecOps воздерживается от приписывания этих атак конкретному действующему субъекту, мы знаем, что по крайней мере, одна организация «нанятых хакеров» продает эксплойты с использованием уязвимостей, которые используют адреса электронной почты в качестве основного идентификатора.
Мы рекомендуем установить, как только будет доступно, обновление iOS.
Хронология эксплуатации
Мы знаем о множественных триггерах, которые происходили, начиная с января 2018 года, на iOS 11.2.2. Вполне вероятно, что те же операторы в настоящее время активно злоупотребляют этими уязвимостями. Скорее всего, злоумышленники использовали эту уязвимость еще раньше. Мы видели сходство между некоторыми из подозреваемых жертв во время запуска этих уязвимостей.
Затронутые версии:
- Все протестированные версии iOS уязвимы, включая iOS 13.4.1.
- Исходя из наших данных, эти ошибки активно возникали на iOS 11.2.2 и, возможно, ранее.
- iOS 6 и выше - уязвимы. iOS 6 была выпущена в 2012 году. Версии до iOS 6 тоже могут быть уязвимы, но мы не проверяли. На момент релиза iOS 6, iPhone 5 был на рынке.
ZecOps клиенты и партнеры
Ссылка скрыта от гостей
могут обнаруживать атаки, использующие уязвимости MobileMail / maild.Благодарность
Перед тем, как углубиться в исследование, мы хотели бы поблагодарить Apple за безопасность продукта и инженерную группу, которая выпустила бета-версию исправления, чтобы заблокировать эти уязвимости от дальнейшего злоупотребления после их развертывания в GA.
Детали уязвимости
ZecOps обнаружил, что в реализации MFMutableData библиотеки MIME отсутствует проверка ошибок для системного вызова ftruncate(), что приводит к Out-Of-Bounds записи. Мы также нашли способ инициировать OOB запись, не ожидая сбоя системного вызова ftruncate. Кроме того, мы обнаружили переполнение кучи, которое можно удаленно запустить.
Нам известны удаленные триггеры обеих уязвимостей.
И ошибка записи OOB, и ошибка переполнения кучи произошли из-за одной и той же проблемы: неправильная обработка возвращаемого значения системных вызовов.
Удаленный баг может быть вызван во время обработки загруженной электронной почты, в этом случае, как результат, электронная почта не будет полностью загружена на устройство.
Затрагиваемая библиотека: /System/Library/PrivateFrameworks/MIME.framework/MIME
Уязвимая функция: -[MFMutableData appendBytes:length:]
Ненормальное поведение после использования уязвимостей
Помимо временных лагов приложения, пользователи не должны наблюдать никаких других аномальных действий. После попытки использования эксплойта (как удачной, так и неудачной) на iOS 12 - пользователи могут заметить внезапный сбой приложения Mail.
На iOS13, кроме временного лага, этого не наблюдается. Неудачные атаки не заметить на iOS 13, если впоследствии будет проведена другая атака, удаляющая электронную почту.
В случае неудачных атак на электронные письма, которые будут отправлены злоумышленником, будет отображаться сообщение: «Это сообщение не имеет содержимого». Как видно на следующем рисунке ниже:
Анализ сбоя
Часть сбоя (из нескольких сбоев), испытываемого пользователем, заключается в следующем.
Сбой инструкции был stnp x8, x9, [x3], означая, что значение x8 и x9 было записано x3 и сбой из-за доступа к неверному адресу, 0x000000013aa1c000 который был сохранен в x3.
Код:
Thread 3 Crashed:
0 libsystem_platform.dylib 0x000000019e671d88 _platform_memmove +88
0x19e671d84 b.ls 0x00008da8
0x19e671d88 stnp x8, x9, [x3]
0x19e671d8c stnp x10, x11, [x3, #16]
0x19e671d90 add x3, x3, 0x20
0x19e671d94 ldnp x8, x9, [x1]
1 MIME 0x00000001b034c4d8 -[MFMutableData appendBytes:length:] + 356
2 Message 0x00000001b0b379c8 -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] + 808
Код с оформлением (BB-коды):
Registers:
x0: 0x000000013aa1b05a x5: 0x0000000000000006
x1: 0x0000000102f0cfc6 x6: 0x0000000000000000
x2: 0x0000000000004a01 x7: 0x0000000000000000
x3: 0x000000013aa1c000 x8: 0x3661614331732f0a
x4: 0x000000000000004b x9: 0x48575239734c314aЧтобы выяснить, почему произошел сбой процесса, нам нужно взглянуть на реализацию MFMutableData.
Приведенное ниже дерево католога вызовов взято из логов сбоев, с которым сталкивается только определенное количество устройств.
Код:
-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:]
|
+-- -[MFMutableData appendData:]
|
+-- -[MFMutableData appendBytes:length:]
|
+-- memmove()Анализируя библиотеку MIME, псевдокод -[MFMutableData appendBytes:length:] выглядит следующим образом:
Код:
-(void)appendBytes:(const void*)bytes length:(uint64_t)len{
//...
uint64_t new_length = old_length + len;
[self setLength:new_length];
if (!self->flush){
self->flush = true;
}
//...
memmove(dest, bytes, len);
}Следующий стек вызовов был выполнен до того, как произошел сбой:
Код:
-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:]
|
+-- -[MFMutableData appendData:]
|
+-- -[MFMutableData appendBytes:length:]
|
+-- -[MFMutableData setLength:]
|
+-- -[MFMutableData _flushToDisk:capacity:]
|
+-- ftruncate(Файл используется для хранения фактических данных, если размер данных достигает порогового значения, при изменении данных содержимое и размер отображаемого файла должны быть соответственно изменены. Системный вызов ftruncate() вызывается внутри, -[MFMutableData _flushToDisk:capacity: ] чтобы настроить размер отображаемого файла.
Ниже приведен псевдокод -[MFMutableData _flushToDisk:capacity:]
Код:
- (void)_flushToDisk:(uint64_t)length capacity:(uint64_t)capacity;{
boolean_t flush;
//...
if (self->path){
boolean_t flush = self->flush; //<-line [a]
}else{
//...
flush = true;
}
if(flush){ //<-line [b]
//...
ftruncate(self->path, capacity);
//...
self->flush = false;
}
}Справочная страница ftruncate указывает:
Код:
ftruncate() and truncate() cause the file named by path, or referenced by fildes, to be truncated
(or extended) to length bytes in size. If the file size exceeds length, any extra data is discarded.
If the file size is smaller than length, the file is extended and filled with zeros to the indicated
length. The ftruncate() form requires the file to be open for writing.
RETURN VALUES
A value of 0 is returned if the call succeeds. If the call fails a -1 is returned, and the global
variable errno specifies the error.Согласно справочной странице: “If the call fails a -1 is returned, and the global variable errno specifies the error.” это означает, что при определенных условиях этот системный вызов не сможет усечь файл и вернуть код ошибки.
Однако в случае сбоя системного вызова ftruncate, _flushToDisk в любом случае, продолжается, что означает, что размер отображаемого файла не увеличивается, и выполнение, наконец, достигает значения memmove() в appendBytes() функции, вызывая запись в файл mmap out-of-bound (OOB) записи .
Поиск другого триггера
Мы знаем, что сбой произошел из-за системной ошибки ftruncate(), означает ли это, что мы ничего не можем сделать, кроме как подождать, сбоя системного вызова?
Давайте еще раз взглянем на функцию -[MFMutableData _flushToDisk:capacity:].
Код:
- (void)_flushToDisk:(uint64_t)length capacity:(uint64_t)capacity;{
boolean_t flush;
//...
if (self->path){
boolean_t flush = self->flush; //<-line [a]
}else{
//...
flush = true;
}
if(flush){ //<-line [b]
//...
ftruncate(self->path, capacity);
//...
self->flush = false;
}
}Как видно из строки line , происходит проверка является ли flush флаг истинным ftruncate(). Это означает, что если мы можем установить flush флаг в false в line [a], то ftruncate() вообще не будет выполняться.
Если кто-то вызовет -[MFMutableData setLength:](set flush to 0), то перед вызовом -[MFMutableData appendData:], ftruncate() won’t be executed due to flush==0) будет аналогичный результат.
Следующая обратная трассировка является демонстрацией локального POC. Комбинируя эту OOB запись с дополнительной уязвимостью и/или методами для управления макетом памяти, эту уязвимость можно запустить удаленно - например, путем управления селекторами (как мы наблюдали в других событиях DFIR, а также в
Ссылка скрыта от гостей
).
Код:
Thread 0 Crashed:
0 libsystem_platform.dylib 0x00000001cc442d98 _platform_memmove + 88
0x1cc442d8c stnp x14, x15, [x0, #16]
0x1cc442d90 subs x2, x2, 0x40
0x1cc442d94 b.ls 0x00008db8 // 0x00000001cc44bf30
0x1cc442d98 stnp x8, x9, [x3]
0x1cc442d9c stnp x10, x11, [x3, #16]
0x1cc442da0 add x3, x3, 0x20
0x1cc442da4 ldnp x8, x9, [x1]
1 MIME 0x00000001ddbf0518 -[MFMutableData appendBytes:length:] + 352
0x1ddbf050c mov x1, x20
0x1ddbf0510 mov x2, x19
0x1ddbf0514 bl 0x000498f4 // 0x00000001ddc39e08
0x1ddbf0518 ldp x29, x30, [sp, #80]
0x1ddbf051c ldp x20, x19, [sp, #64]
0x1ddbf0520 ldp x22, x21, [sp, #48]
0x1ddbf0524 ldp x24, x23, [sp, #32]Хотя эта уязвимость действительно должна быть исправлена, мы подозреваем, что она была вызвана случайно, когда злоумышленники пытались использовать следующую уязвимость.
Вторая уязвимость: удаленное переполнение кучи в MFMutable
Мы продолжили наше расследование в отношении удаленно инициированных событий, которые были подозрительными, и решили, что в той же области существует еще одна уязвимость
Обратный след можно увидеть следующим образом:
Код:
-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:]
|
+-- -[MFMutableData appendData:]
|
+-- -[MFMutableData appendBytes:length:]
|
+-- -[MFMutableData _mapMutableData]Анализируя поток кода, мы определили следующее:
- Функция [MFDAMessageContentConsumer consumeData:length:format:mailMessage:] вызывается при загрузке электронной почты в необработанной форме MIME, а также будет вызываться несколько раз, пока электронная почта не будет загружена в режиме Exchange. Он создаст новый NSMutableData объект и вызовет appendData: для любых новых потоковых данных, принадлежащих тому же сообщению электронной почты / MIME. Для других протоколов, таких как IMAP, он использует -[MFConnection readLineIntoData:] вместо этого, но логика и уязвимость одинаковы.
- NSMutableData устанавливает пороговое значение 0x200000 байта, если данные больше 0x200000 байтов, они записывают данные в файл, а затем используют mmap системный вызов для сопоставления файла в памяти устройства. Пороговый размер 0x200000 можно легко изменить, поэтому каждый раз, когда необходимо добавить новые данные, файл будет повторно отображаться в mmap, и размер файла, а также размер mmap будут увеличиваться и увеличиваться.
- Переопределение выполняется внутри -[MFMutableData _mapMutableData:], уязвимость внутри этой функции.
-[MFMutableData _mapMutableData:] вызывает функцию MFMutableData__mapMutableData___block_invoke при сбое системного вызова mmap
Код:
-[MFMutableData _mapMutableData:]
{
//...
result = mmap(0LL, v8, v9, 2, v6, 0LL);
if (result == -1){
//...
result = (void *)MFMutableData__mapMutableData___block_invoke(&v21);
}
//...
}Псевдокод MFMutableData__mapMutableData___block_invoke выглядит следующим образом, он выделяет память 8 размера кучи, затем заменяет указатель data-> bytes на выделенную память.
Код:
void MFMutableData__mapMutableData___block_invoke(__int64 data)
{
__int64 result; // x0
data->vm = 0;
data->length = 0;
data->capacity = 8; // Reset MFMutableData capacity to 8
result = calloc(data->capacity, 1); // Allocate a new piece of memory, size of 8
data->bytes = result; // replace the mapping memory pointer, which overwrites the -1 in case of mmap failure.
return result;
}После выполнения команды -[MFMutableData _mapMutableData:] процесс продолжает выполнение команды -[MFMutableData appendBytes:length:], вызывая переполнение кучи при копировании данных в выделенную память.
Код:
-[MFMutableData appendBytes:length:]
{
int length = [self length];
//...
bytes = self->bytes;
if(!bytes){
bytes = [self _mapMutableData]; //Might be a data pointer of a size 8 heap
}
copy_dst = bytes + length;
//...
platform_memmove(copy_dst, append_bytes, append_length); // It used append_length to copy the memory, causing an OOB writing in a small heap
}append_length - длина фрагмента данных из потоковой передачи. Поскольку MALLOC_NANO это очень предсказуемая область памяти, эту уязвимость можно использовать.
Злоумышленнику не нужно истощать каждый последний бит памяти, чтобы вызвать сбой mmap, поскольку mmap требует непрерывной области памяти.
Воспроизведение
Согласно справочной странице mmap, при указании MAP_ANON и недостаточном объеме памяти, mmap не будет работать.
Цель заключается в вызове сбоя mmap, что в идеале, при достаточно большом письме неизбежно приведет к этому. Однако мы считаем, что уязвимости могут быть вызваны другими уловками, которые могут истощить ресурсы. Такие трюки можно реализовать с помощью многочастны форматов, RTF и других форматов - подробнее об этом позже.
Другим важным фактором, который может повлиять на уязвимость, являются технические характеристики оборудования:
- iPhone 6 имеет 1 ГБ
- iPhone 7 имеет 2 ГБ
- iPhone X имеет 3 ГБ
Мы определили, что MacOS не уязвим для обеих уязвимостей.
В iOS 12 эту уязвимость проще запустить, так как поток данных осуществляется в рамках того же процесса, что и почтовое приложение по умолчанию (MobileMail), оно работает со значительно большим количеством ресурсов, что "съедает" выделение виртуального пространства памяти, особенно рендеринг пользовательского интерфейса, в то время как в iOS 13, MobileMail передает поток данных в фоновом процессе, а именно в maild. Она концентрирует свои ресурсы на разборе электронной почты, что снижает риск случайного исчерпания пространства виртуальной памяти.
Удаленное воспроизведение/POC
Так как MobileMail / maild явно не устанавливали максимальный предел для размера электронной почты, можно настроить собственный почтовый сервер и отправить электронное письмо, содержащее несколько ГБ простого текста. Библиотека iOS MIME / Message объединяет данные в среднем примерно 0x100000 байтов во время потоковой передачи данных, поэтому не удается загрузить всю электронную почту полностью.
Обратите внимание, что это только один из примеров того, как вызвать эту уязвимость. Злоумышленникам не нужно отправлять такое электронное письмо, чтобы вызвать эту уязвимость, и другие приемы с многочастным форматом, RTF или другими форматами могут выполнить ту же задачу с электронным письмом стандартного размера.
Показатели компромисса
| # | Вид показателя | Предназначение | IOC |
|---|---|---|---|
| 1 | String in raw email | Part of the malicious email sent | AAAAAAAA и AAAAATEy и EA\r\nAABI и "$\x0e\xce\xa0\xd4\xc7\xcb\x08" и T8hlGOo9 и OKl2N\r\nC (обнавлено) |
| 3 | String in raw email | Part of the malicious email sent | 3r0TRZfh и AAAAAAAAAAAAAAAA и \x0041\x0041\x0041\x0041 (unicode AAAA) (обналвено) |
| 4 | String in raw email | Part of the malicious email sent | \n/s1Caa6 и J1Ls9RWH |
| 5 | String in raw email | Part of the malicious email sent | ://44449 |
| 6 | String in raw email | Part of the malicious email sent | ://84371 |
| 7 | String in raw email | Part of the malicious email sent | ://87756 |
| 8 | String in raw email | Part of the malicious email sent | ://94654 |
Патч
Apple исправил обе уязвимости в iOS 13.4.5 beta, как показано на следующем скриншоте ниже:
Для устранения этих проблем - вы можете использовать последнюю доступную бета-версию. Если использование бета-версии невозможно, рассмотрите возможность отключения приложения Mail и используйте Outlook, Edison Mail или Gmail, которые не являются уязвимыми.
Сроки раскрытия информации
- 19 февраля 2020 г. - Подозреваемые события сообщаются поставщику в соответствии с политикой раскрытия информации ZecOps, которая позволяет немедленно выпускать триггеры
- Постоянное общение между затронутым поставщиком и ZecOps
- 23 марта - ZecOps отправил пострадавшему поставщику POC-репродукцию уязвимости OOB записи
- 25 марта - ZecOps поделился локальным POC для записи OOB
- 31 марта - ZecOps подтвердил, что в той же области существует вторая уязвимость и возможность удаленного триггера (Remote Heap Overflow) - обе уязвимости были вызваны на реальных компьютерах
- 31 марта - ZecOps поделился POC с уязвимым поставщиком для уязвимости удаленного переполнения кучи
- 7 апреля - ZecOps поделился собственным почтовым сервером, чтобы вызвать уязвимость переполнения кучи в zero-click на iOS 13.4 / 13.4.1, просто добавив имя пользователя и пароль в Mail и загрузив электронные письма.
- 15-16 апреля - Поставщик исправляет обе уязвимости в общедоступной бета-версии
- 20 апреля - Мы повторно проанализировали данные и обнаружили дополнительные свидетельства триггеров на компьютерах VIP-персон и целевых персон. Мы отправили электронное письмо, уведомляющее поставщика о том, что нам придется немедленно выпустить эту рекомендацию по угрозам, чтобы организации могли защитить себя, поскольку злоумышленники, вероятно, значительно увеличат свою активность, когда это было исправлены в бета-версии.
- 22 апреля - Публичный отчет
Часто задаваемые вопросы
В: Использовалась ли первая и/или вторая уязвимость на практике?
О: Кодовые тригеры подозреваемых электронных писем вызвали обе уязвимости, однако мы считаем, что первая уязвимость (OOB Write) была вызвана случайно, и основной целью было вызвать вторую уязвимость (Remote Heap Overflow).
- Мы видели несколько триггеров на одних и тех же пользователях на разных континентах.
- Мы исследовали подозрительные строки и первопричину (например, события 414141… 41 и в основном другие события):
- Мы подтвердили, что этот путь кода не запускается случайным образом.
- Мы подтвердили, что значения регистров не были получены целевым ПО или ОС.
- Мы подтвердили, что это не было упражнение для red team/тесты POC.
- Мы подтвердили, что контролируемые указатели, содержащие 414141…41, а также другую контролируемую память, были частью данных, отправленных по электронной почте на устройство жертвы.
- Мы убедились, что ошибки могут быть использованы удаленно и воспроизвели триггер.
- Мы увидели сходство между шаблонами, используемыми, по крайней мере, для пары жертв, отправленных одним и тем же злоумышленником.
- Где это возможно, мы подтверждаем, что размер распределения был преднамеренным.
- Наконец, мы убедились, что подозрительные электронные письма были получены и обработаны устройством - согласно трассировке стека, и это должно было быть на устройстве/почтовом сервере. По возможности вместе с жертвами мы проверяли, что электронные письма были удалены.
В: Должен ли злоумышленник сначала активировать первую уязвимость, чтобы вызвать вторую?
О: Нет. Злоумышленник, вероятнее всего, будет нацелен на вторую уязвимость.
В: Почему вы раскрываете эти ошибки до того, как будет доступно полное исправление?
О: Важно понимать следующее:
- Эти ошибки сами по себе не могут причинить вред пользователям iOS - поскольку злоумышленникам потребуется дополнительная ошибка утечки информации и ошибка ядра для полного контроля над целевым устройством.
- Обе ошибки уже были раскрыты во время общедоступного бета-обновления. Злоумышленники уже знают, что такую редкую возможность с MobileMail/maild почти нереально получить, и они, вероятнее всего, будут использовать время до появления патча, чтобы атаковать как можно больше устройств.
- Имея очень ограниченные данные, мы смогли увидеть, что как минимум шесть организаций пострадали от этой уязвимости - и потенциальное злоупотребление этой уязвимостью колосально. Мы уверены, что патч должен быть предоставлен для таких проблем с открытыми триггерами как можно скорее.
Мы надеемся, что с обнародованием этой информации поможем продвинуть более свежий патч.
В: Могут ли обе уязвимости быть запущены удаленно?
О: Доказано, что удаленное переполнение кучи позволяет запускать удаленно без какого-либо взаимодействия с пользователем (так называемый «zero-click») на iOS13. Запись OOB может быть инициирована удаленно с помощью дополнительной уязвимости, которая позволяет вызывать произвольный селектор, как тот, который опубликован в Google Project Zero здесь:
Ссылка скрыта от гостей
- так как мы видели, триггер первой уязвимости возможен, хотя мы считаем, что это было сделано по ошибке (см. выше).В: Требуют ли конечные пользователи каких-либо действий для успешной эксплуатации?
О: На iOS 13 - нет. На iOS 12 - требуется, чтобы жертва щелкнула по электронной почте.
Если злоумышленник контролирует почтовый сервер, атака может быть выполнена без каких-либо кликов на iOS 12.
В: С каких это пор iOS уязвима для этих ошибок?
О: iOS уязвима к этим ошибкам, по крайней мере, с iOS 6 (сентябрь 2012 г.). Мы не проверяли более ранние версии.
В: Что вы можете сделать, чтобы смягчить уязвимость:
О: Недавно выпущенное бета-обновление 13.4.5 содержит патч для этих уязвимостей. Если вы не можете установить исправление для этой версии вместо использования приложения Почта, рассмотрите возможность использования других почтовых приложений, пока не станет доступно исправление GA.
В: Нужно ли злоумышленнику отправлять очень большое письмо (например, 1-3 ГБ), чтобы вызвать уязвимость?
О: Нет. Злоумышленники могут использовать трюки с много-форматным файлом/RTF и т. д., чтобы подобным образом использовать память без отправки большого электронного письма.
В: Требуется ли для уязвимости дополнительная информация, чтобы добиться успеха?
О: Да, злоумышленнику потребуется утечка адреса из памяти, чтобы обойти ASLR. Мы не фокусировались на этой уязвимости в нашем исследовании.
В: Что допускает уязвимость:
О: Уязвимость позволяет запускать удаленный код в контексте MobileMail (iOS 12) или maild (iOS 13). Успешное использование этой уязвимости позволит злоумышленнику перенаправлять, изменять и удалять электронные письма. Дополнительная уязвимость ядра обеспечит полный доступ к устройству - мы подозреваем, что у этих злоумышленников была другая уязвимость. В настоящее время ведется расследование.
В: Заметят ли конечные пользователи какое-либо ненормальное поведение после того, как одна из уязвимостей будет запущена/использована?
О: Помимо временного замедления работы приложения мобильной почты, пользователи не должны наблюдать никаких других аномальных действий.
Когда эксплойт терпит неудачу на iOS 12 - пользователи могут заметить внезапный сбой почтового приложения.
На iOS13, кроме временного замедления, это не будет заметно. Неудачные атаки не будут заметны на iOS 13, если впоследствии будет проведена другая атака, удаляющая электронную почту. В случае неудачных атак на электронные письма, которые будут отправлены злоумышленником, будет показано сообщение: "This message has no content." Как показано на следующем рисунке ниже:
В: Если злоумышленники не справляются, могут ли они сразу же после этого повторить попытку атаки, используя ту же самую уязвимость?
О: На iOS 13 злоумышленники могут несколько раз попытаться заразить устройство бесшумно и без вмешательства пользователя. На iOS 12 - дополнительная попытка потребует от пользователя кликнуть на новое письмо, полученное злоумышленниками. Жертве не нужно открывать вложение, достаточно просто просмотреть электронное письмо, чтобы спровоцировать атаку.
В: Могут ли злоумышленники удалить полученное письмо после того, как оно было обработано устройством и вызвало уязвимость?
A: Да.
В: MacOS также уязвим к этим уязвимостям?
A: Нет.
Последнее редактирование:
