AppSecs – Telegram
Forwarded from DevSecOps Talks
Semgrep Academy: новые курсы!

Всем привет!

Недавно мы писали про Semgrep Academy (вот тут). На тот момент, курсов было немного, но! Недавно их стало больше!

Были добавлены:
🍭 API Security Mini Course (16 уроков, 30 минут видео)
🍭 Secure Coding (70 уроков, 2 часа виде)
🍭 Semgrep 101 (27 уроков, 1 час видео)

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

Надеемся, что проект будет развиваться, появятся лабораторные работы и, возможно, экзамены ☺️
Forwarded from HaHacking
🟥  #мероприятия #заметки #offense #defense

➡️На YouTube канале Positive Events уже выкладываются записи докладов с прошедшего киберфестиваля PHDays 2; Представляю Вашему вниманию перечень докладов, запавших мне в сердце😊

🧩 Плейлист ‟Киберфестиваль PHDays 2
🧩 Трансляция на сайте PHDays [ru/en]


🔥 OFFENSE

⭐️Вам письмо: старые новые атаки на почту
(@hahacking 🐇 + @slonser_notes 🐘 )
Уязвимость современной электронной почты к инъекциям;


⭐️Учат в школе” (@webpwn 💣)
Поиск и эксплуатация уязвимостей в системах обучения хакеров;


⭐️Trust no one: red-teaming-инфраструктура на стероидах” (@purple_medved)
Создание архитектуры и администрирование инфраструктуры для проведения пентестов в формате red teaming, инструменты автоматизации malware development и развертывание атакующей инфраструктуры;


⭐️Регионы памяти, или Как я не туда шеллкод загрузил” (@RedTeambro)
О важности определения верного места для полезной нагрузки, о предотвращении множества детектов антивирусом и о том, как атакующему оставаться скрытым от глаз защитных средств;


⭐️Без лица: предъявите вашу кавычку
Риски безопасности биометрических считывателей;

      ...


🔗 DEFENSE

⭐️Операция «Триангуляция»: почему не надо атаковать исследователей
История о самой сложной цепочке атак и шпионском ПО, которые когда-либо были обнаружены специалистами «Лаборатории Касперского»;


⭐️Не самые типичные методы и инструменты, которые использовали злоумышленники в атаках на российские организации

⭐️RCE-уязвимость в Managed ClickHouse глазами специалиста SOC в Yandex Cloud

⭐️Было ваше — стало наше: что полезного можно найти на серверах злоумышленников

   ⭐️  ‟SCA, или как правильно создавать и анализировать SBOM под каждый используемый язык”  (@bh_cat)
Мир управления зависимостями и безопасности открытого программного обеспечения;

...


Спасибо организаторам за организацию площадки, а докладчикам – за их труд и ценный вклад в сообщество!

➡️Приятного просмотра!

   @HaHacking  🐇
Please open Telegram to view this post
VIEW IN TELEGRAM
Доклад был хорош
Вы наверняка знаете, но если вдруг не знаете, то PayloadsAllTheThings — это уникальный репозиторий, наполненный полезными payload-ами и методами обхода.

Например, вот кейс его использования.

#cheatsheet #payload
Forwarded from PurpleBear (Vadim Shelest)
Меня иногда просят посоветовать self-hosted лабы по различным доменам знаний деятельности пентестеров для наработки и совершенствования навыков на практике, поэтому ловите небольшую подборку:

☑️ Kubernetes Goat - Vulnerable by design Kubernetes cluster
☑️ GOAD - Game of Active Directory
☑️
DVWA - Damn Vulnerable Web Application
☑️ DVWS - Damn Vulnerable Web Sockets
☑️ DVHMA - Damn Vulnerable Hybrid Mobile App (Android)
☑️ DVIA - Damn Vulnerable iOS App
☑️ DVIA2 - Damn Vulnerable iOS App v2
☑️ CI/CD Goat - Vulnerable CI/CD environment
☑️ DVGA - Damn Vulnerable GraphQL Application
☑️ VAmPI - Vulnerable REST API
☑️ DVSA - Damn Vulnerable Serverless Application
☑️ DVFaaS - Damn Vulnerable Functions as a Service (AWS Lambda)
☑️ AWS Goat - Damn Vulnerable AWS Infrastructure
☑️ DVCA - Damn Vulnerable Cloud Application (AWS privesc)
☑️ Azure Goat - Damn Vulnerable Azure Infrastructure
☑️ GCP Goat - Damn Vulnerable GCP Infrastructure
☑️ DVTA - Damn Vulnerable Thick Client App
☑️ DVJA - Damn Vulnerable Java (EE) Application
☑️ DVID - Damn Vulnerable IoT Device
☑️ DVAS - Damn Vulnerable Application Scanner
☑️ DVB - Damn Vulnerable Bank
☑️ DVWPS - Damn Vulnerable WordPress Site
☑️ DVNA - Damn Vulnerable NodeJS Application
☑️ DVGM - Damn Vulnerable Grade Management
☑️ Tiredful API - REST API intentionally designed broken App
☑️ DVCSharp - Damn Vulnerable C# Application (API)
☑️ DVRF - Damn Vulnerable Router Firmware
☑️ DVLLMP - Damn Vulnerable LLM Project
☑️ DVLLMA - Damn Vulnerable LLM Agent

