SSLv2, протокол шифрования от Netscape, вышедший в 1995 году и потерявший актуальность уже в 1996, казалось бы, в 2016 году должен быть отключен во всем ПО, использующем SSL/TLS-шифрование, особенно после уязвимостей POODLE в SSLv3, позволяющей дешифровать 1 байт за 256 запросов, и FREAK, связанной с ослабленными (экспортными) версиями шифров.

И если клиентское ПО (например, браузеры) давно не поддерживает подключения по протоколу SSLv2, и, с недавнего времени, и SSLv3, то с серверным ПО не все так однозначно.

Группа исследователей из Тель-Авивского университета, Мюнстенского университета прикладных наук, Рурского университета в Бохуме, Университета Пенсильвании, Мичиганского университета, Two Sigma, Google, проекта Hashcat и OpenSSL обнаружили уязвимость под названием DROWN — Decrypting RSA using Obsolete and Weakened eNcryption, которая позволяет дешифровать TLS-трафик клиента, если на серверной стороне не отключена поддержка протокола SSLv2 во всех серверах, оперирующих одним и тем же приватным ключом.

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

Почему это возможно?

Несмотря на то, что у большинства веб-серверов протокол SSLv2 отключен по умолчанию, и его никто не будет включать намеренно, данная атака позволяет дешифровать TLS-трафик, имея доступ к любому серверу, поддерживающему SSLv2, и использующему такой же приватный ключ, что и веб-сервер. Часто можно встретить использование одного и того же сертификата для веб-сервера и почтового сервера, а также для FTPS.

Общий вариант атаки эксплуатирует уязвимость в экспортных шифрах SSLv2, использующие 40-битные ключи RSA.

Многие современные компьютерные системы (материнские платы в ПК, смартфоны, сетевое оборудование…) работают под управлением прошивки, которая, как правило, разрабатывается под конкретное железо, может использовать весь спектр доступных аппаратных ресурсов и имеет самые высокие привилегии. Защите прошивок необходимо уделять особое внимание, иначе она будет настоящей Ахиллесовой пятой в безопасности системы.
Этому вопросу будет посвящён небольшой цикл статей, мы покажем слабую и сильную модели безопасности прошивок на реальных примерах.

Кстати, в основе этой статьи – наше исследование защищённости промышленных сетевых коммутаторов, которое было представлено мной на конференции по ИБ для практиков ZeroNights 2015 (доклад «Модификация прошивок промышленных свитчей», презентация лежит здесь).

Введение

Давненько мы ничего не публиковали про SAP, и сегодня мы рассмотрим уязвимость, которая затрагивает любое SAP решение от старинного R/3 до новомодной HANA. Имя этой уязвимости – межсайтовый скриптинг (XSS). Статья эта, вопреки нашему обычному повествованию про поиск и эксплуатацию уязвимости, будет по большей части посвящена защите от данной уязвимости.

Межсайтовый скриптинг — одна из самых распространенных уязвимостей вообще, и в продуктах SAP в частности. Так, за 12 лет в SAP было обнаружено 628 XSS-уязвимостей, что составляет 22% от всех уязвимостей в SAP. Только исследователи ERPScan нашли 52 XSS-уязвимости в SAP, и то потому, что больше времени уходило на написание Advisory и бюрократические моменты, чем на непосредственный поиск уязвимостей. Более подробная информация по всем уязвимостям может быть изучена в нашем исследовании "Analysis of 3000 vulnerabilities in SAP", а мы переходим к основной части.

В нашей компании мы постоянно проводим различные исследования (список), выбирая интересную для нас тему и как итог — представляя общественности pdf с результатами.

Данная статья статья как раз из разряда таких исследований. Проводя работы по анализу защищенности мы приводим обычно очень схожие (общие для всех) советы, которым мало следует, некоторые best practices, которые или просто повышают общий уровень защищенности системы (например — применение CSP), или действительно позволяют предотвратить атаку.

Введение

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

