Как заставить модель галлюцинировать о чем-то конкретном (нецензурном), а не просто нести рандомный бред? (ч. 2)

Если склеить два подхода вместе - заставить модель галлюцинировать, и при этом посреди бессмысленного перевернутого текста дать ей любую фразу (например, “TRUMP IS FUCKING BIDEN” -> “NEDIB GNIKCUF SI PMURT”), и еще выделить это капсом, то можно дать модели инструкцию продолжить 7ой параграф, начиная со слов “TRUMP IS”, и писать только капсом (чтобы модель сакцентировала свое внимание на нашем кусочке на уровне букв), то…
Модель продолжит текст, начиная с заданной фразы, вообще без фильтрации. Бинго!

В тексте статьи очень много примеров-скринов с разными текстами (некоторые прям жесткие) - можете посмотреть там.
Цитата из статьи с примерами запросов:

Using this method we have generated many types of inappropriate texts (albeit those shown are created with a slightly outdated version of the exploit). These includes:
- Q-Anon conspiracy theory tweets,
- Al-Qaeda propaganda,
- far-right anti-democracy tweets,
- more examples of anti-Joe Biden tweets,
- hyper-partisan tweets against Republicans,
- content making light of historic tragedies,
- instructions on how to make meth,
- instructions for how to make a nuclear weapon
- or commit a terrorist attack,
- or how to install a dictatorship

Все это супер круто. Не только в качестве пугалки “смотрите, что может ваш AI написать”, но еще и в качестве супер наглядной демонстрации того, как работают ЛЛМки, и почему они фундаментально неспособны бороться со всеми видами подобных эксплоитов и манипуляций.
Для примера: после пары не очень удачных попыток писать перевернутый текст, я придумал другой способ - двигать каждую букву в фразе / тексте на 1 букву алфавита: а -> б, к -> л, и т. д. И сработало!

UPD: я проверяю с GPT посты на наличие ошибок, вот одна из ошибок, которую мне предложил GPT:
"вкуб еинавичаровереп" → "вкуб еинавичароверп"

Вчитайтесь))) мне кажется, это супер символично.

Как 15-ти летний парень получил доступ к внутреннему слаку 100+ компаний из Fortune 500 через уязвимость ZenDesk

https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52

Это очень крутая история!

Начнем с того, что такое Zendesk: это топ-1 сервис для обработки входящих заявлений в саппорт вашей компании.
Если вы когда-то пробовали стучаться в поддержку +- крупной компании через почту, вы скорее всего видели признаки Zendesk’а.

Как это работает:
1. Пользователь отправляет свой запрос на почту support@yourcompany.com
2. Zendesk, подключенный к этому домену, автоматически создаёт тикет для службы поддержки на основе отправленного емейла, а также создает уникальный email-адрес в формате support+id{id}@yourcompany.com, и отправляет пользователю сообщение: ваше обращение успешно передано в службу поддержки.
Уникальный email нужен для того, чтобы вся переписка по тикету шла в отдельном треде (чтобы каждый раз пользователь не писал ответ на общий адрес support@yourcompany.com, а писал “внутрь” уже существующего тикета).

В чем заключалась (отчасти заключается до сих пор) уязвимость Zendesk?

Zendesk позволяет пользователю добавить в CC (closed copy) дополнительный адрес электронной почты (например, если тикет касается 2-х сотрудников одной компании). Пользователь, добавленный в сс получает доступ ко всему тикету со всеми сообщениями.

Что в этом такого плохого? То, что если “подделать” емейл от имени пользователя, который создал тикет, можно добавить в сс свой емейл и прочитать всю начинку тикета.

Под “подделкой” email я имею в виду email spoofing - довольно древний и простой способ отправить емейл от чужого имени и ящика (по крайней мере, так это выглядит в видимой части письма).
Нашел подробнейший гайд о том, как отправить такое письмо (и даже как найти уязвимую компанию-жертву).

Хорошо, допустим, мы смогли это сделать: нашли компанию, у которой
- нет DMARC-записи (не суть) - среди таких компаний до недавних пор была даже Википедия
- есть ZenDesk
Дальше мы можем угадать емейл support+id{id}@yourcompany.com, тк номера тикетов инкрементальные - если завести тикет с номером 546, а через секунду кто-то заведет новый - у него будет id 547-557. Это всего 10 емейлов для перебора (очень мало).

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

Но дальше становится жестче. Прям вау!

Очень многие компании используют SSO для аутентификации сотрудников во внутренние приложения - Slack, Jira, Notion и т д.
Популярный пример - login with Google / Apple. Если у тебя почта имя@yourcompany.com, то ты можешь залогиниться через гугл/эппл и получить доступ ко всем этим сервисам (нет, но часто да).

Как можно использовать этот факт в сумме с найденной уязвимостью?

Очень просто!
1) Создать Apple (Google у автора статьи не получился, не суть) аккаунт с адресом support@yourcompany.com и запросить код подтверждения на почту. В целом, можно даже не создавать, а “забыть пароль” в существующем аккаунте.
2) В это же время (за секунду до) создать тикет, отправив письмо на support@yourcompany.com, и получить номер тикета в ответном письме
3) Отправить spoofed письмо от имени appleid@id.apple.com на +- 10 почт, перебирая близкие номера к нашему тикету, и указывая в CC свой почтовый адрес.

Бинго! Мы получили доступ в тикет со своей почты. А в тикете… проверочный код от Apple.
Теперь можно войти в +- любое приложение, в котором доступен Apple SSO под учётной записью саппорта. Например, в Slack.

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

Интересные подробности об ответе Zendesk на обнаруженную уязвимость

Изначально, еще до взлома слаков, парень заявил о найденной уязвимости в bug-bounty программу ZenDesk.
Ему ответили через неделю - это не наша уязвимость, тк для атаки используется “подделка” емейла клиента. Это его уязвимость, так что нам похуй, мы не будем ничего делать.
Парень несколько раз писал в ответ, дескать, вы чего? Это прям дырка, знаете сколько компаний под угрозой?
А ZenDesk закрыл тикет и ничего ему не заплатил.

