Индийская мстя

masterok.livejournal.com — Бывший сотрудник ИТ-консалтинговой компании Дипаншу Кхер (Deepanshu Kher) решил отомстить за свое увольнение удалением аккаунтов сотрудников одной из компании-клиента, расположенной в Карлсбаде (Калифорния, США) в сервисе Microsoft 365. Текст в первом.
Новости, Разное | Сова 04:24 01.04.2021
65 комментариев | 54 за, 0 против |
Сова
надзор »
#1 | 04:24 01.04.2021 | Кому: Всем
Вот по этому ссориться с it-шниками не желательно. Или например с 1С-программистами, у нас все ваши серые базы данных :-) Вот вам поучительные истории из Индии.

Бывший сотрудник ИТ-консалтинговой компании Дипаншу Кхер (Deepanshu Kher) решил отомстить за свое увольнение удалением аккаунтов сотрудников одной из компании-клиента, расположенной в Карлсбаде (Калифорния, США) в сервисе Microsoft 365. На нем, согласно обвинительному заключению окружным судом Калифорнии, были завязаны все основные бизнес-процессы, и диверсия Кхера остановила работу компании более чем на два дня.


Названия обеих компаний в документах суда не раскрываются.Кхер удалил 1200 аккаунтов из 1500 имеющихся. Пользователи потеряли доступ к документам, календарям встреч, корпоративным каталогам, видео- и аудиоконференциям, а также к контактам – они не могли связаться с клиентами, а те в свою очередь не имели возможности выяснить, что происходит, и почему сотрудники этой компании вдруг резко перестали выходить на связь.Согласно судебным документам, Дипаншу Кхер, гражданин Индии, работал на ИТ-консалтинговую компанию в период с 2017 г. по май 2018 г.

В 2017 г. компания из Карлсбада обратилась за консалтинговыми услугами в эту фирму – ей нужна была помощь в переводе сотрудников на Microsoft 365. Выполнить эту работу руководство поручило Кхеру, но Carlsbad Company осталась недовольна им, и в январе 2018 г. Кхера отстранили от проекта. 4 мая 2018 г. Кхер был уволен, а в июне 2018 г. он вернулся в Дели (Индия), затаив обиду на компанию из Карлсбада.

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


Последствия взлома

Атакованная Кхером компания частично восстановила работу лишь спустя двое суток после взлома. Тем не менее, на тот момент удалось вернуть не все данные, и сотрудники по-прежнему испытывали немало трудностей с получением доступа к необходимым им корпоративным материалам. На полное восстановление потребовалось три месяца и почти $600 тыс., и под конец вице-президент компании по вопросам ИТ заявил: «За свои 30 с лишним лет работы в сфере ИТ я никогда не попадал в более трудную рабочую ситуацию».

На арест Дипаншу Кхера был выдан ордер, и его смогли задержать 11 января 2021 г., когда он вылетал из Индии в США. Расследование вело ФБР, и Кхер до последнего не знал, что американским властям удалось получить разрешение на его арест.

Вынося приговор, судья окружного суда США Мэрилин Хафф (Marilyn Huff) отметила, что Кхер совершил серьезное и изощренное нападение на компанию, нападение, которое было спланировано и явно было местью. Хафф приговорила его к двум годам тюремного заключения, трем годам под надзором полиции (после освобождения) и штрафу в размере около $567,1 тыс. (43,05 млн руб. по курсу ЦБ на 24 марта 2021 г.) – в эту сумму пострадавшей компании обошлись мероприятия по устранению последствий хакерской атаки Кхера.





ИТ-диверсии индусов в тренде

Месть при помощи информационных технологий за несправедливое (по мнению уволенных) лишение работы в XXI веке стала весьма распространенным явлением. Одним из ярких примеров является ситуация, в которой оказалась компания Cisco.

В конце сентября 2018 г. экс-сотрудник Cisco Судхиш Касаба Рамеш (Sudhish Kasaba Ramesh) с индийскими корнями в отместку за увольнение взломал облако компании в Amazon WebServices и запустил туда некий код, который хранился в его аккаунте Google Cloud Project. Это привело к удалению 456 виртуальных машин, на которых функционировали приложения Cisco WebEx Teams, что в итоге привело к исчезновению аккаунтов в WebEx Teams вместе со всем содержимым.

