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

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




Лучшие белые хакеры зарабатывают в 2,7 раза больше средних программистов

myjxchn1h7ibcb0epgg-qrt2cn4.jpegСообщество HackerOne, на котором зарегистрировано более 160 000 хакеров и которое выплатило им уже $23,5 млн за найденные уязвимости, опубликовало отчёт The 2018 Hacker Report. Это крупнейший в истории опрос этичных хакеров, в котором приняло участие 1698 респондентов. Вместе с результатами приведена интересная статистика.

Ключевые результаты:



Интересно посмотреть на распределение денежных потоков по странам. Слева на диаграмме — компании из каких стран выплатили вознаграждение. А справа — жители каких стран его получили.

lmibea230udyitiebx02t7ohoyc.png

Как видим, россияне входят в число лидеров и за год заработали $1 296 018.

Типичный хакер — юный одарённый IT-профессионал до 35 лет. Почти половина всех хакеров не достигла ещё и 25 лет. У 75,1% опыт хакерства составляет всего лишь 1-5 лет.

46,7% хакеров работает профессионально по специальности (специалисты по ИБ или программисты), а 25,3% — студенты. Около 13% сказали, что занимаются взломами полный рабочий день, то есть более 40 часов в неделю.

Любопытная статистика по инструментам, которые используют хакеры. Преимущественно сейчас все специализируются на веб-платформе, то есть взломе веб-сайтов и веб-приложений. Так вот, самые популярные инструменты:


После веб-сайтов (70,8%) с большим отрывом по хакерскому интересу следуют API (7,5%) и технологии, где хранятся данные самого хакера или где он является пользователем (5%). Операционные системы больше не так популярны как объект для взлома (3,1%), уступая даже Android-приложениям (4,2%).

Любимые векторы атаки — XSS (28,8%), SQL-инъекции (23,1%), фаззинг (5,5%) и брутфорс (4,5%).

Большинство предпочитают работать в одиночку, хотя многие публикуют результаты у себя в блоге, чтобы получить отзывы коллег, и читают их блоги.

Дата: 2018-01-18 12:41:26

Источник: https://habrahabr.ru/post/346944/



Успешная атака принесла преступникам десятки тысяч долларов

Американская клиника Hancock Health заплатила взломщикам 55 тысяч долларов за расшифровку своих файлов. Глава организации Стив Лонг (Steve Long) объяснил, что восстановление информации из резервных копий заняло бы несколько дней и обошлось бы гораздо дороже.

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

Уже в пятницу 12 января менеджмент Hancock Health согласился на выкуп, а утром субботы данные были снова доступны. К понедельнику все системы вернулись в рабочее состояние.

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

Руководитель клиники заверил пациентов, что преступники не покусились на их конфиденциальные данные. Работа медицинского оборудования также не нарушалась. Единственное неудобство для клиентов состояло в невозможности просмотреть свои записи на внешнем портале Hancock Health. Врачи во время простоя IT-систем были вынуждены вести записи с помощью ручек и блокнотов.

Клиника привлекла к решению проблемы внешних специалистов по кибербезопасности и проконсультировалась с ФБР. Государственные агенты традиционно не рекомендуют соглашаться на условия преступников, однако оставляют принятие финального решения жертвам атаки. Лонг отметил, что к оплате выкупа их подтолкнула, в том числе, холодная погода, которая вызвала вспышку заболеваний в регионе.

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

В 2016 году «Лаборатория Касперского» совместно с Европолом, Intel Security и полицией Нидерландов запустила проект No More Ransom, который призван помочь жертвам программ-вымогателей.

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

Дата: 2018-01-18 12:31:01

Источник: https://threatpost.ru/us-clinic-pays-ransom/24146/



[Перевод] Как ошибку Spectre, способную сломать индустрию, держали в тайне семь месяцев

a04b663ee5a7c1e3a7d570e4d87555ce.jpg

Когда исследователь Майкл Шварц из Грацского технического университета впервые связался с компанией Intel, он думал, что расстроит её. Он нашёл проблему в их чипах, работая совместно с коллегами — ему помогали Дэниел Грасс, Мориц Лип и Стефан Мангард. Уязвимость была глубокой и легко используемой. Его команда закончила писать эксплоит 3-го декабря, воскресным днём. Оценив возможные последствия своей находки, они немедленно написали в Intel.

Ответ Шварц получил только через девять дней. Но когда ему позвонили из компании, Шварц удивился: компания уже знала о проблемах с ЦП, и отчаянно пыталась понять, как их исправить. Более того, компания делала всё возможное, чтобы гарантировать, что больше никто не узнает об этом. Они поблагодарили Шварца за его вклад, но сказали, что обнаруженная им информация совершенно секретна, и дали ему дату, после которой этот секрет можно было раскрывать.

Проблема, которую обнаружил Шварц — и, как он потом узнал, много кто ещё — потенциально была катастрофической. Уязвимость на уровне схемы чипа, которая могла замедлить работу любого процессора в мире, при отсутствии идеального исправления за исключением переработки всего чипа. Она поразила практически все крупные технокомпании мира, от серверных ферм Amazon до производителей чипов вроде Intel и ARM. Но Шварц столкнулся с ещё одной проблемой: как сохранять в секрете такую серьёзную уязвимость достаточно долго, чтобы её можно было исправить?

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

У преждевременного раскрытия есть последствия. После обнародования информации наступает путаница — например, подвержены ли чипы от AMD атакам Spectre (подвержены) или характерен ли Meltdown только для Intel (чипы от AMD тоже пострадали). Антивирусные системы оказались пойманными врасплох, и ненамеренно заблокировали множество критических патчей. Разработку других патчей пришлось приостановить после того, как компьютеры переставали работать из-за них. Один из лучших инструментов, подходящих для исправления уязвимости, Retpoline, разрабатывала команда по реагированию на происшествия Google, и изначально они планировали выпустить его одновременно с информацией о баге. Но хотя команда разработчиков Retpoline утверждает, что её не застали врасплох, код этого инструмента не выкладывали в общий доступ вплоть до дня, последовавшего за тем, когда впервые было объявлено о наличии уязвимости, в частности из-за случайного прорыва секретности.

Что больше всего волнует, так это что многие критически важные группы, реагирующие на уязвимости, вообще были не в курсе происходящего. Самое влиятельное предупреждение по поводу имеющейся уязвимости пришло из подразделения CERT Карнеги-Мелон, работающего с Министерством внутренней безопасности по вопросам обнародования уязвимостей. Но, согласно главному аналитику уязвимостей Уилу Дорману, в CERT не знали об этой проблеме до тех пор, пока не были запущены сайты Meltdown и Spectre, что привело к усилению хаоса. В изначальном отчёте замена ЦП была указана как единственное решение. Технически такой совет был правильным в случае с ошибкой в схеме процессоров, но он лишь приумножил панику среди менеджеров в сфере IT, представивших себе, как они выковыривают и заменяют ЦП на всех подотчётных устройствах. Через несколько дней Дорман с коллегами решили, что их совет на практике неприменим, и заменили рекомендацию на простую установку патчей.

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

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

