Статья MailDemon — Техника, Тригеры и Bounty

Данная статья является переводом. Оригинал вот
Ссылка скрыта от гостей
Нажмите, чтобы раскрыть...

Воздействие и ключевые детали (TL;DR)
  1. Демонстрация обычной heap spraying атаки.
  2. Мы смогли использовать эту технику, чтобы убедиться, что эта уязвимость является эксплуатируемой. Мы все еще работаем над этим.
  3. Представление двух новых примеров практичных триггеров, чтобы вы могли сами понять, стоят ли эти ошибки вне патча.
  4. Предложения Apple о том, как улучшить форенсик-информацию / логи и важные вопросы после их ответа на предыдущий disclosure.
  5. Запуск bug-bounty программы для людей, у которых есть трассировки атак, с общей суммой вознаграждения 27 337$
  6. MailDemon на самом деле не такой уж и новый, как мы думали изначально. Существует триггер для этой уязвимости, которому 10 лет, на iPhone 2g, iOS 3.1.3

1592578195230.png


Мы
Ссылка скрыта от гостей
об обнаружении уязвимостей RCE в стандартном почтовом приложении на iOS. Позже, с нами связалось много людей, которые подозревали, что на них была нацелена эта и другие уязвимости в приложении Mail.

ZecOps призывает Apple выпустить out of band исправление для недавно обнаруженных уязвимостей и надеется, что эта статья предоставит дополнительное подкрепление для релиза патчей как можно раньше. В данной статье мы покажем простой способ heap spraying, с помощью которого мы смогли доказать, что дистанционная эксплуатация может создавать возможные проблемы, и мы также предоставим два примера триггеров, наблюдаемых на практике.

В настоящее время у нас уже есть следующее:
  • Удаленное переполнение кучи в приложении Mail.
  • Возможность удаленной активации уязвимости с помощью контролируемого злоумышленником ввода входящей почты.
  • Возможность изменить выполнение кода.
  • Повышение привилегий ядра с помощью 0day.
Чего у нас нет:
  • Информационная утечка - но в этом заключается сюрприз: информационная утечка не обязательно должна быть в Mail, так как информационной утечки почти в любом другом процессе было бы достаточно. Поскольку dyld_shared_cache используется большинством процессов, утечка не обязательно должна быть внутри MobileMail, например,
    Ссылка скрыта от гостей
    под iMessage также может выполнять подобный прием, что дает больше пространства для дальнейших атак (Facetime, другие приложения, iMessage и так далее). Есть
    Ссылка скрыта от гостей
    во время OffensiveCon, демонстрирующая аналогичные темы.
Поэтому теперь у нас есть все требования к удаленному использованию этого бага. Тем не менее, нам следует быть осторожными, чтобы связать это все вместе, потому что:
  • Мы не намерены раскрывать LPE - это позволяет нам выполнять извлечение файловой системы / проверку памяти на устройствах A12 и выше, когда это необходимо. Подробнее о проблемах анализа мобильных устройств вы можете прочитать на
    Ссылка скрыта от гостей
  • Мы не замечали эксплуатации на практике для LPE.
Мы также поделимся двумя примерами триггеров, которые мы видели на практике, и позволим вам сделать свои собственные умозаключения и выводы.


MailDemon Bounty

Наконец, мы представим bounty за те материалы, которые смогли продемонстрировать, что на них было совершено нападение.

1592579302978.png



Эксплуатация MailDemon

Как мы уже упоминали раннее, MailDemon является отличным кандидатом для эксплуатации, поскольку он перезаписывает небольшие фрагменты памяти MALLOC_NANO, в которой хранится большое количество объектов Objective-C. Следовательно, он позволяет злоумышленникам манипулировать указателем ISA-сервера на поврежденные объекты (позволяя им вызывать путаницу типов) или перезаписывать указатель функции для управления потоком кода процесса. Это представляет собой жизнеспособный подход, позволяющий взять на себя управление поврежденным процессом.

