Пару дней назад Cisco выпустила обновление безопасности для Cisco Unified Communications Domain Manager, в котором убрала приватный SSH-ключ root-пользователя.
Да-да, вы все правильно поняли — в прошивке VoIP-контроллера хранился не только публичный ключ аккаунта «support», но и приватный ключ, который можно было извлечь из прошивки и подключиться к любому контроллеру с правами пользователя root

Написал тут маленькую программку, которая позволяет определить тип блокировки сайтов из реестра, применяемый провайдером. Она умеет определять подмену DNS, перенаправление DNS, IP/Port restricted DPI, Full DPI, ну и блокировку по IP, конечно же.
Программа отправляет применяемый тип блокировки на сервер, в дальнейшем можно будет составить таблицу по провайдерам.

Написано на Python 3.
Репозиторий на Github
Бинарники для Windows

Решил я поискать какой-нибудь защищенный мессенджер, посмотреть, что сделали люди за все это время. Протестировал более 20 мессенджеров разной степени готовности. Интересовали только мессенджеры со «своим» протоколом, т.к. в XMPP-мире все нормально и ожидаемо.
Меня, в основном, интересовали мессенджеры для текстового общения с шифрованием в любом его виде. Поиск производился в Google Play по фразам: «secure chat», «secure IM», «secure communication», «secure messaging».
Тестировал только бесплатные решения.

Google запустил сервис по продаже доменных имен domains.google.com. На данный момент, сервис работает по инвайтам. По данным TechCrunch и TheVerge, сервис предлагает бесплатный private whois, перенаправление почты на ваш gmail-аккаунт, HTTP-перенаправления, позволяет создавать до 100 субдоменов и может быть использован для регистрации доменов вроде .guru и .club.
Также, техническая поддержка сервиса будет осуществляться по телефону, что достаточно редко для сервисов Google. Можно предположить, что компания всерьез нацелена конкурировать с гигантами вроде GoDaddy.

Как обещала Microsoft в конце мая, вышла новая версия Skype для Linux. Это достаточно крупное обновление:

• Обновленный UI
• Облачные чаты (отправка сообщений оффлайн, адекватная синхронизация между устройствами)
• Улучшения в отправке файлов при использовании нескольких устройств одновременно
• Улучшения для людей с нарушением зрения
• Поддержка PulseAudio 3.0 и 4.0
• Большое количество багфиксов

Однако, есть и весьма спорное изменение: поддержки ALSA больше нет. Предлагают использовать PulseAudio.
Пока не ясно, появилась ли поддержка видеочатов, или нет.

Вот так неожиданно, через 15 лет после начальной публикации, обновилась спецификация HTTP/1.1
Обновлений много, я бы даже сказал, дофига. Добавили много проясняющего текста, разбили спецификацию на 6 RFC (раньше было 2), добавили новый статус 308, стандартизировали X-Forwarded-For (теперь он просто Forward), и еще много всего.

Неполный спискок изменений:

• Новый статус 308 — Permanent Redirect, но с отправкой этих же самых данных. Т.е. запрос не меняется на GET, как раньше.
• Новый заголовок Forward, который призван заменить X-Forwarded-For и X-Forwarded-Proto
• Убрано ограничение на 2 подключения к серверу
• Убрана поддержка HTTP 0.9
• Убрана кодировка ISO-8859-1 по умолчанию
• Убран заголовок Content-MD5
• Запрет использования Content-Range на POST-запросах
• Добавлено кеширование кодов 204, 404, 405, 414 и 501
• Изменена документация кодов 301 и 302 таким образом, чтобы позволить перенаправлять метод с POST на GET. Т.е. задокументировали текущую реализацию всех браузеров.
• Добавлены разграничения между запретом отправки referer и случаем, когда referer нет. Теперь следует отправлять Referer: about:blank, если referer-а не было.
• Location теперь может перенаправлять на ссылку с хештегом.

