Новости мира информационной безопасности. Расследование и реагирование на инциденты. Кибербезопасность.

Новости информационной безопасности




Обнаружены 7 новых вариантов атак Meltdown и Spectre

Исследователям удалось успешно воспроизвести все семь атак с использованием PoC-кода.

Во вторник, 13 ноября, группа исследователей, в которую также вошли ученые, первыми обнаружившие уязвимости Meltdown и Spectre, опубликовала результаты многомесячной работы в отчете «A Systematic Evaluation of Transient Execution Attacks and Defenses».

В отчете представлены семь новых атак на процессоры AMD, ARM и Intel, связанные с Meltdown (две атаки) и Spectre (пять атак). Исследователям удалось успешно воспроизвести все семь атак с использованием PoC-кода. Еще шесть связанных с Meltdown атак воспроизвести не получилось.

Новые атаки Meltdown:

Meltdown-BR – атака на процессоры x86 Intel и AMD с использованием связанной инструкции;

Meltdown-PK – атака на процессоры Intel путем обхода ключей защиты памяти.

Новые атаки Spectre:

Spectre-PHT – атака с использованием таблицы шаблонов переходов ЦП (Pattern History Table, PHT);

Spectre-BTB – атака с использованием буфера адресов перехода (Branch Target Buffer, BTB);

Spectre-RSB – атака с использованием буфера стека возвратов (Return Stack Buffer, RSB);

Spectre-BHB – атака с использованием буфера истории переходов (Branch History Buffer, BHB).

Исследователи также обнаружили три новых варианта атаки Spectre с использованием механизма PHT и два варианта с использованием BTB. К атакам уязвимы процессоры AMD, ARM и Intel.

Дата: 2018-11-15 05:55:45

Источник: http://www.securitylab.ru/news/496489.php



Что обсудят на восьмой международной блокчейн-конференции в Москве

Blockchain Conference Moscow состоится совсем скоро – 20 ноября. Кто же присоединится к обсуждению блокчейна, ICO и трейдинга?

Blockchain Conference Moscow состоится совсем скоро – 20 ноября. Кто же присоединится к обсуждению блокчейна, ICO и трейдинга?

Представители каких компаний выступят на конференции?

Среди компаний, чьи представители будут читать доклады в рамках Blockchain Conference Moscow, – PwC Legal Switzerland, KUNA.io, РАКИБ и Bitfury Group.

PwC Legal Switzerland – швейцарское подразделение адвокатского бюро с крупнейшим географическим охватом, действующее в 90 странах мира. Представителем компании на конференции станет др. Гюнтер Добрауц-Сальдапенна, партнер и глава PwC Legal Switzerland. Он выступит с докладом «Правовые и регуляторные сложности, с которыми сталкиваются инновационные технологии».

KUNA.io – это первая публичная криптобиржа в Восточной Европе и СНГ. Представителем компании выступит ее основатель – Михаил Чобанян. На конференции Михаил расскажет, как выбрать подходящий сервис и почему известные зарубежные биржи не адаптированы под СНГ.

Российская ассоциация криптоиндустрии и блокчейна (РАКИБ) – ассоциация разработчиков и пользователей технологии блокчейн и продуктов, созданных на ее основе. Ее представителями выступят Валерий Петров – один из крупнейших российских специалистов по финансам, инвестициям и блокчейну, вице-президент РАКИБ, и Андрей Грачев – вице-президент РАКИБ по трейдингу и официальный представитель Huobi Russia.

Bitfury Group – крупнейший за пределами Китая промышленный майнер, разработчик программного и аппаратного обеспечения для работы с блокчейном биткоина. Ее представителем выступит Герберт Шопник, менеджер по работе с ключевыми заказчиками и партнерами. Спикер расскажет о возможности использования блокчейна без криптовалют и том, как блокчейн внедряется в коммерческий и государственный секторы.

Какие официальные представители посетят Blockchain Conference Moscow?

Чтобы послушать спикеров и пообщаться с экспонентами, Blockchain Conference Moscow посетят представители:

Чтобы послушать доклады спикеров, пообщаться с экспонентами и наладить новые деловые связи – регистрируйтесь на Blockchain Conference Moscow .

