Информационная безопасность IT

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

С чего начать: посчитать не пароли, а учётные записи

Первый вопрос, который стоит задать ИТ и ИБ: какие учётные записи вообще существуют в нашей инфраструктуре?

Обычно ответ оказывается сложнее, чем кажется. Есть Active Directory, корпоративная почта, VPN, серверы, сетевое оборудование, облачные сервисы, бизнес-приложения, базы данных, системы резервного копирования. Есть аккаунты подрядчиков. Есть старые тестовые учётные записи. Есть локальные администраторы. Есть сервисные аккаунты, про которые все помнят только тогда, когда после отключения они перестают запускать какой-нибудь важный процесс.

Поэтому я бы начал с обычной инвентаризации.

Для каждой учётной записи должно быть понятно:

• кто её использует;

• зачем она нужна;

• к каким системам имеет доступ;

• какие права у неё есть;

• кто отвечает за неё;

• когда в последний раз она использовалась.

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

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

Самая неприятная категория — привилегированные аккаунты

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

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

Количество таких аккаунтов тоже должно быть ограничено. Если права Domain Admin есть у двадцати человек просто «на всякий случай», то фактически компания имеет двадцать потенциальных точек компрометации.

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

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

Отдельный важный вопрос для проработки: “Можно ли обнаружить подозрительное использование привилегированной учётной записи?”.

Что делать с парольной политикой

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

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

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

А что со сменой пароля каждые 30 дней?

Автоматическая ротация через фиксированный короткий срок не всегда даёт тот эффект, которого от неё ждут.

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

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

Отдельная задача — не допускать использование известных паролей

Есть большая разница между «пароль соответствует нашей политике» и «пароль действительно не скомпрометирован».

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

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

Где сотрудники хранят все эти пароли?

Теперь представим сотрудника, у которого есть доступ к двадцати корпоративным системам и настоятельное ИБ-предписание «Используй уникальные сложные пароли и никогда их не повторяй».

Если у такого сотрудника нет правильного с точки зрения ИБ ответа на этот вопрос нет, парольная политика начинает работать против самой себя. В результате пароли появляются в браузерах, заметках, Excel-файлах, текстовых документах, мессенджерах и письмах. Именно поэтому ксистема хранения паролей — не просто удобный инструмент для сотрудников, а часть системы управления доступами.

Но здесь есть важный нюанс.

Администратор менеджера паролей не должен автоматически видеть все пароли

При выборе решения я бы обязательно задавал поставщику этот вопрос: Что произойдёт, если учётная запись администратора менеджера паролей будет скомпрометирована?

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

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

При выборе решения я бы отдельно проверял:

• кто технически может получить доступ к секретам;

• как устроено шифрование (лучше, чтобы оно было на стороне клиента);

• где и как хранятся ключи;

• может ли администратор расшифровать чужое хранилище;

• как организован аудит действий;

• можно ли разделить административные полномочия;

• что произойдёт при компрометации административной учётной записи;

• как восстанавливается доступ при потере учётной записи пользователя.

Это один из тех случаев, когда архитектура продукта важнее красивого списка функций.

Сервисные аккаунты: про них вспоминают последними

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

Через несколько лет никто уже не знает:

• кому он принадлежит;

• зачем он нужен;

• где используется;

• кто знает его пароль;

• что произойдёт, если его отключить.

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

Если технология позволяет использовать вместо постоянного пароля сертификаты, токены, managed identities или другие механизмы — это обычно стоит рассмотреть.

Особенно опасно хранить сервисные секреты непосредственно в исходном коде, скриптах и репозиториях.

MFA: начинать нужно не с самых удобных систем, а с самых опасных

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

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

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

Общие аккаунты — плохая идея не только с точки зрения безопасности

Представим, что пять системных администраторов используют одну учётную запись. В какой-то момент в журнале появляется: “14:32 — изменена конфигурация сервера”. Кто это сделал?

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

Жизненный цикл учётной записи важнее самой политики

Можно иметь прекрасную парольную политику и при этом оставить бывшему сотруднику доступ к VPN. Это довольно бессмысленная защита. Поэтому парольная безопасность должна быть связана с процессами HR и ИТ.

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

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

Что измерять директору по ИБ

Если эти показатели постепенно улучшаются, работа идёт в правильном направлении.

Что делать в ближайшие 30 дней

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

Сегодня

Настроить мониторинг важных параметров безопасности учетных данных, в том числе:

• доля критичных систем с MFA;

• количество привилегированных аккаунтов;

• количество неиспользуемых аккаунтов;

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

• количество секретов, найденных в открытом виде;

