Аудиты соответствия и тесты на проникновение снова

Снова думал о аудитах соответствия и пентестах, что-то раньше писал.
Пришел к выводу, что для эффективности моего подхода к безопасности проверять мне надо две вещи: 

1. что мое окружение (мои информационные системы, мои админы, мои пользователи) делает все в соответствии с тем, что я считаю безопасно,
2. то, что я считаю безопасно действительно безопасно с учетом современности.

Первое проверяется аудитом соответствия, второе - пентестом.
Первым прогарантирую, что мои контроли работают эффективно(effectively & efficiently), вторым - что мои контроли адекватны реальности.
Первое надо делать почаще (думаю, где-нибудь раз в квартал), второе - можно пореже (раз в 2-3 года - нормально).

Безопасность "на коленках"

Сегодня выступали на конференции.

 Выкладываю презентацию.

How to catch your “hacker” or makeshift security from Sergey Soldatov

Хочется буквально пару слов сказать о мотивации. Изначально мы чувствовали себя как-то некомфортно среди реальных хакеров, которые разобрали по байтам сложнейшие системы, исследовали сложнейшие сетевые протоколы, обходили навороченные защиты и т.п. Тогда как мы планируем рассказывать о вещах, которые доступны для проверки и настройке любому, кто умеет пользоваться компьютером, а мотив подготовки к выступлению исключительно чтобы бесплатно туда попасть не представлялся этически правильным. 
Но все решил первый день. Во-первых я понял, что далеко не все на конференции крутые хакеры, есть достаточно много студентов, много только начинающих вставать на путь ИБ, а следовательно, наряду с тяжелыми докладами должны быть и легкие, иначе, это будет несправедливо по отношению к ребятам. Далее, все что написано в презентации достаточно просто проделать самому, поэтому это может служить неким практикумом что ли. В-третьих, в презентации приведено решение, которое, несмотря на свою бесплатность и "наколеночность" эффективно работает в боевых условиях не хуже дорогущих SIEM-ов, причем, за всю историю использования SEC-а я не смог придумать корреляционного правила, для описания которого мне не хватило бы его синтаксиса (стоит признаться, что SEC позволяет вставлять в обработчики полноценные куски кода на Perl которому доступны параметры события, что делает возможности по корреляции безграничными). Последнее (если ничего не забыл) - в конце первого дня была дискуссионная панель об исследователях и исследованиях, где обсуждалась идея о том, что ресеч никому не нужен... Нет, это не так, поскольку:
1. только благодаря этим, никому не нужным, ресечерам, даже не важно на какой стороне, мы из года в год повышаем безопасность. Старые уязвимости, как и многие старые болезни человечества, ушли в далекое прошлое и сейчас многие принципы безопасности, которые ранее были открытием, сейчас считаются очевидными вещами.
2. лично для меня лучшая мотивация - это видеть результат моей работы. Только жажда результата заставляла меня в свое время сидеть по ночам и писать какие-то программки. А когда желаемый результат наступает остается приятное ощущение маленького подвига. Это может казаться смешным, но в моем случае это так и, лично я, готов многое отдать за это короткое счастье. Могу предположить, что талантливые ресечеры имеют такой же маленький секрет, поскольку уверен, что шедевры не пишутся за деньги, ну, по крайней мере, лично я на внутренней увлеченности уеду намного дальше, чем за деньги. Самим ресечерам нужен ресеч.
3. Есть разные ресечи и почти все они нужны. Не только академические ресечи (которые не финансируются, как правило) есть, есть и сугубо практические, результат которых сразу начинает использоваться. Например, вам нужно выбрать для себя решение DLP. При этом все вендоры вам скажут, что они лучшие (скажу более, не всегда присейлы знают возможности своих продуктов хорошо - надо смотреть). Опыт показывает, что для успешности выбора надо со всеми с ними поиграться какое-то время, только после этого будет более или менее объективное мнение. Чем не ресеч? В свое время я это делал, с финансированием этой задачи проблем не было.
Ну и самое последнее (о чем мы упомянули в речи), в основном все доклады были посвящены (как это почему-то и принято на хакерской конференции) способам и средствам атак, тема защиты представлена довольно скудно. Вот мы и решили этот пробел заполнить и посвятить презентацию именно обороне, а не нападению, как большинство.

Кто же это был?

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

S/MIME в Microsoft

