Как стать автором
Обновить

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

НЛО прилетело и опубликовало эту надпись здесь
Прецедент же! Заплатили раз — заплатят и ещё, т.е. могут начаться массовые атаки на Garmin, если те срочно не переделают всю систему безопасности (а это на рабочих сервисах с нуля всё переделывать — почти нереально).
НЛО прилетело и опубликовало эту надпись здесь
По другим фронтам можно, но ведь и раньше пытались, и что-то я не видел информации, чтобы кто-то особенно много платил. А тут нашли слабое звено, готовое раскошелиться. И если у них аж цеха встали — уязвимость довольно велика.

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


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

НЛО прилетело и опубликовало эту надпись здесь
Так оплатите, перепишут.

Ну вот ютуб пробовали переписать, но гугль активно банит все приложения, которые "переписаны".

Ну вы закажите сервер переписать, может не будет банить.
Ну да.
Для этого vanced.app и распространяется только через сайт, и с собственными gapps-ами
Неужели даже в компаниях такого уровня нет нормальной системы бэкапов?

Чтобы тут же раскатать последний ночной и начать расследование? Ну ладно, пусть будет предпоследний, если в последний уже пошли зашифрованные данные. Это же не банк, потеря изменений за сутки-двое болезненна, но не смертельна.

Тут дома стараешься offline бэкапы делать, чтобы шифровальщик не добрался…
Мне кажется, у Garmin уже давно все плохо было в ИБ.
А сейчас лучше не стало, а только хуже, ибо автомобильный сегмент они потеряли и денег больше не стало.

Там в голове у руководства всё плохо, либо оно живёт в мире радужных пони читая красивые(но не имеющие ничего общего с реальностью) отчёты эффективных менеджеров.
Столько лет пытаться продавать карты для каждого города отдельно ещё и для разных версий, тогда как конкуренты обеспечивали бесплатную(или весьма дешёвую) альтернативу с не худшим качеством.
Они разбалованы малой авиацией, где Garmin пока что абсолютно доминирует на рынке авионики и выставляет за все конские ценники.
Будут дальше ломить цены, получат ровно ту же ситуацию.
Чтобы тут же раскатать последний ночной и начать расследование?

Р — Решето.


Складывается впечатление, что шифровальщик добрался именно до всех бэкапов сразу. Ну, например, завладел рутом на всех устройствах, хранящих бэкапы. Как будто бэкапы были не append-only.


Тут дома стараешься offline бэкапы делать, чтобы шифровальщик не добрался…

А есть какое-нибудь решение для append-only бэкапов? Не на CD же их записывать. (даже если на CD, для чтения надо бы обзавестись непишущим приводом...) Внутренний параноик интересуется.

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

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

PS: Сейчас экспериментирую с Raspberry Pi 4, в принципе неплохо работает в качестве NAS (100 МБ/сек на запись и чтение больших файлов дает, хотя греется при этом знатно).

На случай факапов у меня таки git))
Но, посмотрев на пример garmin и немного обдумав свою конфигурацию, я понял, что против атаки это не поможет.

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

Можно (хотя бы теоретически) записывать на CD-R.

А есть какое-нибудь решение для append-only бэкапов?

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

Зачем CD когда есть BD. Вопрос в том, есть ли системы автоматической подачи чистых дисков для записи и записанных для восстановления, если нет — то оптика не вариант. Автоматизированные LTO-библиотеки?
Кстати да, LTO + WORM картриджи.
WORM, в отличие от BD-R — физически остаётся перезаписываемым, т.е. защита от перезаписи эквивалентна ползунку на картах SD — привод может её игнорировать (если есть возможность хакнуть этот привод извне).

С другой стороны, генерировать стопки одноразовых носителей любого стандарта — неэкологично, потому air gap никто не отменял.
FTP c разрешенным PUT (при этом полным запретом на перезапись при совпадении имен) и отключенными DELE, GET/RETR, APPE, CD/CDUP/CWD и так далее. При этом можно жестко залочить учетку бэкапера в пределах одной конкретной директории (создаваемой, например, автоматически в момент логина). На случай всё же необходимости делать инкрементальные бекапы можно открыть GET/RETR. Серверов FTP множество, возможно, даже какой-нибудь Pure-FTPd/vsftpd уже из коробки это всё умеет.
На самом деле, такие проблемы решаются от обратного. Pull, а не push. Бэкап должен забираться хранилищем, а обратного доступа быть не должно.
Это создает необходимость на продакшн сервере городить еще одну точку отказа (потенциальную дыру), поскольку у бекап-хранилища появляется какой-никакой, но доступ к ресурсам боевой железяки. Но да, можно и GET/RETR-only ftpd. Это если прям на коленке и хардкорно. Суть-то та же.
Вот буквально ВСЕ системы резервного копирования уровня предприятия построены именно таким образом. Хоть Бакула, хоть коммерческие.
управляющий софт, агенты на серверах, агенты на системах хранения. Далее уже работа системного инженера разместить управляющий софт на защищённом от атаки хосте
можно просто стики-бит включить на всех записываемых файлах тогда и не придется команды фильтровать.
Процитирую выдержку из актуального (Debian Buster) man chmod (1):

RESTRICTED DELETION FLAG OR STICKY BIT
The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the
directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files
on some older systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit.