• время от увольнения сотрудника до полного отзыва доступа;

• количество обнаруженных скомпрометированных корпоративных учётных данных.

Первая неделя

Провести инвентаризацию учётных записей и привилегий. Особое внимание — администраторам, VPN, удалённому доступу, резервному копированию и сервисным аккаунтам. Удалить или заблокировать очевидно ненужные аккаунты.

Вторая неделя

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

Третья неделя

Пересмотреть парольную политику. Выбрать подход к централизованному хранению секретов. Определить требования к корпоративному менеджеру паролей (в этой статье есть несколько стоящих рекомендаций) и запустить процесс выбора. Отдельно проверить модель защиты от доступа администратора к пользовательским секретам.

Четвёртая неделя

Перевести критичные учётные записи на новые правила. Запустить ротацию наиболее важных административных и сервисных секретов. Определиться с решениями по управлению паролями и секретами.

В итоге

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

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

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

И только в этой системе требования к длине пароля становятся одной из деталей, а не всей парольной безопасностью компании.

В мире хакеров, как бы это странно ни звучало, довольно мало пересечений между отдельными личностями. Из примеров, возможно, стоит вспомнить только банду Xbox Underground, но там случай исключительный.

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

Читайте в цикле также:

• От мирового признания до трагедии: две истории, две стороны киберпреступности

• Два юных хакера: один взламывал из любопытства, другой — ради денег

• Особенности английской киберпреступности. Две истории о талантливых хакерах

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

  Кубинец из Флориды и компьютер за 3000 в 12 лет

Альберто родился в 1981 году в семье кубинских иммигрантов. Его родители, Пабло и Мария Гонсалес, бежали с Кубы в поисках лучшей жизни и обосновались в Майами, штат Флорида. Семья жила скромно, но старалась поддерживать увлечения сына. Первый ПК появился у парня в 1989 году, семья копила на него несколько месяцев. Это был подарок мальчику на день рождения. Родители верили, что если в раннем возрасте Альберто начнет увлекаться новой и дорогой технологией, тем более светлым будет его будущее.

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

В школе, кстати, у него была кличка Соуп («Да что у тебя за имя-то такое дурацкое, Соуп?») за довольно типичную для своего времени внешность: он был высокий, худой и носил длинные спутанные волосы. А еще уже в школе Гонсалес нашел первые пути для заработка денег на свои увлечения. Данные тут немного расходятся в деталях, но есть один факт: в 12 лет Альберто купил домой компьютер за три тысячи долларов, что для его семьи деньги, откровенно говоря, немалые.

Первая версия гласит, что Альберт работал вместе с отцом и копил деньги (Пабло Гонсалес основал небольшой бизнес в сфере ландшафтного дизайна и ухода за садами, а в Америку приплыл на плоту), другая же опирается на непроверенные факты, мол, Гонсалес подворовывал комплектующие и торговал ими. В пользу первой говорят в том числе будущие судебные материалы и статьи в The New York Times и Rolling Stone.

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

❯ К 14 годам это превратилось в одержимость. Первые преступления Альберто Гонсалеса

По злой иронии, первое, что случилось с его компьютером — он словил вирус. Это побудило Гонсалеса развернуть свой интерес в сторону кибербезопасности и ее обхода.

Собственно, под эгидой этого интереса и была собрана команда единомышленников в старшей школе, в составе которой Альберто и пошел на первое преступление.

Взлом локальной сети South Miami High School, совершенный Альберто Гонсалесом в конце 1990-х годов, стал его первым «демонстративным» преступлением. В те годы школы только начинали массово проводить интернет и объединять компьютеры в локальные сети. О кибербезопасности никто не думал — пароли часто были стандартными, а права доступа настроены некорректно. Альберт, используя свой домашний ПК и ноутбук, начал сканировать школьную сеть. На его ПК стоял сниффер. С его помощью он смог поймать логины и пароли школьных администраторов и учителей.

Через слитые пароли Гонсалес залил на сервер школы бэкдор, с помощью которого он мог удаленно управлять компьютерами на территории школы. И нет, он не поправил себе оценки, он довел до истерики весь педагогический состав. Работа South Miami High School была полностью парализована. Учителя не могли получить доступ к планам уроков и базам данных, администрация осталась без связи, а все компьютерные классы отключились от сети. На восстановление системы ушло несколько дней.

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

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

❯ Новая двойная жизнь в Нью-Йорке

В 2000 году, в возрасте 19 лет, Альберто Гонсалес покидает родительский дом в Майами и переезжает в Нью-Йорк, и начинает жизнь в бедном районе Квинса.

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

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

