Ставил утилиту по инструкции с сайта проекта: блок с командой, кнопка «скопировать», вставка в терминал. Перед Enter посмотрел на строку — вставилось не то, что было в блоке.
Проблема в том, что сайт полностью контролирует, что окажется в буфере обмена. Показать он может одно, положить — другое. И у страницы есть несколько способов сделать это так, что при вставке вы ничего не заметите.
Проверял, что видно про домен заказчика снаружи, и выписал имена из журналов Certificate Transparency. В списке оказались jenkins, gitlab-runner и пара стендов с именами вида test-2 — ни одного из них в публичном DNS не было.
Имя знает не только команда. Его знает весь интернет, причём с того момента, как вы выпустили на этот хост TLS-сертификат.
Патч был на две строки: правка в проверке прав доступа. На ревью читается ровно то, что задумано, — апрув, мёрж. Через день выясняется, что проверка не срабатывает, хотя код перед глазами правильный.
На ревью смотрят глазами. Глаз видит символы так, как их нарисовал шрифт, а интерпретатор читает байты. Между этими двумя представлениями есть зазор, и в него помещается логика, которую при чтении кода не видно.
Этим зазором пользуются двумя способами, и оба закрываются одной проверкой.
«Он подписан, издатель известный» — этим аргументом закрывают вопрос про стороннюю программу, которую тянут в сборку или ставят на рабочий компьютер. Возразить с ходу нечем: вкладка «Цифровые подписи» в свойствах файла и правда показывает «Эта цифровая подпись действительна». Случаи, когда вредоносный файл подписан настоящим сертификатом, редки — на них и не рассчитывают. В таких разговорах я обычно зануда.
Подпись действительно кое-что подтверждает. Просто не то, что от неё ждут. Она говорит: «этот файл в момент подписи выпустил вот такой издатель, и после подписи содержимое не меняли». Она не говорит: «файл безопасен», «издатель — тот, за кого себя выдаёт прямо сейчас» и «ключ не украли полгода назад».
Совет про токен в адресе страницы кочует из статьи в статью в одной и той же формулировке: не кладите его в URL, иначе он уедет в заголовке Referer на все сторонние ресурсы, которые подключает ваша страница.
Совет правильный по выводу и неправильный по обоснованию. Через Referer он давно никуда не уезжает. А вот сам токен из URL утекает — просто в других местах, и там его обычно никто не ищет.
Знакомая схема защиты от подмены. Сервер кладёт клиенту cookie user=guest&role=reader и рядом — подпись sha256(secret + данные), чтобы клиент не переписал reader на admin. Секрет знает только сервер, поэтому пересчитать подпись под изменённые данные клиент вроде бы не может.
Поломается не сама SHA-256, а конструкция вокруг неё: к данным можно дописать хвост &role=admin и предъявить к нему валидную подпись, не зная секрета вообще. Атака называется length extension, и в статье мы её проделаем на своём же сервере.
Ситуация из практики любой компании: сотрудник уволился, ноутбук сдал, пароль от гостевой и рабочей сети остался прежним. Формально сотрудник его не знает — вводил один раз при подключении, полгода назад, наизусть не помнит.
На самом деле пароль он унёс: если ноутбук уехал с ним, а иногда и просто потому, что пароль можно было посмотреть в системе одной командой в любой момент.
Разговор, который у меня повторяется примерно раз в квартал. Интеграция ходит к партнёрскому API, партнёр её режет. Разработчик ставит в запрос User-Agent от Chrome. Не помогает. Дальше идут версии про адрес, про частоту, про капчу — и все мимо.
Сервер понял, что это не браузер, ещё до того, как увидел хоть один HTTP-заголовок. User-Agent он в тот момент не читал, потому что читать было нечего: HTTP начинается после установления TLS, а решение принимается по первому же пакету рукопожатия.
За годы в SOC и на пентестах я привык к неприятному распределению: самый дорогой периметр обходится не через уязвимость в коде, а через того, кто за этим периметром сидит. Файрвол не устаёт, не хочет помочь и не боится начальства. Человек устаёт, хочет и боится.
Эта статья не про конкретные схемы «как разводят» — их пересказывают в каждой новости. Она про механику: что именно происходит с человеком в момент атаки, почему инструктаж почти не помогает и что работает вместо него.
Разбор, на который меня зовут регулярно, и заканчивается он почти всегда одинаково. База клиентов всплывает в продаже. Выгрузку за последний год получали десятки контрагентов — интеграторы, колл-центр, маркетинговое агентство, аудиторы. У всех был законный доступ. Файл у всех был один и тот же.
Дальше начинается разговор в жанре «это не мы», и закончить его нечем: копии побайтово одинаковые, доказать причастность нельзя ни к кому.
Чинится это не после инцидента, а до него — и стоит недорого. Каждый получатель должен получать копию, отличающуюся от остальных так, чтобы отличие не мешало работе и переживало пересохранение файла.
Характеристика, которую пишут в описании правила детектирования и произносят на защите архитектуры: обнаруживает 99% атак при доле ошибок в 1%. Звучит как хороший результат, и принимают её обычно без вопросов.
А вопрос тут есть, и он арифметический. При таких характеристиках почти каждое сработавшее правило окажется ложным — не потому, что правило плохое, а потому что атака редкая.
Заявка была скучная: клиент не проходит проверку по списку разрешённых адресов. Адрес его я вижу, адрес в списке есть, файрвол пакет пропускает. Приложение отвечает «доступ запрещён».
В логе стояло ::ffff:192.0.2.5, в конфиге — 192.0.2.5. Что строки разные, видно сразу. Но выглядит это как разное написание одного адреса: справа те же четыре октета, слева приписка, которую принимаешь за особенность формата. Поэтому проверять я пошёл конфиг, а не сравнение.
Строчка, которая встречается в скриптах повсеместно:
mysql -u admin -pSecretPass123 -e "select 1"
Пока команда выполняется, этот пароль видит каждый, у кого есть доступ к устройству — обычный, непривилегированный. Достаточно посмотреть список процессов.
Формулировка встречается в политиках конфиденциальности постоянно и звучит успокаивающе. На деле она означает одно из двух: либо в компании действительно шифруют пароли — и это плохо, — либо там не различают шифрование и хеширование, что тоже не добавляет уверенности.
Кнопка удобная: не надо придумывать пароль, не надо подтверждать почту, два клика — и вы внутри. Пользуются ей почти все, а вот что именно происходит при нажатии, представляют немногие. Между тем ответ на этот вопрос виден прямо в адресной строке, и посмотреть его стоит один раз, чтобы дальше решать осознанно.
Ситуация обычная: пришёл запрос на удаление персональных данных, разработчик выполнил DELETE FROM clients WHERE id = ..., отчитался. Формально всё правильно — строки в таблице нет, приложение её не видит, выгрузка не содержит.
А в файле базы она есть. Целиком, вместе с именем и номером карты, и достаётся обычным grep.
Обычная логика такая: не хочу, чтобы меня узнавали — открываю приватное окно, и всё, я новый посетитель. Логика была верной примерно до середины десятых годов.
Сейчас узнавание держится не на cookie, а на наборе свойств самого браузера. Их не надо никуда сохранять — они просто есть, и по их сочетанию посетитель определяется с высокой надёжностью. Очистка хранилища на это не влияет никак: удалять там нечего.
Регулярно слышу этот вопрос в разных формулировках. Индикатор сети мигает, когда ничего не открыто. Антивирус молчит, но кажется, что молчит зря. Или человек увидел в диспетчере задач незнакомое имя процесса и теперь не знает, что с этим делать.
Ответ на такой вопрос получается за десять минут стандартными средствами системы, без специальных программ и без переустановки. Показываю порядок действий и то, как отличать нормальное от ненормального — потому что вторая часть обычно оказывается сложнее первой.
Про публичный Wi-Fi принято говорить одно из двух. Либо «там воруют пароли, не подключайтесь», либо «сейчас везде HTTPS, всё в порядке». Обе формулировки неточные, и обе мешают понимать, что происходит на самом деле.
Пароли при работающем HTTPS действительно не украдут — с этим всё в порядке. А вот список сайтов, куда вы ходите, виден любому, кто сидит на том же канале — владельцу точки доступа, провайдеру, соседу с ноутбуком, если сеть открытая. Причём видно его в открытом виде, никакого взлома для этого не требуется.
Каждый раз, когда речь заходит про проверку паролей сотрудников по базам утечек, разговор упирается в один и тот же вопрос: вы что, предлагаете отправить наши пароли на чужой сервис?
Вопрос правильный. Ответ на него — нет, отправлять ничего не нужно, и это не обещание на словах, а свойство протокола, которое проверяется самостоятельно за пять минут. Механика там простая и красивая, а знают её почему-то немногие.
