Спасибо, действительно, не подумали. Сейчас займёмся )
P.S. А может есть где-нибудь общая база знаний последствий атаки? Чтобы понять кто мог потенциально пострадать?
Потенциально, в кусках памяти этих веб-серверов, которые можно было читать при помощи уязвимости, могли встречаться некритичные куки пользователей и приватные ключи наших сертификатов.
Мы решили не рисковать и отозвать их.
Мне кажется, что из известных сервисов больше всех пострадал Yahoo. Их медлительность при патчинге стали активно ретвитить, провоцируя людей заряжать скрипты на login.yahoo.com
Про остальных — не знаю. Но даже на текущий момент, люди не особо задумываются о том что уязвимость не в HTTPS, а в OpenSSL. А значит все Jabber порты, SMTPS, SMTP/TLS и т.п. уязвимы наравне с вебом.
В скором времени мы обязательно расскажем об этом подробнее )
Но если просто, то на данный момент, для каждого домена третьего уровня выставляется отдельная Secure и HTTPOnly авторизационная кука, вместо одной общей. При этом сохраняется единая авторизация, и снижаются риски эксплуатации XSS и угона сессии на каком-нибудь богом забытом проекте компании, куда ещё не дошли руки безопасников.
Примерно по такой-же схеме работает авторизация на Google.com
Векторов атак не так много:
1) Сама джумла. Просто обновляйтесь.
2) Её плагины. Тут вам как раз таки должен помочь какой-нибудь спец. joomla сканер плагинов на наличие багов в безопасности. Ну или просто ручками отсматривайте апдейты плагинов, и не ставьте сомнительные.
3) Ваш хостинг. В случае шаред хостинга, например. вполне реально походить по контенту сайтов «соседей». Поэтому лучше VPS взять.
4) Ваш личный комп, откуда можно ваш пароль угнать малварью. Тут понятно думаю что делать.
Баунти сейчас как раз прорабатывается(а-ля тестируется), по факту репорта :)
Плюс, отрабатываются схемы оплаты, сроков и прочего. Потому что поминая Яндекс, я предполагаю наличие проблем в этом месте :) Как и проблемы, связанные с тысячами репортов об отсутствии SSL от индусов, или проблем связанных с кастомными репортами(которые вообще нереально прочитать без боли в глазах).
Вобщем, уже немного осталось, и я думаю у нас будет нормальное продуманное баунти с манжонгом и гейшами. Правда, распространяться баунти будет только на обойденные аудитами и тестированием безопасности проекты компании. Игры, к сожалению, к ним пока не относятся :(
В случае с распространённым движком, будет достаточно если эксперт просто посоветует вам обновляться почаще, либо заюзать какой-нибудь софт для аудита стандартных движков. Например как WPScan какой-нибудь для Wordpress.
Это естественно, при условии что вы сами дальше исследовать и починить не сможете.
Что же до аудита, например, вашего софта, то чинить всё таки будете вы а не он :)
Его дело лишь отрепортить баги, причем как можно более комплексно и полно, а ваше дело — вникнуть в баги, зафиксить их, и самое главное понять, есть ли ещё аналогичные в других местах проекта.
Определённо сменилась точка зрения.
Мало того, сейчас за эту точку зрения отвечаем я и моя команда :) И у нас есть непреодолимое желание и умения именно в этом месте сделать всё хорошо.
Готов ответить за Mail.Ru.
Во-первых, я прошу прощения за отсутствие быстрого ответа вам. Мы обязательно разберёмся с тем что произошло, и по какой причине вам не ответили оперативно.
Во-вторых, спасибо :)
В-третьих, ваш тикет конечно же дошёл до нужных людей(продуктовая безопасность) в этот понедельник. Пруф: i.imgur.com/YEI7sN1.png После чего баг был быстро отрепорчен разработчикам, с указанием отписаться автору бага(чего не произошло :().
Я прошу вас связаться со мной, по адресу: d.sidorov@corp.mail.ru для обсуждения reward.
Стереолитография — это круто и точно, но к сожалению только для прототипирования :( Потому что потом эту хрупкую детальку фиг где используешь.
Аналогично с принтерами, которые гипсовые фигурки делают.
Отличается тем, что в случае с плагином ты можешь заставить пользователя сохранить свой ключик где-нибудь в надёжном месте, а в случае с JS и localstorage уже нет :)
То что плагины ФФ пишутся на JS(XUL) это понятно, но свои внутренние данные они хранят на диске в надёжном пользовательском профиле, а не в куках или некоем ненадёжном localstorage.
Ты представь себе ситуацию, когда у тебя есть сотни зашифрованых писем, а твой приватный ключик для их расшифровки лежит в localstorage, который очищается сотней левых тулз или плагинов для браузера. Потерял ключик — потерял все письма.
Там другие проблемы возникают.
1) Где хранить приватный ключик юзера для расшифровки письма
2) Где хранить и как получать публичные ключи тех, кто собсно юзеру пишет, для проверки подписи напримерили для шифровки сообщений для них.
т.е. при помощи JS это делать вообще мимо, нужно делать в каком-нибудь клиентском приложении. Можно в Я.Браузере или аддоном каким-нибудь, но тогда возникают проблемы вида: А я зашел в свою почту с другого компьютера, и письма прочитать не могу, т.к. приватных ключиков нету.
P.S. А может есть где-нибудь общая база знаний последствий атаки? Чтобы понять кто мог потенциально пострадать?
Мы решили не рисковать и отозвать их.
Про остальных — не знаю. Но даже на текущий момент, люди не особо задумываются о том что уязвимость не в HTTPS, а в OpenSSL. А значит все Jabber порты, SMTPS, SMTP/TLS и т.п. уязвимы наравне с вебом.
Но если просто, то на данный момент, для каждого домена третьего уровня выставляется отдельная Secure и HTTPOnly авторизационная кука, вместо одной общей. При этом сохраняется единая авторизация, и снижаются риски эксплуатации XSS и угона сессии на каком-нибудь богом забытом проекте компании, куда ещё не дошли руки безопасников.
Примерно по такой-же схеме работает авторизация на Google.com
И я склонен верить тому, что впредь такого не повторится :)
Векторов атак не так много:
1) Сама джумла. Просто обновляйтесь.
2) Её плагины. Тут вам как раз таки должен помочь какой-нибудь спец. joomla сканер плагинов на наличие багов в безопасности. Ну или просто ручками отсматривайте апдейты плагинов, и не ставьте сомнительные.
3) Ваш хостинг. В случае шаред хостинга, например. вполне реально походить по контенту сайтов «соседей». Поэтому лучше VPS взять.
4) Ваш личный комп, откуда можно ваш пароль угнать малварью. Тут понятно думаю что делать.
Может ребята в комментах что ещё подскажут )
Плюс, отрабатываются схемы оплаты, сроков и прочего. Потому что поминая Яндекс, я предполагаю наличие проблем в этом месте :) Как и проблемы, связанные с тысячами репортов об отсутствии SSL от индусов, или проблем связанных с кастомными репортами(которые вообще нереально прочитать без боли в глазах).
Вобщем, уже немного осталось, и я думаю у нас будет нормальное продуманное баунти с манжонгом и гейшами. Правда, распространяться баунти будет только на обойденные аудитами и тестированием безопасности проекты компании. Игры, к сожалению, к ним пока не относятся :(
Это естественно, при условии что вы сами дальше исследовать и починить не сможете.
Что же до аудита, например, вашего софта, то чинить всё таки будете вы а не он :)
Его дело лишь отрепортить баги, причем как можно более комплексно и полно, а ваше дело — вникнуть в баги, зафиксить их, и самое главное понять, есть ли ещё аналогичные в других местах проекта.
Мало того, сейчас за эту точку зрения отвечаем я и моя команда :) И у нас есть непреодолимое желание и умения именно в этом месте сделать всё хорошо.
Готов ответить за Mail.Ru.
Во-первых, я прошу прощения за отсутствие быстрого ответа вам. Мы обязательно разберёмся с тем что произошло, и по какой причине вам не ответили оперативно.
Во-вторых, спасибо :)
В-третьих, ваш тикет конечно же дошёл до нужных людей(продуктовая безопасность) в этот понедельник. Пруф: i.imgur.com/YEI7sN1.png После чего баг был быстро отрепорчен разработчикам, с указанием отписаться автору бага(чего не произошло :().
Я прошу вас связаться со мной, по адресу: d.sidorov@corp.mail.ru для обсуждения reward.
Аналогично с принтерами, которые гипсовые фигурки делают.
Ты представь себе ситуацию, когда у тебя есть сотни зашифрованых писем, а твой приватный ключик для их расшифровки лежит в localstorage, который очищается сотней левых тулз или плагинов для браузера. Потерял ключик — потерял все письма.
1) Где хранить приватный ключик юзера для расшифровки письма
2) Где хранить и как получать публичные ключи тех, кто собсно юзеру пишет, для проверки подписи напримерили для шифровки сообщений для них.
т.е. при помощи JS это делать вообще мимо, нужно делать в каком-нибудь клиентском приложении. Можно в Я.Браузере или аддоном каким-нибудь, но тогда возникают проблемы вида: А я зашел в свою почту с другого компьютера, и письма прочитать не могу, т.к. приватных ключиков нету.