Русский
Русский
English
Статистика
Реклама

Информационная безопасность

Россия в десятке стран по количеству валидных SSL

01.07.2020 14:11:33 | Автор: admin
Cтарейший удостоверяющий центр, ведущий поставщик надежных решений идентификации и безопасности GlobalSign и крупнейший в России хостинг-провайдер и регистратор доменов REG.RU представили данные о лидирующих странах-пользователях SSL-сертификатов, о том, как менялся мировой рынок в момент пандемии коронавируса и о других трендах отрасли.

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

Безусловно, распространение вируса COVID-19 оказало влияние на экономику практически всех стран и отраслей. Из-за ситуации с пандемией с начала 2020 года в сравнении с тем же периодом прошлого года наблюдается небольшое отставание в росте SSL-сертификатов, которое коснулось большинства стран.

Для примера, в России в феврале этого года количество SSL-сертификатов составило 1 476 822, в марте оно упало до 1 297 920, но уже в апреле начался небольшой рост, и общее количество выросло до 1 325 999 сертификатов, что говорит если не о полном восстановлении, то по крайней мере о тенденции возвращения к нормальному функционированию.

Несмотря на сложность прогнозирования в текущей ситуации, последние 4 года продолжает прослеживаться значительная динамика роста SSL-сертификатов по всем странам.


Количество SSL-сертификатов по странам (по данным компании Netcraft). Данные приведены без учёта самоподписанных сертификатов.

Первенство по количеству сайтов продолжает удерживать США. К списку традиционных лидеров крупнейших стран Западной Европы в этом году присоединилась Япония, занявшая 3-е место. Также в этом году в топ-10 стран вошёл Китай, замыкая список лидеров. Россия продолжает занимать 9-ю строчку рейтинга, оставив позади Италию, Австрию, Швейцарию и Испанию.

Особенности российского рынка SSL-сертификатов

По данным аналитического ресурса StatOnline.ru, в апреле 2020 года в зоне .RU были активны 1 440 000 SSL-сертификатов, а в.РФ 150 000. Количество валидных SSL (т. е. выданных удостоверяющими центрами) значительно превосходит количество невалидных 1 470 000 тысяч сертификатов в сумме, выпущенных на домены в зонах .RU и.РФ. Число невалидных и самоподписанных составляет 125 000.

В топ-5 удостоверяющих центров по количеству выпущенных SSL в .RU сегодня входят: Let's Encrypt (960 000), CloudFlare Inc (110 000), DigiCert Inc (85 000), GlobalSign (75 000) и Sectigo Limited (55 000). Значительный перевес Let's Encrypt обусловлен возможностью получать в этом УЦ бесплатные SSL-сертификаты сроком до 90 дней.

В .RU больше всего сертификатов со сроком действия менее года (81%) и 1 год (18%). Наиболее популярен формат использования одного SSL-сертификата для одного домена, их число превышает 1 миллион. Но мультидоменные сертификаты (SAN) тоже востребованы. Так, в сумме количество тех, которые приходятся на 3-10 доменов, составляет около 80 тысяч.

Цифровая безопасность становится всё более актуальной в современном мире, как для обычного пользователя, так и для любой компании. Несмотря на ограничения в условиях пандемии во всём мире, мы отмечаем растущую важность онлайн-коммуникаций и, как следствие, повышенный интерес к защите информации и в частности SSL-сертификатам среди российских компаний, отмечает генеральный директор GMO GlobalSign Russia Дмитрий Рыжиков.

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

Вместе с нашим партнёром, старейшим удостоверяющим центром GlobalSign, мы и дальше будем предоставлять сертификаты всем желающим на российском рынке, в том числе SSL-сертификат на один год в комплекте с доменом и хостингом, комментирует Алексей Королюк, генеральный директор хостинг-провайдера и регистратора доменов REG.RU.
Подробнее..

Почему у Wechat нет и не может быть конкурентов

01.07.2020 16:06:10 | Автор: admin
Возможно, меня можно обвинить в предвзятости и безмерном обожании Wechat. Обоснованно ли пусть судят другие. В любом случае, Wechat это уникальное явление среди всех IT-проектов всего времени. И тут я попытаюсь раскрыть вопрос What makes it special

В статье в равной мере будут упоминаться Wechat(продукт корпорации Tencent) и Alipay(продукт корпорации Alibaba). Пусть это не вводит вас в заблуждение. Это два кита, это два краеугольных камня китайского интернете и китайского общества, и если что-то появилось у одного это появится и у другого в самом скором времени.
Alipay принадлежит 53.8% рынка платежей, а Wechat 39.9%.
Вы скажете а как же карты. Ну, предлагаю вам найти на сайте одного из крупнейших экваеров Китая Meituan хоть одно решение кассы, где можно использовать карту. Все, абсолютно все заточено под Alipay и Wechat.
В этом плане, кстати, мудрые китайцы всецело понимают важность конкуренции. Авиакомпаний с государственным капиталом было создано 3. Сотовых операторов 3. Банков 4. Китайцы прекрасно знают, чем чревата государственная(или иная) монополия и стремятся их разделить. Когда China Southern начала слишком уж выделяться из конкурентов ей было предложено в добровольно-принудительном порядке выделить часть капитала на создание дочки Xiamen Airlines. Точно так же из China Eastern выделили Shanghai Airlines. Air China Shenzhen Airlines.
Точно так же дело обстоит и в онлайн-платежах. Пускай Alipay и Wechat( которым государство одинаково способствует) вечно догоняют друг друга. Всем от этого только благо.
Но вернемся к теме. И рассмотрим ее на практическом примере.
Недавно я ездил в командировку. И так как из-за пандемии встречается довольно много параноиков, которые хотят подтверждения, что я не болен коронавирусом я решил взять справку о том, что я им не болен. Что я для этого сделал? Ну, сходил в ближайшую больницу, сдал мазок. А дальше?
Зафолловил аккаунт больницы в вичате, нажал на результаты анализов
image
Ввел телефон, ФИО, номер ID, получил СМС
image
И нажал на скачать справку
image
Не заметили здесь секурности? А она есть(с)
В предыдущей статье я писал, что одним из методов аутентификации пользователя является его мобильный телефон. Сим-карту в Китае возможно заиметь только после предоставления биометрии лица. И после ввода эти данных можно отправить запрос соответствует ли ФИО и ID. Если ФИО пациента соответствует с ФИО, на которые был зарегистрирован номер, на который отправили СМС с кодом это 99%, что результаты анализов хочет получить сам пациент.
Wechat и Alipay доверяют. Доверяют все без исключения. Прекрасным примером служит их рейтинг.
У Wechat это Wechat Pay Points, у Alipay Sesame Credit. Высчитывается он тайными алгоритмами, которые никому не известны, но их результат и его влияние на себя может испытать каждый
1) он выше 350 можешь им нормально пользоваться
2) он выше 550 можешь без залога брать в аренду павербанки, зонтики, велосипеды
3) он выше 600 можешь получать chargeback мгновенно. Вот буквально не понравились тебе купленные на Таобао туфли и ты жмешь возврат. Деньги мгновенно возвращаются, а у тебя есть уведомление отправьте нам товар обратно на протяжении 15 дней
4) выше 700 брать авто в аренду без залога. Буквально оставил заявку на авто в аэропорту и тебе скинули его геолокацию. Пришел, отсканил QR-код и поехал
5) выше 900 это основание подать в банк заявку на снижение процента по ипотеке. Взял ты ее под стандартные 3,8%, отправил справку из Wechat о своем >900 рейтинге тебе ее снизили до 2,5%. Одна моя знакомая(в рамках программы поддержки социально значимых профессий она учитель, снизила ее себе до 0,1% годовых. Но справку из Wechat/Alipay тоже потребовали
6) 1000(максимально теоретически возможный) не знаю, что там разблокируется за функционал.
Опять же, реальный пример аренда жилья. Когда я регистрировался в Ziroom, они какой-то внутренней магией посчитали, что мой рейтинг такой-то.
Как я снял квартиру? Выбрал в приложении понравившиеся и нажал посмотреть. После этого мне выдало время и 15-минутный код от замка. Я посмотрел, выбрал, год пожил. Потом переезжал в Шеньчжень и возвращал ее. Я нажал в приложении вернуть квартиру
image
И уехал. Уже в поезде меня догнало сообщение подтверждаете ли вы баланс счетчиков
image
Я нажал да и ехал дальше. Наутро я получил полный расчет и 400 юаней переплаты вернулись на счет.
image
При этом не путайте Ziroom с шарагами вроде AirBNB. На основании контракта с Ziroom я без лишних движений оформил себе налоговый вычет на аренду жилья(скрин из приложения налоговой). Для этого мне понадобился только номер контракта и мое ФИО/ID
image
Я вообще к чему Подобный уровень доверия сервиса к пользователю, немыслимый, невозможный уровень доверия возможен только тут.
И именно на основе Wechat/Alipay
Именно поэтому все конкуренты жалкое подобие.
Можно как угодно говорить, но Alipay и Wechat доверяю и я. Да, они параноидальны, да, они могут заблочить аккаунт до подтверждения чего-то там, да, они нещадно отслеживают ненормальные транзакции и блокируют всяких менял, да, они могут отрапортовать в банк и ваш счет закроют(на эту тему чаще всего слышен вой со стороны нелегальных менял и обнальщиков). Но если вы спросите меня я верю им на 100%.
Вы можете спросить любого китайца доверяет ли он им. Вы услышите много жалоб на тему привязал карту и потребовали подтвердить, настучали в банк на тему большого перевода без обоснования, потребовали скинуть распечатку транзакций из банка. Но оборвав их и спросив веришь? каждый ответит да.
И именно на стыке доверия к Alipay/Wechat со стороны государства, населения, банков и сервисов и рождается нечто подобного масштаба.
Говорите, что хотите, но именно Wechat первое, чего мне не хватает за границей.
Спасибо за внимание
Подробнее..

Карантинные хроники как рос DDoS

02.07.2020 10:04:35 | Автор: admin
Как известно, лень двигатель прогресса. А самоизоляция двигатель DDoS'а, добавим мы по итогу осмысления былого за март-май 2020 г. Пока кто-то страдал от безвыходности (в буквальном смысле) своего положения, мамкины хакеры страдали фигней от неотвратимости онлайн-обучения и грядущих экзаменов. Деятельно страдали (эту бы энергию да в мирное русло!). По количеству DDoS-атак в сфере образования наблюдалась наибольшая динамика роста. На пике в апреле число попыток устроить отказ в обслуживании образовательным ресурсам (электронным дневникам, сайтам с проверочными работами, площадкам для онлайн-уроков и т.д.) увеличилось в 5,5 раз по отношению к марту и в 17 раз по отношению к январю 2020 г. Всё это были маломощные (и наверняка бесплатные) атаки с использованием простых легкодоступных инструментов. Разумеется, под прицел злоумышленников (правда, уже более продвинутых) попали и другие отрасли, но тут было ожидаемо: онлайн-торговля, госсектор финансовая сфера, телеком и игровой сегмент. Подробности, как всегда, под катом.



Аналитика, которую мы приводим ниже, составлена на основе данных об атаках на сетях Ростелекома с января по май 2020 года.

Как менялось количество атак


Итак. В марте-мае 2020 года количество DDoS-атак увеличилось в 5 раз в сравнении с аналогичным периодом прошлого года. В целом за первые пять месяцев 2020-го общее число подобных атак год к году выросло более чем в 4 раза.

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



В период самоизоляции изменился и характер интернет-трафика. Многие организации, работавшие раньше только в офлайн, запустили собственные интернет-ресурсы, в том числе халявные. Добавим сюда массовую удаленку и получим новую реальность в сети: если раньше интернет-активность плавно нарастала, достигая пика к 17:00-21:00, то теперь резкий рост был отмечен примерно в 10:00 и не снижался раньше 23:00. В целом трафик за пять месяцев 2020 года вырос примерно на 20% (а где трафик там и диверсанты).

Характеристики атак


При резком росте количества DDoS-атак их сложность и мощность в целом снизились. В основном злоумышленники использовали обычную DNS- или NTP-амплификацию небольших объемов (до 3 Гб/с).

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

На кого охотились


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



Но не школой единой был жив DDoS. Увеличилось количество атак и на госучреждения в апреле более чем в 3 раза в сравнении с мартом.



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



Несмотря на то, что в целом за отчетный период мощность атак упала, в общей статистике выделились операторы связи и дата-центры: здесь чаще обычного случались атаки 150+ Гб. DDoS в этих двух сегментах позволяет вывести из строя не один конкретный сайт, а ударить оптом по клиентам оператора и ресурсам, которые обслуживает ЦОД. При этом такие компании лучше защищены, чем, например, госучреждения или образовательный сегмент. Поэтому злоумышленникам приходится применять более совершенные инструменты. В период пандемии атаки на эти два сегмента были быстрыми и мощными и осуществлялись, скорее всего, через реальные хосты, собранные в одну бот-сеть с возможностью за считанные минуты перенаправить ее на новую жертву.

В целом такое разделение по отраслям продолжает тренд, который сформировался еще в 2019 году. Например, в 2018 году на телеком-индустрию приходилось только 10% всех DDoS-атак, а в 2019 уже 31%. Мишенями хакеров становились небольшие региональные интернет-провайдеры, хостинги и дата-центры, которые обычно не располагают необходимыми для отражения атак ресурсами.

Итого


В период действия карантина на фоне распространения COVID-19 (март-май 2020 года) было зафиксировано в пять раз больше DDoS-атак, чем годом ранее.

Доля простых и маломощных атак увеличилась, что указывает на активность непрофессиональных злоумышленников.

В 5,5 раз выросло количество атак на образовательные ресурсы, а самые мощные атаки за отчетный период пришлись на операторов связи и дата-центры.



Наибольший объем атак в марте-мае пришелся на сектор онлайн-торговли (31%), который традиционно является одним из основных объектов для DDoS. Вторым по популярности стал госсектор (21% атак). Далее следуют финансовая сфера (17%), телеком (15%), образование (9%) и игровой сегмент (7%).

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

Однако, как показал минувший карантин, невозможно спрогнозировать наверняка, когда именно в компанию придет DDoS, так что соломку лучше подстелить заранее.
Подробнее..

7 в одни руки столько заплатит Equifax за слив ПД

02.07.2020 14:05:51 | Автор: admin
Даже несколько лет спустя, ситуация вокруг утечки данных американского кредитного бюро не разрешилась. Обсудим то, как она развивается, и другие крупные утечки, произошедшие за это время.


Фото Hermes Rivera Unsplash

Краткий обзор ситуации


В 2017 кредитное бюро Equifax сообщило о масштабной кибератаке, в результате которой похитили персональные данные почти 150 млн американцев. Тогда издание Ars Technica назвало сложившуюся ситуацию худшей утечкой всех времен, поскольку она затронула номера социального страхования, кредитных карт и водительских удостоверений. Причиной стала уязвимость в открытом фреймворке Apache Struts (CVE-2017-5638), связанная с ошибкой в обработке исключений при загрузке файлов. Специалисты Equifax не успели установить заплатку, выпущенную за два месяца до кибератаки.

Расследованием занялись сразу несколько регуляторов: Федеральная торговая комиссия США (FTC), Бюро финансовой защиты потребителей и прокуроры большинства штатов. В итоге кредитное бюро согласилось заплатить компенсацию в размере $700 млн эта сумма включает штрафы и выплаты для граждан США, чьи данные утекли в сеть. Однако размер этих выплат вызвал вопросы.

Почему выплаты такие маленькие


Ситуация с Equifax получила широкое освещение в СМИ, а бюро подверглось критике сообщества. Несмотря на этот факт граждане США не спешат получить свою компенсацию на текущий момент заявления подали около 10% пострадавших. Им предложили два варианта выплат: компенсация расходов на кредитный мониторинг в размере $125 или деньги наличными.

И тут организация столкнулась со сложностями. В Equifax не ожидали, что большинство пойдёт по второму пути. Денежный фонд, отведенный под прямые выплаты, составил всего $31 млн. В итоге сумма, которую человек может получить на руки, уменьшилась до $6,8.

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


Фото Barthelemy de Mazenod Unsplash

