Pull to refresh
-1
0
Send message

В целом, хотел сказать спасибо за качественное раскрытие возможных векторов атак.

Вы серьезно? В статье же полная ахинея. Нет, даже так - ДИЧАЙШАЯ АХИНЕЯ. Такое ощущение, что это ChatGPT писал статью с его нейронными галлюцинациями. Выглядит правдоподобно - но смысла никакого. Взяли заголовки с этой страницы и написали какую-то отсебятину. Начиная с того что назвали HTTP/2 downgrading атакой, а это не атака, а обычное поведение фронтенд/прокси серверов в данном контексте. Я уже молчу о том что HTTP/2 - вообще бинарный протокол с абсолютно другими псевдо-заголовками и запросы/ответы приведенные в статье видимо из параллельной вселенной, к реальности отношения не имеющие (по секрету скажу, что даже для текстового HTTP/1.1 они не очень валидные). Что вы там авторы курите вообще? Заканчивайте с этим, вы полностью этой статьей дискредитируете себя как ИБ-компанию.

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

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

А я не рекомендую, т.к. они «заботятся» о вашей безопасности только на словах. Например, их веб-сканер почты передает ваши логин/пароль от вашей уютной почты через опасные интернеты в незашифрованном виде. Можете убедиться сами, введя свои данные сюда http://tests.dashlane.com/scan
Я им об этом уже говорил и они сказали не считают это чем-то плохим, такие дела…
Пляски с SSL-сертификатом чтоли? Если у вас есть контроль над DNS зоной, то просто привязать домен — это указать его в настройках как Custom domain и добавить CNAME запись на YOUR-GITHUB-USERNAME.github.io

Или у вас проблема в том, чтобы перенести репозиторий на отдельный аккаунт?
Ну если в данный момент у вас домен привязан верно, то все хорошо, никто не сможет перехватить контроль над вашим доменом. Просто если вы случайно отключите привязку хотя бы на несколько минут, то есть риск, что скрипты злобных хакеров успеют его захватить. Но даже в этом случае вы либо просто удаляете CNAME запись, либо пишите в поддержку гитхаба. Проблема в том, что вы можете не заметить этого сразу, как автор публикации. Таковы современные реалии…
Во-первых, вы уже упустили возможность что-то объяснить где-то комментариев 5 назад и я не прошу вас делать это сейчас, т.к. мне самому пришлось за вас все объяснять, я лишь взываю к вашему разуму, чтобы вы критически подошли к этому вопросу.
Во-вторых, есть в этом мире вещи, которые не измеряются деньгами. Если бы все исследователи проводили свои исследования только за деньги, то мир был бы в гораздо большей опасности. Если уж просите оплаты за свои услуги, то зачем мелочитесь, начинать надо было, как мининум, со $100 или даже с $1000, или вы и в этом себя не уважаете?
Также справедливости ради напомню, что не я разработал схему и написал эту статью, и по идее защищать ее адекватность тоже должен не я. Мое дело лишь предоставить аргументированную критику. А вы ведете себя как барин, которому негоже перед холопами что-то объяснять. Ну, успехов вам в этом деле, у меня есть дела поинтереснее, чем биться головой об пол перед таким барином.

Ну смотря с какой стороны посмотреть. И гитхаб и другие провайдеры не считают это своей уязвимостью, они считают это уязвимостью тех, кто коряво настраивает свои поддомены в их сервисах, даже если это было сделано неявно, как в этой статье. И даже майкрософт тут не причем, это было задолго до него :)
Могу подлить лишь масла в огонь, сказав что та самая тулза tko-subs умеет автоматически захватывать домены (в т.ч. на github pages), если запустить ее с ключом -takeover. То есть, скорее всего, атакующие даже не видят какие именно поддомены захватывают, ведь за них все делает скрипт.

Проблема известна довольно давно (как минимум 4 года) labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more

И гитхаб не единственный, кто этим страдает. По сути вся индустрия сейчас движется в таком же направлении, к сожалению. Есть даже тулза tko-subs, которая парсингом ответа сервера проверяет на возможность его (домена) захвата. Можете посмотреть примерный масштаб трагедии (там далеко не все уязвимые сервисы, их гораздо больше): github.com/anshumanbh/tko-subs/blob/master/providers-data.csv
Я понял суть алгоритма еще после первого ее прочтения. И я вам конкретно пытаюсь указать на слабые места в схеме, а вы просто игнорируете все доводы, аргументируя лишь словами «нет желания» и ими подобными. Складывается впечатление, что вы написали статью на хабр лишь для галочки, но вроде блог не корпоративный, так что очень странно.
Если вам все же действительно нужен фидбэк и интернесны возможные негативные последствия применения вашей схемы на практике, то внимательно перечитайте все мои комментарии, готов ответить на вопросы и разжевать каждое предложение, т.к. мне не безразлична судьба тех сервисов, которые применив вашу схему могут быть уязвимы. Все мои вопросы были, в первую очередь, наводящими для вас, чтобы вы переосмыслили надежность и безопасность предлагаемого решения (безотносительно удобства, которое вы так отстаиваете, хотя не спорю, что оно тоже важно).

