Миф 88. Сертификату Интернет-банка в браузере можно доверять

Форум Сообщества Практиков Конкурентной разведки (СПКР)

Конкурентная разведка, Бизнес-разведка, Корпоративная разведка,
Деловая разведка по открытым источникам в бизнесе.
Работаем строго в рамках закона.

Дезинформация и активные мероприятия в бизнесе
Форум Сообщества Практиков Конкурентной разведки (СПКР) »   Безопасность рабочего места »   Миф 88. Сертификату Интернет-банка в браузере можно доверять
RSS

Миф 88. Сертификату Интернет-банка в браузере можно доверять

<<Назад  Вперед>>Страницы: 1 2 3 4
Печать
 
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
а вот бюллетень от мелкомягких, как самому защититься от проблем с фальшивыми сертификатами DigiNotar (кстати, вы обратили внимание, что часть сертификатов была создана для якобы CA, то есть для фальсификации кого они будут использоваться, вообще непонятно ) - _ttps://blogs.technet.com/b/srd/archive/2011/09/04/protecting-yourself-from-attacks-that-leverage-fraudulent-diginotar-digital-certificates.aspx

[q]

...
All versions of Windows are affected by this attack. However, when a user initiates an HTTPS SSL connection via Internet Explorer on Windows Vista, Windows 7, or Windows Server 2008 and encounters a new root certificate, the Windows certificate chain verification software checks a list of valid root certificates, which is hosted on Windows Update. As of August 29th, this Certificate Trust List (CTL) on Windows Update has been revised to remove DigiNotar from the list of trusted Certificate Authorities so that any certificates issued by DigiNotar are no longer trusted for HTTPS conversations.

Windows XP and Windows Server 2003 do not have the same Windows Update check mechanism. Instead, these versions of Windows rely on a static list of trusted root certificate authorities. This list is updated through the non-security update “Update for Root Certificates (KB 931125)”. DigiNotar was not initially included as a trusted root certificate in Windows XP, so if you have never installed this update, you are not vulnerable to any certificates issued by them.

However, any Windows XP or Windows Server 2003 system that installed this update as of November 2008 or later would have DigiNotar added as a trusted root certificate. Administrators of these systems can follow the steps in the “What you can do to protect yourself” section below to take proactive actions to remove DigiNotar as a trusted root Certificate Authority until Microsoft releases an update that fully addresses this problem.

Windows Phone devices are unaffected. No Windows Mobile devices have a DigiNotar certificate in the Trusted Root Certificate Store.
...
Step 1: Remove the DigiNotar Root from the trusted root CA store

Click Start, click Start Search, type mmc, and then press ENTER.
On the File menu, click Add/Remove Snap-in
Under Available snap-ins, click Certificates, and then click Add
Under This snap-in will always manage certificates for, click Computer account, and then click Next
Click Local computer, and click Finish
If you have no more snap-ins to add to the console, click OK
In the console tree, double-click Certificates
Double-click the Trusted Root Certification Authorities store and click on Certificates to view all certificates in the store
Select the two DigiNotar Root CA certificates. You can confirm the right certificates by checking their thumbprints which should be “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c” and “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”
Right-click the certificates and select Delete

To perform the above steps from the command-line, you can use the certutil.exe tools as follows:

certutil -delstore authroot “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c”
certutil -delstore authroot “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”

If you distribute roots in your enterprise using group policy, follow the instructions to remove a root across an enterprise network via group policy - technet.microsoft.com/en-us/library/cc786148(WS.10).aspx. In step 3 of those group policy instructions, choose the root CA in question here - DigiNotar Root CAs with thumbprints "c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c" and "43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3".

Step 2: Clear the cache to remove any older cached CTL

The simplest way to do so is to use “certutil –urlcache * delete”. This will clean up the cache for the current user. You can find further documentation on this step, including a Microsoft Fix It package to clean up the cache, at support.microsoft.com/kb/2328240
[/q]


кстати, для XP и 2003 выпустили-таки обновления - _ttp://support.microsoft.com/kb/2607712
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
а теперь мелкомягкие добавили в список отозванных сертфиикатов еще шесть, обновили статью об этом - _ttps://technet.microsoft.com/en-us/security/advisory/2607712 и выпустили новое обновление - _ttp://support.microsoft.com/kb/2616676
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
кстати, аудитором DigiNotar, который их регулярно проверял и ничего не находил :binocular: был PriceWaterhouseCoopers

