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

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




Устранять или нет? Вот в чем вопрос!

Malotavr, который недавно вновь вернулся в эпистолярный жанр по ИБ, обратил свое пристальное внимание на тему управления уязвимостями (тут и тут). И это немудрено, учитывая место его работы - компанию Positive Technologies. Так сложилось, что и я недавно погрузился в эту тему, задавшись достаточно простым, на первый взгляд, вопросом - как приоритезировать уязвимости, которые надо устранять? Их могут тысячи и даже сотни тысяч в крупной инфраструктуре. Вариант "устранять все" в реальной жизни не работает. Пока мы устраняем одни уязвимости (в каком порядке? по времени? по критичности узла? по критичности уязвимости?), злоумышленники могут воспользоваться другими. Устраняя "другие", злоумышленники могут воспользоваться третьими. И так далее. Где провести ту грань, за которой уязвимость может быть отложена "на потом"?

Задавшись этим вопросом, я, случайно или нет, наткнулся на интересное исследование, в котором был проведен анализ списка CVE корпорации MITRE. Из 120 тысяч CVE были отброшены зарезервированные, отброшенные или еще обсуждаемые уязвимости - осталось 94457 дыр, по которым исследователи анализировали наличие эксплойта, в том числе и находящегося в диком виде. По результатам исследования были сделаны следующие выводы:


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

В ней я отталкиваюсь в первую очередь от общего рейтинга CVSS; затем смотрю на наличие эксплойта (либо из Банка данных уязвмостей ФСТЭК, либо из CVSS); потом на наличие удаленной эксплуатации дыры (параметр AV в CVSS), и, наконец, на сложность получения доступа (параметр AC в CVSS). Все значения берутся из полей БДУ. В реальной жизни для проверки наличия эксплойта и подтверждения CVSS обычно используются перекрестные базы (NVD, Secunia, ExploitDB, Cisco, Vulners и т.п.), но для ряда пользователей, особенно государственных, использовать зарубежные БД было бы не совсем правильно. К сожалению, наполнение БДУ пока не идеально (особенно в части оперативной информации по наличию эксплойтов), но другой возможности у госов нет (хотя тот же Vulners имеет российские корни, но "не признан" регулятором).

%25D0%2591%25D0%25BB%25D0%25BE%25D0%25BA-%25D1%2581%25D1%2585%25D0%25B5%25D0%25BC%25D0%25B0.png

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

