Уязвимости в облачных сервисах и как их предотвратить

Что такое облачные сервисы и какие виды облачных серверов существуют?

Облачные сервисы – это различные сервисы на удалённом сервере, которые реализуется через аренду. Для лучшего понимания давайте вспомним про тот же гугл диск, где вы можете хранить свои файлы. Т.е ваши файлы хранятся не на вашем устройстве, а на облачном сервисе от Google.

Спецификой облачных технологий в наше время является тот факт, что они реализуются специальными поставщиками облачных решений. Давайте перечислим самые популярные из них:

1. AWS. (Amazon Web Services)
2. Microsoft Azure.
3. Google Cloud Storage.

Заслуженное лидерство взяла на себя компания Amazon, создавшая AWS, поэтому примеры всех уязвимостей будут описаны именно на AWS.

Так чем же так сильно облачные технологии отличаются от собственных серверов и почему все больше компаний держат данные в облаке?

Это банально дешевле. Вот представьте, что у вас 100 своих серверов. Во-первых, их нужно купить. Во-вторых, их нужно грамотно настроить. В-третьих, вам нужно учитывать масштабируемость, ведь и 1000 собственных серверов может не хватить для хранения всех данных.

А теперь представьте облачные технологии. Обслуживание серверов на себя берет компания поставщик. Закупать сервера вам не нужно, вы их арендуете. Излишнее место или его недостаток банально уходят, ведь тот же Amazon позволяет динамически расширять пространство на облаке под ваши нужды, дабы вы не переплачивали. Ну и очевидно, что облака в разы выгоднее как в плане денег, так и в плане работы со стороны системных администраторов.

Также спецификой облачных технологий является то, что облака не всегда исполняют функцию одного лишь хранения данных.

Рассмотрим на другие разновидности облаков на примере AWS:

1. Amazon Elastic Compute Cloud (Amazon EC2) – это веб сервис, предоставляющий безопасные масштабируемые вычислительные ресурсы в облаке.
2. Amazon Simple Storage Service (Amazon S3) – это сервис хранения объектов, предлагающий лучшие в отрасли показатели производительности, масштабируемости, доступности и безопасности данных. Клиенты любой величины и из любой промышленной отрасли могут хранить и защищать необходимый объем данных для практически любого примера использования. Например, для озер данных, облачных приложений и мобильных приложений. Выгодные классы хранилища и простые в использовании инструменты администрирования позволяют оптимизировать затраты, организовать данные и точно настроить ограничения доступа в соответствии с потребностями бизнеса или законодательными требованиями.
3. Amazon S3 Glacier и S3 Glacier Deep Archive – это безопасные, надежные и очень экономичные классы облачного хранилища Amazon S3 для архивации данных и длительного хранения резервных копий.

Как выглядит домен AWS сервера?

https://[имя_бакета].s3.amazonaws.com

https://s3-[регион].amazonaws.com/[имя_организации]

Так же в ходе чтения статьи вы увидите такую разновидность записи домена: http://169.254.169.254

Эта запись будет использоваться, если локальный компьютер и сервер AWS, грубо говоря, функционируют в одной локальной сети.

Регион - это та область планеты Земля, в которой находится ваш сервер. Например, код региона us-west-1 - это Калифорния.

Принцип работы AWS. Что такое IAM?

IAM - это система управления доступом, позволяющая создавать пользователей, давать им различные права доступа, объединять пользователей в свои группы со своими привилегиями и т.д.

Давайте представим себя в роли системного администратора и словесно опишем минимальные действия для внесения сотрудников в систему AWS:

1. У нас должны быть категории пользователей.
2. Пользователи должны авторизоваться в бакете или любом другом сервисе AWS.
3. У пользователей должны быть разные права доступа.

Если логин и пароль, назначенные админом, злоумышленнику получить крайне проблематично, то пару ключей AccessKey и SecretKey мы можем получить множеством способов, которые будут описаны чуть позже.

Во время внесения юзера в пользователя AWS ему выдается политика доступа (коих крайне много), логин и пароль для авторизации через веб-интерфейс и пара ключей.

Так что же из себя представляет эта пара ключей?

Эти ключи нужны для работы с AWS сервером через AWS CLI

Для простоты AccessKey играет роль логина в CLI, а SecretKey играет роль пароля.

AWS CLI

Логично, что нам как-то нужно взаимодействовать с арендуемым AWS сервером, и таким интерфейсом взаимодействия выступает AWS CLI (приложение в командной строке)

Как злоумышленник будет осуществлять поиск серверов AWS?

Ручной поиск при помощи BurpSuite

