Эта статья является частью серии «Fileless Malware». Все остальные части серии:

• Приключения неуловимой малвари, часть I
• Приключения неуловимой малвари, часть II: скрытные VBA-скрипты
• Приключения неуловимой малвари, часть III: запутанные VBA-скрипты для смеха и прибыли
• Приключения неуловимой малвари, часть IV: DDE и поля документа Word (мы тут)

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

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


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

Программисты, не использующие UML, делятся на несколько групп:

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

Всем привет!

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

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

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

JSON Web Token – это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON.

Добро пожаловать в мир свитчей! Сегодня мы поговорим о коммутаторах. Предположим, что вы – сетевой администратор и находитесь в офисе новой компании. К вам подходит менеджер со свитчем «из коробки» и просит его настроить. Возможно, вы подумали, что речь идет об обычном электрическом выключателе (в английском языке слово switch обозначает и сетевой коммутатор, и электрический выключатель – прим. переводчика), но это не так – имеется в виду сетевой коммутатор, или свитч Cisco.



Итак, менеджер передает вам новый коммутатор Cisco, который снабжен множеством интерфейсов. Это может быть 8,16 или 24-х портовый свитч. В данном случае на слайде показан свитч, у которого спереди имеется 48 портов, разделенных на 4 секции по 12 портов. Как мы знаем из предыдущих уроков, сзади свитча имеется еще несколько интерфейсов, одним из которых является консольный порт. Консольный порт используется для внешнего доступа к устройству и позволяет увидеть, как происходит загрузка операционной системы свитча.

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

История об исследовании и разработке в 3-х частях. Часть 3 — практическая.
Буков много — пользы еще больше

Предыдущие статьи из цикла можно найти тут и здесь =)

Проверка боем

Давайте теперь проверим работу нашего скрипта на практике. Для этого попробуем выбросить обратный туннель с виртуалки (Windows 7 .net 4.7) до линуксовой VPS на Digital Ocean и затем, воспользовавшись им, зайдем обратно на Win7. В данном случае мы имитируем ситуацию, когда Windows 7 — машина Заказчика, Linux VPS — наш сервер.

История об исследовании и разработке в 3-х частях. Часть 2 — разработческая.
Буков много — пользы еще больше.

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

Прежде всего, нам необходимо понять, в каком режиме будет работать наш модуль. Очевидно, что для прима-передачи данных нам необходимо будет использовать механизм windows сокетов и предоставляемые .Net возможности по потоковому чтению-записи в сокеты. Но, с другой стороны, т.к. наш модуль должен обслуживать несколько yamux-стримов одновременно, то все операции ввода-вывода не должны полностью блокировать выполнение нашей программы. Отсюда напрашивается вывод о том, что наш модуль должен использовать программную многопоточность и выполнять операции чтения-записи с yamux-сервером, а так же операции чтения-записи к серверам назначения в разных программных потоках. Ну и само собой необходимо предусмотреть механизм взаимодействия между нашими параллельными потоками. Благо, powershell предоставляет широкие возможности по запуску и управлению программными потоками.

История об исследовании и разработке в 3-х частях. Часть 1 — исследовательская.
Буков много — пользы еще больше.

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

В ходе проведения пентестов и RedTeam кампаний не всегда удается воспользоваться штатными средствами Заказчиков, такими как VPN, RDP, Citrix и т.д. в качестве закрепления для захода во внутреннюю сеть. Где-то штатный VPN работает по MFA и в качестве второго фактора используется железный токен, где-то он жестоко мониторится и наш вход по VPN сразу же становится виден, как говорится — со всеми вытекающими, а где-то таких средств попросту нет.

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

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

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

К примеру, MSF-сессии успешно детектируются современными IPS от Cisco или Positive Tech, а обратный SSH- туннель можно задетектить практически любым мало-мальским нормальным файерволлом.

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

Давайте попробуем найти или изобрести нечто подобное.

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

1. Какую работу требуется выполнить

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

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

REST — чрезвычайно популярная архитектура веб-приложений. Для вызова функций на сервере используются обычные HTTP-запросы с задаваемыми параметрами (для структуризации параметров обычно используют JSON или XML), при этом, строгого стандарта для REST-архитектуры не существует, что добавляет ей гибкости (и, конечно, немного хаоса).

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

set -o xtrace

для отладки,

set -o errexit

для выхода по ошибке или

set -o errunset

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

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

_{Паяльник второй половины XIX века, который нагревался на огне}

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

Работа с распределенной системой контроля версий Git на примере GitHub
Год начала данной публикации: 2019
Год окончания данной публикации: не указан





Теоретическая часть
Практическая часть
Настройка программы Git
Инициализация локального репозитория
Работа с удаленным репозиторием
Чтобы некоторые ваши файлы не попадали в репозиторий
Модели ветвления в Git
Выводы
.gitignore. Отправка только тех файлов в репозиторий, которые необходимы



Предупреждение по использованию:

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

1) PROMPT_COMMAND

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

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

Попробуйте запустить это в новом шелле, и увидите, что произойдёт с сессией:

$ PROMPT_COMMAND='echo -n "writing the prompt at " && date'

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!

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

Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.

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

Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.

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

Данная статья о том как настроить современный почтовый сервер.
Postfix + Dovecot. SPF + DKIM + rDNS. С IPv6.
С шифрованием TLS. С поддержкой нескольких доменов — часть с настоящим SSL сертификатом.
С антиспам-защитой и высоким антиспам-рейтингом у других почтовых серверов.
С поддержкой нескольких физических интерфейсов.
С OpenVPN, подключение к которому через IPv4, и которое даёт IPv6.

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

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

В конце 2017 года группа компаний ЛАНИТ закончила один из самых интересных и ярких проектов в своей практике — Дилинговый центр Сбербанка в Москве.

Из этой статьи вы узнаете, как именно «дочки» ЛАНИТ оборудовали новый дом для брокеров и уложились в рекордно короткие сроки.

Источник

Привет, Хабр!

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

Vue.js содержит много интересных и необычных подходов к валидации, которые помогут решить ваши проблемы. Обзор под катом!