Именно в эти времена во всем мире расцветала индустрия краденных кредитных карт и персональных данных. Альберто прикинул, что его навыки вполне могут пригодиться в этой сфере, и начал деятельность под ником Souvenirs («Сувениры»). Выбор ника был циничным: он планировал «коллекционировать сувениры» — чужие личные данные и банковские карты как сувениры.

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

К 2002 году Гонсалес понял, что разрозненные IRC-чаты хакеров неудобны, хаотичны и полны мошенников, которые обманывают друг друга. Ему пришла в голову идея создать единую, безопасную и жестко структурированную платформу для киберпреступников со всего мира.

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

К 2003 году на сайте (который, очевидно, находился в даркнете) было зарегистрировано более 4000 постоянных участников. На площадке ежедневно продавались сотни тысяч украденных номеров карт, поддельные удостоверения личности и инструкции по взлому. Сам Альберто Гонсалес из нищего парня с матрасом на полу превратился в подпольного миллионера, который управлял международной криминальной сетью, не выходя из своей комнаты в Квинсе.

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

Альберто Гонсалес уже тогда отличался холодным расчетом и не сильно ценил любую жизнь, кроме своей. Он сам предложил сделку. Агенты Секретной службы были ошеломлены, когда поняли, кто именно попался им на копеечном обналичивании. Перед ними сидел главный администратор ShadowCrew — человек, который знал в лицо и по никнеймам верхушку всего мирового кардинга. В итоге сделка выглядела так: силовики закрывают глаза на его прошлые заслуги, дают ему полный иммунитет и оклад в 75 тысяч долларов, а он взамен, когда нужно, сдает нужных людей, подстраивает операции и помогает закрывать планы по кибербезопасности, вместе с этим он обязан делиться всеми наработками по взлому для его предотвращения.

Так Альберто Гонсалес стал кротом в собственноручно построенной криминальной империи. Он помогал агентам Секретной службы внедряться на форум, передавал им IP-адреса, реальные имена, переписку и банковские реквизиты топ-менеджеров ShadowCrew. По его наводке спецслужбы создали подставной сервер, через который пустили трафик участников форума, что позволило перехватывать все их сообщения. Результатом такой деятельности стал арест как минимум 28 человек из команды, а впоследствии и полное уничтожение организации изнутри. Сам Гонсалес вышел чистым и за счет своего статуса на него так никто и не подумал. Все, кто с ним работал над ShadowCrew, сели на очень долго.

Пресса трубила о величайшей победе над киберпреступностью, а Альберт Гонсалес стал главным «золотым мальчиком» Секретной службы. Руководство верило, что он полностью исправился. Однако они даже не подозревали, что, сдавая мелких подельников из ShadowCrew, Гонсалес уже создавал новую, гораздо более законспирированную международную ОПГ, чтобы провернуть величайшую кражу в истории человечества.

❯ Доверие стало роковой ошибкой властей

В 2004 году Альберто Гонсалес стал одним из главных аутсорс-экспертов по кибербезопасности у властей. Его перевезли в Майами, силовики оплачивали ему шикарную квартиру, и сам Альберто прилежно каждый день ходил в офис ради вполне себе настоящей работы на службе у властей.

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

Теперь они воровали у корпораций и торговых сетей. Свою преступную деятельность Гонсалес, как указывалось в судебных материалах, называл Operation Get Rich or Die Tryin'. В эту банду вошли лучшие специалисты, которых он смог найти: в США его правой рукой стал гениальный программист Кристофер Скотт, а техническое ядро команды составили высококлассные хакеры, в том числе из СНГ и РФ. Среди них был тот самый Максим Ястремский, о деятельности которого говорили на нашем телевидении в те годы.

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

Гонсалес разработал идеальную тактику: если правоохранительные органы замечали подозрительную активность на каком-то направлении, Альберто, будучи внутри системы Секретной службы, тут же узнавал об этом и предупреждал своих подельников, заставляя их залечь на дно или сменить серверы.

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

Схема состояла из двух шагов: сначала Госалес и Скотт садились в максимально неприметные автомобили с ноутбуками и мощными Wi-Fi репитерами и катались по парковкам крупных ТЦ в Майами. Там они подключались через защищенные сети, сканировали роутеры в зданиях на предмет уязвимостей и, если находили хоть один намек, пробивались во внутреннюю сеть либо здания, либо непосредственно сети, которой оно принадлежит.

