В ходе работ по тестированию на проникновение мы можем столкнуться с уязвимостью, которая позволяет нам выполнять атаки XML eXternal Entity (XXE) Injection. XXE Инъекция — это тип атаки на приложение, которое анализирует ввод XML. Хотя это относительно эзотерическая уязвимость по сравнению с другими векторными атаками веб-приложений, например, Cross-Site Request Forgery (CSRF), мы максимально используем эту уязвимость, когда она появляется, поскольку она может привести к извлечению конфиденциальных данных и даже к удаленному исполнению кода (RCE). В статье мы рассмотрим настройку уязвимого PHP-сервера, эксплуатируя уязвимость вручную, а затем перейдем к удобному инструменту под названием XXEInjector, чтобы автоматизировать этот процесс.

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

От переводчика: Привет, хабр! Представляю вашему вниманию перевод статьи Why you should be using pathlib и её продолжения, No really, pathlib is great. Много внимания нынче уделяется таким новым возможностям Python, как asyncio, оператору :=, и опциональной типизации. При этом за радаром рискуют пройти не столь значительные (хотя, := назвать серьёзным нововведением язык не поворачивается), но весьма полезные нововведения в язык. В частности, на хабре статей, посвящённых сабжу, я не нашел (кроме одного абзаца тут), поэтому решил исправить ситуацию.

Когда я открыл для себя тогда еще новый модуль pathlib несколько лет назад, я по простоте душевной решил, что это всего лишь слегка неуклюжая объектно-ориентированная версия модуля os.path. Я ошибался. pathlib на самом деле чудесен!

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

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


Итак, герой нашей истории — ПО Steam от компании Valve. И уязвимость повышения привилегий в нем, которая позволяет любому пользователю выполнить команды от имени NT AUTHORITY\SYSTEM.

Мой путь в ИБ начался с удивительного открытия: «безопасно ≠ зашифровано». Это сейчас такое утверждение выглядит простым и очевидным, а на первом курсе осознание этого факта произвело эффект сравнимый с ментальной атомной бомбой. Информационная безопасность атаковала расширением границ предметной области: оказалось, что криптография — это только один рубеж защиты, а ещё есть юридические, организационные, да и просто физические, в конце концов. Один из теоретических аспектов гласил «Все вопросы безопасности информации описываются доступами субъектов к объектам». Заучил, нарисовал мандатную и дискреционную модели доступов, рассказал, сдал и забыл.

Я специализируюсь на анализе безопасности Windows приложений. Довольно часто изучение именно различных прав доступа занимает существенную долю исследования. Чтобы автоматизировать процесс поиска странных или неправильных прав доступа пришлось разбираться в SDDL (Security Descriptor Definition Language). Кому интересно научиться читать права в форме SDDL (например что-то такое O:SYG:SYD:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)) и познакомиться с моей утилитой для работы с дескрипторами в таком формате, добро пожаловать под кат.

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


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

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

Неожиданно в вашем тридевятом царстве, в тридесятом государстве возникает потребность провести пентест против вашей воли, например, что-то причудилось начальству, или нагрянуло новое требование законодательства. Вам очевидно, что стоит найти «шарашкину контору», которая сделает имитацию работ и напишет, что всё хорошо, и дело с концом, но ситуация усложняется. Ваша компания решает разыграть конкурс и сделать это максимально эффективно: написать разумное ТЗ, предъявить высокие требования к команде пентестеров (наличие сертификатов, участие в Bug bounty) и т.п. В общем, все сделали за вас, а ваша ответственность — только курировать работы.

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

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

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

Объединяет их то, что все они довольно простые, но мы подчас о них не задумываемся (я во всяком случае о них не задумывался).
В общем я их собрал, подбил, нашёл ответы.
Итак, блиц опрос:

Начнём с самых низких уровней и с самых простых вопросов

В1. Почему для витой пары выбран такой странный порядок: синяя пара на 4-5, разрывая зелёную, которая на 3, 6?

В2. В стандарте Ethernet между кадрами всегда имеется промежуток, называемый IFG (Inter Frame Gap) длиною 12 байтов. Для чего он нужен, и почему он присутствует в современных стандартах?

