Эта история началась давным-давно, еще в прошлом году, когда исследователи из Kryptowire наткнулись на подозрительный трафик, исходящий из купленного по случаю китайского смартфона. Углубившись в прошивку аппарата, они выяснили, что система OTA-обновлений представляет собой натуральный бэкдор. Ну, и еще немножечко апдейтит прошивку, в свободное от шпионажа за пользователем время.
FOTA (firmware over the air), программный модуль от Shanghai Adups Technology Company отправлял куда-то в Китай буквально все: SMS-сообщения, IMSI и IMEI, журнал звонков, географические координаты устройства. На сайте Adups гордо заявлялось, что их чудненький FOTA используется на 700 млн устройств. В основном это китайские и не очень смартфоны, а также навигаторы, умные автомагнитолы и все прочие гаджеты с подключением к Интернету.
После неслабого скандала Adups заявили, что, во-первых, совсем даже не шпионили, во-вторых, вовсе не по заданию китайских госорганов, а, в-третьих, они не специально и больше так не будут. Прошел почти год.
И вот Kryptowire снова раскрыли тему злодейства Adups. Невероятно, но факт: наш герой продолжает в том же духе. Точнее, по-прежнему поставляет в Китай идентификаторы базовых станций, список установленных приложений, серийные номера SIM и IMSI. Проверено на двух моделях – Blu Grand M и Cubot X16S.
Главное во всем этом даже не то, что Adups не перестал шпионить, а что спустя год после «сеанса магии с разоблачением» их продукты кто-то продолжает использовать.
На BlackHat показали новый метод извлечения персональных данных из серверов
Новость. Хороша нынешняя конференция BlackHat в США и доклады на ней интересные. Вот, к примеру, наш человек из Лас-Вегаса пишет, что Омер Гиль из EY Advanced Security Center представил новый способ атаки на CDN-сервисы вроде Akamai и Cloudflare — взлом без взлома. Это когда при определенных условиях сервер выдает закэшированные страницы другого пользователя.
Исследователь описал механизм атаки следующим образом. Допустим, есть URL — 'www.example.com/personal.php', ссылающийся на контент с важными данными, которые кэшировать не полагается. Хакер вынуждает жертву выполнить запрос 'www.example.com/personal.php/bar.css' (для этого есть масса способов). Сервер на это выдает страницу 'www.example.com/personal.php' с важной информацией жертвы – куки-файлы-то у нее имеются. При этом кэширующий прокси справедливо расценивает 'www.example.com/personal.php/bar.css' как запрос на несуществующий, но подлежащий кэшированию файл bar.css и сохраняет вместо этого содержимое '/personal.php'.
Ровно такой же фокус можно провернуть с более чем 40 расширениями: aif, aiff, au, avi, bin, bmp, cab, carb, cct, cdf, class, css, doc, dcr, dtd, gcf, gff, gif, grv, hdml, hqx, ico, ini, jpeg, jpg, js, mov, mp3, nc, pct, ppc, pws, swa, swf, txt, vbs, w32, wav, wbmp, wml, wmlc, wmls, wmlsc, xsd и zip. После этого хакер спокойно заходит на искомый URL и получает из кэша страницу с введенными персональными данными – например, платежной карты. По опыту Гиля, кэшированные файлы в указанных сервисах хранятся около пяти часов. Хуже того, кэшированный запрос может содержать CSRF-токены, идентификаторы сессии, ответы на секретные вопросы, то есть это уже попахивает угоном учетной записи.
К чести Akamai и Cloudflare, оба сервиса признали проблему. Сами они предотвратить подобную атаку не могут и призывают вебмастеров позаботиться о защите своих сайтов — чтобы по запросу на несуществующий файл не выдавали расположенное выше содержимое.
В контейнерах Docker научились прятать зловредов
Новость. Продолжают поступать кул сторис с конференции BlackHat USA. В этот раз участники разоблачили Docker. Этим моднейшим средством для отладки и развертывания приложений в среде виртуализации сейчас пользуются многие разработчики. Исследователи из Aqua Security показали, как можно внедрять в контейнеры Docker малвару, соорудив по сути двойное дно.
Для начала надо найти жертву – разработчика, использующего Docker для Windows. Потом следует вынудить его зайти на специальный сайт, где сидит вредоносный JavaScript, который создает на машине жертвы новый контейнер, втягивающий с репозитория вредоносный код. Его устойчивость на машине обеспечивается скриптом, сохраняющим контейнер при шатдауне и запускающим его во время загрузки Docker.
Временное решение проблемы – обновить Docker, разрешить сетевой доступ только аутентифицированным клиентам, заблокировать порт 2375 на интерфейсе виртуальной машины Moby Linux с помощью файрволла, а во избежание расползания вредоносного кода по сети отключить LLMNR и NetBIOS на всех компьютерах.
Насколько опасна такая атака пока не очень понятно, однако потенциально это реальный способ внедрения в конвейер разработки популярных приложений. Последствия могут быть очень печальные. Мало не покажется никому.
«Drop-1131»
Резидентный неопасный вирус. Стандартно заражает COM- и EXE-файлы при обращении к ним. Перехватывает int 1Ch и 21h. В зависимости от значения своего внутреннего счетчика довольно активно осыпает буквы на экране.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 66.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
FOTA (firmware over the air), программный модуль от Shanghai Adups Technology Company отправлял куда-то в Китай буквально все: SMS-сообщения, IMSI и IMEI, журнал звонков, географические координаты устройства. На сайте Adups гордо заявлялось, что их чудненький FOTA используется на 700 млн устройств. В основном это китайские и не очень смартфоны, а также навигаторы, умные автомагнитолы и все прочие гаджеты с подключением к Интернету.
После неслабого скандала Adups заявили, что, во-первых, совсем даже не шпионили, во-вторых, вовсе не по заданию китайских госорганов, а, в-третьих, они не специально и больше так не будут. Прошел почти год.
И вот Kryptowire снова раскрыли тему злодейства Adups. Невероятно, но факт: наш герой продолжает в том же духе. Точнее, по-прежнему поставляет в Китай идентификаторы базовых станций, список установленных приложений, серийные номера SIM и IMSI. Проверено на двух моделях – Blu Grand M и Cubot X16S.
Главное во всем этом даже не то, что Adups не перестал шпионить, а что спустя год после «сеанса магии с разоблачением» их продукты кто-то продолжает использовать.
На BlackHat показали новый метод извлечения персональных данных из серверов
Новость. Хороша нынешняя конференция BlackHat в США и доклады на ней интересные. Вот, к примеру, наш человек из Лас-Вегаса пишет, что Омер Гиль из EY Advanced Security Center представил новый способ атаки на CDN-сервисы вроде Akamai и Cloudflare — взлом без взлома. Это когда при определенных условиях сервер выдает закэшированные страницы другого пользователя.
Исследователь описал механизм атаки следующим образом. Допустим, есть URL — 'www.example.com/personal.php', ссылающийся на контент с важными данными, которые кэшировать не полагается. Хакер вынуждает жертву выполнить запрос 'www.example.com/personal.php/bar.css' (для этого есть масса способов). Сервер на это выдает страницу 'www.example.com/personal.php' с важной информацией жертвы – куки-файлы-то у нее имеются. При этом кэширующий прокси справедливо расценивает 'www.example.com/personal.php/bar.css' как запрос на несуществующий, но подлежащий кэшированию файл bar.css и сохраняет вместо этого содержимое '/personal.php'.
Ровно такой же фокус можно провернуть с более чем 40 расширениями: aif, aiff, au, avi, bin, bmp, cab, carb, cct, cdf, class, css, doc, dcr, dtd, gcf, gff, gif, grv, hdml, hqx, ico, ini, jpeg, jpg, js, mov, mp3, nc, pct, ppc, pws, swa, swf, txt, vbs, w32, wav, wbmp, wml, wmlc, wmls, wmlsc, xsd и zip. После этого хакер спокойно заходит на искомый URL и получает из кэша страницу с введенными персональными данными – например, платежной карты. По опыту Гиля, кэшированные файлы в указанных сервисах хранятся около пяти часов. Хуже того, кэшированный запрос может содержать CSRF-токены, идентификаторы сессии, ответы на секретные вопросы, то есть это уже попахивает угоном учетной записи.
К чести Akamai и Cloudflare, оба сервиса признали проблему. Сами они предотвратить подобную атаку не могут и призывают вебмастеров позаботиться о защите своих сайтов — чтобы по запросу на несуществующий файл не выдавали расположенное выше содержимое.
В контейнерах Docker научились прятать зловредов
Новость. Продолжают поступать кул сторис с конференции BlackHat USA. В этот раз участники разоблачили Docker. Этим моднейшим средством для отладки и развертывания приложений в среде виртуализации сейчас пользуются многие разработчики. Исследователи из Aqua Security показали, как можно внедрять в контейнеры Docker малвару, соорудив по сути двойное дно.
Для начала надо найти жертву – разработчика, использующего Docker для Windows. Потом следует вынудить его зайти на специальный сайт, где сидит вредоносный JavaScript, который создает на машине жертвы новый контейнер, втягивающий с репозитория вредоносный код. Его устойчивость на машине обеспечивается скриптом, сохраняющим контейнер при шатдауне и запускающим его во время загрузки Docker.
Временное решение проблемы – обновить Docker, разрешить сетевой доступ только аутентифицированным клиентам, заблокировать порт 2375 на интерфейсе виртуальной машины Moby Linux с помощью файрволла, а во избежание расползания вредоносного кода по сети отключить LLMNR и NetBIOS на всех компьютерах.
Насколько опасна такая атака пока не очень понятно, однако потенциально это реальный способ внедрения в конвейер разработки популярных приложений. Последствия могут быть очень печальные. Мало не покажется никому.
Древности
«Drop-1131»
Резидентный неопасный вирус. Стандартно заражает COM- и EXE-файлы при обращении к ним. Перехватывает int 1Ch и 21h. В зависимости от значения своего внутреннего счетчика довольно активно осыпает буквы на экране.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 66.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Поделиться с друзьями
Slihs
Справедливо заметить, что Омер писал об этом еще в феврале https://omergil.blogspot.co.uk/2017/02/web-cache-deception-attack.html и все уважающие себя сервисы закрыли эту дыру уже давно. Даже не секлабе была новость http://www.securitylab.ru/news/485441.php. И действительно CDN тут совсем не причем, это возможно при любом другом кэшировании.
ivan386
Ну если бы CDN не игнорировали хедеры с правилами кеширования то проблема была бы только в настройках сервера.