Первый шаг в раскрытии уязвимостей Meltdown и Spectre был сделан шесть месяцев назад, до открытия Шварца, в письме от 1 июня, отправленном Яном Хорном, участником проекта Google Project Zero. Письмо, направленное в Intel, AMD и ARM, расписывалась новая уязвимость, которая получит название Spectre, и демонстрировался эксплоит процессоров Intel и AMD, и неприятные последствия для ARM. Хорн подошёл к этому с осторожностью и выдал изготовителям только необходимый минимум информации. Он специально обратился к трём производителям чипов, и призвал каждую компанию разобраться с тем, как ей самой предать дело огласке и связаться с другими компаниями, на которых ситуация может сказаться. В то же время Хорн предупредил их, чтобы они не распространяли информацию слишком далеко и слишком быстро.

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

Довольно сложным делом оказалось установить, кто именно подвержен уязвимости. Началось всё с изготовителей чипов, но вскоре стало понятно, что необходимо будет патчить операционные системы, что требовало привлечения ещё одного круга исследователей. Это должно повлиять и на браузеры, а также на массивные облачные сервисы, управляемые компаниями Google, Microsoft и Amazon, которые можно было считать наиболее привлекательными целями для нового бага. В итоге десяткам компаний со всех концов света придётся выпускать тот или иной патч.

Официальной политикой Project Zero было предоставлять 90 дней перед публикацией новостей, но чем больше компаний присоединялось к кругу избранных, тем сильнее Project Zero уступал своим требованиям, и продлил этот период больше, чем в два раза. Шли месяцы, компании начали выпускать собственные патчи, стараясь скрыть, что именно они исправляли. Команда реагирования на происшествия из Google получила информацию в июле, через месяц после первого предупреждения от Project Zero. Программа Microsoft Insiders выпустила тихий ранний патч в ноябре. В этот период директор Intel Брайан Кржанич совершал более спорные действия, в октябре заказав автоматическую продажу акций на 29-е ноября. 14 декабря клиенты Amazon Web Server получили предупреждение, что 5 января волна перезагрузок компьютеров может сказаться на быстродействии. Ещё один патч от Microsoft был скомпилирован и выпущен в канун Нового года, что говорит, что команда компании, вероятно, работала над ним всю ночь. В каждом из случаев причины изменений были размытыми, и пользователи мало что знали о том, что именно исправляется.

Нельзя однако переписать основы инфраструктуры интернета, чтобы это кто-нибудь не заметил. Самые толстые намёки пришли из мира Linux. Эта ОС, на которой работает большинство облачных серверов в интернете, обязана играть большую роль в любом исправлении ошибок Spectre и Meltdown. Но, так как исходный код этой системы открыт, любые изменения придётся предъявлять общественности. Каждый апдейт выкладывался на открытый Git-репозиторий, и все официальные обсуждения проходили на общедоступном списке рассылки. Когда для загадочной функции «page table isolation» один за другим начали выходить патчи для ядра ОС, пристально наблюдавшие за этим люди поняли, что что-то не так.

Самым большим намёком стало событие от 8 декабря, когда Линус Торвальдс принял новый патч, изменявший то, как ядро Linux работает с процессорами x86. «Это исправление, кроме того, что исправляет утечки KASLR), также усиливает код для x86», — пояснил Торвальдс. А самый последний выпуск ядра вышел всего за день до этого. Обычно патч должен был подождать включения в следующий релиз, но по какой-то причине этот патч был слишком важным. Отчего же обычно капризный Торвальдс вдруг так просто включил внештатное обновление, особенно если оно вроде бы может замедлить работу ядра?

Ещё страннее выглядело вдруг появившееся письмо месячной давности, в котором предлагалось обновить старые ядра новым патчем задним числом. Суммируя слухи, 20-го декабря ветеран Linux Джонатан Корбет написал, что проблема с таблицей страниц «имеет все признаки патча безопасности, выпущенного под давлением дедлайна».

И всё же им было известно не всё. Page Table Isolation, «изоляция таблицы страниц» — это способ отделить пространство ядра от пространства пользователей, поэтому проблема явно была в какой-то утечке из ядра. Но оставалось непонятным, что именно неправильно работало в ядре или как далеко распространялось действие этого бага.

Следующее известие пришло от самих производителей чипов. В новом патче Linux описал все процессоры x86 как уязвимые, включив туда и процессоры от AMD. Поскольку патч занижал быстродействие, AMD была не рада включению этого патча. На следующий день после Рождества [католического, 25 декабря / прим. перев.] инженер AMD Том Лендаки отправил письмо в список рассылки по ядру Linux, объясняя, почему именно чипам от AMD патч не требовался.

«Микроархитектура AMD не позволяет оперировать такими ссылками на память, в том числе спекулятивными, которые получают доступ к привилегированным данным, работая в менее привилегированном режиме, в тех случаях, когда такой доступ может привести к ошибке „page fault“, — писал Лендаки.

Вся эта история переполнена техническими терминами, но для всех людей, пытавшихся выяснить сущность ошибки, она звучала, как пожарная тревога. Инженер из AMD точно знал об уязвимости, и говорил, что проблема ядра проистекала из чего-то такого, что процессоры делают уже почти 20 лет. Если проблемой были спекулятивные ссылки, эта проблема касалась всех — и для её исправления должно потребоваться нечто гораздо большее, чем простое исправление ядра.

»Это послужило толчком, — говорит Крис Уильямс, редактор The Register. — До того момента никто не упоминал спекулятивные ссылки на память. Только после появления этого письма мы поняли, что что-то не так".

Когда стало ясно, что проблема связана со спекулятивными ссылками, исследователи смогли дорисовать картину до конца. Годами исследователи безопасности искали методы взлома ядра через спекулятивное выполнение программ; команда Шварца из Граца опубликовала работу по этому поводу аж в июне. Андерс Фог опубликовал свои попытки похожих атак в июле, хотя они и не увенчались успехом. Всего через два дня после письма из AMD исследователь под ником brainsmoke представил работу по этой теме на конференции Chaos Computer Congress в Лейпциге. Все эти работы не привели к открытию бага, пригодного для эксплуатации, но благодаря ним стало ясно, как он должен выглядеть — и выглядел он крайне плохо.

