Comments 34
Эта уязвимость обсуждается уже пару месяцев, причем без особой реакции Instagram. Лишнее напоминание о том, что публичный Wi-Fi — небезопасная штука.
так понимаю, что они добавили функцию signed_body как раз для защиты от атаки по Вашей ссылке.
Правда это ничего особо не поменяло…
Правда это ничего особо не поменяло…
Нет, эта функция была и раньше. (Честно говоря, сходу не отвечу, почему в описании по моей ссылке о ней ни слова). Если интересно, попробуйте погуглить signed_body, на эту тему было много болтовни.
А инстаграму уже пора заняться безопасностью, для этого можно нанять несколько человек хоть из команды фейсбука. Ситуация для североамериканского стартапа довольно обычная: до тех пор, пока они распространены в США и Западной Европе, проект может жить со значительным числом дыр и не подвергаться серьезным атакам. Но выход на рынки развивающихся стран сразу же привлечет внимание русских и китайских хакеров, которые проведут хм… подробнейший аудит безопасности :)
А инстаграму уже пора заняться безопасностью, для этого можно нанять несколько человек хоть из команды фейсбука. Ситуация для североамериканского стартапа довольно обычная: до тех пор, пока они распространены в США и Западной Европе, проект может жить со значительным числом дыр и не подвергаться серьезным атакам. Но выход на рынки развивающихся стран сразу же привлечет внимание русских и китайских хакеров, которые проведут хм… подробнейший аудит безопасности :)
Я немного недопонял. Эти signed_body и media_id действуют вечно или меняются через пол-часа/при смене IP/действуют только в текущей сессии?
media_id — это идентификатор фотки + идентификатор пользователя. Постоянные величины. Пример: 370914688453536573_179269057
signed_body — это кастомная хэш функция на базе SHA256. Соответственно хэш от константы есть тоже константа.
Наверное, в это и есть главный косяк. Если бы аргументом хэш функции был хотя бы еще и session_id — все было бы совсем не так красиво…
signed_body — это кастомная хэш функция на базе SHA256. Соответственно хэш от константы есть тоже константа.
Наверное, в это и есть главный косяк. Если бы аргументом хэш функции был хотя бы еще и session_id — все было бы совсем не так красиво…
Спасибо за объяснение. Так всё оказывается хуже чем я сначала подумал…
UFO just landed and posted this here
Не могу понять…
А смысл от signed_body — если пользовательский траффик проходит незашифрованным через Ваш роутер?
Там же все видно…
Или надо было signed_body генерировать на основе постоянных данных + случайной строки, которую нужно хранить только на сервере и привязывать к session_id? Даже если так сделать — то все равно вы можете повторить любой запрос, который перехватит ваш снифер
А смысл от signed_body — если пользовательский траффик проходит незашифрованным через Ваш роутер?
Там же все видно…
Или надо было signed_body генерировать на основе постоянных данных + случайной строки, которую нужно хранить только на сервере и привязывать к session_id? Даже если так сделать — то все равно вы можете повторить любой запрос, который перехватит ваш снифер
signed_body нужен чтобы сохранить протокол проприетарным (запретить альтернативные клиенты) и ставить палки в колеса спаммерам, добавляя криптографию практически в каждую команду серверу.
В моих примерах я не повторяю пакеты. Я их собираю из своих прегенерированных signed_body и юзеровских печенек. Если бы signed_body был привязан к сессии, то я не мог бы его подсовывать в чужие пакеты.
В моих примерах я не повторяю пакеты. Я их собираю из своих прегенерированных signed_body и юзеровских печенек. Если бы signed_body был привязан к сессии, то я не мог бы его подсовывать в чужие пакеты.
Я понимаю, что не в теме… но хочу все же понять:
У вас же в куки которые вы перехватываете — session_id хранится. Смысл привязывать к сессии signed_body, если можно перехватить session_id через куки?
У вас же в куки которые вы перехватываете — session_id хранится. Смысл привязывать к сессии signed_body, если можно перехватить session_id через куки?
можно (нужно) кормить хэшфункции какую-нибудь юзерозависимую переменную. Тогда мы не сможем заранее прегенерировать нужный хэш на своем девайсе.
я пока еще исхожу из условия, что хэшфункция не разгадана (хотя в комментах ниже есть её алгоритм, но его еще нужно проверять). Поэтому даже зная аргументы хэшфункции мы пока что не можем вычислить signed_body самостоятельно.
я пока еще исхожу из условия, что хэшфункция не разгадана (хотя в комментах ниже есть её алгоритм, но его еще нужно проверять). Поэтому даже зная аргументы хэшфункции мы пока что не можем вычислить signed_body самостоятельно.
Мне кажется мы о разном говорим?
Я имею ввиду, что хеш функция — генерируется на сервере и ею подписываются запросы от пользователя.
Для каждого session_id — своя хеш функция
Просто я исхожу из условия, что траффик не шифруется и все заголовки, и в том числе куки — перехвачены.
Как быть тогда?
Я имею ввиду, что хеш функция — генерируется на сервере и ею подписываются запросы от пользователя.
Для каждого session_id — своя хеш функция
Просто я исхожу из условия, что траффик не шифруется и все заголовки, и в том числе куки — перехвачены.
Как быть тогда?
signed_body генерируется на стороне клиента. Но в пакете передается не только хэш, но и исходный «открытый» текст — параметры типа media_id, user_id. Сервер генерирует на основании передаваемых параметров свой хэш и если он совпадает с клиентским — пакет идет дальше.
при условии, что алгоритм signed_body остается секретным, функция обеспечивает электронную подпись каждого сообщения и защищает протокол от различных атак.
косяк конкретно этой реализации — малое количество входных параметров signed_body. Если бы туда добавляли идентификатор пользователя, время, команду и т.д. — то протокол был бы достаточно стойким (не от прослушивания, но от модификации и подделки запросов от имени пользователя).
при условии, что алгоритм signed_body остается секретным, функция обеспечивает электронную подпись каждого сообщения и защищает протокол от различных атак.
косяк конкретно этой реализации — малое количество входных параметров signed_body. Если бы туда добавляли идентификатор пользователя, время, команду и т.д. — то протокол был бы достаточно стойким (не от прослушивания, но от модификации и подделки запросов от имени пользователя).
int getRandomNumber()
{
return 4; // chosen by fair dice roll
// guaranteed to be random
}
{
return 4; // chosen by fair dice roll
// guaranteed to be random
}
остается только найти доступный роутер «трафика Президента», и от его имени писать комментарии к «оттяжным фоткам»
Ненужно в квадрате, как мило.
что за адская картинка, жму в опере копиравать адрес картинки опера виснет. Жму в ие9 и он виснет O_o
Любой сервис без https подвержен подобным «атакам», тема стара, как мирИнтернет.
С чего бы? Amazon S3 доступен по обычному http, но просто так из чужих букетов вы ничего не скачаете. Потому что руки прямые, в отличие от «миллиардеров».
Из чужих кого?
Действительно bucket по-русски звучить немного неоднозначно :)
и произносится оно «бакит», если уж на то пошло :)
Я, честно говоря, не в курсе, как реализована у S3 защита от перехвата трафика на стороне пользователя (например от replay-атак, рассмотренных в данном топике), расскажи вкратце, если несложно.
Я, честно говоря, не в курсе, как реализована у S3 защита от перехвата трафика на стороне пользователя (например от replay-атак, рассмотренных в данном топике), расскажи вкратце, если несложно.
Ну там все заголовки подписываются ключом пользователя. Так что если перехватить запрос, то можно только повторить тоже самое действие, которое сделал пользователь. Например, если мы перехватили GET, то мы по сути можем скачать только тот же самый файл, а мы его и так можем перехватить, так как данные всё равно открыты. Другое действие (например удалить) вы сделать не сможем. Ну и таймстамп тоже в подписи, так что она протухнет через 15 минут после генерации.
Хэш генерируется довольно просто тут:
1) Ключ берется методом
2) Алгоритм аутентификации сообщений — HMAC с SHA-256, причем надо заметить интересно они ищут алгоритм по названию… :)
3) Входными данными для MAC является входной параметр
4) Далее хэш преобразуется в BigInteger, хотя зря на мой взгляд: String.format принимает и byte[] в том числе
5) На выход идет String с hex записью полученного хэша.
1) Ключ берется методом
NativeBridge.getInstagramString("a4d1b77bbb1a4a5ca695ad72c84b77e5"); в кодировке UTF-8. Видимо какой-нибудь native функцией судя из названия, хотя мало ли2) Алгоритм аутентификации сообщений — HMAC с SHA-256, причем надо заметить интересно они ищут алгоритм по названию… :)
3) Входными данными для MAC является входной параметр
String paramString из generateSignature4) Далее хэш преобразуется в BigInteger, хотя зря на мой взгляд: String.format принимает и byte[] в том числе
5) На выход идет String с hex записью полученного хэша.
Я им писал около 9 месяцев назад об этом. Ответа не последовало. Ок. Залайкал около 20-30 млн фотографий, собрал более 10000 фолловеров и хейтеров. Забанили.
Sign up to leave a comment.
Как инстаграммить по-черному или следи за печеньками