В начале года американский суд закончил рассмотрение еще одного дела, связанного с утечкой в кредитном бюро. Equifax дополнительно выплатит до $20 тыс. всем клиентам, которые понесли финансовые потери из-за слива персональных данных. Суд также обязал бюро направить $1 млрд на развитие ИТ-инфраструктуры и повышение защиты ПД. Хотя в организации отмечают, что в период с 2018 по 2020 год уже выделили миллиард долларов на усиление информационной безопасности.

Кто еще платил и заплатит за утечки


За последние несколько лет утечка данных в Equifax стала одной из самых крупных, но не единственной. Например, в октябре 2019 года Yahoo согласилась потратить $117,5 млн на выплаты пользователям, пострадавшим из-за слива ПД в 2013 году. По предварительным оценкам, каждый из них получит примерно $358. Хотя эксперты ожидают, что на практике эта сумма будет значительно меньше (как и в случае с Equifax).

В ближайшее время крупную выплату придется совершить и Facebook. Осенью в интернет попали более 400 млн телефонных номеров пользователей социальной сети, поскольку их база хранилась на незащищенном сервере. Одним из первых этим вопросом заинтересовался ирландский регулятор, и согласно GDPR он может назначить штраф в размере $2,2 млрд. Но пока рано говорить, какая часть этой суммы пойдет непосредственно на выплаты пострадавшим пользователям.

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



Больше материалов в нашем корпоративном блоге:

Потенциальные атаки на HTTPS и как от них защититься
Как замести следы и удалить себя из большинства популярных сервисов
Как защитить виртуальный сервер в интернете
Бенчмарки для Linux-серверов



Подробнее..

Исключения хранения биометрических данных

02.07.2020 14:05:51 | Автор: admin
Перевод статьи QuantumCryptTM Enabling biometric technologies to eliminate biometric data storage

Биометрические технологии быстро развиваются


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

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

Основные положения


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

Модели True Biometric Hash, которые Infinity создала для 2D лица, отпечатков пальцев и радужной оболочки, позволяют использовать различные биометрические методы для удаления биометрических данных с использованием передовых технологий для извлечения только надежных и повторяемых характерных векторов из изображения биометрического сканирования. Мало того, что эти же самые характерные векторы извлекаются многократно и точно, но платформа также собирает только надежные биты, так что это не ставит под угрозу общую эффективную биометрическую энтропию для лучшей безопасности и производительности.

Проблемы конфиденциальности


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

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

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

Решение


Технология QuantumCrypt от Infinity генерирует такой же стабильный и повторяемый биометрический код для создания True Biometric Hash. Генерация стабильных биометрических кодов из различных условий окружающей среды и естественного шума датчиков во время биометрического сканирования гарантирует ограничение ошибок регистрации. В результате система работает с высокой производительностью и хорошим пользовательским опытом. В этих изменяющихся условиях True Biometric Hash работает лояльно по отношению к рискам появления разных людей с некоторыми сходствами и создания одинаковых стабильных кодов. Энтропия, генерируемая системой, учитывает это. Таким образом, использование только стабильных битов из биометрического сканирования автоматически создаст стабильный код, и для него не требуется сохраненный биометрический шаблон для аутентификации.

image

Истинный биометрический Хэш в криптографическом пространстве


Процесс регистрации

  • Биометрическое сканирование захватывает изображение
  • Технология QuantumCrypt идентифицирует, извлекает из изображения стабильные и воспроизводимые векторы
  • Генерируется открытый/закрытый код. Закрытый код хешируется
  • Симметричные или асимметричные криптографические ключи выдаются из сгенерированного биометрического хэш-кода
  • В случае асимметричных криптографических ключей открытый ключ сохраняется, закрытый ключ стирается из системы. Никаких биометрических данных не хранится ни в одном случае.

Верификация

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

image

1. Блок-схема с симметричными криптографическими ключами (для локальной защиты или проверки данных)

image

2. Блок-схема с асимметричными криптографическими ключами (для удаленной безопасной передачи данных проверки)

Как мы это делаем


Технология Infinity QuantumCrypt разработана для работы с различными существующими биометрическими алгоритмами, чтобы постоянно генерировать повторяемые биометрические коды. Алгоритм собирает и повторно измеряет биометрические сигналы на повторяемой основе.
Внедрение общедоступного кода это инновация, позволяющая собирать стабильные данные, не используя при этом биометрическую информацию или конфиденциальные данные. Публичный код отвечает на вопрос Где собирать данные?, но это не позволяет угадать какое-либо битовое значение частного кода. Для этого необходимо наличие биометрического сканирования, чтобы получить закрытый код.
Структура Public Code позволяет создавать отзывные коды. Изменяя выбор функций, на которые есть ссылки в открытом коде, мы можем создать другой частный код и, следовательно, другие криптографические ключи, сохраняя при этом тот же биометрический источник и не раскрывая никаких биометрических данных.

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

Вывод


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

Голосовой помощник для совершения операций на бирже

02.07.2020 18:23:23 | Автор: admin
Алиса, купи одну акцию Яндекс.
Заявка на покупку Яндекс по рыночной цене, тикер: YNDX, количество акций: 1, для подтверждения скажите подтверждаю, для отмены скажите нет.
Подтверждаю.
Заявка исполнена.


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


Как всё начиналось



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

Время шло, в каталоге навыков Алисы появлялись бесполезные банковские голосовые помощники (не в обиду разработчикам). У Сбербанка, например, помощник озвучивал условия кредита и предлагал прийти в отделение, у Тинькофф тоже самое, только вместо отделения предлагал перейти на сайт, чтобы заполнить заявку. Ребята, кто разрабатывал это, пожалуйста, не обижайтесь на меня, но, правда, я не хочу никуда идти, ни в отделение, ни на сайт, я хочу иметь возможность перевести 100 рублей другу фразой: Алиса, отправь 100 рублей Саше.

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

В какой-то момент, я просто встал с кровати и начал делать приватный навык для Алисы, чтобы голосом управлять своим брокерским счётом. Я перебрал своих брокеров и остановился на Тинькофф Инвестиции OpenAPI. Затем на месяц погрузился в изучение возможностей платформы Яндекс.Диалоги, и ещё через некоторое время купил первые ценные бумаги через голосовой помощник на Московской бирже один лот Банк ВТБ. Надеюсь, эта сделка войдёт в историю.

С самого начала я решил, что не буду прятать исходный код, чтобы любой желающий мог настроить себе голосовой помощник: https://github.com/denismosolov/oliver

Возьми с полки пирожок и расскажи наконец о проблемах



Компаний много, а я один



Когда я говорю Алисе: Купи одну акцию Яндекс, то платформа Яндекс.Диалоги извлекает название ценной бумаги из фразы и преобразовывает в специальный идентификатор FIGI (Financial Instrument Global Identifier), необходимый для взаимодействия с торговой платформой через OpenAPI. Вот так выглядит FIGI для акций компании Яндекс, торгующихся на Московской бирже: BBG006L8G4H1.

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

entity EFigi:    values:        BBG005DXJS36:            %exact            TCS            %lemma            тиньков(банк)?            тинькоф(банк)?            тинькофф(банк)?            ти си эс (груп)?


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

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

Компания торгуется на двух биржах в разной валюте



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

Например, когда я говорю: Продай одну акцию TCS Group, и у меня на счёте есть только акции в рублях, то нужно без уточнений продавать в рублях на Московской бирже. Если у меня на счёте акции TCS Group в рублях и долларах, то Алиса должна задать уточняющий вопрос: У вас глобальные депозитарные расписки TCS Group в рублях и в долларах, в какой валюте вы хотите продать?.

Я пока это не реализовал и TCS Group всегда покупается и продаётся за доллары. Но, надеюсь, скоро возьмусь за выставление заявок на покупку и продажу ценных бумаг по заданной цене (лимитные заявки), а там уже научу голосовой помощник разливать акции на разных биржах по валюте, которая будет в цене покупки или продажи.

Ошибки распознавания



Люди спрашивают, а что будет, если Алиса распознает что-то не так, например, купит не ту бумагу или не то количество? Для этого я предусмотрел подтверждение сделок. После того, как Алиса распознает команду на покупку или продажу, она проговаривает детали сделки и ожидает подтверждения. Если подтверждения не последует, то сделка не состоится.

Сообщение при подтверждении сделки звучит так: Заявка на <покупку | продажу> <$название_ценной_бумаги> по <$цена_за_одну_бумагу>, тикер: <$тикер>, количество акций: <$количество>, для подтверждения скажите подтверждаю, для отмены скажите нет.

Такое подтверждение отлично воспринимается на слух, но есть одна недоработка. Алиса плохо читает название тикера, например, YNCX, звучит как йинкс.

Я хотел написать функцию, которая бы разбирала тикеры по буквам, и для каждой буквы проигрывала звук из озвучки английского алфавита. Код принимал бы на вход строку YNDX, а возвращал вот такую строку в формате tts:
<speaker audio="sounds-y.opus"><speaker audio="sounds-n.opus"><speaker audio="sounds-d.opus"><speaker audio="sounds-x.opus">

Алиса будет проигрывать звуки, и в теории всё будет звучать хорошо.

Безопасность при совершении сделок



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

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

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

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

Вместо заключения


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

До встречи в будущем!
Подробнее..

Разбираем атаки на Kerberos с помощью Rubeus. Часть 2

02.07.2020 22:10:39 | Автор: admin


Всем привет!

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

Overpass The Hash/Pass The Key (PTK);
Pass The Ticket;
Unconstrained Delegation;
Constrained Delegation.

О том, почему возможны эти атаки, какие механизмы их реализации существуют, какой принцип лежит в основе работы Kerberos, написано уже много (например, коллеги из Инфосистемы Джет опубликовали хорошую статью с разбором), поэтому в своем материале я сделаю упор на реализацию атак с помощью Rubeus.

Помимо экшенов для проведения атак и взаимодействия с Kerberos, в Rubeus есть небольшая приятная мелочь: на основании пароля в открытом виде он может посчитать NTLM хэш, что иногда бывает очень удобно и полезно.



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

Overpass The Hash/Pass The Key (PTK)


Материал из Википедии свободной энциклопедии

Атака Pass-the-hash один из видов атаки повторного воспроизведения. Она позволяет атакующему авторизоваться на удалённом сервере, аутентификация на котором осуществляется с использованием протокола NTLM или LM.

Но что делать, если в сети отключена аутентификация по протоколам NTLM или LM и используется только аутентификация Kerberos, а у вас есть хэш пароля? Здесь в игру вступает Overpass-the-hash с помощью имеющегося хэша пароля пользователя Rubeus может запросить билет TGT для данной учетной записи.

Вот доменный пользователь Barsik решил изучить вопросы информационной безопасности, где-то раздобыл хэш пароля администратора домена ADadmin, скачал Rubeus, прочитал умных статей и пробует применить это на практике.



Видим, что кэшированных билетов у него нет, как и нет доступа к контроллеру домена DC-16.meow.local, но дальше Barsik запускает Rubeus с экшеном asktgt и аргументами /domain, /user, /rc4, /ptt, чтобы на основании имеющегося хэша пароля учетной записи ADadmin получить валидный TGT билет, аргумент /ptt сразу подгрузит полученный билет в текущую сессию пользователя Barsik.



Билет получен и загружен, Barsik пробует ещё раз авторизоваться на контроллере домена как Adadmin.



И на этот раз у него это успешно получается.

Pass The Ticket (PTT)


Данная атака похожа на Overpass-the-hash/Pass-the-key, атакующий старается получить билет доменного пользователя (желательно имеющего максимальные привилегии в домене) и загрузить его в текущую сессию. Один из способов получения TGT билетов дамп билетов локально на текущей доменной машине из процесса lsass.exe (Local Security Authentication Server). Чтобы это сделать, необходимо иметь привилегии локального администратора, а лучше NT AUTHORITY/SYSTEM. Rubeus может выгрузить билеты, хранящиеся в lsass, с помощью экшена dump, а экшн triage покажет, какие билеты хранятся в системе на данный момент.





Rubeus выгружает билеты из lsass в кодировке base64, при этом в самом инструменте есть заметка, как сохранить полученный base64 билет в формате .kirbi.



Сохраним и импортируем билет в текущую сессию пользователя.



Как видно из скриншота, тикет ADadmin успешно загружен и мы можем посмотреть содержимое диска C на контроллере домена DC-16.meow.local от имени ADadmin.

Unconstrained Delegation


Unconstrained Delegation (неограниченное делегирование) это привилегия в домене, которая может быть предоставлена учетным записям пользователей или компьютеров. Она позволяет учетной записи проходить проверку подлинности на сервисе в сети от имени другой учетной записи.

Вот теперь пришло время немного подкрутить тестовый стенд и включить неограниченное делегирование: дадим привилегию неограниченного делегирования компьютеру BARSCOMP.



Один из этапов проведения тестирования безопасности домена Active Directory поиск учетных записей с включенным делегированием, обычно для этих целей используют Powerview, но можно и вручную, используя стандартный модуль ActiveDirectory.



Для проведения данной атаки я воспользуюсь Printer Bug, который подробно описал Lee Christensen из SpecterOps. Любой прошедший проверку пользователь может удаленно подключиться к серверу печати контроллера домена и запросить обновление новых заданий на печать, сказав ему отправить уведомление учетной записи с неограниченным делегированием. Lee Christensen написал приложение SpoolSample, которое производит обращение к службе печати на КД по протоколу MS-RPRN.

На компьютере, с которого будет проводится атака (BARSCOMP.meow.local), необходимо запустить Rubeus в режиме мониторинга, используя экшн monitoring. Данный режим требует привилегий NT ATHORITY/SYSTEM и слушает новые билеты TGT/TGS в процессе lsass. Я установлю аргументом /interval:1 (в секундах) интервал опроса lsass на наличие новых билетов, и аргументом /filteruser:DC-16$ установлю фильтр отображения только билетов пользователя DC-16$.



Rubeus запущен, параллельно в другой сессии запускаю SpoolSample.exe с аргументами dc-16.meow.local (атакуемая машина) и barscomp.meow.local (наш слушающий хост).



Посмотрим, что намониторил Rubeus.



Пойман TGT билет учетной записи контроллера домена. Теперь можно, используя уже известную Pass-the-ticket атаку, импортировать билет и с помощью mimikatz провести атаку DCSync, чтобы получить NTLM-хэш учетной записи krbtgt (а как вы уже знаете из первой части статьи, хэш этой учетной записи можно использовать для создания Golden Ticket и полного захвата домена AD).



Обратите внимание, что Rubeus понимает билеты как в виде .kirbi файла, так и в строке закодированной base64.


Сonstrained Delegation


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

Создадим нового доменного пользователя Backup с паролем B@ckup1234, присвоим ему SPN для службы cifs на контроллере домена.



Теперь можно установить для этой учетной записи возможность делегирования служб ldap и cifs на контроллере домена DC-16.meow.local.



Определить учетные записи, которым разрешено ограниченное делегирование, можно также с помощью Powerview или модуля ActiveDirectory.



Зная пароль или NTLM-хэш учетной записи meow.local\Backup, с помощью Rubeus можно запросить билет TGT для неё.



Теперь, используя экшн s4u в Rubeus можно запросить TGS для пользователя, которому разрешена аутентификация на сервисе cifs\dc-16.meow.local (например, администратору домена ADadmin).



Здесь я указываю полученный ранее билет учетной записи Backup; /impersonateuser пользователя, права которого хочу получить; /domain домен, в котором всё происходит; /msdsspn /asltservice сервис, для которого нужен TGS; /ptt сразу импортировать полученный билет в текущую сессию.

Вот что происходит в Rubeus:



Здесь можно заметить, что при ограниченном делегировании включаются 2 расширения Kerberos: это S4U2self и S4U2proxy.

S4U2self позволяет участникам службы запросить специальный TGS с флагом FORWARDABLE к себе от имени конкретного пользователя. Это нужно для того, чтобы данный билет в дальнейшем мог использоваться расширением S4U2proxy.

