По ссылке находятся исходники обфусцированного алгоритма шифрования RC4, который используется в Skype для шифрования трафика.

Upd с enrupt.com:

Опубликованный алгоритм это ВСЁ что нужно для расшифровки трафика между клиентами и супернодами. Ключа нет. Совсем. Потому что это уровень обфускации, предназначенный для того, чтобы другие не смогли сделать своих клиентов для протокола Skype. Поэтому этот алгоритм был защищен так сильно как только это возможно. Монополия Skype, которой больше нет.
Не беспокойтесь если Skype сменит протокол, нам понадобилось всего несколько дней чтобы его добыть. Мы тут же выпустим апдейт.

Наша публикация никак не влияет на приватность звонков, сообщений или передач файлов. Они защищены с помощью AES-256, а согласование ключей происходит с помощью 1024битного RSA. Так что без паники )

В следующем месяце мы может быть выложим програмку, которая расшифровывает UDP пакеты Skype и проверяет их CRC :)

Введение

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

Вооружившись Wireshark'ом я получил несколько дампов и был, честно говоря, ошарашен содержимым. К шестнадцатеричным значениям было уже не привыкать, но вот структуры никакой вычленить было невозможно. Так как опыт в системном программировании у меня совсем небольшой, я решил воспользоваться советами профессионала (автора темы) и попросить у него наводку: в какую сторону копать. Кроме общих рекомендаций, я узнал, что трафик игры зашифрован при помощи алгоритма RC4, а данные сервера к тому же сжимаются (об этом в другой раз). Направление было задано и я начал изучать алгоритм, чтобы реализовать его на C#.

Google первой среди крупных интернет-компаний внедрила на HTTPS-серверах функцию защиты от будущей потери секретного ключа (функция называется perfect forward secrecy или PFS). Для этого разработано open-source дополнение к OpenSSL, в частности, написан быстрый генератор ключей на эллиптических кривых P-224, P-256 и P-521. По ходу работы специалисты Google также исправили несколько багов в OpenSSL.

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

В случае с Google такой вариант не пройдёт. Теперь здесь используются недолговечные («эфемерные») сеансовые ключи, которые обмениваются по схеме ECDHE (аббревиатура ECDHE расшифровывается как «эфемерный алгоритм Диффи-Хеллмана с использованием эллиптических кривых»). После сеанса связи ключи уничтожаются, и даже владелец сервера не сможет расшифровать сессию, которую его сервер зашифровал прошлым ключом.

Предисловие

Я уже долгое время ничего не исследую, так сказать ушел на покой. Но тут мне на глаза попалась очередная поделка немало известного в определенных кругах PE_Kill'a. Т.к. мне довелось решать его предыдущую поделку в рамках CRACKL@B Contest 2010, которая в свою очередь была довольно интересна, я решил взглянуть на его новое «детище».

Что вас ждет под катом: подделка CRC32, брут ключа для RC4, факторизация для RSA, а также использование коллизии для MD4 и генерация двух разных сообщений с одинаковыми хешеми. Всё это и многое другое под катом.

Вышел очередной релиз — кандидат новой ветки PHP 5.4. Отличия от предыдущей сборки:

• Добавлена конфигурационная переменная max_input_vars, позволяющая бороться с атаками, основанными на совпадении хэшей (hash collision attacks)
• Исправлен segfault в работе traits
• Исправлен баг с некорректным чтением и записью при использовании traits
• Исправлен segfault после 2 POST запросов с типом multipart/form-data (коды 200 + 404)
• Исправлена ошибка с неотображением ошибок PHP в некоторых браузерах, использующих SAPI
• Исправлен segfault при использовании старых версий OpenSSL
• Исправлены неработающие функции bindValue и bindParam в драйвере PDO для Firebird

Кстати для тех, кто хочет попробовать новые возможности PHP 5.4 (например, traits), не разбираясь в тонкостях сборки PHP из исходных кодов в своей Debian-based системе, можете использовать пакеты версии 5.3.99 с сайта http://apt.damz.org/(для Ubuntu 11.04).

После нескольких часов чтения обзоров, Боб с нетерпением нажал на кнопку перехода к оформлению заказа на галлон цельного молока, и…
Воу, что только что произошло?

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