Cisco потратила две недели на восстановление удаленных данных. Ущерб от действий Рамеша она оценила в $2,4 млн – $1 млн компания потратила на компенсации пострадавшим клиентам, а оставшиеся $1,4 млн пошли на оплату труда ее специалистов, помогавших восстанавливать данные.

В июле 2020 г. Рамеш признал себя виновным в содеянном. Как сообщал CNews, в середине декабря 2020 г. его приговорили двум годам тюрьмы, полутора годам под надзором полиции и $15 тыс. штрафа.

В марте 2018 г. стало извесно о похожем случае в Санкт-Петербурге. Сотрудник туристической фирмы из северной столицы после своего увольнения уничтожил базу данных собственной компании. В ней хранилась информация, необходимая для доступа сотрудников турфирмы в офис. Мотивом к уничтожению данных послужил конфликт злоумышленника с руководителем ИТ-отдела, а сам инцидент произошел 14 февраля 2017 г. Для уничтожения базы данных он использовал свой ПК, откуда имелся доступ к серверу компании, где хранилась база. Против него было заведено уголовное дело, расследованием которого занялось ГУ МВД России по Санкт-Петербургу и Ленобласти. Хакеру грозило до четырех лет лишения свободы.

В апреле 2017 г. в США завели уголовное дело против Нимеша Пателя (Nimesh Patel), который в течение 14 лет работал системным администратором в компании Allegro MicroSystems. Ему пришлось уйти из компании, и он решил отомстить бывшему работодателю путем заражения вирусом базы данных его бухгалтерии на СУБД Oracle.

В сентябре 2016 г. системный администратор Джо Вито Вензор (Joe Vito Venzor), уволенный из компании по производству обуви Lucchese Bootmaker, в отместку обрушил ее сервер. Он также удалил файлы, необходимые для его восстановления. Производство ковбойских сапог Lucchese Bootmaker, существующее с 1883 г., простаивало, пока сторонний подрядчик не починил сервер, и компании пришлось потратить две недели, чтобы полностью восстановить производство и наверстать упущенные заказы.

Если работодатель недостаточно платит своим сотрудникам, то он тоже рискует стать жертвой ИТ-мести. На себе это испытал в 2002 г. банк UBS Paine Webber. Когда «логическая бомба» удалила все файлы на главном сервере его центральной базы данных и двух тысячах серверов в 400 филиалах, при этом отключив систему резервного копирования. Виновником случившегося оказался системный администратор банка – он получил вдвое меньшую премию по итогам года, что и заставило его отомстить работодателю.
#2 | 04:42 01.04.2021 | Кому: Всем
Сидел бы в своей Индии и в ус не дул.
#3 | 04:43 01.04.2021 | Кому: Всем
А Трампа выбрать не смог - лошара.
#4 | 04:53 01.04.2021 | Кому: Всем
> Дипаншу Кхер

Хорошая фамилия!
#5 | 05:06 01.04.2021 | Кому: Всем
[ Пишет: "индусов не нанимать, они мстительные долбоёбы" ]
[censored]
#6 | 05:13 01.04.2021 | Кому: глюкер
> Хорошая фамилия!

Злостный Хер!!!
#7 | 05:15 01.04.2021 | Кому: Всем
Пока читал - аж сердце кровью обливается! До чего же трудно буржуям всего мира с таким народишком! Только соберёшься с них прибыль получить - а они страшный экстремизм творят, да в такие убытки вводят - хоть последнюю яхту продавай! Ну, хорошо, хоть, власть и суды за них, а то совсем бы хана.
#8 | 06:03 01.04.2021 | Кому: Всем
Если мне с кем-то память не изменяет, то K перед H не читается, ну, по правилам наглицкой мовы, так что он не Кхер, а именно что Хер.

И очень злостный!!!
#9 | 06:08 01.04.2021 | Кому: Всем
> трем годам под надзором полиции (после освобождения)

