Новоподробно описан инструмент за офанзивна сигурност, наречен RAVEN, показва как една компрометирана Elasticsearch среда може да се превърне в инцидент със загуба на данни с постоянен достъп.

Инструментът демонстрира какво би могъл да направи атакуващ, след като достигне до изложен клъстер или поеме контрол над Kibana. Пътят на атаката започва, след като разузнаването и експлоатацията са отворили вратата.

Операторът може да прави заявки към Elasticsearch, да копира съхранени записи, да създава алтернативни идентификационни данни и да оставя механизми, които възстановяват достъпа, след като защитаващата се страна започне почистване.

От LevelBlue заявяват в доклад, споделен с Cyber Security News (CSN), че техните изследователи рамкират RAVEN като контролиран инструмент за тестове за проникване, а не като доказателство за реална престъпна кампания, но неговият работен процес илюстрира последствията от слабо защитени платформи за данни.

Изследването е използвало базирани на Docker Elasticsearch 7.17.22 лаборатории, със и без сигурност от X-Pack.

То последва по-ранни тестове, които достъпиха Elasticsearch през порт 9200 и постигнаха изпълнение на код през порт 5601 след компрометиране на Kibana – маршрут, станал още по-тревожен от критични уязвимости за изпълнение на код в Kibana, докладвани другаде.

Инструментът RAVEN източва цели бази данни на Elasticsearch и запазва достъпа

Модулът за източване на данни на RAVEN може да извлече избран индекс или да експортира всеки несистемен индекс в локални JSON файлове с разделители за нов ред.

За по-нови версии на Elasticsearch той използва Point-in-Time API за преминаване през записите; при версии преди 7.10 може да използва Scroll API.

Следователно една единствена опорна точка може да се превърне в практически начин за събиране на масиви от данни за клиенти, поръчки или приложения.

Инструментът може да възобнови прекъснато събиране; неговата групова настройка позволява на оператора да компрометира скоростта в замяна на по-малко забележими заявки.

Той също така може да изпраща копирани данни към контролиран от атакуващия Elasticsearch сървър, запазвайки мапингите и настройките на индексите. Това представлява конкретен бизнес риск, а не просто доказателство, че записите са били четими.

RAVEN също така предлага метод за създаване на резервно копие (snapshot) на ниво сървър. Операторът може да регистрира хранилище на целевата машина и да създаде snapshot на избрани индекси.

Тъй като масовото преместване на данни се случва вътре в Elasticsearch, а не чрез мрежов трафик, този подход може да създаде много по-малко забележима активност от многократните заявки. Докладът посочва, че необичайните snapshot хранилища и задачи заслужават разследване.

Излагането на Elasticsearch и неговия слой за управление остава опасно, когато уязвимости или незащитени настройки осигуряват първоначалната опорна точка.

Организациите трябва да дадат приоритет на корекциите, включително на проблемите, обхванати от скорошни корекции за сигурност на Elastic, и да ограничат достъпа до портовете за управление, вместо да ги оставят отворени за несигурни мрежи.

API ключовете надживяват промените на пароли

По-персистентната част от демонстрацията включва API ключове за Elasticsearch. RAVEN може да изброява ключове, видими за компрометирания потребител, и да създава нов ключ, носещ правата на този потребител.

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

Докладът също така описва опити за събиране на ключове от индекса за сигурност, където разрешенията го позволяват.

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

Модулът за персистентност на RAVEN добавя три слоя: злонамерен потребител с високи привилегии, дълготраен API ключ и задача Elasticsearch Watcher.

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

Това променя плана за реагиране. Екипите трябва да направят инвентаризация на потребителите, API ключовете, акаунтите за услуги, дефинициите на Watcher, хранилищата и последните промени в сигурността, преди да декларират овладяване на инцидента.

Те трябва изрично да анулират непознатите ключове, първо да премахнат неоторизираните Watchers, да ротират засегнатите идентификационни данни и да прегледат одитните логове за подозрителни самоличности.

Насоките относно заобикалянето на удостоверяване с API ключове също показват защо издадените ключове се нуждаят от собствен процес на преглед и отмяна. RAVEN записва действията по промяна на състоянието в лог на активността с информация за тяхното отмяна.

Въпреки че това подпомага почистването при оторизирани тестове, защитниците не могат да приемат, че атакуващият ще остави такъв запис.

Ротацията на пароли е само една стъпка за овладяване на ситуацията; възстановяването изисква също така откриване на всеки независим идентификатор и планиран механизъм, който може да отвори вратата отново.