А еще можно поучаствовать в конкурсе «Придумай своего криптогероя» от организатора, компании Smile-Expo, и провести аналогию между супергероями и криптомонетами.

Чтобы поучаствовать в конкурсе, необходимо:
1. подписаться на YouTube-канал Smile-Expo — https://youtu.be/NB1bzbUPyDE
2. и написать о своем криптогерое с суперспособностями в комментариях

Итоги будут объявлены 16 ноября. Два победителя получат билеты на Blockchain Conference Moscow. Желаем удачи!


Дата: 2018-11-15 05:54:19

Источник: http://www.securitylab.ru/news/496487.php



Adobe закрыла брешь, для которой уже опубликован PoC-код

Ноябрьский выпуск обновлений для продуктов Adobe содержит всего три заплатки, в том числе патч к уязвимости в Acrobat и Reader, принцип использования которой давно известен.

Этот баг раскрытия информации, которому был присвоен идентификатор CVE-2018-15979, обнаружили в начале текущего месяца операторы EdgeSpot — бесплатного онлайн-сервиса, специализирующегося на анализе эксплойтов.

«Успешная эксплуатация может привести к самопроизвольному сливу хешированного NTLM-пароля пользователя», — сказано в бюллетене Adobe. Протокол аутентификации NTLM используется в сетях с системами Windows, а также при входе в сеть с изолированной системы.

По словам экспертов EdgeSpot.io, новая брешь в Acrobat/Reader возникла из-за ошибки, допущенной Adobe при создании патча для CVE-2018-4993 (вышел в мае). Как оказалось, эта заплатка решила проблему лишь наполовину. В то же время детали уязвимости и концепция эксплойта были опубликованы почти одновременно с выходом патча, то есть полгода назад. Тогда же Adobe разъяснила суть проблемы: затронувшая ее продукты ошибка в реализации NTLM позволяет автору атаки перенаправить пользователя на внешний вредоносный ресурс и заполучить таким образом аутентификационные сообщения NTLM.

Степень опасности CVE-2018-15979 оценена как существенная, а заплатке присвоен приоритет 1. Согласно системе ранжирования Adobe, это означает, что закрываемая уязвимость уже используется злоумышленниками либо риск атаки высок из-за наличия рабочего эксплойта.

Проблема актуальна для Windows-версий Acrobat DC и Reader DC сборки 2019.008.20080 или ниже, Acrobat Classic / Reader Classic 2017.011.30105 и ниже, а также Acrobat DC / Acrobat Reader DC 2015.006.30456 и ниже. Патч включен в состав обновлений 2019.008.20081, 2017.011.30106 и 2015.006.30457.

Уязвимость CVE-2018-15978, закрытая в Adobe Flash Player, тоже грозила утечкой конфиденциальной информации. Она относится к типу «чтение за пределами выделенного в памяти буфера» (out-of-bounds read) и присутствует во всех прежних выпусках продукта вплоть до 31.0.0.122. Проблема признана существенной и была решена путем выпуска обновления 31.0.0.148, которое рекомендуется установить на всех платформах.

Третий патч предназначен для графических редакторов Photoshop CC, работающих на Windows и macOS. Выпуски 19.х продукта (до 19.1.6)  подвержены уязвимости CVE-2018-15980, связанной с ошибкой out-of-bounds read. Согласно Adobe, эксплойт в данном случае тоже позволяет получить доступ к важым данным. Пользователям рекомендуется установить обновление 19.1.7 или 20.0.

Дата: 2018-11-15 05:43:50

Источник: https://threatpost.ru/adobe-fixes-acrobat-and-reader-flaw-with-publicly-available-poc/29187/



Google откроет регистрацию в доменной зоне .dev

В 2015 году компания приобрела право на домен верхнего уровня .dev, чем вызвала негодование у разработчиков.

В начале следующего года откроется регистрация в доменной зоне .dev. Об этом сообщили представители компании Google на саммите разработчиков Chrome Dev Summit 2018, проходившем 12-13 ноября в Сан-Франциско.

В 2015 году Google получила право собственности на домен верхнего уровня .dev, чем вызвала негодование среди разработчиков, использовавших его для сайтов, где проводили внутреннее тестирование своих продуктов. Однако теперь компания, похоже, готова поделиться с общественностью доменом, до недавнего времени принадлежавшим только ей.

