пятница, 10 сентября 2010 г.

Политика управления персональными паролями, часть вторая. Краткий ликбез по парольной защите: устойчивость пароля.

Предыдущая часть:
Политика управления персональными паролями, часть первая. Определяем проблему.

-- Диктую... Вначале цифры. Семь. Четыре. Шесть. Ноль. Шесть. Два.
Четыре. Семь. Теперь буквы. W. H. O. Все прописные. d. s. Все строчные.
Снова цифры. Один. Три. Шесть. Восемь. Один. Строчная y. Прописная Z.
Символ доллара. Собака.
-- Которая в адресах? Или слово собака? -- деловито спрашивает Пат.
-- Значимые слова в шифрах используют только ламеры, -- говорю я. --
Знак, конечно. Теперь три открытые скобки, цифра восемь. И восклицательный знак.
(c) "Фальшивые зеркала", Лукьяненко С.
   Для начала, давайте разберемся с тем, какие же меры обеспечения безопасности собственных паролей доступны рядовому пользователю и каким образом пользователь может их применять. Таких мер всего три: обеспечение устойчивости паролей к взломам методом грубого (полного) перебора и перебора по словарю, посильное обеспечение безопасности каналов передачи и восстановления паролей и обеспечение безопасности мест хранения паролей. В этой заметке, мы рассмотрим первую из них...

четверг, 9 сентября 2010 г.

Политика управления персональными паролями, часть первая. Определяем проблему.

Shors (VICTOR): кто нить номер маей аськи помнит
Shors (VICTOR): вот ведь засада после форматирования винта
Shopen (SHOPEN): xxx-xxx-xxx
Shors (VICTOR): вооо спасибо Ваня
Shors (VICTOR): дружищщще
Shors (VICTOR): выручил
Shopen (SHOPEN): пароль надо? )
(с) bash.org.ru
   К написанию этой заметки меня подвигло обсуждение вредных советов для разработчиков парольной аутентификации, опубликованное мной на RSDN несколько дней назад, равно как и периодически всплывающие там же, в различных форумах, вопросы о защищенности информационных систем, основанных на парольной аутентификации.

суббота, 3 июля 2010 г.

Использование DEP и ASLR в популярных продуктах

Ребята из Secunia подготовили отчет об использовании технологий DEP и ASLR в некоторых популярных программных продуктах, а именно: Adobe Flash Player, Sun Java JRE, Adobe Reader, Mozilla Firefox, QuickTime Player,  VLC Media Player, Apple iTunes, Google Chrome, Adobe Shockwave Player, OpenOffice.org, Google Picasa, Foxit Reader, Opera, Winamp, RealPlayer и Apple Safari.

Получившаяся картина, по состоянию на июнь 2010, не выглядит обнадеживающей:


Из чего следует, что среди этих продуктов все хорошо только у Google Chrome, что не может не радовать, но и весьма огорчает в отношении остальных объектов данного анализа. Жаль также, что несмотря на упоминание в отчете "широкого использования преимуществ этих технологий в большинстве продуктов Microsoft", более подробной информации по ним, увы - нет. Было бы интересно взглянуть, особенно в разрезе существования для каждого из продуктов MS публично-доступных эксплоитов, позволяющих обойти эти технологии ;)

Подробный отчет доступен на сайте Secunia.

четверг, 4 февраля 2010 г.

Null/Third-party domain XSS в Google Chrome 5.x и ниже

Давеча, играясь с XSS-фильтрами в IE8 и Chrome, обнаружил сабж. Хромовский XSS Auditor пропускает javascript, запущенный через внедрение тега <IFRAME> в контент сайта, подверженного XSS уязвимостям первого типа. Попутно выяснилось, что вместо загрузки в <IFRAME> своего HTML с payload-скриптом, можно просто использовать самодостаточный XSS на базе протокола data:

Живое демо на примере одного из очередных казино-лохотронов:

XSS через загрузку HTML
XSS через data: протокол

Памятуя об обещанных 500$ за каждую некритическую уязвимость в Chrome/Chromium, сообщил о ней куда следует и, после короткого диалога с разработчиками Chrome выяснилось, что они не считают это уязвимостью XSS Auditor, т.к. в данном случае у атакующего отсутствует возможность выполнять скрипт в контексте домена уязвимого сайта, а следовательно – XSS-уязвимостью это не является и в scope XSS-Auditor’а не попадает. Забавно то, что в scope XSS-фильтра IE8 этот вектор вполне себе попадает и успешно блокируется, также как и в фоксовом NoScript’е.

В сухом остатке, мы имеем на руках:

  • отраженную HTML-injection, позволяющую через специально-сформированную ссылку внедрить в контент уязвимого сайта как произвольный javascript (что является риском даже безотносительно домена, в котором выполняется скрипт, вообще-то), так и произвольный binary-контент, например, pdf/swf/doc с эксплоитом очередной уязвимости обработчиков этих форматов;
  • отказ разработчиков браузера фиксить эту уязвимость;

К.О. также подсказывает, что в то же время мы не имеем на руках обещанных 500$… да ну и фиг с ними. Обидно то, что в используемом браузере обозначилась дыра, которая будет существовать в нем еще очень и очень долго, судя по всему :(

UPD: Так и не признав данный вектор уязвимостью, Google все же по-тихому исправили ее где-то к 12-ой версии Chrome :LOL:

среда, 20 января 2010 г.

Многообещающее начало

"Путешествие в тысячу миль начинается с одного шага", справедливо заметил однажды китайский философ Лао Цзы. И вот, решившись на маленький, но столь важный шаг в деле блоговедения, я тут же нечаянно нарвался на активный XSS прямо здесь, в еще не родившемся блоге, о чем красноречиво пока еще свидетельствует уже не свидетельствует покореженная шапка в самом верху страницы. Всему виной - невинная идея построить название блога на базе широко используемого вектора для быстрого теста на подверженность XSS'ам, что должно было символизировать предметную область, ради которой все это, собственно, и затевалось. Впрочем, покореженная шапка символизирует не меньше, и так, пожалуй, даже симпатичнее. Посему - решил считать это хорошим началом и признаком того, что направление для первого шага я выбрал верное :)