Сбор информации при помощи технологии OSINT в связке с DataSploit
Форсайт
Для тех, кто не знаком с этой концепцией, поясню, что технология OSINT расшифровывается как Open-Source INTelligence (разведка на основе открытых источников) и в основном представляет собой сбор публично доступной информации в интернете для последующего анализа. С другой стороны, поведенческие характеристики описывают деятельность пользователя, в том числе и перечень посещаемых сайтов. Например, так: «Боб – женатый юрист и использует Dropbox, LinkedIn и Facebook. Также у Боба есть учетная запись в Gmail».
Проблемы безопасности электронной почты
В современном мире не так редки случаи, когда происходит информационная утечка о том, что имена пользователей или электронных ящиков, находится в базе данных веб-приложения.
Зачастую злоумышленник, при помощи исключительно взаимодействия с формой авторизации, может легко догадаться, что электронная почта хранится в базе приложения. То есть можно просто ввести неправильную электронную почту или пароль и посмотреть, каков будет ответ сервера.
Ситуация
Ответ сервера
Электронная почта не хранится в базе приложения
Учетная запись с такой электронной почтой не найдена
Электронная почта хранится в базе данных, но пароль неверный
Пароль неверный, попробуйте снова
Вышеуказанные примеры позволяют определить, зарегистрирован ли пользователь в системе. Однако не каждое потенциально уязвимое приложение выдает такие ответы. Иногда, информация утекает во время отсылки браузеру статусного HTTP-кода, отличного от 200, или перенаправления на другую страницу, на которой можно извлечь нужные сведения.
Почему эти уязвимости встречаются в приложениях?
Основная причина заключается в желании архитекторов сделать систему более удобной, плюс, в некоторой степени, влияние крупных игроков, таких как Microsoft или Google, которые задают современные тренды в проектировании и написании приложений.
Сервис
Ситуация
Ответ сервера
Outlook
Несуществующий пользователь
Такой учетной записи не существует
Gmail
Несуществующий пользователь
Невозможно найти вашу учетную запись
И тут веб-разработчику может прийти следующая мысль: «Если большие компании так делают, то почему не могу я?».
Но не забывайте о хакерах. Сообщения выше являются понятными для пользователя и помогают сориентироваться, что происходит, но и негативно влияют на безопасность, что особенно актуально, если сайт предназначен для широкой аудитории.
Компаниям следует защищать информацию, хранимую в базах приложений, используемых людьми с определенной религией, расой, сексуальной ориентацией, политическими взглядами и так далее. Эта тема касается сайтов знакомств, игровых сайтов и любых других сервисов, у которых можно получить приватные поведенческие паттерны пользователей.
Рассмотрим подробнее угрозы, связанные с утечкой электронной почты:
· Пользовательские учетные записи потенциально могут быть получены при помощи брутфорса.
· Рабочие электронные адреса могут извлекаться для спама.
· OSINT может использоваться для выяснения персональной информации на сайтах, где зарегистрирован пользователь.
Как решить проблему?
С точки зрения разработчика ответ сервера должен быть таким, чтобы не было понятно, что произошло, как показано в таблице ниже.
Ситуация
Ответ сервера
Несуществующая электронная почта
Предоставленные учетные данные не корректны
Существующая почта с неправильным паролем
Предоставленные учетные данные не корректны
Twitter – один из примеров, где было пожертвовано частью удобствами пользователей ради безопасности:
Сервис
Ситуация
Ответ сервера
Несуществующий пользователь
Введенная электронная почта и пароль не совпадают ни с одной нашей записью
Решение оказалось довольно простым: сообщения об ошибках во время авторизации должны иметь такое содержимое, чтобы не было понятно, вы ошиблись при вводе или учетной записи не существует.
OSINT в контексте электронной почты
Начиная с небольших веб-приложений, написанных на PHP, JavaScript или Python, и заканчивая широко известными сайтами по всему миру, включая ERP и CRM системы с открытым исходным кодом, существует масса случаев утечек электронных адресов из баз данных.
Помните, что у хакеров может быть достаточно времени и мотивация на выполнение ручного пентеста и написание утилит, заточенных под конкретную задачу, с целью идентификации электронных адресов с поведенческими характеристиками.
Автоматический OSINT в связке с DataSploit
DataSploit представляет собой фреймворк, реализующий технологию OSINT и написанный на Python, который в автоматическом режиме собирает информацию о доменах, электронной почте, именах пользователей и телефонах. Вы можете использовать DataSploit как внутри Python-приложений, так и в качестве отдельного инструмента через командную строку.
Ниже показан перечень команд для установки DataSploit:
git clone https://github.com/datasploit/datasploit /etc/datasploit
cd /etc/datasploit/
pip install -r requirements.txt
mv config_sample.py config.py
Если установка завершилась успешно, в консоли будет выведено следующее сообщение:
python datasploit.py
True
Для запуска потребуется нужно указать цель или файл.
Формат команды: datasploit.py [-h] [-i SINGLE_TARGET] [-f FILE_TARGET] [-a] [-q] [-o OUTPUT]
Возможные аргументы:
Аргумент
Описание
-h, --help
Показать справку и выйти
-i SINGLE_TARGET, --input SINGLE_TARGET
Нужно указать цель
-f FILE_TARGET, --file FILE_TARGET
Нужно указать файл
-a, --active
Активное сканирование
-q, --quiet
Тихое сканирование в автоматическом режиме и принятие стандартных ответов
-o OUTPUT, --output OUTPUT
Нужно указать целевую директорию
Ниже показан пример для сбора информации, касающейся конкретного электронного адреса:
python emailOsint.py bob@genericdomain.org
Результат работы команды:
[-] Skipping Hacked because it is marked as disabled.
---> Finding Paste(s)..
[-] google_cse_key not configured
[-] google_cse_key and google_cse_cx not configured. Skipping paste(s) search.
Please refer to http://datasploit.readthedocs.io/en/latest/apiGeneration/.
---> Searching Scribd Docs
---> Checking breach status in HIBP (@troyhunt)
Pwned at 4 Instances
Title: Adobe
BreachDate: 2013-10-04
PwnCount: 152445165
Description: In October 2013, 153 million Adobe accounts were breached with each containing an internal ID, username, email, <em>encrypted</em> password and a password hint in plain text. The password cryptography was poorly done and <a href="http://stricture-group.com/files/adobe-top100.txt" target="_blank" rel="noopener">many were quickly resolved back to plain text</a>. The unencrypted hints also <a href="http://www.troyhunt.com/2013/11/adobe-credentials-and-serious.html" target="_blank" rel="noopener">disclosed much about the passwords</a> adding further to the risk that hundreds of millions of Adobe customers already faced.
DataClasses: Email addresses, Password hints, Passwords, Usernames
Title: Dropbox
BreachDate: 2012-07-01
PwnCount: 68648009
Description: In mid-2012, Dropbox suffered a data breach which exposed the stored credentials of tens of millions of their customers. In August 2016, <a href="https://motherboard.vice.com/read/dropbox-forces-password-resets-after-user-credentials-exposed" target="_blank" rel="noopener">they forced password resets for customers they believed may be at risk</a>. A large volume of data totalling over 68 million records <a href="https://motherboard.vice.com/read/hackers-stole-over-60-million-dropbox-accounts" target="_blank" rel="noopener">was subsequently traded online</a> and included email addresses and salted hashes of passwords (half of them SHA1, half of them bcrypt).
DataClasses: Email addresses, Passwords
Title: LinkedIn
BreachDate: 2012-05-05
PwnCount: 164611595
Description: In May 2016, <a href="https://www.troyhunt.com/observations-and-thoughts-on-the-linkedin-data-breach" target="_blank" rel="noopener">LinkedIn had 164 million email addresses and passwords exposed</a>. Originally hacked in 2012, the data remained out of sight until being offered for sale on a dark market site 4 years later. The passwords in the breach were stored as SHA1 hashes without salt, the vast majority of which were quickly cracked in the days following the release of the data.
DataClasses: Email addresses, Passwords
Title: MySpace
BreachDate: 2008-07-01
PwnCount: 359420698
Description: In approximately 2008, <a href="http://motherboard.vice.com/read/427-million-myspace-passwords-emails-data-breach" target="_blank" rel="noopener">MySpace suffered a data breach that exposed almost 360 million accounts</a>. In May 2016 the data was offered up for sale on the "Real Deal" dark market website and included email addresses, usernames and SHA1 hashes of the first 10 characters of the password converted to lowercase and stored without a salt. The exact breach date is unknown, but <a href="https://www.troyhunt.com/dating-the-ginormous-myspace-breach" target="_blank" rel="noopener">analysis of the data suggests it was 8 years before being made public</a>.
DataClasses: Email addresses, Passwords, Usernames
---> Checking Fullcontact..
[-] fullcontact_api not configured
[-] Full-Contact API Key not configured. Skipping Fullcontact Search.
Please refer to http://datasploit.readthedocs.io/en/latest/apiGeneration/.
---> Searching Clearbit
[-] clearbit_apikey not configured
[False, 'INVALID_API']
[-] Clearbit API Key not configured. Skipping Clearbit Search.
Please refer to http://datasploit.readthedocs.io/en/latest/apiGeneration/.
---> Basic Email Check(s)..
[-] mailboxlayer_api not configured
[-] mailboxlayer_api not configured
[-] MailBoxLayer_API Key not configured. Skipping basic checks.
Please refer to http://datasploit.readthedocs.io/en/latest/apiGeneration/.
---> Searching Slideshare
---> Searching Whoismind for associated domains
Мы получили очень много информации. При помощи базового запроса выяснилось, что пользователь с электронной почтой bob@genericdomain.org использует Adobe, Dropbox, LinkedIn и MySpace.
Обратите внимание, что для получения информации DataSploit интенсивно использует сторонние сервисы и API. Отчет выше был получен при помощи публичного сервиса haveibeenpwned.com (HIBP), который проверяет, присутствует ли конкретный адрес электронной почте в массиве скомпрометированных данных.
Соответствующая секция в отчете выше:
---> Checking breach status in HIBP (@troyhunt)
Для более детального отчета по другим раздела нужно получить API-ключ у соответствующего провайдера информации, который поддерживает DataSploit:
· https://account.shodan.io/register
· https://www.censys.io/register
· https://dashboard.clearbit.com/signup
· https://hunter.io/users/sign_up
· https://dashboard.fullcontact.com/signup
· https://console.developers.google.com/
· https://www.zoomeye.org/accounts/register
Затем нужно выполнить соответствующие настройки в файле config.py.
Заключение
В этой статье мы коснулись информационных утечек и технологии OSINT, которая позволяет получить информацию из открытых источников. В частности, был рассмотрен пример поиска адреса электронной почты по общедоступным базам данных.
Некоторые сайты и приложения имеют отношение интернет-знакомствам, игровой тематике, или предназначены для людей, придерживающихся определенной религии или сексуальной ориентации или политической идеологии. Хакеры с хорошей мотивацией и большим запасом времени могут выполнить тест на проникновение вручную, чего может быть вполне достаточно для идентификации поведенческих характеристик пользователя.
Кроме того, мы рассмотрели фреймворк DataSploit, который автоматизирует сбор информации по технологии OSINT. В частности, скрипт emailOsint.py предназначен для сбора информации об электронной почте. Более того, был рассмотрен пример, как легко выяснить сайты, на которых зарегистрирован указанная электронная почта.
Основы современной контейнеризации
08:13 / 21 Апреля, 2020
Технологии контейнеризации очень сильно отличаются от технологии виртуализации.
Автор: Черкашин Михаил, ведущий инженер отдела средств защиты информации группы компаний InnoSTage
Тема виртуализации системы очень большая и в одной статье всё не осветить. Весь материал мы разделили на цикл статей и данная статья будет первой из этого цикла:
- Основы современной контейнеризации
- Автоматизация работы с контейнерами
- Безопасность контейнеров
ИСТОРИЧЕСКИЙ ЭКСКУРС
Идея изоляции пользовательского пространства на уровне операционной системы сформировалась еще в 80х годах. Началось всё с системного вызова chroot, появившегося в ядре UNIX v7 в 1979 году наряду с другими новыми системными вызовами. Он позволял программе, запущенной с измененным корневым каталогом, иметь доступ только к файлам данной категории. С самого начала, данный системный вызов создавался для реализации функции безопасности, связанной с защитой файловой системы и процессов от повреждения или компроментации.
Как развитие этой технологии в 2000 году в операционной системе FreeBSD 4.0 появился механизм изолирования окружения, позволяющий создавать несколько копий FreeBSD, называемых jails, независимо работающих на одном ядре и разделенных между собой при помощи системного вызова jail и раздельного пользовательского окружения. Всё это было сделано, чтобы ограничить права пользователя внутри виртуального окружения.
В 1982 году Билл Джой, будущий сооснователь компании Sun Microsystems добавил системный вызов chroot в BSD. Как результат – в 2005 году компания Sun Microsystems реализовала технологию виртуализации на уровне операционной системы и назвала её Solaris Zones.
В 2005 году в ядре Linux появилась технология OpenVZ, которая позволяла запускать на одном физическом сервере большое количество виртуальных частных серверов (VPS). Это уже был шаг в сторону аппаратной виртуализации, где применялись другие техники, такие как технология паравиртуализации. Но это уже «другая история».
Для того, чтобы до конца прояснить различия между виртуализацией на уровне операционной системы от аппаратной виртуализации, стоит сказать, что аппаратная виртуализация, эмулируя аппаратное окружение, может запускать отдельные гостевые системы, а виртуализация на уровне операционной системы позволяет запускать экземпляр операционной системы только с тем же ядром, что и на основной операционной системе (Рис. 1).
Рис. 1
Однако, в связи с отсутствуем полноценной операционной системы и собственного ядра, необходимых для запуска полноценной операционной системы, отсутствуют и накладные расходы на контейнер. Так что это – два разных способа «виртуализоваться» – со своими достоинствами и недостатками. Достаточно истории – перейдем к технологиям, которые непосредственно связаны с современной контейнеризацией.
CGROUPS И NAMESPACES И ПРИЧЕМ ЗДЕСЬ КОНТЕЙНЕРЫ
В 2006 году Пол Менэдж и Рохит Сет начали разработку собственных механизмов изоляции ядра и ограничения на некоторые вычислительные ресурсы. Изначально разработка называлась «контейнеры процессов», которая позволяла образовывать группы процессов с заданными ресурсными лимитами. Начиная с версии ядра Linux 2.6.24, она под новым названием cgroups была включена в официальную версию. В этом же году появляется новая функция ядра Linux, называемая Linux Containers или LXC, в основе которой лежит функция ядра namespaces, позволяющая изолировать и виртуализировать глобальные системные ресурсы групп процессов. Собственно, namespaces – это ни что иное, как эволюция chroot, которая позволила осуществить задуманное, а именно обеспечить полную изоляцию среды.
Всё бы и оставалось на прежнем уровне развития, если бы в 2013 году не появилось программное обеспечение, способное автоматизировать процесс развертывания и управления приложениями в виртуальных средах путем объединения приложения с его окружением и зависимостями, а также ограничениями cgroups в один контейнер. Назвали его Docker.
DOCKER И OCI
Проект Docker стал логичным продолжением истории развития изолированных сред и включил в себя большинство наработок в данном направлении. Docker оторвался от всех других разработок за счет автоматизации управления контейнерами и собрал вокруг себя большое сообщество, так как с его помощью время развертывания виртуальных узлов сокращалось в десятки раз. Но очень скоро стало понятно, что Docker не идеален и слишком мало стандартов в новой области виртуализации уровня операционной системы. Docker на момент релиза в 2013 году использовал наработки прошлых лет, представляя пользователю удобный интерфейс взаимодействия с данным уровнем абстракции. Со временем сообщество, зародившееся вокруг технологий контейнеризации объявило о создании проекта Open Container Initiative (OCI), целью которого стала разработка единого стандарта в области контейнерных технологий. В 2015 году из-под его крыла вырвался инструмент для запуска контейнеров runC (данный runtime-движок начал так же поддерживаться Docker'ом с версии 1.11 в 2017 году). (Рис. 2) Достаточно теории, давайте перейдем к практике.
Рис. 2
ПЕРВЫЙ ЗАПУСК
Для начала, определяемся какое ядро нам необходимо для запуска контейнеров, т.к. от этого будет зависеть платформа для разворачивания среды Docker. На выбор у нас есть: Windows, Linux и Mac. Тут стоит оговориться, что контейнеры, разработанные для среды Windows на Linux не заработают (например Windows IIS сервер под Ubuntu), ввиду изначальной разности этих операционных систем, так как мы имеем дело с виртуализацией уровня операционной системы. Здесь мы рассмотрим случай, когда ядром для запуска контейнеров будет ядро Linux.
Первое, с чем нам придется столкнуться – это установка дистрибутива и создание учетной записи на сайте docker.com. Для установки последней версии Docker'а в ОС Ubuntu набираем следующие команды:
# проверяем наличие обновлений
$ sudo apt-get update
# устанавливаем Docker CE (Community Edition)
$ sudo apt-get install docker-ce docker-ce-cli containerd.io
Для проверки работоспособности вводим следующую команду:
$ sudo docker run hello-world
Docker подтянет тестовый образ контейнера hello-world и запустит его! (Рис. 3)
Рис. 3
Далее – изучим инструмент под названием Docker Hub. Это такой App Store в мире контейнеров. Для доступа к хабу нам необходимо создать учетную запись на сайте https://hub.docker.com/ , где мы сможем размещать свои образы и делиться ими со всем миром, а также загружать кем-то уже созданные контейнеры, не тратя время на их сборку. Тут стоит рассказать об одной особенности работы с «чужими» контейнерами. Контейнер может собрать и опубликовать в Docker Hub любой желающий, не всем издателям стоит доверять, так как в контейнерах могут содержаться как устаревшие, так и уязвимые версии пакетов и приложений. Docker проверяет наиболее популярные образы и маркирует их тегом Docker Certified (Рис. 4).
Рис. 4
Есть ещё одна разновидность «проверенных» контейнеров – официальные образы. Эти образы представляют собой образцово-показательные контейнеры, собранные по всем правилам и лучшим практикам Docker-платформы. (Рис.5)
Рис. 5
НАЧАЛО РАБОТЫ
Мы поставили Docker и создали учетную запись, разобрались как подходить к выбору контейнеров. Теперь настало время попробовать запустить что-нибудь полезное и поэкспериментировать с его работой. Для начала выберем объект наших испытаний – им будем CentOS, которую мы запустим в окружении Ubuntu. Для того, чтобы запустить какую-либо команду на CentOS в виртуальном окружении нам потребуется всего одна команда:
$ sudo docker run –t centos:latest /usr/bin/ top
Если Docker не найдет у нас уже локально выгруженный контейнер – он выгрузит его из Docker Hub'а и сразу же запустит контейнер, выполнив в нем команду top.
Как мы видим (Рис. 6) – запущенный нами процесс – единственный и ничего кроме него контейнер не видит. Мы запустили свой полностью рабочий контейнер.
Рис. 6
ИТОГИ
Технологии контейнеризации очень сильно отличаются от технологии виртуализации. У этой технологии очень много плюсов и многообещающее будущее.