Cloudbleed: Как да се справим

Tavis Ormandy (Tavis Ormandy) от Google Zero Project разкри нужна уязвимост в услугата за инфраструктура на Cloudflare Internet. По същество заявките в мрежата към сайтове, подкрепени с Cloudflare, получиха отговори, включващи произволна информация от други сайтове, поддържани от Cloudflare! Тази информация потенциално може да включва поверителна информация (лични съобщения в сайтове за запознанства, имейли), информация за самоличността на потребителя (Лична идентифицираща информация (PII)) и потенциално в контекста на здравеопазването, Защитена здравна информация (PHI) или идентификационни данни на потребители, приложения или устройства (пароли, ключове за API, маркери за удостоверяване и т.н.)

И Project Zero, и Cloudflare действаха своевременно. Грешката бе съобщена за 2017–02–17 и смекчаване настъпи в рамките на един час. Публично известие беше дадено на 2017–02–23.

Продължителността (2016–2012–22 до 2017–02–20) и потенциалната широчина на изложената информация е огромна - Cloudflare има над 2 милиона уебсайтове в своята мрежа и данните от всеки от тях са потенциално изложени. Cloudflare заяви, че действителното въздействие е сравнително малко, така че смятам, че в действителност бяха разпространени само ограничени количества информация. По същество широк спектър от данни е потенциално изложен на риск, но рискът за всеки отделен данни е много малък. Независимо, ако не може да се покаже категорично, че вашите данни НЕ са били компрометирани, би било разумно да се разгледа възможността да бъдат компрометирани.

Докато услугата на Cloudflare бързо се закърпва, за да елиминира тази грешка, данните изтичаха постоянно преди тази точка - в продължение на месеци. Някои от тези данни бяха кеширани публично в търсачки като Google и се премахват. Други данни може да съществуват в други кеши и услуги в Интернет и очевидно е невъзможно да се координира изтриването във всички тези места. Винаги има потенциал някой злонамерен да открие тази уязвимост независимо и преди Тавис и може би активно я използва, но няма доказателства в подкрепа на тази теория. За съжаление също е трудно да се обори окончателно.

Най-чувствителната информация, която изтече, е информация за автентификация и идентификационни данни. Компромисът с тези данни може да има трайни и продължаващи последици, докато идентификационните данни бъдат отменени и заменени.

От индивидуална гледна точка това е ясно - най-ефективното смекчаване е да промените паролите си. Въпреки че това по всяка вероятност не е необходимо (е малко вероятно вашите пароли да са били изложени в този инцидент), това ще подобри абсолютно сигурността ви както от този потенциален компромис, така и от много други, далеч по-вероятни проблеми със сигурността. Cloudflare стои зад много от най-големите потребителски уеб услуги (Uber, Fitbit, OKCupid, ...), така че вместо да се опитвате да идентифицирате кои услуги са в Cloudflare, най-предпазливо е да използвате това като възможност да завъртите ВСИЧКИ пароли на всичките си сайтове , Това ще подобри вашата сигурност, въпреки че основната полза е от заплахи, несвързани с този инцидент.

(Най-добрата практика е да използвате дълъг произволен низ за всяка парола, уникален за всеки сайт и да управлявате тази колекция с помощта на „мениджър на пароли“, като например 1Password, LastPass или вградените мениджъри на пароли в съвременните уеб браузъри. Потребители трябва също да излезете и да влезете в мобилните си приложения след тази актуализация. Докато сте в него, ако е възможно да използвате 2FA или 2SV със сайтове, които считате за важни (използвайки нещо като TOTP / Google Authenticator или U2F), това е смислено. надграждане на сигурността също.)

За операторите на сайтове, които използват Cloudflare: макар това да е разрушително, трябва сериозно да помислите за въздействието върху потребителите си. Използвайте този инцидент като възможност за упражняване на вашия процес за справяне с инциденти - обсъдете специфичното въздействие върху вашето приложение и какъв отговор има най-голям смисъл (вероятно е различен за всеки сайт или приложение.) Трябва да балансирате с неизвестен, но малък риск срещу други разходи. Внимавайте да не ги „уплашите“, но може да е разумно да предприемете действия. Поне бих подготвил „отговор на акции“ за подкрепа за този инцидент и в контекста на предприятие или b2b проактивно общувам с клиентите за степента на инцидента и неговия ефект върху вашето приложение и техните данни. За по-голямата част от сайтовете в Cloudflare, това само е вероятно достатъчно.