Продолжая криптографическую тему хочется отметить некорректности вот этой статьи (Outlook S/MIME certificate selection):
http://blogs.technet.com/b/pki/archive/2008/12/17/outlook-s-mime-certificate-selection.aspx

Достаточно много народа на нее ссылались, поэтому тема ее неточностей - актуальна.

"When sending an encrypted eMail, Outlook actually requires two certificates. One certificate is owned by the recipient and one is owned by the sender. The recipient’s certificate is used by the sender for encrypting the eMail which is sent out. The sender’s certificate is used by the sender to encrypt the eMail that is stored in the Sent Items folder in Outlook"

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

На самом деле это не так: письмо шифруется один раз на ключах всех получателей и на ключе отправителя. Цитата из RFC3851, раздел 3.3:

"Step 2. The MIME entity and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [CMS] Section 6)."

Из сего факта есть интересно следствие, что, будучи получателем письма, я могу залезть в ящик к отправителю и прочитать отправленное мне письмо своим ключом. Это может повторить любой из получателей, причем, применительно и к отправителю и к любому из получателей.

Далее,
"To find a valid certificate owned by the recipient, Outlook verifies if any certificates are stored in the userSMimeCertificate attribute in Active Directory. If so, Outlook examines the PKCS#7 blobs to find out if Outlook is the one that published them. In that case, there is an extra signed attribute that indicates which is the default certificate. If the certificate marked as default is found in the userSMimeCertificate attribute, it is chosen. If the default certificate is not found, the first valid certificate in the store is selected. In case the userSMimeCertificate attribute stores no certificates, Outlook queries the userCertificate attribute in Active Directory"

Может сложиться впечатление, то Outlook берет сертификат непосредственно из AD, и, увидев сертификат в AD, можно долго удивляться почему же Outlook его никак не находит при попытке написать письмо.

На самом деле все не так. Может пройти аж до 48 часов с момента выпуска пользователю сертификата до момента появления возможности отправки ему шифрованного письма.

Очень понятно и подробно об этом написано в KB#841273 - Administering the offline address book in Outlook. Очень рекомендую это внимательно почитать. В двух словах - сертификат берется не из АД, а из локальной копии автономной адресной книги, которая на сервере Exchange генерится не часто (по умолчанию - раз в день), и также нечасто забирается Outlook-ом для автономной работы (если включено кеширование, которое включено по умолчанию).

Еще важно отметить, что по умолчанию Outlook всегда хочет проверять CRL как для сертификатов получателей, так и для сертификата отправителя. Тут может быть масса проблем, начиная с недоступности указанных в сертификате CDP, заканчивая банальными настройками прокси, когда локальный CRL не скачивается по HTTP через настроенный прокси. Не хочу говорить, что я бы рекомендовал отключение проверки CDP, но думать об этом надо.

Вообще, полезно почитать перечень криптопараметров Outlook и решить что как подкрутить в соответствии с потребностями (Plan for e-mail messaging cryptography in Outlook 2010):
http://technet.microsoft.com/en-us/library/cc179061.aspx

Свой собственный УЦ на OpenSSL

Снова пришлось упражняться с криптографией в исследовательских целях: надо было поднять свой (недоверенный в домене УЦ и проверить с ним некоторые штуки). Необходима была цепочка УЦ, т.е. что-то типа: Корневой УЦ --> Еще УЦ --> уже мой сертификат:


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

После того, как OpenSSL скачали и поставили.
1. Делаем корневой УЦ.
1.1. Делаем для него папку и подпапки:
Текстовый файл не содержит ничего (комментарий).
serial - содержит текущий сериальный номер сертификата.
serial.old - будет сделан после выпуска сертификата - там запишется предыдущий.
index.txt - надо сделать пустым. Все остальные index.txt.* сделаются после выпуска сертификата с этого УЦ.
openssl.cnf - копия дефолтного с незначительными изменениями, применительно к данному CA. Файл снабжен понятными комментариями.

1.2. Выпускаем корневой, самоподписанный сертификат:
openssl req -new -x509 -days 3650 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -config openssl.cnf

При этом секретный ключ будет положен  cakey.pem, сертификат - в cacert.pem.

2. Делаем выпускающий УЦ, подчиненный нашему корневому.
2.1. Такую же структуру папок:

В папку clients будем складывать сертификаты и pfx-ы клиентов (вручную, само туда класться не будет - чтобы корневая папку УЦ не засорялась).