он гражданин другого государства - его выпускать из страны 3 года не собираются?!
#10 | 06:13 01.04.2021 | Кому: глюкер
> > Дипаншу Кхер
>
> Хорошая фамилия!

[censored]
#11 | 06:15 01.04.2021 | Кому: Всем
Удалил кхерам.
#12 | 06:28 01.04.2021 | Кому: Всем
очень интересно, как они этого типа смогли найти, что это именно он сделал.
а потом еще и на суде присяжных доказать, что это именно он сделал.
#13 | 06:40 01.04.2021 | Кому: Сова
> удалил 1200 аккаунтов из 1500 имеющихся.

Дурачок. Вот если бы рандомно перемешал, чтоб потом годами глюки выскакивали то тут, то там...

>когда он вылетал из Индии в США


Клинический дурачок.
#14 | 06:56 01.04.2021 | Кому: Всем
Пффф, два года. А еще как-то в РФ программист в прошивку фискальных регистраторов заложил таймбомбу. Ущерб никто не считал. Кстати, где он?
#15 | 06:59 01.04.2021 | Кому: Всем
> трудно буржуям всего мира с таким народишком
В Индии капитализм в полный рост.
Эксплуатация в таких IT сервис и ресурс конторах (это аутсорс для буржуев, достаточно дорогой, и не всегда сейчас он дешевле местного неиндийского, как было много лет) индусами-манагерами своих же индусов-подчиненных достигает 146 и более процентов. Там некого в индийском IT жалеть.
#16 | 07:09 01.04.2021 | Кому: Всем
> В апреле 2017 г. в США завели уголовное дело против Нимеша Пателя (Nimesh Patel), который в течение 14 лет работал системным администратором в компании Allegro MicroSystems. Ему пришлось уйти из компании, и он решил отомстить бывшему работодателю путем заражения вирусом базы данных его бухгалтерии на СУБД Oracle.

Базу!!! Оракл!!! Вирусом!!!

[убегает ставить антивирусы на свои оракловые базы]
spitfire
надзор »
#17 | 07:15 01.04.2021 | Кому: Strider
> Базу!!! Оракл!!! Вирусом!!!

DROP TABLE *;
#18 | 07:22 01.04.2021 | Кому: Сова
> Deepanshu Kher

Опять какой-то хер виноват!!!
#19 | 07:24 01.04.2021 | Кому: spitfire
> DROP TABLE *;

Оракл не любит дураков и саботажников, он так не позволит. DROP DATABASE тогда уж.
#20 | 07:28 01.04.2021 | Кому: poruchik
> Пффф, два года.

Скорее всего досудебная сделка.
#21 | 07:41 01.04.2021 | Кому: TPEHEP
> Опять какой-то хер виноват!!!

- Что случилось с нашей сетью?
- А хер его знает!
- И где же этот хер, который знает?
#22 | 07:43 01.04.2021 | Кому: spitfire
> DROP TABLE *;

А ты, хакер!
#23 | 08:10 01.04.2021 | Кому: Giatsynt
> > удалил 1200 аккаунтов из 1500 имеющихся.
>
> Дурачок. Вот если бы рандомно перемешал, чтоб потом годами глюки выскакивали то тут, то там...

Гораздо веселее нагенерить нцать мульёнов фейковых веков и тщательно перемешать с реальными..
#24 | 08:37 01.04.2021 | Кому: Strider
> Базу!!! Оракл!!! Вирусом!!!
>
> [убегает ставить антивирусы на свои оракловые базы]

Читал однажды статью про вирусы-шифраторы, с полезными советами. Там файл "readme.txt" в каждой папке, в котором написано: "Переведите деньги на вот этот-вот биткойн-кошелёк", называли телом вируса и рекомендовали срочно удалить.
#25 | 08:58 01.04.2021 | Кому: Strider
не силен в ИТ, а что здесь не так?
#26 | 09:05 01.04.2021 | Кому: честный
> не силен в ИТ, а что здесь не так?