Фог сказал, что с самого начала было ясно — любой рабочий баг обернётся катастрофой. «Когда вы начинаете изучать что-то подобное, вы уже знаете, что ваш успех приведёт к очень плохим последствиям», — сказал он мне. После выпуска Meltdown и Spectre и разразившегося хаоса, Фог решил не публиковать дальнейшие исследования по этой теме.

На последовавшей неделе слухи о баге стали просачиваться через Twitter, списки рассылки и форумы. Обычный измеритель скорости, пролетевший в списке рассылки PostgreSQL, обнаружил 17% замедление быстродействия — ужасное число для людей, ожидавших патч. Другие исследователи писали неформальные посты, описывая всё, что им известно, и подчёркивали, что это всего лишь слухи. «Эта статья в основном предоставляет догадки, до тех пор, пока не будет отменено эмбарго», — писал один из авторов. «А в этот день следует ожидать фейерверков и драматических событий».

К Новому году слухи стало невозможно игнорировать. Уильямс решил, что пора что-то написать. 2-го января The Register опубликовала статью о том, что они назвали «недостатком в схеме процессоров Intel». Там описывалось то, что происходило в списке рассылки Linux, зловещее письмо из AMD, и ранние исследования. «Из того, что описал программист Том Лендаки из AMD, следует, что ЦП от Intel грешат спекулятивным выполнением кода без проверок на безопасность», — говорилось в статье. — Это позволит пользовательскому коду уровня ring-3-level читать данные с уровня ядра ring-0-level. А это нехорошо".

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

И в любом случае эмбарго продержалось бы всего ещё один день. Официальный выпуск планировался на 9 января, одновременно с четверговыми патчами от Microsoft и прямо в разгар выставки потребительской электроники Consumer Electronics Show, что могло бы приглушить плохие новости. Но комбинация из диких слухов и доступных исследователей сделала невозможным сдерживание новостей. Репортёры забрасывали исследователей письмами, и все, кто имел в этому отношение, изо всех сил старался сохранять молчание, поскольку вероятность того, что секрет продержится ещё неделю, постоянно уменьшалась.

Переломный момент наступил благодаря brainsmoke. Он был одним из малого числа исследователей ядра, на которых не распространялось эмбарго, поэтому он воспринял слухи как руководство к действию и решил отыскать этот баг. На следующее утро после статьи в The Register он его нашёл, и твитнул скриншот своего терминала в качестве доказательства. «Никаких page fault не нужно, — писал он в последовавшем твите. — Основной вопрос, судя по всему, содержится в том, чтобы перетаскивать всё в кэш и из кэша».

Когда исследователи увидели этот твит, всё и завертелось. Команда из Граца твёрдо решила не раскрывать карты до Google или Intel, но после распространения доказательств возможности использования бага из Google поступило сообщение о том, что эмбарго будет отменено в тот же день, 3 января, в 2 часа дня по тихоокеанскому времени. В назначенный час полная версия исследования появилась на двух специально подготовленных сайтах, вместе с предварительно подготовленными логотипами каждой из уязвимостей. Сообщения потекли рекой из ZDNet, Wired и The New York Times, часто описывая информацию, собранную всего за несколько часов до этого. После более чем семи месяцев планирования секрет, наконец, вышел наружу.

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

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

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

«Возможно, лучше уже нельзя было ничего сделать, — сказала она. — Стандарты ISO могут сказать вам, о чём нужно задуматься, но они не скажут вам, что делать на пике развития подобной ситуации. Это похоже на то, как вы читаете инструкции и выполняете парочку учебных тревог. Хорошо, когда есть план, но когда ваш дом горит, вы действуете не так, как написано в плане».

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

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

Дата: 2018-01-18 12:00:01

Источник: https://geektimes.ru/post/297311/



Интернету грозит фрагментация из-за кибератак

Трансграничные кибератаки могут привести к распаду Глобальной сети на региональные сегменты.

В результате трансграничных кибератак интернет может распасться на отдельные национальные и региональные участки. Об этом сообщается в докладе «Глобальные риски – 2018», представленном на Всемирном экономическом форуме (ВЭФ) в Женеве.

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

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

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

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

Дата: 2018-01-18 11:09:05

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



ПДн. Изменения в законодательстве РФ за 2017 г.


Федеральный закон от 29.07.2017 N 214-ФЗ
"О проведении эксперимента по развитию курортной инфраструктуры в Республике Крым, Алтайском крае, Краснодарском крае и Ставропольском крае"
 ...обязаны осуществлять учет плательщиков курортного сбора и освобождаемых от уплаты курортного сбора лиц, которым были оказаны услуги, указанные в пункте 3 части 1 статьи 3 настоящего Федерального закона, с соблюдением требований Федерального закона от 27 июля 2006 года N 152-ФЗ "О персональных  данных ".
Федеральный закон от 29.07.2017 N 217-ФЗ
"О ведении гражданами садоводства и огородничества для собственных нужд и о внесении изменений в отдельные законодательные акты Российской Федерации"
 2. Обработка персональных  данных , необходимых для ведения реестра членов товарищества, осуществляется в соответствии с настоящим Федеральным законом и законодательством о персональных  данных .
Федеральный закон от 31.12.2017 N 485-ФЗ
"О внесении изменений в Жилищный кодекс Российской Федерации и отдельные законодательные акты Российской Федерации"
 Согласие собственников помещений в многоквартирном доме на передачу персональных  данных , содержащихся в реестре собственников помещений в многоквартирном доме, при предоставлении этого реестра в порядке, установленном настоящей частью, в целях созыва и организации проведения общего собрания собственников помещений в многоквартирном доме не требуется.";
Федеральный закон от 25.11.2017 N 328-ФЗ
"О внесении изменений в Федеральный закон "Об ипотеке (залоге недвижимости)" и отдельные законодательные акты Российской Федерации"
 "7. Депозитарий по запросу предоставляет персональные  данные  заемщика и (или) залогодателя - физического лица лицу, на счете которого учитываются права на обездвиженную документарную закладную или на электронную закладную, в целях осуществления таким лицом своих прав по обездвиженной документарной закладной или электронной закладной.
Федеральный закон от 29.07.2017 N 240-ФЗ
"О внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации"
 7) согласие на обработку своих персональных  данных  и предоставление их третьим лицам исключительно в целях урегулирования задолженности.
Федеральный закон от 31.12.2017 N 504-ФЗ
"О внесении изменений в Федеральный закон "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд"
 ...комиссии должно включаться одновременно с контрактом, заключенным в соответствии с настоящим пунктом, в реестр контрактов, предусмотренный статьей 103 настоящего Федерального закона, при условии обеспечения предусмотренного Федеральным законом от 27 июля 2006 года N 152-ФЗ "О персональных  данных " обезличивания персональных  данных ;