2.2. Делаем запрос на сертификат выпускающего УЦ (почему-то я его назвал Subordinate): 
openssl req -new -days 3650 -keyout private/subcakey.pem -out subcareq.pem -config openssl.cnf


2.3. Идем на наш Корневой УЦ (== просто делаем туда CD) и выпускаем сертификат на только что сделанный запрос (подписываем запрос):
openssl ca -in ..\subca\subcareq.pem -extensions v3_ca -config openssl.cnf

3. Выпускаем сертификат для пользователя.
3.1. Идем на наш подчиненный УЦ (выпускающий УЦ) и делаем там запрос для пользовательского сертификата:
openssl req -new -days 365 -keyout key.pem -out req.pem

3.2. Подписываем запрос ключем УЦ:
openssl ca -in clients\req.pem -out clients\cer.cer -config openssl.cnf

3.3. Делаем из PKCS#12 (сшиваем ключ и сертификат в PFX):
openssl pkcs12 -export -out cer.pfx -inkey key.pem -in cer.cer

3.3* Иногда бывает нужно вытащить из PFX только секретный ключ, иногда хочется его вытащить и сохранить без шифрования, - команда ниже:
openssl pkcs12 -in ppp.pfx -out ppp.pem -nodes

Ключ будет сохранен в ppp.pem.

Ошибки.
1. Иногда, когда много раз упражняемся с выпуском сертификатов для одного пользователя, возможно возникновение ошибки при вызове команды п. 3.2
.....
Sign the certificate? [y/n]:y
failed to update database
TXT_DB error number 2
Здесь проблема связана с тем, что в одном CA OpenSSL не может быть более одного сертификата с одинаковыми параметрами. Для решения необходимо отозвать старый сертификат этого пользователя и повторить команду. Отозвать можно так:
openssl ca -revoke clients\certfilename.cer -config openssl.cnf

2. Для организации S/MIME в Outlook сертификат должен иметь определенные keyUsage и extendedKeyUsage:















Для указания этого OpenSSL проще отредактировать openssl.cnf:
[ usr_cert ]
....
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = critical, emailProtection
....

Анонимусы лучшие

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

Финальная фаза на которую нет смысла тратить время тут
Анализ фазы 1 тут и тут.

PS. леечка предлагает поделиться расшифрованными хешами со страждущими. Ради этого стоит записаться в твиттер.

Гугл жжет

анонимус против роснефти

К счастью или сожалению, с роснефтью у анонимусов так же облом - снова подделка. С такими хакИрами антарктиду не спасти никак.

Первое, что напрягает - удаленный доступ к консоли сервера через, аналог HP-шного ILO от DELL, который и распространен в наших корпорациях кругом и вокруг.

Затем забавность в имени пользователя, подключающегося к БД. Ну rosneft* ну rn*, ну никак не ros*.

У почтарей роснефти, можно получить NDR, чтобы проверить валидность адреса (похоже, ЗП админов почтаря в Роснефти ниже, чем в Газпроме). Делать это лень - нет желания в 10й раз подтверждать лживость анонимусов-пингвинов.

Забавно, что некоторые адреса, типа "guzzledyq@snpz.rosneft.ru" взяты из списков рассылок или спамловушек. Вероятно анонимусы торопились или просто устали генерировать пароли.

Результаты ниже.