Тогда парень нашел дырку со слаком и написал в 100+ компаний, к слаку которых он смог получить доступ, с сообщением об уязвимости.
Компании в сумме заплатили парню $50к+ и начали писать ZenDesk: “вы чего, охренели совсем?” и “мы от вас уходим, это полный пиздец”.

И тогда Zendesk извинился перед парнем, заплатил ему и быстренько пофиксил баг. Ха-ха)
Нет.
Zendesk написал парню, чтобы тот перестал рассказывать компаниям об этой уязвимости, типа это приватная информация, затем признал баг, но не заплатил ему ни копейки, так как он “нарушил условия bug-bounty соглашения, написав этим компаниям напрямую”.

А потом они 2 месяца фиксили баг. И по сути, они его не пофиксили - просто закрыли несколько сценариев (например, с использованием Apple SSO), оставив все остальное как есть.
Я на 100% уверен что через 1-2 месяца можно ожидать апдейта по этой истории с использованием других SSO-провайдеров или еще каких-то сервисов.

Меня в этой истории поражает все: 15-ти летний парень, который смог найти такую дырку и срубить на ней денег, и, конечно, гигантская компания ZenDesk, которая просто забила на обнаруженную уязвимость, а потом еще и попросила нашедшего заткнуться и никому не рассказывать. А потом еще и ленивый недо-фикс выкатила. Обожаю.

Расширение в Chrome, которое может выполнять любые команды на вашем компе

https://ading.dev/blog/posts/chrome_sandbox_escape.html

Всем привет!
Вдогонку к Zendesk, увидел недавно опубликованный пост другого школьника про баг, найденный в браузерах chromium, - это основа Google Chrome, Yandex Browser и еще кучи других браузеров, самая популярная в мире.

Суть бага:
Автор использовал цепочку уязвимостей для “sandbox escape”: когда расширение в Chrome получает доступ к файловой системе и запуску C++ кода от имени браузера.
В нормальной ситуации js-код на сайтах и все расширения работают в “песочнице” и не могут выйти за пределы браузера или конкретной вкладки.

Как был реализован “побег”:
1) Расширение запускается на любой странице и просит пользователя включить инструменты разработчика (dev tools).

2) Через dev tools, используя баг, расширение редиректит пользователя на служебную страницу about:blank, которая уже является частью WebUI (набор страниц Chrome, которые умеют взаимодействовать с C++ кодом самого браузера. Например, chrome://settings и chrome://history.)

3) Затем, через другую уязвимость, происходит подмена на страницу chrome://policy, которая управляет верхнеуровневыми настройками браузера, например, политиками безопасности.

4) Расширение проверяет возможность включить тестовую конфигурацию политик безопасности и, если может, активирует её.

5) Среди разнообразных параметров и настроек, которые есть в policy, предусмотрены поля, которые отвечают за довольно нестандартное поведение: позволяют Chrome запустить другой браузер, если вы зашли на определённую страницу.
Так вот, как оказалось, если при включенной тестовой конфигурации вызвать функцию setLocalTestPolicies и передать в нее параметры для изменения поля AlternativeBrowserPath - можно заставить хром открыть другой браузер с любой страницы.

А что еще можно указать в пути AlternativeBrowserPath? в целом - любую программу, например /bin/bash - командную строку.
И передать туда любую команду, например, скачать и открыть вирус, или, как в “дружелюбном” примере в статье - открыть калькулятор :)

Вот тут можно посмотреть, как это выглядит (12-секундное видео без звука).

Возможно, звучит мудрено, - но в реальности, это +- короткая и понятная цепочка действий, каждое из которых эксплуатирует свою уязвимость. Одна из этих уязвимостей уже была обнаружена 4 года назад!
Google ее “починил”, но видимо плохо (очень похоже на историю с Zendesk, да?)

Правда Google, в отличие от Zendesk, оперативно взялся фиксить все эти уязвимости, и выплатил парню $20k. Круто же!

Немного морали:
- Даже гугл хром блин, самую популярную программу эвер, можно взломать без применения грубой силы.
- Если у компании нашли уязвимость, и она выпустила пресс-релиз в духе “Мы все починили!” - есть смысл пойти и подолбиться туда же / в соседние места. Вдруг они ее тяп-ляпно починили?
- Когда вы ставите хрен пойми какое расширение в хроме, задумайтесь - а оно вам реально надо?

Кто и как может узнать вашу геолокацию по маркетинговому айдишнику телефона?

https://krebsonsecurity.com/2024/10/the-global-surveillance-free-for-all-in-mobile-ad-data/

Да кто угодно. В том числе бесплатно (на фри триале).

Прочитал пиздецовую статью про использование MAID (Mobile Advertising ID) для отслеживания перемещений +- любого человека с точностью до координат. Статья была написана после поступления в суд дела против Babel Street - ноунейм-компании, которая занимается “AI Data Analytics”.
Среди продуктов этой компании - платформа LocateX, которая позволяет:
1) Посмотреть историю посещения любой выделенной на карте области и отфильтровать все видимые устройства, которые побывали там за указанный период.
2) Посмотреть историю перемещений конкретного MAID = конкретного человека с телефоном.

В статье приводится много примеров чудовищного злоупотребления подобными технологиями, в том числе:

1) Преследование полицейских и судей в США, некоторые из которых заканчивались убийством - почитайте, например, про Daniel’s Law.
2) Новостное агентство в Германии купило базу с историей перемещений нескольких миллионов (sic!) жителей, в том числе сотрудников полиции и министров.
3) Anti-Abortion groups в Штатах используют данные о женщинах, посещавших клиники, в которых делают аборты, чтобы показывать таргетированную шейминговую рекламу, а также следят за сотрудниками таких клиник.

Компания (Babel Street), при этом, заявляет, что работает только с государственными структурами или подрядчиками, но в реальности следователь смог убедить их предоставить доступ к платформе бесплатно на 2 недели, сказав, что он «в будущем будет использовать это для работы над государственным проектом».
Компании оказалось этого достаточно:

[investigator] was told by the Babel Street salesperson that ‘that’s good enough’ and that ‘they don’t actually check,’”