16 января 2019 года начнется прием заявок от владельцев торговых марок на регистрацию доменных имен, который продлится до 19 февраля. Безусловно, регистрируемое доменное имя должно соответствовать торговой марке в целях предотвращения возможного мошенничества.

В период 19-28 февраля продлится фаза «раннего доступа», позволяющая зарегистрировать домен, но уже по более высокой цене. Во сколько обойдется регистрация в этот период, Google не уточняет. По словам компании, стоимость будет повышаться постепенно вплоть до открытия доступа 28 февраля.

Как и запущенный ранее в нынешнем году домен верхнего уровня .app, .dev получит встроенную поддержку HTTPS.

Дата: 2018-11-15 04:52:36

Источник: http://www.securitylab.ru/news/496488.php



Daily Blog #538: Forensic Lunch Test Kitchen 11/14/18

Hello Reader,
          Tonight I did a bit of an experimental stream. I loaded the current first chapter draft of the new book and its proposed outline and talked through with those watching what I was planning to do. Thanks to Hooligan Goto for helping me out as I tried to figure out what my outline was missing.

I'm excited to work on this new project, as well as all the other projects I'm working on, because all of them will continue to force me to learn, write and contribute going forward for the long term.

Here is the new outline:

Windows Forensic Fundamentals

Why this data exists

How to form your hypothesis

Building a test bed

Writing python code for DFIR

Disk Structures

MBR

GPT

EFI

Full Disk Encryption

RAIDs

File systems

NTFS

FAT32

EXFAT

REFS


Extended Windows File System Concepts

Shadow Copies

Symlinks, Hardlinks, Reparse Points

TXF, TXR

Single instance storage

Event Tracing Logs

Event Logs

Registry

Registry Fundamentals

Registry Transaction Logs

Recovering deleted data within Registries

Accessing Registries with YARP



User Activity

Registry Data

User Assist

Typed Paths

Cortana Search

RecentApps



File access

ObjectIDs

Lnk Files

Jumplists

Shellbags

Registry data

Device access

Driver install process

Registry data

Driver install logs

GUIDs and meanings

Event Logs

ETLs

Program execution

Application Compatibility Caching

Shimcache

Amcache

Application prefetching

Application Superfetching

User application tracking

ETLs

Event Logs

Network access

RDP

Network Shares

Teamviewer

Event Logs



Network connectivity

Network connections

Network drivers

ETLs

Event Logs

Browser Forensics

Chrome

IE

Firefox



Cloud Hosted

Webmail

  Gmail, outlook,

Cloud Storage

Google Drive, Dropbox



Email Forensics

Outlook

OWA

System Logging

Event Logs

Event Tracing Logs



System Monitoring

Journal Analysis

SRUM



Anti Forensics

Wipers

Cleaners



VM Forensics

Vmware Workstation

VMDKS

VMEMS

Virtuabox

Hyper-V

Here is the video if you want to watch it:

Дата: 2018-11-15 04:02:35

Источник: http://www.hecfblog.com/2018/11/daily-blog-538-forensic-lunch-test.html



Меня окружали милые, симпатичные люди, медленно сжимая кольцо... или токсичность российских специалистов по ИБ

