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

Про автоматизацию

Условно, всю автоматизацию можно разделить на три категории:
Категория 1 — отдельные “умные” устройства. Вы приобретаете у разных производителей лампочки, чайники и т.д. Плюсы: каждое устройство расширяет возможности и повышает комфорт. Минусы: для каждого нового производителя необходимо свое приложение. Протоколы устройств разных производителей зачастую не совместимы между собой.

Категория 2 — установка одноплатного ПК или х86 совместимого. Это снимает ограничения по вычислительной мощности, и на данную машину устанавливается MajorDoMo или любой другой серверный дистрибутив для управления умным домом. Таким образом, устройства большинства производителей соединяются в едином информационном пространстве. Т.е. появляется свой Сервер для умного дома. Плюсы: совместимость под единым центром, что дает расширенные возможности для управления. Минусы: при поломке\отказе сервера вся система возвращается в стадию 1, т.е. становится разрозненной, или делается бесполезной.

Категория 3 — самый хардкорный вариант. На стадии ремонта закладываются все коммуникации и дублируются все системы. Плюсы: все доведено до идеала и тогда дом становится действительно умным. Минусы: крайняя дороговизна по сравнению с категориями 1 и 2, необходимость продумывания наперед всего и учета каждой мелочи.

Большинство пользователей выбирают вариант один, а затем плавно переходят в вариант два. А в дальнейшем самые стойкие доходят до варианта 3.

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

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

Рассмотрим интеграцию в нашу систему на примере.

Представим, что у нас в сети имеется 8 модулей Sonoff. Некоторым пользователям будет достаточно управления через облако Sonoff (категория 1). Некоторые станут использовать стороннюю прошивку и плавно перейдут в категорию 2. Основная масса сторонних прошивок работает по одинаковому принципу: передача данных на MQTT-сервер. OpenHub, Majordomo или любой другой служат одной цели – объединить разрозненные устройства в единое информационное пространство, расположенное либо в Интернете, либо в локальной сети. Следовательно, наличие Сервера является обязательным. Отсюда возникает главная проблема – при отказе Сервера вся система перестает работать автономно. Для предотвращения этого, системы усложняются, добавляются ручные способы управления, которые дублируют автоматику в случае отказа Сервера.

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

Вернёмся к мысленному эксперименту. Снова возьмём те же самые 8 модулей Sonoff и установим в них прошивку Lytko. Во всех прошивках Lytko реализована функция SSDP. SSDP — сетевой протокол, основанный на наборе протоколов Интернета, служащий для объявления и обнаружения сетевых сервисов. Ответ на запрос может быть как стандартный, так и расширенный. Мы заложили в этот ответ помимо стандартных функций создание списка устройств в сети. Таким образом, устройства сами находят друг друга, и у каждого из них будет такой список. Пример SSDP листа:

"ssdpList":  	{ 		"id": 94967291,   		"ip": "192.168.x.x",                 "type": "thermostat" 	},  	{ 		"id": 94967282, 		"ip": "192.168.x.x",                 "type": "thermostat" 	}

Как видно из примера, список включает в себя id устройств, ip-адрес в сети, тип блока (в нашем случае — термостат на основе Sonoff). Данный список обновляется один раз в две минуты (этого промежутка достаточно для реагирования на динамическое изменение количества устройств в сети). Таким образом, мы отслеживаем добавление, изменение и отключение устройств без каких-либо действий со стороны пользователя. Этот список отправляется в браузер или мобильное приложение, и скрипт сам формирует страницу с заданным количеством блоков. Каждый блок соответствует одному устройству/сенсору/контроллеру. Визуально список выглядит так:

Но если к esp8266/esp32 подключены другие радио-сенсоры через cc2530 (ZigBee) или nrf24 (MySensors)?

Про проекты

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

Ниже приведены проекты, которые так или иначе стараются изменить ситуацию с несовместимостью разных производителей между собой. Это, например, SLS Gateway, MySensors или ZESP32. ZigBee2MQTT завязан на MQTT-сервере, поэтому не подходит для примера.

