30 апреля 2021 года автор проделал рикролл по своему школьному округу. Это не только моя школа, но и весь школьный городской округ 214 (далее — D214), один из крупнейших школьных округов в Иллинойсе, состоящий из 6 школ, в которых учатся более 11 000 человек.
Подробности рассказываем в этом пятничном посте к старту курса по этичному хакерству.
Эта история не из тех типичных рикроллов, когда студенты проносят Рика Астли на презентации, шоу талантов или звонки Zoom. Я исполнил рикролл, захватив каждый сетевой дисплей в каждой школе, чтобы транслировать «Never Gonna Give You Up» в полной синхронизации. Телевизор в коридоре, проектор в классе или большой экран, отображающий меню обеда, если они были подключены к сети, — я взломал их!
В этой заметке я расскажу, как я это сделал и как мне удалось избежать обнаружения, а ещё о последствиях, когда я раскрыл себя и не попал в беду.
Disclaimer
Этот пост предназначен только для образовательных целей. Не выполняйте подобные действия без явного разрешения.
Мы подготовили полную документацию обо всём, что мы делали, включая рекомендации по устранению обнаруженных нами уязвимостей. Мы предоставили в технический отдел D214 полный отчёт о тестировании на проникновение на 26 страницах и работали с отделом, чтобы помочь защитить их сеть.
При этом то, что мы сделали, было очень незаконно, и другие администрации могли выдвинуть обвинения. Мы благодарны, что администрация D214 отнеслась к этому с пониманием.
Большой Рик
Для начала вот кое-какие кадры всего этого:
Первый взлом
Эта история начинается с первого курса, когда у меня не было особой технической дисциплины: время, которое я могу описать только как начало моего скриптового детства. Я не понимал основ этики или ответственного раскрытия информации и прыгал от радости при любой возможности что-нибудь сломать.
Поэтому, очевидно, мне стало любопытно узнать о технологиях в моей средней школе. И под «любопытством» я имею в виду сканирование портов всего диапазона IP-адресов внутренней районной сети.
Я попросил нескольких друзей помочь с этим проектом, и — о, боже, мы сделали это! Наше сканирование генерировало так много трафика, что об этом узнал школьный технадзор и в один прекрасный момент пришёл попросить нас остановиться. Конечно, мы сделали это немедленно, но к тому времени уже закончили сканирование первой половины адресного пространства округа 10.0.0.0/8 — всего 8 388 606 IP-адресов.
В сети округа мы обнаружили различные незащищённые устройства. В том числе принтеры, IP-телефоны… и даже камеры наблюдения без аутентификации по паролю!
И я снова заявляю: никогда не получайте несанкционированный доступ к другим системам без разрешения.
Технический персонал округа был проинформирован о проблеме, которую они решили, добавив ограничения ACL. Однако многие устройства оставались подключёнными к студенческой сети и, что более важно для этой статьи, к системе IPTV!
Система IPTV Exterity
Перед тем как двигаться дальше, я кратко обрисую систему IPTV. Она состоит из трёх элементов:
AvediaPlayer (приёмники).
AvediaStream (кодеры).
AvediaServer (управление).
AvediaPlayers — это небольшие синие коробки, которые подключаются к проекторам и телевизорам. Они могут отправлять последовательные команды на соответствующее устройство для включения/выключения дисплея, изменения входов/громкости, переключения каналов и т. д.
Эти приёмники содержат как веб-интерфейс, так и SSH-сервер для выполнения последовательных команд. Кроме того, они работают под управлением встроенного Linux с инструментами BusyBox и используют какую-то непонятную архитектуру процессора, разработанную для IoT-устройств, под названием ARC (Argonaut RISC Core).
Далее кодеры AvediaStream подключаются к устройствам, транслирующим видео. Они кодируют прямой эфир, поступающий с этих устройств, на приёмники AvediaPlayer, которые отображают этот поток. Кодеры подключаются к компьютерам, которым необходимо транслировать поток, например текстовые карусели или утренние объявления. Они также имеют встроенное программное обеспечение, аналогичное AvediaPlayers.
И последнее, но не менее важное: AvediaServers позволяют администраторам управлять всеми приёмниками и кодерами одновременно. Их типичные процессоры x86_64 и работают под управлением корпоративного дистрибутива Linux, CentOS. Как и приёмники и кодеры они также имеют веб-интерфейсы и SSH-серверы.
С первого курса у меня был полный доступ к системе IPTV. Я возился с ним всего несколько раз и планировал устроить розыгрыш для старшеклассников, но он отошёл на задворки моего сознания и в конце концов был забыт.
Подготовка
Перед вами второй семестр выпускного класса, начало 2021 года: все школы перешли на гибридное обучение из-за пандемии COVID-19. До этого момента очное обучение проводилось по желанию, большинство студентов, включая меня, обучались дистанционно. Но в марте суперинтендант объявил, что 5 апреля перейдёт на модель отказа от очного обучения.
Поскольку почти все ученики должны были вернуться в школу, я понял, что теперь и стоит устроить выпускной розыгрыш с участием системы IPTV. Через несколько дней я решил поделиться своими мыслями с близкими друзьями.
Я собрал небольшую команду по всему району и начал подготовку. Мы стали называть эту операцию «Большой Рик».
1. Полезная нагрузка C2 и эксплойт
Первое, на чём мы сосредоточились, — это выяснение того, как управлять всеми проекторами одновременно. Хотя мы могли бы отправлять команды на каждый приёмник с помощью веб-интерфейса, это было бы неидеально, если бы мы спамили HTTP-трафик на каждый приёмник одновременно.
Вместо этого как канал управления я использовал SSH-доступ на каждом приёмнике (C2). Я разработал простой сценарий, который послужил поэтапной полезной нагрузкой, загружаемой в каждый приёмник заранее. Этот скрипт содержал различные функции, которые могли выполнять запросы к веб-интерфейсу локально на приёмнике. Благодаря повышенной гибкости полезной нагрузки я также мог создавать резервные копии и восстанавливать настройки приёмника в файловой системе после рикролла:
#!/bin/sh
# get IP address of receiver's main interface for use in HTTP requests to self
# web server is not bound to localhost, so this IP has to be used
ip_address=$(/sbin/ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{print $2}' | cut -f2 -d:)
# POST helper function
sendRequest() {
content=$1
length=${#content}
header="POST /cgi-bin/json_xfer HTTP/1.1\r\nHost: $ip_address\r\nContent-Type: application/json\r\nContent-Length: $length\r\nAuthorization: Basic bnVueWE6YnVzaW5lc3M=\r\n\r\n"
echo -e "${header}" "${content}" | nc "$ip_address" 80
}
# JSON POST data to send "power on" serial command
jsonSerialPowerOn='{"params":{"TVCtrlType":"serial","serialPort":"Serial","standbyActions":"tv_off","unstandbyActions":"tv_on","ToggleDelay":"0","serialActions":"tv_on"},"action":"apply_send"}'
# ... more JSON data payloads
# sample macro function to loop request for three minutes
exampleMacro() {
secs=180
endTime=$(( $(date +%s) + secs ))
while [ $(date +%s) -lt $endTime ]; do
sendRequest "$jsonSerialPowerOn"
sleep 10
done
}
# delete script from filesystem
selfDestruct() {
rm -- "$0"
}
# ./b1gr1ck.sh 1
if [ "$1" -eq "1" ]; then
exampleMacro
# ./b1gr1ck.sh 2
elif [ "$1" -eq "2" ]; then
selfDestructЭто примерная версия полезной нагрузки C2. В реальной полезной нагрузке, чтобы поддерживать работу рикролла, я многократно повторял команды. Например, каждые 10 секунд дисплей включался и устанавливал максимальную громкость.
Таким образом, если кто-то попытается выключить проектор или отключить звук, он вернётся и продолжит воспроизведение. Есть только два способа отключить рикролл — выдернуть вилку из розетки или изменить источник входного сигнала.
Циклическое изменение входного сигнала вызывает вспышки, даже если текущий источник совпадает с последним источником. Мне пришлось полагаться на отказоустойчивый входной переключатель, который активировался прямо перед началом рикролла, чтобы все были настроены на него. Вы можете увидеть эту вспышку в видео на 48-й секунде.
Уязвимости, которые эксплуатировались для получения первоначального доступа, были специфичны для конкретной реализации (то есть D214 виновен в использовании паролей по умолчанию). Однако я обнаружил вендорные уязвимости эскалации привилегий во всех IPTV-продуктах Exterity, что позволило мне получить root-доступ во всех системах. Одна из этих ошибок была простым GTFO-bin, но две другие — новые уязвимости, которые я не могу (и не должен) публиковать.
2. Многоадресный стрим RTP
Следующий вопрос, который мы решали, заключался в настройке пользовательского видеопотока для воспроизведения рикролла в режиме реального времени. Нам нужно было транслировать многоадресный трафик, но из-за ограничений ACL это могли делать только кодеры AvediaStream или серверы AvediaServer.
Настройка потока была, пожалуй, самой трудоёмкой частью подготовки, потому что тестирование стало абсолютным мучением. Для разработки мне нужен был только один проектор, но добраться до него нелегко: в классах работают весь день.
Поэтому я тестировал ночью! Подключался к одному из компьютеров класса с фронтальной камерой, направленной на проектор, записывал видео, чтобы проверить, правильно ли проектор отображает поток.
Для проверки качества потока я использовал цикл с прыгающим логотипом DVD.
Задержка, которую вы видите на видео, — одна из первых проблем, с которыми я столкнулся при работе с потоком. Оказалось, что попытка перенаправить UDP-трафик через кодеры AvediaStream добавляет слишком большую задержку. Я исправил это, транслируя многоадресную рассылку непосредственно с сервера AvediaServer с помощью ffmpeg. Надеюсь, я не напугал никого из персонала!
3. Неожиданное развитие событий
Это было 27 апреля, всего через три дня после финала «Большого Рика», когда один из моих коллег после сканирования обнаружил новый диапазон IP-адресов, полный устройств IoT. Оказалось, что дело в недавно установленной системе звонков, которая называется «Education Paging and Intercom Communications» (EPIC). Большинство устройств в этом диапазоне были колонками, установленными в коридорах, классах и т. д.
Подобно тому, как AvediaPlayers связаны с AvediaServers, каждая колонка подключалась к серверу EPIC своей школы. Веб-интерфейс этих серверов был скрыт за страницей входа.
Учётные данные по умолчанию использовались только на одном сервере EPIC. Мы смогли изменить расписание звонков по своему усмотрению, а также загрузить кастомные звуковые сигналы. И смогли изменить звонки, чтобы они играли «Never Gonna Give You Up».
У нас был доступ только к системе EPIC этой отдельной школы, ведь только у неё были уязвимые учётные данные.
Но я обнаружил, что взломанный нами сервер EPIC еженедельно создавал резервные копии своей конфигурации на внешнем файловом ресурсе SMB. Учётные данные для этого SMB-сервера оказались такими же, как учётные данные по умолчанию в системе EPIC. Каждая резервная копия содержала SQL-дамп имён пользователей и хешей паролей.
А что, если другие системы EPIC также имеют серверы резервного копирования? А поскольку эти резервные серверы находятся отдельно от серверов EPIC, они могут по-прежнему использовать учётные данные по умолчанию.
Именно так и было! Оттуда я смог получить доступ к хешам паролей для других серверов EPIC и определить учётную запись локального администратора, доступную на всех серверах EPIC. После взлома пароля мы получили контроль над всеми расписаниями звонков в округе!
Исполнение
Одним из наших главных приоритетов было не допустить срыва занятий, то есть мы могли провести розыгрыш только до начала занятий, во время перемен или после уроков. До пандемии некоторые занятия начинались раньше, некоторые позже, в некоторых было блочное расписание, а в некоторых все уроки проходили в один день. Удобно, что благодаря COVID-19 все средние школы в округе перешли на единое блочное расписание, поэтому нам не нужно было беспокоиться о составлении расписания для каждой школы.
Ещё один момент — выпускные экзамены были не за горами. Наибольшее беспокойство вызвало стандартизированное тестирование, в котором не будет перерывов. Мы выбрали 30 апреля, это была пятница перед началом экзаменов по курсам повышенной сложности. Также мы провели обширный опрос, чтобы выяснить, проводились ли в этот день какие-либо значимые тестирования. Мы были полностью готовы всё отменить, если бы узнали, что проводится стандартизированное тестирование.
За несколько недель до Большого Рика мы установили полезную нагрузку C2 на все AvediaPlayers в автоматическом режиме, тщательно распыляя наши действия, чтобы избежать обнаружения. В день Большого Рика мы использовали два из семи серверов AvediaServers в качестве C2-мастеров, которые подключались ко всем AvediaPlayers и выполняли полезную нагрузку. Ниже приводится хронология событий 30 апреля:
Хронология событий
10:40. Поток рикролла запускается с 20-минутным обратным отсчётом.
10:55. Системы плеера Avedia инициализируются, включаются дисплеи и активный канал меняется на поток рикролла.
11:00. Поток завершает обратный отсчёт с проигрыванием рикролла в конце первого блока.
11:10. Полезная нагрузка восстанавливает системы AvediaPlayer в их предыдущее состояние и удаляет себя.
14:05. В конце третьего блока вместо звонка играет рикролл.
14:15. Отчёт о тесте на проникновение автоматически отправляется техническим руководителям.
15:25. Начался ещё один звонок с подменой. Если районные технические специалисты всё ещё не выяснили, что произошло, чтобы вернуть звонки, в конце дня прозвучит 1-минутная версия 3-секундного звонка в конце дня, [то есть прозвучит звонок в 20 раз дольше].
Они всё же догадались, поэтому я включил аудиофайл сюда, чтобы и вы смогли им насладиться:
Последствия
Через несколько дней после отправки отчёта через анонимный электронный ящик мы получили ответ по электронной почте от директора по технологиям D214. Директор заявил, что из-за наших рекомендаций и документации округ не будет применять дисциплинарные меры. Более того, он поблагодарил нас за наши выводы и попросил, чтобы мы предоставили отчёт команде технических специалистов. Позже он рассказал, что сами руководители проверили наш отчёт и были впечатлены им.
Я был в восторге от того, что администрация открыта для исправления своих проблем и проведения аудита вместе с нами. Хотя администрация D214 заявила о добрых намерениях (и действительно придерживалась их в будущем), мои сверстники не доверяли ей и скептически отнеслись к истинной природе встречи — один из них назвал всё это спецоперацией!
Мы решили, что на встрече Zoom я раскрою себя, чтобы представить слайды для подведения итогов, а остальные останутся анонимами. Я планировал объявить о своём участии с самого начала, так как хотел опубликовать этот пост в блоге. Но на всякий случай я назначил дебрифинг на время после окончания учёбы.
![Да, это реальный слайд из нашего брифинга. Не @ меня [мне всё равно, что вы подумаете]](https://habrastorage.org/getpro/habr/upload_files/ed8/142/ecf/ed8142ecff097411dfea8ccb75fdbedc.jpeg "Да, это реальный слайд из нашего брифинга. Не @ меня [мне всё равно, что вы подумаете]")
Если серьёзно, дебрифинг прошёл очень хорошо и стал продуктивным для всех. Мы ответили на уточняющие вопросы технической команды и дали дополнительные советы по устранению проблемы. Нам даже удалось заставить округ рассмотреть возможность расширения программы IT/кибербезопасности и, надеюсь, спонсирования CTF в D214. Это одно из самых удивительных впечатлений из моей жизни в старшей школе, и я благодарю всех, кто поддержал меня. Это всё, и спасибо, что прочитали.
Если вы из D214 и у вас есть какие-нибудь видеоролики, фотографии или сообщения о рикролле в социальных сетях, отправьте их мне, и я поделюсь ими ниже с упоминанием.
Видео от nitw_t.
А что вы взломали в своей школе? Поделитесь в комментариях.
Продолжить погружение в IT, чтобы научиться решать проблемы бизнеса, вы сможете на наших курсах:
Узнайте подробности здесь.
Другие профессии и курсы
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также