S4U2proxy позволяет вызывающей стороне использовать этот специальный билет, чтобы запросить TGS пользователя для службы, к которой разрешено делегирование (в данном случае cifs\dc-16.meow.local). Более подробно об этом можно прочитать здесь и здесь.

В это время Rubeus уже получил финальный тикет и импортировал его в текущую сессию.



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



Да, всё прошло успешно.

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

Спасибо за внимание, всем добра, не болейте!
Подробнее..

VMware приобретает Datrium для развития сервиса аварийного восстановления данных

03.07.2020 16:05:03 | Автор: admin


Американская компания VMware, чьи продукты используют многие облачные провайдеры, объявила о своем намерении приобрести Datrium, разработчика сервисов по аварийному восстановлению данных. Покупка обусловлена желанием расширить возможности своего решения Disaster-Recovery-as-a-service (DRaaS) и активным ростом спроса на услугу. Аналитики IDC назвали самым быстрорастущим сегментом рынка защиты данных, оценив его в 4,5 млрд долларов. По итогам сделки технологии Datrium будут интегрированы в портфель облачных решений VMware, и это поможет улучшить сервис восстановления.

Datrium с момента своего основания привлекла около 120 млн долларов инвестиций и поддерживал партнерские отношения и с крупнейшими облачными провайдерами под лозунгом любое облако, любое приложение, любое устройство с собственной системой безопасности. Стартап не первый год работает вместе с VMware, предлагая услуги восстановления систем в среде VMware Cloud на Amazon Web Services, позволяя создавать резервные копии, которые шифруются, дедуплицируются и хранятся в хранилище Amazon S3.

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

По мнению вице-президента и руководителя направления гиперконвергентной инфраструктуры VMware Джона Гилмартина, новое решение способно уменьшить стоимость и сложность обеспечения бесперебойности бизнес-процессов компаний. А генеральный директор Datrium Тим Пейдж подчеркнул, что аварийное восстановление должно быть быстрым и простым. И компании не должны довольствоваться конвертацией форматов виртуальных машин или длительными периодами восстановления состояния их приложений по уцелевшим данным, когда авария в самом разгаре. Поскольку VMware решает аналогичные задачи по обеспечению бесперебойной работы в мире облачных сред, объединение двух компаний было делом времени.

Сделка VMware с Datrium это очередной этап развития американской компании своих облачных сервисов. В мае 2020 года она поглотила Octarine (компания занималась вопросом защиты контейнеров Kubernetes), а в июне Lastline (стартап специализировался на борьбе с вредоносным ПО).
Подробнее..

АES американский стандарт шифрования. Часть II

03.07.2020 16:05:03 | Автор: admin
image

Основные операции шифра


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

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

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

Конкурсной комиссией были предварительно отобраны 15 заявок от разных стран. Выступать могли как организации, так и частные лица. В итоге победил RIJNDAEL(Бельгия) авторы Винсент Рюмен (Vincent Rijmen) и Ион Дэмен (Joan Daemen). Структуру шифра считают классической SP-сетью.

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

Шифрование сообщений


Разработчиками создан шедевр, впервые идеология и реализация симметричного блочного шифра стала до конца понятной, так как шифр полностью основан на элементах классической (прозрачной) алгебраической структуры (поле), с достаточно скромными для обозрения количественными характеристиками. Конечное расширенное поле (поле многочленов) характеристики 2 имеет степень расширения n=8 и число элементов (порядок поля 28 = 256), отсюда обозначение поля GF(28).

Выбор неприводимого многочлена поля $(x) =x^8 +x^4 + x^3 + x + 1$ и примитивного элемента поля = 000000112 = 310, также не является загадочным. Одним словом, это не DES и не отечественный ГОСТ 28147.89.
Исходные тексты подготавливаются на устройствах с клавиатурой, используя
Таблицу Символы кода ASCII



Раунды и операции шифрования АЕS


Число раундов шифра обозначается Nr и зависит от длины ключа (Nr = 10 для ключа 128 битов, Nr= 12 для ключа 192 бита и Nr = 14 для ключа 256 битов).
Цикл (один раунд) шифрования AES состоит (в изменении состояния State шифруемого сообщения) из четырех основных операций:
1. AddRoundKey S + Ki; суммирование состояния (исходного текста с ключом)
2. SubBytes ax-1 + b; замена результатов суммирования другими байтами
3. ShiftRows; Sp(x); циклические сдвиги строк на разное число позиций
4. MixColumns A0S. перемешивание столбцов квадрата.

Покажем, как это происходит на числовом примере для текущего состояния в каждой операции, начиная с верхней (нулевой) строки. Результаты 2-й и 3-й операций не требуют числовых преобразований, но MixColumns связана с умножением 2-х матриц и определение элементов результирующей матрицы требует конкретных вычислений в поле GF(28). Алгоритм выработки ключа (Kеу Schedule) формирует 32-разрядные слова, число которых равно длине блока Nb.

Первому раунду предшествует предварительный (нулевой), в котором суммируются квадраты исходного текста и ключа. Рассмотрим каждую операцию более детально.

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

Операция AddRoundKey для i-го раунда


Суммирование столбцов State с раундовым ключом (Add Round Key).

Раундовый ключ, предварительно вычисленный и выбранный, представляется в форме (квадрат) State (Key). Суммирование выполняется для одноименных столбцов. Пара столбцов State (Data) и State (Key) операцией XOR поразрядно складывается.

Таким образом, преобразование AddRoundKey состоит из суммирования матрицы S блока (квадрата 44) сообщения в M4(GF(28)) с частичным Ki ключом i-го раунда (также с квадратом 44 ). Результат суммирования обозначается SiA, т е. состояние после i-го AddRoundKey M4(GF (28)) M4(GF (28)), S SiA = S + Ki.
В начальном раунде (r = 0) выполняется только Add RoundKey суммирование по mod2 (XOR) байтов блока данных и блока ключа. Результат этого раунда используется как исходное (State) состояние для первого раунда (r=1) и представляется в формате квадрат.
Шифрование сообщений AES

Пример 1. Сообщение (исходный текст = ИТ) в 16-ричном представлении
имеет вид 32 43 f6 a8 88 5a 30 8d 31 31 98 a2 e0 37 07 34,
а ключ шифра 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 0f 4f 3c.
Операция AddRoundKey S + Ki для всех 16 байтов квадрата State
Предварительный раунд зашифрования подготавливает сумму ИТ с ключом.

Их Сумма, представленная байтами в формате квадрат при Nb = Nk = 4 и Nr = 10 имеет вид:


Рисунок Результат предварительного раунда (до первого)

Ключ и исходный текст (это может быть и звук и картинка и др.) представлены в 16-ричном виде. Это не самое удобное представление, поэтому преобразуем его к двоичным векторам и выполняем сложение по модулю 2.



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

Операция SubByte для i-го раунда


Замена байтов (Sub Bytes ( ) )

Первый раунд. Операция AddRoundKey уже выполнена. Все байты суммарного квадрата (исходного состояния обозначим их точками (х, y) на некоторой плоскости) преобразуются функцией S (x, y) в новые значения табличка "Замена байтов".

Заменяем угловой (левый верхний) байт State = Сумма, (равный 19), на байт d4 из таблицы замен S-блока и следующий (3D) на 27 (они выделены заливкой). Так преобразуются все 16 байтов квадрата "Сумма".

Так для первого байта {19} = {x, y}, x = 1, y = 9, S(19) = d4. Все такие значения также представляются квадратом с замещениями.

Функция S (x, y) табулирована, т. е. задана таблицей с двумя входами строка (х) и столбец (у). Поскольку все многообразие байтов исчерпывается числом 256, то таблица имеет размер 1616 = 256, а ее строки и столбцы пронумерованы x, y = 0(1)15 цифрами 16-ричной системы счисления. Вид таблицы S (x, y) приведен ниже.



Покажем, как получены значения этой таблицы S (x, y). Вначале каждый байт исходного состояния {x, y} преобразуется в инвертированный {x, y}-1, в мультипликативный обратный в поле GF(28). Затем байт умножается на матрицу А. Нулевой байт переходит в себя {0, 0}-1 = {0, 0}.

Каждая строка матрицы аффинного преобразования А содержит лишь пять единиц.

Затем к инвертированному (обращенному) байту применяют аффинное преобразование, которое в векторно-матричной форме записывается так



Аффинная матрица

Запись векторов сверху (младший разряд) вниз. Вектор сдвига c = {63}16, что в таблице S (x, y) отражено для байта {00}. Каждый байт исходного состояния подвергается такому преобразованию, и их значения вписаны в квадратную таблицу S (x, y).

Скалярное представление аффинного преобразования имеет следующий вид (общий вид i -го элемента результата):


где $c_0 = c_1 = c_5 = c_6 = 1; c_2 = c_3 = c_4 = c_7 = 0$; $b_i$, $b_i$' соответственно исходное и преобразованное значение i-го разряда байтов, i = 0(1)7.

Выражение для $b_i$' содержит 6 слагаемых, так как каждая строка циклической матрицы аффинного преобразования имеет лишь 5 ненулевых элементов; шестое слагаемое берется из вектора сдвига ci.

Для ускорения вычислений используется квадратная таблица фиксированных значений (S (x, y) блок). Значение b =63 16 ричное число принадлежит GF(28) и матрица а имеет вид, показанный ранее. В сущности, операция реализует подстановку (замену) байт из S квадрата 1616.

Преобразование SubByte состоит в применении к каждому элементу матрицы S элементарного преобразования s. Результат этой операции обозначается SiSu, т. е. это состояние блока текста после операции SubByte i-го раунда. Не путать буквы S и s (большую и малую).

В сущности, здесь выполняется аффинное преобразование с постоянным вектором сдвига, обозначаемым символом b
M4 (GF(28)) M4 (GF(28)).

Запись векторов сверху (младший разряд) вниз. Вектор сдвига c = {63}16, что в таблице S (x, y) отражено для байта {00}. Каждый байт исходного текста (состояния) подвергается такому преобразованию, и их значения вписаны в таблицу S (x, y).

Пример 2. Первый байт исходного состояния первого раунда равен {19}. Мультипликативный обратный для него (см. Табл. П1) равен 3f = {19}-1= 0011 11112 =113. Это значение легко находится по таблице элементов поля GF(28). При отсутствии таблицы элементов поля можно выполнить и непосредственные вычисления.

Пусть байт {x, y} = 09 = 199 и {09} -1 = 4f, тогда
b0 = (1+0+1)mod2 = 0, b4 = (1+1+0)mod2 = 0,
b1 = (1+0+1)mod2 = 0, b5 = (0+1+1)mod2 = 0,
b2 = (1+0+0)mod2 = 1, b6 = (0+1+1)mod2 = 0,
b3 = (1+1+0)mod2 = 0, b7 = (0+1+0)mod2 = 1.
Результирующий вектор ( 0, 1, 2, 3, 4, 5, 6, 7) =1000 01002 = 84.

Следовательно, байт 4f S-блоком преобразуется в байт 84, что можно увидеть в таблице замен S (x, y) = S (4, f) = 84. Этот результата лежит на пересечении строки с номером 4 и столбца с номером f. Геометрическое представление замены байтов (SubBytes) изображено на рисунке 4, где s нелинейное преобразование, определяемое соотношениями:
GF(28) GF(28),


Операция ShiftRows для i-го раунда


В каждом раунде после замены всех байтов State получен квадрат (средний) исходного состояния для преобразования сдвига строк. Такой сдвиг способствует еще большему перемешиванию данных.

Выбор величин сдвигов подчинен следующим условиям:
Каждая строка должна иметь индивидуальное смещение элементов;
Реализация операции должна быть простой;

Совокупность сдвигов наилучшим образом должна препятствовать проведению атак:

А) атак, использующих сокращенные дифференциалы
В) атак типа Square.


Рисунок 5 Состояние после сдвига строк

ShiftRows преобразование перемещения байтов строки в матрице состояния S, которое циклически сдвигает строки матрицы состояния на различные по величине смещения. Результат операции обозначается SiSh, т. е. это состояние после операции ShiftRows
i-го раунда. Такие перемещения могут быть описаны Р(х) перестановкой байт из квадрата S, которая имеет вид:


Из всех вариантов сдвигов, обеспечивающих наилучшее противостояние атакам, был выбран самый простой циклический сдвиг и c0 = 0.

Геометрическое представление преобразования замены байтов изображено на рисунке 4, где приведены квадраты числового примера для первого раунда.

Сдвиг строк в массиве State выполняется влево. Строка с номером нуль остается неподвижной (не сдвигается). Остальные строки RIJNDAEL сдвигаются на число байтов c1, c2, c3, указанное в квадрате на рисунке 5), в зависимости от числа Nb байтов в блоке данных. Строка 1 сдвигается на c1 байтов, строка 2 на c2 байтов и строка 3 на с3 байтов.

В стандарте AES величина Nb = 128 постоянная, поэтому всегда c1 = 1, c2 = 2 и c3 = 3.

Таблица Величины сдвигов



Операция MixColumns для i-го раунда


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

  • Обратимость получаемого результата.
  • Линейность в поле GF(28); выполнение этого требования создает условия для применения алгоритма прямого расшифрования.
  • Достаточно сильное рассеивание данных.
  • Высокую скорость реализации на 8-разрядных процессорах; единообразие обработки любых блоков данных, т. е. симметричность.
  • Простой вид для описания и реализации.

Все названные требования удовлетворены в стандарте АES. Из возможных линейных преобразований 4 bytes 4 bytes выбрана операция умножения многочленов (элементов поля) по модулю (x) = x4 + 1. Выбор коэффициентов сомножителей обусловлен требованиями 1, 3 и 4. Коэффициенты {00}, {01}, {02}, {03}, соответствуют: {00} отсутствию преобразования; {01} не требуется умножения; {02} умножение при использовании функции x time ( ) и {03} при использовании x time и последующего сложения по mod2 промежуточных результатов.

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

Сущность преобразования Mix Columns ( ) состоит в следующем. Столбцы State
S = < S0c, S1c, S2c, S3c>, с = 0(1)3, после сдвига строк рассматриваются как элементы поля GF(28) и умножаются по mod(x4 + 1) на фиксированный многочлен g(x):
g(x) = {03}x3+{0,1}x2+{01}x+{02}.


где с номер столбца State, c = 0(1)3.

где А циркулянтная матрица, т. е. линейное инвертируемое (обратимое) отображение на GF (28), А принадлежит M8(GF (28)),
обозначает умножение матрицы из GF (28) и вектора
х -1 = {b0 b1b7 }b, который рассматривается как элемент над полем GF(2) векторного пространства, эквивалентный транспонированному в вектор {b0 b1b7 }b.

Развернем это выражение в скалярную форму
S0C = ({02} S0C) ({03} S1C) S2C S3C;
S1C = S0C ({02} S1C) ({03} S2C) S3C;
S2C = S0C S1C ({02}S2C) ({03} S3C);
S3C = ({03} S0C) S1C S2C ({02} S3C).
В результате выполнения указанных действий байты вектора
SC = <S0c, S1c, S2c, S3c> будут заменены байтами S0C, S1C, S2C, S3C.

MixColumns преобразование состоит из умножения двух матриц. Матрицы S промежуточного состояния текста и фиксированной матрицы A0 обе из введенного ранее множества M4 (GF (28)). Результат операции обозначается символом SiM, это по существу состояние S после операции MixColumns i-го раунда.

M4 (GF (28)) M4 (GF (28)),
S Si, М = АS,
где матрицы А и А-1 (циркулянтные матрицы) определяются как:

.
Операция MixColumns произведение специальной цикловой А0 матрицы на матрицу State, по правилу строка на столбец

.
Два пустых столбца в результирующей матрице оставлены для самостоятельного заполнения.
Начинаем с левого углового элемента нулевой строки квадрата. Его значение определяется суммой произведений пар элементов: {02}D4{03}BF {01}5D {01}30. Элементы обеих матриц это элементы поля GF(28) с одной стороны и информационные байты в 16-ричном представлении с другой. Умножение элементов в поле удобно выполнять в степенном представлении примитивного элемента.

Пользуясь таблицей поля, выполним замену 16-ричного представления на степенное для левой цикловой матрицы элементы {01} = a0, {02} = a25, {03} = a1. Для правой матрицы в произведении получим


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