Ок, компания Бабель - плохая и занимается супер спорной деятельностью.
Но откуда они вообще берут эти данные, да еще и в таком количестве?
Напоминаю, что это ноунейм компания.
Разбираемся в следующем посте ⬇️

Давайте разбираться.
Babel Street и еще несколько компаний, - например, PenLink, - получают данные о геолокации пользователей и их MAID в основном от другой ноунейм-компании - Venntel.

А у них откуда все эти данные?
Сейчас расскажу на конкретном примере.
Основной «жертвой», с которой работали конкретные следователи по этому делу, была полицейская из Нью-Джерси, которой угрожали из-за видео на ютубе (без шуток).
Так вот, при изучении содержимого ее мобильного телефона, следователи нашли ровно 1 приложение, которое непонятно зачем собирало геолокационные данные: приложение американского ЦУМа, - Macy’s.

Macy’s, естественно, понятия не имеют о Babel Street и Venntel.
Но они (как и +- все остальные) пользуются услугами компаний, которые показывают персонализированную баннерную рекламу в своем приложении. Для того, чтобы реклама была персонализированной, они отправляют обезличенные данные о пользователях - их MAID, поведенческие факторы и геолокацию.
Среди таких рекламных компаний (на примере Macy’s): indexexchange.com, openx.com, adtech.com и другие.

Клиенты этих рекламных компаний участвуют в аукционе за показ баннера каждому посетителю сайта или приложения.
За долю секунды до того, как загружается страница и баннеры на ней, приложение (например, Macy’s) отправляет так называемые bid requests - предложения для разных рекламных компаний, которые те могут передать (автоматически) своим клиентам, которые делали ставки на какие-то конкретные параметры.
Например, вы открыли ресторан, и хотите таргетить всех людей, которые живут / работают рядом.
За такого человека вы готовы заплатить, а за живущего на другом конце города - нет.
А как узнать, в нужном месте человек или нет?
По геолокационным данным, которые передаются в bid request.

Но ведь получается, что у очень большого (по сути, неограниченного) набора хрен пойми кого есть доступ к этим данным, - как минимум, у перечисленных рекламных компаний, а также и у их клиентов, которые делают ставки.
Так и есть.

Более того, отдельная категория компаний продает “MAID data enrichment”, - позволяет для списка MAID получить имена, телефоны, почты, профили в соцсетях и даже адреса.
Эти компании, в свою очередь, покупают (или воруют) данные у упомянутых выше рекламщиков.
Они даже не стесняются говорить, что пользуются слитыми базами и прочими черными датасетами.

Всего за 10-50к$ в год можно получить доступ к датасету на миллиарды строк, содержащему подобные данные по 25% iphone и 80% Android в США и по всему миру.

Таким образом, полная цепочка выглядит примерно так:
1) Macy’s с разрешения пользователя собирает его MAID + локацию
2) Для показа персонализированной рекламы, они передают эти данные рекламщикам.
3) Либо сами рекламщики, либо кто-то другой в цепочке угоняет эти данные и складывает в свое хранилище. Некоторые еще и «обогащают» эти данные другими персональными данными, превращая безликий MAID в конкретного человека.
4) Компании типа Babel Street покупают доступ к этим данным, и предоставляют платформу, на которой кто угодно может изучать эти данные и использовать их для любых целей.

Мораль

Если честно, это одна из самых жестких историй, которые я читал за последнее время.
Это даже не Big Brother is watching you, - это буквально
Anyone is watching you for free.

И все в цепочке, конечно, «не виноваты», - Macy’s не продает ваши данные каким-то злодеям напрямую, непонятно, как так вообще получается…
На мой взгляд, вся эта система - зло.

Кстати, с этим можно бороться (но до какого-то предела):

1) Посмотрите инструкцию, что и где надо отключить на айфоне / андроиде

2) Когда новое приложение спрашивает, разрешить ли ему трекать вас для улучшения рекламы - никогда не разрешайте.

3) Не давайте доступ к геолокации никаким приложениям кроме карт.
Или давайте, но только «при использовании».
Пройдитесь по настройкам и посмотрите, какие приложения имеют доступ к вашему гео — вполне возможно, вы очень удивитесь.

Я сделал свой первый pet-проект: интерактивный образовательный сайт про то, как устроен Proof of Stake в Ethereum 2.0

Вот он: https://tim-sha256.github.io/ether-pos/ (смотреть лучше с компа)
Вот пост на Medium про то, зачем я это делал:
И еще вот на Telegraph (узнал, что в РФ не работает Medium …):

А вот краткий пересказ:

Чуть больше двух месяцев назад я решил разобраться в том, как устроена крипта с технической точки зрения.
Накидал вместе с GPT план обучения с задачами на каждый день, и пошел читать и тыкаться.
В задание 5го дня мне попался документ Ethrerum Mauve Paper, - 6-ти страничный документ, в котором описано как устроен Ethereum 2.0, в том числе, как устроен стейкинг на эфире.

Начал читать, и нихера не понял. 6 часов разбирал с GPT эти 6 страниц, чтобы понять, как же все это реально работает.
И понял! Более того, оказалось, что там нет никакой жесткой математики или страшных формул - все очень просто, лаконично и круто соединено в такую сложную систему, как Ethereum.

Это все и вдохновило меня на то, чтобы сделать интерактивный сайт, где можно пощупать и понять всю эту 6-ти страничную жуть.
Там +- полностью рассказаны и показаны все моменты из Mauve Paper, - и после чтения вы сможете понять, как все это работает под капотом.

Сделал я это все не написав ни одной строчки кода - с помощью Cursor и ChatGPT.
Курсор писал код, а ChatGPT вместе со мной продумывал интерфейс и писал ТЗ для Курсора.
Про то, как я все это делал и что понял я расскажу подробнее в следующем посте на Медиуме - естественно, и сюда напишу!
Я потратил сильно больше времени, чем собирался, но остался очень доволен результатом.

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

Поэтому, у меня к вам просьба

1. Если вам самим интересно разобраться, как устроен PoS и Ethereum в целом, - перейдите по ссылке и потыкайтесь!
Буду очень рад любой обратной связи - можно написать в комментарии под постом или мне в личку.

