Найдена уязвимость в устройствах D-Link DGS-1210

Найдена уязвимость в устройствах D-Link DGS-1210

Независимый ИБ-эксперт Варанг Амин (Varang Amin), совместно с главным архитектором компании Elastica Cloud Threat Labs Адитьей Судом (Aditya Sood), рассказали на конференции ToorCon о том, что им удалось обнаружить уязвимость в свитчах DGS-1210 из линейки Gigabit Smart Switches компании D-Link.

Пока исследователи не разглашают детальной информации о найденной уязвимости, но описываю баг в общих чертах. Данная модель коммутаторов может хранить бекап (в состав которого входят логи, прошивка и файлы конфигурации) как на веб-сервере, так и во флеш-памяти самого устройства. Проблема в том, что нормального механизма авторизации и аутентификации при этом не предусмотрено, что позволяет атакующему получить доступ к бекапу, где бы тот ни хранился — в памяти или на сервере. Дело в том, что получить доступ к файлам, хранящимся в памяти, можно, просто зная IP-адрес устройства, а попасть в корневую директорию веб-сервера тоже не слишком сложно, передает xakep.ru.

«Как правило, когда включена опция бекапа, логи и файлы конфигурации хранятся на флеш-накопителе. Логи включены по умолчанию на многих устройствах, и большинство системных администраторов настраивают систему таким образом, чтобы скачать эти файлы можно было легко и быстро, — рассказал Суд изданию SecurityWeek.  — Как только файл конфигурации попал в руки атакующего, вся информация о коммутаторе в его распоряжении. Он может, к примеру, загрузить конфигурацию на другой свитч (купленный с рук), чтобы добраться до деталей. Логи же содержат информацию о клиентах, которые обращались к устройству, и другие данные, связанные с инфраструктурой. Компрометация коммутаторов может привести к чудовищным последствиям, так как атакующий сможет, фактически, контролировать весь поток трафика».

Эксперты сообщают, что обратились с данной проблемой в компанию D-Link еще в начале октября 2015 года, однако компания до сих пор не выпустила исправление. Амин и Суд решили дать D-Link еще время и пока не обнародовали подробностей о своем открытии.

Android 17 запретит приложениям внезапно орать в фоне

Google решила покончить с одной из самых мерзких мобильных неожиданностей: когда давно свёрнутое приложение или забытая вкладка браузера внезапно начинает воспроизводить звук. В Android 17 для этого появился системный механизм Background Audio Hardening.

Теперь приложение сможет включать аудио, запрашивать аудиофокус и менять громкость только при видимом на экране интерфейсе либо при корректно запущенной foreground-службе.

Ограничение действует на все приложения в Android 17, даже если они пока не адаптированы под API 37.

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

Как объясняет Google, нововведение должно остановить случайный запуск звука. Например, приложение могло зависнуть из-за проблем с сетью, быть заморожено системой, а затем очнуться через несколько часов и внезапно продолжить воспроизведение. Другой сценарий — потерянная медиасессия, которая продолжает жить уже без видимого интерфейса и понятной кнопки остановки.

Изменение работает на уровне всей операционной системы, поэтому это не специальное лекарство для Chrome, YouTube или сайтов с наглым автовоспроизведением. Под новые правила попадут браузеры, игры, медиаплееры и остальные приложения.

Побочный эффект тоже имеется. Программы, которым действительно нужно играть музыку или подкасты при выключенном экране, должны правильно использовать foreground-службу для медиавоспроизведения. Разработчикам с кривой реализацией придётся переписать код, иначе Android молча прикрутит им громкость.

Google также предусмотрела тестирование через ADB: защиту можно включить, отключить или перевести в жёсткий режим, при котором некорректные обращения к аудиоинтерфейсам вызывают явные ошибки.

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