1-й элемент нулевой строки определяется в виде:

{02}D4 {03}BF {01}5D {01}30 = a25а65 a1а157 a0а136 a0а101 = а90 a158а136а101,

2-й элемент нулевой строки определяется аналогичным соотношением (поменялся столбец)

{02}Е0{03}B4 {01}52 {01}АЕ = a25а68 a1а251 a0а253 a0а123 = а93 a252 а253а123,

3-й элемент нулевой строки определяется аналогичным соотношением поменялся столбец

{02}B8{03}41 {01}11 {01}F1 = a25а59 a1а143 a0а4 a0а74 = а84 a144 а4 а74,

4-й элемент нулевой строки определяется аналогичным соотношением поменялся столбец

{02}1Е{03}27 {01}98 {01}Е5 = a25а28 a1а106 a0а89 a0а32 = а53a107 а89а32.

Показатели степеней просто суммируются при перемножениях как логарифмы. Суммирование слагаемых удобно выполнить возвратом к 16-ричному, а от него к двоичному представлению. Опять воспользуемся таблицей элементов поля GF(28).



Перейдем к вычислению элементов 1-й строки матрицы (изменяется номер строки циклической матрицы) Элементы в парах произведений изменяются относительно 0-й строки.

1-й элемент 1-й строки матрицы перемешанных столбцов определяется соотношением.


Перейдем к вычислению элементов 2-й строки матрицы (изменяется номер строки циклической матрицы). Элементы в парах произведений изменяются относительно 1-й строки.

1-й элемент 2-й строки матрицы перемешанных столбцов определяется соотношением



Перейдем к вычислению элементов 3-й строки матрицы (изменяется номер строки циклической матрицы) Элементы в парах произведений изменяются относительно 2-й строки.

Подробнее..

Перевод Нет Cookies, нет проблем использование ETag для отслеживания пользователей

03.07.2020 22:11:07 | Автор: admin
Работая старшим консультантом по дижитал-аналитике в ведущем международном аналитическом агентстве, с огромным интересом наблюдаю за нынешним крестовым походом современных веб-браузеров против технологии cookie.

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


Для наглядности я создал демо-сайт. Вот он.

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

Итак, как именно я могу хранить идентификатор и узнавать, что вы с определённого устройства возвращаетесь на сайт, при этом без входа в систему и без использования куки?
EDISON Software - web-development
Мы в EDISON со всеми этими нюансами приватности сталкиваемся постоянно.


Наш новый выполненный проект Резидент Такси в котором мы связали в единое целое сайт агрегатора-такси, CRM-систему, блок контроля водителей и автомобилей, мобильные приложения для iOS и Android.

Однако, всегда учитываем: безопасность каждого пользователя это святое ;-)

Cookies используются всё меньше


Если вы достаточно активный пользователь интернета, вы наверняка так или иначе сталкивались с бесконечными дискуссиями относительно файлов cookie и о том, как они используются. В настоящее время браузерные технологии всё чаще отказываются от куки тем паче что сейчас всё строго зарегламентировано правилами конфиденциальности, такими как GDPR или CCPA. Хотя это, безусловно, прогресс, так как является важным шагом на пути к более ориентированному на конфиденциальность интернету, однако с другой стороны также наносит огромный урон основной функциональности большинства веб-сайтов, их UX, экономической структуре интернета и индустрии дижитал-аналитики. Хотя в техническом аспекте использование cookie-файла браузером в качестве идентификатора для возвращающегося пользователя весьма надёжно, есть и другие веб-технологии, основанные на хранении информации на локальном компьютере.

Роль кэша


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

Кэширование может быть выполнено с использованием ETag. Это такие идентификаторы, которые прикрепляются к каждому ресурсу, предоставляемому сервером (например, веб-странице или изображению). Таким образом сервер выясняет, кэшировал ли пользователь самую новую версию ресурса. Когда ресурс на сервере изменяется, для этого ресурса создается новый идентификатор ETag.

  • Понедельник.
    Пользователь заходит на веб-сайт впервые. В запросе отсутствует ETag. Страница сайта отправляется в браузер с ETag 123. Сайт сохраняется (кэшируется) на локальном устройстве.
  • Вторник
    Пользователь снова заходит на тот же сайт ETag 123 включён в исходящий запрос Сервер проверяет, изменился ли ресурс (Идентификатор ETag остается прежним?) Если ETag не изменился, сервер инструктирует браузер: просто используйте сайт, который был уже доставлен и кэширован в понедельник. Нет необходимости веб-ресурс пересылать повторно, время и трафик экономятся. Profit.


Использование технологии кэширования для отслеживания и идентификации пользователей


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

Вот как это сделал я в моём примере:

  • Создаётся простой сайт с тремя страницами.
  • Вставляется один и тот же iFrame на каждую страницу. Этот iFrame просто белый пиксель 1x1, который невидим для пользователя.
  • Когда запрашивается этот веб-ресурс iFrame, с помощью PHP генерируется случайный идентификатор на стороне сервера. Я использую этот идентификатор, чтобы переопределить идентификатор ETag для iFrame, который обычно сервером выдаётся автоматически.
  • Каждый раз, когда пользователь запрашивает одну из трёх страниц (и, следовательно, запрашивает iFrame), мой идентификатор ETag включается в запрос. Затем проверяется на стороне сервера, существует ли этот идентификатор или это первый запрос без ETag.
  • Если ETag существует: значит, это вернувшийся посетитель. Можно зафиксировать как удостоверение его личности.
  • Если ETag не существует: это новый посетитель. Новый ID. С этого момента этот идентификатор будет включен во все заголовки запросов устройства этого пользователя на сайте.
  • В качестве последнего шага вот как этот ETag ID попадает в аналитику:
    я беру ID из заголовков запроса/ответа в iFrame на стороне сервера. Невидимый для пользователя, этот iFrame теперь содержит идентификатор пользователя. Затем я использую JavaScript на стороне клиента и просто включаю этот идентификатор в свой запрос отслеживания аналитики вместо идентификатора файла cookie.



Поиск ETag ID iFrame с помощью Chrome DevTools.

Как предотвратить отслеживание с помощью ETag


Это может быть достаточно непросто. Здесь не используются куки или локальное хранилище браузера. Работает без участия JavaScript. И не используется User-Agent.

Однако у пользователей есть несколько вариантов защиты от отслеживания ETag:

  • Отключите в настройках браузера кеширование.
    Тут следует соблюдать осторожность как пояснялось выше, кеширование может быть очень полезным и имеет много преимуществ.
  • Модифицируйте заголовки headers с помощью надстройки браузера.
    Хотя большинство браузеров изначально не предоставляют возможность изменять headers, для этой задачи существует множество доступных расширений браузера, таких как ModHeader. Почему это работает? Функциональность ETag опирается на заголовки запроса и ответа для обмена идентификатором. Например, если пользователь перезаписывает заголовок If-None-Match, чтобы он был пустым при каждом запросе, новое значение ETag будет генерироваться при каждом запросе страницы. Это предотвращает идентификацию устройства пользователя.




Почему это важно


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

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

Один из многих (безопасных) примеров ETag в интернете можно найти, к примеру, в политике конфиденциальности сети быстрого питания Wendy в отношении файлов cookie и технологий отслеживания:


С помощью ETag можно генерировать уникальные значения отслеживания, даже если пользователь блокирует файлы cookie HTTP, Flash и/или HTML5.

Подобное объявление, похоже, является примером того, как многие сайты используют ETag в своей политике конфиденциальности. Чтобы было ясно: это само по себе не является ни плохим, ни незаконным. Конечно, значения ETag должны быть уникальными. В этом весь смысл их работы в целях кэширования. Однако этот раздел сформулирован очень расплывчато и неоднозначно, особенно когда речь идет о том, используются ли эти значения ETag для отслеживания или нет. И лично я считаю это проблемой. При запросе в отдел конфиденциальности Wendy, они ответили стандартным электронным copy-paste письмом, подтверждающим, что ETag не используются для отслеживания. Политика конфиденциальности, однако, оставляет эту дверь широко открытой. И это то, что меня беспокоит.

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

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

Расчет факторов в антифроде. Доклад Яндекса

04.07.2020 12:05:52 | Автор: admin
Антифрод сервис по поиску и нивелированию случаев эксплуатации других, общедоступных сервисов Яндекса. Три года назад мы начали проектировать платформу, позволяющую быстро и легко развернуть антифрод где угодно в компании. Сложность задачи в том, что многим сервисам нужны максимально строгие гарантии по скорости, надежности и качеству; часть из них оперирует очень большими объемами данных. Команде антифрода, в свою очередь, важна гибкость системы, простота поддержки и выразительность факторов, на которых будет строиться машинное обучение.


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

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

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

Что такое антифрод?


Что вообще такое антифрод? Думаю, проще всего показать.

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

С чем вообще борется антифрод? Пара примеров.

Например, имитация действий пользователя. Этим занимаются ребята, которых мы называем черные SEO, те, кто не хочет улучшать качество сайта и контент на сайте. Вместо этого они пишут роботов, которые ходят на поиск Яндекса, кликают по их сайту. Они расчитывают, что так их сайт поднимется выше. На всякий случай напоминаю, что такие действия противоречат пользовательскому соглашению и могут привести к серьезным санкциям со стороны Яндекса.



Или, например, накрутка отзывов. Такой отзыв можно увидеть у организации на Картах, которая ставят пластиковые окна. За этот отзыв она же сама и заплатила.

Верхнеуровнево архитектура антифрода выглядит так: некоторый набор сырых событий попадают в саму система антифрод как в черный ящик. На выходе из него генерируются размеченные события.

У Яндекса много сервисов. Все они, особенно большие, так или иначе сталкиваются с разными видами фрода. Поиск, Маркет, Карты и десятки других.

Где мы были еще года два-три назад? Каждая команда выживала под натиском фрода как могла. Она генерировала свои команды антифрода, свои системы, которые не всегда работали хорошо, были не очень удобны для взаимодействия с аналитиками. И главное, они были слабо проинтегрированы между собой.

Я хочу рассказать, как мы это решили созданием единой платформы.



Зачем нам нужна единая платформа? Переиспользование опыта и данных. Централизация опыта и данных в одном месте позволяет быстрее и качественнее реагировать на крупные атаки они обычно бывают кросс-сервисными.

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

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

Расскажу немного про то, как мы классифицируем антифроды.



Это может быть офлайн-система, которая считает часы, дни и тяжелые офлайн-процессы: например, сложные кластеризации или сложное переобучение. Этой части я практически не буду касаться в докладе. Есть near real-time-часть, которая работает за единицы минут. Это некая золотая середина, у нее быстрая реакция и тяжеловесные методы. В первую очередь я остановлюсь на ней. Но не менее важно сказать, что на этом этапе мы используем данные с этапа уровнем выше.

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

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

Я практически не буду касаться самих ML-методов. В основном я буду рассказывать о платформах, создающих фичи, которые мы потом используем в обучении.

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

Какие у системы требования? Их достаточно много, вот некоторые из них:

Большой поток данных. Мы обрабатываем сотни миллионов событий за пять минут.
Полностью конфигурируемые фичи.
Декларативный язык описания факторов.
Конечно же, кросс-ДЦ и exactly-once-обработка данных, которая нужна для некоторых сервисов. Удобная инфраструктура как для аналитиков, которые подбирают итоговые фичи, обучают модели и подобное, так и для разработчиков, которые поддерживают систему.
И, конечно, скорость.

Дальше расскажу про каждый из этих пунктов в отдельности.

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

Все совпадения с реальными сервисами, естественно, случайны. Рассмотрим в первую очередь near real-time-версию, так как онлайн конкретно здесь не нужен при первом приближении.

Большие данные



В Яндексе есть классический способ решения проблем с большими данными: использовать MapReduce. Мы используем нашу собственную реализацию MapReduce, называется YT. Кстати, у Максима Ахмедова сегодня вечером рассказ про нее. Вы можете использовать вашу реализацию либо опенсорсную реализацию вроде Hadoop.

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

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

Дальше мы над этим набором батчей запускаем набор Reduce и получаем размеченный батч.



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

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

Как следствие, нам нужна большая история данных, в которой мы будем хранить эти статистики.



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

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



Заменим это на некий key-value store. Это вновь наша собственная реализация, key-value-хранилище, но она хранит данные в памяти. Наверное, ближайший аналог какой-нибудь Redis. Но у нас тут получается небольшое преимущество: наша реализация key-value store очень сильно проинтегрирована с MapReduce и кластером MapReduce, на котором это запускается. Получается удобная транзакционность, удобная передача данных между ними.

Но общая схема что мы в каждом джобе этого Reduce будем ходить в этот key-value storage, обновлять данные и записывать обратно после формирования вердикта по ним.

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

Конфигурируемые фичи


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

Давайте разобьем на три этапа:
Extract, где мы изымаем данные для данного ключа и из лога.
Merge, где мы сливаем эти данные со статистикой, которая находится в истории.
Build, где мы формируем итоговое значение фичи.

Давайте, например, посчитаем процент детективов, прочитанных пользователем.



Если пользователь читает слишком много детективов, он слишком подозрительный. Никогда непонятно, чего от него ждать. Тогда Extract изъятие количества детективов, которые прочел пользователь в этом батче. Merge взятие всех детективов, всех этих данных из батчей за месяц. И Build это какая-то сумма.

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

А если мы хотим посчитать разные значения, например, количество различных авторов, которых читает пользователь?





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



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

Давайте, например, введем вот такие разрезы пользователь, автор и жанр.



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

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

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



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



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

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

Как это сделать в парадигме MapReduce? Давайте сделаем несколько последовательных редьюсов и зависимости между ними.



У нас получается граф редьюсов. Он влияет на то, по каким срезам мы считаем фичи, какие джойны вообще допустимы, на количество потребляемы ресурсов: очевидно, чем больше редьюсов, тем больше ресурсов. И Latency, throughput.

Построим, например, такой граф.



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

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

Здесь важно, что у нас нет вот такой зависимости:



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

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



Второе значение на первом этапе батча N+1, и итоговое значение нужно считать на втором этапе батча N+1. Таким образом, при переходе между первым этапом и вторым будут, может быть, не совсем точные статистики для батча N+1. Но обычно этого достаточно для подобных расчетов.



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



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

Но так как поток у нас может приходить неравномерно, сначала клик, то мы должны его отложить до момента, пока мы не увидим показ и не примем вердикт на его основе.

Язык описания фич


Расскажу немного про язык описания всего этого.



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



Это какая-то фича, nullable-число.



И какое-то правило. Что мы называем правилом? Это набор условий на этих фичах и что-то еще. Было у нас три отдельных файла.

Проблема в том, что тут одна цепочка действий разнесена по разным файлам. С нашей системой нужно работать большому количеству аналитиков. Им было неудобно.

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

Решение давайте сделаем свой DSL. Он более понятно описывает наш сценарий, он проще для новых людей, он более высокоуровневый. Вдохновение мы брали у SQLAlchemy, C# Linq и подобного.

Приведу пару примеров, аналогичных тем, которые я приводил выше.



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



Если мы считаем количество различных авторов, то делаем группировку по пользователю, задаем distinct авторов. К этому можем добавить какие-нибудь условия, например окно расчета или лимит на количество значений, которые мы храним из-за ограничения памяти. В итоге считаем count, количество ключей в нем.



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



К этому мы потом можем добавить условие фильтрации. То есть фильтр у нас может быть, например, таким: лояльность не слишком высокая и количество процентов детективов между 80 из 100.

Что мы для этого используем под капотом?



Под капотом мы используем самые современные технологии, напрямую из 70-х годов, такие как Flex, Bison. Может быть, слышали. Они генерируют код. У нас файл с кодом проходит через наш лексер, который сгенерирован во Flex, и через парсер, который сгенерирован в Bison. Лексер генерирует терминальные символы или слова в языке, парсер генерирует синтаксические выражения.

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

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

Надежность


Некоторые сервисы требуют отказоустойчивости: кросс-ДЦ и exactly-once-обработку. Нарушение может вызывать расхождение статистик и потери, в том числе денежные. Наше решение для MapReduce такое, что мы считаем данные в каждый момент времени только на одном кластере и синхронизируем их на второй.