Предисловие

Проснулся я сегодня с мыслью, что огромное количество инструкций по настройке NAT советуют использовать строку вида:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Многие понимают проблемы этой конструкции, и советуют добавлять:

iptables -A FORWARD -i ppp0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Но, зачастую, забывают задать таблице FORWARD действие DROP по умолчанию, или добавить правило REJECT в конец таблицы.
На первый взгляд, вроде бы, все кажется нормальным. Однако, это далеко не так. Дело в том, что если не запретить маршрутизировать трафик из WAN-порта в WAN-порт, кто-нибудь из вашей WAN-сети (предположим, что провайдер садит весь подъезд в одну /24) может маршрутизировать трафик через вас, просто прописав ваш IP в качестве шлюза. Все современные SOHO роутеры это учитывают, а вот неопытный администратор, который делает роутер под обычным linux, может не знать или забыть об этом. В подсети моего провайдера таких роутеров не оказалось, и мой план по захвату мира провалился. Однако, статья совсем не об этом.

Магические двоеточия

Как вы, может быть, знаете, многие современные программы и сервисы биндятся на IP :: (два двоеточия), а не на 0.0.0.0, как было раньше. IPv6 адрес :: значит то же самое, что и IPv4 0.0.0.0, т.е. «слушаем все интерфейсы». Многие считают, что если программа слушает ::, то этот сокет может принимать только IPv6-соединения, однако это далеко не так.
В IPv6 есть так называемое отображение IPv4-адресов в IPv6 диапазон. Если программа слушает сокет ::, а к ней обращаются из IPv4-адреса 1.2.3.4, то программа получит соединение с адреса ::ffff:1.2.3.4. Этого можно избежать, сделав:

sysctl -w net.ipv6.bindv6only=1

Но это нужно далеко не всегда, т.к. обычно удобно, что программа слушает один сокет, а получать соединения может по двум протоколам сразу. Практически во всех дистрибутивах, IPv6-сокеты ведут себя именно так, т.е. bindv6only=0.

Вчера какой-то анонимный пользователь ThePirateBay выложил дистрибутив северокорейского производства — Red Star 3.0. Ранние версии этого дистрибутива были доступны и раньше, однако эта версия относительно свежая, датирована 12.12.2013.

В торрент-файле содержится сам дистбирутив rss3_32_key_gui_20131212.iso (817M), взломанный загрузчик boot.iso (37M) и readme.txt

Сначала я пытался запустить дистрибутив в моем любимом QEMU, однако, по какой-то причине установщик никак не переходил к процессу копирования файлов, поэтому пришлось использовать VirtualBox.


Да, вы правильно поняли, это запрос серийного номера. Нужно запускать установщик через boot.iso, в нем содержится крякнутый loader, который не проверяет серийный номер.

Разработчики TrueCrypt ответили: сайт | твиттер

Разработчик TrueCrypt «David»: «Мы были счастливы, что аудит ничего не выявил. Мы усердно работали над проектом 10 лет, но ничего не длится вечно.»
Steven Barnhart: (перефразировано) разработчик считает, что форк навредит еще больше: «Исходный код в любом случае доступен, можете подглядывать» (The source is still available as a reference though). «Я спросил, и было очевидно в последнем ответе, что разработчики считают форк вредным, т.к. только они сами разбираются в коде». «Также он сказал, что никакого контакта с правительством, кроме когда ему предлагали „контракт на поддержку“, у него не было».
Разработчик TrueCrypt «David»: «Битлокер 'достаточно хорош' и Windows был основной целью разработки»
Цитируя разработчика: «Больше нет интереса».

TL;DR: «Новая» версия может только дешифровывать данные, и может содержать троян (хотя я и не нашел, но вы мне не верьте на слово). Бинарник подписан верным ключом разработчика. Все старые версии удалены, репозиторий тоже очищен.

