Предположу, что многие впервые услышали этот термин. Действительно, это не столь известный вид атак по сравнению с гуру игольной сцены SQL, PHP и XSS. Но, несмотря на это, в некоторых случаях такие атаки оказываются не менее эффективными. Сегодняшний рассказ будет про них. Интро Сокращение CRLF происходит от английских словосочетаний "carriage return / line feed" (возврат каретки / перевод строки), это два управляющих символа с кодами 0Dh и 0Ah в ASCII соответственно. Они ничего не отображают на экране, но широко используются во многих ОС для обозначения конца строки. Например, в системах DOS, Windows, OS/2 используются оба этих символа. В системах *nix в конце каждой строки ставится только символ LF. В MacOS используется только CR. Не знаю, из каких соображений так сложилось, будем считать, что исторически. Кстати, немного об истории. Эти символы пришли к нам со времен компьютерных терминалов и прочих пишущих машинок. В конце каждой строки команда возврата каретки возвращала печатающую головку к левой границе страницы, а команда перевода строки проворачивала бумагу на одну строку вниз. Время терминалов с рулонами бумаги давно прошло, но, тем не менее, управляющие символы CR и LF остались, и по сей день используются многими приложениями и сетевыми протоколами в качестве разделяющих символов. Различные хакеры не могли обойти вниманием и эти символы в процессе поиска уязвимостей. Атакующий может внедрить символы CRLF в запрос, тем самым изменив логику исполнения интересующей программы.. Лог-файлы Самый простой пример CRLF инъекции заключается в добавлении произвольных записей в лог-файлы. Представим себе программу, которая принимает данные от пользователя и записывает их в файл. Атакующий может сформировать следующий запрос: Code: Test<CRLF>MYSQL DATABASE ERROR: TABLE CORRUPTION Администратор, просматривающий логи, наверняка потратит много времени, пытаясь решить несуществующую проблему. Хакер может использовать данный прием для отвлечения администратора, атакуя/исследуя в это время другую подсистему. * в своих примерах я обозначаю символы CRLF как <CRLF>, но в каждом конкретном случае синтаксис использования уязвимости может отличаться. Небезопасное прораммирование Рассмотрим приложение, которое получает от пользователя имя файла и выполняет над ним команду, например "ls -a". Если приложение подвержено CRLF инъекции, атакующий может сформировать следующий запрос: Code: file<CRLF>rm -rf /. Уязвимое приложение выполнит команду "ls -a file", а затем – команду "rm –rf /.". Если приложение запущено с привилегиями root это будет последняя когда-либо исполненная им команда.. Интернет протоколы Многие интернет протоколы проектировались таким образом, что клиент должен посылать символы CRLF после каждой команды серверу. В случае если эти символы не фильтруются мы можем выполнить несколько команд за раз. Протокол POP3 использует команду "RETR x" для передачи сообщений. Если клиентская программа для получения сообщений посылает запрос вида "RETR $msg<CRLF>", и строка $msg не фильтруется на наличие символов CRLF, мы сможем посылать серверу произвольные команды через данный запрос. Протокол NNTP использует команды "ARTICLE x" для передачи сообщений клиенту и "POST" – для передачи сообщений серверу и последующего их отображения. Если клиентская программа посылает запрос вида "ARTICLE $id\015\012" и опять же строка $id не фильтруется, то мы можем читая одну новость незаметно запостить другую. В обоих примерах запрос в общем случае выглядит следующим образом: Code: <KEY><SEP><VAL><NL> где <KEY> - посылаемая команда <SEP> - разделитель <VAL> - значение <NL> - символы CRLF Если поле <VAL>, получаемое непосредственно от пользователя может содержать типы данных/символы, использующиеся в других полях, то уязвимость существует. Новостные, почтовые, веб заголовки Все эти заголовки имеют структуру "Key: Value", разделяются они между собой опять же символами CLRF. В протоколе HTTP существуют заголовки "Location:" (используется для редиректа на другой сайт) и "Set-Cookie:" (используется понятно-для-чего). Если некий скрипт содержит процедуру редиректа, в которой не фильтруются символы CRLF, то мы можем сформировать запрос, например произвольно меняющий кукисы пользователя. Конкретный пример приводить не буду, он реализовывается аналогично предыдущим. Заключение Абсолютно таким же образом мы можем добавлять произвольные поля в заголовки во многих интернет протоколах, при этом конечно нужно учитывать структуру этого заголовка и не нарушать её. Дальше мусолить тему смысла не вижу, концепцию (будем надеяться) я объяснил. Данная техника достаточно старая, но почему-то про неё очень мало материалов. Тем не менее, совсем недавно в PHP обнаружена подобная уязвимость, позволяющая через некоторые функции производить массовые рассылки писем. Итак, любые атаки, связанные с внедрением данных, влияющих на логику обработки запроса, избегаются грамотной фильтрацией входных данных. Причем, не только пользовательских, но и тех, которые могут передавать другие приложения. При разработке программ не стоит об этом забывать. Хотелось бы довести статью до ума с вашей помощью. Жду предложений, спасибо за внимание (;
эту уязвимость можно еще использовать, чтоб xss вызвать, например.. а вообще, эфективного применения этой баги я как-то особо не находил пока что..
Ага. Но уязвимость была давно найдена, очень давно, в функции mail, позволяющая менять заголовки отсылаемых данных. Соотвественно можно было отослать, подменив данные, сразу 255 людям )
ответ: в силу устройства этой программы =) т.е. при входных данных "file<CRLF>rm -rf /." на консоль идет "ls -a file" и "rm -rf /." как-то так..
Можно конкретный пример уязвимого скрипта пожалуста? И пример данной атаки? file<CRLF>rm -rf /. В данном листинге в какой функции исполняеться команда??? И почему ls файл??? данная команда покажет существует данный файл или нет... Относяться ли к данной атаке. ; прерыв кода в php | перераспределение в perl??? Еще давольно опасным являеться символ табуляции "\x09" Статья понравилась +, но тема не раскрыта.
Не слышал про это? чем именно он опасен? Конкретных примеров щас назвать не могу. Это вещь давольно редкая, но иногда ее можно применить. Напрмер, когда форум хранит инфу о своих юзерах в файле. И еще много всего. Зависит от конкретного случая
На чем написан форум язык? Если php в каких функция передаються параметры??? команду ls можно выполнить только в систеиных файлах. А записаь в файл как правиль fopen(); fwrite(); Fclose();
Если ты про мой случай то тут не важно, на чем он написан, это может катить в старых ikonboard (не проверял) в wr_forum Инфа храниться в виде типа |slon|123|admin|hek...| и записываеться в файлы, таких приложений очень мало, все используют базу, но иногда попадаються... Если вставить <crlf> то можно добавлять в этот конфигурационный файл произвольные строки.. Опять же зависит от конкретного случая CASH, так что там про табуляцию то говорил? Что дает эта уязвимость?
В том что ты сможешь исползывать табуляцию. PS пишешь какойто бред. Запишу я сюда все что захочу в силу фильтров. Если в файле будет ls -la мне легче не станет. Как это не важно на jsp например нету функций мозволяющих исполнять команды да и iss к такому виду атак слегда по другому относиться. 2iv. Ответь пожалуста на мои вопросы можно в pm или icq
Да я тебе вообщето не про системные команды говорил Насчет них конкретно примеров не видел. Ну кроме ';' но это уже не Crlf
господа, статья будет дополняться, без паники =) думаю над вопросом демонстрации конкретной уязвимости. что ещё добавить?
Итак, наконец нашел время для демонстрации конкретной уязвимости (уже неактуальной, пофиксена в декабре 2006) на примере Google Adwords с использованием техники HTTP Response Splitting (частный случай CRLF injection в заголовке HTTP протокола). FYI: статья из соседнего раздела HTTP Response Splitting: разделяй и властвуй. Подверженные атаке запросы: Code: https://adwords.google.com/select/ProfessionalWelcome?hl=%0D%0A[B]fakeheader[/B]&null=Go%20HTTP/1.0 https://adwords.google.com/select/Login?hl=%0D%0A[B]fakeheader[/B]&null=Go%20HTTP/1.0 Таким образом мы можем сформировать прозвольный второй ответ, но вот каково его реальное использование кроме всяких XSS, я что-то не соображу. =( В багтраке лежит немало уязвимостей подобного рода кстати.
Перечитал пару раз, но так и не вкурил, как можно исходя из этого реализовать ХСС. Ну послали ложный запрос, ну получили ложный ответ и? Если можно чуток поподробней для особо развитых
