kliMaster

Данный класс представляет собой описание метода ActionScript и содержит указатель на тело функции в памяти по смещению $+4.

В объекте VTable по смещению $+D4 находится описание метода ByteArray::toString(). Имея возможность произвольно читать и писать в память, атакующий способен изменить указатель функции на тело функции (MethodEnv + 4) и благополучно перехватить поток исполнения приложения, выполнив ByteArray::toString().

Такое становится возможным по причине того, что метод данного класса будет вызываться из JIT-кода:

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

Данный метод обхода CFG был исправлен с выходом Adobe Flash Player версии 18.0.0.160 (KB3065820, Июнь 2015). Исправление заключается в следующем: если JIT-функция содержит неявный вызов, то JIT-компилятор вставит вызов процедуры проверки непосредственно перед неявным вызовом.

Любой адрес в пределах тела динамической функции является валидным

Предыдущий метод обхода был возможен из-за недочета в функции, которая производит неявный вызов. А данный метод возможен из-за недочета в функции, которую неявно вызывют.

Исследователи Юрий Дроздов и Людмила Дроздова из Center of Vulnerability Research представили данный метод обхода CFG на конференции Defcon Russia.

Статья:

http://cvr-data.b*l*o*g*spot.ru/2015/07/advanced-cfg-bypass-on-adobe-flash.html

Их метод основан на том факте, что при выделении исполняемой памяти ядро выставляет единичный бит в битовой карте CFG для всей выделенной памяти. Посмотрим, к чему может привести такое поведение.

Предположим, что существует некая JIT-функция по адресу 0x69BC9080, в теле которой находится следующий код:

Что именно делает эта функция, нас не интересует, нужно лишь обратить внимание на 2 байта FF D0 инструкции по адресу 0x69BC90F0. Что будет, если начало функции вдруг сдвинется в середину данной инструкции? Вот что:

FF D0 — не что иное, как call eax! Вот так безобидная на первый взгляд функция превратилась в прекрасную цель для атакующего — неявный вызов без проверки Control Flow Guard. Нужно лишь разобраться с двумя вопросами: как добиться нужной последовательности байтов и как записать в регистр необходимый адрес.

Сгенерировать необходимую последовательность можно, просто экспериментируя с ActionScript-кодом. Стоит лишь учитывать тот факт, что Nanojit (JIT-компилятор AVM) обфусцирует генерируемый код, поэтому легкого пути не будет. Посмотрим, во что превратит Nanojit данную функцию:

public static function useless_func():uint

{

return 0xD5EC;

}

Совсем не то, что мы ожидали. Опытным путем можно прийти, например, к такому варианту кода:

public static function useless_func():void

{

useless_func2(0x11, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26);

}

public static function useless_func2(arg1:uint, arg2:uint, arg3:uint, a, b, c, d, e, f, g, h, i, j, k, l, m, n, p, q, r, s, t, u, v, w, x, y, z):void

{

}

Тело первой функции будет содержать следующие инструкции:

Интересующие нас байты FF 11 являются инструкцией call [ecx]:

Неявный вызов получили, теперь нужно занести в регистр ecx контролируемый адрес. Выясним, что хранится в данном регистре в момент вызова функции useless_func().

В момент вызова функции, в регистре ecx находится объект класса MethodEnv. Первый DWORD данного класса является указателем на виртуальную таблицу функций (ту, которую генерирует компилятор C++). Эта таблица в момент вызова метода useless_func() не используется, поэтому ничего не мешает атакующему непосредственно перед вызовом метода заменить указатель на свой.

Реализация данного алгоритма будет следующей:

var class_addr:uint = read_addr(UselessClass);

var vtable:uint = read_dword(class_addr + 8);

var methodenv:uint = read_dword(vtable + 0x54); // $+54 = useless_func

var func_ptr:uint = read_dword(methodenv + 4);

write_dword(methodenv + 4, func_ptr + offset_to_call_ecx);

write_dword(methodenv, rop_gadget); // ecx <- pointer to rop gadgets

UselessClass.useless_func(); // call [ecx]

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

Этот метод обхода CFG был исправлен в версии 18.0.0.194 (KB3074219, Июнь 2015). Исправление заключается в использовании нового флага