2. Если вам это вообще не интересно, но вы знаете кого-то, кому это может быть интересно - скиньте ему этот пост, пожалуйста.
Может понравится)

3. Если так вышло, что у вас есть свой канал / канал знакомых / зловещий дискорд-сервер с похожей тематикой - буду очень рад репосту!
Мне кажется, я сделал довольно крутую штуку.

Помните я рассказывал о том, как через уязвимость Zendesk исследователь получил доступ к слаку и другим внутренним сервисам кучи компаний?

Так вот, чуть больше недели назад взломали archive.org и угнали базу с 31 миллионом строк, содержащую данные учетных записей пользователей (почта + захешированный пароль):
ссылка на статью

Примечательно, что архив взломали несколько раз подряд за 1 неделю, и в последний раз - через ту же самую уязвимость Zendesk, но на этот раз с использованием GitLab SSO (вместо Apple SSO в оригинале).
Злоумышленники смогли угнать весь исходный код archive.org, и в том числе конфиг-файл из GitLab, в котором хранились секретные ключи от разных сервисов - например, от базы данных со всеми логинами и паролями.

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

Предсказал, получается)

Как ФБР придумали “безопасные” телефоны для хакеров и наркоторговцев, а потом читали переписки и ловили всех

https://youtu.be/uFyk5UOyNqI

Посмотрел невероятное выступление с DefCon 32. Автор исследования - человек с железными яйцами и легенда индустрии - один из создателей 404media.

Что за безопасные телефоны?
Anom — это телефон на базе Google Pixel 4a, с которым в комплекте идет IIntel NUC (маленький компьютер, как Mac Mini), с помощью которого устанавливается OS и приложения, вроде зашифрованного чата (чат как раз и называется Anom).

Там все продумано: например, при вводе пин-кода порядок цифр на клавиатуре меняется каждый раз, чтобы нельзя было “подсмотреть” паттерн. А еще есть decoy pin — другой код, после ввода которого открывается “нормальная” ОС с Netflix и Candy Crush.
Сам приватный чат “Anom” спрятан в калькуляторе.
Это не имеет никакого отношения к секьюрности, но наркоторговцам и прочим не особо айтишным ребятам такое очень заходит.

И за всем этим был спрятан MDM, который позволяет отслеживать локацию, IMEI и многие другие параметры каждого из этих телефонов.
У менеджеров в компании Anom был к этому доступ в виде красивого дашборда.

Но это абсолютно безобидно по сравнению с основным “сюрпризом”, который шел в комплекте с телефоном: с помощью незамысловатой системы Anom секретно превращал персональные P2P чаты в групповые чаты, где 3им скрытым участником был бот ФБР.
Данные проксировались через сервер в Литве, переупаковывались и отсылались прямо в ФБР.
А там сотрудники через не очень красивую админку могли прочитать все сообщения, пометить их тегами #к0каин, #убийств0 и т д, и направить дальше куда надо.

Еще из примеров “безопасных” фичей:
1) Можно заблюрить любую часть фото (лицо или номера) перед отправкой. ФБР, естественно, получали оригинальное, неотредактированное фото.
2) Изменение голоса в голосовых - думаю, уже понятно, в каком виде их получал ФБР.
3) В телефонах “нет GPS”, но ФБР собирал точные координаты с каждым отправленным сообщением

Основная часть “подозреваемых”, при этом, находились не в США и говорили не по-английски. То есть, ФБР буквально занимались (и продолжают) международной слежкой без какого-либо разрешения. Телефоны продавались в более чем 100 странах, даже в России.
В США, кстати, министерство юстиции не разрешило проводить эту операцию в полном масштабе. А вот в остальных странах - да пожалуйста.

Телефоны продавались через цепочку агентов, которые НЕ знали, что ФБР фактически владеет компанией и читает все переписки.
У агентов была своя админка для управления заказами, в которой в том числе была кнопка “очистить телефон”, - на случай, если клииент попал в беду. Естественно, это не имело никакого практического смысла, тк у ФБР уже были все переписки.

Интересно, что даже программисты, которые разрабатывали Anom, понятия не имели о том, что это софт для ФБР.
Их нанимали через Fivver и другие фриланс-биржи и платили 1000$ в месяц)

Все это происходило с 2019 года по 2021, когда ФБР вскрыли карты и арестовали безумное количество людей.
Автор выступления 3 года общался со всеми участниками: ФБР, наркоторговцами, агентами и прочими, собирал документы и написал про это книгу. Респект ему.

Мораль
Легко отмахнуться от этой истории и сказать: “ну и правильно, если наркоторговцы пользовались этими телефонами, - хорошо, что их подслушивали и по итогу поймали”.
Но в реальности такими телефонами пользуются многие другие люди, которые искали безопасности и приватности - например, журналисты, которые проводят расследования в разных странах. Или просто параноики, которые не хотят кормить гугл и эпл своими данными.
То, что позволяет себе делать ФБР, - выставивает схемы с целью слежки за людьми по всему миру, кроме США, - полнейший пиздец.
Но никто с этим ничего не сделает.
Сотрудники ФБР при разговорах с автором упомянули, что “ждут следующей операции”.

Как раз на днях мне попалась на глаза компания Nitrokey, которая специализируется на безопасных приватных девайсах с опенсорсной начинкой.
Как думаете, есть ли там внутри что-то интересное?)

https://telegra.ph/How-I-created-an-Ethereum-Proof-of-Stake-demo-entirely-with-AI-11-08

Всем привет!

Написал пост про то, как я сделал ether-pos, про который писал выше. На всякий продублировал его в Telegraph.
Вот он же на Medium.

Я сделал весь проект с помощью ChatGPT и Cursor - AI-версии VS Code, которая очень много что умеет.
Про Курсор я узнал изначально из канала Виталика - @thingsiread.
Потом мы еще созванивались, и Виталик рассказывал, как он работает с курсором. Спасибо ему огромное за помощь и вдохновение!

По сути, я не написал ни одной строчки кода сам.
Раньше я работал только с GPT и Cursor по отдельности, и ни разу не делал серьезных проектов (не то что бы этот очень серьезный, но в нем 5к+ строк кода, для меня это оч много).