Только выезжая заграницу, на какое-либо мероприятие по ИБ, понимаешь, насколько наш российский междусобойчик отличается от всего того, что происходит за его пределами. И дело не в том, какие темы обсуждаются на конференциях "здесь" и "там", а в том, как воспринимают Россию в киберпространстве "здесь" и "там". Я уже писал, что американцы раздувают киберугрозу со стороны нашей страны, рисуя из нас образ врага и обвиняя во взломах всего "что движется".
Screenshot%2B2018-11-14%2Bat%2B12.16.12.png
У российских специалистов эта тема вызывает лишь улыбку - никаких серьезных доказательств не представлено, а те, что опубликованы в докладе Мюллера, докладах американской разведки, в исследованиях американских ИБ-компаний, рассматриваются с точки зрения нечестных методов геополитической борьбы, в которых все методы хороши, лишь бы удержаться на вершине геополитического Олимпа. Ну действительно, можно ли всерьез рассматривать в качестве доказательства использование в атаках российских IP-адресов, московский часовой пояс и имя "Феликс Эдмундович" в коде найденных вредоносных программ? Смешно. Но в последнее время уровень представленных доказательств изменился. В ход пошли такие факты, которые сложно выявить чисто техническими мероприятиями - ФИО, должности, звания, места дислокации, номера в/ч и т.п. Все это говорит либо о том, что у американцев и их партнеров есть и оперативная информация о том, что и кто осуществляет различные действия в киберпространстве от имени России, либо об усилении дезинформации западного общества и приведении якобы неубиенных фактов, которые должны лишний раз доказать вину России.
Screenshot%2B2018-11-14%2Bat%2B12.16.39.png
Лично я не знаю, какая из этих версий более реалистична (вполне возможно, что обе). Только я вижу что:
На прошедших осенью "Подмосковных вечерах" клуба топ-менеджеров 4CIO как-то само собой зашел разговор о будущем, о работе заграницей и о том, что айтишники стали возвращаться, так как в условиях текущей геополитики стало сложно работать зарубежом. А я стал примерять эти рассуждения на безопасников и картинка тоже не самая радостная. Быть российским специалистом (и компанией) по ИБ (включая и многие страны СНГ, как это не парадоксально) стало очень токсичным. За последние 2,5 года, с момента когда я написал заметку про то, как американцы раздувают угрозу из России, ситуация стала гораздо хуже. Вот только некоторые проявления с которыми сталкиваются многие:


  • Нет доступа к сайтам, если пытаться подключаться из России.
  • Некоторые госорганы начинают блокировать доступ к себе, если он идет со стороны нероссийских IP-адресов.
  • Ярлык "русские хакеры" прочно укрепился в мире и "там" он несет вполне негативную конотацию, в отличие от России, где это не более чем забавный термин, который, по мнению многих, не подкреплен никакими доказательствами.
  • Российские компании по ИБ попадают в санкционные списки, что мешает им вести бизнес не только на Западе (или Востоке), но и в России (крупные заказчики начинают снижать свою активность по работе с такими "токсичными" компаниями). По ряду направлений разрываются партнерские отношения, которые длились годами.
  • Против иностранных (читай, американских) компаний в России вводятся ограничения, которые снижают проникновение инновационных технологий и отбрасывают российских заказчиков назад.
  • На Интернет начинаются гонения, а запретительная стратегия набирает все большие обороты. Балканизация Рунета не за горами.
  • Запрет на передачу исходников и снижение числа сертифицированных зарубежных ИБ-решений, приводящие к отсутствию свободы маневра при выстраивании долгосрочной и среднесрочной стратегии ИБ на предприятии.
  • В риторике западных стран (Европа и Северная Америка) все чаще начинает проскальзывать идея симметричного ответа на российскую киберагрессию, а учитывая, что российский ИТ-рынок построен преимущественно на западных технологиях, то градус недоверия растет.

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

  1. Готов ли я строить систему ИБ своей организации на решениях, происходящих из стран - геополитических противников? Если нет, то какова альтернатива? Если да, то каковы пути отхода, если с этими решения что-то "вдруг" произойдет?
  2. Если в качестве альтернативы мы рассматриваем Китай, то где гарантии безопасности со стороны этого "союзника" (союзником, кстати, его называет только Россия, - Китай по отношению к нам это слово не использует никогда)?
  3. Готов ли я к тому, что российские компании, решения которых я выбрал для своей системы ИБ, будут внесены в санкционные списки и я могу столкнуться с риском вторичных санкций?
  4. Готов ли я к атакам со стороны не только киберпреступников, но и целых государств и их спецслужб (если я интересен для них)?
  5. Готов ли я к отключению Рунета от всемирной Сети? Можно и в более легкой форме задать этот вопрос. Что я буду делать в случае учащения случаев блокировок иностранных IP-адресов (актуально для активных пользователей XaaS-платформ)?

Не хотелось бы, чтобы эта заметка рассматривалась как пессимистичный взгляд в будущее и разговор в стиле "все пропало". Безопасность - это в первую очередь управление рисками (в том числе и их принятие). Просто сейчас, некоторые, ранее чисто теоретические риски, становятся более приоритетными и их уже нельзя сбрасывать со счетов.