И да, если все же не захотите перечитывать — еще раз кратко: концепцию токенов, привязанных к устройствам, с которых был успешный вход (которые вы называете доверенными), используют уже очень и очень давно, но используют правильно, не ослабляя безопасность. И к вашей схеме с генерацией валидных/невалидных токенов это не имеет никакого отношения, т.к. нет никакой связи между валидностью токена и его доверенностью (выражаясь терминами из вашей статьи). Вместо того, чтобы сразу показать пользователю зашедшего с нового устройства капчу после N неверных попыток входа, вы просто предоставляете злоумышленнику уже N*M попыток (где M может увеличиваться до 1000 в минуту, если не превышать лимит). На «дружелюбность» доверенных токенов это не влияет от слова никак, поэтому выкидываем их из схемы (используя их отдельно), а затем выкидываем саму схему, т.к. она ослабляет безопасность.
Еще раз внимательно перечитайте мой предыдущий комментарий, там я за вас ответил на вопросы, на которые не смогли ответить вы. Жаль, что вы не умеете аргументированно обосновывать свою точку зрения, особенно в деталях, ведь я надеялся, что хабр для этого и нужен, чтобы иметь возможность сообща приходить к наиболее полному и верному решению. Тот комментарий был для того, чтобы предостеречь доверчивых людей от использования вашей схемы без 2FA, т.к. вы не смогли подтвердить или опровергнуть мои опасения о безопасности такой схемы.

P.S.
Кстати, концепцию т.н. «доверенных» токенов, можно использовать раздельно от вашей основной схемы валидных/невалидных devid, как это делается множеством сервисов. Напр. при первом успешном входе с недоверенного токена отправлять ссылку на имэйл, и при подтверждении считать его доверенным. Также это часто делают для тех юзеров, у кого отключена 2FA через СМС/OTP-токены. Но по факту это и есть 2FA, просто вторым фактором выступает не СМС и OTP, а email. И опять же не надо городить никакой другой «дружественной» мути, снижая безопасность, ведь этого уже достаточно.
Но прошу вас потратить еще немного на прохождение ваших кейсов по схеме.

Я изучил схему еще вчера, но ответов на мои вопросы там не нашел. Я думал просто, что вы случайно или намеренно не упомянули некоторых деталей. Жаль что вы не захотели отвечать на эти вопросы, придется мне отвечать за вас.
Таким образом, вопрос про необходимость доверенного токена отвечен вами как — «нафиг он не нужен», потому что если выбросить элемент алгоритма «Is devid untrusted?» — ничего не изменится в работе алгоритма. А блок «Mark devid as trusted» можно заменить на «Number of attempts = 0».

Капча будет включена в период атаки, и автрматом выключится при нормализации ситуации. А атака захлебнется из-за таких включений

Послать 1000 запросов в минуту — это захлебнуться? Чтобы атакующему выполнить дос-атаку на процесс логина ему не нужно проходить капчу. Пользователю же чтобы войти в систему это будет нужно. Ну и кто захлебнется из них? Ведь как я понимаю по вашим пространным ответам вы и не пытаетесь реально бороться с брутом, наоборот вы смягчаете защиту от брута ради «друзей».
А теперь ход конём: атакующий заранее постепенно генерит мильёны devid, а затем спокойненько себе брутит в свое удовольствие, попутно блокируя выдачу новых devid для всех остальных :) Не нашел где в вашей схеме есть противодействие такому поведению. В итоге: и защиту смягчили и «друзей» не спасли от доса. За двумя зайцами погонишься… Информационная безопасность это всегда баланс: нельзя просто так взять и повысить удобство, не пожертвовав безопасностью.

Ну и посылать в faq пользователя… ну это моветон. А если ему 78 лет?

Ок, погорячился, считайте это за шутку или моветон, как вам угодно. По существу: жирными буквами надо писать чтобы включали 2FA, если не хотите страдать от брута.