Heap Spraying и Heap Grooming техники

Для управления потоком кода требуется heap spraying для помещения созданных данных в память. С помощью распределения поддельного класса, содержащего кэш ненастоящего метода и метода 'dealloc', мы смогли контролировать Program Counter (PC) регистр после срабатывания уязвимости с помощью этого метода*.

Ниже приведен частичный лог сбоев, созданный во время тестирования нашего POC:

Код: 
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Subtype: EXC_ARM_DA_ALIGN at 0xdeadbeefdeadbeef
VM Region Info: 0xdeadbeefdeadbeef is not in any region.  Bytes after previous region: 16045690973559045872
      REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      MALLOC_NANO            0000000280000000-00000002a0000000 [512.0M] rw-/rwx SM=PRV
--->
      UNUSED SPACE AT END

Thread 18 name:  Dispatch queue: com.apple.CFNetwork.Connection
Thread 18 Crashed:
0   ???                               0xdeadbeefdeadbeef 0 + -2401053088876216593
1   libdispatch.dylib                 0x00000001b7732338 _dispatch_lane_serial_drain$VARIANT$mp  + 612
2   libdispatch.dylib                 0x00000001b7732e74 _dispatch_lane_invoke$VARIANT$mp  + 480
3   libdispatch.dylib                 0x00000001b773410c _dispatch_workloop_invoke$VARIANT$mp  + 1960
4   libdispatch.dylib                 0x00000001b773b4ac _dispatch_workloop_worker_thread  + 596
5   libsystem_pthread.dylib           0x00000001b796a114 _pthread_wqthread  + 304
6   libsystem_pthread.dylib           0x00000001b796ccd4 start_wqthread  + 4


Thread 18 crashed with ARM Thread State (64-bit):
    x0: 0x0000000281606300   x1: 0x00000001e4b97b04   x2: 0x0000000000000004   x3: 0x00000001b791df30
    x4: 0x00000002827e81c0   x5: 0x0000000000000000   x6: 0x0000000106e5af60   x7: 0x0000000000000940
    x8: 0x00000001f14a6f68   x9: 0x00000001e4b97b04  x10: 0x0000000110000ae0  x11: 0x000000130000001f
   x12: 0x0000000110000b10  x13: 0x000001a1f14b0141  x14: 0x00000000ef02b800  x15: 0x0000000000000057
   x16: 0x00000001f14b0140  x17: 0xdeadbeefdeadbeef  x18: 0x0000000000000000  x19: 0x0000000108e68038
   x20: 0x0000000108e68000  x21: 0x0000000108e68000  x22: 0x000000016ff3f0e0  x23: 0xa3a3a3a3a3a3a3a3
   x24: 0x0000000282721140  x25: 0x0000000108e68038  x26: 0x000000016ff3eac0  x27: 0x00000002827e8e80
   x28: 0x000000016ff3f0e0   fp: 0x000000016ff3e870   lr: 0x00000001b6f3db9c
    sp: 0x000000016ff3e400   pc: 0xdeadbeefdeadbeef cpsr: 0x60000000

В этом случае идеальным примитивом для heap spraying является ошибкой утечки памяти, которая можно вызвать удаленно, поскольку мы хотим, чтобы распределенная память оставалась нетронутой до тех пор, пока не произойдет её повреждения. Мы оставили это как упражнение для читателя. Такой примитив может претендовать на вознаграждение до 7,337 от ZecOps (подробнее читайте ниже).

Другим способом является использование самого MFMutableData - когда размер MFMutableData меньше 0x20000 байт, он выделяет память из кучи вместо создания файла для хранения содержимого. И мы можем контролировать размер MFMutableData, разбивая содержимое письма на строки размером менее 0x20000 байт, поскольку библиотека IMAP читает содержимое письма строками. С таким примитивом у нас больше шансов разместить пейлоад по нужному нам адресу.

1592580353965.png


