Как найти пароли в логах

Время на прочтение
9 мин

Количество просмотров 8.4K

Знаете ли вы что хранится в вашем git репозитории? Нет ли среди сотен коммитов паролей от продуктовых серверов, попавших туда по ошибке?

А что если ansible скрипт при публикации упадет и засветит пароли в логе?

Рассказываю о том как мы попробовали автоматизировать такие проверки и что из этого получилось.

Привет, Хабр!

Меня зовут Олег, я работаю в достаточно крупном для РФ банке, в подразделении «IT для IT».

Недавно к нам обратились друзья из внедрения (OPS) с просьбой помочь им автоматизировать процесс приемки изменений в скрипты деплоя (ansible) и конфигурации приложений на промышленных средах. 

Исторически у нас есть 2 git хранилища (на самом деле больше, но это не так важно), в одном команды хранят свой код, в другом хранятся скрипты деплоя, конфигурации приложений итд, в общем все что относится к OPS составляющей.

Так вот, исходя из принятого процесса скрипты и конфигурации для промышленных сред хранятся в master ветке и при вливании в нее нужен апрув от OPS. 

Почему именно так? Потому что кроме всего там же в git хранятся и пароли от сред (хоть и зашифрованные) и отвечают за них OPSы. Если какой то пароль засветится в логе Jenkins или попадет в открытом виде в git — это серьезная утечка и безопасность придет (с паяльником) именно к OPS.

Пароли в git? Серьезно?

Да, к сожалению серьезно. Конечно же для таких вещей нужно использовать системы secret management, такие как HashiCorp Vault, CyberArk Conjur итд.

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

Число команд, проектов и деплоев растет постоянно и ребята уже просто не могли анализировать то количество pull request которое к ним приходило.

Значит, будем автоматизировать!

Что анализируем?

Совместно с коллегами выявили 3 основных вектора утечки пароля, которые их интересовали и встречались наиболее часто:

Пароль в открытом виде 

---
    dev_ssh_username1: "admin"
    dev_ssh_password1: "admin123"

Тут все должно быть ясно — хранить пароли в открытом виде нельзя.

Передача параметров в shell или command таски ansible

- name: Deploy
  hosts: all
  tasks:
    - name: Update
      shell: "update.sh --user={{ update_user }} --password={{ update_password }}"

Тут опасность заключается в том, что если playbook будет вызван с -v то мы получим в логах наши секреты в открытом виде.

$ ansible-playbook deploy.yml -i env/DEV/hosts -v
TASK [Update] ******************************************************************
changed: [192.168.1.2] => {"changed": true, "cmd": "/home/dev/update.sh --user=secret_user --password=secret_password", "delta": "0:00:05.056532", "end": "2020-11-06 09:53:09.397355", "rc": 0, "start": "2020-11-06 09:53:04.340823", "stderr": "", "stderr_lines": [], "stdout": "Update SUCCESS", "stdout_lines": ["Update SUCCESS"]}

Или, если playbook упадет то в логе выведется строка с секретами (даже если не указывать -v)

$ ansible-playbook deploy.yml -i env/DEV/hosts
TASK [Update] ******************************************************************
fatal: [192.168.1.2]: FAILED! => {"changed": true, "cmd": "/home/dev/update.sh --user=secret_user --password=secret_password", "delta": "0:00:00.018710", "end": "2020-11-06 10:14:30.642419", "msg": "non-zero return code", "rc": 127, "start": "2020-11-06 10:14:30.623709", "stderr": "/bin/sh: /home/dev/update.sh: Нет такого файла или каталога", "stderr_lines": ["/bin/sh: /home/dev/update.sh: Нет такого файла или каталога"], "stdout": "", "stdout_lines": []}

Чтобы этого избежать можно использовать environment, например:

- name: Deploy
  hosts: all
  tasks:
    - name: Update
      shell: "/home/dev/update.sh $AUTH_DATA"
      environment:
        AUTH_DATA: "--user={{ update_user }} --password={{ update_password }}"

Тогда в вывод наши credentials не попадут. Еще можно указывать атрибут no_log.

Неосторожное использование withCredentials

У нас используется Jenkins, в котором для работы с credentials используется конструкция withCredentials. С помощью нее внутри pipeline можно получить credential, сохранить его в переменные и использовать, например для подключения к какой нибудь сторонней системе. Jenkins при этом будет маскировать в логе значение этих переменных.

Однако, если мы сделаем, например так:

node {
  stage('Jenkins Credentials | Decrypt Secret File') {
    withCredentials([file(credentialsId: 'credentials-id', variable: 'secretFile')]) {
      sh 'cat $secretFile'
    }
  }
}

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

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