Безусловно некоторые из них уже устарели и содержат не самые актуальные баги, а с некоторыми придется повозиться чтобы установить и развернуть, но все же это хорошая отправная точка для погружения в интересующую тематику😎
1🔥1
Взломали Google (почти)

Написал на коленке writeup на таск категории web прошедшего Google CTF.

Из интересного в статье:
- Схема data:,, и как ее можно использовать в своих целях
- Использование event listener
- Особенности fetch() запроса для получения в ответе подконтрольных данных
AppSecs
Взломали Google (почти) Написал на коленке writeup на таск категории web прошедшего Google CTF. Из интересного в статье: - Схема data:,, и как ее можно использовать в своих целях - Использование event listener - Особенности fetch() запроса для получения…
Вредный совет, как можно решать таски (и только таски ctf 🌚), в которых нужен подконтрольный ресурс для отправки эксплойта и получения флага — лабы portswigger, например csrf.

В client-side лабах как правило предоставляется временный сервер для эксплойта. Он доступен в глобальной сети и идеально подходит под такие таски.
Удобно, быстро и бесплатно.
Forwarded from Cybred
https://github.com/gracenolan/Notes

Я инженер по безопасности в Google, и это заметки, сделанные во время подготовки к собеседованиям. Это моя первая работа в сфере безопасности, и многие спрашивали меня, как я учился.

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

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


Learning Tips
Interviewing Tips
Networking
Web Application
Infrastructure (Prod / Cloud) Virtualisation
OS Implementation and Systems
Mitigations
Cryptography, Authentication, Identity
Malware & Reversing
Exploits
Attack Structure
Threat Modeling
Detection
Digital Forensics
Incident Management
Coding & Algorithms
Security Themed Coding Challenges
Почему такой Dockerfile считается плохой практикой?


FROM alpine
RUN echo "top-secret" > /password.txt
RUN rm /password.txt


Один слой создает файл, а следующий его удаляет. Если собрать этот образ и затем его запустить, то никаких следов файла password.txt вы не увидите:

vagrant@vagrant:~$ docker run --rm -it sensitive ls /password.txt
ls: /password.txt: No such file or directory


Однако не позволяйте ввести себя в заблуждение — конфиденциальные данные все равно попали в образ. Чтобы убедиться в этом, экспортируйте образ в файл tar с помощью команды docker save и разархивируйте его:


vagrant@vagrant:~$ docker save sensitive > sensitive.tar
vagrant@vagrant:~$ mkdir sensitive
vagrant@vagrant:~$ cd sensitive
vagrant@vagrant:~$ tar -xf ../sensitive.tar
vagrant@vagrant:~/sensitive$ ls
0c247e34f78415b03155dae3d2ec7ed941801aa8aeb3cb4301eab9519302a3b9.json
552e9f7172fe87f322d421aec2b124691cd80edc9ba3fef842b0564e7a86041e
818c5ec07b8ee1d0d3ed6e12875d9d597c210b488e74667a03a58cd43dc9be1a
8e635d6264340a45901f63d2a18ea5bc8c680919e07191e4ef276860952d0399
manifest.json


Где 0c24...json — конфигурация образа.

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


vagrant@vagrant:~/sensitive$ cat 0c247*.json | jq '.history'
[
{
"created": "2019-10-21T17:21:42.078618181Z",
"created_by": "/bin/sh -c #(nop) ADD
file:fe1f09249227e2da2089afb4d07e16cbf832eeb804120074acd2b8192876cd28 in / "
},
{
"created": "2019-10-21T17:21:42.387111039Z",
"created_by": "/bin/sh -c #(nop) CMD [\"/bin/sh\"]",
"empty_layer": true
},
{
"created": "2019-12-16T13:50:43.914972168Z",
"created_by": "/bin/sh -c echo \"top-secret\" > /password.txt"
},
{
"created": "2019-12-16T13:50:45.085349285Z",
"created_by": "/bin/sh -c rm /password.txt"
}
]