Триггер

Огромное электронное письмо способно воспроизвести уязвимость в виде PoC (подробности см. в нашей
Ссылка скрыта от гостей
), но для стабильного эксплойта нам нужно более подробно рассмотреть "-[MFMutableData appendBytes:length:]".

Код: 
-[MFMutableData appendBytes:length:]
{
  int old_len = [self length];
  //...
  char* bytes = self->bytes;
  if(!bytes){
     bytes = [self _mapMutableData]; //Might be a data pointer of a size 8 heap
  }
  copy_dst = bytes + old_len;
  //...
  memmove(copy_dst, append_bytes, append_length); // It used append_length to copy the memory, causing an OOB writing in a small heap
}

Адрес назначения memove - "bytes + old_len" вместо "bytes". Так что же произойдет, если мы накопим слишком много данных перед вызовом уязвимости? «old_len» будет иметь огромное значение, так что адрес назначения окажется в недопустимом адресе, который находится за пределами этой области, и сразу же каршнется, учитывая, что размер области MALLOC_NANO равен 512 МБ.

Код: 
             +----------------+0x280000000
             |                |
   bytes --> +----------------+\
             |                | +
             |                | |
             |                | |
             |    padding     | |
             |                | |
             |                | | old_len
             |                | |
             |                | |
             |                | |
             |                | +
copy_dst --> +----------------+/
             | overflow data  |
             +----------------+
             |                |
             |                |
             |                |
             |                |
             +----------------+0x2a0000000

Чтобы уменьшить размер заполнения, нам нужно использовать как можно больше данных, прежде чем запускать уязвимость - утечка памяти будет одним из наших кандидатов.

Следует отметить, что «заполнение» не означает, что адрес переполнения является абсолютно случайным, «заполнение» предсказуемо аппаратными моделями, поскольку размер ОЗУ одинаков, а в наших тестах mmap обычно выходит из строя с тем же размером.


Анализ сбоев

В этом посте будут обсуждаться несколько триггеров и эксплуатационные возможности уязвимости MobileMail, обнаруженной на практике, о которой мы рассказывали в предыдущей
Ссылка скрыта от гостей
.

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

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

Первый случай

Следующее краш был вызван прямо внутри уязвимой функции во время переполнения.

Код: 
Coalition:           com.apple.mobilemail [521]

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000004a35630e //[a]
VM Region Info: 0x4a35630e is not in any region.  Bytes before following region: 3091946738
      REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->
      __TEXT                 000000010280c000-0000000102aec000 [ 2944K] r-x/r-x SM=COW  ...p/MobileMail]


