Saturday, December 22, 2012

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

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

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

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

Wednesday, November 21, 2012

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

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

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



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

Tuesday, November 20, 2012

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

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




Thursday, October 25, 2012

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


Wednesday, October 24, 2012

Свой собственный УЦ на 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

....

Thursday, October 18, 2012

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

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

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

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

Thursday, September 20, 2012

Гугл жжет


Tuesday, July 31, 2012

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

К счастью или сожалению, с роснефтью у анонимусов так же облом - снова подделка. С такими хакИрами антарктиду не спасти никак.
Первое, что напрягает - удаленный доступ к консоли сервера через, аналог 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