Вывод: либо нормальная защита от брута (банально — после 3-х попыток ставим капчу), либо 2FA. И слоган — хотите стать нашими друзьями — включайте 2FA! Вот и все, не нужно ничего городить лишнего. Я думаю любой, даже самый тупой пользователь при первой же невозможности залогиниться с нового устройства без капчи, если ему написать что при включении 2FA такого не будет — с радостью включит его, или тупо забьет, т.к. 1 раз ввести капчу для него не принципиально.

Здесь ситуация походит на криптографию — постоянно возникают люди, думающие, что они знают что-то лучше многолетних изысканий великих криптографов, посвятивших этим самым изысканиям всю свою жизнь. Хотя я в целом рад стремлению автора сделать что-то лучшее, но все же надо более внимательно подходить к таким вопросам, тем более что вашими советами могут неправильно воспользоваться другие люди. Нельзя скопировать то, что было сделано для 2FA и применить это без этой самой 2FA. Если вы во всем этом надеетесь еще и на Security Through Obscurity, то когда-нибудь вы (или тот, кто вам доверился) за это поплатитесь нехилым сливом, и может быть вспомните мои слова. Но все же советую одуматься сейчас, чем кусать локти потом.
В статье не сказано преимущества доверенного токена перед просто валидным. Если его нет, то он бессмысленен, если оно все же есть (напр. больше попыток на вход и т.д.), то тогда еще вопрос — доверенный devid как-то привязывается к пользователю или нет? Если не привязывается — что атакующему мешает сделать его доверенным через вход в его собственный аккаунт и вся защита сходит на нет. Если привязывается, то это порождает множество других проблем — усложнение системы, сложность входа с одного устройства разных пользователей и т.д.

Вообще, это скорее не защита от брута, а защита от доса через брут, т.к. в плане усложнения перебора здесь ничего нет (любые фронтенд фичи легко обходятся естественно), а по факту только увеличение количества потенциальных слабых мест, как с примером выше. Обычно защиты от брута выглядят гораздо строже.
Например, хитрость с превышением лимита и т.н. «режимом атаки» легко обходится тестовыми запросами для вычисления лимита. Сам лимит в 1000 в минуту не адекватен (понимаю, что для примера, но пример не очень):
  1. Если лимит привязан к юзеру — ничто не мешает атакующему брутить параллельно миллионы юзеров и тут даже 10 попыток в минуту может хватить чтобы сбрутить нереальную кучу юзеров/паролей.
  2. Если лимит привязан к IP — ботнеты в помощь
  3. Если лимит ни к чему не привязан — получаем сразу DoS всей системы выдачи devid и больше никто с нового девайса не зайдет. Включение капчи и любые другие ужесточения все равно убьют на корню всю задумку «дружественной» защиты

Таким образом, защита от брута получается от слова «никакая». К сожалению, ничего лучшего 2FA в этом плане пока не придумали, как вы и сами заметили. Тогда весь смысл вашей задумки все равно теряется. А приведенный пример mail.ru как раз реализован в 2FA, где ему и место.

Также ваша задумка «дружественной» защиты подразумевает, что пользователь не узнает, что на его аккаунт идет атака. Это тоже неверное решение. Если его аккаунт брутят, значит он скорее всего куда-то утек (либо взломаны его другие аккаунты на этом имейле, либо еще какая-то уязвимость используется), а в этом случае надо большими красными буквами писать об этом пользователю, даже если это не влияет на его текущую сессию. Надеюсь вы понимаете почему.
Если все же целью является только антидос логина, то предложу еще один вариант обхода. Я так понимаю, что при логауте пользователя сессия разрушается, но devid сохраняется как доверенный. Есть еще один тип атак — CSRF. Большинство сервисов имеют login/logout CSRF и не считают это за уязвимость (почем зря). Однако через логаут и последующие N некорректных логинов… ну вы поняли :) Вот такой вот CSRF DoS, причем массовый (не направленный на конкретного юзера).

А все это ради чего — неведения пользователя, что его атакуют? Итак пользователи слабо осведомлены о самых базовых аспектах ИБ, так мы им в этом еще поможем. Снижение нагрузки на саппорт? Отправляйте в FAQ, где жирными буквами будет написано, что если вы не можете войти в систему и это не вы превысили количество попыток — то ваш аккаунт пытаются взломать, ну и кучу советов по этому поводу, включая 2FA.
Мнимая безопасность часто хуже ее отсутствия… Хотя вопрос с антидосом логина считаю открытым, возможно и есть более подходящее решение.
Один из немногих годных комментов. Также добавлю что уязвимость можно (а точнее нужно) было преподнести полностью опустив факт слива через имэйл (а дополнить этой инфой только в случае адекватной реакции). Например, просто сообщить о ссылке на файл паролей, доступной без авторизации. Если заранее были опасения в неадекватной реакции на репорт, то можно было пойти дальше и скормить ссылку краулерам поисковиков, а после индексации отписать что файл в свободном доступе, да еще и в индексе Гугла и еще много кого. Это уже железно должна была быть валидная уязвимость.

