CPL malware представляет из себя особый вид вредоносного ПО, который распространяется в виде динамических DLL библиотек, выступающих в роли расширений элементов панели управления Windows (Windows Control Panel). Такой тип вредоносных программ особенно популярен у злоумышленников в Бразилии и используется для распространения даунлоадера Win32/TrojanDownloader.Banload и банкера Win32/Spy.Banker.T.



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

Вчера мы писали про утечку конфиденциальных данных кибергруппы Hacking Team, которая подверглась масштабному взлому. В архиве находились исходные тексты нескольких 0day эксплойтов, в т. ч. LPE sandbox-escape эксплойт для веб-браузера Internet Explorer и опасный RCE+LPE эксплойт для актуальной версии Flash Player. Рабочая версия последнего уже гуляет по сети и представляет для пользователей очень большую опасность, поскольку эксплойт является универсальным и позволяет удаленно исполнять код сразу в нескольких браузерах (актуальные версии), включая, Google Chrome, Opera, MS Internet Explorer, и, даже, MS Edge в составе Windows 10.

ASLR (Address Space Layout Randomization) является одним из наиболее эффективных механизмов защиты в современных операционных системах. Но данный метод не является совершенным. Многие современные APT (advanced persistent threat) уже научились использовать инновационные технологии для обхода ASLR.

Рассмотрим наиболее известные методы байпаса, которые были обнаружены за последний год:

• Использование non-ASLR модулей
• Изменение BSTR длина/нулевое окончание
• Модификация объектов Array

Ниже будет подробно рассмотрена каждая из техник.

Мы уже неоднократно упоминали ASLR, по справедливому замечанию MS, эта технология позволяет сделать разработку эксплойтов гораздо более дорогостоящим мероприятием, поскольку кроме эксплуатации самой уязвимости в ПО злоумышленнику нужно опереться на те или иные предсказуемые адреса в памяти в момент эксплуатации, которых ASLR его лишает. Как мы видим, в последнее время, в том числе, и с выпуском новейших Windows 8/8.1 MS решили более серьезно подойти к развертыванию данной особенности в системе. Если в узком смысле ASLR понимается как просто перемещение образа по непредсказуемым адресам с каждой перезагрузкой, то в более общем смысле эта возможность на уровне системы должна лишить атакующих любой возможности зацепится за те или иные адреса функций системных библиотек и иных системных объектов (ASLR bypass mitigation / Address Space Information Disclosure Hardening) в тех нескольких десятках байт шелл-кода, который может быть исполнен минуя DEP (ROP).

Мы не будем касаться истории ASLR, которая известна уже почти всем, отметим лишь некоторые не совсем очевидные возможности, которые Microsoft использует для улучшения ASLR в своих флагманских ОС Windows 7-8-8.1.

Работа посвящена погрешностям округления, возникающим при вычислениях у чисел с плавающей запятой. Здесь будут кратко рассмотрены следующие темы: «Представление вещественных чисел», «Способы нахождения погрешностей округления у чисел с плавающей запятой» и будет приведен пример компенсации погрешностей округления.

В данной работе примеры приведены на языке програмиирования C.

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

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

Одно время приходилось постоянно работать с сетевыми данными и в особенности с заголовками сетевого и транспортного уровней модели OSI. Постоянно напрягал тот факт, что многие поля были в Big-Endian, а код выполнялся на архитектуре Little-Endian. Ну невозможно было постоянно вызывать ntohl(), htonl(), ntohs(), htons()...


Автор фото: Ciroduran, источник фото: flickr.

Недавно познакомился со структурами C/C++ — struct. Господи, да «что же с ними знакомиться» скажете вы? Тем самым вы допустите сразу 2 ошибки: во-первых я не Господи, а во вторых я тоже думал что структуры — они и в Африке структуры. А вот как оказалось и — нет. Я расскажу о нескольких жизненно-важных подробностях, которые кого-нибудь из читателей избавят от часовой отладки…

WinDbg — позволяет отлаживать 32/64 битные приложения пользовательского уровня, драйвера, может быть использован для анализа аварийных дампов памяти, WinDbg поддерживает автоматическую загрузку отладочных символов, имеется встроенный скриптовый язык для автоматизации процесса отладки, скачать отладчик можно тут.