PAGE_TARGETS_INVALID/PAGE_TARGETS_NO_UPDATE (0x40000000) для функций VirtualAlloc и VirtualProtect в связке с новой функцией WinAPI — SetProcessValidCallTargets.

Флаг PAGE_TARGETS_INVALID при выделении исполняемой памяти выставляет нулевой бит для всего участка памяти, а флаг PAGE_TARGETS_NO_UPDATE при изменении типа памяти на исполняемую предотвращает изменение битовой карты для целевого участка памяти.

Данное исправление можно наблюдать в функции AVMPI_makeCodeMemoryExecutable в исходном коде ядра AVM (AVMPI/MMgcPortWin.cpp):

Вызов функции SetProcessValidCallTargets реализован в AVMPI_makeTargetValid (AVMPI/MMgcPortWin.cpp):

Из этого можно сделать вывод, что правильная последовательность действий при размещении в памяти динамически генерируемого кода в условиях работы CFG должна быть следующей:

VirtualAlloc(PAGE_READWRITE)

Запись кода в выделенный участок

VirtualProtect(PAGE_EXECUTE_READ | PAGE_TARGETS_NO_UPDATE)

SetProcessValidCallTargets()

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

Проверка Control Flow Guard заключается в валидации вызываемого адреса, но валидными адресами являются не только начала пользовательских функций. Все функции WinAPI, как и любые другие функции из таблицы импорта, являются валидными адресатами для неявного вызова. Атакующему ничего не мешает перевести поток исполнения напрямую в библиотечную функцию, минуя тем самым выполнение шеллкода (shellcode) или ROP-гаджетов. Хорошим кандидатом для такой цели является WinAPI функция kernel32!WinExec.

Данная идея впервые была озвучена исследователем Yuki Chen из Qihoo 360 Vulcan Team на конференции SyScan (Сингапур, 2015) в презентации, посвященной эксплуатации уязвимости в Internet Explorer 11 с обходом новых механизмов защиты. Также на конференции BlackHat (США, 2015) исследователь Francisco Falcón описал реализацию данного метода применительно к Adobe Flash Player.

В своей реализации Francisco Falcón оперировал методом toString() объекта класса Vector, но мы попробуем реализовать данный метод, пользуясь наработками из предыдущего.

Основная сложность данного метода заключается в том, чтобы передать параметры WinExec через стек. Данная функция, согласно справке, принимает 2 параметра: LPCSTR lpCmdLine и UINT uCmdShow.

lpCmdLine — указатель на строку, которую нужно выполнить (должна заканчиваться нулевым байтом).

uCmdShow — режим отображения запускаемого приложения.

Обратимся к скриншоту из предыдущего метода:

В момент вызова нашей функции на стеке оказывается 3 параметра. Третий параметр нас не интересует. Со вторым все отлично, поскольку 0 = SW_HIDE (приложение запустится скрыто). Первым параметром является указатель на объект MethodEnv.

Как мы уже выяснили ранее, первые 4 байта данного объекта являются указателем на виртуальную таблицу функций, и в момент вызова ActionScript-метода она никак не задействуется. Следующие 4 байта указывают на тело функции, и именно их нужно изменить на указатель функции WinExec.

Поскольку порча указателя на тело функции не приведет ни к чему хорошему, в нашем распоряжении имеется лишь первые 4 байта. В данный размер можно, например, уместить строку cmd\0 (командная строка Windows). Данной командой, конечно, не добиться полной компрометации системы, но для демонстрации подойдет.

Модифицируем алгоритм из предыдущего метода и получим следующий код:

var class_addr:uint = read_addr(UselessClass);

var vtable:uint = read_dword(class_addr + 8);

var methodenv:uint = read_dword(vtable + 0x50); // $+50 = useless_func

var winexec:uint = get_proc_addr("kernel32.dll", "WinExec");

write_dword(methodenv + 4, winexec); // useless_func() --> WinExec()

write_dword(methodenv, 0x00646d63); // '\0', 'd', 'm', 'c'

UselessClass.useless_func();

Поиск WinAPI функции в условиях современных Flash-эксплоитов является тривиальной задачей. Данную реализацию мы опустим, но с ней можно всегда ознакомиться, изучив пакет Flash Exploiter из фреймворка Metasploit.

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