Понятно, что у схемы есть и свои ограничения. Например, мы отсекаем локальные уязвимости без эксплойта с CVSS ниже 6.5, которые могут быть использованы злоумышленником, имеющим физический доступ к объекту защиты. Но тут я исхожу из предположения, что потребитель все-таки имеет хоть какие-то меры по контролю физического доступа, усложняющие эксплуатацию локальной уязвимости (хотя риск инсайдера остается). Также за двухнедельный временной зазор может быть разработан эксплойт и система может быть взломана. Можно попробовать уменьшить этот срок, но тогда мы слишком часто будем запускать цикл проверки, что для многих систем, особенно ГИС/МИС, будет непросто. Также я исхожу из того, что при отсутствии мер защиты безопасники все-таки смогут разработать компенсирующие меры (отключить уязвимую систему от сети, заменить уязвимое устройство, установить «виртуальный патч», зарезервировать систему, заблокировать использование уязвимости с помощью МСЭ или IDS и т.п.). Если нет, то тут уже ничего сделать нельзя :-(

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

Дата: 2018-11-14 02:25:02

Источник: http://lukatsky.blogspot.com/2018/11/blog-post_14.html



Androspy - Backdoor Crypter & Creator With Automatic IP Poisener

Androspy_2.png
Androspy : is Backdoor Crypter & Creator with Automatic IP Poisener Coded By Belahsan Ouerghi

Dependencies

Installation
sudo apt-get install git
git clone https://github.com/TunisianEagles/Androspy.git
cd Androspy
chmod +x setup.sh
sudo ./setup.sh
chmod +x androspy.sh
sudo ./androspy.sh

Tested on :

Contact

Дата: 2018-11-13 21:16:00

Источник: http://www.kitploit.com/2018/11/androspy-backdoor-crypter-creator-with.html



Дружелюбная защита WEB ресурса от атак перебором

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

Чаще всего, вопрос решается относительно просто. Если пользователь ввел несколько раз неправильно пароль, его учетка блокируется на какое-то время. Альтернативное решение — выводить капчу. Сразу, или после нескольких неудачных попыток. Ну, и не забудем про 2F авторизацию, которая почти неуязвима. Казалось бы — профит! Но, не все так радужно…

Давайте рассмотрим некоторые проблемы описанных решений:

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

Капча — относительно неплохое и эффективное решение. Правда доставляет неудобство пользователю, требуя вводить что-то там дополнительно. Достаточно “неприятно” встраивать в дизайн. Ах да… еще эта штука, в зависимости от реализации, может быть подвержена DoS атаке.

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

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

Если вы пользуетесь почтой, например mail.ru, и у вас установлена 2F авторизация, то возможно уже замечали, что 2F авторизация запрашиваться только для нового “устройства” при первом входе. Далее, устройство считается доверенным. И нужно просто вводить логин и пароль.

Удобная штука. Юзерфрендли, так сказать. Реализуется это двумя токенами. Первый идентификатор “устройства” (определим как devid), а второй сессионный (определим как session). Devid, в отличии от session не теряет актуальности даже после завершения сессии пользователем. Он передается при следующей попытке входа, и если логин/пароль верный, а также devid доверенный, 2F уже не запрашивается. Но, если очередная попытка входа оказалась неудачной, токен devid тут же протухает. И теперь нужно пройти полный путь авторизации.

За основу была взята эта парадигма. Т.е. ввести токен devid, который будет выдаваться постоянно, при любом ответе WEB-ресурса, конечно, если его не было в запросе.

Для случая 2F авторизации был, фактически, реализован вышеописанный алгоритм. И сразу все стали довольны. Т.ч. его детально рассматривать смысла нет. А вот «навороты», лучше рассмотреть на схеме, с пояснениями:

mkgoljdvztzitumsn48anqe0hvk.png

Даже, если не установлена 2F авторизация, но вход был успешным, то токен devid помечается как доверенный. Казалось бы, смысла особого нет делать это без 2F авторизации. Но, все чуть хитрее. Если мы знаем, что devid доверенный, т.е. с него был успешный вход, мы как минимум предполагаем, что именно с этого устройства входил реальный юзер. Это очень важная информация, которую использует описываемый алгоритм в своей работе в режиме отражения атаки.

Была принята стратегия: любая авторизация может происходить только при наличии валидного токена devid. Валидный devid отличается от доверенного тем, что он еще НЕ доверенный, т.е. с него не было успешных входов, но система готова обрабатывать с ним запросы на авторизацию. На один валидный токен количество попыток ограничено N раз. Если происходит ошибка авторизации более N раз подряд, токен помечается как “скомпрометированным”. Он переносится в отдельный журнал со статистикой подбора. Запросы с его участием продолжают обрабатываться, но… залогиниться с ним уже нельзя. Все, что происходит — накопление статистики активности.

Так отбиваются самые глупые атаки. Например, если атакующий, игнорируя devid, пытается логиниться в систему или если он не смог понять логику работы devid (откуда ему знать сколько дается попыток логина с одним и тем же devid?), его запросы терминируются.

Собственный фронт знает, что после N раз неуспешных попыток входа с одного devid, он уже “протух”. Теперь нужно получить новый токен, перед очередной попыткой логина.

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

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

Таким образом получается гибкая система контроля и управления атаками. Образуются надежные метрики по которым может срабатывать мониторинг поднимая тревогу. Накопленную статистику можно преобразовывать в правила блокировки и т.п.

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

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

Дата: 2018-11-13 20:57:13

Источник: https://habr.com/post/429804/



Ноябрьский перевыпуск октябрьского обновления Windows 10

Со второй попытки Microsoft все-таки выпустила для всех пользователей октябрьское обновление Windows 10, ранее отозванное из-за проблем с удалением пользовательских данных.
обсуждение | Telegram | Facebook | Twitter

Дата: 2018-11-13 19:23:00

Источник: https://bugtraq.ru/rsn/archive/2018/11/01.html



Hackers Change WordPress Siteurl to Pastebin

Hackers Change WordPress Siteurl to Pastebin

Last Friday, we reported on a hack that used a vulnerability in the popular WP GDPR Compliance plugin to change WordPress siteurl settings to erealitatea[.]net. At that time it was not clear who was behind the massive attack, since the erealitatea[.]net domain didn’t work and the infection simply broke the compromised sites. Our SiteCheck scanner detected the infection on about 700 sites over the weekend and PublicWWW now currently returns 573 results.

Continue reading Hackers Change WordPress Siteurl to Pastebin at Sucuri Blog.

Дата: 2018-11-13 16:17:32

Источник: https://blog.sucuri.net/2018/11/hackers-change-wordpress-siteurl-to-pastebin.html



Свежий баг MS Word нашел применение в реальных атаках

Злоумышленники взяли на вооружение опасную уязвимость Microsoft Word уже через две недели после того, как ее описали ИБ-эксперты. Логическая ошибка в функции добавления онлайн-видео помогает преступникам похищать пользовательские данные.

В конце октября о проблеме с текстовым редактором Microsoft сообщили специалисты Cymulate. Они обнаружили возможность вредоносных манипуляций через внедрение в DOCX-файл онлайн-видео и редактирование его XML-содержимого. Если заменить адрес, к которому обращается Word при загрузке ролика на пользовательскую машину, можно выполнить опасный код, минуя проверки антивирусных систем.

Случаи применения этой уязвимости в реальных атаках не заставили себя ждать. Через две недели после публикации эксперты Trend Micro обнаружили на онлайн-сканере VirusTotal первый вредонос на базе описанной техники. Злоумышленники доработали механику и применили ее для распространения трояна Ursnif.

Этот давно знакомый экспертам вредонос также известен как Rovnix, Papras и Gozi. В настоящей версии его основная функция — сбор информации о списке установленных на зараженном компьютере программ, драйверов и подключенных сетевых устройств, внешнем IP-адресе, файлах cookie и др. Троян также умеет записывать видео с экрана и красть банковские данные через веб-инъекции.

Как установили аналитики, организаторы кампании добавили в код Word-документа ссылку на Pastebin, где размещен загрузчик. Этот скрипт в свою очередь скачивает и распаковывает полезную нагрузку.

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

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

Разработчики Microsoft пока не изменили свою позицию по данной уязвимости. Поскольку речь идет о легитимной функции, компания утверждает, что пользователи должны сами заботиться о своей безопасности — не открывать подозрительные вложения и проверять легитимность скаченного контента перед тем, как запускать его на своем компьютере. Эксперты также рекомендуют заблокировать все документы Word со встроенным видео.

Ранее «Лаборатория Касперского» сообщила, что на сегодняшний день первое место по использованию в атаках занимает уязвимость Microsoft Office CVE-2017-11882, которая позволяет выполнять сторонний код.

Источник: https://threatpost.ru/hackers-exploit-recent-msword-bug/29129/

Дата: 2018-11-13 15:57:15

Источник: https://exploit.in/2018/11938/



Гипервизоры VMWare получили важные патчи

Компания VMWare закрыла две бреши в своих продуктах, предназначенных для мониторинга виртуальных машин. Уязвимости позволяют из-под гостевой ОС выполнить произвольный код на хост-машине, а также допускают утечку данных при передаче информации между хостом и пользователем с правами гостя. Баги затронули ключевые продукты разработчика, включая гипервизор ESXi, предназначенный для использования в масштабах предприятия.

Проблема кроется в виртуальном сетевом адаптере vmxnet3, код которого содержит ошибку, позволяющую использовать неинициализированную память стека.

Новая возможность побега из песочницы в виртуальной среде была обнаружена в ходе конкурса этичных хакеров GeekPwn, проходившего 24 и 25 октября этого года в Шанхае. Уязвимости присутствуют в гипервизорах vSphere ESXi, VMWare Workstation (Pro и Player), а также Fusion и Fusion Pro.

Уязвимости зарегистрированы в базе CVSS как CVE-2018-6981 и CVE-2018-6982. Первой разработчик присвоил максимальный, критический уровень опасности и в течение двух недель после получения информации о багах выпустил апдейты для всех затронутых продуктов. Создатели программ подчеркивают: поскольку бреши привязаны к компоненту vmxnet3, использовать их при отключенном виртуальном адаптере невозможно.

Для ESXi версий 6.0–6.7 VMWare выпустила комплект патчей, а продукты семейства Workstation и Fusion получили обновления версий. Все апдейты доступны пользователям уязвимых систем по каналам техподдержки производителя.

Месяц назад VMWare уже латала бреши в тех же разработках. Уязвимость, которую обнаружили специалисты проекта Zero Day Initiative, позволяла киберпреступникам расширить свои привилегии на атакуемом устройстве через выполнение стороннего кода. Как выяснили ИБ-аналитики, проблема возникает из-за некорректной обработки специально созданных SVGA-изображений, передаваемых на хост злоумышленником.

Источник: https://threatpost.ru/vmware-patches-guest-to-host-escape-in-esxi-workstation-fusion/29107/

Дата: 2018-11-13 15:55:46

Источник: https://exploit.in/2018/11937/



Руткит скрывает криптомайнер из списка активных процессов

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

Атака начинается с доставки на компьютер загрузчика, который связывается с хранилищем в сервисе Pastebin, скачивает и выполняет скрипт оболочки. Он устанавливает на зараженное устройство еще один скрипт, отвечающий за развертывание и обновление криптомайнера. Полезная нагрузка попадает в целевую систему под видом JPG-файла, который в действительности является исполняемым модулем в формате ELF.

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

Он представляет собой модифицированную версию кода, доступного для скачивания в Интернете.

Руткит подменяет компонент readdir библиотеки libc, чтобы программы мониторинга процессов не видели зловред. Таким образом, жертва не сможет обнаружить и выгрузить криптомайнер, а индикатором заражения будет служить лишь полная загрузка центрального процессора.

Многофункциональные зловреды, способные генерировать цифровые деньги, уже попадали в сферу внимания ИБ-специалистов. Осенью этого года стало известно о программе XBash, совмещавшей в себе возможности бота, вымогателя, интернет-червя и майнера. Скрипт атаковал компьютеры под управлением Windows, macOS и Linux, используя подбор паролей и несколько эксплойтов для взлома сетевых баз данных.

Источник: https://threatpost.ru/rootkit-hides-miner-from-process-monitoring-tools/29103/

 

Дата: 2018-11-13 15:53:57

Источник: https://exploit.in/2018/11936/



В Windows 10 может появиться поддержка WPA3

Несмотря на то что Microsoft официально не объявила о поддержке протокола WPA3, в сборке Windows 10 SDK 18272, также известной как 19H1, появилось несколько API, поддерживающих новый стандарт безопасности Wi-FI.

Новый стандарт безопасности беспроводной связи был представлен летом 2018 года. WPA3 использует одновременную аутентификацию равноправных элементов (Simultaneous Authentication of Equals, SAE) — новую технологию проверки подключаемых устройств, устойчивую перед атаками с переустановкой ключа (Key Reinstallation Attacks, KRACK). SAE основана на принципе, согласно которому каждая из сторон может независимо от другой отправить как запрос на соединение, так и удостоверяющую информацию.

Предыдущее поколение стандарта WPA2-Personal использовало технику PSK (Pre-Shared Key), основанную на алгоритме валидации путем сообщения пароля после «обмена четырьмя рукопожатиями» — именно в него вмешивался злоумышленник методом KRACK и на третьем «рукопожатии» перехватывал ключ.

Технология SAE предназначена для личных устройств и обеспечивает безопасность даже при использовании слабых паролей. Для передачи информации по корпоративным сетям в WPA3-Enterprise по умолчанию предусмотрено 128-битное шифрование, однако при желании можно задействовать кодирование в 192 бита.

Изменения в API новой сборки Windows 10 SDK заметили MSPoweruser. Они приняли участие в изучении функций и возможностей новой, 18 272-й версии, которое компания специально проводит для получения обратной связи и устранения замеченных недостатков. О находке написали также и другие пользователи, однако отметили, что на данный момент функция должным образом не работает.

Возможно, поддержка нового стандарта станет доступна для всех пользователей Windows 10 в начале 2019 года. Тем не менее, сам протокол еще только входит в широкий оборот. У производителей сетевых устройств уйдет несколько месяцев на то, чтобы получить сертификат Wi-Fi Alliance на внедрение WPA3.

Дата: 2018-11-13 15:40:34

Источник: https://threatpost.ru/windows10-may-support-wpa3/29141/



Основные источники киберугроз в III квартале 2018 года

В ежеквартальном отчете по киберугрозам специалисты «Лаборатории Касперского» представили рейтинг эксплойтов, использовавшихся злоумышленниками для атак с июля по сентябрь 2018 года. Как выяснили эксперты, чаще всего мошенники применяли для нападения уязвимости в Microsoft Office, а также бреши в браузерах. Наибольшей популярностью у нападающих пользовались давно известные и уже пропатченные баги в редакторе формул Equation Editor.

Как следует из отчета, 70% атак, эксплуатирующих баги программных продуктов, в третьем квартале строилось на ошибках пакета Office. Желанной целью злоумышленников по-прежнему остаются пользователи, не устанавливающие вовремя апдейты безопасности. Например, уязвимость CVE-2017-11882 была закрыта Microsoft еще год назад, однако до сих пор нередко применяется киберпреступниками для проникновения на целевое устройство. Патч для другой бреши в Equation Editor, CVE-2018-0802, был выпущен в январе, но она все еще остается популярной точкой входа для нападающих.

Эксплойты в браузерах, занимающие второе место среди основных направлений атак, используются киберпреступниками гораздо реже. На их долю приходится менее 14% инцидентов. В этом сегменте наибольшую обеспокоенность среди ИБ-экспертов вызывала уязвимость Internet Explorer CVE-2018-8373, найденная в августе 2018 года. Брешь допускала выполнение на устройстве стороннего кода в контексте текущего пользователя и могла привести к перехвату контроля над целевой системой.

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

Значительное количество кампаний проводится через веб-ресурсы. Мошенники используют для атак специально созданные интернет-площадки или внедряют вредоносный код на страницы легитимных сайтов. По данным «Лаборатории Касперского», в третьем квартале 2018 года антивирусными продуктами зафиксировано более 246 млн уникальных IP-адресов, замеченных в распространении зловредов.

Безоговорочным лидером по размещению криминальных сайтов являются США, на долю которых в отчетный период пришлось более 52% срабатываний веб-антивируса. На втором месте — Нидерланды (16,26%) , третью строчку заняла Германия (около 7%). Россия занимает шестую позицию (1,86%), пропустив вперед Великобританию и Францию.

Список направлений кибератак существенно отличается от их источников. Как выяснили специалисты, страной с самым высоким уровнем интернет-инцидентов является Венесуэла. Более 35% местных пользователей антивирусных продуктов «Лаборатории Касперского» подвергались в третьем квартале риску заражения, пытаясь перейти на вредоносный сайт. В тройку лидеров вошли также Албания и Алжир, набравшие почти по 32,5% срабатываний веб-антивируса. Из постсоветских республик риск заражения из веба выше всего в Беларуси (31,08%).

Дата: 2018-11-13 15:07:00

Источник: https://threatpost.ru/main-threat-sources-in-q3-of-2018/29138/