ВЕБ-ХАКИНГ

ВЕБ-ХАКИНГ

INHIDE
Быстро подписался, если хакером назвался!

Введение

На повестке дня три вопроса.

  1. Чем мы будем заниматься?
  2. Что мы получим в итоге?
  3. Какие начальные требования?


1. Мы будем учиться находить и эксплуатировать уязвимости в веб-приложениях.

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

Проще говоря, вы врубитесь что к чему и в конце курса получите мощный пинок в нужное место и в нужном направлении.

3. Начальные требования.

Что нужно для прохождения курса? Браузер, denwer (или аналог).

Все остальное будет идти в комплекте либо будут даны ссылки на соответствующие ресурсы.

Предполагаю, что вы хотя бы шапочно знаете:

  • html, css, javascript
  • SQL
  • php
  • regexp
  • nix-системы
  • Tcp/Ip
  • http-протокол
  • Apache (базовая настройка, модуль mod_rewrite)


Если вам нужно освежить знания, я рекомендую следующие материалы:

  • html, css - Самоучители на htmlbook.ru (да и вообще, недостатка в материалах по html/css нет).
  • javascript - Самоучитель на learn.javascript.ru, Курсы Специалиста (specialist.ru) по javascript.
  • SQL - базовые знания даст книжка "SQL - 10 минут на урок".
  • RegExp - базовые знания даст книжка "Регулярные выражения - 10 минут на урок"
  • nix - базовые знания даст книжка "UNIX - 10 минут на урок"
  • php - Курсы Специалиста по php, уровень 1/2.
  • http, Apache - Курсы Специалиста "Веб-мастеринг", RFC 2616

Это теоретический минимум, необходимый для понимания уроков курса. Все перечисленные выше материалы легко усваиваются и их легко найти в инторнетах (торрентах и т.д.).

В связи с тем, что я не обещал 1000 шеллов в день и дохода в 10к $$$ в неделю, тот факт что вы дочитали до данного места, говорит о том, что у вас действительно есть шансы, чтобы чему-то научиться.

Сбор информации

Как вы уже догадались из названия, начальный этап перед любым взломом это сбор информации о цели (рекогницировка, как говорят на курсах CEH). Техники описанные ниже, позволят собрать первоначальные данные о цели. Этих данных уже хватит, чтобы понять с чем придется работать (и стоит ли вообще работать... может лучше потроллить школоту в вк, да выпить чаю).

Пассивный сбор информации:

  • Узнаем IP
  • Whois
  • DNS
  • Сканируем порты
  • Хостинг
  • Reverse-IP
  • SEO-параметры
  • Разработчики
  • Контакты
  • Сотрудники
  • Вакансии
  • Конкурентная разведка
  • Веб-архив
  • Поисковые системы
  • Блек-листы

Пассивный сбор информации.

1. Узнаем IP. Тут все относительно просто. Запускаем консольку (Win+R, печатаем 'cmd', жмем Enter) и пишем всем знакомое:

(Пожалуйста, продолжайте читать, дальше все не настолько плохо))

Удобнее установить в браузер плагин, который будет сразу показывать IP сайта.

Подобные плагины можно найти практически под любой браузер.

В некоторых (крайне запущенных) случаях можно воспользоваться онлайн-сервисами:

Вполне может быть, что у ресурса IP не один, а сразу несколько:

Попробуйте, возможно это не будет лишним.

2. Whois. После того, как мы узнали IP адрес домена, воспользуемся сервисом whois, чтобы узнать немного дополнительной информации.

В данном случае мы воспользовались сервисом whoer.net. Мы увидели страну и провайдера, которому принадлежит IP адрес. Помимо этого, мы можем увидеть некоторые дополнительные данные:

Очевидно, что IP принадлежит сервису CloudFlare, что в свою очередь значит, что реальный IP сайта от нас скрыт (можно воспользоваться сервисом http://exonapps.nl/cfresolver/).

Проделываем те же самые операции только для домена (данные везде от балды, не удивляйтесь, что ip cloudflare, a ns-сервера - хостер.ру).

Мы можем увидеть ns-записи. Чаще всего они прямо указывают на хостинг сайта. Иногда - на проксирующий сервис. Иногда на сам домен, что позволяет заключить, что сайт находиться на выделенном сервере.

Легко найти сервисы для проверки whois:

Стоит добавить, что есть такой замечательный сервис - http://www.whoishistory.ru/. Благодаря ему, мы можем узнать, как изменялись данные whois (сейчас, например, почта вообще не показывается).

У этого сервиса есть один минус - работает он только с доменами .ru, .su и .рф. Для буржуйских сайтов существует сервис http://www.domaintools.com/research/whois-history/, но он к сожалению платный. А для триала нужен картон...

3. Проверяем dns-записи. Существует большое количество самых разных видов DNS-записей (A, MX, NS, CNAME, SOA, SRV, PTR, RP, HINFO). Нам нужно узнать поддомены сайта - увеличить количество целей для атаки, и следовательно увеличить шансы взлома.

Чтобы узнать поддомены, можно воспользоваться запросом в гугл вида:

site:*.target.com

Все ссылки в выдаче будут вести на поддомены, не закрытые от индексации.

Но, чтобы получить все dns-записи, мы спросим все что нам надо у DNS-серверов. Есть такая штука, под названием передача зоны DNS (AXRF). Нужно это для того, чтобы DNS сервера поддерживали в актуальном состоянии свои базы (если вам нужны детали - википедия вас ждет с распростертыми объятьями). Т.е. отправили AXRF-запрос, получили все DNS-записи. В нормальном режиме это полезная штука, но когда DNS-сервер отвечает всем подряд без разбора, это уже несекьюрно.

Я не в курсе, что касается windows, но на *nix команда выглядит так:

dig -t AXFR target.com @ns.target.com

Разумеется есть и онлайн-сервисы:

В случае успеха, мы получаем все DNS-записи:

Разумеется, это не всегда получится (не все dns-сервера отдают инфу кому попало), да и не у всех сайтов вообще есть поддомены. Если не получилось узнать с помощью AXRF, стоит воспользоваться брутфорсером поддоменов.

https://code.google.com/p/dns-discovery/

Аналогов не нашел, но при желании можно самому накодить подобный скрипт.

4. Сканируем порты. Получив большой список поддоменов, IP, мы натравливаем сканер портов, например nmap:

И разумеется не только в дефолтном режиме (об этом напишем в других статьях).

Мы должны определить все открытые порты, сервисы, ОС.

Если нет желания палить собственный IP, или лень разбираться с nmap то можно воспользоваться сервисами:

Возможно найдется рабочий эксплоит под какой-то из сервисов/демонов, может быть сможем сбрутить ftp, ssh, rdp, и тогда даже не нужно будет возиться с веб-приложением. В любом случае — чем больше информации о цели, тем проще найти лазейку.

5. Хостинг.

Способы определения хостинга:

5.1. Домен третьего уровня (к примеру - target.freehosting.com, кто является хостером, очевидно).

5.2. Реклама на сайте. Частенько, фрихостинги пихают свою рекламу во все возможные места - popup, iframe, шапка, футер. В таком случае, определить хостинг не составляет труда.

5.3. 403/404. Пробуем открыть заведомо несуществующую страницу (вызвать ошибку 404). Или попытаемся вызвать ошибку 403 - пробуем зайти в папки /admin/, /images/ и т.д. Очень часто мы увидим заглушку от хостера.

5.4. index.html. При создании нового сайта в этом файле может находиться заглушка от хостера.

5.5. NS-записи. Изучая ns-записи, мы можем столкнуться с тремя ситуациями:

  • Сайт: target.com
  • ns-записи: ns1.hosting.com, ns2.hosting.com
  • Наиболее распространенный случай на shared хостингах. Хостингом является hosting.com.
  • Сайт: target.com
  • ns-записи: ns1.target.com, ns2.target.com
  • Владелец сайта использует свои собственные dns-сервера. Вероятно это VDS/DS.
  • Сайт: target.com
  • ns-записи: ns1.freedns.com, ns2.freedns.com
  • Владелец сайта использует сторонние dns-сервера. Вместо freedns.com может быть любой другой подобный сервис.

5.6. Проверяем данные по IP адресу. Смотрим на e-mail для контакта. Выглядят они как admin@superhost.com. Очевидно, что стоит смотреть на сайт superhost.com. Это может быть мыло как хостера, так и датацентра, где хостер арендует/держит серваки. В любом случае, хоть какая-то информация.

5.7. Заходим по IP адресу. Т.е. если Ip сайта - 123.123.23.23, мы вбиваем в браузере http://123.123.23.23/ и смотрим, что нам выдаст веб-сервер. У крупных хостеров стоит заглушка (по которой мы хостера резко и чотка опознаем). У мелких хостеров мы увидим либо вход в панель управления (ISP и подобные), либо один из сайтов, которые находятся на данном сервере.

5.8. Reverse DNS lookup. На линухе достаточно пингануть IP, на винде - использовать nslookup. Хостинг получается определить благодаря тому, что в PTR записях обычно используется название хостинга:

Например тут видно, что хостер - webhost1.ru. Для получения тех же результатов можно воспользоваться одним из сервисов:

5.9. Traceroute. Воспользуемся штатной утилитой traceroute (в винде - tracert).

Благодаря трассировке, мы узнаем не только хостера, но и дата-центр (в данном случае это hetzner.de) Ежели лень наша не знает границ, мы опять таки, воспользуемся онлайн-сервисами:

5.10. SMTP. Делаем коннект на 25 порт. Если там висит почтовый сервис, он нам сходу выдаст имя хоста (способ похож на предыдущие 2 - определяем хостинг по имени хоста).

Набираем:

telnet

o firststeps.ru 25

Видим:

Но, как и всегда, мы можем не напрягать свой мозг и использовать сервисы:

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

Проделав вышеописанные операции мы с вероятностью в 90% определим хостинг сайта. Исключение составят те случаи, когда IP сайта скрыт сервисами типа cloudflare или чем-то подобным.

Итак, что мы можем узнать, зная хостинг:

Виртуальный хостинг. Топаем на сайт хостера, изучаем сайт, изучаем форум, если он есть. Читаем FAQ. Можно даже оплатить аккаунт или взять тестовый, чтобы изучить хостинг вдоль и поперек. Смотрим, как происходит восстановление пароля, как происходит взаимодействие с техподдержкой. Работает ли ftp, ssh, что возможно сделать через панель хостера. Есть ли WAF. Какие настройки php (можно попросить показать вывод функции phpinfo()).

Узнаем, были ли взломы сайтов данного хостера. Если были, то как это происходило, есть ли дыры сейчас.

Если сайт находится на платформе типа ucoz, blogspot или подобных, то поиск уязвимостей на сайте равносилен поиску уязвимостей на самой платформе (что существенно усложняет задачу). Однако, есть плюс в том, что мы можем использовать методы социальной инженерии не только к владельцу сайта, но и к техподдержке хостинга.

VPS/VDS/DS. Если хостер так и не определен, то скорее всего мы имеем дело с выделенным сервером. В некоторых случаях это может быть арендованный сервер в дата-центре, может и домашний комп со белым IP, который не выключают сутками. Есть шанс, что админ выделенного сервера не настолько опытен, как админы крупных хостингов, и совершил ошибки при настройке сервера.

Данные phpinfo() на некоторых хостингах

Данные phpinfo() на некоторых хостингах:

Эта инфа выдрана с сайта hosting-ninja.ru (там чуть больше хостингов).

Наиболее интересны для нас следующие директивы php:

  • allow_url_fopen - поддержка оберток URL (URL wrappers), которые позволяют работать с объектами URL как с обычными файлами.
  • allow_url_include - возможность использования URL в функциях include, include_once, require, require_once (одно из основных условий для уязвимости RFI).
  • display_errors - опция отвечающая за отображение ошибок в выводе страницы, если отключена, то вы не увидите ничего вроде "Warning:....", "Deprecated:....", "Fatal error:....", "Parse error:....", либо пустой экран, либо вывод без ошибок (основное условие для уязвимости FPD).
  • expose_php - если включена, то в заголовках ответа можно узнать версию php
  • file_uploads - опция, разрешает/запрещает загрузку файлов на сервер, с помощью php (могут возникнуть сложности при заливке шелла).
  • magic_quotes_gpc - автоматическое экранирование кавычек, двойных кавычек, нулл-байта, обратного слеша обратным слешем в данных полученных из Get/Post/Cookie (могут возникнуть сложности при эксплуатации SQL-инъекций)
  • register_globals - уже редкость, чаще всего отключена. Если включена, то есть возможность передавать значения переменных через get, post, cookie.
  • safe_mode - безопасный режим. Много ограничений, включается запрет функций использования команд.
  • safe_mode_exec_dir - если включено, то можно запускать команды в пределах указанной директории (у недалеких админов бывает равно "/", что сводит на нет эту директиву).
  • disable_functions - Отключенные функции (чаще всего отключают функции выполнения команд).




Report content on this page

Report Page

Please submit your DMCA takedown request to dmca@telegram.org