Сервисы и устройства Garmin слегли, вероятно, из-за атаки вируса-вымогателя



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

    Согласно информации издания ZDNet, этот серьезный инцидент, буквально остановивший работу целой компании, произошел из-за проникновения внутрь закрытой сети Garmin вируса-вымогателя WastedLocker, который смог заразить большинство ПК сотрудников и часть серверов, отвечающих за передачу данных умных часов и другой спортивной электроники Garmin. Кроме того, сбой коснулся и сервиса для пилотов самолетов flyGarmin. Пилоты, использующие сервис, не могут обновить базы данных Garmin в своих навигационных устройствах, хотя по требованию Федерального управления гражданской авиации США это должно делаться регулярно. Вдобавок перестало работать приложение Garmin Pilot, которое используется при планирования полетов.

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

    Однако, сами пользовательские устройства Garmin от атаки вируса не пострадали, но они сейчас не могут полноценно работать из-за отказа доступа к онлайн-сервисам. Многие пользователи смогли сохранить текущие данные о тренировках со своих гаджетов с помощью ПК и доступу к партнерским службам Garmin, например, Strava.

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

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

    Эксперты ИБ-компании Fox-IT отслеживают появление и использование зловреда WastedLocker с мая 2020 года. По их данным, вымогатель используется исключительно против американских компаний, а суммы выкупов, которые он требует у пострадавших, исчисляются миллионами долларов. При развертывании внутри атакуемой сети вирус шифрует данные на файловых серверах, атакует БД-сервисы, виртуальные машины и облачные среды, нарушает работу приложений для резервного копирования и связанной с ними инфраструктуры, включая удаление резервных копий, чтобы максимально затруднить восстановление информации для пострадавших компаний. Единственное, что WastedLocker не делает — копирование данных перед их шифрованием.

    См. также: «Security Week 31: атака на инфраструктуру Garmin»
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 34

      +1
      А для такого всего одному человеку в огромной компании достаточно открыть приложение в письме с незнакомого адреса.
        +4

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

          –3
          на которые всем плевать, если нет какихто навязанных со стороны стандартов
        +6
        Облачные сервисы.jpg.exe

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

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

          +1

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


          В свое время, я пережил очень похожую историю, когда атака шла со стороны пк админов. Это было в 2009м и дальше шлюзов проникнуть не смогли. Т.е. у нас полегло несколько филиалов, но ядро осталось целым.
          Уже потом мы выяснили, что в одном из оконечных маршрутизаторов в ргионе (!) был хитрый бекдор… Это так, к слову.

            +1
            Уже потом мы выяснили, что в одном из оконечных маршрутизаторов в ргионе (!) был хитрый бекдор…

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

            Я учавствовал в паре тестирований на проникновение, достаточно иметь пару неустановленных патчей в уязвимых местах, специализированный софт моментально выстраивает цепочку проникновения… помню в одом случае у тестеров хватило около 4х часов чтобы получить рута на сервере в ядре сети, только потому что последние апдейты на марштуризаторы ставились месяц назад, а на ОС — две недели назад…
            Полностью вся цепочка была взломана эксплойтами месячной-недельной давности, причем в автоматическом режиме и с минимальными возбуханиями со стороны сервисов мониторинга (все выглядело как обычные действия админов, пока через созвоны выясняли что происходит, было уже поздно)
              0

              Вах как интересно. А как софт называется?
              Мне бы себя поломать эксперимента ради...

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

                но это точно был какойто типовой спец.дистрибутив линукса для тестирования безопасности ИБ с платными подписками на какуюто забугорную контору предоставляющую эксплойты
                  0
                  Не Kali Linux случаем? Этот дистрибутив на слуху.
                    0
                    вполне вероятно, это давно было
            +2

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

              +1

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

                +1

                а апи у них наслышан дерьмовый, на оаус1...

                  +1
                  Самое интересное в этой истории, что софт в телефоне не может показывать загруженные с часов данные без доступа к серверам. Гармин и так-то качеством софта не блистал, мягко говоря, но это совсем уж днище.
                    0
                    Если вашей целью является бигдата, то архитектурно вполне логично мастер источником данных считать центральную БД. Это раз и навсегда решает конфликт версионности и сужает возможности для подтасовки. То, что центральную БД не смогли защитить и прозевали зловреда который скрывался дольше глубины инкрементального резервного копирования, да еще и логи СУБД «съел» — отдельный залет. Ну да ничего страшного. Раскатают последний целый бекап, потеряют «неделю» данных и «руками» восстановят самое важное, извинившись за остальное.
                      0
                      одна точка отказа это очень плохо. особенно когда на нее завязаны миллионы пользователей. пусть тогда делают дублированные распределенные сервера, блокчейн весь этот. Понятное дело, что со сложными политиками, чтобы один сбойный сервер не угробил данные на всех остальных
                      А вообще, конфликт версионности это не решает, т.к. исходные данные лежат на пользовательских устройствах(часах), и там форматы не меняются лет по десять. а весь софт для анализа этих данных уже вторичен, не так страшно что будут разные версии.
                      Я надеюсь, хотя и маловероятно это, что они сделают оффлайн-билд своих сервисов чтобы вернуть лояльность пользователей
                        0
                        Представьте ситуацию когда ваш тренер или доктор хотят получить доступ к данным о вашем здоровье и тренировках. Они должны получить их с ваших часов? С вашего телефона? Или с сервера в интернет?
                          0

                          Доктор или тренер должны получить их лично от меня, на USB стике или в виде файла, или даже просто посмотреть на моём экране — и ни при каких условиях они не должны получать их с сервера в интернет. Если лично не получается — передача в зашифрованном виде на устройство доктора. В любом случае — только push, никаких pull — это единственное что может минимизировать (хотя и не исключить) проблемы с их утечкой и злоупотреблениями.


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


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


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


                          Плюс ко всему — любые данные которые хранятся в облаке должны быть зашифрованы с ключём доступным только пользователю (или доверенным агентам, которых он сам определяет — исключительно opt in), с детальным трекингом кто, когда и что оттуда вытаскивал.


                          Конечно, это в идеальном мире...

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

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


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


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


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


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

                            0
                            Что вы предлагаете делать, когда устройство восстановлено после сбоя и пытается передать иные данные за период который уже занесен в центральную базу?
                              0

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


                              В сочетании с уникальным идентификатором набора данных (учётка + id устройства) это обеспечивает довольно простой и отказоустойчивый способ передавать только то что нужно, причём в обе стороны (синхронизировать).


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

                                0
                                Вы не ответили на вопрос что делать, если устройство все же пытается передать данные за предыдущий период с повторными id/hash? Отбрасывать и верить базе (мастер-база)? Перезаписывать в базе тем, что передано с устройства(мастер-устройство)? Сохранять обе версии? А если попыток несколько, сохранять все версии?
                                  0

                                  Ваш вопрос очень абстрактный. Какое устройство? Была ли на нём предусмотрена возможность повторной передачи? Как оно определяет что данные нужно передавать за определенный период? Где хранятся данные (внешний носитель, внутренний, доступный извне, недоступный etc)? Какими метаданными располагает база и какие находятся в передаваемых данных (метки времени, etc)? Есть ли валидация данных (контрольные суммы etc)? Могут ли в принципе переданные данные корректироваться или дополняться пока не было связи?


                                  Но всё же… поскольку устройство (по крайней мере если это фитнес-трекер) — изначальный генератор данных и в конечном итоге их потребитель — то верить нужно только устройству. База должна быть исключительно репликой данных устройства.


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


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

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


                                  Хотя самая простая стратегия, которая покроет 99% всех случаев — это игнорировать старые данные, тем не менее подтверждая их приём, опционально сравнивая с уже имеющимися.


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


                                  Как я уже сказал, способов зиллион, но нужно знать точно о чём речь и текущую архитектуру.

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

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


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


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


                                      PS: Преставьте что вы пишете рассказ и периодически заливаете новые версии в облако, но в какой-то момент облако решает что ваша версия — совсем не мастер, и нужно вернуть то что хранится в облаке. Вы правда этого хотите? Данные трекеров — тот же рассказ.

                        +1
                        Днище, вот именно. Вторую тренировку уже не могу проанализировать по-человечески.
                        Реквестирую создание нормального опен-сорсного софта для сохранения и анализа занятий (графики там, наложение трека на OSM карту, подсчет средних-среднеквадратичных-стандартных отклонений...), благо .fit это простой текстовый формат (то ли xml то ли csv, давно копался, не помню).
                        Под мак лет десять назад подобное было, но очень слабо развитое на тот момент
                          0
                          Вы путаете .fit и всякие .gpx, .tcx.
                          FIT — это полноценный бинарный формат с кучей наворотов, вроде хранения фаз сна, кровяного давления и имеет спецификацию под 200 стр.

                          Но открытого нормального софта под это всё — равно мало, ввиду относительно малого спроса. Большинство пользуются стандартными Garmin Connect, Strava и тд — и не парятся об открытости и «облачности».
                            0

                            Насколько я помню, fit конвертируется в gpx посредством gpsbabel, а gpx открывается osmand или gpxanalyser под android.
                            И, вроде бы, в gpsbabel есть ещё опция экспорта в какой-то простой формат (csv или txt), я прямо таки в Excel треки потом рисовал для интереса.

                              0
                                0
                                Да, точно, golden cheetah. Виснет после каждого чиха и интерфейс вырвиглазный
                                  0
                                  ну так пойдите поправьте ;)
                              0
                              (Задумчиво)
                              Интересно, их не мяукнули часом?

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

                              Самое читаемое