Thread 4 Crashed:
0   libsystem_platform.dylib          0x00000001834a5a80 _platform_memmove  + 208
       0x1834a5a74         ldnp x10, x11, [x1, #16]     
       0x1834a5a78         add x1, x1, 0x20             
       0x1834a5a7c         sub x2, x2, x5               
       0x1834a5a80         stp x12, x13, [x0]   //[b]       
       0x1834a5a84         stp x14, x15, [x0, #16]     
       0x1834a5a88         subs x2, x2, 0x40           
       0x1834a5a8c         b.ls 0x00002ab0 

1   MIME                              0x00000001947ae104 -[MFMutableData appendBytes:length:]  + 356
2   Message                           0x0000000194f6ce6c -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:]  + 804
3   DAEAS                             0x000000019ac5ca8c -[ASAccount folderItemsSyncTask:handleStreamOperation:forCodePage:tag:withParentItem:withData:dataLength:]  + 736
4   DAEAS                             0x000000019aca3fd0 -[ASFolderItemsSyncTask handleStreamOperation:forCodePage:tag:withParentItem:withData:dataLength:]  + 524
5   DAEAS                             0x000000019acae338 -[ASItem _streamYourLittleHeartOutWithContext:]  + 440
6   DAEAS                             0x000000019acaf4d4 -[ASItem _streamIfNecessaryFromContext:]  + 96
7   DAEAS                             0x000000019acaf758 -[ASItem _parseNextValueWithDataclass:context:root:parent:callbackDict:streamCallbackDict:parseRules:account:]  + 164
8   DAEAS                             0x000000019acb001c -[ASItem parseASParseContext:root:parent:callbackDict:streamCallbackDict:account:]  + 776
9   DAEAS                             0x000000019acaf7d8 -[ASItem _parseNextValueWithDataclass:context:root:parent:callbackDict:streamCallbackDict:parseRules:account:]  + 292
10  DAEAS                             0x000000019acb001c -[ASItem parseASParseContext:root:parent:callbackDict:streamCallbackDict:account:]  + 776
...

Thread 4 crashed with ARM Thread State (64-bit):
    x0: 0x000000004a35630e   x1: 0x00000001149af432   x2: 0x0000000000001519   x3: 0x000000004a356320
    x4: 0x0000000100000028   x5: 0x0000000000000012   x6: 0x0000000c04000100   x7: 0x0000000114951a00
    x8: 0x44423d30443d3644   x9: 0x443d30443d38463d  x10: 0x3d31413d31443d30  x11: 0x31413d31463d3444
   x12: 0x33423d30453d3043  x13: 0x433d30443d35423d  x14: 0x3d30443d36443d44  x15: 0x30443d38463d4442
   x16: 0x00000001834a59b0  x17: 0x0200080110000100  x18: 0xfffffff00a0dd260  x19: 0x000000000000152b
   x20: 0x00000001149af400  x21: 0x000000004a35630e  x22: 0x000000004a35630f  x23: 0x0000000000000008
   x24: 0x000000000000152b  x25: 0x0000000000000000  x26: 0x0000000000000000  x27: 0x00000001149af400
   x28: 0x000000018dbd34bc   fp: 0x000000016da4c720   lr: 0x00000001947ae104
    sp: 0x000000016da4c720   pc: 0x00000001834a5a80 cpsr: 0x80000000

С помощью [a] и мы знаем, что процесс завершился сбоем внутри «memmove», вызываемого «- [MFMutableData appendBytes: length:]», и означает, что значение «copy_dst» является недопустимым адресом на первом месте, которым является 0x4a35630e.

Так откуда же взято значение регистра x0 (0x4a35630e)? Это намного меньше, чем самый небольшой действительный адрес.

Оказывается, что процесс завершился сбоем одновременно после неудачной попытки вызвать файл, и после ошибки во время выделения 8-байтовой памяти.

Неверный адрес 0x4a35630e на самом деле смещение, которое является длиной MFMutableData до запуска уязвимости (то есть «old_len»). Когда calloc не может выделить память, он возвращает NULL, поэтому copy_dst будет «0 + old_len (0x4a35630e)».

В этом случае «old_len» составляет около 1,2 ГБ, что соответствует средней длине нашего POC, которое может вызвать сбой mmap и уязвимость.

Обратите внимание, что x8-x15 и x0 полностью контролируются отправителем.

Сбой дает нам еще один ответ на вышеприведенный вопрос: "Что, если мы соберем слишком много данных до того, как сработает уязвимость?" - Выделение 8-байтной памяти может привести к сбою и аварийному завершению работы при копировании пейлоада по некорректному адресу. Это может помешать эксплуатации, так как можно крашнуть программу до получения доступа к счетчику программы.

Привет из прошлого: таинственный триггер на iOS 3.1.3 в 2010 году!

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


Уязвимая версия: iOS 3.1.3 на iPhone 2G
Время сбоя: 22 октября 2010 г.

Пользователь "shyamsandeep", зарегистрировавшийся 12 июня 2008 года и последний раз заходивший в систему 16 октября 2011 года, имел одно сообщение на форуме, которое содержало именно этот триггер.

Этот краш имел значение r0, равное 0x037ea000, что могло быть результатом первой уязвимости, о которую мы писали в предыдущем блоге, и которая была вызвана отказом функции ftruncate().

Интересно, что, как мы объясняли в первом случае, это также могло быть результатом выделения 8-байтового отказа памяти, однако точную причину определить невозможно, поскольку в логах не было информации об областях памяти. Тем не менее, очевидно, что с 2010 года существовали триггеры для эсплуатации этой уязвимости.

Код: 
Identifier: MobileMail
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]