Итак, по словам автора приложения APRSdroid, начиная с Android 2.3 при установке SSL-соединения вместо использовавшейся ранее комбинации алгоритмов шифрования и хэширования AES256 и SHA1 первой стала предлагаться значительно более слабая комбинация из RC4 и MD5.
Почитать пост с описанием этого открытия вы можете по ссылке.
Оставляя за скобками мотивы разработчиков android установить приоритет именно для этих алгоритмов, я хочу рассказать чем плох RC4 в качестве основного метода шифрования и чем это чревато для SSL.

Патентные тролли в последнее время становятся всё более наглыми. Пользуясь недостатками американского законодательства, они зарабатывают миллионы долларов, подавая иски против рядовых компаний и предпринимателей. Одним из последних примеров стала активность фирмы TQP Development, которая предъявила нескольким сотням компаний претензию в использовании запатентованной схемы «криптографически защищённой электронной коммерции». В патенте, фактически, описано одновременное использование SSL и RC4.

Почти 140 компаний выплатили TQP Development в общей сложности более 45 миллионов долларов. Среди них — такие гиганты, как Amazon (заплатила $500 тыс.) и Microsoft ($1 млн).
Шантаж продолжался бы и дальше, но на сцену вышел интернет-магазин Newegg. Он отказался платить лицензионные отчисления и потребовал рассмотрения дела в суде.

Об этом, возможно, уже много написано в блогах, но… хоть шифрование RC4 и считается уязвимым, многие вебсайты всё ещё используют его по умолчанию, и Firefox отображает такие соединения как использующие «высокую степень шифрования». К счастью, мы можем отключить поддержку RC4 в настройках Firefox.

1. Открываем страницу настройки по адресу about:config.
2. В ответ на предупреждение, что вы можете «лишиться гарантии», отвечаем, что будем осторожными.
3. В строке поиска в верхней части страницы вводим «RC4».
4. В результате мы видим различные комбинации шифров, использующие данный стандарт (должно быть 6 записей с типом «логическое»/«boolean»). Переключаем каждую двойным кликом на значение «false».
5. Наслаждаемся результатом.

Естественно, если сайт поддерживает только RC4, произойдёт ошибка соединения. Но, скорее всего, вам и не нужно туда ходить.

Исследователи Mathy Vanhoef и Frank Piessens из iMinds-DistriNet и KU Leuven обнаружили опасную уязвимость в устаревшем, но все еще широко применяемом потоковом шифре RC4. В случае с веб-сайтами, уязвимость позволяет дешифровать часть зашифрованного HTTPS-потока (например, сессионный идентификатор, передающийся в Cookie) за десятки часов. Для реализации уязвимости необходимо применять MiTM-атаку, прослушивать и сохранять зашифрованный трафик, а также иметь возможность выполнять большое количество запросов от имени жертвы (как было и в случае POODLE), что проще всего достингуть, если внедрять жертве специальный скрипт на HTTP-страницы других сайтов, генерирующий большое количество запросов на интересующий хакера сайт. Кроме того, злоумышленнику необходимо каким-то образом узнать или установить свое значение Cookie, которое бы располагалось близко к искомому значению в передаваемом трафике.

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

Ребята улучшили старую атаку от AlFardan, которая основывается на построении и использовании разброса распределений исследователей из Cisco Fluhrer и McGrew, добавив вариант распределения японских исследователей Takanori Isobe, Toshihiro Ohigashi, Yuhei Watanabe, Masakatu Morii, и скомбинировав их. Текст около искомого Cookie требуется для нахождения Байесовской вероятности.

Если атаку на HTTPS организовать достаточно проблематично, то, в случае с Wi-Fi, цифры более реальные: требуется всего 1 час активной атаки на сеть, после которой получается дешифровать используемый временной ключ, используемый для передачи Unicast-трафика (pairwise transient key, PTK). Атака сильно упрощается за счет наличия криптографически слабой проверки подлинности в TKIP-фреймах. Примечательно, что точки должны периодически (как правило, каждый час) менять этот ключ, однако большинство точек обновляют только ключ, который используется для передачи Broadcast-трафика — groupwise transient key (GTK). В любом случае, уязвимы даже правильно работающие точки, т.к. атака занимает чуть меньше времени, чем требуется для обновления ключа.