Прошло уже три дня с тех пор, как исследователь Parvez Anwar опубликовал информацию о множественных dll hijacking уязвимостях в продуктах Microsoft Office, а какой-либо реакции не наблюдается. Ни CVE, ни сообщений на специализированных ресурсах, Windows Update не качает свежих патчей. Что ж, может, так и нужно, может быть, это не уявимость, а особенность продукта?
Между тем, эксплуатация этой особенности проста и доступна даже ребенку. И, раз уж производитель пока эту «фичу» не удалил, почему бы не написать о ней небольшую статью.

Речь пойдет о Windows 7. Работает ли это на других версиях — мне на текущий момент неизвестно, нужно проверять. Принцип действия описываемого явления (как и многих других, впрочем) основан на старой доброй технологии COM/OLE/ActiveX.

Здравствуйте!

Данный пост является ответом на недавнюю публикацию на ресурсе Хабрахабр от российского представительства компании Cisco.

Автор – тот самый «незрелый» и «начинающий» исследователь из компании Digital Security, упомянутый в статье представителя Cisco.

Странно, представительство столь известной компании позволяет себе использовать в официальном блоге столь низкий слог, а также дает комментарии, основываясь на поверхностных выводах, а не на технических деталях. Давайте посмотрим, что же такого сделал наш исследовательский центр, и с чем не смогли или не захотели разбираться специалисты Cisco.

* — в статье пойдет речь только про Samsung SmartTV


Изображение с mnn.com

«Please be aware that if your spoken words include personal or other sensitive information, that information will be among the data captured and transmitted to a third party.»

Соглашение о конфиденциальности Samsung SmartTV (до февраля 2015 года)

The telescreen received and transmitted simultaneously. Any sound that Winston made, above the level of a very low whisper, would be picked up by it; moreover, so long as he remained within the field of vision which the metal plate commanded, he could be seen as well as heard. There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.

«1984» — роман-антиутопия Джорджа Оруэлла, изданный в 1949 году

Вступление

Буквально на прошлой неделе прошла конференция ZeroNights, про которую мы так много писали на Хабре (еще не опубликован финальный отчет, надо дописать). И кроме всего прочего, там я прочитал доклад про Samsung SmartTV, рассказав, что может быть, если при проектировании подобных мультимедийных платформ руководствоваться интуитивно наиболее близкими и легкими решениями (раскроем эту тему это очень подробно). Формат повествования был выбран хронологический, т.е. как я и что смотрел и как прорабатывал решение, будь бы я инженером подобного устройства.

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

Конечно, вы слышали о двух хакерах, которые перехватили управление джипом, ведь об этом писали все. Я хотел копнуть глубже и предположить, что не именно эта, но другие схожие проблемы могут быть не случайными, а запланированным результатом атаки. То есть, теоретически, атакующий может намеренно внедрить уязвимость в продукцию. Хотя пока это больше напоминает сценарий новой серии Мистера Робота, но скандал, связанный с другим крупным автоконцерном, Volkswagen, показывает, что подобную атаку вполне можно провернуть и в реальности (окей, если не сейчас, то уже в ближайшем будущем).

Привет!

До конференции ZeroNights, о которой мы уже не раз писали на Хабре, остаются считанные дни!

Одним из последних наших постов был рассказ про HackQuest. Он успешно прошел и пришло время о заданиях и о том, как их решали. И конечно же — поздравить победителей!

• 1 день, задание “Chocolate Factory” (web) — cdump и BlackFan
• 2 день, задание “HSM V1.0” (web, crypto, hash cracking) — Abr1k0s
• 3 день, задание “BAZAAR NG” (web) — AV1ct0r
• 4 день, задание “ILLOGICAL PHOTOGALLERY” (web, oauth) — Beched
• 5 день, задание “CRACKME” (reverse) — sysenter
• 6 день, задание “BANK ROBBERY”, (phreaking, web) — dr.glukyne
• 7 день, задание “BLINK2PWN”, (reverse, binary pwn) — mr_dawerty

До старта конференции ZeroNights 2015 остается 2 недели

Друзья, вот мы и подошли к финишной прямой. До нашей с вами встречи осталось всего две недели! Программа конференции полностью сформирована, на нашем сайте размещено итоговое расписание двух дней, с ним вы можете ознакомиться здесь: 2015.zeronights.ru/assets/files/ZNagenda2015.pdf.
Ну а мы кратко опишем те выступления, о которых еще не рассказывали вам прежде, чтобы вы знали, чего ждать от предстоящего события. Итак, по порядку.

