Добро пожаловать! Войти Создать Новый Профиль

Расширенный

Атаки

Написано al 
al
Атаки
June 23, 2019 03:27PM
Атака на биржу криптовалюты через взлом счётчика StatCounter

Зафиксирован взлом популярного сервиса web-аналитики StatCounter, JavaScript-код со счётчиком которого размещён на более чем двух миллионах сайтов, а число загрузок составляет около 10 миллиардов страниц в месяц. По данным компании ESET взлом выполнен для совершения целевой атаки на биржу криптовалют gate.io, на страницах которой размещён код счётчика StatCounter.

После взлома злоумышленники добавили в код счётчика несколько дополнительных строк, которые перехватывают информацию о всех транзакциях с криптовалютой Bitcoin в web-интерфейсе Gate.io. Вредоносный код активируется только для страниц, содержащих в URL маску "myaccount/withdraw/BTC", которая специфична для сайта Gate.io и используется на странице перевода средств.

В случае обнаружения в форме перевода Bitcoin-адреса, вредоносный код заменяет его на Bitcoin-адрес злоумышленников во время нажатия кнопки для отправки средств. Для каждой жертвы используется отдельный подставной Bitcoin-адрес (при каждой загрузке скрипта c.php генерируется новый Bitcoin-адрес), что затрудняет отслеживание ущерба от атаки.

Атака была совершена 3 ноября и пока сохраняет активность. Код изменённого счётчика (www.statcounter.com/counter/counter.js) до сих пор содержит вредоносное изменение (скрипт упакован утилитой packer для экономии трафика, поэтому без распаковки появление вредоносного кода не бросается в глаза). Выявившие проблему исследователи направили в StatCounter уведомление о проблеме, но пока не получили ответа.

Администраторы Gate.io удалили счётчик со своих страниц, но он продолжает использоваться на многочисленных сайтах других пользователей StatCounter. Несмотря на то, что вредоносный код нацелен только на компрометацию биржи Gate.io, не исключено, что злоумышленники в любой момент могут изменить код счётчика для совершения более масштабной универсальной атаки (например, для захвата паролей или платёжной информации на сайтах со счётчиком StatCounter).
avatar Re: Атаки
June 23, 2019 03:37PM
Разработан метод атаки на DRAM-память, позволяющий обойти защиту ECC

Группа исследователей из Амстердамского свободного университета разработала (PDF) усовершенствованный вариант атаки RowHammer, позволяющей изменить содержимое отдельных битов в памяти на базе чипов DRAM, для защиты целостности в которых применяются коды коррекции ошибок (ECC). Атака может быть выполнена удалённо при наличии непривилегированного доступа к системе.

Напомним, что уязвимость RowHammer позволяет исказить содержимое отдельных битов памяти путём цикличного чтения данных из соседних ячеек памяти. Так как память DRAM представляет собой двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора, выполнение непрерывного чтения одной и той же области памяти приводит к флуктуации напряжения и аномалиям, вызывающим небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить её первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных.

До сих пор использование ECC считалось наиболее надёжным способом защиты от вышеописанных проблем, но исследователям удалось разработать метод изменения заданных битов памяти, не приводящий к срабатыванию механизма коррекции ошибок. Метод может применяться на серверах с ECC-памятью для модификации данных, подстановки вредоносного кода и изменения прав доступа. Например, в ранее продемонстрированных RowHammer-атаках при наличии у злоумышленника доступа к виртуальной машине инициировалась загрузка вредоносных системных обновлений через изменение в процессе apt имени хоста для загрузки и модификации логики проверки цифровой подписи.

Обход ECC основан на особенностях коррекции ошибок: если изменён один бит - ECC откорректирует ошибку, если два бита - будет сгенерировано исключение и программа будет принудительно завершена, но в случае одновременного изменения трёх битов ECC может не заметить модификации. Для определения условий при которых проверка ECC не срабатывает разработан похожий на состояние гонки метод проверки, позволяющий оценить возможность совершения атаки для конкретного адреса в памяти.

Метод основывается на факте, что при исправлении ошибки возрастает время чтения и возникающая задержка вполне измерима и заметна. Атака сводится к последовательным попыткам изменить каждый бит по отдельности, определяя успешность изменения возникновением задержки, вызванной корректировкой ECC. Таким образом выполняется поиск машинных слов с тремя изменяемыми битами. На последнем этапе необходимо добиться, чтобы три изменяемые бита в двух местах были разными, после чего попытаться за один проход изменить их значение.