Date/Time: 2010-10-22 08:14:31.640 +0530
OS Version: iPhone OS 3.1.3 (7E18)
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x037ea000 Crashed Thread: 4
Thread 4 Crashed:
0 libSystem.B.dylib 0x33aaef3c 0x33aad000 + 7996 //memcpy + 0x294
1 MIME 0x30a822a4 0x30a7f000 + 12964 //_FastMemoryMove + 0x44
2 MIME 0x30a8231a 0x30a7f000 + 13082 // -[MFMutableData appendBytes:length:] + 0x6a
3 MIME 0x30a806d6 0x30a7f000 + 5846 // -[MFMutableData appendData:] + 0x32
4 Message 0x342e2938 0x34251000 + 596280 // -[DAMessageContentConsumer consumeData:length:format:mailMessage:] + 0x25c
5 Message 0x342e1ff8 0x34251000 + 593912 // -[DAMailAccountSyncConsumer consumeData:length:format:mailMessage:] +0x24
6 DataAccess 0x34146b22 0x3413e000 + 35618 // -[ASAccount
folderItemsSyncTask:handleStreamOperation:forCodePage:tag:withParentItem:withData:dataLength:] + 0x162
7 DataAccess 0x3416657c 0x3413e000 + 165244 //[ASFolderItemsSyncTaskhandleStreamOperation:forCodePage:tag:withParentIt em:withData:dataLength:] + 0x108
...

Thread 4 crashed with ARM Thread State:
r0: 0x037ea000 r1: 0x008729e0 r2: 0x00002205 r3: 0x4e414153
r4: 0x41415367 r5: 0x037e9825 r6: 0x00872200 r7: 0x007b8b78
r8: 0x0001f825 r9: 0x001fc098 r10: 0x00872200 r11: 0x0087c200
ip: 0x0000068a sp: 0x007b8b6c lr: 0x30a822ab pc: 0x33aaef3c
cpsr: 0x20000010

Второй случай 2

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

Код: 
Coalition:           com.apple.mobilemail [308]

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0041004100410041 // [a]
VM Region Info: 0x41004100410041 is not in any region.  Bytes after previous region: 18296140473139266
      REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      mapped file            00000002d31f0000-00000002d6978000 [ 55.5M] r--/rw- SM=COW  ...t_id=9bfc1855
--->
      UNUSED SPACE AT END

