пятница, 26 октября 2012 г.

Новости ИБ за 22 – 26 октября 2012 года

Блоги:
«The Risks of Trusting Experts». Брюс Шнайер.





Статьи:
«Брутфорс TrueCrypt заработал на образах дисков». Журнал «Хакер».



«Смертельная» USB-флэшка». Журнал «Хакер». Про эксплоит в Windows 7 с NTFS

 Вебинары:

01 ноября 2012 г. в 14:00, «Взломать сайт на ASP.NET? Сложно, но можно» от Positive Tehnologies.

Ресурсы:
Видео и презентации с Yet another Conference 2012 (см. раздел «Безопасность»).

Антифишинг.ру – онлайн-проект, целью которого является противодействие фишингу и распространению вредоносных программ.

«On Free Log Management Tools». Dr.Anton Chuvakin. Бесплатные решения для управления лог-файлами.

среда, 24 октября 2012 г.

SchoolCTF-2012

28 октября 2012 года с 14:00 до 18:00 по томскому времени (UTC+7) (т.е. с 11:00 до 15:00 по московскому) пройдут ежегодные соревнования по защите компьютерной информации для школьников - School CTF, организованные Томским государственным университетом в рамках Дней науки.

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

Зарегистрироваться на SchoolCTF-2012 (в правом верхнем углу). 

Источник: http://blackbox.sibears.ru/newsblog/schoolctf-2012annonce/

пятница, 19 октября 2012 г.

Новости ИБ за 12 – 19 октября 2012 года



Блоги:
«Сертифицированные межсетевые экраны (часть 6 и часть 7)». Тарас Злонов.

«Идеальная конференция по ИБ». Алексей Лукацкий.


«Обо мне, критике и регуляторах». Алексей Лукацкий.


«Чего не могут короли?». Алексей Волков. Ответ ФСТЭК на вопрос «Могут ли представители этой службы  проверять техническую защиту "негосударственных" ИСПДн и нужна ли для обработки ПДн лицензия на техническую защиту конфиденциальной информации?»

Статьи:
«Беззубые антивирусы или как разрушалась сталь».

«Системный эксплойт для Windows 7». Журнал «Хакер».


«Высший арбитражный суд запретил немотивированно «закрывать» процессы». Сергей Подосенов.


Законодательство:
Приказ Федеральной службы по оборонному заказу от 23 июля 2012 г. N 100 "О защите персональных данных федеральных государственных гражданских служащих Рособоронзаказа"

Ресурсы:
Wasm – проект, посвященный программированию, отладкt и дизассемблированию.

Virus Total Scanner – утилита для быстрой антивирусной проверки файлов по базе virustotal.com

четверг, 18 октября 2012 г.

Browser Security Handbook. Глава 1, пункт 3


Руководство по безопасности браузеров (Browser Security Handbook). Глава 1

2. Unicode в Url

 


3.         Подлинные URL-протоколы

