Как сделать 0day эксплоит

04.10.202320.08.2023 admin 0 Comments

Что такое атака нулевого дня? Определение и описание

Нулевой день. Определение и описание

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

Нулевой день иногда обозначают как 0-день. Слова уязвимость, эксплойт и атака обычно используются в сочетании со словами «нулевого дня», и важно понимать разницу между этими терминами:

Что такое и как работают атаки нулевого дня?

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

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

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

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

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

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

Кто совершает атаки нулевого дня?

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

На кого нацелены эксплойты нулевого дня?

При атаках нулевого дня могут использоваться различные уязвимые объекты:

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

Также полезно выделить целевые и нецелевые атаки нулевого дня:

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

Как выявить атаки нулевого дня

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

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

Часто используется комбинация различных систем обнаружения.

Примеры атак нулевого дня

Ниже приведены примеры последних атак нулевого дня.

2021: уязвимость нулевого дня Google Chrome

В 2021 году Google Chrome подвергся серии атак нулевого дня, ставших причиной ряда обновлений Chrome. Уязвимость возникла из-за ошибки в JavaScript-движке V8, используемом в веб-браузере.

2020: Zoom

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

2020: Apple iOS

Apple iOS часто называют самой безопасной платформой для смартфонов. Однако в 2020 году она подверглась как минимум двум атакам нулевого дня. Одна из ошибок нулевого дня позволила злоумышленникам удаленно скомпрометировать iPhone.

2019: Microsoft Windows, Восточная Европа

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

2017: Microsoft Word

Результатом этого эксплойта нулевого дня стала компрометация личных банковских счетов. Жертвами оказались люди, которые неосознанно открывали вредоносный документ Word. В документе отображалось предложение загрузить удаленное содержимое – всплывающее окно, запрашивающее внешний доступ из другой программы. При нажатии на кнопку «Да» на устройства пользователей устанавливалось вредоносное ПО, перехватывающее учетные данные для входа в интернет-банк.

Stuxnet

Один из самых известных примеров атак нулевого дня – Stuxnet – вредоносный компьютерный червь, впервые обнаруженный в 2010 году, но зародившийся еще в 2005 году. Его атаке подверглись производственные компьютеры с программируемыми логическими контроллерами (ПЛК). Основной целью были заводы Ирана по обогащению урана, атака на которые могла подорвать ядерную программу страны. Червь проник на ПЛК через уязвимости в программном обеспечении Siemens Step7 и заставил ПЛК выполнять непредусмотренные команды на сборочном оборудовании. История Stuxnet впоследствии легла в основу документального фильма «Уязвимость нулевых дней» (Zero Days).

Как защититься от атак нулевого дня

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

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

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

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

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

Использование комплексного антивирусного программного решения. Kaspersky Total Security помогает защитить ваши устройства, блокируя известные и неизвестные угрозы.

Источник

0day своими руками: Ищем уязвимость и пишем эксплойт для Music Maker 16

Содержание статьи

Здравствуйте, дорогие любители эксплойтостроения! Сегодня мы познакомимся с немецкой компанией MAGIX AG и ее продуктом Music Maker 16. В процессе нашего знакомства мы найдем уязвимость нулевого дня, а также напишем эксплойт, который будет обходить DEP и ASLR.

Предыстория

Началась эта история с того, что автор, как обычно, на работе с чашкой чая и пончиком в зубах читал новостную ленту (вот так работают в Digital Security). Мое внимание привлек заголовок «MAGIX AG угрожает судебным преследованием специалисту по безопасности». Суть была примерно в следующем: шведский парень Acidgen из тусовки Corelan Team нашел уязвимость в продукте компании MAGIX AG под названием Music Maker 16.

После чего он написал письмо разработчикам, где сообщил всю инфу о баге и сказал, что после патча опубликует ее вместе с PoC. Вроде бы ситуация классическая, и такие истории происходят каждый день с самыми разными компаниями. Однако немцы не оценили добрые намерения шведского хакера и вместо того, чтобы сказать парню спасибо, обратились в суд. По всей видимости, работники MAGIX AG не очень-то в курсе того, как следует себя вести в таких ситуациях. Что ж, им же хуже: сейчас я покажу, как даже без PoC любой баг-хантер может разнести их программу на куски.

Ищем 0day

Скачав триал Music Maker 16, можно начать искать баги. Как известно, обычно уязвимости ищут фаззингом или статическим анализом. Но прежде чем начать использовать артиллерию, следует просто взглянуть на то, как работает программа. Итак, данный продукт предназначен для монтирования и сведения аудиоматериалов. Каждый проект объединяет в себе несколько аудиофайлов, их привязку к дорожкам, времени и так далее.