Thread 13 name:  Dispatch queue: Internal _UICache queue
Thread 13 Crashed:
0   libobjc.A.dylib                   0x00000001b040fca0 objc_release  + 16
       0x1b040fc94         mov x29, sp                  
       0x1b040fc98         cbz x0, 0x0093fce4            
       0x1b040fc9c         tbnz x0, #63, 0x0093fce4      
       0x1b040fca0         ldr x8, [x0]            // [b]      
       0x1b040fca4         and x8, x8, 0xffffffff8      
       0x1b040fca8         ldrb w8, [x8, #32]            
       0x1b040fcac         tbz w8, #2, 0x0093fd14        

1   CoreFoundation                    0x00000001b1119408 -[__NSDictionaryM removeAllObjects]  + 600
2   libdispatch.dylib                 0x00000001b0c5d7d4 _dispatch_client_callout  + 16
3   libdispatch.dylib                 0x00000001b0c0bc1c _dispatch_lane_barrier_sync_invoke_and_complete  + 56  
4   UIFoundation                      0x00000001bb9136b0 __16-[_UICache init]_block_invoke  + 76    
5   libdispatch.dylib                 0x00000001b0c5d7d4 _dispatch_client_callout  + 16
6   libdispatch.dylib                 0x00000001b0c0201c _dispatch_continuation_pop$VARIANT$mp  + 412
7   libdispatch.dylib                 0x00000001b0c11fa8 _dispatch_source_invoke$VARIANT$mp  + 1308
8   libdispatch.dylib                 0x00000001b0c0ee00 _dispatch_kevent_worker_thread  + 1224  
9   libsystem_pthread.dylib           0x00000001b0e3e124 _pthread_wqthread  + 320        
10  libsystem_pthread.dylib           0x00000001b0e40cd4 start_wqthread  + 4


Thread 13 crashed with ARM Thread State (64-bit):
    x0: 0x0041004100410041   x1: 0x00000001de1ac18a   x2: 0x0000000000000000   x3: 0x0000000000000010
    x4: 0x00000001b0c60388   x5: 0x0000000000000010   x6: 0x0000000000000000   x7: 0x0000000000000000
    x8: 0x0000000281f94090   x9: 0x00000001b143f670  x10: 0x0000000142846800  x11: 0x0000004b0000007f
   x12: 0x00000001428468a0  x13: 0x000041a1eb487861  x14: 0x0000000283ed9d10  x15: 0x0000000000000004
   x16: 0x00000001eb487860  x17: 0x00000001b11191b0  x18: 0x0000000000000000  x19: 0x0000000281dce4c0
   x20: 0x0000000282693398  x21: 0x0000000282693330  x22: 0x0000000000000000  x23: 0x0000000000000000
   x24: 0x0000000281dce4c8  x25: 0x000000000c000000  x26: 0x000000000000000d  x27: 0x00000001eb48e000
   x28: 0x0000000282693330   fp: 0x000000016b8fe820   lr: 0x00000001b1119408
    sp: 0x000000016b8fe820   pc: 0x00000001b040fca0 cpsr: 0x20000000

[a]: Указатель объекта был перезаписан на "0x0041004100410041", в перевода на Unicode - AAAAA.

[b] - это одна из инструкций относительно адреса сбоя, которую мы добавили для лучшего понимания, процесс завершился сбоем по команде «ldr x8, [x0]», в то время как - [__ NSDictionaryM removeAllObjects] пытался освободить один из объектов.

При реверсе [__ NSDictionaryM removeAllObjects], мы понимаем, что регистр x0 был загружен из x28 (0x0000000282693330), поскольку регистр x28 никогда не изменялся до сбоя.

1592582499363.png


Давайте посмотрим на информацию об области виртуальной памяти x28: 0x0000000282693330, перезаписанный объект был сохранен в области MALLOC_NANO, в которой хранятся небольшие куски кучи. Уязвимость переполнения кучи приводит к повреждению той же области, поскольку она переполняется в 8-байтовом блоке кучи, который также хранится в MALLOC_NANO.

Код: 
MALLOC_NANO              0x0000000280000000-0x00000002a0000000     rw-/rwx

Этот сбой на самом деле очень близок к управлению ПК, так как он управляет указателем объекта Objective-C. Указав значение регистра x0 на память, заполненную поддельным объектом и классом с поддельным кешем методов, злоумышленники могут контролировать указатель на ПК, эта
Ссылка скрыта от гостей
объясняет подробности.

Итог
  1. Редко можно увидеть, что предоставленные пользователем входные тригеры запускают и контролируют удаленные уязвимости.
  2. Мы доказали, что эту уязвимость можно использовать, по описанной методике.
  3. Мы наблюдали за триггеры на практике с большим размером размещения.
  4. Мы увидели действительные триггеры, которые встречаются в коде, и которые контролируются отправителем.
  5. Письма, которые мы искали, отсутствовали или были удалены.
  6. Шанс успеха можно улучшить. Эта ошибка существовала еще в 2010 году на устройстве iPhone 2G.
  7. На наш взгляд, исходя из вышеизложенного, эта ошибка заслуживает out of band патча.

Как Apple может улучшить логи?

Недостаток подробностей в логах iOS и отсутствие возможности выбора степени детализации данных для отдельных лиц и организаций необходимо изменить, чтобы iOS соответствовала возможностям MacOS, Linux и Windows. В целом, концепция взлома телефона с целью его анализа, полностью ошибочна и не должна выполняться обычным способом.

Мы предлагаем Apple усовершенствовать процесс диагностики ошибок, чтобы помочь частным лицам, организациям и SOC-отделам исследовать свои устройства. У нас есть несколько полезных технических предложений:

  1. Улучшение сбоев: Включите, чтобы видеть память рядом с каждым указателем
  2. Улучшение сбоев: Показать стек / кучу памяти / память рядом с регистрами
  3. Добавьте PID / PPID / UID / EUID ко всем применимым событиям
  4. Возможность отправлять эти логи на удаленный сервер без физического подключения телефона - нам известно о нескольких случаях, когда логи были удалены
  5. Возможность выполнить полный форенсик-анализ подозреваемых устройств iOS без необходимости сначала взламывать устройство.

Вопросы для Apple
  • Сколько триггеров вы видели в этом переполнении кучи со времен iOS 3.1.3?
  • Как вы смогли в течение одного дня определить, что все триггеры к этой ошибке не являются вредоносными, и действительно ли вы просматривали каждое событие?
  • Когда вы планируете исправить эту уязвимость?
  • Что вы собираетесь делать с улучшением криминалистики на мобильных устройствах (см. список выше)?

MailDemon Bounty

Если у вас возникли какие-либо из трех указанных ниже симптомов, воспользуйтесь другим почтовым приложением (например, Outlook for Desktop) и отправьте соответствующие электронные письма (включая источник электронной почты) на адрес maildemon@zecops.org - в нижней части этого поста есть инструкции.

Подозреваемые электронные письма могут выглядеть следующим образом:

1592583156060.png



1592583422982.png
1592583439801.png
1592583442830.png


Информация о bounty: мы проверим, содержит ли электронная почта код эксплойта. Для первых двух случаев, содержащих эксплойты Mail, которые были проверены командой ZecOps, мы предоставим:
  • 10,000 долларов США
  • Одна лицензия на ZecOps Gluon (DFIR для мобильных устройств) на 1 год
  • Одна лицензия на ZecOps Neutrino (DFIR для конечных точек и серверов) на 1 год.

Мы предоставим дополнительную сумму в размере до $7,337 за примитив эксплойта, как описано выше.

Мы определим, какими были первые две действительные заявки в соответствии с датой их получения на нашем почтовом сервере и содержат ли они код эксплойта. Общая сумма наград и лицензий ZecOps Gluon & Neutrino составляет 27 337 долларов США.

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

Обратите внимание: не каждое письмо, вызывающее вышеуказанные действия будет иметь право на вознаграждение, так как в MobileMail/maild могут быть и другие ошибки - мы ищем только те, которые содержат атаку.


Как отправлять сообщения электронной почты с помощью Outlook:
  1. Откройте Outlook с компьютера и найдите соответствующую электронную почту
  2. Выберите Actions => Other Actions => View Source
  3. И отправьте исходник на maildemon@zecops.org
1592583631705.png


Как отправить подозрительное электронное письмо через Gmail:
  1. Найдите и выберите соответствующее сообщение
  2. Нажмите на три точки «…» в меню и нажмите «Вперед» в качестве вложения.
  3. Отправьте письмо с приложением «.eml» на maildemon@zecops.org
* Пожалуйста, обратите внимание, что мы не опубликовали все детали намеренно. Эта ошибка до сих пор не исправлена, и мы хотим избежать дальнейшего злоупотребления этой ошибкой.

1592583681612.png
 
Нажмите, чтобы раскрыть...
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

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

Верх Низ