Новости мира информационной безопасности. Расследование и реагирование на инциденты. Кибербезопасность.

Новости информационной безопасности




Сотрудник опубликовал закрытый AWS-ключ компании на GitHub

В сентябре американская компания DXC Technologies пострадала из-за невнимательности одного из своих сотрудников. Член проектной группы опубликовал код проекта в публичном репозитории GitHub, не заметив, что в коде зашит закрытый ключ AWS. Об инциденте стало известно из внутреннего документа, который попал в руки репортеров из The Register.

Ключи AWS обеспечивают пользователям доступ к облачным хранилищам на Amazon, и в данном случае сотрудник открыл «корзины» DXC Technologies для любого посетителя GitHub. Этой «щедростью» воспользовались неизвестные злоумышленники, которые за четыре дня настроили на ресурсах компании 244 виртуальные машины (причем большинство из них — в течение суток после инцидента), причинив ущерб на $64 000.

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

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

Инциденты, связанные с Amazon, регулярно появляются в новостях. Тем не менее, чаще всего причиной утечек и компрометации, как и в случае с DXC Technologies, становятся сами пользователи. Конфиденциальные данные из корзин появляются в открытом доступе из-за ошибок в конфигурации. Например, разработчик ПО и сервисов Broadsoft слил в открытый доступ конфиденциальные данные сети Time Warner Cable (TWC), включая базы данных SQL, фрагменты кода, журналы доступа, адреса и телефоны пользователей, а также некоторые данные 4 млн клиентов телекомпании за последние 7 лет.

В сентябре компания Election Systems & Software (ES&S), поставщик систем голосования и управления выборами, скомпрометировала данные всех избирателей округа Чикаго из-за неправильной конфигурации «корзин» S3. В результате утекли около 1,8 млн учетных записей, включающих имя, адрес, дату рождения, часть номера социального страхования, а в отдельных случаях также номер водительского удостоверения и государственный идентификационный номер.

Amazon предпринимает усилия, чтобы минимизировать риски утечек из-за человеческого фактора. В начале ноября компания представила пять обновлений Amazon S3, в том числе заметный желтый индикатор Public в консоли управления. Он будет сообщать администратору сервера, если какая-либо из «корзин» открыта для публичного доступа. Это сократит время обнаружения ошибки конфигурирования и позволит избежать утечек, насколько это возможно. Также администратор сможет легко определить, какой из элементов политики доступа (ACL, Bucket Policy или оба) «виновен» в том, что данные оказались в публичном доступе.

Дата: 2017-11-16 17:28:13

Источник: https://threatpost.ru/dxc-technologies-aws-key-goes-public-on-github/23255/



Поиск багов помогает хакерам легализовать свою деятельность

Собственное исследование платформы Bugcrowd показало, что за прошлый год число white-hat специалистов выросло почти в полтора раза. Корпоративные заказчики обращаются к профессионалам ИБ, чтобы найти бреши в своих системах, возвращая хакеров в рамки законодательства.

В последние годы деньги за обнаруженные бреши можно было получить у Microsoft, Facebook, Tesla и прочих технологических гигантов. В России подобными проектами известен Павел Дуров — еще в 2013 году он пообещал $200 000 тому, кто сможет прочитать его зашифрованную переписку в Telegram. Как правило, вознаграждение оказывается гораздо меньше: в Tesla за уязвимость платят до $10 000, в Dropbox — чуть меньше $5000, в Facebook установлен фиксированный тариф по $500 за баг. В настоящее время программы bug bounty есть у крупных организаций вроде Mail.Ru Group и «Лаборатории Касперского», и компаний поменьше — например, у оператора электронных платежей «Центральная касса».

«Белый» хакер может получить деньги напрямую от компании или через посредническую платформу. Одна из крупнейших подобных площадок Bugcrowd объединяет более 22 тысяч специалистов, которые получили свыше 2 млн долларов за уязвимости в продуктах Microsoft, Western Union, Tumblr, MasterCard, Pinterest. Это вовсе не рекорд — на площадке HackerOne пользователи заработали уже более 17 миллионов долларов. Деньги поступили от Uber, Yahoo, Starbucks, Adobe, уже упомянутых «Лаборатории Касперского» и Mail.Ru Group.

Для white-hat-взломщиков подобные сервисы — это один из немногих легальных источников заработка. Письмо с просьбой заплатить за информацию об уязвимости может привести в суд — подобные действия слишком похожи на шантаж. Кроме того, бизнес неохотно идет на письменные гарантии, и инициативный хакер может остаться ни с чем. Сама по себе практика оплаты подобных услуг появилась не так давно. Долгое время считалось само собой разумеющимся, что добросовестный ИБ-специалист довольствуется гипотетическим вкладом в борьбу против киберпреступников. Только в 2009 году на канадской конференции CanSecWest эксперты Алекс Сотиров (Alex Sotirov), Дино Дай Зови (Dino Dai Zovi) и Чарли Миллер (Charlie Miller) запустили движение No More Free Bugs («Больше никаких бесплатных багов»), призвав коллег требовать оплату за свой труд. По словам Дай Зови, на решение во многом повлияла беззащитность «белого хакера» перед законом, равно как и тот факт, что прибыль от устранения бреши значительно превосходит самые смелые запросы ИБ-специалиста.

С развитием электронных сервисов программы bug bounty запускают и организации вне высокотехнологичного сектора. По словам исполнительного директора HackerOne Мартена Микоса (Marten Mickos), в 2016 году 41% проектов пришелся на медиа, индустрию развлечений, финансовые услуги, электронную коммерцию, государственные организации. Так, программа Министерства обороны США Hack the Pentagon объединяет сразу несколько инициатив, направленных на безопасность нескольких родов войск. На призыв ведомства откликнулись хакеры из более чем 50 стран, включая Россию, Индию, Австралию, Великобританию и другие. Они обнаружили в информационных системах три тысячи лазеек, в том числе для SQL-инъекций, удаленного выполнения кода, обхода систем аутентификации и прочих атак.