Внутри каталога каждого из слоев находится еще один файл tar с содержимым файловой системы на этом слое. Можно легко извлечь файл password.txt

из каталога соответствующего слоя:

vagrant@vagrant:~/sensitive$ tar -xf 55*/layer.tar
vagrant@vagrant:~/sensitive$ cat password.txt
top-secret

Из этого ясно, что, даже если последующий слой и удаляет его, любой файл, когда-либо существовавший на любом из слоев, можно легко получить путем распаковки образа.

Звучит как таск на цтф 🙃️️️️️️
Подробнее можно почитать книгу O’Reily «Безопасность контейнеров»

#docker
Знали про такой прикол в JS?

j = -9007199254740991000
j === j +1 // true


Максимальное целое число, которое может быть точно представлено в JavaScript, равно 2^53−1, что соответствует 9007199254740991. Числа, превышающие этот предел, теряют точность. Когда вы пытаетесь добавить 1 к числу, значительно превышающему этот предел, происходит потеря точности, и результат остается прежним.

Где это можно применить? Например, в циклах, где можно контролировать начальное и конечное значение для итераций (например, это одна и та же переменная), тем самым вызвать DoS из-за бесконечного цикла.

#js
👍2🔥1
Вкратце знакомимся с DOM Clobbering.

Шаг 1
Из учебника JS узнаем, что:

При чтении HTML браузер генерирует DOM-модель. При этом большинство стандартных HTML-атрибутов становятся свойствами соответствующих объектов.

Например, если тег выглядит как <body id="page">, то у объекта будет свойство body.id = "page".

Глобальный объект предоставляет переменные и функции, доступные в любом месте программы. В браузере это window, а его свойства называются глобальные переменные.

Шаг 2
Из книги JavaScript for Hackers узнаем непосредственно про сам DOM Clobbering: «Затирание (clobbering) DOM это метод, пользующийся преимуществом шаблона кодирования, который проверяет глобальную переменную и когда она не существует, следует иным путём кода.»

Основная идея состоит в том, что вы затираете несуществующую глобальную переменную неким элементом DOM, чаще всего элементом привязки (ancor).

Представьте что у вас имеется следующий код:

let url = window.currentUrl || 'http:///example.com';


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

Для большего понимания в терминологии данной книги «элементы привязки (ancor)» определены здесь: HTMLAnchorElement

Элементы привязки позволяют вам применять атрибут "href" для изменения имеющегося значения затираемого объекта:

<a href="clobbered:1337" id=x></a>
<noscript>
alert(x);//clobbered:1337
alert(typeof x);//object
</noscript>


Т.е. глобальная переменная x затирается с помощью элемента привязки id, а значение переменной задается элементом привязки href.

Шаг 3
Далее, знакомимся с DOM-коллекциями: «Особый перебираемый объект-псевдомассив»

В контексте атаки можно использовать несколько элементов с одним и тем же id или name и это создаёт коллекцию

<a id=x>
<a id=x name=y href=clobbered:1337>
<noscript>
alert(x.y)//clobbered:1337
</noscript>


В приводимом выше примере имеются две совместно используемых привязки атрибута id с одним и тем же значением "x", это формирует DOM-коллекцию, кроме того, вторая привязка обладает атрибутом name, а поскольку это коллекция DOM, вы можете ссылаться на элементы в такой коллекции по имени или индексу, в данном случае мы ссылаемся на вторую привязку по имени "y".

Шаг 4
Этих знаний должно быть достаточно для решения лабораторной работы в PortSwigger Academy, а так же ответа на вопрос из предыдущей подборки


DOM Clobbering Cheatsheet
#js
👍3
1/2

Что можно предложить разрабам вместо .innerHTML, чтобы избежать DOM XSS (без использования фреймворков)?

Исходный код:

<body>
<div id="output"></div>
<noscript src="test1.js"></noscript>
</body>



const userInput = '<img src=x onerror=alert(1)>';
const element = document.getElementById('output');
element.innerHTML = userInput;


Тут сразу стоит сказать, что payload вида <noscript>alert(1)</noscript> не отработает, т.к. браузер парсит (анализирует) строку HTML и создаёт соответствующие DOM-элементы, но браузер только создаёт элемент в DOM, но не выполняет код внутри него. Связано это со спецификацией браузеров.

🔘 1. Вставлять пользовательский ввод как текст

element.innerText = userInput;
element.textContent = userInput;
element.insertAdjacentText('beforeend', userInput);

В этом случае в теге <div> весь HTML код будет отображаться как текст. Не подходит для случаев, когда .innerHTML используется для вставки HTML-кода (например, для добавления новых элементов на сайт, которые зависят от пользовательского ввода)