Ищем пароли

Казалось что поиск паролей в открытом виде это какая то плевая задача. У нас в арсенале есть не только SonarQube но и Checkmarx. Уж они точно должны уметь решать эти задачи.

И вроде бы вот оно — есть такое правило для SonarQube Hard-coded credentials are security-sensitive

Но при внимательном рассмотрении оказывается что правило достаточно простое, оно проверяет попадает ли название переменной под определенный паттерн. Исходник, если интересно тут.

C Checkmarx оказалась так же картина — реагирует он очень выборочно. И правила там тоже очень простые (коллеги из Application Security рассказали). Например, такой код пропускает:

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.RestController;
 
@RestController
public class DemoController {
    @RequestMapping("/show_me_creds")
    public @ResponseBody String show_me_creds() {
        String thisIsMyLittleSecret = "qwerty12345";
        return thisIsMyLittleSecret;
    }
}

Изучив что есть на рынке пришли к выводу что будем смотреть в сторону opensource утилит. Запрос в google «find secrets in git» выдает нам примерно такие варианты:

• https://github.com/awslabs/git-secrets/blob/master/README.rst

• https://github.com/dxa4481/truffleHog/blob/dev/README.md

• https://github.com/Yelp/detect-secrets

• https://github.com/zricethezav/gitleaks

Попробовав их все мы остановились на Gitleaks, вот почему:

• Проводит анализ на основе regexp, которые можно расширять;

• Умеет учитывать энтропию при анализе;

• Репорты в json;

• Легко задавать исключения;

• В пилоте показал лучший результат.

Как он работает — в основе лежит toml файл с описанием правил, например: 

[[rules]]
  description = "generic secret regex"
  regex = '''secret(.{0,20})([0-9a-zA-Z-._{}$/+=]{20,120})'''
  tags = ["secret", "example"]

Кроме того в правиле можно указывать требуемую энтропию, например: 

[[rules]]
  description = "entropy and regex example"
  regex = '''secret(.{0,20})([0-9a-zA-Z-._{}$/+=]{20,120})'''
  [[rules.Entropies]]
    Min = "4.5"
    Max = "4.7"

В переводе на человеческий это означает: «Если мы встречаем строку кода, которая соответствует регулярному выражению, и эта строка попадает в пределы энтропии от 4,5 до 4,7, то это пароль»

Я не буду заниматься переводом документации, все прекрасно описано тут.

Пример срабатывания:

➜  ~  gitleaks --repo=gitleaks --repo=https://github.com/gitleakstest/gronit.git --verbose --pretty
INFO[2020-04-28T13:00:34-04:00] cloning... https://github.com/gitleakstest/gronit.git
Enumerating objects: 135, done.
Total 135 (delta 0), reused 0 (delta 0), pack-reused 135
{
        "line": "const AWS_KEY = "AKIALALEMEL33243OLIAE"",
        "offender": "AKIALALEMEL33243OLIA",
        "commit": "eaeffdc65b4c73ccb67e75d96bd8743be2c85973",
        "repo": "gronit.git",
        "rule": "AWS Manager ID",
        "commitMessage": "remove fake key",
        "author": "Zachary Rice",
        "email": "zricethezav@users.noreply.github.com",
        "file": "main.go",
        "date": "2018-02-04T19:43:28-06:00",
        "tags": "key, AWS"
}
...
...
WARN[2020-04-28T13:00:35-04:00] 6 leaks detected. 33 commits audited in 77 milliseconds 738 microseconds

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

Если произошло ложное срабатывание — достаточно занести строку в whitelist правила, например:

[[rules]]
  description = "entropy and regex example"
  regex = '''secret(.{0,20})['|"]([0-9a-zA-Z-._{}$/+=]{20,120})['|"]'''
  [[rules.Entropies]]
    Min = "4.5"
    Max = "4.7"
  [[rules.whitelist]]
    regex = '''secret.some_value_that_match_regexp_but_not_really_a_secret'''
    description = "ignore that string"

В результате мы пришли к такой схеме — при создании pull request через webhook вызывается Jenkins, который скачивает репозиторий, запускает для него gitleaks и если тот находит утечки — ставит статус NEED WORK.

Конечно мы немного затюнили правила под себя, так же мы поправили вывод, чтобы найденные gitleaks пароли не светились в логах (чтобы борясь с компрометацией мы не компрометировали пароли). 

Проверяем ansible

Двигаемся дальше, итак, мы хотим находить вот такие playbook, потому что не хотим случайно засветить в логах Jenkins наши креды.

