И так, третья часть...материала, созданного в моем воспаленном от жары мозге!:)
На дворе в тени, +33 С!
Трюк первый:
Данные из БД-шки, доверяют почти 99% приложений. При заносе в БД данные тщательно проверяются, но не наооборот. Самый смак в том, что даже если на серваке включен - magic_quotes и найденный инклуд невозможно проэксплуатировать, то MySQL дает отличный козырь, посколько он вполне "хавает" NULL-байт.:) Ну а в базе может хранить путь к двигу, шаблону,языку, который входит в часть пути инклуда....
Модуль восстановления БД, есть практически везди на сегодняшнее время...
и вот так нехитрым образом, можно посмотреть базу аккаунтов на сервере:
UPDATE cms_config SET lang=contact ( ' rus/../../../../etc/passwd ' , 0x00 ) ;
Сладкое "печенье":
Предположим, с помощью найденной баги удалось перехватить хэш пароля админа, но вот незадача - вход в админку реализуется только по паролю (не в виде хэша:( ), неужели брутить!??? Не спешим запускать "крылатую с гуманной ядренной боевой частью" любимый брутфорс...внимательно копаемся в сорцах с целью выяснения механизма авторизации, в 50% вовсе не обязательно - "сразу колоть хэш" - достаточно элементарно сгенерировать валидный кукиз, на его основе и админка будет нами открыта, "как Бог черепашку"!?:)
Кстати еще не все движки используют сессии, время жизни сессии/кукиза, или хитрый алгоритм с солью, что препятствует использованию добытого хэша в хакерских целях:(
Трюк второй:
Автоматизация - Рано или поздно настает время написания эксплоита на удачно найденный баг!
Не волнуемся, тут нет ничего архисложного. Новичку на первое время можно по рекомендовать разобраться в чужом эксплоите и элементарно его проапгрейдить под свои нужды. Набравшись опыта в апгрейде кода эксплоита, напишите и свой!
Выбор языка и реализаций - дело вкуса исклонностей!
При написании эксплоита желательно:
- использовать алгоритм атаки, наиболее незаметной с точки зрения логов(POST,COOKIE, но никак не GET!) не стоит палить сразу найденный баг!:(
- учитывать пограничные ситуации, когда в работе эксплоита может пойти что-то не так! Например отключен вывод ошибок, на который опирается в работе эксплоит или версия/тип базы данных не подходит.
Лирика:
Возьмем в качестве подопытной мышки, хороший продукт - движок SMF (Simple Machines Forum) v.1.1.4:)
В 2008 году в SMF нашли SQL-injection и в связи с этим обнародовали публичный эксплоит. Сразу после выхода инфы в широкие массы - кодеры реально озаботились секурностью своего продукта и залатали почти все дырки по полной программе.
Гайки закрутили - мама не горюй....:)
Слешируется и "чарится" абсолютно все, что только существует, при чем иногда по два или три раза. Встроенная защита от анслета, глобальса, SQL-атак, организовано грамотное логирование ошибок...
Но русские хакеры не сдаются:)
Берем сорцы, и..." проходим на бреющем и в шлеме целеуказания, над головами,...идем не быстро и смотрим зорко:)))":
Глобальный массив_REQUEST насильно переписывают через_GET и_POST.
Даже и не знаю зачем это понадобилось!?:(
Далее, разрабы - забывают обнулить $topic в случае отсутствия его в новом запросе.
Таким образом, при register_globals=ON, мы можем определить $topic через COOKIE и...рев форсажных камер...oбойти фильтрацию!!!Вот такий легкий Профит!!!
Дело в том, что в дальнейшем скрипты всецело доверяют переменной $topic, подставляя её в кучу кверей даже без кавычек!:)
Пока на этом все....
Кому интересно, прошу в комменты!:)
Как видим, даже весьма серьезные и защищаемые продукты не застрахованы от всех потенциальных опасностей...Безграмотность кодеров и незнание тонкостей среды, в которой они программируют - настоящий рог изобилия багов!
Помним об этом и копаем дальше!:)
золотые слова в конце статьи...