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

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

Проблема представляла собой уязвимость межсайтовой подделки запросов (CSRF), позволявшую использовать легитимный вход в Facebook для несанкционированных действий. Для успешного осуществления атаки злоумышленник должен был заставить авторизованного в соцсети пользователя зайти на вредоносный сайт через браузер Chrome. Когда жертва кликала в любом месте на сайте, злоумышленник мог показывать всплывающее уведомление или открывать новую вкладку со страницей поиска Facebook и отправлять любое количество запросов на получение личной информации.

Через уязвимость исследователи из Imperva смогли узнать, фотографировался ли пользователь в определенных местах, писал ли недавно пост с использованием определенного текста и поставили ли его друзья «лайк» странице Facebook. Кроме того, им удалось узнать интересы пользователей и их друзей, даже если доступ к этим данным был ограничен настройками приватности.

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

Компания Microsoft выпустила плановый пакет обновлений безопасности, исправляющий в общей сложности 62 уязвимости в различных продуктах производителя (ОС Windows, Office, Edge, Internet Explorer и пр.), в том числе более двух десятков критических и проблему повышения привилегий (CVE-2018-8589) в компоненте Windows Win32k, активно эксплуатируемую киберпреступниками. Однако уязвимость в службе Microsoft Data Sharing, PoC-код для эксплуатации которой был опубликован в минувшем октябре, пока остается неисправленной.

Из 24 критических уязвимостей 8 содержатся в скриптовом движке Chakra в составе браузера Microsoft Edge. Каждая из них позволяет удаленное выполнение кода, что предоставляет злоумышленнику возможность загрузить вредоносное ПО или выполнять различные действия на системе с правами текущего пользователя.

Еще несколько критических уязвимостей были исправлены в протоколе Trivial File Transfer Protocol (CVE-2018-8476), графическом компоненте в Windows (CVE-2018-8553), платформе бизнес-приложений Dynamics 365 (CVE-2018-8609), в движке Windows VBScript (CVE-2018-8584), в Word (CVE-2018-8539, CVE-2018-8573), а также две проблемы в PowerShell (CVE-2018-8256, CVE-2018-8415).

В числе прочих были устранены четыре XSS-уязвимости в Dynamics 365 (CVE-2018-8605, CVE-2018-8606, CVE-2018-8607, CVE-2018-8608), DoS-уязвимость в Skype for Business (CVE-2018-8546) и проблема обхода шифрования (CVE-2018-8566) в BitLocker.

С полным списком уязвимостей можно ознакомиться здесь .

Hello Reader,
          The test kitchen has returned! Tonight we looked at the new USB artifacts described in yesterdays post http://www.hecfblog.com/2018/11/daily-blog-536-usb-30-external-storage.html and look to see how USB Detective handles the new driver.

Here is what we learned:

• The DeviceContainers key is the place that glues together the disparate keys you need for a storage device to figure out its properties
• The USB enum key has the same 83da property GUID for driver installs that provides the install, last insert and last removal dates that USBStor did. 
• USB Detective properly detected the drives, found the serial numbers, dates of install and even the volume serial number with the assistance of the event logs!

Jason Hale is now going to update USB Detective to get the rest of the data and I'd be happy to provide the same test data to any other developer out there who would also like to update their tools.

You can watch the video here:

В связи с наращиванием зарубежными странами возможностей информационно-технического воздействия на информационную инфраструктуру в военных целях у Службы защиты государственной тайны Вооруженных Сил РФ (Службы ЗГТ) появились новые задачи. Об этом в среду, 14 ноября, сообщил начальник Службы ЗГТ генерал-лейтенант Юрий Кузнецов в интервью журналистам газеты «Красная звезда».

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

В настоящее время в обязанности Службы ЗГТ также входит обеспечение безопасности информации в автоматизированных системах Минобороны РФ, обнаружение, предупреждение и ликвидация последствий кибератак на критически важные объекты ВС и техническая защита информации на объектах, обрабатывающих информацию ограниченного доступа. Кроме того, Служба ЗГТ занимается обеспечением целостности и подлинности электронных документов, сертификацией средств защиты информации и проведением контрольно-технических мероприятий по обеспечению информационной безопасности.

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

По данным отчета «Лаборатории Касперского» по развитию угроз за третий квартал 2018 года, WannaCry возглавляет список самых распространенных семейств шифровальщиков. С июля по сентябрь ЛК зафиксировала 74 621 попытку WannaCry атаковать клиентов компании. Если в третьем квартале 2017 года на долю вредоноса приходилось 17% от всех атак с использованием вымогательского ПО, то теперь этот показатель составляет 29%. Однако, как отметили исследователи, в нынешнем году число вымогательских программ меньше, чем в прошлом.

WannaCry распространяется с помощью EternalBlue – эксплоита, разработанного Агентством национальной безопасности США для уязвимости в SMB. Благодаря ему вымогатель распространяется подобно червю и никогда не прекращает попыток «пролезть» дальше. В прошлом году Microsoft выпустила исправляющие уязвимость обновления, однако многие пользователи до сих пор их не установили и по-прежнему рискуют стать жертвами WannaCry.

На втором месте после WannaCry по распространенности оказался GandCrab – на его долю приходится 12% от всех атак с использованием вымогательского ПО. В список самых распространенных вымогателей также попали Cryakl, PolyRansom, Shade и Crysis.

Как отмечают эксперты, в нынешнем году число заражений шифровальщиками заметно ниже, чем в прошлом, когда мир сначала захлестнула волна атак WannaCry, а затем NotPetya. В общей сложности ЛК зафиксировала 259 867 попыток вымогательского ПО атаковать пользователей, из них 132 810 попыток было выявлено в одном лишь в сентябре.

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

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

• 23% опубликованных уязвимостей имеют эксплойт.
• 2% уязвимостей имеют эксплойт в диком виде.
• Вероятность уязвимости быть использованной в 7 раз выше, если эксплойт существует. 
• 50% эксплойтов публикуется в течение двух недель после обнаружения уязвимости.

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

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

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

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

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

Dependencies

• keytool
• jarsigner
• Apache2
• Metasploit-Framework
• xterm

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 :

• BackBox Linux
• Kali linux
• Parrot os

Contact