Основным способом поиска серверов является ручной способ. Допустим, наше приложение отправляет информацию с основного домена на бакет, тогда логично предположить, что мы можем перехватить этот запрос при помощи burp suite, узнать url бакета и провести аудит этого самого бакета.

Просто записывайте в отдельный файл все AWS адреса во время тестирования Burp Suite основного домена.

Shodan/Censys

Лучшими друзьями в поиске AWS серверов навсегда останутся Shodan и Censys

Для поиска серверов достаточно ввести в панель поиска слово AWS или любой сервис по типу S3 или EC2.

Стоит понимать, что связанные с основным тестируемым доменом сервера вы не найдете, но просто посмотреть на открытые AWS тоже можно, дабы понять, что вообще может лежать на тех или иных сервисах от AWS.

Google Dorks (в простонародье дорки)

Например, такой дорк позволит искать файлы конфигураций:

intitle:"index of" "aws-config.php"

Больше дорков для aws вы сможете найти тут. (просто вбейте в поиске AWS или название конкретного сервиса AWS)

Опять-таки, дорки здесь нужны скорее для анализа утечек через облака, ибо связанные AWS с доменом вы не найдете. Естественно, если вы нашли ручным методом тот или иной сервер, вы можете обнаружить при помощи дорков интересные директории и ранее проиндексированные страницы.

Поиск URL адресов в коде

Если мы при вскрытии того же андроид приложения, сайта или при анализе кода на GitHub найдем URL AWS сервера, то мы без сомнений можем приступать к тестированию этого сервера.

Уязвимости

А теперь давайте начинать говорить о том, зачем мы тут все и собрались.

1. Публичный доступ S3 Bucket

S3 bucket безопасен из коробки, но критическим моментом может стать проставленная в настройках сервера галочка, разрешающая получать доступ к серверу публично. Такая проблема может возникнуть как из-за неосведомленности системного администратора, так и из-за проблем настройки инфраструктуры, которая не может получать доступ к закрытому от внешних глаз серверу.

Если вы нашли любой s3 bucket и вы предполагаете, что он доступен публично, то вы можете просмотреть его через браузер, либо использовать эту команду AWS CLI, которая позволит посмотреть содержимое сервера:

aws s3 ls s3://(имя бакета)/ --region (имя региона)

Так же не стоит опускать руки, если AWS отдает пустую HTML страницу, попробуйте получить содержимое с помощью утилиты curl, возможно, вы получите инструкции по получению папок на сервере, т.к вы могли пропустить какие-то важные заголовки в запросе.

Но даже если сам бакет закрыт от посторонних глаз, то все равно есть вероятность, что файлы, лежащие в бакете, публичны

Единственным способом найти публично лежащие объекты в бакете является метод брутфорса, например, с помощью wfuzz или gobuster.

Так же при использовании Kubernetes есть риск обнаружить незакрытые от публичного просмотра кластеры. (особенно, если они содержат AWS сервера с конфиденциальными данными)

2. Неправильная структура файлов в бакете

Очевидно, что какие-то файлы в бакете (например, изображения или видео для основного домена) вы захотите хранить публично. В пределах одного бакета можно настроить классификацию файлов по степени доступности. Если на одном бакете лежат конфиденциальные данные и данные общедоступные, ни в коем случае не смешивайте их.

3. Утечки ключей через код

При разработке любого приложения, будь то веб-приложение, будь то мобильное приложение, всегда есть возможность утечки конфиденциальных данных через код, включая AWS Keys, об обфускации которых вам стоит позаботиться. Так же если вы явно указываете URL адрес в коде, позаботьтесь о его защите, ведь злоумышленник сможет спокойно обнаружить ваш сервер в коде и атаковать его

Для автоматизации этого процесса можно пройтись по коду или репозиторию с кодом тем же GitMiner.

4. SSRF атаки и их связь с облачными решениями

Как бы хорошо вы не закрыли бакеты, объекты на бакетах. Как бы хорошо вы не провели аудит контейнеров и т.д, решающую роль может сыграть наличие SSRF в вашем веб-приложении.

Для тех, кто в танке:

SSRF -  это уязвимость веб-приложения, позволяющая заставить сервер, на котором крутится веб-приложение, отправлять запросы на другие ресурсы, включая сервера внутренней инфраструктуры. Если же основной сервер общается с серверами aws, арендуемыми компанией, то злоумышленник так же может послать запрос для извлечения конфиденциальных данных.

Например, у нас есть основной сайт по продаже одежды, который при покупке хочет проверить наличие товара на складе, посылая следующий запрос:

POST / HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118

checkTovar=http://sklad.example-shop.com/check-shirt