Управление памятью – центральный аспект в работе операционных систем. Он оказывает основополагающее влияние на сферу программирования и системного администрирования. В нескольких последующих постах я коснусь вопросов, связанных с работой памяти. Упор будет сделан на практические аспекты, однако и детали внутреннего устройства игнорировать не будем. Рассматриваемые концепции являются достаточно общими, но проиллюстрированы в основном на примере Linux и Windows, выполняющихся на x86-32 компьютере. Первый пост описывает организацию памяти пользовательских процессов.

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

Месяц назад портал на моей новой работе был взломан. Руководство задалось вопросом «Как?». В ходе недолгих поисков и анализу подключений к серверам, был найден ПК сотрудника, с которого устанавливалось подключение примерно в то самое время. Сотрудник ничего о взломе не знал, но в ходе беседы вспомнил один случай, ему незадолго до взлома пришёл документ от «сотрудника фирмы», который не открылся. Файл был в формате exe, с этого и началась вся история.

Перед разработчиками довольно часто встаёт выбор — сделать всё правильно, потратив на решение задачи уйму времени, или сделать так, чтобы работало, не особо вдаваясь в детали того, как именно это получилось. Со стороны заказчика, разумеется, наиболее привлекательной является некая золотая середина, которая в данном случае заключается одновременно и в хорошем понимании программистом выполненного таска, и в как можно меньшем количестве затраченных на него человеко-часов. С разработчиками тоже не всё так однозначно — с одной стороны, понимать, что происходит в своём собственном коде, это вполне естесственное желание (особенно если поддержка данного продукта также будет лежать на его плечах), а с другой стороны, если результаты работы приложения представлены в наглядном виде (графики / звуковые или видео-фрагменты etc), разработка разовая, и отдел тестирования говорит, что всё хорошо, то почему бы не проскроллить оставшуюся часть рабочего времени Хабр, посвятив время себе любимому?

Ближе к делу. В одной из предыдущих статей я уже упоминал о программе под названием «Говорилка». Несмотря на название, сама по себе она ничего не озвучивает, а лишь является связующим звеном между пользователем и речевыми движками, предоставляя более удобный интерфейс и возможность конфигурации. Одним из наиболее популярных в узких кругах движков является «Digalo 2000 text-to-speech engine» (далее — Digalo), ссылку на который можно найти как раз на сайте «Говорилки». Как вы уже, наверное, догадались из тематик моих предыдущих статей, не всё с ним так хорошо, и без багов тут также не обошлось. На этот раз проблема проявилась при озвучивании текста «ааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааа». Немного поэкспериментировав, я обнаружил, что при достижении определённого количества «неразрывных» символов Digalo начинает крашиться, предлагая отладить свой процесс. Ну, а что, почему бы и нет?

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

В этой статье мы исследуем аналог одной очень известной программы для Windows под названием «Блокнот» и напишем DLL расширяющее его возможности. Аналог называется NFOPad.

Хотел бы рассказать о мобильных рекламных сетях, об их системе защиты и способах её обхода. Способы обхода систем защиты применялись только в образовательных целях. Также замечу, что алгоритмы атак, представленные здесь, справедливы для любых платформ, однако в примере приводится работа Android, т.к. атаки на его код самые простые для описания.

Не так давно, закончив работу над очередной статьёй для Хабра, я решил оптравить её на ревью своему знакомому. Сохранив HTML-страницу со всем окружением (картинки, стили etc), я запаковал её в ZIP-архив и отправил адресату. Уже через пять минут я получил фидбек, который, вопреки моим ожиданиям, был связан вовсе не с самой статьёй, а с тем, что архив был абсолютно пустой. Почесав голову и решив, что я затупил с архивированием, я повторил процедуру, убедившись, что выделил все необходимые для запаковывания файлы. Спустя несколько минут знакомый снова разразился удивлённым «Ты что, шутишь?», в то время как я совсем не шутил.

Я начал собирать воедино все элементы паззла. Во-первых, я выяснил, чем он пытается открыть архив. Вдруг, в качестве viewer'а он использует какую-нибудь третьесортную фигню не пойми от какого разработчика? Однако им оказался дефолтный explorer.exe. Я же пользовался Total Commander'ом как для запаковки, так и для просмотра получившегося архива, и в моём случае он вовсе не был пустым:



Что, неужели это сборочка xxxWindowsUltimateEditionxxx подкачала? Я попытался открыть тот же самый архив на моём компьютере при помощи explorer.exe и наконец поверил своему знакомому — архив действительно выглядел пустым:



Кто же виноват в таком поведении? Давайте разберёмся.

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