Дальше в дело вступала схема, корни которой Гонсалес использовал еще в школе — SQL-инъекции и снифферы. Через брешь в защите запускали бэкдор, а через него ставили сниффер пакетов — вредоносную программу, которая перехватывала данные банковских карт (номер, срок действия и CVV-код) прямо в момент, когда покупатель расплачивался на кассе. Украденные массивы данных автоматически утекали на арендованные Гонсалесом серверы в Латвии, СНГ и Нидерландах. Оттуда базы данных продавались огромными партиями на черном рынке.

Но на фоне работы по сети TJX (крупная сеть международных брендов в сегменте off-price) и компании Heartland Payment Systems (крупная американская финансово-технологическая компания и процессинговый центр, которая занимается обработкой платежей и предоставлением бизнес-решений) всё описанное выше — это мелкие кражи.

TJX не особо задумывались о безопасности, ведь группировка Гонсалеса незаметно контролировала серверы этой огромной розничной сети почти два года. Они похитили данные более 45 миллионов карт. А с Heartland Payment Systems всё ещё хуже — кража произошла в 2007, а раскрыта была только в 2009. За это время было стянуто колоссальное количество данных и принесены гигантские убытки.

Как они влезли в практически кровеносную систему американского эквайринга? Хакеры обнаружили, что на одном из публичных веб-сайтов Heartland использовалась устаревшая форма авторизации (страница входа в систему), программный код которой был написан еще за 8 лет до этого и ни разу не обновлялся. Из-за отсутствия фильтрации входящих данных Гонсалес и его сообщники смогли ввести специальную команду прямо в поле ввода логина/пароля. Веб-скрипт «обманул» внутреннюю базу данных и выполнил стороннюю команду хакеров, предоставив им первичный доступ к корпоративной сети. Сразу скачивать ничего не стали, чтобы не вызывать подозрений, первый массив данных выкачали только через 8 месяцев.

Данные забирались таким же образом, как и в случае с кражей напрямую из торговых центров. В момент, когда покупатель в каком-нибудь магазине США прокатывал карту через терминал, данные в зашифрованном виде шли в Heartland. Но внутри самого процессора для авторизации платежа эти данные на долю секунды расшифровывались. Сниффер Гонсалеса перехватывал эту информацию прямо «в полете» — в транзитном, несжатом и незашифрованном виде.

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

Финальный объем составил более 130 миллионов уникальных банковских карт. Компания Heartland Payment Systems буквально чудом смогла избежала полной смерти и понесла убытки на более чем 200 миллионов долларов и выплатила гигантские штрафы.

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

❯ Силовики увидели знакомые никнеймы

Собственно, долго это продолжаться не могло, и Секретная служба серьёзно взялась за расследование дела TJX и Heartland Payment Systems. Разгадка гигантской схемы началась далеко от США. Агенты Секретной службы отслеживали, куда именно уходят украденные миллионы номеров банковских карт с серверов розничных гигантов вроде TJX. Они выяснили, что основные оптовые партии дампов перепродаются через теневые площадки.

Первым нашли, как ни странно, Максима Ястремского. Спецслужбы смогли идентифицировать и взять под контроль несколько серверов в Европе (в частности, в Нидерландах и Латвии), которые банда Гонсалеса и Ястремский использовали для обмена данными. Там, спустя небольшой ресерч, смогли выйти на почту и ICQ последнего.

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

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

Финалом истории буквально штурм одного из лучших номеров элитного отеля National Hotel в Майами-Бич. Гонсалеса уложили лицом в пол до того, как он успел хотя бы дотянуться до своих компьютеров. При нем, помимо техники, был заряженный пистолет. Альберто буквально всегда был при оружии.

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

Из них он отсидел 15 и вышел в 2023 году. Снизили срок по гигантской совокупности факторов: от хорошего поведения до диагностированного синдрома Аспергера. Про то, чем занимается сейчас, ничего не известно. Социальных сетей нет, интервью не дает, за домом до сих пор периодически следит полиция. Но он жив, и с ним в принципе всё неплохо. Чего явно нельзя сказать о тех, кто пострадал от рук его преступной организации.

Такая вот история. Всем спасибо!

Самое неприятное обнаружилось при проверке реальной опасности. Хелме создал поддельный сертификат для платёжного API api.stripe.com и поднял тестовый сервер на собственном компьютере. Утилита curl успешно проверила сертификат, Python установил защищённое соединение, а Node.js подтвердил подлинность сервера. Аналогичные результаты исследователь получил на протестированных системах Linux и macOS.

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

Причина катастрофической слабости ключей оказалась удивительно простой. eMudhra использовала криптографический алгоритм на эллиптической кривой P-384, где закрытый ключ должен быть случайным числом размером около 384 бит. Вместо полноценного случайного значения система создала ключи, содержавшие всего один ненулевой байт. Для восстановления каждого секрета достаточно проверить не более 255 вариантов.

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