Исследователи успешно продемонстрировали возможность атаки на четырёх разных серверах с памятью DDR3 (теоретически уязвима и память DDR4), три из которых были укомплектованы процессорами Intel (E3-1270 v3, Xeon E5-2650 v1, Intel Xeon E5-2620 v1 ), а один - AMD (Opteron 6376). При этом отмечается, что поиск необходимого сочетания битов в лабораторных условиях на неактивном сервере занимает около 32 минут. Совершить атаку на работающем сервере значительно труднее из-за наличия помех, возникающих в процессе активности приложений. На рабочих системах для поиска необходимого сочетания изменяемых бит может потребоваться до одной недели.

Итоговый вывод сводится к тому, что ECC полностью не исключает проведение атаки RowHammer, но существенно замедляет и усложняет её. Для выявления попыток совершения атаки администраторам многопользовательских систем рекомендуется включить в логах отображение фактов коррекции ошибок ECC и настроить мониторинг связанной с ними активности.
avatar Re: Атаки
June 23, 2019 04:09PM
Зафиксирована атака вредоносных шифровальщиков на Git-репозитории


Сообщается о волне атак, направленных на шифрование Git-репозиториев в сервисах GitHub, GitLab и Bitbucket. Атакующие очищают репозиторий и оставляют сообщение с просьбой отправить 0.1 BTC (примерно $700) для восстановления данных из резервной копии (на деле лишь портятся заголовки коммитов и информация может быть восстановлена). На GitHub подобным образом уже пострадал 371 репозиторий.

Некоторые жертвы атаки признаются, что использовали ненадёжные пароли или забыли удалить токены доступа из старых приложений. Некоторые считают (пока это лишь домыслы и гипотеза ещё не подтверждена), что причиной утечки учётных данных стала компрометация приложения SourceTree, предоставляющего GUI для работы с Git из macOS и Windows. В марте в SourceTree было выявлено несколько критических уязвимостей, позволяющих удалённо организовать выполнение кода при обращении к подконтрольным злоумышленнику репозиториям.

Для восстановления репозитория после атаки достаточно выполнить "git checkout origin/master", после чего
узнать через "git reflog" хэш SHA своего последнего коммита и сбросить изменения атакующих командой "git reset {SHA}". При наличии локальной копии проблема решается выполнением "git push origin HEAD:master --force".

Дополнение: GitHub, GitLab и Bitbucket опубликовали совместный отчёт с анализом инцидента. Основной причиной захвата репозиториев стало включение пользователями в публичные репозитории или размещение на web-серверах конфигурационных файлов ".git/config", содержащих ключи доступа или параметры аутентификации в сервисах.
avatar Re: Атаки
June 23, 2019 04:21PM
Взлом внутренней сети NASA через плату Raspberry Pi

Национальное управление по аэронавтике и исследованию космического пространства (NASA) раскрыло информацию о взломе внутренней инфраструктуры, который оставался невыявленным около года. Примечательно, что от внешних угроз сеть была изолирована, а взлом был произведён изнутри при помощи платы Raspberry Pi, подключённой без разрешения в Лаборатории реактивного движения.

Данная плата использовалась сотрудниками в качестве точки входа в локальную сеть. В ходе взлома внешней пользовательской системы, имеющей доступ к шлюзу, атакующие смогли получить доступ к плате и через неё ко всей внутренней сети Лаборатории реактивного движения, разрабатывавшей марсоход Кьюриосити и выведенные в космос телескопы.

Следы проникновения посторонних во внутреннюю сеть были выявлены в апреле 2018 года. В ходе атаки неизвестные смогли перехватить 23 файла, общим размером около 500 МБ, связанных с проведением миссий на Марсе. Два файла содержали информацию, подпадающую под запрет экспорта технологий двойного назначения. Кроме того, атакующие получили доступ к сети спутниковых антенн DSN (Deep Space Network), применяемых для приёма и отправки данных на космические аппараты, используемые в миссиях NASA.

Из причин, которые способствовали осуществлению взлома, называется
несвоевременное устранение уязвимостей во внутренних системах. В частности, некоторые актуальные уязвимости оставались неисправленными более 180 дней. В подразделении также ненадлежащим образом велась инвентаризационная база данных ITSDB (Information Technology Security Database), в которой должны были отражаться все подключенные ко внутренней сети устройства. Анализ показал, что данная БД заполнялась неаккуратно и не отражала реальное состояние сети, в том числе в ней не была учтена плата Raspberry Pi, используемая сотрудниками. Сама внутренняя сеть не была разбита на более мелкие сегменты, что упростило деятельность атакующих.
avatar Re: Атаки
August 08, 2019 01:24PM
Атака на системы фронтэнд-бэкенд, позволяющая вклиниться в сторонние запросы

