Введение

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

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

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

Однажды один из клиентов компании-интегратора, где я работал, попросил оперативно нарисовать проект небольшой системы хранения данных. Как назло, специальный человек по SAN оказался недоступен и задачу поручили мне. На тот момент мои знания по СХД сводились к непробиваемой идее "Fibre Channel – это круто, а iSCSI – не очень".

Корректное отключение

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

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

К примеру, по итогам пентеста в одной компании мы пришли к выводу, что все доступные машины в домене были не ниже Windows10/Windows Server2016, и на них стояли все самые свежие патчи. Сеть регулярно сканировалась, машины хардились. Все пользователи сидели через токены и не знали свои «20-символьные пароли». Вроде все хорошо, но протокол IPv6 не был отключен. Схема захвата домена выглядела так:

mitm6 -> ntlmrelay -> атака через делегирование -> получен хеш пароля локального администратора -> получен хеш пароля администратора домена.

К сожалению, такие популярные сертификации, как OSCP, GPEN или CEH, не учат проведению тестирования на проникновение Active Directory.

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

Итак, для демонстрации используем ноутбук на Kali Linux 2019 и поднятые на нем виртуальные хосты на VMware. Представим, что главная цель пентеста — получить права администратора домена, а в качестве вводных данных у нас есть доступ в корпоративную сеть компании по ethernet. Чтобы начать тестировать домен, нам понадобится учетная запись.

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

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



Ответ знает Алексей Учакин (Night_Snake) — лидер команды сетевых инженеров в компании IQ Option. Главная его задача — доступность платформы для пользователей. В расшифровке доклада Алексея на Saint HighLoad++ 2019 поговорим про BGP, DDOS-атаки, рубильник от интернета, ошибки провайдеров, децентрализацию и случаи, когда маленький роутер отправил интернет поспать. В конце — пара советов, как все это пережить.

SSH/HTTPS/OpenVPN/Telegram и всё на одном порту?! Что?!
— Да!

• Хотите скрыть наличее у вас некоторых сервисов?
• В публичной wi-fi сети блокируется всё кроме 443 (https) порта?
• Настроили Telegram Proxy/OpenVPN и не хотите его «светить» ?
• SSH подключение к своему серверу из стран с цензурой?

На все эти вопросы ответ один — Мультиплексирование SSL/TLS соединений, или SSLH.

В посте мы рассмотрим как в 1 команду спрятать кучу сервисов за 1 портом.

Приветствую всех читателей Habr! Сегодняшняя статья будет о датчике температуры, влажности и атмосферного давления c длительным сроком работы от одной батарейки. Датчик работает на микроконтроллере nRF52832 (даташит). Для получения температуры, влажности и атмосферного давления использован сенсор BME280 — даташит. Датчик работает от батареек CR2430/CR2450/CR2477. Потребление в режиме передачи составляет 8мА, в режиме сна 5мкА. Итак, обо всем попорядку.

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

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

В современном мире различные VPN-технологии используются повсеместно. Некоторые (например, PPTP) со временем признаются небезопасными и постепенно отмирают, другие (OpenVPN), наоборот, с каждым годом наращивают обороты. Но бессменным лидером и самой узнаваемой технологией для создания и поддержания защищенных частных каналов по-прежнему остается IPsec VPN. Иногда при пентесте можно обнаружить серьезно защищенную сеть с торчащим наружу лишь пятисотым UDP-портом. Все остальное может быть закрыто, пропатчено и надежно фильтроваться.

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

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

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

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

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

Посмотрите на рисунок. Вот так конфигурируется классический NAT на маршрутизаторе Cisco, допустим там больше ничего не сконфигурировано. А теперь ответьте сами себе на вопрос. Может ли при определенных условиях кто-либо обратиться извне на RDP порт (TCP 3389) супер секретного сервера 192.168.0.250 и попытаться подобать пароль к нему. Уточним, что сервер стоит одиноко в сети и никуда сам не обращается (имеется в виду, что на нем нет никаких троянов, автоматических обновлений и прочих прелестей).

Считаете — нет? Вспомним анекдот.

Лекция по филологии. Старый профессор рассказывает:

— В некоторых языках мира двойное отрицание означает согласие. В других, двойное отрицание так и остается отрицанием. Но, нет ни одного языка в мире, в котором двойное согласие означает отрицание. Голос с задней парты:

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

Входные требования следующие:

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

Тема нового дайджеста «Мира Hi-Fi» — аудиоформаты. Статьи подборки расскажут про кодеки для сжатия аудио и различные аналоговые носители. Итак, время чтения на выходных.