Все восемь слабых ключей появились 30 апреля 2025 года. Каждый использовался в двух промежуточных сертификатах, один подписала сама eMudhra, второй в мае 2025 года дополнительно подписала Sectigo. Таким образом, существовало 16 сертификатов с восемью одинаково уязвимыми ключевыми парами. Возможность восстановить закрытые ключи сохранялась около 17 месяцев, причём злоумышленникам не требовалось проникать в инфраструктуру удостоверяющего центра.

Первые защитные меры приняли 17 октября 2026 года после обращения исследователя, обнаружившего проблему. Google заблокировала опасные ключи в Chrome через механизм CRLSet, а Mozilla распространила блокировку через OneCRL. Пользователям с обычными настройками не понадобилось даже перезапускать браузеры. Аналогичную защиту для Android Google начала распространять через сервисы Google Play 19 октября.

Дополнительным барьером стала система Certificate Transparency, которая требует публично регистрировать сертификаты сайтов. Google не обнаружила в журналах ни одного TLS-сертификата, выпущенного шестью проблемными центрами до их блокировки. Поэтому поддельные сертификаты не могли пройти стандартную проверку Chrome, требующую подтверждения регистрации. Однако далеко не все программы используют такой механизм.

Основной риск теперь связан с приложениями, которые проверяют сертификаты иначе, чем современные браузеры. Серверные API, автоматические установщики программ, системы непрерывной сборки и развёртывания CI/CD, облачные инструменты и пакетные менеджеры часто полагаются на локальное хранилище доверия. Многие клиенты по умолчанию не проверяют отзыв сертификатов и не требуют регистрации в публичных журналах. Поэтому формально отозванный сертификат всё ещё может пройти проверку.

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

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

Mozilla 20 октября выпустила Firefox 158.0.1 и обновления веток ESR 115.43.1 и 153.5.1. Дополнительно разработчики подготовили NSS 3.131.1 с удалением доверия к корневому сертификату emSign ECC Root CA - G3. Google также решила исключить соответствующий корневой сертификат из Chrome Root Store. Массовое распространение такого изменения запланировано на 27 октября. Владельцам сайтов, использующим затронутую корневую цепочку, потребуется заменить сертификаты, иначе соединения могут перестать работать.

Cloudflare проверила собственную инфраструктуру и не обнаружила признаков эксплуатации проблемы в своих сервисах. Компания обновила клиенты WARP и Cloudflare Tunnel, а также внедрила дополнительные ограничения в CDN и сервисах Zero Trust. Администраторам рекомендуют обновлять системные наборы сертификатов, библиотеки проверки TLS и контейнерные образы. Проверять необходимо именно приложения, поскольку исправленный браузер не гарантирует безопасность остальных программ на компьютере.

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

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

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

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

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

https://www.securitylab.ru/news/579028.php

https://xakep.ru/2026/10/21/emudhra-certs/

https://www.opennet.ru/opennews/art.shtml?num=66515

Дыры нашли независимо сразу три команды. Исследователи Calif использовали GPT-5.6 Sol в рамках программы OpenAI Patch the Planet, компания Wiz – Gemini 4 Argon и тот же GPT-5.6 Sol, третьей была команда OpenAI Codex Security. По словам Wiz, один исследователь с ИИ за неделю сделал то, на что раньше у целой команды ушли бы месяцы. Глава Wiz Ами Луттвак назвал находку самой серьезной уязвимостью, когда-либо найденной с помощью ИИ.

Первое сообщение разработчики PHP получили 11 августа. Дальше два месяца шла тихая подготовка: OpenAI собрала коалицию из Google, Microsoft, AWS, Cloudflare и других компаний, подключила американские госструктуры – агентство кибербезопасности CISA и даже "Силы по сверхинтеллекту" при Белом доме. Публичное раскрытие назначили на 22 октября.

20 октября на Hacker News появился пост, который сорвал этот план: две критические дыры в PHP, 10 баллов из 10, раскрытие 22-го. Технических деталей не было, автор сам признал, что доказательств у него нет, кроме "поверьте мне". Но исследователи из watchTowr подтвердили, что утечка настоящая. Разработчики PHP сдвинули выпуск исправлений на 21 октября, а утром того же дня, около 10:30 по Москве, хостинги и Cloudflare зафиксировали первые атаки – больше чем за шесть часов до выхода патча.