База данных - это упорядоченная совокупность данных, она хранится в файлах базы. Но эти файлы - не исполняемые. Вирус же может существовать в системе как сам по себе, так и встраиваться в другие файлы ("заражать" их), но для работы его код обязательно должен быть запущен. Испортить файлы данных - без проблем, заразить исполняемые файлы СУБД - без проблем, а вот "заразить базу вирусом" - никак невозможно. Поэтому смешно.
#27 | 09:24 01.04.2021 | Кому: Strider
А как же триггеры на события в наиболее часто используемой таблице? Не совсем вирус, наверное. С ораклом не сталкивался, но в ms sql криво написанный триггер может и базу положить. Другое дело, что можно относительно быстро вычислить источник проблемы.
#28 | 09:27 01.04.2021 | Кому: Strider
> База данных - это упорядоченная совокупность данных, она хранится в файлах базы. Но эти файлы - не исполняемые. Вирус же может существовать в системе как сам по себе, так и встраиваться в другие файлы ("заражать" их), но для работы его код обязательно должен быть запущен. Испортить файлы данных - без проблем, заразить исполняемые файлы СУБД - без проблем, а вот "заразить базу вирусом" - никак невозможно. Поэтому смешно.
>

а как на счет хранимых процедур и внешних библиотек из них вызываемых?
CREATE LIBRARY ...
#29 | 09:37 01.04.2021 | Кому: Mayor
> А как же триггеры на события в наиболее часто используемой таблице? Не совсем вирус, наверное.

Не то, что "не совсем вирус", а "совсем не вирус".

> С ораклом не сталкивался, но в ms sql криво написанный триггер может и базу положить.


И в оракле может.

> Другое дело, что можно относительно быстро вычислить источник проблемы.


Совершенно верно. С точки зрения СУБД это пользовательский объект, и спрятать его от SYS (ораклового SA) никак не получится.
#30 | 09:39 01.04.2021 | Кому: tarasz
> а как на счет хранимых процедур и внешних библиотек из них вызываемых?

Есть такое. Но это тоже не вирусы.
#31 | 09:43 01.04.2021 | Кому: Strider
Но вопить будут про вирус! Так дороже в устранении последствий и ответственность виновному больше.
#32 | 09:52 01.04.2021 | Кому: Mayor
> Но вопить будут про вирус! Так дороже в устранении последствий и ответственность виновному больше.

Топ-менеджеры и изнасилованные вирусами журналисты вовсе не обязаны разбираться в подобных технических нюансах!!!
#33 | 10:25 01.04.2021 | Кому: Всем
[censored]
#34 | 10:52 01.04.2021 | Кому: Strider
> а вот "заразить базу вирусом" - никак невозможно.

а когда эти самые базы под шифровальщик попадают.
это не значит что база заражена?
#35 | 10:59 01.04.2021 | Кому: честный
> а когда эти самые базы под шифровальщик попадают.
> это не значит что база заражена?

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

Кстати, нормальные современные базы данных типа Oracle или MS SQL строго бдят за своей внутренней целостностью, и при малейшей модификации файлов данных (физической или логической) в обход СУБД безжалостно эти файлы помечают как испорченные. Вплоть даже до отказа стартовать и открываться.
#36 | 11:18 01.04.2021 | Кому: Strider
спасибо за разъяснения.
#37 | 11:29 01.04.2021 | Кому: честный
> спасибо за разъяснения.

Да не за что, был рад помочь разобраться.

Для дополнительного понимания просто прими как факт, что абсолютное большинство современных вредоносных программ, называемых в обиходе "вирусами", в каноническом смысле вирусами вовсе не является. Черви, трояны, шифровальщики - но не вирусы. Механизмы распространения и вредоносные проявления - схожи, устройство и принципы работы - нет.
#38 | 11:32 01.04.2021 | Кому: Strider
> Для дополнительного понимания просто прими как факт, что абсолютное большинство современных вредоносных программ, называемых в обиходе "вирусами", в каноническом смысле вирусами вовсе не является. Черви, трояны, шифровальщики - но не вирусы.

ну это я знаю))
#39 | 11:34 01.04.2021 | Кому: Mayor
> криво написанный триггер может и базу положить