Как вы помните из прошлого выпуска провайдер linkmeup встал на ступень Tier 2. Но просто предоставлять услуги доступа в Интернет или L2/3VPN-ы (быть по сути трубой для трафика) Linkmeup не устраивает. Сейчас большим спросом пользуются услуги облачного хранения данных, поэтому linkmeup обзавелся несколькими собственными датацентрами, расположенные по экономическим соображениям в Рязани. В связи с этим перед нами встала новая задача — как связать датацентры между собой и предоставить клиентам доступ к корпоративным СХД, расположенные в наших автозалах? Ввиду того, что в core-network уже запущен MPLS, то наш выбор пал на EVPN/MPLS. Его и рассмотрим.

Сегодня мы поговорим об очередной интересной технологии — VxLAN — что это за зверь и с чем его едят, да и вообще нужен ли он вам. Мое знакомство с данной технологией началось с изучения гипервизоров — я постоянно натыкался на термин VxLAN, но что это и как работает не знал. В один прекрасный день я решил все-таки прочитать, что это за зверь. Прочитав пару-тройку статей, я усвоил для себя основные аспекты работы технологии и облегченно выдохнул, прочитав, что данная технология — удел гипервизоров и к транспорту имеет косвенное отношение (хотя, как оказалось позже отношение VxLAN к транспорту имеет самое, что ни на есть прямое). После чего про технологию благополучно забыл и вернулся я к ней снова только через год, когда начал погружаться в EVPN — большинство статей и мануалов были именно о симбиозе EVPN и VxLAN. Литературы по данной технологии много, особенно если вы владеете английским. Я же попробую в данной статье рассказать об основах работы данной технологии и показать на практике — как это настраивается и работает. Но начнем с MPLS…

Как ранее сообщалось на GeekTimes, EFF при поддержке Mozilla, Cisco, Akamai, IdenTrust и исследователей из Мичиганского университета (University of Michigan) создали новый некоммерческий центр сертификации (Certificate Authority) Let's Encrypt [1]. Целью проекта является ускорение перехода всемирной паутины от HTTP к HTTPS.

Прим. переводчика: Это перевод статьи Питера Брайта (Peter Bright) «How security flaws work: The buffer overflow» о том, как работает переполнение буфера и как развивались уязвимости и методы защиты.

Беря своё начало с Червя Морриса (Morris Worm) 1988 года, эта проблема поразила всех, и Linux, и Windows.



Переполнение буфера (buffer overflow) давно известно в области компьютерной безопасности. Даже первый само-распространяющийся Интернет-червь — Червь Морриса 1988 года — использовал переполнение буфера в Unix-демоне finger для распространения между машинами. Двадцать семь лет спустя, переполнение буфера остаётся источником проблем. Разработчики Windows изменили свой подход к безопасности после двух основанных на переполнении буфера эксплойтов в начале двухтысячных. А обнаруженное в мае сего года переполнение буфера в Linux драйвере (потенциально) подставляет под удар миллионы домашних и SMB маршрутизаторов.

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

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

Разработчик Firefox и хакер Роберт О'Каллахан временно покинул Mozilla, стал свободен от корпоративных обязательств и теперь волен говорить правду без оговорок. Он призвал пользователей к немедленному удалению сторонних антивирусов со своих компьютеров (Windows Defender лучше оставить).

«Теперь [после ухода из Mozilla] я могу безопасно сказать: разработчики антивирусных программ ужасны; не покупайте антивирусные программы, и удалите уже установленные (кроме Microsoft, если вы под Windows [10]», — заявил Роберт.

Основные правила безопасности: следить за обновлениями операционной системы, устанавливать последние патчи безопасности. Специалист добавил, что если человеку приходится использовать устаревшие системы Windows 7 или, не дай бог, Windows XP, то сторонние антивирусы всё-таки помогут ему быть не в полной дыре — чувствовать, что есть хоть какая-то защита.

Несколько месяцев назад разработчики Chrome объявили, что в июле 2018 года начнут помечать как небезопасные все страницы HTTP. Значок «Не защищено» (“Not secure”) появится в адресной строке рядом с URL.

Это важное нововведение, потому что людей приучают избегать сайтов, которые не установили сертификат TLS для шифрования трафика. Ведь такие сайты действительно подвергают опасности пользователей. Например, провайдеры и другие злоумышленники могут внедрять в незашифрованный трафик рекламу, криптомайнеры и другой вредоносный контент. В опросе на Хабре 55% пользователей согласились, что все сайты должны шифровать трафик по HTTPS.

Сейчас стало известно об ещё одном изменении, смысл которого сразу не так очевиден. Оказывается, с версии Chrome 69 (сентябрь 2018 года) у защищённых сайтов HTTPS исчезнет индикатор «Защищено». Спрашивается, почему?