Дата: 2018-11-15 02:54:02

Источник: http://lukatsky.blogspot.com/2018/11/blog-post_15.html



[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 17: «Аутентификация пользователя», часть 2

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год


Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3

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

2cbirrdqzgf2drt5yd_bpbepq6a.jpeg

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

Так что Telepathwords — это просто забавный сайт, они утверждают, что они не хранят ваши пароли, так что можете поверить им на слово, если хотите. Но очень интересно просто сесть и подумать, насколько хороший пароль я придумал? А затем ввести его сюда и посмотреть, насколько легко его угадать. Он даже позволяет делать такие вещи, как эвристический анализ популярных фраз из нескольких слов, из которых для пароля выбирается только первая буква каждого слова. Так что эта штука очень полезна.

Ещё одна интересная вещь – это то, что ваши пароли можно отгадать в режиме оффлайн. Эта уязвимость, называемая preauth, или „предварительная аутентификация“, была присуща Kerberos v4 и v5. Любой желающий мог запросить у KDC билет, зашифрованный паролем пользователя.

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

2lar5oy0f8w3gtkack35hqeosic.jpeg

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

В Kerberos версии 5 клиент должен передать KDC временную метку, после чего эта метка будет зашифрована с помощью K_C. Всё это отправляется серверу, сервер смотрит на этот запрос и проверяет его пред тем, как отослать что-то клиенту. Так что любой случайный клиент может прийти и просто попросить эту вещь у сервера.

Студент: значит, временная метка записана в сообщении? Не может ли злоумышленник просто взять и взломать это сообщение методом brute-force?

Профессор: давайте посмотрим. Может ли злоумышленник получить это сообщение {time stapm} K_C?

Студент: да, это зашифрованное сообщение.

f0rzphy2pjhsj8jlfzpgvcibh3u.jpeg

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

Студент: нет, он бы использовал brute-force для подбора K_C.

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

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

Еще одна важная вещь касается восстановления пароля. Смысл заключается в том, что если вы теряете свой пароль, то вы должны пойти в офис и попросить другой пароль. Но прежде чем вы получите этот пароль, вы должны каким-то способом доказать, что вы – это вы.

Итак, как это работает? Как можно восстановить пароль? Интересно, что люди часто сосредоточены на энтропии самого пароля. Но проблема в том, что если вопросы, используемые для восстановления пароля, или схема восстановления пароля имеет мало энтропии, это влияет на энтропию общей схемы аутентификации. Другими словами, прочность общей схемы аутентификации равна минимальной энтропии пароля и минимальной энтропии вопроса для восстановления пароля. Существует много сценариев и правил, есть достаточно известных случаев, таких как случай Сары Пэйлин. Кто-то смог восстановить её пароль обманным путем, потому что ее вопросы для восстановления пароля были такими, что любой посторонний человек мог найти на них ответ, например, прочитав о ней статью в Википедии, в которой было написано, в какую школу она ходила и так далее.

yzxo9qku-c3hosdnhfvz8xcp8bq.jpeg

Так что часто эти вопросы для восстановления пароля не достаточно хороши по нескольким причинам. Иногда такие вещи просто имеют очень низкую энтропию. Например, если ваш вопрос для восстановления пароля «какой ваш любимый цвет», то самыми популярными ответами будут «синий» и «красный». Никто не ответит «белый», «фуксия» или «пурпурный». Таким образом, некоторые из этих вопросов для восстановления по своей сути не в состоянии обеспечить достаточно много энтропии.

Другая проблема заключается в том, что иногда ответы на вопросы для восстановления пароля могут просочиться через социальные сети. Например, если один из вопросов для восстановления пароля: «какой ваш любимый фильм», то пространство для отгадывания здесь намного больше, например, я могу просмотреть ваш профиль на сайте IMDB или Facebook и найти там название вашего любимого фильма, которое вы сами мне подсказали.

И еще одна проблема, самая смешная, это то, что сами пользователи придумывают очень слабые вопросы для восстановления, например, чему будет равно 2 плюс 3? То есть пользователь думает, что для кого-то будет большой проблемой дать правильный ответ на подобные вопросы, но большинство людей, которые проходят тест Тьюринга, могут успешно на них ответить и использовать ваш пароль.

axbs8gyv9rhmxxd7a3mapzcqbum.jpeg

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

Профессор: я не знаю ни одного подобного исследования, но на самом деле эти вещи намного лучше. Я это знаю, потому что я пытался помочь своей подруге пройти через этот процесс. Она утратила контроль на своим аккаунтом Gmail и пыталась доказать, что это ее учетная запись. И владельцы сайта спрашивали её о таких вещах, как, например, когда именно она создала свой аккаунт, разговаривала ли она с кем-то о своём аккаунте, например, с «Хезболла», прежде чем утратила над ним контроль, и тому подобное. На самом деле это довольно трудоемкий процесс, но в конечном итоге для восстановления пароля дополнительная информация более сильная вещь, чем вопросы. Я не знаю никаких официальных исследований этой темы, но кажется, что это очевидно.

Если у вас нет вопросов, мы можем приступить к теме сегодняшней лекции, описанной в статье. Итак, авторы предлагают рассмотреть кучу факторов, которые могут использоваться для оценки эффективности схем проверки подлинности. Что действительно здорово в этой статье, так это то, что в ней говорится, что большинство из нас в сообществе безопасности борется только за эстетические принципы. Например, «мы должны выбрать это, потому что мне просто нравится, как фигурные скобки выглядят в доказательстве», или «мы должны выбрать это, потому что здесь используется много математических методов».

Они говорят, почему бы нам не попытаться установить какие-то критерии оценки эффективности? Может быть, некоторые из этих критериев будут немного субъективны, но давайте просто попробуем систематизировать способы оценки схем аутентификации. Давайте просто посмотрим, как эти различные схемы раскладываются по отдельным стопкам.

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

Некоторые из этих категорий довольно просты, некоторые включают в себя немного хитростей, но в этом заключён большой смысл. Если посмотреть на пароли, то они соответствуют данному требованию, потому что все привыкли использовать пароли, поэтому мы скажем, что их использованию легко научиться, и ответим «да».

Второе требование – редкость ошибок аутентификации. Это означает, что если вы являетесь фактическим пользователем системы, то при попытке вашей аутентификации не должны происходить ошибки. И здесь в отношении паролей авторы говорят, что они условно соответствуют этому параметру. «Условно» в данном случае означает, что авторы признают наличие субъективности в своей оценке. Таким образом, на вопрос, редко ли происходят ошибки при аутентификации с помощью паролей, мы не можем определённо ответить ни «да», ни «нет».

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

Следующее требование — это масштабируемость для пользователей. Основная идея здесь заключается в том, что если у пользователя есть куча разных сервисов, в которых он или она хочет аутентифицировать себя, хорошо ли масштабируется эта схема? Должен ли пользователь запоминать что-то новое для каждой из схем? Здесь в отношении паролей авторы однозначно говорят «нет», так как аутентификация с помощью паролей не удовлетворяет этому требованию. Потому что на практике пользователям очень сложно запомнить отдельный пароль для каждого сайта, на который они заходят. На самом деле это одна из причин, почему люди часто используют один и то же пароль для аутентификации в разных сервисах.

Еще одно требование удобства использования – это простота восстановления. То есть что произойдет, если вы утратите токен для аутентификации, в данном случае ваш пароль, легко ли будет его сбросить? В этом случае ответ для паролей — да. На самом деле, их даже слишком легко сбросить, как мы обсуждали несколько минут назад.

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

fxbmz7rvfvohsg5mvax6ijrcthk.jpeg

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

Итак, следующий параметр высокого уровня, который авторы статьи используют для оценки схемы аутентификации – это развертываемость, deployability. Он характеризует, насколько легко внедрить эту систему аутентификации в существующие сетевые сервисы. Например, они смотрят на совместимость с сервером, то есть легко ли интегрировать эту схему в современные сервера, в которых аутентификация основана на использовании текстовых паролей? В этом смысле пароли полностью соответствуют данному требованию, поэтому мы можем ответить «да».

Второе требование — совместимость с браузером, оно похоже на предыдущее и говорит, могу ли я использовать эту схему аутентификации для существующих популярных браузеров без необходимости установки плагина или чего-то в этом роде? Опять-таки, здесь пароли выигрывают по умолчанию.

Ещё одно интересное требование – это доступность, excessibility. То есть смогут ли использовать эту схему аутентификации люди с какими-то физическими недостатками, например, слепые или слабослышащие, с недостаточной моторикой и тому подобное. На самом деле это довольно важное требование.

Здесь авторы еще раз говорят „да“, что немного странно, потому что не ясно, как люди с ограниченными возможностями смогут использовать пароли, но авторы говорят, что смогут.

5ijwbippdprufyde22fnr9lk-ns.jpeg

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

Итак, последний параметр, который мы рассмотрим, — это безопасность, security. Какие же виды нападения эта схема может предотвратить? Я обозначу эту характеристику сокращенно Res – устройчивость к foo, где foo – это любое воздействие, способное причинить вред.

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

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

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

Далее следуют два требования, относящиеся к угадыванию. Первое – это устойчивость к интенсивному угадыванию. Это означает, что злоумышленник не сможет выдавать догадки со скоростью передачи данных по сети, например, при использовании защиты Antihammering. В этом смысле пароли небезопасны, так как легко подвергаются угадыванию методом перебора, и авторы статьи говорят «нет». Причина, почему они говорят „нет“, заключается в том, что на практике пароли не только имеют низкую энтропию наследования, потому что они не такие длинные, но и перекос в распределении. Поэтому при достаточно интенсивном переборе значений злоумышленник легко отгадывает пароли многих пользователей.

Ещё одно требование – устойчивость к не интенсивному угадыванию. Предположим, что злоумышленник может выдать запрос проверки аутентификации так быстро, как он хочет. Другими словами, злоумышленник ограничен только скоростью своего оборудования. И здесь схема аутентификации с помощью паролей также не соответствует требованию, и авторы говорят «нет» по той же причине, что и в предыдущем случае.

Таким образом, пароли преимущественно имеют очень маленькое энтропийное пространство и асимметричное распределение, так что с этим всё просто.

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

Так что если злоумышленник каким-то образом устанавливает клавиатурный перехватчик и получает пароль, он может использовать этот пароль до тех пор, пока не истечет срок его действия или он не будет отозван. Он сможет использовать его снова и снова для доступа к серверу. Так что пароли не проходят этот тест.

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

lrbcxx5fbsdriqsviuafsv5y5ci.jpeg

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

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

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

Родственным свойством обладает третье требование – стойкость к утечкам через сторонние сервисы, в которых происходит аутентификация. Имеется ввиду, что некоторые сервисы подвержены утечке информации, которая поможет атакующему использовать ваши данные для аутентификации в других сервисах. В основном это мошеннические схемы, когда один сайт незаконным путём может передавать ваши персональные данные другому сайту или сервису. Здесь с паролями складывается та же ситуация, что и в предыдущем требовании – если мы не доверяем никаким третьим сторонам, то мы не доверяем и сторонним системам аутентификации.
Проблема здесь заключается в том, что стойкость всей системы равна стойкости самого слабого звена, например, HTTPS или СА. Например, если скомпрометирован один центр авторизации CA, то его сертификаты могут быть распространены по множеству сайтов. Если кто-то ошибочно выдаст сертификат СА стороне, не заслуживающей доверия, он нанесёт ущерб всем участникам системы.

pleayyascjo0wsynx8gwbrnqkda.jpeg

Авторы статьи считают, что пароли не ответствуют этому требованию, поэтому говорят «нет». Это связано с тем, что пользователи часто используют один и тот же пароль на множестве различных сайтов. Например, если кто-то украдёт мой пароль от аккаунта Gmail, он автоматически завладеет и моим паролем для аккаунта на Facebook.

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

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

Одной из интересных характеристик биометрии является размерность ключей, определяющая степень энтропии. Размерность ключей не настолько велика, каким должна была бы являться. Например, для отпечатков пальцев размерность ключа составляет примерно 13,3 бита, для сканирования сетчатки глаза – 19,9 бит, распознавание голоса имеет размерность ключа, или показатель энтропии порядка 11,7 бит.

54:15 сек

Курс MIT «Безопасность компьютерных систем». Лекция 17: «Аутентификация пользователя», часть 3


Полная версия курса доступна здесь.

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до декабря бесплатно при оплате на срок от полугода, заказать можно тут.

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Дата: 2018-11-14 21:30:53

Источник: https://habr.com/post/429682/



BabySploit - BabySplot Beginner Pentesting Framework

BabySploit_7.png

Tested on Kali Linux. Should work with all Debian based distros (and other ones if you have the right packages installed)
BabySploit is a penetration testing framework aimed at making it easy to learn how to use bigger, more complicated frameworks like Metasploit. With a very easy to use UI and toolkit, anybody from any experience level will find use out of BabySploit.

BabySploit_8.png

Features (Current, In The Works, Planned):

Information Gathering:

Exploitation:

Post Exploitation:

Bruteforcing:

Phishing:

Crypto/Steno:

Дата: 2018-11-14 20:57:00

Источник: http://www.kitploit.com/2018/11/babysploit-babysplot-beginner.html



Семь новых атак на механизм спекулятивного выполнения в CPU

Группа исследователей безопасности, из которых трое (Daniel Gruss, Michael Schwarz, Moritz Lipp) участвовали в выявлении первых уязвимостей Meltdown и Spectre, опубликовали сведения о семи новых атаках, затрагивающих механизм спекулятивного выполнения инструкций современных процессоров. Возможность проведения атак протестирована на CPU Intel, AMD и ARM. Две новые атаки являются вариантами уязвимости Meltdown (Meltdown-PK для CPU Intel и Meltdown-BR для Intel и AMD), а оставшиеся пять представляют собой варианты уязвимости Spectre (применимы для Intel, AMD и ARM). Для всех семи атак подготовлены работающие прототипы эксплоитов.

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

0_1542219665.png

Выявленные проблемы класса Meltdown (позволяют получить доступ к памяти приложений других пользователей, операционной системы и виртуальных окружений):

Выявленные проблемы класса Spectre:

По заявлению компании Intel все из упомянутых в отчёте уязвимостей могут быть блокированы с использованием уже применяемых для Spectre и Meltdown методов защиты (производители процессоров и операционных систем были заранее уведомлены о проблемах).

0_1542219756.png

Дата: 2018-11-14 18:55:47

Источник: http://www.opennet.ru/opennews/art.shtml?num=49608



«Лаборатория Касперского» помогла закрыть 0-day в Windows 7

В очередном пакете обновлений для Windows разработчики Microsoft закрыли уязвимость нулевого дня, которую ранее обнаружили эксперты «Лаборатории Касперского». По сообщению компании, преступники уже попытались использовать ее в реальных атаках.

Проблема, которая актуальна для Windows 7, Windows Server 2008 и Windows Server 2008 R2, содержится в драйвере режима ядра win32k.sys. Как объясняют эксперты, злоумышленники могут создать состояние гонки (race condition), манипулируя обменом сообщениями между двумя взаимосвязанными потоками. В результате взломщик получает привилегии, достаточные для закрепления в системе.

Уязвимость получила идентификатор CVE‑2018‑8589. Обнаружить ее удалось благодаря собственным технологиям «Лаборатории Касперского» в области поведенческого анализа. В октябре эти системы зафиксировали подозрительную активность в Ближневосточном регионе. Преступники применили эксплойт, чтобы повысить привилегии в системе своей жертвы и установить зловредное ПО.

Эксперты «Лаборатории Касперского» передали информацию разработчикам Microsoft 17 октября. Тем понадобилось около четырех недель для подготовки и публикации патча. За это время специалисты зарегистрировали еще несколько случаев применения уязвимости, однако их количество осталось незначительным. Все жертвы находятся на Ближнем Востоке и работают в 32-битной версии ОС.

Ранее в октябре Microsoft устранила еще одну брешь нулевого дня, о которой компании сообщили специалисты «Лаборатории Касперского». Уязвимость, которая нашла активное применение в продвинутых хакерских атаках, позволяла выполнить произвольный код в режиме ядра.

Дата: 2018-11-14 17:36:23

Источник: https://threatpost.ru/microsoft-patches-windows-7-zero-day-dicovered-itw-by-kl-researchers/29173/