Причина выключения магазина Amazon не называются

Магазин Amazon.com вышел из строя на 20 минут

Вебсайт Amazon.com выключился на короткий срок 19 августа 2013 года. Деактивирована только американская и канадская версия магазина. VentureBeat утверждает, что ресурс был неактивным на протяжении 20 минут, что подтверждают вебсайты Down For Everyone и Just Me. Причины выключения магазина Amazon не называются.

Время, которое вебсайт оставался неактивным, точно не определено. По некоторым оценкам срок простоя составлял 15, 25, 40 или 45 минут. Если даже ресурс простоял без работы 40 минут это могло стоить компании почти $4,72 млн, как сообщает Puget Sound Business Journal. В среднем продажи компании составляют $117882 в минуту. Впрочем, летом в будний день активность пользователей могла оказаться намного ниже.

По данным Gigaom, локальные версии магазина Amazon в разных странах успешно работали. Ресурсы компаний Zappos и Diapers.com, которые также принадлежат Amazon, были активны.

Домашняя страница Amazon практически никогда не выключается, поэтому мы подозреваем, что причиной деактивации сайта стала хакерская атака. Разумеется, официально Amazon не подтверждает эту теорию, так что скорее всего она не верна. Добавим также, что в прошлом году сервис Amazon Elastic Compute Cloud (EC2) выключался как минимум пару раз: в июне и октябре. Из-за этого из строя вышли Netflix, Instagram и Reddit.

Добавим, что главная страница Google также не открывалась на протяжении 5 минут 16 августа 2013 года. Стоимость простоя составила $545 тысяч. Недоступность Google.com также привела к 40-процентному падению мирового трафика. Наблюдались проблемы с Outlook.com и сайтом New York Times. Западных пользователей беспокоит, что ряд крупнейших ресурсов отключается с перерывом в несколько дней без ярко выраженных причин.

Критическая уязвимость в telnetd жила почти 10 лет и давала root-доступ

Исследователь по информационной безопасности Саймон Йозефссон обнаружил критическую уязвимость в компоненте telnetd, входящем в состав GNU InetUtils. Брешь незаметно существовала почти десять лет — с мая 2015 года — и позволяла удалённо входить в систему без аутентификации, сразу под пользователем root.

Проблема затрагивает все версии GNU InetUtils с 1.9.3 по 2.7 включительно. По сути, любой злоумышленник при определённых условиях мог получить полный контроль над системой, даже не зная пароля.

Как поясняет Йозефссон, сервер telnetd запускает системную утилиту /usr/bin/login, обычно от имени root, и передаёт ей имя пользователя. В уязвимой реализации это имя можно получить из переменной окружения, переданной клиентом.

Если клиент подсовывает значение -f root и подключается к серверу с опцией telnet -a (режим автологина), происходит следующее:

  • telnetd передаёт значение переменной окружения USER напрямую в login(1);
  • никакой проверки или экранирования не выполняется;
  • login(1) воспринимает -f root как служебный параметр;
  • а параметр -f означает вход без проверки пароля.

В итоге сервер автоматически аутентифицирует подключение как root — полностью обходя процесс валидации.

Обычное подключение по telnet не позволяет указать имя пользователя в таком виде. Однако в режиме автологина (-a) имя пользователя берётся не из командной строки, а именно из переменной окружения USER.

Именно здесь и кроется корень проблемы: telnetd доверял содержимому USER без какой-либо валидации. Достаточно было установить переменную окружения в значение -f root, и система сама открывала дверь.

Йозефссон показал рабочий пример атаки на системе Trisquel GNU/Linux 11, где после одной команды пользователь моментально получал root-доступ.

Как выяснилось, уязвимость появилась в коммите от 19 марта 2015 года и попала в релиз GNU InetUtils 1.9.3 от 12 мая того же года. Изначально изменение задумывалось как исправление проблемы с автологином в средах с Kerberos — разработчики добавили передачу имени пользователя через переменную окружения, но забыли проверить её содержимое.

Саймон Йозефссон рекомендует как можно скорее ограничить сетевой доступ к telnet-порту только для доверенных клиентов; установить патч или обновиться до версии GNU InetUtils, в которой уязвимости нет;  в идеале — ещё раз задуматься, нужен ли telnet в инфраструктуре вообще.

Напомним, в этом месяце мы сообщали об опасной уязвимости в GNU Wget2, которая позволяет удалённо перезаписывать файлы.

RSS: Новости на портале Anti-Malware.ru