Все современные Flash-эксплоиты так или иначе используют метод запуска полезной нагрузки (payload) из утекших исходников эксплоитов компании HackingTeam. Автором данного метода является Виталий Торопов. Его метод основан на вызове WinAPI функции kernel32!VirtualProtect, благодаря чему достигается обход всех механизмов защиты и, в том числе, Control Flow Guard.

Целью данного метода является метод apply() класса Function (core/FunctionClass.cpp)

В исходном коде данного метода происходит нативный вызов core->exec->apply(get_callEnv(), thisArg, (ArrayObject*)AvmCore::atomToScriptObject(argArray));, который можно перехватить, оперируя объектами ActionScript.

Подробное описание данного метода требует отдельной статьи, но с реализацией можно ознакомиться на GitHub. Также есть хороший материал с разбором данного метода в условиях 64-битного Flash в блоге Metasploit.(https://community.rapid7.com/community/metasploit/blog/2015/...)

Заключение

Несмотря на свои недостатки, Control Flow Guard при должном внимании со стороны разработчиков является хорошим дополнением в арсенале борцов с эксплоитами в среде ОС Windows. Компании Microsoft удалось, пусть и не полностью, реализовать концепцию Control Flow Integrity, минимально повлияв на производительность приложений, и сохранив обратную совместимость. Данный механизм еще не достиг предела своих возможностей, и разработчики из Microsoft наверняка в ближайшем будущем смогут усилить защиту приложений.

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

https://habrahabr.ru/company/dsec/blog/305960/

http://sjc1-te-ftp.trendmicro.com/assets/wp/exploring-contro...

http://www.powerofcommunity.net/poc2014/mj0011.pdf

https://github.com/adobe/avmplus

https://www.blackhat.com/docs/eu-15/materials/eu-15-Falcon-E...

Компания Microsoft не оставляет попыток победить в бесконечной войне с эксплоитописателями, раз за разом реализуя новые техники по защите приложений. На сей раз разработчики операционной системы Windows подошли к решению данного вопроса более фундаментально, переведя свой взгляд на корень проблемы. Работа почти каждого эксплоита так или иначе нацелена на перехват потока исполнения приложения, следовательно, не помешало бы "научить" приложения следить за этим моментом.

Концепия Control Flow Integrity (целостность потока исполнения) была описана еще в 2005 году. И вот, 10 лет спустя, разработчики из компании Microsoft представили свою неполную реализацию данного концепта — Control Flow Guard.

Control Flow Guard (Guard CF, CFG) — относительно новый механизм защиты Windows (exploit mitigation), нацеленный на то, чтобы усложнить процесс эксплуатации бинарных уязвимостей в пользовательских приложениях и приложениях режима ядра. Работа данного механизма заключается в валидации неявных вызовов (indirect calls), предотвращающей перехват потока исполнения злоумышленником (например, посредством перезаписи таблицы виртуальных функций). В сочетании с предыдущими механизмами защиты (SafeSEH, ASLR, DEP и т.д.) являет собой дополнительную головную боль для создателей эксплоитов.

Данная секьюрити фича доступна пользователям ОС Microsoft Windows 8.1 (Update 3, KB3000850) и Windows 10.

Компиляция программ с поддержкой CFG доступна в Microsoft Visual Studio 2015.

Рассмотрим принцип работы CFG в пользовательском режиме. Данный механизм имеет два основных компонента: битовую карту адресов (управляется ядром) и процедуру проверки указателя вызываемой функции (используется пользовательскими приложениями).

Вся служебная информация CFG заносится в IMAGE_LOAD_CONFIG_DIRECTORY исполняемого файла во время компиляции:

GuardCFCheckFunctionPointer — указатель на процедуру проверки

GuardCFFunctionTable — таблица валидных адресов функций (используется ядром для инициализации битовой карты)

GuardCFFunctionCount — количество функций в таблице

GuardFlags — флаги

В заголовок IMAGE_NT_HEADERS.OptionalHeader.DllCharacteristics заносится флаг IMAGE_DLLCHARACTERISTICS_GUARD_CF, показывающий, что данный исполняемый файл поддерживает механизм CFG.

IMAGE_GUARD_CF_INSTRUMENTED (0x00000100) — Модуль производит проверки потока исполнения при поддержке системы

IMAGE_GUARD_CFW_INSTRUMENTED (0x00000200) — Модуль производит проверки целостности потока исполнения и записи

IMAGE_GUARD_CF_FUNCTION_TABLE_PRESENT (0x00000400) — Модуль содержит таблицу валидных функций

IMAGE_GUARD_SECURITY_COOKIE_UNUSED (0x00000800) — Модуль не использует security cookie (/GS)

IMAGE_GUARD_PROTECT_DELAYLOAD_IAT (0x00001000) — Модуль поддерживает Delay Load Import Table, доступную только для чтения

IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION (0x00002000) — Delay Load Import Table находится в своей собственной .didat секции

IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_MASK (0xF0000000) — Шаг одного элемента таблицы валидных функций Guard CF кодируются в данных битах (дополнительное количество байтов для каждого элемента)

Также стоит обратить внимание на присутствие некоторых интересных флагов, официальной информации о которых нет. Разработчики Microsoft, по всей видимости, тестируют дополнительный механизм CFG для проверки адреса записи (IMAGE_GUARD_CFW_INSTRUMENTED).

Во время загрузки ОС ядром (функция nt!MiInitializeCfg) создается битовая карта nt!MiCfgBitMapSection, которая является общей (shared) секцией для всех процессов. При запуске процесса, поддерживающего CFG, происходит отображение (mapping) битовой карты в адресное пространство процесса. После чего адрес и размер битовой карты заносятся в структуру ntdll!LdrSystemDllInitBlock.

Сопоставлением адресов функций с битами в битовой карте занимается загрузчик исполняемых файлов (функция nt!MiParseImageCfgBits). Каждый бит в битовой карте отвечает за 8 байт пользовательского адресного пространства процесса. Адреса начала всех валидных функций соотносятся с единичным битом по соответствующему смещению в битовой карте, а всё остальное — 0.

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

Для наглядности посмотрим на один и тот же код, скомпилированный без CFG и с ним.

Оригинальный код на C++:

class CSomeClass

{

public:

virtual void doSomething()

{

std::cout << "hello";

}

};

int main()

{

CSomeClass *someClass = new CSomeClass();

someClass->doSomething();

return 0;

}

mov eax, [ecx] ; EAX = CSomeClass::vftable

call dword ptr [eax] ; [EAX] = CSomeClass::doSomething()

С ключем компиляции /guard:cf :

mov eax, [edi] ; EAX = CSomeClass::vftable

mov esi, [eax] ; ESI = CSomeClass::doSomething()

mov ecx, esi

call ds:___guard_check_icall_fptr ; checks that ECX is valid function pointer

mov ecx, edi

call esi

В первом случае код подвержен атаке с использованием техники подмены таблицы виртуальных функций. Если атакующий при эксплуатации уязвимости способен перезаписать данные объекта, то он может подменить таблицу виртуальных функций таким образом, что вызов функции someClass->doSomething() приведет к выполнению контролируемого атакующим кода, тем самым перехватив поток исполнения приложения.

В случае же использования Control Flow Guard, адрес вызываемой функции предварительно будет сверен с битовой картой. Если соответствующий бит будет равен нулю, произойдет программное исключение.

При запуске данного приложения на ОС, которые поддерживают механизм Guard CF, загрузчик исполняемых файлов построит битовую карту и перенаправит адрес проверяющей процедуры на функциюntdll!LdrpValidateUserCallTarget.

Данная функция в ОС Windows 10 (build 1511) реализована следующим образом:

Целевую ячейку получили, теперь требуется определить номер интересующего нас бита. Номером является значение следующих 5 бит адреса (выделены жирным). Но нужно учитывать, что если проверяемый адрес не выравнен по границе 16 байт (address & 0xf != 0), то использоваться будет нечетный бит (offset | 0x1). В данном случае адрес выравнен и номер бита будет равен 10110(двоичная) = 22(десятичная).

Проверив 22-ой бит, можно убедиться, что адрес вызываемой функции является валидным.

Реализация данного алгоритма на Python выглядит следующим образом:

def calculate_bitmap_offset(addr):

offset = (addr >> 8) * 4

bit = (addr >> 3) % 32

aligned = (addr & 0xF == 0)

if not aligned:

bit = bit | 1

print "addr = 0x%08x, offset = 0x%x, bit index = %u, aligned? %s" % (addr, offset, bit, "yes" if aligned else "no")

calculate_bitmap_offset(0x0B3385B0)

addr = 0x0b3385b0, offset = 0x2cce14, bit index = 22, aligned? yes

Не во всех случаях вызов невалидной функции будет заканчиваться 29-ым прерыванием. В функции ntdll!RtlpHandleInvalidUserCallTarget происходят следующие проверки:

Включен ли DEP для текущего процесса

Имеет ли целевой адрес необходимые права (PAGE_EXECUTE_WRITECOPY | PAGE_EXECUTE_READWRITE | PAGE_EXECUTE_READ | PAGE_EXECUTE)

Разрешены ли "suppressed" вызовы — ntdll!RtlGuardAllowSuppressedCalls

Является ли целевой адрес "suppressed" — ntdll!RtlpGuardIsSuppressedAddress

Псевдокод данной функции выглядит следующим образом:

Официальная информация про "suppressed" вызовы отсутствует. Можно лишь сказать, что данные вызовы требуют поддержку компилятора — должна быть установлена маска IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_MASK во флагах GuardFlags и компилятор должен сгенерировать расширенную таблицу. В байтах, соответствующих данной маске, хранится значение дополнительного размера для элементов таблицы GuardCFFunctionTable. Если адрес функции является "suppressed", то байт, следующий за адресом, должен быть равен единице.

Разрешить "suppressed" вызовы можно, например, с помощью ветки реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\, установив параметр CFGOptions для требуемого приложения в значение 1.

Как и любой другой защитный механизм, CFG имеет некоторые слабые места:

Выключенный DEP процесса влечет за собой потерю смысла проверок CFG, поскольку функция ntdll!RtlpHandleInvalidUserCallTarget в таком случае будет всегда разрешать исполнение невалидного адреса.

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

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

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

За каждые 8 байт адресного пространства отвечает 1 бит, но, на самом деле, 1 выравненный адрес соотносится с одним четным битом, при этом следующий нечетный бит соотносится сразу с 15 байтами адресного пространства. Убедиться в этом можно, запустив приведенный выше Python скрипт в цикле и проанализировав результат:

addr = 0x08f38480, offset = 0x23ce10, bit index = 16, aligned? yes

addr = 0x08f38481, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f38482, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f38483, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f38484, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f38485, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f38486, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f38487, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f38488, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f38489, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f3848a, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f3848b, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f3848c, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f3848d, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f3848e, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f3848f, offset = 0x23ce10, bit index = 17, aligned? no

addr = 0x08f38490, offset = 0x23ce10, bit index = 18, aligned? yes

addr = 0x08f38491, offset = 0x23ce10, bit index = 19, aligned? no

addr = 0x08f38492, offset = 0x23ce10, bit index = 19, aligned? no

addr = 0x08f38493, offset = 0x23ce10, bit index = 19, aligned? no

addr = 0x08f38494, offset = 0x23ce10, bit index = 19, aligned? no

...

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

Динамически генерируемые функции (например, JIT-функции) требуют особого внимания от разработчиков, поскольку необходимо обеспечить проверки неявных вызовов на стадии генерирования функций. В добавок к этому, необходимо учитывать, что стандартное поведение функций ntdll!NtAllocVirtualMemory и ntdll!NtProtectVirtualMemory заключается в проставлении единичного бита для всего региона памяти в битовой карте Control Flow Guard, если память становится исполняемой (PAGE_EXECUTE_*).

CFG не способен предотвратить перехват потока исполнения при модификации атакующим адреса возврата функции.

Вызовы библиотечных функций (например, WinAPI) с точки зрения CFG являются валидными, но атакующему предстоит решить задачу наполнения стека/регистров необходимыми параметрами.

Начиная с Windows 8 плагин Adobe Flash Player интегрирован в Internet Explorer, а с Windows 8.1 (Update 3) он поставляется с поддержкой CFG. Существует несколько реализаций обхода Control Flow Guard в эксплоитах под Adobe Flash Player, некоторые из которых актуальны и по сей день.

Обход при помощи динамического кода

В Adobe Flash Player активно используется JIT-компиляция, которая позволяет избегать выполнения такой ресурсоемкой операции, как интерпретация ActionScript кода. Но, как было сказано ранее, динамически генерируемые функции требуют дополнительного внимания со стороны разработчиков. Два метода обхода, описанные ниже, являются следствием упущения разработчиков в отношении работы с выделением памяти.

Отсутствие проверок неявных вызовов в динамическом коде

Данный метод был предложен и реализован исследователем Francisco Falcón из Core Security в своем анализе эксплоита для уязвимости CVE-2015-0311. Оригинальная статья довольно хорошо и подробно описывает процесс реализации обхода. Суть метода заключается в модификации внутренней таблицы виртуальных функций определенного ActionScript класса. После чего один из методов данного класса должен быть вызван из тела динамически сгенерированной функции. Для данной цели хорошо подходит класс ByteArray.

Структура объекта ByteArray:

Класс VTable является внутренним представлением виртуальной таблицы функций (то есть не той, которую генерирует C++) для классов ActionScript.

Часть2 http://pikabu.ru/story/control_flow_guard_printsip_rabotyi_i...

Источник: https://habrahabr.ru/company/dsec/blog/305960/

Криптовымогатели сейчас повсюду. Программы, шифрующие файлы пользователя, а затем требующие выкуп за расшифровку данных приносят большие деньги своим создателям. Среди такого рода программного обеспечения есть поистине гениальные программы. Во многих случаях разработчики таких зловредов выполняют обещание: если пользователь платит, он получает ключ для расшифровки файлов. Но так бывает далеко не всегда — иногда ключ после оплаты и не приходит.

Случается и так, что нет не только ключа, но и файлов. Ranscam — зловред, который только притворяется криптовымогателем. ПО делает вид, что файлы зашифровываются, хотя на самом деле все, что пользователь видит на экране — командная строка со списком удаляемых файлов. Как только файлы удаляются, программа показывает всплывающее окно с требованием заплатить деньги за получение ключа шифрования.

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

Чуть ниже в окне размещается поле, куда нужно вводить свои данные после совершения платежа. Зловред якобы должен «проверить» платежные данные жертвы. При этом говорится, что нажатие на кнопку без проведения платежа чревато полным удалением всех файлов. Все, что делает это ПО — выполняет HTTP GET запрос для получения PNG картинок, демонстрирующих пользователю процесс верификации. На самом деле программа ничего не проверяет.

Кроме того, оплата не поможет — все файлы удаляются криптовымогателем при заражении ПК. Автор же зловреда пытается обмануть жертву, чтобы та заплатила деньги. Само программное обеспечение довольно простое — над ним явно поработали не слишком опытные злоумышленники.

На компьютер пользователя вирус проникает в виде исполняемого .NET файла. Файл подписан цифровым сертификатом, выданным reca[.]net. Дата выдачи сертификата — 6 июля 2016 года.

Зловред в этом случае полностью оправдывает свое название, поскольку выполняет еще ряд действий, убивающих систему пользователя:

Удаление всех файлов Windows, отвечающих за резервное копирование данных (System Restore);

Удаляет теневые копии;

Удаляет ряд ключей реестра, отвечающих за запуск системы в Safe Mode.

После всего этого система запрашивает JPEG файл для демонстрации сообщения о необходимости внесении оплаты за расшифровку файлов.

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

Специалисты по информационной безопасности, изучающие зловреда, отправили по указанному в сообщении вируса адресу e-mail. «Жертва» запросила помощи у создателя вируса, рассказав, что не смогла выполнить правильно транзакцию с Bitcoin. Почти сразу после запроса пришел ответ.

Последовала еще одна просьба помочь: «Я ничего не понимаю в этих штуках. Я не понимаю, что все это значит или сколько стоит, но я хочу заполучить свой компьютер обратно. У меня много фотографии моей семьи и я не могу и просмотреть. Есть ли какое-то место, куда я могу отправить мои данные, или, возможно, есть номер телефона, по которому можно позволить, чтобы вы мне помогли? Я не знаю, что я сделал, но компьютер моей дочери не показывает это гадкое сообщение, что я должен делать? Пожалуйста, помогите вернуть мои фото, они важны!».

Спустя пару часов после запроса злоумышленник прислал ответ, где дал подробную инструкцию по оплате. После этого автор вируса не стал продолжать общение. Тем не менее, он предоставил тот же адрес кошелька Bitcoin, который был указан в информационном окне, показываемом вирусом. Этот адрес 1G6tQeWrwp6TU1qunLjdNmLTPQu7PnsMYd. Эксперты, изучающие проблему, проверили транзакции по этому кошельку, и увидели, что общая сумма переведенных средств достигает уже $277.61. Правда, эти деньги поступали на кошелек раньше, до 20 июня. После этой даты нет ни одной транзакции.

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

Источник: https://geektimes.ru/post/278436/

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

Исследователи акцентировали внимание на том, что видеозапись вовсе не обязательно просматривать на экране смартфона: достичь цели хакер может и «извне», когда ничего не подозревающий пользователь просматривает YouTube-ролики на любом соседнем устройстве — ноутбуке, компьютере, смарт-ТВ и пр. При этом голосовые команды все равно смогут достичь телефона, после чего он будет взломан.

Взлому по описанному сценарию подлежат как мобильные устройства на IOS, так и на Android. Приняв голосовую команду, которая для пользователя воспринимается как бессвязный набор звуков или не слышна вообще, электронный ассистент Google Now или Siri отдает команду для перехода по ссылке и загрузки вредоносного софта.

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

По словам специалистов, обезопасить владельца мобильного устройства от подобной угрозы с вероятностью более 99.8% позволит активация на устройстве опции доставки уведомлений на получение и исполнение голосовых команд.

Это не первый случай взломов смартфонов через популярную платформу видеохостинга. Ранее сотрудники Техасского университета говорили о возможности взлома смартфона на Android при идентификации владельца. В поле разблокировки достаточно было ввести максимальное количество символов, после чего ОС выдавала ошибку и блокировка снималась. За обнаруженную «брешь» в защите смартфонов на Android, группа исследователей из Техаса получила денежное вознаграждение от разработчиков. Однако в этот раз ни одна из ведущих компаний — производителей мобильных устройств текущую ситуацию пока не прокомментировала.

Источник: https://geektimes.ru/company/dronk/blog/278386/

Специалистов по информационной безопасности в мире довольно много. Виртуальных угроз — еще больше. Но пока что с ними удается справляться благодаря усилиям специалистов. При появлении новой угрозы (уязвимость в CMS, новый зловред и т.п.) решение находится довольно быстро. Проблема в том, что эти решения обычно публикуются в корпоративных, частных блогах, частных инструкциях и отчетах. Такая информация фрагментирована, и добыть ее бывает непросто.

«Давайте представим, что завтра выходит статья о новом типе вредоносного ПО, а затем различные блоги публикуют дополненные данные у себя», — говорит Кэвин Шкапинец, глава стратегического отдела IBM. «То, что мы делаем — это учим Watson понимать публикуемую информацию, искать несколько источников, находить связи между ними». По различным аспектам информационной безопасности ежемесячно выходят публикации в 60000+ блогах по информационной безопасности. И это только один источник данных для IBM Watson.

Борьбе с интернет-злоумышленниками сейчас уделяется очень много времени. Кроме того, тратятся огромные средства. Предприятия всего мира напрасно выбрасывают миллионы долларов только на попытки ликвидации ложных угроз. По временным затратам такая борьба с ветряными мельницами занимает около 21000 часов в совокупности. Ситуация усугубляется тем, что каждый день появляются все новые уязвимости, которые очень быстро обнаруживают хакеры. На данный момент насчитывается около 75000 актуальных интернет-угроз, внесенных в National Vulnerability Database.

В прошлом году «языку кибербезопасности» систему обучали собственные специалисты IBM Security. Они смогли дать когнитивной системе навыки борьбы с информационной угрозой в Сети. IBM Watson изучил тысячи документов по данной тематике, структурировал информацию и научился ее использовать.

Теперь мы планируем ускорить процесс обучения. Этой осенью IBM Watson станет студентом сразу восьми учебных заведений по специальности «информационная безопасность». Watson начнет учиться вместе со студентами Калифорнийского государственного политехнического университета, Помона, студентами MIT, Нью-Йоркского университета, Мэрилендского университета и другими высшими учебными заведениями. В частности, Мэрилендский университет вместе с IBM создаст центр Accelerated Cognitive Cybersecurity Laboratory (ACCL), где студенты, ученые и специалисты IBM будут заниматься различными проблемами кибербезопасности.

В рамках IBMWatson будет выделен облачный сервис Watson for Cyber Security, специализация которого — обнаружение новых информационных угроз и поиск способов их ликвидации (или же ликвидации последствий, если саму угрозу нивелировать не удалось).

Источник: https://geektimes.ru/company/ibm/blog/277210/

В марте 2016 года специалисты «Лаборатории Касперского» рассказали о мобильном трояне Triada, который атакует Android-устройства. Тогда эксперты писали, что этот вредонос является одним из самых технически сложных образцов малвари, что им доводилось видеть. Теперь исследователи «Лаборатории Касперского» сообщают, что Triada обзавелся опасным модулем и демонстрирует новую технику атак, перехватывая и подменяя ссылки в мобильных браузерах.

Напомню, что Triada — это первый троян, который на практике научился осуществлять успешные атаки на процесс Zygote; ранее подобные техники рассматривались исключительно с теоретической точки зрения и в виде proof-of-concept. Родительский процесс Zygote содержит системные библиотеки и фреймворки, используемые практически всеми приложениями, и является своего рода шаблоном. После удачного осуществления атаки, троян становится частью этого шаблона, что дает ему возможность проникнуть во все приложения, установленные на зараженном устройстве, а затем изменить логику их работы.

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

6 июня 2016 года исследователи «Лаборатории Касперского» представили подробный разбор одного из модулей Triada, который был обнаружен еще в марте текущего года, вскоре после обнаружения самого трояна. Модуль Backdoor.AndroidOS.Triada.p/o/q атакует процессы четырех популярных браузеров для Android:

android.browser (стандартный Android-браузер);

com.qihoo.browser (защищенный 360 Browser);

ijinshan.browser_fast (браузер Cheetah);

oupeng.browser (браузер Oupeng).

Исследователи пишут, что в основном злоумышленники использовали данную схему атак для доставки рекламы, в большинстве случаев просто изменяя домашнюю страницу браузера жертвы или поиск по умолчанию. По сути, модуль применялся как обычное adware-решение, несмотря на весь его вредоносный потенциал. Более того, авторы Triada, похоже, вообще забросили данную разработку и не используют этот компонент малвари уже некоторое время.

В заключение аналитики «Лаборатории Касперского» отмечают, что создатели малвари для Android весьма ленивы. Хотя в последнее время злоумышленники стали уделять больше внимания структуре ОС и пополнили свой арсенал новыми, более сложными векторами атак, чаще атакующие все же идут по пути наименьшего сопротивления. К примеру, им проще похищать деньги у жертв напрямую, посредством отправки сообщений на платные номера или подделывая окна банковских приложений.

Как прогнать преступников из своего телефона?

Самое неприятное в истории с «Триадой» то, что от нее с большой вероятностью могут пострадать очень много людей. Согласно нашим данным, во второй половине 2015 года каждый десятый пользователь Android был атакован теми самыми мелкими троянцами, получающими права суперпользователя, которые среди прочего могут устанавливать на устройство «Триаду». Таким образом, жертвами этого троянца уже могут быть миллионы пользователей.

Так как защитить себя от мерзкого проныры? Не так уж сложно.

1. Во-первых, всегда устанавливать последние системные обновления. Мелким зловредам сложно перехватить root-привилегии в устройствах с Android 4.4.4 и выше, так как большое количество уязвимостей в этих версиях ОС было закрыто. Если на вашем телефоне установлена более-менее современная операционная система, вы находитесь в относительной безопасности. Однако наша статистика показывает, что около 60% пользователей Android сидят на Android 4.4.2 и более древних версиях этой ОС. И вот для них шанс заразиться весьма высок.

2. Во-вторых, лучше вообще не испытывать судьбу и не подсчитывать вероятность тех или иных шансов. Надежную защиту вашего устройства обеспечит только хороший антивирус. Известно немало случаев, когда даже в официальных магазинах Google находили троянцев (собственно, мелкие зловреды, скачивающие «Триаду, как раз из таких). Так что рекомендуем вам установить надежное защитное решение.

Подведем итоги: «Триада» — это еще один весьма наглядный пример неприятной тенденции. Разработчики вредоносного ПО начали воспринимать Android всерьез. Более того, они научились эффективно использовать его уязвимости.

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

Источники:

https://xakep.ru/2016/06/08/triada-browser-module/

https://blog.kaspersky.ru/triada-trojan/11102/