Одним из вариантов реализации MySensors является шлюз, основанный на ESP8266. Остальные примеры — на ESP32. И в них можно внедрить наш принцип работы по обнаружению и созданию списка устройств.

Проведём ещё один мысленный эксперимент. Имеем шлюз ZESP32 или SLS Gateway, или MySensors. Как можно их объединить в едином информационном пространстве? К стандартным функциям данных шлюзов добавим библиотеку протокола SSDP. При обращении к данному контроллеру по SSDP, он к стандартному ответу добавит список устройств, которые подключены к нему. На основе этой информации браузер сформирует страницу. В общем виде это будет выглядеть так:

Web-интерфейс

PWA-приложение

"ssdpList":  {    "id": 94967291, // уникальный идентификатор устройства    "ip": "192.168.x.x", // ip адрес в сети    "type": "thermostat" // тип устройства }, {    "id": 94967292,    "ip": "192.168.x.x",    "type": "thermostat" }, {    "id": 94967293,    "ip": "192.168.x.x",    "type": "thermostat" }, {      "id": 13587532,     "type": "switch"   }, {      "id": 98412557,     "type": "smoke" }, {      "id": 57995113,     "type": "contact_sensor" }, {      "id": 74123668,    "type": "temperature_humidity_pressure_sensor" }, {     "id": 74621883,      "type": "temperature_humidity_sensor" } 

Из примера видно, что устройства добавляются независимо друг от друга. Подключены 3 термостата с собственными ip-адресами и 5 разных сенсоров с уникальными id. Если сенсор подключен к Wi-Fi сети, то он будет иметь свой ip, если подключен к шлюзу, то ip-адрес устройства будет являться ip-адресом шлюза.

Для связи с устройствами мы применяем WebSocket. Это позволяет минимизировать затраты ресурсов по сравнению с get-запросами и получать информацию динамически при подключении или изменении.

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

Первой попыткой реализации такого подхода было PWA-приложение. Это позволяет хранить базу блоков на устройстве пользователя и запрашивать только необходимые данные. Но ввиду особенностей структуры такой вариант неполноценен. И выход один — нативное приложения для Android и IOS, которое сейчас находится в активной разработке. По умолчанию, приложение будет работать только во внутренней сети. При необходимости можно перевести всё на внешнее управление. Так, когда пользователь покидает локальную сеть, приложение автоматически переключается на облако.

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

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

Про термостат

Рассмотрим систему управления на примере нашего термостата.

Предусмотрено:

1. Регулирование температуры каждого термостата (отображается в виде отдельного блока);
2. Настройка расписания работы термостата (утро, день, вечер, ночь);
3. Выбор Wi-Fi сети и подключения к ней устройства;
4. Обновление устройства “по воздуху”;
5. Настройка MQTT;
6. Настройка сети, к которой подключено устройство.

Кроме управления посредством web-интерфейса, предусмотрели классическое — нажатиями по дисплею. На борту стоит монитор Nextion NX3224T024 2.4 дюйма. Выбор пал на него ввиду простоты работы с девайсом. Но в разработке находится собственный монитор на основе STM32. Его функционал ничуть не хуже, чем у Nextion, но стоить будет он дешевле, что положительно скажется на конечной цене устройства.

Как и любой уважающий себя экран термостата, наш Nextion умеет:

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

Кроме того, с помощью монитора можно:

• выбрать тип установленного у пользователя датчика;
• управлять функцией защиты от детей;
• обновить прошивку.

По клику на бар WiFi пользователь узнает информацию о подключенной сети. QR код используется для сопряжения устройства в прошивке HomeKit.

Демо работы с дисплеем:

Мы разработали демо-страницу с тремя подключенными термостатами.

Вы спросите: “В чём особенность вашего термостата?” Сейчас на рынке существует множество термостатов с функцией Wi-Fi, работой по расписанию, сенсорным управлением. А энтузиасты написали модули для взаимодействия с большинством популярных систем умный дом (Majordomo, HomeAssistant и т.п.).

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

И расширяемость. Любой желающий сможет заменить установленный у него обычный термостат на наш. С минимальными усилиями. Мы выбрали 5 самых популярных датчиков, представленных на рынке, и добавили их поддержку. Но даже в случае эксклюзивных характеристик датчика, пользователь сможет подключить его к нашему термостату. Для этого понадобится произвести калибровку термостата для работы с конкретным сенсором. Инструкции мы предоставим.

Подключая термостат или любое другое устройство, оно одновременно появляется везде: и в web-интерфейсе, и в PWA-приложении. Добавление устройства происходит автоматически: достаточно лишь подключить его к Wi-Fi сети.

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

Для заинтересовавшихся — наши соцсети: Telegram, Instagram, Telegram News, VK, Facebook.

Почта: shop@lytko.com

P. S. мы не призываем отказываться от Сервера. У нас также присутствует поддержка MQTT-сервера и есть собственное облако. Наша цель — вывести стабильность и надёжность системы на качественно новый уровень. Чтобы Сервер не являлся слабым местом, а дополнял функционал и делал систему удобнее.

В прошлом году мы в DeviceLock провели анализ утекших паролей. На тот момент в нашей «коллекции» паролей было около 4 млрд уникальных пар логин/пароль. За время, прошедшее с прошлого исследования, «коллекция» пополнилась почти 900 млн новыми уникальными логинами и паролями. Кстати, следить за обновлениями «коллекции» паролей можно через мой авторский Telegram-канал «Утечки информации».

Пришло время нового исследования. Поехали…

В исследование вошло примерно 4,9 млрд уникальных пар логин/пароль. Под логином в данном случае понимается адрес электронной почты. Те пары, в которых в качестве логина использовалось имя пользователя, не являющееся адресом электронной почты, были дисквалифицированы и не повлияли на результат исследования.

Отдельно отмечу, что за все время (начиная с самого первого исследования паролей в 2017 году) нами было проанализировано 29,5 млрд паролей (включая неуникальные).

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

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

За 2019 год можно отметить следующие крупные утечки (свыше 25 млн пар логин/пароль), попавшие в данное исследование:

• генеалогический сервис «MyHeritage» — 180 млн
• приложение для фитнеса и учета питания «MyFitnessPal» — 49 млн
• облачный сервис создания видео «Animoto» — 40 млн
• онлайн магазин одежды «Shein.com» — 31 млн
• образовательный портал «Chegg» — 29 млн
• разработчик онлайновых игр «Zynga» — 26 млн

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

На момент исследования в базе паролей:

• 4,883,711,954 всего паролей (было 4,039,047,139)
• 779,281,749 паролей содержат только цифры (было 652,395,037)
• 1,275,706,800 паролей содержат только буквы (было 1,060,863,995)
• 13,696,084 паролей содержат буквы кириллического алфавита (было 12,205,832)
• 159,948,243 паролей содержат буквы, цифры и спецсимволы (было 129,628,109)
• 3,126,556,695 паролей содержат 8 и более символов (было 2,604,395,502)

На основании этих данных был составлен наш традиционный «хит-парад» паролей. В скобках указывается старое место записи в топе (если она в него попадала ранее), жирным шрифтом (болдом) – новые записи, которые не попадали в топ ранее.

10 самых популярных паролей:

1. 123456
2. 123456789
3. qwerty
4. 12345 (5)
5. password (4)
6. 12345678 (8)
7. qwerty123 (6)
8. 1q2w3e (7)
9. 111111
10. 1234567890

Как видно, никаких существенных изменений в пределах первой десятки не произошло, лишь некоторые записи поменялись местами. Интересно, что точно такая же картина наблюдается и в пределах первых ста паролей. Самое существенное изменение — это появление в конце первой сотни паролей «zinch», «princess» и «sunshine».

А вот так выглядят 10 самых популярных паролей из утечек только за 2019 год:

1. 123456
2. 123456789
3. 12345
4. qwerty
5. password
6. qwerty123
7. 1q2w3e
8. 12345678
9. 111111
10. 1234567890

Нетрудно заметить, что принципиальной разницы с общим Топ-10 (см. выше) паролей нет.

10 самых популярных паролей, содержащих только буквы:

1. qwerty
2. password
3. qwertyuiop
4. qwert
5. iloveyou
6. zxcvbnm
7. unknown
8. qazwsx (7)
9. dragon (8)
10. monkey (9)

10 самых популярных паролей, содержащих буквы, цифры и спецсимволы:

1. Aa123456.
2. )4ever (1)
3. 1qaz@WSX (2)
4. P@ssw0rd (3)
5. p@ssw0rd (5)
6. 123456QQAqqa_ (4)
7. 1qaz!QAZ
8. Spiritwear_2004
9. wowecarts@123 (6)
10. film@123 (8)