В пятый юбилейный раз мы проводим конференцию по практической информационной безопасности (пройдет 25-26 ноября в Москве, 2015.zeronights.ru).

Традиционно мы проводим перед ней хакквест, предлагая всем желающим порешать задания связанные с reverse engineering'ом, веб-хакингом, пентестом, анализом протоколов и т.п. вещами.

Наверное, многие в России уже соскучились по хорошей, хардкорной хакерской атмосфере и докладам. Докладам, которые не просто интересно послушать, но и полезно как для защиты, так и для атаки. Но не грустите: 25-26 ноября в Москве в пятый раз состоится конференция ZeroNights ;) Часть программы уже известна, и мы рады представить вам ее. Так что добро пожаловать под кат.

Меня зовут Дмитрий Частухин, и я уже долгое время занимаюсь информационной безопасностью различных софтверных решений для Enterprise. В основном, это, конечно, разнообразные продукты компании SAP (можно почитать предыдущие мои посты на эту тему тут, тут или тут).

Сегодня же мы с вами заглянем под «капот» SAP Afaria – MDM-решения от известного немецкого софтверного гиганта. Устраивайтесь поудобнее и откидывайтесь на спинку кресла (пожалуйста, будьте аккуратнее, если вы сидите на стуле).

Мне хотелось бы поведать сегодня итоги своего небольшого исследования, связанного с протоколом TACACS+, причём именно с пентестерской точки зрения. Использовать протокол по прямому мне не приходилось, так что каких-то тонкостей могу не упомянуть.

Что такое TACACS+

Terminal Access Controller Access-Control System Plus (TACACS+) — специальный протокол от Cisco для AAA (authentication, authorization, and accounting). То есть это протокол для централизованного управления доступом – чаще всего доступом именно к Cisco, но можно прикрутить что-то еще.

Итак, обычно поднимается один-два сервера с TACACS+ сервисом на 49 порту протокола TCP, а на всех устройствах настраивают его использование. Таким образом, когда пользователь хочет аутентифицироваться на свитче, роутере или другом устройстве, устройство пересылает его аутентификационные данные на TACACS+ сервер, где их проверяют, и принимается решение о разрешении доступа, о чём и сообщается в ответных пакетах



Удобно, централизовано. Можно настроить различные привилегии для различных пользователей на различных устройствах. Есть логирование доступа и действий на серверной стороне. Можно прикрутить поверх другую централизацию доступа, типа AD или LDAP'а. Есть open source реализации сервера (Cisco когда-то официально выложила код).

Сегодня мобильные технологии – неотъемлемая часть нашей жизни, и иногда проникают туда, где их не следовало бы использовать. Удобство часто оказывается важнее безопасности. Сейчас можно отслеживать состояние АСУ ТП (автоматизированной системы управления технологическим процессом) или даже управлять ей с новенького смартфона на Android или iOS. Поищите “HMI” (человеко-машинный интерфейс), “SCADA” (система диспетчерского контроля и сбора данных) или “PLC” (программируемый логический контроллер) в магазине Google Play, и вы удивитесь количеству результатов. Более того, многие из этих приложений разработаны серьезными производителями: Siemens, GE, Omron и т. д., и обеспечивают доступ, контроль и управление HMI, PLC, DCS (распределенная система управления) и SCADA-системами в инфраструктуре АСУ ТП. Безопасны ли они? Может ли злоумышленник нанести вред, получив доступ к планшету инженера-технолога? Какие уязвимости существуют в этих приложениях? Какие векторы атак возможны?

С 1995 г. в продуктах Oracle было найдено 3896 уязвимостей, и их количество продолжает расти. Исследовательский центр Digital Security занимается поиском проблем безопасности в системах Oracle уже почти 10 лет, найдя за это время массу всевозможных уязвимостей во всей линейке их продуктов, включая разнообразные опаснейшие архитектурные баги. Некоторые из них исправлялись вендором около 3 лет после нашего уведомления (!). Поэтому с Ораклом мы знакомы не понаслышке.

