Получите клиентов в любой нише!
Делегируйте запуск рекламы нам — бесплатно
Подробнее
12.3
Похек
Канал о кибербезопасности, багбаунти и реальных кейсах из мира ИБ. Новости, полезные инструменты, разборы уязвимостей и советы для специалистов всех уровней. Аудитория — активное ИТ-сообщество, эксперты и новички. Идеальная площадка для рекламы в сфере технологий и ИБ.
Поделиться
В избранное
Купить рекламу в этом канале
Формат:
keyboard_arrow_down
- 1/24
- 2/48
- 3/72
- Нативный
- 7 дней
- Репост
1 час в топе / 24 часа в ленте
Количество:
%keyboard_arrow_down
- 1
- 2
- 3
- 4
- 5
- 8
- 10
- 15
Стоимость публикации:
local_activity
12 587.40₽12 587.40₽local_mall
0.0%
Последние посты канала
imageИзображение не доступно для предпросмотра
1300
11:30
30.01.2025
imageИзображение не доступно для предпросмотра
1300
11:30
30.01.2025
imageИзображение не доступно для предпросмотра
(PHP) Type Juggling
Этот пост начну с предповествования.
У различных языков программирования разный подход к типизации - то есть к тому, насколько строго ЯП будет относиться к типам переменным (int, float, string и т.д.). Здесь будет идти речь о свободно типизированных языках программирования (eng: loosely typed), а в частности о PHP, как о ЯП, который собрал в себе наиболее интересные штуки, о которых рассказано далее. Данные языки стараются "предугадывать", что имел в виду программист или пользователь и делать внутри неявное преобразование переменных в другие типы. К слову, некоторые подходы могут быть применимы и к другим свободно типизорованным ЯП, например Perl, JavaScript, но у них есть своя специфика, о которой здесь рассказывать не буду.
Итак,
🟪 Type Juggling - автоматическая конвертация типов в свободно типизированных языках программирования.
По своей сути это является особенностью языка, а не уязвимостью. Тем не менее, неаккуратное ее использование зачастую приводит к неожиданным последствиям, которые зачастую результируют в проблемы безопасности.
🟣 Тип:
Programming Language, Web, Server-Side.
Наибольший интерес в данном ключе вызывают операции сравнения. В PHP их два вида:
📝 свободное (loose):
📝 строгое (strict):
И самые интересные моменты всплывают как раз в первом типе.
🟣 Пример уязвимого кода:
В данном случае если пользователь введет что-то, что при преобразовании в int будет давать 0 (например
Еще один интересный пример
Больше подобных сравнений я поместил в скрине к посту (источник)
🟣 Влияние:
Такие штуки помогают обходить разные условные конструкции и критичность будет зависеть от расположения подобной проблемы в коде. Один из наиболее базовых и критичных импактов - возможность обходить контроль доступа при авторизации (сравнение хешей паролей) - тут и появилось понятие "магических хешей" (magic hashes).
🟣 Как защититься?
Использовать строгое (`===`) сравнение и использовать функции
На самом деле, в наши дни такое можно встретить только на CTF, где оно используется очень часто. Последние версии PHP умеют элегантно справляться с подобными проблемами и большинством способов обхода защиты, а даже если и используется более старая версия языка, то обнаружить эту проблему без наличия исходных кодов (и явных признаков от самого приложения) крайне сложно. Но тем не менее, знать о существовании этого очень полезно и может пригодиться во многих сферах работы.
#edu #vuln #programming #web #php #php_type_juggling #magic_hashes #type_juggling
Этот пост начну с предповествования.
У различных языков программирования разный подход к типизации - то есть к тому, насколько строго ЯП будет относиться к типам переменным (int, float, string и т.д.). Здесь будет идти речь о свободно типизированных языках программирования (eng: loosely typed), а в частности о PHP, как о ЯП, который собрал в себе наиболее интересные штуки, о которых рассказано далее. Данные языки стараются "предугадывать", что имел в виду программист или пользователь и делать внутри неявное преобразование переменных в другие типы. К слову, некоторые подходы могут быть применимы и к другим свободно типизорованным ЯП, например Perl, JavaScript, но у них есть своя специфика, о которой здесь рассказывать не буду.
Итак,
По своей сути это является особенностью языка, а не уязвимостью. Тем не менее, неаккуратное ее использование зачастую приводит к неожиданным последствиям, которые зачастую результируют в проблемы безопасности.
Programming Language, Web, Server-Side.
Наибольший интерес в данном ключе вызывают операции сравнения. В PHP их два вида:
==
или !=
===
иди !==
И самые интересные моменты всплывают как раз в первом типе.
if (md5($user_input) == '0e732793752744629114494286417663') { ...
В данном случае если пользователь введет что-то, что при преобразовании в int будет давать 0 (например
GTJ3YSmZ
в md5 будет 0e{digits...}), то условие будет истинным, так как для PHP обе эти строки будут конвертироваться в 0 (данный синтаксис возводит 0 в огромную степень, что результирует в 0).Еще один интересный пример
'abc' == 0
. Данное условие будет истинным, так как в первой строке PHP будет смотреть на ее начало в поиске цифр, по ненахождению которых он будет считать строку нулем. То есть следующее условие также будет истинным: '23abc' == 23
Больше подобных сравнений я поместил в скрине к посту (источник)
Такие штуки помогают обходить разные условные конструкции и критичность будет зависеть от расположения подобной проблемы в коде. Один из наиболее базовых и критичных импактов - возможность обходить контроль доступа при авторизации (сравнение хешей паролей) - тут и появилось понятие "магических хешей" (magic hashes).
Использовать строгое (`===`) сравнение и использовать функции
password_hash()
, password_verify()
и hash_equals()
для работы с хешами и паролями. (Ну и md5 не используйте для этих целей - он уже давно признан старым, оставьте в покое старичка).На самом деле, в наши дни такое можно встретить только на CTF, где оно используется очень часто. Последние версии PHP умеют элегантно справляться с подобными проблемами и большинством способов обхода защиты, а даже если и используется более старая версия языка, то обнаружить эту проблему без наличия исходных кодов (и явных признаков от самого приложения) крайне сложно. Но тем не менее, знать о существовании этого очень полезно и может пригодиться во многих сферах работы.
#edu #vuln #programming #web #php #php_type_juggling #magic_hashes #type_juggling
1100
08:37
30.01.2025
На моё искреннее удивление 0_0 ответы поделились практически по ровну 50/50
Я выделил некоторые проблемы, с котороыми сталкивались вы или я сам и как их можно решить
Часть 1
Часть 2
➡️ Я боюсь, что мои работы никто не заметит
Решение:
▪️ Продвигайте свои проекты: публикуйте ссылки на Github, активно участвуйте в профильных чатах, а не read-only формат.
▪️ Ведите личный блог в виде сайтика или Telegram-канала, где будете делиться своими наработками.
▪️ Ребята уже в 16 лет выступают на крупных конфах, чем вы хуже? Абсолютно точно ничем. Поэтому, даже если есть страх выступления/сцены, то возможно его стоит перебороть.
➡️ Я не знаю, как рассказать о своём вкладе в командные проекты
Решение:
▪️ Описывайте конкретные задачи, за которые вы отвечали. Это же относиться к резюме. Например: "Я в команде Аудита занимался автоматизацией, т.к. мне были выданы доступы к N сотен объектов, безопасность которых нужно проверять постоянно." Что-нибудь в таком духе)
▪️ Упоминайте, какие навыки вы использовали или приобрели в процессе работы. К примеру у меня первая запись в трудовой книжке - это работа младшим аналитиком. Я занимался ручной разметкой сырых данных для нейросети. Изучал алгоритмы и подходы машинного обучения.
Я думаю вам стало понятнее, как пробиться на работу и те 168 юзеров, кто проголосовами за Да, есть проблемы смогут их разрешить)
P.S. важная сноска. Последнее время много пишут с просьбой оценить резюме. Ребят, это занимает достаточно времени. Поэтому в порядке очереди + по настроению на это отвечаю. Для всего остального есть расчётный счёт :)
Если остались какие-то глобальные вопросы, то задавайте в комментариях к этому посту и отвечу в следующей части, если наберём на неё!
🌚 @poxek | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча
Я выделил некоторые проблемы, с котороыми сталкивались вы или я сам и как их можно решить
Часть 1
Часть 2
Решение:
Решение:
Я думаю вам стало понятнее, как пробиться на работу и те 168 юзеров, кто проголосовами за Да, есть проблемы смогут их разрешить)
Если остались какие-то глобальные вопросы, то задавайте в комментариях к этому посту и отвечу в следующей части, если наберём на неё!
2400
09:09
28.01.2025
На моё искреннее удивление 0_0 ответы поделились практически по ровну 50/50
Я выделил некоторые проблемы, с котороыми сталкивались вы или я сам и как их можно решить
Часть 1
Часть 2
➡️ У меня нет опыта работы, а все требуют проекты и достижения
Решение:
▪️ Участвуйте в CTF (Capture the Flag) соревнованиях. Даже начинающие задачи могут быть значимым вкладом в портфолио.
▪️ Опишите выполненные учебные проекты, например, анализ уязвимостей или создание простых систем безопасности.
▪️ Учавствуйте в BugBounty, сейчас этот рынок РФ быстро растёт и уже с прошлого года вижу как в вакансиях появился новый пункт в разделе Будет плюсом об участии в багбаунти. Понятно, что надо и баги найти, а не просто зарегаться :D
➡️ Я не знаю, что добавить в портфолио, чтобы это заинтересовало работодателей
Решение:
▪️ Пишите writeup'ы (райтапы) по лабам HackTheBox/TryHackMe/PortSwigger Academy. С помощью грамотного описания как вы поломали что-то вы улучшите: понимание темы/уязвимости/системы, навык написания отчётов (что нужно не только для техписов/аналитиков), грамотную подачу мыслей.
▪️ Документируйте свои исследования: анализ уязвимостей, best practice использование инструментов, какие-то автоматизации. К примеру был кейс, когда пришёл одному парню в компании1 дали задачу написать крутой сетевой сканер (типо naabu от Project Discovery, только тогда naabu ещё не существовало)). В итоге парня сократили в компании1, т.к. сказали что разработка больше не нужна. Он пришёл на собес к одной из ИБ компаний в России и чё-то как-то начал рассказывать и когда он сказал, чем он занимался и что у него уже есть на руках, то его практически сразу взяли на работу. Ведь наши знаний, как кандидата на место в компанию, могут стоить для компании кратно дороже, чем мы их сами оцениваем)
➡️ Я не умею правильно оформить своё портфолио
Решение:
▪️ Используйте GitHub, как платформу для публикации проектов. Систематизируйте репозитории по категориям. Делитесь с сообществом своими наработками, компаниям это нравится.
▪️ Не надо думать, что вы дофига дизигнер и нарисуете сами или через какой-то сервис генерации красивое, красочное резюме. Когда ко мне приходят с оценкой резюме и я вижу каракули — практически всегда это выглядит как детская поделка на субботнем утренике. У нас есть генератор резюме на hh, как стандарт. HRы в крупных компаниях тратят буквально несколько секунд на беглый осмотр вашего резюме. Всё что не укладывается в стандартизированный формат, будет либо скипнуто, либо запомниться недовольством о вашем резюме.
➡️ Мои проекты выглядят слишком простыми — как показать свой потенциал?
Решение:
▪️ Сходи к психологу и проработай свой синдром самозванца. Скромным не дают много деняг, потому что они не умеют требовать.
▪️ Добавляйте пояснения, чего вы хотели достичь проектом и какие выводы сделали. Например: "Задача проекта — понять механизмы SQL-инъекций и предложить эффективные защиты."
▪️ Покажите процесс решения задачи: от поиска проблемы до её устранения. Т.е. опишите ваш flow (не переводится) мышления, тогда либо вашему будущему руководителю, либо HRу будет понятно, как вы думаете и подходит ли ваше мышление для отдела.
▪️ Если всё ещё счиатете проекты простыми, то выходите из зоны комфорта и ставьте цели кратно сложнее. Даже если не добъётесь конечного результата, за вами уже будет ковровая дорожка.
🌚 @poxek | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча
Я выделил некоторые проблемы, с котороыми сталкивались вы или я сам и как их можно решить
Часть 1
Часть 2
Решение:
Решение:
Решение:
Решение:
2100
09:09
28.01.2025
Вопрос к студентам и начинающим в ИБ
3000
10:11
26.01.2025
Точно, сегодня же день студента, а коли большая часть моей аудитории студенты - поздравляю вас всех, мои дорогие, желаю вам автоматов в зачетке, а не в руках, успешного закрытия сессий, зачётов, экзаменов и сдачи дипломов.
Вы наше будущее в ИБ, поэтому уж постарайся исправить все косяки за нами :}
С днём студента!
Вы наше будущее в ИБ, поэтому уж постарайся исправить все косяки за нами :}
С днём студента!
3300
12:44
25.01.2025
Небольшая заметка про уязвимую конфигурацию nginx при проксировании запросов на S3, которое позволило в том году налутать немного уязвимостей на BugBounty.
Объектные хранилища, совместимые с S3 API, используют два варианта указания имени бакета в запросе.
Virtual-hosted–style
Path-style
При использовании path-style варианта может возникнуть довольно неочевидная проблема с конфигурацией nginx.
Рассмотрим на примере сайта, который проксирует запросы подставляя имя бакета в путь с помощью следующего rewrite правила.
В nginx rewrite применяется к нормализованному пути и если в нем присутствует символ переноса строки %0A, то данное регулярное выражение не сработает, поскольку в нем используются якоря начала и конца строки.
Что в результате приведет к возможности указать любое имя бакета в запросе. Причем декодированный символ %0A в имени объекта не помешает, так как S3 это не файловая система и такие имена разрешены.
Таким образом, если используется публичное объектное хранилище, атакующий может создать в нем свой бакет с произвольным именем и загрузить на него файл foo%0Abar с XSS. Символ %0A в имени объекта должен быть декодированным, поэтому проще всего загрузить объект на него с помощью PUT запроса.
В данном запросе подпись формируется с помощью Hackvertor тегов расширения для Burp Suite.
Если же запрос попадает во внутреннее объектное хранилище, то атакующий может перебирать существующие в системе бакеты, часть из которых может разрешать создание объектов PUT запросом без авторизации. Что в результате также приведет к возможности проэксплуатировать XSS.
Но чаще встречается ситуация, когда проксирование запросов производится только из одной папки, например:
Но даже в данном случае конфигурация будет уязвима из-за разницы обработок переданного пути. Правило location и rewrite работают с нормализованным путем, а proxy_pass, в котором указан URI без пути, отправит ненормализованное значение.
Таким образом для эксплуатации уязвимости необходимо отправить запрос, который в нормализованном виде попадет в location /static/, но будет начинаться с бакета, который контролирует атакующий.
Как и в прошлом примере наличие в имени объекта символов %0A и /../ не помешают эксплуатации, так как это не файловая система и такой объект можно создать PUT запросом.
Также, если вы планируете искать подобные мисконфиги блэкбоксом, то нужно учитывать, что ошибки NoSuchObject и NoSuchBucket часто заменяют на дефолтную страницу 404, что может помешать.
Обойти это можно вызывая ошибки с кодом, отличным от 404, например отправляя PUT запрос без указания Content-Length.
Объектные хранилища, совместимые с S3 API, используют два варианта указания имени бакета в запросе.
Virtual-hosted–style
GET /object-name HTTP/1.1
Host: bucket-name.s3endpoint
Path-style
GET /bucket-name/objectname HTTP/1.1
Host: s3endpoint
При использовании path-style варианта может возникнуть довольно неочевидная проблема с конфигурацией nginx.
Рассмотрим на примере сайта, который проксирует запросы подставляя имя бакета в путь с помощью следующего rewrite правила.
location / {
set $s3_name "company-bucket";
set $s3_host "storage.yandexcloud.net";
rewrite ^(.*)$ /$s3_name$1 break;
proxy_pass https://$s3_host;
В nginx rewrite применяется к нормализованному пути и если в нем присутствует символ переноса строки %0A, то данное регулярное выражение не сработает, поскольку в нем используются якоря начала и конца строки.
http://example.tld/test/test.html
=
https://storage.yandexcloud.net/company-bucket/test/test.html
http://example.tld/test/foo%0Abar
=
https://storage.yandexcloud.net/test/foo%0Abar
Что в результате приведет к возможности указать любое имя бакета в запросе. Причем декодированный символ %0A в имени объекта не помешает, так как S3 это не файловая система и такие имена разрешены.
Таким образом, если используется публичное объектное хранилище, атакующий может создать в нем свой бакет с произвольным именем и загрузить на него файл foo%0Abar с XSS. Символ %0A в имени объекта должен быть декодированным, поэтому проще всего загрузить объект на него с помощью PUT запроса.
В данном запросе подпись формируется с помощью Hackvertor тегов расширения для Burp Suite.
PUT /bucket-name/foo%0Abar HTTP/2
Host: storage.yandexcloud.net
Content-Type: text/html
Authorization: AWS ##ACCESS_KEY##:<@base64><@hex2ascii><@hmac_sha1('##SECRET-KEY##')><@d_burp_url>PUT%0A%0Atext/html%0A<@date("EEE, dd MMM yyyy HH:mm:ss z","GMT")/>%0A/bucket-name/foo%250Abar<@/d_burp_url><@/hmac_sha1><@/hex2ascii><@/base64>
Date: <@date("EEE, dd MMM yyyy HH:mm:ss z","GMT")/>
Content-Length: 25
<script>alert(1)</script>
Если же запрос попадает во внутреннее объектное хранилище, то атакующий может перебирать существующие в системе бакеты, часть из которых может разрешать создание объектов PUT запросом без авторизации. Что в результате также приведет к возможности проэксплуатировать XSS.
Но чаще встречается ситуация, когда проксирование запросов производится только из одной папки, например:
location /static/ {
set $s3_name "company-bucket";
set $s3_host "storage.yandexcloud.net";
rewrite ^(.*)$ /$s3_name$1 break;
proxy_pass https://$s3_host;
Но даже в данном случае конфигурация будет уязвима из-за разницы обработок переданного пути. Правило location и rewrite работают с нормализованным путем, а proxy_pass, в котором указан URI без пути, отправит ненормализованное значение.
Таким образом для эксплуатации уязвимости необходимо отправить запрос, который в нормализованном виде попадет в location /static/, но будет начинаться с бакета, который контролирует атакующий.
http://example.tld/attacker-bucket/..%2Fstatic/foo%0Abar
=
https://storage.yandexcloud.net/attacker-bucket/..%2Fstatic/foo%0Abar
Как и в прошлом примере наличие в имени объекта символов %0A и /../ не помешают эксплуатации, так как это не файловая система и такой объект можно создать PUT запросом.
Также, если вы планируете искать подобные мисконфиги блэкбоксом, то нужно учитывать, что ошибки NoSuchObject и NoSuchBucket часто заменяют на дефолтную страницу 404, что может помешать.
Обойти это можно вызывая ошибки с кодом, отличным от 404, например отправляя PUT запрос без указания Content-Length.
PUT /attacker-bucket/..%2Fstatic/foo%0Abar HTTP/1.1
Host: example.tld
Connection: close
3500
10:50
23.01.2025
1. Разобьет стеклянную дверь кувалдой.
2. Успеет взломать и сделать все что надо до того как охрана надает по тыкве.
Поэтому члены команды пентеста в Бастионе решили сделать пробив офиса и показать архитектурные косяки множества СКУД. Как сис админ по первой работе, я помню какие же дырявые были у нас в госке СКУДы. Некоторые были такие слабые (магниты, как часть системы), что дверь можно было открыть просто приложив усилие. А некоторые ... ну ладно, что-то меня понесло)
Представляю вашему вниманию
#redteam #bastion #СКУД #RFID
Удержаться от знакомства с новой СКУД оказалось поистине «невыполнимой» миссией. В конце концов, кто, если не мы, протестирует безопасность компании, которая отвечает за безопасность других? «Мы» — это эксперты Бастиона по программно-аппаратному взлому: Иван Глинкин и Алексей Петренко.
Подрядчик установил в офисе довольно дорогие гаджеты: 7-дюймовый экран, широкоугольная камера, инфракрасная подсветка для работы в полной темноте. По заявлениям производителя, такие терминалы узнают человека за доли секунды с точностью 99%, запоминают тысячи лиц и способны идентифицировать людей в ковидных масках.
3700
11:26
22.01.2025
1. Разобьет стеклянную дверь кувалдой.
2. Успеет взломать и сделать все что надо до того как охрана надает по тыкве.
Поэтому члены команды пентеста в Бастионе решили сделать пробив офиса и показать архитектурные косяки множества СКУД. Как сис админ по первой работе, я помню какие же дырявые были у нас в госке СКУДы. Некоторые были такие слабые (магниты, как часть системы), что дверь можно было открыть просто приложив усилие. А некоторые ... ну ладно, что-то меня понесло)
Представляю вашему вниманию
#redteam #bastion #СКУД #RFID
Удержаться от знакомства с новой СКУД оказалось поистине «невыполнимой» миссией. В конце концов, кто, если не мы, протестирует безопасность компании, которая отвечает за безопасность других? «Мы» — это эксперты Бастиона по программно-аппаратному взлому: Иван Глинкин и Алексей Петренко.
Подрядчик установил в офисе довольно дорогие гаджеты: 7-дюймовый экран, широкоугольная камера, инфракрасная подсветка для работы в полной темноте. По заявлениям производителя, такие терминалы узнают человека за доли секунды с точностью 99%, запоминают тысячи лиц и способны идентифицировать людей в ковидных масках.
3700
11:26
22.01.2025
close
Отзывы канала
Отзывов нет
Лучшие в тематике
Новинки в тематике
Выбрано
0
каналов на сумму:0.00₽
Подписчики:
0
Просмотры:
Перейти в корзинуКупить за:0.00₽
Комментарий