- name: Deploy
  hosts: all
  tasks:
    - name: Update
      shell: "update.sh --user={{ update_user }} --password={{ update_password }}"

С ansible все просто — его легко распарсить, можно использовать OPA (рекомендую статью от Александра Токарева  по теме), можно самим быстро написать проверки в python.

Хорошо что мы этого не сделали, а вспомнили про Ansible Lint.

Это официальный линтер для Ansible, который имеет «из коробки» кучу полезных проверок, но нас интересует не это.

Нам были нужны вот эти 2 фичи:

• Возможность писать свои правила;

• Автоматическое сканирование и поиск playbook. Не нужно передавать конкретные файлы на проверку, можно запустить линтер в папке и он сам найдет их. 

Писать правила очень просто — правило представляет собой python код, в котором обязательно должны быть объявлены переменные id, short description, description и tags (их использует Ansible Lint для ведения списка правил) и методы match или matchtask, в которых мы пишем саму логику проверки. Более подробно предлагаю почитать в оригинальной документации.

Для нашей проверки мы используем matchtask, на вход которого поступает каждый найденный task, который мы можем анализировать. 

К сожалению я не могу здесь привести код именно нашего таска, но он похож на этот пример (полностью тут):

class CommandsInsteadOfModulesRule(AnsibleLintRule):
    id = '303'
    shortdesc = 'Using command rather than module'
    description = (
        'Executing a command when there is an Ansible module '
        'is generally a bad idea'
    )
    severity = 'HIGH'
    tags = ['command-shell', 'resources', 'ANSIBLE0006']
 
    _commands = ['command', 'shell']
    _modules = {
        'apt-get': 'apt-get',
#сокращаю список, чтобы не постить простыню
        'yum': 'yum',
    }
 
    def matchtask(self, file, task):
        if task['action']['__ansible_module__'] not in self._commands:
            return
 
        first_cmd_arg = get_first_cmd_arg(task)
        if not first_cmd_arg:
            return
 
        executable = os.path.basename(first_cmd_arg)
        if executable in self._modules and 
                boolean(task['action'].get('warn', True)):
            message = '{0} used in place of {1} module'
            return message.format(executable, self._modules[executable])

Логика примерно такая — если task является command или shell и первый аргумент является командой из списка _modules — рекомендуем заменить команду на модуль.

Нашу проверку мы организовали похожим образом — составили список интересующих нас аргументов (password/pass/login итд) и анализируем каждый аргумент тасков command и shell на попадание в список. 

Кроме того мы учитываем атрибут no_log, при его наличии аргументы не анализируем. Если в будущем разработчик уберет no_log — новый код опять попадет на проверку и наше правило это увидит.

Итак, после проверки Gitleaks запускается Ansible Lint, который в режиме автоматического сканирования прогоняет наше правило. Другие правила мы отключили, т.к. не можем навязывать командам использование линтера (хотя и рекомендует всем).

Проверяем withCredentials

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

node {
  stage('Jenkins Credentials | Decrypt Secret File') {
    withCredentials([file(credentialsId: 'credentials-id', variable: 'secretFile')]) {
      sh 'cat $secretFile'
    }
  }
}

А вот тут нас ждал провал.

Jenkinsfile это по сути groovy, который можно разобрать на Abstract Syntax Tree и анализировать.  Мы использовали AstBuilder чтобы получить дерево, научились находить withCredentials, анализировать его параметры и находить их использование внутри withCredentials. Например, код выше мы научились анализировать и реагировать на него.

Однако в жизни все сложнее, например я могу записать secretFile в глобальную переменную и использовать где-то в другом stage, могу записать secretFile в какой то временный файл итп итд. 

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

Кстати, если у вас используется только декларативный pipeline то потенциально можно использовать Pipeline model definition plugin, в котором можно конвертнуть pipeline в удобный json и анализировать уже его. Нам это к сожалению не подошло — у нас вовсю используется скриптовый.

Что в результате?

Мы провели внутренний пилот, в который попало 1000 pull request. Порядка 3% были ложные срабатывания gitleaks, в некоторых случаях были найдены реальные секреты, опасные скрипты ansible.

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

В конце так же хочу поделится интересными проектами, которые использовать в этой работе не удалось:

• https://nightfall.ai/resources/introducing-radar-api-detect-credentials-secrets-in-code-via-machine-learning/ — обещают интеллектуальный поиск паролей в исходниках. Кто-нибудь пробовал?

• https://www.shellcheck.net/ — поможет найти кучу проблем в shell скриптах.