email	Md5 hash	pass	google
sekr@nknpz.rosneft.ru	60a68754da6c98fc7b9fb148e9726548	pguvxq	729
ChufistovAV@snp.rosneft.ru	ec1a131e6518cada5b41205a7835d012	7LqrgF	9
KravtsovaGV@snp.rosneft.ru	83b0e3ef3ac28664ef6ae96d6432b25b	2Mvs9w	9
sales@oao-rosneft.ru	73833b16b402c2400570b5216e27ce5e	cXcI6j	5090
of02@anhk.rosneft.ru	ed0fa519d5aa4be307061cd0d0e78090	Bng0UZ	1
i_khasanov@rosneft.ru	4d75827ca2f5d19edd8960cf006e0d8f	VdUmE9	5
SadchikovaMN@tmbnpo.rosneft.ru	f51cb06eb19dbc7ea25fc089799b0acc	ffFSlS	6
l_kiselevskaya@rosneft.ru	6d9babf24f88c4313370baefb9b41247	g7Vn85	1
rnbunker@rosneft.ru	e4b64f39a1ed4db47bffd034eaac08a6	4zlLz2	164
TihonovAN@anhk.rosneft.ru	0a7252c68304abf56fed57bfd5530e0f	SPVlhw	1
knpz@rosneft.ru	c47c619de155725f7b9cd052af994bb5	ZFZNuJ	26800
e_vorobieva@rosneft.ru	245ff9e179aa66bf08336f09a2e94206	lMdrcZ	45
a_mityukov@rosneft.ru	b48d012e295bf007283efb750db45746	KPPsE1	6
almendinger_rnk@rosneft.ru	7da23a95ab172f653daba6af14ca262b	wYw2xn	2
delo@anhk.rosneft.ru	3c00c213d77814290872d48475f48986	gx3coo	4340
postman@ojsc-rosneft.ru	9cf3291ac5f6bc4e2291ea8ed24e90fd	Z44roA	9
y_nishkevich@rosneft.ru	d2051e1acfa779ded1e926e9c3884986	Mdg60w	8
sekr_snha@snha.rosneft.ru	d2f5c1c7ba6afd857942e22bf1a05c7e	ACU1JY	121
azkios@anhk.rosneft.ru	4ff3d10eb9a3d6e0a963ca143399037e	1rSqTW	656
n_malyshev@rosneft.ru	8d3eb05bd1f75559fd6325d93547b0f9	sa6n23	3
sekr1@anpz.rosneft.ru	2bb6e87c48334f7f41d58b5a0ac50729	vgbfqV	647
secr@azp.rosneft.ru	b388f97f62b2959752b11b6f46b8aed3	rjG41y	391
LoginovAN@nzmp.rosneft.ru	381851a31729d00f67eeb1e5dab2d5af	bIuw2C	6
m_khlebnikova@rosneft.ru	30b8ccf36dfbba9e1b31e9e325d8cb02	FzVCMZ	28
a_bogdanchikov@rosneft.ru	b9888f89e1ca04dfe8e4d29ba2923d14	YxM9mW	401
a_pashali@rosneft.ru	d755e55cf35ad3b3b5ab792da9f9e9c7	zsFR6T	27
ElshinAI@anhk.rosneft.ru	c4d7113ce3aec7d3cdf0eb75e99b02ef	1OSBge	6
TominVP@anhk.rosneft.ru	7616780009be0ca745357a868cc2bccc	CCtdof	21
Sekr_Top@nzmp.rosneft.ru	ba7c05e0f712a218c4b93d603f6bbb2a	nj0vzd	2110
ObraztsovaNE@vnp.rosneft.ru	07844431bf7883c03d6e106a25448fe7	kYdhmD	7
GolovaNA@vnp.rosneft.ru	3a4fc9ad4ea66548d51f05dd35b8252d	CBkLIH	9
VasilevaYuN@vnp.rosneft.ru	e23787524c90c0e6993a0f8103d2f91f	zzj2vj	9
i_zaikin@rosneft.ru	2af0a0ebfbf43e3ae2c67eb2058b5b62	zPEvlM	8
adam@ulanude.rosneft.ru	27e6a7fc583b267248d09fd63bf170d8	IoA3ZB	1
v_markeev@rosneft.ru	438bae36b41ac162bf626cfaf78da3c7	8bG21B	4
d_bogdanov@rosneft.ru	c5b70b3da8a17446f40ec20121418409	VkoLVB	2
v_voevoda@rosneft.ru	cc23796b64dc827387b86c6c3c69e711	pb3BaF	2800
shareholders@rosneft.ru	858365bffc34c9b6a11b3a2be5821946	NPEhz0	4530
s_gritskevich@rosneft.ru	95bdcd07851a5662ba0819912e2167ec	oa7vSq	8
rn_trade@rosneft.ru	6148c120d2824e27cf6aa6ea2847e2e5	fHckWn	4
perlovsg@bryansk.rosneft.ru	8fe7ff920f3585c5d22831d7deff7657	IKbl9N	4
v_surtaev@rosneft.ru	6da62f2ff996cc50f8f64cc88d37416f	WEcbZJ	2
v_pavlov@rosneft.ru	ee23314596c059b93fa8825de54926b1	eOga70	2
sekr_bnp@ulanude.rosneft.ru	576ca02c836e6485f34d5a6b2d6b0dfa	ok3eJ0	110
armz_market@anhk.rosneft.ru	ccee136118fe9789a3f308281864eec8	2Vznuc	346
t_shakhnazarova@rosneft.ru	27337e025b8224260a6c3be190fe5bd9	XCrrLc	4
v.popov@rosneft.ru	5e5c88f2cce888eeb07956d067ab59ee	ax6dP9	157
n_manvelov@rosneft.ru	dab34b5f500498f7c6fda8af579c78bb	t9rdXG	5900
usks_putevka@anhk.rosneft.ru	92cb9da387c1ac4d849c0c5ed6230a37	mI74Ga	9
p.stepanov@nsknp.rosneft.ru	c7e30fa305249bd4ce271a2fc194814b	85492o	4
ripe@nsknp.rosneft.ru	e444c2ffeb16081a26e5e04715b41b99	ZI2aKP	2
r_filonenko@rosneft.ru	8bc9ee83d12ef747807199331c41dcb2	6OzKlm	7
aapolyakov@rosneft.ru	6608d5ed7e3022a84fcd3ef07123ce6a	CtxWdy	13
enin.v.a@stng.rosneft.ru	9bf26e36033a3f6ed9b967f584e00135	agk0Fq	19
mz_commerce@rosneft.ru	ee7da81b57a3f912df94816020ea2758	DX1DMK	4
o_tomilina@rosneft.ru	11d1336c9b78616d0ef2978e043e52f8	qaWTnf	3
nksc@nkrm.rosneft.ru	6872a120a6cffebd7af925d86b61e791	vtzelZ	7
r_bagrin@rosneft.ru	5cc1efae61a9105e7af0854487d38633	OIjA1P	42
sekr@snpz.rosneft.ru	674a638c8f339863ea7c62fe5c8b9e4e	Mj6I32	991
VyskrebentsevPYu.@snpz.rosneft.ru	686e0cfc90d275c96247bef4632685b0	Gh5Uxs	8
kazankovAA@snpz.rosneft.ru	55a82519e0f9a7f595b28cb0b284d167	hmTLFY	1
distendedq87@snpz.rosneft.ru	64187908bdedbc335e3fe87f65b076f7	ye6qj9	1
ghoulishdjlx1@snpz.rosneft.ru	f11d4a9201795c7351f99074d9b2dc8b	QMff14	1
fraudfl5@snpz.rosneft.ru	1abcc44258a325fad899b5d0836ef653	TSYSyS	1
liveliestj07@snpz.rosneft.ru	7a798186594a7afa228b19db5bed5438	qQmvsB	1
TrofimovSN@snpz.rosneft.ru	312710347fd04de38186858069767742	pwBnup	5
pyn@snpz.rosneft.ru	882584c4ce16abfbdb91b5b0aaa1d202	QJI3nb	2
KuznetsovaEYa@snpz.rosneft.ru	c70b7ef661e1aad0bce623d52dbf2853	T4zeTu	4
urist1@snpz.rosneft.ru	4104b744be73acbec3b6f871d6b2017c	hwsq22	2
ShiyanovVA@snpz.rosneft.ru	ce8b0b42d848160e80bd967d133131b7	RTas4V	5
MisykIYa@snpz.rosneft.ru	3e34fcf7e53a515d60bba903084208bf	SermJ3	5
RyltsevSV@snpz.rosneft.ru	130c383b047dbc415f37de36e787f18b	su5ak0	3
aluevaem@snpz.rosneft.ru	bf8c7d818c31880119437d2b059a07b7	io74PK	5
BelovDV@snpz.rosneft.ru	ff71903e1dcd23f0629782078f2a08ab	GarRsa	1390
KrylovaEA@snpz.rosneft.ru	8b985bb709e85bd0fd2fbf43ce82009a	09exRj	5
ZorinaLN@snpz.rosneft.ru	7f597d97959ba888a217e0459f4c093f	XjVe46	1
guzzledyq@snpz.rosneft.ru	16ce24eb0404c06c8960e43f0b9a0e1a	wOVMvq	1
kda2@snpz.rosneft.ru	5e4b9ce75891687bdda15ede74677889	7ecknJ	6
ZhorinaLN@snpz.rosneft.ru	f1c1e6b7f3a576378ff39a8d315a1542	n1opfv	8
Sekr@snpz.rosneft.ru	51bae475074779a118eaf65f5e313301	xQFjnB	991
smg@snpz.rosneft.ru	0cc2f8136e6084c6234ab345e0a02dd4	TEmtga	3160