Скандал, который разразился вчера в мире немедленно после публикации и последующего удаления – по словам вице-президента и главного архитектора Oracle Эдварда Скривена (Edward Screven), запись «не отражала истинных взглядов компании на взаимоотношения с пользователями», – этой записи в блоге CSO компании Oracle Мэри Энн Дэвидсон (Mary Ann Davidson), на самом деле достаточно поучителен. В нем прекрасно проявилась вся боль вендоров, все их реальное отношение к безопасности продуктов.

Наилучшей иллюстрацией здесь мог бы быть фильм с Мэлом Гибсоном «Чего хотят женщины?» Исследователи безопасности и заказчики – внимательно прочтите, что же на самом деле думает об исследованиях главный безопасник Oracle и как на самом деле она относится к безопасности своих продуктов. При этом следует понимать, что она говорит то, что другие вендоры просто не решаются сказать. Они благодарят исследователей за найденные уязвимости, мило улыбаются заказчикам, а внутри себя тихо ненавидят и тех и других. «Не трогайте наши продукты!», «Согласно лицензии, вы не имеете право на реверс-инжиниринг!» – это дословно ее высказывания. «Отстаньте уже от нас со своей безопасностью, мы сами разберемся», – вот что на самом деле думают вендоры. И как они сами «разбираются», по три года закрывая опаснейшие архитектурные уязвимости (в частности, с аутентификацией на клиенте!), мы отлично знаем. Что интересно, особенно этим славится именно компания Oracle. И теперь неудивительно почему – при таком-то отношении ее главного безопасника. Однако все-таки дело не в Oracle – и это самое важное. Их CSO просто выразила мнение всех вендоров, сказала то, что не принято говорить открыто. Это наглядная демонстрация реального отношения всех вендоров к безопасности. Что бы кто угодно из них ни говорил, – думают они именно это.

И это страшно.

Поражает и то, что CSO Oracle не знает, что большинство уязвимостей находятся вовсе не реверсингом. Oracle может смело менять слоган со старого – «Несокрушимый» – на современный: «Неприкасаемый».

Исследователи 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). В любом случае, уязвимы даже правильно работающие точки, т.к. атака занимает чуть меньше времени, чем требуется для обновления ключа.

Passwords, passwords never change...
Почти каждый пользователь сети Интернет имеет хотя бы один аккаунт или хотя бы однажды оставлял свои данные в различных службах. Почтовые сервисы, социальные сети, облачные хранилища, онлайн-игры и многое другое, – в одном Facebook уже более 1 млрд учетных данных. Естественно, что, имея большую аудиторию, компании стараются обеспечивать хорошую защищенность своих серверов и сервисов. Однако, если пользователи не прилагают усилий к защите своих аккаунтов и вообще не соблюдают минимальных мер информационной безопасности, все усилия извне могут оказаться напрасны.

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

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

Интро

Не так давно я выступал на конференции FrontendConf 2015 (РИТ++) с темой данной статьи. И при подготовке доклада начал искать информацию, а кто вообще выступал на данную тему и что есть в Сети на данный момент.

Оказалось, что информации совсем немного, более-менее можно было бы отметить доклад mikewest.org/2013/09/frontend-security-frontendconf-2013 от Mike West из компании Google, но какой-то «непентестерский» взгляд и уж совсем мало материала. И www.slideshare.net/eoftedal/web-application-security-in-front-end где тема раскрыта более детально, но выступление 2011 года. А за 4 года технологии и атаки на месте не стояли.

Долго и сложно выбирая темы, что же все-таки рассказать разработчикам фронтендов про безопасность, при этом минимум касаясь бекэнда (местами все-таки это неделимо), получился доклад, а здесь — его текстовый пересказ.

О чем вообще разговор?

А действительно, о чем тут вообще можно разговаривать? Говоря про взломы и безопасность невольно приходят в голову тезисы — слили базу, получили доступ к выполнению команд ОС на сервере, прочитали чужую переписку. Но это все — server side код. А что ж может «нагородить» фронтэндер? Главная опасность, конечно же, в обходе атакующим SOP — Same Origin Policy, главной политики безопасности браузеров, которая регулирует работу в разных Origin. Но не только, давайте разбираться.