Федеральный закон от 31.12.2017 N 498-ФЗ
"О внесении изменений в отдельные законодательные акты Российской Федерации в части проведения государственной дактилоскопической регистрации в Российской Федерации"
 Часть 2 статьи 11 Федерального закона от 27 июля 2006 года N 152-ФЗ "О персональных  данных " (Собрание законодательства Российской Федерации, 2006, N 31, ст. 3451; 2009, N 48, ст. 5716; 2011, N 31, ст. 4701; 2014, N 23, ст. 2927) после слова "актов," дополнить...
Федеральный закон от 31.12.2017 N 482-ФЗ
"О внесении изменений в отдельные законодательные акты Российской Федерации"
 ...лица, и сведения, предусмотренные абзацем вторым подпункта 1 пункта 1 настоящей статьи, а также в единой информационной системе персональных  данных , обеспечивающей сбор, обработку, хранение биометрических персональных  данных , их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным  данным  физического лица (далее - единая биометрическая...
Федеральный закон от 29.12.2017 N 455-ФЗ
"О внесении изменений в Градостроительный кодекс Российской Федерации и отдельные законодательные акты Российской Федерации"
 14. Обработка персональных  данных  участников общественных обсуждений или публичных слушаний осуществляется с учетом требований, установленных Федеральным законом от 27 июля 2006 года N 152-ФЗ "О персональных  данных ".
Федеральный закон от 27.11.2017 N 335-ФЗ
(ред. от 28.12.2017)
"О внесении изменений в части первую и вторую Налогового кодекса Российской Федерации и отдельные законодательные акты Российской Федерации"
 ...показателей по всем физическим лицам не соответствуют этим же показателям в целом по плательщику страховых взносов и (или) в расчете указаны недостоверные персональные  данные , идентифицирующие застрахованных физических лиц, такой расчет считается непредставленным, о чем плательщику не позднее дня, следующего за днем получения расчета в электронной форме...
Федеральный закон от 05.12.2017 N 376-ФЗ
"О внесении изменений в Воздушный кодекс Российской Федерации"
 "2. В целях ведения реестров лиц, воздушная перевозка которых ограничена, перевозчики осуществляют обработку персональных  данных  пассажиров в соответствии с законодательством Российской Федерации в области персональных  данных .";
Федеральный закон от 05.12.2017 N 386-ФЗ
"О внесении изменений в статью 46 Федерального закона "О связи" и статью 1 Федерального закона "О внесении изменений в Федеральный закон "О связи"
 ...средств массовой информации, массовых коммуникаций, информационных технологий и связи, сформированного по результатам контрольных мероприятий, в случае неподтверждения в течение пятнадцати суток соответствия персональных  данных  фактических пользователей сведениям, заявленным в абонентских договорах, а также в случае предотвращения и пресечения преступлений с использованием сетей связи и средств связи;";".
Федеральный закон от 29.07.2017 N 245-ФЗ
(ред. от 05.12.2017)
"О внесении изменений в Федеральный закон "О связи"
 ...средств массовой информации, массовых коммуникаций, информационных технологий и связи, сформированного по результатам контрольных мероприятий, в случае неподтверждения в течение пятнадцати суток соответствия персональных  данных  фактических пользователей сведениям, заявленным в абонентских договорах, а также в случае предотвращения и пресечения преступлений с использованием сетей связи и средств связи;";
Федеральный закон от 29.07.2017 N 223-ФЗ
"О внесении изменений в отдельные законодательные акты Российской Федерации"
 Внести в Федеральный закон от 27 июля 2006 года N 152-ФЗ "О персональных  данных " (Собрание законодательства Российской Федерации, 2006, N 31, ст. 3451; 2009, N 48, ст. 5716; 2010, N 27, ст. 3407; 2011, N 23, ст. 3263; N 31, ст. 4701; 2013, N...
Федеральный закон от 29.07.2017 N 266-ФЗ
"О внесении изменений в Федеральный закон "О несостоятельности (банкротстве)" и Кодекс Российской Федерации об административных правонарушениях"
 ...законом от 1 декабря 2007 года N 315-ФЗ "О саморегулируемых организациях", обязана разместить с соблюдением требований федеральных законов, предъявляемых к защите информации (в том числе персональных  данных ), на своем сайте в информационно-телекоммуникационной сети "Интернет":
Федеральный закон от 29.07.2017 N 242-ФЗ
"О внесении изменений в отдельные законодательные акты Российской Федерации по вопросам применения информационных технологий в сфере охраны здоровья"
 5. Применение телемедицинских технологий при оказании медицинской помощи осуществляется с соблюдением требований, установленных законодательством Российской Федерации в области персональных  данных , и соблюдением врачебной тайны.
Федеральный закон от 01.07.2017 N 148-ФЗ
"О внесении изменений в Федеральный закон "О государственной охране" и отдельные законодательные акты Российской Федерации"
 "9) обеспечение защиты персональных  данных  объектов государственной охраны и членов их семей.";
Федеральный закон от 22.02.2017 N 16-ФЗ
"О внесении изменений в главу 5 Федерального закона "О персональных данных" и статью 1 Федерального закона "О защите прав юридических лиц и индивидуальных предпринимателей при осуществлении государственного контроля (надзора) и муниципального контроля"
Федеральный закон от 07.02.2017 N 13-ФЗ
"О внесении изменений в Кодекс Российской Федерации об административных правонарушениях"
 "Статья 13.11. Нарушение законодательства Российской Федерации в области персональных  данных
Федеральный закон от 07.02.2017 N 7-ФЗ
"О внесении изменений в Федеральный закон "О государственной защите судей, должностных лиц правоохранительных и контролирующих органов" и Федеральный закон "О государственной защите потерпевших, свидетелей и иных участников уголовного судопроизводства"
 "По решению органа, обеспечивающего безопасность, может быть наложен временный запрет на выдачу находящихся у оператора данных о личности защищаемых лиц (персональных  данных ), за исключением случаев, если такие сведения выясняются в установленном порядке в связи с производством по уголовному делу.";

Дата: 2018-01-18 10:42:31

Источник: http://sborisov.blogspot.com/2018/01/2017.html



Новый ботнет инфицирует технику майнеров, заменяя адреса кошельков

89a783097dc5af24606477a6847f8dae.jpg

Satori — семейство зловредного программного обеспечения, представители которого поражают роутеры, камеры наблюдения и другие IoT устройства. Цель — формирование ботнетов, что позволяет выполнять различные задачи — от DDoS до более сложных, вроде майнинга. Но сейчас появился новый представитель этого семейства, который ничего не майнит, а просто ворует добываемые коины.

8 января представители компании по информационной безопасности Netlab 360 из Китая опубликовали отчет, в котором сообщается про обнаружение зловреда, захватывающего майнинговые системы. Новая версия Satori использует уязвимости в Claymore Miner, заменяя адрес кошельков владельцев майнингового оборудования кошельками злоумышленников.

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

Кошелек известен, и сколько там находится денег тоже известно. За все время было добыто всего лишь две монеты Ethereum, так что огромных доходов разработчики червя (пока) не получили. Но если вирус окажется заразным, потоки финансов могут увеличиться многократно. На данный момент производительность захваченного зловредом оборудования составляет около 2,1 миллионов хэшей в секунду. Такую мощность могут развить 85 ПК с картой Radeon Rx 480 или 1135 компьютеров с картами GeForce GTX 560M.

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

Стоит отметить, что семейство Satori — это модифицированная версия ботнета Mirai, исходники которого с недавних пор находятся в общем доступе. Mirai захватывает контроль над устройствами Интернета вещей, а в 2016 году этот ботнет стал развиваться очень быстрыми темпами, что стало причиной довольно значительных проблем.

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

Исследователи из Netlab 360 утверждают, что новая версия Satori, заточенная на криптовалюты появилась 8 января. Она анализирует устройства на предмет двух различных IoT уязвимостей, плюс использует дыру в ПО Claymore Mining, о чем и говорилось выше.

Пока что точно неясно каким именно образом новый вирус инфицирует компьютеры, добывающие криптовалюты. Сейчас известно, по крайней мере, об одной уязвимости в Claymore Mining. Насколько можно понять, червь работает с 3333 портом с дефолтными настройками (без аутентификации).

Большего количества данных компания Netlab 360 не предоставила во избежание получения полезной для своей работы информации злоумышленниками. Разработчики Claymore Mining пока не ответили на заявления кибербезопасников.

А вот кто-то из разработчиков Satori добавил сообщение следующего содержания: «Не переживайте из-за этого бота, он не выполняет никаких вредных действий. Со мной можно связаться по адресу curtain@riseup.net». Довольно странное заявление, поскольку уже то, что зловред заменяет кошельки майнеров на кошельки собственных разработчиков, явно нельзя назвать безобидным действием.

Что касается Satori, то это далеко не единственный «наследник» Mirai. В октябре прошлого года исследователи заявили о том, что в Сети обнаружилась новая проблема — еще один мощный зловред, который стал известен под названиями Reaper и IoTroop. Он также находит уязвимости в ПО и аппаратном обеспечении «облачных» устройств, и заражает их, превращая в зомби.

Дата: 2018-01-18 10:37:14

Источник: https://geektimes.ru/post/297319/



Подборка бесплатных утилит компьютерной криминалистики (форензики)

image

В этой статье представлены бесплатные инструменты для проведения расследования инцидентов информационной безопасности.

Дисковые инструменты и сбор данных


Arsenal Image Mounter утилита для работы с образами дисков в Windows, доступ к разделам и томам и т. д.

DumpIt утилита для создания дампа физической памяти компьютеров Windows, 32/64 бит. Может работать с USB-накопителя.

EnCase Forensic Imager утилита для создания доказательных файлов EnCase.

Encrypted Disk Detector утилита для выявления зашифрованных томов TrueCrypt, PGP или Bitlocker.

EWF MetaEditor утилита для редактирования метаданных EWF (E01).

FAT32 Format утилита для форматирования дисков большой емкости в FAT32.

Forensics Acquisition of Websites браузер, предназначенный для захвата веб-страниц для проведения расследований.

FTK Imager просмотр и клонирование носителей данных в среде Windows.

Guymager многопоточный утилита с GUI для создания образов дисков под управлением Linux.

Live RAM Capturer утилитая для извлечения дампа RAM, в том числе защищенный анти-отладочной или антидампинговой системой.

NetworkMiner инструмент сетевого анализадля обнаружения ОС, имени хоста и открытые портов сетевых узлов с помощью перехвата пакетов / анализа PCAP.

Magnet RAM Capture утилита для захвата RAM от Windows XP до Windows 10, Win Server 2003, 2008, 2012.

OSFClone утилита live CD/DVD/USB для создания dd или AFF образов.

OSFMount утилита для монитирования образов дисков, также позволяет создавать RAM-диски.

Анализ электронной почты


EDB Viewer утилита для просмотра файлов EDB Outlook без сервера Exchange.

Mail Viewer утилита для просмотра файлов Outlook Express, Windows Mail/Windows Live Mail, базы данных сообщений Mozilla Thunderbird и отдельных файлов EML.

MBOX Viewer утилита для просмотра электронных писем и вложений MBOX.

OST Viewer утилита для просмотра файлов OST Outlook без сервера Exchange.

PST Viewer утилита для просмотра файлов PST Outlook без сервера Exchange.

Анализ файлов и данных

analyzeMFT утилита парсинга MFT из файловой системы NTFS, позволяя анализировать результаты с помощью других инструментов.

bstrings утилита поиска в двоичных данных, включая поиск регулярных выражений.

CapAnalysis утилита просморта PCAP.

Crowd Response консольное приложение Windows для помощи в сборе системной информации для реагирования на инциденты и обеспечения безопасности.

Crowd Inspect утилита для получения информации о сетевых процессах, перечислении двоичных файлов, связанных с каждым процессом. Создает запросы к VirusTotal и другим онлайн-средствам анализа вредоносных программ и служб репутации.

DCode утилита преобразует различные типы данных в значения даты / времени.

Defraser утилита для обнаружения полных и частичных данных о мультимедийных файлах в нераспределенном пространстве.

eCryptfs Parser утилита рекурсивно анализирует заголовки каждого файла eCryptfs в выбранном каталоге.

Encryption Analyzer утилита для анализа защищенных паролем и зашифрованных файлов, анализирует сложность шифрования отчетов и варианты дешифрования для каждого файла.

ExifTool утилита для чтения и редактирования данных Exif в большом количестве типов файлов.

File Identifier онлайн анализ типа файлов (более 2000).

Forensic Image Viewer утилита для извлечения данных из изображений.

Link Parser утилита для рекурсивного анализа папок, извлекающая более 30 атрибутов из файлов Windows .lnk (shortcut).

Memoryze анализ образов RAM, включая анализ «page» файлов.

MetaExtractor утилита для извеления мета-информации из офисных документов и pdf.

Shadow Explorer утилита для просмотра и извлечения файлов из теневых копий.

Инструменты для Mac OS


Audit утилита для вывода аудита и журналов OS X.

Disk Arbitrator блокирует монтирование файловых систем, дополняя блокиратор записи при отключении арбитража диска.

FTK Imager CLI for Mac OS консольная версия для Mac OS утилиты FTK Imager.

IORegInfo утилита для отображении информации по подключенным к компьютеру устройствам (SATA, USB и FireWire, программные RAID-массивы). Может определять информацию раздела, включая размеры, типы и шину, к которой подключено устройство.

mac_apt утилита для работы с образами E01, DD, DMG.

Volafox утилита для анализа памяти в Mac OS X.

Мобильные устройства

iPBA2 утилита анализа резервных копий iOS.

iPhone Analyzer утилита анализа файловой структуры Pad, iPod и iPhone.

ivMeta утилита для извлечения модели телефона и версии программного обеспечения, а также временные данные и данные GPS с видео iPhone.

Rubus утилита для деконструирования резервных файлов Blackberry .ipd.

SAFT извлечение SMS, журналов звонков и контактов из Android устройств.



Предыдущие статьи данного цикла:
Компьютерная криминалистика (форензика) — обзор инструментария и тренировочных площадок.
Компьютерная криминалистика (форензика): подборка полезных ссылок.

Дата: 2018-01-18 10:37:10

Источник: https://habrahabr.ru/post/346910/



Экспертам удалось заработать больше $100 тыс. за взлом Google Pixel

Исследователи разработали цепочку эксплоитов для удаленного выполнения произвольного кода на Pixel и других Android-устройствах.

На прошлогоднем конкурсе Pwn2Own Google Pixel оказался единственным смартфоном, который не удалось взломать участникам. Однако специалисты команды Qihoo 360 смогли выявить ряд уязвимостей, совместная эксплуатация которых позволяет удаленно выполнить код на Pixel и других Android-устройствах.

Разработанный исследователями эксплоит основан на двух уязвимостях: CVE-2017-5116 и CVE-2017-14904. Первая представляет собой уязвимость несоответствия используемых типов данных (type confusion) в движке JavaScript с открытым исходным кодом V8, ее можно использовать для удаленного выполнения кода в изолированном обработчике Chrome. Google исправила эту уязвимость в сентябре прошлого кода с выпуском Chrome 61.

Вторая проблема затрагивает модуль libgralloc в Android и может быть проэксплуатирована для выхода из окружения «песочницы». Данная уязвимость была устранена в декабре 2017 года. Совместное использование двух вышеописанных уязвимостей позволяет атакующему внедрить произвольный код в процесс system_server. Для этого злоумышленнику потребуется заставить жертву посетить вредоносный сайт.

За цепочку эсплоитов команда заработала $105 тыс. в рамках программы Android Security Rewards (ASR) и еще $7,5 тыс. по программе вознаграждения за найденные уязвимости в Chrome. Подробности эксплуатации уязвимостей представлены в блоге исследователей.

 

 

 

Дата: 2018-01-18 10:16:44

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



OAuth аутентификация в приложении Flask

Эта статья является бонусом к новому циклу статей Flask Mega-Tutorial (2018).
Автор тот же Мигель Гринберг. Статья не новая, но не утратила своей актуальности.

blog.miguelgrinberg.com

Технологии OAuth уже больше 10 лет, и 99% процентов интернет-аудитории имеет аккаунт минимум на одном из ресурсов, поддерживающих OAuth. Кнопка «Войти через» есть почти на каждом ресурсе? Разберемся как это делается с применением микрофреймворка Flask.


krs9vfybluzgbsolq4vy091xgf0.png

Многие веб-сайты предоставляют пользователям возможность упрощенной регистрации в "один клик", используя стороннюю службу аутентификации, с использованием учетной записи пользователя, в каком либо из известных социальных сервисов. В моем старом курсе Flask Mega-Tutorial я показал вам, как использовать один из этих протоколов, называемый OpenID, ( который ныне почил с миром прим. переводчика).


yfrp028vv-mcsmzwftlqz0cvjje.png

В этой статье я хочу дать вам введение в протокол OAuth, который в наши дни заменил OpenID как предпочтительный сторонний механизм аутентификации. Я также покажу вам полное приложение Flask, которое реализует функции Sign In with Facebook и Sign In with Twitter. С этими двумя реализациями в качестве примера вам будет легко добавить любые другие провайдеры OAuth, которые могут вам понадобиться.

Прим. переводчика: Еще пара ссылок о том как устроен OAuth здесь, здесь

Краткое введение в OAuth

Лучший способ представить OAuth — перечислить список событий, которые происходят во время входа:


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

В настоящее время используются две версии протокола OAuth, как в соответствии с описанным выше общим процессом, так и с некоторыми различиями в реализации. OAuth 1.0a, используемый Twitter, является самым сложным из двух. OAuth 2, используемый Facebook, представляет собой несовместимую пересмотренную версию протокола, которая устраняет большую часть сложности версии 1.0a, полагаясь на защищенный HTTP для шифрования.


Регистрация у провайдеров OAuth

Прежде чем приложение сможет использовать стороннего поставщика OAuth, его необходимо зарегистрировать. Для Facebook и Twitter это делается на своих соответствующих сайтах разработчиков с созданием "app", которое представляет приложение для пользователей этих сайтов.

Создать приложение для Facebook вы можете здесь https://developer.facebook.com.

Жмем "НАЧАТЬ" и NEXT. По ходу заполняем различную информацию о себе.


vdkkrytlp3lu11zodu7buxs9y3q.png

q5oredyovzvbdl5ogjotzavjxy0.png

Выбираем "Вход через Facebook"

6zkutgt_jszixhm6cu33s91jki8.png

Из списка возможных приложнеий выберите тип "WWW/Website".

w6-k8nnqtpdqte-xs9jp835e8fu.png

Укажите URL-адрес приложения, который в случае его запуска на вашем компьютере будет http://localhost:5000.

el5iainvbxe1bs6-fhqqer4u_gm.png

Пример аутентификации OAuth

В следующих разделах я собираюсь описать относительно простое приложение Flask, которое реализует аутентификацию Facebook и Twitter.

Я покажу вам важные части приложения в статье, но полное приложение доступно в этом репозитории GitHub: https://github.com/miguelgrinberg/flask-oauth-example. В конце этой статьи я покажу вам инструкции по ее запуску.


User Model

Пользователи в примере приложения хранятся в базе данных SQLAlchemy. Приложение использует расширение Flask-SQLAlchemy для работы с базой данных и расширение Flask-Login для отслеживания зарегистрированных пользователей.

from flask.ext.sqlalchemy import SQLAlchemy
from flask.ext.login import LoginManager, UserMixin

db = SQLAlchemy(app)
lm = LoginManager(app)

class User(UserMixin, db.Model):
    __tablename__ = 'users'
    id = db.Column(db.Integer, primary_key=True)
    social_id = db.Column(db.String(64), nullable=False, unique=True)
    nickname = db.Column(db.String(64), nullable=False)
    email = db.Column(db.String(64), nullable=True)

@lm.user_loader
def load_user(id):
    return User.query.get(int(id))

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


Класс User наследуется от UserMixin из Flask-Login, который дает ему методы, требуемые этим расширением. Функция обратного вызова user_loader, также требуемая Flask-Login, загружает пользователя по его первичному ключу.


Реализация OAuth

Для Python существует несколько клиентских пакетов OAuth. В этом примере я решил использовать Rauth. Однако, даже при использовании пакета OAuth существует множество аспектов проверки подлинности провайдерами, что затрудняет задачу.

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

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

class OAuthSignIn(object):
    providers = None

    def __init__(self, provider_name):
        self.provider_name = provider_name
        credentials = current_app.config['OAUTH_CREDENTIALS'][provider_name]
        self.consumer_id = credentials['id']
        self.consumer_secret = credentials['secret']

    def authorize(self):
        pass

    def callback(self):
        pass

    def get_callback_url(self):
        return url_for('oauth_callback', provider=self.provider_name,
                       _external=True)

    @classmethod
    def get_provider(self, provider_name):
        if self.providers is None:
            self.providers = {}
            for provider_class in self.__subclasses__():
                provider = provider_class()
                self.providers[provider.provider_name] = provider
        return self.providers[provider_name]

class FacebookSignIn(OAuthSignIn):
    pass

class TwitterSignIn(OAuthSignIn):
pass

Базовый класс OAuthSignIn определяет структуру, которой должны следовать подклассы, реализующие услуги каждого провайдера. Конструктор инициализирует имя провайдера, а также идентификатор приложения и секретный код, назначенные им, и полученные из конфигурации. Ниже приведен пример конфигурации приложения (конечно, вам нужно будет заменить эти коды своим собственным):

app.config['OAUTH_CREDENTIALS'] = {
    'facebook': {
        'id': '470154729788964',
        'secret': '010cc08bd4f51e34f3f3e684fbdea8a7'
    },
    'twitter': {
        'id': '3RzWQclolxWZIMq5LJqzRZPTl',
        'secret': 'm9TEd58DSEtRrZHpz2EjrV9AhsBRxKMo8m3kuIZj3zLwzwIimt'
    }
}

На верхнем уровне есть два важных события, поддерживаемых этим классом, которые являются общими для всех провайдеров OAuth:


Метод get_provider() используется для поиска правильного экземпляра OAuthSignIn с именем поставщика. Этот метод использует интроспекцию для поиска всех подклассов OAuthSignIn, а затем сохраняет экземпляр каждого в словаре.


Аутентификация OAuth с помощью Rauth

Rauth представляет провайдеры OAuth с объектом класса OAuth1Service или OAuth2Service, в зависимости от версии используемого протокола. Я создаю объект этого класса в подклассе OAuthSignIn каждого провайдера. Реализации для Facebook и Twitter показаны ниже:

class FacebookSignIn(OAuthSignIn):
    def __init__(self):
        super(FacebookSignIn, self).__init__('facebook')
        self.service = OAuth2Service(
            name='facebook',
            client_id=self.consumer_id,
            client_secret=self.consumer_secret,
            authorize_url='https://graph.facebook.com/oauth/authorize',           
            access_token_url='https://graph.facebook.com/oauth/access_token',
            base_url='https://graph.facebook.com/'
        )

class TwitterSignIn(OAuthSignIn):
    def __init__(self):
        super(TwitterSignIn, self).__init__('twitter')
        self.service = OAuth1Service(
            name='twitter',
            consumer_key=self.consumer_id,
            consumer_secret=self.consumer_secret,
            request_token_url='https://api.twitter.com/oauth/request_token',
            authorize_url='https://api.twitter.com/oauth/authorize',
            access_token_url='https://api.twitter.com/oauth/access_token',
            base_url='https://api.twitter.com/1.1/'
        )

Для Facebook, который реализует OAuth 2, используется класс OAuth2Service. Объект службы инициализируется именем службы и несколькими аргументами, специфичными для OAuth. Аргументами client_id и client_secret являются те, которые назначены приложению на сайте разработчика Facebook. Authorize_url и access_token_url — это URL-адреса, определенные Facebook для приложений, к которым необходимо подключиться во время процесса аутентификации. Наконец, base_url задает URL-адрес префикса для любых вызовов API Facebook после завершения проверки подлинности.

Twitter реализует OAuth 1.0a, поэтому используется класс OAuth1Service. В OAuth 1.0a идентификационные и секретные коды называются consumer_key и consumer_secret, но в остальном идентичны по функциональности аналогам OAuth 2. Протокол OAuth 1 требует, чтобы провайдеры отображали три URL вместо двух, есть дополнительный запрос request_token_url. Аргументы name и base_url идентичны аргументам, используемым в службах OAuth 2. Следует отметить, что Twitter предлагает два параметра для параметра authorize_url. URL, показанный выше, https://api.twitter.com/oauth/authorize, является самым безопасным, так как он представит пользователю окно, в котором нужно будет разрешить приложению получать доступ к Twitter каждый раз. Изменение этого URL-адреса на https://api.twitter.com/oauth/authenticate заставит Twitter запрашивать разрешение только в первый раз, а затем тихо разрешит доступ до тех пор, пока пользователь не выйдет из Twitter.

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


Фаза авторизации OAuth

Когда пользователь нажимает ссылку «Вход в систему с ...» для инициирования аутентификации OAuth, вызов следует по такому маршруту:

@app.route('/authorize/<provider>')
def oauth_authorize(provider):
    if not current_user.is_anonymous():
        return redirect(url_for('index'))
    oauth = OAuthSignIn.get_provider(provider)
    return oauth.authorize()

Этот маршрут сначала гарантирует, что пользователь не вошел в систему, а затем просто получает подкласс OAuthSignIn, соответствующий данному поставщику, и вызывает его метод authorize(), чтобы инициировать процесс. Ниже показана реализация authorize() для Facebook и Twitter:

class FacebookSignIn(OAuthSignIn):
    # ...
    def authorize(self):
        return redirect(self.service.get_authorize_url(
            scope='email',
            response_type='code',
            redirect_uri=self.get_callback_url())
        )

class TwitterSignIn(OAuthSignIn):
    # ...
    def authorize(self):
        request_token = self.service.get_request_token(
            params={'oauth_callback': self.get_callback_url()}
        )
        session['request_token'] = request_token
        return redirect(self.service.get_authorize_url(request_token[0]))

Для провайдеров OAuth 2, таких как Facebook, реализация просто выдает перенаправление на URL-адрес, созданный объектом службы rauth. Область действия зависит от Поставщика, в этом конкретном случае я прошу, чтобы Facebook предоставил электронную почту пользователя. В response_type='code' аргумент говорит oauth-провайдеру, что приложение представляет собой веб-приложение (есть и другие возможные значения для различных процессов аутентификации). Наконец, аргумент redirect_uri назначает маршрут приложения, который должен вызвать поставщик после завершения проверки подлинности.

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


Фаза обратного вызова Callback OAuth

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

@app.route('/callback/<provider>')
def oauth_callback(provider):
    if not current_user.is_anonymous():
        return redirect(url_for('index'))
    oauth = OAuthSignIn.get_provider(provider)
    social_id, username, email = oauth.callback()
    if social_id is None:
        flash('Authentication failed.')
        return redirect(url_for('index'))
    user = User.query.filter_by(social_id=social_id).first()
    if not user:
        user = User(social_id=social_id, nickname=username, email=email)
        db.session.add(user)
        db.session.commit()
    login_user(user, True)
    return redirect(url_for('index'))

Этот маршрут создает экземпляр класса поставщика OAuthSignIn и вызывает его метод callback(). Этот метод имеет функцию завершения аутентификации с провайдером и получения информации о пользователе. Возвращаемое значение представляет собой кортеж с тремя значениями, уникальный идентификатор (называемый social_id, чтобы отличать его от первичного ключа id), псевдоним пользователя и адрес электронной почты пользователя. Идентификатор и псевдоним являются обязательными, но в этом примере приложения я сделал электронное письмо необязательным, так как Twitter никогда не делится этой информацией с приложениями.

Пользователь просматривается в базе данных по полю social_id, и если не найден, новый пользователь добавляется в базу данных с информацией, полученной от провайдера, эффективно регистрируя новых пользователей автоматически. Затем пользователь регистрируется с помощью функции login_user() в Flask-Login и, наконец, перенаправляется на домашнюю страницу.

Реализация метода callback() для провайдеров OAuth для Facebook и Twitter показана ниже:

class FacebookSignIn(OAuthSignIn):
    # ...
    def callback(self):
        def decode_json(payload):
            return json.loads(payload.decode('utf-8'))

        if 'code' not in request.args:
            return None, None, None
        oauth_session = self.service.get_auth_session(
            data={'code': request.args['code'],
                  'grant_type': 'authorization_code',
                  'redirect_uri': self.get_callback_url()},
            decoder=decode_json
        )
        me = oauth_session.get('me').json()
        return (
            'facebook$' + me['id'],
            me.get('email').split('@')[0],  # Facebook does not provide
                                            # username, so the email's user
                                            # is used instead
            me.get('email')
        )

class TwitterSignIn(OAuthSignIn):
    # ...
    def callback(self):
        request_token = session.pop('request_token')
        if 'oauth_verifier' not in request.args:
            return None, None, None
        oauth_session = self.service.get_auth_session(
            request_token[0],
            request_token[1],
            data={'oauth_verifier': request.args['oauth_verifier']}
        )
        me = oauth_session.get('account/verify_credentials.json').json()
        social_id = 'twitter$' + str(me.get('id'))
        username = me.get('screen_name')
        return social_id, username, None   # Twitter does not provide email

В методе callback() передается токен проверки, который приложение может использовать для связи с API-интерфейсом провайдера. В случае OAuth 2 это происходит как аргумент code, тогда как для OAuth 1.0a это oauth_verifier, оба заданные в строке запроса.
Этот код используется для получения oauth_session из объекта службы rauth.

Обратите внимание, что в последних версиях API Facebook токен сеанса возвращается в формате JSON. Формат по умолчанию, ожидаемый rauth для этого токена, должен указываться в строке запроса. По этой причине, необходимо добавить аргумент decoder, который декодирует содержимое JSON. В Python 2 достаточно передать json.loads, но в Python 3 нам нужен дополнительный шаг, потому что полезная нагрузка возвращается как байты, которые json-парсер не понимает. Преобразование из байтов в строку выполняется во внутренней функции decode_json.

Объект oauth_session может использоваться для предоставления API-запросов поставщику. Здесь он используется для запроса информации о пользователе, которая должна предоставляться определенным провайдером. Facebook предоставляет идентификатор пользователя и адрес электронной почты, но не дает имен пользователей, поэтому имя пользователя для приложения создается из левой части адреса электронной почты. Twitter предоставляет идентификатор и имя пользователя, но не поддерживает электронную почту, поэтому электронное письмо возвращается как None.

Данные, полученные от провайдера, окончательно возвращаются в виде трехэлементного кортежа для функции просмотра. Обратите внимание, что в обоих случаях значение id от провайдера добавляется с «facebook $» или «twitter $» до его возврата, чтобы сделать его уникальным для всех поставщиков. Поскольку это то, что приложение будет хранить как social_id в базе данных, необходимо сделать это, чтобы два поставщика, которые назначили один и тот же id двум различным пользователям, не конфликтовали в базе данных приложения.


Вывод

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

Клонировать или загрузить репозиторий проекта: https://github.com/miguelgrinberg/flask-oauth-example
Создать виртуальную среду и установите пакеты по списку в файле requirements.txt (вы можете использовать Python 2.7 или 3.4).
Зарегистрируйте «приложение» с помощью Facebook и Twitter,
как описано выше.
Отредактируйте app.py с идентификатором и секретными кодами ваших приложений Facebook и Twitter.
После выполнения этих инструкций вы можете запустить приложение с помощью python app.py, а затем запустить http://localhost: 5000 в своем браузере.

Надеюсь, что эта статья полезна в демистификации OAuth.
Если у вас есть вопросы, напишите их ниже.

Miguel

Дата: 2018-01-18 10:07:00

Источник: https://habrahabr.ru/post/346918/



Патчи для Spectre/Meltdown вызывают сбои в работе не только старых, но и более новых процессоров

Компании пока не удалось установить причину проблемы.

На минувшей неделе компания Intel сообщила , что патчи, исправляющие уязвимости Spectre и Meltdown, могут вызывать сбой в работе компьютеров на базе устаревших процессоров Broadwell и Haswell. Однако проблема оказалась несколько шире.

Как выяснилось в ходе внутреннего тестирования Intel, ошибка, вызывающая неожиданную перезагрузку после установки патча, затрагивает ряд конфигураций чипов Skylake, Kaby Lake, Ivy Bridge и Sandy Bridge. Пока производителю не удалось установить причину ошибки, но по словам вице-президента Intel Навина Шеноя (Navin Shenoy), компания существенно продвинулась в этом направлении. Он добавил, что на следующей неделе Intel представит на ознакомление вендоров бета-версию микрокода.

Компания также обнародовала некоторые данные о влиянии патчей для Spectre/Meltdown на производительность серверов, в частности, на базе нового процессора Intel Xeon Scalable. Результаты тестирования представлены в таблице ниже 

rytreuiyieury.png

Дата: 2018-01-18 09:49:19

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