На странице рассказывается о том, что разработка TrueCrypt была прекращена в мае этого года, после того, как Microsoft прекратила поддержку Windows XP, и что TrueCrypt более небезопасен и может содержать уязвимости.
Далее, на странице содержится подробная инструкция миграции с TrueCrypt на BitLocker.

На сайте есть также ссылки на бинарный файл TrueCrypt, которые ведут в раздел загрузок SourceForge, вместе с цифровой подписью. Этот файл подписан корректным (старым) ключом, а внутри него:

В предыдущих сериях:

1. Взламываем D-Link DSP-W215 Smart Plug
2. Взламываем D-Link DSP-W215 Smart Plug. Снова
3. Взламываем D-Link DSP-W215 Smart Plug. Снова и опять

До сих пор, все найденные в DSP-W215 уязвимости могли быть выполнены только из LAN, ну, если вы не глупец и не открыли доступ к Smart Plug из интернета.
Типичным способом атаки устройств со встроенным веб-сервером, доступным только из внутренней сети, типа того, что у DSP-W215 — через CSRF. Проблема этого метода в том, что любой веб-браузер будет кодировать (urlencode) передаваемые данные, например, адрес возврата, но до этого момента мы использовали уязвимости, которые не декодируют (urldecode) наши данные (уязвимость в функции replace_special_char, которую мы эксплуатировали в предыдущей статье, декодирует только ограниченный набор ASCII-символов).

Бинарный файл my_cgi.cgi, который является основной уязвимой целью, содержит функцию-декодировщик «decode», которая декодирует POST-данные. Этой функции передается два аргумента: указатель на закодированные данные и указатель на буфер, где хранятся раскодированные данные:

void decode(char *encode_buf, char *decode_buf);

Эта функция просто проходит циклом по всем байтам в encode_buf и раскодирует или копирует их в decode_buf:

Вот мы снова и опять.


В последнем эксплоите к DSP-W215 я говорил, чтобы функция get_input_entries не падала, нужно использовать имя «storage_path» в POST-запросе. Так нужно было сделать из-за того, что есть еще одно переполнение буфера, на этот раз в функции get_input_entries, которую вызывает get_input_entries, если имя пост параметра отлично от «storage_path» или «path»:


В функцию replace_special_char передается один аргумент — указатель на обрабатываемое POST-значение:

Недавно, D-Link выпустил прошивку v1.02 для DSP-W215, в которой исправлен баг HNAP с переполнением буфера в my_cgi.cgi. Хоть они и быстренько убрали прошивку с сайта: «Вы можете обновить прошивку через мобильное приложение», я успел ее скачать перед моим рейсом в Мюнхен, и 8-часовой перелет предоставил мне достаточно времени для качественного анализа новой версии прошивки.

К сожалению, баг с HNAP был не единственной проблемой этого устройства. Конфигурационный файл lighttpd показывает нам, что my_cgi.cgi используется для обработки некоторых страниц, а не только HNAP-запросов:

alias.url += ( "/HNAP1/" => "/www/my_cgi.cgi",
               "/HNAP1"  => "/www/my_cgi.cgi",
               "/router_info.xml" => "/www/my_cgi.cgi",
               "/post_login.xml" => "/www/my_cgi.cgi",
               "/get_shareport_info" => "/www/my_cgi.cgi",
               "/secmark1524.cgi" => "/www/my_cgi.cgi",
               "/common/info.cgi" => "/www/my_cgi.cgi"
)

Главная функция в my_cgi.cgi имеет два ветвления кода: один для обработки HNAP-запросов, а другой — для всего остального:

Разработчик с ником fin1te пишет безопасную обертку над curl, которая позволяет защититься от SSRF-атак, и в связи с этим проводит контест: если вы сможете скачать файл btc.txt, который расположен на демо-сервере SafeCurl safecurl.fin1te.net и доступен только с source IP 127.0.0.1 и 37.48.90.196 (внешнего IP сервера), то вы получите доступ к кошельку, в котором находится B⃦0.25.

