Весьма распространено мнение о том, что социальная инженерия является наиболее эффективным методом взлома корпоративной защиты. Спорить не стану, потому что мнение это -- верно. Не скажу, что оно математически доказуемо, но практика его подтверждает. Да и интуитивно понятно, что все технические "дыры" возможно залатать, а на каждый 0-day найдется свой IPS, главное чтобы бюджет был по-больше. А вот гарантированный способ защититься от человеческой глупости пока не изобретен и в ближайшее время на рынке вряд ли появится.
На этапе подготовки социальной атаки, основной задачей является т.н. "домашняя работа" -- сбор и анализ публично доступных данных о компании-цели. Среднестатистический корпоративный сайт содержит основную информацию о компании, ее продуктах, способах связаться с представителями и т.д. Этих данных может быть вполне достаточно для нормального пользователя Интернет, но... не наш случай. Помимо "открытой" информации, на сайте как правило существует уйма "скрытых" данных, которые могут оказаться полезны для осуществления социальной атаки.
Все возможные сценарии перебирать не будем, а очертим для примера один классический план. Вопреки многочисленным недостаткам и уязвимостям, во многих компаниях используется ПО Adobe Actobat Reader (это предположение #1). Также, традиционно, многие сотрудники ИТ все еще используют привилегированные учетные записи для интерактивного входав ОС на рабочих станциях (это предположение #2). Комбинация этих двух фактов дает нам надежду получить доступ к админской учетке путем эксплуатациикакой-нибудьизвестной уязвимости в Adobe Reader, благо последний не прекращает ими радовать чуть ли не ежемесячно. Для этого всего нужно-то, -- сесть за Metasploit да скрафтить зловредный PDF-ник, содержащий нужный exploit. В качестве payload поместить в него, скажем, meterpreter/reverse_http (все еще жутко глючит, но если часок поколдовать, то можно добиться нужного результата). А потом разослать этот PDF-ник во вложении к письму, "декорированному" в корпоративном стиле какого-нибудь известного вендора из числа поставщиков компании-цели. То есть, дело за малым, осталось всего лишь уточнить некоторые детали:
- от кого слать письмо, для того, чтобы его гарантированно прочитали;
- кому слать письмо, чтобы его гарантированно если не прочитали, то хотя бы открыли.
На вопрос "От кого?" ответы можно найти следующими способами.
- Просканировать "внешний периметр" компании-цели на предмет версий оборудования и ПО. В результате получим список предпочтений.
- Проштудировать сайты местных интеграторов на предмет хвастовства об очередном супер-внедрении какого-нибудь мега-аппаратно-программного комплекса в компании-цели. Кстати, интегратор вероятно осуществляет первый уровень поддержки этого мега-решения, так что можно рассмотреть вариант действия от его лица.
- Дополнительно, стоит профильтровать на тему мега-внедрений айтишную прессу, так как она с голодухи только об этом сейчас и пишет.
- Подробно изучить веб-сайт компании-цели, возможно она сама не постеснялась похвастаться тем, какая она современная и технологичная, и какие мега-решения она использует. И какие версии. С точностью до пятого разряда.
- Если охота экстриму -- можно заняться dumpster diving-ом или попросту порыться в мусоре. Поверьте, инвойсы уничтожают в шредере очень редко, а коммерческие предложения -- почти никогда.
Альтернативно, можно "забить" на возню с вендорами и интеграторами и проработать вариант отправки письма от имени генерального или еще какого-нибудь директора. Лучше, с GMail-а и когда "автор" будет в командировке или в отпуске. Общий смысл послания: "вашу мать, опять VPN не работает", только в предельно вежливом "корпоративном" стиле. А во вложении -- PDF-ник со скрином ошибки. Скажете, подозрительно, могут догадаться? Поверьте, никто не заподозрит неладное, от менеджеров и не такого ожидать можно.
В общем, "что" и "от кого" -- выяснили. Осталось определиться "Кому?"Тут нам и поможет metadataиз документов хранящихся (обычно в изобилии) на сайте компании-цели. Почти все типы документов "круче" текстовых содержат в себе метаданные -- вспомогательную информацию, помещаемую в документ программой-редактором для каких-то одной ей понятных целей. Среди этих данных обычно содержатся всяческие параметры формата документа: типы, идентификаторы, кол-во слов/символов, даты создания и последнего сохранения и пр. Но самое главное -- версия ПО редактора, в котором документ был создан, и имена пользователей, создавших и/или редактировавших документ. Эта информация -- золото для социального инженера, так как она почти всегда правдива и служит отличной отправной точкой для дальнейших исследований. Ну например, получив из метаданных документа имя пользователя vpupkin мы автоматически имеем:
- имя пользователя в домене компании-цели -- vpupkin;
- действительный адрес электронной почты -- vpupkin@victim.tld;
Далее, отправляем запрос "Пупкин Victim LLC"в LinkedIn, Мой Круги т.п. -- личность жертвы установлена. Роемся в его контактах в поисках разнообразных айтишников (если он сам таковым не является). Эту процедуру повторяем до тех пор, пока не составим внушительный список ИТ-персонала компании-цели. Что до полезности версии ПО, тут разговор короткий. Даже если она и не позволит подобрать конкретные эксплойты, то хотя бы поможет составить общее впечатление о культуре ИБ в компании: используются ли устаревшие программы, обновляются ли они после выхода критических патчей безопасности и т.п.
В следующем посте я напишу о том, как собирать необходимые метаданные из открытых источников, как этот процесс автоматизировать, а также о том, как защитить "критичные данные от утечки в виде метаданных.
Больше о метаданных в этом блоге
Больше о метаданных в этом блоге