Как я понял, шведский хакер Acidgen нашел другую уязвимость, зато нашу уязвимость параллельно и независимо нашел лидер команды Corelan — Corelancod3r, автор известной примочки pvefindaddr. Но у него свой путь, а у нас — свой. Вообще, неудивительно, что одну и ту же уязвимость находят несколько человек, особенно такую простую и очевидную :).

Эксплойт

Найдя уязвимость, я выложил скриншот бага, чтобы донести до создателей софта простую мысль: для нахождения уязвимости совершенно не нужен никакой PoC, достаточно абстрактного указания «в софтине Music Maker есть бага». Кстати, опубликованный скриншот с ошибкой никаким образом нельзя считать вредоносным кодом, поэтому я абсолютно чист перед законами ФРГ и РФ. Однако очевидно, что информации со скриншота достаточно, чтобы любой другой человек нашел уязвимость. Так и получилось: наш читатель, известный мне под ником @ontrif, без труда докопался до сути проблемы и даже написал эксплойт! Суть его проста: перезаписываем SEH-указатель на адрес инструкции pop REG/pop REG/retn, который предварительно нашли в программе, в какой-нибудь подгруженной ДЛЛ-ке без SafeSEH (что несложно, так как вендор не потрудился включить защиту safeSEH). Это приведет к тому, что когда случится Access Violation, управление перейдет по данному указателю… а там у нас pop/pop/retn. Это значит, что 8 байт из стека уйдут, и указатель ESP опустится на 8 байт выше («опустится выше» — добро пожаловать в матрицу).

В этом случае ход выполнения программы такой:

Все здорово, только эксплойт у меня не заработал. Причин несколько. Поскольку у меня Windows 7 x64, то я защищен DEP и ASLR. Из-за этого выбранное ontrif значение YYYY указывало на dll’ку, которая прыгала в памяти из-за ASLR и BaseFixUP. А даже если поменять YYYY на то, что надо, YYYY и ZZZZ не будут исполнятся, так как DEP не даст исполнится коду из неисполняемого участка памяти — стека. Таким образом, эксплойт работает только в среде Windows XP. Чуть позже ontrif случайно сделал еще одну версию эксплойта, исправив один байт из YYYY на нулевой. В таком варианте Access Violation не происходило, так как программа воспринимала ввод как две строчки (из-за нулевого байта).

При этом переписывалось значение адреса возврата из функции на указатель кучи, причем ровно на место YYYY! Удивительное, магическое везение, как потом описывал данное событие ontrif.

В этом варианте после выхода из функции программа передавала управление в кучу на место YYYY. Это позволяет не думать об ASLR, но не решает проблему с DEP.

ROP-эксплойт

Самое время вспомнить о возвратно-ориентированном программировании. Год назад я уже писал о таких эксплойтах, время повторить изученное, но на более сложном примере. Дело в том, что наш буфер в стеке обрезанный. Хоть мы и переполняем буфер в стеке, мы ограничены длиной, которую программа считывает из файла. После перезаписи SEH у нас остается в стеке ровно 508 байт! Сюда поместится РОП-программа или шеллкод, но и то и то вместе не поместится. Corelancod3r сделал РОП-программу + egg-hunter-шеллкод (он маленький и помещается после РОПпрограммы в оставшийся объем, но он работает до-о-олго, пока ищет в куче основной шеллкод по восьмибайтной метке). Я же мазохист, и мне интересно мгновенное срабатывание шеллкода.

Покопавшись по содержимому стека, я увидел следующее: в стеке до SEH байт 100. В стеке по определенному смещению содержится указатель на кучу, на результат конкатенации пути + имени файла. Причем, если в стеке у нас начало имени файла попорче но, то в куче нет, тем не менее, длина также ограничена.

Моя идея состояла в следующем: переписываем SEH (YYYY)указателем на ROP-инструкцию для выравнивания указателя на стек так, чтобы ESP указывал не куда-то там, а точно на нашу ROP-программу из стека. То есть YYYY должен указывать на ROPгаджет, который меняет указатель ESP, а потом делает RETN, чтобы передать управление следующему ROP-гаджету и ROP-программе в целом. Для поиска гаджетов я использовал уже упомянутую примочку Corelancod3r’а. Все мои гаджеты из двух не поддерживающих ASLR библиотек — LTKRN14N.dll и LTDIS14n.dll. Таким образом, я нашел гаджет ADD “ESP,4F8 # RETN 4” по адресу 0x20012026 (всегда постоянные, так как модуль не поддерживает ASLR). В результате после Access Violation программа переходила по этому адресу и меняла указатель стека, после чего он указывал в зону aaaa…aaaa.

Таким образом, RETN 4 передавала управление по адресу из аааа… аааа, поэтому туда я также добавил адреса, но уже с меньшим сдвигом — ADD ESP, 40 # RETN. В результате указатель стека рос, пока не попадал в зону ZZZZ, где я и расположил РОП-программу.