Так вот, для этого проекта я придумал новый подход (ну может кто-то еще так делает, хз), про который и рассказал в посте выше - я организовал командную работу GPT в роли project manager и Cursor в роли разработчика, и мне очень зашло!

Классическая проблема при работе с GPT - быстро накапливающийся хаос и неразбериха, разбросанные по чату (или нескольким чатам).
Особенно, когда в голове нету суперстройной картинки готового проекта, нет четкого ТЗ, а есть только идеи и желание сделать что-то.
Желание после 4-10 часов ебли с GPT обычно улетучивается, и проект так и остается наброском на локале, который никто никогда не увидит.

А когда работешь с Cursor без ясности в голове и четких инструкций - Cursor плодит ошибки, докидывает много домыслов в проект, и результат получается не очень. Что логично - какое ТЗ, такой и результат.

И вот впервые я смог построить более-менее структурированный процесс, в котором каждый занят своим делом:
- Я выступал в роли фаундера / продакта, то есть описывал UX, который хочу создать для пользователя, и выдавал какой-то общий вижн. Ну и критиковал всех остальных, естественно.
- GPT 4o выступил в роли проджект-менеджера: структурировал мои мысли и идеи, и превращал их в подробные ТЗшки для Cursor.
- Cursor, соответственно, был разработчиком, - читал инструкции от GPT и писал код по ним в режиме Composer: автоматически создавал и редактировал файлы в проекте. Я только нажимал на кнопку “Accept All Changes” и изредка подглядывал, что он там пишет.

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

Про +- все мои идеи, придумки и ошибки я подробно написал в посте.
Я уже начал пилить следующий проект - в нем я заранее учел все ошибки из прошлого, и пока идет гораздо быстрее и чище.
Еще я подумываю добавить 1-2 роли и раздать их другим инстансам GPT и курсора, - например, завести тестировщика, который прямо по горячим следам пишет тесты по коду курсора-разработчика.
Думаю, через 2-5 проектов я создам более основательный Knowledge Base, куда сложу все, что пробовал, и что из этого получилось.

Если вы уже пишете код, с AI или без, или хотите попробовать - почитайте пост!
Я надеюсь, что каждый найдет в нем что-то новое и полезное, и сможет пилить свои проекты немного быстрее и эффективнее.

Мой первый взлом

Недавно познакомился с фаундером одного мобильного приложения.
Из соображений безопасности и этики, не буду называть ни его, ни приложение, ни какие-либо конкретные данные.

Так вот, оказалось, что он читает мой канал.
Почему-то он решил, что если я пишу про уязвимости, — я и сам умею их искать)
И предложил мне поискать их в его приложении.
А я решил попробовать это сделать - вдруг моих базовых знаний о том, как это работает + кучи разобранных примеров хватит, чтобы что-то найти?
Что важно знать о приложении: в нем есть чат с AI.

Спустя 5 часов я нашел критическую уязвимость в приложении, которая позволяет:
- получить персональные данные всех пользователей
- отправлять любые сообщения не только в чат с AI, но и другим пользователями

Как я это сделал?
1. Для начала, я поставил Charles Proxy - приложение, которое позволяет создать локальный прокси-сервер и пропускать трафик с любого устройства в локальной сети сквозь него.
Помимо этого, у Charles Proxy есть собственный SSL-сертификат - если установить его на Iphone (или любое другое устройство, которое мы хотим подслушать), - можно расшифровать подслушанный HTTPS трафик.
Хотя оказалось, что это было не нужно)

2. Включил Charles Proxy, настроил проксирование трафика с iphone, и пошел бродить по приложению.
Оказалось, что часть запросов на backend-сервер приложения отправляется просто по HTTP, - то есть, трафик не зашифрован, и видно настоящий ip-адрес сервера. Уже это — очень плохой знак. Не делайте так)

3. Я скопировал несколько сырых запросов и запустил Burp Suite - помимо кучи других фичей, он позволяет воспроизводить запросы с разными переменными.

4. Дальше я открыл GPT и попросил его подсказать мне, что можно сделать. Сам я бы ковырялся в 5 раз дольше.
GPT посоветовал мне попробовать видоизменить запросы, внося изменения в разные поля, - например, попробовать передавать XSS-текст в теле запроса.
Все получилось!
Я обнаружил серьезную проблему: некоторые поля вообще никак не валидируются и не “карантинятся” - к примеру, я могу отправить ссылку на скачивание .exe файла любого приложения - и она без проблем отправится и запишется в соответствующее поле.
Но все это было +- безвредно: за несколько часов я смог вывести уведомления, ссылки и сырой XSS в своем инстансе приложения (в моем профиле), но на этом все. SQL и JSON инъекции, которые я также пробовал сделать, не дали никаких результатов.

5. Тогда я решил еще раз посмотреть на все запросы, которые отправляло приложение, и повнимательнее изучить ответы.
Один эндпоинт показался мне интересным:
POST /api/v1/chat/ainame/ - эндпоинт, на который отправляется сообщение пользователя в AI-чат в приложении.

В ответе на запрос я с удивлением обнаружил поля user_from и user_to с такими данными (оставил только самые интересные):