Уже совершено 3 успешных взлома:

• @zoczus обошел защиту, зайдя по 0.0.0.0/btc.txt
• @47696d6569 и ryanc выполнили DNS rebinding, что позволило им загрузить файл с другого IP адреса, уже после прохождения валидации
• @shDaniell использовал уязвимость в парсинге URI, скачав файл ссылкой вида user:pass@safecurl.fin1te.net?@google.com/

D-Link DSP-W215 Smart Plug — беспроводное устройство для мониторинга и контроля за электрическими розетками. Его пока нельзя купить в магазинах Amazon или Best Buy, но прошивка уже доступна для скачивания на сайте D-Link.

TL;DR: DSP-W215 содержит ошибку переполнения буфера, которая позволяет неаутентифицированному пользователю полностью управлять устройством, в том числе и самой розеткой.

Полтора месяца назад, chr13 обнаружил способ произвести DDoS любого сайта с помощью Google Spreadsheet, а теперь же он применил такой способ в Facebook Notes. И он сработал!

Способ эксплуатации совершенно такой же, как и в Google Spreadsheet:

1. Сделайте список «уникальных» «картинок»
   

   <img src=http://targetname/file?r=1></img>
   <img src=http://targetname/file?r=2></img>
   ...
   <img src=http://targetname/file?r=1000></img>

2. Создайте заметку через m.facebook.com. Сервис обрежет заметку после какой-то фиксированной длины
3. Создайте несколько таких заметок под одним или несколькими пользователями. Каждая заметка будет делать 1000+ HTTP-запросов
4. Откройте все заметки одновременно. Указанный сервер получит гору HTTP-трафика. Тысячи запросов уйдут на сервер в течение пары секунд.

Похоже, ботнет BillGates распространяется все больше и больше — уже 4 знакомых человека обратились ко мне с вопросами, как от него избавиться, и что это такое.
Мне удалось заполучить свежую версию, которая нормально работала на моей системе (получала команды с сервера и DOS-ила), и это весело!

Что изменилось?

Модуль «Gates» теперь состоит из 2 модулей: «Beikong» и «Monitor (moni)». Если он запускается по пути /usr/bin/pojie (в моем случае), то запускается moni, если же по какому-то другому пути, то Beikong. Beikong, по сути, является хренотенью, которая переконфигурирует и обновляет другие модули, а moni отслеживает состояние всех модулей (и перезапускает их в случае необходимости), собирает с них статистику и отправляет ее на сервер через Beikong. Если /usr/bin/pojie не существует, то Beikong скопирует себя туда и запустит.

Представляю вашему вниманию обзор и мои субъективные оценки некоторых специализированных способов обхода блокировок со стороны провайдеров или сетевых администраторов.

1. Аддоны для браузеров

ZenMate (Chromium-based, Firefox, Android, iOS)

• Удобство использования: 5/5
• Скорость: 5/5
• Шифрование трафика: Да (TLS)
• Анонимность: Да
• Проксирование всего трафика: Да
• Выборочное проксирование: Да

    Описание:
        Хороший, быстрый аддон.
        На момент тестирования было доступно 5 прокси в разных странах.

    Плюсы:
        Высокая скорость работы аддона
        Быстрые прокси

    Минусы:
        Требуется регистрация в сервисе

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

Что произошло?

1 января 2012 года, Robin Seggelmann отправил, а steve проверил commit, который добавлял HeartBeat в OpenSSL. Именно этот коммит и привнес уязвимость, которую назвали HeartBleed.

Насколько она опасна?

Эта уязвимость позволяет читать оперативую память кусками размером до 64КБ. Причем уязвимость двусторонняя, это значит, что не только вы можете читать данные с уязвимого сервера, но и сервер злоумышленника может получить часть вашей оперативной памяти, если вы используете уязвимую версию OpenSSL.