Раскрыты детали новой атаки на сайты, использующие модель фронтэнд-бэкенд, например, работающие через сети доставки контента, балансировщики или прокси. Атака позволяет через отправку определённых запросов вклиниваться в содержимое других запросов, обрабатываемых в том же потоке между фронтэндом и бэкендом. Предложенный метод успешно применён для организации атаки, позволяющей перехватывать параметры аутентификации пользователей сервиса PayPal, который выплатил исследователям около 40 тысяч долларов в рамках программы информирования о наличии неисправленных уязвимостей. Атака также применима для сайтов, использующих сеть доставки контента Akamai.

Суть проблемы в том, что фронтэнды и бэкенды зачастую обеспечивают разный уровень поддержки протокола HTTP, но при этом инкапсулируют запросы разных пользователей в общий канал. Для связи принимающего запросы фронтэнда и обрабатывающего запросы бэкенда устанавливается долгоживующее TCP-соединение, через которое транслируются запросы пользователей, передаваемые по цепочке, один следом за другим с разделением средствами протокола HTTP. Для разделения запросов могут использоваться заголовки "Content-Length" (определяет общий размер данных в запросе) и "Transfer-Encoding: chunked" (позволяет передавать данные по частям, указывая блоки разного размера в формате "{размер}\r\n{блок}\r\n{размер}\r\n{блок}\r\n0"подмигнуть.

Проблема возникает если фронтэнд поддерживает только "Content-Length", но игнорирует "Transfer-Encoding: chunked" (например, так поступал CDN Akamai) или наоборот. В случае поддержки Transfer-Encoding: chunked" на обеих сторонах для атаки могут использоваться особенности реализации парсеров HTTP-заголовков (например, когда фронтэнд игнорирует строки вида "Transfer-Encoding: xchunked", " Transfer-Encoding: chunked", "Transfer-Encoding:[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" или "Transfer-Encoding : chunked", а бэкенд успешно обрабатывает их).

В этом случае атакующий может отправить запрос, в котором одновременно указаны заголовки "Content-Length" и "Transfer-Encoding: chunked", но размер в "Content-Length" не соответствует размеру chunked-цепочки, которая меньше фактического значения. Если фронтэнд обработает и перенаправит запрос в соответствии с "Content-Length", а бэкенд будет ожидать завершения блока на основе "Transfer-Encoding: chunked", то конец данных на основании "Transfer-Encoding: chunked" будет определён раньше и оставшийся хвост запроса атакующего окажется вначале следующего запроса, т.е. атакующий получит возможность прикрепления произвольных данных к началу чужого запроса, переданного следом.



Для определения проблемы в используемой связке фронтэнд-бэкенд через фронтэнд можно отправить запрос вида:
POST /about HTTP/1.1 Host: example.com Transfer-Encoding: chunked Content-Length: 4 1 Z Q

Проблема присутствует, если бэкенд сразу не обработает запрос и будет ожидать прихода финального нулевого ограничивающего блока chunked-данных. Для более полной проверки подготовлена специальная утилита, которая также тестирует возможные методы скрытия заголовка "Transfer-Encoding: chunked" от фронтэнда.

Проведение реальной атаки зависит от возможностей атакуемого сайта, например, при атаке на web-приложение Trello можно подменить начало запроса (подставить данные вида "PUT /1/members/1234... x=x&csrf=1234&username=testzzz&bio=cake"подмигнуть и отправить сообщение, включающее оригинальный запрос стороннего пользователя и указанные в нём Cookie аутентификации. Для атаки на saas-app.com оказалось возможным осуществить подстановку JavaScript-кода в ответ, через его подстановку в один из параметров запроса. Для атаки на redhat.com был использован внутренний обработчик для перенаправления на сайт атакующего (был подставлен запрос вида "POST /search?dest=../assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1"подмигнуть.

Применение метода для сетей доставки контента, позволяло просто подменить запрашиваемый сайт через подстановку заголовка "Host:". Атака также применима для организации отравления содержимого систем кэширования контента и извлечения прокешированных конфиденциальных данных. Вершиной применения метода стала организация атаки на PayPal, позволяющей перехватывать пароли, отправляемые пользователями при аутентификации (было осуществлено изменение запроса iframe для выполнения JavaScript в контексте страницы paypal.com/us/gifts, для которой не применялся CSP (Content Security Policy)).

Интересно, что в 2005 году была предложена похожая по сути техника подмены запросов, позволяющая подменить данные в кэширующих прокси (Tomcat, squid, mod_proxy) или обойти блокировки межсетевых экранов через указание нескольких запросов "GET" или "POST" в рамках одного HTTP-сеанса.
Извините, но только зарегистрированные пользователи могут писать на этом форуме.

Нажмите, чтобы войти