Исправленные версии вышли днем 21 октября: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для PHP 8.1 и старше официальных исправлений нет, а на таких версиях работает примерно каждый пятый сайт на WordPress и почти каждый четвертый на Joomla. Специалисты Sansec ждали массовых атак уже через 15 минут после выхода патча: по исправлению легко понять, где именно была дыра.

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

Вы бы пустили такого робота-латальщика на свой сервер?

P.S. О том, что нейросети уже находят в коде раньше людей, я пишу в канале "сбежавшая нейросеть".

Хорст Фейстель родился в Берлине 30 января 1915 года. В 1934 году транзитом через Швейцарию он эмигрировал в США (не стал ждать повестки в военкомат, в Германии всеобщая воинская повинность была официально введена в 1935 году) где получил степень бакалавра по физике в MIT, а затем магистра в Гарварде.

Во время Второй мировой войны Фейстель, как уроженец Германии, находился под домашним арестом. Американское гражданство он получил только 31 января 1944 года. Уже на следующий день ему дали допуск к работе и он приступил к работе в Air Force Cambridge Research Center — над системами радиолокационного опознавания «свой-чужой».

После войны были лаборатория Линкольна при MIT, MITRE, а в 1968 году — исследовательский центр IBM в Йорктаун-Хайтс. Именно там Фейстель занялся криптографией и вместе с коллегами начал разрабатывать Lucifer.

Что вообще такое «сеть Фейстеля»

Если убрать формулы — идея почти неприлично простая для того, что защищало банковские и государственные данные полвека.

Блок данных режется пополам — на левую L и правую R части. Дальше несколько раундов подряд повторяется одно и то же:

1. Правая половина R проходит через функцию F вместе с ключом раунда. F может быть сколь угодно сложной и даже необратимой — и это нормально.

2. Результат складывается с левой половиной L по модулю 2 — то есть выполняется операция XOR.

3. Половины меняются местами, и всё повторяется заново.

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

Именно поэтому внутрь F можно засунуть довольно сложную начинку — например, нелинейные S-блоки — не боясь, что шифр станет невозможно расшифровать.

Вехи создания

У Lucifer было несколько версий, и Фейстель с коллегами постепенно усложняли конструкцию. Начиналось всё с 48-битного блока и 48-битного ключа, затем появились варианты с другими параметрами. В одной из версий Джона Л. Смита использовались 64-битный ключ и 32-битный блок.

А затем появился Lucifer с 128-битным блоком и 128-битным ключом, построенный уже на сети Фейстеля. Именно эта версия особенно важна для нашей истории: из неё выросла конструкция, которая в итоге привела IBM к DES (созвучно с death, они что там, не крещенные? Так по загробному миру фанатеть...).

То, ради чего вообще статья затевалась

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

Шаг 2 - собственно фиксируем байт, с которым будем работать далее, тут не очень интересно, показывать нечего, жмём Далее

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

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

Сделка с дьяволом: могло ли АНБ оставить в DES бэкдор?

Ну что, с сетью Фейстеля разобрались и даже немного поиграли. Теперь вернёмся к Lucifer — потому что именно здесь начинается самая интересная часть истории.

В 1973 году американское Национальное бюро стандартов (NBS, ныне NIST) объявило конкурс на единый стандарт шифрования для гражданских ведомств. IBM предложила доработанный Lucifer. Работу над ним возглавили Уолтер Тачмен и Карл Мейер.

И тут в историю вошло АНБ.

АНБ узнало, что Уолтер Тачмен из IBM работает над новой версией Lucifer. Агентство оформило ему допуск к секретной информации (в переводе с бусурманского - к гос. тайне) и подключилось к совместной работе над шифром.

Дальше возник вопрос, который до сих пор делает историю DES такой интересной:

а нельзя ли встроить в шифр секретный вход для тех, кто знает, где его искать?

Бэкдор, которого никто не должен увидеть

На первый взгляд идея кажется вполне реалистичной.

Если ты участвуешь в разработке стандарта, можешь влиять не только на длину ключа, но и на саму конструкцию алгоритма. А в DES особенно подозрительно выглядели S-блоки — таблицы, которые превращают входные данные в выходные и добавляют шифру нелинейность.

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

Отсюда и подозрение: а вдруг внутри S-блоков спрятана математическая лазейка?

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

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

А вот ключ действительно укоротили

Зато здесь никаких теорий заговора не требуется.

В процессе стандартизации АНБ настояло на сокращении длины ключа. Обсуждались разные варианты, а в итоге остановились на 56 битах.

При этом АНБ участвовало и в разработке S-блоков.

Получилась странная комбинация: одну часть защиты сделали слабее, а другую — загадочным образом изменили в закрытом режиме.