Когда компьютеры наконец научатся включать напрямую в мозг, наша жизнь станет значительно интереснее. Вместо смс-ок мы будем получать ментограммы, их вкрадчиво нашепчет внутренний голос. Подумал интересную мысль — поделись с друзьями легким движением мозга! Вспомни, что жена просила купить в магазине; всего за $2.99 без НДС. Несовершенные технологии первых биодискретных интерфейсов будут передавать на компьютер (смартфон, только без экрана) терабайты данных в минуту, оставляя за мощными процессорами будущего работу по вылавливанию крупиц смысла из шума электроимпульсов.

Короче, новейший iPhone 164 будет знать о нас абсолютно все. Переживший уже 34 ребрендинга и 8 реструктуризаций Гугл будет хранить эти данные и перерабатывать дальше в датацентрах, занимающих более 2 процентов поверхности Земли. И только потом, совершив невероятный прорыв в технологиях, начнут думать о том, как эти данные защитить. Только после первого появления сборника эротических снов ничего не подозревающих граждан и гражданок на черном рынке в Бангкоке. Только после скандала с банком, читающим мысли получателей кредита прямо во время подачи заявления. И вот тогда придется всерьез разбираться — что же мы за данные собираем? Как храним?

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

Зачем на картинке подают в голову 5 и 12 вольт? Я не знаю!

Одна из самых резонансных новостей этой недели посвящена черному рынку удаленного доступа к серверам. Эксперты «Лаборатории» исследовали сервис, на котором любой желающий может недорого приобрести информацию для доступа к одному из 70 с лишним тысяч серверов по всему миру по протоколу RDP. Взломанные серверы достаточно равномерно распределены по земному шару, примерно треть приходится на страны, где выбор — максимальный: Бразилию, Китай, Россию, Индию и Испанию.

Ничего не подозревающим владельцам этих серверов наверное будет интересно узнать, что с ними могут сделать злоумышленники, но тут я даже затрудняюсь в выборе, с чего начать. Если коротко — сделать можно все. Дальнейший взлом инфраструктуры жертвы — без проблем. Рассылка спама, DDoS-атаки, криминальный хостинг, кража информации, таргетированные атаки с эффективным заметанием следов — тоже можно. Кража данных кредиток, денег со счетов, бухгалтерской отчетности — да, если взломанный сервер имеет доступ к такой информации. Все это — по смешным ценам: 7-8 долларов за учетку.

XDedic и подобные сервисы (можно предположить, что он такой не один) — это криминальный екоммерс и финтех, он объединяет преступников разного профиля, крутых и не очень, использует современные технологии, предоставляет качественный сервис. Сами украденные данные предоставляют больше 400 продавцов — тут вам и конкуренция, и борьба за увеличение количества взломов. Самый подходящий момент напомнить — вас могут взломать, даже если вам кажется, что ваши данные никому не нужны. Во-первых, нужны, и вам в любом случае не понравится, как их используют. Во-вторых, ресурсы тоже стоят денег, а когда цена вопроса — три копейки, под удар попадают все вплоть до малого бизнеса. Украдут деньги со счета, или дампы кредиток, или хотя бы контакты клиентов для рассылки спама, атакуют через вас другую компанию, а если вообще ничего не выйдет — ну поставят генератор биткоинов и сожрут электричество.

С такими эволюциями киберкриминала трудно бороться, но данное исследование позволяет примерно понять, как это делать.
Все выпуски сериала — тут.

Чтобы сходу понимать материалы об инфраструктуре открытых ключей, сетевой безопасности и HTTPS, нужно знать основы криптографической теории. Один из самых быстрых способов изучить их — посмотреть или прочитать лекцию Владимира ivlad Иванова. Владимир — известный специалист по сетям и системам их защиты. Он долгое время работал в Яндексе, был одним из руководителей нашего департамента эксплуатации.


Мы впервые публикуем эту лекцию вместе с расшифровкой. Начнём с первой части. Под катом вы найдёте текст и часть слайдов.

Перевод статьи, автор – Latacora

В литературе и самых сложных современных системах есть «лучшие» ответы на многие вопросы. Если вы разрабатываете встроенные приложения, то предлагают использовать STROBE и модный современный криптографический стек для аутентификации полностью из одиночных SHA-3-подобных функций губки. Советуют использовать NOISE для разработки безопасного транспортного протокола с формированием общего ключа аутентификации (AKE). Говоря об AKE, есть около 30 различных парольных AKE на выбор.

Но если вы разработчик, а не криптограф, то не должны делать ничего такого. Следует придерживаться простых и обычных решений, которые легко поддаются анализу — «скучных», как говорят люди из Google TLS.