Forwarded from REDtalk (Alexey)
Привет! 🤥
Недавно я перечитывал свои посты и наткнулся на один из самых старых — про переполнение стека. Вспомнил молодость, словил испанский стыд и решил сделать ремейк, а точнее, полностью переписать пост. Получилось небольшая статья про введение в эксплуатацию бинарных уязвимостей на простом примере задачи в формате ctf. Описаны базовые виды защиты памяти, пошагово создан CTF-таск с подробным решением.
Приятного чтения!🔗 Читать
Но это еще не всё! Cейчас в тренде импортозамещение, так, что я тоже решил не отставать и создал свой небольшой сайт:🔗 read.pyfffe.site. Туда переехали материалы из Notion, и теперь все гифки в постах нормально загружаются без впн (да, всё было ради гифок 👸 ). Да и в целом хорошо бы иметь полный контроль над своим ресурсом (просьба не пробовать его получать 👾).
Теперь всё, спасибо за внимание!
Недавно я перечитывал свои посты и наткнулся на один из самых старых — про переполнение стека. Вспомнил молодость, словил испанский стыд и решил сделать ремейк, а точнее, полностью переписать пост. Получилось небольшая статья про введение в эксплуатацию бинарных уязвимостей на простом примере задачи в формате ctf. Описаны базовые виды защиты памяти, пошагово создан CTF-таск с подробным решением.
Приятного чтения!
Но это еще не всё! Cейчас в тренде импортозамещение, так, что я тоже решил не отставать и создал свой небольшой сайт:
Теперь всё, спасибо за внимание!
Please open Telegram to view this post
VIEW IN TELEGRAM
pyfffe blog
Самый простой StackOverflaw
Привет, когда-то давно я писал свой первый таск на переполнение стека, и вот решил обернуть всё это в пост про введение в категорию pwn.
TL;DR
Исходники доступны ***на гитхабе.*** Таск поднимается несколькими командами, нужен лишь Docker. Решение также лежит…
TL;DR
Исходники доступны ***на гитхабе.*** Таск поднимается несколькими командами, нужен лишь Docker. Решение также лежит…
Forwarded from PurpleBear (Vadim Shelest)
Account Takeover by Unicode/Punycode email password reset
Уже довольно давно у меня в бэклоге лежала интересная техника, найденная где-то на просторах сети, которой я хочу сегодня поделиться.
Сначала немного теории:
Так как изначально в системе доменных имён были предусмотрены только латинские буквы A-Z, цифры 0-9 и дефис, придумали специальную кодировку -
♦️Тестирование механизмов восстановления пароля/байпаса 2FA через почту по умолчанию в методологии любого пентестера и багхантера, поэтому берём валидный email
♦️Добавляем Collaborator
♦️ Наблюдаем результат → в Collaborator проверяем SMTP отстуки. Если приходит письмо для сброса пароля / 2FA - значит система некорректно обработала Unicode.
♦️Репортим багу как
💸 Вы великолепны!
Почему так работает для фишинга абсолютно понятно, латинская
Уже довольно давно у меня в бэклоге лежала интересная техника, найденная где-то на просторах сети, которой я хочу сегодня поделиться.
Punycode / IDN Homograph традиционно используется в проведении фишинговых компаний для получения первоначального доступа во время Red Team и пентестов, но можно также использовать эту технику для тестирования механизмов восстановления пароля/байпаса 2FA через email в рамках багбаунти😎Сначала немного теории:
IDN (Internationalized Domain Name) - это технология, позволяющая использовать в доменных именах символы из национальных алфавитов: кириллицы, китайских иероглифов, арабской письменности и пр.Так как изначально в системе доменных имён были предусмотрены только латинские буквы A-Z, цифры 0-9 и дефис, придумали специальную кодировку -
Punycode/Unicode, как способ закодировать домен с не-ASCII символами в ASCII-совместимую форму. Например: домен.рф → xn--d1acufc.xn--p1ai♦️Тестирование механизмов восстановления пароля/байпаса 2FA через почту по умолчанию в методологии любого пентестера и багхантера, поэтому берём валидный email
victim@gmail.com и меняем домен на Unicode-вариант victim@gmáil.com♦️Добавляем Collaborator
victim@gmáil.com.<collab>.burpcollaborator.net, перехватываем запрос → подменяем email жертвы и отправляем дальше.♦️ Наблюдаем результат → в Collaborator проверяем SMTP отстуки. Если приходит письмо для сброса пароля / 2FA - значит система некорректно обработала Unicode.
♦️Репортим багу как
Account Takeover для victim@gmail.com💸 Вы великолепны!
Почему так работает для фишинга абсолютно понятно, латинская
a vs кириллическая а визуально практически неотличимы, а вот как можно допустить такую ошибку в механизме восстановления пароля для меня загадка😜 Но тем не менее уже есть кейсы когда багхантеры лутали за эту багу 10k$ в публичных программах.❤1
Fsecurity | HH pinned «Как я понял по опросу, вы не против личных заметок — поэтому пишу. Выше заметно интересное обновление Adaptix C2. Спросите, что это такое? Объясняю: это C2‑фреймворк, но вам известнее слышать RATка. RAT (Remote Access Trojan) — это программный агент, устанавливаемый…»
Forwarded from 1N73LL1G3NC3
Win32_Process has been the go to WMI class for remote command execution for years. In this post we will cover a new WMI class that functions like Win32_Process and offers further capability.
🔗 WMI_Proc_Dump.py
Dump processes over WMI with MSFT_MTProcess
🔗 mtprocess.py
Python script that uses Impacket to use the MSFT_MTProcess WMI class to execute a command. If wanting to use against a Workstation it can install the provider.
P.S. One more way to dump LSASS.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from PWN AI (Artyom Semenov)
Почему LLM всё ещё генерируют уязвимый код. Результаты A.S.E Benchmark
В недавнем исследовании был представлен бенчмарк A.S.E (AI Code Generation Security Evaluation), который оценивает способность языковых моделей генерировать безопасный код в условиях, максимально приближённых к реальной разработке. В этом посте мы разберём: чем A.S.E отличается от предыдущих подходов, какие результаты он показал на ведущих моделях и почему они до сих пор уязвимы.
Главное отличие A.S.E в том, что проверка проводится на уровне целого репозитория, а не как это было раньше, на отдельных участках кода. Это позволяет учитывать архитектуру проекта, взаимосвязь файлов и внешние зависимости. Основой для бенчмарка стали реальные репозитории в GitHub с зафиксированными CVE и опубликованными патчами.
Чтобы избежать банального запоминания шаблонов небезопасного кода, разработчики бенчмарка добавили семантические и структурные мутации уязвимостей. Ещё одна важная деталь — автоматическая проверка с помощью правил статического анализа, которые отслеживают источник уязвимости, пути распространения данных и точку эксплуатации, что делает бенчмарк ближе к условиям, которые можно встретить при реальной разработке.
Результаты оказались показательными.
Среди 26 протестированных моделей ни одна не достигла уровня, который бы позволял назвать модель “Best FOR Security Generated CODE”. Лучший общий результат продемонстрировал Claude-3.7-Sonnet, однако его показатели по безопасности существенно отставали от качества кода. При этом наивысший балл именно по безопасности получила модель Qwen3-235B-A22B-Instruct, что указывает на сближение открытых и проприетарных решений в этой области. Самое впечатляющее — reasoning-режимы не помогали исправлять уязвимости, а делали код менее безопасным. Самой проблемной категорией уязвимостей оказался Path Traversal: почти все модели систематически ошибались при обработке путей и проверке доступа к файлам.
На мой взгляд, ценность A.S.E заключается именно в том, что он вскрывает технические слабости LLM, которые не видны на синтетических бенчмарках (хотя, к слову, их сейчас стало заметно меньше). Эти слабости отражают важную проблему: модели хорошо справляются с синтаксисом и общей структурой кода, но по-прежнему не способны достойно учитывать требования безопасности. Я думаю, что в течение года мы увидим заметный прогресс, но пока ситуация остаётся далёкой от уровня, который позволял бы доверять LLM генерацию кода без постоянной проверки.
В недавнем исследовании был представлен бенчмарк A.S.E (AI Code Generation Security Evaluation), который оценивает способность языковых моделей генерировать безопасный код в условиях, максимально приближённых к реальной разработке. В этом посте мы разберём: чем A.S.E отличается от предыдущих подходов, какие результаты он показал на ведущих моделях и почему они до сих пор уязвимы.
Главное отличие A.S.E в том, что проверка проводится на уровне целого репозитория, а не как это было раньше, на отдельных участках кода. Это позволяет учитывать архитектуру проекта, взаимосвязь файлов и внешние зависимости. Основой для бенчмарка стали реальные репозитории в GitHub с зафиксированными CVE и опубликованными патчами.
Чтобы избежать банального запоминания шаблонов небезопасного кода, разработчики бенчмарка добавили семантические и структурные мутации уязвимостей. Ещё одна важная деталь — автоматическая проверка с помощью правил статического анализа, которые отслеживают источник уязвимости, пути распространения данных и точку эксплуатации, что делает бенчмарк ближе к условиям, которые можно встретить при реальной разработке.
Результаты оказались показательными.
Среди 26 протестированных моделей ни одна не достигла уровня, который бы позволял назвать модель “Best FOR Security Generated CODE”. Лучший общий результат продемонстрировал Claude-3.7-Sonnet, однако его показатели по безопасности существенно отставали от качества кода. При этом наивысший балл именно по безопасности получила модель Qwen3-235B-A22B-Instruct, что указывает на сближение открытых и проприетарных решений в этой области. Самое впечатляющее — reasoning-режимы не помогали исправлять уязвимости, а делали код менее безопасным. Самой проблемной категорией уязвимостей оказался Path Traversal: почти все модели систематически ошибались при обработке путей и проверке доступа к файлам.
На мой взгляд, ценность A.S.E заключается именно в том, что он вскрывает технические слабости LLM, которые не видны на синтетических бенчмарках (хотя, к слову, их сейчас стало заметно меньше). Эти слабости отражают важную проблему: модели хорошо справляются с синтаксисом и общей структурой кода, но по-прежнему не способны достойно учитывать требования безопасности. Я думаю, что в течение года мы увидим заметный прогресс, но пока ситуация остаётся далёкой от уровня, который позволял бы доверять LLM генерацию кода без постоянной проверки.