29 August 2011

Когда просто отфильтровать параметры запроса недостаточно или о вреде универсальности

Information Security
У уважаемой компании «Российские Железные Дороги» есть замечательный сайт ticket.rzd.ru. Не смотря на некоторые шероховатости, сайт неплохо справляется со своей основной задачей — позволяет заказать и оплатить билеты он-лайн.

Некоторое время я заказывал там себе билеты, и моя исследовательская сущность не смогла просто пройти мимо, не заглянув в исходный код страницы.



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



Адрес этого изображения выглядит примерно так:
https://ticket.rzd.ru/isvp/barcode?data=0000000000000&type=Code39&width=1&height=60&checksum=false.
Первое, что я сделал — это подставил в поле data свое произвольное число. Результат предсказуем — я получил штрих код для этого числа. Ну что ж, перед нами замечательный дармовой универсальный сервис кодирования штрих-кодов. Но хорошо ли это для РДЖ? Копаем дальше…

Затем я очистил поле data. Результат — stack-trace с именем библиотеки генератора штрих-кодов (barbecue) и сервера приложений (IBM WebSphere Application Server). Много ли информации это дало? Этого, конечно, недостаточно для того чтобы сломать сервер. Но и показывать свой «паспорт» постороннему «человеку на улице» не самое разумное дело.

Попробуем посмотреть на остальные параметры:
  • type=Code39 — Это тип кодирования штрих-кода. Нас интересует мало.
  • width=1 — методом тыка выясняем, что это ширина линий.
  • height=60 — очевидно, высота.
  • checksum=false — очевидно, добавление дополнительных штрихов контрольной суммы.

Теперь в принципе уже готов вектор атаки. «Рисование» штрих-кода, очевидно происходит в памяти, а затем отдается запрашивающему. Параметры ширины и высоты линий, длина цифрового кода никак не фильтруется — следовательно тривиальным перебором подбираются параметры съедающие всю оперативную память сервера десятком-другим запросов. Пока разберутся, в чем дело — несколько часов «в дауне». А если неправильные настройки ОС, и она начнет свопится, то недалеко и до аппаратной смерти сервера.

Готовой «ссылки смерти» по понятной причине не даю. И надеюсь на благоразумность читателя, не ставшего проверять, что это действительно так, и поверившего на слово.

Оставим пока вопрос, кому и зачем это может понадобиться ддосить РЖД. Нам же это — хороший пример, что:
  1. фильтровать параметры надо не только в PHP, но и во вполне «безобидных» сервисах на Java;
  2. делать излишне универсальные сервисы вредно.

P.S. Письмо разработчикам сайта было отправлено заблаговременно. Вежливый ответ о том что «учтут» пришел (тут респект), но время идет, и пока не «учли» (тут дисреспект)…
Tags:ddosофициальный сайтРЖДуязвимостьwebsphere application server
Hubs: Information Security
+58
1.2k 10
Comments 44
Top of the last 24 hours