10 самых популярных кириллических паролей:

1. пароль (2)
2. йцукен (3)
3. я (1)
4. любовь
5. привет
6. наташа (7)
7. люблю (6)
8. максим
9. андрей
10. солнышко

Здесь самое существенное изменение в пределах первой сотни — это появление в самом конце пароля «вампир».

В результате исследования журнал Wall Street Journal выяснил, что атака Cloud Hopper была гораздо обширнее, чем считалось ранее

Казалось, что хакеры таятся везде.

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

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

Впервые исследователи кибербезопасности обнаружили признаки взлома в 2016 году, и назвали их Cloud Hopper [облачный попрыгун]. В прошлом декабре прокуроры США обвинили в этом двух граждан Китая. Подозреваемые пока не задержаны.

В исследовании Wall Street Journal обнаружено, что на самом деле масштаб этой атаки гораздо больше, чем считалось ранее. Он выходит далеко за пределы 14 неназванных компаний, перечисленных в обвинительном акте, распространяется на несколько облачных провайдеров числом не менее десяти, включая CGI Group Inc., одного из крупнейших канадских провайдеров; Tieto Oyj, крупную финскую IT-компанию; и International Business Machines Corp.

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

В WSJ обнаружили, что в Hewlett Packard Enterprise Co. всё было настолько плохо, что облачная компания даже не заметила повторного проникновения хакеров в сети клиентов, и дала зелёный свет всем клиентам.

