уязвимость
Подписчиков:
5Постов:
23
В играх на движке Source найдена уязвимость, позволяющая получить доступ к аккаунтам игроков
Группа "белых" хакеров The Secret Club, заявила, что обнаружила уязвимость в системе приглашений Steam в игры, основанных на игровом движке Source (CS:GO, TF2, Portal, HL и т.д.), с помощью которой возможно получить доступ к аккаунту игрока, который примет приглашение в игру от хакера. Если отправить приглашение от имени сообщества, то возможно получить доступ к большому количеству пользователей, принявшим приглашение.
Два года назад член The Secret Club @floesen_ сообщил об ошибке удаленного выполнения кода, затрагивающей все игры на движке Source. Его можно запустить через приглашение в Steam. Она еще не исправлена и Valve запретила нам обнародовать её.
Также, они заявили, что Valve знает об этой проблеме уже несколько лет и до сих пор не прокомментировала и не исправила её. Боле того, она запретила обнародовать данные об уязвимости, но не сообщила, как это осуществить.
Как я нашел в публичном доступе исходники нескольких сервисов ФНС
Предыстория
Суть приложения «Проверка чеков»
Страница приложения «Проверка чеков» в App Store
Страница входа в Sentry команды Studio TG 
Страница входа в GitLab команды Studio TG 
Публично доступный репозиторий ansible_conf/install_geo 
Содержимое архивов из репозитория ansible_conf/install_geo 
Содержимое папки lkip-web-login, это — исходный код сервиса lkip2.nalog.ru 
uppod-styles.txt на сайте lkip2.nalog.ru 
Содержимое файла .env судя по всему прямиком с боевых серверов В итоге
Как-то так.
Возьмём приложение «Проверка чека» и разберемся что оно делает и зачем ваще кому-то понадобилось проверять чеки с помощью приложения.
Я не помню как это работало раньше, но с 2016-2017 годов, благодаря 54-ФЗ «О применении ККТ» появились некие ОФД с целью «...осуществления операций по приёму, обработке, хранению и передаче фискальных данных в ФНС», а всех кого только можно обязали использовать кассовое оборудование, генерирующее те самые фискальные данные и что немаловажно, обязали эти данные посредством ОФД передавать в ФНС.
Если у вас тоже немного припекает от всех этих аббревиатур, то вот вам терминальная стадия аббревиатуринга в лице названия организации которая отвечает за приложение «Проверка чека» — ФГУП ГНИИВЦ ФНС РФ.
К этому моменту — мы еще вернёмся, кстати.
Прикладной смысл вышеописанного очень лёгко понять на примере сервиса заказа еды.
После заказа вы получаете на почту электронный чек, это и есть те самые фискальные данные. Отправляет их в ваш адрес, однако, не сервис заказа еды, а именно ОФД, которое используется сервисом, в данном случае — Яндекс
Любой подобный чек всегда содержит несколько обязательных идентификаторов в натуральном виде и в виде QR-кода, который можно отсканировать с помощью исследуемого нами приложения «Проверка чека».
В итоге, в приложении «Проверка чека», появляется электронная копия данного чека и тут я хочу обратить ваше внимание на атрибутивный состав кортежа с данными, а именно, на полный и детальный список чего и когда и за сколько денег моя персона приобрела, это — важно.
Но всё бы ничего, если бы не один недавний апдейт данного поделия, который и привёл меня в ужас. До недавних пор приложение оперировало лишь теми данными которые ты сам соизволил туда засунуть путём сканирования QR-кодов и не представляло, ни особого интереса, ни особой угрозы личной безопасности.
Всё изменилось две недели назад после обновления 2.15.0 в рамках которого был выкачен функционал «отображение чеков из сервиса Мои Чеки Онлайн».
История версий приложения «Проверка чека»Обновление 2.15.0
Если пройти аутентификацию в приложении «Проверка чека» указав номер телефона, который вы так же используете в популярных сервисах, например, в Яндекс.Еде, Яндекс.Такси, Самокате, Ситимобиле и других, то в разделе «Мои чеки» автомагически будут отображены все ваши чеки по всем операциям в этих сервисах за «всё время».
В моём случае, это порядка 400 чеков, каждый из которых содержит детальный набор «сколько, за что, когда и куда».
Мне сразу же стало интересно насколько хорошо подобный массив данных защищен и может ли предполагаемый злоумышленник получить несанкционированный доступ к нему.
Для исследования я поставил в разрыв между интернетом и приложением «Проверка чека» простой прокси и записывая сетевую активность приложения потыкал в кнопки.
Довольно быстро выяснилось, что эндпойнт с данными находится по адресу irkkt-mobile.nalog.ru:8888 на котором живёт простейшее приложение на NodeJS с применением фреймворка Express, а механизм аутентификации пользователя пускает тебя к данным, если ты верно указал заголовок «sessionId» значение которого представляет из себя какой-то самопальный токен генерирующийся на стороне сервера.
При этом, если нажать кнопку «Выйти» в приложении «Проверка чека», то как оказалось, инвалидации данного токена не происходит. Так же нет функционала просмотра всех своих сесссий и нет кнопки «Выйти на всех устройствах».
Таким образом даже если вы каким-то образом поняли что токен доступа был скомпрометирован, то нет никакой возможности его сбросить и тем самым гарантировать с этого момента отсутствие у предполагаемого злоумышленника доступа к вашим данным.
Крайне безответственно, но не фатально.
SentryВ процессе просмотра «улова» на промежуточном прокси я обратил внимание, что в случае крэша приложения оно отправляет диагностические данные в Sentry располагающийся по адресу не связанному, ни с ФНС, ни с ФГУП ГНИИВЦ ФНС РФ, а на домен зарегистрированный на физическое лицо — sentry.studiotg.ru.
Дальнейшее исследование эндпойнта привело к ссылками на публичные репозитории в этом Гитлабе находящиеся в индексе Гугла уже более года.
Содержимое публичных репозиториевзаставило меня биться в истерике.
Пояснение к скриншоту выше: папки содержащие подстроки «lkio», «lkip», «lkul» напрямую относятся к одноименным сервисам ФНС на домене nalog.ru.
Для сверки, что обнаруженные исходники действительно относятся к сервисам ФНС, проведена простая проверка наличия на боевом веб-сервере файла uppod-styles.txt, который не мог там оказаться по случайному совпадению.
Фактический разработчик мобильного приложения «Проверка чека» некая studiotg.ru.
Вероятно есть нарушение соглашений об обработке персональных данных в силу передачи диагностических сведений со стороны ФГУП ГНИИВЦ ФНС РФ в адрес третьих лиц.
Данные ребята так же причастны к разработке сервисов lkip.nalog.ru, lkul.nalog.ru и lkio.nalog.ru.
По их вине исходный код данных сервисов находится в публичном доступе уже около года.
Исходя из общей картины, предположу, что данные о ваших покупках попадающие в ОФД путём информационного обмена фискальными данными с ФНС, на текущий момент, находятся под угрозой утечки.
Самый беззащитный — уже не Сапсан. Всё оказалось куда хуже…
Больше года назад хабравчанин keklick1337 опубликовал свой единственный пост «Самый беззащитный — это Сапсан» в котором рассказывает как он без серьёзных ухищрений получил доступ ко внутренней сети РЖД через WiFi Сапсана.
В ОАО «РЖД» прокомментировали результаты этого расследования. «Есть результаты проверки. Почему удалось взломать? Наверное, потому, что злоумышленник. Наверное, из-за этого… Ну, он из „фана“. Юный натуралист. Там уязвимостей, которые бы влияли на утечку каких-то критических данных, нет. Мультимедийный портал „Сапсанов“ функционирует как положено и не нуждается в доработке», — заявил Евгений Чаркин.
То есть вместо того, чтобы выразить благодарность за обнаруженную уязвимость, автора обозвали «злоумышленником» и «Юным натуралистом».
В ОАО «РЖД» прокомментировали результаты этого расследования. «Есть результаты проверки. Почему удалось взломать? Наверное, потому, что злоумышленник. Наверное, из-за этого… Ну, он из „фана“. Юный натуралист. Там уязвимостей, которые бы влияли на утечку каких-то критических данных, нет. Мультимедийный портал „Сапсанов“ функционирует как положено и не нуждается в доработке», — заявил Евгений Чаркин.
То есть вместо того, чтобы выразить благодарность за обнаруженную уязвимость, автора обозвали «злоумышленником» и «Юным натуралистом».
К сожалению, но специалисты РЖД, начиная с директора по информационным технологиям, отнеслись к статье очень пренебрежительно, проигнорировав важное указание автора:
Также оттуда в сеть РЖД есть впн. Если захотите — найдёте её там сами.
И вот, год спустя я попал в сеть РЖД даже не садясь в Сапсан.
Видимо, только этот котэ добросовестно охраняет вокзал.
Как именно я попал в сеть РЖД с пруфами, чего не сделал директор по информационным технологиям ОАО «РЖД» Чаркин Евгений Игоревич и возможные последствия — под катом.
В интернете очень много бесплатных прокси-серверов. Но кто в здравом уме будет открывать всем желающим выход в интернет через свой роутер? Вариантов по большому счету два: это либо взломанные устройства, либо владелец забыл отключить эту функцию.
Таким образом меня посетила идея проверить гипотезу: «Есть ли жизнь за прокси»?
Я запустил nmap по диапазону адресов по порту 8080. Далее из полученного результата прошёлся прокси-чеккером в поисках публичного прокси без авторизации и из положительных результатов выбрал самый близкий ко мне по пингу.
Запустил сканер через него по адресам 172.16.0.0/12 порт 8291 (mikrotik winbox). И! Я его нашёл! Без пароля!
То есть за роутером с прокси есть ещё один — Mikrotik без пароля. Гипотеза подтверждена: за прокси могут быть целые незащищённые сети.
Только на тот момент я недооценивал масштаб «незащищённости», который я случайно нашёл.
В поисках
Так как я придерживаюсь принципов Grey hat (Обо мне mysterious Russian-speaking grey-hat hacker Alexey и статья на Хабре) и «съел собаку» на безопасности Mikrotik, то я принялся искать владельца системы, чтобы связаться с ним.
Кстати, заходите в Телеграм чат «RouterOS Security» t.me/router_os
Недолго думая я поднял исходящий VPN до себя. Всё же комфортней через нормальный туннель дальше изучать сеть и искать признаки владельца системы. HTTP connect — ещё тот геморрой…
За интерфейсами ether1 и bridge ничего интересного не обнаружил. Найденные камеры были абсолютно не информативными.
А вот сканирование vpn, отмеченные красным на скрине выше, выдало более 20 000 устройств…
Причём более 1000 штук — микротики. Огромное количество устройств с заводскими паролями.
Вот некоторые из найденных сервисов с паролями по умолчанию:
1. Камеры наружного наблюдения — подавляющее большинство.
Даже офисы внутри
Камер, по скромным ощущениям, не менее 10 000 штук. Производители разные: beward, axis, panasonic и т.д.
2. Ip-телефоны и FreePBX сервера также большое количество.
3. IPMI серверов:
Много узлов кластера Proxmox (по поднятым сервисам и трафиком между ними.)
6. Внутренние сервисы
Различные системы управления табло на перронах :-)
Некий терминал, но внутри модифицированный дебиан.
Кстати, аптайм у него почти год:
6. Сетевое оборудование
Разумеется, много различных роутеров. Как уже сказано выше, мне больше интересны Микротики. Подавляющее большинство с последней прошивкой и пароли не пустые. Но есть без паролей и с устаревшими прошивками.
Туннели наружу подымаются легко. То есть фильтрации исходящих коннектов практически нет.
Более того огромное количество микротиков со включенным прокси, аналогично тому, при помощи которого я и попал в эту сеть… Кстати, туннели через них тоже замечательно подымаются.
Не полный кусок лога по прокси.
Такое ощущение, что интегратор, который строил сеть, специально оставил этот доступ.
Думаю, что уже все и так догадались.
Это я пробежался по верхушкам в рандомном порядке. Потратил я на это чуть больше 20 минут, чем автор статьи про Сапсан.
Это здец. Сеть просто в решето.
Причём это устройства по всей РФ.
Развёрнута профессиональная система видеонаблюдения.
Нашёл презентацию по вокзалам.
Находил Кемерово, Новосибирск, Омск и т.д. По внешнему виду вокзалы сложно определить. К тому же я поездом уже лет 5 не ездил.
Я всегда считал, что уязвимости в корпоративных сетях появляются из-за ошибок или специальных действий безграмотных сотрудников. Первое что пришло мне в голову — это некий сотрудник по разрешению СБ поднял у себя из дома VPN до рабочей сети на микротике в своей домашней сети. Но в данном случае эта моя гипотеза разбилась как только я увидел обратный резолв адреса через который я попал на этот Микротик.
То есть это один из шлюзов в мир из сети РЖД. Ну и в сеть РЖД тоже…
Получилась вот такая картина:
Вероятно, что это один из офисов РЖД, который прилинкован к основой сети через l2tp. Я попадаю в сеть где межсетевые экраны отсутствуют как класс. Запускаю интенсивное сканирование хостов — у меня соединение не рвётся. Значит о системах обнаружения вторжения (IDS/IPS) РЖД тоже ничего не слышал. Микротик может замечательно интегрироваться, например Обнаружил кучу устройств без защиты. Это говорит, что службы сетевой безопасности в РЖД так же нет.Много устройств с дефолтными паролями. То есть политики паролей тоже нет.С Микротиков внутри сети я легко поднял туннели. То есть исходящий трафик не контролируется. Я вижу все интерфейсы управления в одной сети с клиентскими сервисами. Админы РЖД ничего не знают о Management VLAN
«Российские железные дороги» провели проверку после взлома мультимедийной системы поезда «Сапсан» одним из пассажиров, критических уязвимостей не обнаружено.
Так дайте ответ, Евгений Игоревич, какой «Юный натуралист» проводил расследование и не заметил гнездо со слонами?
У меня лично есть всего три варианта ответа на этот вопрос:
1. У Вас исходно плохая команда.
Проверку проводил тот же отдел, который и проектировал/обслуживает систему. Отрицая проблему, они или сохраняют свою работу, или преследуют иные цели.
2. Вы доверились не тому специалисту. Аудит проводил некомпетентный сотрудник.
3. Вы и так знаете о проблеме, но по каким-то неведомым причинам не можете ее публично признать и решить.
«Что есть защищенная система? Защищенная система — это та система, взлом которой стоит дороже, чем ценность информации, которая там есть. Вот и все», — подытожил директор по информационным технологиям ОАО «РЖД».
Предлагаю применить Вашу систему оценки в теории на примере системы видеонаблюдения РЖД.
Чтобы вывести камеры из строя так, чтобы их могли восстановить только специалисты вендора, достаточно залить прошивку с заблокированным сетевым интерфейсом.
Рандомно выбранная из списка установленных модель стоит ~13к рублей.
А закупки по 44-ФЗ отличаются, как непредсказуемой конечной стоимостью, так и временем проведения самой процедуры и получения продукта. Я потратил 8 часов для сбора информации для этой статьи. Найдено ~10к камер. Производителей камер, которые установлены, немного — максимум штук 10.
Гипотетическому злоумышленнику потребуется:
Модифицировать прошивки, заблокировав сетевой порт на 10 прошивках. Думаю, что на это у специалиста уйдёт три рабочих дня;Написать сканер, который будет анализировать устройство и заливать соответствующую прошивку. Заложим ещё 2 дня;Запустить этот сканер-прошивальщик, чтобы не смогли найти источник и заблокировать — часа два.
Таким образом за неделю работы специалиста по взлому РЖД потеряет минимум 130 миллионов рублей. Отсюда стоимость одного часа работы злоумышленника будет равна ~2,5 млн. рублей.
Двигаемся дальше.
Быстро заменить камеры на работающие РЖД не сможет. В резерве столько нет. Купить новые из-за обязанности объявления торгов так же не получится. Таким образом вся железная дорога будет без видеонаблюдения не меньше месяца.
А вот это уже опасность террористической угрозы. Чтобы её хоть как-то снизить потребуется на 10 тысячах объектов существенно усилить охрану. То есть даже на маленькую ж.д. станцию потребуется дополнительно 6 человек охраны…
Кажется счёт уже уходит за миллиарды…
Что нужно изменить, чтобы снизить вероятность возможных последствий?
Далее чисто мой взгляд на решение данной ситуации. Он ничего общего не имеет с мировыми best practices.
Так же, сразу оговорюсь, что проблема касается только обнаруженной мною сети видеонаблюдения. В других сегментах сети РЖД, очень надеюсь, всё намного лучше.
1. Нанять сетевых аудиторов, которые помогут найти и закрыть самые «зияющие» дыры.
2. Нанять крутых системных архитекторов, которые имеют богатый опыт построения больших сетей. И не факт, что это будут российские специалисты. Перед ними поставить следующие задачи:
2.1. доработать текущую инфраструктуру до безопасного состояния за минимальные средства (зачем вкладывать много денег в проект, который скоро разберут)
2.2. разработать новую полноценную инфраструктуру, отвечающую всем требованиям безопасности и план поэтапной миграции.
3. Нанять подрядчика, который будет реализовывать в жизни данные проекты и передавать на эксплуатацию сетевикам РЖД.
4. После сдачи проектов провести аудит безопасности инфраструктуры.
5. По окончанию пентестов своими силами объявить Bug Bounty
Чтобы мотивировать аудиторов и внутренних специалистов работать качественно, надо объявить лимит на количество и серьёзность уязвимостей, которые могу найти участники программы Bug Bounty. Если внешние специалисты найдут багов меньше лимита, то свои аудиторы получают премии. Если багов будет больше лимита, то штрафовать.
В дальнейшем службу внутреннего аудита информационной безопасности оставить на постоянку и премии формировать уже на основании обнаруженных багов и их устранении.
Разумеется, что схема имеет огромное количество подводных камней, которые за время написания статьи предусмотреть не возможно.
Заключение
Я не единственный кто нашёл данные уязвимости. Очень много признаков, что в этой сети кто-то «живёт».
Например, вот эти линки я уже встречал не раз на роутерах, никак не относящихся к РЖД.
Все информационные системы уязвимы априори. Когда их вскроют — зависит от интереса злоумышленников к ним, беспечности создателя и времени, которое они на это потратят.
Основой основ безопасности является ограничение доступа к системам при несанкционированном проникновении в одно устройство.
В случае с Сапасаном, чтобы через полученный VPN доступ можно было увидеть только один сервис — с которым взаимодействует пользователь системы, а не всю сеть РЖД…
Я старался достаточно жирно намекнуть на узкие места не раскрывая деталей и надеюсь, что специалисты РЖД их всё же увидят.
Связаться со мной можно через телеграм t.me/monoceros
Обсудить данную статью приглашаю в профильный чат по Микротикам в Телеграм «RouterOS Security»: t.me/router_os
Кстати, Евгений Игоревич, с повышением!
Источник
Также оттуда в сеть РЖД есть впн. Если захотите — найдёте её там сами.
И вот, год спустя я попал в сеть РЖД даже не садясь в Сапсан.
Видимо, только этот котэ добросовестно охраняет вокзал.
Как именно я попал в сеть РЖД с пруфами, чего не сделал директор по информационным технологиям ОАО «РЖД» Чаркин Евгений Игоревич и возможные последствия — под катом.
Всё началось с гипотезы
В интернете очень много бесплатных прокси-серверов. Но кто в здравом уме будет открывать всем желающим выход в интернет через свой роутер? Вариантов по большому счету два: это либо взломанные устройства, либо владелец забыл отключить эту функцию.
Таким образом меня посетила идея проверить гипотезу: «Есть ли жизнь за прокси»?
Я запустил nmap по диапазону адресов по порту 8080. Далее из полученного результата прошёлся прокси-чеккером в поисках публичного прокси без авторизации и из положительных результатов выбрал самый близкий ко мне по пингу.
Запустил сканер через него по адресам 172.16.0.0/12 порт 8291 (mikrotik winbox). И! Я его нашёл! Без пароля!
То есть за роутером с прокси есть ещё один — Mikrotik без пароля. Гипотеза подтверждена: за прокси могут быть целые незащищённые сети.
Только на тот момент я недооценивал масштаб «незащищённости», который я случайно нашёл.
В поисках Немо владельца системы
Так как я придерживаюсь принципов Grey hat (Обо мне mysterious Russian-speaking grey-hat hacker Alexey и статья на Хабре) и «съел собаку» на безопасности Mikrotik, то я принялся искать владельца системы, чтобы связаться с ним.
Кстати, заходите в Телеграм чат «RouterOS Security» t.me/router_os
Недолго думая я поднял исходящий VPN до себя. Всё же комфортней через нормальный туннель дальше изучать сеть и искать признаки владельца системы. HTTP connect — ещё тот геморрой…
За интерфейсами ether1 и bridge ничего интересного не обнаружил. Найденные камеры были абсолютно не информативными.
А вот сканирование vpn, отмеченные красным на скрине выше, выдало более 20 000 устройств…
Причём более 1000 штук — микротики. Огромное количество устройств с заводскими паролями.
Вот некоторые из найденных сервисов с паролями по умолчанию:
1. Камеры наружного наблюдения — подавляющее большинство.
Ещё камеры 
Даже офисы внутри
Камер, по скромным ощущениям, не менее 10 000 штук. Производители разные: beward, axis, panasonic и т.д.
2. Ip-телефоны и FreePBX сервера также большое количество.
3. IPMI серверов:
Asus 
Dell (их подавляющее большинство) 
Supermicro 
Из серверов виртуализации встречаются ESXi, Proxmox и oVirt ![4r G A He3amnmeH0 | 10 4/cgi/url_redirect.cgi?url_name=mainmenu
© System © Summary
[J»l Java iKVM Viewer v1.69.26 [1 .4] - Resolution 1024 X 768 - FPS 9 Virtual Media Record Macro Options User List Capture Power Control Exit
© FRU Reading
© Hardware Informatioi
Vttuare ESXi 6.0.0](https://img2.safereactor.cc/pics/post/РЖД-дыра-уязвимость-6421376.png "РЖД,дыра,уязвимость,новости,habrahabr,habr,длинопост,информационная безопасность,it,политика,политические новости, шутки и мемы,мопед не мой,информационная небезопасность")
Много узлов кластера Proxmox (по поднятым сервисам и трафиком между ними.)
4. Преобразователи ethernet во 'что угодно' (Moxa UniPing etc) ![4r O A He3aiiii/iuieHO | 10 131 M0X3
j Main Menu Cl Overview Cl Basic Settings Cl Network Settings l'C3 Serial Settings LCl Port 1 1Operating Settings LCl Port 1 Cl Accessible IP Settings 1-^3 Auto warning Settings l-Q E-mail and SNMP Trap ;-Q Event Type ] Digital 10 |-Q DIO Settings 1 Cl DIO](https://img2.safereactor.cc/pics/post/РЖД-дыра-уязвимость-6421378.png "РЖД,дыра,уязвимость,новости,habrahabr,habr,длинопост,информационная безопасность,it,политика,политические новости, шутки и мемы,мопед не мой,информационная небезопасность")
5. Системы управления ИБП 
6. Внутренние сервисы
Что-то похожее на мониторинг состояния систем обеспечения здания. 
Система управления кондиционированием и вентиляцией 
Различные системы управления табло на перронах :-)
Эта самая красивая 
Некий терминал, но внутри модифицированный дебиан.
Таких нашёл около 20 
Кстати, аптайм у него почти год:
6. Сетевое оборудование
Разумеется, много различных роутеров. Как уже сказано выше, мне больше интересны Микротики. Подавляющее большинство с последней прошивкой и пароли не пустые. Но есть без паролей и с устаревшими прошивками.
Туннели наружу подымаются легко. То есть фильтрации исходящих коннектов практически нет.
Более того огромное количество микротиков со включенным прокси, аналогично тому, при помощи которого я и попал в эту сеть… Кстати, туннели через них тоже замечательно подымаются.
Не полный кусок лога по прокси.
Такое ощущение, что интегратор, который строил сеть, специально оставил этот доступ.
И все же кто же хозяин?
Думаю, что уже все и так догадались.
Это я пробежался по верхушкам в рандомном порядке. Потратил я на это чуть больше 20 минут, чем автор статьи про Сапсан.
Это здец. Сеть просто в решето.
Причём это устройства по всей РФ.
Например, вот это вокзал Уфы 
Антропово Костромской области 
Развёрнута профессиональная система видеонаблюдения.
Нашёл презентацию по вокзалам.
macroscop 
Находил Кемерово, Новосибирск, Омск и т.д. По внешнему виду вокзалы сложно определить. К тому же я поездом уже лет 5 не ездил.
Как же так получилось?
Я всегда считал, что уязвимости в корпоративных сетях появляются из-за ошибок или специальных действий безграмотных сотрудников. Первое что пришло мне в голову — это некий сотрудник по разрешению СБ поднял у себя из дома VPN до рабочей сети на микротике в своей домашней сети. Но в данном случае эта моя гипотеза разбилась как только я увидел обратный резолв адреса через который я попал на этот Микротик.
То есть это один из шлюзов в мир из сети РЖД. Ну и в сеть РЖД тоже…
Получилась вот такая картина:
Вероятно, что это один из офисов РЖД, который прилинкован к основой сети через l2tp. Я попадаю в сеть где межсетевые экраны отсутствуют как класс. Запускаю интенсивное сканирование хостов — у меня соединение не рвётся. Значит о системах обнаружения вторжения (IDS/IPS) РЖД тоже ничего не слышал. Микротик может замечательно интегрироваться, например Обнаружил кучу устройств без защиты. Это говорит, что службы сетевой безопасности в РЖД так же нет.Много устройств с дефолтными паролями. То есть политики паролей тоже нет.С Микротиков внутри сети я легко поднял туннели. То есть исходящий трафик не контролируется. Я вижу все интерфейсы управления в одной сети с клиентскими сервисами. Админы РЖД ничего не знают о Management VLAN
«Российские железные дороги» провели проверку после взлома мультимедийной системы поезда «Сапсан» одним из пассажиров, критических уязвимостей не обнаружено.
Так дайте ответ, Евгений Игоревич, какой «Юный натуралист» проводил расследование и не заметил гнездо со слонами?
У меня лично есть всего три варианта ответа на этот вопрос:
1. У Вас исходно плохая команда.
Проверку проводил тот же отдел, который и проектировал/обслуживает систему. Отрицая проблему, они или сохраняют свою работу, или преследуют иные цели.
2. Вы доверились не тому специалисту. Аудит проводил некомпетентный сотрудник.
3. Вы и так знаете о проблеме, но по каким-то неведомым причинам не можете ее публично признать и решить.
Стоимость уязвимости
«Что есть защищенная система? Защищенная система — это та система, взлом которой стоит дороже, чем ценность информации, которая там есть. Вот и все», — подытожил директор по информационным технологиям ОАО «РЖД».
Предлагаю применить Вашу систему оценки в теории на примере системы видеонаблюдения РЖД.
Чтобы вывести камеры из строя так, чтобы их могли восстановить только специалисты вендора, достаточно залить прошивку с заблокированным сетевым интерфейсом.
Рандомно выбранная из списка установленных модель стоит ~13к рублей.
А закупки по 44-ФЗ отличаются, как непредсказуемой конечной стоимостью, так и временем проведения самой процедуры и получения продукта. Я потратил 8 часов для сбора информации для этой статьи. Найдено ~10к камер. Производителей камер, которые установлены, немного — максимум штук 10.
Гипотетическому злоумышленнику потребуется:
Модифицировать прошивки, заблокировав сетевой порт на 10 прошивках. Думаю, что на это у специалиста уйдёт три рабочих дня;Написать сканер, который будет анализировать устройство и заливать соответствующую прошивку. Заложим ещё 2 дня;Запустить этот сканер-прошивальщик, чтобы не смогли найти источник и заблокировать — часа два.
Таким образом за неделю работы специалиста по взлому РЖД потеряет минимум 130 миллионов рублей. Отсюда стоимость одного часа работы злоумышленника будет равна ~2,5 млн. рублей.
Двигаемся дальше.
Быстро заменить камеры на работающие РЖД не сможет. В резерве столько нет. Купить новые из-за обязанности объявления торгов так же не получится. Таким образом вся железная дорога будет без видеонаблюдения не меньше месяца.
А вот это уже опасность террористической угрозы. Чтобы её хоть как-то снизить потребуется на 10 тысячах объектов существенно усилить охрану. То есть даже на маленькую ж.д. станцию потребуется дополнительно 6 человек охраны…
Кажется счёт уже уходит за миллиарды…
Что нужно изменить, чтобы снизить вероятность возможных последствий?
Далее чисто мой взгляд на решение данной ситуации. Он ничего общего не имеет с мировыми best practices.
Так же, сразу оговорюсь, что проблема касается только обнаруженной мною сети видеонаблюдения. В других сегментах сети РЖД, очень надеюсь, всё намного лучше.
1. Нанять сетевых аудиторов, которые помогут найти и закрыть самые «зияющие» дыры.
2. Нанять крутых системных архитекторов, которые имеют богатый опыт построения больших сетей. И не факт, что это будут российские специалисты. Перед ними поставить следующие задачи:
2.1. доработать текущую инфраструктуру до безопасного состояния за минимальные средства (зачем вкладывать много денег в проект, который скоро разберут)
2.2. разработать новую полноценную инфраструктуру, отвечающую всем требованиям безопасности и план поэтапной миграции.
3. Нанять подрядчика, который будет реализовывать в жизни данные проекты и передавать на эксплуатацию сетевикам РЖД.
4. После сдачи проектов провести аудит безопасности инфраструктуры.
5. По окончанию пентестов своими силами объявить Bug Bounty
Чтобы мотивировать аудиторов и внутренних специалистов работать качественно, надо объявить лимит на количество и серьёзность уязвимостей, которые могу найти участники программы Bug Bounty. Если внешние специалисты найдут багов меньше лимита, то свои аудиторы получают премии. Если багов будет больше лимита, то штрафовать.
В дальнейшем службу внутреннего аудита информационной безопасности оставить на постоянку и премии формировать уже на основании обнаруженных багов и их устранении.
Разумеется, что схема имеет огромное количество подводных камней, которые за время написания статьи предусмотреть не возможно.
Заключение
Я не единственный кто нашёл данные уязвимости. Очень много признаков, что в этой сети кто-то «живёт».
Например, вот эти линки я уже встречал не раз на роутерах, никак не относящихся к РЖД.
Все информационные системы уязвимы априори. Когда их вскроют — зависит от интереса злоумышленников к ним, беспечности создателя и времени, которое они на это потратят.
Основой основ безопасности является ограничение доступа к системам при несанкционированном проникновении в одно устройство.
В случае с Сапасаном, чтобы через полученный VPN доступ можно было увидеть только один сервис — с которым взаимодействует пользователь системы, а не всю сеть РЖД…
Я старался достаточно жирно намекнуть на узкие места не раскрывая деталей и надеюсь, что специалисты РЖД их всё же увидят.
Связаться со мной можно через телеграм t.me/monoceros
Обсудить данную статью приглашаю в профильный чат по Микротикам в Телеграм «RouterOS Security»: t.me/router_os
Кстати, Евгений Игоревич, с повышением!
Источник
Отличный комментарий!
Сама статья: https://habr.com/ru/post/536750/
https://habr.com/ru/users/LMonoceros/ - UPD: связались со мной специалисты РЖД и совместно закрыли уязвимости.
Премию дадут?
Аванс: его жизнь.
Оплата: его не посадят.
Оплата: его не посадят.
В SIM-картах выявлена ошибка, позволяющая взломать телефон отправкой SMS
Специалисты по кибербезопасности обнаружили существование новой, ранее не выявленной, критической уязвимости в SIM-картах, которая позволяет злоумышленникам удалённо взламывать целевые мобильные телефоны и шпионить за жертвами, просто отправив SMS-сообщение. Эта уязвимость, получившая название SimJacker, находится в программном обеспечении S@T Browser (динамический инструментарий для SIM-карт), встроенном в большинство SIM-карт и широко используемом операторами мобильной связи как минимум в 30 странах.S@T Browser содержит ряд инструкций STK — таких как отправка короткого сообщения, настройка вызова, запуск браузера, предоставление локальных данных, запуск по команде и отправка данных — все они могут быть вызваны простым отправлением сообщения SMS на устройство. ПО предлагает среду выполнения и автоматически запускает вредоносные команды на мобильных телефонах.
Более того, по словам исследователей, SimJacker активно пользовалась некая связанная с правительством частная компания для слежения за людьми в течение как минимум двух лет в нескольких странах. Причём люди проверялись массово по нескольку раз в день.
Обнародованная исследователями из AdaptiveMobile Security в опубликованном недавно докладе уязвимость может быть использована с помощью простого GSM-модема за $10. С него можно отправить на телефон жертвы сообщение SMS, включающее определённой вид вредоносного кода. Благодаря этому злоумышленник может:
получить местоположение целевого устройства и информацию IMEI;распространить неверную информацию путём отправки поддельных сообщений от имени жертв;совершать звонки на платные номера от имени абонента;шпионить за окружением жертв, приказав устройству звонить на номер телефона злоумышленника;распространять вредоносный код путём открытия браузером жертвы вредоносных веб-страниц;исполнять атаку, отключающую SIM-карту;получать другую информацию вроде языка, типа радио, уровня заряда батареи и так далее.
При этом во время работы SimJacker пользователь не знает, что он подвергся атаке, а информация была извлечена. Данные о местонахождении тысяч устройств были получены с помощью этой атаки без ведома или согласия пользователей мобильных телефонов, однако SimJacker была расширена для выполнения дополнительных видов атак.
Хотя технические подробности и подробный документ с описанием атаки планируется опубликовать в октябре этого года, исследователи заявили, что выявили реальные атаки на пользователей телефонов практически всех производителей, включая Apple, ZTE, Motorola, Samsung, Google, Huawei и даже различной электроники с поддержкой SIM-карт. Одна из выявленных жертв подверглась за неделю 250 атакам. Потенциально риску могут быть подвержены более миллиарда человек.
«Simjacker представляет собой явную опасность для мобильных операторов и абонентов. Это потенциально самая изощрённая атака, касающаяся основ мобильных сетей, из когда-либо существовавших, — сказал технический директор AdaptiveMobile Security Кэтал МакДейд (Cathal McDaid). — Это очень тревожный сигнал, который показывает, что злоумышленники вкладывают значительные средства во всё более сложные и изощрённые способы подрыва сетевой безопасности. Он ставит под угрозу приватность и доверие клиентов к операторам мобильной связи и влияет на национальную безопасность целых стран».
Более того, теперь, когда эта уязвимость была публично раскрыта, исследователи ожидают, что хакеры и другие злоумышленники попытаются развить эти атаки. Исследователи уже предоставили полную информацию об уязвимости Ассоциации GSM и Альянсу SIM. Последний признал проблему и выпустил рекомендации для производителей SIM-карт по обеспечению безопасности push-сообщений S@T. Мобильные операторы также могут немедленно устранить угрозу, настроив процесс анализа и блокировки подозрительных сообщений, содержащих команды браузера S@T. Пользователь мобильного устройства, похоже, ничего не может сделать, если использует SIM-карту с S@T Browser — разве что обратиться к оператору для замены SIM-карты на более безопасную.
Отличный комментарий!
чисто случайно оказалась уязвимость, чисто случайно уязвимость дает доступ ко всем параметрам, необходимым для слежки, чисто случайно о ней знали тока частные спецслужбы, чисто случайно следили за людьми. Конечно же это уязвимость, а не преднамеренная дырень.
Новая «дыра» Spoiler ,которой подвержены все процессоры Intel Core
Новая уязвимость под названием Spoiler использует особенности микроархитектуры Intel и обеспечивает доступ к личным данным и паролям любого ПК. Для взлома системы достаточно вируса или скрипта в браузере. Защита от Spectre и Meltdown в случае со Spoiler бесполезна.Ни программной, ни аппаратной защиты от Spoiler пока не существует
Реакция Intel
По словам авторов статьи, они уведомили Intel о наличии проблемы с уязвимостью Spoiler еще 1 декабря 2018 г. Поскольку представители компании не ответили разработчикам, документ с подробным описанием Spoiler был придан гласности по истечении 90-дневного «grace-периода».После публикации данных об уязвимости Spoiler представитель Intel связался с порталом The Inquirer и прокомментировал вопрос следующим образом: «В Intel осведомлены об этом исследовании. Мы рассчитываем, что защитить программы от таких проблем можно с помощью дополнительных решений. Они должны обеспечить воздержание от использования команд для работы с соответствующими данными. Мы также надеемся, что модули DRAM с защитой от атак типа Rowhammer остаются в безопасности. Защита наших клиентов и их данных остается нашим важнейшим приоритетом, и мы ценим усилия сообщества информационной безопасности за их непрекращающиеся исследования».
Имя Spoiler уязвимость получила от обнаруживших ее специалистов. Как отметил один авторов исследования Ахмад Могими (Ahmad Moghimi) в своем пояснительном письме интернет-порталу The Inquirer, было выбрано имя, начинающееся с «Sp», поскольку проблема возникает из-за спекулятивного выполнения команд, и она «спойлит представления о безопасности современных процессоров».
Техника восстановления ключей шифрования через анализ шумов в сигнале от беспроводных чипов
Оригинал на opennet.ru
Вносимых шумов достаточно чтобы полностью восстановить применяемый для шифрования ключ AES-128 через анализ сигнала от Bloetooth-адаптера на расстоянии около 10 метров при использовании на стороне целевой системы библиотеки tinyAES и на расстоянии одного метра при использовании mbedTLS. Для определения ключа потокового шифра используется корреляционная атака, для осуществления которой применялся модифицированный инструментарий ChipWhisperer (опробованы два варианта кореллияционной атаки - CRA (Correlation Radio Attack) и TRA (Template Radio Attack), ранее разработанных для определения ключей на основании анализа перепадов напряжения в цепях питания).
Утечка информации через шумы не специфична для каких-то определённых производителей, например, возможность совершения атаки продемонстрирована для Bluetooth-чипа nRF52832 от компании Nordic Semiconductor и WiFi-брелока с интерфейсом USB на базе чипа AR9271 от Qualcomm/Atheros. Для захвата сигнала использовался универсальный программируемый приёмопередатчик USRP N210.
Новость №500: Обнаружены новые варианты использования уязвимостей Meltdown и Spectre, основанные на работе кэша в процессоре
http://news.nplus1.ru/xdlz
Meltdown и Spectre - названия двух атак на процессоры Intel/AMD/ARM64
Разработчики из Google Project Zero опубликовали детали уязвимостей, которые затрагивают не только процессоры Intel и ARM64, но и AMD тоже (есть сообщения, что только при включении BPF JIT в ядре, что по умолчанию выключено). Названия им дали: Meltdown и Spectre (расплавление ядерного реактора и призрак).Meltdown позволяет приложению читать любую память компьютера, включая память ядра и других пользователей. Этой атаке подвержены процессоры Intel (по неподтвержденным данным все модели с 1995 года, кроме Itanium и Atom) и ARM64.
Уязвимостям назначены следующие CVE: CVE-2017-5753, CVE-2017-5715 и CVE-2017-5754. Есть PoC (п.4.3) , демонстрирующий атаку с этой уязвимостью через JavaScript. Разработчики ARM приводят подробности атаки для ARM, заявляют о том, что уязвимы лишь некоторые процессоры ARM, дают их список и меры по повышению безопасности.
Уязвимость Meltdown (CVE-2017-5754) позволяет приложению прочитать содержимое любой области память компьютера, включая память ядра и других пользователей. Проблема также позволяет получить доступ к чужой памяти в системах виртуализации и контейнерной изоляции, например, пользователь одной виртуальной машины может получить содержимое памяти хост-системы и других виртуальных машин. Уязвимости подвержены процессоры Intel (фактически все процессоры, выпускаемые с 1995 года, за исключением Intel Itanium и Intel Atom, выпущенных до 2013 года) и ARM64 (Cortex-A15/A57/A72/A75). Подготовленный прототип эксплойта позволяет читать память ядра со скоростью 2000 байт в секунду на процессоре Intel Xeon архитектуры Haswell.
Уязвимость Spectre (CVE-2017-5753, CVE-2017-5715) создаёт брешь в механизме изоляции памяти приложений и позволяет атакующему обманным способом получить данные чужого приложения (только приложения, но не памяти ядра). Этой атаке подвержены процессоры Intel, AMD (только при включенном eBPF в ядре) и ARM64 (Cortex-R7/R8, Cortex-A8/A9/A15/A17/A57/A72/A73/A75). По сравнению с Meltdown уязвимость существенно труднее в эксплуатации, но её и значительно труднее исправить.
Применение патча обязательно так как пользователи ежедневно запускают чужой код на своих компьютерах, посещая веб сайты с JavaScript (>99%) и одним из инструментов совершения атаки может стать web-браузер. Разработчики Google Chrome работают над интеграцией защиты от совершения атаки через JavaScript прямо в браузер. Исправление будет доступно в релизе Chrome, назначенном на 23 января. Сложности также создаёт то, что атаку можно провести незаметно, без оседания следов в логах.
Обновление для блокирования Meltdown уже выпущено для RHEL и Fedora. Проследить за появлением обновлений в других дистрибутивах можно на следующих страницах: Debian, Ubuntu, SUSE(частично исправлена), openSUSE, FreeBSD, OpenBSD, NetBSD. Исправления для Windows и macOS ожидаются в ближайшее время. Для платформы Android исправления были доставлены в последнем обновлении. Проблема также устранена в Chrome OS 63.
Раскрыты детали новой техники атаки KRACK (Key Reinstallation Attacks), позволяющей вклиниться в беспроводное соединение на базе технологии WPA2 и организовать перехват или подстановку трафика без подключения к беспроводной сети и без определения пароля доступа. Новая техники атаки сводит на нет уровень защиты WPA2, делая работу через WPA2 не более защищённой чем, работа в публичной WiFi-сети. Всем пользователям рекомендуется обязательно использовать дополнительные уровни защиты при работе с конфиденциальными данными при соединении через WPA2, такие как VPN или обращение к ресурсам только по HTTPS.
Атака затрагивает концептуальную недоработку в стандарте WPA2, что делает уязвимыми все корректные реализации стандарта, независимо от применяемых шифров (WPA-TKIP, AES-CCMP, GCMP). В том числе наличие проблемы подтверждено в Android, Linux, macOS, iOS, Windows, OpenBSD, MediaTek и Linksys. Наибольшую опасность представляет уязвимость в пакете wpa_supplicant, для которого проведение атаки существенно упрощается, так как в версиях wpa_supplicant 2.4+ дополнительно найдена уязвимость, при помощи которой атакующие могут перевести соединение на работу с пустым ключом шифрования и полностью контролировать трафик. Уязвимость связана с тем, что после установки ключ очищается из памяти, поэтому операция переустановки приводит к использованию пустого ключа. Wpa_supplicant используется в платформе Android 6+ и дистрибутивах Linux, что делает данные системы наиболее уязвимыми при доступе в сеть через WPA2. Для других реализаций возможна выборочная расшифровка кадров.
Атака сводится к инициированию процесса перенастройки сессионных ключей шифрования WPA/WPA2/RSN (TK, GTK или IGTK), путём отправки клиенту или точке доступа специально оформленного кадра. Подобная перенастройка может быть использована злоумышленником для отключения защиты от повторного воспроизведения и существенного снижения стойкости шифрования до уровня, позволяющего, в зависимости от применяемого шифра, выполнить расшифровку содержимого передаваемых кадров или определить части ключей шифрования.
В частности, так как атакующий добивается переустановки уже используемого ключа в процессе согласования соединения, то осуществляется сброс привязанного к соединению номера передаваемых пакетов (nonce) и сбрасывается счётчик полученных ответов. Таким образом появляется возможность повторного использования одноразового значения "nonce". В зависимости от настроек беспроводной сети атакующий может организовать прослушивание трафика или манипуляцию данными, например, осуществить подстановку вредоносного кода на страницы сайтов, получаемые без HTTPS.
Опасность проблемы сглаживает то, что уязвимость может быть устранена без нарушения обратной совместимости, путём наложения патча на стороне клиента. Проблема будет устранена в hostapd/wpa_supplicant 2.7, но уже доступны патчи и пакеты с исправлением сформированы для Debian и Fedora, а в ближайшие часы ожидаются для Ubuntu, RHEL и SUSE. Из производителей оборудование обновление прошивки пока выпустил только Mikrotik. В OpenBSD проблема была устранена ещё конце августа, так как разработчики данной системы отказались откладывать исправление до окончания эмбарго, но согласились не афишировать связь исправления с уязвимостью до общего анонса.
После сегодняшнего раскрытия информации, WPA2 более нельзя будет считать надежным, как это некогда произошло с WEP. Под ударом, вероятнее всего, окажутся миллионы сетевых устройств и их владельцы, а использования Wi-Fi придется избегать до выхода патчей. И если роутеры, скорее всего, получат обновления для этих потенциальных проблем, что произойдет с сонмом IoT-устройств, можно только догадываться.
Мало кто знает, что буква S в аббревиатуре IoT означает Security
Отличный комментарий!
Более простым языком
Атака состоит в том, что можно сбросить IV (или nonce, в терминологии wifi) на клиенте. Таким образом можно заставить клиента использовать тот же самый keystream ещё раз. А потом ещё раз. И ещё. Дальше мы ксорим два потока данных с одинаковым keystream между собой и таким образом снимаем шифрование. Остаются просто расшифрованные данные, поксоренные между собой.
Если используется AES — то прослушка всего трафика, если TKIP или GCMP — то еще и подмена.
Номера уязвимостей:
CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
Ubiquiti выпустили обновление
We've prepared firmware 3.9.3.7537. Please see below for the changelog and links to the firmware binaries.
Firmware changes from 3.9.2:
[ACIWPro] Enable DFS support.
[UAP] Add more security details to scan info.
[UAP] Security patch for the WPA2 vulnerability called KRACK (details HERE).*
[UAP] Various backend fixes and/or improvements.
[USXG] Fix fastpath tools.
[HW] Improve error codes returned on firmware upgrade fail.
В LEDE бекпортировали исправления. Пока только в транке, обновлений к стабильному выпуску не выходило.
Кинетики пропатчены в 2.11.A.4.0-1 и в официальной beta тоже поправлено.
Атака состоит в том, что можно сбросить IV (или nonce, в терминологии wifi) на клиенте. Таким образом можно заставить клиента использовать тот же самый keystream ещё раз. А потом ещё раз. И ещё. Дальше мы ксорим два потока данных с одинаковым keystream между собой и таким образом снимаем шифрование. Остаются просто расшифрованные данные, поксоренные между собой.
Если используется AES — то прослушка всего трафика, если TKIP или GCMP — то еще и подмена.
Номера уязвимостей:
CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
Ubiquiti выпустили обновление
We've prepared firmware 3.9.3.7537. Please see below for the changelog and links to the firmware binaries.
Firmware changes from 3.9.2:
[ACIWPro] Enable DFS support.
[UAP] Add more security details to scan info.
[UAP] Security patch for the WPA2 vulnerability called KRACK (details HERE).*
[UAP] Various backend fixes and/or improvements.
[USXG] Fix fastpath tools.
[HW] Improve error codes returned on firmware upgrade fail.
В LEDE бекпортировали исправления. Пока только в транке, обновлений к стабильному выпуску не выходило.
Кинетики пропатчены в 2.11.A.4.0-1 и в официальной beta тоже поправлено.
Давай ещё более простым языком, ладно?
Здесь мы собираем самые интересные картинки, арты, комиксы, мемасики по теме уязвимость (+23 постов - уязвимость)
Собираем на сервера
В этом месяце собрано $634.21 из $1360.00.
Наши любимые теги
Топ комментов
А бывает, комменты лучше постов. Смотрим топ тредов и вникаем!
Отличный комментарий!