Всем привет.
Хочу поделиться одной ситуационной проблемой, которая возникла в ходе моего пребывания на проходящем в Калининградской области международном форуме и ее решением в стиле голодного IT'шника.
Пост будет о том, как удалось обойти лимит на одну порцию, установленную в столовой.
Предисловие
Совсем недавно я в очередной раз побывал в качестве участника на международный форуме, ежегодно проходящий у нас в Калининградской области, на берегу Балтийского моря.
Основная задача нашего потока на DevCamp была за время пребывания разработать и презентовать концепцию какого-либо IT-проекта.
Однако, помимо работы над основным проектом, появилось желание немного отвлечься в сторону…
Проблема: одной порции явно мало
В этом году на территории столовой форума было нововведение: пройти покушать можно было только 1 раз (один раз на завтрак, один на обед и один на ужин).
Контроль осуществлялся на входе с помощью специально обученного человека и МК со считывателем, к которому нужно прикладывать персональный бейджик с rfid меткой.
Если загорался зеленый светодиод — пропускали покушать, если красный — нет.
Рис.1 (Микроконтроллер ответственный за пропуск)
Мне захотелось повлиять на данную ситуацию, и у меня это получилось.
Анализ алгоритма принятия решения пропуска к еде
Первое, на что я обратил внимание, это патчкорд, который выходил из МК. Я немного прогулялся по пути его следования.
Это привело меня в дальний угол столовой, где висел роутер.
Рис.2 (Роутер в углу шатра столовой)
Когда время кормежки кончилась, и столовая освободилась от людей, я подключился к свободному порту в надежде достать пароль от WiFi сети, чтобы продолжить свои исследования, не привлекая лишнего внимания — подальше от столовой. Оказалось, что роутер перепрошит в DD-WRT и стандартные пароли в его админку поменяны, по этой причине мне пришлось продолжить, сидя в столовой.
Сканирование сети
DHCP на роутере был предположительно выключен, либо стояли фильтры, т.к моему ноутбуку адрес не выдавался. Как оказалось, адресация устройств была стандартная.
рис.3 (Результат сканирования сети)
Не сложно было догадаться, какие адреса могут иметь МК (их два, один с левого и один с правого входа в столовую).
Кандидатов было три: 192.168.1.130,192.168.1.120 и 192.168.1.112.
Анализ трафика
Используя технологию ARP-Poisoning, я замитмил трафик между шлюзом и предполагаемым МК через себя. И очень быстро смог поймать нужный пакет.
рис.4 (Оригинальный диалог между МК и сервером)
Как оказалось, за принятие решения ответственен сервер erp.labadabadoo.ru. МК шлет HEAD запрос в формате /skud/meal/?id={идентификатор rfid метки}. Сервер в ответ шлет либо код «200» и на МК загорается зеленый светодиод, либо «403» — тогда загорается красный.
Влияем на ситуацию
Для этого был установлен Apache и применена атака типа DNS-Spoofing. Теперь хостнейм erp.labadabadoo.ru резолвился как 192.168.1.99 (мой ноутбук) и мой локальный Apache всегда отвечал «200».
рис.5 (DNS-Spoofing в действии)
Итоговый результат можно увидеть ниже. Прошу прощения за горизонтальное видео.
Дисклеймер: ни один борщ в ходе исследований не пострадал
Хочу сказать спасибо Intercepter за инструмент, который не позволит остаться айтишнику голодным.
В ходе исследования лишняя еда не была съедена, зато морально я был сыт.
Автор: AndreyKu
