Телеграм канал «»

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

особенность секретных чатов Telegram - PFS в них происходит спустя 100 сообщений или спустя 1 неделю (https://core.telegram.org/api/end-to-end#perfect-forward-secrecy)

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

таким образом - ЕСЛИ получен доступ к серверу Telegram и введено логирование зашифрованных сообщений (или каким-то образом обошли PFS для основного соединения MTProto), если человек включил автоудаление в своем секретном чате и там было менее 100 сообщений, или просто в конце почистил историю, тогда все удаленные сообщения удастся прочитать в течение недели поскольку PFS еще не произойдет

интересно что я смог скачать фотографию загруженную в секретный чат спустя 8 месяцев..

большинство думает, что когда ты шлешь миллион запросов через какой-нибудь балансировщик типа nginx или haproxy, он просто кидает их по кругу (round-robin) или по наименьшему числу соединений.

на незначительных объемах это работает. но когда у тебя начинается реальный бигдейта-трафик, обычный балансировщик начинает ломать архитектуру, потому что он не сохраняет состояние сессий без костылей.
тут в игру вступает consistent hashing (консистентное хеширование).

обычный модуль % N (хеш от ip, деленный на количество серверов) это катастрофа. если у тебя 10 серверов и один из них падаeт, N становится равно 9. в этот момент хеш-ключ абсолютно для каждого пользователя смещается. результат: 100% кешей на всех оставшихся 9 серверах мгновенно превращаются в ноль. наступает классический "кешевый шторм" (cache stampede), и падают вообще все серверы по цепочке.

как это решается в нормальном софте?
выстраивается виртуальное «кольцо» (hash ring) от 0 до 2^{32}-1.

серверы хешируются и расставляются по этому кольцу.
ключ пользователя (например, user_id или session_id) тоже хешируется и попадает в какую-то точку кольца.
запрос отправляется на первый сервер, который встречается на кольце по часовой стрелке.

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

но и тут есть подвох, про который забывают 90% инженеров, диспропорция узлов. если просто бросить 5 серверов на кольцо, они раскидаются неравномерно. один сервер будет задыхаться от 50% всего трафика, а соседний пинать хуи.

чтобы это обойти, придумали виртуальные узлы (vnodes). один физический сервер режется на 100–200 виртуальных точек и случайно размазывается по всему кольцу. в итоге градиент нагрузки получается идеально ровным.

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

Network engineer here.
Best way to learn is by doing, I don't disagree, but it's better to build and know what you're breaking than to just start breaking. Buy a cheap firewall appliance, learn OPNsense, some old office PCs and run docker on ubuntu server, and get a managed VLAN capable switch, then throw any wireless into the mix and make it work the manual way. Breaking it without knowing how it build it is pointless because this stuff does matter and that mindset shows why cyber teams are ignored when they opt to "secure/break" what makes the company money without knowing how and why it works.

Перевод.
Я сетевой инженер.
Лучший способ учиться — это делать, я не спорю, но лучше создавать и понимать, что ты ломаешь, чем просто начинать ломать. Купите недорогой межсетевой экран, изучите OPNsense, несколько старых офисных ПК и запустите Docker на сервере Ubuntu, приобретите управляемый коммутатор с поддержкой VLAN, а затем добавьте любую беспроводную сеть и настройте её вручную. Ломать, не зная, как это было создано, бессмысленно, потому что это действительно важно, и именно такой образ мышления объясняет, почему киберкоманды игнорируются, когда они решают «защищать/ломать» то, что приносит компании деньги, не зная, как и почему это работает.

10-го октября задержали еще одного участника shinyhunters. федералы продолжают зачистку, и под руку на этот раз попал не какой-то дроп, а вполне себе известный в узких кругах тип, канадский ИБ-эксперт и переговорщик по выкупам Эдвард Дубровский.

его задержали прямо в пенсильвании, куда он приехал на конфу. по версии фбр, он помогал этой группировке легализовать и монетизировать вымогательство, а также участвовал в резонансной атаке на инфраструктуру самого же бюро (когда через уязвимость слили БД портала fbijobs с персональными данными, хэшами и контактами кандидатов).

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

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

видео (те кто не знают английского,есть русская дорожка)
https://youtu.be/A03M8T77MyA?si=P6epcbDXZb_YZKGm

telemetr.me/TorZireael1/1130
думаю вы слышали об этом инциденте, и у меня есть вопросы. почему Rey не подстраховался? я имею в виду, что он мог попросить соучастников: если ФБР его не отпустят, слить всю базу данных. либо заранее установить скрипт «мёртвая рука», при котором, если в течение 24 или 48 часов не ввести код, вся база данных будет слита. при таком раскладе можно было, так сказать, шантажировать ФБР, и с большой долей вероятности они бы нашли компромисс, потому что утечка базы данных ФБР — это полный обвал, потеря репутации и угроза безопасности сотрудников.

было логично что скорее всего кого то поймают,фбр такое не прощает.

Как сообщают источники, Rey — лидер ShinyHunters был задержан в Иордании 29 сентября.

Дополнительно подтверждает факт задержания лидера SH то, что представитель группы перестал пользоваться прежним аккаунтом в мессенджере, с ним поддерживали связь BleepingComputer и Reuters, которые подтвердили что с ним не удалось установить контакт после сообщения о задержании.

30 сентября, на следующий день после задержания Rey, блог группы ShinyHunters также стал недоступен.

1 октября, группой был запущен новый блог, и как сами SH сообщили причиной стало "DDoS-атаки конкурентов и проблемы с дата-центрами. Заявили о защите нового сайта и попытках восстановить старый."

3 октября, Reuters сообщило о сотрудничестве Rey со следствием. По источникам агентства, он помогает искать остальных участников, предоставляя сведения об устройствах и переписке.