Почти никога не ни е нужен експлойт
Тестваме клиентски системи от 2014 г. и често установяваме сериозно въздействие без сложен експлойт. Причините са достъпни данни за вход, прекомерни права, останали след миграция, и връзки на доверие, чиито последствия не са били преразгледани. Разглеждаме тези повтарящи се модели и начините за ограничаването им.
Пропастта между това как хората си представят пробива и как той се случва
Когато говорим за компрометиране, често си представяме сложен експлойт: дефект в парсър, заобикаляне на защитни механизми и изпълнение на код върху обновена система. Тази представа насочва вниманието към корекциите, скенерите и бюлетините. Практическите проверки обаче трябва да обхващат и обикновени административни пропуски, които могат да доведат до същия резултат.
Това, което виждаме при ангажименти, не прилича на нищо подобно. Обичайната форма е данни за достъп на място, където не би трябвало да ги има, използвани срещу услуга, която ги приема без оплакване, от принципал, чиито права са по-широки, отколкото някой е предполагал, вътре в мрежа, където една система гарантира за друга по исторически причини. Никой не пише shellcode. Заявките са добре оформени, удостоверени и неразличими от тези, които приложението обслужва по цял ден.
Нека бъдем точни, защото заглавието го надценява нарочно. Ние не казваме, че повредата на паметта е без значение или че можете да игнорирате критична отдалечена уязвимост в услуга, изложена към интернет. Експлойтите имат огромно значение на конкретни места: неудостоверени гранични устройства, дълготрайни устройства, всичко, където закърпването е бавно, а изложеността — постоянна. Понякога се нуждаем от такъв, а когато се нуждаем, той обикновено е публичен, срещу нещо, което отдавна е трябвало да бъде изведено от употреба.
Твърдението е по-тясно и, смятаме, по-трудно за оспорване: рискът се концентрира другаде. През нашите ангажименти констатациите, които ни позволяват да преминем от нищо към сериозно бизнес въздействие, са преобладаващо за това как системите са конфигурирани, за кого ви смятат и на какво се доверяват. Това е твърдение за разпределение, не за възможност. Ако разпределяте ограничен капацитет за отстраняване, разпределението е единственото, което има значение.
Какво казват собствените ни числа
Публикуваме анонимизиран набор от данни, за да може този довод да се провери, а не просто да се твърди. Текущият набор покрива 21 ангажимента и 190 констатации. От тях 180 имаха оценка на критичността по CVSS и се разпределят така:
Критичност на CVSS-оценени констатации (n = 180)
Critical 5 3%
High 26 14%
Medium 50 28%
Low 80 44%
Informational 19 11%
Забележете формата. Сериозните констатации са редки — 31 на High или Critical, около една на шест от всичко, което оценихме — докато масата на разпределението е при Low и Medium, където отиват повечето часове и повечето спорове. Забележете също, че петте Critical констатации са целият доклад, що се отнася до бизнеса, а нито една от тях не произлезе от намирането на нов бъг.
Класовете констатации ви казват повече, отколкото критичностите. Ето колко често се появява всеки клас, като дял от ангажиментите, в които докладвахме поне един негов случай.
- Разкриване на информация — 76%. Системи, които доброволно издават вътрешни детайли: версии, следи от стека, наименования, метаданни на обекти — поотделно безвредни, колективно карта.
- Неправилна конфигурация на сигурността — 57%. Компонент, внедрен с настройки, които бяха добри за демонстрация и никога не бяха затегнати за производство.
- Липсващи хедъри за сигурност — 52%. Евтини, добре документирани контроли от страната на браузъра, просто отсъстващи.
- Незакърпени или с изтекъл срок на поддръжка компоненти — 43%. Софтуер отвъд точката, в която изобщо някога ще бъде поправен.
- Нарушен контрол на достъпа — 38%. Удостоверени заявки, достигащи данни или действия, принадлежащи на някой друг.
- Слабости в удостоверяването — 38%. Слаби фактори, възстановими сесии, потоци, които може да се подхванат по средата.
- Слаба криптография — 33%. Остарели алгоритми, недоразмерени параметри, защити, които не биха издържали на внимателен поглед.
Сравнете този списък с филма в главите на хората. Повечето от честите класове изобщо не са уязвимости в смисъла на софтуерен дефект; те са решения. Един от тях — незакърпени и с изтекъл срок на поддръжка компоненти, на 43% — е историята за закърпването, и той наистина е чест. Но дори там обичайният проблем не е липсваща актуализация на поддържан продукт; той е продукт, който никой не актуализира, защото няма останала поддържана версия. Това е провал на жизнения цикъл и собствеността, облечен в дрехите на уязвимост. Методологията и определенията са в нашия доклад с констатации.
Конфигурация, идентичност, доверие
Когато сортираме сериозните констатации — онези, които промениха какво направи клиентът през следващия месец — те попадат в три категории със забележителна последователност.
Конфигурацията е състоянието, в което една система действително се намира, за разлика от състоянието, което документацията ѝ описва. Подразбирани стойности, никога преразгледани. Разрешителна опция, включена по време на миграция и никога върната назад. Подробна диагностика, оставена включена, защото е била полезна веднъж. Хранилище, направено достижимо, за да се реши петъчен проблем. Конфигурацията е там, където зее пропастта между намерението и реалността, и тя непрекъснато се измества: всяко внедряване и всяка поправка на инцидент я побутва.
Идентичността е въпросът за кого една заявка има право да се представя и какво може да прави тази идентичност. Акаунти и токени, надживели предназначението си. Служебни принципали, получили широки права, защото стесняването им изискваше разбиране на приложението. Споделени данни за достъп. Тайни в артефакти от билдове. Роли, които натрупват права и никога не ги изхвърлят, защото премахването на право рискува да счупи нещо, а добавянето — никога. Разрастването на идентичности е най-надеждният ни маршрут от малка опорна точка към голяма.
Доверието е това, което една система допуска за друга, без да проверява. Вътрешни услуги, които приемат всеки извикващ, вече вътре в периметъра. Интеграции, където компрометирането на едната страна е транзитивно компрометиране на другата. Сегменти, номинално отделени и практически съседни. Управляващи слоеве, достижими от места, които никой не е начертал на диаграмата. Отношенията на доверие рядко са документирани като такива, което е точно причината да преживяват одити.
И трите са систематично недоприоритизирани спрямо закърпването, по структурни, а не по небрежни причини. Закърпването има идентификатор, бюлетин от доставчик, скенер, който го маркира, табло, което го брои, и заявка, която се затваря чисто. Конфигурацията, идентичността и доверието нямат нищо от това. Никой канал не ви казва, че роля е станала с прекомерни права миналото тримесечие, никое число не намалява, когато премахнете остаряла интеграция, и няма очевиден собственик — тези проблеми седят в шевовете между екипите на платформата, приложението и операциите, където всеки може основателно да вярва, че ги държи някой друг. Освен това те се влошават безшумно: правилна конфигурация става неправилна през обикновена работа, без никой да присъства в момента, в който се обръща.
Как да укрепите защитата
- Направете конфигурацията тестван артефакт, не състояние. Заложете настройките, които имат значение — изисквано удостоверяване, изключена диагностика, частно хранилище, политика за шифри — като проверки, които се изпълняват при всяко внедряване и го провалят, а не като документ за закаляване, който някой е прочел веднъж.
- Дайте на всяка нечовешка идентичност собственик и срок на изтичане. Токените, ключовете, служебните акаунти и данните за достъп за интеграции — всички се нуждаят от назован собственик и дата, след която спират да работят. Всичко без двете е неуправляван риск.
- Преглеждайте правата според това, което е било използвано, не според това, което е било поискано. Извлечете действителната употреба за всеки принципал за представителен период и премахнете останалото. Прегледи, които питат дали едно право още е нужно, винаги отговарят с „да“.
- Запишете отношенията си на доверие. За всяка услуга избройте кой може да я извиква, какво тя приема като доказателство за идентичност и какво може да достигне. Онези, които не можете да формулирате, са първите за тестване.
- Третирайте изтичането на срока на поддръжка като контрол с краен срок. Проследявайте датите „поддържан до“ като първокласен инвентар и задайте датата за извеждане от употреба, преди поддръжката да приключи, а не след като констатацията се появи.
- Търсете тайни там, където се натрупват — хранилища, журнали от билдове, образи, архиви, заявки за поддръжка. Ротирайте намереното, после поправете пътя, който го е поставил там.
Защо това е обратното на успокоително
Има прочит на всичко това, който звучи като добра новина: ако нападателите не се нуждаят от експлойти срещу нас, не се изправяме пред екзотична способност, а проблемите ни са банални. Чуваме го често, и то е точно наопаки. „Не е нужен експлойт“ е по-лошата констатация, по три причини.
То премахва бариерата на умението. Написването на надежден експлойт срещу съвременна цел изисква експертиза, време и търпимост към провал, което ограничава колко хора могат да го правят и колко често си правят труда. Използването на валидни данни за достъп срещу услуга, която ги приема, не изисква нищо от това. Всеки, който може да пусне масов инструментариум, да купи достъп или да подмами служител с фишинг, може да оперира на нивото, което сериозните ни констатации описват. Слабост, която не изисква специализирано умение, има порядъци по-голяма популация от нападатели от онази, която изисква.
То премахва доказателството. Експлоатацията е шумна: сривове, неправилно оформен вход, аномално поведение на процеси — видът неща, около които е изградено откриването. Дейността, която описваме, не произвежда нищо от това. Токен с прекомерни права, използван да прочете данни, които технически може да прочете, генерира удостоверена, оторизирана, добре оформена заявка с отговор 200. Тя се появява в журналите като нормална употреба, защото по собствените правила на системата тя е нормална употреба. Единствените отличителни черти са контекстуални — този принципал, този обем, този час, този обект, който никога преди не е докосвал — а почти никой не логва с достатъчно структура, за да задава тези въпроси.
То премахва разстоянието. Експлойт се нуждае от достижима уязвима версия на конкретно нещо. Слабостите в конфигурацията, идентичността и доверието се нуждаят само от опорна точка — която и да е опорна точка. Една сесия, открадната чрез фишинг, едни изложени данни за достъп, една компрометирана интеграция на доставчик — и натрупаният набор става наличен наведнъж, защото тези слабости не са струпани на ръба. Те са разпределени из средата, затова опорна точка където и да е е в съседство с повечето от тях. Ето защо пропастта между „някой влезе“ и „някой взе всичко“ толкова често се измерва в часове.
Събрано заедно: слабостите, които доминират констатациите ни, са по-лесни за използване, по-трудни за забелязване и по-близки до всяка начална точка от онези, около които повечето програми са организирани. Нататък следват конкретните модели, какво направиха различно защитниците, които ни хванаха, и защо редът на поправяне, който повечето организации използват, е обърнат с главата надолу.
Данни за достъп, надживели всичко около тях
Най-полезният артефакт, който възстановяваме при вътрешен ангажимент, рядко е уязвим двоичен файл. Той е парола, която никой не е имал смелост да промени. В една среда намерихме привилегирован служебен акаунт, чиято парола беше зададена за последно преди около седемнадесет години. Тя все още работеше, все още държеше правата, предоставени при създаването, плюс каквото се беше натрупало оттогава, а нищо в инфраструктурата не можеше да забележи, че е станала вкаменелост.
Причината тя да оцелее не е небрежност. Ротацията се смята за рискована: никой не е сигурен кои процеси обвързват данните за достъп, коя планирана задача ще се провали безшумно, коя интеграция ще се счупи в края на тримесечието. Хората, които са изградили зависимостта, са се преместили, затова изглеждащото най-безопасно решение всяка година беше да я оставят на мира. Седемнадесет такива решения подред създават нещо, за което изобщо не може да се разсъждава.
Това, което прави случая повече от оплакване за хигиена, е как данните за достъп на такава възраст се натрупват:
- Те предхождат текущата политика. Избрани по каквито правила са съществували тогава, те обикновено са достатъчно кратки, за да паднат от офлайн атака в рамките на часове, щом веднъж разполагаш с хеша.
- Те са в документацията. Ръководства за работа, ръководства за билдове и бележки за предаване, оставени от три поколения оператори — всяко копие е място, където тайната може да я прочете някой, за когото тя никога не е била предназначена.
- Те са в архивите. Всяка точка за възстановяване и архивиран образ на машина от целия период все още държат материал, който отключва производствения акаунт днес. Прозорецът на изложеност не е „сега“; той е цялата история на инфраструктурата.
- Те се използват повторно. Парола на такава възраст почти винаги е била зададена и на съседни акаунти, локални администраторски акаунти или приспособление, а нищо оттогава не ги е разграничило.
Възрастта измерва колко копия на данни за достъп съществуват извън контролите, които вярвате, че имате. Същият ангажимент изведе дузини акаунти без флага за предварително удостоверяване на Kerberos — съседният провал, който позволява на нападател да поиска материал, подлежащ на офлайн разбиване за тези акаунти, без изобщо да се удостоверява. Сам по себе си — пропуск в политиката. Заедно — път.
Как да укрепите защитата
- Инвентаризирайте служебните акаунти по възраст на паролата. Третирайте всичко отвъд няколко години като неуправлявана тайна.
- Отговорете на страха от ротация с наблюдаемост, не със смелост: няколко седмици логване на удостоверяването за всеки акаунт ви казват какво обвързва данните за достъп.
- Предпочитайте типове акаунти, при които платформата ротира тайната вместо вас, така че решението да се взема веднъж.
- Поправете акаунтите, които не изискват предварително удостоверяване; това премахва безплатен примитив за офлайн атака.
- Приемете, че всякакви данни за достъп, по-стари от съхранението на архивите ви, вече са разкрити. Ротирането им е ограничаване, не поддръжка.
Защити на протоколите, които никога не бяха включени
Вторият модел е по-тих, защото нищо не липсва. Контролът съществува, дошъл е с продукта и е изключен — както е бил от инсталацията, защото включването му беше умишлено действие, което никой проект така и не поема.
Списъкът се повтаря през ангажиментите. Подписване и защита на канала на протоколите за споделяне на файлове и директории, оставени изключени, така че нападател, който може да повлияе на разрешаването на имена, препредава удостоверяването, вместо само да го наблюдава. Подразбирани данни за достъп, все още живи на услуга за база данни, непроменени от ръководството за инсталация. Акаунт за база данни с права далеч отвъд всичко, което приложението използва, защото предоставянето на всичко беше най-бързо. Тайни в чист текст в конфигурационни файлове, четими от повече акаунти, отколкото е предвидено.
Най-ясният случай беше услуга за трансфер на файлове между бизнеси, изложена към интернет. Тя завършваше TLS ръкостискания, без изобщо да поиска клиентски сертификат: взаимен TLS беше поддържан и документиран, но не беше конфигуриран. Удостоверяването на партньори следователно беше рухнало, безшумно, от притежание на частен ключ към познаване на споделена тайна — а споделена тайна може да се възпроизведе отвсякъде от всеки, който веднъж я е възстановил, от заявка, скрипт или конфигурационен файл като онези по-горе.
възстановена конфигурационна тайна
→ удостоверяване към изложен към интернет слушател за трансфер
→ сървърът никога не иска клиентски сертификат
→ партньорска идентичност твърдяна, не доказана
→ оторизирано пускане на файл в обработка надолу по веригата
Нищо от това не е дефект. Всяко е функция, която съществува в продукта, идва изключена за съвместимост и никога не се включва, защото системата работи без нея. Нищо не се чупи и никакъв сигнал не се задейства. Контролът е в архитектурната диаграма и отсъства от работещата конфигурация, а тази пропаст е там, откъдето идва повечето от достъпа ни.
Как да укрепите защитата
- Третирайте „поддържано, но не включено“ като собствен клас констатации: подписване, обвързване на канала, взаимно удостоверяване, валидиране на сертификати.
- Изисквайте подписване и защита на канала на протоколите за директории и споделяне на файлове и измерете кои наследени клиенти се чупят преди промяната, вместо да ги третирате като причина да не я направите.
- На всеки слушател, обърнат към партньори, изисквайте клиентски сертификат и проверявайте издателя и субекта. Където споделена тайна е единственият удостоверител, границата на доверие е по-слаба, отколкото договорът твърди.
- Редовно сканирайте хранилищата на конфигурации, хранилищата на код и артефактите от билдове за тайни в чист текст.
- Дайте на акаунтите за бази данни само правата, които приложението доказуемо използва, и заменете подразбиранията по време на билда.
Доверие, което сочи навън
Когато докладваме опорна точка, обикновено ни питат какво е достигнала. Това е погрешната ос. По-съществен е въпросът какво ни позволи да станем.
От един набор възстановен материал държахме три обърнати навън идентичности: данни за достъп за партньорски акаунти за трансфер на файлове, ключ за внедряване за хранилище, което внедряваше автоматично при коммит, и миграционен ключ за наследени back-end възли. Нито един не е интересен като дестинация; всеки е интересен като възможност за имитация. Партньорските идентичности позволяват фалшифицирани пускания на файлове в чужд конвейер, където данните пристигат предварително удостоверени и им се вярва повече, отколкото на каквото и да било на входната врата. Ключът за внедряване позволява коммит, който става работещ код без човек в пътя — а премахването на това триене е целта на пайплайна.
опорна точка на достижим хост
→ възстановяване на съхранени ключове за интеграция
→ коммит към автоматично внедряващо хранилище
→ код се изпълнява в производството без преглед
→ радиусът на поражение сега включва всеки консуматор надолу по веригата
Обхватът на пораженията следователно престава да е вътрешна мярка: организацията вече не е само жертвата, но и механизмът за доставка, а вредата каца върху контрагенти, които никога не бяха тествани и които никога не са давали съгласие. Рискът също се измества от технически към договорен и регулаторен — споразумения за обработка на данни, задължения за уведомяване, които може да принадлежат на няколко страни наведнъж, уверения пред доставчици, които вече не можете да давате искрено. Докладван точно, той е частта от ангажимента, която един борд може да остойности.
Как да укрепите защитата
- Поддържайте регистър на доверието към външни системи: всеки ключ и акаунт, чрез който можете да действате като себе си в чужда система, и кой го държи.
- Дръжте данните за внедряване извън хостове с общо предназначение; обхванете ги към едно хранилище и среда и ги направете краткотрайни.
- Изисквайте стъпка за човешко одобрение между коммит и производствено внедряване за всичко, което пресича граница.
- Подписвайте полезните товари, които изпращате на партньори, не само канала, така че открадната транспортна идентичност да не може сама по себе си да произведе доверен файл.
- Репетирайте пътя за уведомяване за инцидент, в който вие сте векторът; правната позиция е по-трудна за изясняване по време на самия инцидент.
Какво защитниците бяха направили правилно
Би било нечестно да оставим впечатлението, че тези среди бяха зле управлявани. Същите ангажименти показаха и последователен набор от добре свършени неща, няколко от които ни спряха.
- TLS конфигурация на външните услуги. Конфигурация на периметъра, оценена в най-горната категория: съвременни версии на протокола, разумни шифри, правилна обработка на веригата. Някога надежден източник на констатации, и до голяма степен вече не.
- Стеснена повърхност на разширенията в базата данни. Инсталирано беше само нужното, затова няколко добре известни маршрута за ескалация вътре в двигателя нямаха компонентите, на които разчитат.
- Няма изложен контейнерен сокет в контейнер за база данни. Най-честото бягство от контейнер към хост, което търсим, не беше там. Някой беше помислил за него.
- Закалени мениджъри на приложения. Административните интерфейси, които обикновено вървят право от слаба парола към изпълнение на код, бяха заключени или извън обсег.
- Подменени пароли, открити в бази с изтекли данни. Където потребителите на организацията се появяваха в публични данни за пробиви, данните им за достъп бяха променени. Спрейването с известен материал не даде нищо.
- Мрежово разположение, което прекрати път за ескалация. Сертификационен орган беше недостижим от тестваната мрежа. Добре разбран маршрут съществуваше на хартия и не можеше да бъде извървян — не защото слабостта беше закърпена, а защото топологията ни отказа разговора.
Последният е най-ясният пример за защита в дълбочина, която действително работи. Слабостта беше налице; пътят до нея — не. Сегментацията свърши точно работата, за която се продава — което е по-рядко, отколкото маркетингът подсказва. Ротацията и повърхността на разширенията правят свързана точка за това къде усилието се отплаща: и двете са непримамливи, и двете са невидими, когато успеят, и двете премахнаха цели категории атаки, а не отделни констатации.
Докладваме ги наред с провалите като метод, не от любезност. Тест, който изброява само счупеното, оставя ръководителя на сигурността неспособен да каже кои инвестиции работят, и така неспособен да ги защити. Той също така преценява погрешно критичността, защото констатация, чийто път на експлоатация е затворен от сегментация, не е същото като констатация, чийто път е отворен.
Какво да поправите първо и защо редът е противоинтуитивен
Инстинктивният ред на отстраняване започва с списъка с чакащи актуализации, защото е номериран, измерим и видимо намаляващ. Ние бихме го поставили последен от четирите.
Първо, хигиена на идентичността и данните за достъп. Одитирайте служебните акаунти по възраст, ротирайте древните, поправете флаговете за предварително удостоверяване, разделете преизползваните пароли, преместете тайните извън конфигурационните файлове. Данните за достъп са единственият актив, чиято изложеност е със задна дата: ключ, възстановен днес, отключва системите, каквито са сега, а всяко историческо копие остава живо до ротация. Закърпването поправя бъдещето; ротацията поправя миналото.
Второ, включете защитите, които вече сте купили. Подписване, защита на канала, взаимен TLS на слушатели към партньори, минимални права на акаунтите за бази данни, заменени подразбирания. Нищо тук не се нуждае от доставка: цената е преглед на конфигурацията и тест за съвместимост, а ефектът е да се премахнат препредаване, повторение и имитация като техники, а не като отделни случаи. Вече плащате за тези функции.
Трето, съпоставете доверието към външни системи. Избройте идентичностите, чрез които системите ви могат да действат вътре в системите на други организации, после ги обхванете, съкратете им живота и им поставете порти. Направете това преди закърпването, защото то определя как изглежда най-лошият ви ден: две среди на идентични нива на прилагане на актуализации за сигурност имат различни обхвати на пораженията, ако едната държи жив ключ за внедряване на хост с общо предназначение.
Четвърто, закърпвайте. То има значение, а хостове с изтекъл срок на поддръжка, изпълняващи услуги в чист текст, наистина трябва да си отидат. Но изоставането е най-видимото и най-малко решаващо от четирите: то никога не е завършено, затова поглъща усилие, без да достигне състояние на покой, а точките му са подредени по резултат, а не по достижимост, затова работата тече към уязвимости, до които не води път. И то рядко е първата брънка във веригата. Не влизаме чрез повреда на паметта. Влизаме чрез нещо, което ни е дадено.
Твърдението е за подреждането под фиксиран бюджет: първите три нива премахват техники, четвъртото премахва отделни случаи. Правете работата, която променя какво е способен да прави един нападател.
Къде нападател всъщност би влязъл?
Тестът за проникване отговаря на това с доказателство, а не със списък актуализации за сигурност — пътищата, които работят, и редът, в който да ги затворите.
Определете обхват на тест за проникване