Другой примечательный пример: известный портал PornHub заплатил хакерам $20 000 за уязвимость, которая позволяла загружать произвольный код. Награду получил Руслан Хабалов, инженер информационной безопасности, который работает в швейцарском офисе Google. Руслан относится к самой большой демографической группе среди white-hat специалистов. Из отчета Bugcrowd следует, что 60% участников платформы работают в ИБ менее трех лет, а 15% респондентов отнесли себя к студентам. Основатель Bugcrowd Кейси Эллис (Casey Ellis) отмечает, что в индустрии практикуется меритократия — результаты работы говорят больше, чем строчки резюме. Большинство молодых хакеров считают отлов уязвимостей временным занятием, которое не принесет серьезные деньги.

Это справедливо и для отечественных специалистов, которые стабильно занимают первые места на white-hat соревнованиях, оправдывая распространенное представление о «русских хакерах». В прошлом году группа студентов и молодых ИБ-специалистов из Москвы и Санкт-Петербурга вошла в тройку сильнейших в мире на соревновании CTFtime — эта международная организация организует мероприятия в области информационной безопасности по всему миру. Россияне опередили более 12 тыс. команд, уступив только коллегам из Украины и Польши.

В большинстве случаев хакеры работают в одиночку. Так, Андрей Леонов, который в ноябре 2016 года получил от Facebook рекордные $40 000, говорит, что занимается багхантингом в свободное время. При этом на Bugcrowd Андрей входит в топ-100 исследователей. Награду от Facebook он заслужил, когда заметил, что функция «поделиться новостью» берет заглавное изображение со сторонних серверов без проверки. Это позволяет внедрить в пост зловредный скрипт. По классификации международного консорциума безопасности OWASP подобная уязвимость имеет самый высокий рейтинг.

Награда в $40 000 — редкость для white-hat хакеров, не говоря уже о российских специалистах. Низкая оплата труда наряду с возможностью обмена опытом с зарубежными коллегами заставляет отечественных ИТ-экспертов смотреть в сторону западных фирм, которые высоко оценивают советскую математическую школу. Однако российский бизнес активно конкурирует с ними — к примеру, «Лаборатория Касперского» стала одной из первых ИБ-компаний, запустившей свое представительство на HackerOne.

Дата: 2017-11-16 16:45:26

Источник: https://threatpost.ru/white-hat-hackers-collective-portrait-2/23254/



ROC - Infineon RSA Vulnerability

roca_impact.png

This tool is related to ACM CCS 2017 conference paper #124 Return of the Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli.

It enables you to test public RSA keys for a presence of the described vulnerability.

Update: The paper of the attack is already online, ACM version.

Currently the tool supports the following key formats:

The detection tool is intentionally one-file implementation for easy integration / manipulation.

Pip install
Install with pip (installs all dependencies)
pip install roca-detect

Local install
Execute in the root folder of the package:
pip install --upgrade --find-links=. .

Dependencies
It may be required to install additional dependencies so pip can install e.g. cryptography package.
CentOS / RHEL:
sudo yum install python-devel python-pip gcc gcc-c++ make automake autoreconf libtool openssl-devel libffi-devel dialog
Ubuntu:
sudo apt-get install python-pip python-dev build-essential libssl-dev libffi-dev swig

Usage
To print the basic usage:
# If installed with pip / manually
roca-detect --help

# Without installation (can miss dependencies)
python roca/detect.py
The testing tool accepts multiple file names / directories as the input argument. It returns the report showing how many files has been fingerprinted (and which are those).
Example (no vulnerabilities found):
Running recursively on all my SSH keys and known_hosts:

$> roca-detect ~/.ssh
2017-10-16 13:39:21 [51272] INFO ### SUMMARY ####################
2017-10-16 13:39:21 [51272] INFO Records tested: 92
2017-10-16 13:39:21 [51272] INFO .. PEM certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. DER certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. RSA key files: . 16
2017-10-16 13:39:21 [51272] INFO .. PGP master keys: 0
2017-10-16 13:39:21 [51272] INFO .. PGP total keys:  0
2017-10-16 13:39:21 [51272] INFO .. SSH keys:  . . . 76
2017-10-16 13:39:21 [51272] INFO .. APK keys:  . . . 0
2017-10-16 13:39:21 [51272] INFO .. JSON keys: . . . 0
2017-10-16 13:39:21 [51272] INFO .. LDIFF certs: . . 0
2017-10-16 13:39:21 [51272] INFO .. JKS certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. PKCS7: . . . . . 0
2017-10-16 13:39:21 [51272] INFO No fingerprinted keys found (OK)
2017-10-16 13:39:21 [51272] INFO ################################
Example (vulnerabilities found):
Running recursively on all my SSH keys and known_hosts:

$> roca-detect ~/.ssh
2017-10-16 13:39:21 [51272] WARNING Fingerprint found in the Certificate
...
2017-10-16 13:39:21 [51272] INFO ### SUMMARY ####################
2017-10-16 13:39:21 [51272] INFO Records tested: 92
2017-10-16 13:39:21 [51272] INFO .. PEM certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. DER certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. RSA key files: . 16
2017-10-16 13:39:21 [51272] INFO .. PGP master keys: 0
2017-10-16 13:39:21 [51272] INFO .. PGP total keys:  0
2017-10-16 13:39:21 [51272] INFO .. SSH keys:  . . . 76
2017-10-16 13:39:21 [51272] INFO .. APK keys:  . . . 0
2017-10-16 13:39:21 [51272] INFO .. JSON keys: . . . 0
2017-10-16 13:39:21 [51272] INFO .. LDIFF certs: . . 0
2017-10-16 13:39:21 [51272] INFO .. JKS certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. PKCS7: . . . . . 0
2017-10-16 13:39:21 [51272] INFO Fingerprinted keys found: 1
2017-10-16 13:39:21 [51272] INFO WARNING: Potential vulnerability
2017-10-16 13:39:21 [51272] INFO ################################

PGP key
In order to test your PGP key you can export it from your email client or download it from the PGP key server such as https://pgp.mit.edu/
You can also use gpg command line utility to export your public key:
gpg --armor --export your@email.com > mykey.asc

Advanced use case
Detection tool extracts information about the key which can be displayed:
roca-detect.py --dump --flatten --indent  ~/.ssh/

Advanced installation methods

Virtual environment
It is usually recommended to create a new python virtual environment for the project:

virtualenv ~/pyenv
source ~/pyenv/bin/activate
pip install --upgrade pip
pip install --upgrade --find-links=. .

Separate Python 2.7.13
We tested tool with Python 2.7.13 and it works (see Travis for more info). We have reports saying lower versions (
Use pyenv to install a new Python version locally if you cannot / don't want to update system Python.
It internally downloads Python sources and installs it to ~/.pyenv.
git clone https://github.com/pyenv/pyenv.git ~/.pyenv
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
exec $SHELL
pyenv install 2.7.13
pyenv local 2.7.13

Python 3
Basic testing routine is quite simple and works with Py3 but the rest of the code that processes the different key formats and extracts the modulus for inspection is not yet fully py3 ready.
We are working on Py3 compatible version.

Docker container
Run via Docker container to avoid environment inconsistency. Dockerfile source can be audited at https://hub.docker.com/r/unnawut/roca-detect/.

docker run --rm -v /path/to/your/keys:/keys --network none unnawut/roca-detect
Make sure to use --rm and --network none flags to disable container's network connection and delete the container after running.

Дата: 2017-11-16 13:13:00

Источник: http://www.kitploit.com/2017/11/roc-infineon-rsa-vulnerability.html



Эксперты пролили свет на бизнес по разблокировке и продаже украденных iPhone

Специалисты Trend Micro опубликовали исследование, посвященное прибыльному бизнесу разблокировки и перепродажи похищенных iPhone.

Мобильные гаджеты представляют интерес для злоумышленников по всему миру не только с точки зрения стоимости собственно устройства, но и потенциальной возможности доступа к персональным данным их владельцев. Многие производители предлагают различные приложения и сервисы, позволяющие отследить устройство и удалить с него данные в случае хищения или утери гаджета. Например, владельцы iPhone с помощью функции Find my iPhone («Найти iPhone») могут отследить местоположение смартфона, удаленно заблокировать экран или превратить гаджет в «кирпич». Тем не менее, далеко не все пользователи используют данную функцию. В результате украденный iPhone попадает на черный рынок. Специалисты компании Trend Micro опубликовали исследование, посвященное прибыльному бизнесу разблокировки и перепродажи украденных iPhone. 

В мае 2016 года команда Trend Micro обнаружила бизнес-схему, в рамках которой преступники предлагали инструменты для взлома учетных записей iCloud и разблокировки iPhone. Для обхода блокировки активации Find My iPhone и получения доступа к конфиденциальным данным пользователей в iCloud, злоумышленники обратились к методам интернет-мошенничества, делая ставку на желание владельца вернуть смартфон.

Преступники отправляли жертве электронное письмо или SMS-сообщение якобы от Apple с уведомлением о том, что устройство найдено. Движимые желанием вернуть гаджет, пользователи переходили по указанной ссылке и вводили свои учетные данные для аккаунта в iCloud. Эта информация затем использовалась злоумышленниками для взлома учетной записи и разблокировки iPhone.

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

Преступники использовали ряд инструментов, в том числе MagicApp, Applekit и Find My iPhone (FMI.php) – фреймворк, имитирующий легитимный сервис Apple. Разработчики этого программного обеспечения предлагают свои услуги в соцсетях и на собственных сайтах, а также сдают в аренду серверы для фишинговых рассылок.

FMI.php предоставляет возможности для фишинговой атаки, Applekit создает сеть из похищенных устройств, а MagicApp автоматизирует разблокировку iPhone. После разблокировки смартфона ПО может использоваться злоумышленниками для отправки фишинговых сообщений и подмены GPS-координат украденных устройств. Применение данных инструментов позволяет злоумышленникам отключить все сервисы Apple, удалить всю информацию, связанную с бывшим владельцем гаджета, и подготовить его для продажи.

Дата: 2017-11-16 12:40:28

Источник: http://www.securitylab.ru/news/489751.php



В Сети появился бесплатный сервис для определения периметра web-приложений

Сервис позволяет быстро выявить полный перечень используемых поддоменов, API, web- и мобильных приложений.

В Сети появился новый бесплатный сервис, ориентированный на обеспечение безопасности web-приложений. ImmuniWeb Discovery от компании High-Tech Bridge позволяет выявить полный перечень используемых поддоменов, API, web- и мобильных приложений, распространяемых или связанных с тестируемым доменным именем.

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

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

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

Дата: 2017-11-16 12:10:00

Источник: http://www.securitylab.ru/news/489750.php



Администрация Красноярска обезопасит себя от прослушки

На приобретение средств защиты информации будет выделено 225,3 тыс. руб.

Городская администрация Красноярска намерена усилить свою информационную защиту. С этой целью 1 ноября текущего года на официальном сайте администрации был объявлен тендер на покупку средств защиты данных.

На усиление ИБ из городского бюджета планируется выделить 225,3 тыс. руб. Речь идет о приобретении устройств для обеспечения безопасности телефонов на линиях с цифровой информацией, технических средств защиты речевой акустической информации (генератора-аудиоизлучателя и генератора-виброизлучателя), блока питания и управления для системы защиты речевой информации. Создаваемый ими шум будет препятствовать прослушиванию разговоров, уверено руководство города.

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

На аукцион была подана всего одна заявка, поэтому победителем тендера стала подавшая ее компания «ЦБС».

Дата: 2017-11-16 11:45:46

Источник: http://www.securitylab.ru/news/489748.php



Форум PHDays 8: покажем цифровую изнанку

Восьмой форум Positive Hack Days пройдет 15 и 16 мая 2018 года.

Друзья, объявляем даты восьмого форума Positive Hack Days — он состоится 15 и 16 мая 2018 года. Место встречи, как и прежде, московский Центр международной торговли. Подготовка к событию уже началась: организаторы готовят много сюрпризов, проектируют игровой полигон The Standoff, тестируют новое оборудование и продумывают детали программы. Вот уже восьмой год мы упрямо гнем свою линию и стараемся сделать мероприятие с характером, и этот год не исключение: главная тема PHDays 8 — «Цифровая изнанка».

Мы на пороге больших перемен. Государство сделало ставку на «цифру», и теперь телемедицина, цифровые госуслуги, дистанционное управление транспортной и промышленной инфраструктурой, умные устройства и криптовалюта — это не далекое завтра, а осязаемое сегодня. И уже в ближайшем будущем новые технологии сулят людям качественное улучшение жизни. Но пока весь мир охвачен идеей цифровой трансформации, хакеры решают — кто станет жертвами этого процесса, а кто получит от него выгоду…

Что ждет нас, если данные окончательно станут главной ценностью? Есть ли шанс защититься в мире, где жизнь полностью построена вокруг технологий, а грань между реальным и виртуальным размыта? К чему готовиться в эпоху повсеместной цифровизации: к новому миру или цифровому армагеддону? Комментирует Борис Симис, заместитель генерального директора по развитию бизнеса Positive Technologies:

«Сегодня мы живем в такое время, когда жизнь миллиардов людей невозможна без подключения к сети, а объем информации растет колоссальными темпами. В таких условиях переход на цифровую экономику нужно рассматривать как естественный этап развития государства. Несмотря на перспективы этого направления, нужно понимать, что цифровизация предприятий, отдельных отраслей и в целом экономики несет за собой риски информационной безопасности. На PHDays мы продемонстрируем возможные проблемы информационной безопасности, с которыми придется столкнуться государству, бизнесу и частным лицам вследствие перехода на "цифру". Мы хотим, чтобы все осознали реальную опасность цифровой изнанки, которая скрывается за маркетинговым глянцем».

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

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

Формат кибербитвы между атакующими и защитниками уже успел полюбиться аудитории. В этом году организаторы обещают удивить всех посетителей форума. Каким же будет The Standoff версии 3.0?

Конфликт атакующих и защитников выходит на новый уровень. Битва развернется в городе, вся экономика которого основывается на блокчейн-технологиях. Городская инфраструктура включает в себя ТЭЦ и подстанцию, железную дорогу, «умные» дома с рекуперацией энергии, банки с банкоматами и киосками самообслуживания. Ну и конечно, в нем работают различные онлайн-сервисы, сотовая связь и интернет. Планами грядущего The Standoff делится член оргкомитета PHDays Михаил Помзов:

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

Пока счет у команд — 1:1. Каким в итоге получится главный конкурс форума и кто выйдет вперед — узнаем в мае.

***

До конца весны еще целых полгода, поэтому, чтобы скоротать время, можно посмотреть видео лучших докладов  с PHDays VII. Совсем скоро откроются первая волна приема заявок на доклады и продажа билетов. Следите за новостями!

 

Дата: 2017-11-16 11:37:18

Источник: http://www.securitylab.ru/news/489746.php



Предполагаемый оператор BTC-E назвал свой арест провокацией спецслужб США

Александр Винник не понимает, почему американские власти не прислали ордер на его арест в Россию.  

По мнению гражданина РФ Александра Винника, арестованного в Греции по запросу властей США, его арест является провокацией и был произведен в рамках проводимой американскими спецслужбами операции.

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

«Ордер на мой арест выдан в Америке с января. Почему они не прислали его в Россию? Я ни от кого не скрываюсь. А ловить здесь, по Европе, – это чтобы легче было вывезти человека в Америку. Мой арест – по сути, американская спецоперация», – заявил Винник журналистам издание «РИА Новости».

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

Дата: 2017-11-16 10:57:50

Источник: http://www.securitylab.ru/news/489749.php



ЦБ РФ внесет связанные с ИБ поправки в кодекс корпоративного управления

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

Центробанк РФ приступил к работе над изменениями в кодекс корпоративного управления, связанными с вопросами развития информационных технологий и кибербезопасности. Об этом сообщила директор департамента корпоративных отношений ЦБ РФ Елена Курицына в рамках выступления на круглом столе ОЭСР-Россия по корпоративному управлению.

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

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

«Настало время чтобы в российском кодексе корпоративного управления нашли свое отражение вопросы управления IT-технологиями и кибербезопасностью на должном уровне. Мы полагаем, что должна быть закреплена стратегическая роль совета директоров в том, чтобы организовывать систему управления рисками, связанными с развитием IT-технологий и вопросами кибербезопасности. Совет директоров должен такую политику утверждать, также как и по всем остальным направлениям контролировать менеджмент. Совет директоров должен обладать необходимыми компетенциями, чтобы его состав отвечал тем вызовам, которые перед компанией стоят на определенном этапе времени», — сказала Елена Курицына.

Согласно данным опроса, проведенного регулятором среди российских компаний, 73% респондентов считают вопросы кибербезопасности весьма актуальной темой, 68% опрошенных отметили, что уже приняли внутренние документы, определяющие принципы работы IT и обеспечения кибербезопасности. Порядка у половины респондентов в состав совета директоров избран директор, владеющий необходимыми компетенциями и навыками в сфере информационных технологий и кибербезопасности. За последние три года у трети компаний на заседаниях совета директоров ежегодно рассматривались вопросы, связанные с развитием IT или обеспечения кибербезопасности, рассказала госпожа Курицына. 

Дата: 2017-11-16 10:24:40

Источник: http://www.securitylab.ru/news/489747.php



Investigation Report for the September 2014 Equation malware detection incident in the US

no-image

Background

In early October, a story was published by the Wall Street Journal alleging Kaspersky Lab software was used to siphon classified data from an NSA employee’s home computer system. Given that Kaspersky Lab has been at the forefront of fighting cyberespionage and cybercriminal activities on the Internet for over 20 years now, these allegations were treated very seriously. To assist any independent investigators and all the people who have been asking us questions whether those allegations were true, we decided to conduct an internal investigation to attempt to answer a few questions we had related to the article and some others that followed it:

  1. Was our software used outside of its intended functionality to pull classified information from a person’s computer?
  2. When did this incident occur?
  3. Who was this person?
  4. Was there actually classified information found on the system inadvertently?
  5. If classified information was pulled back, what happened to said data after? Was it handled appropriately?
  6. Why was the data pulled back in the first place? Is the evidence this information was passed on to “Russian Hackers” or Russian intelligence?
  7. What types of files were gathered from the supposed system?
  8. Do we have any indication the user was subsequently “hacked” by Russian hackers and data exfiltrated?
  9. Could Kaspersky Lab products be secretly used to intentionally siphon sensitive data unrelated to malware from customers’ computers?
  10. Assuming cyberspies were able to see the screens of our analysts, what could they find on it and how could that be interpreted?

Answering these questions with factual information would allow us to provide reasonable materials to the media, as well as show hard evidence on what exactly did or did not occur, which may serve as a food for thought to everyone else. To further support the objectivity of the internal investigation we ran our investigation using multiple analysts of non-Russian origin and working outside of Russia to avoid even potential accusations of influence.

The Wall Street Journal Article

The article published in October laid out some specifics that need to be documented and fact checked. Important bullet points from the article include:

Beginning of Search

Having all of the data above, the first step in trying to answer these questions was to attempt to identify the supposed incident. Since events such as what is outlined above only occur very rarely, and we diligently keep the history of all operations, it should be possible to find them in our telemetry archive given the right search parameters.

The first assumption we made during the search is that whatever data was allegedly taken, most likely had to do with the so-called Equation Group, since this was the major research in active stage during the time of alleged incident as well as many existing links between Equation Group and NSA highlighted by the media and some security researchers. Our Equation signatures are clearly identifiable based on the malware family names, which contain words including “Equestre”, “Equation”, “Grayfish”, “Fanny”, “DoubleFantasy” given to different tools inside the intrusion set. Taking this into account, we began running searches in our databases dating back to June 2014 (6 months prior to the year the incident allegedly happened) for all alerts triggered containing wildcards such as “HEUR:Trojan.Win32.Equestre.*”. Results showed quickly: we had a few test (silent) signatures in place that produced a LARGE amount of false positives. This is not something unusual in the process of creating quality signatures for a rare piece of malware. To alleviate this, we sorted results by count of unique hits and quickly were able to zoom in on some activity that happened in September 2014. It should be noted that this date is technically not within the year that the incident supposedly happened, but we wanted to be sure to cover all bases, as journalists and sources sometimes don’t have all the details.

Below is a list of all hits in September for an “Equestre” signature, sorted by least amount to most. You can quickly identify the problem signature(s) mentioned above.

Detection name (silent) Count
HEUR:Trojan.Win32.Equestre.u 1
HEUR:Trojan.Win32.Equestre.gen.422674 3
HEUR:Trojan.Win32.Equestre.gen.422683 3
HEUR:Trojan.Win32.Equestre.gen.427692 3
HEUR:Trojan.Win32.Equestre.gen.427696 4
HEUR:Trojan.Win32.Equestre.gen.446160 6
HEUR:Trojan.Win32.Equestre.gen.446979 7
HEUR:Trojan.Win32.Equestre.g 8
HEUR:Trojan.Win32.Equestre.ab 9
HEUR:Trojan.Win32.Equestre.y 9
HEUR:Trojan.Win32.Equestre.l 9
HEUR:Trojan.Win32.Equestre.ad 9
HEUR:Trojan.Win32.Equestre.t 9
HEUR:Trojan.Win32.Equestre.e 10
HEUR:Trojan.Win32.Equestre.v 14
HEUR:Trojan.Win32.Equestre.gen.427697 18
HEUR:Trojan.Win32.Equestre.gen.424814 18
HEUR:Trojan.Win32.Equestre.s 19
HEUR:Trojan.Win32.Equestre.x 20
HEUR:Trojan.Win32.Equestre.i 24
HEUR:Trojan.Win32.Equestre.p 24
HEUR:Trojan.Win32.Equestre.q 24
HEUR:Trojan.Win32.Equestre.gen.446142 34
HEUR:Trojan.Win32.Equestre.d 39
HEUR:Trojan.Win32.Equestre.j 40
HEUR:Trojan.Win32.Equestre.gen.427734 53
HEUR:Trojan.Win32.Equestre.gen.446149 66
HEUR:Trojan.Win32.Equestre.ag 142
HEUR:Trojan.Win32.Equestre.b 145
HEUR:Trojan.Win32.Equestre.h 310
HEUR:Trojan.Win32.Equestre.gen.422682 737
HEUR:Trojan.Win32.Equestre.z 1389
HEUR:Trojan.Win32.Equestre.af 2733
HEUR:Trojan.Win32.Equestre.c 3792
HEUR:Trojan.Win32.Equestre.m 4061
HEUR:Trojan.Win32.Equestre.k 6720
HEUR:Trojan.Win32.Equestre.exvf.1 6726
HEUR:Trojan.Win32.Equestre.w 6742
HEUR:Trojan.Win32.Equestre.f 9494
HEUR:Trojan.Win32.Equestre.gen.446131 26329
HEUR:Trojan.Win32.Equestre.aa 87527
HEUR:Trojan.Win32.Equestre.gen.447002 547349
HEUR:Trojan.Win32.Equestre.gen.447013 1472919

Taking this list of alerts, we started at the top and worked our way down, investigating each hit as we went trying to see if there were any indications it may be related to the incident. Most hits were what you would think: victims of Equation or false positives. Eventually we arrived at a signature that fired a large number of times in a short time span on one system, specifically the signature “HEUR:Trojan.Win32.Equestre.m” and a 7zip archive (referred below as “[undisclosed].7z”). Given limited understanding of Equation at the time of research it could have told our analysts that an archive file firing on these signatures was an anomaly, so we decided to dig further into the alerts on this system to see what might be going on. After analyzing the alerts, it was quickly realized that this system contained not only this archive, but many files both common and unknown that indicated this was probably a person related to the malware development. Below is a list of Equation specific signatures that fired on this system over a period of approximately three months:

HEUR:Trojan.Win32.Equestre.e
HEUR:Trojan.Win32.Equestre.exvf.1
HEUR:Trojan.Win32.Equestre.g
HEUR:Trojan.Win32.Equestre.gen.424814
HEUR:Trojan.Win32.Equestre.gen.427693
HEUR:Trojan.Win32.Equestre.gen.427696
HEUR:Trojan.Win32.Equestre.gen.427697
HEUR:Trojan.Win32.Equestre.gen.427734
HEUR:Trojan.Win32.Equestre.gen.446142
HEUR:Trojan.Win32.Equestre.gen.446993
HEUR:Trojan.Win32.Equestre.gen.465795
HEUR:Trojan.Win32.Equestre.i
HEUR:Trojan.Win32.Equestre.j
HEUR:Trojan.Win32.Equestre.m
HEUR:Trojan.Win32.Equestre.p
HEUR:Trojan.Win32.Equestre.q
HEUR:Trojan.Win32.Equestre.x
HEUR:Trojan.Win32.GrayFish.e
HEUR:Trojan.Win32.GrayFish.f

In total we detected 37 unique files and 218 detected objects, including executables and archives containing malware associated with the Equation Group. Looking at this metadata during current investigation we were tempted to include the full list of detected files and file paths into current report, however, according to our ethical standards, as well as internal policies, we cannot violate our users’ privacy. This was a hard decision, but should we make an exception once, even for the sake of protecting our own company’s reputation, that would be a step on the route of giving up privacy and freedom of all people who rely on our products. Unless we receive a legitimate request originating from the owner of that system or a higher legal authority, we cannot release such information.

The file paths observed from these detections indicated that a developer of Equation had plugged in one or more removable drives, AV signatures fired on some of executables as well as archives containing them, and any files detected (including archives they were contained within) were automatically pulled back. At this point in time, we felt confident we had found the source of the story fed to Wall Street Journal and others. Since this type of event clearly does not happen often, we believe some dates were mixed up or not clear from the original source of the leak to the media.

Our next task was to try and answer what may have happened to the data that was pulled back.  Clearly an archive does not contain only those files that triggered, and more than likely contained a possible treasure trove of data pertaining to the intrusion set. It was soon discovered that the actual archive files themselves appear to have been removed from our storage of samples, while the individual files that triggered the alerts remained.

Upon further inquiring about this event and missing files, it was later discovered that at the direction of the CEO, the archive file, named “[undisclosed].7z” was removed from storage. Based on description from the analyst working on that archive, it contained a collection of executable modules, four documents bearing classification markings, and other files related to the same project. The reason we deleted those files and will delete similar ones in the future is two-fold; We don’t need anything other than malware binaries to improve protection of our customers and secondly, because of concerns regarding the handling of potential classified materials. Assuming that the markings were real, such information cannot and will not consumed even to produce detection signatures based on descriptions.

This concern was later translated into a policy for all malware analysts which are required to delete any potential classified materials that have been accidentally collected during anti-malware research or received from a third party. Again to restate: to the best of our knowledge, it appears the archive files and documents were removed from our storage, and only individual executable files (malware) that were already detected by our signatures were left in storage. Also, it is very apparent that no documents were actively “detected on” during this process. In other words, the only files that fired on specific Equation signatures were binaries, contained within an archive or outside of it. The documents were inadvertently pulled back because they were contained within the larger archive file that alerted on many Equation signatures. According to security software industry standards, requesting a copy of an archive containing malware is a legitimate request, which often helps security companies locate data containers used by malware droppers (i.e. they can be self-extracting archives or even infected ISO files).

An Interesting Twist

During the investigation, we also discovered a very interesting twist to the story that has not been discussed publicly to our knowledge. Since we were attempting to be as thorough as possible, we analyzed EVERY alert ever triggered for the specific system in question and came to a very interesting conclusion. It appears the system was actually compromised by a malicious actor on October 4, 2014 at 23:38 local time, specifically by a piece of malware hidden inside a malicious MS Office ISO, specifically the “setup.exe” file (md5: a82c0575f214bdc7c8ef5a06116cd2a4 – for detection coverage, see this VirusTotal link) .

Looking at the sequence of events and detections on this system, we quickly noticed that the user in question ran the above file with a folder name of “Office-2013-PPVL-x64-en-US-Oct2013.iso”. What is interesting is that this ISO file is malicious and was mounted and subsequently installed on the system along with files such as “kms.exe” (a name of a popular pirated software activation tool), and “kms.activator.for.microsoft.windows.8.server.2012.and.office.2013.all.editions”. Kaspersky Lab products detected the malware with the verdict Backdoor.Win32.Mokes.hvl.

At a later time after installation of the supposed MS Office 2013, the antivirus began blocking connections out on a regular basis to the URL “http://xvidmovies[.]in/dir/index.php”. Looking into this domain, we can quickly find other malicious files that beacon to the same URL. It’s important to note that the reason we know the system was beaconing to this URL is because we were actively blocking it as it was a known bad site. This does however indicate the user actively downloaded / installed malware on the same system around the same time frame as our detections on the Equation files.

To install and run this malware, the user must have disabled Kaspersky Lab products on his machine. Our telemetry does not allow us to say when the antivirus was disabled, however, the fact that the malware was later detected as running in the system suggests the antivirus had been disabled or was not running when the malware was run. Executing the malware would not have been possible with the antivirus enabled.

Additionally, there also may have been other malware from different downloads that we were unaware of during this time frame. Below is a complete list of the 121 non-Equation specific alerts seen on this system over the two month time span:

Backdoor.OSX.Getshell.k
Backdoor.Win32.Mokes.hvl
Backdoor.Win32.Shiz.gpmv
Backdoor.Win32.Swrort.dbq
DangerousObject.Multi.Chupitio.a
Exploit.Java.Agent.f
Exploit.Java.CVE-2009-3869.a
Exploit.Java.CVE-2010-0094.bb
Exploit.Java.CVE-2010-0094.e
Exploit.Java.CVE-2010-0094.q
Exploit.Java.CVE-2010-0840.gm
Exploit.Java.CVE-2010-0842.d
Exploit.Java.CVE-2010-3563.a
Exploit.Java.CVE-2011-3544.ac
Exploit.Java.CVE-2012-0507.al
Exploit.Java.CVE-2012-0507.je
Exploit.Java.CVE-2012-1723.ad
Exploit.Java.CVE-2012-4681.l
Exploit.JS.Aurora.a
Exploit.MSVisio.CVE-2011-3400.a
Exploit.Multi.CVE-2012-0754.a
Exploit.OSX.Smid.b
Exploit.SWF.CVE-2010-1297.c
Exploit.SWF.CVE-2011-0609.c
Exploit.SWF.CVE-2011-0611.ae
Exploit.SWF.CVE-2011-0611.cd
Exploit.Win32.CVE-2010-0188.a
Exploit.Win32.CVE-2010-0480.a
Exploit.Win32.CVE-2010-3653.a
Exploit.Win32.CVE-2010-3654.a
HackTool.Win32.Agent.vhs
HackTool.Win32.PWDump.a
HackTool.Win32.WinCred.e
HackTool.Win32.WinCred.i
HackTool.Win64.Agent.b
HackTool.Win64.WinCred.a
HackTool.Win64.WinCred.c
HEUR:Exploit.FreeBSD.CVE-2013-2171.a
HEUR:Exploit.Java.CVE-2012-1723.gen
HEUR:Exploit.Java.CVE-2013-0422.gen
HEUR:Exploit.Java.CVE-2013-0431.gen
HEUR:Exploit.Java.CVE-2013-2423.gen
HEUR:Exploit.Java.Generic
HEUR:Exploit.Script.Generic
HEUR:HackTool.AndroidOS.Revtcp.a
HEUR:Trojan-Downloader.Script.Generic
HEUR:Trojan-FakeAV.Win32.Onescan.gen
HEUR:Trojan.Java.Generic
HEUR:Trojan.Script.Generic
HEUR:Trojan.Win32.Generic
Hoax.Win32.ArchSMS.cbzph
KHSE:Exploit.PDF.Generic.a
not-a-virus:AdWare.JS.MultiPlug.z
not-a-virus:AdWare.NSIS.Agent.bx
not-a-virus:AdWare.Win32.Agent.allm
not-a-virus:AdWare.Win32.AirAdInstaller.cdgd
not-a-virus:AdWare.Win32.AirAdInstaller.emlr
not-a-virus:AdWare.Win32.Amonetize.fay
not-a-virus:AdWare.Win32.DomaIQ.cjw
not-a-virus:AdWare.Win32.Fiseria.t
not-a-virus:AdWare.Win32.iBryte.jda
not-a-virus:AdWare.Win32.Inffinity.yas
not-a-virus:AdWare.Win32.MultiPlug.nbjr
not-a-virus:AdWare.Win32.Shopper.adw
not-a-virus:Downloader.NSIS.Agent.am
not-a-virus:Downloader.NSIS.Agent.an
not-a-virus:Downloader.NSIS.Agent.as
not-a-virus:Downloader.NSIS.Agent.go
not-a-virus:Downloader.NSIS.Agent.lf
not-a-virus:Downloader.NSIS.OutBrowse.a
not-a-virus:Downloader.Win32.Agent.bxib
not-a-virus:Monitor.Win32.Hooker.br
not-a-virus:Monitor.Win32.KeyLogger.xh
not-a-virus:PSWTool.Win32.Cain.bp
not-a-virus:PSWTool.Win32.Cain.bq
not-a-virus:PSWTool.Win32.CredDump.a
not-a-virus:PSWTool.Win32.FirePass.ia
not-a-virus:PSWTool.Win32.NetPass.amv
not-a-virus:PSWTool.Win32.PWDump.3
not-a-virus:PSWTool.Win32.PWDump.4
not-a-virus:PSWTool.Win32.PWDump.5
not-a-virus:PSWTool.Win32.PWDump.ar
not-a-virus:PSWTool.Win32.PWDump.at
not-a-virus:PSWTool.Win32.PWDump.bey
not-a-virus:PSWTool.Win32.PWDump.bkr
not-a-virus:PSWTool.Win32.PWDump.bve
not-a-virus:PSWTool.Win32.PWDump.f
not-a-virus:PSWTool.Win32.PWDump.sa
not-a-virus:PSWTool.Win32.PWDump.yx
not-a-virus:RiskTool.Win32.WinCred.gen
not-a-virus:RiskTool.Win64.WinCred.a
not-a-virus:WebToolbar.JS.Condonit.a
not-a-virus:WebToolbar.Win32.Agent.avl
not-a-virus:WebToolbar.Win32.Cossder.updv
not-a-virus:WebToolbar.Win32.Cossder.uubg
not-a-virus:WebToolbar.Win32.MyWebSearch.sv
PDM:Trojan.Win32.Badur.a
Trojan-Banker.Win32.Agent.kan
Trojan-Downloader.Win32.Genome.jlcv
Trojan-Dropper.Win32.Injector.jqmj
Trojan-Dropper.Win32.Injector.ktep
Trojan-FakeAV.Win64.Agent.j
Trojan-Ransom.Win32.ZedoPoo.phd
Trojan.Java.Agent.at
Trojan.Win32.Adond.lbgp
Trojan.Win32.Buzus.umzt
Trojan.Win32.Buzus.uuzf
Trojan.Win32.Diple.fygv
Trojan.Win32.Genome.amqoa
Trojan.Win32.Genome.amtor
Trojan.Win32.Genome.kpzv
Trojan.Win32.Genome.ngd
Trojan.Win32.Inject.euxi
Trojan.Win32.Starter.ceg
Trojan.Win32.Swisyn.aaig
UDS:DangerousObject.Multi.Generic
UFO:(blocked)
VirTool.Win32.Rootkit
VirTool.Win32.Topo.12
Virus.Win32.Suspic.gen
WMUF:(blocked)

Conclusions

At this point, we had the answers to the questions we felt could be answered. To summarize, we will address each one below:

Q1 – Was our software used outside of its intended functionality to pull classified information from a person’s computer?

A1 – The software performed as expected and notified our analysts of alerts on signatures written to detect on Equation group malware that was actively under investigation. In no way was the software used outside of this scope to either pull back additional files that did not fire on a malware signature or were not part of the archive that fired on these signatures.

Q2 – When did this incident occur?

A2 – In our professional opinion, the incident spanned between September 11, 2014 and November 17, 2014.

Q3 – Who was this person?

A3 – Because our software anonymizes certain aspects of users’ information, we are unable to pinpoint specifically who the user was. Even if we could, disclosing such information is against our policies and ethical standards. What we can determine is that the user was originating from an IP address that is supposedly assigned to a Verizon FiOS address pool for the Baltimore, MD and surrounding area.

Q4 – Was there actually classified information found on the system inadvertently?

A4 – What is believed to be potentially classified information was pulled back because it was contained within an archive that fired on an Equation specific malware signatures. Besides malware, the archive also contained what appeared to be source code for Equation malware and four Word documents bearing classification markings.

Q5 – If classified information was pulled back, what happened to said data after? Was it handled appropriately?

A5 – After discovering the suspected Equation malware source code and classified documents, the analyst reported the incident to the CEO. Following a request from the CEO, the archive was deleted from all of our systems. With the archive that contained the classified information being subsequently removed from our storage locations, only traces of its detection remain in our system (i.e. – statistics and some metadata). We cannot assess whether the data was “handled appropriately” (according to US Government norms) since our analysts have not been trained on handling US classified information, nor are they under any legal obligation to do so.

Q6 – Why was the data pulled back in the first place? Is the evidence this information was passed on to “Russian Hackers” or Russian intelligence?

A6 – The information was pulled back because the archive fired on multiple Equation malware signatures. We also found no indication the information ever left our corporate networks. Transfer of a malware file is done with appropriate encryption level relying on RSA+AES with an acceptable key length, which should exclude attempts to intercept such data anywhere on the network between our security software and the analyst receiving the file.

Q7 – What types of files were gathered from the supposed system?

A7 – Based on statistics, the files that were submitted to Kaspersky Lab were mostly malware samples and suspected malicious files, either stand-alone, or inside a 7zip archive. The only files stored to date still in our sample collection from this incident are malicious binaries.

Q8 – Do we have any indication the user was subsequently “hacked” by Russian actors and data exfiltrated?

A8 – Based on the detections and alerts found in the investigation, the system was most likely compromised during this time frame by unknown threat actors. We asses this from the fact that the user installed a backdoored MS Office 2013 illegal activation tool, detected by our products as Backdoor.Win32.Mokes.hvl. To run this malware, the user must have disabled the AV protection, since running it with the antivirus enabled would not have been possible. This malicious software is a Trojan (later identified as “Smoke Bot” or “Smoke Loader”) allegedly created by a Russian hacker in 2011 and made available on Russian underground forums for purchase. During the period of September 2014-November 2014, the command and control servers of this malware were registered to presumably a Chinese entity going by the name “Zhou Lou”, from Hunan, using the e-mail address “zhoulu823@gmail.com”. We are still working on this and further details on this malware might be made available later as a separate research paper.

Of course, the possibility exists that there may have been other malware on the system which our engines did not detect at the time of research. Given that system owner’s potential clearance level, the user could have been a prime target of nation states. Adding the user’s apparent need for cracked versions of Windows and Office, poor security practices, and improper handling of what appeared to be classified materials, it is possible that the user could have leaked information to many hands. What we are certain about is that any non-malware data that we received based on passive consent of the user was deleted from our storage.

Q9 – Could Kaspersky Lab products be secretly used to intentionally siphon sensitive data unrelated to malware from customers’ computers?

A9 – Kaspersky Lab security software, like all other similar solutions from our competitors, has privileged access to computer systems to be able to resist serious malware infections and return control of the infected system back to the user. This level of access allows our software to see any file on the systems that we protect. With great access comes great responsibility and that is why a procedure to create a signature that would request a file from a user’s computer has to be carefully handled. Kaspersky malware analysts have rights to create signatures. Once created, these signatures are reviewed and committed by another group within Kaspersky Lab to ensure proper checks and balances. If there were an external attempt to create a signature, that creation would be visible not only in internal databases and historical records, but also via external monitoring of all our released signatures by third parties. Considering that our signatures are regularly reversed by other researchers, competitors, and offensive research companies, if any morally questionable signatures ever existed it would have already been discovered. Our internal analysis and searching revealed no such signatures as well.

In relation to Equation research specifically, our checks verified that during 2014-2016, none of the researchers working on Equation possessed the rights to commit signatures directly without having an experienced signature developer verifying those. If there was a doubtful intention in signatures during the hunt for Equation samples, this would have been questioned and reported by a lead signature developer.

Q10 – Assuming cyberspies were able to see screens of our analysts, what could they find on it and how could that be interpreted?

A10 – We have done a thorough search for keywords and classification markings in our signature databases. The result was negative: we never created any signatures on known classification markings. However, during this sweep we discovered something interesting in relation to TeamSpy research that we published earlier (for more details we recommend to check the original research at https://securelist.com/the-teamspy-crew-attacks-abusing-teamviewer-for-cyberespionage-8/35520/). TeamSpy malware was designed to automatically collect certain files that fell into the interest of the attackers. They defined a list of file extensions, such as office documents (*.doc, *.rtf, *.xls, *.mdb), pdf files (*.pdf) and more. In addition, they used wildcard string pattern based on keywords in the file names, such as *pass*, *secret*, *saidumlo* (meaning “secret” in Georgian) and others. These patterns were hardcoded into the malware that we discovered earlier, and could be used to detect similar malware samples. We did discover a signature created by a malware analyst in 2015 that was looking for the following patterns:

These strings had to be located in the body of the malware dump from a sandbox processed sample. In addition, the malware analyst included another indicator to avoid false positives; A path where the malware dropper stored dropped files: ProgramData\Adobe\AdobeARM.

One could theorize about an intelligence operator monitoring a malware analyst’s work in the process of entering these strings during the creation of a signature. We cannot say for sure, but it is a possibility that an attacker looking for anything that can expose our company from a negative side, observations like this may work as a trigger for a biased mind. Despite the intentions of the malware analyst, they could have been interpreted wrongly and used to create false allegations against us, supported by screenshots displaying these or similar strings.

Many people including security researchers, governments, and even our direct competitors from the private sector have approached us to express support. It is appalling to see that accusations against our company continue to appear without any proof or factual information being presented. Rumors, anonymous sources, and lack of hard evidence spreads only fear, uncertainty and doubt. We hope that this report sheds some long-overdue light to the public and allows people to draw their own conclusions based on the facts presented above. We are also open and willing to do more, should that be required.

 Appendix: Analysis of the Mokes/SmokeBot backdoor from the incident

Дата: 2017-11-16 10:00:34

Источник: https://securelist.com/investigation-report-for-the-september-2014-equation-malware-detection-incident-in-the-us/83210/