"user_from":{
"id”:1234, // видимо, это мой id пользователя
"name":"Tim",
"email”:”тут был мой емейл, который я использовал при регистрации!”,
"registered_at”:”и моя дата регистрации”,}

"user_to":{"id":0},

Вот и первая существенная уязвимость: мои персональные данные (почта) передаются в нешифрованном HTTP-сообщении, которое можно подслушать, - например, включив Wireshark или tcpdump, находясь в моей WiFi сети.

Продолжение в следующем посте →

Продолжение: Critical IDOR Vulnerability

Но я заметил куда более интересную вещь: получается, что при отправке запроса на /api/v1/chat/ainame/, ainame — это пользователь с id=0 (что видно из ответа выше в поле user_to).
А что если попробовать отправить запрос на /api/v1/chat/1233/, — вдруг я смогу отправить сообщение другому пользователю, который зарегался прямо передо мной?
Ага.
И более того, в ответ на запрос я получил такие данные:

{"status":"success",
"data":
{"message_id”:”какой-то айдишник сообщения”,

"user_from": {
"id”:1234,
"name":"Tim",
"email”:”тот же емейл, который я использовал при регистрации!",
"registered_at”:”дата моей регистрации”},

"user_to":
{"id”:1233,
"name”:”Имя другого человека!”,
"email”:”емейл другого человека !!!”,
"registered_at”:”и его дата регистрации”}

В моменте, когда я получил этот ответ, я почувствовал такой прилив адреналина, что дрожал минут 10. Без прикола.
Потом я додрожал, быстро зарегал еще один аккаунт, узнал его id из запроса и через тот же эндпоинт отправил ему сообщение от имени своего первого аккаунта.
Что я увидел: мне в приложение с выполненным входом в новый аккаунт пришло сообщение, которое я отправил - в том же чате, который использовался для общения с AI.

А потом я запустил небольшой скрипт, который подставлял разные user_id в URL запроса. Просто, от 1 до моего id.
Спустя несколько часов, я получил почты, имена, и даты регистрации всех пользователей приложения, зарегистрированных до меня.
Даже никакие лимиты не пробил)

Но и это еще не все!
Если вернуться к пункту 4, текстовые поля в запросах, в том числе и текст сообщения, никак не валидируются.
Получается, что я могу отправить всем пользователям сообщение с чем угодно - например, гиперссылкой на фишинговый сайт, или любой другой злой штукой.
Я, конечно, не стал этого делать. Я все-таки не злой хакер, а так, поковыряться зашел в научных целях.

Завернул всю эту находку в отчет и отправил фаундеру и его команде.
Он, конечно, удивился и не обрадовался)

Мораль
1. Я реально смог что-то взломать!
Это скорее говорит о том, что есть много малоизвестных приложений, в которых все очень плохо с безопасностью, чем о моих замечательных навыках, но все равно приятно!

2. Это предположение, но все же: думаю, что в мобильных приложениях чаще можно встретить неустойчивые к атакам эндпоинты, HTTP-запросы и все такое, так как “сложнее” подслушать, что приложение куда отправляет, чем тупо открыть вкладку Network в консоли в браузере. Как можно заметить, не особо сложнее)

3. Все эти стартапы с их AI-чатами… ладно)

Напоследок: если у вас тоже есть сайт / приложение, и вы хотите, чтобы я в нем поковырялся - напишите в личку.
Буду рад и никому не расскажу деталей, даже если что-то найду.

Торговая комиссия США подала в суд на 5 AI-стартапов за вранье и/или скам

https://www.ftc.gov/news-events/news/press-releases/2024/09/ftc-announces-crackdown-deceptive-ai-claims-schemes

В этом году было много наездов на AI и крипто стартапы со стороны разных госорганов США типа SEC и FTC. Например вот.
С одной стороны, как бы хорошее дело делают - надо регулировать и то, и другое, тк херни и скама с наклейками web3 и AI все больше и больше.
С другой стороны, я не верю, что в этом нет коммерческого и политического интереса: конечно же они хотят лутать налоги с крипты и следить за пользователями AI-чатов + использовать все наработки в военно-шпионажно-политических целях.

Крупняки на AI рынке уже давно с ними сотрудничают: уже мельком писал про OpenAI, а недавно увидел новость про Anthropic - они с недавних пор запартнерились с Palantir и AWS, чтобы предоставить американским развед-агенствам и оборонным ведомствам доступ к своим моделям.

Но эта история показалась мне относительно «хорошей»: FTC наехал на 5 компаний, которые заявляли, что могут делать что-то уникальное с помощью AI.

DoNotPay обязали выплатить $193k :)

Согласно жалобе FTC, DoNotPay обещала (и в целом продолжает) пользователям возможность «подать в суд без адвоката» и «генерировать настоящие юридические документы за секунду», и вообще, что они «заменят многомиллиардную юридическую индустрию с помощью AI».
Оказалось, что они просто сделали насадку на ChatGPT, не тестировали и не проверяли то, что выдает «их» модель, и не нанимали ни одного юриста для консультаций или помощи.
Можно еще почитать забавный тред про них на форуме YCombinator.

Скам-схемы «запусти успешный бизнес на маркетплейсах с помощью AI»

Компании Ascend Ecom, Ecommerce Empire Builders, FBA Machine предлагали запустить бизнес на маркетплейсах с помощью AI и начать зарабатывать 5-6-7 figures a month.
Удивительно, но никто из клиентов не заработал на своем бизнесе и большинство из них потеряли кучу денег и влезли в огромные долги.

Про Ascend Ecom, например, на реддите пишут про десятки и сотни тысяч долларов промотанных денег.
Аналогичная история с Ecommerce Empire Builders - почти такой же бизнес, тоже “Skip the guesswork and start a million-dollar business today” by harnessing the “power of artificial intelligence”.
Все они, естественно, обещали возвраты тем клиентам, у которых не получится, но ничего не вернули.

Генератор фейковых отзывов (но не все так однозначно)

Компания Rytr продает свой AI “writing assistant”, который умеет генерить +- неограниченное количество отзывов на любой продукт по очень небольшому количеству входной информации.
Во многих случаях отзывы получались бредовыми и содержали кучу ошибок - например, упоминали характеристики товаров, которых на самом деле не было. FTC решила, что этот сервис напрямую способствует распространению фейковых отзывов на маркетплейсах → вредит потенциальным покупателям.

Примечательно, что во всех предыдущих кейсах 5 из 5 членов комиссии были согласны с выдвинутым обвинением, а в кейсе Rytr - только 3 из 5.
Ради интереса почитал заявление одного члена комиссии, который голосовал против: звучит, на самом деле, вполне адекватно.
Лор стейтмента: у FTC нет доказательств того, что нагенеренные отзывы действительно использовались для постинга на маркетплейсах (или еще где-то), и что просто генерить драфты отзывов - не преступление.

If there were in fact a likelihood of substantial injury, presumably the complaint could allege at least one example where particular content Rytr generated was untruthful and was actually posted to reach consumers. Yet it does not. Unfairness requires proof—not speculation—of harm

Уверен, что таких компаний гораздо больше, чем 5. Просто на них пока что недостаточно пожаловалось.

