• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Статья Вы получили zero-click письмо

Данная статья является переводом, оригинал вот

Обновления
  • Мы опубликовали еще одну статью:
  • Уязвимость коснулась даже первого 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 года.


Данная статья является первой частью цикла статей, со второй частью можно ознакомиться

1591803554044.png


1591803610245.png

На сайте можно заполнить анкету и проверить не угрожает ли вам эта уязвимость.


Многочисленные уязвимости в 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 из Саудовской Аравии и Израиля
  • Журналист в Европе
  • Подозреваемый: руководитель швейцарского предприятия
Немного из подозрительных событий включают в себя строки, которые обычно используют хакеры (например, 414141… 4141) - см. FAQ. После проверки на то, что это не было упражнением для red-team, мы подтвердили, что эти строки были предоставлены отправителем электронной почты. Следует отметить, что, хоть данные и подтверждают, что электронные письма об эксплойтах были получены и обработаны устройствами iOS жертв, соответствующие электронные письма, которые должны были быть получены и сохранены на почтовом сервере, все же отсутствовали. Поэтому мы делаем вывод, что эти электронные письма могли быть намеренно удалены как часть мер по обеспечению безопасности.

Мы считаем, что эти атаки соответствуют как минимум одному оператору угрозы национального государства или национальному государству, которое приобрело эксплойт у исследователя 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, если впоследствии будет проведена другая атака, удаляющая электронную почту.

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

1591808513523.png



Анализ сбоя

Часть сбоя (из нескольких сбоев), испытываемого пользователем, заключается в следующем.

Сбой инструкции был 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 ГБ
Старые устройства имеют меньше оперативной памяти и меньший объем виртуальной памяти, поэтому нет необходимости использовать каждый последний бит оперативной памяти, чтобы вызвать эту ошибку, mmap завершится сбоем, когда не сможет найти непрерывную память заданного размера в доступной виртуальной памяти пространства.

Мы определили, что MacOS не уязвим для обеих уязвимостей.

В iOS 12 эту уязвимость проще запустить, так как поток данных осуществляется в рамках того же процесса, что и почтовое приложение по умолчанию (MobileMail), оно работает со значительно большим количеством ресурсов, что "съедает" выделение виртуального пространства памяти, особенно рендеринг пользовательского интерфейса, в то время как в iOS 13, MobileMail передает поток данных в фоновом процессе, а именно в maild. Она концентрирует свои ресурсы на разборе электронной почты, что снижает риск случайного исчерпания пространства виртуальной памяти.


Удаленное воспроизведение/POC

Так как MobileMail / maild явно не устанавливали максимальный предел для размера электронной почты, можно настроить собственный почтовый сервер и отправить электронное письмо, содержащее несколько ГБ простого текста. Библиотека iOS MIME / Message объединяет данные в среднем примерно 0x100000 байтов во время потоковой передачи данных, поэтому не удается загрузить всю электронную почту полностью.

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


Показатели компромисса


#Вид показателяПредназначениеIOC
1String in raw emailPart of the malicious email sentAAAAAAAA и AAAAATEy и EA\r\nAABI и "$\x0e\xce\xa0\xd4\xc7\xcb\x08" и T8hlGOo9 и OKl2N\r\nC (обнавлено)
3String in raw emailPart of the malicious email sent3r0TRZfh и AAAAAAAAAAAAAAAA и \x0041\x0041\x0041\x0041 (unicode AAAA) (обналвено)
4String in raw emailPart of the malicious email sent\n/s1Caa6 и J1Ls9RWH
5String in raw emailPart of the malicious email sent://44449
6String in raw emailPart of the malicious email sent://84371
7String in raw emailPart of the malicious email sent://87756
8String in raw emailPart of the malicious email sent://94654


Патч

Apple исправил обе уязвимости в iOS 13.4.5 beta, как показано на следующем скриншоте ниже:

1591816770066.png


Для устранения этих проблем - вы можете использовать последнюю доступную бета-версию. Если использование бета-версии невозможно, рассмотрите возможность отключения приложения 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 и в основном другие события):
      1. Мы подтвердили, что этот путь кода не запускается случайным образом.
      2. Мы подтвердили, что значения регистров не были получены целевым ПО или ОС.
      3. Мы подтвердили, что это не было упражнение для red team/тесты POC.
      4. Мы подтвердили, что контролируемые указатели, содержащие 414141…41, а также другую контролируемую память, были частью данных, отправленных по электронной почте на устройство жертвы.
    • Мы убедились, что ошибки могут быть использованы удаленно и воспроизвели триггер.
    • Мы увидели сходство между шаблонами, используемыми, по крайней мере, для пары жертв, отправленных одним и тем же злоумышленником.
    • Где это возможно, мы подтверждаем, что размер распределения был преднамеренным.
    • Наконец, мы убедились, что подозрительные электронные письма были получены и обработаны устройством - согласно трассировке стека, и это должно было быть на устройстве/почтовом сервере. По возможности вместе с жертвами мы проверяли, что электронные письма были удалены.
