47 lines
3.5 KiB
Markdown
47 lines
3.5 KiB
Markdown
<h1 align="center">Admission Drift</h1>
|
||
|
||
<p align="center">
|
||
<img src="https://img.shields.io/badge/category-Forensic-blueviolet" alt="Forensic"/>
|
||
<img src="https://img.shields.io/badge/difficulty-medium-orange" alt="medium"/>
|
||
</p>
|
||
|
||
В архиве `admission_drift_case.zip` находятся материалы инцидента с admission-контроллером ingress-nginx. Нужно восстановить последовательность событий от входящего AdmissionReview до чтения секрета. Флаг состоит из четырёх частей, которые находим по журналам.
|
||
|
||
## Решение
|
||
|
||
Проверяем переходы по файлам архива.
|
||
|
||
| Артефакт | Что подтверждает |
|
||
|---|---|
|
||
| `network/admission_service_access.jsonl` | Источник запроса и `review_uid` |
|
||
| `admission/reviews/review-*.json` | Тело AdmissionReview |
|
||
| `ingress-nginx/controller.log` | Обработку запроса контроллером |
|
||
| `ingress-nginx/config_snapshots.tar` | Сгенерированный `nginx.conf` |
|
||
| `runtime/falco_events.jsonl` | Фактическое обращение к файлу |
|
||
| `rbac/secret_access.jsonl` | Успешное чтение секрета |
|
||
|
||
Начинаем с access log. Ищем `POST`, у которого `source_category == "workload-pod"` и `apiserver_proxy == false`. Запрос пришёл прямо от workload-пода, минуя API server. Из записи берём `review_uid`, начинающийся с `84f1d2`, и путь `review_file`.
|
||
|
||
Открываем указанный JSON и сверяем `request.uid`. В аннотациях объекта находим `validation-template`: именно она запускает обработку шаблона. Тот же UID встречается в логе контроллера.
|
||
|
||
Для поиска снимка берём первые шесть символов UID, то есть `84f1d2`. В `ingress-nginx/config_snapshots.tar` читаем соответствующий `snapshots/review-84f1d2/nginx.conf`. В конфиге есть путь вида `/proc/<pid>/fd/<n>` — обращение к файловому дескриптору процесса. Одного конфига мало, поэтому ищем в Falco событие с тем же `review_uid` и точно совпадающим `fd.name`. Из поля `marker` совпавшего события получаем `procfd`.
|
||
|
||
Переходим к журналу секретов. Выбираем запись с тем же UID, `verb=get`, `resource=secrets`, `response_code=200`. Хвост имени прочитанного секрета — `7c19`.
|
||
|
||
Собираем нормализованные компоненты:
|
||
|
||
| Компонент | Значение |
|
||
|---|---|
|
||
| Тип потока | `ad` |
|
||
| Первые шесть символов UID | `84f1d2` |
|
||
| Маркер из runtime-события | `procfd` |
|
||
| Хвост имени секрета | `7c19` |
|
||
|
||
Соединяем их через `_`. Совпадение UID и пути дескриптора на промежуточных шагах подтверждает, что запрос, конфиг, runtime-событие и чтение секрета относятся к одному инциденту.
|
||
|
||
[Солвер](solve/solve.py).
|
||
|
||
## Флаг
|
||
|
||
`caplag{ad_84f1d2_procfd_7c19}`
|