Новые уязвимости? Часть 4. Атаки NFT Flashloan
Эта уязвимость была обнаружена при AirDrop токенов для проекта BAYC. Владелец NFT мог вызвать функцию claimTokens() и получить взамен токены Apes равные количеству NFT.
Другие проекты, типа NFTX пытаются привнести механизмы DeFi в мир NFT. Другими словами, они блокируют на контракте ваш NFT и дают взамен токены.
При этом NFTX также предлагает флеш займы этих токенов, что по сути является займом данного оригинального NFT.
Получается, что сторонний пользователь может взять займ этого NFT, зайти на проект BYAC и получить бесплатный AirDrop.
Вероятнее всего, аудиторам придется предусматривать и такие развития ситуаций в скором будущем.
#security #phantom
Эта уязвимость была обнаружена при AirDrop токенов для проекта BAYC. Владелец NFT мог вызвать функцию claimTokens() и получить взамен токены Apes равные количеству NFT.
Другие проекты, типа NFTX пытаются привнести механизмы DeFi в мир NFT. Другими словами, они блокируют на контракте ваш NFT и дают взамен токены.
При этом NFTX также предлагает флеш займы этих токенов, что по сути является займом данного оригинального NFT.
Получается, что сторонний пользователь может взять займ этого NFT, зайти на проект BYAC и получить бесплатный AirDrop.
Вероятнее всего, аудиторам придется предусматривать и такие развития ситуаций в скором будущем.
#security #phantom
👍1
Новые уязвимости? Часть 5. Read-Only Reentrancy
Еще одна интересная атака. Попробую объяснить ее просто.
Все мы знаем, что некоторые функции в контрактах защищаются с помощью модификатора nonReentrant или каким-либо другим способом, который предотвращает повторный вход в функцию, до момента ее полного исполнения.
После ее выполнения практически всегда изменяется одна из переменных состояния, например баланс пользователя или пула.
Так вот, несмотря на то, что в external функции ставят защиту, view функции порой обходят стороной. А зря.
Теперь небольшой пример.
Возьмем функцию remove_liquidity(), которая удаляет все токены ликвидности с пула, делает рассылку underling токенов участникам один за одним в цикле, и в конце изменяет стоимость токена и его баланс.
Далее есть view функция get_virtual_price(), на которую полагаются другие протоколы, и которая показывает цену токена.
Хакер, в этих протоколах, мог вызывать view функцию через fallback(), в тот момент когда шла рассылка токенов в remove_liquidity(), и проводить свои манипуляции не до конца измененной ценой данного токена.
Надеюсь более-менее понятно расписал, потому что я сам пару раз запутывался в логике.
Проводя аудит контракта, теперь нам нужно следить и за view функциями, особенно, когда они на полагаются на баланс или цену токенов из стороннего контракта или биржи в целом.
#security #phantom
Еще одна интересная атака. Попробую объяснить ее просто.
Все мы знаем, что некоторые функции в контрактах защищаются с помощью модификатора nonReentrant или каким-либо другим способом, который предотвращает повторный вход в функцию, до момента ее полного исполнения.
После ее выполнения практически всегда изменяется одна из переменных состояния, например баланс пользователя или пула.
Так вот, несмотря на то, что в external функции ставят защиту, view функции порой обходят стороной. А зря.
Теперь небольшой пример.
Возьмем функцию remove_liquidity(), которая удаляет все токены ликвидности с пула, делает рассылку underling токенов участникам один за одним в цикле, и в конце изменяет стоимость токена и его баланс.
Далее есть view функция get_virtual_price(), на которую полагаются другие протоколы, и которая показывает цену токена.
Хакер, в этих протоколах, мог вызывать view функцию через fallback(), в тот момент когда шла рассылка токенов в remove_liquidity(), и проводить свои манипуляции не до конца измененной ценой данного токена.
Надеюсь более-менее понятно расписал, потому что я сам пару раз запутывался в логике.
Проводя аудит контракта, теперь нам нужно следить и за view функциями, особенно, когда они на полагаются на баланс или цену токенов из стороннего контракта или биржи в целом.
#security #phantom
👍1
Пример работы Frontrun ботов
Нашел прекрасное видео, хоть и на английском языке, которое демонстрирует как работают frontrun боты в мемпуле.
Рекомендую к просмотру каждому.
#frontrun #security
Нашел прекрасное видео, хоть и на английском языке, которое демонстрирует как работают frontrun боты в мемпуле.
Рекомендую к просмотру каждому.
#frontrun #security
YouTube
How To Get Front-Run on Ethereum mainnet
In this video, we:
- Cover the concept of front-running
- Write and deploy a smart contract that is vulnerable to front-running
- Put 0.035 ETH (~$8) in the contract
- Submit a transaction that is front-run by several parties, creating a gas-war to be the…
- Cover the concept of front-running
- Write and deploy a smart contract that is vulnerable to front-running
- Put 0.035 ETH (~$8) in the contract
- Submit a transaction that is front-run by several parties, creating a gas-war to be the…
👍2
Код - ловушка
Посмотрите внимательно на код на скрине. Если вы повстречаете его где-либо, то, скорее всего, перед вами типичная honeypot ловушка.
Помните, что address(this).balance всегда включает в себя msg.value данной транзакции.
#security
Посмотрите внимательно на код на скрине. Если вы повстречаете его где-либо, то, скорее всего, перед вами типичная honeypot ловушка.
Помните, что address(this).balance всегда включает в себя msg.value данной транзакции.
#security
👍4
Double Entry Point
На каникулах прочитал об одном интересном эксплойте, который случился с Balancer в 2022 году. Саму статью можно прочитать тут, а я дам краткий пересказ уязвимости.
Balancer позволяет пользователям брать быстрые займы без залога, если они будут возвращены в той же транзакции. Именно в функции flashloan и крылся интересный баг.
Кратко говоря, функция узнавала изначальный баланс имеющихся токенов для займа, высчитывала процент займа и пересылала средства пользователю. Также там была fallback функция receiveFlashLoan(), которая должна была быть определена в контракте пользователя для возврата займа.
После того, как займ возвращался обратно от пользователя, высчитывалась разница в изначальном и конечном балансах, и эта разница пересылалась в другой контракт Balancer, который использовался как сейф.
Так в чем же здесь может быть проблема?
А в том, что контракт функционировал через прокси.
Мы же помним, что в правильном варианте работы логики прокси контрактов, пользователь взаимодействует именно с прокси, который позже переводит все действия в контракт исполнения? Т.е., упрощенно говоря, мы вызываем какую-либо функцию в прокси контракте, она делегирует исполнения в третий контракт.
Так вот, в случае с Balancer пользователь мог взаимодействовать как с прокси контрактов, так и с третьим контрактом напрямую! Это-то и создавало баг double entry point.
В примере эксплойта, который приводится в статье, хакер мог запросить займ токенов из обоих контрактов: прокси и исполнения. Причем в первом случае он брал займ на 100% возможную сумму токенов, а во втором - 0. Это создавало некий баг в конечный расчетах, что приводило к тому, что весь займ токенов переводился в контракт Сейфа, и никто потом больше не мог брать займ под этот токен.
Да, хакер не получал ничего, но и работа сервиса стопорилась.
Мне просто понравился этот баг, и теперь при аудите контрактов, где используется прокси и erc20, я всегда проверяю и эту возможность.
#security #doubleentrypoint
На каникулах прочитал об одном интересном эксплойте, который случился с Balancer в 2022 году. Саму статью можно прочитать тут, а я дам краткий пересказ уязвимости.
Balancer позволяет пользователям брать быстрые займы без залога, если они будут возвращены в той же транзакции. Именно в функции flashloan и крылся интересный баг.
Кратко говоря, функция узнавала изначальный баланс имеющихся токенов для займа, высчитывала процент займа и пересылала средства пользователю. Также там была fallback функция receiveFlashLoan(), которая должна была быть определена в контракте пользователя для возврата займа.
После того, как займ возвращался обратно от пользователя, высчитывалась разница в изначальном и конечном балансах, и эта разница пересылалась в другой контракт Balancer, который использовался как сейф.
Так в чем же здесь может быть проблема?
А в том, что контракт функционировал через прокси.
Мы же помним, что в правильном варианте работы логики прокси контрактов, пользователь взаимодействует именно с прокси, который позже переводит все действия в контракт исполнения? Т.е., упрощенно говоря, мы вызываем какую-либо функцию в прокси контракте, она делегирует исполнения в третий контракт.
Так вот, в случае с Balancer пользователь мог взаимодействовать как с прокси контрактов, так и с третьим контрактом напрямую! Это-то и создавало баг double entry point.
В примере эксплойта, который приводится в статье, хакер мог запросить займ токенов из обоих контрактов: прокси и исполнения. Причем в первом случае он брал займ на 100% возможную сумму токенов, а во втором - 0. Это создавало некий баг в конечный расчетах, что приводило к тому, что весь займ токенов переводился в контракт Сейфа, и никто потом больше не мог брать займ под этот токен.
Да, хакер не получал ничего, но и работа сервиса стопорилась.
Мне просто понравился этот баг, и теперь при аудите контрактов, где используется прокси и erc20, я всегда проверяю и эту возможность.
#security #doubleentrypoint
👍7
Signature Malleability
Нашел интересную ветку в Твиттере с описанием данной уязвимости.
Все подписи содержат в себе значения:
R - a point on the secp256k1 elliptic curve (32 bytes)
S - a point on the secp256k1 elliptic curve (32 bytes)
V - recovery id (1 byte)
Имея на руках подпись и подписанное сообщение, любой пользователь может восстановить адрес, кому эта подпись принадлежит, используя функцию ecrecover(hash, v, r, s).
Уязвимость Signature Malleability может содержать в себе две и более разных подписей для восстановления для одного и того же подписанного сообщения. Это может быть достигнуто изменением оригинальной подписи и недостаточной валидацией.
В данном примере используется модификация подписи EIP2098 (Компактная подпись), которая помещает V (0 или 1) на верх бита S. Это приводит к тому, что подпись становится на 1 бит короче, и теперь нужно, чтобы контракт делал дополнительное действие - разворачивание подписи.
Посмотрите на пример выше на скрине. Тут передается подпись, восстанавливается адрес и сообщение сохраняется в маппинг, чтобы предотвратить replay атаку.
Тем не менее мы можем выполнить эту функцию дважды: с нормальной подписью и, модифицировав ее, с EIP2098.
Чаще всего используется библиотеки от OpenZeppeling. Эта уязвимость возможна на версиях ниже 4.7.3.
Обращайте на это внимание.
#security #ECDSA #signature
Нашел интересную ветку в Твиттере с описанием данной уязвимости.
Все подписи содержат в себе значения:
R - a point on the secp256k1 elliptic curve (32 bytes)
S - a point on the secp256k1 elliptic curve (32 bytes)
V - recovery id (1 byte)
Имея на руках подпись и подписанное сообщение, любой пользователь может восстановить адрес, кому эта подпись принадлежит, используя функцию ecrecover(hash, v, r, s).
Уязвимость Signature Malleability может содержать в себе две и более разных подписей для восстановления для одного и того же подписанного сообщения. Это может быть достигнуто изменением оригинальной подписи и недостаточной валидацией.
В данном примере используется модификация подписи EIP2098 (Компактная подпись), которая помещает V (0 или 1) на верх бита S. Это приводит к тому, что подпись становится на 1 бит короче, и теперь нужно, чтобы контракт делал дополнительное действие - разворачивание подписи.
Посмотрите на пример выше на скрине. Тут передается подпись, восстанавливается адрес и сообщение сохраняется в маппинг, чтобы предотвратить replay атаку.
Тем не менее мы можем выполнить эту функцию дважды: с нормальной подписью и, модифицировав ее, с EIP2098.
Чаще всего используется библиотеки от OpenZeppeling. Эта уязвимость возможна на версиях ниже 4.7.3.
Обращайте на это внимание.
#security #ECDSA #signature
👍3
Signature Malleability 2
Ну, и еще одна уязвимость от того же автора из Твиттер.
Посмотрите на скрин. Вероятно, вы видели или сами реализовывали такое восстановление подписи у себя в контракте.
Но тут чего-то не хватает?
А точнее, тут не хватает валидации S значения!
if (uint256(s) > 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 ) {
return (address(0), RecoverError.InvalidSignatureS);
}
Если открыть контракт от OpenZeppelin, то там увидите довольно большой комментарий, зачем нужна проверка этого значения.
Из-за особенностей работы системы, сюда вы можете передать две разные подписи (с одинаковым подписанным сообщением) и получить один и тот же восстановленный адрес!
В этой ветке дается объяснения почему это происходит, и как это связано с EIP2 и secp256k1n/2. Спойлер: особенности шифрования.
Как я понял, вообще нужно быть очень аккуратными и внимательными с этими подписями и их восстановлением.
#security #signature #eip2
Ну, и еще одна уязвимость от того же автора из Твиттер.
Посмотрите на скрин. Вероятно, вы видели или сами реализовывали такое восстановление подписи у себя в контракте.
Но тут чего-то не хватает?
А точнее, тут не хватает валидации S значения!
if (uint256(s) > 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 ) {
return (address(0), RecoverError.InvalidSignatureS);
}
Если открыть контракт от OpenZeppelin, то там увидите довольно большой комментарий, зачем нужна проверка этого значения.
Из-за особенностей работы системы, сюда вы можете передать две разные подписи (с одинаковым подписанным сообщением) и получить один и тот же восстановленный адрес!
В этой ветке дается объяснения почему это происходит, и как это связано с EIP2 и secp256k1n/2. Спойлер: особенности шифрования.
Как я понял, вообще нужно быть очень аккуратными и внимательными с этими подписями и их восстановлением.
#security #signature #eip2
👍1
Классная задача от Immunefi
Уже в первых числах января Immunefi выложила еще одну задачу, которая меня очень впечатлила.
Для того, чтобы понять всю идею, откройте скрин на весь экран и внимательно прочитайте код строчка за строчкой.
Я напишу ответ не закрытый, как обычно, так как большинство участников точно не знает, в чем тут может быть проблема.
С кодом все ок. По крайней мере, если не знать особенностей работы контрактов токенов и разных EIP.
В случае с ERC20 - все будет ок. Однако проблемы могут начаться, если хакер захочет использовать токены ERC777.
Если кто не знает, то такие токены стандарта ERC777 при трансфере имеют не одну, а целых две callback функции:
_callTokensToSend() - которая вызывается до фактической отправки токенов;
_callTokensReceived() - которая вызывается после отправки токенов.
Обе они в рамках функции transfer(). Поняли теперь, в чем дело в задаче?
Используя _callTokensToSend() токена, хакер может заходить в функцию deposit() несколько раз (reentrancy), и спровоцировать увеличенное количество shares!
Лично я не знал этого момента. Пришлось покопаться в сети, чтобы понять принципы работы.
Интересно, да?
#task #security #erc777
Уже в первых числах января Immunefi выложила еще одну задачу, которая меня очень впечатлила.
Для того, чтобы понять всю идею, откройте скрин на весь экран и внимательно прочитайте код строчка за строчкой.
Я напишу ответ не закрытый, как обычно, так как большинство участников точно не знает, в чем тут может быть проблема.
С кодом все ок. По крайней мере, если не знать особенностей работы контрактов токенов и разных EIP.
В случае с ERC20 - все будет ок. Однако проблемы могут начаться, если хакер захочет использовать токены ERC777.
Если кто не знает, то такие токены стандарта ERC777 при трансфере имеют не одну, а целых две callback функции:
_callTokensToSend() - которая вызывается до фактической отправки токенов;
_callTokensReceived() - которая вызывается после отправки токенов.
Обе они в рамках функции transfer(). Поняли теперь, в чем дело в задаче?
Используя _callTokensToSend() токена, хакер может заходить в функцию deposit() несколько раз (reentrancy), и спровоцировать увеличенное количество shares!
Лично я не знал этого момента. Пришлось покопаться в сети, чтобы понять принципы работы.
Интересно, да?
#task #security #erc777
👍2
Задачка на день
Ну, и небольшая задачка на день. Сможете найти, в чем тут проблема?
Решение
В аудитах следует всегда обращать внимание на модификаторы функций, какие условия они нам ставят.
В текущем же примере, он просто сверяет msg.sender с другим параметров, а значит, что функция _safeMint() не защищена от reentrancy атак.
#security #task
Ну, и небольшая задачка на день. Сможете найти, в чем тут проблема?
Решение
В текущем же примере, он просто сверяет msg.sender с другим параметров, а значит, что функция _safeMint() не защищена от reentrancy атак.
👍2
Read-only-reentrancy
Я уже писал ранее о новой уязвимости, которая может получить распространение в этом году. Она основана на том, что даже если функция выполняющая внешний вызов защищена от reentrancy модификатором, библиотекой или как-то еще, но есть другая view / pure функция, которая используется ней, производя какие-то расчеты, например, по выплатам rewards, то все равно сохраняется возможность взлома.
Теперь аудиторы должны научиться распознавать подобные штуки в контрактах.
Пользователь под ником Bytes32 в Твиттере сделал прекрасную ветку, где расписал эту уязвимость не только на простом примере, но и показал реальный контракт, где это было возможно.
Обязательно к прочтению для всех аудиторов!
#security #reentracy
Я уже писал ранее о новой уязвимости, которая может получить распространение в этом году. Она основана на том, что даже если функция выполняющая внешний вызов защищена от reentrancy модификатором, библиотекой или как-то еще, но есть другая view / pure функция, которая используется ней, производя какие-то расчеты, например, по выплатам rewards, то все равно сохраняется возможность взлома.
Теперь аудиторы должны научиться распознавать подобные штуки в контрактах.
Пользователь под ником Bytes32 в Твиттере сделал прекрасную ветку, где расписал эту уязвимость не только на простом примере, но и показал реальный контракт, где это было возможно.
Обязательно к прочтению для всех аудиторов!
#security #reentracy
👍3🤔1
Подборка проектов с новостями
Встретил на просторах Твиттера прекрасную подборку проектов, которые пишут статьи или делают новостную рассылку о последних взломах и вопросах безопасности в блокчейне.
Secureum
Blockchain Threat Intelligence
Week in Ethereum News
NotOnlyOwner
Vulnerability Research by Samczsun
Noxx
Faith's Blog
Cygaar’s Substack
Rekt
DeFiHackLabs’s Substack
Если вас не раздражают емайл рассылки, то эти будут как нельзя кстати!
#email #security #news
Встретил на просторах Твиттера прекрасную подборку проектов, которые пишут статьи или делают новостную рассылку о последних взломах и вопросах безопасности в блокчейне.
Secureum
Blockchain Threat Intelligence
Week in Ethereum News
NotOnlyOwner
Vulnerability Research by Samczsun
Noxx
Faith's Blog
Cygaar’s Substack
Rekt
DeFiHackLabs’s Substack
Если вас не раздражают емайл рассылки, то эти будут как нельзя кстати!
#email #security #news
👍5🔥2❤1
ReentrancyGuard в прокси?
Необычный способ реализации ReentrancyGuard предложила одна из команд на мероприятии ETHDenver 2023 Hackathon.
Основной смысл заключается в том, чтобы вместо добавления модификатора ReentrancyGuard в каждую функцию в контракте Логики, создать защиту только в Прокси контракте.
Не смотря на то, что это поможет избежать популярных багов и недочетов со стороны команды разработчиков при последующих обновлениях, система не до конца проверена и безопасна.
Более подробно можно прочитать в этой статье.
Возможно, мы скоро увидим этот концепт в конкурсных аудитах.
#reentrancy #security #proxy
Необычный способ реализации ReentrancyGuard предложила одна из команд на мероприятии ETHDenver 2023 Hackathon.
Основной смысл заключается в том, чтобы вместо добавления модификатора ReentrancyGuard в каждую функцию в контракте Логики, создать защиту только в Прокси контракте.
Не смотря на то, что это поможет избежать популярных багов и недочетов со стороны команды разработчиков при последующих обновлениях, система не до конца проверена и безопасна.
Более подробно можно прочитать в этой статье.
Возможно, мы скоро увидим этот концепт в конкурсных аудитах.
#reentrancy #security #proxy
Not So-Famous Solidity Attack Vectors
Одновременно прекрасное и ужасное видео с с конференции ETH Dubai, рассказывающее о не самых очевидных атаках в смарт контрактах.
Прекрасное оно из-за набора тем, которые поднимает спикер. Многие из них действительно могут быть упущены при аудите. Ужасное же оно только из-за сложности восприятия речи. Будет сложно даже тем, кто хорошо знает и понимает английский язык.
Тем не менее, видео достойное для изучения.
#security #ethdubai
Одновременно прекрасное и ужасное видео с с конференции ETH Dubai, рассказывающее о не самых очевидных атаках в смарт контрактах.
Прекрасное оно из-за набора тем, которые поднимает спикер. Многие из них действительно могут быть упущены при аудите. Ужасное же оно только из-за сложности восприятия речи. Будет сложно даже тем, кто хорошо знает и понимает английский язык.
Тем не менее, видео достойное для изучения.
#security #ethdubai
YouTube
Not So-Famous Solidity Attack Vectors, often missed/overlooked while Auditing! by Tejaswa Rastogi
Get notified when tickets, dates and call for speakers are available for our next edition in 2024 https://www.ethdubaiconf.org/api/next
👍6
Бесплатный курс от Statemind
Ребята из Statemind попросили поделиться информацией о наборе на свой бесплатный курс Smart Contract Security Specialist.
Кратно об обучении:
• Обучение онлайн
• Длительность 4 недели
• Обучение на английском/русском языках
• Отбор проводим по входному тесту (в форме)
• После успешного прохождения программы проводим интервью и по результатам предлагаем возможность присоединиться к нашей команде в качестве интерна (мы работаем удаленно)
• Обучение с нашей стороны бесплатное, потому что основная наша задача - найти единомышленников
• Помогаем с релокацией
В программе курса:
• Introduction to blockchain
• DeFi primitives
• DeFi security
Подробная информация и форма для заполнения для тех, кому будет интересно
https://docs.google.com/forms/d/e/1FAIpQLSfdCWi1HYlU1nZs62WwwYA-PZZi7msTqpHnpBtMOARFPer2vg/viewform?usp=sf_link
Залетайте!
P.S. Подчеркну, что потребуется знание английского языка!
#statemind #security
Ребята из Statemind попросили поделиться информацией о наборе на свой бесплатный курс Smart Contract Security Specialist.
Кратно об обучении:
• Обучение онлайн
• Длительность 4 недели
• Обучение на английском/русском языках
• Отбор проводим по входному тесту (в форме)
• После успешного прохождения программы проводим интервью и по результатам предлагаем возможность присоединиться к нашей команде в качестве интерна (мы работаем удаленно)
• Обучение с нашей стороны бесплатное, потому что основная наша задача - найти единомышленников
• Помогаем с релокацией
В программе курса:
• Introduction to blockchain
• DeFi primitives
• DeFi security
Подробная информация и форма для заполнения для тех, кому будет интересно
https://docs.google.com/forms/d/e/1FAIpQLSfdCWi1HYlU1nZs62WwwYA-PZZi7msTqpHnpBtMOARFPer2vg/viewform?usp=sf_link
Залетайте!
P.S. Подчеркну, что потребуется знание английского языка!
#statemind #security
👍13❤6🔥1👌1
Канал разбора конкурсных отчетов
Кстати, я продолжаю вести закрытый канал, где мы разбираем баги с конкурсных аудитов. В день выкладываю по два небольших разбора, иногда делаю посты по нюансам в безопасности СК, на которые стоит обращать внимание, задачки, а также иногда "заходим" в небольшой конкурс и рассматриваем его в течение нескольких дней.
Сейчас уже разобрали более 100 различных уязвимостей и 3 конкурсных протокола. Дальше будем смотреть на проблемы с defil протоколами и сетями l2.
Если хотите прокачать свои навыки в поиске багов и начать чуть лучше разбираться в безопасности протоколов, то приглашаю присоединиться к нам.
Доступ в группу идет по месячной оплате в 1000 рублей, чтобы в ней оставались только те, кому интересная и актуальна тема.
Буду рад новым участникам!
#security
Кстати, я продолжаю вести закрытый канал, где мы разбираем баги с конкурсных аудитов. В день выкладываю по два небольших разбора, иногда делаю посты по нюансам в безопасности СК, на которые стоит обращать внимание, задачки, а также иногда "заходим" в небольшой конкурс и рассматриваем его в течение нескольких дней.
Сейчас уже разобрали более 100 различных уязвимостей и 3 конкурсных протокола. Дальше будем смотреть на проблемы с defil протоколами и сетями l2.
Если хотите прокачать свои навыки в поиске багов и начать чуть лучше разбираться в безопасности протоколов, то приглашаю присоединиться к нам.
Доступ в группу идет по месячной оплате в 1000 рублей, чтобы в ней оставались только те, кому интересная и актуальна тема.
Буду рад новым участникам!
#security
👍5🔥1