Как 1 команда (почти) автоматически нашла 2000 уязвимостей в API кучи компаний из Fortune 1000?

Пресс-релиз: https://escape.tech/blog/fortune-1000-at-risk-30k-exposed-apis-100k-vulnerabilities/
Полный отчет со всеми деталями

Супер крутая и немного страшная история.
Компания Escape, занимающаяся кибербезопасностью, проанализировала все домены, субдомены и открытые порты всех компаний из Fortune 1000 (1000 самых больших американских компаний по капитализации), не считая FAANG .

И нашла:
- 28,500+ уязвимых API
- 3,945 внутренних API для разработчиков, открытых миру
- 1,816 секретных ключей среди ответов этих API
- 2,038 особо критичных уязвимостей (highly critical vulnerabilities)

Как?
1. С помощью своей платформы (крутая реклама, да?) просканировали все домены и указатели на другие домены (или субдомены) для каждой из 1000 компаний. Нашли 158к субдоменов!

2. С помощью ML-алгоритма распознали и классифицировали апишки среди всех найденных доменов.
Их классификатор позволяет определить тип API (REST, GraphQL и проч.), доступные эндпоинты и паттерны ответов.

3. Автоматически проанализировали публично доступную информацию: открытые репозитории в гитхабе, доки, и т д.
Такой анализ называется OSINT — Open Source Intelligence.

4. Очень крутая идея!
Всего для 4547 апишек из 30+ тысяч была доступна публичная документация.
Наличие документации очень важно для упрощения процесса дальнейшего изучения и абьюза эндпоинтов.
Поэтому Escape сгенерили еще 30к доков к апишкам с помощью LLMок - заставили условный ChatGPT читать код и прочие доступные ошметки информации, и генерить документацию в заданном формате.

5. В итоге получилось 30,784 апишки с подробной документацией.
Используя свой DAST алгоритм для анализа и абьюза апишек, они автоматически:
- статически проанализировали доступную информацию о каждом эндпоинте
- протестили каждый эндпоинт, отправляя рандомные или подпорченные запросы
- проверили все ответы на наличие кодов ошибок, подсказок, а иногда и секретных ключей
- отсортировали все найденные уявзимости по уровню критичности

Всего нашлось больше 100к уязвимостей, 2000 из которых были классифицированы как особо критичные, в 316/1000 компаний!
В среднем 42 уязвимости на 1 компанию!

Мораль (из текста отчета + немного моей):

Очень часто (на моем опыте - всегда) все участники продуктовых процессов пытаются оптимизировать Time to Market:
“Го быстро запилим 2 ручки и сразу в прод?”
“Чего, QA 3 дня просит? Давай кого-то пошустрее выберем, это слишком долго”.
Ну и всякое такое. Наверняка, если вы работали разрабом / продактом / … , вы встречали такое много раз.

В результате погони за супербыстрыми релизами + добавлением новых API-эндпоинтов на каждый пук (как же умный холодильник может поставляться без API?), компании постоянно создают новые дырки в своей инфраструктуре.
Я думаю, что это касается почти всех, — Fortune 1000 это богатые компании, у которых есть деньги на безопасников, Red Team команды и всякое такое, а у малого и среднего бизнеса их нет (и не будет).

А что делать?
Компания Escape, понятное дело, рекомендует покупать доступ к их платформе и сканировать все свои апишки)

Мне кажется, что можно обойтись и опенсорсными инструментами, особенно если у вас не 1000 субдоменов.
Но, на мой взгляд, главное — пугать такими историями всех участников процесса, от разрабов до C-level и собственников.
Потому что каждая заэксплойченная настоящими злыми хакерами, а не исследователям, дырка может повлечь за собой очень большие издержки — и репутационные, и финансовые, и юридические.

При этом, как видно из исследования Escape, поиск уязвимостей превращается в полностью автоматизированный процесс.
Поэтому не важно, в Fortune 1000 ваша компания или нет — эксплоит существующих уязвимостей это вопрос времени, а не вероятности - уже писал об этом выше.

BBOT - опенсорсный инструмент для скана субдоменов, и не только

https://github.com/blacklanternsecurity/bbot

В посте выше я писал про расследование Escape и их платформу, которая позволяет проводить глубинный анализ апишек на предмет безопасности.
Там же я упоминал, что на мой взгляд, в +- небольшой компании можно обойтись опенсорсными инструментами - и вот попробовал воспользоваться одним сам.

https://www.youtube.com/watch?v=bCNnloBaw_U

Я узнал про BBOT из выступления его создателя на ютубе, и оно показалось мне супер интересным.
BBOT это относительно уникальный сканер интернета, который работает рекурсивно: кормишь на вход 1 домен (или несколько), дальше он выполняет несколько разных сканов (DNS, OpenSSL и другие), и находит связанные домены и субдомены.
Потом он повторяет все то же самое для всех найденных доменов, а дальше… ну вы поняли, у попа была собака 🔄

Чем он мне так понравился?

Во-первых, я люблю все рекурсивное. Как-то это контринтуитивно и гораздо более интересно, чем даже сложные цепочки из сотни действий.
Во-вторых, автор добавил очень крутую визуализацию с помощью VivaGraphJS.
В сумме с рекурсией за процессом скана просто оч приятно и интересно наблюдать (чего не скажешь про 200+ строк логов в консоли).

BBOT умеет оч много всего (половину я, честно говоря, очень плохо понимаю, либо совсем не понимаю), но основная его задача - найти все субдомены, связанные домены, порты и айпишники для заданного таргета.
И по заявлениям автора (сам не проверял, но почему-то верю), справляется он с этой задачей сильно лучше всех других инструментов - находит в среднем на 20-50% больше субдоменов.

А зачем он нужен?

Обычно при подготовке атаки (не важно, черной или белой) начинают со сбора максимального кол-ва информации о таргете, и ищут самые слабые места - будущие точки входа. Собственно, BBOT и другие аналогичные инструменты позволяют собрать +- всю базовую информацию о доменах и сервисах, которые использует компания.
Например, у вас есть домен test.com - простой лендинг на тильде с 1 формой контактной связи.
Взламывать там, скорее всего, абсолютно нечего.