ROP-программа

ROP-программа представляет собой указатели на РОП-гаджеты, а также некоторые параметры. Главное ограничение — запрет на использование нулевых байт и размер. Так как шеллкод в стек не поместить, моя РОП-программа брала на сохраненный до aaaa…aaaa указатель на кучу, где хранится путь и имя файла, соединенные в одну строку:

Примерно так. Замечу еще раз, что в стеке у нас поместилась только часть этого буфера: aaaa…aaaaXXXXYYYYZZZZZZ… именно ее мы используем для ROP-программы. Вышеупомянутый указатель указывает на FFFF, так что ROP-программа будет использовать найденную кучу для того, чтобы записать в FFFF параметры для вызова VirtualAlloc. Чтобы выполнить шеллкод, нам надо сделать память исполняемой. Для этого годится, например, вызов VirtualProtect, который может менять флаги доступа на страницы памяти и может сделать ее исполняемой. Но в указанных библиотеках я не нашел вызовы этой функции, зато нашел вызовы VirtualAlloc, которая выделяет память, однако ее можно использовать для «перевыделения» памяти, задав при этом флаг доступа на исполнение, что позволит нам выполнить шеллкод из кучи.

Последняя часть нужна, так как выяснилось, что иногда PPPP лежит в другой странице памяти, поэтому WW..WW делает исполняемой только FFFF-часть, а PPPP — нет. Поэтому stage 0 шеллкод вычисляет по сдвигу PPPP, еще раз вызывает VA, делает уже страницу с PPPP исполняемой, после чего передает управление на шеллкод. Ну вот, с теорией и покончено. Как видно, написать эксплойт намного сложнее, чем найти дыру :). Теперь давай перейдем к самому эксплойту, который я написал в виде модуля для Metasploit.

Реализация эксплойта

aaa_data = aaa_header # Заголовок MMM-файла
aaa_data

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

Послесловие

Как видишь, даже в условиях с ограничениями по размеру данных в стеке можно написать рабочий эксплойт, который обойдет все защиты. Можно было бы воспользоваться и вариантом egg-hunter, но это сильно замедляет атаку. Corelancod3r обещал придумать, как ускорить свой вариант эксплойта с egg-hunter’ом :). Наш же вариант ограничен по размеру шеллкода в 750 байт, зато работает моментально.

Источник

Zero-day эксплоит в Windows 10 и 11 позволяет повысить права пользователя до администратора

Уязвимость работает с любой поддерживаемой версией операционной системы

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

Проверкой опубликованной уязвимости занялись специалисты из BleepingComputer. Им удалось открыть командную строку с правами SYSTEM. Этого удалось добиться при использовании аккаунтов с низкими привилегиями. По словам экспертов, злоумышленник может повысить права внутри системы, а сам эксплоит затрагивает все поддерживаемые версии ОС, включая Windows 10, Windows 11 и Windows Server 22.

Уязвимости был присвоен идентификатор CVE-2021-41379. Эксплоит был выявлен в ходе исследования ноябрьского набора патчей от Microsoft. Он мог возникнуть в результате неправильного устранения предыдущего бага.

Источник

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

Linux для хакера

Издание Bleeping Computer сообщило, что ИБ-исследователь опубликовал эксплоит для новой уязвимости нулевого дня, которая может использоваться для локального повышения привилегий во всех поддерживаемых версиях Windows, включая Windows 10, Windows 11 и Windows Server 2022.

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

В этом месяце, в рамках «вторника обновлений», Microsoft устранила уязвимость CVE-2021-41379, связанную с повышением привилегий посредством Windows Installer. Эта проблема была обнаружена ИБ-исследователем Абдельхамидом Насери (Abdelhamid Naceri), который теперь сообщил о том, что патч можно обойти, а уязвимость после этого трансформируется в более серьезную проблему.

Насери уже опубликовал на GitHub PoC-эксплоит для новой 0-day проблемы, подчеркнув, что баг опасен для всех поддерживаемых версий ОС. Насери объясняет, что, можно настроить групповые политики таким образом, чтобы пользователи с правами уровня Standard не могли выполнять операции установщика MSI, однако новая уязвимость позволяет обойти эту политику.

«Этот вариант [уязвимости] был обнаружен во время анализа патча для CVE-2021-4137: ошибка была исправлена некорректно и напротив предоставила возможность обхода [исправления]», — пишет эксперт.

Когда журналисты поинтересовались у Насери, почему он публично раскрыл информацию о серьезной 0-day уязвимости, тот ответил, что разочарован уменьшением размера вознаграждений в bug bounty программу Microsoft.

«Bug bounty Microsoft испортилась в апреле 2020 года. Я правда не стал бы этого делать, если бы MSFT не приняла решение о понижении выплат», — пояснил специалист.

Источник