На основании вышеизложенного и другой информации мы полагаем, что эти уязвимости активно использовались в условиях реальный компьютеров.


В: Должен ли злоумышленник сначала активировать первую уязвимость, чтобы вызвать вторую?

О: Нет. Злоумышленник, вероятнее всего, будет нацелен на вторую уязвимость.


В: Почему вы раскрываете эти ошибки до того, как будет доступно полное исправление?

О: Важно понимать следующее:

    • Эти ошибки сами по себе не могут причинить вред пользователям iOS - поскольку злоумышленникам потребуется дополнительная ошибка утечки информации и ошибка ядра для полного контроля над целевым устройством.
    • Обе ошибки уже были раскрыты во время общедоступного бета-обновления. Злоумышленники уже знают, что такую редкую возможность с MobileMail/maild почти нереально получить, и они, вероятнее всего, будут использовать время до появления патча, чтобы атаковать как можно больше устройств.
    • Имея очень ограниченные данные, мы смогли увидеть, что как минимум шесть организаций пострадали от этой уязвимости - и потенциальное злоупотребление этой уязвимостью колосально. Мы уверены, что патч должен быть предоставлен для таких проблем с открытыми триггерами как можно скорее.
Мы обязаны раскрыть эти проблемы общественности, нашим клиентам, партнерам и пользователям iOS по всему миру, чтобы заинтересованные люди могли защитить себя, применив бета-версию патча, или прекратить использовать Mail и временно переключиться на альтернативы, которые не уязвимы для этой ошибки.

Мы надеемся, что с обнародованием этой информации поможем продвинуть более свежий патч.


В: Могут ли обе уязвимости быть запущены удаленно?

О: Доказано, что удаленное переполнение кучи позволяет запускать удаленно без какого-либо взаимодействия с пользователем (так называемый «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." Как показано на следующем рисунке ниже:

1591817775513.png



В: Если злоумышленники не справляются, могут ли они сразу же после этого повторить попытку атаки, используя ту же самую уязвимость?

О: На iOS 13 злоумышленники могут несколько раз попытаться заразить устройство бесшумно и без вмешательства пользователя. На iOS 12 - дополнительная попытка потребует от пользователя кликнуть на новое письмо, полученное злоумышленниками. Жертве не нужно открывать вложение, достаточно просто просмотреть электронное письмо, чтобы спровоцировать атаку.



В: Могут ли злоумышленники удалить полученное письмо после того, как оно было обработано устройством и вызвало уязвимость?

A: Да.


В: MacOS также уязвим к этим уязвимостям?

A: Нет.
 
Последнее редактирование:
  • Нравится
Реакции: Vertigo, Ntlrr и Xulinam

voldim

One Level
10.07.2017
5
1
BIT
0
Вы конечно извините но это тяжело читать. Перевод ужасен. Тупо гугл перевод Ctrl+C -> Ctrl+V. Пытаешься вникнуть в тему уязвимости но вместо этого переводишь с русского на русский. А так тема интересная...
 

g00db0y

Red Team
11.06.2018
139
690
BIT
1
Вы конечно извините но это тяжело читать. Перевод ужасен. Тупо гугл перевод Ctrl+C -> Ctrl+V. Пытаешься вникнуть в тему уязвимости но вместо этого переводишь с русского на русский. А так тема интересная...
Благодарю за отзыв, но если вы нашли опечатки, то процитируйте их, иначе, учите английский и читайте оригинал.
 
  • Нравится
Реакции: Pilger

voldim

One Level
10.07.2017
5
1
BIT
0
Проблема не в опечатках а в построении словосочетаний. Как с "чукчей" общаться: "моя твоя не понимай".

Однако в случае сбоя системного вызова ftruncate, в _flushToDisk любом случае, продолжается, что означает, что размер отображаемого файла не увеличивается, и выполнение, наконец, достигает значения memmove() в appendBytes() функции, вызывая запись в файл mmap out-of-bound (OOB) записи .
Что продолжается???

Мы знаем, что сбой произошла из-за системного ошибки ftruncate(),...
....
И такое по всему тексту. Просто перечитайте и постарайтесть вникнуть. Как будто школьному учителю дали перевести техническую документацию...

PS: И пожалуйста не принимайте это лично на свой счет, мне Ваши статьи интересны, просто такие мелочи очень влияют на восприятие текста...
 
  • Нравится
Реакции: g00db0y

g00db0y

Red Team
11.06.2018
139
690
BIT
1
Проблема не в опечатках а в построении словосочетаний. Как с "чукчей" общаться: "моя твоя не понимай".


Что продолжается???


....
И такое по всему тексту. Просто перечитайте и постарайтесть вникнуть. Как будто школьному учителю дали перевести техническую документацию...

PS: И пожалуйста не принимайте это лично на свой счет, мне Ваши статьи интересны, просто такие мелочи очень влияют на восприятие текста...
Отредактировал.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!