• https://github.com/PyCQA/bandit — отличный security linter для python.

• https://twitter.com/leak_scavenger — просто интересный бот в твиттер, который сканит github, pastebin, ghostbin на предмет секретов, кредиток, приватных ключей итд. Исходники, конечно, доступны.

Возможно, вы и не думали, что с правильным подходом к поиску, вы можете взламывать аккаунты, устройства и просто находить тонны конфиденциальной информации, просто вводя запросы в Google.

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

Расширенное приложение операторов поиска Google — Google Dorking — использование операторов поиска для поиска определенных уязвимых устройств с помощью целевых поисковых строк. Если мы предположим, что Google проиндексировал большинство устройств, случайно подключенных к Интернету, мы можем использовать текст, который, как мы знаем, появляется на их страницах входа в систему или административных страницах, чтобы найти их.

Что понадобится?

Для этого вам понадобится браузер с доступом в Интернет. Всё.

Прекрасной особенностью использования Google dorks является то, что мы можем использовать инструменты, доступные почти каждому, для поиска уязвимых систем

Когда у вас откроется браузер, перейдите на Google.com, и мы сможем начать.

Поиск FTP-серверов и веб-сайтов с использованием HTTP

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

Поиск этих серверов может позволить нам найти файлы, которые должны быть внутренними, но по незнанию были обнародованы.

intitle:"index of" inurl:ftp after:2018

Эти серверы становятся общедоступными, потому что индексный файл их FTP-сервера это данные, которые Google любит сканировать.

Сканирование Google приводит к полному списку всех файлов, содержащихся на сервере.

Если мы хотим найти небезопасные веб-страницы, по-прежнему использующие HTTP для поиска, мы можем слегка изменить команду, изменив «ftp» на «http» и повторно выполнив запрос.

intitle:"index of" inurl:http after:2018

Поиск по этой строке должен привести к появлению списка сайтов, использующих HTTP и готовых к атаке. Но если мы ищем определенный тип сайта, мы можем пойти еще дальше.

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

intitle:"forum" inurl:http after:2018

Мы можем продолжать добавлять поисковые операторы, такие как AND inurl: «registration», чтобы получить более конкретную информацию и искать страницы регистрации незащищенных веб-сайтов.

Находим логи с паролями

Следующим шагом будет поиск файлов типа .LOG.

Поиск файлов LOG позволит нам выяснить, какие учетные данные могут быть у системы или у разных учетных записей пользователей или администраторов.

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

allintext:password filetype:log after:2018

При поиске текущих файлов журналов, мы находим это практически сразу.

Здесь указывается, что пароль не менялся и все такой же — по умолчанию.

С помощью одного запроса мы, возможно, нашли учетные данные этой системы, ничего не взломав.

Ищем файлы конфигурации с паролями

Конфигурационные файлы никогда не должны быть публичными и файлы .ENV являются отличным примером.

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

filetype:env "DB_PASSWORD" after:2018

Если мы удалим after: 2018, мы увидим старые файлы, которые также предоставляют открытый доступ.

Как насчет почты?

Списки адресов электронной почты — отличный способ разобраться и попытаться найти информацию в корпоративных или школьных целях.

Эти списки часто выставляются компаниями или школами, которые пытаются составить списки адресов электронной почты для своих людей.

Чтобы найти такие почты, мы будем искать тип файла .XLS электронной таблицы со строкой «email.xls» в URL.

Хотя эти таблицы и будут полезны, не загружайте ничего. Это может быть приманкой.

Камеры!

Если вы думали, что Shodan был единственным сервисом, который может найти открытые камеры, то вы очень сильно ошибаетесь.

Вход в систему с камеры и просмотр страниц обычно выполняются по протоколу HTTP.
Это означает, что Google с радостью проиндексирует их и предоставит их для просмотра, если вы знаете нужный запрос.

Одним из распространенных форматов поиска строк веб-камеры является «top.htm» в URL с указанием текущего времени и даты.

inurl:top.htm inurl:currenttime

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

inurl:"lvappl.htm"

С помощью этого, я смог найти лучшую камеру из всех — птичью!

Многие камеры также контролируют зоны внутри заводов или промышленных территорий.

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

Эта тактика, хотя и незаконна, позволяет легко получить доступ ко многим веб-камерам, не предназначенным для публичного просмотра.

Google Dorks дает возможность взламывать открытые сервисы

Благодаря тому, что Google индексирует практически все, что связано с Интернетом и предлагает веб-интерфейс, мы можем найти любую информацию, которую не скрыли от посторонних глаз.

Админ

Как чекать логи | Статья для новичков

---