_ttps://isc.sans.edu/diary.html?n&storyid=11590

[q]

...
OPTA also names PriceWaterhouseCoopers as the (regular) auditors of DigiNotar, but does not go as far as to name them the ones that gave them the apparent clean bill of health on July 27th, 2011
..
[/q]


Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
сначала статистика о том, сколько сайтов используют TLS 1.0 - _ttp://blog.ivanristic.com/2011/09/ssl-survey-protocol-support.html

потом информация о новой уязвимости в TLS 1.0 - _ttp://www.imperialviolet.org/2011/09/23/chromeandbeast.html

[q]

...
Contrary to several press reports, Duong and Rizzo have not found, nor do they claim, any new flaws in TLS. They have shown a concrete proof of concept for a flaw in CBC that, sadly, has a long history. Early reports of the problem date back nearly ten years ago and Bard published two papers detailing the problem.
...
The problem has been fixed in TLS 1.1 and a workaround for SSL 3.0 and TLS 1.0 is known
...
The workaround (prepending empty application data records) is perfectly valid according to the protocol but several buggy implementations of SSL/TLS misbehaved when it was enabled.
...
Use of TLS 1.1 would also have solved the issue but, despite it being published in 2006, common SSL/TLS libraries still don't implement it. But even if there was widespread deployment of TLS 1.1, it wouldn't have helped avoid problems like this. Due to a different, common bug in SSL 3.0 implementations (nearly 12 years after SSL 3.0 was obsoleted by TLS 1.0), browsers still have to perform SSL 3.0 downgrades to support buggy servers. So even with a TLS 1.1 capable browser and server, an attacker can trigger a downgrade to SSL 3.0 and bypass the protections of TLS 1.1.
...
The attack is still a difficult one; the attacker has to have high-bandwidth MITM access to the victim. This is typically achieved by being on the same wireless network as the victim.
...
Also, an attacker with MITM abilities doesn't need to implement this complex attack. SSL stripping and mixed-scripting issues are much easier to exploit and will take continued, sustained effort to address. Duong and Rizzo have highlighted this fact by choosing to attack one of the few HSTS sites.

[/q]


а в и _ttps://isc.sans.edu/diary.html?n&storyid=11635 описывается подробно атака и как от нее защититься
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
_ttp://www.anti-malware.ru/news/2011-11-05/4872

[q]

Компания KPN, еще один сертификационный центр SSL из Нидерландов, приостановила операции по выпуску цифровых удостоверений в связи с обнаружением факта несанкционированного доступа к своим серверам. Фирма ведет внутреннее расследование инцидента.


В процессе аудита систем безопасности специалисты обнаружили в локальной вычислительной сети KPN признаки присутствия злоумышленников: на одном из серверов компании предполагаемые хакеры устроили хранилище своих программных инструментов, в частности - средств организации и ведения DDoS-атак. Точное время компрометации сервера не известно; не исключено, что "арсенал" был оборудован не один год назад.

Признаков того, что вскрытые вычислительные мощности использовались для изготовления поддельных сертификатов SSL, эксперты пока не обнаружили. Тем не менее, с учетом недавнего происшествия с DigiNotar компания считает, что вероятность подобного развития событий "не может быть полностью исключена" - так что операции по сертификатам пришлось приостановить на время проведения детального расследования. Действительно, осторожность в подобных вопросах никогда не бывает лишней, так что решение сертификационного центра представляется оправданным.

Если опасения руководства KPN подтвердятся, то эффект может быть существенным: как и DigiNotar, эта фирма снабжает сертификатами крупные компании и государственные учреждения, причем после падения DigiNotar многие ее бывшие клиенты перешли на обслуживание именно в KPN. Пока затруднительно прогнозировать, каковы будут конкретные последствия подобного происшествия, поскольку доподлинно не известно, сколь широка клиентская база компании (напомним, что услугами DigiNotar пользовалось относительно небольшое число сетевых ресурсов, что сделало всеобщий отказ от ее сертификатов относительно безболезненным).