Злоумышленник может подключиться к, предположим, уязвимому интернет-банку, получить приватный SSL-ключ из оперативной памяти и выполнить MITM-атаку на вас, а ваш браузер будет вести себя так, будто бы ничего и не произошло, ведь сертификат-то верный. Или просто может получить ваш логин и пароль.

Каков масштаб трагедии?

По моим оценкам, примерно ⅔ вебсайтов используют OpenSSL для HTTPS-соединений, и примерно ⅓ из них были уязвимы до сегодняшнего дня.

Уязвимость была/есть, как минимум, у:

• 10 банков
• 2 платежных систем
• 8 VPN-провайдеров
• mail.yandex.ru
• mail.yahoo.com

Используя уязвимость, с mail.yandex.ru можно было получить письма пользователей вместе с HTTP-заголовками (и, подставив cookie, зайти под этим пользователем), а, например, в АльфаБанке получать незашифрованные POST-данные с логином и паролем от Альфа-Клик (интернет-банкинг).

Думаю, большинству хабрапользователей хоть раз да приходилось кодировать видео. Возможно, вы хотели посмотреть свежую серию любимого сериала в метро, а ваш смартфон или иное портативное устройство никак не хотело играть этот кодек, или SmartTV отказывался декодировать звук в видеофайле, либо же вы застряли в 2004 и транскодировали H.264 в MPEG-4 для вашего старого DVD-проигрывателя. Или же, например, сжимали невероятного размера видео, снятое фотоаппаратом, во что-то более-менее приличное по размеру. Наверняка вы замечали, что это не самый быстрый процесс.

Для кодирования видео сделано огромное количество софта, начиная от программ типа «жми крестик чтобы кодировать» и заканчивая софтом, который принимает AviSynth-скрипты на вход. Однако программы, поддерживающие хоть какое-то распределение кодирования, можно пересчитать по пальцам одной руки.

Что вообще следует понимать под распределенным кодированием видео? В моем представлении, есть 2 разных задачи:

1. Кодирование большого количества видеофайлов на множестве компьютеров одновременно
2. Кодирование одного видеофайла по частям на множестве компьютеров одновременно

Первая задача подразумевает наличие большого количества видеофайлов, сильно больше, чем компьютеров, на которых их можно кодировать, и довольно легко автоматизируется с использованием CLI-кодировщиков, например, HandBrake или FFmpeg и любых средств автоматизации, которые поддерживают распределение, вроде GNU Parallel или PPSS (к слову, о нем мало кто знает, рекомендую!).

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

Мой телевизор («старая» модель LG 32LG5000) никогда не работал в Linux. Каждый раз, когда я подключал его через HDMI-порт, ядро сообщало мне ошибку:

kernel: [  869.677850] [drm:drm_edid_block_valid] *ERROR* EDI  has major version 2, instead of 1

и полностью игнорировало его.

Эта проблема меня не сильно-то и беспокоила, т.к. я не часто им пользовался, да и VGA-порт работал, хоть и с максимальным разрешением 1360×768. Однако сегодня, когда я решил посмотреть фильм, качество вывода через VGA было невероятно хреновым, и я решил с этим покончить.

Анализируем EDID

Для тех, кто не знает, EDID — небольшое количество данных, содержащих в себе информацию о возможностях монитора, в основном разрешения и тайминги, которые он поддерживает. Сообщение об ошибке интересно тем, что в нем говорится об EDID 2.0, которого (почти) никогда не существовало. Вот что нам говорит Wikipedia:

Структура EDID имеет версии от v1.0 до v1.4 размером в 128 байт, каждая последующая версия обратно совместима с предыдущей. Структура EDID v2.0 была размером 256 байт, однако позже была объявлена устаревшей и на замену ей пришла v1.3.

Похоже, EDID 2.0 был объявлен устаревшим где-то в 2000. Довольно забавно, что ТВ 2008 года использовал именно эту версию.