Внутри облаков группа хакера, которую западные чиновники и исследователи окрестили APT10, получила доступ к огромному набору клиентов. В исследовании WSJ были обнаружены сотни фирм, работавших с пострадавшими облачными провайдерами, включая Rio Tinto, Philips, American Airlines Group Inc., Deutsche Bank AG, Allianz SE и GlaxoSmithKline PLC.

Директор ФБР Кристофер Рэй зачитывает обвинение двух граждан Китая в атаке Cloud Hopper 20 декабря 2018

Вопрос о том, остаются ли хакеры внутри сетей компаний и по сей день, остаётся открытым. WSJ изучили данные, предоставленные SecurityScorecard, и обнаружили сотни IP-адресов по всему миру, которые в период с апреля по середину ноября продолжали передавать данные в сеть APT10.

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

Теперь правительство США утверждает, что APT10 удалось похитить подробные дела на более чем 100 000 служащих ВМФ США.

Моряки ВМФ США наблюдают за самолётом EA-18 Growler

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

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

Представитель Министерства внутренней безопасности США не стал отвечать на вопрос о том, подверглось ли министерство взлому. Не ответили на запрос и из министерства юстиции.

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

«Мы полностью отрицаем все обвинения со стороны СМИ в том, что HPE не сотрудничала с правительством со всем возможным рвением, — сказал Бауэр. – Все подобные заявления являются неприкрытой ложью».

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

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

Многие фирмы, с которыми связалась редакция WSJ, отказались раскрывать информацию о том, подвергались ли они атакам. Из American Airlines сообщили, что получили уведомление от HPE в 2015 году о том, что «их системы оказались вовлечены в инцидент с кибербезопасностью», и что они «не нашли никаких свидетельств компрометации систем или данных».

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

Представитель Allianz сообщил, что компания «не нашла свидетельств» присутствия APT10 в их системах.

