Pull to refresh

Comments 18

Кстати, уже много лет спамеры используют похожий метод время от времени. Они передают свои хосты и линки через «referer» или параметры запроса.
Правда, эффективность этого метода для этих целей сомнительна, так как не все просматривают логи достаточно часто.
Это называется рефспам и эффективность его образуется вовсе не от того, что кто-то там вручную просматривает логи.

На самом деле при массовом рефспаме образуется куча ссылок на целевой ресурс со страниц статистики других ресурсов. У них там могут быть собственные анализаторы логов, торчащие наружу — например webalizer или awstat. В них указано что-то типа «за прошедшие сутки зафиксированы заходы с таких-то сайтов». Это полностью автоматический процесс и достаточно сделать один единственный запрос что бы попасть в такой лог. Поисковики видят такую статистику и раньше даже учитывали ссылки в ней.
На неправильно отконфигурированом софте эффективность тоже не фонтан, конечно.
Эффективнее почтовые серверы искать открытые, но это уже другая крайность.

Интересный метод старой доброй стеганографии.

И дополнительные очки — за использование публично доступных логов )

Только сверять не по MD5, наверное, его же поломали уже.
Тут проверка больше для валидности нужна. Даже CRC32 сойдёт для этих целей.
Ну всё-таки неплохо проверять аутентичность сообщения, и защиту от replay добавить. Впрочем, это уже не совсем про хеш.
Обычно тайники нужны для тех, кто про них знает. То есть, хороший тайник тот, который для незнающих выглядит как что-то обычное.
А так при желании можно просто шифровать перед base64.
Я про ситуацию, когда информация о тайнике утекла, но «знающие» ещё не знают об этом. Похоже, предусмотрительность кому-то тут не нравится.
UFO just landed and posted this here
Хм, мне вспоминается история:

– Учитель, я подобрал хороший пароль, которого не может быть в словарях.
Инь Фу Во кивнул.
– Я ввёл его в Гугле, – продолжал Сисадмин, – и убедился, что в Сети такого сочетания нет.
– Теперь есть.

Конечно, появятся альтернативы этому методу, но всё же общая концепция уже известна. Так что ваша фраза «Вряд ли СОРМ или система DLP будет сканировать URL'ы на предмет сжатых текстовых файлов» не совсем верна.
Не понял. Что значит ЛЮБОЙ веб сервер. Судя по всему тот на который есть доступ к серверу. А если есть доступ причем тут логи вообще, можно писать куда угодно. Или вопрос что если службы зайдут на сервер они не найдут там переписку? Так теперь найдут грепнув по слову transfer. Вообще какая-то муть
Ну это же не ISO, чтоб именно "?transfer?" использовать. Хотя статистический анализ с поиском нетипичных адресов в логах, возможно, подскажет нужное направление.
Так концепция же, например заменим веб сервер на почтовый, и читаем его логи на предмет EHLO «КОДИРОВАНЫЙ ПАКЕТ»… или x-referer-rkn даже
Вообще какая-то муть

Такое же ощущение после прочтения)
Тайник в поисковом сервере, кстати, еще проще. В их каше запросто можно писать открытым текстом )
Можно вспомнить, как раньше некоторые продвинутые компании размещали вакансии для разработчиков в заголовках HTTP или в коде HTML-страниц.

Теперь это в js-консоли делают и не только для разработчиков. Яркий пример на сайте qiwi.

Помню на одном из серверов, который я админил, как оказалось было уязвимое веб-приложение, через post запрос, можно было запустить любой php файл на сервере, злоумышленник это нашёл, но способа залить бэкдор к него не было. Но он увидел, что есть доступ к логам веб-сервера, сформировал так запрос, чтобы в логи попал валидный php код, а потом просто выполнил этот код через раннее найденную уязвимость, php интерпретатор успешно выполнил код из логов, и так он залил бэкдор. Сервер был тестовый для разработки, поэтому для удобства, логи доступны пользователю от которого бэк запущен. Мораль — логи надо защищать, не такая уж это безобидная вещь.
Sign up to leave a comment.