Но мы так же можем поменять значение заголовка checkTovar:

POST / HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118

checkTovar=http://169.254.169.254

Доступ к AWS серверу, лежащему в локальной сети организации, расположенному по адресу http://169.254.169.254 будет получен, т.к мы заставляем основной хост обратиться к серверу в своей локальной сети. Т.е извне получить доступ без SSRF невозможно.

Для понимания серьезности SSRF атак достаточно вспомнить случай, произошедший два года назад с банком Capital One, s3 бакеты которого были скомпрометированы(в бакетах лежали данные клиентов банка)

Атака была проведена с основного сайта банка, ведя запрос с корневого домена на URL:

http://169.254.169.254/latest/meta-data/iam/securitycredentials

По этому адресу хранятся AWS IAM Keys, которые были использованы для доступа к бакетам с конфиденциальными данными.

В папке securitycredintals находятся AccessKey и SecretKey, с помощью которых мы можем получить доступ к серверу при помощи такой команды:

aws configure –profile (имя_профиля)

И последующим вводом данных:

Список основных URL для извлечения конфиденциальных данных при помощи SSRF.

http://169.254.169.254/latest/user-data

http://169.254.169.254/latest/user-data/iam/security-credentials/(имя_пользователя)

http://169.254.169.254/latest/meta-data/

http://169.254.169.254/latest/meta-data/iam/security-credentials/(имя_пользователя)

http://169.254.169.254/latest/meta-data/iam/security-credentials/PhotonInstance

http://169.254.169.254/latest/meta-data/ami-id

http://169.254.169.254/latest/meta-data/reservation-id

http://169.254.169.254/latest/meta-data/hostname

http://169.254.169.254/latest/meta-data/public-keys/

http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy

http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

http://169.254.169.254/latest/dynamic/instance-identity/document

Так же хотелось бы упомянуть инструмент пост эксплуатации для AWS под названием Pacu.

Pacu позволяет пентестерам эксплуатировать ошибки конфигураций учетной записи AWS, используя модули для легкого расширения ее функциональности. Модули, встроенные в Pacu позволяют выполнить обширную пост эксплуатационную атаку на захваченном сервере AWS.

5. Веб уязвимости

Бакеты, как и любой другой сервер, могут быть использованы для хранения отдельных HTML страниц, JS кода, целых веб-сайтов. При таком раскладе не стоит забывать про банальную атаку XSS. Если JS код уязвим, то страницу с вредоносным JS кодом злоумышленники могут спокойно использовать для атак с применением социальной инженерии. Согласитесь, когда сотрудник получает письмо с действующим сервером AWS, принадлежащим компании, он будет более лоялен в открытии вредоносной ссылки.

6. Неправильное хранение ключей на локальном компьютере

После установки AWS CLI на локальном компьютере появляется папка /домашняя_папка/.aws/credentials, которая содержит ключи для входа через CLI, данная папка всегда находится под угрозой, поэтому если на компьютер попадет вредонос, то сервер будет скомпрометирован. Защитите эту папку банальным паролем.

Так же стоит немного дополнить данный момент возможной LFI уязвимостью на основном хосте. Если сервер, на котором крутится веб-приложение, имеет в файловой системе файл /.aws/credentials, то с помощью Local File Inclusion можно этот файл прочитать, поэтому не стоит хранить на основном сервере файлы с ключами, если есть риск LFI.

7. Неправильные разрешения

Представим, что киберпреступник захватил пару ключей дизайнера вашей компании и будет манипулировать сервером через AWS CLI при неправильно настроенных разрешениях. Допустим, вы по ошибке выдали дизайнеру разрешения разработчика. Собственно, у злоумышленника будет больше возможностей для полного захвата вашей облачной инфраструктуры.

Рекомендации по безопасности

1. Закрывайте доступ к бакетам извне, банально не меняя настройки публичности по умолчанию.

2. Включайте MFA. (проверка владельца аккаунта через физическое устройство, например, через телефон)

3. Полностью удаляйте сервер из сети.

Некоторые бакеты удалены из сети не полностью (остаются записи DNS), что может привести к атаке угона домена.

4. Включите шифрование критически важных файлов в бакете.

5. Включите журналы аудита в бакете (отключены по умолчанию), чтобы просматривать тех, кто заходил на сервер.

6. Внимательно следите за разрешениями учетных записей пользователей.

7. Усильте защиту веб-приложения, если таковое имеется на AWS сервере.

8. Обфусцируйте код приложения и не хардкодьте ключи и URL адреса AWS серверов.

9. Самое золотое правило: обучите персонал противодействию киберпреступникам, использующим социальную инженерию.