GlaxoSmithKline, Deutsche Bank, Rio Tinto и Tieto комментариев не давали. Из CGI не пришло ответа на несколько запросов. Китайское правительство также не стало отвечать на запрос. В прошлом оно уже отрицало обвинения во взломе.

Призраки

Исследователи говорят, что Cloud Hopper стала новой техникой для APT10 (Advanced Persistent Threat, «постоянной передовой угрозы»), одной из самых неуловимых китайских хакерских группировок. «Помните ту старую шутку о том, зачем нужно грабить банк? – Сказала Энн Ньюбергер, глава директората по кибербезопасности Национального агентства безопасности. – Потому что там лежат деньги».

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

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

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

Шахта Rio Tinto в Бороне, Калифорния.

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

Орин Паливода, спецагент ФБР, расследовавший деятельность Cloud Hopper, сказал на недавней конференции по безопасности в Нью-Йорке, что команда APT10 работала подобно призракам в облаках. Они «по сути, выглядели похожими на весь остальной трафик, — сказал он. – И это большая, большая проблема».

Крис Макконки, старший исследователь по кибербезопасности из лондонского филиала PricewaterhouseCoopers, одним из первых обнаружил объём операций APT10. Во время рутинного аудита безопасности в международной консалтинговой фирме в начале 2016 года, на его дисплеях внезапно стали появляться красные точки, обозначающие массовую атаку.

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

«Когда понимаешь, что таких случаев много – и что атакующие на самом деле понимают, к чему они получили доступ и как злоупотребить этим – понимаешь серьёзность возможных последствий», — сказал Макконки. Он не стал называть конкретные компании или провайдеров.

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

Крис Макконки

Они узнали, что хакеры работали в командах. «Вторничная команда», как назвал её Макконки, посещала сервисы, чтобы убедиться, что все украденные имена пользователей и их пароли всё ещё работают. Другая группа часто появлялась через несколько дней, и крала целевые данные.

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

В первые месяцы работы группа Макконки начала делиться информацией с другими фирмами, занимающимися вопросами безопасности, которые тоже начали наталкиваться на призраков. Иногда атакующие поддразнивали охотников, регистрирця доменные имена для своей кампании типа gostudyantivirus.com и originalspies.com.

«Мало я видел китайских APT-групп, так активно издевавшихся над исследователями», — сказал Майк Маклеллан, директор исследований в области безопасности в компании Secureworks. Он добавил, что иногда APT10 часто включала в свои вредоносные программы оскорбительные фразы.

Одной из наиболее значимых жертв хакеров была HPE, чьи услуги по предоставлению облачных сервисов для бизнеса обслуживают данные тысяч компаний из десятков стран. Один из её клиентов, Philips, управляет 20 000 ТБ данных, включая огромные объёмы информации, связанные с клиническими исследователями, и данные приложения для людей с диабетом, как указывается в рекламном ролике, опубликованном в твиттере HPE в 2016 году.

APT10 была серьёзной проблемой для HPE, по меньшей мере, с 2014 года – и компания не всегда сообщает клиентам степень серьёзности проблемы с её облаками, как утверждают знакомые с этой темой люди.

Серверный шкаф в HP Enterprise в Бёблингене, Германия.

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

«Мы добросовестно работали над устранением последствий вторжения, пока не убедились, что полностью устранили следы взломщиков в системе», — сказал Бауэр, представитель HPE.

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

Представитель DXC Ричард Адамонис сказал, что «не было инцидентов, связанных с кибербезопасностью, которые бы неблагоприятно повлияли на материальные активы DXC или её клиентов».

Представитель Philips сообщил, что услуги, предоставляемые HPE, «не связаны с хранением, управлением или передачей данных пациентов».

Отпор

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

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

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

APT10 вскоре вернулась, атаковав новых жертв, включая несколько финансовых компаний.

Одной из новых целей стала IBM, предлагающая облачные услуги для множества фирм из списка Fortune 500, а также для таких правительственных учреждений США, как управление общего обслуживания, министерство внутренних дел и армия.