Товарищам из Киевстара и всем кто не снимает лапшу с ушей про Out-of-Scope.
Вот вам показательный пример собственной бб-программы hackerone, а точнее репорта, который по иронии судьбы был им отправлен разработчиком из Киева (кстати на хабре есть рид-онли аккаунт с его ником). Вкратце: сотрудник Hackerone оставил персональные токены доступа в логах на Гитхабе. Итог — выплата $2000 за возможность потенциального коммита вредоносного кода в некоторые репозитории, который мог бы быть пропущен и в конечном счете импортирован куда не следует. Как вы думаете есть ли такое в Scope программы? Можете не гадать, а убедиться здесь, что явно такие вещи не указаны, т.к. любому грамотному человеку будет ясно, что уязвимости оцениваются по импакту, пусть даже от уязвимости которая косвенно влияет на основные активы компании, ведь в современном запутанном информационном пространстве дырочка в отдаленном сайте/сервисе может обернуться дырищей в самой компании.
В большинстве случаев так и есть, но тут речь не об этом.
Во-первых, я не зря написал потенциально порождают, т.к. обычно фиксация сессии через URL с последующим захватом аккаунта происходит именно в аутентификационном запросе (иначе атакующий просто залогинит жертву под своим аккаунтом). Таким образом, сгенерив новый ID после аутентификации мы уже на корню предотвратим такой класс уязвимостей.
Во-вторых, фиксация сессии возможна и через другие сценарии. Самый простой пример — через XSS, когда сессионные куки имеют флаг httpOnly и напрямую их не угнать, тут и придет на помощь session fixation. Опять же, OWASP в помощь.
Как выше написал автор, именно в этом месте ахинеи то как раз и нет. Подавляющее большинство адекватных сайтов работают по той же схеме, т.е. при любом запросе генерируют сессию (это не обязательно означает что пользователь был авторизован для каких либо действий, даже существует сессия анонимного пользователя). Тем более как вы себе представляете аутентификационный запрос с CSRF токеном, если этот токен не будет привязан к ID сессии?
Другой вопрос, что все нормальные сайты после этой самой аутентификации должны генерировать новый ID сессии. А вот это делают далеко не все, и сами выстреливают себе в ногу, т.к. потенциально порождают сессионные уязвимости типа Session fixation.
Вообще OWASP довольно хорошо об этом говорит здесь:
A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

Справедливо заметить, что Омер писал об этом еще в феврале https://omergil.blogspot.co.uk/2017/02/web-cache-deception-attack.html и все уважающие себя сервисы закрыли эту дыру уже давно. Даже не секлабе была новость http://www.securitylab.ru/news/485441.php. И действительно CDN тут совсем не причем, это возможно при любом другом кэшировании.
В оригинальной статье от CloudFlare написано что в т.ч. были утечки ключей внутренних соединений между CF серверами, но не ключи пользователей.
One obvious piece of information that had leaked was a private key used to secure connections between Cloudflare machines.
Я думаю это скорее реклама AdBlock. Или еще один повод вырезать Яндекс.Директ…
Сори, веткой ошибся…
Да и ни один современный браузер не даст джаваскрипту изменять код в iframe стороннего сайта (напр. вписать номер карты получателя), даже при отсутствии заголовка X-Frame-Options, только ввод самого пользователя. SOP однако…
Вы невнимательно читали статью.
Причем здесь используется не окно iframe.
Лет 10 назад, когда еще только-только стали появляться турникеты в метро и станциях электричек, в которых был сканер штрих-кода чека для прохода, мне приснился сон, видимо навеянный мыслями о несовершенстве такой технологии. Суть была в том, что для прохода на какое-то мероприятие (то ли на конференцию, то ли на представление в театре) посетителю нужно было пройти через специальную рамку, которая полностью сканировала все тело человека и если находила валидный чек об оплате прохода (хоть в руках, хоть в кармане), то пропускала. Мы еще с друзьями смеялись над тем что такое маловероятно и как-то футуристично, но при этом довольно удобно. Теперь же я все больше понимаю, что это вполне может быть реализовано, те же NFC-метки можно считывать за десятки сантиметров. А может такое где то уже есть (вопрос в первую очередь автору публикации)?

Information

Rating
Does not participate
Registered
Activity