Класть базу не надо и удалять не надо. Надо тихонько рандомно менять старые данные, чтоб прошло несколько месяцев до обнаружения. Накопится большое количество бекапов, которые будут битыми и восстановление актуальных данных станет очень вазелиновым.
#40 | 11:38 01.04.2021 | Кому: Strider
> Кстати, нормальные современные базы данных типа Oracle или MS SQL строго бдят за своей внутренней целостностью, и при малейшей модификации файлов данных (физической или логической) в обход СУБД безжалостно эти файлы помечают как испорченные. Вплоть даже до отказа стартовать и открываться.

Надо портить/менять данные нежно и месяцами, чтоб бекапы были все битые.
Оно все будет целое но совершенно не пригодное для работы.
#41 | 11:50 01.04.2021 | Кому: Швейк
> Надо портить/менять данные нежно и месяцами, чтоб бекапы были все битые.
> Оно все будет целое но совершенно не пригодное для работы.

С ораклом точно не проканает, там целостность блоков на лету отслеживается, и при работе, и при бэкапе. Вот бэкапы сами можно попытаться испортить, это да, если админ лох или неопытный.
#42 | 11:55 01.04.2021 | Кому: Всем
Хорошо, что лет 5 назад учил sql - теперь даже понимаю, о чëм люди говорят.
#43 | 12:09 01.04.2021 | Кому: Strider
> С ораклом точно не проканает, там целостность блоков на лету отслеживается

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

А бекапы сами нахуярятся, они через пару месяцев уже обычно не все хранятся.
Псфп5
#44 | 12:22 01.04.2021 | Кому: Швейк
> Так он целый будет. Просто все числовые показатели немножко другие станут, но так чтоб итог сохранился прежний))

Ты про сами данные, что ли, говоришь? Просто для меня, например, "битый бэкап" - это битый на блочном уровне или неконсистентный.
#45 | 12:24 01.04.2021 | Кому: Всем
> это битый на блочном уровне или неконсистентный.

Ну он будет совершенно не битый и совершенно бесполезный, особенно через полгодика
#46 | 14:31 01.04.2021 | Кому: Сова
> Вот по этому ссориться с it-шниками не желательно. Или например с 1С-программистами, у нас все ваши серые базы данных :-) Вот

и тут же рассказывает историю про it-шника, которого нагнули раком на 43 миллиона рубасов и выписали два года тюрячки

ну а так-то не желательно, да
#47 | 20:20 01.04.2021 | Кому: Strider
> Базу!!! Оракл!!! Вирусом!!!

Скрипт вполне себе можно накатать в теории и сделать компонентом БД.
Чем не вирус?

Внешнюю dll можно.
Чем не вирус?

Сильно фантазируя в теории, если есть специфическая бизнес-логика с багом, то можно так задать данные в БД, что работая на них, логика будет их множить и плодить в сущности по заранее заданному совокупностью данных алгоритму.
Тоже вирус.
#48 | 20:34 01.04.2021 | Кому: Strider
> База данных - это упорядоченная совокупность данных, она хранится в файлах базы.

Не ведь не только лишь обязательно данных.
Ведь так?

> Вирус же может существовать в системе как сам по себе, так и встраиваться в другие файлы ("заражать" их), но для работы его код обязательно должен быть запущен.


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

> а вот "заразить базу вирусом" - никак невозможно.


Можно.

И потому что файлы базы содержат зачастую исполняемые скрипты.

И потому что внешняя библиотека может быть внедрена в БД (тут дискуссионно).

И потому что вирус может быть просто данными, которые на определенном уровне абстракции можно рассматривать как информацию об алгоритме.
#49 | 20:37 01.04.2021 | Кому: Mayor
> А как же триггеры на события в наиболее часто используемой таблице? Не совсем вирус, наверное. С ораклом не сталкивался, но в ms sql криво написанный триггер может и базу положить.

И не только они.

Любые скрипты, живущие как компонент базы.
#50 | 20:39 01.04.2021 | Кому: Strider
> > А как же триггеры на события в наиболее часто используемой таблице? Не совсем вирус, наверное.

> Не то, что "не совсем вирус", а "совсем не вирус".


Почему?

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