Стенд IBM на ярмарке CeBIT в Ганновере, Германия, 2018.

Представитель управления общего обслуживания сообщил, что агентство работает с несколькими облачными компаниями, знает про Cloud Hopper, и «неусыпно справляется с угрозами безопасности». Министерство внутренних дел и армия США не прокомментировали ситуацию.

О том, что случилось в IBM, известно очень мало. Хакеры научились лучше скрываться и перенаправляли свои атаки через цепочки из нескольких серверов. Американские чиновники описывали ощущение паники, захватившей их в 2017 и 2018 годах, когда они узнали о новых взломах, осуществлённых APT10. Ситуация стала настолько критической, что им пришлось выпустить публичное предупреждение о том, что хакеры проникли в важнейшие инфраструктуры страны, включая IT, энергетику, здравоохранение и производство.

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

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

Из двух этих лиц есть немного информации о Чжу Хуа, известном в онлайне, как Godkiller. Другого человека, Чжана Шилуна, известного, как Darling Dragon, исследователи связали с учётной записью в соцсетях, где размещались инструкции по обучению взлому.

Оба они, скорее всего, до сих пор находятся в Китае, и могут попасть в тюрьму США на срок до 27 лет за организацию заговора, мошенничество и кражу личности. Но у США нет договора о выдаче преступников с Китаем, и редакции WSJ не удалось связаться с ними для того, чтобы получить комментарии.

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

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

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

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

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

«Я бы был шокирован, узнав, что на сегодня нельзя найти несколько десятков компаний, не подозревающих, что APT10 взламывали их сеть, или до сих пор имеют к ней доступ», — сказал Люк Дембоски, бывший заместитель помощника генерального прокурора по национальной безопасности, ныне работающий с компаниями, подвергшимися атакам различных групп, в том числе и APT10.

«Вопрос лишь в том, что они там делают? – сказал Макконки. – Они никуда не делись. Просто то, что они делают в данный момент, мы не видим».

Привет, Хабр! Представляю вашему вниманию перевод статьи "Functional PowerShell with Classes.
I promise it’s not an oxymoron" автора Christopher Kuech.

Объектно-ориентированная и функциональная парадигмы программирования могут казаться не в ладах друг с другом, но обе в равной мере поддерживаются в Powershell. Практически все программные языки, функциональные и нет, имеют средства расширенного связывания имён и значений; Классы, подобно struct-ам и record-ам, это всего лишь один подход. Если мы ограничим использование Классов связыванием имён и значений и станем избегать таких "тяжёлых" объектно-ориентированных программных концепций, как наследование, полиморфизм, или изменяемость (mutability), мы сможем использовать их преимущества, не усложняя наш код. Далее, добавляя неизменяемые (immutable) методы преобразования типов, мы можем обогатить Классами наш функциональный код.

Магия кастов

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

Каст хэштаблиц

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

class Cluster {     [ValidatePattern("^[A-z]+$")]     [string] $Service     [ValidateSet("TEST", "STAGE", "CANARY", "PROD")]     [string] $FlightingRing     [ValidateSet("EastUS", "WestUS", "NorthEurope")]     [string] $Region     [ValidateRange(0, 255)]     [int] $Index }  [Cluster]@{     Service       = "MyService"     FlightingRing = "PROD"     Region        = "EastUS"     Index         = 2 }

Кроме того, каст помогает получить чистый вывод. Сравните вывод массива хэштаблиц Cluster переданный в Format-Table c тем, что получится, если прежде кастовать эти хэштаблицы в класс. Свойства класса всегда перечисляются в том порядке, в котором они там определены. Не забудьте добавить ключевое слово hidden перед всеми теми свойствами, которые не должны быть видны в выдаче.

Каст значений

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

class Cluster {     [ValidatePattern("^[A-z]+$")]     [string] $Service     [ValidateSet("TEST", "STAGE", "CANARY", "PROD")]     [string] $FlightingRing     [ValidateSet("EastUS", "WestUS", "NorthEurope")]     [string] $Region     [ValidateRange(0, 255)]     [int] $Index      Cluster([string] $id) {         $this.Service, $this.FlightingRing, $this.Region, $this.Index = $id -split "-"     } }  [Cluster]"MyService-PROD-EastUS-2"