Иными словами, на сегодняшний день (как и гласит Википедия) можно в общем случае считать, что ОС Linux игнорирует этот бит на файлах. А для каталогов помимо бита в контексте обсуждаемой защиты необходимо обеспечить:

  • каталог не принадлежит пользователю с euid учетной записи на FTP-сервере
  • файлы после их заливки меняют своего владельца с euid учетной записи на FTP-сервере (перестают принадлежать этому пользователю)


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

Мы также облажались. Шифровальщик зашифровал сервер и бэкапы к этому северу.

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

Посмотрите по «атака на основе (подобранного) открытого текста» — если кратко, теоретически возможно, но на практике труднореализуемо. Современные системы шифрования разрабатывались с учетом противодействия таким атакам.
Потому что современные криптоалгоритмы устойчивы к такого рода атакам. (упс, YMA ответил быстрее меня)
Кроме вышесказанного, там каждый файл своим ключом шифровался:
screen
image
Я не криптоаналитик, но даже мне понятно, что не сработает. Представьте текстовый файл, в нем первая буква по одному алгоритму, вторая по второму и т.д. И даже одинаковые буквы будут иметь разные значения после шифрования.

Будь так просто, вся современная криптография была бы бесполезна. Всего лишь треть от 2048, а сложность растёт чуть ли не экспоненциально.
У меня на прошлой работе сисадмин каждый день касеты(бекапы бд) менял и клал их в сейф. Босс держал часть касет у себя дома. Касет боло припасено на месяц. На текущей работе хз, что делают. Т.к. фирма раз в 50 больше.
А наличие данных на кассетах когда ни будь потом проверял?
админы делятся на три типа:
1)которые не делают бэкапы
2)которые делают бэкапы
3) которые проверяют — восстанавливаются ли бэкапы
На кассетах то данным ничего не будет, но не каждый бэкап полноценен.
2) — которые УЖЕ делают бэкапы.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
«Оказывается из бэкапов мускуля, которые мы делали 5 лет, невозможно восстановиться. Угадайте, в какой момент мы это узнали?»
Самое интересное что иногда бывает так что имея полные бэкапы все равно восстановиться не получается.
Я недавно поднимал в одной конторе один сервер «для внутренних нужд» с помершими дисками. Бэкапы с данными в порядке, а толку нет, т.к. для запуска того устаревшего движка на php5.3 просто невозможно найти этот самый php5.3 со всеми рюшечками. Софт не развивался и версий под новый php, старые репозитории давно выпилены.
В итоге нашел старый дистриб убунты 10, натянул на виртуалку — только так удалось запустить.
Да, есть такое. У меня крутится древний сайтик еще аж на 5.2 с кучей патчей и затычек, потому что на 5.3 что-то там не работало.
И попытки перенести сайт на другое место не удаются, как раз по описанной вами причине.
Конечно, можно потратить кучу времени и пофиксить проблему на уровне кода, или попытаться восстановить руками все затычки, но долго это, да и лень
И это проблема одного мелкого сайтика, а что будет на уровне корпорации…
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Никогда такого не было и вот опять!
Проблема в сознании высшего менеджмента. Вернее в тотальном и хроническом дилетантстве и вороватости высшего менеджмента. ИТ стали в сознании этого менеджмента чем-то типа слесарей и уборщиц. Компьютеры же ш как трубы и грязь — везде одинаковы. ИТ есть во всех компаниях, обязательны для использования, преимуществ перед другими компаниями (у которых тоже используются ИТ) нет никаких, деньги тратят, мнят о себе черт знает что, прикидываются умными и интеллигентными, игнорируют корпоративную иерархию почитания-поклонения, говорят на птичьем языке и о птичьих проблемах. Одним словом ИТ в сознании менеджмента — это генератор стабильных трат и убытков от которого надо избавиться при первой возможности.
А тут еще и какая-то ИТ безопасность. Совсем там они опупели! Про эту безопасность слышали все. Так достаточно выдать всем слесарям-ИТшникам команду: «Работать безопасно!» На вопрос, что под этим подразумевается — строго посмотреть в глаза такому выскочке-недотепе и раздраженно заявить о его токсичности. Все понимают, а он не понимает. На худой конец нанять приятного и послушного во всех отношениях перца и объявить его офицером по ИТ безопасности. И все как бы безопасно станет!
Так будет до тех пор пока как минимум 10% крупных компаний за 10 лет не будут банкротиться по причине громких инцидентов в ИТ безопасности. До чего пока далеко. Так что киберпреступникам есть куда расти.
Так достаточно выдать всем слесарям-ИТшникам команду: «Работать безопасно!»

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


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

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


Такие большие, а в сказки поверили. Если Emsisoft — бенифициары от использования инструментов расшифровки (а забесплатно они не работают), то 100% что они, как минимум, причастны к созданию всего этого ransomware.

Где-то в начале 90х мне пришлось писать дешифровщики для нескольких древних вирусов, я уже не помню что то за хрень была (почти 30 лет прошло) — они шифровали файлы (правда, только com/exe) весьма примитивным способом (банальный xor с фидбеком, ключём выступала начальная часть файла, если я помню правильно). Делал я это совсем не бесплатно, даже подумывал на этом (антивирусах) специализироваться, и только сейчас, после вашего комментария я понял какую возможность упустил… наверное, был бы уже олигархом.


PS: Это не вы случайно блестящую шапочку уронили?

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

А если сразу все файлы шифровать? Тогда шифровальщик не страшен.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости

Изменить настройки темы

Истории