Информации на прошлом этапе было собрано достаточно. Теперь мы будем активно работать с сайтом. Много следить в логах, использовать кул-хацкерские программы, сканерочки, парсерки и прочие веселые программки.
Общая схема того, что мы будем делать на данном этапе такая:
Ничего страшного, все довольно просто. Мы пойдем по списку:
Поиск и эксплуатацию уязвимостей оставим для следущих уроков, а пока мы занимаемся исключительно сбором информации.
Активный сбор информации.
1. Определение CMS. Пробуем определить используемую CMS (или CMSки, ведь никто не запрещает использовать несколько CMS на одном домене). Если используется распространенный движок, то определить это можно с вероятностью в 99%.
Если вам в лом самим определять CMS, можете воспользоваться сервисами:
Можно использовать плагин для браузера - wappalyzer.
Очень удобно, сразу видно движок, язык, js-фреймворки и т.д.:
Joomla 1.5
Файлы и Папки. CMS можно определить по наличию/отсутствию некоторых файлов и папок. Например, в большинстве CMS есть файлы с названиями типа Changelog.htm, readme.txt, config.example и подобными. Скачиваем распространенные движки, изучаем структуру файлов и папок, пробуем найти интересные файлы/папки на изучаемом сайте.
Таким способом можно очень точно определить используемый движок и его версию.
Просто потренируйтесь - устанавливайте разные движки, ставьте разные шаблоны, плагины. После небольшой практики, вы сможете определять движок взглянув одним (прищуренным) глазом на главную страницу.
В результате, после выполнения всех вышеописанных проверок, возможны 3 варианта:
2. Определение тем/плагинов/модулей/компонентов. Если мы работаем с одной из распространненых CMS, то мы можем проверить еще и модули/плаигны. Для этого можно быстренько набыдлокодить свой убер-скрипт либо воспользоваться существующим софтом (к примеру для скана плагинов WP):
Разумеется, этот пункт относится только к популярным движкам (wp, joomla, drupal и подобным), а не студийным поделкам сумрачных гениев.
3. Ищем уязвимости в CMS. Первым делом идем на bug-трекеры. Чекаем CMS на сайтах:
Стоит особенно отметить 1337day (наследник милворма):
И exploit-db:
Если сплойт не пашет, то внимательно изучите исходник, есть шанс, что в сплойте допущена ошибка (по старой хэккерной традиции). Также очень часто бывает, что исходники движка нельзя найти, а сплойт под движок - легко.
Если ничего в паблике не нашлось, идем на страницы разработчиков и внимательно читаем changelog. Какие ошибки были исправлены, когда, обязательно обращаем внимание на патчи связанные с безопасностью.
4. Сканер директорий. После того как мы узнали CMS (или не узнали), мы натравливаем на сайт сканер директорий - DirBuster.
DirBuster многопоточен, кроссплатформенен, красив и умен. Скачать можно по ссылке - http://sourceforge.n...cts/dirbuster/. Благодаря сканеру директорий, мы можем найти:
Обыкновенно, сторонние скрипты подключают as is, не беспокоясь о возможных уязвимостях. В общем никогда не забывайте пользоваться сканером директорий, даже если CMS определена и плагины успешно найдены. Может быть в забытой кодерами папке /upload_old/new1/new11/new1111/old/upload.php вас ждет форма заливки файлов без проверки на расширения и прочие условности.
5. Сбор параметров. После того как мы просканировали директории и файлы, необходимо узнать все точки входа.
Образно говоря, если бы мы грабили квартиру, то сначала проверили бы все двери, окна, замки, затем выбрали самую уязвимую цель (открытая форточка, фанерная дверь, китайский замок), затем мы бы начали использовать отмычки(или другой инструмент), чтобы попасть внутрь.
В хаке сайтов все то же самое - находим все точки входа в приложение (Get, post, cookie, заголовки приложения), затем ищем уязвимые параметры и пытаемся их экплуатировать (только если домушник пихает отмычки в замок, мы пихаем кавычки и скобки
Общая схема того, что мы будем делать на данном этапе такая:
Ничего страшного, все довольно просто. Мы пойдем по списку:
- Определение CMS
- Определение тем, плагинов, модулей, компонентов
- Поиск уязвимостей в CMS и плагинах
- Сканирование директорий
- Краулер
- Обход mod_rewrite (и аналогов этого модуля)
- Сбор параметров (Get, Post, Cookie, Headers)
Поиск и эксплуатацию уязвимостей оставим для следущих уроков, а пока мы занимаемся исключительно сбором информации.
Активный сбор информации.
1. Определение CMS. Пробуем определить используемую CMS (или CMSки, ведь никто не запрещает использовать несколько CMS на одном домене). Если используется распространенный движок, то определить это можно с вероятностью в 99%.
Если вам в лом самим определять CMS, можете воспользоваться сервисами:
Можно использовать плагин для браузера - wappalyzer.
Очень удобно, сразу видно движок, язык, js-фреймворки и т.д.:
Joomla 1.5
- Joomla. http://target.com/administrator
- WordPress. http://target.com/wp-admin/
- Drupal. http://target.com/user
- DLE. http://target.com/admin.php
- Любая другая CMS - http://google.com/?q...админку+cmsname
Файлы и Папки. CMS можно определить по наличию/отсутствию некоторых файлов и папок. Например, в большинстве CMS есть файлы с названиями типа Changelog.htm, readme.txt, config.example и подобными. Скачиваем распространенные движки, изучаем структуру файлов и папок, пробуем найти интересные файлы/папки на изучаемом сайте.
Таким способом можно очень точно определить используемый движок и его версию.
Просто потренируйтесь - устанавливайте разные движки, ставьте разные шаблоны, плагины. После небольшой практики, вы сможете определять движок взглянув одним (прищуренным) глазом на главную страницу.
В результате, после выполнения всех вышеописанных проверок, возможны 3 варианта:
- CMS определена, исходники можно изучить.
- CMS определена, но нет возможности изучить исходники.
- CMS не определена.
2. Определение тем/плагинов/модулей/компонентов. Если мы работаем с одной из распространненых CMS, то мы можем проверить еще и модули/плаигны. Для этого можно быстренько набыдлокодить свой убер-скрипт либо воспользоваться существующим софтом (к примеру для скана плагинов WP):
Разумеется, этот пункт относится только к популярным движкам (wp, joomla, drupal и подобным), а не студийным поделкам сумрачных гениев.
3. Ищем уязвимости в CMS. Первым делом идем на bug-трекеры. Чекаем CMS на сайтах:
- http://1337day.com/
- http://exploit-db.com/
- http://securityfocus.com/
- http://securiteam.com/
- http://osvdb.org/
- http://cxsecurity.com/exploit/
- http://packetstormse...s/tags/exploit/
- http://cve.mitre.org/
Стоит особенно отметить 1337day (наследник милворма):
И exploit-db:
Если сплойт не пашет, то внимательно изучите исходник, есть шанс, что в сплойте допущена ошибка (по старой хэккерной традиции). Также очень часто бывает, что исходники движка нельзя найти, а сплойт под движок - легко.
Если ничего в паблике не нашлось, идем на страницы разработчиков и внимательно читаем changelog. Какие ошибки были исправлены, когда, обязательно обращаем внимание на патчи связанные с безопасностью.
4. Сканер директорий. После того как мы узнали CMS (или не узнали), мы натравливаем на сайт сканер директорий - DirBuster.
DirBuster многопоточен, кроссплатформенен, красив и умен. Скачать можно по ссылке - http://sourceforge.n...cts/dirbuster/. Благодаря сканеру директорий, мы можем найти:
- WYSIWIG-редакторы
- файловые менеджеры
- phpmyadmin (и аналоги)
- скрипты статистики
- старые версии скриптов (index.php.old и т.д.)
- бекапы
- многое другое
Обыкновенно, сторонние скрипты подключают as is, не беспокоясь о возможных уязвимостях. В общем никогда не забывайте пользоваться сканером директорий, даже если CMS определена и плагины успешно найдены. Может быть в забытой кодерами папке /upload_old/new1/new11/new1111/old/upload.php вас ждет форма заливки файлов без проверки на расширения и прочие условности.
5. Сбор параметров. После того как мы просканировали директории и файлы, необходимо узнать все точки входа.
Образно говоря, если бы мы грабили квартиру, то сначала проверили бы все двери, окна, замки, затем выбрали самую уязвимую цель (открытая форточка, фанерная дверь, китайский замок), затем мы бы начали использовать отмычки(или другой инструмент), чтобы попасть внутрь.
В хаке сайтов все то же самое - находим все точки входа в приложение (Get, post, cookie, заголовки приложения), затем ищем уязвимые параметры и пытаемся их экплуатировать (только если домушник пихает отмычки в замок, мы пихаем кавычки и скобки