В 1977 году DES стал федеральным стандартом США — FIPS PUB 46.

И почти сразу появились вопросы.

«56 бит? Вы серьёзно?»

В том же году Уитфилд Диффи и Мартин Хеллман опубликовали статью с недвусмысленным названием — Exhaustive Cryptanalysis of the NBS Data Encryption Standard.

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

Оставался вопрос: что именно АНБ сделало с S-блоками?

В 1978 году специальный комитет Сената США расследовал участие АНБ в создании DES. Скрытой математической «двери» в алгоритме не обнаружили. Но выяснилось, что АНБ действительно убедило IBM согласиться на сокращённый ключ и участвовало в разработке S-блоков. То есть подозрения имели под собой почву. Просто доказательств бэкдора не нашли. И на этом историю можно было бы закончить. Но тогда мы не получили бы главный твист.

Тайна, которую скрывали почти 20 лет

В 1990 году Эли Бихам и Ади Шамир опубликовали метод дифференциального криптоанализа — мощный способ атаковать блочные шифры. И тут выяснилось кое-что странное.

DES оказался очень хорошо защищён от этой атаки.

В 1994 году Дон Копперсмит, один из разработчиков DES в IBM, раскрыл причину: IBM знала о дифференциальном криптоанализе ещё с 1974 года — задолго до того, как о нём узнал открытый научный мир. Более того, устойчивость к этой атаке была одним из критериев при проектировании S-блоков и перестановки DES.

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

И вот здесь появляется настоящий вопрос.

Откуда IBM знала об этой атаке в 1974 году?

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

Но парадокс остаётся:

АНБ действительно вмешалось в разработку DES.
АНБ действительно добилось более короткого ключа.
АНБ действительно участвовало в разработке S-блоков.
Но доказательств, что оно оставило бэкдор, нет.

А спустя двадцать лет выяснилось, что S-блоки были спроектированы гораздо умнее, чем могла знать публика.

Диффи и Хеллман всё-таки оказались правы

Оставалась другая проблема — 56-битный ключ. В 1998 году Electronic Frontier Foundation построила специализированную машину Deep Crack менее чем за $250 000.

Она перебирала ключи DES со скоростью около 88 миллиардов ключей в секунду и нашла нужный ключ за 56 часов.

Год спустя EFF вместе с distributed.net сделали это уже за 22 часа 15 минут.

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

DES было пора на пенсию. Lucifer умер да здавствует... Кхе, кхе

Но сеть Фейстеля никуда не делась

Да, DES устарел, а идея Фейстеля — нет.

На сети Фейстеля или её модификациях построены Blowfish, Twofish, Camellia, KASUMI и другие шифры. Похожие конструкции используются и в форматно-сохраняющем шифровании.

А по другую сторону железного занавеса существовала своя история.

В СССР был создан ГОСТ 28147-89 — блочный шифр с 64-битным блоком, 256-битным ключом и 32 раундами, тоже на сети Фейстеля. Его разработка проходила в закрытой системе советской криптографии, поэтому подробности долго оставались недоступными. Сегодня обновленная версия этого алгоритма в российском стандарте ГОСТ Р 34.12-2015 известен как «Магма».

В 2001 году NIST утвердил новый стандарт — AES. Он уже не использовал сеть Фейстеля, а был построен на другой архитектуре — подстановочно-перестановочной сети, но это уже совсем другая история.

Lucifer умер. DES тоже.

А идея одного немецкого гражданина, эмигрировавшего в США, продолжает жить.

И всё началось с довольно простой мысли: разделить блок пополам, немного покрутить одну половину, смешать её с другой — и повторить.

И в заключении хотелось бы сказать: "Помните алгоритмы шифрования - это всё здорово, но самое главное, берегите себя и своих близких".

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

Звучит сложно? На самом деле всё проще. У одного нашего героя синдром Аспергера, у второго — аутизм, а оба они по-своему гении.

Читайте также:

• От мирового признания до трагедии: две истории, две стороны киберпреступности

• Два юных хакера: один взламывал из любопытства, другой — ради денег

Мальчик, который напугал всех в ЦРУ

Всё, как обычно, идет из детства. Кейн Гэмбл рос в относительно небольшом, но очень унылом за счет своей серости городе Лестер, Англия. В принципе, семья обычная — пара британских работяг с одного из местных заводов (которых в Лестере действительно МНОГО), и одной маленькой светлой точкой в биографии. Мать парня выиграла в лотерею 1997 года довольно много денег — 1,7 миллиона фунтов стерлингов. Деньги были вложены в бизнес, который прогорел и стал причиной не самой здоровой обстановки в семье на годы вперед.

