Аудит эксплойтов

Отличные ссылки по этому процессу аудита. https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/

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

Сначала посмотрите на то, чего вы не делали. Если вы обычно мало что делаете на своём ADC, эти записи должны быть очень тихими, хотя в них могут быть записи за недели, месяцы или годы — с последнего раза, когда вы заходили. Более точные запросы приведены чуть ниже. Также поймите, что это игра в кошки-мышки, даже в этом блоге. Пока мы раскрываем то, что видели и как выявлять атакующих, они используют эту информацию против нас, меняя свою тактику, чтобы избежать обнаружения.

Контрольный список быстрой проверки эксплуатации v1

• 1. Проверьте свою лицензию. Я слышал о некоторых, кто перезагружал устройства и обнаруживал просроченную лицензию.
• 2. Получите Support File (Файл поддержки), иначе говоря Backup System -> Diagnostics -> Get Support File, и сохраните этот файл.
• 3. Все приведённые ниже команды выполняются в NSCLI, и если вы подключаетесь по SSH к коробке и используете Shell, вы можете опустить префикс Shell.
• 4. Проверьте дату на коробке, чтобы помочь сопоставить находки в логах
  • a. shell date
• 5. Проверьте дату изменения вашей конфигурации
  • a. Shell ls -l /netscaler/ | grep netscaler
  • b. Shell ls -l /nsconfig | grep netscaler
    • i. Какая дата у вашего netscaler.conf?
    • ii. Это выглядит правильно? Ищите файловые ссылки на другие места.
• 6. Проверьте файл локальных паролей учётных записей
  • a. Shell ls -lh /etc/passwd
    • i. Проверьте, когда файл был изменён. Если после эксплуатации и это не вы, то вам нужно сменить этот пароль как можно скорее.
    • ii. Я рекомендую сменить пароль nsroot или любых локальных учётных записей, если обнаружены какие-либо эксплойты. Во многих случаях
  • b. Shell cat /etc/passwd
    • i. Посмотрите, какие учётные записи там есть.
    • ii. Root, nsroot, daemon, operator, bin, nobody, sshd, nsmonitor — это стандартные.
• 7. Проверьте свои логи
  • a. shell ls -lh /var/logfile
    • i. Файлы на месте? Они очень маленькие?
    • ii. https://support.citrix.com/article/CTX121898