Каст к строке

Также вы можете переопределить метод класса [string] ToString(), чтобы определить логику строкового представления объекта, например использовать интерполяцию строк.

class Cluster {     [ValidatePattern("^[A-z]+$")]     [string] $Service     [ValidateSet("TEST", "STAGE", "CANARY", "PROD")]     [string] $FlightingRing     [ValidateSet("EastUS", "WestUS", "NorthEurope")]     [string] $Region     [ValidateRange(0, 255)]     [int] $Index      [string] ToString() {         return $this.Service, $this.FlightingRing, $this.Region, $this.Index -join "-"     } }  $cluster = [Cluster]@{     Service       = "MyService"     FlightingRing = "PROD"     Region        = "EastUS"     Index         = 2 }  Write-Host "We just created a model for '$cluster'"

Каст сериализованных инстансов

Каст позволяет безопасную десериализацию. Примеры ниже завершатся ошибкой, если данные не отвечают нашей спецификации в Cluster

# Валидация сериализованных данных  [Cluster]$cluster = Get-Content "./my-cluster.json" | ConvertFrom-Json [Cluster[]]$clusters = Import-Csv "./my-clusters.csv"

Касты в вашем функциональном коде

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

Функциональный ли Powershell я пишу?

Много людей пришедших из C# или с подобным прошлым пишут Powershell, который похож на С#. Поступая так, вы отказываетесь от использования концепций функционального программирования и, вероятно, получите пользу усиленно погрузившись в объектно-ориентированное программирование в Powershell или лучше изучив функциональное программирование.

Если вы глубоко полагаетесь на трансформацию иммутабельных данных, используя конвейеры (|), Where-Object, ForEach-Object, Select-Object, Group-Object, Sort-Object и т. д. — у вас более функциональный стиль, и вам поможет использование классов Powershell в функциональном стиле.

Функциональное использование классов

Касты, хотя и используют альтернативный синтаксис, всего лишь маппинг между двумя доменами. В конвейере можно смапить массив значений, используя ForEach-Object.

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

# Пример комбинирования классов с конвейерами для separation of concerns в конвейерах  class Node {     [ValidateLength(3, 7)]     [string] $Name     [ValidateSet("INT", "PPE", "PROD")]     [string] $FlightingRing     [ValidateSet("EastUS", "WestUS", "NorthEurope", "WestEurope")]     [string] $Region     Node([string] $Name) {         $Name -match "([a-z]+)(INT|PPE|PROD)([a-z]+)"         $_, $this.Service, $this.FlightingRing, $this.Region = $Matches         $this.Name = $Name     } }  class Datum {     [string] $Name     [int] $Value     [Node] $Computer     [int] Severity() {         $this.Name -match "[0-9]+$"         return $Matches[0]     } }  Write-Host "Urgent Security Audit Issues:" Import-Csv "./audit-results.csv" `     | ForEach-Object {[Datum]$_} `     | Where-Object Value -gt 0 `     | Group-Object {$_.Severity()} `     | Where-Object Name -lt 2 `     | ForEach-Object Group `     | ForEach-Object Computer `     | Where-Object FlightingRing -eq "PROD" `     | Sort-Object Name, Region -Unique

Упаковка класса для переиспользования

Ничто не столь уж хорошо, как кажется

К сожалению, классы не могут быть экспортированы модулями тем же образом, как функции или переменные; но хитрости кое-какие есть. Допустим, ваши классы определены в файле ./my-classes.ps1

• Вы можете сделать дотсорсинг файла с классами:. ./my-classes.ps1. Это выполнит my-classes.ps1 в вашей текущей области видимости и определит там все классы из файла.

• Вы можете создать модуль Powershell, который экспортирует все ваши пользовательские API (командлеты) и установить переменную ScriptsToProcess = "./my-classes.ps1" в манифесте вашего модуля, с тем же результатом: ./my-classes.ps1 выполнится в вашем окружении.

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