URL-протоколы указывают общую схему для получения данных и способ обработки для отображения этих  данных. Схемы также могут быть привязаны к конкретным значениям некоторых URL-полей, определенных по умолчанию, например, к TCP-порту или нестандартному синтаксическому правилу разбора URL (последним, обычно, обозначается отсутствие символов «//» после схемы идентификатора).
Еще в 1994 году RFC 1738 выложил несколько URL-протоколов для просмотра веб-страниц. Некоторые из них изначально не обрабатывались браузером или устарели.
С развитием интернета появилось несколько новых открытых и собственных протоколов. Начали различаться и наборы протоколов, поддерживаемые различными браузерами. RFC 2718 попытался определить некоторые основные правила для создания новых протоколов. RFC 4395 постановила, что новые протоколы должны быть зарегистрированы в IANA (список зарегистрированных протоколов). Однако некоторые отказались следовать по этому пути.
Для широкого обзора возможностей современных браузеров URL-протоколы можно условно разделить на 2 группы: «Поддерживаемые программным обеспечением» и «Поддерживаемые плагинами, расширениями, или сторонними программами». Протоколы, которые относятся к списку из первой группы, отражены в таблице 3.
 Таблица 3

Название протокола
MSIE7
MSIE8
FF3
Safari
Opera
Chrome
Android
HTTP (RFC 2616)
ДА
ДА
ДА
ДА
ДА
ДА
ДА
HTTPS (RFC 2818)
ДА
ДА
ДА
ДА
ДА
ДА
ДА
SHTTP (RFC 2660)
как HTTP
как HTTP
НЕТ
НЕТ
НЕТ
НЕТ
НЕТ
FTP (RFC 1738)
ДА
ДА
ДА
ДА
ДА
ДА
НЕТ
file (RFC 1738)
ДА
ДА
ДА (частично)
ДА (частично)
ДА
ДА
НЕТ
Gopher (RFC 4266)
НЕТ
НЕТ
ДА
НЕТ
исчез?
НЕТ
НЕТ
НЕТ
НЕТ
НЕТ
НЕТ
ДА
НЕТ
НЕТ
 
Эти протоколы могут быть использованы для доставки исходного содержимого, которое интерпретируется и выполняется с помощью правил безопасности реализованных в браузерах.
Другой список сторонних протоколов, направленных в другие приложения, сильно зависит от конфигурации системы. Набор протоколов и их обработчики, как правило, содержаться в отдельном общесистемном реестре. Браузеры, по умолчанию,  имеют белые списки (выполнение внешних программ без запроса) или черные списки (запрет на их использование в целом). К наиболее распространенным протоколам этой группы относятся:

acrobat
Acrobat Reader
callto
обмен мгновенными сообщениями, ip-телефония
daap/itpc/itms/...
Apple iTunes
FirefoxURL
Mozilla Firefox
hcp
Microsoft Windows Help
ldap
функциональные возможности адресной книги
mailto
почтовые агенты
mmst/mmsu/msbd/rtsp/...
потоковые мультимедийные сообщения
mso-offdap
Microsoft Office
news/snews/nntp
новостные клиенты
outlook/stssync
Microsoft Outlook
rlogin/telnet/tn3270
telnet-клиент
shell
Windows Explorer
sip
программное обеспечение для ip-телефонии

Новые обработчики могут быть зарегистрированы в ОС и специфическим для приложения способом, например, путем регистрации нового ключа в реестре Windows по адресу HKCR\Protocols\Handlers или добавлением в настройки Firefox network.protocol-handler.*.
Как правило, протоколы из последней группы не выполняются внутри визуализатора (рендерера) при обращении к элементам документа, таких как изображение, скрипт или апплет источников и т.п.; они работают как <IFRAME> или целевая ссылка, и при необходимости будут запускать отдельные программы. Эти программы иногда могут объединяться с рендерером, но правила, по которым они отображают содержимое и налагают ограничения безопасности, обычно, не связаны с браузером.
Такие сторонние протоколы можно внедрить в ссылки при уязвимых внешних программах, которые регистрируют обработчики протокола без согласия пользователя. Поэтому, по возможности, лучше отклонять непредвиденные протоколы и проявлять осторожность при внедрении нечто неожиданного на стороне клиента (в том числе и наблюдение за безопасной передачей допустимых параметров).

пятница, 12 октября 2012 г.

Новости ИБ за 08 – 12 октября 2012 года



Блоги:
«И вновь о безопасности МФУ». Алексей Лукацкий.

«Обещанный эксклюзив - ISM:МАРКЕТ». Александр Бондаренко.

«Общее. Материалы с мероприятий по ИБ за сентябрь-октябрь». Сергей Борисов.


Статьи:


Вебинары:
15 октября 2012 г. в 11:00 “Изменения законодательства по защите ПДн. Как реализовать новые требования?” от «Код Безопасности». Зарегистрироваться.


16 октября 2012 г. в 11:00 «Практические аспекты выполнения ФЗ о персональных данных» от «Диалогнаука»


Ресурсы:

Rdot.org - форум по информационной безопасности

вторник, 9 октября 2012 г.

Новости ИБ за 28 сентября - 08 октября 2012 года



Блоги:
«Разъясняй и властвуй». Алексей Волков. Советы по общению с регуляторами.

«Если вас взломали, то это еще не значит, что вам нельзя помочь!». Алексей Лукацкий. Про инструкцию по реагированию на инциденты от Group-IB.

«А у вас есть лицензия на гостайну? Нет?! Может пора задуматься?». Алексей Лукацкий.

«Что такое SIEM?». Олеся Шелестова.

«Беспечность в социальных сетях может дорогого стоить!». Александр Бондаренко.

Статьи:
«Аудит информационной безопасности: какой, кому, зачем?». Алексей Лукацкий.


«Digital Security предупреждает о новом виде атак на корпоративные системы». Cnews

«NIST принял решение: SHA-3 будет использовать алгоритм Keccak». Илья Сименко.

«Internet Explorer оказался самым безопасным браузером». Cnews.
  

Вебинары:
10.10.2012 в 11:00 состоится вебинар «Защита информации в национальной платежной системе» от компании ЛЕТА. Докладчики: Бурцев Игорь, Малюшкин Константин.


Ресурсы: 
Материалы с вебинара «Безопасность веб-приложений: starter edition».

четверг, 4 октября 2012 г.

Юмор. Документик. Семен Альтов

Документик. Семен Альтов.

У входа стоял человек с кобурой .
Преградив путь, сказал:
-Ваши документы!
Я ответил:
-Мои.
-Проходи!
При этом даже не посмотрел документы.
Так продолжалось неделю.
-Ваши документы!
-Мои.
-Проходи!
И вдруг ни с того, ни с сего:
-А ну покажите!
Я протягиваю.
Он долго смотрит на фотографию, на меня, опять на фотографию, опять на меня. Показывает мне документ. А там тетка мало того, что голая, так еще и спиной!
Он спрашивает:
-Это ваши документы?
-Вы же видите. Документы не мои, они судя по всему женские.
Он говорит:
-Правильно. Проходи!
И так месяц. Он меня спрашивал: ”Ваши документы?” Я показывал чужие документы и честно говорил: ”Не мои.”
-Проходи...
И вдруг дурацкий вопрос:
-А чьи?
-Понятия не имею. Можно пройти?
- Нельзя! Узнайте, чьи документы, тогда пройдете!
-Но вы же пускали, зная, что не мои, почему вдруг се -годня...
Он руку на кобуру:
-Я здесь для чего стою?!
-На знаю.
-И я не знаю. Но наверно, поставили не просто так! Для проверки документов.
- Так вы их и проверили! Установили: документы не мои!
-Значит, я свой долг выполнил... Проходи!

вторник, 2 октября 2012 г.

Browser Security Handbook. Глава 1, пункт 2

Руководство по безопасности браузеров (Browser Security Handbook). Глава 1

1. Унифицированный указатель ресурса (URL)

 

2.         Unicode в Url

Некоторые технологии, связанные с перемещением веб-контента и Url-адресов, не имеют особого набора символов, определенных соответствующим RFC. В RFC-3986 сказано: «На местном или региональном уровне, а также с усовершенствованием технологии, пользователи могут воспользоваться возможностью применения широкого диапазона символов; такое использование не определенно в настоящей спецификации». Тот же пренебрежительный подход принят в спецификации http-заголовка.
В результате, в контексте web-страницы, любой старший бит пользовательского ввода, может и должен быть использован как %nn-последовательности, но нет конкретных указаний о том, как перекодировать введенный пользователем адрес в собственную кодовую страницу системы, общаясь с другой стороной, которой не может передать эту кодовую страницу. Системе, которая использует кодировку UTF-8 и получает URL, содержащий Unicode в пути, соответствует исходная последовательность 0xC4 0x85. Однако, при отправке на сервер, который использует ISO-8859-2, исправленное значение должно послать 0xB1 (или, в качестве альтернативы, должна быть включена дополнительная информация о кодировке на клиенте, чтобы осуществить преобразование на стороне сервера). На практике же, большинство браузеров, по умолчанию, отправляют данные в кодировке UTF-8 на любой, введенный вручную в поле URL, текст, и используют данную кодировку страницы на всех последующих ссылках.
Еще одно ограничение Url прослеживается в DNS. RFC 1035 позволяет использовать в метках DNS только символы A-Z a-z 0-9 и «.», использующуюся  в качестве разделителя; распознаватель[4] позволяет использовать дополнительно подчеркивание « в DNS-именах, что нарушает стандарт. С развитием Всемирной паутины,  появилась необходимость в именах хостов использовать символы нелатинского алфавита. И использование %nn-кодирования это не альтернатива, потому что %, как такового, не было в списке.
Чтобы решить эту проблему, RFC 3490 изложила довольно надуманную схему кодирования, которая допускает Unicode-символы хранить в DNS-метках, и RFC 3492, описывающий конкретные реализации в DNS-метрике, часто называемый «Punycode», который обозначается следующим образом:

xn--[US-ASCII-часть]-[закодированные данные в Unicode]

Браузер, поддерживающий Punycode, преобразовывает неизвестные символы, содержащиеся в доменном имени, в последовательность ASCII-символов, а затем выполняет обычный DNS-поиск в кодированной строке.
Ниже показан пример преобразования в Punycode:


Соответствующие ключи безопасности различные в старшем бите URL-обработки приведены в таблице 2.

Таблица 2

Описание
MSIE7
MSIE8
FF3
Сафари
Опера
Хром
Android
Требование к кодировке URL-пути, когда следуют обычные ссылки
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
Требование к кодировке строки запроса URL, когда следуют обычные ссылки
кодировка страницы
кодировка страницы
кодировка страницы
кодировка страницы
кодировка страницы
кодировка страницы
кодировка страницы
Требование к кодировке URL-пути для XMLHttpRequest- запроса
кодировка страницы
кодировка страницы
кодировка страницы
кодировка страницы
кодировка страницы
кодировка страницы
кодировка страницы
Требование к кодировке строки запроса URL для XMLHttpRequest-запроса
кодировка страницы
кодировка страницы
кодировка страницы
искалечен
кодировка страницы
искалечен
искалечен
Требование к кодировке URL-адресов, введенных вручную
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
Требование к кодировке строки запроса URL, введенных вручную
перекодирование в 7-бит
перекодирование в 7-бит
UTF-8
UTF-8
голый?
UTF-8
UTF-8
Необработанные данные Unicode в именах хостов автоматически преобразовываются в Punycode?
ДА
ДА
ДА
ДА
ДА
ДА
НЕТ
«Процент-кодирование» на основе UTF-8 в именах хостов автоматически преобразовываются в Punycode?
ДА
ДА
на повтор
ДА
ДА
ДА
НЕТ
Отображение адресной строки Unicode в имени хоста
Unicode
Unicode
Unicode
Unicode
Unicode
Unicode
Punycode
Отображение адресной строки Unicode за пределами имени хоста
Unicode
Unicode
Unicode
Unicode
как?
Unicode
n/a


ПРИМЕЧАНИЕ 1: Firefox, как правило, использует кодировку UTF-8 для кодирования большинства Url, но будет посылать символы, поддерживаемые ISO-8859-1, с помощью данной кодовой страницы.
ПРИМЕЧАНИЕ 2: Для защиты от фишинга многими браузерами вводятся дополнительные ограничения на использование некоторых или всех символов Unicode в некоторых доменах верхнего уровня.