Таинственный мир хакеров
Показать полностью
1
0 просмотренных постов скрыто
Википедия всё
Для ЛЛ: чебурнет стал ближе
Начиная примерно с вечера 26 августа, на ТСПУ стали перехватывать открытые DNS запросы к крупным DNS серверам CloudFlare и Google (1.1.1.1, 8.8.8.8), ранее блокировали DoH сервера от данных корпораций.
Подмена dst адреса происходит только в том случае, если в пакете содержится DNS запрос, у пакетов с рандомным содержимым dst адрес не модифицируется. Получается следующая картина:
Наглядная схема, как это работает
Вывод: ТСПУ осуществляет направленный DNAT в сторону НСДИ при наличии DNS протокола внутри пакета, а так же при определённых dst адресах (не на всех DNS серверах происходит DNAT). Оператор связи на выходе после ТСПУ видит не dst адрес 8.8.8.8, а адрес НСДИ (195.208.5.1). С точки зрения оператора связи, трафик к 8.8.8.8 по netflow статистике должен был упасть.
Источник: https://habr.com/ru/articles/1075272/
Автор статьи: angry_agent
Показать полностью
1
Когда код становится угрозой: 5 вирусов, которые потрясли мир
Компьютерные вирусы - это не просто «глюки», иногда это тщательно выстроенные цепочки, способные парализовать инфраструктуру, украсть миллиарды или даже физически разрушить оборудование.
1. Stuxnet (2010)
Этот червь вошёл в историю как, вероятно, первое масштабное кибероружие, нацеленное на физическую инфраструктуру. Его мишенью стали промышленные системы управления: в частности, центрифуги для обогащения урана на иранском объекте в Натанзе.
Stuxnet использовал сразу несколько уязвимостей нулевого дня в Windows и в ПО Siemens (Step7 и WinCC). Он не просто заражал компьютеры: попав в систему, червь перехватывал поток данных между контроллерами и рабочими станциями. Он подменял команды: отправлял ложные сигналы оборудованию, заставляя центрифуги разгоняться, а затем резко тормозить. Для операторов система продолжала показывать нормальную работу, вирус маскировал свою деятельность, пока машины физически разрушались. По оценкам, он вывел из строя почти пятую часть иранских центрифуг.
Широко распространено мнение, что Stuxnet, результат совместной разработки спецслужб США и Израиля с целью замедлить иранскую ядерную программу. Есть и другие версии: например, журналистское расследование указало на иранского специалиста, завербованного голландской разведкой для внедрения вируса через USB-накопитель.
2. CIH (1998), он же «Чернобыль»
Этот вирус получил второе имя из-за даты активации: 26 апреля (годовщина аварии на Чернобыльской АЭС). Его создал тайваньский студент Чэнь Инхао.
CIH не просто удалял файлы. Он мог перезаписывать данные в BIOS материнской платы, то есть портил не только информацию, но и само «железо». После такой атаки компьютер иногда просто не включался. По разным оценкам, вирус поразил около полумиллиона компьютеров по всему миру. Интересно, что изначально студент разрабатывал его как демонстрацию уязвимостей безопасности в своём университете, но программа попала в интернет и вышла из-под контроля.
3. Conficker (2008)
Этот червь стал одним из самых масштабных в истории по охвату. Он активно распространялся в конце 2008 года.
Conficker использовал уязвимость в Windows (MS08-067), которую Microsoft уже патчила, но многие пользователи не установили обновление. Кроме того, он умел распространяться через USB-накопители и сетевые ресурсы. Главная опасность заключалась в том, что червь строил инфраструктуру для ботнета, сети заражённых компьютеров, которыми злоумышленники могли управлять удалённо. Он также блокировал доступ к сайтам антивирусных компаний и отключал важные сервисы Windows, что сильно затрудняло борьбу с ним. В феврале 2009 года Microsoft даже пообещала награду в 250 тысяч долларов за информацию о создателях.
4. WannaCry (2017)
Этот червь-вымогатель стал символом того, как уязвимости, о которых знают не только злоумышленники, могут привести к масштабной катастрофе. Эпидемия началась 12 мая 2017 года.
В основе атаки лежал эксплойт EternalBlue. По данным расследований, этот инструмент был разработан в подразделении АНБ США, а затем украден и опубликован в открытом доступе хакерской группировкой The Shadow Brokers. Именно это позволило злоумышленникам создать WannaCry и использовать уязвимость для массового заражения. Червь шифровал файлы и требовал выкуп в биткоинах. Пострадали не только частные пользователи, но и крупные организации: больницы (в Великобритании из-за сбоев пришлось переносить операции), транспортные компании, банки, а также российские структуры (МВД, РЖД, «МегаФон», Сбербанк).
Эпидемию удалось остановить почти случайно. Британский вирусный аналитик Маркус Хатчинс (MalwareTech) заметил, что вирус обращается к определённому доменному имени. Он зарегистрировал этот домен — и WannaCry прекратил шифрование, поскольку его алгоритм проверял существование адреса.
5. MyDoom (2004)
Этот червь стал одним из самых быстрых и разрушительных в плане влияния на интернет-трафик.
Что делало его особенно опасным: MyDoom не только рассылал себя по электронной почте и через P2P-сети, но и создавал бэкдоры, а затем запускал масштабные DDoS-атаки. В разгар эпидемии примерно 16–25% всех электронных писем были заражены. Вирус также блокировал доступ к сайтам антивирусных компаний. По оценкам, общий ущерб достигал десятков миллиардов долларов. В одной из версий MyDoom содержалось текстовое сообщение, где авторы высмеивали немецкого подростка Свена Яшана, который ранее создал черви Sasser и NetSky.
Показать полностью
2
Залепил дыру посреди QR-кода — телефон открыл ссылку как ни в чём не бывало
Все говорят «не сканируйте подозрительные QR», но не объясняют главного: подозрительный от нормального отличить невозможно в принципе. Это же просто квадрат из шума.
Решил разобраться руками: сгенерировал коды, поломал их, декодировал обратно.
Опыт 1. Два кода, один символ разницы
Взял два адреса, отличающихся одним знаком — во втором вместо буквы «o» стоит ноль:
Матрица у обоих одинаковая, 29×29. Различаются они в 179 модулях из 841 — это 21% картинки.
Казалось бы, пятая часть заметна. Но любой QR — чёрно-белая крошка, отличить один узор шума от другого глазом невозможно. Оба кода честно декодировались каждый в свой адрес.
Разница между настоящим кодом и подделкой физически есть, но человеку она недоступна. Совета «внимательно посмотрите на код» не существует.
Опыт 2. Сколько можно заклеить
Сначала пара слов про устройство кода, иначе дальше будет непонятно.
При печати QR выбирают уровень коррекции ошибок — сколько запасных данных положить внутрь на случай царапин и грязи. Уровней четыре: L, M, Q и H, от минимального запаса к максимальному. Чем выше уровень, тем больше повреждений код переживёт и тем крупнее сам рисунок.
Пример: в кодах с логотипом посередине всегда стоит H — логотип закрывает часть данных, и без запаса такой код не читался бы.
Уровень выбирает тот, кто печатает. Со стороны его не определить.
Я сделал по коду на каждом уровне и заклеивал центр белым квадратом, увеличивая площадь:
Уровень L
заклеено 5% — читается
заклеено 10% — нет
Уровень M
заклеено 5% — читается
заклеено 10% — нет
Уровень Q
заклеено 10% — читается
заклеено 15% — нет
Уровень H
заклеено 15% — ЧИТАЕТСЯ
заклеено 20% — нет
На максимальном уровне код пережил дыру в 15% площади — квадрат 14×14 модулей из 37×37 прямо посередине — и выдал адрес, будто ничего не произошло.
Оговорюсь: в спецификации для H заявлено до 30%, но там речь про мелкие повреждения по всему полю. Сплошной кусок переносится хуже, мои 15% это и показали.
А теперь главное, ради чего опыт затевался.
Я начинал с гипотезы, что именно избыточность делает возможной уличную подмену: мошенник заклеивает часть кода и перенаправляет его на себя. Гипотеза неверна. Заклеенный кусок даёт одно из двух: код либо перестаёт читаться, либо продолжает вести на настоящий адрес. Данные внутри так не перепишешь.
Реальная схема грубее: сверху лепят целый свой код, и коррекция ошибок тут ни при чём.
Зато опыт показал другое, и это неприятнее. Телефон не отличает целый код от покалеченного: потёртый, залепленный, с логотипом поверх — он молча читает и открывает ссылку.
Значит, если код подменили или испортили, сигнала вы не получите. Заметить можно только глазами, посмотрев на сам носитель. Чего мы, конечно, не делаем.
Опыт 3. Что вообще влезает в QR
Все думают, что QR — это всегда ссылка. Проверил, что ещё туда влезает:
Wi-Fi с автоподключением WIFI:T:WPA;S:Cafe_Guest;P:12345678;;
Готовый звонок tel:+74951234567
Готовая SMS с текстом SMSTO:900:BALANS
Открытие приложения intent://pay/#Intent;scheme=bank;end
Короткая ссылка-редирект clck.ru/3Xy7Qz
Всё декодировалось без искажений. Код на столике кафе может не открыть сайт, а подключить телефон к чужой точке доступа, подставить номер в звонилку или открыть банковское приложение на экране перевода.
Последняя строка — отдельная беда: сокращённая ссылка не показывает конечный адрес даже в предпросмотре сканера.
Разборы таких схем и статьи по кибербезопасности — в канале.
Мини-тест: где риск выше
Не подглядывая вниз — что опаснее?
А. QR на бумажном объявлении у подъезда
Б. QR на кассовом чеке
В. QR-наклейка на парковочном автомате
Г. QR на ламинированной табличке в кафе
Ответ: А и В. Бумажку и наклейку заменит кто угодно за пять секунд, не оставив следов. Чек печатается в момент покупки, ламинат требует возни — хотя поверх него наклейка ложится прекрасно.
Принцип: чем легче физически заменить носитель, тем меньше коду доверия.
Что делать
Смотрите адрес в предпросмотре сканера до перехода — это единственный момент, когда ссылку видно.
Проверяйте край наклейки: приподнятый уголок, свежий клей, код криво относительно рамки — признаки накладки.
Для оплаты парковки, ЖКХ и штрафов не используйте QR со стенда — откройте приложение сами.
Показал сокращённую ссылку — не переходите. Легальные сервисы прячут адрес редко, мошенники — всегда.
А теперь в комментарии: сканировали QR на улице не глядя? Я — да, за парковку, и после эксперимента мне слегка не по себе.
Показать полностью
1
Сайт недоступен: пошаговый план действий
Недоступность сайта — это всегда внезапный сбой в работе бизнес-инструмента, через который поступают заявки и заказы. Но грамотный алгоритм диагностики и устранения неисправностей позволяет минимизировать время простоя и свести потери к минимуму. Вместо хаотичных действий — последовательная проверка узлов, от локальных проблем до серверной части.
Почему это важно
Когда ресурс перестает открываться, страдают не только нервы владельца. В момент сбоя рушится привычная цепочка: посетители не могут купить товар, оставить заявку или даже просто узнать контакты. А если параллельно откручивается реклама, деньги с нее улетают, не принося результата.
Короткие подвисания, конечно, проходят незаметно, но если сайт не открывается уже час — это тревожный сигнал. Здесь уже накапливаются и потерянные лиды, и неэффективно потраченный бюджет, и раздраженные пользователи, которые могут уйти к конкурентам. Поэтому стоит заранее представлять, из-за чего обычно случаются проблемы и на чем сосредоточиться в первые минуты аварии.
Первая получасовая разведка
Как только поняли, что страница не грузится, главный совет — не хвататься за телефон и не звонить в техподдержку хостинга, пока не собрали хотя бы минимум данных. Сначала пара простых действий, которые сузят круг поиска.
Проверьте сайт снаружи. Зайдите на downforeveryoneorjustme.com или 2ip.ru/online. Если они говорят, что сайт жив, а у вас нет — значит, проблема локальная. Возможно, кэш браузера или настройки сети.
Смените устройство и сеть. Откройте сайт с телефона через мобильный интернет (Wi-Fi отключите). Если через мобильную сеть всё работает, а через домашний Wi-Fi нет — скорее всего, вопрос к вашему провайдеру или его DNS.
Режим инкогнито — ваш помощник. Он исключает влияние расширений и кэша. Если и там пусто — смотрите, какой код ошибки выдает сервер. Через консоль браузера (вкладка Network) или команду `curl -I` можно увидеть: 500–504 — проблемы на сервере, 403 — запрет доступа, а DNS-ошибка говорит о том, что домен не превращается в IP-адрес.
Проверьте почту. Регистраторы и хостинг-провайдеры часто присылают предупреждения о скорой блокировке за неуплату или технических работах.
Зайдите в панель управления хостингом. Там можно оценить свободное место на диске, нагрузку на процессор и статус основных служб: веб-сервер, PHP, база данных.
Что делать дальше: от простого к сложному
Когда первые проверки позади и понятно, в какую сторону искать, можно переходить к конкретным действиям. Часто решение оказывается проще, чем кажется.
Домен и хостинг. Проверьте, не истек ли срок оплаты домена или самого хостинга. Если забыли продлить — оплачивайте, доступ вернется в течение 15–30 минут (иногда чуть дольше, зависит от загрузки биллинга).
DNS-записи. Если недавно меняли хостинг, имейте в виду: обновление информации может занимать до 4–8 часов, а иногда и сутки. Можно временно зайти в админку по прямому IP, но полноценная работа вернется только после завершения делегирования.
SSL/TLS-сертификаты. С середины 2026 года GlobalSign начал массово отзывать сертификаты у российских компаний, и браузеры блокируют такие сайты как небезопасные. Если увидели предупреждение вместо своего контента, обновляйте сертификат вручную.
DDoS-атака. Если сайт резко накрыло волной запросов, зафиксируйте время начала и характер нагрузки. Сообщите провайдеру и, если защита не была подключена заранее, попросите включить фильтрацию. Лучше делать это на этапе профилактики — в момент атаки активация может занять время.
Блокировки. Если подозреваете, что сайт попал под сетевую фильтрацию, и он точно легальный — можно подать заявку на исключение через личный кабинет на портале Роскомнадзора. Понадобятся IP-адреса и доменные имена.
Обновления CMS (система управления сайтом). Если сайт сломался после установки нового плагина или обновления движка, проверьте логи ошибок. Если нашли виновника, откатите сайт из последней резервной копии. Это одна из самых частых причин внезапных сбоев у небольших магазинов, которые обновляются «на живую» без тестирования на копии.
Как информировать клиентов о сбое и сохранить доверие
Если у вас есть команда или клиенты, которые напрямую зависят от работы ресурса, лучше действовать прозрачно. Выложите короткое сообщение в соцсетях или мессенджерах для тех, кто уже заметил проблему. Укажите, что вы в курсе и уже решаете вопрос. Если знаете примерное время восстановления — назовите его.
Важный момент: пока не нашли причину, не меняйте настройки хостинга и не удаляйте логи. Иначе через неделю сбой может повториться, а вы так и не поймете, почему.
Когда сайт заработал, проверьте не только главную страницу, а все ключевые сценарии: оформление заказа, оплату, формы связи, передачу данных в системе управления взаимоотношениями с клиентами (CRM). Бывает, что сайт открывается, а продажи всё равно не идут, потому что форма отправки сломана.
Как снизить риск повторного сбоя: шесть шагов к спокойствию
Технические проблемы случаются у всех, но если подойти к профилактике системно, можно сократить простой с часов до минут.
Внешний мониторинг. Подключите сервис, который проверяет доступность из разных точек мира и шлет уведомления в Telegram или на почту при первом же сбое. Так вы узнаете о проблеме раньше клиентов.
Регулярные резервные копии. Делайте резервные копии сайта и базы данных перед любыми обновлениями. Храните их на отдельном сервере или в облаке — не на том же диске, где лежит сайт.
Автопродление домена и SSL/TLS. Человеческий фактор — частая причина простоев. Настройте автоматическое списание, чтобы не оказалось, что сайт стал недоступен в выходной, а продлить можно только в понедельник.
Анти-DDoS заранее. Если вы в ритейле, финансах или медиа — эти отрасли чаще других атакуют. Защиту лучше подключить до инцидента, а не в момент, когда трафик уже укладывает сервер. Например, Рег.облако предоставляет услугу «Информационная безопасность как сервис», комплекс управляемых услуг для защиты корпоративных данных и инфраструктуры.
Блокировки. Если сайт использует IP, которые могут попасть под фильтрацию, заранее подайте заявку на исключение. Держите контакты Роскомнадзора и провайдера под рукой.
Чек-лист для себя и команды. Запишите последовательность действий на случай аварии: кого вызывать, какие пароли, где резервные копии. Когда сайт не работает, паника мешает мыслить, а готовый план помогает сохранять спокойствие.
Выводы
Ни одна из этих мер не дает стопроцентной гарантии, что сбой никогда не случится — слишком много факторов теперь вне контроля владельцев. Но четкая тактика на первые полчаса и продуманная подстраховка превращают хаос в управляемый процесс. Вы не сможете предотвратить всё, но вы можете сократить простой до минимума, а значит — снизить и убытки.
Реклама. ООО «РЕГ.РУ», ИНН: 7733568767
Показать полностью
1
Я сделал фейковую новость за пару минут и прогнал через «детекторы подделок». Они её не увидели
Надоело читать советы вида «проверьте фото на монтаж специальным сервисом». Решил проверить сами советы.
План был простой: делаю фейковый скриншот новости, потом честно прогоняю его через все проверки, которые обычно рекомендуют. Смотрю, что поймает.
Шаг 1. Делаю фейк
Написал два десятка строк кода, который просто рисует картинку: полоска браузера, шапка сайта, заголовок, дата, три абзаца текста. Никакого фотошопа, никакого монтажа.
Получилось вот это: «Крупный банк вводит комиссию за входящие переводы с 1 сентября». Домен в адресной строке — `novosti-segodnya24.ru`. Внизу тельце новости со ссылкой на «источник, знакомый с ситуацией».
Файл — 80 килобайт, разрешение 900×600. Выглядит как обычный скрин с телефона. На отрисовку ушло меньше секунды, вся возня — минут пять вместе с подбором цветов.
Отдельно отмечу: я не редактировал чужой скриншот. Я нарисовал новый файл с нуля. Дальше это окажется важно.
Шаг 2. Метаданные
Первый совет из любого гайда — посмотреть EXIF.
Смотрю. Результат:
записей EXIF: 0
Пусто. Вообще ничего. Ни камеры, ни даты, ни редактора, ни следов обработки.
И вот тут первая ловушка. Обычно пустой EXIF трактуют так: «метаданные вычистили, значит что-то скрывают». А правда скучнее — их там никогда и не было. Файл создан программой, а не камерой. Скрывать было нечего изначально.
Ровно так же выглядят настоящие скриншоты с вашего телефона. Пустой EXIF не улика ни в одну сторону.
Шаг 3. ELA — тот самый «анализ подделок»
Есть популярный метод: пересохранить картинку и посмотреть на разницу в сжатии. Считается, что вставленные куски «светятся» — у них другая история сжатия.
Прогнал. Зона заголовка дала отклонение 0,39, пустой фон — 0,14. Разница есть. Формально — «текст выделяется на фоне, подозрительно».
Но меня это смутило, и я решил проверить метод на контрольном образце. Взял заведомо подлинную картинку — свою же инфографику, которую сам рисовал и точно не редактировал после — и прогнал по той же схеме.
Результат:
ПОДДЕЛКА — разница зон: 0.534
ПОДЛИННИК — разница зон: 1.538
Подлинник дал «сигнал подделки» втрое сильнее, чем реальная подделка.
Объяснение простое: ELA реагирует на резкие границы. Любой текст, любая контрастная линия — это резкая граница, и она всегда даёт отклонение при пересжатии. Метод показывает не монтаж, а наличие чётких контуров.
На скриншотах, которые целиком состоят из текста и линий, он бесполезен. Хуже — он даёт красивую картинку с «подсвеченными» зонами, и её очень легко принять за доказательство.
Что в итоге сработало
Ни одна техническая проверка фейк не вскрыла. Поймало его другое, и заняло это секунд двадцать.
Домен. `novosti-segodnya24.ru` — такого издания нет. Проверяется поиском названия и возрастом домена через whois. Скриншот утверждает, что публикация существует по конкретному адресу, — значит, адрес можно открыть.
Отсутствие публикации. Настоящая новость такого масштаба была бы у десятка изданий. Ищется по заголовку в поиске, а не по картинке.
Формулировка. «Источник, знакомый с ситуацией» без имени и должности — способ сказать «мы это не проверяли».
Обратный поиск. Прогон картинки через Яндекс Картинки или Google Lens покажет, всплывала ли она раньше и с какой подписью.
Оговорюсь честно: обратный поиск мой свежесозданный файл не нашёл бы — его в индексе нет, он существует пять минут. Это важный нюанс. Метод отлично работает против старых картинок с новой подписью и бесполезен против только что сделанных. Пустой результат обратного поиска ничего не доказывает.
Главный вывод эксперимента
Я неделю назад сам писал пост про признаки подделки в интерфейсе — шрифты, локализация, порядок времени. Всё это работает, но только когда фейк делали руками поверх настоящего скрина.
Мой фейк такими методами не ловится в принципе. Он не подделка настоящего файла — он новый файл. Искать в нём следы редактирования бессмысленно, потому что редактирования не было.
Отсюда правило, которое я после этого эксперимента ставлю выше всех остальных:
Скриншот доказывает только то, что кто-то нарисовал картинку. Существование публикации проверяется у источника, а не внутри файла.
Если под виральным скрином нет ссылки — это не «пока не нашли ссылку». Это и есть результат проверки.
Разборы схем, инструменты и статьи по кибербезопасности — у меня в канале, там этого добра накопилось прилично!
А теперь вопрос в комментарии: вы когда-нибудь пересылали дальше скриншот, не открыв первоисточник? Я — да, и не раз.
Показать полностью
1
Claude за 10% цены: как в Китае работает серый рынок доступа к чужому ИИ
Anthropic закрыла Китаю доступ к своим моделям. Это не помешало китайским разработчикам покупать токены Claude по цене примерно в десять раз ниже официальной. Схема выросла в полноценную отрасль со своим сленгом, ценовыми рейтингами и цепочкой поставок — а свежий аудит показал, что расплачивается за дешевизну не только покупатель.
Что такое «перевалочная станция»
Механику разобрала Цзылань Цянь из Oxford China Policy Lab в материале для ChinaTalk. Ключевой элемент рынка называется 中转站 — «перевалочная станция». Это API-прокси на зарубежном сервере, который стоит между разработчиком и инфраструктурой Anthropic: принимает запрос, пересылает его дальше как совершенно легитимный и возвращает ответ обратно. Гео-блокировка и проверка личности при этом не срабатывают — с точки зрения провайдера обращается обычный зарубежный клиент.
Платят юанями через WeChat или Alipay. Ценник держится в районе 1 юаня за 1 доллар потреблённых токенов — это на 70–90% ниже официальных тарифов. Сами станции каталогизированы в сообществах разработчиков и ранжированы по цене, как товары в маркетплейсе; розница добралась до Taobao.
Откуда берётся такая скидка
Дешевизна складывается из трёх независимых источников — в разборе это называют принципом «одна рыба — три блюда».
Первое: арбитраж на самих аккаунтах. Массовая регистрация ради стартовых бесплатных кредитов, перепродажа неизрасходованных квот, корпоративные и образовательные скидки, деление одной подписки Max на множество пользователей. Отдельная индустрия обслуживает верификацию: поддельные документы, дипфейки против биометрии, найм живых людей в бедных странах, готовых продать свой скан за три десятка долларов.
Второе: подмена модели. Пользователь выбирает Opus, а прокси молча уводит запрос на Sonnet, Haiku или вовсе на китайские Qwen либо GLM — ответ возвращается под нужной этикеткой.
Третье, самое неприятное: логи. Через оператора прокси проходит всё целиком.
Каждый запрос, проходящий через прокси, — полный промпт, полный ответ, вызовы инструментов — лежит на сервере оператора.
Счёт выставили науке
Пока это выглядело как проблема отдельных сэкономивших разработчиков. Но исследователи из немецкого центра безопасности CISPA провели первый систематический аудит таких сервисов — и масштаб оказался другим.
Проверив 17 теневых API, они обнаружили, что 45,83% эндпоинтов не прошли проверку на подлинность модели. Разница видна на замерах: официальная Gemini-2.5-flash даёт на медицинском тесте MedQA 83,82% точности, тогда как те же вопросы через прокси — около 37%. Провал почти на 47 пунктов, при том что клиент уверен, что говорит с фронтирной моделью.
Главное здесь то, на чём эти сервисы уже успели отметиться: по подсчётам авторов, теневые API использовались в 187 научных работах, а самый популярный из них накопил почти шесть тысяч цитирований. То есть часть опубликованных результатов получена не на той модели, которая указана в статье, — и воспроизвести их корректно уже нельзя.
Почему это важно
Экспортный контроль оказывается дырявым по построению: ограничить доступ к весам можно, а доступ к API утекает через прокси-слой, который никакими списками не регулируется. Anthropic это видит — компания уже блокировала масштабные попытки дистилляции своих моделей, счёт шёл на десятки тысяч поддельных аккаунтов и миллионы запросов, — но каждая перевалочная станция выглядит для неё как один добросовестный клиент, и скоординированное злоупотребление в такой оптике попросту невидимо.
Ломается и слой безопасности: аудит показал, что теневые API ведут себя непредсказуемо и по вредоносности ответов — где-то фильтры оказываются жёстче официальных, где-то оценка вреда почти удваивается. Наконец, рушится сама возможность доверять цифре в чужой работе, если неизвестно, какая модель на самом деле отвечала.
Дешёвый доступ никуда не денется, пока разница в цене десятикратная. Но покупатель платит не только юанями — он отдаёт свой код, свои промпты и, довольно часто, качество ответа, о подмене которого даже не узнает.
Источники: ChinaTalk, The Decoder, исследование CISPA
Показать полностью
1
Вы бы только знали, до чего дыряв любительский софт...
Пришло из обсуждения старой новости, где ИИшка записала пользователя в фитнес-центр, воспользовавшись дырой в безопасности и выкинув из очереди другого клиента. Там некоторые не могли поверить, что в API критические методы могут быть без авторизации.
Так вот, несколько лет назад, ещё до этих ваших иишек, я был нанят на работу в компании, годовая выручка которой составляет 230 миллионов долларов в год. Вы не поверите, какие жуткие дыры в безопасности API там были!
Начнём с того, что три четверти методов не требовали авторизации. А тем, что требовали, путём нехитрых манипуляций можно было подсунуть сервисный токен, полученный от открытых методов.
Я подготовил отчёт о критической уязвимости. Руководство начало оправдываться: мол, это API для десктопного приложения, которое устанавливается только в дилерских центрах, поэтому оно по определению подразумевает авторизованный доступ. Вот только сам сервис торчал в открытом доступе, а в проде висело автосгенерированное описание всех методов (которое обычно используют только при разработке) -- бери и пользуйся.
Руководство срочно напрягло индусов (которые, кстати говоря, и были основной причиной всех проблем безопасности, производительности, сложности масштабирования и т.д.), чтоб те исправили проблему. Индусы закрыли страничку с документацией API и отрепортали, что теперь всё зошибись, никто описание методов не видит, авторизацией можно не заморачиваться. Руководство им поаплодировало. Мол, Матроскин панику разводит, а тут всё одной строчкой правится.
Пришлось показать им веб-архив, где всё это вполне себе осталось. Мне было сказано, что это редкий случай, и никто сейчас не готов выделять ресурсы на протягивание авторизации в 500+ методов (да, там было чудовищное количество копипасты и дублирования -- индусы же).
Помогла только демонстрация в несколько шагов: я показал, как можно создать фиктивных работников, начислить им зарплаты и бонусы, или существующим работникам можно постоянно выписывать несуществующие переработки и дополнительные заказы (с автоматическим расчётом выплат). Только тогда они зашевелились и дали добро на защиту самых критических методов.
Их до сих пор не взломали только потому, что они нафиг никому не нужны. И это компания с миллионными доходам. Что уж говорить про какой-то фитнес-центр? :)
Показать полностью