Digital Security опровергает связь участника Zeronights с MoneyTaker

Digital Security опровергает связь участника Zeronights с MoneyTaker

Digital Security опровергает связь участника Zeronights с MoneyTaker

В связи с тем, что публикация отчета Group-IB, посвященного группе хакеров MoneyTaker, 11 декабря 2017 года, содержит факты о конференции ZeroNights, компания Digital Security решила внести свои комментарии по этому поводу.

По словам Digital Security, Group-IB предоставила вводящие в заблуждение факты.

«Как видно на скриншотах текстов из Телеграм-канала Group-IB и отчета, выложенного на сайте компании и доступного по ссылке: https://www.group-ib.ru/blog/moneytaker, в аналитике содержится фраза: «Важными «находками», позволившими обнаружить связи между преступлениями, стали программы для повышения привилегий, скомпилированные на основе кодов с российской конференции ZeroNights 2016». Эти слова вызвали волну вопросов и непонимания в среде специалистов по ИБ и представителей СМИ, поскольку позволяли сделать выводы о том, что злоумышленники получили исходный код для зловредного ПО на конференции», — пишет Digital Security в своем официальном ответе.

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

Итак, аргентинским исследователем Enrique Elias Nissim из IOActive был найден способ обхода механизма рандомизации в ядре Windows 10 с помощью атаки по времени (Timing attack).

Далее, он выступил с докладом, посвященным данной находке, в октябре 2016 на Ekoparty #12 (26 октября 2016 - 28 октября 2016): Enrique Nissim - I Know Where Your Page Lives: De-randomizing the Windows 10 Kernel.

Исполняемый файл назывался "ASLRSideChannelAttack.exe", а не "SLRSideChannelAttack.exe", и он был скомпилирован 23 октября 2016. ZeroNights 2016 состоялась 17-18 ноября, (https://2016.zeronights.ru), а исходный код метода обхода ASLR в репозиторий IOActive был выложен уже после выступления на ZN2016 исследователем 23 ноября 2017 (коммит f9e0e7d3e1eb57f82b16226746d36629b97aa804): https://github.com/IOActive/I-know-where-your-page-lives/commit/f9e0e7d3...

Там же доступен и исполняемый файл  "ASLRSideChannelAttack.exe", а не "SLRSideChannelAttack.exe", имеющий дату компиляции - 23 октября 2016.Подчеркнем, что речь идет не о коде вируса, а о методе обхода рандомизации, который, возможно, использовался в ПО злоумышленников (MoneyTaker).

Digital Security рекомендует специалистам компании Group-IB внимательнее относиться к фактчекингу при создании своих отчетов.

Ранее мы писали о том, что Group-IB опубликовала отчет, в котором говорится, что в течение полутора лет русскоговорящая группа киберпреступников MoneyTaker взламывала системы информационной безопасности трех российских банков.

Android запретит доступ к экрану «лишним» приложениям

Google, похоже, готовит ещё одно нововведение по части безопасности Android. В тестовой сборке Android Canary 2602 обнаружена новая функция для Advanced Protection Mode — режима «максимальной защиты», который компания представила в Android 16.

Теперь Advanced Protection Mode может ограничивать работу приложений, использующих AccessibilityService API, если они не классифицированы как инструменты для доступности.

AccessibilityService API — это мощный механизм Android, изначально созданный для помощи людям с ограниченными физическими возможностями. С его помощью приложения могут читать содержимое экрана, отслеживать действия пользователя и даже выполнять жесты от его имени.

Именно поэтому этот API часто становился инструментом атакующих. За последние годы многие приложения — от автоматизаторов и лаунчеров до «оптимизаторов» и антивирусов — использовали его для обхода системных ограничений. Формально ради удобства, однако на деле получая очень широкие права.

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

По данным аналитиков, в новой версии Android Canary  при включении Advanced Protection Mode система:

  • запрещает выдавать разрешение Accessibility Service приложениям, не признанным Accessibility Tools;
  • автоматически отзывает уже выданные разрешения у таких приложений.

Если приложение сильно зависит от этого API, оно просто перестанет работать.

В тестах, например, приложение dynamicSpot (эмулирующее Dynamic Island на Android) становилось недоступным: пункт был с пометкой «Restricted by Advanced Protection». Причина простая: оно использует AccessibilityService для чтения уведомлений и отображения поверх других приложений.

Инструменты, официально классифицированные как средства доступности, под ограничения не попадают.

RSS: Новости на портале Anti-Malware.ru