Назад | Перейти на главную страницу

Обман устройств, которые отправляют данные на удаленный компьютер, чтобы отправлять данные вам в вашей сети

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

Вопрос: Существуют ли решения для настройки устройства во вторичной автономной сети (только LAN) и перехвата информации, которая передается на удаленные серверы (возможно, обманом заставив устройство думать, что оно подключено к удаленному [что было бы невозможно так как сеть только LAN])? Я нашел api на github, который позволяет пользователям собирать данные для себя, но все они работают, собирая данные, когда они уже были отправлены на сервер (например, совенок, snoo). Таким образом, они больше взаимодействуют с (сторонними) серверами, которые компания передала в субподряд, а не с самим устройством. Возможно, это сводится к решению от устройства к устройству, поскольку вам придется взламывать любую встроенную защиту, чтобы подтвердить, что это их удаленный сервер, но я полностью новичок в этой области, поэтому даже упоминание фраз в Google и получение дополнительной информации было бы полезно.

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

Спасибо.

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

В целом корпоративное решение:

Запретите прямой доступ в Интернет из вашей собственной сети (сегментов).

Предоставляйте доступ в Интернет только явно разрешенным устройствам и, в идеале, только явно определенным адресатам.

———

Если протокол, используемый устройствами, позволяет это и устройство поддерживает настройку явного прокси:

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

Настройте устройство для использования вашего прокси-сервера

И вы можете видеть, какие сообщения кому отправлены.

———

Если устройство не позволяет настроить явный прокси-сервер - настройте прокси-сервер как прозрачный прокси и перенаправьте трафик на сетевом уровне (например, http-трафик на порт 80 api.example.com) на up-адрес вашего прокси-сервера и порт

И вы можете видеть, какие сообщения отправлены.

———

Когда устройство обменивается данными по TLS - транспортный уровень будет зашифрован.

Вы можете настроить свой собственный корневой сертификат, создать, например, поддельный сертификат для api.example.com и использовать явный или прозрачный прокси-сервер для представления этого сертификата, а затем попытаться выполнить перехват действия посредника. TLS-трафик.

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

Это сработает с большей вероятностью, если вы можете добавить свой собственный ЦС в список доверенных сертификатов ЦС на устройстве.

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

———

Если протокол нелегко проксировать (и является открытым текстом), вы можете попытаться записать сообщения с помощью перехвата пакетов или сетевого сниффера.

———

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