И, казалось бы, в такой среде мог вырасти кто угодно из представителей классической английской уличной преступности (простите мне мою субъективность), но нет, Кейн Гэмбл видел мир не так, как другие парни из не самых благополучных семей. У мальчика было диагностировано расстройство аутистического спектра, что вкупе с не раз упомянутыми обстоятельствами сильно влияло на мировоззрение Кейна. Он видел мир без серой морали, с четким и очень своеобразным делением на добро и зло. А еще он с раннего подросткового возраста увлекался политикой и ненавидел гос. аппарат США за коррумпированность и, это цитата, «расчётливость».

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

В интернете Кейн Гэмбл называл себя Cracka, а всю свою деятельность в кооперации с D3f4ult помечал как работу группировки C.W.A. (на сленговом языке чернокожих Cracka означает «белый»), что переводится на русский как «Белые с мнением», отсылка на культовый коллектив N.W.A. Идея их группировки была не в деньгах, а в желании как можно сильнее опозорить первых лиц американских спецслужб, и чем публичнее лицо, тем лучше.

Так под их прицел и попал Джон Бреннан, директор ЦРУ на момент описываемых событий. Кейн Гэмбл взломал его почту, аккаунты в мессенджере AOL, а также личный кабинет сотового оператора Verizon. Через цепочку слитых документов нашелся в том числе личный мобильный номер, который завалили сначала просто спам-звонками, а потом и откровенными угрозами вперемешку с отборным (насколько позволяет бедный на это дело английский язык) матом.

Позже через почту найдется доступ к домашней экосистеме Бреннана, где были подключены все устройства его семьи, и уже на них стали приходить угрозы и спам. Разумеется, рядом с этим пошла утечка внутренних рабочих писем с конфиденциальными данными, в том числе и о военных операциях разных временных периодов. Кейн Гэмбл, кстати, не стеснялся делиться в социальных сетях фактом, что у него есть эти данные, ага. Он позже признается, что делал всё это под веществами и не хотел навредить, ему было просто весело кошмарить не просто случайного человека, а директора ЦРУ.

Джон Бреннан, кстати, в ходе этих событий несколько раз менял место жительства, жил под круглосуточным наблюдением вооруженной охраны, и в целом в структуре начался жуткий переполох. Только вот факт — C.W.A., несмотря на угрозы, практически не слили в сеть ничего важного, они просто несколько недель кошмарили человека и его семью, чтобы показать, что неприкасаемых людей не существует.

А потом им надоело, и они перестали это делать. Но история на этом не кончилась. В целом отследить звонки и прочую деятельность было изначально трудно... если бы не пьяный D3f4ult, который случайно проговорился другу, что имеет отношение к развирусившейся истории о взломе директора ЦРУ. За свой длинный язык он получит пять лет тюрьмы и по возвращению вольется в легализованные криптотусовки, да начнет ходить по различным подкастам. Собственно, основываясь на выпуске подкаста Darkest Diaries с ним, и написана большая часть этого текста.

Кейн Гэмбл, естественно, тоже был быстро найден, потому что D3f4ult раскололся. Суд Англии учел диагноз и возраст, поэтому парню дали всего 2 года колонии для несовершеннолетних. По выходу он пропал с радаров и, по слухам, до сих пор работает где-то в сфере информационной безопасности.

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

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

Спусковым крючком стала кража. Пришел с деньгами, ушел без, полиция развела руками, и дело в ход не пошло. Зато в отместку пошли на дно около сотни сайтов образовательных учреждений по всей Америке. Адам положил их методом банального DDoS в рамках тестирования своего небольшого проекта под названием... Titanium Stresser.

Адам Мадд разрабатывал программу несколько лет в полном одиночестве и секретности от всех. Если говорить простыми словами, Titanium Stresser — это оружие массового поражения, программа, которая за счет умной DDoS-атаки способна класть на лопатки буквально любой ресурс вне зависимости от объема его защиты. Titanium за счет переброса трафика и пустых запросов в гигантском количестве создавал просто адскую нагрузку на сервера, которую никто не мог выдержать.

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

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

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

Но, как это обычно бывает, всё сломал один длинный язык нахального школьника. Есть такая идейная группировка борцов с корпорациями под названием Lizard Squad, их особенно не любят геймеры даже в нашей стране, ведь раньше они частенько по причинам «потому что можем» ложили сервера Sony и Microsoft. Да, угадайте, с помощью какого софта они это делали.

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

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

Мораль такова: цените свои навыки, развивайте и направляйте в правильное русло. А еще никакая болезнь таланту не помеха. Хорошего дня!