Анализ подозрительных PDF файлов

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

    Практически все инструменты представленные в данной статье содержаться в дистрибутиве Remnux, созданном специально в целях reverse engineering malware. Вы можете сами загрузить себе образ виртуальной машины для VirtualBox или Vmware.

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



    Декодировал javascript код с помощью все того же pdf-parser:



    Привел к удобному виду, для этого можно воспользоваться js-beautify:



    Неплохо. Также проанализировал файл с помощью отличной утилиты jsunpack:



    На первый взгляд им была обнаружена уязвимость CVE-2009-1492, связанная с выполнением произвольного кода или отказа в обслуживании через Adobe Reader и Adobe Acrobat версий 9.1, 8.1.4, 7.1.1 и ранних версий, с помощью pdf файла, содержащего annotaion и использующего метод getAnnots. Но если проверить мои результаты, полученные выше, с соответствующим exploit-ом, то обнаруживается, что эта уязвимость не имеет отношения к текущему случаю. В нашем варианте annotaion используется для хранения большой части скрипта в том числе в целях обфускации.

    Данные из annotaion вызываются методом getAnnots и находятся в объекте 9 нашего файла(как показал pdfparser). Сохраним полученный javascript код, добавив к нему поток из объекта 9. Обычно, первым шагом для безопасного выполнения кода является замена функции eval безобидным alert или console.log и открытии файла с помощью браузера. Также в этих целях можно использовать Spidermonkey. Основные необходимые нам функции и переменные уже определены в файле pre.js, который вы также можете обнаружить в дистрибутиве Remnux.



    Неплохо. После запуска Spidermonkey мы получили новый скрипт, который использует функции eval и поток данных из объекта 7:



    Наиболее интересная вещь в данном скрипте скрыта в переменной var v12 – это функция arguments.callee. Arguments.callee обозначает вызов самой текущей исполнемой функции. Таким образом этот код использует сам себя в целях обфускации. То есть если вы изменяете что то в текущем коде (как я делал ранее при рефакторинге или замене функции eval на alert) вы сломаете всю следующую часть расшифровки. Но не стоит отчаиваться. Статьи, описывающие подобные ситуации: isc.sans.org/diary/Browser+*does*+matter%2C+not+only+for+vulnerabilities+-+a+story+on+JavaScript+deobfuscation/1519, isc.sans.edu/diary/Static+analysis+of+malicous+PDFs+%28Part+%232%29/7906 и www.nobunkum.ru/ru/flash (от Алисы Шевченко).

    В этом случае мы можем заменить вызов arguments.callee.toString().length на длину самой функции и идти дальше, заменяя вызов arguments.callee.toString().charCodeAt(0) первым символом в строке нашей функции.

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



    Финальный скрипт выглядел так:



    После рефакторинга получил:



    Детали уязвимости описаны тут: cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5659. Пару публичных эксплоитов можно обнаружить здесь: downloads.securityfocus.com/vulnerabilities/exploits/27641-collectEmailInfo-PoC.txt, www.exploit-db.com/exploits/16674/.

    Как видно во втором случае используются наши unescape("%u0c0c%u0c0c") и this.collabStore = Collab.collectEmailInfo({subj: "",msg: #{rand12}});

    2. В функции func_04 использована переменная var v0 также со значением 0x0c0c0c0c, что как бы намекает на наличие heap spray эксплоита. Почему это значение столь популярно можно почитать тут www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heap-spraying-demystified.

    В переменных v3, v4 просматривается shellcode из-за наличия серии NOP инструкций в начале значений переменных.

    Чтобы подтвердить мои предположения я использовал эмулятор libemu из бесплатного продукта PDFStreamDumper со значением, взятым из переменной v4. Также libemu вы можете найти и в Remnux:



    Бинго. Обнаружился url xxxxxx.info/cgi-bin/io/n002101801r0019Rf54cb7b8Xc0b46fb2Y8b008c85Z02f01010 который и использовался для загрузки с последующем исполнением нашего вредоноса:



    3. Также параметры сравнения, обнаруженные в скрипте:



    выглядят также как описано в CVE-2009-2990: Ошибка индекса в массиве Adobe Reader и Acrobat 9.x до версии 9.2, 8.x и 8.1.7, а также с версии 7.x до 7.1.4 позволяет выполнить произвольный код.
    В кодируемом FlateDecode потоке объекта 11 мы также обнаруживаем код в U3D:



    Теперь мы имеем URL, Shellcode, несколько CVE и этого вполне достаточно для данной статьи.

    Автор статьи: Андрей Ефимюк, эксперт в области ИБ, OSCP, eCPPT, хороший друг PentestIT.
    Оригинал статьи
    • +32
    • 16.9k
    • 4
    Pentestit
    69.49
    Информационная безопасность
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 4

      –5
      Если бы все было так просто. На грамотном PDF все действия обломаются ещё на пункте парсинга, так как не существует нормального парсера pdf формата.
        +3
        А можете поподробнее про этот пункт?
          –1
          У PDF есть куча штук, которые позволяют обфусцировать. На деле парсить pdf — это тоже самое, что парсить исполняемые бинарники, все время можно что-то придумать для сокрытия.

          Для анализа игрушечных уязвимостей описанный автором способ еще может прокатить.

          The detection rate of PDF malware by current antivirus software is very low. A PDF file is easy to edit and
          manipulate because it is a text format, providing a low barrier to malware authors. Analyzing PDF files for malware is
          nonetheless difficult because of a) the complexity of the formatting language, b) the parsing idiosyncrasies in Adobe
          Reader, and c) undocumented correction techniques employed in Adobe Reader
        +2
        Еще материал по теме — Analyzing Malicious PDFs

        Only users with full accounts can post comments. Log in, please.