Протокол Telegram известен своей доступностью и открытостью. У него есть множество публичных реализаций: tdlib/td, rubenlagus/TelegramApi, vysheng/tg, LonamiWebs/Telethon и другие. Однако, даже имея в распоряжении столь богатый инструментарий и объемную документацию (https://core.telegram.org/api), решить прикладную задачу, собрав из многообразия методов API нужную цепочку – не так-то просто. Сможет, например, “неподготовленный ум“ сходу догадаться, как решить прикладную задачу а-ля “поиск по номеру в Telegram“? — Скорее всего, придется потратить какое-то время на изучение API.

Официальный клиент Telegram содержит в себе массу API-цепочек, реализующих определенные пользовательские сценарии. Если подумать, взаимодействие на основе сценариев — наиболее удобный и предпочтительный способ, поэтому мы решили пойти по пути упрощения взаимодействия с Telegram на основе реализации библиотеки сценариев. Так как наша деятельность тесно связана с направлением OSINT, то в первую очередь мы решили реализовать ряд OSINT-сценариев, применимых в сети Telegram, о которых и хотим рассказать в этой статье.

Для решения задач OSINT мы еще давно начали работу над собственным клиентом для сети Telegram, который в последствии трансформировался в расширяемую библиотеку сценариев — telegram-osint-lib.

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

Как это было

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

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

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

Бублики — это инструкции в файле Dockerfile

-0x01 — Intro

Данная статья посвящена разбору всех заданий Flare-On 2019 — ежегодного соревнования по реверс-инжинирингу от FireEye. В данных соревнованиях я принимаю участие уже второй раз. В предыдущем году мне удалось попасть на 11-ое место по времени сдачи, решив все задачи примерно за 13 суток. В этом году набор тасков был проще, и я уложился в 54 часа, заняв при этом 3 место по времени сдачи.

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

Если вас заинтересовало, то добро пожаловать под кат!

Недавнее исследование «Использование и атрибуция сниппетов кода Stack Overflow в проектах GitHub» внезапно обнаружило, что чаще всего в опенсорсных проектах встречается мой ответ, написанный почти десять лет назад. По иронии судьбы, там баг.

Давным-давно…

Еще в 2010 году я сидел в своём офисе и занимался ерундой: развлекался код-гольфингом и накручивал рейтинг на Stack Overflow.

Моё внимание привлёк следующий вопрос: как вывести количество байт в удобочитаемом формате? То есть как преобразовать что-то вроде 123456789 байт в «123,5 МБ».


Старый добрый интерфейс 2010 года, спасибо The Wayback Machine

Всем привет. Сегодня рассмотрим вариант запуска meterpreter сессии на машине Windows 10 с самыми свежими патчами (включая Windows Defender). И все также будем обходить антивирусы. Meterpreter — расширенная многофункциональная начинка (payload, нагрузка), которая может быть динамически расширена во время выполнения. В нормальных условиях это обеспечивает вас основной оболочкой и позволяет вам добавлять новые особенности к ней по мере необходимости.
Будем мы это делать с помощью Python, и посмотрим, как поведут себя антивирусные средства.

Предугадывая вопрос «А нужен ли нам Python на машине жертвы для запуска ехе?», отвечу сразу – нет, не нужен, все уже внутри.

Меня всегда удручало подключение к Windows машинам. Нет, я не противник и не сторонник Microsoft и их продуктов. Каждый продукт существует для своей цели, но речь не об этом.
Для меня всегда было мучительно больно подключаться к серверам с Windows, потому что эти подключения либо настраиваются через одно место (привет WinRM с HTTPS) либо работают не очень стабильно (здравствуй RDP к виртуалкам за океаном).

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

Warning

Информация в статье устарела, Flipper Zero был полностью пеработан на другой платформе. Актуальная информация в нашем блоге blog.flipperzero.one

Flipper Zero — проект карманного мультитула на основе Raspberry Pi Zero для пентеста IoT и беспроводных систем контроля доступа, который я разрабатываю с друзьями. А еще это тамагочи, в котором живет кибер-дельфин.

Он будет уметь:

• Работать в диапазоне 433 MHz — для исследования радиопультов, датчиков, электронных замков и реле.
• NFC — читать/записывать и эмулировать карты ISO-14443.
• 125 kHz RFID — читать/записывать и эмулировать низкочастотные карты.
• iButton ключи — читать/записывать и эмулировать контактные ключи, работающие по протоколу 1-Wire.
• Wi-Fi — для проверки защищенности беспроводных сетей. Адаптер поддерживает инъекции пакетов и мониторный режим.
• Bluetooth — поддерживается пакет bluez для Linux
• Режим Bad USB — может подключаться как USB-slave и эмулировать клавиатуру, ethernet-адаптер и другие устройства, для инъекции кода или сетевого пентеста.
• Тамагочи! — микроконтроллер с низким энергопотреблением работает, когда основная система выключена.

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

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

Наверное, тогда маркетологи и придумали такое название как Flash Accelerator (флеш-акселератор или флеш-ускоритель).

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

Мотивация

• Хотелось ли вам за разумные деньги купить SSD размером в несколько терабайт?
• Чтобы ресурс был на десятки петабайт?
• Такой, что что бы вы ни делали, вы бы не смогли его исчерпать?
• При этом с защитой по питанию и сделанный из самых качественных деталей и самой стойкой памяти?

При слове «криптография» некоторые вспоминают свой пароль WiFi, зелёный замочек рядом с адресом любимого сайта и то, как трудно залезть в чужую почту. Другие вспоминают череду уязвимостей последних лет с говорящими аббревиатурами (DROWN, FREAK, POODLE...), стильными логотипами и предупреждением срочно обновить браузер.

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

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

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

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

Что происходило там — особой смысловой нагрузки не несёт, а вот что началось потом — это что-то.

Как закончилась конференция, все её участники взяли билеты на сапсан, последний сапсан Санкт-Петербург — Москва выезжает в 21:00, и я на него успевал…

Прим. перев.: Эта публикация британского программиста, ставшая настоящим хитом в англоязычном интернете, ссылается на Git-коммит 6-летней давности. Он был зафиксирован в одном из открытых репозиториев Government Digital Service — службы, занимающейся развитием цифровых услуг в Великобритании и поддерживающей проект GOV.UK. Сам коммит интересен не столько изменениями в коде, сколько сопровождающим их описанием…


Картинка из xkcd #1296

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