iv.
13.04.2007, 01:58
Предположу, что многие впервые услышали этот термин. Действительно, это не столь известный вид атак по сравнению с гуру игольной сцены SQL, PHP и XSS. Но, несмотря на это, в некоторых случаях такие атаки оказываются не менее эффективными. Сегодняшний рассказ будет про них.
Интро
Сокращение CRLF происходит от английских словосочетаний "carriage return / line feed" (возврат каретки / перевод строки), это два управляющих символа с кодами 0Dh и 0Ah в ASCII соответственно. Они ничего не отображают на экране, но широко используются во многих ОС для обозначения конца строки.
Например, в системах DOS, Windows, OS/2 используются оба этих символа. В системах *nix в конце каждой строки ставится только символ LF. В MacOS используется только CR. Не знаю, из каких соображений так сложилось, будем считать, что исторически.
Кстати, немного об истории. Эти символы пришли к нам со времен компьютерных терминалов и прочих пишущих машинок. В конце каждой строки команда возврата каретки возвращала печатающую головку к левой границе страницы, а команда перевода строки проворачивала бумагу на одну строку вниз. Время терминалов с рулонами бумаги давно прошло, но, тем не менее, управляющие символы CR и LF остались, и по сей день используются многими приложениями и сетевыми протоколами в качестве разделяющих символов.
Различные хакеры не могли обойти вниманием и эти символы в процессе поиска уязвимостей. Атакующий может внедрить символы CRLF в запрос, тем самым изменив логику исполнения интересующей программы..
Лог-файлы
Самый простой пример CRLF инъекции заключается в добавлении произвольных записей в лог-файлы. Представим себе программу, которая принимает данные от пользователя и записывает их в файл. Атакующий может сформировать следующий запрос:
Test<CRLF>MYSQL DATABASE ERROR: TABLE CORRUPTION
Администратор, просматривающий логи, наверняка потратит много времени, пытаясь решить несуществующую проблему. Хакер может использовать данный прием для отвлечения администратора, атакуя/исследуя в это время другую подсистему.
* в своих примерах я обозначаю символы CRLF как <CRLF>, но в каждом конкретном случае синтаксис использования уязвимости может отличаться.
Небезопасное прораммирование
Рассмотрим приложение, которое получает от пользователя имя файла и выполняет над ним команду, например "ls -a". Если приложение подвержено CRLF инъекции, атакующий может сформировать следующий запрос:
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 не фильтруется, то мы можем читая одну новость незаметно запостить другую.
В обоих примерах запрос в общем случае выглядит следующим образом:
<KEY><SEP><VAL><NL>
где
<KEY> - посылаемая команда
<SEP> - разделитель
<VAL> - значение
<NL> - символы CRLF
Если поле <VAL>, получаемое непосредственно от пользователя может содержать типы данных/символы, использующиеся в других полях, то уязвимость существует.
Новостные, почтовые, веб заголовки
Все эти заголовки имеют структуру "Key: Value", разделяются они между собой опять же символами CLRF.
В протоколе HTTP существуют заголовки "Location:" (используется для редиректа на другой сайт) и "Set-Cookie:" (используется понятно-для-чего).
Если некий скрипт содержит процедуру редиректа, в которой не фильтруются символы CRLF, то мы можем сформировать запрос, например произвольно меняющий кукисы пользователя. Конкретный пример приводить не буду, он реализовывается аналогично предыдущим.
Заключение
Абсолютно таким же образом мы можем добавлять произвольные поля в заголовки во многих интернет протоколах, при этом конечно нужно учитывать структуру этого заголовка и не нарушать её.
Дальше мусолить тему смысла не вижу, концепцию (будем надеяться) я объяснил.
Данная техника достаточно старая, но почему-то про неё очень мало материалов. Тем не менее, совсем недавно в PHP обнаружена подобная уязвимость, позволяющая через некоторые функции производить массовые рассылки писем.
Итак, любые атаки, связанные с внедрением данных, влияющих на логику обработки запроса, избегаются грамотной фильтрацией входных данных. Причем, не только пользовательских, но и тех, которые могут передавать другие приложения. При разработке программ не стоит об этом забывать.
Хотелось бы довести статью до ума с вашей помощью. Жду предложений, спасибо за внимание (;
Интро
Сокращение CRLF происходит от английских словосочетаний "carriage return / line feed" (возврат каретки / перевод строки), это два управляющих символа с кодами 0Dh и 0Ah в ASCII соответственно. Они ничего не отображают на экране, но широко используются во многих ОС для обозначения конца строки.
Например, в системах DOS, Windows, OS/2 используются оба этих символа. В системах *nix в конце каждой строки ставится только символ LF. В MacOS используется только CR. Не знаю, из каких соображений так сложилось, будем считать, что исторически.
Кстати, немного об истории. Эти символы пришли к нам со времен компьютерных терминалов и прочих пишущих машинок. В конце каждой строки команда возврата каретки возвращала печатающую головку к левой границе страницы, а команда перевода строки проворачивала бумагу на одну строку вниз. Время терминалов с рулонами бумаги давно прошло, но, тем не менее, управляющие символы CR и LF остались, и по сей день используются многими приложениями и сетевыми протоколами в качестве разделяющих символов.
Различные хакеры не могли обойти вниманием и эти символы в процессе поиска уязвимостей. Атакующий может внедрить символы CRLF в запрос, тем самым изменив логику исполнения интересующей программы..
Лог-файлы
Самый простой пример CRLF инъекции заключается в добавлении произвольных записей в лог-файлы. Представим себе программу, которая принимает данные от пользователя и записывает их в файл. Атакующий может сформировать следующий запрос:
Test<CRLF>MYSQL DATABASE ERROR: TABLE CORRUPTION
Администратор, просматривающий логи, наверняка потратит много времени, пытаясь решить несуществующую проблему. Хакер может использовать данный прием для отвлечения администратора, атакуя/исследуя в это время другую подсистему.
* в своих примерах я обозначаю символы CRLF как <CRLF>, но в каждом конкретном случае синтаксис использования уязвимости может отличаться.
Небезопасное прораммирование
Рассмотрим приложение, которое получает от пользователя имя файла и выполняет над ним команду, например "ls -a". Если приложение подвержено CRLF инъекции, атакующий может сформировать следующий запрос:
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 не фильтруется, то мы можем читая одну новость незаметно запостить другую.
В обоих примерах запрос в общем случае выглядит следующим образом:
<KEY><SEP><VAL><NL>
где
<KEY> - посылаемая команда
<SEP> - разделитель
<VAL> - значение
<NL> - символы CRLF
Если поле <VAL>, получаемое непосредственно от пользователя может содержать типы данных/символы, использующиеся в других полях, то уязвимость существует.
Новостные, почтовые, веб заголовки
Все эти заголовки имеют структуру "Key: Value", разделяются они между собой опять же символами CLRF.
В протоколе HTTP существуют заголовки "Location:" (используется для редиректа на другой сайт) и "Set-Cookie:" (используется понятно-для-чего).
Если некий скрипт содержит процедуру редиректа, в которой не фильтруются символы CRLF, то мы можем сформировать запрос, например произвольно меняющий кукисы пользователя. Конкретный пример приводить не буду, он реализовывается аналогично предыдущим.
Заключение
Абсолютно таким же образом мы можем добавлять произвольные поля в заголовки во многих интернет протоколах, при этом конечно нужно учитывать структуру этого заголовка и не нарушать её.
Дальше мусолить тему смысла не вижу, концепцию (будем надеяться) я объяснил.
Данная техника достаточно старая, но почему-то про неё очень мало материалов. Тем не менее, совсем недавно в PHP обнаружена подобная уязвимость, позволяющая через некоторые функции производить массовые рассылки писем.
Итак, любые атаки, связанные с внедрением данных, влияющих на логику обработки запроса, избегаются грамотной фильтрацией входных данных. Причем, не только пользовательских, но и тех, которые могут передавать другие приложения. При разработке программ не стоит об этом забывать.
Хотелось бы довести статью до ума с вашей помощью. Жду предложений, спасибо за внимание (;