Компания Radware сообщила о новой критической уязвимости безопасности ChatGPT, получившей название ShadowLeak.
ShadowLeak эксплуатирует возможность автономного исследования интернета ИИ-агентом Deep Research, интегрированным в ChatGPT. Злоумышленник отправляет специально сформированное электронное письмо с невидимыми инструкциями, которые агент обрабатывает самостоятельно в облаке OpenAI. В процессе анализа почты и запросов агент на сервере собирает и отправляет конфиденциальную информацию на контролируемый хакерами сервер, полностью обходя конечные устройства жертвы и традиционные средства защиты.Исследование показывает, что подобные утечки данных от ИИ-агентов с каждым годом будут становиться всё серьёзнее, требуя от компаний усиленного контроля и надзора за интеграцией ИИ.
OpenAI уже выпустила патчи, устраняющие уязвимость.
Источник: ixbt
Подписывайся на 127.0.0.1
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from НеКасперский
Ниндзя
CERT-UA зафиксировал атаки UAC-0245 на украинских офицеров через Signal.
Целями хакеров стали члены Союза украинских офицеров, которые используют Signal именно из-за его репутации безопасного канала связи.
Они рассылали ZIP-архивы под видом документов о задержаниях на границе. Внутри архива лежал XLL-файл, который при открытии в Excel разворачивал целую инфраструктуру. Дроппер размещал исполняемый файл в автозагрузку, загрузчик в XLSTART, а PNG-файл содержал зашифрованный шелл-код.
Бэкдор, написанный на C, поддерживает сбор информации, выполнение команд, перехват скриншотов и передачу файлов. Связь идёт через TCP после последовательного стука в четыре порта. Данные сжимаются MSZIP и фрагментируются при превышении 65 КБ.
Все компоненты малвари напичканы проверками на запуск в песочнице. Он проверяет отсутствия
НеКасперский
CERT-UA зафиксировал атаки UAC-0245 на украинских офицеров через Signal.
Целями хакеров стали члены Союза украинских офицеров, которые используют Signal именно из-за его репутации безопасного канала связи.
Они рассылали ZIP-архивы под видом документов о задержаниях на границе. Внутри архива лежал XLL-файл, который при открытии в Excel разворачивал целую инфраструктуру. Дроппер размещал исполняемый файл в автозагрузку, загрузчик в XLSTART, а PNG-файл содержал зашифрованный шелл-код.
Бэкдор, написанный на C, поддерживает сбор информации, выполнение команд, перехват скриншотов и передачу файлов. Связь идёт через TCP после последовательного стука в четыре порта. Данные сжимаются MSZIP и фрагментируются при превышении 65 КБ.
Все компоненты малвари напичканы проверками на запуск в песочнице. Он проверяет отсутствия
wine_get_unix_file_name, ищет артефакты гипервизоров в BIOS, и даже замеряет времени выполнения CPUID через RDTSC, потому что в песочнице, как правило, эти операции выполняются дольше. Поймать шпиона в лабораторных условиях почти невозможно.НеКасперский
Можно использовать как чек-лист при старте нового проекта
https://beagreatengineer.github.io/how-to-develop-perfect-crud/
Подписывайся на 127.0.0.1
https://beagreatengineer.github.io/how-to-develop-perfect-crud/
Подписывайся на 127.0.0.1
Сегодня так глубоко погрузился в ядро Linux(глубже некуда), что еле-еле выбрался оттуда. Хочу здесь оставить важную шпаргалку.
Итак, есть 4 вызова системных, которые описывают жизнь процесса, это clone execve exit wait.
Запустил strace, чтобы увидеть полный цикл своими глазами. Настроил фильтры и вывел результат в файл /tmp/trace.log
Итак, вот команда:
Ниже привел структуру всего этого дела:
И вот trace.log:
Что здесь можно отметить:
*bash₀ запустил strace
*strace создал процесс bash₁ под наблюдением
*bash₁ выполнил clone() и породил bash₂
*bash₂ заменил себя программой ls (execve) и завершился (exit_group)
*bash₁ дождался завершения ребёнка (wait4) и сам вышел (exit_group)
*strace записал всю цепочку в /tmp/trace.log
Если коротко, то
Итак, есть 4 вызова системных, которые описывают жизнь процесса, это clone execve exit wait.
Запустил strace, чтобы увидеть полный цикл своими глазами. Настроил фильтры и вывел результат в файл /tmp/trace.log
Итак, вот команда:
strace -f -e trace=clone,execve,wait4,exit_group bash -c 'ls & wait'
Ниже привел структуру всего этого дела:
bash₀ #исходный терминал
└── strace
└── bash₁ #bash под наблюдением strace
└── bash₂ → execve("/usr/bin/ls") #выполнил ls и завершился
И вот trace.log:
root@terraform:/proc/sys# cat /tmp/trace.log
3598036 execve("/usr/bin/bash", ["bash", "-c", "ls & wait"], 0x7ffe794d47c8 /* 25 vars */) = 0
3598036 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f5fde19fa10) = 3598037
3598036 wait4(-1, <unfinished ...>
3598037 execve("/usr/bin/ls", ["ls"], 0x5640fac45c20 /* 25 vars */) = 0
3598037 exit_group(0) = ?
3598037 +++ exited with 0 +++
3598036 <... wait4 resumed>[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3598037
3598036 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3598037, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
3598036 wait4(-1, 0x7fff10cad250, WNOHANG, NULL) = -1 ECHILD (No child processes)
3598036 exit_group(0) = ?
3598036 +++ exited with 0 +++
Что здесь можно отметить:
*bash₀ запустил strace
*strace создал процесс bash₁ под наблюдением
*bash₁ выполнил clone() и породил bash₂
*bash₂ заменил себя программой ls (execve) и завершился (exit_group)
*bash₁ дождался завершения ребёнка (wait4) и сам вышел (exit_group)
*strace записал всю цепочку в /tmp/trace.log
Если коротко, то
clone → execve → exit_group (child) → wait4 → exit_group (parent)
Подписывайся на 127.0.0.1Прособесился с опытным сисадмином(Windows), у которого 17+ лет опыта для проверки своей экспертизы и выявления точек для роста. Доволен результатом и благодарен Сергею.
Его чат: https://xn--r1a.website/+xe0zRLVDudxiYTFi
Подписывайся на 127.0.0.1
Его чат: https://xn--r1a.website/+xe0zRLVDudxiYTFi
Подписывайся на 127.0.0.1
Forwarded from ᅠ
Решил проверить свою экспертизу в Windows и назначили с Сергеем встречу.
Сергей прособесил по темам: сети, Windows, резервное копирование и т.д. Собеседование длилось около часа.
Остались только хорошие впечатления.
Думал, что от А до Я понимаю такие базовые вещи, как DNS и NAT, различие групповых политик компьютера от политик пользователя, как эти политики применяются, но во время собеседования вскрылись некоторые пробелы. Не очень приятно осознавать, что в таких, казалось бы, простых темах можно «посыпаться», если попросят описать технологию более детально.
Спросит ли кто-то настолько глубоко — это уже другой вопрос, но приятно понимать, что если вдруг спросят, ты сможешь спокойно и чётко объяснить, что к чему. И интервьюеру тоже приятно услышать развернутый, уверенный ответ.
Многие даже опытные специалисты могут «плавать» в базовых вещах. Нужно ли им вникать так глубоко или нет — отдельная тема, но на собеседовании это часто становится решающим моментом.
Мне один знакомый рассказывал, как проходил собеседование на DevOps в компанию: успешно прошёл технический этап, его пригласили на финальный разговор с руководителем. Тот спросил: «Что такое ARP?» И угадайте что? Он, к сожалению, не смог объяснить тему в деталях — и его не взяли. Так что какой интервьюер попадётся и спросит ли он про ARP или SOA-запись, никто не знает.
Если коротко, рекомендую прособеседоваться с Сергеем, чтобы проверить свою экспертизу в сетях, Windows и резервном копировании и т.д. Я изначально хотел поговорить про Linux, но так как Сергей эксперт именно в Windows-инфраструктуре(более 17 лет опыта), мы сосредоточились на этой теме. Зато получилась отличная тренировка по сетям и базовым вещам, которые спрашивают везде, независимо от того, работаешь ли ты в Linux- или Windows-среде.
Одного часа маловато — многие темы не успели разобрать подробно, поэтому советую либо брать два часа, либо заранее выбрать только те темы, по которым хотите углублённо пообщаться в рамках часа. Всем успехов!
Сергей прособесил по темам: сети, Windows, резервное копирование и т.д. Собеседование длилось около часа.
Остались только хорошие впечатления.
Думал, что от А до Я понимаю такие базовые вещи, как DNS и NAT, различие групповых политик компьютера от политик пользователя, как эти политики применяются, но во время собеседования вскрылись некоторые пробелы. Не очень приятно осознавать, что в таких, казалось бы, простых темах можно «посыпаться», если попросят описать технологию более детально.
Спросит ли кто-то настолько глубоко — это уже другой вопрос, но приятно понимать, что если вдруг спросят, ты сможешь спокойно и чётко объяснить, что к чему. И интервьюеру тоже приятно услышать развернутый, уверенный ответ.
Многие даже опытные специалисты могут «плавать» в базовых вещах. Нужно ли им вникать так глубоко или нет — отдельная тема, но на собеседовании это часто становится решающим моментом.
Мне один знакомый рассказывал, как проходил собеседование на DevOps в компанию: успешно прошёл технический этап, его пригласили на финальный разговор с руководителем. Тот спросил: «Что такое ARP?» И угадайте что? Он, к сожалению, не смог объяснить тему в деталях — и его не взяли. Так что какой интервьюер попадётся и спросит ли он про ARP или SOA-запись, никто не знает.
Если коротко, рекомендую прособеседоваться с Сергеем, чтобы проверить свою экспертизу в сетях, Windows и резервном копировании и т.д. Я изначально хотел поговорить про Linux, но так как Сергей эксперт именно в Windows-инфраструктуре(более 17 лет опыта), мы сосредоточились на этой теме. Зато получилась отличная тренировка по сетям и базовым вещам, которые спрашивают везде, независимо от того, работаешь ли ты в Linux- или Windows-среде.
Одного часа маловато — многие темы не успели разобрать подробно, поэтому советую либо брать два часа, либо заранее выбрать только те темы, по которым хотите углублённо пообщаться в рамках часа. Всем успехов!
👀2
Media is too big
VIEW IN TELEGRAM
Собеседование для проверки знаний по сетям и Active Directory
00:28 - DNS
01:40 - какие типы DNS зон существуют
02:16 - зона прямого просмотра и зона обратного просмотра
03:18 - в зоне прямого просмотра какие типы DNS записей ты знаешь? Зачем они нужны?
05:00 - пробел по MX
06:18 - ответ по MX
06:35 - зачем нужна А запись?
08:35 - PTR записи
09:15 - еще какие есть записи
09:44 - записи типа TXT(SPF,DKIM,DMARC)
10:30 - остальные записи
10:52 - SOA (start of authority)
11:25 - CNAME
12:40 - как происходит разрешение DNS записей
14:30 - чем отличается рекурсивный от итеративного
16:00 - корневые серверы за что отвечают. За какую зону
21:02 - не нужен DNS сервер провайдера
21:38 - что такое NAT
27:15 - при NAT меняется порт
30:00 - как одна машина находит другую машину в сети
35:57 - куда отправляем ARP запрос
36:33 - с чего мы взяли что IP находится в той же сети
37:36 - как понимаем в одной ли подсети находится устройство
38:40 - открытие TCP
39:57 - аутентификация пошла (Kerberos)
42:26 - AD 5 ролей FSMO
45:38 - по какому протоколу происходит репликация внутри домена
46:11 - DFSR SYSVOL
47:00 - RPC
47:15 - какой протокол используется для подключения к каталогу
47:35 - групповые политики проектировал?
50:54 - резервное копирование
52:05 - Copy-on-write
54:15 - SQL
55:55 - фидбек
Подписывайся на 127.0.0.1
00:28 - DNS
01:40 - какие типы DNS зон существуют
02:16 - зона прямого просмотра и зона обратного просмотра
03:18 - в зоне прямого просмотра какие типы DNS записей ты знаешь? Зачем они нужны?
05:00 - пробел по MX
06:18 - ответ по MX
06:35 - зачем нужна А запись?
08:35 - PTR записи
09:15 - еще какие есть записи
09:44 - записи типа TXT(SPF,DKIM,DMARC)
10:30 - остальные записи
10:52 - SOA (start of authority)
11:25 - CNAME
12:40 - как происходит разрешение DNS записей
14:30 - чем отличается рекурсивный от итеративного
16:00 - корневые серверы за что отвечают. За какую зону
21:02 - не нужен DNS сервер провайдера
21:38 - что такое NAT
27:15 - при NAT меняется порт
30:00 - как одна машина находит другую машину в сети
35:57 - куда отправляем ARP запрос
36:33 - с чего мы взяли что IP находится в той же сети
37:36 - как понимаем в одной ли подсети находится устройство
38:40 - открытие TCP
39:57 - аутентификация пошла (Kerberos)
42:26 - AD 5 ролей FSMO
45:38 - по какому протоколу происходит репликация внутри домена
46:11 - DFSR SYSVOL
47:00 - RPC
47:15 - какой протокол используется для подключения к каталогу
47:35 - групповые политики проектировал?
50:54 - резервное копирование
52:05 - Copy-on-write
54:15 - SQL
55:55 - фидбек
Подписывайся на 127.0.0.1
🔥5👀5 1
https://www.lizrice.com/
Если прочитаешь эту книгу и поймёшь хотя бы 70% — поздравляю, ты почти DevSecOps-сеньор с пропиской в Kubernetes
Речь не про «да, я разворачивал отказоустойчивый кластер», а про настоящее понимание, что под капотом.
Ведь Kubernetes сам по себе не магия — он просто оркестрирует контейнеры.
А контейнер — это не коробка с приложением, а хитрая комбинация пространств имён, cgroups и немного Linux-черной магии.
И вот когда ты реально понимаешь, как всё это живёт в ядре, kube-сервисы и поды начинают складываться в осмысленную картину, а не в YAML-хаос.
Без спойлеров, просто парочка скринов из книги.
Подписывайся на 127.0.0.1
Please open Telegram to view this post
VIEW IN TELEGRAM
Liz Rice - containers, eBPF, security, Kubernetes, software engineering
Liz Rice is a software engineer and entrepreneur based in London, UK. As Chief Open Source Officer for eBPF experts Isovalent, she travels the world speaking about containers, security and distributed systems. Her programming language of choice is Golang…
Вы тоже, скорее всего, получали этой весной в Telegram странные сообщения от друзей по типу “смотри, это ты?” вместе с APK-файлом.
Я решил разобрать один из таких “подарков”. Не то чтобы я гуру реверса, но стало интересно посмотреть, что у него внутри и как он работает. Малварь оказался довольно примитивным, почти без обфускации, сделан по учебнику.
APK маскировался под приложение “Видео (317)”, а внутри сидел полноценный Android-троян. Приложение запрашивает все критически опасные разрешения: читать и отправлять SMS, перехватывать уведомления, получать доступ к данным SIM-карт, управлять звонками, запускаться после перезагрузки и собирать информацию об устройстве(скрины). В пакете 'com.example.researchapp' -- почти полный набор компонентов для ботнета:
сервисы для отправки SMS без ведома пользователя, перехватчики входящих сообщений, обработчики команд, сборщики информации и автозапуск.
Троян регулярно связывается с сервером, получает команды и, при необходимости, может выполнять действия на устройстве от имени пользователя.
Самое интересное "то адрес панели управления был спрятан под AES-шифрованием, но расшифровывался без особых проблем. В итоге реальный C2 оказался здесь: http://62[.]60[.]226[.]104:5000 .
Порт снаружи не отвечает, скорее, он открыт локально и запросы просто блокируется firewall-ом. Если коротко, то С2 живой.
Также в коде попалась забавная строка 'https://www[.]pornhub[.]com/'
В целом это действительно рабочая малварь, но собранная без какого-то большого опыта. Логика прозрачная, архитектура простая, связь с сервером прямолинейная, защита минимальная. Тем не менее разобрать её было любопытно, а заодно полезно увидеть, как подобные вещи устроены изнутри.
Подписывайся на 127.0.0.1
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👀1