Путь вперед

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

class Cluster {     [ValidatePattern("^[A-z]+$")]     [string] $Service     [ValidateSet("TEST", "STAGE", "CANARY", "PROD")]     [string] $FlightingRing     [ValidateSet("EastUS", "WestUS", "NorthEurope")]     [string] $Region     [ValidateRange(0, 255)]     [int] $Index }  function New-Cluster {     [OutputType([Cluster])]     Param(         [Parameter(Mandatory, ParameterSetName = "Id", Position = 0)]         [ValidateNotNullOrEmpty()]         [string] $Id,         [Parameter(Mandatory, ParameterSetName = "Components")]         [string] $Service,         [Parameter(Mandatory, ParameterSetName = "Components")]         [string] $FlightingRing,         [Parameter(Mandatory, ParameterSetName = "Components")]         [string] $Region,         [Parameter(Mandatory, ParameterSetName = "Components")]         [int] $Index     )      if ($Id) {         $Service, $FlightingRing, $Region, $Index = $Id -split "-"     }      [Cluster]@{         Service       = $Service         FlightingRing = $FlightingRing         Region        = $Region         Index         = $Index     } }  Export-ModuleMember New-Cluster

Что ещё почитать

About Classes
Defensive PowerShell
Functional Programming in PowerShell

В конце прошлого года китайское правительство представило новый закон о киберпезопасности, так называемую Многоуровневую схему кибебезопасности (Cybersecurity Muti-Level Protection Scheme, MLPS 2.0). Закон, вступивший в силу в декабре, фактически означает, что правительство имеет неограниченный доступ ко всем данным внутри страны, независимо от того, хранятся ли они на китайских серверах или передаются через китайские сети.

Это означает, что не будет никаких анонимных VPN (а многие популярные VPN принадлежат китайским компаниям). Никаких личных или зашифрованных сообщений. Никаких анонимных онлайн-аккаунтов и конфиденциальных данных. Любые данные будут доступны и открыты для китайского правительства, в том числе и данные иностранных компаний на китайских серверах или проходящие через Китай, поясняется в комментарии юридической фирмы Reed Smith. В каком-то смысле MLPS 2.0 и сопутствующие законы можно сравнить с российским «пакетом законов Яровой».

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

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

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

В соответствии с нынешним MLPS, который существует с 2008 года, сетевые операторы (очень широкий термин, который охватывает любые подключенные компьютеры или системы, отправляющие или обрабатывающие данные) обязаны классифицировать свои сети и информационные системы по различным уровням и применять соответствующие меры защиты. Схема ранжирует системы информационно-коммуникационных технологий (ИКТ) по шкале чувствительности: 1 — наименее чувствительные, 5 — наиболее чувствительные. Чем выше рейтинг, тем более строгому контролю со стороны Министерства общественной безопасности (МПС) подлежит эта система. Третий уровень — та точка, в которой самосертификация превращается в правительственную проверку. Этот уровень достигается, когда ущерб сети приведёт к «особенно серьёзному ущербу законным правам и интересам китайских граждан, юридических лиц и других заинтересованных организаций, или нанесет серьезный ущерб общественному порядку и общественным интересам, или нанесёт ущерб национальной безопасности».

Аналитическая компания NewAmerica поясняет, что MLPS 2.0 представляет собой «смещение в сторону большего количества проверок». В рамках MLPS 2.0 сети, подлежащие проверке, расширяются по существу до любых и всех IT-систем.

Требования к локализации данных

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

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

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

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

Проблемы для иностранных компаний

Американский аналитический центр Центр стратегических и международных исследований (CSIS) утверждает, что Китай в последние годы выпустил около 300 новых национальных стандартов, связанных с кибербезопасностью. Одним из последних изменений является обновление MLPS.

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

Фактически, у них остаётся два варианта.

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

Второй — согласиться на снижение конфиденциальности и безопасности как цену ведения бизнеса в Китае.

Можно сказать, что у иностранных компаний в России остаются те же два варианта.

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