Например, как бы мы вели себя здесь? Есть лидер, follower и message broker. Можно считать, что это условная кафка, хотя тут, конечно, собственная реализация.



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

Раз в какое-то время мы, естественно, должны сделать репликацию. То есть мы собираем снапшоты, собираем ченжлоги изменения за каждый батч. И то, и то синхронизируем на второй кластер follower. И также поднимаем историю, которая находится в таком горячем состоянии. Напомню, что история здесь хранится в памяти.

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

Почему бы вообще не считать на двух кластерах параллельно? Внешние данные могут отличаться на двух кластерах, поставлять их могут внешние сервисы. Что вообще такое внешние данные? Это что-то, что с вот этого более высокого уровня поднимается. То есть сложные кластеризации и подобное. Либо просто вспомогательные для расчетов данные.

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

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



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

Преимущество мы можем на препроде считать больше фичей. Почему это вообще нужно? Потому что понятно, что если мы хотим большой объем фич считать, то нам часто не нужно все их считать на проде. Там мы считаем только то, что нужно для получения итоговых вердиктов.

(00:25:12)

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

К этому добавляются преимущества B2B-тестирования. То есть мы все выкатываем, естественно, сначала на препрод. Полностью сравниваем любые отличия, и, таким образом, не ошибемся, минимизируем вероятность, что мы можем ошибиться при выкатке на прод.

Немного про планировщик. Понятно, что у нас есть какие-то машины, которые запускают задачу в MapReduce. Это некие воркеры. Они регулярно синхронизируют свои данные в Cross-DC Database. Это просто состояние того, что они успели посчитать на данный момент.



Если воркер становится недоступен, то другой воркер пытается захватить лог, забрать состояние.



Переподняться с него и продолжить работу. Продолжить ставить задачи на этом MapReduce.



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

То есть весь код должен быть написан так, чтобы это нормально работало.



Немножко расскажу про exactly-once. Мы выносим вердикт согласованно, это очень важно. Используем технологии, которые дают нам такие гарантии, и мониторим, естественно, все расхождения, сводим их к нулю. Даже когда кажется, что это уже сведено, периодически возникает очень хитрая проблема, которую мы не учли.

Инструменты


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



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



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



Что мы вообще мониторим? Очевидно, лаг системы крайне важен. Очевидно, время работы каждой отдельной стадии и, конечно же, фильтрация отдельных правил. Это бизнесовое требование.

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

Скорость


Расскажу про переход в онлайн-часть. Тут проблема в том, что лаг в полноценном контуре может достигать единиц минут. Это в контуре на MapReduce. В некоторых случаях нам нужно банить, обнаруживать мошенников быстрее.

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



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

В такой схеме может возникнуть следующая проблема.



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

Тогда мы из этого key-value storage считаем данные на оба воркера из истории, мы его обновим по-разному и возникнет гонка при попытке записать обратно.

Решение: давайте сделаем предположение, что можно разделить чтение и запись, что запись может происходить с небольшой задержкой. Обычно это не сильно важно. Под небольшой задержкой я здесь подразумеваю единицы секунд. Это важно, в частности, по той причине, что наша реализация этой key-value store занимает больше времени на запись данных, чем на чтение.

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



И другая вещь. Для простоты сольем вот эти истории в одну и пошардируем ее по типу и по ключу разреза. У нас есть какая-то единая история.

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

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



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

Здесь у него меняется его предназначение. Он больше не принимает вердикты. Вместо этого он просто принимает updates из Reader, смешивает их и правильно применяет к истории.

Понятно, что здесь нужна компонента, координатор, которая распределяет эти updates между ридерами и райтерами.

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



Что мы вообще получили? Аналитики стали делать работу быстрее и одинаково для всех сервисов. Это повысило качество и связанность всех систем. Можно переиспользовать данные между антифродами разных сервисов, а новые сервисы получают качественный антифрод быстро.



Пара мыслей в конце. Если вы будете писать нечто подобное, сразу подумайте про удобство аналитиков в части поддержки и расширяемости данных систем. Делайте конфигурируемым все что можно, это вам понадобится. Иногда свойств кросс-ДЦ и exactly-once бывает сложно достичь, но можно. Если вам кажется, что уже достигли, перепроверьте. Спасибо за внимание.
Подробнее..

Перевод 6 лучших практик для безопасного управления Git-репозиториями

04.07.2020 12:05:52 | Автор: admin
Избегайте захламления репозиториев и других действий, которые усложняют управление кодовой базой. Вместо этого используйте лучшие практики, которые помогут упростить работу.



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


Изучите свой репозиторий




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

Старайтесь не добавлять бинарники




Git изначально заточен под текстовые файлы, будь то код на C, Python или Java, или JSON, YAML, XML, Markdown, HTML и так далее:

$ cat hello.txtThis is plain text.It's readable by humans and machines alike.Git knows how to version this.$ git diff hello.txtdiff --git a/hello.txt b/hello.txtindex f227cc3..0d85b44 100644--- a/hello.txt+++ b/hello.txt@@ -1,2 +1,3 @@ This is plain text.+It's readable by humans and machines alike. Git knows how to version this.


Git не любит бинарные файлы:

$ git diff pixel.pngdiff --git a/pixel.png b/pixel.pngindex 563235a..7aab7bc 100644Binary files a/pixel.png and b/pixel.png differ$ cat pixel.pngPNGIHDR7n$gAMA              abKGDtIME                          -2RIDAc`!3%tEXtdate:create2020-06-11T11:45:04+12:00r.%tEXtdate:modify2020-06-11T11:45:0


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

Что ещё хуже, вы сами не можете проверить (прочитать и проанализировать) двоичные данные.
В дополнение к обычным инструментам POSIX вы можете найти двоичные файлы, используя git diff. Когда вы попытаетесь запустить команду diff с параметром --numstat, Git вернёт нулевой результат:

$ git diff --numstat /dev/null pixel.png | tee-     -   /dev/null => pixel.png$ git diff --numstat /dev/null file.txt | tee5788  0   /dev/null => list.txt


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

Сторонние библиотеки должны оставаться сторонними


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

Для управления внешними зависимостями используйте Git Submodule.

Не используйте git add вслепую




Если ваш проект успешно скомпилирован, не поддавайтесь желанию использовать команду git add. (где . это текущий каталог например). Это особенно важно, если вы не компилируете свой проект вручную, а используете IDE для управления своим проектом. Может быть чрезвычайно сложно отследить, что было добавлено в ваш репозиторий, когда вашим проектом управляет IDE. Поэтому важно добавлять только то, что вы сами создали и подготовили для добавления, а не какой-либо новый объект, который загадочным образом появился в папке вашего проекта.

Так что, прежде чем запускать git add, просмотрите, что будет добавлено в репозиторий. Если вы видите незнакомый объект, выясните, откуда он и почему он всё ещё находится в каталоге вашего проекта после выполнения команды make clean (или эквивалентной команды).

Используйте Git ignore




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

Файл gitignore даёт возможность отфильтровать лишнее. Github.com/github/gitignore предлагает несколько специально созданных шаблонов gitignore, которые вы можете загрузить и разместить в своём проекте. Gitlab.com, например, предлагал такие шаблоны ещё несколько лет назад.

Модерируйте изменения кодовой базы




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

Возьмите на себя ответственность


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



На правах рекламы


Эпичные серверы это виртуальные серверы на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрыми NVMe дисками Intel. Расходятся, как горячие пирожки!

Подробнее..

HackTheBox. Прохождение Forwardslash. LFI, backup и шифрованный том

04.07.2020 18:11:54 | Автор: admin

Продолжаю публикацию решений отправленных на дорешивание машин с площадки HackTheBox.

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

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ.

Организационная информация
Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.

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

Recon


Данная машина имеет IP адрес 10.10.10.183, который я добавляю в /etc/hosts.

10.10.10.183    forwardslash.htb

Первым делом сканируем открытые порты. Так как сканировать все порты nmapом долго, то я сначала сделаю это с помощью masscan. Мы сканируем все TCP и UDP порты с интерфейса tun0 со скоростью 500 пакетов в секунду.
masscan -e tun0 -p1-65535,U:1-65535 10.10.10.183    --rate=500



Теперь для получения более подробной информации о сервисах, которые работают на портах, запустим сканирование с опцией -А.
nmap -A forwardslash.htb -p22,80



На сервере работают служба SSH и веб-сервер. Заходим на веб-сервер, и смотрим, что нам могут предложить.



Так нам сообщают о взломе хоста, упоминают XML и FTP. Давайте переберем директории с помощью gobuster. В параметрах указываем количество потоков 128 (-t), URL (-u), словарь (-w) и расширения, которые нас интересуют (-x).
gobuster dir -t 128 -u http://forwardslash.htb/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x html,php,xml,txt



И находим note.txt. Давайте прочитаем.



Сообщается о группе, взломавшей сайт и о том, что есть бэкап. Давайте поищем поддомены. В качестве фильтра установим количество символов не равно 0.
wfuzz -H 'HOST:FUZZ.forwardslash.htb' -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u forwardslash.htb --hh 0



И на ходим поддомен backup. Добавим его в файл /etc/hosts.
10.10.10.183 backup.forwardslash.htb
Переберем директории и для этого домена.
gobuster dir -t 128 -u http://backup.forwardslash.htb/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x html,php,xml,txt



И переходим по данному адресу.

Entry Point


Нас встречает форма авторизации.



Также есть возможность регистрации. Давайте зарегистрируемся, а потом войдем.



Гуляя по ссылкам, находим формы смены имени, пароля, а также можно задать изображение профиля. Пожалуй остановимся на нем.



Сообщают, что в связи со взломом данная функция отключена. При этом поле ввода не доступно, скорее всего disabled в HTML.



Удаляем данное свойство у обоих элементов. Я запустил на локальной машине веб-сервер, и указал в поле ссылку на файл test.txt.



Так как не никаких фильтров, давайте попробуем вектор LFI. Для удобства делам это в Burp Suite.



И есть LFI!

USER


Давайте проверим конфигурации apache.



Но если попробовать прочитать файл php, то он не будет представлен вам как текст. Вместо этого он будет выполнен.



Но мы можем использовать php фильтры, к примеру base64. Так файл php сначала кодируется, а потом отображается на странице. Таким образом он не будет выполнен.
php://filter/convert.base64-encode/resource=../../../../var/www/backup.forwardslash.htb/index.php


Выделим нужный фрагмент и нажмем Ctrl+Shift+B.



Получаем декодированный код. Давайте этим способом прочитаем все найденные во время сканирования файлы. В файле config.php находим пароль для подключения к базе данных.



Давайте так же взглянем на /dev/index.php. И там находим аутентификационные данные пользователя chiv.



Данный пользователь есть в в системе, это мы узнаем из /etc/passwd. Попробуем эти данные для подключения по SSH.



USER2


Для сбора данных в системе используем скрипт LinPEAS. И находим в бэкапах какую-то записку.





Таким образом в бэкапах есть старый конфиг с паролем. Он принадлежит painу.



Так на программу backup стоит SUID бит. То есть мы можем выполнить программу от имени пользователя pain.



Мы можем сделать backup, но только определенного рандомного файла.



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



Теперь добавим создание ссылки и повторный бэкап.



Запустим из домашней директории пользователя и получим файл.



Сменим пользователя введя данный пароль.



ROOT


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



Таким образом, мы имеем шифрованный том. Чтобы расшифровать и монтировать его, нам нужен пароль.



Мы имеем шифртекст и программу.



Для дешифрования используем следующий код.
def decrypt(key, msg):key = list(key)msg = list(msg)for char_key in reversed(key):for i in reversed(range(len(msg))):if i == 0:tmp = ord(msg[i]) - (ord(char_key) + ord(msg[-1]))else:tmp = ord(msg[i]) - (ord(char_key) + ord(msg[i-1]))while tmp < 0:tmp += 256msg[i] = chr(tmp)return ''.join(msg)ciphertext = open('ciphertext', 'r').read().rstrip()for i in range(1, len(ciphertext)):for j in range(256):key = chr(j) * itext = decrypt(key, ciphertext)if ' the ' in text or ' to ' in text:print(key)print(text)exit()

И успешно дешифруем сообщение.



Посмотрим, что у нас по указанному пути.



Расшифруем том.



И примонтируем его.



Там расположен ключ SSH.



Подключаемся и забираем флаг.



Вы можете присоединиться к нам в Telegram. Там можно будет найти интересные материалы, слитые курсы, а также ПО. Давайте соберем сообщество, в котором будут люди, разбирающиеся во многих сферах ИТ, тогда мы всегда сможем помочь друг другу по любым вопросам ИТ и ИБ.
Подробнее..

Блокчейн и стандартные базы данных. А есть ли разница

04.07.2020 20:20:46 | Автор: admin
В этот раз хочется рассказать о том какие я вижу различия между блокчейном и обычными системами баз данных. Конечно не считаю что я нашел ответ, считайте это моими размышлениями

Сначала вспомним про блокчейн



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

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

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

Давайте попробуем сравнить



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

Скажем кое-какие организации хотят хранить свои данные так, как бы самостоятельно. Они заводят базу данных, любую и благополучно туда их вставляют.
Затем у них появляются партнеры, которые хотят клянчить немного оттуда и вставлять что-нибудь о своих клиентах, продукции и т.д. Тоже не вопрос мы же можем их синхронизировать, скажем, по REST, принцип транзакций прекрасно реализован в большинстве их движков, а принцип ключей (PK, UNIQUE) не позволяет вставить одно и тоже повторно и по-сути решает проблему двойной траты. И это все стандартные системы управления базами данных.

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

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

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

Кстати об открытости данных. Поскольку многие СУБД закрыты, то они не могут реализовать принципы доверия и это как бы намекает, что технология должна быть разделена и подходить для работы с любыми базами данных.

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

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

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

Григорий Бакунов об электронном голосовании

06.07.2020 02:17:13 | Автор: admin

Григорий Бакунов


Директор по распространению технологий Яндекса Григорий bobuk Бакунов в эфире Точки на Эхе Москвы поделился мнением о системе голосования, которая использовалась на выборах в городскую думу в 2019 году и на голосовании по вопросу изменения конституции в 2020. Получился любопытный разбор технических деталей для неспециалистов. На Хабре уже была хорошая публикация на эту тему.


Ниже приведена стенограмма эфира, который провёл Александр plushev Плющев. Его реплики выделены полужирным.


Я не делал этого сам, но я помог другому человеку поучаствовать в этом онлайн, поэтому весь процесс я всё-таки посмотрел, и теперь я его знаю.


То есть он голосовал не тайно? Была нарушена тайна голосования? Я прошу обратить на это внимание центризбирком.


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


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


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


Так, что ты имеешь в виду? Прежде всего?


Что это тот же самый, по большому счёту, блокчейн, который, на самом деле, довольно фиктивный. Что это процесс, в котором большая часть того, что относится к нашей безопасности, сделано, на самом деле, на совершенно фиктивном уровне. И очень жаль, что технических специалистов здесь никто не послушал. Я специально пошёл в интернет посмотреть, а были ли умные люди, которые до этого писали: Ребята, а вот как надо. И таких статей, которые рассказывают, как надо, как можно было сделать, чтобы технические специалисты во всё это поверили, очень много. Но, разумеется, это, по честному если, никому не нужно. Можно прямо разбор провести. Вот давайте с самого начала начнём. Смотрите, нам много раз в разных источниках говорили про то, что это блокчейн. А значит ничего подделать нельзя. Но это, на самом деле, чудовищный обман. В данном случае используется вообще-то хорошая, качественная реализация блокчейна. Этот блокчейн называется Exonum. Это довольно крутая разработка, очень качественная, в которую люди вложили много усилий, чтобы в ней действительно ничего нельзя было подделать. Если бы не одно но. Там такая структура, в которой есть узлы, которые записывают данные в блокчейн, а есть валидаторы. Такая система, которая каждый раз подтверждает, что то, что записано в блокчейн, записано верно. И там невероятно сложная конструкция, которая всё это валидирует. Она продумана так, что для того, чтобы убедить систему записать поддельные данные, или сказать, что какая-то часть данных поддельная, тебе нужно завладеть более, чем двумя третями плюс одним узлом. То есть если у тебя их десять, то тебе нужно, чтобы у тебя в этой системе было семь узлов, чтобы сказать, что запись, которая проведена в блокчейн, она неправильная. Но тут есть один тонкий момент. Я специально пошёл и специально проверил. Все валидаторы, на самом деле, принадлежат государству. Все до одного.


Поясни, что это значит. Чем это чревато?


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


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


Оно может подвергаться изменению в процессе. Как это выглядит. Вот смотрите, в чём идея блокчейна. В том, что в каждой последующей записи есть информация о предыдущих записях. Таким образом, если ты хочешь изменить какую-то запись, например, на пять от текущего момента назад, тебе придётся изменить не только её, но и пять последующих. Так вот в текущей ситуации с текущим блокчейном сделать это довольно легко, это несложная история. Мы об этом говорили ещё и во время московских выборов. С тех пор ничего глобально не поменялось, к сожалению. При этом, смотрите, в основе этого оригинального блокчейна, который называется Exonum, в нём была даже для этого предусмотрена специальная фишка, которая называлась Anchoring. Ну, как сказать, якорение. Идея была такая: раз в какое-то время записывать контрольную сумму, то есть записывать информацию о транзакциях, которые через этот блокчейн прошли, в другой блокчейн, не зависящий от этого. Например, в блокчейн биткойна. В систему, которая показательно независима, и поэтому ты там ничего поделать не можешь. Разумеется, эта фича была выключена, выпилена и никак не использовалась. В Exonum была отдельная такая сущность, которая называлась узлы аудита. Которые не могут ничего писать, но которые могут только проверять информацию. И которые можно было выдать, не знаю, мне, например, или тебе, чтобы ты был руководителем этого узла и мог смотреть, что там происходит. Но они тоже не были предоставлены. Не было классической истории про новый блокчейн, которая называется контроль развёртывания. Это такая практика, при которой, когда разворачивается новый блокчейн на серверах, туда пускаются специальные люди, которые контролируют, что в блокчейне на момент разворачивания нет никакой подделки, нет никаких непонятных действий внутри. Вы понимаете, сейчас единственное, что мы знаем про текущий блокчейн, это текущие транзакции, которые прямо сейчас по нему проходят. Но мы не знаем, не было ли туда доложено предварительно большое количество других транзакций. Мы ничего про это не знаем. Большое количество дополнительной информации Блин, прости, что я монологом говорю.


Давай-давай, интересно.


Я покопал большое количество дополнительной информации. И вот статья, которую ты мне скинул Спасибо тебе большое за неё, потому что я бы, конечно, сам не взялся, а так я просто проверил. Действительно, выяснилось, что довольно простым набором действий можно подтвердить, что голосование было устроено Вот как сейчас, смотрите. Вы заходите на сайт. Для простоты, mos.ru. Вы получаете там, грубо говоря, разрешение или бюллетень на голосование. Там генерируется особенная строчка в вашем собственном браузере, и после этого, внимание, эта строчка отправляется на сервер, который называется elec.moscow. Я пошёл специально посмотреть по адресам, где находятся эти замечательные сервера, которые называются elec.moscow. И там, внезапно, знаете, такие странные штуки: московский минздрав, штука, которая, вот я до сих пор не знаю, что такое Moscow District Council. Ты мне можешь сказать? Я не знаю.


Районный совет?


Ну, вероятно Я не знаю, что это такое. Тем не менее, это всё московские государственные организации. То есть когда нам говорили, что вот этот сайт голосования, который будет эту промежуточную страницу выдавать, он будет на независимых узлах Ну, вот настолько они независимые. То есть они принадлежат московскому правительству. Это те узлы, по которым смог пройти я. В чём здесь фокус. В том, что вы получаете действительно уникальный идентификатор, который вроде как mos.ru не знает. Но этот промежуточный сайт, который назвается elec.moscow, он его всё равно получает. И этого в принципе достаточно по времени для того, чтобы идентифицировать и связать вас как человека, пользующегося mos.ru...


Смотри, в результате ты выяснил уже две вещи: первая вещь, что голосование можно подменить, верно?


В процессе его можно подмешивать, да. И изменять, как тебе хочется, всё так.


И второе, что его можно проконтролировать.


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


У главного редактора, ты имеешь в виду.


У главного редактора, прости пожалуйста, а почему я сказал у генерального директора?


Не знаю.


Наверное, заволновался. Ну, ты понял меня.


Да.


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


Подожди, что за сайт ты имеешь в виду?


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


Ты имеешь в виду constitution.observer?


Да-да. Что-то такое там было. Я, к сожалению, не очень запоминаю...


Нет, боюсь, не то. Я, правда, не знал даже о таком.


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


Да-да-да, есть такое дело.


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


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


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


Да, но ты говоришь, что возможность того, чтобы эти фальсификации были, оставлена.


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


Понятно. Слушай, ещё хотел несколько штук Для меня очень комичная ситуация, что сайт, который нам очень долго рекламировали, 2020og.ru, вот он упал утром первого дня голосования и до сих пор, главное, не вставал. Там, по сути, есть информационный сайт, и есть на его поддомене сайт, на котором проходит голосование. Вот информационный сайт упал и лежит. И не встаёт. То есть формально, если бы это было единственное место, где можно узнать о поправках в конституцию, то вы бы больше нигде не узнали, потому что всё, он лежит. Что они сделали. Они просто сделали переадресацию на голосование. Если вы заходите на 2020og.ru, то вы уходите на голосование. И вам говорят, можете вы проголосовать или нет. Всё. Всё остальное закончилось. Это ЦИКовский проект, это уже не ДИТ, это ЦИК делал, центризбирком России. И вот, видимо, это из того же ряда, о котором говорил Григорий Бакунов, насчёт высочайшей квалификации, с которой всё это сделано. Ну, потому что, что тут можно сказать. Это что, не рассчитали нагрузку и поняли, что даже если его поднимут, то лучше и не надо? Или что, объясни.


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


Отчёты это то, что ты можешь скачать оттуда?


Да. Когда оно просто не формировалось. То есть, нет, не так, вру. Оно формировалось. Видимость того, что отчёты есть, была. Просто отчёты были нулевой длины.


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


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


Ты про начальника управления смарт-проектов правительства Москвы Артёма Костырко?


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


Понятно. Я хочу скзать, что Артёма Костырко мы звали сегодня. Мы подумали, что хватит уже с Ильёй Массухом при всём уважении говорить. До голосования поговорили, а теперь, когда система заработала, мы хотели бы поговорить с Артёмом Костырко. Но он не смог посетить сегодня нашу программу, в том числе и удалённо. Так что, может быть, вы опосредованно услышите его либо в других наших передачах, либо в других средствах массовой информации.


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


Кто-то один из нас издевается над московскими властями.


Ты знаешь, удивительно, что это сегодня не ты, да? Но просто у меня подпригорает Простите, подгорает. Я не знаю У меня довольно тёплое сидение сейчас, на котором я сижу, потому что, ну, действительно, я не ожидал, что всё настолько плохо.

Подробнее..

Персональные данные, права субъектов ПД

06.07.2020 14:13:22 | Автор: admin
image

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

Что такое персональные данные?

Итак, начнем с самого простого, что же такое персональные данные? Согласно определению, приводимому в ст. 3 ФЗ-152 О персональных данных это: любая информация, относящаяся прямо или косвенно к определенному или определяемому физическому лицу. Другими словами это ФИО, номер телефона, электронная почта, паспортные данные, фотография и т.д. С этого момента уже начинаются вопросы, например, может ли ФИО считаться Персональными данными? Для ответа на этот вопрос обратимся к разъяснениям Роскомнадзора, в данном случае именно это ведомство выступает Регулятором.

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


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

ФЗ-152 О персональных данных

Основной документ, который регулирует отношения в сфере персональных был принят, еще в 2006 году и называется Федеральный закон О персональных данных. В него уже не раз вносились правки, но сейчас хотелось бы упомянуть о проекте нового КОАП, в данный момемнт активно обсуждается новый Кодекс административных правонарушений. В проект добавлена новая статья, которая предусматривает штрафы до 500 т.р. за утечку персональных данных. Раньше такой статьи не было, но не будем забегать вперед.

Сосредоточим внимание на 3-й Главе вышеупомянутого закона она так и называется Права субъекта персональных данных. И начнем со статьи 14. И первое на что имеет право субъект персональных данных доступ к своим персональным данным. Другими словами Вы можете в любой момент отправить любому оператору (не важно является ли он Государственным органом или нет) запрос на предоставление сведений касающихся Ваших ПД, и оператор обязан предоставить такую информацию. Сроки обработки такого запроса могут быть разными, но не превышать 30 дней. Например, если вы обнаружили в сети интернет, данные о себе, которые не соответствуют действительности, то владелец такого ресурса должен в срок не более 7-ми дней с момента получения Вашего запроса внести необходимые корректировки или вовсе удалить их.
Данный момент закреплен в статье 20 Федерального закона О персональных данных.

Как сформировать запрос оператору персональных данных?

При формировании такого запроса нужно соблюсти ряд требований, но они не очень сложны. Такой запрос должен содержать паспортные данные субъекта (Номер паспорта, дату выдачи, кем и когда он был выдан). Помимо этого Вы должны приложить подтверждение того, что оператор ведет обработку Ваших данных, это может быть номер и дата договора, скриншот или любые подтверждающие факт обработки сведения. Допускается даже словесное обозначение, т.е. просто описание того факта, что обработка Ваших персональных данных ведется конкретным оператором. Ну и конечно потребуется поставить подпись.
Допускается направлять запрос и в форме электронного документа, но в таком случае он должен быть подписан электронной подписью.

Если оператор предоставил Вам запрашиваемые сведения, то Вы имеете право запросить их повторно, но не ранее чем через 30 дней. Отсчет ведется с даты направления предыдущего запроса.

Если же оператор предоставил Вам не все сведения, которые Вы запрашивали, то ждать 30 дней не обязательно, в таком случае формировать повторный запрос можно сразу же. Но не забудьте обосновать свое обращение.

image

Какие сведения имеет право запросить субъект персональных данных?

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

  • 1) подтверждение факта обработки персональных данных оператором;
  • 2) правовые основания и цели обработки персональных данных;

Правовыми основаниями могут выступать договор, устав, лицензия или норма закона, в памятке операторам РКН приводит следующий пример:

ст. 86-90 Трудового кодекса РФ; ст. 53, ч. 2 ст. 54 Федерального закона от 07.07.2003г. 126-ФЗ О связи; п. 4.5 Лицензии _____от______ ., выдана ООО _________ Федеральной службой по надзору в сфере связи на осуществление деятельности по оказанию услуг связи; п.1 Устава ООО _________, утверждённого на общем собрании акционеров 01.01.0000г., протокол 1.

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

Цели оператор определяет заранее, при подаче заявления в Роскомнадзор, подробнее про определение целей и подготовке уведомления в Роскомнадзор можно прочитать в этой статье.


  • 3) цели и применяемые оператором способы обработки персональных данных;

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

  • 4) наименование и место нахождения оператора, сведения о лицах (за исключением работников оператора), которые имеют доступ к персональным данным или которым могут быть раскрыты персональные данные на основании договора с оператором или на основании федерального закона;
  • 5) обрабатываемые персональные данные, относящиеся к соответствующему субъекту персональных данных, источник их получения, если иной порядок представления таких данных не предусмотрен федеральным законом;
  • 6) сроки обработки персональных данных, в том числе сроки их хранения;
  • 7) порядок осуществления субъектом персональных данных прав, предусмотренных Федеральным законом О персональных данных;
  • 8) информацию об осуществленной или о предполагаемой трансграничной передаче данных;

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

  • 9) наименование или фамилию, имя, отчество и адрес лица, осуществляющего обработку персональных данных по поручению оператора, если обработка поручена или будет поручена такому лицу;
  • 10) иные сведения, предусмотренные настоящим Федеральным законом или другими федеральными законами.


Когда могут отказать в доступе к персональным данным?

Несомненно каждый человек имеет право запросить у оператора сведения об обработке собственных персональных данных. Но есть и ряд исключений, когда оператор может отказать. Как правило все эти случаи связаны с работой силовых ведомств. Это может быть оперативно-розыскная или разведывательная и контрразведывательная деятельность. Доступ к ПД может быть ограничен, если в отношении субъекта возбуждено уголовное дело или если обработка персональных данных осуществляется в соответствии с законодательством о противодействии легализации( отмыванию) доходов, полученных преступным путем.
Ограничение доступа может возникнуть, если нарушаются права и законные интересы третьих лиц.

СПАМ, персональные данные и закон о рекламе

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

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

В ст. 15 ФЗ-152 говориться, что обработка персональных данных в целях продвижения товаров, работ и услуг при помощи средств связи может осуществляться только при условии согласия физического лица. Очень интересный момент заключается в том, что в случаях рекламы собственных работ и услуг, компания должна доказать, что такое согласие было получено.
В случае, если Вы все таки дали оператору такое согласие( путем проставления галочки в чек-боксе на сайте или заключая с ним договор), то в любой момент можете его отозвать. Для этого достаточно написать обращение в компанию, которая забрасывает Вас письмами и оператор обязан немедленно прекратить обработку Ваших персональных данных для целей носящих рекламный характер.
Более того, если сообщения Вы получаете на электронную почту, в письме должна быть ссылка для автоматического отказа и исключения Ваших контактов из рекламной рассылки.
image

Что же такое реклама, обратимся к определению информация, распространяемая любым способом и адресованная неопределенному кругу лиц направленная на привлечение внимания к объекту рекламирования, формирование или поддержание интереса к нему и его продвижению на рынке

Как и в ситуации с законом О персональных данных в законе О рекламе, в главе 2, ст. 18 написано, что распространение рекламы по сетям электросвязи допускается только при условии, что абонент дал на это предварительное согласие. Так же рекламодатель обязан доказать наличие такого согласия, как и в случае с требованиями 152-ФЗ. Требования законов сходятся и части того, что рекламораспостранитель обязан немедленно прекратить процесс распространения рекламы получив соответствующее требование от физического лица.

Если регулятором в области персональных данных выступает Роскомнадзор, то в случае закона О рекламе это Федеральная Антимонопольная Служба (ФАС). Требования к оформлению жалобы, размещены на сайте регулятора. Выполнить их достаточно просто, во многом механизм подачи схож с требованиями к подачи обращения в РКН, нужно указать:

  • ФИО заявителя и его место жительства
  • Наименование рекламодателя

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

  • Требования заявителя

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

ПО результатам обращения ФАС может инициировать проверку. Результатом которой, вполне возможно, окажется штраф рекламораспространителю. Сумма штрафа в данном случае довольно существенная. Размер штрафов регламентирует ст. 14.3. КОАП РФ и достигать они могут 500 000р.
image
Пример из жизни, Сбербанк опять не на высоте

В качестве примера разберем случай произошедший с ПАО Сбербанк в 2018г. Суть данного судебного разбирательства состоит в том, что ПАО Сбербанк заключил с одним из своих клиентов договор на выпуск международной карты. При этом договор присоединения был составлен таким образом, что подразумевал отправку сообщений рекламного характера. Клиент не мог получить необходимую ему карту и при этом отказаться от навязанной банком услуги. В данной ситуации потребитель банковской услуги не растерялся и отозвал ранее данное согласие.
Когда же он получил очередную рассылку с рекламой услуг банка он обратился в Федеральную антимонопольную службу.
Не смотря на ряд доводов представителей банка, суд постановил Сбербанк выплатить штраф в размере 250 000р. В соответствии с ч.1 ст. 14.3. КОАП РФ.

Самое важное в одном абзаце

Физические лица достаточно хорошо защищены законодательством, в частности ФЗ-152 О персональных данных. Имеют право на доступ, изменение и уничтожение своей личной информации. В любой момент могут отозвать данное ранее согласие на обработку персональных данных. Имеют выигрышную позицию по отношению к оператору, который в свою очередь, должен доказывать, что получил вышеуказанное согласие. И как сказано в ст. 17 закона О персональных данных: Субъект имеет право на защиту своих прав и законных интересов, в том числе на возмещение убытков и компенсацию морального вреда в судебном порядке
Подробнее..

Безопасность мобильных устройств и приложений пять популярных сценариев атак и способы защиты

06.07.2020 16:22:04 | Автор: admin


Изображение: Unsplash

Современные мобильные устройства очень сложны, и это дает злоумышленникам возможности для проведения атак. Для взлома вашего смартфона может быть использовано буквально все от Wi-Fi и Bluetooth до динамика и микрофона.

Аналитики Positive Technologies опубликовали исследование распространенных сценариев атак на мобильные устройства и приложения. В
нашей статье главные тезисы этого документа.

Как атакуют мобильные устройства и приложения



Существует пять основных сценариев атаки. Среди них:

  • Физический доступ. Если телефон был украден или потерян, владелец отдал его в сервис или подключил к поддельному зарядному устройству по USB все это открывает возможность для атаки.
  • Вредоносное приложение на устройстве. Иногда такие приложения могут попасть на устройство даже из официальных источников, Google Play и App Store (для Android, для iOS).
  • Атакующий в канале связи. Подключившись к недоверенному Wi-Fi, прокси-серверу или VPN, мы становимся уязвимыми для атак в канале связи.
  • Удаленные атаки. Атакующий может действовать при этом удаленно, пользуясь серверами мобильных приложений или иными службами для доставки эксплойта.
  • Атаки на серверную часть. Отдельно от всего можно рассмотреть атаки на серверную часть мобильных приложений, поскольку в этом случае доступ к устройству злоумышленнику не требуется.

Поговорим подробнее о каждом из вариантов и обсудим возможные способы защиты от таких атак.

Атаки с физическим доступом


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

Зарядная станция, к которой вы подключаете свой смартфон по USB, вполне может оказаться не совсем безопасной. Для современных версий ОС Android и iOS при подключении с смартфона к ПК по USB требуется разрешение на доступ к устройству. Однако на Android 4.0 и ниже этого не требовалось. В итоге при подключении таких устройств к скомпрометированным или установленным хакерами зарядным станциям, открывается возможность для атаки. Ее сценарий может выглядеть так:

  • На вашем смартфоне с версией Android 4.0 или ниже доступна отладка по USB.
  • Вы подключаетесь к зарядной станции по USB-кабелю.
  • Вредоносная зарядная станция выполняет команду adb install malware.apk, чтобы установить вредонос на ваше устройство.
  • Вредоносная зарядная станция выполняет команду adb am start com.malware.app/.MainActivity для запуска этого вредоносного приложения.
  • Запущенный троян пробует различные техники повышения привилегий, получает права root и закрепляется в системе. Теперь ему доступны все хранимые данные, включая аутентификационные (логины, пароли, токены) от всех установленных приложений, а также неограниченный доступ к любому приложению во время исполнения.

Как защититься


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

Атаки с помощью вредоносных приложений


Есть несколько источников таких приложений:

  • Официальные магазины приложений Google Play и App Store. Редко, но даже в официальных маркетах можно найти вредоносное приложение, которое может нанести ущерб вам и вашим данным. Часто такие приложения стараются заполучить побольше установок с помощью кликбейтных названий типа Super Battery, Turbo Browser или Virus Cleaner 2019.
  • Неофициальные сайты и магазины приложений (third-party appstore). Для Android-устройств достаточно разрешить установку из недоверенных источников, а затем скачать apk-файл приложения с сайта. Для iOS-устройств достаточно перейти по ссылке в браузере Safari, подтвердить установку сертификата на устройство, после чего любое приложение в этом неофициальном магазине станет доступно для установки прямо из браузера.
  • Пользователь может установить скачанное из интернета приложение с помощью USB-подключения.
  • Для Android-устройств доступна возможность загрузки части приложения при переходе по ссылке механизм Google Play Instant.

При установке на смартфон в зависимости от полученных разрешений вредоносные приложения будут иметь доступ к некоторым хранимым данным, микрофону, камере, геопозиции, контактам и т. п. Также они получат возможность взаимодействия с другими установленными приложениями через механизмы межпроцессного взаимодействия (IPC/XPC). Если установленные приложения содержат уязвимости, которые можно проэксплуатировать через такое взаимодействие, вредоносное приложение сможет этим воспользоваться. Особенно актуально это для Android-устройств.

Помимо этого, вредоносное приложение может попытаться получить повышенные привилегии в системе, проэксплуатировав уязвимости, позволяющие получить root-права или jailbreak.

Как защититься


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

Атаки в канале связи


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

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

Даже если проверка сертификатов происходит корректно, у злоумышленника остается лазейка: под неким предлогом вынудить жертву установить на свое устройство сертификат злоумышленника как доверенный. Кроме того, если приложение само по себе безопасно работает с сервером, но содержит ссылки на сторонние ресурсы, загружаемые по HTTP, это все равно составляет возможность для проведения фишинговых атак.

Если злоумышленнику удастся получить контроль над трафиком между клиентским приложением и сервером, то это даст ему целый ряд возможностей:

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

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

Как защититься


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

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

Удаленные атаки


Некоторые уязвимости в мобильных приложениях можно проэксплуатировать удаленно, и для этого даже не требуется контролировать передачу данных между приложением и сервером. Многие приложения реализуют функциональность по обработке специальных ссылок, например myapp://. Такие ссылки называются deeplinks, и работают они как на Android, так и на iOS. Переход по такой ссылке в браузере, почтовом приложении или мессенджере может спровоцировать открытие того приложения, которое умеет такие ссылки обрабатывать. Вся ссылка целиком, включая параметры, будет передана приложению-обработчику. Если обработчик ссылки содержит уязвимости, то для их эксплуатации будет достаточно вынудить жертву перейти по вредоносной ссылке.

Аналогичный образом в мобильных устройствах могут обрабатываться более привычные ссылки http:// и https:// они могут быть переданы приложению вместо браузера, в некоторых случаях это может происходить без подтверждения со стороны пользователя.

Для Android-устройств переход по ссылке может спровоцировать загрузку Instant App, что делает возможным удаленную эксплуатацию уязвимостей, связанных с установкой вредоносного приложения.

Как защититься


Своевременная установка обновлений приложений и ОС в данном случае единственный способ защититься. Если у вас нет возможности установить обновление или оно еще не вышло, можно временно прекратить использование уязвимого приложения: удалить его с устройства или просто разлогиниться.

Атаки на серверную часть


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

Зачастую устройство серверной части мобильного приложения ничем не отличается от веб-приложения. Как правило, устроены серверы мобильных приложений еще проще и часто представляют из себя json- или xml-api, редко работают с HTML-разметкой и JavaScript, как это часто делают веб-сайты.

Если сравнивать уязвимости веб-приложений и серверных частей мобильных приложений, то мы видим, что следующие уязвимости преобладают в мобильных приложениях:

  • недостаточная защита от подбора учетных данных: 24% веб-приложений и 58% серверов мобильных приложений содержат такие уязвимости,
  • ошибки бизнес-логики: 2% веб-приложений и 33% серверов мобильных приложений.

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

Как защититься


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

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

Хорошей рекомендацией для разработчиков будет внедрение практики безопасной разработки (security development lifecycle, SDL) и регулярный анализ защищенности приложения. Такие меры не только помогут своевременно выявить потенциальные угрозы, но и повысят уровень знаний разработчиков в вопросах безопасности, что повысит уровень защищенности разрабатываемых приложений в долгосрочной перспективе.

Автор: Николай Анисеня, руководитель группы исследований безопасности мобильных приложений Positive Technologies
Подробнее..

5 стадий неизбежности принятия ISOIEC 27001 сертификации. Торг

06.07.2020 22:14:15 | Автор: admin
Третья стадия эмоционального реагирования на изменения торг. Разобравшись со своим гневом и эмоциональной составляющей, мы начали думать о том, что реально нужно сделать для того, что у нас всё заработало. Настало время изучить стандарт более детально, применить его к нашей текущей ситуации и адаптировать его требования под нашу компанию. Здесь важно было при соблюдении требований стандарта обойтись малой кровью. Любые изменения должны были быть адекватными то есть соизмеримыми с соответствующим риском. Затраты на защиту не должны были превышать возможный ущерб от реализации риска.

image

На этом пути нам пришлось решить множество вопросов, с которыми мы никогда не сталкивались ранее:

Выбор средства для работы над библиотекой политик


Первый (казалось бы, очень простой) вопрос, с которым мы столкнулись где создавать и как хранить все необходимые документы системы менеджмента информационной безопасности? Для нас было крайне важно сохранять версионность документов и иметь возможность откатить версию политики на несколько редакций назад. Изучив предложения на рынке, мы остановились на вики-системе Confluence и используем её по сей день.

В качестве системы версионирования (контроля версий) мы могли использовать git, но для удобства пользователей мы выбрали портальное решение (Confluence). Мы сумели ограничиться бесплатной версией (до 10 авторизованных пользователей): больше нам и не понадобилось, так как неавторизованные могли просматривать библиотеку.

Подготовка плана внедрения


Здесь мы не стали применять какие-то креативные методики просто запросили у нашего консультанта перечень необходимых политик, назначили ответственных за их написание и согласование, проставили ключевые даты и оформили это всё в виде диаграммы Ганта (которая также была подгружена в Confluence).

Оценка рисков компании


Очевидно, что для выбора средств защиты нам нужно было оценить риски (чтобы тратить ресурсы только туда, где это реально нужно). Для этого мы создали перечень активов компании, которые мы планируем защищать в него входили как физические активы (рабочие станции, сервера, бумажные документы и т.д.), так и нематериальные (клиентская информация в электронном виде, пароли и т.д.).

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

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

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

2. Отсутствие резервных вычислительных мощностей
Данная проблема требовала больших финансовых и человеческих ресурсов, поэтому оставлять ее на конец было неправильно. Мы подобрали площадку для резервирования наших основных сервисов: на первоначальном этапе мы пользовались IaaS (инфраструктура как сервис), которая позволила нам быстро и бюджетно настроить резерв основных сервисов компании; в дальнейшем мы закупили дополнительное оборудование и настроили резерв в отдельном ЦОДе (co-location). Впоследствии мы отказались от облачного решения в пользу ЦОДа ввиду большого объема данных.

3. Контроль за супер-пользователями, а также за теми, кто работает с особой, чувствительной информацией
Другими словами, нам необходимо было установить контроль за пользователями, которые имеют обширный доступ к конфиденциальной информации. Эту проблемы мы решили с помощью DLP системы. Мы выбрали отечественное ПО StaffCop благодаря приемлемой цене и хорошей технической поддержке.

Написание политик


Здесь мы подключили все возможные ресурсы:
использовали политики других компаний, которые нашли в открытом доступе;
запросили примеры политик у нашего консультанта по внедрению;
сочиняли тексты политик самостоятельно, основываясь на требованиях стандарта.
В итоге лучше всего сработал именно третий (самый сложный путь). Это было довольно долго, но зато на выходе мы получили хорошо составленные именно для нашей компании документы. Так на выходе у нас получилось 36 основных политик Системы Менеджмента Информационной Безопасности.

Распределение ролей


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

Абсолютно у всех сотрудников была как минимум одна роль пользователь.

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

Вовлечение коллег


К оценке рисков и описанию требований заинтересованных сторон помимо менеджера проекта и Руководителя отдела ИТ/ИБ был привлечен Операционный директор компании. Потребовалось существенное вовлечение и Руководителя отдела HR ей требовалось описать в политике полный жизненный цикл сотрудника: от заявки на вакансию до периода после его увольнения. К счастью, все коллеги понимали важность сертификации и шли нам навстречу.

Технические аспекты


В процессе подготовки мы поняли, что для выполнения требований стандарта нам потребуется как минимум следующее:
Перенести сервера во внешний дата-центр;
Оборудовать все офисы СКУД (система контроля и управления доступом).
В дальнейшем к этим двум пунктам добавилось множество других вещей: внедрение DLP-системы, запуск резервного дата-центра, введение двухфакторной авторизации и т.д.

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

В предыдущих материалах:

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Отрицание: заблуждения о сертификации ISO 27001:2013, целесообразность получения сертификата/
5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Гнев: С чего начать? Исходные данные. Затраты. Выбор провайдера.
Подробнее..

(Без)умные устройства топ-10 уязвимостей IoT от OWASP

07.07.2020 06:22:58 | Автор: admin

Не секрет, что реализация механизмов безопасности IoT-устройств далека от совершенства. Известные категории уязвимостей умных устройств хорошо описаны в Top IoT Vulnerabilities от 2018 года. Предыдущая версия документа от 2014 года претерпела немало изменений: некоторые пункты исчезли совсем, другие были обновлены, появились и новые.


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


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



За подробностями следуйте под кат.


I1 Слабые, предсказуемые и жестко закодированные пароли


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


Тип устройства Название CWE Недостаток безопасности
Routers Netgear CWE-601: URL Redirection to Untrusted Site ('Open Redirect') Кто угодно из сети может воспользоваться путаницей в конфигурации, чтобы получить контроль над устройством, изменять настройки DNS и перенаправлять браузер на зараженные сайты.
Loxone Smart Home CWE-261: Weak Encoding for Password Злоумышленник может получить доступ к паролям пользователей, а следовательно, и к их аккаунтам.
AGFEO smart home ES 5xx/6xx CWE-261: Weak Encoding for Password Злоумышленник может получить доступ к паролям пользователей, а следовательно, и к их аккаунтам.
Industrial wireless access point Moxa AP CWE-260: Password in Configuration File Злоумышленник может войти с парой логин-пароль от учетной записи администратора, указанной в инструкции, и получить доступ к управлению всей системой.
Heatmiser Thermostat CWE-260: Password in Configuration File Злоумышленник может войти с парой логин-пароль от учетной записи администратора, указанной в инструкции, и получить доступ к управлению всей системой.
Digital video recorder Mvpower CWE-521: Weak Password Requirements Учетная запись администратора не требует пароль при входе, поэтому доступ к ней может получить кто угодно.
DBPOWER U818A WIFI quadcopter drone CWE-276: Incorrect Default Permissions Злоумышленник может получить доступ к файловой системе, используя возможность анонимного доступа без пароля.
Nuuo NVR (network video recorder) and Netgear CWE-259: Use of Hard-coded Password Злоумышленник может получить привилегии администратора, а значит, и полный контроль над системой из-за жестко закодированного пароля.
Vacuum Cleaner LG CWE-287: Improper Authentication Злоумышленник может обойти аутентификацию и получить доступ к видеозаписям с устройства.
Eminent EM6220 Camera CWE-312: Cleartext Storage of Sensitive Information В инструкции указан пароль 123456, который большинство пользователей установят не задумываясь и сделают свое устройство уязвимым.
LIXIL Satis Toilet CWE-259: Use of Hard-coded Password Пароль для подключения устройства по Bluetooth хранится в открытом виде в коде, что дает злоумышленнику возможность управлять работой умного унитаза по собственному желанию и против воли владельца.
FUEL Drill CWE-259: Use of Hard-coded Password Злоумышленник может найти жестко закодированный пароль и получить права администратора и управлять устройством.
Billion Router 7700NR4 CWE-798: Use of Hard-coded Credentials Жестко закодированные учетные данные дают злоумышленнику возможность получить полный контроль над устройством.
Canon Printers CWE-269: Improper Privilege Management & CWE-295: Improper Certificate Validation Злоумышленник может получить доступ к незащищенному устройству и обновить прошивку, потому что логин и пароль не требуются для доступа к устройству.
Parrot AR.Drone 2.0 CWE-285: Improper Authorization Пустая пара логин-пароль дает возможность злоумышленнику подключиться к дрону и управлять им.
Camera Amazon Ring CWE-285: Improper Authorization Злоумышленник может использовать для авторизации учетные данные по умолчанию.

I2 Небезопасные сетевые подключения


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


Тип устройства Название CWE Недостаток безопасности
Smart Massager CWE-284: Improper Access Control Злоумышленник может изменить параметры массажера и причинить пользователю боль, вызвать ожог кожи и нанести вред здоровью.
Implantable Cardiac Device CWE-284: Improper Access Control Злоумышленник может изменить настройки имплантируемого устройства, что может увеличить расход батареи и/или нанести вред здоровью.
Hikvision Wi-Fi IP Camera CWE-284: Improper Access Control Злоумышленник может удаленно управлять камерой и даже отключить ее.
Foscam C1 Indoor HD Cameras CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') Удаленное исполнение кода на камерах может привести к утечке чувствительной пользовательской информации.
Toy Furby CWE-284: Improper Access Control Злоумышленник может внести изменения в прошивку и использовать Ферби для слежки за детьми.
Toy My Friend Cayla CWE-284: Improper Access Control Злоумышленник может следить за пользователями и собирать информацию о них.
iSmartAlarm CWE-20: Improper Input Validation Злоумышленник может "заморозить" будильник, и он перестанет будить.
iSPY Camera Tank CWE-284: Improper Access Control Злоумышленник может залогиниться на устройстве как анонимный пользователь и заполучить контроль над файловой системой устройства.
DblTek GoIP CWE-598: Information Exposure Through Query Strings in GET Request Злоумышленник может отправить команды для изменения конфигурации или выключить устройство.
Nuuo NVR (network video recorder) and Netgear CWE-259: Use of Hard-coded Password Злоумышленник может получить привилегии администратора, изменять настройки устройства и даже следить за пользователями.
Sony IPELA Engine IP Cameras CWE-287: Improper Authentication Злоумышленник может использовать камеру для отправки фото и видео, добавить камеру в ботнет Mirai или следить за пользователями.
iSmartAlarm CWE-295: Improper Certificate Validation Злоумышленник может получить пароль или другие пользовательские данные с помощью поддельного SSL-сертификата.
Routers Dlink 850L CWE-798: Use of Hard-coded Credentials Из-за небезопасного сетевого подключения злоумышленник может получить полный контроль над устройством.
Amazons Ring Video Doorbell CWE-419: Unprotected Primary Channel Учетные данные для подключения к устройству передаются по незащищенному каналу связи.
Cacagoo IP camera CWE-287: Improper Authentication Злоумышленник может воспользоваться возможностью неавторизованного доступа к устройству, а затем управлять им.
Trifo Ironpie M6 Vacuum cleaner CWE-284: Improper Access Control Злоумышленник может удаленно подключиться к устройству и управлять им.

I3 Небезопасные интерфейсы экосистем


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


Тип устройства Название CWE Недостаток безопасности
Industrial wireless access point Moxa AP CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Злоумышленник может получить доступ к сессии, которая никогда не истечет.
AXIS cameras CWE-20: Improper Input Validation Злоумышленник может изменить любой файл в системе, получив права администратора.
Belkins smart home products CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') & CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Злоумышленник может получить достук к телефону и чувствительной информации.
Routers D-Link DIR-300 CWE-352: Cross-Site Request Forgery (CSRF) Злоумышленник может изменить пароль от учетной записи администратора и получить его привилегии.
AVTECH IP Camera, NVR, DVR CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Злоумышленник может изменять настройки устройства через атаку CSRF (например, пароли пользователей).
AGFEO smart home ES 5xx/6xx CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Злоумышленник может получить доступ ко всем файлам, хранящимся в системе. Он может изменить конфигурацию устройства и установить нелегитимное обновление.
Loxone Smart Home CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Все функции устройства могут контролироваться злоумышленником через команды веб-интерфейса.
Switch TP-Link TL-SG108E CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Злоумышленник может реализовать XSS-атаку на устройство и "заставить" администратора выполнить Javascript-код в браузере.
Hanbanggaoke IP Camera CWE-650: Trusting HTTP Permission Methods on the Server Side Злоумышленник может изменить пароль администратора и получить его привилегии.
iSmartAlarm CWE-287: Improper Authentication Злоумышленник может отправлять команды на устройство, включать и выключать его.
Western Digital My Cloud CWE-287: Improper Authentication Злоумышленник может получить полный контроль над устройством.
In-Flight Entertainment Systems CWE-287: Improper Authentication Злоумышленник может контролировать средства информирования пассажиров. Например, может подделать данные о полете (высота, скорость и пр.).
Smart key KeyWe CWE-327: Use of a Broken or Risky Cryptographic Algorithm Злоумышленник может узнать закрытый ключ, чтобы открыть дверь.

I4 Отсутствие безопасного механизма обновлений


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


Тип устройства Название CWE Недостаток безопасности
Devices by GeoVision CWE-295: Improper Certificate Validation Злоумышленник может обновить прошивку устройства без авторизации.
Canon Printers CWE-295: Improper Certificate Validation Механизм аутентификации отсутствует: кто угодно может получить доступ к устройству и обновить/изменить прошивку.
Smart Nest Thermostat CWE-940: Improper Verification of Source of a Communication Channel Прошивка доставляется на устройство по незащищенному протоколу передачи данных, и нет возможности проверить ее легитимность.

I5 Использование небезопасных или устаревших компонентов


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


Тип устройства Название CWE Недостаток безопасности
Amazon Echo CWE-1233: Improper Hardware Lock Protection for Security Sensitive Control Злоумышленник при помощи паяльника может изменить конфигурацию колонки, и превратить ее в устройство для прослушки.
Light bulb CWE-1233: Improper Hardware Lock Protection for Security Sensitive Controls Злоумышленник может перепаять элементы лампы.

I6 Недостаточная защита приватности


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


Тип устройства Название CWE Недостаток безопасности
Gator 2 smartwatch CWE-359: Exposure of Private Information ('Privacy Violation') Злоумышленник может получить доступ к информации о версии прошивки, IMEI, времени, методе определения локации (GPS/Wi-Fi), координатах и уровне заряда батареи.
Routers D-Link DIR-600 and DIR-300 CWE-200: Information Exposure Злоумышленник может получить доступ к чувствительной информации об устройстве или сделать его частью ботнета.
Samsung Smart TV CWE-200: Information Exposure Злоумышленник может получить доступ к бинарным файлам или аудиозаписям, хранящимся в системе телевизора.
Home security camera CWE-359: Exposure of Private Information ('Privacy Violation') Фотографии пользователя могут быть украдены злоумышленником и опубликованы в сети.
Smart sex toys We-Vibe CWE-359: Exposure of Private Information ('Privacy Violation') Злоумышленник может получить информацию о температуре устройства и интенсивности его вибрации.
iBaby M6 baby monitor CWE-359: Exposure of Private Information ('Privacy Violation') Злоумышленник может просмотреть информацию, включая детали видеозаписи.

I7 Небезопасная передача и хранение данных


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


Тип устройства Название CWE Недостаток безопасности
Owlet Wi-Fi baby heart monitor CWE-201: Information Exposure Through Sent Data Злоумышленник может следить за детьми и родителями через камеру.
Samsung fridge CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle') Злоумышленник может заполучить учетные данные от Google-аккаунтов жертв.
Volkswagen car CWE CATEGORY: Cryptographic Issues Злоумышленник может получить удаленный доступ к управлению машиной.
HS-110 Smart Plug CWE-201: Information Exposure Through Sent Data Злоумышленник может контролировать работу вилки, например, выключить подсветку.
Loxone Smart Home CWE-201: Information Exposure Through Sent Data Злоумышленник может контролировать каждое устройство, работающее в системе умного дома, и получить права доступа пользователя.
Samsung Smart TV CWE-200: Information Exposure Злоумышленник может прослушивать беспроводную сеть и инициировать атаку брутфорсом, чтобы восстановить ключ и дешифровать трафик.
Routers Dlink 850L CWE-319: Cleartext Transmission of Sensitive Information Злоумышленник может удаленно контролировать устройство.
Skaterboards Boosted, Revo, E-Go CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle') Злоумышленник может отправлять различные команды, чтобы управлять скейтом.
LIFX smart LED light bulbs CWE-327: Use of a Broken or Risky Cryptographic Algorithm Злоумышленник может перехватывать и дешифровать трафик, включая данные о конфигурации сети.
Stuffed toys CWE-521: Weak Password Requirements Аудиозаписи пользователей хранятся так, что доступ к ним может получить злоумышленник.
IoT Smart Deadbolt CWE-922: Insecure Storage of Sensitive Information Злоумышленник может получить доступ к чувствительной информации, хранящейся на устройстве.
Router ASUS CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Злоумышленник может получить доступ к чувствительной пользовательской информации.

I8 Отсутствие возможности настройки устройства


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


Тип устройства Название CWE Недостаток безопасности
TP-LINK IP Surveillance Camera CWE-? (не удалось подобрать CWE) Злоумышленник может беспрепятственно эксплуатировать уязвимость в устройстве, так как оно устарело и не обновляется.

I9 Небезопасные настройки по умолчанию


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


Тип устройства Название CWE Недостаток безопасности
ikettle Smarter Coffee machines CWE-15: External Control of System or Configuration Setting Злоумышленник может получить полный контроль над устройством из-за того, что большинство пользователей не настраивают кофемашины под себя, а оставляют их с заводскими небезопасными настройками.
Parrot AR.Drone 2.0 CWE-284: Improper Access Control Настройки дрона предполагают возможность неавторизованного подключения к нему и управления им.
HP Fax machine CWE-276: Incorrect Default Permissions Злоумышленник может воспользоваться неправильными настройками факса и полным отсутствием механизмов безопасности.
Smart speakers CWE-1068: Inconsistency Between Implementation and Documented Design Колонки активируются словами, не указанными в инструкции, и прослушивают происходящие.

I10 Отсутствие физической защиты


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


Тип устройства Название CWE Недостаток безопасности
Baby monitors Mi-Cam CWE-284: Improper Access Control Злоумышленник может следить за пользователями.
TOTOLINK router CWE-20: Improper Input Validation Злоумышленник может внедрить бэкдор.
Router TP-Link CWE-284: Improper Access Control Злоумышленник может получить привилегии администратора и сделать устройство частью ботнета через незащищенный UART.
Smart Nest Thermostat CWE-284: Improper Access Control Злоумышленник может загрузить процессор через периферийное устройство по USB или UART.
Blink XT2 Sync Module CWE-1233: Improper Hardware Lock Protection for Security Sensitive Controls Незащищенный разъем позволяет злоумышленнику подключиться к устройству.
Amazon Echo CWE-1233: Improper Hardware Lock Protection for Security Sensitive Controls Злоумышленник при помощи паяльника может изменить конфигурацию колонки, превратив ее в устройство для прослушки.

К сожалению, этот список можно продолжать бесконечно. На рынке появляется все больше IoT-устройств, а значит у злоумышленников появляются все новые возможности для достижения своих целей. Наша подборка уязвимых IoT-устройств не единственная, и мы предлагаем вам узнать о них больше: Safegadget, Exploitee и Awesome IoT Hacks


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


Национальный институт стандартов и технологий США выпустил Межведомственный отчет о состоянии международной стандартизации кибербезопасности для Интернета вещей (IoT). В этом документе приведены стандарты безопасности программного обеспечения и рекомендации по повышению его защищенности. Кроме того, производителям IoT-устройств рекомендуется использовать программное обеспечение, способное предотвращать, обнаруживать и смягчать вредоносное воздействие на производимые устройства.


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


Мы в свою очередь предлагаем услугу исследования безопасности IoT и сетевых устройств. Она может быть востребована как производителями, так и покупателями больших партий таких устройств (например, камер охраны периметра).


Первоисточник

Подробнее..

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

07.07.2020 10:10:24 | Автор: admin


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

Часто реклама этих сервисов звучит относительно безвредно. Некоторые производители продают свои программы под видом инструментов для автоматического отслеживания расхода времени или анализа рабочего места. Другие предлагают продукцию компаниям, беспокоящимся о возможных утечках данных или кражах интеллектуальной собственности. Мы будем называть все эти инструменты следилками [bossware]. Следилки, пусть они и предназначены в помощь работодателям, подвергают риску безопасность и конфиденциальность работников, записывая каждый щелчок мышкой и нажатие клавиши, тайно собирая информацию для будущих судебных исков, и используя другие шпионские возможности, далеко выходящие за пределы необходимого и разумного управления рабочей силой.

Это неправильно. Когда дом становится офисом, он не перестаёт быть домом. Работники не должны подвергаться несанкционированной слежке, или чувствовать себя под колпаком у себя дома только ради того, чтобы не потерять работу.

Что они умеют?


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

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

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

Некоторые следилки идут ещё дальше, дотягиваясь до окружающего работника физического мира. Компании, предлагающие ПО для мобильных устройств, почти всегда включают в него отслеживание перемещений по GPS. По меньшей мере два сервиса StaffCop Enterprise и CleverControl позволяют работодателям тайно включать веб-камеры и микрофоны в устройствах их работников.

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

Видимая слежка


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

Работникам могут дать доступ к определённой части информации, собранной об их работе. Компания Crossover, предлагающая продукт WorkSmart, сравнивает его с фитнес-трекером для работы за компьютером. Его интерфейс позволяет работникам смотреть на выводы системы, касающиеся их активности, представленные в виде графиков и диаграмм.

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

Невидимая слежка


Большая часть компаний, создающих видимое для пользователя следящее ПО, также делают продукты, пытающиеся спрятаться от тех людей, чью деятельность они отслеживают. Teramind, Time Doctor, StaffCop и другие производят следилки, максимально усложняющие их обнаружение и удаление. С технической точки зрения эти программы ничем не отличаются от stalkerware шпионского ПО для слежки за людьми без их ведома. Некоторые компании даже требуют от сотрудников перед установкой своих программ определённым образом настроить свои антивирусы, так, чтобы они не обнаруживали и не блокировали это ПО.


Часть процедуры регистрации в сервисе TimeDoctor, где работодатель выбирает между видимой и невидимой слежкой.

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

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

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

Распространённые возможности слежки в ПО для мониторинга



Насколько распространены следилки?


Бизнес слежки за работниками не нов, и ещё до вспышки пандемии он был довольно большим. И хотя оценить распространённость следилок достаточно сложно, они без сомнения стали более популярными после того, как работники вынуждены были перейти на удалённую работу в связи с коронавирусом. Компания Awareness Technologies, владеющая InterGuard, заявляет, что за первые несколько недель вспышки расширила пользовательскую базу на 300%. Многие из изученных нами производителей используют коронавирус в рекламных заявлениях.

Следилки используют одни из крупнейших компаний. Среди клиентов Hubstaff числятся Instacart, Groupon и Ring. Time Doctor заявляет о наличии 83 000 пользователей; среди её клиентов Allstate, Ericsson, Verizon и Re/Max. ActivTrak используют более 6 500 организаций, включая Аризонский государственный университет, университет Эйморе и администрации городов Денвер и Малибу. Такие компании, как StaffCop и Teramind не раскрывают информацию о клиентах, но заявляют, что их области деятельности включают в себя здравоохранение, банковские услуги, моду, производство и кол-центры. По отзывам клиентов, использующих следилки, можно судить о том, каким образом они используют эти программы.

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

Для чего используются собранные данные?


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

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


Рекламный материал с домашней страницы Work Examiner

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

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

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


С сайта Work Examiner: запись нажатий клавиш что они там печатают?
Запись нажатий записывает все нажатия клавиш, сделанные пользователем. Вы увидите, что он печатал в любой программе, будь то мессенджер, сайт, веб-почта, или MS Word. Можно перехватывать даже пароли, вводимые в программах и на веб-сайтах!


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

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

Что можно с этим сделать?


По имеющимся в США законам у работодателей слишком большая свобода действий в установке следящего ПО на свои собственные устройства. Также мало что мешает им заставить работников установить подобное ПО на их собственные устройства (если только его можно отключать в нерабочие часы). В разных штатах существуют разные правила по поводу того, что могут и не могут работодатели. Однако у работников часто остаётся очень мало возможностей юридически воздействовать на чрезмерно любопытное ПО для слежки.

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


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

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

Наконец, работники могут опасаться заговаривать о слежке за ними, из боязни вылететь с работы в период рекордной безработицы [в США безработица составляет более 11%]. Выбор между навязчивой чрезмерной слежкой и безработицей сложно назвать выбором.

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

Категории

Последние комментарии

© 2006-2020, personeltest.ru