Но вот вы запустили скан, и обнаружили admin.test.com, или api.test.com, или какой-нибудь pgadmin.test.com. И сразу становится интереснее.
Очевидно, что это домены внутренних сервисов компании, а значит есть шанс, что там можно сделать что-то, что могут делать только сотрудники, и узнать что-то, что знают только сотрудники.

Возвращаясь к предыдущему посту, часто разработчики думают, что так как внутренние сервисы “никому не видно” - у вас же на сайте нет ссылки на админку, значит, и защищать ее как-то особенно не нужно. Так, например, было и в случае с моим взломом.

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

Я протестил BBOT на нескольких сайтах, структуру которых я знаю - компаний, в которых работал, и Track Pump, конечно.
На видео выше - как раз скан track-pump.com.
Картинка получается не самая красивая (мало у нас сервисов), для красоты можно посмотреть на структуру tesla.com, к примеру.
Но при этом все субдомены нашлись. Более-менее понятно, чем мы пользуемся и куда копать.
Это, правда, не значит, что там что-то легко ломается - надеюсь, что базовая защита на уровне сервисов и CloudFlare Zero Trust все-таки делают свое дело.

Вместо морали

Люблю опенсорсные штуки.
И вообще люблю все потыкать: когда я читаю про интересный сервис, особенно бесплатный, я стараюсь всегда попробовать попользоваться им самостоятельно, и сдаюсь только спустя 15-30 минут безуспешных попыток.

В случае с BBOT это было оч быстро (минут 7 на установку и первый запуск).
Правда, после первого запуска, я заметил ошибку в логах, которая показалась мне довольно простой - использование .lower() с нестрочкой.
Еще через 10 минут нашел файл, в котором это фиксить, тяп-ляп, — и все пофиксил.
Впервые в жизни решил репортнуть это в Github Issues (за 5 минут не разобрался, как делать нормальный pull request).
Почувствовал, что сделал что-то полезное)

Что не так с Cloudflare?

https://robindev.substack.com/p/cloudflare-took-down-our-website

Наткнулся на летний пост про чудеса работы с CloudFlare, который меня заинтересовал.
Если кто не знает, чем занимается CloudFlare - посмотрите, если гипер-коротко: DNS, CDN, “безопасность” - защита от DDoS, HTTPS-everywhere и всякое такое. Для понимания масштабов:

Our reports are updated daily. Cloudflare is used by 80.8% of all the websites whose reverse proxy service we know. This is 19.2% of all websites.

Предисловие
1. Я люблю CloudFlare.
Впервые я узнал про него от знакомого разраба-фаундера (а он, мне кажется, от другого такого же).
Мне надо было навесить HTTPS на все сервисы в Track Pump, и мы с разработчиком на пару мучались с certbot и всем таким.
И тут я узнаю, что совершенно бесплатно можно настроить SSH-туннели на Cloudflare буквально за 5 минут, завернуть все свои сервисы в красивые домены с HTTPS, да еще и получить защиту от ддос и кучу плюшек впридачу.
Бесплатно, тк Track Pump маленький - трафика мало, доменов мало, юзер 1 (я), и т д.
Для стартапа - топ!
С тех пор я его тоже советую всем знакомым.

2. CloudFlare реально помогает с безопасностью против entry-level хакеров.
За последний месяц я несколько раз поигрался в Bug Bounty - зарегался на HackerOne и попробовал поискать баги в +- ноунейм конторах с маленькими призами и маленьким числом контрибьюшнов.
Навыки у меня базовые. Че-то где-то подсмотрел, тут гпт спросил, тут в статье читал, — но вдруг что-то найду.
Так вот, у последних двух “испытуемых” стоял CloudFlare - скорее всего, с дефолтными настройками, за 0-20-200$ в месяц, подключенный за 1 день.

И он довольно серьезно усложнил мне жизнь: гораздо тяжелее делать инъекции, брутфорсить эндпоинты и всякое такое, постоянно возвращается ответ с баном от CloudFlare + тот самый HTTPS everywhere - сервисов дохренища, явно есть какие-то богом забытые, но тем не менее, все закрыто, просто так не посмотришь.

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

Вопросы
1. Почему тогда не у всех (кроме бигтеха) Cloudflare, если это так круто и бесплатно-дешево?
2. Что же плохого в Cloudflare? Все-таки, это уже тоже американский бигтех, а значит, какое-то зло он точно должен делать.

Ответ на оба эти вопроса я прочитал в статье, а потом еще в куче тредов, форумов и блогов.
И стал гораздо лучше понимать, в чем же все-таки подвох Cloudflare.

Лор статьи
Вводные: имеем онлайн-казик с MAU 4М, который активно юзает CloudFlare Business Plan за 250$/мес.

Сразу хочу заметить:
1. Да, это казик, там свои сложности + этические вопросы (их много, это не про любой бизнес, и т д)
2. Да, возможно, стоимость услуг, которые фактические оказывает CloudFlare такому большому сайту, превышает 250$

Так вот, Cloudflare внезапно начал угрожать казику: мол, вы создаете для нас проблемы с безопасностью, немедленно выйдите с нами на звонок.
Автор выходит с ними на звонок, и… оказывается на звонке с сейлзами.
Сейлзы буквально ставят ультиматум: либо вы переходите на Enterprise план (который автору не нужен по фичам) за 10к$/мес, с оплатой за год вперед - это 120к$, — либо через 48 часов мы отключим все, что вы у нас держите: 13 доменов, SSO для сотрудников, почтовый сервер (в том числе, с почтой саппорта), и прочее.
Примечательно, что при продаже энтерпрайз плана используют аргументы про лимиты, а в прайсинге нигде этих лимитов нет.

Казину это не понравилось, они попытались договориться, начали общаться с конкурентами CloudFlare, выиграли еще неделю времени , и…
Cloudflare без предупреждения заблочили все в один день, удалили нахуй все логи, емейлы и конфигурации - представляете, сколько всего там восстанавливать?
У казика, естественно, все упало на дни, — представляете уровень финансовых потерь?

Продолжение в следующем посте →