Заметим, что незадолго до появления официальной информации от KPN сетевые СМИ сообщили о еще одном происшествии, связанном с работой центров выдачи удостоверений SSL: производители Интернет-обозревателей (в частности, Mozilla и Microsoft) заблокировали сертификаты малайзийского поставщика Digicert. Согласно имеющимся сведениям, причиной тому стало нарушение требований к безопасности - центр выпустил ненадежные удостоверения, харакеризующиеся несколькими потенциально опасными изъянами.
[/q]
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009

и еще с одним CA проблемы - _ttps://blogs.technet.com/themes/blogs/generic/post.aspx?WeblogApp=msrc&y=2011&m=11&d=03&WeblogPostName=untrusted-certificate-store-to-be-updated&GroupKeys=

[q]

This post is to notify customers that Microsoft will revoke trust in an Intermediate Certificate Authority, DigiCert Sdn. Bhd. (Digicert Malaysia) in an update to be released through Windows Update.

DigiCert Sdn. Bhd is a Malaysian subordinate CA under Entrust and Verizon (GTE CyberTrust). There is no relationship between DigiCert Malaysia and DigiCert Inc., which is a member of the Windows Root Certificate Program.

Microsoft was notified by Entrust, Inc, a certificate authority in the Microsoft Root program, that a Malaysian subordinate CA, DigiCert Sdn. Bhd issued 22 certificates with weak 512 bit keys. Additionally, this subordinate CA has issued certificates without the appropriate usage extensions or revocation information. This is a violation of the Microsoft Root Program requirements (http://technet.microsoft.com/en-us/library/cc751157.aspx).

There is no indication that any certificates were issued fraudulently, however, these weak keys have allowed some of the certificates to be compromised. These compromised certificates could allow an attacker to impersonate the legitimate owner and make a user believe they are trusting a website or signed software that was created for malicious use.

The subordinate CA has clearly demonstrated poor CA security practices and Microsoft intends to revoke trust in the intermediate certificates.
[/q]
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
ну вот - мелкомягкие исключают сертификат CA, выдавшего эти 22 сертификата, из списка доверенных - _ttps://technet.microsoft.com/en-us/security/advisory/2641690 и _ttp://support.microsoft.com/kb/2641690
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
еще пример использования ворованного сертификата - см. _ttp://www.f-secure.com/weblog/archives/00002269.html

[q]

...
In some of these cases, the certificate has been created by the criminals just for the purpose for signing malware. In other cases they steal code signing certificates (and their passphrases) so they can sign code as someone else.

We recently found a sample signed with a stolen certificate. The file properties looked like this:

Publisher: Adobe Systems Incorporated
Copyright: Copyright © 2010
Product: Adobe Systems Apps
File version: 8, 0, 12, 78
Comments: Product of Adobe Systems

And the signing info was:

Signer: anjungnet.mardi.gov.my
Digisign Server ID (Enrich)
GTE CyberTrust Global Root
Signing date: 5:36 24/08/2011

Turns out mardi.gov.my is part of the Government of Malaysia: Malaysian Agricultural Research and Development Institute. According the information we received from the Malaysian authorities, this certificate has been stolen "quite some time ago".

The malware itself has been spread via malicious PDF files that drop it after exploiting Adobe Reader 8. The malware downloads additional malicious components from a server called worldnewsmagazines.org. Some of those components are also signed, although this time by an entity called www.esupplychain.com.tw.

It's not that common to find a signed copy of malware. It's even rarer that it's signed with an official key belonging to a government.

This particular malware does not gain much advantage of the signature any more, as the mardi.gov.my certificate expired in the end of September.

The Malaysian Government has been informed about the case.

We detect this malware as Trojan-Downloader:W32/Agent.DTIW. MD5 hash is e9f89d406e32ca88c32ac22852c25841.
[/q]
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
_ttp://www.anti-malware.ru/news/2012-03-20/8686

[q]

На прошлой неделе "Лаборатория Касперского" перехватила вредоносное программное обеспечение с цифровой подписью, которому присвоила наименование Mediyes. Сертификат, которым злоумышленники оснастили компьютерный вирус, принадлежал швейцарской компании Conpavi AG и был выпущен от имени Symantec. Расследование позволило пролить свет на его происхождение.

Symantec опубликовала заявление, в котором сообщается, что принадлежавший Conpavi AG секретный ключ шифрования был неизвестным образом похищен и использован для генерации цифрового удостоверения. Доподлинно не известно, было ли это делом рук инсайдера или же внешнего нападающего, но факт есть факт: ключ попал не в те руки. Это происшествие в очередной раз обозначило те риски, с которыми сопряжено хранение секретных ключей для сертификатов: если владелец не принимает надлежащих мер по их защите, то последствия могут быть весьма печальны. Symantec уже прекратила действие ложного удостоверения и теперь помогает швейцарской фирме с анализом инцидента и предотвращением новых неприятностей того же рода.

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

Согласно подсчетам "Лаборатории Касперского", жертвами Mediyes могли стать пять тысяч пользователей из Западной Европы. Ареал распространения инфекции охватывает Германию, Швейцарию, Швецию, Францию и Италию. Цель злоумышленников - перехват поисковых запросов в обозревателях Интернета и последующее использование зараженных компьютеров в мошеннических схемах с оплатой за переходы по ссылкам.
[/q]
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
_ttp://www.securitylab.ru/news/423885.php

[q]

Организация Trustworthy Internet Movement (TIM), занимающаяся изучением вопросов интернет-безопасности, провела исследование почти 200 тыс. крупнейших web-сайтов с поддержкой протокола HTTPS на наличие уязвимостей, позволяющих осуществить атаку "человек посередине".

В ходе исследования SSL Pulse компания проверяла, какие протоколы поддерживают веб-сайты с HTTPS (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, и т.д.), длину ключа, используемого для обеспечения связи (512 бит, 1024 бит, 2048 бит и т.д.) и размер поддерживаемого кода (256 бит, 128 бит или ниже).

По результатам исследования TIM, половина сайтов из рейтинга Alexa, поддерживающие HTTPS, используют сочетание современных протоколов, надежного кодирования и длинных ключей, но только 10% из них являются действительно безопасными. 75% оказались уязвимыми к атакам, с помощью инструмента BEAST.

На сегодняшний день все современные браузеры оснащены функционалом защиты от BEAST-атак. Тем не менее, многие из тех, кто еще использует устаревшее ПО, остаются незащищенными.

Исследование SSL Pulse показало, что более 13% из обследуемых сайтов с поддержкой HTTPS допускают перенаправление по небезопасным соединениям. Это особенно рискованно для сайтов с большим количеством пользователей, или тех, которые содержат ценную информацию.

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

Подробнее с отчетом исследования SSL Pulse можно ознакомиться здесь .
[/q]
<<Назад  Вперед>>Страницы: 1 2 3 4
Печать
Форум Сообщества Практиков Конкурентной разведки (СПКР) »   Безопасность рабочего места »   Миф 88. Сертификату Интернет-банка в браузере можно доверять
RSS

Последние RSS
Open Source Intelligence (OSINT) Tools and Resources Handbook
Top tips on gathering information about companies by using free online sources
Новое на блоге HRразведка
Безопасность данных в MS Access
Слово как улика
20 Recon and Intel Gathering Tools used by InfoSec Professionals
What’s Changed?
10 альтернативных поисковиков
Ситуационный центр главы Республики Коми
Развёртывание ситуационных центров на базе технологии Avalanche
Как принимать сложные решения. Советы бывшего оперативника ЦРУ.
Открытая информация о "Новичке" из сети интернет.
Ген. директор "ОЗХО" Ахмет Узюмдж о "Новичке" и хим. атаке в Сирии
Онлайн-сервисы для Twitter
Коллекция для Twitter
Приложение Opera VPN закрывается
О работе разведки
Deep web и 11 поисковиков по нему
Об изначальной "лживости" любых документов
Обновление на блоге HRазведка

Самые активные 20 тем RSS
Стандартные источники информации в СайтСпутнике
Слово как улика
Open Source Intelligence (OSINT) Tools and Resources Handbook
Top tips on gathering information about companies by using free online sources
Новое на блоге HRразведка
WebSite Watcher
Безопасность данных в MS Access