В системе управления конфигурацией Ansible (https://www.ansible.com/) выявлена (https://www.computest.nl/advisories/CT-2017-0109_Ansible.txt) уязвимость (CVE-2016-9587 (https://security-tracker.debian.org/tracker/CVE-2016-9587)), позволяющая организовать выполнение команд на стороне управляющего сервера Ansible (Controller) через манипуляции на подчинённых хостах. Например, в случае компрометации одного из клиентских серверов, конфигурация которого настраивается через Ansible, атакующие могут получить доступ к управляющему серверу и через него ко всем остальным управляемым через Ansible хостам сети.Проблема проявляется во всех выпусках Ansible и устранена (http://www.mail-archive.com/ansible-project@googlegroup...) в предварительных выпусках 2.1.4 и 2.2.1, которые пока имеют статус кандидатов в релизы. Исправление также доступно (https://github.com/ansible/ansible/commit/ec84ff6de6eca9224b...) в виде патча. Уязвимость связана с возможностью применения в команде lookup (http://docs.ansible.com/ansible/playbooks_lookups.html) переменной ansible_python_interpreter, позволяющей организовать выполнение кода на стороне управляющего сервера, вернув в ответ на запрос сервера специально оформленный набор атрибутов.
Доступен (https://www.computest.nl/advisories/CT-2017-0109_Ansible.txt) рабочий прототип эксплоита.
URL: http://www.mail-archive.com/ansible-project@googlegroup...
Новость: http://www.opennet.dev/opennews/art.shtml?num=45842
знойная дырка
А говорили питон безопаснее пхп. А оказалось одинаково.
А я ведь точно такую же новость читал совсем недавно. Про crush-report в убунте. На чужих ошибках учиться решительно не желаем!
Ansible принадлежит RedHat.
На мобильнике эта новость за экран выползла (сижу на mobile.opennet.ru). Поправьте пожалуйста верстку.
Единственный комментарий, имеющий отношение к новости -)
:-)
У них нет CSS-разработчика и HTML архитектора.
Как будто никто не знал что это хипсторский "мега-продукт".Впрочем огород на баше и ССШ будет с большой вероятностью ещё хуже.
> Впрочем огород на баше и ССШ будет с большой вероятностью ещё хуже.Фишка огорода в том что его "автоматическими способами" сложно сломать, т.к. у каждого свой забор.
p.s. Даже если у вас левая админка на сайте доступна для всех у кого есть url (admin.site.zone/dgosidhygwut3oihgfwpeoriwpifpfs) то ожидать взлома можно только при индивидуальном подходе.
Это вы здесь за проприетарщину и security by obscurity агитировать пытаетесь?
> Это вы здесь за проприетарщину и security by obscurity агитировать пытаетесь?Нет просто контр-аргумент :)
А потом окажется что кто-то отправил ссылку по почте в незашифрованном виде, а где то стоит сканер и собирает все урлы *admin*.
> А потом окажется что кто-то отправил ссылку по почте в незашифрованном виде,
> а где то стоит сканер и собирает все урлы *admin*.И? А там нестандартная админка, в ручную всё разбирают?
Всё проще - открыл в хроме и гугль уже запустил по этой ссылке своих ботов для поиска, а дальше весь интернет об этой ссылке знает.
> Всё проще - открыл в хроме и гугль уже запустил по этой
> ссылке своих ботов для поиска, а дальше весь интернет об этой
> ссылке знает.Да даже если бы это было правдой, какова вероятность что кто-то зайдёт по ней и что-то сделает ( да ещё и составит такой запрос который её покажет не на 1000-й странице, ведь там столько интересных и уникальных текстов, в самописной админке то?) А даже банальный пароль на уровне apache уже сделает сценарий несанкционированного доступа без инсайда совсем невероятным.
Я бы не стал надеяться на то, что кто-то что-то не найдёт хоть на тысячной странице, хоть на десятитысячной. Искать всё равно будут — если будут — не вручную. А боту всё равно сколько страниц, он железный.
> А потом окажется что кто-то отправил ссылку по почте в незашифрованном виде,
> а где то стоит сканер и собирает все урлы *admin*.Если по скайпу, то не "где-то" ;)
http://www.h-online.com/security/news/item/Skype-with-care-M...
> A reader informed heise Security that he had observed some unusual network traffic following a Skype instant messaging conversation ... It turned out that an IP address which traced back to Microsoft had
> accessed the HTTPS URLs previously transmitted over Skype. Heise Security then reproduced the events by sending two test HTTPS URLs, one containing login information and one pointing to a private cloud-based file-sharing service.
> A few hours after their Skype messages, they observed the following in the server log:
> 65.52.100.214 - - [30/Apr/2013:19:28:32 +0200]
> "HEAD /.../login.html?user=tbtest&password=geheim HTTP/1.1"
> The access is coming from systems which clearly belong to Microsoft.
> Source: Utrace They too had received visits to each of the HTTPS URLs transmitted over Skype from an IP
> address registered to Microsoft in Redmond.
> Даже если у вас левая админка на сайте доступна для всех у кого есть url (admin.site.zone/dgosidhygwut3oihgfwpeoriwpifpfs) то ожидать взлома можно только при индивидуальном подходе.А потом однажды обнаруживается, что подобный суперсекретный путь проиндексировался Google... Знаем, проходили.
> Впрочем огород на баше и ССШ будет с большой вероятностью ещё хуже.Ну, огороднику виднее...
> Ну, огороднику виднее...А что, садоводы уже вынесли у себя третий баш, чтобы над огородниками стебаться?
# ansible --version
ansible 2.1.1.0запускает такую команду:
ssh -C -q -o ControlMaster=auto -o ControlPersist=60s \
-o KbdInteractiveAuthentication=no \
-o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey \
-o PasswordAuthentication=no -o ConnectTimeout=10 \
-o ControlPath=/home/user/.ansible/cp/ansible-ssh-%h-%p-%r \
-tt \
<hostname> /bin/sh -c '....'-o ForwardAgent=no я там не вижу, а значит как только админ с ForwardAgent=yes в конфиге ssh зайдет на инфицированный хост - все хосты, куда подходит его ключ, будут доступны
хихи, как подсказывают коллеги, и отключить-то не всегда можно, особенно когда нужен git с приватного репа
Админ с ForwardAgent=yes в конфиге ssh -- это либо лентяй, либо суицидальник припадочный. Такие должны погибать.
Либо понимает как это работает, какие потенциальные риски несет и как их избежать. В отличии от дилетанта, который просто где-то прочитал, что ForwardAgent это опасно, но не удосужился понять почему и тупо как обезьянка его отключает.
> Админ с ForwardAgent=yes в конфиге ssh -- это либо лентяй, либо суицидальник
> припадочный. Такие должны погибать.А каким ещё образом можно использовать бастион-хост? Не, ну можно держать запароленные ключи прямо на нём и делать ssh-add, но всё равно в итоге у тебя на хосте открытый сокет, с помощью которого можно соединиться с другими хостами от твоего имени.
> А каким ещё образом можно использовать бастион-хост?Вот таким: http://openwall.info/wiki/internal/ssh#How-to-access-intrane...
Это хреновый способ, т.к. надо вручную пробрасывать порты, что довольно геморно и люди на это забьют. Правильный способ, если боишься компрометации бастиона - ProxyJump или ProxyCommand: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...
> Правильный способ, если боишься компрометации бастиона -
> ProxyJump или ProxyCommand: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...Спасибо, хорошее описание, особенно начиная с https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J... (выше этого места описаны и небезопасные способы тоже). Добавил эту ссылку на Openwall wiki.
$ grep -i 'forwardagent.*yes' ~/.ssh/config | wc -l
14Приезжай в любое время и погибни меня, ламер.
Понабирали каких-то попугаев в админы и на опеннет комментировать отправили.
Багрепорт-то отправил, умник?
Эта штука написана таким образом, чтобы интерпретировать всё подряд как код. Чему тут удивляться. Впрочем, это вполне в традициях python way.