🔘 2. Использовать CSP.

<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; noscript-src 'self';">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<noscript>Document</noscript>
</head>
<body>
<div id="output"></div>
<noscript src="test1.js"></noscript>
</body>
</html>


В данном примере директивы CSP объявляются через тег <meta> для удобства, но хорошей практикой считается выставление директив через HTTP заголовок, поскольку тег не контролирует контент до объявления тега + отсутствие поддержки некоторых директив посредством объявления через тег

CSP по умолчанию запрещает выполнение inline-скриптов, включая обработчики событий, таких как onerror, если не разрешено явно через 'unsafe-inline', хэши или nonces.

Получается, что тег <noscript> не вставить из-за спецификации браузера, а вставить onerror (да и любой другой обработчик событий) в любой другой тег не получится из-за CSP.
Такую защиту можно обойти, если в CSP будет указана директива ’unsafe-inline’ для скриптов. Возможно, есть еще байпас такого решения, но сходу не нашел
2/2

Две новые технологии, с которыми я знакомлюсь:

🔘 3. Использовать Trusted Types API (TTA)

Основная идея и ее использование хорошо описано в данном видео.

Если вкратце, то браузер позволит вставить в DOM только «доверенные типы» данных. Чтобы использовать данную технологию, добавляем политику CSP с директивой require-trusted-types-for (использование TTA не совместимо с использованием классического CSP).

Пример:

<meta http-equiv="Content-Security-Policy" content="require-trusted-types-for 'noscript';">

Здесь мы говорим, что хотим применять политику TTA в скриптах. Теперь объявим «доверенный тип» my-types в политике CSP:

<meta http-equiv="Content-Security-Policy" content="trusted-types my-types; require-trusted-types-for 'noscript';">


Опишем его:

const escapeHTMLPolicy = window.trustedTypes.createPolicy('my-types', {
createHTML: string => string.replace(/\</g, '&lt;'),
})


Хук createHTML вызывается, когда код пытается произвести изменения в DOM, вставить какую-либо строку, и он эту строку должен обработать. Его обработкой (санитизацией) занимается сам разработчик. В данном примере идет замена в строке символа на закодированный. Здесь так же можно использовать сторонние библиотеки, например DOMPurify:

const escapeHTMLPolicy = trustedTypes.createPolicy('my-types', {
createHTML: (input) => {
// Очистка или проверка входных данных
return DOMPurify.sanitize(input);
},
});


Существует всего три хука: createHTML, createScript, createScriptURL


Данная технология отработает в Google Chrome, выдав ошибку

This document requires 'TrustedHTML' assignment.

Uncaught TypeError: Failed to set the 'innerHTML' property on 'Element': This document requires 'TrustedHTML' assignment.


Но в Firefox ситуация обратная, alert(1) выполнился, а браузер указал, что не знает такой директивы:

Content-Security-Policy: Не удалось обработать неизвестную директиву «require-trusted-types-for»


В этом минус данной технологии, ее не поддерживают все браузеры: https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API


🔘 4. Sanitizer API.
Из того же видео узнаем, что в современных браузерах есть встроенное API для санитизации. В видео два примера, один с явным созданием объекта Sanitizer:

let sanitizer = new Sanitizer();
let b = sanitizer.sanitizeFor("div", userInput);
console.log(b)


Второй — более простой, просто с использованием метода .setHTML() вместо .innerHTML.

const userInput = '<img src=x onerror=alert(1)>';
const element = document.getElementById('output');
element.setHTML(userInput);


В Google Chrome в свежих версиях включен по умолчанию, в Firefox в тестовом режиме, поэтому выключен. Можно включить в настройках (`about:config`): dom.security.sanitizer.enabled

Почитать можно здесь: https://web.dev/articles/sanitizer
🔥1
Недавно установил себе агрегатор новостей. Довольно удобно, все в одном месте, можно собрать сборник про политику, можно на другие темы. Так же есть возможность добавить YouTube каналы. Мб можно еще телеграмм каналы, но пока не разобрался.
Вот список, который у меня собрался на данный момент.
👍4
Intro в client-side уязвимости. Будет полезно знать чуть больше, чем 3 вида XSS и CSRF.

https://wr3dmast3r.gitbook.io/client-side-fundamental
👍5
Еще один ИБ-шный roadmap, в этот раз по специальностям на русском языке с материалами.
Так же в ней выделены перспективные специальности на горизонте 3-5 лет. В основном связано с *SecOps направлениями, ML и крипта.

https://cybersecurity-roadmap.ru
👍3