Налагането на промяна на паролата на потребителя има много реални разходи - потребителите могат да загубят доверие във вашата услуга и това е неудобство. Не изглежда, че голям брой идентификационни данни са били компрометирани, така че за потребителска услуга с ограничен риск за компрометирани акаунти може да не си струва усилията да масово обезценят паролите и да наложат промяна. За идентификационни данни на администратора или за сайтове, обработващи високо чувствителна информация чрез Cloudflare, липсата на количествено измерима максимална експозиция вероятно означава, че си струва да наложите актуализация на паролата. Ако имате някакви други причини да искате да изпратите актуализация на паролата на всички ваши потребители, това, разбира се, би било допълнителен фактор в решението.

Сайтовете трябва да обезсилят идентификационните данни за удостоверяване на мобилни приложения и други машини за машинна комуникация (IoT устройства и др.), Принуждавайки потребителите да регистрират отново приложения и устройства, ако са използвали Cloudflare като доставчик на инфраструктура. Ако не искате да принуждавате промяна на пароли, междинна жизнеспособна стъпка може да бъде обезсилване на маркери за удостоверяване, принуждавайки потребителите да влизат отново със съществуващите си пароли; тъй като маркерите за автентификация се предават по-често между браузър и сървър, е много по-вероятно да съществуват в изтичане на произволна памет от сървъра, отколкото необработени пароли, и принуждаването на ново влизане е минимално въздействие за потребителите и може да не изисква конкретни съобщения или известие.

Освен това всички сайтове, които не са в Cloudflare, но с много потребители, които използват хоствани в Cloudflare сайтове (по същество всички големи или потребителски сайтове в Интернет), трябва да обмислят да принудят промени в паролата на потребителите, в случай че техните потребители са използвали едни и същи пароли на всеки сайт , Това вероятно не е оправдано за по-голямата част от сайтовете (всеки с нужда от сигурност е толкова висок, че това би имало смисъл да използва инфраструктура за удостоверяване, далеч по-силна от паролите на потребителите, в противен случай почти сигурно е, че потребителите ще използват отново пароли с компрометиран сайт ), но това може да е възможност. Лично аз бих го използвал като възможност за надграждане на цялостната ми инфраструктура за автентификация в такъв случай - разполагане на 2FA (в идеалния случай U2F или по-добре, или избран от потребителя TOTP / HOTP, а не SMS), мониторинг на активността на акаунта и т.н. - вместо да бързам промяна като невалидни пароли. Самостоятелните пароли в Интернет вече не са най-добрата практика за удостоверяване на потребителите.

Ако вашето приложение или уебсайт са на Cloudflare и са обект на индустриални или национални регулации, това може да е доклад за инцидент. (примери са грижи за здравето / медицинската поверителност при HIPAA). Вашите екипи за сигурност и съответствие трябва да оценят. Очевидно е, че пълното спазване на приложимите разпоредби е съществена част от сигурността.

Субективно смятам, че това е сериозен проблем със сигурността и трябва да бъде оценен от всяка голяма услуга, използваща Cloudflare. Вероятно не е „край на света“ по тежест, тъй като освен ако не е имало съгласувана злонамерена експлоатация, уязвимите данни вероятно са сравнително произволно разпределени в интернет, но наличието на данни в кешовете за търсене може да направи възможно мащабната експлоатация. Тъй като смекчаването за крайните потребители като цяло е добър съвет (използвайте мениджър на пароли, използвайте уникални случайни пароли за сайтове, завъртете на всеки компромис), това е „без мозък“ за повечето крайни потребители, които са със сигурност. За операторите на сайтове решението наистина се свежда до вашата конкретна потребителска база и тяхното ниво на сложност на сигурността и толерантност към риска. Дълбоко оценявам както текущата работа на Project Zero (особено Tavis), така и бързата реакция на Cloudflare по този въпрос.