RSA заменит токены SecurID всем пострадавшим компаниям

RSA заменит токены SecurID всем пострадавшим компаниям

Два с половиной месяца спустя компания RSA, признав факт утечки информации, предложила заменить токены SecurID пострадавшим клиентам, среди которых оказался  крупный подрядчик Министерства обороны США компания Lockheed Martin.

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

В марте директор компании RSA Арт Ковьелло убедил своих клиентов и всю общественность в том, что извлеченная информация из базы данных компании не достаточна для взлома. Однако, череда атак против крупных заказчиков производителя доказала обратное.

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

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

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

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

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

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

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

RSS: Новости на портале Anti-Malware.ru