• 8. Проверка плохих файлов
  • a. Если какой-либо из этих файлов имеет длину более или менее 8-9 символов и случайное имя файла, это признак более продвинутого атакующего, который изменил стандартный эксплойт. Если вы это видите, вам нужно соответствующим образом скорректировать меры по устранению. Pwnpzi1337.xml — это имя файла для эксплойта Project India
  • b. shell ls /netscaler/portal/templates/*.xml
    • i. Здесь не должно быть XML-файлов.
    • ii. Если заражено, посмотрите на даты файлов здесь.
    • iii.shell ls -lh /netscaler/portal/templates/
  • c. shell ls /var/tmp/netscaler/portal/templates
    • i. Этот каталог не должен существовать.
    • ii. Если заражено, посмотрите на даты файлов здесь.
    • iii.shell ls -lh /var/tmp/netscaler/portal/templates
  • d. shell ls /var/vpn/bookmark/*.xml
    • i. Чаще всего не существует, но там также не должно быть XML-файлов.
    • ii. Если заражено, посмотрите на даты файлов здесь.
    • iii.shell ls -lh /var/vpn/bookmark/
  • e. shell ls /tmp/.init
    • i. Этот каталог не должен существовать.
• 9. Cron-задачи (методы сохранения присутствия)
  • a. shell cat /etc/crontab
  • b. shell crontab -l -u nobody
• 10. Проверка криптоджекинга
  • a. shell top -n 10
    • i. NSPPE-xx (Packet Engine) должен быть на 100% или около того, если там есть другой процесс, возможно, вас используют для майнинга
• 11. PCAP
  • a. Shell find / -name "*.cap"
  • b. Помогает найти любые посторонние файлы захвата, которые могли быть взяты.
  • c. Это будет признаком более продвинутого атакующего, который мог прослушивать трафик.
• 12. Логи Shell
  • a. shell cat /var/log/bash.log | grep nobody
    • i. Ищем доступ пользователя от nobody.
  • b. shell gzcat /var/log/bash.*.gz | grep nobody
    • i. Ищем доступ пользователя от nobody в сжатых логах.
• 13. Проверка логов Apache
  • a. shell "cat /var/log/httperror.log | grep -B2 -A5 Traceback"
  • b. shell "gzcat /var/log/httperror.log.*.gz | grep -B2 -A5 Traceback"
  • c. shell grep -iE 'POST.*.pl HTTP/1.1" 200 ' /var/log/httpaccess.log -A 1
  • d. shell grep -iE 'POST.*.pl HTTP/1.1" 200 143' /var/log/httpaccess.log -A 1
  • e. shell grep -iE 'GET.*.xml HTTP/1.1" 200' /var/log/httpaccess.log -B 1
  • f. shell grep -i '.pl HTTP/1.1" 200 143' /var/log/httpaccess.log | grep POST
    • i. Все эти команды ищут определённые элементы, связанные с перемещением файлов .pl и .xml в систему или из неё.
  • g. shell cat /var/log/httperror.log
    • i. Это просмотр необработанного содержимого файла в целом, чтобы найти другие выделяющиеся элементы.
• 14. Постоянные скрипты
  • a. shell ps -aux | grep python
  • b. shell ps -aux | grep perl
  • c. shell ps -auxd | grep nobody
    • i. Это оба известных метода сохранения присутствия, использующие скрипты для обратных оболочек и других задач. В списке процессов вы должны видеть только команду grep.
    • ii. Это описывает некоторые находки другого метода сохранения присутствия. Этот эксплойт использовал вредоносный процесс, запущенный пользователем Nobody. https://soolidsnake.github.io/2020/01/17/citrix_malware.html
• 15. Проверка паролей/учётных записей
  • a. shell ls -l /etc/passwd
    • i. Также посмотрите на дату файла, если что-то было недавно добавлено.
  • b. shell cat /etc/passwd
    • i. Что-то выглядит подозрительно? Локальные учётные записи?
• 16. Проверка TCP-соединений
  • a. Shell netstat -natu
  • b. Ищите нелокальные IP-адреса в ваших VLAN. Внутренние IP также следует проверить на случай, если другой компьютер был скомпрометирован.
• 17. Проверьте свои профили аутентификации
  • a. Были ли они установлены на TLS или SSL, а теперь стали PlainText?
    • i. Я видел, как в некоторых аудитах и онлайн их меняли.
    • ii. Это также признак продвинутого атакующего.
  • b. Это будет связано с тем, был ли изменён ваш конфигурационный файл ns.conf или, к счастью, нет.
  • c. Если раньше был PlainText, вам нужно как можно скорее перевести его на TLS и SSL, независимо от того, обнаружены ли признаки эксплуатации или нет.
• 18. Проверьте свои сертификаты
  • a. Это SSL-сертификаты, которые, возможно, нужно перевыпустить, особенно если ваш компьютер был скомпрометирован.
  • b. Я рекомендую при любых признаках эксплуатации перевыпустить SSL-сертификаты. Некоторые крупные развёртывания могут столкнуться с большими трудностями из-за количества других мест, где привязан этот сертификат, и возможных простоев/сбоев, которые может вызвать смена SSL-сертификата.
  • c. Я видел клиентов, которые не перевыпускали сертификаты, поскольку у них были хорошие логи, чтобы доказать, что они не делали ничего, кроме выполнения эксплойта, и не проникали в конфигурацию системы. У большинства клиентов может быть только пара дней логов
• 19. Проверьте свой конфигурационный файл на наличие потенциальных целей первого уровня
  • a. Просмотрите свой ns.conf — это создаст ваш список целей первого уровня, к которым, скорее всего, обращались в первую очередь, если устройство было скомпрометировано.

Если произошла эксплуатация

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

Какие органы по соблюдению требований охватывают ваш бизнес? Финансы/банковское дело, SOX, PCI, HIPPA, государственные/местные и федеральные законы.

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

Вот ссылки на два хорошо известных руководства по процессу реагирования на инциденты: https://security.berkeley.edu/incident-response-planning-guideline https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

Пока известно, что около 10-01-20 был выпущен первый публичный эксплойт, и есть сообщения о заражениях 9-го числа, так как он появился именно тогда. В большинстве случаев риск гораздо ниже, если вы обновили свою систему до 2020 года, а не позднее в этом месяце.

CVE-2019-19781 Примерный риск угрозы по времени

17–31 декабря — самый низкий риск эксплуатации 1–8 января — низкий риск эксплуатации 9–13 января — повышенный риск эксплуатации 14 января — настоящее время — самый высокий риск эксплуатации

Это должно войти в ваш процесс для дальнейших шагов.

Я обнаружил следы эксплуатации — что теперь? Это всё ещё зависит от ситуации. Одна из проблем в том, что большинство развёртываний Citrix ADC не настроены на хорошее ведение SNMP и SYSLOG, и у них может не быть хорошего способа поиска, фильтрации или оповещения при обнаружении артефактов. Если у вас есть абсолютное ведение логов и вы уверены, что ничего не было сделано, возможно, вы сможете продолжить жить дальше. Если же вы что-то нашли и смогли уверенно удалить их удалённый доступ, то тоже можно двигаться дальше.

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

Мои следующие советы будут меняться в течение ближайших двух недель.

Примерные пути реагирования на инциденты

Я не могу дать правильного и идеального ответа, который подойдёт для всех ситуаций — это мои мысли на данный момент (19-01-20), и они могут измениться по мере того, как я узнаю больше о следующих шагах и появятся новые данные со стороны защиты или атаки, связанные с этой уязвимостью. Правильного ответа нет; ИТ-безопасность — это область, где всем правит «зависит от ситуации». Я настоятельно рекомендую: если вы найдёте что-то, кроме только этих файлов в тех трёх каталогах, я бы считал коробку скомпрометированной и пошёл по более осторожному пути. В некоторых случаях я предлагаю более осторожный путь, особенно когда нет логов, чтобы подтвердить, что они сделали или не сделали. Вам нужно работать со своей командой, чтобы решить наилучший курс действий, исходя из вашей ситуации, потому что это командная работа. Всегда может быть лучший способ исправить такие вещи, но на основе имеющихся у вас доказательств на устройстве и вокруг него (цели первого уровня), возможно, вы сможете снизить риск и двигаться дальше.

• Смягчение: с этого нужно начинать в любом случае. Используйте новую прошивку или политику responder.
• Эксплойты обнаружены во время аудита.
  • Запустите процесс реагирования на инциденты.
• При хорошем ведении логов устройства
  • Признаки продвинутых атак или сохранения присутствия
    • Построить новую и мигрировать
  • Нет признаков продвинутых атак или сохранения присутствия
    • Исправить и продолжать работу
• Без ведения логов устройства
  • Признаки продвинутых атак или сохранения присутствия
    • Построить новую и мигрировать
    • Сброс до заводских настроек
  • Нет признаков продвинутых атак или сохранения присутствия
    • Построить новую и мигрировать
    • Сброс до заводских настроек
• При хорошем ведении логов целей первого уровня
  • Признаки продвинутых атак или сохранения присутствия
    • Построить новую и мигрировать
    • Сброс до заводских настроек
  • Нет признаков продвинутых атак или сохранения присутствия
    • Исправить и продолжать работу
• Без ведения логов целей первого уровня
  • Признаки продвинутых атак или сохранения присутствия
    • Построить новую и мигрировать
    • Сброс до заводских настроек
  • Нет признаков продвинутых атак или сохранения присутствия
    • Построить новую и мигрировать
    • Сброс до заводских настроек

Определение и мысли по ответным мерам

• Построить новую и мигрировать — начать процесс реагирования на инциденты, затем можно начать этот процесс https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html. Это относительно легко для клиентов VPX и SDX из-за виртуальной природы и гибкости платформы конфигурации. Миграция MPX — это другая история из-за того, как работает сброс до заводских настроек и поддерживается базовый образ; может быть очень низкий риск, если продвинутый атакующий мог сохранить присутствие через обновление прошивки и/или сброс до заводских настроек. Вероятность может быть ниже, но это всё ещё возможно (как и всё в кибермире).
• Сброс до заводских настроек — начать процесс реагирования на инциденты, удалить файлы .xml и всё остальное, что обнаружено, перезагрузить и снова проверить на сохранение присутствия. Затем запустить процесс сброса до заводских настроек. У Citrix можно получить скрипты, которые проведут через этот процесс. Это очистит систему до самого низкого уровня перед переустановкой операционной системы, но все будут доверять этому методу, исходя из своего ландшафта угроз, и, возможно, захотят большего.
  • Наиболее радикальный метод — отправить устройства по RMA для перезагрузки дисков. Это может быть хорошей или плохой идеей в зависимости от вашего жизненного цикла, платформы и плана резервирования. Я бы предложил это только в том случае, если вы видели продвинутые методы и подтвердили боковое перемещение на основе их техник, чтобы, возможно, пойти по этому пути. Я знаю, что Citrix работает над вариантами «что если» и
• Исправить — начать процесс реагирования на инциденты, удалить файлы .xml и всё остальное, что обнаружено, перезагрузить и снова проверить на сохранение присутствия. Если у вас есть хорошие логи, вы узнаете, было ли что-то сделано; если нет, то посмотрите на свой ландшафт угроз и, если у вас есть логи по целям первого уровня или что-то ещё, чтобы узнать, нужно ли рассматривать сброс до заводских настроек и/или построение новой системы и миграцию.

Уровни ведения логов

• Хорошее локальное ведение логов
  • Вы в наилучшей позиции, чтобы увидеть, что произошло локально и были ли попытки бокового перемещения или эксплойт был просто запущен, как в большинстве случаев.
• Хорошее ведение логов целей первого уровня
  • Вы в наилучшей позиции, чтобы увидеть, произошло ли боковое перемещение или была ли хотя бы попытка. Это должны быть первые вещи, которые могут быть атакованы; если вы видели успешное боковое перемещение, вам следует больше всего беспокоиться и действовать с большей осторожностью на пути исправления. Если нет, то вы можете снизить риск угрозы и просто пойти по пути исправления.
• Нет локального ведения логов
  • Вы в наихудшей позиции, чтобы увидеть, что произошло локально и были ли попытки бокового перемещения или эксплойт был просто запущен, как в большинстве случаев. Вам нужно действовать с большей осторожностью на пути исправления.
• Нет ведения логов целей первого уровня
  • Вы в наихудшей позиции, чтобы увидеть, произошло ли боковое перемещение или была ли хотя бы попытка. Это должны быть первые вещи, которые могут быть атакованы; если вы видели успешное боковое перемещение, вам следует больше всего беспокоиться и действовать с большей осторожностью на пути исправления.

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

Другие хорошие последующие шаги

Есть два основных момента, по которым нужно принять решение, если есть какие-либо следы эксплуатации.

• 1. Сменить пароль NSROOT
  • a. Я рекомендую сделать это независимо от того, что вы нашли или какие у вас логи. Это хорошая возможность включить nsroot в ротацию смены паролей. Управление ADC должно быть привязано к LDAP, а NSROOT должен использоваться только для экстренных случаев.
• 2. Сменить учётную запись службы LDAP (или другой службы аутентификации)
  • a. Смените этот пароль, а также я рекомендую по возможности перейти на другую учётную запись, чтобы у вас был и другой SID. Это может быть пассивное изменение, никто не заметит, если протестировать перед развёртыванием.
• 3. Сменить ключи SSL
  • a. Хорошее ведение логов
    • i. Возможно, всё в порядке, если вы на 100% уверены, что логи хорошие.
    • ii. Во мне ещё есть часть, которая хочет сказать — перевыпускайте всё, но я знаю, сколько это может быть работы в крупной организации.
  • b. Нет ведения логов
    • i. Думаю, вам придётся перевыпустить всё на устройстве. Есть защита PEM и PFX, но я видел много мест, где используются очень простые пароли, которые можно взломать офлайн. Поскольку мы не знаем, нужно защищать компанию.

Мысли о паролях

Я рекомендую сменить пароли для всех локальных учётных записей на коробке, если есть хоть малейшее подозрение на успешный эксплойт. Сделайте это, потому что во многих развёртываниях их могли ни разу не менять с момента первоначального развёртывания 4–7 лет назад. Если вы видите признаки доступа через командную строку и/или вмешательства, скорее всего, атакующий смог взломать пароль. На прошивках до версии 11.0 использовался AES256, а в более поздних сборках — AES512, что также можно взломать. Убедитесь, что он безопасно привязан к LDAP, и настройте оповещения для входов NSROOT.

Мысли о LDAP

Если вы заметили некоторые уровни эксплуатации, я бы также сменил все служебные учётные записи, определённые в конфигурации Citrix ADC. Самая распространённая — учётная запись привязки LDAP/Kerberos. Получение эксплойта на Citrix ADC не означает, что они стали администраторами домена, но в зависимости от ваших средств контроля и логов это может занять не слишком много времени. Это очень простое изменение, которое при тестировании может быть незаметным для пользователей.

Мысли о сертификатах

В зависимости от того, что вы нашли в ходе аудита, это поможет разобраться и с этим. Если у вас были хорошие логи и вы видите, что был запрошен доступ к этому файлу, нужно перевыпускать. Если у вас нет хороших логов, также нужно перевыпускать. Если у вас есть wildcard-сертификат, это ещё одна большая проблема: чем больше сайтов он привязан, тем больше ваш риск и подверженность. Худшее, что может случиться — вы предполагаете, что всё в порядке, а кто-то разворачивает фишинговый сайт с вашим сертификатом, и все ваши обучения не предотвратят клики. Это может привести к гораздо более серьёзным проблемам, если кто-то получит доступ к вашим сертификатам. Я бы предложил действовать с осторожностью и сделать перевыпуск. Это может быть подходящее время в зависимости от срока действия текущего сертификата. Я видел, как в этом процессе переходили к другому регистратору сертификатов, просто чтобы что-то изменить, но у них были логи, что файл был открыт и скачан, а также были обнаружены другие продвинутые техники.

Благодарности ###И последнее, но не менее важное: благодарности некоторым людям, которые работали над этой проблемой с момента её появления. Есть ещё много людей, не попавших в этот список, потому что они работают за кулисами, и я их тоже не видел.

• Команда Citrix – работа над распространением информации, а также над новыми версиями прошивок. Им приходится одновременно работать над 5 патчами из-за различий в семействах кода, что делает задачу ещё сложнее.
• Daniel Weppeler @_DanielWe – Политика регистрации Responder для обнаружения зондов/атак
• Florian Roth @cyb3rops – Файл YAR Nessus для обнаружения эксплуатации
• CTP Anton van Pelt @AntonvanPelt и CTA Mads Petersen @mbp_netscaler и Jan Tytgat @jantytgat – Постоянная работа с командами CTP\CTA и Citrix по многим направлениям.
• KevTheHermit @KevTheHermit – Раскрытие уязвимости паролей экземпляров AWS в дополнение к CVE
• Bad Packets Report @bad_packets – Вся команда Bad Packets https://badpackets.net
• Kevin Beaumont @GossiTheDog – Массовое продвижение информации о замеченных проблемах, а также некоторые детали о его honeypot и том, что он видел.
• Mpgn @mpgn_x64 – Подробности об эксплойте и его вариантах
• Nick Carr @ItsReallyNick – Подробности об эксплойте и советы по реагированию на инциденты.
• Digi Cat u/digicat – Пользователь Reddit, отличный блог с новостями.
• Ben Sadeghipour @NahamSec – Видео на YouTube по DFIR и другие материалы
• Команда SANs – Статьи, DFIR и видео с глубоким погружением
• Craig Dods @0xCraig – Последствия паролей и исследование
• Manuel Kolloff @manuelkolloff – Прохождение пост-эксплуатации.
• Команды FireEye и Mandiant: Спасибо Рику Коулу за создание самого раннего покрытия обнаружения и команде реагирования на инциденты Mandiant за вклад в этот блог — особенно Остину Бейкеру, Брендану Шондорферу и Джону Прието — а также всем консультантам, которые реагируют на эту уязвимость или защищают от неё среды своих клиентов. Также спасибо Николасу Людтке из нашей команды по анализу уязвимостей за помощь в уточнении временной шкалы раскрытия и инструментов в этом блоге.